The term “Scope Creep” doesn’t need detailed explanation, as most of the project managers would have faced it atleast once. Project managers would have to love it because it’s one of the reason why they are in the project. I was just kidding…
Even for a project with well-defined requirements and specifications, project managers have to be watchful of scope creep. This is because the scope creep affects the other project development pillars – cost, time and quality apart from scope.
What is scope creep?
As Wikipedia describes it “Scope creep (also called requirement creep and feature creep) in project management refers to uncontrolled changes or continuous growth in a project’s scope. This can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered harmful.”
What causes scope creep?
There are definite reasons for scope creep. It generally tends to occur when new features are requested to product designs that are already approved without any equivalent consideration of increase in budget, time, and resources. Other reasons that can contribute to scope creep, but not limited, are as follows:
- Poorly executed requirements analysis and requirement gathering activity without involving all stakeholders
- Poorly documented specs that is more subjective in nature
- Non-involvement of users at an early stage to understand their requirements
- Indulge in “Gold plating” by offering something outside of the project scope in a wrong belief that it will add value to customer
- Misunderstanding the complexity of project, especially when venturing into something new and different
- Uncontrolled changes due to lack of following the standard project development processes
- Poor communication between the provider and requester
- Unawareness of project development processes and the project cost implications by the parties involved
- Lack of coordination among stakeholders
- Delayed response to queries
Can we prevent Scope Creep?
No, we can’t prevent scope creep. The business requirements keep on changing in the current dynamic environment .We can’t do anything to stop the changing requirements, but we can definitely control and manage it.
How to control Scope Creep?
Traditional Projects (Waterfall model): Most of the traditional projects have well defined requirements that are identified at an early stage, the need for changes in scope can be deferred to a viable future date. In such projects, the requirements can also be controlled by engaging the involved parties to go through a well-defined change management process. This will help to re-assess the impact in all areas (budget, time, quality, resource availability etc.) before taking an appropriate decision.
Agile Projects: There is some misunderstanding about how scope changes should be managed in agile development. In agile projects, controlling scope isn’t much different. Agile process is about being flexible. Agile is about how we can be “flexible” in accommodating a scope change. Please refer the term “flexible”. This is different from scope creep. Flexible scope in agile is about controlled scope changes. Whereas scope creep is about uncontrolled increase of scope. Controlling scope in agile involves assessing the scope changes for the items identified to be worked in the upcoming iteration. After the assessment, this would need to undergo prioritization by the concerned technical staff and business sponsors. The scope of assessment is limited to the items identified to be worked for the next iteration. Thus it doesn’t delay the current phase of development.
Flexible scope in agile means the product owner will ONLY add new features after they have made space by removing other features in the list based on the priority. Also due to continuous testing and demonstration of the implemented features, the required changes can be identified much earlier without impacting the overall project schedule.
Impact of scope creep:
In addition to the obvious impact to the planned schedule, cost and quality, scope creep also affects the morale of the team members to some extend even if the customer is willing to accommodate the cost and schedule implications. Thus all care must be taken to prevent and control the scope creep.
How to fight the scope creep?
- Clearly define and document the project scope for all core functional and nonfunctional requirements. This can be used as reference in future when a request for change comes in
- Conduct frequent demos to get the customer feedback and validate the implemented functionalities with key stakeholders as soon as a feature is developed
- Be vigilant of any additional requirements coming in and be in control
- Categorize and Prioritize the scope changes by discussing with relevant technical members and business sponsors
- Provide frequent updates on the schedule and cost to the customer
- In case of fixed cost projects form a change control board involving members from both parties to review the implications of the scope changes to project budget and schedule
- In case of scope creep in an agile project , discuss with the product owner to remove low priority items equivalent to the effort of the new additions from scope changes
- In agile projects, conduct a retrospection meeting involving all members from both sides at the end of the spring to discuss and review the implications of the scope additions and ways to minimise it in future.