Scope creep
Smart strategies to avoid scope overblow
Understanding the root causes
Scope or requirement creep is an often-referred expression for adding unauthorized deliverables to a project timeline that affects resource and time utilization. The risk of scope creep is that the project will not finish by the predefined timeline, or it will face a cost overrun. According to Dey, Bennett and Clegg (2021), scope creep has a high impact on implementation projects. Scope creep mainly occurs in two large phases: in the initial planning and during the production phase.
The project manager and the project team are responsible for assessing the requirements of users in a quality and extensive manner. If the initial project charter is not clearly defined in the business case and on the high-level features, then the requirement assessment will not be precise. As a result, users tend to extend the requirements list throughout the lifetime of the project as they discover new elements, causing delays and cost overruns.
In other cases, it might also occur that the project team conducts unauthorized changes, mainly for three reasons: First, there is no change control process to handle incoming change request; second, the project team does not adhere to the existing change control mechanism as it would take too much time or bureaucracy; third, the project team wishes to impress final users with a positive attitude and they quickly implement some changes outside of the change control system to favor the final users.
Stabilizing the root causes
In order to reduce the project’s exposure to scope creep, the boundary of the project has to be clearly shaped and embedded in the project charter, signed off by the sponsors and final users. The boundaries of the project need to be kept in mind during the requirement assessment, not to overburden the project scope with unreasonable and unjustified requests. It is advised that the final draft of the scope statement is countersigned or validated by the supervisor of the final users, thus a more holistic view confirms the aggregated requirements.
Moreover, the project team shall develop a well-established and tailor-made change control system that describes how incoming change requests will be handled. This ensures that the project team can track each request and offers transparency for final users.
Project Management Institute (2017) suggests the following change control system method in PMBOK 6th edition: Each change request shall be captured in written format in the change management log, and its estimated schedule and cost impact shall be determined by the project team. If the baseline schedule or cost is affected, then the change request element has to be evaluated by the Change Control Board (CCB) for approval, deferral, or rejection. From this point, the approved change requests are available for the project manager for scheduling and integration.
Summary in short
- Capturing initial requirements as detailed as possible to fix and frame the scope.
- Applying effective requirement collection and analysis techniques.
- Setting up a rigid change control process for the project team and transparently communicating it to stakeholders.
- Validating and signing off on the requirements by the stakeholder before actual development or configuration begins.
- Documenting change requests for transparency and clear project history.
ARE YOU READY to take your knowledge to a new level?
Review our End-To-End Masterclass
for comprehensive knowledge.
Start your journey today!
Bibliography
– Dey, P. K., Bennett, D. & Clegg, B., 2021. Managing risk in enterprise resource planning projects, Birmingham: Aston Business School.
– Project Management Institute, 2017. A Guide to the Project Management Body of Knowledge (PMBOK Guide). 6th ed. Philadelphia: Project Management Institute.
