Introduction to Scope Creep & Potential Harms
This article explores the bane of many a project manager’s existence: scope creep. We’ll begin by defining scope creep and the danger scope creep presents to project teams and stakeholders. We’ll then examine specific causes of scope creep and provide solutions for savvy project teams hoping to prevent scope creep from escalating to full-blown project failure.
What Is Scope Creep?
Scope creep occurs when the original project scope begins to expand, creating increasing demands on the project team. It’s important to note that almost all projects will have their requirements change over the course of an engagement—what distinguishes scope creep is that these changes are not authorized by all parties. Scope creep can happen intentionally, such as when an underhanded client tries to get more out of a project than they paid for, or unintentionally, such as when the project team underestimates the time required to conduct quality assurance and consequently misses a deliverable deadline. Scope creep can be driven by individuals at all levels of a project’s staffing, including the client executive team, the project team lead, or a business analyst on the project team, and can occur at almost any point in a project’s life cycle.
The opportunities for scope creep may seem endless, and that’s because they are. Scope creep is an omnipresent feature of modern-day project management. According to PMI’s 2018 Pulse of the Profession survey, 52% of projects completed in the past 12 months experienced scope creep or uncontrolled changes to the project’s scope, a significant increase from the 43% reported five years ago.
The report also found that project complexity affects scope creep as well, and the percentage of projects with high complexity is on the rise—from 35% in 2013 to 41% in 2018.
What Are the Potential Harms of Scope Creep?
Because scope creep is unauthorized, this additional work is requested without the normal research and planning processes that accompany a change in a project’s direction. If the budget or allocated time stays constant, this gives the project team less time and fewer resources to complete the deliverables agreed to in the original SoW. If severe enough, scope creep will resolve itself in one of two ways:
The project wraps up within budget and on deadline, but the originally approved features, products, or services are not delivered due to the additional demands of scope-creep-generated work.
The project is eventually completed, but with significant time and/or cost overruns.
In either case, the client generally isn’t happy, and the project team can feel strained and overworked. If the scope creep is so large as to impede major deliverables, cause a massive budget increase, or force the project team to miss a critical deadline, it may undermine the entire expected value of the project.
Note that while extreme scope creep can be disastrous, a small amount of scope creep is not always bad. Assuming the project team is external, the extra work created by scope creep can justify a request for an increase in budget, thus increasing project revenues. Additionally, a project team taking on additional work can lead to increased client satisfaction and project team reputation, as long as the additional work doesn’t interfere with delivering on the original scope!
How to Prevent & Manage Scope Creep
How Does Scope Creep Happen?
In almost all cases, the root cause of scope creep can be traced back to inefficient communication between project stakeholders. This can happen in any number of ways. Maybe executives don’t want to oversee every single decision, and therefore grant the project team increased autonomy. A project team lead may decide on a small change to the project’s scope and, thinking it too small to matter, opt not to flag this to executive stakeholders. Fast forward a few weeks and the project has spun in a new direction entirely as a result of that “small change,” and the project deadline is weeks away!
That’s just one example of how scope creep can derail a project. Below, we’ll dig into the various ways that failures of communication can lead to scope creep, as well as provide possible solutions to managing scope creep effectively.
Project Communication: Statement of Work as "True North"
Ensure Alignment on the Statement of Work
It pays to ensure all stakeholders are aligned on key details of the project scope including project milestones, deadlines, and budget expectations before the start of work on any given project. As noted above, the project manager should have this in writing form via the SoW. Once the project scope has been clearly defined and agreed upon, the project team lead should host a kick-off meeting with all team members to align on expectations and key dates. When the full team starts working and things inevitably begin to veer off course, the project lead can use the SoW as a true north to orient the team’s efforts.
Update All Stakeholders on Changes to the Statement of Work
In a scenario where your team is reporting to someone who wasn’t involved in authorizing the original SoW (for example, you signed the SoW with a member of the executive team but your project team then reports to a product manager), you should sit down with your manager to make sure you’re fully aligned on key milestones and deliverables. If the project scope should change, make sure to update both your direct manager and the original SoW signatories—don’t take for granted that the client has clear and regular internal communication about the status of your project. We’ll cover the process for changes to the SoW in the section on change control process beneath “Client Communication.”
Team Communication: Check-Ins, Workflows, and Prioritization
Hold Regular Check-Ins to Track Progress and Identify Blockers
As a general rule of thumb, the longer the project, the greater the opportunity for scope creep to occur. With this in mind, project team leads should schedule regular check-ins with team members to create visibility into progress and help expose any blockers. During these check-ins, encourage team members to raise issues proactively by making it clear that honest communication on challenges is far more important than perceived progress.
Use Workflow Strategies to Enhance Transparency
On top of regular team meetings, team leads should set up workflows in such a way that potential setbacks can be spotted and managed early on in the project’s life cycle. This will help managers identify potential setbacks that team members might not even know exist. This could include extensive planning prior to beginning the bulk of work (for example, encouraging designers to use wireframe mapping to make sure everyone is aligned on the big picture of a website redesign), or asking team members to use field-tested forecasting strategies to provide a sense of when work will be shipped (for example, asking a team member conducting quality assurance to estimate the time needed for QA as a percentage of development time).
Ruthlessly and Regularly Prioritize
While these steps can help mitigate some scope creep risk, team leads should accept that some scope creep is inevitable and plan accordingly by always working on the highest-priority features of a given project. When the client comes back to you with a request for an additional feature or an extra analysis, you’ll be able to sleep much better knowing the most important work has already been done. This process of prioritization should take place at regular intervals throughout the duration of a project, and should always be based on the project objectives detailed in the SoW.
Client Communication: Change Control Process & Manage
Ensure a Clear Change Control Process
During any engagement, the project team will face decisions over how to allocate time and budget as new problems arise and new solutions present themselves. Small changes to a project plan can usually be made independently by a team lead, but more significant changes, especially those that will impact budget or deadline, need to be handled differently. The answer at these junctures is not to stick rigidly to the project scope and ignore possible new directions (known as “scope kill”), but to quickly evaluate whether or not these changes to the original project scope are worthwhile (note that this is a hard-learned skill in and of itself, and one that helps separate the best project managers from the pack).
If these changes are deemed necessary, the project team lead should follow an established change control process. This may involve constructing a thorough requirements analysis and cost-benefit analysis and presenting this to project stakeholders for approval or rejection. If this change then leads to a significant budget increase or delay, it won’t be coming as a surprise to anyone involved. Finally, you may find out that the client doesn’t even want to pay for an additional feature that you thought was absolutely necessary.
Don’t Let Communication Become Too Much of a Good Thing
While maintaining communication with the client is important, permitting nonstop, unstructured feedback from the client to project team participants can be a recipe for disaster. Occasionally clients ask their contracted team to get some extra work done, not realizing that this will prevent the project team from achieving its original, more critical goals. In these cases, the project team lead could either provide an estimate for the extra work (in other words, make it clear this additional work is not included within the original project scope) or offer to construct a cost-benefit analysis of that ask as it relates to the original project.
Scope creep is an inevitable aspect of project management, although you can minimize the damage done to expected project value with the help of the strategies above. The key to mitigating scope creep is to remember that scope creep happens as the result of unauthorized changes to a project scope, which can almost always be traced back to failures of communication. By keeping clear and constant communication between all project stakeholders, the worst effects of scope creep can be avoided.