A project on fire looks chaotic from the inside, but the recovery is not chaotic. It follows the same four moves almost every time. I have run this enough times that I can describe it in the time it takes a coffee to cool — but the value is in doing it properly, not quickly.

One thing worth saying first: most "failing" projects are not failing because of bad people. They are failing because nobody stopped to map where the programme actually is against where it needs to be. The four moves below are how you get that map and then act on it.

1. Land

Before anything else, talk to people. Everyone. Find out who knows what, and who actually does what — which are rarely the same list. The org chart tells you the official version; the first day of conversations tells you the real one. You are listening for two things: where the knowledge really sits, and where the quiet anxiety is. The person everyone goes to when something breaks is the most useful person on the programme, and they are almost never the person whose name is on the plan.

2. Map the mess

Now write down the As-Is, honestly and without flinching. What is the architecture actually — not the architecture in the original deck, but the one that exists? What is genuinely built, integrated and decided? How are people really working around the gaps? This single artefact — an accurate, shared picture of the current state — is usually worth the engagement on its own, because most troubled programmes have never had one written down.

3. Blueprint the future

Then design the To-Be. Not the ideal architecture in a vacuum — the one that fits the budget that remains, the people you actually have, the data as it really is, and the political reality in the room. Make the diagrams explicit. Name the trade-offs out loud. And then do the part people skip: get genuine agreement on it, from the team and from the people holding the budget. A plan nobody has agreed to is not a plan.

4. Flex, adjust, deliver

A recovery plan that survives contact with reality is one that expects to be adjusted. Stay close to delivery. Work the integration questions as they surface rather than deferring them. Keep the documentation current. Be there for the harder decisions. The goal is not a perfect plan — it is steady, visible progress towards a result the team and the board can both stand behind.

The pattern behind the moves

Land, map, blueprint, deliver. It reads as common sense, and it is — but the reason troubled programmes stay troubled is that they skip straight to delivering without ever landing or mapping. They are busy, but they are busy without a shared picture of where they are. Slowing down for long enough to draw that picture is almost always the fastest way forward.

I have run this recovery on enterprise programmes many times. If a project of yours is in the difficult middle, it is usually worth a conversation before it becomes a crisis three weeks from go-live.