Delayed Projects – Time Slip
The main causes of ERP implementation delays are poor planning, weak project management, inadequate data preparation, and lack of user adoption.
We have summerised some of the reasons we frequently see D365 delayed project in the sections below, project delays are not uncommon but continually delaying one means you need to look rather closely at why because delays burn through budget and user goodwill quite rapidly.
Unclear requirements & scope creep
We mention this several times but once again its worth emphasising how important it is to have a thorough understanding of your requirements.
Many ERP projects stutter and fall behind simply because business requirements aren’t fully defined at the start of the project. This leads to scope creep, where new features or modules are added mid-project, extending timelines, altering plans and potentially having to rework areas that had previously been considered complete. This is one of the main reasons you see a D365 delayed project – put the time in to get all the requirements detailed is our mantra.
Poor D365 project leadership & governance
Without strong executive sponsorship and clear accountability, you can allow your D365 implementation to lose direction. Weak leadership often results in missed deadlines and conflicting priorities and results in a D365 delayed project.
We have frequently seen people transitioning into D365 project manager roles, if unfamiliar with ERP and the sequence in which modules logically need to be implemented mistakes will occur, a classic example is starting a workstream activity too early. such as data migration and mapping fields onto D365. Until a workstream have conducted some build activity and playback there’s a risk that data gets mapped to the wrong areas. Strong experienced D365 project management know what is a concurrent and what is a consecutive activity and this stops consultants falling over each other, burning cash and missing deadlines.
Inaccurate or incomplete data migration
The section above touched on the subject of data migration with the example of trying to map data into D365 at too early a stage. This does not mean data migration does not start as soon as the project starts, in fact experienced users will often start the process of preparation as soon as they learn an ERP software selection process is on the cards because cleansed data is key and inevitably older ERP systems will have a build up of inaccurate information.
Data cleansing and migration are often underestimated. Errors, duplicates, or missing records can stall mapping, testing and go-live phases.
Subject to data volumes data staging between your legacy software and Dynamics 365 environment may be required to ensure a swift transition from old to new during the go-live cutover phase. Building resilience into these tools helps ensure a smooth cutover but will take longer than simply mapping one system to the other.
Unrealistic D365 timelines
Companies sometimes set aggressive deadlines to minimize disruption, but ERP implementations are complex, trying to fit an implementation into a time period without any detailed plan is unlikely to work if the timeline is too aggressive.
We understand businesses may have some strategic reasoning behind dictating such timelines but fundamentally you either make a choice to plan appropriately or take a very minimal deployment approach which carries its own risks.
When timelines are tight inexperienced D365 project managers may drop cycles of testing this leads to late discovery of issues, forcing rework and delaying rollout and rarely n our 20 years plus history have we seen a satisfactory outcome when this approach is used and it inevitably ends up costing more in the long run.
Employee resistance & lack of training
If end-users aren’t properly trained or engaged, adoption slows down. Resistance to change can cause delays in process alignment and system acceptance.
Some of the points made in this section themselves lead to user resistance particularly when users are continually pressured to deliver when other factors are impinging on their been able to do this successfully – nothing worse as a user been told to try fit everything into an unrealistic timeline, succeed and then have another workstream like Data Migration fail to meet the same deadline causing a project reset and try again.
Everything is connected in a D365 ERP rollout plan, one critical path item slips and it has the potential to more the plan to the right – hence we keep banging the project management and planning drum!
Budget constraints
Underfunded projects often cut corners on resources, consultants, or training, which later causes delays when problems surface.
A well structured waterfall style plan takes time to develop but will if done properly, identify what can be delivered within budget. If some requirements cannot be met they should be taken out of the plan, simply attempting to do everything with a ‘lets see what happens’ approach will undoubtedly result in disappointment.
At AX Software we can design a D365 delivery plan around a limited budget, using a minimum viable product MVP is a methodology that does work however in such circumstances you have to communicate to all involved to address issues of perceived under achievement, managing user expectations is a big part pf D365 programme management.