Why Projects Fail (Part 4):
Scope Creep and Uncontrolled Change
The request is small. A stakeholder asks whether the control room can be moved to the other side of the building. The engineer looks at it, decides it is not a major issue, and it is accommodated.
No change request is raised. The estimate is not revised. The schedule is not updated, because the change is not expected to affect the critical path.
Over the following months, a few dozen decisions of that kind are made.
Individually, none of them is significant. Together, they describe a project that is no longer the one that was approved.
This is scope creep.
It is the fourth common cause of failure in this series, and unlike the first three, it does much of its damage after the plan has been approved, while the project still appears to be going well.
Parts 1 to 3 looked at ineffective stakeholder engagement, the absence of a systematic project management methodology, and starting execution before the scope is mature.
Change is not the problem
Projects are carried out in environments that change. Regulations are amended, markets move, technology improves, and stakeholders understand their own requirements better as the work progresses. Some changes are unavoidable. Others are genuinely worth making.
A project that resists every change may deliver exactly what was specified and still fail to deliver what the organisation needs.
The failure is not change itself. It is change that is absorbed into the project without being assessed, authorised and recorded.
Why scope creep is difficult to see
Scope creep is rarely the result of a single decision. It accumulates.
Each change is small enough to be accommodated. Each is usually requested by someone with a reasonable case. Each is often agreed to by someone acting in good faith and trying to be helpful.
The difficulty is that the work grows while the baseline stays where it was.
Once the scope being delivered has drifted away from the approved baseline, cost and schedule performance are measured against a plan that no longer describes the project. Variance reporting becomes unreliable. Dates slip for reasons that cannot easily be traced. And when the project is eventually reported as late and over budget, the failure is often attributed to execution, because the decisions that caused the deviation were never formally recorded.
The team is then held accountable for underperforming against a plan that nobody is actually working to.
Where uncontrolled change comes from
Common sources include:
- Scope described in general terms, so the boundary between a clarification and a change was never clear.
- Requirements that were never confirmed with the stakeholders who had the influence to insist on them later.
- No agreed process for raising, assessing and approving change, so change is handled differently by different people.
- Informal commitments at working level — agreements between engineers, supervisors or site staff that never reach the project manager.
- Additions made by the project team itself, on the assumption that a better product will be appreciated, although nobody asked for it.
- Contract or specification wording ambiguous enough for client and contractor to hold different views of what was included.
The first three of those are the subjects of the earlier articles in this series, which is not a coincidence.
Controlling change without obstructing it
The purpose of change control is not to prevent change. It is to ensure that changes are made deliberately, by people with the authority to make them, with the consequences understood before the commitment is made.
In practice this requires:
- A single, known route through which a change request enters the project. Where people do not know how to raise a change formally, they will make it informally.
- An assessment of the impact on cost, schedule, resources, risk, quality and other deliverables before a decision is taken.
- Approval by someone with appropriate authority. Larger changes may require the sponsor or a change control board; smaller ones may be delegated within defined limits. Both should be defined in advance, not negotiated at the time.
- An updated baseline once a change is approved, so that performance is measured against the work the project is now expected to deliver.
- Communication of the decision to everyone whose work it affects.
- A record of the decision, — including the changes that were rejected, and why.
“It is a small change” should be the conclusion of an assessment, not the reason to skip one.
Rejected change requests are worth keeping. They are often the clearest available evidence of the difference between what was asked for and what was agreed.
Adaptive approaches change the mechanism, not the principle
In Agile and other adaptive environments, change is expected rather than resisted. Requirements are elaborated as understanding improves, and the ability to respond to change is treated as a strength.
That does not mean change is uncontrolled.
In many Agile environments, change is managed through a prioritised product backlog. New or changed requirements are made visible and considered against other work, available capacity, time and cost constraints.
What changes is the mechanism used to manage scope, not the need for discipline.
Accepting additional work without deciding what will be given up in return is not agility. It is the same failure in a different vocabulary.
What the four causes have in common
Across this series, the pattern is consistent.
Poor stakeholder engagement creates uncertainty. Weak methodology leaves that uncertainty unmanaged. Starting execution before the scope is mature turns uncertainty into rework. Uncontrolled change then allows the project to continue moving while its original plan becomes increasingly irrelevant.
These causes rarely occur in isolation. They reinforce one another.
A project that begins with unclear stakeholder expectations is more likely to experience scope changes later. A project without a systematic management approach is less likely to assess those changes consistently. And a project that starts execution before the scope is sufficiently mature creates more opportunities for late changes to become costly.
That is why project failure is often difficult to trace back to one decision. It is usually the result of a chain of decisions, omissions and assumptions that gradually reduce the project's ability to remain aligned with its objectives.
Good project management does not eliminate uncertainty or change. It creates the structure needed to manage both.
A question worth asking
Before agreeing to a change of any size:
What does this change cost, what does it delay, what risk does it introduce, who has the authority to approve it, and where will the decision be recorded?
If those questions cannot be answered on a small change, they will not be answered on a large one.
Projects rarely fail because the scope changed. They fail because the scope changed and the plan did not.
Learn More About the Course
These principles form part of the University of Pretoria's Project Management Principles, Practices and Scheduling short course, presented by Prof Herman Steyn and offered fully online. A face-to-face option is also available.
The course covers project initiation, scope definition, work breakdown structures, scheduling, resource planning and project control. It also earns credit as the first of eight modules of the Programme in Project Management.
On successful completion, participants receive a University of Pretoria certificate and earn 20 PMI PDUs, 5 ECSA CPD points and 5 SACNASP CPD points.
Find out more about the course: Online Short Course on Project Management Principles, Practices and Scheduling
The Why Projects Fail series
Scope creep and uncontrolled change (this article)
