Why Your Programme Is Late (And It Is Not What You Think)
Everyone has a theory about why programmes run late.
Scope creep. Poor planning. Unrealistic timelines. Lack of stakeholder alignment. These are the answers that appear in every post-mortem, every lessons-learned session, every McKinsey report. They are not wrong. They are just not the real answer.
After 15 years of running complex programmes and watching others run them, I have noticed something. The surface reasons are always present. But underneath them, almost without exception, is one of a small number of problems that nobody wants to put in writing.
This is my attempt to put them in writing.
The report said green. The room knew otherwise.
The most common reason programmes are late is one that rarely appears in the official record.
The RAG status was green, or amber at worst, long after the people in the room knew the timeline was not going to hold. Somebody knew. Several somebodies knew. But the escalation never happened, the conversation was deferred, and by the time the red appeared on the dashboard, the delay was already baked in.
This is not a planning failure. It is a psychological safety failure. People do not escalate bad news in environments where bad news is unwelcome. They manage upwards. They smooth the report. They tell themselves it will sort itself out.
The question to ask is not "why did the schedule slip" but "when did people stop saying what they actually thought, and why?"
The decision that nobody made
The second pattern is slower and harder to see in real time.
Somewhere in the middle of a programme, a decision needs to be made. It might be a scope trade-off, a resource reallocation, a technology choice, or a call about whether a dependency is truly resolved. The decision gets raised, discussed, and then... does not get made.
It goes into a log. It gets escalated. It becomes a standing agenda item. Meanwhile, teams are building against an assumption that may not hold, because they cannot stop and wait. They are on a timeline.
I watched this play out in one engagement in a way that is hard to forget. A critical dependency had been flagged from the very first programme report. It appeared in every steering committee pack. Every stakeholder in the room acknowledged it. Nobody disputed that it was a risk. And yet the decision required to resolve it kept getting deferred. One month. Then another. Then several more. By the time it was finally addressed, the downstream rework and delay had inflated the programme cost to 150 percent of the original budget. The dependency itself was never the problem. The inability to make a decision about it was.
Delayed decisions compound. Each one creates a downstream assumption that becomes harder to unwind as the programme progresses. By the time the decision finally gets made, the cost of reversing the work built on the wrong assumption is part of why the programme is late.
Decision latency is one of the most underreported causes of delay in large programmes. It does not show up as a risk. It rarely shows up in a lessons-learned. It is just there, quietly accumulating.
The sponsor who was not really sponsoring
In 15 years of delivery, I have seen genuine executive sponsorship once.
The programme was an energy platform. The team defined, designed, and delivered a working MVP in seven months. By any measure, that is exceptional. But what made it possible was not the team's capability, though they were good. It was what they did not have to do.
They did not have to manage stakeholders. They did not have to tell the story upwards. They did not have to worry about whether the business was aligned, whether the right people were onboard, whether the next steering committee would surface a challenge that would derail the sprint.
The sponsor did all of that. Stakeholders were part of the demos, part of the process, but the sponsor was the one who managed the narrative, brought people along, and made sure that by the time a decision was needed, the groundwork had already been done. The delivery team delivered. The sponsor sponsored.
The result was the smoothest programme I have been part of.
I have thought about that programme often since, because it showed me something clearly. The reason most programmes do not run like that is not that sponsors are bad leaders. It is that most sponsors do not understand that managing the stakeholder environment is their primary job, not an occasional obligation.
Executive sponsorship is one of those things that looks fine on paper until it is not. The sponsor attends the steering committee. They sign off on the status report. They are visible enough that nobody questions whether they are truly engaged.
But genuine sponsorship is different. It means carrying the story so the team does not have to. It means pushing back on the business when the business is creating the problem. It means being willing to absorb political cost on behalf of the programme.
When that does not happen, the delivery team fills the gap. They context-switch between building and managing upwards. They spend time in conversations that should never have been theirs to have. The programme slows. Nobody names the real reason.
The team that was not really a team
Large programmes are assembled, not built.
People are pulled from business units, allocated by vendors, seconded from other teams. On a RACI they look like a delivery function. In practice, they are a group of people with different employers, different incentives, and different definitions of what success means.
No team identity. No shared norms. No reason to cover for each other when things go wrong.
When the pressure comes, as it always does, these assembled groups fragment. People protect their own workstreams. They escalate to their own management chains. They optimise for their own deliverables at the expense of the programme outcome.
This is not a resourcing problem. It is a team design problem. And it is entirely preventable if the delivery leadership invests in it early. Most do not, because there is always something more urgent to do in the first month.
What the post-mortem will not say
When the programme finally ends, late or otherwise, the lessons-learned will record the same things they always do. Scope was not controlled tightly enough. Stakeholder engagement could have been better. Planning assumptions were optimistic.
These are true. They are also safe. They do not require naming the executive who never really showed up, or the environment where nobody felt safe saying what was really going on, or the fact that the team was never actually a team.
The real lessons are in those things. And until we get better at saying them out loud, in the room, before the programme ends, the 70 percent failure rate will hold.
What AI will not fix (and what it might make worse)
There is a version of this conversation where AI is the answer. Better data. Faster reporting. Predictive risk models that flag the dependency before it becomes a crisis. Automated dashboards that remove the human temptation to soften the RAG.
Some of that is real. AI is already being used to surface delivery signals that would previously have been buried in project logs and status reports. Used well, it could reduce the gap between what is happening on a programme and what leadership actually sees.
But here is the problem. AI can surface the signal. It cannot make the decision. It cannot create the psychological safety that makes people willing to escalate. It cannot ensure the executive sponsor treats their role as something other than an attendance obligation. It cannot turn an assembled group of contractors into a team that holds together under pressure.
If anything, the introduction of AI into programmes adds new layers of decision latency and new forms of nominal accountability. Who owns the AI workstream? Who is accountable for whether the AI feature actually delivers its projected business value? Who makes the call when the model is not performing as expected?
These questions are already appearing in programmes where AI features have been added to existing roadmaps, often mid-delivery, often without a clear owner for the outcome. The dependency is flagged. The awareness is acknowledged. The decision keeps getting deferred.
The pattern is familiar. The technology is new. The leadership problem is the same.
The question worth asking
The next time a programme in your organisation is running late, before you reach for the plan, ask a different set of questions.
When did people stop saying what they actually thought? Which decisions have been sitting in a log for more than two weeks? Is the sponsor actually sponsoring, or performing sponsorship? Does this group of people function as a team, or as adjacent workstreams? And if AI is in scope: who is actually accountable for it landing?
The answers will be more useful than anything in the risk register.
