Most programme failures do not arrive as a single catastrophic event. They accumulate. Slowly. Across governance, delivery, and stakeholder engagement. By the time the symptoms are obvious, the options have narrowed. Here are seven signs that your programme needs an independent set of eyes.

The steering committee has stopped asking hard questions

A functioning programme governance structure is relentless. Steering committees challenge assumptions, push back on timelines, interrogate risk mitigations, and demand evidence. They exist to make decisions that programme management should not.

When that stops, governance has failed.

You see it first in the agenda. Steering becomes a briefing forum rather than a decision forum. The same RAIDs appear month after month. Challenges that should have triggered escalation are buried in the appendix. The sponsor nods, the CFO signs off, and nothing changes. This is rubber-stamping. It means governance is not performing its real function. It means the programme is managing itself unchallenged.

This signals something structural: control has shifted away from the client. Whether to the vendor, to the SI, to the incumbent programme team, or simply into structural inertia, the client is no longer actively steering its own transformation.

The programme timeline has been reset more than once

Plan changes. That is normal. A reset is different. It is an admission that the previous timeline was fundamentally wrong, and a new one has been constructed to replace it. When this happens once, it signals a planning failure that was eventually caught and corrected. When it happens twice, it signals something deeper.

A second reset means the root causes of the first reset were not addressed. It means the programme either does not understand what is driving delay, or understands and cannot fix it. Every reset also signals something to the broader organisation: delay is acceptable. The timelines are not firm. Momentum is not maintained. That message cascades through the stakeholder base and erodes pressure to complete.

This signals something structural: the programme does not have reliable visibility into its own progress, or it has lost the leverage to maintain schedule discipline. Either way, the current plan is not credible.

The vendor is setting the agenda in workshops

Implementation workshops are where configuration decisions are made and design assumptions are documented. These are client decisions. They should be owned by the client, challenged by the client, and decided by the client with the vendor in a supporting role. The vendor brings platform expertise and experience from other implementations. That is valuable. It is not decision authority.

When the vendor drives the agenda, defines the options, and "recommends" a course of action that the client then accepts, the decision framework has reversed. The client is no longer deciding. It is approving. This happens most easily when the client team lacks the platform fluency to interrogate vendor advice, or when time pressure creates permission to skip the decision process.

This signals something structural: the client has lost functional control of its own implementation. The vendor is now prioritising the path of least resistance within the platform, not the best outcome for the client business. Configuration debt is accumulating.

Nobody can explain the benefits case anymore

Every transformation programme exists because it is supposed to deliver something. Efficiency gains. Cost reduction. Capability improvement. Risk mitigation. Revenue protection. The benefits case is the answer to why. It anchors every subsequent decision.

When you ask a programme lead to articulate what the programme is delivering, and the answer is vague, or hedged, or has been revised multiple times, the programme has a deeper problem than schedule or budget. It has lost its purpose. Benefits are either not being tracked, or are being actively avoided because they are not tracking as planned. Neither is defensible.

This signals something structural: the programme may be delivering something, but it is not delivering what it was commissioned to deliver. That is not a delivery failure. That is a governance failure. Nobody is minding the store.

The programme team and the business have stopped talking

A healthy programme maintains tight connectivity with the business it is transforming. Not because everyone loves each other. But because the business has requirements, the programme is supposed to meet them, and that conversation does not end at the initial discovery phase. It continues. Requirements change. Assumptions surface. Trade-offs need to be made together.

When that communication goes dark, it usually means one of two things. Either the business has given up on the programme and stopped engaging because it has concluded the programme will not deliver what was promised. Or the programme has stopped asking, because it is delivering what was technically planned rather than what the business actually needs. Either way, the gap is widening.

This signals something structural: the programme is no longer customer-focused. It is process-focused. What gets built may be technically correct and on-spec. It will not be what the organisation needed.

RAIDs are being managed but nothing is being resolved

A RAID is a tool. It surfaces and tracks risks, assumptions, issues, and dependencies. But a list is not management. Management is resolving them. When you see a RAID where issues are being logged, updated, and re-logged month after month without closure, you are looking at process theatre. The team is busy maintaining the log. It is not busy closing the issues.

This happens when issues are either genuinely unresolvable within the current programme structure, or when resolving them would require decisions that nobody wants to make. Deferred issues accumulate. They become dependencies for later activities. Later activities slip. Slippage gets escalated. Nothing changes.

This signals something structural: the programme has unresolved problems and is managing the symptoms rather than addressing the root causes. It is burning schedule and credibility to keep moving.

The executive sponsor has gone quiet

The executive sponsor is the owner. Not in the sense of a figurehead approval. In the sense of accountability. A functioning sponsor is active. Present. Asking questions. Removing obstacles. Holding people to account. Making decisions when the programme needs them made.

When the sponsor disappears from the programme, it is almost always because they have concluded that the programme is not going to deliver and do not want to be associated with that outcome. Or they have moved their focus elsewhere because they have lost confidence in the programme leadership. Either way, the signal is clear: the programme is no longer a priority.

That signal cascades. Vendors dial back resources. Team members start looking for other projects. Decisions that would normally be escalated to the sponsor are not, because nobody expects an answer. Momentum evaporates.

This signals something structural: the programme has lost executive confidence and sponsorship. Everything that follows is salvage, not transformation.

A proper health check examines all of these dimensions systematically. It looks at governance structures and decision rights. People. Delivery processes and execution discipline. Technology and the configuration decisions that have been embedded. And the current state of the programme against its original intent. That structural framework is what creates the insight to distinguish between normal programme complexity and warning signs that require intervention.

Programme failure does not announce itself as a single event.

It announces itself in symptoms. Governance erosion. Schedule uncertainty. Loss of client control. Stakeholder disconnection. Unresolved issues.

By the time those symptoms are visible, an independent assessment is the only way to determine what is actually going wrong, and whether there is still time to fix it.