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 the month 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 plainly: what is genuinely built and integrated, what is still open, 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 that comes good, recovered in a way that holds.
Engagement shapes
Three ways to bring a programme back on its feet
Most recovery engagements are fractional — I sit inside your team for the months it takes to land the programme. A short read is the usual entry point.
2–3 weeks · fixed scope
Programme Read
2–3 days a week · 3-month minimum
Recovery Lead (Fractional)
6–10 weeks · project-shaped
Architecture Re-baseline
Is a programme of yours in the difficult middle?
It is usually worth a frank conversation before it becomes a crisis close to go-live. The first call is just a read of where things are.