The recurring causes
Unclear objectives and scope
If people cannot say in one sentence what the project will achieve and how success will be measured, scope will expand to fill the gap.
Weak requirements
Building the right thing requires knowing what it is. Requirements discovered during build or testing are the most expensive kind — see business analysis.
Slow decisions
Issues that wait weeks for a decision quietly destroy schedules. Governance should make it clear who decides what, and how quickly.
Unmanaged risk and dependencies
Risks that are known but not owned become issues. A simple, actively used RAID register prevents many surprises.
Optimistic reporting
Status that is green until suddenly red is a reporting failure. Progress should be shown in working outcomes, not percentages.
Supplier misalignment
Vague contracts and acceptance criteria let supplier and client hold different views of what "done" means.
Ignoring adoption
A delivered system that people do not use, or use badly, is a failed project. Change management belongs from the start.
Early warning signs
- Milestones keep moving, and each new plan is as optimistic as the last.
- Nobody can show working output, only activity.
- Scope changes are accepted without impact assessment.
- Key decisions are repeatedly deferred.
- Users have not seen the solution, and go-live is close.
What recovery looks like
- An independent health check of the real position.
- Root causes separated from symptoms.
- A reset of objectives, scope and plan with sponsors.
- Stabilised governance, reporting and supplier management.
- Delivery in short, demonstrable increments to rebuild confidence.
See project rescue for governance-led recovery, and software project rescue when the code itself needs recovering.