Service — Project recovery
An honest read of where the programme is — and a credible way forward.
When a Microsoft AI or Dynamics 365 programme has stalled, the first thing it needs is not more activity. It is an accurate picture of where it actually is, and a plan the team and the board can both stand behind. That is the work.
The signals
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 team is usually working hard — just without a shared picture to work from. A few signs tend to show up together:
- No one can describe the current architecture the same way twice.
- The hard items — security, data migration, integrations — keep being deferred with “we’ll figure that out later”.
- The plan and the reality have quietly drifted apart, and nobody has re-baselined.
- The person everyone goes to when something breaks is overloaded and undocumented.
- Status is green on the report and amber in every corridor conversation.
“We’ll figure that out later” is the single phrase that tells me a programme is already in trouble. Later rarely comes — it just turns into a crisis three weeks before go-live.
The method
Four moves to turn it around
1 · Land
Talk to everyone. Find out who really knows what, who actually does what, and who the team turns to when something breaks. The corridor view of a programme tells you more in the first hour than any document.
2 · Map the mess
Write down the As-Is honestly — what is genuinely built, integrated and decided, and where the workarounds are. That single accurate artefact is usually worth the engagement on its own.
3 · Blueprint the future
Design the To-Be that fits the budget that remains, the people you have and the data as it really is. Make the trade-offs explicit, then get genuine agreement — from the team and from the people holding the budget.
4 · Flex, adjust, deliver
Stay close to delivery. Work the integration questions as they surface rather than deferring them, keep the documentation current, and be there for the harder calls — steady, visible progress towards a result everyone can stand behind.
What you get
Tangible artefacts, not a verdict
A recovery engagement is not an audit that hands back a score. It produces things the programme can use: an accurate As-Is reference the team keeps using long after I leave; a To-Be design with the trade-offs named openly; a re-baselined plan the board can actually get behind; and hands-on architecture leadership through the part of delivery where it matters most.
And because your team is involved at every step, the programme comes out of it with stronger people — not a dependency on me. The aim is a project we can both be proud of, recovered in a way that holds.
Is a programme of yours in the difficult middle?
It is usually worth a straightforward conversation before it becomes a crisis three weeks from go-live. The first call is just an honest read of where things are.