Five Examples of D365 F&O Implementation Challenges
Why your IMPLEMENTATION is out of time and over budget
Introduction
We all know that 70% of ERP implementations are a failure, a vague statistic that means absolutely nothing. Yes, it is true, ERP implementations have a certain tendency of ending up over time and over budget, but why? What are the real causes? How to identify them before they unfold, and how to avoid them?
This article summarises a decade of real hands-on experience. If you have no time to read further, let this be your main takeaway: prevention is your best friend. And to prevent effectively, you need two things:
- Understand the root cause of the problem, and:
- Be aware of the chain of events that cause the problem to manifest.
If you do have time to read further, here are the top five challenges that will cause your D365 F&O implementation to end up out of time and over budget, and ultimately become a trainwreck.
Challenge 1. Unrealistic expectations
D365 F&O implementations are very expensive enterprises for a business, often part of an even bigger enterprise (e.g. a digital transformation). This often causes bias in expecting an immediate and visible return on the investment, especially from the board or C-suite.
The most dangerous case is the unhealthy expectation of quick results: some stakeholders hold the unspoken assumption that the new ERP will replace a 10+ year-old customised legacy system in a few months and outperform it spectacularly from day one. Spoiler alert: it’s not going to happen.
So why can’t we go faster and optimise times? Two reasons. One, there are technical limitations to how much one can compress or run activities in parallel during the full cycle of an ERP implementation. Two, software implementation projects have a negative correlation between development time and deliverables quality. In other words, pressure on deadlines causes activities to be executed sloppily or skipped altogether. Since an ERP is a set of interconnected modules, lack of care in one area is likely to cause issues in other areas too.
Another common assumption is that the effort terminates as soon as D365 F&O goes live, with the system becoming sort of self-sustaining after that moment. This is untrue and a dangerous belief. Hypercare (the period immediately after go-live) is one of the most critical phases of the project. To be honest, the danger is not over until all periodic functions have been executed at least once, which could mean reaching as far as the one-year anniversary from go-live.
Plus, a new set of challenges begins when the system responsibility shifts from the implementation team (often external) to the support team (often internal). These two teams have different skills that cannot be acquired nor transferred quickly; yet many organisations still expect employees to become immediately autonomous with the new system without spending any time to train people and document procedures.
So how do unrealistic expectations actually manifest? Let’s have a look at how things could play out in a realistic scenario.
Worst case example
A complex interface between D365 F&O and a key supplier is estimated to be designed, built, and delivered in two weeks. The timeline is insufficient to implement proper stock availability checks and handle purchase order changes, so they are skipped. For the same reason, the specs are rough and no training material is created. The interface is delivered half-baked and is unfit for purpose.
When the problem is finally escalated to be addressed, the implementation team is long gone and no documentation is available to understand how the interface actually works.
End users start to use Excel to track the stock available at the supplier, which is communicated via a chaotic exchange of emails. The procurement team designs a colour-coded system to flag purchase orders to monitor. More data and logic start thriving outside of the ERP system, reducing accuracy and efficiency. The dashboard for the head of procurement shows unreliable KPIs, skewing key decisions.
Sounds familiar? We know how to help.
How to avoid it
Business leaders should not make assumptions if they have little to no experience of ERP implementations. They should also not listen to those who are equally inexperienced or have ulterior motives. Good advice is:
- Take pre-sales estimates for what they are, estimates, and rely on an independent and competent third-party to stress-test the implementation plan and the timeline.
- Ensure that competent resources are allocated (ideally full-time) to the project from its beginning, and that their time is safeguarded throughout the project duration.
- If time gets tight, do not force deadlines; instead, identify the risk of leaving features out of scope and do so if possible, to avoid jeopardising the project timeline.
Challenge 2. Unstable business processes
Before we dive into the next challenge, let’s review the definition of ERP. An ERP system is an IT business application whose purpose is to improve and facilitate the way a company executes and manages its business operations. This is possible thanks to a common platform used by many functional areas of the organisation at once, which improves circulation and accuracy of information thanks to a central database.
When implemented and leveraged properly, an ERP like D365 F&O enhances the execution of complex business tasks. However, what it doesn’t do is solving problems outside of the IT dimension, such as wacky business practices or weak business processes.
Many companies measure an ERP implementation’s return on investment with KPIs such as reduced operating costs, saved labour, or increased operational efficiency. But they fail to understand that an IT system can only be as effective as the underlying business processes it is expected to support.
If a business process is unclear, unstable, has a high variance of execution, or it depends more on senior employees’ experience and judgement than repeatable and formalised business practices, hardly any IT tool (or any other external influence, for that matter) will make a significant difference in improving it.
D365 F&O itself will not increase company revenue, will not reduce exceptions, nor it will raise production throughput. These are not IT issues, and an IT tool won’t fix them.
Ok, but why would a business process become unclear or unstable? Simply put, when companies change and grow based on unplanned external factors rather than a plan, the natural tendency is entropy. Leave it unchecked long enough, and you end up with obsolete procedures, temporary-now-permanent exceptions, and duplicated efforts because data are not accurate.
Then, when the ERP implementation starts, key users struggle to describe all and every use case organically, or even justify why something is done in a certain way. If the analysis phase is not carried out thoroughly, assumptions are made on how things work, which in turn causes the system to operate on fragile foundations.
So what does this mean in practice?
Worst case example
The production planning process of a company has a high variance based on a long list of factors and exceptions, including cases that are handled manually. During the D365 F&O implementation no effort is spent to streamline it, rather the goal becomes to have it all automated in the system.
Configuration starts from a basic scenario, then more and more parameters are changed to include all cases as they are spotted. Exceptions are still not handled, so custom features are built in an attempt to automate everything.
Complexity increases, so the IT manager makes the decision of building a prototype to be improved in iterations. Now time has become scarce, so testing and training are minimised to avoid delays.
After go-live, end users struggle to use the custom feature proficiently and end up reverting to a manual process to chase control over the output. They start blaming the system for the lack of improvement.
Efficiency is further reduced by discovering yet more use cases, which trigger the need for further customisations. Eventually, the production planning solution is a monster of complexity, that shows virtually no benefit and make users regret the legacy situation.
Sounds familiar? We know how to help.
How to avoid it
Business leaders should spend plenty of time to review their internal processes before starting the D365 F&O implementation. They should not assume that IT specialists are also business specialists, because often they are not. Here is more advice:
- Separate the solution at software architecture level (ERP and IT applications landscape) from the solution at business process level, ensuring that the latter is stable and complete by itself.
- Allocate time to analyse and map current and future business processes from start to end, for each relevant functional stream, before starting to build the system.
- Review each process to see if they can be simplified, by removing steps and reducing anomalies, to build a system that fulfils core needs and not a myriad of use cases that have low chance of occurring.
Challenge 3. Undiscovered requirements
While core business processes are common to every company, different industries have different practices, and every company is unique in their very own way of doing business. Similarly, every ERP application offers a common set of modules (think general ledger or warehouse management), but every module has a range of different functionalities, which may or may not be relevant to the specific use case that the system is expected to support.
It’s naïve to assume that there is a “one and only”, simple and linear path to a D365 F&O implementation. Company processes are similar, the application is the same, yet every situation is different.
Why this preamble? Because whether an ERP feature is suitable for a company depends on stakeholder needs and expected realisable benefits. Which brings us to requirements gathering: it’s the activity of identifying, understanding, and formalising stakeholders needs with respect to a specific business process or scenario. This, in turns, drives the expected system behaviour, with predictable outputs under well-defined conditions.
The problem is that requirements often don’t present themselves in an oven-ready format: ask the average stakeholder what they want and you’ll end up with a superficial, incomplete, and sometimes even chaotic picture. It’s not their fault – stakeholders are usually influenced or limited by how the company operates at present. They may not have visibility of what happens in other departments, and are unlikely to know what the new ERP can offer. Last but not least, it might not be their responsibility to assess the second-order consequences of their needs or the impact on third-parties (hint: that’s what a functional consultant is for).
Fail to ask the right questions, fail to unearth the real needs, fail to stress-test by asking “what if”, and you end up with poor functional specifications. The same happens if cross-functional requirements are not double checked by all departments, or if they are just collected as a long list of items as opposed to a coherent bigger picture (another hint: that’s what a solution architect is for).
A side note to this exercise: it is possible to carry out the entire requirements gathering phase without mentioning the word ERP once. Or any IT application, for that matter. Requirements are, first and foremost, business needs. It is worth defining them internally, rather than bringing in a whole team of ERP specialists and see the implementation budget halved before any system configuration takes place. That, or ending up with poor specifications as already mentioned.
One last important point: not all requirements will be in scope, but it is way better to leave them out with an intentional decision, than as oversights due to lack of meticulousness. Misunderstanding stakeholder needs and neglecting business processes means unidentified use cases. And those will always come back to bite you, often after you have designed and built a fragile solution at ERP level. At that point, everybody scrambles to quickly modify the solution to handle them. Naturally, the closer the implementation is to completion, the higher the cost of doing so.
Let’s now consider a realistic situation to see the impact of undiscovered requirements.
Worst case example
The new sales order process is built to simplify the activity of sales agents, who can place an order only if there is stock in the warehouse, to allow immediate fulfilment.
Later, during the training phase, the accounts payable team highlights that they need to flag orders for customers who are bad creditors, but only when specific conditions are met.
This requirement was not identified earlier. Implementing it now would mean delaying the go-live, so the IT team rejects it. Finance users are not happy with the matter and escalate it to the finance director, who uses her influence to ensure the request is implemented anyway.
Two IT consultants are assigned to it, but the timeline is tight and puts pressure on them, so they neglect their original tasks and cause stress to the whole project team.
The feature is eventually delivered, but the finance department is startled: they are wary about the new system’s ability to cope with their business needs and they now distrust the IT team. Their resistance is not open but passive, so adoption of new features is slower due to extra scrutiny. Overall, the benefits promised with D365 F&O take way longer to appear.
Sounds familiar? We know how to help.
How to avoid it
Business leaders should not assume that a requirement is valid just because an influential stakeholder said so. A thorough requirements gathering phase saves pain down the line. Here’s how to do it:
- For every set of requirements, dig deeper to find out the real business needs. Explore use cases thoroughly: do not neglect exceptions and carefully evaluate all possible implications.
- Stress-test proposed solutions by mapping end-to-end process and data flows, for main branches and for deviations if any.
- Design the new solution on paper and get it review by all stakeholders, and make sure to do this before starting the system build phase.
Challenge 4. Unsound sequence of activities
Implementing an ERP system is a complex project, no doubt about that. Your average implementation is divided into phases, and if it is a program it will have separate projects according to countries or companies in the group. In special cases, the go-live may be staggered, with only some functional areas (e.g. finance or sales) using D365 F&O at the beginning, before the system is rolled out to the entire company.
Decisions about the implementation sequence are usually taken to reduce complexity or disruption to business operations, and sometimes to accommodate specific needs (think of a private equity-backed acquisition).
However, these decisions sometimes neglect IT best practices and ignore the natural dependencies of an ERP implementation. A simplified example to explain: you can’t use the system if real data are not in it first, can you?
They key concept here is that an ERP like D365 F&O is a collection of master data and functionalities that are built on top of each other, so there are dependencies to respect. Proper ERPs were born when operational capabilities (manufacturing) of MRP applications were combined with back-office functionalities (accounting), eventually extending to integrate every company function. This means that the application, and therefore its implementation, cannot occur in isolation for a single functional area of the company.
The board wanting a new application in place to make the auditors happy is also not a good reason to think about company functions in isolation. The assessment for a new ERP must start from the financial model, followed by the core business operations, and extended to ancillary processes.
Focus on selective or advanced functionalities, without covering the basics first, and you’ll discover missing key parts later, or experience instability due to weak foundations, or both. It goes without saying that attempting to retroactively fix the situation will cause costs to skyrocket.
Another common issue is failing to adopt a clear methodology, and sticking to it throughout the implementation. Leaving aside the politicised battle between agile and waterfall, let’s consider less ideological cases. Think of a poorly drafted project plan, which ignores the correct steps for a D365 F&O implementation. Or a replacement of project sponsors or key decision makers, a reallocation of budget within the company, or a strategy shift decided by the board.
Some of these events are unavoidable or unforeseeable, but that is not a good reason to neglect risk mitigation. Budgeting an ERP implementation with a tight timeline in mind is a safe recipe for delay or disaster. And assuming that changes in goal and scope can be executed immediately by a team of dozens of people, without factoring in inertia, is delusional.
Lack of consistency and poor governance cause wasted time in useless tasks, repeated focus on low value-added activities, rework of previous phases, and poor people coordination. Enough of those, and your go-live may be jeopardised.
Let’s see it in practice with a realistic case.
Worst case example
A sales-oriented company decides to implement the new ERP starting from their CRM system, because that’s where the core customer data are kept.
A strong focus is put on the sales stream, with its processes and CRM interfaces, ignoring the financial and operational setup in the ERP.
Eventually the project reaches a point in which the lack of basic data and configuration in the ERP causes a key milestone to be missed, forcing a board meeting to discuss the situation.
The project sponsor is replaced, and the new one demands a prototype of the system to understand the implementation status. Key decisions are still outstanding and no data migration has been done, so the implementation team uses sample data and makes assumption on the functionalities required to build the prototype.
When it’s ready, the project is severely behind schedule. Worse, only a small part of the prototype fits the deliverables criteria. Due to the repeated lack of progress, the CFO cuts the funds and the project is put on hold for the foreseeable future.
Sounds familiar? We know how to help.
How to avoid it
Business leaders must understand what an ERP implementation entails and how it works. It is perfectly normal not to know it, but it is unreasonable to think one knows better than a whole industry predicated on it. Therefore:
- Ensure a robust and sensible project plan is in place at the beginning of the project and it is reviewed regularly, monitoring actual progress carefully.
- Stick to a tested implementation methodology and double check dependencies between phases before allocating time and resources to them.
- Protect the project from sudden changes of direction, keeping stakeholders informed of the risks and consequences of doing so; if everything else fails, assume the worse and be ready to mitigate.
Challenge 5. Unchecked scope
What is a project? Literature tells us that it is a temporary and carefully planned endeavour aimed to deliver a specific outcome, subject to constraints such as time or cost. An ERP implementation fulfils this definition perfectly and is therefore a project. But with a peculiarity: it is a collaborative effort between the customer and the supplier.
This sometimes causes issues regarding the definition of the outcome. We already said that a D365 F&O implementation does not follow a ready-made path, and if we also consider conflicting interests from different stakeholders, the outcome may very well change before the project has been completed.
The most common change of outcome is an increase in scope, especially when compared to the original plan. Adopting an ERP is a decision made by the C-suite and the board because it fits a broader company strategy, but middle managers and end users see the introduction of the new system very differently.
They may perceive a loss of control over their work, a reduction in functionalities (especially if available in the legacy application), or extra manual labour to run recurring tasks. Lack of training can also make things worse. When all of this happens, stakeholders will demand changes to adapt the new system to their needs, rather than vice versa.
If there is no filter in place, all requests are granted without consideration, so the project scope inflates and brings with it additional workload and complexity. Trying to do everything and rejecting anything less than a perfect system will eventually put at risk the whole implementation.
But hold on, what causes these requests for extra features in the first place? The main reason is lack of understanding or acceptance that not all benefits of a system like D365 F&O will be realised on day one. Companies tend to use an ERP for many years (sometimes even decades), so obviously things will evolve and new features will be introduced as time passes.
Consequently, it is necessary to have an understanding that some features will be delivered before of go-live, but others will be postponed to phase two. Deciding what makes the cut and what does not is key.
However, it is very, very unlikely that any decision on this will satisfy all parties. When it comes to project scope, further tension usually emerges as the go-live gets closer and the stakes get higher.
Requests for change are most disruptive when no precise statement of work exists, when stakeholders are not aligned, when there is no formal process to review change requests, and in general at later stages of the implementation. As a consequence, discussions heat up, rework increases, and milestones seem to slip out of reach.
Let’s see this in a realistic scenario, where scope is not kept under control.
Worst case example
A company decides to keep their production scheduling system, to be used in parallel with the accounting functionalities of D365 F&O.
During the analysis phase, all production use cases are identified, but to ensure that the overall timeline is respected, the integration scope is limited to the most common use cases for go-live, leaving any exceptions to be sorted manually.
When the interface is tested, the production manager realises how much extra labour is required, so he demands that all use cases are included. Leveraging the lack of any formal documentation to define the scope, he gets all change requests approved and the interface is redesigned to include extra new use cases.
Following this episode, all other department managers start demanding additional functionalities. They all insist that all these features are essential for go-live, so they encounter virtually no opposition and all change requests are approved.
This happens in several waves, to a point where the initial solution design is now unfit for purpose. The UAT phase fails on multiple fronts, forcing the governance team to postpone the go-live.
Sounds familiar? We know how to help.
How to avoid it
Business leaders should keep a tight grip on the project scope, communicating clearly and from the beginning to key stakeholders what is in scope and what is not. To handle unavoidable scope creeps:
- Involve all parties early in the design and ensure that key stakeholders are comfortable with the proposed solution, to reduce the risk of change of mind later.
- Put in place a formal process to formalise, submit, consider, and approve or reject any change request presented by stakeholders.
- Do not assume that design changes are the only acceptable solutions; instead explore manual workarounds and alternatives, even at the cost of causing some dissatisfaction to end users.
Conclusion
This long article describes the top five challenges that cause an ERP implementation to run out of time and go over budget. Expectations, business processes, requirements, sequence of activities, and scope all play an important role in a D365 F&O implementation.
If one thing is clear from the worst case examples, is that as a business leader awareness and prevention are your best weapons. Once the events that lead to these five challenges start appearing, it becomes more and more difficult to fix them.
So be ready and prepared from the start – hopefully now you know how. And if you are still in doubt, reach out to us and we will be thrilled to help you.
