Seven signs your programme needs a health check

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 the decisions a programme cannot make for itself.

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. The first slipped date was the signal, and what a board asks in the fortnight after it largely determines whether there is a second. 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 and the system integrator in supporting roles. The vendor knows the platform. The system integrator knows the method. Both are worth paying for. Neither is decision authority.

When the vendor or the system integrator 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 fluency to interrogate the 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 platform is being shaped by the path of least resistance, not by how the business needs to run. Configuration debt is accumulating.

Nobody can explain the benefits case any more

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: something is being built, and nobody can say whether it is what was commissioned. 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.

An old issue is one of three things. It has been accepted, which is legitimate and has a decision behind it. It is genuinely unresolvable within the current programme structure. Or resolving it would require a decision that nobody wants to make. The log cannot tell you which. A person can. 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 goes quiet, it is easy to read that as the sponsor withdrawing. It is almost never a sponsor problem. A sponsor holds authority. They rarely hold the detail, and they only ever see the programme's own account of itself. Sit in that seat for six months, where every pack says the same thing and every question gets a reassuring answer, and silence is what a reasonable person does.

The silence 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, and it is not a failure of will. The sponsor has been left with nothing independent to act on. What reaches them has been shaped entirely by the people being governed.