Failure is not an option

CxO Guide to successful implementation of Dynamics 365 Finance and SCM

The purpose of the cycle is to describe a typical Microsoft Dynamics 365 Finance and Supply Chain Management (D365 F/SCM) implementation project as a high level guide to success for C level leaders. I am aiming at providing the overview of the project at the level important for C level leaders but with the background. And all that from the perspective of an implementation company.

This article is the 4th in a cycle. You may want to read them before jumping into this one.

First one - “A Chief X Officer guide to ERP implementation”

Second one - “When the cat starts meowing...“

Third one - “Stay relevant!”

Let’s assume that your company started a D365 F/SCM implementation project at the very beginning of the year. This is the one and only assumption that will allow me to describe the typical project step by step or rather month by month to give you an overview of the activities performed during the project, the problems you may encounter and the decisions you should be ready to make.

So let’s get to the business. March has finished which means that your project should be close to the first major milestone. Your analysis phase should be ended and you should see the first products of it. Let’s look into them. Of course the list is just an example and yours may be different due to the chosen implementation method. Nevertheless you should be able to find similar things in your project.

1. FitGap Analysis - this document should give you the simple information about level of fit - meaning the ratio of features of your dynamic 365 implementation covered by standard system vs these that requires modification
2. Architecture of the solution - this document should give you information about how the system will fit your current and to be system landscape in your organization. And it is not only the picture! The right product should contain architectural justifications for every piece of the software that will integrate or influence in either way your Dynamics implementation.
3. AS IS processes - this document usually describes the way how your business works with the current ERP system. We (the implementation companies) are treating this step only as a baseline to understand your current operations and its specific. Current trend is to limit the effort in this area only to snapshot the current state. However in some cases this part of analysis can be really important. Especially if you are running highly sophisticated business processes that are truly unique and no ERP system on the market fits your business well.?
4. TO BE processes - one of the most important documents. The idea of analyzing to-be processes during implementation makes sense only if you run it in context of the system you are implementing. This analysis should give you full understanding of the best functions delivered by the standard system and best practices from your business combined together.
5. Migration Analysis - identification of the data sources, scope of the data, granularity, availability in time and the technology needed to obtain the data and migrate to the new system. You need to understand that your new system will require an enormous amount of the data to be migrated before golive, during golive, during the implementation project. This is pure cost. Postponing this analysis during the project will be painful from a financial perspective but also will bring substantial decision issues later. Do not start the build phase without understanding your migration approach.
6. Integration Analysis - modern ERP systems as Dynamics 365 Finance and SCM are designed to be highly integrated with your environment. Integration points must be reflected in the architecture, you should have high level design of interfaces ready, you should know how many interfaces the new system will require. You should also know what you will need to build interfaces. Some of them will be built as part of your implementation project, but for some you will need to hire third parties or engage your IT team. For all this - you need the plan. And this document should give you this plan.
7. Security considerations - apply ZERO TRUST approach. Engage your Chief Security Officer to review the Security requirements and be pragmatic. You are implementing the system that is the backbone of your business. Think about some offensive scenarios that can happen towards your system. Think about potential security risks, data leak, security breaches. If you find these answers in your analysis documents - you are most probably fine. But again - ZERO TRUST is the right approach here. Oh, have you heard about companies that ended up with frozen production or logistic systems due to some malware infections? Or maybe you heard about organizations that will hash your data and ask you to pay millions for dehashing? This is the right moment to ask these questions.
8. Modification chart - you should understand how big effort in customizing the system to your requirements will be needed. Apply your own judgment - and look for answers for one important question: Is this particular modification relevant? That is the one of the last moments in the project when you can stop irrelevant modifications. What to look for here? There is one simple test you can do: If you see an enormous modification on the chart - ask how many people will require this particular modification in your organization. I bet you will find few of them when somebody is asking for 100man days+ modification to ease daily routine of 1-5 people. If you feel that this is OK - then it is OK. But in most cases it will not be OK.
9. Build backlog - this document should give you two major elements to the puzzle. First is the number of build tasks to be performed during the build phase. Second is the schedule. The art of delivering a successful project is to fit the big number of tasks into fixed time. I am using this document to judge if the implementation company is setting me for failure (by too aggressive planning) or for success (when I see that planning is reasonable). One more important thing here is that you can sense how much effort will be required by your team. Somebody needs to review the deliverables as they start to appear.?
10. Final estimation - most painful moment in the project. This estimation may be different (and usually is) from what you got during the RFP process.The difference could be a show stopper. Or it can be reasonable. If it exceeds your budget - prepare yourself for the closest Steering Committee with questions about what can be taken out from the project and steer the discussion into limiting the build phase into MVP (minimum viable product).
11. Open items register - optional document which will give you the list of items that are open or not analyzed. There will be few of them at least. Make sure you understand the consequences of them.
12. Risk register - this is self explanatory. If your project does not have the process for managing the risks - stop the project. Expect the risk register. The risks will be there. You need to be sure that they are properly managed.

Your implementation project is complex. Even if you are running simple business processes and you have the most stellar implementation partner. My simplest advice here will be to read the book of Mr. Gene Krantz, former Chief Flight Director in NASA - “Failure is not an option”. Despite the story of NASA space programs you will read there how they managed the particular missions with no option for failure. It was simple, they fail - people will die. And the whole world will witness the failure. In your case nobody will die and the world will not see the failure. But failure will cost you real money. Each of the above mentioned deliverables should have an owner in your team. Or owners. They should give you “GO” for engaging the next step of the project. If you see hesitation on getting other signals than “GO” - take your time to understand the reason. Overriding their hesitation with your decision may end in landing the project not exactly where you wanted it to land.

If you are in such a situation, and you are filled with doubts - call me. Together with an experienced team we will guide you back to the right path and make your Dynamics implementation a success together.

To be continued…

Expect more insights on Dynamics 365 F/SCM implementations. I will bring more examples and more relevant to this particular system in further articles. If you are particularly interested in certain areas of the system (like Finance, Supply Chain, Manufacturing, Projects, HR) and challenges there - let me know.?

This text is meant to ease your morning coffee routine and is really a helicopter view of the topic. If you haven’t thought this way about the project you are in, I do encourage you to do so. Mind that this is my own personal view and that I have Microsoft CRISPRed into my DNA. Your view might be different.