7 questions to ask your SI before you start a D365 implementation

The seven questions experienced ERP buyers wish they'd asked before kickoff. A practical starter conversation for first-time D365 customers and their SIs.

Justin Delisle
Justin DelisleCo-founder & CEO at Tato · 2026-04-21

Key takeaways

  • Most of what determines whether a D365 project lands well gets decided in the first few weeks — before the build starts, sometimes before the contract is signed.
  • 80% of ERP projects run long, over budget, or short on scope. The failure mode is almost always alignment, not technology.
  • Fixing a problem during design is cheap. During testing it costs about 5x more. After go-live, up to 10x. Getting clear on scope and 'done' early is worth real money.
  • Verbal decisions fade. A four-hour workshop can produce one paragraph of notes. The questions about documentation and recordings are about making sure what was agreed stays agreed — six months in, not just six hours.
  • The goal isn't to test your SI. It's to start the project with the same picture in both heads.

If this is your first Tier 1 ERP implementation, here's something worth knowing upfront: most of what determines whether the project lands well gets decided in the first few weeks. Before the build starts. Sometimes before the contract is even signed.

That's not a criticism of how these engagements work — it's just the shape of them. The early decisions compound. The conversations in month 1 are the ones you'll reference in month 9.

The seven questions below are the ones experienced ERP buyers tell us they wish they'd asked earlier. Not as a test, and not as a trap. As a way to make sure you and your SI start the project with the same picture in both heads — so the work that follows has the best chance of going well for everyone.

Why this moment matters

About 80% of big ERP projects run long, over budget, or short on scope. That's not because the tech doesn't work, and it's not because SIs are bad at their jobs. The technology is fine. The people are qualified. What tends to slip is alignment — the shared understanding of what was decided, what's in scope, and what "done" looks like.

A lot of that alignment gets set up (or not) in the first few weeks. Getting clear on a few basics now saves months of interpretation later. For both sides.

1. Is there a Solution Blueprint Review on the calendar?

The Solution Blueprint is the document that captures what's being built — what's in scope, what's being customized, and what's out. It's usually produced after the fit-gap analysis, which is the process where your business needs get mapped against what Dynamics already does out of the box.

The Blueprint Review is the meeting where you validate that document together. Once it's signed off, it becomes the reference point for the rest of the project.

Ask when it's scheduled, who's expected to be in the room, and what has to be true for it to be accepted. A good SI will have clear answers. This is normal project setup — you're just making sure it's on the calendar and you understand your role in it.

2. Is there a written test plan?

Ask to see the plan that describes how testing will work — when it starts, when it ends, and what's in scope. Most mature SIs will have a template ready. If yours is still building it, that's fine — just ask when it'll be ready and stay in the loop as it develops.

The thing to look for is clarity about the milestones. "We'll do testing in the spring" isn't a plan. "Here's how we define the start and end of each testing phase, and here's who signs off on each one" is.

3. What does "done" look like for testing?

This is the follow-up to question 2, and it's one of the most useful conversations you can have before build starts.

"Done" in ERP testing usually means something specific — all the planned test cases executed, critical defects resolved, and someone (usually the test lead) signing off. It's worth making sure that definition is written down and agreed on.

The reason this matters isn't about catching anyone out — it's about cost. Fixing issues found during design is cheap. Fixing them during testing is about 5x more expensive. Fixing them after go-live can be 10x. Clear "done" definitions at each phase are what keep that math on your side.

4. How are workshop notes and action items handled?

Fit-gap workshops and design sessions generate a lot of decisions, most of them verbal. A four-hour session might produce one paragraph of formal notes — which is fine if both sides remember the full discussion six months later, and less fine if memories diverge.

Ask how your SI handles workshop documentation. Do notes go out within 24 hours? Are action items assigned to named people with dates? Is there a searchable archive you can both reference later?

There's no single "right" answer here — different SIs have different systems. The goal is to understand theirs and make sure your team can find what it needs when it needs it. If the approach feels light, that's a good thing to raise now, while everyone's fresh.

5. How will custom development items be tracked?

Custom development — the stuff that has to be built because it isn't in the out-of-the-box product — is usually where the most complexity lives on an implementation. It's often called RICEFW in Dynamics shorthand: Reports, Interfaces, Conversions, Enhancements, Forms, and Workflows.

Because every custom item has to be requested, specified, built, and tested, tracking them clearly is a big deal. Ask how your SI tracks them and whether you can see the status directly, rather than through a summary in the weekly status report.

Shared visibility here helps everyone. Your SI spends less time re-explaining status. Your team can answer internal questions without chasing. And there's no surprise about what's in flight.

6. Where will workshop recordings live, and who has access?

Most implementations today record workshops — it's how modern project teams stay aligned. The question worth asking is practical: where are the recordings stored, who can search them, and what happens when the project ends?

Most of the time, workshops are recorded on the SI's Teams environment because that's what got set up first. That works fine during the project. It's worth thinking through what happens at handover — when a consultant rotates off, when the project closes, when questions come up six months after go-live.

The underlying point is that the workshops are your business requirements being captured. It's reasonable to make sure your team can still access them down the road, same as your SI.

7. What's the plan when someone rolls off?

On an 18–24 month implementation, it's normal to have three to five consultant changes along the way. People take new roles, get pulled to other clients, or simply move on. Your SI will have seen it a dozen times.

Ask how handoffs usually go. Is there a written protocol? How much overlap is typical between the outgoing and incoming person? What gets formally transferred — and what tends to live in the departing consultant's memory?

This isn't about worst-case scenarios. It's about knowing the pattern. A good SI has a clean answer here because they've lived through it many times. You're just getting ahead of it.

What these questions really do

They aren't about testing your SI. They're about starting the project on the same page.

Every one of these questions opens a conversation that's better to have in month 0 than in month 7. The Blueprint Review timing. The definition of "done." How documentation flows. Where records live. What happens when the team changes. These are the things that, handled well, keep a project healthy — and handled late, become the things that are hard to unwind.

A great SI will appreciate the conversation. Most of them have seen enough projects go sideways to know that an informed customer is an easier project partner, not a harder one. Clear expectations, clear records, clear handoffs — everybody benefits. Your SI included.

Where this leaves you

If you're looking at a D365 implementation, you don't need to become an ERP expert overnight. You just need to know what to ask and what to listen for. The seven questions above cover the areas first-time buyers most often wish they'd thought about earlier.

The work that follows — keeping the whole project aligned as it unfolds — is bigger than any checklist. That's the specific problem Tato helps with: making sure decisions, conversations, and commitments made across the project stay findable and shared, so the picture you and your SI started with is still the picture you both have in month 9.

But that's a conversation for later. For now, print the seven questions. Bring them to your next meeting. You'll be surprised how much clearer things get when everybody's answering the same questions at the same time.

Frequently asked questions

Frequently asked questions

Deliver successful projects with automation

Chat with a member of our team to see how Tato can help you stay in scope, on time, and on budget.

7 questions to ask your SI before you start a D365 implementation | Tato Blog