Most overruns are not technical failures
When an IT project runs late, the review usually points at a technical cause: an integration that took longer than expected, a vendor that missed a deadline, a migration that hit unexpected data issues. Those things happen, but in most projects I have been part of or reviewed, the technical issue was a symptom. The actual cause was upstream, in how the project was governed before the technical work even started.
Scope defined well enough to say no to
A scope document that describes what the project will deliver, but not what it will not deliver, is not really a scope document. Without an explicit boundary, every reasonable sounding request during delivery becomes a debate instead of a quick decision. The projects that hold their timeline usually have a change control process that was actually used, not just written into a charter and forgotten.
A stakeholder cadence that surfaces problems early
Weekly status reports that say on track until the week they suddenly do not are a governance failure, not a project failure. A cadence built around a small number of concrete indicators, whether a milestone is actually complete rather than planned, whether risks logged two weeks ago moved or stayed static, catches problems while there is still time to act on them.
A risk register that gets used, not filed
Most projects have a risk register. Far fewer actually revisit it in every steering meeting and update ownership and mitigation status. A risk that sits unchanged for a month in a spreadsheet nobody opens is not being managed, it is being documented.
Vendor management that assumes misalignment, not malice
Vendor delays are rarely about a vendor cutting corners. They are usually about a dependency, an approval, or a piece of information the vendor was waiting on from the client side that nobody tracked as a joint responsibility. Treating vendor timelines as a shared risk, with joint checkpoints rather than a one way status update, catches this earlier.
Go live readiness that is a checklist, not a feeling
Deciding a system is ready to go live should not come down to a gut sense in a steering committee meeting. A defined readiness checklist, covering data validation, rollback plan, support coverage, and user training completion, turns that decision into something objective that can be reviewed and challenged before the date is locked in.
A short example
On a large enterprise platform migration I supported, the program had a solid technical plan but was tracking three weeks behind by the midpoint. The root cause was not the technical build. It was that change requests were being approved informally in hallway conversations and never reflected in the plan, so the plan looked accurate while the actual scope had quietly grown. Reinstating a simple, enforced change control step, no new scope without a written impact assessment, brought the program back within two weeks of its original date without cutting anything from what was delivered.
A short checklist for your next steering meeting
- Can your team name three things this project explicitly will not do?
- Does your status report show milestone completion, or milestone intention?
- When was the risk register last actually updated, not just opened?
- Are vendor delays tracked as a shared risk or a one way status?
- Is go live readiness a checklist, or a feeling in the room?
The same discipline applies whether the project is a cloud migration or a platform build. If you want to see how the cost side of a migration typically breaks down, that is covered in what a migration actually costs. If the delivery includes a Kubernetes platform, the reliability patterns worth building in from day one are in this post.
If you are running a program that has started to slip and want an outside read on where the real risk sits, get in touch through the contact page.
Leave a comment