Red to Green: The First 30 Days of Rescuing a Programme

For months the status report said amber, or even green. Then, quite suddenly, it says red: the date will be missed, the money has run out, or the thing being built does not do what the business needs. Practitioners call this “watermelon reporting”: green on the outside, red on the inside.

When a programme is in trouble, the instinct is to act fast: add people, demand a new plan, replace the supplier. Most of those moves make things worse in the first month. This article sets out why programmes hide trouble for so long, and a practical way to spend the first 30 days of a rescue.

Why bad news travels slowly

Researchers have studied this for decades, and the findings are consistent.

• People keep quiet. Studies of troubled software projects describe a “mum effect”, in which people are reluctant to pass bad news up the line, and a “deaf effect”, in which managers fail to act on warnings when they do arrive. Some who raised the alarm paid a personal price for it Communications of the ACM JMIS.
• Commitment escalates. Barry Staw’s experiments in the 1970s found that people who were responsible for a failing decision tended to invest more in it, not less, although later attempts to repeat the results have been mixed Organizational Behavior and Human Performance. In a survey of IT audit professionals, Keil, Mann and Rai reported that 30% to 40% of IT projects showed some degree of escalation, and the strongest predictor was the urge to finish once a project seemed nearly done MIS Quarterly.
• It happens slowly. Keil and Mähring describe failing projects becoming “black holes” one day at a time, through drifting, treating symptoms and rationalising continuation, and conclude that “without executive intervention, these projects almost inevitably turn into black holes” California Management Review.

None of this is about bad people. It is about normal people in a system that makes bad news expensive to deliver. A rescue has to change the system, not just the plan.

Programmes do turn around

Red is not the same as failed. In the UK government’s major projects portfolio, 34 of 189 projects were rated red in 2026. The same report recorded 18 projects moving from amber to green and one from red to green, and NISTA, which publishes it, notes that a red rating “does not necessarily indicate project failure” NISTA.

Research on troubled software projects found that turnarounds were usually triggered by someone from outside the team: a senior manager, an auditor or an external adviser JMIS. Universal Credit is a well-known example. In 2013, after a review raised serious concerns, the programme was paused and reset; the department wrote off £34m of IT, and the National Audit Office found it had lacked “adequate measures of progress” NAO. The reset was painful, and it is why the programme could continue.

Week 1: establish the truth

• Commission an independent baseline. Someone with no stake in the history should establish what has actually been delivered, what has been spent, and the rate at which money is going out.
• Work from evidence, not reports. Look at working software, test results, the defect list and the contracts, not the status slides.
• Make bad news safe. Say, out loud and often, that the people who surface problems now are helping. Then prove it.
• Rate it honestly. Use plain definitions. In government’s scale, red means successful delivery “appears to be unachievable” without major action, which is a reason to act, not a verdict on the people.

Week 2: stop the bleeding

• Freeze scope. No new requirements until the plan is reset, however good they are.
• Cut work in progress. Count everything that has started and not finished, and stop starting. Little’s law, a basic result in queueing, shows that at a given rate of delivery, more work in progress means everything takes longer Operations Research. Donald Reinertsen’s work on product development makes the same case for limiting work in flight.
• Don’t add people as a reflex. In The Mythical Man-Month, Fred Brooks warned that “adding manpower to a late software project makes it later”. Later analysis suggests it depends on timing and on how well the work can be divided, but the warning stands: fix the flow and the scope before adding people.
• Pause what cannot show progress. If a workstream cannot demonstrate what it has delivered, it should not keep spending while you find out.

Week 3: reset governance

• Appoint one accountable owner, with the authority to make decisions and the time to make them.
• Set clear decision rights. Who can change scope, approve spend and accept the work?
• Report on evidence. Replace colour-coded opinions with measures of delivered, working outcomes. The National Audit Office traces repeated problems in major programmes to four areas: scope, planning, managing dependencies, and oversight NAO. Report on each.
• Agree tripwires in advance. Decide now what would trigger a stop or a re-scope, so that the decision is not made under pressure later.

Week 4: re-plan with ranges, and decide

• Plan in ranges. Estimates early in a programme can be out by a factor of four in either direction Construx, and studies of real projects found that uncertainty does not shrink on its own as work progresses IEEE Software. It narrows when decisions are made. Give a likely date and a cautious one, and say what would move them.
• Make a real decision. Continue, re-scope or stop. Montealegre and Keil’s study of how failing projects are brought back under control describes the steps: recognise the problem, re-examine the current course, look for alternatives, and carry out the change.
• Test for sunk costs. Ask: if we were starting today, knowing what we know now, would we start this programme? If the answer is no, the money already spent is not a reason to continue.

What success looks like at day 30

Not green. A programme rescued in 30 days is rare, and claiming it would be the old habit returning. Success at day 30 is a programme that everyone agrees is telling the truth about itself: a known position, less work in flight, one owner, a plan in ranges, and a decision taken on its merits.

If you have a programme in trouble and need an independent view, talk to us. We will tell you where it really stands, and help you decide what to do next.

Sources

1. Keil, M. and Robey, D. (2001). Blowing the whistle on troubled software projects. Communications of the ACM, 44(4).
2. Smith, H. J., Keil, M. and Depledge, G. (2001). Keeping mum as the project goes under. Journal of Management Information Systems, 18(2).
3. Staw, B. (1976). Knee-deep in the big muddy: a study of escalating commitment to a chosen course of action. Organizational Behavior and Human Performance, 16(1).
4. Keil, M., Mann, J. and Rai, A. (2000). Why software projects escalate. MIS Quarterly, 24(4).
5. Keil, M. and Mähring, M. (2010). Is your project turning into a black hole? California Management Review, 53(1).
6. National Infrastructure and Service Transformation Authority (2026). NISTA major projects annual report 2025-26.
7. Keil, M. and Robey, D. (1999). Turning around troubled software projects. Journal of Management Information Systems, 15(4).
8. National Audit Office (2013). Universal Credit: early progress.
9. Little, J. D. C. (1961). A proof for the queuing formula: L = λW. Operations Research, 9(3).
10. Reinertsen, D. (2009). The Principles of Product Development Flow. Celeritas Publishing.
11. Brooks, F. (1975). The Mythical Man-Month. Addison-Wesley.
12. National Audit Office (2020). Lessons learned from major programmes.
13. McConnell, S. The cone of uncertainty. Construx.
14. Little, T. (2006). Schedule estimation and uncertainty surrounding the cone of uncertainty. IEEE Software, 23(3).
15. Montealegre, R. and Keil, M. (2000). De-escalating information technology projects: lessons from the Denver International Airport. MIS Quarterly, 24(3).