Why Projects Fail (Part 3):
Starting Execution Before the Scope Is Ready

The sponsor wants a completion date. The financial year closes in six weeks and the funds have to be committed. The design is perhaps eighty percent settled, and the team agrees that the rest can be resolved as the work proceeds.
So execution begins.
For a few months, the project looks like one of the best-performing in the portfolio. Purchase orders are placed. Site work starts. Progress reports are full of green.
Then it begins to slip.
Parts [1] and [2] of this series looked at ineffective stakeholder engagement and the absence of a systematic project management methodology. The third common cause of failure is starting execution while the scope is still immature.
Why premature execution is so costly
Early in the project lifecycle, the ability to influence the outcome is at its highest and the cost of change is at its lowest.
Once execution begins, expenditure accelerates while the opportunity to influence cost, schedule and quality narrows.
Research by the Construction Industry Institute illustrates how significant the consequences can be. In its Project Definition Rating Index (PDRI) research on industrial projects, projects with better-defined scopes finished around four percent under budget, compared with around four percent over budget for projects with poorer scope definition. Schedule performance showed a similar difference: projects with better-defined scopes finished approximately four percent behind schedule, compared with around ten percent for projects with poorer scope definition.
Consider what this looks like in practice.
A processing plant needs to be expanded. The long-lead vessels carry a nine-month delivery time, so they are ordered while the process layout is still being finalised.
The layout then changes.
The vessels no longer fit the intended arrangement, so the structural steel is redesigned, the piping routing is reworked, and the civil contractor — already on site — stands down for five weeks while waiting for revised drawings.
None of that is necessarily a failure of execution. The team may have built exactly what they were instructed to build.
The underlying issue often begins months earlier, when a commitment is made before the scope is sufficiently defined to support it.
Time spent defining scope early is usually far less expensive than correcting scope during execution.
Signs that a project is not ready
Warning signs may include:
- Deliverables are described in general terms rather than as defined, verifiable end products.
- Significant technical or delivery alternatives remain unresolved.
- Key stakeholders have not confirmed the requirements, or different stakeholders describe the finished project differently.
- There is no work breakdown structure decomposed to a level that supports estimating and control.
- Estimates and schedules rely heavily on assumptions rather than sufficiently defined work.
These warning signs do not necessarily mean execution must stop, but they may indicate that the project is moving ahead before the scope is sufficiently defined.
Overlap should be a decision, not a default
There are good reasons to begin some execution work before definition is complete.
Fast-tracking can bring a facility into operation sooner. Long-lead items may need to be ordered before the design is finalised. On some projects, waiting for every detail before starting anything would itself create unnecessary delay.
The problem is not the overlap.
The problem is overlap that has not been recognised and managed as a risk.
Where phases are deliberately overlapped, the project manager should know which parts of the scope are sufficiently defined to proceed, which remain open, and what additional risk the organisation is taking on.
Contingency, procurement decisions, contracting strategy and change management should all reflect that uncertainty.
Not every project can define its full scope up front. Where uncertainty is inherent, progressive elaboration may be the appropriate response.
The principle holds either way:
The level of scope definition should match the level of commitment being made.
Projects get into trouble when an organisation commits to a fixed scope, cost or schedule baseline that the current level of definition cannot reliably support.
Managing the transition to execution
Phase gates with clear readiness criteria provide a practical safeguard.
For projects using a baseline-driven approach, before significant execution begins, ask whether the project has:
- An approved scope baseline, including a work breakdown structure decomposed to a level that supports estimating and control.
- Estimates and schedules appropriate to the current level of definition.
- Key risks identified and assessed.
- Major assumptions documented.
- Confirmation from key stakeholders that the defined scope reflects their requirements.
A phase gate only works if it is a genuine decision point.
If approval is automatic, it becomes an administrative formality rather than a project control.
A mature scope is also one of the project's strongest defences against the fourth common cause of failure — poor management of scope change — which is the subject of the next article.
When work begins before the scope is properly defined, every clarification looks like a change, and every change looks like a clarification.
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.
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
