The purchase and deployment of ERP (Enterprise Resource Planning) software can be some of the most expensive, yet most important initiatives that a company can execute. I have had the opportunity to witness and be a part of a number of successful large IT projects in my career, but I will also admit that I have witnessed a couple that weren’t so successful. Almost all of the points below can affect any software project, but they certainly factor into the case of ERP, including managing project pace.
Below are eight of the major reasons that I have seen ERP projects fail, in no particular order.
1. Lack of Governance
While I don’t have hard and fast numbers, my experience with the output from ERP sniffer programs from the experts that run them is that about 60% of customizations are not used. Project cost and time to deliver will balloon if significant numbers of customizations or extensions are proposed. Seek solutions that are adaptive and flexible that account for your processes within the standard as much as possible. Have your users learn the software you are considering as deeply as possible, understand your own processes, and be as forthright with the implementation consultants as possible to surface opportunities to use the standard software. Ultimately, if some change is to be considered, the need for governance is self-evident. Keep it simple, create a forum with an executive sponsor, where customizations can be looked at for their return on investment. During the project phase, this will have to occur with frequency as things can move fast, and it is usually not possible to wait month to month to review proposed changes. It needs to be determined if it is a hard save or soft save. Ask the originator of the customization to define the business benefit for the change. Unfortunately, I have witnessed many companies that use little or no governance on even their individual end users requesting customizations. Even asking simple questions to the requestor will get some customizations to filter out, because once the questions are asked, the requestor often goes back and will invest more thought in what they were asking for.
2. Lack of Clean Data
Unless you plan on starting from scratch with data, it is highly likely that you will want to move data from the legacy system to the new system. Data must be cleansed from non-conforming formats or characters, and moved into constructs that will meet new transformational requirements from the business and the new system. This data conversion activity requires adherence to standards, effort from the business to own the cleansing of their data, and the use of tools to ideally speed up the process and provide rails for the transformed data to now flow into the new system. Test loads can illuminate issues – make time for those, and make sure that near the go live day or days that enough resources are available to ensure the final touches on the data.
3. Lack of Resource Plan
While this is foundational project management, I have unfortunately seen examples where this artifact is absent and leads to detrimental effects within project delivery. The concept is fairly simple. Take a spreadsheet or some similar tool, list every person that has a task or tasks critical to the successful deployment of the software, and then in your columns to the right, list out where that person will be every day from the project start until the end of hypercare. Fill in where that person will be – onsite or offsite, PTO, etc. This is vital, especially in global projects where there are individual holidays not common to all regions, or cultural expectations about work hours. Too many times, a key person will go on vacation or be off site when there are critical deliverables, and a resource plan, overlaid with the Gantt chart could easily reveal these conflicts.
4. Lack of Authority to Effect Milestones
Here I am talking about “The Hammer.” The larger companies get the more potential variables and obstacles there are that could jeopardize a successful go-live. Some of these are simply people issues – there is a plant manager that doesn’t want the new software at a particular time, so they drag their feet. There is a Finance Director who wants to do something different, so they throw up roadblocks or drag their feet. I have witnessed, even at the largest companies in the world, that sometimes people need a tap on the shoulder or a phone call from “The Hammer” to encourage them to stay on plan. What is “The Hammer”? It is someone that is either the senior leader of the business unit funding the project, or one of their direct reports (usually needs to be Ops or Finance) that is onboard with and committed to the objectives of the project. IT is not the hammer. A steering committee can solve a lot of issues, but they typically are not going to get into tactical issues, even if they could cause strategic problems. Yes, I’m sure I will get comments about how people witnessed their companies band together and march in the same direction all at once with complete harmony. This message isn’t for you.
5. Lack of Testing
Even in products with the same design that are manufactured thousands of times, there are still quality checks, even if statistical in nature, on those products. Software development should be no different. Make sure you run testing on your environment. Even if not to reveal some sort of defect, but to provide another exposure opportunity to a user on how the system will work in the new paradigm. If you customize software, or create scripts or low code / no code extensions or apps, or whatever it may be, rigorous testing can save you time, money, and heartache down the line. With testing comes a reduction of risk and a protection of the investment. For every customization or app, I would allocate a percentage to the funding and staffing of testing. Don’t cut corners here, even though the temptation might be there.
6. Failure to Properly Plan for Spend
Changing horses is expensive. This is a simple reality that many customers don’t fully realize in the earlier stages of their RFP to implement a new solution. If I am building a custom house, I still need to live somewhere while I am building the new house. As is the case of new cloud software, there might be a level of excitement about a new direction, or possibly a new executive staff that wants to bring in a new system. What many companies fail to do early in their planning is to account for the carrying cost of the legacy system while they are funding and implementing a new system. Don’t make that error. It needs to be in the TCO calculations.
7. Staffing Timing and Purchase or Subscription Not Aligned with Deployment
It is important for companies to expressly communicate with stakeholders that once a deployment plan is created, it needs to be adhered to with significant rigor. I would take the time to tell the different functional group leaders within your company that any delays will equal X amount in lost monthly carrying cost for the project. For example, if you purchase a subscription, but the go live gets delayed six months or a year, then this becomes a potentially needless sunk cost. If you allocate and staff a number of people to the project, but the deployment extends out, then this could also be sunk cost. These facts are also what “The Hammer” can use to move people along.
8. Lack of Follow Through
When a project is in the execution phase, there is a lot of attention and significant resources devoted to the effort. Trainers are present and there is a focus on getting the organization ready for the new system. Once the project is complete, the resources can scatter to the four winds, leaving users without ready help. Be certain to determine if the software vendor has advanced online training tools. Additionally, after a period of time has gone by, if there has been attrition among the user base, or gaps in training, then there might be requests for unnecessary customizations to be added to the environment. There might be processes now performed incorrectly. To counter this, there should be a planned exercise, 4-6 months after the hypercare period ends, where the software company (primary) or the implementation partner (secondary) executes an assessment for the client. The purpose is to ensure that the customer is receiving all of the value that they can get out of the software, and that they are using it correctly. There should not be a cost for this. After the initial assessment, performing one every year or so could bring similar value.
Certainly there are many other impediments to successful ERP projects as this is just a small list. Please share your experiences and other impediments in the comments below.
