Quick Answer:
Many failing implementations don't look like failures from the outside. The system is live, the project has been closed out on paper, and the trouble won’t start rearing its head until months later. Gartner puts the ERP implementation failure rate somewhere around 70% – but failure rarely happens all at once. Catching the warning signs early, like a team quietly running the real numbers in an offline spreadsheet, or a go-live date that keeps slipping, saves you from costly re-implementations later.
Imagine this: You’ve spent tens of thousands, if not hundreds of thousands of dollars on your business’ ERP implementation (hardly unrealistic). It has taken months for your team to plan the deployment, train your staff on what they’ll be doing differently, and set out a reasonable timetable. You finally reach go-live, and everything seems to be going swimmingly.
…except you’re just not seeing the promised productivity benefits. If anything, your margins are down a little. Your schedule is slipping just like it was before you turned to this new platform.
This isn’t a scary story told around a campfire with a flashlight held underneath the chin. This is reality for many businesses, large and small alike, that have assumed adopting Dynamics 365 or some other ERP would instantly solve their woes. This isn’t an unfounded belief; when done well a Dynamics 365 deployment can really be a business game-changer. But when implemented poorly, it can feel like burning money.
So, how can you tell if your Dynamics 365 implementation is failing? And, more importantly, how do you fix it?
What should you be looking out for to see if your Dynamics 365 deployment is on the wrong track? Failure signs might look something like these:
Let’s look at these in more detail. Because we’re primarily a Dynamics 365 shop, we’ll be specifically referring to it – but these problem signs apply equally to whatever ERP your business uses.
If your sales team still keeps their real pipeline in a personal spreadsheet, or finance reconciles in Excel because they don't trust what's in Dynamics 365, that's probably not a training problem, but rather an adoption failure.
This usually means that your system is missing something – a field, a report, or some automation feature that the team built into Excel years ago – and nobody has bothered to implement it.
If your team is regularly using a workaround, make sure to ask them why. Get a sense of what they do all day, and the pain point that the ERP created rather than resolved. With hindsight, it will likely have been something that should have been resolved before implementation, but better fixed late than never.
IES Tip: Ask frontline users (we think the magic number is three, but it can vary based on size and complexity of your business) rather than managers to walk you through their real daily workflow in the system. This will help reconcile gaps between how they actually work and what was written in your original process documentation.
One slip is normal – to paraphrase the famous bumper sticker, stuff happens. But when you wind up pushing the go-live date back not once, not twice, but repeatedly, that’s a sign that the project might have lost its footing – and you may be falling victim to scope creep.
So, what’s the problem here? Is it poor technical knowledge in your team? Actually, probably not – according to industry analysts, inadequate change management is often the culprit, far more than any technical cause.
So, what’s the fix here? Usually, it’s less “we need better project management software” (you don’t want to be getting distracted by wrangling another, different deployment) than it is simply having the discipline of separating what you need from what would be nice to have.
Put in writing a locked "must-have for go-live" list, signed off by whoever owns the budget, and don’t deviate from it. Scope decisions getting made in a quick watercooler chat or a status call are exactly how requirements balloon and timelines slip.
IES Tip: If your go-live date has already slipped twice, stop asking "when can we launch" and start asking "what's changed since the original plan?" This is a great way to find the root cause of the trouble.
When two people pull the same report and get two different numbers, or leadership stops trusting the dashboards to the point they’re seeking out the people keeping the spreadsheet from #1, you don’t have a reporting problem – you have a data integrity problem. This usually traces back to duplicate records, incomplete data migration, or inconsistent data entry that nobody ever went back and cleaned up, whether before go-live or after.
It's tempting to respond by building better dashboards. Resist that instinct until the underlying numbers are actually trustworthy; a nicer-looking report built on bad data is still bad data. It’s just got a bow on it.
Try running an audit against a handful of numbers you already know to be true, e.g., actual revenue, actual headcount, or actual open deals. Trace any discrepancies back to where they entered the system, and fix the issue at its source rather than patching the report.
IES Tip: Pick one metric that different departments already argue about (pipeline value is a common one) and reconcile that first. Whatever process gets everyone to agree on that number will often work for the rest of your data too.
A properly configured Dynamics 365 environment should reduce manual work, not quietly add it back. If your team is exporting data to manipulate it somewhere else and re-importing it, or manually triggering something that was supposed to happen automatically, your Dynamics 365 deployment probably doesn't match how the business actually operates anymore – if it ever did in the first place.
As we mentioned in our IES Tip for #1, have your implementation team walk through a process end to end with the people who actually do it, rather than just checking it against the org chart's idea of how it should work.
If automation exists for a task but isn't being used, find out why. Sometimes it's a permissions issue; sometimes the automation is genuinely broken. Or, more often than you'd think, people simply don't know it's there because they weren’t taught how it could genuinely save them time.
IES Tip: For one normal week, try to have your managers keep a running list of every manual workaround their team mentions in passing. In struggling Dynamics 365 deployments, this is a major sign of trouble – but the good news is that it’s also a ready-made priority list of what to fix.
In Douglas Adams’ classic Hitchhiker’s Guide to the Galaxy sci-fi/comedy novels, the protagonists’ spaceship has the one thing more powerful than a cloaking device: a “somebody else’s problem” device. Any enemy who sees their ship passing through hostile territory? Meh, that’s somebody else’s problem.
Adams was a funny writer, but there’s a grain of truth in the comedy – if everybody thinks that an issue is someone else’s responsibility, problems are left to fester.
A healthy Dynamics 365 deployment has someone in the business whose job it is to understand why the system is configured the way it is, and who gets to make the first call if something looks off. They should know their role, everyone else should know that this is their role and responsibility – so that if there is a problem, it’s not “somebody else’s problem,” it’s “this is Deborah’s problem and I should tell her ASAP.”
Without this person, small issues can quietly compound into bigger ones, and institutional knowledge can walk out the door a little bit at a time with every employee who moves on to a new career elsewhere. You need someone who knows your business processes well and can take the time to own configuration decisions rather than merely living with them.
IES Tip: If you can’t name who this person is – or would be – at your organization, that’s the warning sign itself. Start there before you audit anything else, since an implementation with no owner will keep drifting.
None of these five signs, on their own, means your implementation has failed outright; every live system develops a few rough edges. But when two or three of these show up together, that’s a blinking red warning light, and it means you might want to take a closer look.
The good news is that fixing a struggling implementation almost never means starting over. Most fixes can be far more targeted, like reconfiguring a specific workflow, cleaning up a specific dataset, or closing one adoption gap at a time. Catching these signs early is what keeps a fix small.
In practice, said fix tends to follow the same rough sequence regardless of which sign triggered it:
Audit against reality → Prioritize by business impact → Fix the highest-impact item first → Re-check with frontline users
The audit step is the one businesses skip most often, usually because it feels slower than just diving in and changing settings. We caution you to resist that urge, because a configuration change made before you understand why the current setup exists risks solving the wrong problem, or worse, breaking something that was actually working.
Start with the sign that's causing the most pain today, even if it’s not the easiest one to fix. Also, bring in the frontline users who showed you the problem in the first place to confirm the fix actually landed.
If any of this is starting to sound scarily familiar to you, you don’t have to tackle this alone. IES has experience auditing Dynamics 365 environments that aren’t delivering what they should and helping get them back on track. Reach out today and let’s talk.