Skip to content

What is scope creep and how can we mitigate it?

Added to your CPD log

View or edit this activity in your CPD log.

Go to My CPD
Only APM members have access to CPD features Become a member Already added to CPD log

View or edit this activity in your CPD log.

Go to My CPD
Added to your Saved Content Go to my Saved Content
Shutterstock 543880450

The term ‘scope creep’ may sound like another innocuous piece of professional jargon, but it has the potential to become the bane of any project professional’s life.

The APM glossary defines it as “the term sometimes given to the continual extension of the scope of some projects”. There are many further definitions: adding additional features, requirements or unauthorised work; adding deliverables after commencement of a project; continuous uncontrolled growth in scope; and when a client adds requirements or deliverables beyond the agreed scope, without review or control.

Causes of scope creep are as varied as definitions, but can be summed up as changes by clients and other stakeholders, miscommunication and a lack of systems and tools to handle change when it occurs.

It is generally agreed that scope creep is problematic, inevitable to some degree and disruptive. Paul Kidston, former Director of Project Controls at Costain and lead author of APM’s 2015 book Planning, Scheduling, Monitoring and Control, likens it to the children’s game of grandmother’s footsteps.

“Scope can increase by a surprising amount, hence it has crept up on you. These little but constant changes add up to a large impact on a project,” not to be confused with major changes in external policy or benefits realisation. “The term implies lots of the small stuff.”

Small perhaps, but scope creep can lead to increased cost and delivery delays and general project disruption. “Small changes in themselves may seem easy to cope with, but if thousands of them combine to add, say, 20% additional work to the project, that cannot be delivered by the same people, in the same time, using the same infrastructure.”

And then there is the risk aspect, with the possibility that last-minute changes could cause serious accident. “This has happened for at least one international contractor.”

How best to deal with scope creep?

Scope creep may be inevitable, but only up to a point.

“To a certain extent it is inevitable in some projects, as projects have a lot of risk and uncertainty in them,” says Kidston, “for example, if the design cannot be completed until works have started. In construction, one may not be able to determine ground conditions until you actually start digging.”

But often scope is simply badly defined, he says: “Of course, there are some projects that cannot be well defined – but this must be reflected in the risk log and contingency allowances.”

Thus, dealing with scope creep comes down to tools. Key tools, according to Kidston, are scope definition, benefits management and change control (especially where change is necessary and must be accommodated, such as changes in legal requirements over the life of a project).

“Rigorously setting out the former two and returning to them and reviewing them through the life of the project [is key], and rigorously managing change to ensure changes are necessary and viable – that they do not water down the benefits.”

On a practical level, in construction, this could include ongoing surveys and reviews of designs and conditions. “When change happens, an additional allowance should be made for additional risk and additional overhead to cover the increase in both.” And, to deal with client caprice, contracts must take uncertainty into account. “Choosing the right one for the project is key.”

Focus on the benefits, with agility

Hugo Minney, APM Fellow and Co-Chair of its Benefits and Value Specific Interest Group, champions benefits management – and a laser focus on the benefits from start to finish – as a vital tool against scope creep.

“Scope creep pressure is always there, and it depends how you cope with it,” he says. “Benefits management can overcome complexity and scope creep. If a customer is clear about what they want to realise, it is easier to say whether the creep that may arise helps achieve it or not.”

Thus, a benefits management system in place from the start keeps focus on a project’s actual purpose, allowing emerging ideas to be properly assessed and ranked and adding transparency to a ranking system, allowing clear agreement throughout on what is to be achieved and how change is managed. “Scope is moving, but not growing.”

Minney also points out that, with agile, scope creep almost stops being an issue. “Agile sticks to a date but can cope with the dependencies changing.” It is a necessary reaction to the reality of scope creep in project management, especially in the sector in which agile’s origins lie: software, which is especially prone to scope creep.

“With software, you often don’t know what you need, and you need to have the scope to evolve, unlike, say, building a road or a bridge.” Thus, agile is the industry’s response to scope creep potential, with tools to deploy usefully in other sectors.

Keeping the focus

Whatever tools are used, the reality of client-driven project management is that scope creep will always be present. And since clients cannot simply be told they cannot have what they want, scope creep must be folded in and managed, says Minney.

“There is a difference between scope creep and improved understanding. The latter means you can reprioritise. What is the foundation for that? Proper benefits management.”

And ultimately, changes to scope can have positive aspects too.

“There is a choice between planning everything in advance, which means you never get started, and getting started, going with the flow and seeing how things develop. There is so much change out there – legislative, scientific, academic and more.”

But the key is to have the tools to manage the change – and have all parties know the difference between scope change and scope creep.

You may also be interested in:

4 comments

Join the conversation!

Log in to post a comment, or create an account if you don't have one already.

  1. Unknown User 28 October 2022, 04:42 PM

    Love this Conrad, thank you for posting. One thing I'd like to add is the value of strategic planning on this. Overall, love it!

  2. Unknown User 31 October 2022, 11:37 AM

    While I agree with much of the thrust of this blog, in my experience, spending quality time with the client rigorously defining baseline project requirements (not the same as scope or benefits) gives you a solid starting point to measure against and quantify scope creep. I have seen many cases where poorly researched requirements definition almost guarantees scope creep.

  3. Unknown User 31 October 2022, 11:48 AM

    Thanks Sunchana and Tim, excellent points. There is a lot to know and understand about scope creep - this a brief snapshot of a complex issue laden with risk for PMs, and there's many more angles to explore, which I hope to do with future pieces.

  4. Unknown User 31 October 2022, 12:30 PM

    In one sense, Tim Lyons is right, that if it's down in black and white then at least the provider can demand more money for changes. In another sense, that kind-of misses the point! Organisations make investment for a purpose, to achieve benefits. They frequently don't know exactly what they want, and equally frequently contract with a big name delivery organisation in order to get the experience to make the changes necessary to the works so that the works deliver the purpose and benefits. Therefore understanding why the client wanted this in the first place is important. It means that the experience and skills of the project manager and team are put to good use, prioritising the creep of scope to best help the client's success. This can be taken further - with shared purpose, contracts can include risk and reward sharing. A knowledgeable provider has the space to show off their advantages to the client during the tendering process, and to implement changes to what is delivered (ie creep the scope themselves) to both party's advantage because of their special knowledge. These apply whether it's an internal project (where the client is a business function and the supplier is ICT for example) or external.