How to Manage Project Scope Without Scope Creep (with examples)
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.
The ‘formally authorized’ part is important because you can, of course, make changes to what’s in the scope statement at any point. It’s normal to make scope changes as you go. However, those changes should be fully analyzed, documented, and incorporated into 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?
Scope creep is 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.
The top 5 causes of scope creep are:
- Ambiguous or poorly defined scope
- Lack of any formal scope or requirements management process
- Inconsistent process for collecting product requirements
- Lack of sponsorship and stakeholder involvement
- Project length (because long projects have more time for sponsors to refine their ideas and for the original business proposition to evolve).
These are laid out in a research paper from PMI*.
Who is responsible for scope creep?
The project manager is responsible for letting scope creep affect the project.
Ultimately, it isn’t the project manager coming up with new requirements and asking the team to “just do it”.
However, 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.
What’s so bad about scope creep anyway?
Scope creep is bad for projects because unauthorized changes:
- Add additional cost
- Add additional time
- 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.
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.
Change control is important because any change 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.
How to avoid scope creep
Scope creep can be prevented by making sure changes are not introduced into the project without the appropriate analysis and control.
How do you do that? Managing scope starts and ends with a robust
The eight steps of a
- 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.
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.
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, plan and budget.
Issue a new version of those documents so everyone has the current view of the project scope and requirements.
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.
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?
Scope is flexible in agile, so scope creep doesn’t really exist at a project level. The risk of scope creep comes when additional scope items are added part-way through an iteration or sprint. There are formal approaches in agile approaches to avoid this, and the Scrum master or agile team should be on the look out for when new features are added after the backlog items for the iteration have been set.
What is the opposite of scope creep?
The opposite of scope creep is scope crush. I first came across this term via Jason Fried, founder and CEO at Basecamp.
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?
You can identify scope creep because of the impact it has on the project plan. Look for tasks taking longer, unapproved work being done that is not in the original baselined scope or on the change log and listen out for annoyed colleagues complaining that users are never satisfied!
Is scope creep a risk?
Scope creep is a risk for most projects, especially in situations where you don’t have a full understanding of the project requirements. However, you can manage the risk via good change control processes and most project managers would not add scope creep to their risk log.
* 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.
