What a Consulting-Ready Organization Looks Like and Why Most Aren't

Most organizations think they're ready for a consulting engagement. They're not and it costs them. Here's what separates the projects that deliver from the ones that don't.

A client called us about eight months into what should have been a six-month D365 Finance rollout. Their CFO, the person who scoped the entire engagement, signed off on the roadmap, and was the most aligned executive we'd worked with in years… had left in month three.

The person who stepped in wasn't opposed to the project. But she hadn't been in the room when decisions were made, so the answers required going back through documentation, re-explaining logic, and in a few places, reopening scope that had already been built into configuration. That engagement ended up costing about 60% more than the original estimate. Not because D365 failed. Not because our team missed anything. Because the person who defined what "done" looked like wasn't there to hold the line.

We've watched this happen with enough engagements to recognize the pattern, that we started calling it the continuity tax.  

After enough of these engagements, a pattern gets hard to ignore. The budget doesn't predict the outcome. The software doesn't either. What predicts it is whether the right people showed up prepared genuinely open to being challenged, aligned on what they were really building, and still in the room when it mattered most.

Research from Godlan's 2025 analysis puts the ERP failure rate between 68–70% across industries. When you look at what's driving those numbers, it’s not only vendors and technology that can be root causes it can also be leadership commitment, undefined scope, mid-project stakeholder changes, and similar issues related to not being “ready for consulting.”

What "Consulting-Ready" Actually Means

Most organizations believe they're ready to work with a consultant because they have a budget approved and a rough idea of what they want..  

Real readiness comes down to three things. Openness-meaning both the client and the consultant showing up without defensiveness, willing to question assumptions including their own, and genuinely invested in building something better than either party could have designed alone. Clarity-meaning a shared picture of what you're building, what it costs, and what success looks like after go-live. And Continuity-meaning the same people who scoped the project are still present and engaged when that scope becomes a live system. Those three things sound obvious. They're not common.

Consulting-ready organizations aren't always the most experienced or the best-funded. Some of the most expensive engagements we've run were with organizations that had been through multiple ERP implementations before. The prior experience hadn't made them humble. If anything, it had made them more certain they already knew the answers. What separates the engagements that deliver from the ones that don't usually have anything to do with the software and everything to do with how the client shows up.

The Three Pillars of a Consulting-Ready Organization

Openness

What openness looks like in practice is both parties' client and consultant, walking in without a fixed answer that is already decided. That's harder than it sounds on either side of the table.

We worked with a distribution company, one of the harder engagements in recent memory where the VP of Operations had spent fifteen years building the process we were being asked to replace. Brilliant operator. Deep knowledge of how their business ran. And every single time our consultants recommended a configuration that departed from how things had always been done; it became a negotiation. Then a standoff. Then an escalation to leadership that had already signed off on the approach.

The work that should have taken four months took eight. Not because new features were added. Because both sides stopped questioning and started defending. The client defended their existing process. We defended our configuration. Nobody stopped to ask whether there was a third option neither party had considered yet. That's what openness is supposed to prevent.

Research from Pemeco puts leadership commitment at the top of the ERP failure list, above data quality, above integration complexity, and above implementation partner choice.

That tracks what we've seen. But openness isn't just a client responsibility. The consulting team has to bring it too. The instinct to defend what you've built whether you're a client protecting a fifteen-year process or a consultant defending a configuration you spent weeks on, is real on both sides of the table. Openness is what keeps that instinct from running the project.

Intelligence and openness aren't the same thing. Some of the sharpest operators we've worked with have struggled here not because they weren't capable, but because of expertise and the willingness to be wrong to pull in opposite directions. The same is true for consultants. The engagements that go sideways aren't always the ones where one party was difficult. Sometimes they're the ones where both parties were too certain, too early.

Clarity

Two ways to come into a consulting engagement with good clarity, and both are fine.

One: you've done the upfront work. You have documented current-state processes, a defined scope, and a roadmap that can answer the four questions that is what we are building, when, at what investment, and what does success looks like after go-live. These engagements move faster and cost less. Not because the work is simpler, but because decision-making is faster. There's a map and everyone is reading the same one.

Two: you know you don't have clarity yet, and you're genuinely open to building it with your consultants. That's also fine. Roadmap work is real work, and some of the cleanest implementations we've run started with a client who said, "we know we need this; we just don't know what it looks like yet" and meant it.

The third option: the one that costs money, is believing you know what you need, but refusing to have that belief tested. We had a mid-market manufacturer come in with a very detailed, very confident picture of what their D365 implementation should look like. Specific. Documented. Wrong in about four critical ways that only surfaced six weeks into configuration during a process validation session.

The issue wasn't the vision itself. It was that nobody on their side had ever sat with the question "what if we're wrong about this." Requirements that can't be questioned become requirements that get built wrong.

Panorama Consulting's work on ERP readiness shows this consistently it's not vague requirements that cause the most damage. It's rigid ones. The ones that felt like certainty at the start of the project became expensive rework by the middle of it.

Continuity

This is the one that gets underestimated most often, and in our experience, does the most damage when it goes wrong.

Continuity means the people who defined the requirements and agreed to the roadmap are still present actively engaged, with decision-making authority when those requirements and that roadmap are being turned into a live system. It sounds like a low bar. It is not a low bar.

Here's what a continuity breakdown looks like in practice: a senior leader deprioritizes the project because something else became urgent. Their backup wasn't in the room when the scope was defined. They ask reasonable questions. Those questions reopen to decisions. The consultants who have been building against agreed requirements have to pause and re-explain work that's already done. Some of it gets relitigated. Some of it gets reworked. The team loses momentum and confidence in the direction starts to wobble.

Governance frameworks for consulting work are clear on this: decision rights and stakeholder tenure are primary predictors of whether an engagement delivers value. If the people who made the decisions aren't there to hold them, the decisions don't hold either.

"We now ask every prospective client directly: will the people who scope this project still be accountable for it at go-live? The answer tells us more about what the engagement will cost than any other question we ask."

The Consulting Tax: What Unreadiness Actually Costs

Earlier we discussed the Continuity Tax – that’s just one of many kinds of “Consulting Taxes” that we see that leads to major cost overruns.

ERP Software Blog's analysis of D365 failure points puts budget overruns at 55%+ across implementations. The causes aren't technical. They map almost exactly to the three pillars, leadership that undermined the process, scope that was never really defined, and people who were there at the start and gone by the middle.

The question isn't whether you can afford a consultant. It's whether you're ready for one. Those are different questions with different answers.

Are You Actually Ready? An Honest Self-Assessment

We run through some versions of this before every engagement starts. If you're evaluating a D365 or ERP project, it's worth doing the same honestly, not optimistically.

If something in that list produced a real hesitation, not a "we’ll figure it out," but a genuine pause, that’s the thing to address before the engagement starts, not after.

What DCG Does Differently

We handle both strategy and execution, which puts us in a different position than firms that only do one. But we've learned the hard way that doing both well requires being honest about which one a client really needs before any work begins.

Some clients come in ready to build. Others need the roadmap first. A smaller number need someone to ask whether they should even be doing this right now, given where the organization is. We've had that conversation. It's uncomfortable when someone has already invested in a vendor selection process and built out a business case. It's still the right conversation to have.

Our methodology isn't mysterious. It starts in the same place every time with an honest assessment of where the client stands against the three pillars, before a single line of configuration gets written.

Explore:  D365 Implementation Services · Early Warning Signs Your ERP Is in Trouble · Stalled Project Forensics Checklist

The Bottom Line

The organizations that come out of ERP implementations having delivered what was promised aren't the ones with the biggest budgets or the most experienced teams. They're the ones that showed up ready, ready to be challenged with assumptions they'd carried for years, ready with a map that people agreed on, ready to keep the same people in the room from month one to go-live.

If something in this felt uncomfortably familiar to the leader who can't let go of how things have always been done, the scope document everyone knows is incomplete, but nobody wants to reopen, the project manager who's already been half-reassigned to something else that discomfort is information. Don't start the engagement before you address it. The tax compounds. And it's substantially cheaper to prevent in month zero than it is to fix in month seven.