Stack of documents
Scope creep is easy enough to define, relatively simple to identify, but often exceedingly difficult for project managers to control.

In simple terms, scope creep involves expanding a project’s scope — with additional requirements or features — after the project is under way and without adjusting the project’s timeline, budget or available resources.

In other words, if your stakeholders, whether internal or external, add requirements to your project after you have collected requirements and received signoff on the project’s scope statement, and you don’t adjust the project’s time, cost or resources accordingly, you have just facilitated scope creep.

This happens very frequently in projects. The customer just wants to add this one little thing. A developer just wants to improve that feature a bit by adding something that wasn’t defined in the project requirements.

And as the project manager, it’s easy to get stuck in the middle between a request for just one little bitty addition and the project documents you created to establish and confirm your timeline, budget and resources.

But it’s essential you handle new requests properly, lest scope creep set up your project for failure. Here are some tips:

1. Collect and Confirm Requirements

A major culprit of allowing scope creep into projects is incomplete or vague requirements. Collecting requirements is a crucial step in the project life cycle that can really make or break your team’s ability to deliver a successful project on time and within budget.

So make sure you are diligent about this task, check and double-check, confirm and receive signoff from all relevant stakeholders and make sure you are transparent about the requirements you have collected and will be using to define your project’s scope. This will give you an accurate and approved document to reference down the road as needed.

2. Establish a Change Control Process

Scope creep can’t always be avoided. Uncontrolled scope creep can.

So go into your projects knowing that somewhere along the lines, someone is likely to request a new feature, an additional requirement, a little teeny tiny tweak that will add days, weeks or months of work for you and your project team, and know that saying NO! is not always possible or sensible.

Avoiding scope creep is ideal, but sometimes it can’t be avoided. So use your project management methods to control and manage scope creep, starting with establishing a change control process when you create your initial project documents. Make sure all relevant stakeholders sign off on this process, and then manage it throughout your project so that any change requests that come along are handled according to the process you established.

Make sure your change control document identifies how change requests will be submitted and reviewed, who will sign off on them, and what the process will be for adjusting timeline, cost or resources as scope increases.

3. Say No by Saying Yes

Another good method for managing scope and controlling scope creep is to say no by saying yes.

After change requests are submitted via your defined change control process, they will need to be reviewed for viability and to determine whether they might require an adjustment to the project timeline, budget or resources.

As project manager, it is your responsibility to determine how the changes will affect your project and communicate that to the relevant stakeholders. You might see a request come through and know right off the bat that it’s going to blow your budget out of the water, but use your documentation and data to say no for you. That might look something like “Yes, we can add that change into the project; it will just require X more money in the budget and another developer to accomplish within the agreed-upon timeframe. Or we can keep the budget as-is but add X more weeks to the project. Which would you prefer?”

In this scenario, you have avoided simply telling the stakeholder no and have presented a couple of very reasonable options for going forward. If all key stakeholders agree the change is worth increasing cost or timeline, go for it — capture the new requirements, adjust the scope, timeline, cost and resources as needed and continue in your role as Resident Problem Solver.

If, however, increasing budget and/or deadline is not an option — which we’ve found it often is not — then you have allowed the stakeholder to say no to the change and you can capture the request and determine whether to introduce it as part of a new project when your current one is complete.

4. Avoid Gold-Plating

We’ve dug into gold-plating in another article in more detail, but in short, gold-plating refers to adding in something the client has not requested or approved.

We run into this frequently in website and software development, as developers or designers tend to think “I’ll make this even better than they requested by adding XYZ!”

The intention behind gold-plating is generally good, but the result of gold-plating without observing the change control process and receiving approval can be detrimental to your project’s success, as adding unrequested features can lead to cost or time overruns, rework and introduction of bugs or other issues that could take time and budget to resolve.

Make sure your team is well aware of the dangers of gold-plating and that any adjustments to their task requirements need to be approved via the change control process. One way to explain this to a well-meaning team member is that the client might have a very specific reason for wanting this part of the product exactly as it has been scoped, and any changes to that could create issues for them and for the project. We always encourage developers to share ideas for improving task requests, whether they think the idea might be put into action or not; the goal of avoiding gold-plating is not to limit creativity and critical thinking, but rather to ensure your project delivers as scoped within the time and budget constraints.

Additional Reading: