Here is a quick question, think about your last ERP project, or the one you are planning right now. Answer honestly:
Did you define the role requirements by module, or by "D365 experience"? Was the person who ran your design workshops the same person who managed your ERP go-live? Did your implementation deliver the outcomes that justified the investment or just a go-live date?
If any of those gave you pause, you are in the right place.
Why Do So Many Implementations Fall Short?
The numbers are uncomfortable. According to Deloitte's ERP industry research, the failure rate for ERP implementations sits between 70% and 90% — and that figure includes projects that technically go live but never deliver their stated business objectives. A 2024 study by Forrester Consulting found that only 60% of Dynamics 365 implementations achieve the ROI the organisation expected at the point of investment.
The platform is almost never the reason.
Gartner attributes 70% of ERP delays to data migration issues. Info-Tech Research Group reports that over half of ERP projects run over budget. And 35% of implementation failures trace directly back to inexperienced delivery teams.
The software works. The problem is who is running it, and whether they were the right fit for the specific work the project needed.
What Is Actually Going Wrong on These D365 Projects?
The failure patterns repeat across implementations with enough consistency that they can be mapped. They tend to cluster around six recognisable pressure points.
Scope that does not survive first contact with the business. When the delivery team lacks the seniority to pressure-test requirements against platform constraints, scope is agreed that cannot be delivered cleanly. Change requests follow, then cost overruns, then timeline extensions. Organisations that reach UAT with undefined scope are already in recovery mode.
Configuration decisions made without conviction. A Microsoft Dynamics consultant who is uncertain about a design choice either defers it or makes a reversible decision that gets revisited at the worst possible moment. In a D365 F&O implementation, a chart of accounts decision made tentatively in month two can require significant rework by month eight. The cost of those deferred decisions is invisible until it is unavoidable.
Data migration treated as a final-phase task. Gartner's research makes clear that data migration issues account for 70% of ERP delays — yet implementation plans routinely treat data migration as something that happens after the system is configured. Legacy data is rarely clean. Duplicate records, inconsistent formats, and missing fields all need to be resolved before migration begins, not during it. The cleanup cost when this fails runs from $25,000 to $140,000 depending on data volume.
ERP go-live cutover managed by people who have not done one before. Cutover is high-stakes, time-compressed, and unforgiving. The decision trees are complex, the fallback options narrow with every hour on the clock, and the pressure is unlike any other phase of the project. Consultants who have the technical knowledge but not the operational memory of a live cutover tend to underestimate what can go wrong.
Customisation that outlasts its usefulness. Over-customisation routinely adds $50,000 or more to D365 project costs. The instinct to bend the system to existing processes rather than improving the processes first is understandable — but it creates technical debt that compounds through every subsequent platform update.
Post-live support handed to the wrong profile. The consultants who build a system are not always the right people to sustain it. Managed services require deep system knowledge, proactive monitoring orientation, and the ability to diagnose configuration issues without the original build context in the room. When post-live support is mismatched, client confidence in the system erodes fast.
None of these failures are mysterious. They are the predictable consequences of specific team composition gaps.
Who Needs to Be on a D365 Implementation, and Why Does Role Definition Matter?
Dynamics 365 is not a single product. It spans Finance & Operations, Supply Chain Management, Business Central, Commerce, Customer Engagement, and more — each with its own configuration logic, functional depth requirements, and implementation methodology. A consultant who describes themselves as having "Dynamics 365 experience" may have spent their career in Business Central and never touched F&O Finance. Both statements are accurate. Only one profile is right for your project.
This is where implementation planning most commonly breaks down — not at the point of delivery, but at the point of role definition.
Solution Architects carry the most consequential early decisions. In a multi-entity F&O rollout, the architect shapes intercompany accounting, consolidated reporting structures, and data migration strategy. These are decisions that compound. A gap in experience at architect level creates downstream problems that are expensive to unwind. You need someone who has made these decisions under pressure before, not someone who is making them for the first time on your timeline.
Functional Consultants are where module depth becomes non-negotiable. An SCM consultant who has delivered warehouse management in a manufacturing environment brings entirely different readiness to a supply chain project than one whose background is primarily procurement configuration. Both are functional consultants. The difference between them only becomes visible when the configuration work gets complex — which it always does.
Technical Consultants and Developers need platform fluency that maps to your actual environment. Power Platform integration, Azure middleware, AL development for Business Central, X++ for F&O — these are distinct skills. The developer who is strong in one area needs ramp time in another, and that ramp time sits on your project schedule.
Project Managers running D365 programmes need familiarity with how Microsoft's Success by Design methodology operates at scale. Managing milestone governance, handling change requests through a structured scope control process, and keeping business stakeholders aligned across a 12-to-18 month engagement requires a specific combination of technical literacy and delivery discipline that general project management experience does not automatically provide.
Where Is the Market Right Now, and Why Is Finding This Talent Getting Harder?
The talent pressure in the D365 space is structural, and it has been building since 2023.
Microsoft's end-of-support deadlines for legacy platforms — Dynamics NAV 2015, GP 2015, Dynamics CRM 2015 — triggered a migration wave that has not let up. Pearson Carter reports that D365 professionals with multi-module exposure are 35% more likely to secure top-tier offers, and that qualified candidates are booked out months in advance. Some Microsoft Dynamics implementation partners are turning down new project engagements because they cannot staff them.
The Copilot layer has further tightened the market. According to Talent International's 2025 US Microsoft market analysis, there was a 30% increase in job flow across Microsoft Biz Apps and Cloud roles in 2025 alone. Job descriptions that once read "D365 F&O Functional Consultant" now routinely include Power Platform fluency and AI process design experience. The candidate pool that meets both the module depth requirement and the Copilot readiness requirement is genuinely small.
Nigel Frank's 2026 compensation analysis confirms that D365 and Power Platform salaries are not softening despite broader technology hiring recalibration. Demand continues to outpace supply in roles that combine delivery leadership, governance ownership, and the ability to translate business requirements into scalable Microsoft solutions. For hiring managers on tight project timelines, this market reality shows up in how long shortlists take to build and how much leverage candidates hold when offers arrive.
How Does Dynamics Monk Approach D365 ERP Delivery Differently?
Dynamics Monk's project delivery model is built around one operating principle: the people who start your project finish it.
Consultant rotation — where the team that ran discovery is not the team doing configuration, and the team doing configuration is not managing the ERP go-live — is one of the most consistent sources of knowledge loss on long-running D365 programmes. That loss rarely shows up on a status report. It shows up in decisions made without context, in rework that should not have been necessary, and in post-live support that lacks the system memory to be effective.
We staff against role requirements at the point of scoping. That means matching functional depth to module, verifying delivery experience at phase level, and building the team with continuity as a design requirement, not an afterthought.
Scope governance runs through the entire engagement. Change requests are managed within a structured framework aligned to Microsoft's Success by Design methodology, protecting your project's original objectives without blocking necessary evolution. Financial predictability is not aspirational — we operate to defined budgets from day one.
For clients in regulated environments — healthcare, financial services, supply chain — we bring domain-specific delivery experience, not just platform knowledge. The Dynamics 365 implementation services that work in a hospital environment have different compliance requirements, data sensitivity considerations, and stakeholder dynamics than those in a distribution company. Both need the right team. What "right" looks like is different in each context.
Post-launch, our Managed Services capability extends delivery continuity. The team that built the system continues to operate and optimise it. Context does not reset at go-live. Accountability carries forward.
What Should You Do Next?
If you are scoping a Dynamics 365 implementation, the highest-leverage decision you will make is the team composition conversation before a contract is signed or a project kicked off. Ask potential Microsoft Dynamics implementation partners:
- Which consultants will be on this project from design through go-live cutover?
- What is their specific module-level experience, and can you evidence it?
- How is scope change managed under Success by Design, and who owns that process?
- What does post-live support look like, and is it the same team?
These questions do not make conversation adversarial. They make it honest. An experienced partner will answer them without hesitation.
If you have a D365 project in flight that is not performing, the same questions are worth asking of your current delivery structure. The reasons a project is struggling are usually visible once you know what to look for.
Dynamics Monk delivers Microsoft Dynamics 365 implementations across Finance & Operations, Supply Chain, Business Central, and Customer Engagement, with a track record spanning 80+ projects across 10+ countries. Speak to our delivery team if you're planning an implementation or looking for an honest conversation about what it should take.
