Most projects don’t deliver their original scope: 54% of projects fail to deliver the agreed-upon functionality.
One of the reasons for that is scope creep – and that’s what this article is all about.
What is scope creep?
Scope creep in project management is where additional requirements are added to the project, beyond what was originally agreed, and these additions are not formally authorized.
Scope creep happens when the project sponsor says, “Can you just…?”
(By the way, the answer to that question is: “Yes, let me analyze what the impact will be and bring you a recommendation for what that means for our current budget and timeline.”)
Scope creep can happen at any time after the project formally begins, and is one of the most common reasons why projects go over budget and past their deadline.
Approved changes vs scope creep
Everyone expects change to happen on projects. The difference is that approved changes are fully analyzed, documented and incorporated into the project with their impact known. Scope creep is where unapproved changes end up in the project.
What is feature creep?
Feature creep or requirement creep is basically the same thing as scope creep. The term refers to how the project’s requirements or feature list grows over time without proper control.
Scope creep is the more common term, but you might hear both, especially if you are working in software development.
What causes scope creep?
So why does scope creep happen? It’s caused by lack of requirements management. When the project manager is not actively managing changes to scope, there is no control about what is in and what is out. Basically, anything goes.
According to research from PMI*, the top 5 causes of scope creep are:
- Ambiguous or poorly defined scope i.e. unclear requirements
- Lack of any formal scope or requirements management process i.e. a weak change control process
- Inconsistent process for collecting requirements
- Lack of leadership or stakeholder involvement (which sometimes shows up as stakeholder pressure)
- Project length (because long projects have more time for sponsors to refine their ideas and for the original business proposition to evolve).
Poor planning is also a cause. A vague project charter and undefined deliverables is like an open door for scope creep. If you don’t define what it is you are doing, how can anyone say that a new request is outside the original agreed scope? Define your success criteria and requirements up front to help keep the scope tight.
Gold plating vs scope creep
Scope creep happens when the stakeholders ask for additional work. Gold plating happens with the project team add in extra features that the client didn’t ask for. The outcome of both is the same: more work, and probably more cost and more time.
The role of stakeholders in scope creep
Who is responsible for scope creep? The project manager is responsible for letting scope creep affect the project, but it’s normally stakeholders, and in my experience, senior ones, who add the requests in.
Ultimately, it isn’t the project manager coming up with new requirements and asking the team to “just do it”. Well-intentioned stakeholder requests can end up in the project without proper boundaries, and that’s on the project manager.
An ineffective project manager will say yes to every change without considering the impact on the original plan, the team, the budget and the project schedule. And they won’t update the scope definition document (or however you record your scope), which is another problem.
What’s so bad about scope creep anyway?
Scope creep is bad for projects because unauthorized changes:
- Add additional cost and cause budget overruns
- Add additional time and cause schedule delays
- Take the team away from other work because they are spending more time on this project.
There’s a business impact to making a project last longer, cost more and tie up resources. It means other projects can’t start on their expected date, and that overall the full cost of this project goes up.
There’s likely to be a delay to receiving the benefit of this project, and because the resources are busy working on doing extra stuff, they aren’t available to start delivering value on new projects.
In real life, changes are often expected to be incorporated “just like that” without any impact on time or budget. The project team has to find creative ways to deliver what is expected, which normally means cutting corners on the original scope or working overtime until it is done.
Have you ever worked on a project that seemed like it would never end? That’s probably because people kept adding in new requirements to the task list and you had to keep working… with no end in sight.
How to identify scope creep early
Here are some warning signs for scope creep that you might spot on your project:
- Task lists getting longer
- Unlogged change requests
- There are more project delays than you would expect
- Team members not knowing what’s a priority
- Stakeholders asking about items that you know aren’t in scope.
Use backlog reviews or a regular scope check in session to make sure that you’re having regular conversations about what’s in and what’s out.
Your project might already be slipping if you feel like the time is getting given more and more work and the project is never going to end!
It takes its toll on team morale. Scope management is the way to deal with that, so let’s talk about how we can use change control protocol to help with it all.
What is change control and why is it important?
Change control or change management is the process of managing unplanned but desired influences on the project. It’s the process of ensuring changes are properly evaluated and incorporated into project plans, and it should be part of your standard project controls.
Change management is important because any change to the baseline scope needs:
- to be analyzed for its impact on project objectives
- to be analyzed for its impact on the approved statement of work
- to be understood as it modifies your existing plans
- to be recorded properly for a complete audit trail.
Practical strategies to prevent scope creep
How do we avoid scope creep? It’s actually pretty easy. Scope creep can be prevented by making sure changes are not introduced into the project without the appropriate analysis and control.
You should:
- Define scope clearly
- Get scope approved by all stakeholders
- Establish a change control process
- Communicate boundaries and push back when stakeholders try to get extra work added outside the formal process.
These are good habits to have as a project manager, and they help build everyone’s confidence in your ability to get the work done.
How to set up a change control process
Managing scope starts and ends with a robust
- Document the change request in the change log
- Analyze the request briefly to establish ownership
- Assign an owner who can more fully analyse the change impact
- Assess the priority of the change request
- Analyse and report back on the change impact
- Decide the course of action: approve or reject the change request
- Record the outcome in the change log
- If approved, update all relevant documentation
Step #1: Document the change request in the change log
Ask the person who has suggested the change to be as specific as possible and put the change in writing. If they have any supporting materials (like quotes or estimates for the work that needs to be done) that might help the analysis, ask for those too.
The change log is like a risk or issue log and in its simplest form is a document where changes and activities are written down. I just use Excel as a simple way to record what’s proposed and what’s approved.
Step #2: Analyze the request briefly to establish ownership
As a team, look at the change request to decide whether to take it forward. This gives you the chance to discuss the political motivations behind the change and to throw out anything that is blatantly impossible.
The change control process can be used by project stakeholders to bring things to the project team’s attention or to raise issues, so you also have the opportunity to check whether it is a legitimate change or a query that is better handled via a different route.
Step #3: Assign an owner who can more fully analyse the change impact
Step two will have flagged who is best suited to carry out the full impact analysis. Allocate an owner to the change: someone who can co-ordinate this activity.
Step #4: Assess the priority of the change request
Give the change request a priority. Is it a necessary change, important or nice to have? This provides a sense of urgency for planning the impact analysis.
Step #5: Analyse and report back on the change impact
The relevant people should carry out the impact analysis on the proposed change looking at:
- what elements would need to change
- what the impact would be on the schedule/budget/resources/quality/business case (remember the contingency budget is not there to pay for new requirements!)
- what effort would be required to make the change
- what the impact would be if the change is not made.
Stakeholder communication is important here, so the right people are engaged. The owner should report back to the project team (larger projects may have a delegated change control team or forum) with a recommendation.
Step #6: Decide the course of action: approve or reject the change request
Take the decision, ratifying it with the relevant stakeholders and those affected by the change.
If you have to say no to scope changes (without damaging relationships) I would recommend leaning into the ‘why’. Explain the rationale for the decision, which could be that there isn’t the time or budget to incorporate at it this time. You’re not saying no to the person, you’re saying no (or ‘not yet’) to the specific request.
And probably the decision will be made by a committee or senior person, and you are reporting back what that decision was.
If you’ve done good stakeholder engagement in the previous step, the outcome won’t come as a surprise to anyone!
Step #7: Record the outcome in the change log
Complete the documentation for the change log. Note whether the change request was approved or not, the rationale behind it and the date the decision was communicated to the requestor.
Changes could be approved, rejected or put on hold to review later.
Include where the impact analysis can be found so if there is a query or similar change raised later you can find it again easily.
Step #8: If approved, update all relevant documentation
Finally, if the change is approved, cascade the relevant changes into all the project documents that need updating, like the project initiation document, scope statement, plan and budget.
Issue a new version of those documents so everyone has the current view. If the change affects project deliverables, make sure their descriptions are updated and that the teams working on them know that things have changed.
Your company’s process may be slightly different. Follow internal guidelines if there are any but the activities will be largely the same as described here.
How to handle scope creep when it’s already happening
Let’s say that you recognize your project isn’t the best when it comes to controlling scope. Acknowledge that the change has ended up in the project by talking to stakeholders. Explain what the impact of the change is. By this point, you’re probably already committed to delivering it, so focus on the impact to budget, timeline, resource or anything else.
Agree the next steps with stakeholders. For example, you could continue to work on the change but add extra time, or reduce work in other areas to make up for the resources required to do this change, or something else.
Catching any change mid-project is better than not catching it at all, so just do what you can.
Tools and templates for keeping scope in check
Your normal project management tools will help you manage scope. For example:
- RACI matrix: Sets out who can submit changes and approve new work
- Change log: Documents what changes have been approved
- Scope templates and requirements documentation: For documenting what has been agreed
- Steering group decks or project board reports: Useful for showing what changes have been submitted/approved
3 Examples of scope creep
Example of scope creep in software development
Scope creep in software development occurs when more features are added after the original feature set has been agreed.
Example: The customer sees a wireframe of the software and decides that it’s so good they want to extend functionality and add in more product options for the end user. They think this can be done for free and within the existing timescales – that’s the impact of scope creep!
Example of scope creep in construction
Scope creep in construction occurs when the build project team is asked to introduce more features than are included in the signed-off plans.
Example: You are two months into the build of a new hotel. The hotel owner decides that it’s necessary to convert a floor of guest bedrooms into staff accommodation, meaning smaller units and changing the elevator configuration so that guests can’t access that area of the hotel. This involves reworking the architectural plans but can be done in the current budget. The project manager agrees without consulting the team… and then finds out that it’s going to take time to have the new plans ready. That’s going to create a delay – all because the change wasn’t analyzed properly.
Example of scope creep in Scrum
Scope creep in Scrum would happen when more user stories or backlog items are added to a sprint.
Example: After the backlog grooming session, the team agree what’s going to be in the next iteration. Work starts as normal. A few days pass, and the Product Owner attends a daily stand up meeting to tell the team that they need to include an extra feature in the sprint. It has to be ready for demo along with everything else. Because that feature was sized as a small development, she thinks it will be “easy” to add that in.
FAQ
What is scope creep in agile?
What is the opposite of scope creep?
He didn’t define scope crush in his tweet but here’s how I define scope crush: doing less, better. Crush your scope down as small as it will go and deliver that. Then build on it incrementally.
How do you identify scope creep?
Is scope creep a risk?
How do I deal with a stakeholder who keeps adding new requests?
Generally, you want to minimize changes as they do slow down the velocity of the team, so it probably points to not having a clear scope and stakeholder buy-in at the beginning.
* Larson, R. & Larson, E. (2009). Top five causes of scope creep … and what to do about them. Paper presented at PMI® Global Congress 2009—North America, Orlando, FL. Newtown Square, PA: Project Management Institute.
This article first appeared on Rebel’s Guide to Project Management and can be read here: How to Manage Project Scope Without Scope Creep (with examples)
