Scope creep is the uncontrolled expansion to product or project scope without adjustments to time, cost, and resources.
In other words, scope creep is a change to the project scope without considering and accounting for the impact of the change on schedule, cost, quality, resources, risks etc.
Example of Scope Creep
Here’s a story for you to help understand the problems associated with scope creep.
Bob, a new project manager, was managing a project to develop a mobile app for a customer. When the work on the app was underway, the customer asked for adding email notification feature to the app. The original scope did not have this requirement. However, as the project was one week ahead of schedule and the new request was fairly simple to implement, Bob agreed to add the feature to the scope without a formal change request, or asking for additional time.
Fast forward two weeks, the internal QC found a few defects with the email notification feature that required some rework. When it passed the internal quality control, and went to the customer for acceptance testing, customer requested to add two modifications to the notification feature. After those changes were done, customer team found that the images in the email were being blocked by their firewall. After making configuration changes to the firewall, customer learned that all official emails must follow their corporate branding guidelines. So, the customer came out with a new template for the email.
You can see where this is heading. A seemingly small change that was “absorbed” by the team, ended up creating a lot of work for the team. If formal change control process was followed, some of these issues could have been avoided. The team would have evaluated the impact of the change on schedule, cost, quality, risks, and customer satisfaction before deciding to add the new feature.
As explained in the article on Triple Constraints, any change to the project baselines needs to be evaluated for its impact on project scope, schedule, cost, quality, resources, risk, customer satisfaction and other project constraints. In most cases, when one constraint is changed, there is impact to one or more other constraints.
Common Causes of Scope Creep
Let’s review some of the common reasons for Scope Creep.
Ambiguous scope definition - if the project scope statement is worded loosely or not detailed enough or the scope is not properly decomposed into work packages and activities, it may leave the door open for interpretations and introduce scope creep. Therefore, it’s important to have the right level of details in the project scope statement, work breakdown structure, and activity definitions.
Missed requirements - use a formal process for requirements collection and documentation, requirements traceability and approvals to avoid missed requirements.
Lack of strong sponsorship - the sponsor defines the vision of the product and helps to control the factors that introduce changes. Therefore, it is important for the project manager to actively engage with the sponsor throughout the project.
Length of the project - long drawn projects tend to have more scope creep. It’s better to split big projects into smaller sub-projects to have better control over the scope.
Demanding customers - some customers want things done for cheap or even free, and push the project team to add additional scope to the project without accounting for additional cost and time. It is important to have the change control process clearly outlined in the contract such that all changes go through formal change control.
Unclear roles and responsibilities - if too many changes are being introduced, it’s likely that the roles and responsibilities are not clearly defined. Use a RACI matrix to define the responsibilities related to requesting, analyzing, reviewing and approving change requests.
In summary, scope creep is always bad for the project. No matter how small a change is, if it impacts the project baselines (approved scope, schedule, budget etc.) it must go through the integrated change control process.