Learning Dynamics 365 Finance and Supply Chain Management is straightforward. Microsoft Learn, community resources, and sandbox environments make the platform accessible to anyone willing to put in the time. What separates successful implementations from troubled ones is understanding the nuances — the decisions that don’t live in documentation, the patterns that only emerge after years of delivery, and the discipline to keep the client’s success at the center of every conversation.

Estimation is where that discipline starts. It is the first commitment you make on a project, and it shapes everything that follows. Let’s talk about how to get it right.

Where Estimation Breaks Down

In my experience across 18 years of Dynamics 365 F&SCM implementations, estimation challenges fall into three distinct categories:

Client readiness. Organizations often approach an ERP implementation expecting it to be a silver bullet for every operational challenge they face. That expectation, while understandable, creates a gap between what the project is scoped to deliver and what stakeholders believe they are getting. Addressing this early — ideally by engaging executives and securing their commitment to understand the system first — sets a realistic foundation for the entire program.

Pre-sales oversimplification. Requirements gathered during the sales cycle are, by nature, high-level. When those early conversations become the basis for detailed estimates without sufficient validation, the numbers carry forward assumptions that may not hold up once the delivery team engages with the client’s actual processes.

Delivery variables. Changes in client direction — whether driven by budget constraints, organizational shifts, or evolving technology priorities — introduce estimation variance that is difficult to predict upfront. Experienced delivery teams anticipate this and build frameworks to absorb it. Less mature teams treat the original estimate as fixed and struggle when reality shifts.

The CRP Moment of Truth

Here is a pattern that plays out on nearly every implementation: the gap between estimate and reality becomes visible during Conference Room Pilots. And there is a good reason for that.

Prior to CRP, the project lives in documents — requirements specifications, process flow diagrams, design documents. While these are necessary artifacts, they often do not resonate with client SMEs and stakeholders the way a working system does. It is one thing to review a flowchart; it is another to sit in front of the application and walk through your daily process.

CRP is the point where customers realize what they truly need. That realization is valuable, but it also means the original estimate was built on an incomplete picture.

How to bridge that gap earlier: Prototyping and simple walkthroughs before formal CRP can significantly reduce the surprise factor. Even a lightweight demo on a sandbox environment — showing the client their core processes in Dynamics 365 before design is finalized — helps stakeholders connect with the solution in a way that documents simply cannot achieve. This early alignment makes estimation more grounded because the requirements they validate are informed by what they have actually seen.

The Myth That Every Business Is the Same

One of the most persistent assumptions in our community is that if you have implemented Dynamics 365 for one manufacturing company or one retail operation, the next one will follow the same pattern. While core supply chain concepts remain common across industries, the moment you tap into the pulse of a specific customer’s business, nuances emerge that generic templates miss entirely.

This is where the balance between standard and custom becomes critical. There are a few principles that guide this decision:

Keep the core processing engines untouched. Customizations should live on the periphery — around the edges of the standard process, not replacing the engines that drive it. This approach serves three purposes: it lowers user adoption risk because the core behavior remains familiar, it provides longevity during Microsoft service updates, and it reduces long-term maintenance costs.

Simplicity is the goal, regardless of the path. You could deliver a standard solution — as long as it is simple for the users. Or you could extend the solution to make it simple enough. The right answer depends on the specific process, the specific users, and the specific organization. It is always about balance, and it is rarely black and white.

The SI partner is not the one using the system. Every design decision should be evaluated from the perspective of the person who will use it daily. A solution that is elegant from an architecture standpoint but confusing to the warehouse associate or the AP clerk has missed the point.

A Framework That Works: Scrum/Agile with Gated Checkpoints

Methodology is often a point of debate on ERP programs, and rightly so. Here is the approach that has yielded the best results in my experience.

Start with Scrum and Agile as your foundation. The backlog-driven model gives you the flexibility to reprioritize, absorb scope adjustments, and deliver incrementally. Work is visible, progress is measurable, and the team stays focused on what matters most in each sprint.

Layer in gated checkpoints at key milestones. Design sign-off, CRP completion, data migration readiness, integration validation — these gates provide the governance structure that pure Agile sometimes lacks on large ERP programs. Sprints run within each phase, but the gates ensure that the program does not advance until critical criteria are met.

This hybrid works best when the internal team is driving. Scrum and Agile truly shine when the people building the solution understand the legacy systems, the business processes, and the organizational context. Internal teams are in the best position to build a “product” from the backlog because they live with the consequences of every decision.

Building the In-House Team: Your Most Important Guardrail

For organizations that do not yet have internal Dynamics 365 capability, here is the approach I recommend:

Start with the SI partner, but run your project team alongside them from day one. The client’s IT team and key business users should not be observers — they should be active participants in every sprint, every design review, and every CRP session.

Simultaneously, begin building your internal team around the implementation. Whether through training existing staff or recruiting new talent, the goal is to have people on the client side who understand not just the system, but the why behind every configuration and customization decision.

A trained client-IT team brings something an SI partner alone cannot: deep knowledge of the legacy systems, institutional awareness of where current processes are inefficient, and the ability to point the implementation toward genuine improvement rather than a like-for-like migration. I have seen this on recent projects where a strong and involved client-IT team ensured the project was being steered in an optimal direction, keeping business needs front and center. The difference in outcomes is measurable.

Where AI Changes the Estimation Conversation

AI-assisted tools are opening up meaningful possibilities in how we approach estimation and requirements — provided we use them thoughtfully.

Smarter requirements gathering. One of the most promising applications is using AI to structure the discovery process itself. By feeding a client’s current process documentation into AI tools, you can generate sharper discovery questions, identify gaps in the requirements before estimation begins, and translate business language into clearer, more structured inputs. This helps the entire team — client and partner alike — arrive at requirements that are more lucid and less prone to misinterpretation.

AI-assisted estimation with a caveat. An estimation tool is only as good as the estimates it learns from. However, if you are able to feed it clearer, well-structured requirements — which the AI-assisted discovery process enables — then AI-powered estimation tools can be a game changer. The key is treating AI as a tool that amplifies good inputs, not one that compensates for vague ones.

The broader shift. As AI capabilities within Dynamics 365 itself continue to evolve — Copilot features, intelligent automation, predictive analytics — the scope of what “standard” covers is expanding. This changes the build-vs-configure conversation and, by extension, the estimation equation. Staying current with these capabilities is part of estimating responsibly.

The Takeaway: Walk In with Questions

If you are a functional consultant, solution architect, or project manager reading this over your morning coffee, here is the one thing I would ask you to carry into your next project:

Walk in with questions. Do not put the cart before the horse.

Resist the urge to arrive with pre-built solutions and work backward to justify them. Instead, invest the time to understand the client’s business — the real business, not the one described in the RFP. Try the solutions after the fact. And most importantly, evaluate every decision by asking: does this make sense to the person who will use it every day?

Resonate your solutions to the people using the system, not from a system perspective. That shift in mindset — from “what can Dynamics 365 do?” to “what does this organization need Dynamics 365 to become?” — is the difference between an implementation that goes live and one that truly succeeds.

---

What frameworks or practices have helped you estimate more effectively on your Dynamics 365 projects? I would love to hear your experiences — connect with me and let’s continue the conversation.