There are many reasons as to why project scope might increase, but here are a couple of the common ones I've encountered:
- Something was forgotten or assumed to be not required
- A change in the environment (e.g. competitive pressure, internal strategy change) requires something extra
Using good scope management practices (e.g. developing a WBS or story map) along with a healthy dose of risk management and ensuring that assumptions and scope exclusions are surfaced OR if the project's context is suitable, considering an adaptive lifecycle are ways to reduce the potential for scope increase.
Kiron Saving Changes...
Tascha HalliburtonProject Manager| Braathe EnterprisesBentonville, Ar, United States
Hi Marvin,
I agree with Kiron’s points on how the project scope can be widened to include various changes in the environment. I actually had a conversation with a colleague a few weeks ago who cautioned PM’s in expanding an agreed upon scope when a client suggests changes outside of the project plan. The risks of which are obvious: risk of the project going over budget, exhaustion of project resources (i.e. staffing), and non adherance to the agreed upon project timetable.
During my Project Management time at a consulting firm, I actually had a fellow PM face this very same issue when a client mid-way through the project suggested changes that were outside of the scope. The changes suggested by the client weren’t minor changes either. The changes would have taken the project so far off scope, that it would be impossible to complete the project on time and under budget. As a result, the firm terminated the project before it was finished. In part because of the client’s incessant demands, but also due in part to the client’s unwillingness to finance resources that would accommodate such changes.
From witnessing this experience, I would strongly advise every PM to take their time in the project planning phase and creation of the project charter to make sure ALL the stakeholders are on the same page as far as deliverables and work packages goes. If these are not agreed upon, I would recommend not going forward with the project until an agreement is met. Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
I tend to find any need to increase scope comes from feedback from the stakeholder whereas the identification of such [gaps] can be discussed and prioritized accordingly. If it is determined that the identified must be included now, then the discussion can be had and the impacts mitigated.
The direction this will take ideally would be discussed ahead of time so when scope is discussed, the process is of no surprise. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Something mostly forgotten is all related to project is defined from product/service/result to be created. Then, project scope is defined from product/service/result scope. The last one is the driver to any change into project. Saving Changes...
Marvin PoughBusiness Analyst/ Project Manager| 22nd Century TechnologiesEast Point, Ga, United States
Thanks for the responses? Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
It is never necessary to change the scope because a stakeholder insists.The reasons given for possible scope change are valid and common. Whenever a change is required the impact should be analyzed and presented to the change board, or project sponsor in the absence of a board. If a change can be justified with positive cost/benefit then typically the change is approved and the scope altered, if not it can always be considered for a subsequent phase.A more agile approach which looks at value instead of just scope you might consider dropping a lower priority requirement for the change if it can be prioritized higher. Saving Changes...
We always blame the Business Users for not having a documented business processes and therefore new requirements emerge when asking for their feedback . I have had this assumption for long time that but now I could see why some projects have to be agile because the scope is not clear from the beginning and BU don't know what they really want . So to answer your questions if the project is waterfall increasing the scope is not a good practice unless they mitigate the risks associate with increasing scope but if the project is agile then scope definitely would change throughout the project if this change would add value to the product and stakeholders . Saving Changes...
Using trend analysis to examine project performance and using variance analysis to compare the scope baseline to actual output results will help to determine feasibility of increasing the scope. Saving Changes...
Are you asking: "when do you increase scope?"
Or are you asking: "when do you MANAGE scope increase"?
Scope can increase (or change or decrease) for many reasons, many of which are covered above, and including changing requirements or market conditions, early feedback on what you're building, change in stakeholders or target groups, etc.
Scope Management is used when it's important to manage/control the impact of scope changes, which can impact timelines, resources, costs, quality, and other project factors. Formal Scope Change Management, typically through a formal Change Request process, is the method of ensuring that key people agree to the impact(s) BEFORE the change is taken on. Saving Changes...
