Most Dynamics 365 programmes don’t fail in build. They start to unravel much earlier, during discovery.
It’s a pattern that comes up time and again. Discovery gets treated as a formality, a box to tick before the real work begins, or it gets handed entirely to the SI to run without sufficient client-side ownership. From a Programme Director’s perspective, that’s the moment control starts to slip away.
Here’s the thing: discovery isn’t about configuration. It isn’t a fit-gap marathon. Done properly, it’s about removing uncertainty before momentum makes change expensive. Because once you’re deep into build and assumptions start to surface as problems, the cost of course-correcting is a different conversation entirely.
At its simplest, discovery should be able to answer one question: do we understand the business, data, technology and separation constraints well enough to proceed with confidence?
If the answer is anything other than a clear yes, you’re not ready to move forward.
Strong discovery creates clarity across five areas. Each one matters in its own right. Together, they determine whether a programme is built on solid ground or borrowed time.
Who owns process decisions? Who signs off on data? Who provides regulatory assurance, and who has the authority to say a programme is ready to go live? If those answers are fuzzy during discovery, they will be contested later, typically under pressure, and at the worst possible moment.
Discovery is where Day 1, TSA and post-stabilisation scope need to be made explicit. Not everything belongs in Day 1, and that’s fine, but everything must be consciously staged rather than left to be figured out further down the line.
ETO/MTO, service, installed base, quality, country requirements. These are the areas where the standard D365 model or an established template is most likely to be stretched. Discovery should surface those pressure points before configuration begins, not after.
Critical data objects, their real owners and the quality risks sitting underneath them must be visible early. Late data issues are rarely technical problems. They’re discovery failures that were allowed to travel downstream.
Are the resourcing assumptions realistic? Which roles genuinely need to stay business-owned? Where are dual-role pressures already forming before the project has even properly started? These are questions discovery should be answering, not delivery.
There’s a misconception worth addressing directly. Discovery is sometimes viewed as a brake on delivery, particularly when there’s pressure to show momentum early.
The opposite is true. Strong discovery is what allows delivery to move faster, with fewer surprises, clearer ownership, and far more confidence at every stage gate. Programmes that rush through discovery don’t move faster overall. They just move their problems later, where they’re more expensive to solve.
And when discovery does its job properly, it also surfaces something else: the gaps. Gaps in Programme Directors, process owners, data leads and D365 specialists are often where programmes quietly stall. Not because of the technology, but because the right people aren’t in place at the right time.
That’s the uncomfortable truth that experienced Programme Directors will recognise immediately.
The technology exists. The platform is capable. What causes programmes to lose momentum, overshoot budgets and miss go-live windows is almost always the assumptions that were left unspoken during discovery, and the talent gaps that weren’t addressed early enough to matter.
At Broster Buchanan, we specialise in placing transformation and ERP talent across the full programme lifecycle. Whether you’re building out a client-side team ahead of discovery or reinforcing a programme that’s already in flight, we work quickly and precisely to find the people who make the difference.
If you’re running a D365 programme and want to talk through your resourcing needs, get in touch with the Broster Buchanan team today.
