Your Microsoft Dynamics 365 implementation should have changed the way you do business. Rather, it is six months behind schedule, the budget is four times higher, your staff is burnt out, and the system is not yet actually meeting the needs you have. Sounds like you?
This is not your fault; more importantly, this can be fixed. But only if you don’t treat symptoms and you do the work to solve the real issues.
The majority of ERP failures in Australia aren’t necessarily the fault of the ERP software. They’re confused by scope creep, no one noticed, an implementation partner that over-promised, governance structures that failed under stress, and decision makers that were getting the status quo updates they liked until it all went wrong.
This article is not a list of definitions. It’s a “how-to” rescue plan for Australian business owners and executives facing a problematic Dynamics 365 project and unsure of what to do next.
The Reason Behind Dynamics 365 Implementation Failure
You can’t treat an illness if you don’t know what causes it. The sad reality is that most ERP system failures are not technical, but human and process-related. Microsoft’s Dynamics 365 platform is developed, powerful, and updated frequently. The number one culprit is if one or more of the following have gone wrong:
Mismatching business and implementation partner expectations
During week one, your Dynamics 365 partner listened to initial needs and made it sound like you are the only needs they are trying to meet, but perhaps that wasn’t the case. What is usually the case is that the scope document is written to get a contract, not to secure a client.
Insufficient change management
Some Businesses in Australia often don’t recognise the fact that Dynamics 365 transforms everyday business processes. If you’re not bringing your people along for the ride from the beginning, you’re losing your ROI right now, due to resistance.
No real experience of project governance
Status reporting is not governance, and neither is a monthly steering committee. Real governance implies that someone has authority and is making hard decisions every week on scope, budget, timeline, and trade-offs.
Customisation overload
The biggest mistake made when implementing ERP is, “But we’ve always done it this way!” All customisations you create are technical debt. Too many and you’ve created a weak system that will fail with each Microsoft patch.
Gartner reports that about 55-75% of ERP implementations do not achieve their intended goals. Whether your project has issues isn’t the question; it’s whether you are ready to take steps to prevent things from going downhill.
Steps to Rescue a Failed Dynamics 365 Implementation
Step 1: Stop the bleeding – Triage Plan
In an emergency, the first thing a surgeon does is not operate. They diagnose the issue. The same reasoning would go here. Stop development at the freezing level if it is not critical. If you are in the middle of customisation work that does not have a hard go-live dependency, such as a business rule that is not specific to one of the two release points, suspend the work. Any hours spent on a project where the unknown structure is wasted money.
Have a quick and honest health assessment. This should be completed within 14 days and should contain the answer to four questions:
- What was initially committed (scale, budget, schedule)?
- So what is the "here and now"?
- What is the change and what was the reason for the change?
- What are the 'must-have' business needs that need to be met?
Have an unbiased assessment. When your current Dynamics 365 implementation partner is performing the health check on their own, you will get an incomplete picture of the health check. Introduce an outside Dynamics 365 consultant or technical team to analyse the code base, configuration decisions, and project documentation. This is not something that is well-received by Australian businesses, as it would seem to be a sign that they are failing. It isn’t, it’s due diligence.
Seek input from end users. Not via project managers, not via summarised reports. Have a conversation with the people who will be using the system on a day-to-day basis: “What is broken? What do you find confusing? What can’t you live without?” Implementations get killed when there is a gap between the vision of users and the vision of leadership for a workplace.
Step 2: Re-Baselining – Re-Defining Success
This is the part that most organisations miss, and this is why many “rescue” operations do not work. Re-baselining is not the same as reducing your standards. It’s about creating a new, realistic, agreed-upon definition of what this project is going to deliver, by when, and for how much. If not, you’re only piling on the pressure for an already stressed system.
Start with a prioritised requirements workshop. Bring together your key business stakeholders and your implementation team. For each outstanding requirement, ruthlessly classify it into:
- A must-have for go-live
- Important, but can be delivered post go-live
- Nice to have, put in "deprioritise indefinitely" section and let it go
- No longer relevant
This is an uncomfortable exercise and there will be priorities that people will discuss. Business units will make their needs their gods. That’s why it must have a senior decision-maker on deck who can make the decision.
Start the project schedule from where it is now, and not from the original project plan. An often dangerous mindset in a rescue is to think that what originally could be done can be done with a bit of effort. Create a new timeline from today that takes into account what has actually been done and has realistic buffers, not the 10% contingency that works nicely on a slide deck but never gets you anywhere in real life.
Secure the scope, in writing. All changes that are in scope from here on are in a formal change control process. Every change must be agreed upon by the project manager, client sponsor, and implementation partner, and must be documented and have an impact on time and budget. This sounds bureaucratic; it is, that’s the point.
Renegotiate the contract, if needed. If the original Statement of Work is no longer aligned with what you are looking to get delivered, a commercial reset with your implementation partner may be required. This is a business discussion, not an altercation. If a Dynamics 365 implementation partner is pushing back hard on a commercial reset, they are showing you something about how they work.
Step 3: Governance Reset – Recreating the Governance Framework
If your implementation failed, likely, your governance model failed first. It’s time to reconstruct it.
Form a true steering committee. Meet fortnightly and clearly define terms of reference. Acquire a business sponsor (with budget authority), an IT lead, a business representative from your implementation partner, and a change management lead. This is a governance failure if escalated to the CEO, as the buck stops here.
Designate a project owner from within the organisation. This can’t be a second job. Organisations that attempt an ERP implementation with only 20% of their time simply don’t perform well, as those with a dedicated internal owner who is able to make day-to-day decisions, hold their partner to account and keep business stakeholders involved.
Follow appropriate risk tracking procedures. All project risks need to be recorded; each risk needs to be assigned a level of likelihood, a level of impact, an owner and a mitigation action. Risk registers in SharePoint that are not reviewed are not risk management; it’s box-ticking. Risk discussion and action should be part of your governance reset process.
Set up transparent reporting. The project should be reported to the board or executive team every fortnight with a one-page project status report that should contain: RAG (Red, Amber, Green) status for scope, schedule, budget and risk; a list of decisions that need to be made by the steering committee; and a trend line indicating if the project is improving or deteriorating.
Incomplete Implementation Costs You More Than You Think
Most articles about this issue don’t state explicitly: A failing implementation of Dynamics 365 that gets to go live in a flawed state is often more harmful than a paused implementation that is properly rescued.
- When a go-live fails, workarounds are the norm, spreadsheets fill in the blanks, people lose faith in Dynamics 365, and that goes away almost as fast as the system is fixed.
- Dynamics 365 can be used across finance, supply chain, customer service, and field operations, but only if it is properly set up and trusted for implementation. A go-live that requires workarounds is a go-live that costs you money.
- Australian compliance considerations, such as privacy and security laws, including the Privacy Act 1988 and the Security of Critical Infrastructure Act 2018 (for industries relevant to these laws), must be factored in to any data migration project being undertaken.
- Exposure to compliance risks in a rescue is often an afterthought when trying to solve technical issues; don't do that.
How Can You Decide Whether to Rescue, Restart or Replace?
That is the question that all business owners dread asking, and each answer comes with a high price tag. Now here’s a practical way to decide:
Rescue: If core is established, problems are primarily process/governance, data is adequate, and <60% budget is misused.
Restart (D365): If too many customisations are not properly documented, requirements are not understood, and repair is more expensive than rebuild.
Replace: If your business has grown so much that D365 is no longer viable, your business has changed significantly, and another platform is likely to be more cost-effective over the long term (very rare).
Most businesses reading this won’t be replacing; they’ll be rescuing or restarting within D365. It’s not the platform that’s the issue.
Realistic Timeline For Recovery Evaluation
To give you some real-world perspective on the expectations: A mid-sized Australian business (200-500 employees, mid-complexity implementation) usually takes the following length of time to complete a Dynamics 365 rescue project:
Timeline | Recovery phase |
|---|---|
Week 1-2 | Triage;independent health check;stop non-critical work |
Week 3-4 | Re-baselining workshop, scope agreement, commercial reset (if necessary) |
Week 5-8 | Project schedule is baselined, a new governance structure is put in place, and technical remediation starts |
Week 9-28 | Development and configuration are prioritised, a steering committee is held on a weekly basis, and regular end-user engagement is carried out. |
Week 29-36 | Phased go-live with hypercare support, review post go-live |
It is not something that can be done quickly. If anyone tells you they can fix a failing Dynamics 365 implementation in 6 weeks, they either don’t know what they are doing or they want to cover up any issues and give you a system that will fail again in 12 months.
Final Thought
When your Microsoft Dynamics 365 implementation is in trouble, the last thing you want to do is to wait and see what happens. Each week without a proper rescue plan is a week of burning money, burning people and accruing technical debt.
The companies that do recover from bad ERP implementations have three traits: They come to terms with the actual issues early on; they enlist the right help without an ego trip; and they adopt the ERP discipline of governance right off the bat.
Dynamics 365 is an extremely strong platform. When done properly, it can truly revolutionise the way that an Australian business works. However, it will not save itself. That is up to you. If you are reading articles such as this one, you know that there is a problem that must be addressed. Begin at the triage. All others will follow.
FAQs
Standard challenges are accompanied by definite mitigation plans and open communication. Some warning signs are that the scope is growing without a corresponding increase in budget, milestones are being missed, or the partner is unable to tell you the truth. When your steering committee is hearing good news, but your operational teams are saying chaos, believe the operational teams.
The cost of a Triage, Re-baselining and Governance Reset in a targeted rescue engagement is in the range of $50,000 to $200,000 AUD for a mid-market business. A complete re-implementation will be expensive, but consider the cost of continued operations of a broken system. A health check performed by a third party prior to the path being taken for a rescue is typically $15,000 – $40,000 and is strongly recommended.
Yes, and sometimes it really is the right thing to do. It’s not all bad when you change partners because there are risks to transferring knowledge and commercial disputes; it may be worse if the partner loses your trust. When switching, make sure to back up all project artefacts: code, configuration documentation, and data migration scripts before the beginning of the switch.
Your partner should take advantage of Microsoft’s Free Architectural Advice and Best Practice Support for Microsoft Dynamics 365 implementations through FastTrack. If they are not, you can request access separately with your Microsoft account team.
