70% of ERP projects fail; 25% of them fail catastrophically (L. Clark, The Register 2025). Those figures are alarming enough but it gets worse when you consider the consequences. If we consider a “mild failure” then we could expect to see a two to six month over run which, assuming a cost expenditure of $1m/month then this equates to between $2m and $6m cost over run. I would also advise clients to put aside enough funds for a six month over run- “just in case”. If you consider Birmingham City Council to be at the other end of the spectrum then we are talking about a project that planned to cost £20m actually costing nearer £170m or eight and a half times the original cost (L. Clark, The Register 2025).
The good news is that there a relatively small number of things that can go wrong and all are avoidable. At the heart of the project are four pillars that we need to manage:
- The timeline
- The scope which includes the benefits and requirements catalogue
- The testing of the system to ensure we go-live with quality built in
- The resources involved (project team; end users and suppliers)
Let’s consider the top 3 threats to each in turn:
Timescales
The project plan forecasts when the new system will go-live. At the most granular level, it tells us what tasks need to be accomplished each day and the milestones tell us whether we are on track or not. The go-live itself is the culmination of a large number of interlocking activities that are highly dependent on other activities. Should something change then the dates can move- sometimes for the better but often for the worse.
The top 3 risks to manage against the timeline are:
- Underestimating how long each activity takes. This occurs because people can lack experience of the delivery of such projects and simply get their forecast wrong. In an ERP project, a task that should take two days can often take five to ten days to ensure that everybody who needs to be involved in the task has been consulted. Building the correct review times into such activities is a key mitigation
- The dependencies themselves are key. Often dependencies are missed and key activities or even phases of work such as End User Testing can’t start because a key pre-cursor wasn’t identified. This can lead to unnecessary stand still on a project that can be burning $1m/month
- Change to the scope of the project is inevitable. On an ERP project we might anticipate 40-60 such requests for change. Not all of these result in an increase in cost but they can affect the timeline. It is crucial that any changes to the scope are considered before being agreed to. The good news is that implementing a robust project change management approach is fairly simple to do- but it needs to be done early and everybody involved in the project needs to be onboard and involved with this process
Scope
ERP projects are not cheap and it is likely that a business case was needed to be written and approved to release the investment funds required. The business case will have highlighted the benefits of the project which, hopefully, will include tangible financial savings to the organisation. Alongside the business case will be the need for a clear definition of scope of the project which should include a catalogue of business requirements.
The top 3 risks to manage against the scope are:
- Not realising the benefits. This often occurs because there are gaps in the requirements catalogue and/or that the requirements are not traced back to the benefits. Discussed above is the need to manage change of scope and a key failing of a project during the design or testing phase is to descope a requirement without understand the impact it could have on the benefits that have been signed up to.
- Finance ERP systems are renowned for needing a large number of technical integrations with other systems. These can be “up stream” systems that have inbound interfaces into the ERP system or “down stream” systems that have outbound interfaces from the ERP system. The technical integrations that need a disproportionate amount of attention are the systems that have “two way” integrations. The most common of these is if there a separate Customer Experience System (“CX”) that sits outside of the ERP platform. Such “two way” integrations are not just twice the risk of other “one way” integrations but more likely to be four or eight times more risky.
- Focusing on the technology and not the business process itself. Yes, an ERP project is a huge technical undertaking but not understanding the impact the new system can have on the underlying process can often lead to business disruption after go-live
Quality
Testing the system is key. Technical Interfaces are rigorously tested as part of the System Integration Testing (“SIT”) and User Acceptance Testing (“UAT”) is there to ensure that each business requirement is met at that the system supports the end-to-end business process. The ERP system itself will have been thoroughly tested by the software provider so we have a look a little deeper at where the quality threats come from.
The time 3 risks to manage against the quality of the system are:
- Data Migration. ERP systems have robust workflows to allow data to be created (e.g. setting up a new supplier). There is then a technical term called “referential integrity” to ensure that data from one part of the system corrects correctly to data in another part of the system. An example being when a Purchase Order is created against the supplier that we also set-up in the system. This flow continues with the Goods Receipt Notice; the Purchase Invoices and the payment notification. If all the data was created directly in the ERP system then we would have a much simpler project. However, at any given point, there will be open Purchase Orders; goods in transit; good receipted but not paid for etc etc. In practice, we are required on an ERP project to migrate different types of data from the old system to the new system. We now have the added complexity, for examples, of testing whether we can create a new Purchase Order in the new system linked to a supplier’s details that have been migrated over. It is critical that the migrated data used for UAT is super clean (Circa 95% correct). Getting data migration right is extremely tricky and should have a project work stream all to itself.
- Reporting requirements are not met at go-live. ERP systems come with a large number of reports and dashboards out-of-the box. However, every organisation runs their processes slightly differently. This results in reports often needing to be amended or new ones created. New ERP systems bring new ways of visualising the data and this often reduced the number of reports required. It wouldn’t be unusual to have 600 reports on the old system that become whittled down to just 60 reports on the new system without losing anything. This is quite a transformation and getting this right should have a project work stream all to itself
- Product defects in the cloud based system. ERP systems are Common Off-the-Shelf (“COTS”) software packages. If the software selection has gone according to plan then there should be between 85-90% match of the business requirements with the out-of-the-box system. However, there are no guarantees that the new software will be glitch free. At the time of writing, software providers are busy creating quarterly upgrades with new Artificial Intelligence features. The software doesn’t stand still and there is always a risk that new features dont work for your given use cases or that these new features have had an unintended consequence on existing features. Such issues are rare but do need to be managed with the software supplier to ensure that there are no unnecessary delay. Having a representative of the software provider on the project board is a key mitigation.
Resource
ERP projects not only need an army of people (which is where the costs come from) but also highly skilled people – include existing people in the organisation who have a deep understanding of how the processes work across the organisation.
The time 3 risks to manage against the project resources are:
- Resource availability. This can manifest itself in a number of ways. For example, there maybe a certain skill that is an organisation doesn’t have a lot of (e.g. Sales & Purchase Taxation processing). Assume that there is only one person in the organisation with this skill and they have a busy day job as well as needing to be available for the project. Also, the project Subject Matter Experts (“SMEs”) are fully utilised on the projects and there are pinch points on their time across the project. This is particularly a problem if some activities become delayed and the original resource profile changes. For example, an SME might need to work on the review of training material at the same time as supporting SIT execution and UAT preparation. These activities creates a very timetabled schedule and problems with any of these work streams can knock the timetable out.
- Resistance to change. ERP systems are not replaced very often- as much as once every 20 years. So people across the organisation get very familiar with their ways of working. The pain points that we are trying to get rid of in the old system have simply become accepted workarounds over the years. Managing the business change should have a dedicated project work stream to manage this risk.
- System integrator performance issues. The System Integrator market place is exceptionally mature with each of them having well refined accelerators in order to get the new ERP system delivered as speedily as possible. However, these methodologies are only as good as the people using them. System Integrators need people with a plethora of skills such as ERP technical skills; good at people management; an understanding of the underlying industry sector for the implementation; project management disciplines as well as a working knowledge of the system integrator’s accelerator product. It is key that there is an escalation process in place with the system integrator to ensure everything runs smoothly and that issues are dealt with quickly and effectively.
