Scope Creep!!!!
"How do you manage scope creep in your projects?" Question came from the interviewer. Being run many projects and faced with so many such situations, I could give some examples and what I have done earlier. Interviewer might have satisfied but I was deeply thinking coming out of the room on what I was really doing all these years on 'Scope Creep'?
Scope creep is part and parcel of any projects (especially IT Projects). It is very unavoidable and most of the projects nowadays have contingency plans from the beginning itself to manage this. According to the maturity levels of the client organization scope creep would fluctuate. Also gaps in initial scope development and expectations setting would influence scope creep through out projects.
How can we manage scope creep? I am still using the term 'manage' as we cannot get rid of scope creep anyways. What we can do is to manage it well so that client is not unhappy and scope is not ballooned out of our control. First step is to understand the business processes behind the requirement. I am always of the opinion that to have holistic view of IT Projects, PM should have full understanding of the business processes and the final objective from the project. This will help us while negotiating additions to scope coming on the way to be prioritized, and discussed with the users in a language that makes sense to them. Most of the times, scope creeps happen because users feel them as required but will not be a priority when connected to the business process.
Second is to understand the maturity levels of the client organization to see when and where to negotiate. In low maturity organizations, you may have to take this up to steering committee (again prioritizing based on business processes and its criticality) or the project sponsor himself. We tend to accept initial scope creeps and then only escalate as in these organizations, definition of project is not very different from operations!! As the maturity improves, negotiation can be at core team level or sometimes at the requester level itself. PM has to take a discrete decision on this to ensure this doesn't fire back!
As a prequel, having more involvement from delivery team (PM and/or his team) in the initial scope preparation will help but this is not very practical at times. A better approach is to get client representatives (sponsor, steering committee and/or core team) during project planning to understand the importance of project baseline in meeting their business objective. They should be convinced that minimizing the scope creep is of their best interest!!!
Director - Data Analytics * Data Governance & Management * Business Intelligence * Information Strategy
8 年To add my thought to your good post, Nishen - is that the number one tip is never forget what the "project scope" is. Everyone will continually try to get to make seemingly "small" scope changes, which the Project Governance Team should resist. After all if Project Team give into one person's request, they create a precedent and before long a little change starts snowballing and voila PM has lost control of the project and potentially the project management career. Another trick for controlling scope creep is to "phase out the project". Projects have phases. We usually roll out a simple, base version of say, a software product before moving on to more complicated, advanced versions. What we would like to do is to create a little timeline on Powerpoint showing people that there ARE subsequent phases on specific dates that will allow them to roll in additional features in the software. Many of the users worry that if they don't squeeze in every last enhancement into the system by a particular date, they will NEVER get it into the system. A general practical approach which a PM should practice is well, take them to lunch, show them the timeline with phases and educate them. Let's tell them “Look, there are subsequent phases for the project. You can roll in this extra screen in Phase 2. In Phase 1, let's get the basic functionalities in first”. Reasonable users will agree to this approach and our Delivery Team will not have a tough time to get the basics right.
IT Auditor
8 年A dreadfull term for a consultant.