The most expensive part of a project is the bit nobody plans for

By Fiona Ibbetson

From above of chalkboard with When Will It End inscription on black background

In this series I have written about the planning that gets skipped at the start, and the accountability that drifts once a project is underway. This time I want to focus on the end, or rather, what happens when a project does not quite get there, and what is lost when it does not.

The statistics are stark

The data on project outcomes is not reassuring. Research by the Project Management Institute found that only around 29% of projects are completed on time and within budget. The Standish CHAOS Report, which has tracked project outcomes for decades, consistently finds that fewer than a third of projects are considered fully successful.

A separate PwC study of more than 10,000 projects found that only 2.5% of organisations complete all of their projects successfully.

These figures are drawn largely from larger organisations with dedicated project management capability. The picture in smaller businesses, where projects tend to be less formally managed, is unlikely to be more encouraging.

Most projects, in most organisations, do not fully deliver what they set out to do.

Why projects stall in the final stretch

The halfway point of a project is where the energy peaks. The initial excitement is still present, some progress is visible, and the end feels close enough to motivate.

But the final third is harder. The interesting, creative work is largely done. What remains is often the detailed, painstaking work of implementation: testing, training, communication, process embedding, and the thousand small tasks that turn a project output into something the business can actually use.

This is also the point at which the business, having waited patiently for the project to deliver, starts to expect results. Pressure builds. People who have been borrowed from their day jobs want to return to them. Sponsors who have been funding the work want to see a return.

And so, more often than not, the project is declared done before it is finished. A system goes live without proper training. A new process is documented but not embedded. A change is announced but not followed through.

Finishing is not the same as succeeding

This is the distinction that project management theory calls benefits realisation, and it is the phase that most organisations handle least well.

A project is not successful because it was delivered on time and within budget. It is successful because the change it was designed to create actually happened, and the business is genuinely better as a result.

If a new CRM system goes live but the sales team does not adopt it, the project has not succeeded. If a new process is designed but not followed, the project has not succeeded. If a restructure is completed on paper but the working patterns and relationships do not change, the project has not succeeded.

Benefits realisation is the work of making sure the change actually lands. It is unglamorous, it is slow, and it requires sustained attention after the moment of launch when everyone’s focus has already moved on. Which is precisely why it so often does not happen.

Why this matters more in growing businesses

In a large organisation, a project team might stay in place for months after go-live to support adoption, manage issues, and track whether the intended benefits are being realised. There are often formal review points, benefit tracking mechanisms, and governance structures that persist beyond delivery.

In a growing business, the project team is usually the senior leadership team, plus whoever else could be spared. When the project is declared done, everyone returns to their day jobs immediately. The headspace that was devoted to the project disappears almost overnight.

And so the final 10% of the work, the embedding, the adoption, the measurement, gets quietly abandoned. The project is considered finished. The benefits are assumed rather than tracked. And six months later, when someone asks whether things have changed, the honest answer is: not as much as we expected.

Asking the question at the start

The most effective way to improve benefits realisation is to define what it looks like before the project begins.

What does success look like, specifically, 90 days after go-live? What behaviours will have changed? What metrics will have moved? Who is responsible for tracking that, and what happens if it is not happening?

These questions are uncomfortable to answer before the project has started, because the honest answer is often: we do not know yet. But the act of asking them forces a clarity about purpose that makes everything that follows more deliberate.

A project with a clear definition of the change it is trying to create is more likely to get to the end. And a project team that knows it will be asked to demonstrate benefits is more likely to plan for the work of realising them.

The question worth asking

Before the next project begins, it is worth asking a simple question: if we get to the end and declare this done, how will we know whether it actually worked?

If the answer is uncertain, that uncertainty is worth resolving before the project starts, not after it finishes.

The cost of a project that delivers without landing is not just the budget and the time. It is the opportunity cost of change that did not happen, and the organisational fatigue of going through the process of change without receiving its benefits.

That is an expensive outcome. And in most cases, it is a preventable one.

If you are planning a project and want to think through how you will know whether it has truly succeeded, or if you are partway through one and wondering whether the benefits are being properly tracked, I am always happy to have that conversation.

Get Ahead’s team works across the full range of project support, from planning and coordination to delivery and benefits tracking.

Get in touch: fiona@getaheadva.com   |   Explore our support: getaheadva.com



Find out more about our services or call 0330 223 7580 to discuss in more detail.