Have you ever thought about what actions you need to take to fix a failing Microsoft Dynamics 365 implementation? If not that’s perfectly ok, because this article is specifically for you.
To begin with, D365 software is an extremely useful tool that can double the ability of your organization to optimize your customer relationships. Companies that use a high rate of ERP technology have reported a better run business and have seen increases in their overall outcome metrics.
Microsoft Dynamics 365 is no pushover to say the least, as nearly 22,701 enterprise companies have a subscription to the service and that number is growing. So, when your implementation plan is falling apart, how do you make sure that you get back on the right track and ensure that you can benefit from your Microsoft Dynamics 365 implementation plan? How do you overcome the risks of implementing Microsoft Dynamics 365?
Similar to other projects you start up, it’s important that you find the warning signs of a possible failing project before anything detrimental happens. These are some of the patterns and warning signs we see when helping fix Dynamics 365 implementations or analyzing as independent Dynamics 365 expert witnesses:
We could go on, so these are just a few of the many warning signs that your project may be coming off the rails. The first step is recognizing and accepting that there is a problem. The next steps are to do something about it.
The first things we do when helping a client get its Microsoft Dynamics 365 transformation back on track is to use our technology-agnostic quality assurance and risk assessment methodology to assess the project from all angles. This framework leverages our many lessons from our clients’ Microsoft Dynamics 365 failures, as well as other best practices we have learned through the years.
In most cases, this framework exposes a host of risks and obstacles to change that your Microsoft D365 systems integrator refuses or doesn’t have the objectivity to admit. The key is to analyze the project from a people, process, and technology perspective, plus everything in between.
This video outlines the framework that we typically use to manage successful Microsoft implementations, as well as to expose the risks of those Microsoft Dynamics implementations.
Often times, the above analysis reveals that the best thing would be to pause the project, regroup, and cast a more realistic plan than the one you are currently working from. If you are running at a highly inefficient and bloated run rate in your monthly project costs, you are wasting a lot of time and money for every day that continues down this wrong path.
Be prepared for your systems integrator to push back hard on the idea of calling a timeout. You will most certainly hear how the sky is falling, you are going to lose momentum, “we’re this close to turning the corner,” the team will get staffed on another project, and a host of other excuses. But stick to your guns. This is your project (and your career) at stake. (For more on this, read our recent article about big ERP systems integrators exposed.)
Once you have hit the pause button and the bleeding has temporarily stopped, it is time to revisit your business blueprint. Not your Microsoft design blueprint, but your business process and target operating model blueprint. If you haven’t done this yet, then you should take the time to do it now.
Before continuing, you should have a clearly defined and documented vision for what you want your business processes, target operating model, and organizational design to look like. The good news is that you may have already worked through some of this during your Microsoft Dynamics design workshops, but chances are there are still quite a few gaps.
Once you have analyzed the above, it is important to consolidate the findings and recommendations into a more effective Microsoft transformation plan. It should include a more comprehensive approach that the one your systems integrator initially proposed and managed the project from. It should also include that many missing components of Microsoft’s D365 Sure Step methodology.
It is also important to ensure you have established the right project governance and controls. You don’t want the fox guarding the henhouse, so your systems integrator should not be providing the project governance and risk mitigation for their own project. You should either take on this responsibility internally or enlist the help of an independent third-party such as Third Stage to help.
At the end of the day it’s important for you to realize that this is your project, so it’s time to take back the reins and fix it.
Feel free to contact us with questions or to brainstorm ideas on how to fix your failing Microsoft Dynamics 365 project. I am happy to be an informal and agnostic sounding board as you continue your journey!