The Project Was Planned. So Why Did It Not Deliver?

I have sat in enough project meetings to notice something uncomfortable. Most projects are not short of plans.

They have schedules. They have dashboards. They have risk registers. They have action logs. They have Agile boards. They have progress meetings, integration meetings, commercial meetings, design meetings and leadership meetings.

There can be thousands of activities, hundreds of reports and more data than anybody could realistically read. And yet one very simple question can make the room go quiet.

What exactly needs to happen next for this project to move forward?

That question exposes something I think our industry does not discuss enough. We have become very good at managing information about delivery. That is not always the same as managing delivery.

A schedule can tell me that an activity is late. It does not automatically tell me why it is late. A dashboard can tell me that performance is red. It does not automatically tell the team what decision needs to be made today. A risk register can tell me something might happen. It does not guarantee that anybody is actively changing the conditions that allow it to happen.

An Agile board can show hundreds of completed tasks. It does not guarantee that the customer can use anything yet. A meeting can contain twenty people talking for an hour without producing one clear decision.

The gap between planning and execution

We often treat planning and execution as separate worlds. The planners create the programme. The engineers execute the work. Commercial manages contracts. Design manages design. Risk manages risk. Leadership receives reports. Suppliers manage their own packages.

Everybody is busy. But projects are not delivered inside departments. Projects are delivered through the connections between them.

That design decision changes procurement. That procurement delay changes construction. That construction sequence changes commissioning. That interface milestone changes another contractor's plan. That unresolved assumption becomes tomorrow's critical path.

The project does not care which department owns the problem. It only cares whether the dependency works.

This is why communication cannot simply mean sending more emails or holding more meetings. APM describes communication in terms of exchanging information and establishing shared understanding. Its Conditions for Project Success research also places planning and review, clear objectives, governance, competent teams and commitment among important conditions associated with success.

Information sent is not the same as information understood. An action recorded is not the same as an action owned. A decision discussed is not the same as a decision made. An activity completed is not the same as value delivered.

Agile is not the problem. Waterfall is not the problem.

This is where the debate often becomes unnecessarily tribal. Someone says Agile failed. Someone else says traditional planning failed. Then somebody recommends another framework.

The more useful question is whether the delivery system works. No methodology can compensate for unclear ownership, disconnected schedules, unresolved interfaces, poor decisions, invisible dependencies and teams that do not communicate.

You can run two week sprints. You can run a twenty thousand activity Primavera programme. You can run both together. The fundamental questions remain the same.

If the project cannot answer those questions quickly, changing the methodology will not solve the underlying problem.

The schedule should not be a reporting document

This is one of the biggest opportunities I see in project controls. The programme should be the operating model of the project.

It should connect scope, logic, interfaces, decisions, assumptions, risk, resources, milestones and accountability. When something moves, we should be able to understand what it affects. When something becomes critical, the right people should know. When a dependency breaks, it should become visible. When a decision is required, someone should own it.

When the project changes, the information people use to make decisions should change with it. That is a delivery system.

Agile should still produce something usable

Agile was never supposed to mean doing lots of activity quickly and integrating everything at the end. The Scrum Guide describes an Increment as a concrete step towards the Product Goal and states that an increment must be usable in order to provide value.

DORA also highlights the value of working in small batches because smaller changes shorten feedback loops and make it easier to learn and correct course.

Completing another hundred tasks is not necessarily progress. Progress is reducing the distance between where the project is today and something that can actually be used, accepted, commissioned or handed over.

Perhaps we are measuring the wrong thing

Instead of asking only how many activities are complete, ask what became deliverable because those activities were completed.

Instead of asking how many actions were closed, ask what risk, constraint or decision disappeared because they were closed.

Instead of asking whether the project is green, ask what evidence says it will still be green thirty days from now.

Instead of asking whether everybody received the report, ask whether everybody understands what they need to do differently because of it.

From reporting to decision intelligence

That is where project controls becomes more than reporting. It becomes decision intelligence for delivery. That is where I believe our profession needs to go next.

Not more reports. Not more ceremonies. Not another fashionable methodology. Better visibility. Better decisions. Better integration. Better communication. Better execution.

Plans do not deliver projects. People do. But people cannot deliver what they cannot see, understand, own and coordinate.

That is the problem I want XERR to help solve.