Even if you’ve never heard that phrase before, you know exactly what scope creep is. You’ve almost certainly experienced it at some point in your professional life – and probably even in your personal life, too.
Essentially, scope creep refers to instances in which changes to a project’s plan are made after the project is already underway.
Generally speaking, scope creep is almost always detrimental for all involved parties (i.e., the team assigned to a given project and the party that commissioned the project).
On the developer’s or creator’s end, a change in plans typically results in the (unanticipated) usage of additional time and resources. Not only does this equate to more money being spent upfront to complete a project, but it also holds the team up from moving on to future projects – resulting in the loss of potential revenues.
Also, because changes to the project were made “on the fly,” there’s a good chance the end product won’t be nearly as polished as it could have been had the team been better prepared.
On the client’s side of things, scope creep means they’ll likely have to wait longer for the project to be completed – and may also need to sink more money into the project, as well. If the product in question is to be used for business purposes on the client’s end, the longer wait and higher cost could end up eating into their overall profit margin.
Needless to say, scope creep can cause those on both sides of the equation major stress and frustration – neither of which, of course, is good for business.
Unfortunately, scope creep is all too real – and all too prevalent. According to data collected by Project Management Works in 2015:
- Only 39% of projects are completed as originally planned (in terms of time, budget, and agreed-upon features)
- 70% of companies reported at least one completely failed project in the previous year
- For every $1 billion invested in completing projects, companies lose $109 million due in large part to scope creep
Clearly, scope creep is an entity to be avoided as much as possible.
In this article, we’ll explain some of the reasons scope occurs in the first place – then dive into what you can do to prevent it from plaguing your next project. We’ll also provide some advice for those who are facing scope creep in a current project and are in need of some major damage control.
First, though, let’s clarify two common misconceptions regarding scope creep.
Scope Creep vs. Feature Creep
Oftentimes, the term “feature creep” is used as a synonym for “scope creep.”
(Source / Caption: The moment I started relating to Dilbert was the moment I realized I was old.)
While both terms are related, they don’t necessarily refer to the same thing. While scope creep refers to any instance of change or addition to a project, feature creep refers specifically to the addition of features to a product that go beyond those that were planned for at the onset of development.
To put it another way, scope creep refers to changes made to a project while said project is being completed, while feature creep refers to changes made to a product once the baseline features have been added to it.
Technically, scope creep can be caused by feature creep (e.g., a project goes over budget because the development team added extra, unplanned-for features to the final product). However, there are a number of other causes of scope creep – which we’ll get to in a bit.
Next, we’ll ponder what may seem like a rather odd question: Can scope creep be a good thing?
Can Scope Creep Ever Be Beneficial?
If you’ve been hanging onto every word of this article, you’re probably thinking the answer to this question is a resounding “NO!”
For the most part, you’re not wrong. As the stats we referred to earlier show, scope creep typically leads to a ton of wasted time, energy, and – especially – money.
That being said, there is an ever-so-slight chance that scope creep actually can benefit both parties involved in the completion of a project.
For one thing, the changes made to a project may result in the creation of a much more valuable finished product. Given the choice between receiving a sub-par final product according to an original plan and receiving a superb final product according to an amended plan, it stands to reason most end-users would choose the latter.
On the developer’s side, though scope creep will almost certainly cost the organization up front, it may lead to major breakthroughs (and potential gains) down the road.
For example, those familiar with The Elder Scrolls video game series might be surprised to discover that the original concept for the series barely resembled the highly-successful role-playing games we know and love.
Long story short, Bethesda’s head developers realized a relatively minor aspect of the original game was actually more entertaining than the rest of the game, so they scrapped the entire project and started over (missing deadlines and spending much more than originally anticipated in the process).
Fortunately, the gamble paid off; The Elder Scrolls is now considered one of the most popular video game series’ of all time.
On the other side of things, we have the Duke Nukem video game series. For those who don’t know the unfortunate story of Duke Nukem, just take a look at this screenshot from Wikipedia:
Again to make a long story short, the “saga” of Duke Nukem basically goes like this:
- The original game was a surprise hit, spawning two sequels that were even more successful
- Under pressure to produce an even more successful follow-up to Duke Nukem 3D, the game’s developers pushed back its release date time and time again
- By the time Duke Nukem Forever was released fifteen years later, interest in the game had completely waned
- To add insult to injury, the final game in the series simply wasn’t up to standard by any means whatsoever, and was panned by game critics and consumers alike
The reason we went so deep into these examples is to illustrate this point:
While major changes to a project’s scope can potentially result in huge breakthroughs and major success (for your client and your company), such changes will more often than not lead to disaster. In other words, unless you’re absolutely certain that changes to your original plan will result in big things, it’s ultimately best just to stay the course.
Why Does Scope Creep Happen?
Before we dig into some of the most efficient ways of avoiding scope creep, we need to have a full understanding of why it occurs in the first place.
While creating a finite list of “reasons scope creep occurs” is rather impossible (since, realistically speaking, there’s an infinite amount of ways a given project can go off the rails), we’ve narrowed the list down to the most common ways in which scope creep rears it’s ugly head.
Let’s look at each in a bit more detail.
Lack of Agreement and/or Clarity Between Developer and Client
If the people working on a project and the party commissioning said project aren’t seeing eye-to-eye with regard to what the project entails, and what the final product will look like, there’s little chance of the process going off without a hitch.
Sometimes, this lack of clarity is due to the fact that the client either can’t articulate exactly what they want – or doesn’t truly know what they actually want in the first place. In such a case, the developer will simply have to do their best to figure out what their client wants – and hope that the client is satisfied with the finished product.
Still, other times the fault may lie in the developer’s inability to understand the client’s instruction – or their inability to follow through with such direction. Of course, it goes without saying that if the client is unhappy with the developer’s finished product, all involved parties stand to lose out.
Ignoring the End-User
Here’s a question we haven’t really addressed up until now:
Who is going to be using the final product being developed?
Whether it be the client commissioning the project, or said client’s customers, that person’s input is essential to the successful completion of the project in question.
Unfortunately, developers and their clients will often wait until a project is underway to begin soliciting input from the people who will actually be using the product being created. Of course, if this input clashes with that which has already been developed, the development team will essentially have to go back to the drawing board.
As if that isn’t bad enough, there are many cases in which the client and/or developer places no importance whatsoever on user feedback. While this won’t technically contribute to scope creep (i.e., the project technically is completed according to the original plan), the end-product stands little chance of being received well by its intended audience. As alluded to earlier, given the choice between scope creep and all-out failure, scope creep is definitely the better option.
Sometimes, developers will add extra features to a commissioned product in an effort to really “wow” their clients.
While this might seem like a good idea in theory, gold plating can cause a number of problems when actually put into practice.
For one thing, when a developer adds more features than originally agreed upon, they’re essentially doing more work for less money. Though, as mentioned, the intention of adding more than expected is to impress the client, the reality is that putting in this extra effort simply isn’t a smart business move; even if the client is impressed with the addition, they’re under no obligation to pay more for the extra features. Additionally, the client may come to expect such extras to be added in the future – even if they don’t offer more money for the additions.
Another downside to gold plating is that it’s a slippery slope that leads to massive feature creep (leading, of course, to uncontrollable scope creep). The addition of a single extra feature can easily open the door to another potential feature to be added, in turn leading to even more possible additions, and so on. Since the developer will have already gone past the original scope of the project, they’ll have no clear stopping point in front of them, and may keep adding features ad nauseam.
Finally, the client may simply not want any additional features to be added to the final product. This being the case, not only would the developer be wasting their time and resources making such additions in the first place, but they might also turn off their client in terms of future endeavors (which, of course, is the exact opposite of what they had intended).
Underestimating the True Scope of a Project
Okay…technically, this is less of a cause-and-effect thing, and more of a one-in-the-same thing. Of course if a developer underestimates the scope of a project, they’re going to experience scope creep; that’s what scope creep is.
Still, it’s worth mentioning that even veteran project managers and developers are prone to underestimating the amount of time, money, and energy will need to go into a given project. In fact, those who have been “in the game” for longer may unintentionally fall into the trap of thinking they’ll be able to complete a specific project with less, since they may have done so successfully in the past.
The problem with such thinking, though, is that development doesn’t happen in a vacuum. While a team may have completed a similar project before, that doesn’t necessarily mean this next one will go so smoothly. And it definitely doesn’t mean they’ll be able to complete the project faster, or with fewer resources, than they previously had.
Not only can underestimating a project’s scope leave a development team without the resources needed to complete the project in question, but it can also cause the team’s morale to drop – which, in turn, will also cause the project as a whole to suffer.
Failure to Anticipate Scope Creep
Going along with the previous section, it’s essential that project managers and developers recognize that, no matter how well planned-out a project is, scope creep is bound to happen to some degree.
As we alluded to above, even the slightest hint of scope creep can be detrimental to a development team’s psyche – especially if they’re not prepared to face it head on. This turns scope creep into a self-fulfilling prophecy, in which even the prospect of missing a deadline or going over budget can completely derail the project at hand.
In other words, the more your team allows scope creep to affect them, the worse it can potentially become. For this reason, it’s important to know how to minimize the chances of it occurring in the first place – and how to head it off before it turns into an insurmountable obstacle.
Preventing and Mitigating Scope Creep
Okay, so I know we just said that truly preventing scope creep is all but impossible.
But, now that we understand just how detrimental scope creep can be, it’s definitely worth doing everything in our power to stop it from affecting your team, right?
Preventing Scope Creep
Here, we’ll address some of the issues we discussed above, and provide some advice regarding how to avoid these problems altogether.
We’ll start with setting clearly-defined goals for your project.
Setting SMART Goals
You may be familiar with the concept of SMART goals, but for the sake of clarity, let’s go through what this entails.
- Specific: Your plan should address what you want to accomplish, why you want to accomplish it, who is involved in the process, and which resources are necessary for successful completion of it.
- Measurable: Your goals for a given project need to be tangible, so as to know for sure that you’ve accomplished what you’ve set out to accomplish.
- Achievable: The measure of success needs to be realistic, taking into consideration the specific information mentioned above.
- Relevant: Essentially, you need to be confident that your efforts will undoubtedly lead you to accomplish your goal.
- Timely: You need to be sure that you’ve given yourself enough time to complete the project at hand.
Setting SMART goals not only allows you to envision a clear path for a given project’s development, but it also enables you to evaluate the validity of each step you take while completing said project. This, in turn, will allow you to stay on track, and to avoid putting effort into extraneous tasks that may cause scope creep to occur.
Assume the Role of Expert
As we said earlier, sometimes clients can be rather unsure of what they’re actually looking for in terms of a final product. Or, they may think they know what they want, but their vision might be a bit off-base.
This is to be expected; if they knew what they wanted, and they knew how to make it happen, they wouldn’t have hired a development team in the first place.
Still, the client may be rather adamant as far as dictating how they want their development team to proceed. As a project manager or team leader, it’s your duty to guide the client toward realistic expectations, and to show them why certain tasks must be gone about a specific way.
Think of it like this: your client didn’t hire you just to complete a project; they hired you to complete a project that would be of value to them. It’s your duty, then, to not allow anything – even the person who hired you – to stop you from completing your assigned task.
Ensure Your Client Understands All Your Project Entails
Along with this last point, you also want to be completely transparent with your client with regard to the logistics of the project.
Now, this isn’t to say you should explain every last detail of the project to your client; for the most part, all they care about is the final product.
The point, here, is to explain to your client that you have a process in place, and that any deviation from this plan will lead to delays in completion of the project.
You might also choose to explain to your client the rationale behind your pricing, as well. This, again, is strictly so that they understand that a deviation from the plan may result in a higher cost.
Essentially, you simply want to ensure that both your development team and your client are on the same page before you move forward with the task at hand.
Your best course of action is to get all of this in writing in the form of a legal document. That way, there will almost certainly be no surprises for either party as the project comes to a close.
Dissuade the Client From Adding On
Of course, even if you make things crystal clear, and you’re certain your client knows what to expect from a given project, they may still try to tack on “a little extra” right while you’re in the thick of things.
As we mentioned above, if you’ve gotten everything in writing, you can easily fall back on the initial agreement and simply explain that you won’t be adding to the project. However, this may cause a rift between you and your client – and will likely be the last time you do business together.
With this in mind, it may be prudent to include a clause within your contract specifying the process of making changes to the scope of the project. This clause should include added resources to be used, time allowed for completion of the addition, and the additional cost of making such changes.
In this way, you make it clear that you’re more than happy to make changes to the project as your client sees fit – but you certainly won’t be doing so for free. By going about it this way, you can hopefully dissuade your client from interfering in the middle of the process.
Managing and Mitigating Scope Creep
As we’ve warned throughout this article, scope creep is sometimes unavoidable.
That being said, there are a few things you can do once you notice scope creep beginning to rear its ugly head in order to minimize the amount of damage it ends up causing.
Have a Protocol in Place
As we spoke about in the section above, you should have a clear policy written into your contractual agreement regarding changes and additions to the project at hand.
Not only should you have such documentation in place, but you also need to be sure to follow said regulations as you complete the project.
In other words: don’t compromise, no matter how simple a change might seem. The reason it’s called “scope creep” is because it creeps up on you; if you’re not careful, what seems like a simple change or addition at first can become an entirely new project unto itself.
We covered this above, so I’ll be brief:
If you do agree to make changes, make sure to document them.
Not only will this enable you to rationalize extra fees or deadline extensions to be made, but it can also benefit your team in terms of planning future projects.
That is, the next time you work with this same client (or work on a similar project with a different client), you’ll have a decent idea of where you might end up needing to make changes once the project is underway. This way, you can anticipate potential scope creep ahead of time, and make the proper adjustments in your operations.
Just Say “No”
As we said earlier, sometimes it’s best to not include a “scope creep clause,” and simply reject your client’s wishes to make changes to a project.
Typically, this is best when the project in question is rather straightforward, and is something your team has a lot of experience in.
Like we said before: you’re the expert. You know what will work, what won’t work, and what will be superfluous. If your client is adamant about making certain changes – but isn’t willing to budge with regard to extra payment – perhaps you’d be better off leaving them behind, anyway.
If you never want to hear the phrase “scope creep” again, I don’t blame you. But, in order to understand how to deal with it, it’s essential that you understand why it happens – and what can happen if it snowballs out of control.
Keep this in mind as you begin your next project – whether it be for a client, or for your own company. Stay vigilant in your pursuits; don’t let scope creep sink you.