The problem

It is often said that the scariest word you can hear from a stakeholder is ‘just’…

• Can you just add an extra widget here…
• Would it be possible to just move it a bit to the left…
• Just make it happen…

More often than not, this gives rise to a phenomenon in project management called scope creep. 

Despite the huge amount of attention given to it in the project management literature, we’ll deal with it pretty succinctly here – the trick is not to panic!

Also called requirements creep or feature creep, scope creep refers to uncontrolled changes or continuous growth in a project’s scope, usually after the plan has been approved and the project is in delivery – it is generally considered harmful.

This is because scope creep is a zero-sum game.

Clients benefit from scope creep (by getting more than what they originally commissioned); however, this is achieved at the expense of the project team, who need to find the time and resources to meet the changed requirements.

For that reason, it is the bane of managing projects and is routinely blamed for excessive costs, delays, failed projects, and a lot of additional work.

Typical (and related) sources of scope creep include:

• Poorly or vaguely defined requirements
• Lack of sponsorship and stakeholder involvement (including late stakeholder identification)
• Overstatement of project benefits (often made in order to secure the work)
• Underestimation of project complexity
• Indecisive or conflicting project stakeholders (which may result in unnecessary accommodation or compromise)
• Poor risk identification
• Disingenuous clients trying to get ‘something for nothing’
• Allowing direct (unmanaged) contact between the client and project team 
• An unrealistic desire to deliver a ‘perfect’ product, service or result

---

The solution

Remember the triple constraints?

If budget, resources, and schedule are increased along with the scope, the change is usually considered an acceptable addition to the project, and the term scope creep is not used.

Herein lies the solution to our dilemma.

Having made it this far through the course, you know the importance of stakeholder-inclusive project planning and communication. 

By getting a commitment from all stakeholders that the business case and project plan acceptably define the work to be performed, you should largely avoid scope creep issues.

This should also include explicitly stating what is out-of-scope for the project; that is, work that (it is agreed) will not be performed.

Yet, we have also emphasized the importance of being open to and embracing new ideas on the path to innovation. 

Given that it is impossible to plan for every uncertainty and opportunity, shouldn’t we actually be inviting people to creep on our scope!?

After all, stakeholders trying to creep scope are invariably looking to add value to the project – they are trying to realize an opportunity.

So what is the solution?

Just… Say… YES!

---

How it works

It really is that simple.

As part of your delivery process, you should proactively identify and intercept the potential for scope creep as it occurs. 

And because you have a stakeholder-agreed plan guiding your project’s performance, you should have the tools at your disposal to reliably estimate the costs (if not benefits) of the proposed change to scope.

For the project manager, then, saying ‘yes’ does not mean, ‘Yes, I will do it.’

Saying yes instead becomes, ‘Yes, I can do it, and this is how it will impact schedule and cost.’

All that is required then is identifying the appropriate authority to approve or deny the change request. 

If that isn’t you as the project manager – and quite often it isn’t – the sponsor/steering committee / CCB can either agree to absorb the costs internally or pass them on to the client via a variation.

In other words, scope creep – when it occurs – should be formally managed through our process of change control.