Once in a blog planning session together, our CEO asked, “Can you define scope creep?” My immediate answer was, “Scope Creep is the devil and you should use every religious and secular remedy you can think of to banish it back to [redacted]!”
After years of watching scope creep in project management wear down entire teams and single-handedly ruin projects, I still have a knee jerk reaction to the hellish idea. I would not be surprised if the way to the underworld is actually paved with last minute “Must Have” feature requests!
But my visceral negative response to the idea of scope creep doesn’t have to be universal. In fact, once I learned how to manage scope creep successfully, I understood it can actually be a positive opportunity for all involved. Yes, really!
I’m going to talk about the basics of recognizing and managing scope creep so that you, too, can handle scope creep as “the devil you know” with confidence. In this article, I’ll cover:
What is scope creep?
Scope creep has many names. It is also referred to a feature creep, requirement creep, kitchen sink syndrome, and of course, “the devil.” The Project Management Institute defines scope creep as “adding features and functionality (project scope) without addressing the effects on time, costs, and resources, or without customer approval.”
Implicit in the definition is that in order to have scope creep, a project has to have a scope (“features and functionality”) to begin with. There are any number of great ways to understand project and feature scope, but for simplicity, let’s use the classic Project Management Triangle of Expectations:
This is also commonly referred to as the “pick two” model. We talked about it in more detail in our Project Manager Roles, Responsibilities, and Expectations article.
Basically, any project can be fast, good, or cheap: Pick two!
When you have agreed with a client about the Quality, Money, and Time parameters for producing a specific set of features, you have a “scope.” Scope creep happens when a change occurs in any of those areas, or someone attempts to cheat and “pick three” at some point during production.
In services, there are other flavors of scope creep.
Scope creep in Agile
Novice practitioners of Agile development sometimes claim that scope creep doesn’t happen in Agile. It most certainly does! While Agile accommodates changes mid-project, those changes have to be carefully managed. In Agile, scope creep usually happens when the product owner refuses to prioritize the user stories against a cohesive vision, creating bloat every two weeks. The scrum master is often complicit in such shenanigans.
Scope creep in project management
The majority of this article assumes that the type of scope creep we are referring to is happening in a service environment and therefore involves project management to some degree. That said, scope creep within project management can be loosely defined as: The result of a project manager who tasks a team with requests outside of the scope, regardless of the source of those tasks. In other words, a project manager who refuses to say No is the one causing the most scope creep.
What – and who – causes scope creep
The number one cause of scope creep is a poorly defined scope, which means that, ironically, the “devil” is actually in the lack of details when it comes to scope creep.
Here’s where people get hung up and why scope creep happens: Developing a proper scope of work (SoW) takes real effort and can be quite time intensive.
Creating a good scope of work is both a science and an art.
Developing a clear, strong scope of work always requires excellent communication skills and negotiation skills. There are a lot of industries where writing a good SoW requires experience and/or technical knowledge. And, not everyone is capable or willing to spend the effort and expertise on building the foundational document of a project.
For all these reasons and more, the process of getting all the stakeholders to agree on what the work will be and how it will be completed within a specific time and budget – i.e., the project’s scope – often gets clipped.
How to write a good scope of work
This article isn’t a guide to writing a good scope, but I want to share one of the most useful articles on the subject I’ve read.
Joe Di Stefano’s “The Problem, the Ballon, and the Four Bedroom House” condenses a good scope down to one central question: What problem are you solving?
Once you know the problem you are solving, then you can define the solution in terms of features and outcomes. Every new request not in the scope can be tested as either part of the solution or not.
When scope creep happens, Joe recommends that the response should be to tell the truth. Your problem-definition and scope of work document should help you do this. The approach and details will differ between industries, but your scope of work documentation should accomplish these three goals:
- Define the problem
- Define the solution
- Tell the truth at all times during the project
How clients cause scope creep
There are a lot of ways clients can cause scope creep and detailing them all isn’t very useful, at least for our purposes. Instead, let’s shift the question to “when do clients cause scope creep?”
Regardless of how, scope creep usually happens when you’re reviewing critical deliverables and/or hitting major milestones on a project.
This is usually the place where there is enough completed for the client to have a real taste of the work, but it isn’t finished and therefore not representative of the final product. The client’s real yet incomplete experience can inspire new ideas, create miscommunication, or instill doubt in the progress. Each of these responses must be dealt with and addressed as they come up, while resisting scope creep at every turn.
Bottom line: if you ask for feedback, you are going to get it! Be prepared and go into any presentation of your work with a strategy to combat the subsequent invitation toward scope creep.
Regardless of industry, I recommend “Design is a Job” by Mike Monteiro as a starting point for improving how you manage your clients when you present work.
How stakeholders cause scope creep
Let’s agree that a stakeholder is someone who has sway on a project but isn’t the person who hired you for the job. This can be a CEO, investor, department head, someone from an advisory board, or, god help you, the founder’s teenage nephew (this once happened to me in real life).
The stakeholders can cause scope creep in the same ways that customers do, but they often have their own unique issue: they want to solve a different problem. Their pet problem can be related to the problem you were hired to solve, but it is indeed a different problem and therefore out of scope.
A classic example of this is the “University website.” The marketing department hired you to build the website according to specific parameters, but every single department head can have a different set of problems that needs solving. They’re included as stakeholders to the project, but can’t (or shouldn’t) be able to change the scope mid-project with their special requests. It can become a tangled mess of expectations really fast.
The larger the organization, the more you should insist on agreeing to who has say in the project and who doesn’t, so you can adjust the project schedule and budget accordingly.
How your team causes scope creep
Your team is the best! And the best people want to always do their best work. But, unfortunately, your clients won’t always have the best budget. And sometimes the “best” work doesn’t produce value to the client or at a value that justifies the cost.
It’s not uncommon for at least a few people on the team to sneak in additional effort to meet their own personal standards. They may not try to charge the client for their perfectionism, but it still takes time and therefore incurs a cost. Is this bad? Not necessarily. But it is technically scope creep because they are adding unauthorized work to the project.
This is where it can be very helpful to have a team discussion to clarify any additional work that directly solves the defined problem. There are cases where the additional work will save time and budget in the future; the client may not find it valuable immediately, but the value could be substantial over time.
For example, taking the time to refactor a section of the code so it is more performant, leaner, and well-documented may not add any immediate value to the project, but over the next six months those extra hours of effort could save the client a lot. The cost of refactoring now versus 6 months in the future is typically substantially cheaper.
Is it the right call? The answer will be found by following the Joe Di Stefano’s advice to “tell the truth.” This means your team needs to tell you, the project manager, why they want to do it; you need to invest the time to understand the work’s potential value; and then truthfully communicate the scope changes to the client.
Of course, there are times when your talented, well-intentioned team just needs to pass the salt.
You can keep your team from contributing to scope creep by getting into the habit of having this type of openness, so these issues will surface before the work is done.
How to manage scope creep
The only way to manage a thing is to know what it is and have a plan for handling it. That’s what a scope of work does: it defines the project, thereby defining what isn’t the project – so you can recognize and deal with scope creep when it arises. This cannot be emphasized enough:
The most important thing you can do to handle scope creep is to invest the effort to produce a good scope of work.
Depending on your field of expertise, this can mean many things, but let’s be clear about what it’s not: A great scope of work is not making every little decision a line item with an estimate. We can’t fool ourselves into believing we can solve the problem before the work is started.
A scope of work defines the problem and presents a framework for discovering and building a solution that includes a schedule and budget. It should help you tell the truth and measure any additional work by its value in solving the scoped problem.
Scope creep is unavoidable
In my opinion, scope creep is unavoidable. It will happen in probably 99.9% of projects because often, a problem’s best solution emerges during the work. We should not be surprised that a talented team of professionals will improve and innovate on proposed solutions as they do the work. In fact, I would go so far as saying that if the team doesn’t improve the proposed solution that something is wrong in the process or the team composition.
Smart people love solving problems elegantly. This is going to cause scope creep every single time.
The good news is that this means that scope creep is knowable (and you know what they say about “the devil you know”). Instead of creating a project plan that pretends it could never happen to you, it’s far better to know that scope creep is inevitable. That way you can plan for it, budget for it, and not be hijacked by it.
Jessica Hall, Senior Director, Product Strategy & Design at 3Pillar Global, gives a short talk with the controversial title, There Is No Such Thing as Scope Creep. In this video, she offers a ton of great info on how to turn scope creep into opportunity for improvement in process, communication, and culture.
With a solid scope of work document, you can create a scope creep metric, turn it into a KPI, and use that to create a “flex” budget and space in the schedule to allow for some creep to take place.
As a starting point, I recommend setting aside 10% of the budget as “flex” that will account for healthy scope creep, until you establish your data for how you operate. For more information on setting up KPIs and KPI targets, read our Guide to KPIs & KPI Dashboards for Professional Services Companies.
When you accept the inevitability of scope creep, you and your team will be able to discern when scope creep is good and adds value to a project.
You’ll develop a practice where you can kindly and effectively say No to distractions and enthusiastically say Yes to innovations.
Your client will love you for telling you the truth in a way that sets them at ease and helps them trust that you can deliver the best results. And, since you planned for it, there will be some budget and schedule to empower legitimate innovation that first emerged as what a less-wise project manager may have discarded as “scope creep.”
Summary
Scope creep is the much-feared bedevilment of many a project deadline and budget. But while it happens in almost every project, scope creep doesn’t have to be its ticket to hell.
When you create a strong scope of work that defines reasonable timeline and budget parameters and are willing to say No to clients or stakeholders when necessary, you can differentiate between distractions and innovations.
Healthy scope creep is often where the magic happens – where bigger problems get solved and new ideas are born. It’s up to good project managers to create the conditions that nurture the good kind of feature creep while banishing the “devil” back to hell.
I’d be remiss to not point out that using VOGSY to automate your business can help you manage scope creep. With its real-time information dashboard, VOGSY can help you forecast how new requests might impact your schedule and budget. You can track your KPI targets, observe budget usage, view the timeline and goals, and much more. With its total transparency, VOGSY helps you tell the truth during the project so that everyone involved can make a good decision. This kind of truth-telling is the cornerstone to long, successful client relationships.
