In short: programmes rarely fail without warning. They report green while the same ten problems build underneath: reporting nobody wants to turn amber, blocked decisions, the wrong measures, uncounted work, steering committees that do not decide, unclear ownership, quiet resistance, benefits nobody owns, data that is not ready, and treating go-live as the finish line, with testing and support cut short. Each one can be found early with a plain question.
Most programmes I am brought into are reporting green. The RAG status (the red, amber or green traffic light that every programme uses to report progress) says all is well, right up until it very visibly is not. These are the ten reasons I see most often. Each comes from a real programme, and nobody is named.
1. Nobody wants to turn it amber
The green is rarely about the programme. It is about the people reporting it. Nobody wants the conversation that follows amber, so the status stays green, the report goes up and the steering committee nods. Nobody lies. They just do not say it. Not this week.
I have seen a multi-million-pound ERP programme report green for eleven consecutive weeks while the data migration was quietly falling apart, the super-users had not been trained and the go-live date was already a fiction.
The question: Are the data migration and business readiness green on the same evidence as the system build? They almost never are.
2. Stopped, and the colours cannot say so
A decision is waiting and nobody has made it. A dependency is stuck and nobody is moving it. The team has done everything it can, so the status says green, or at most amber. Red would mean someone senior explaining why the decision has not been made, and nobody wants that in writing.
On one programme, a scope decision due in September was still waiting in November. That is why I use a fourth colour. Black means stopped. Red is a delivery problem. Black is a governance problem, and it needs a different conversation.
The question: Which workstreams are waiting on a decision or a dependency outside the team, and since when?
3. Measuring the wrong thing
Green means on track against the plan. It does not say whether the plan is still the right one.
I have seen programmes genuinely green on every measure: build on time, testing on track, budget within tolerance. Meanwhile the business had changed its mind about what it needed six weeks earlier and nobody had updated the plan. The dashboard was green. The programme was delivering the wrong thing.
The question: When did anyone last check the plan against what the business needs now, not what it needed at the start?
More on this: The 6Ws: The Questions Every Change Programme Must Answer
4. The sums stopped adding up
Dashboards do not observe the programme. They report what people put in. Scope grows through a hundred small yeses, each too small to record. The people needed to change the business are the same people already running it, doing the day job and the programme at once. Nobody has counted that either.
Most programme failure is not dramatic. It is arithmetic. When demand is greater than capacity, control has already gone, whatever the colour on the screen.
The question: Has anyone counted the work, and the people available to do it, since the plan was approved?
More on this: A Task List Is Not a Plan
5. The steering committee does not decide
Forty-seven slides arrive the afternoon before the meeting. Everything is green apart from one carefully chosen amber, there to make the green look credible. Twelve people leave having made no decisions.
On one major public sector programme, the same three risks sat on the RAID log (the register of risks, assumptions, issues and dependencies) for six consecutive months. Same risks. Same owners. Same status. Documented. Owned. Unresolved.
The question: How many decisions did the last steering committee make? If the answer is zero, it was a performance, not governance.
6. Nobody owns it
Everybody was sure Somebody would do it. Anybody could have done it. Nobody did. Most programme problems start with unclear ownership, not bad people. A name typed in the owner column is not ownership.
Often the problem is seen by several people, and each decides it belongs to someone more senior. That is how important jobs get handed, very politely, to Nobody. A sponsor who attends but does not decide is the same problem at the top.
The question: For the top three risks and the next three decisions, does the named owner know, agree, and have the authority to act?
7. Quiet resistance
The loudest critic is not the problem. You can work with visible resistance. The person to watch smiles in the meeting, agrees with everything, then does nothing, or raises concerns sideways to someone who matters.
I have seen programmes derailed by people who never once said no. They are rarely malicious. Usually they are frightened that the change threatens their expertise, their authority or the workarounds only they understand.
The question: What did people actually do in the week after they agreed in the meeting? One week you can explain. Three weeks is a pattern.
8. Nobody owns the benefit
Business cases used to answer three questions: what problem the system solves, what it really costs to buy and to run, and how you will know it worked. Now the business case is often just a good demonstration, a competitor with a similar system, or the fact that it has AI in it.
The cost of buying gets examined in detail. The cost of running it is left for later, and over five years the running cost is usually the bigger number. If nobody can say what the benefit is, nobody owns it. A benefit nobody owns is a cost.
The question: Who owns each benefit, and how will it be measured after go-live?
More on this: Capex Buys the Car. Opex Keeps It Moving.
9. The data is fine
Ask any organisation whether its data is ready to migrate and the answer is yes. It has been running the business for years. That is not the same as being ready to move.
On one public sector housing programme, sixteen years of history for 4,000 properties sat across more than forty sources. The previous team had decided it was manageable. It was not. We found the problems early enough to meet a fixed contractual go-live. On another migration the old system was shut down on a Thursday, and historical data was still arriving the following Tuesday.
The question: Has the migration been rehearsed at full volume, more than once, with the business checking the results rather than the load log?
More on this: Would You Fill Your Kettle with Muddy Water?
10. Go-live treated as the finish line
Go-live day is the best day on any programme. Then Monday happens. The first call comes in at 8:14. By lunchtime someone has found a data issue that was not caught in UAT, the final round of testing where real users try to break the system. The users were trained six weeks ago and have not touched it since. The hypercare team, the people who stay close to support users after go-live, was meant to be eight people. It is three.
I have seen hypercare planned to run for four weeks after go-live, then cut to eleven days. The finish line is not go-live. It is the business performing better than it did before the programme started.
The question: Did real users test the system with real data, and does the hypercare plan name people, confirm their availability and say when it ends?
The pattern
None of the ten is a technology problem. Each one is about people: what they report, what they decide, what they own and what they avoid saying out loud. That is why the status was green.
Every one of them can be found early, by asking a plain question and listening to the answer.
Early in my career I was testing the control system at a gas compressor station. I disconnected one wire to see what would happen, and shut down the whole site in front of everyone. The design was wrong. It had looked fine on every drawing and passed every test that did not pull the wire. That lesson has stayed with me ever since.
Which of the ten apply to your programme?
The Programme Health Checker tests these areas in sixteen questions and gives an instant RAG score, including Black, with a report you can take straight into a steering committee.
Use the Health Checker Read the FAQ