The project that looked profitable until April
Picture a 35-person Microsoft partner. They sign a Dynamics 365 Finance & Operations rollout, staff it with their strongest Solution Architect, and the burn-down chart looks clean through go-live. Then the October release wave lands, a customized form they hand-built stops binding to the entity it was wired to, and the only person who understood that configuration is now three projects deep on a different account. The fix takes two weeks of unbilled senior time. Multiply that across a portfolio of clients and you understand why a firm can be "fully booked" and still watch its services margin sag quarter over quarter.
This is the part of Dynamics delivery nobody puts in the SOW. The platform is not the problem — Microsoft ships a genuinely capable stack. The problem is that the knowledge of how this client's instance was actually built lives in one person's head, and Microsoft's twice-yearly release cadence guarantees that knowledge gets tested again and again. When configuration decisions aren't written down, every release wave is a new diagnostic project instead of a routine validation.
It's a well-documented pattern: roughly 60% of Dynamics 365 implementations fail to deliver the ROI the client signed up for, and the failure rarely shows up at go-live. It shows up in month seven, when the people who built the system have moved on and the documentation that should have carried the logic forward never existed.
Do the margin math on rework
Rework is the quiet line item that decides whether a delivery shop is a real business or a high-stress hobby. Industry data puts rework at 30 to 50% of total effort in undocumented implementation environments. Run that through partner economics: say a firm targets 40% gross margin on services, and a third of its billable hours get eaten by re-configuring flows that were scoped wrong, debugging customizations after an update, and apologizing to a client who expected something else. Effective margin collapses toward zero. You're not running a consulting practice at that point — you're subsidizing your clients' learning curve with your own payroll.
If you want the version of this argument framed around exit value, we wrote it up in From Tribal Knowledge to Turnkey: Documenting Your Way to Higher Multiples.
The gap between what Sales sold and what F&O actually does
Most service founders think customer success in the Dynamics world is about quarterly reviews and staying close to the sponsor. In a complex ERP or CE rollout, that's a rounding error. Success here is technical consistency — whether the Order-to-Cash flow you demoed still does the same thing after the next release, whether a junior consultant can pick up the account without re-deriving every design decision, whether the client's controller can close the month without filing a support ticket.
Clients don't churn over a missed check-in. They churn because someone in your sales conversation said "native integration," your delivery team knew that meant a meaningful build of custom dual-write logic and Azure middleware, and nobody reconciled those two definitions in writing before the build started. The word "integration" meant three different things to three people in the room:
- Sales heard a plug-and-play connector that ships in the box.
- Delivery knew it was a real engineering effort with mapping, error handling, and retry logic.
- The client assumed it would behave like the consumer apps on their phone.
That spread is where the project quietly goes red. And it's the dominant failure mode across the category — per the breakdown of McKinsey's analysis of why ERP projects fail, around 70% of transformation failures trace to organizational misalignment and weak requirements rather than technical defects. The code mostly works. The shared understanding of what the code is supposed to do does not. Broader research on why most ERP transformation projects fail lands in the same place: it's a definition-and-documentation problem dressed up as a software problem.
The fix is unglamorous. Before a single extension is deployed, the integration design, the customization-versus-configuration call, and the acceptance criteria for each business process need to be written down and signed off — not buried in a Teams thread. You cannot recover a misaligned architecture with relationship management. The hard part is admitting that an "agile, we'll figure it out as we go" delivery style is often just an undocumented one. We get into the recovery side of this in Turning Delivery Failures into Retention.
Four documentation moves that keep a Dynamics project out of the red zone
None of this is about turning your architects into form-fillers. It's about giving them a baseline so their senior judgment goes toward the genuinely hard problems instead of re-solving the same Order-to-Cash configuration for the fifth client this year.
1. Document the exception path, not just the demo
Your design docs almost certainly cover the clean scenario where every field is populated and every approval fires on time. Dynamics projects don't die there. They die in the exceptions: what the system does when an order is cancelled after the invoice posts, how a customer record with no primary email routes through a workflow, what happens to a dual-write sync when one side times out. Make the team write down the exception logic explicitly. That's the documentation a future consultant will actually reach for when a release wave breaks something.
2. Build a configuration baseline instead of starting at zero
Stop hand-building a bespoke sales process flow for every CE engagement. A large share of B2B selling motions are functionally identical, and most F&O setups share the same backbone. Maintain a documented standard configuration — a reference build with the design rationale captured — so your team starts each project most of the way to done. A junior consultant working from a senior-authored baseline ships senior-quality work, and you stop paying for the same wheel to be reinvented account after account.
3. Put hard gates on the project, modeled on FastTrack discipline
Microsoft's own implementation guidance is built around staged checkpoints for a reason. Borrow the structure: lock real gates at requirements sign-off, solution-blueprint approval, and UAT readiness. If the design document for a phase isn't signed, the phase doesn't start. It feels rigid the first time you enforce it and it saves you the most expensive thing in this business — senior cleanup time after go-live.
4. Run a pre-mortem with the client before kickoff
Sit the sponsor down and ask: "It's six months from now and this rollout failed — what happened?" You'll surface risks that never make it onto a RAID log, like a VP of Sales who quietly resents being moved off the tool he built his career on. Write those risks down and attach a mitigation to each one. The honest ones are usually about people and adoption, not technology.
Do this consistently and you've done more than protect a few client relationships. You've made your delivery transferable — which is precisely what an acquirer pays a premium for and discounts hard when it's missing. More on that in The Transferability Premium.
