In The Business of ERP Project Recovery: Top 10 Implementation Failures Under The Microscope

erp project recovery

Today we will tackle the uncertainty of the long-standing topic in the ERP world of why so many implementation projects fail. Let me first honestly state that I am not particularly an expert in this area as our team has virtually no experience in failing ERP implementations. Quite the opposite – we dare to succeed in our ERP endeavors, and thus the focus of this blog is on how to avoid failures. After 20+ years of software implementation challenges, including the last 10 years exclusively in the Microsoft Dynamics AX(now Dynamics 365 for Operations) space and significant experience of recovering troublesome or failed projects initiated by other providers, here is our top 10 list of signs of trouble and how to avoid it.

10. Software Selection

I was never able to verify this number, but have seen it mentioned multiple times. Apparently, there are 52,000+ ERP solutions out there despite numerous consolidations in the latter years. The majority are industry or geography based or represent small sub-segments of functional users. However, there are plenty of “generic” ERP products and even more home-grown, internally built software solutions. It is absolutely imperative from the get-go to lineup your selection process to match the business requirements, potential expansion or contraction plans, data and infrastructure strategies, industry musts, etc. As we live and breathe in the Dynamics AX world, we can quickly disqualify most banks or hospitals from the potential suitors, however can bring a lot of benefits to most manufacturing, distribution or service industries clients.

9. Aligning Objectives And Execution

There are two main strategic approaches for a new enterprise solution. You may elect to deploy a new system to get competitive advantages in your industry, your market, your geographical area. OR (and it is a very big OR) you may elect to dive into this messy excitement to simply achieve a controlled, managed system of records. Every case is different, and I am not in position to advise that the same approach must be taken in every situation. However, it is very important to understand what goals are being pursued and build your project plan, testing policies, technical and infrastructure investments to support the selected strategy. A very common misstep is to claim that the objective is to gain competitive advantage (everyone loves to put it on their resume) yet execute under the simplified “just the system of records” project scope. However, it is quite a catch 22 situation, as building a solution with a lot differentiators may require bypassing some of the established best practices – that’s where a true value of an experienced consultant is in the spotlight.

8. Management Commitment

Imagine you have decided to take on a huge loan and build a new dream house. You will be paying for this baby for the next 30 years. This is your personal project of a lifetime. Would you then hire a Contractor and tell them “call me when you are done”? ERP projects are beasts. For most organizations, it would represent the most expensive, most influential investment of the year (sometimes of the decade). Yet the lack of leadership engagement is painfully visible in many poorly executed deployments. A number of stakeholders are involved in a project of this magnitude. In a perfect world, a dedicated team of your top innovators is created to lead the project. In the real world, that happens less and less, and only the largest of the large companies are able to do so. On the contrary, most organizations compose a team of part-timers (read “those who continue on their regular jobs for 40 hours per week and add 10 more for the ERP project”). This is exactly the area where leadership can show true commitment to the initiative… and avoid paying for it twice. One of our projects started with the client’s management staff missing 14 of the initial 18 scheduled meetings. These were the specific gatherings to put together the true objectives in every area of the business. A very high probability such an engagement will never end on time and on budget. It was time for a face-to-face with the CEO to make some changes.

7. Unrealistic Expectations 

Living in the world of ERP consulting, it is very self-serving to tell the prospects to spend more money. However, it is not that difficult to paint a reasonable picture and set the expectations in order behind the success stories of positive results. We were never shy to tell the clients’ leadership whenever their expectations were not practical. It feels so much better to under-promise and over-deliver (ecstasy on the level of a “three-point hoop in the last second of the Final Four”) than get the sale and fail to succeed. Remember the golden rule – the cost of a botched implementation and re-work will make the original budget look like the bargain-basement, heavily discounted price. Not all in the consulting fees, mind you, but primarily in your costs of doing business. A very recent example – a potential prospect has reached out to us to help them out getting the project over the finish line. The perception was that the ERP implementation was 90% done and just required the final push. Unfortunately, once we have collectively reviewed both what was done and what was left to do, it became apparent the situation was more dire – closer to 10% ready than 10% remaining. There is a happy ending to this story though – a new project plan with its own ROI and the rescue was successfully completed. They are live on Dynamics AX with expansion plans to sister businesses.

6. Change Management

You are sitting in your living room, watching an NFL game on a Sunday afternoon, enjoying a bucket of wings and your favorite adult beverage. Now close your eyes and imagine an earthquake and a tornado hit your house at the same time, and a gang runs through the kitchen and steals your TV in the aftermath.  That is the effect of the new ERP implementation on your user community. Their day-to-day activities will be shattered and while the end result should be a brand new house with a bigger living room and a nicer TV, if the change management process is not properly planned, your users may end up in the bathtub holding the remote control and antenna (as in hiding from tornado, of course). However, if you are well prepared in advance (for ERP read “practically feasible project plan”), have evacuation procedures (read “user training”), fortify your doors (read “testing, testing, testing”), and avoid building your house in an earthquake zone (read “solid data and infrastructure foundation”), then you don’t have to sit a hope for a Hail Mary.

5. Data, Data, Data

Not that dissimilar to the real estate market with the infamous “location, location, location” motto, the success of your project is tightly depended on the data management. Rarely have we seen the case of a failed or poorly deployed ERP solution where data was given the respect it deserves. While such a project presents a perfect opportunity to cleanse your legacy data, many focus on shoving it into their new system as is. Before you start, check your project plan. If tasks related to data loads and scrubbing are not prominently featured, you are up for one heck of a surprise. Back to the real estate analogy – in the world of saving broken down implementations, poor foundational data turns a quick “fixer-upper” into “level the building and start over”.

4. Decision-Makers … Please Stand Up!

A very customary challenge in these types of endeavors is the lack of resources in position to make important, business-changing decisions. It is crucial to have appropriate involvement by the folks, who are both authorized and willing to step up, listen to the mountain of options and enable the path to success. Unfortunately, unavailability of decision-makers is one of the most popular threats to the deadlines, and eventually, budgets. Vague and uninformed decisions are as much of a concern as delays and constant changes in requirements. No matter how good or bad the consultants you engage are, the end user company must take the ownership of the final result. On a slightly related topic, these are the same people in charge of keeping the project scope in perspective to avoid constantly changing requirements.

3. Focused Expertise

This is one of my personal pet peeves. Many project owners and even product implementers focus on generic ERP experience or, even worse, on the overall IT background when building their implementation team. While the foundation is very similar from product to product, it is an absolutely negligent approach to assume that just because someone has seen Mapics or BPICS or Netflix (fill in any of 52,000+ ERP solutions out there), they will be able to jump into Dynamics AX and be productive. Typically, by the time you realize that Mapics Master Planning is not quite like Dynamics AX Master Planning, you have to take multiple steps backwards and start re-designing the foundation of your system (always painful). The team must be filled with experts in whatever product you are implementing. There is a nice, quick list of essential traits to look for in the ERP team member from ERPFocus.com (http://www.erpfocus.com/five-essential-traits-to-look-for-in-your-erp-team-members-3306.html), however it is missing the key ingredient: product expertise.

2. Legacy Is Not The Benchmark

legacy systems to erp upgrade dynamics 365

While it is imperative to involve internal SMEs in all of the important decisions, there is one clear rule for this type of a project. You have to start by outlawing the expression “because that’s how we have always done it”. Gathering business requirements and properly constructing your solution is the foundation of the future of your enterprise. Be afraid of, scream and yell, run away from situations when the WHY question is answered with “just make it the same as my old system”. It leads to un-needed customizations (read “will be paying for this over and over again with future upgrades, support and maintenance, etc”). This is unequivocally NOT a vote against customizations – all I am arguing for is to follow the requirements and focus on the best design (not on the “that is how it has always been done” solution). One of my favorite stories of this variety comes from a customer with significant EDI requirements. In their legacy setup, they would receive customer orders via EDI, print them on paper, then fax this paper to the next room. There it was entered into an MS Access database and with a few fields re-sorted and re-calculated, it was then printed again and delivered via internal company mail (big brown envelope) to another department in the same building for data entry into the main ERP system (that’s not even accounting for a few additional steps in between involving highlighters, pencils and manila folders). It was quite a major breakthrough once they have discovered that EDI stands for “Electronic Data Interchange”.

1. No Cutting Corners

One consistently common variable we find in the numerous recovery projects we have engaged in is the lack of consistent processes, technical documentation, user guides, documented test cases, and sufficient training. If you think you can save a few bucks by skipping these integral parts of every ERP implementation (or any  enterprise project for that matter), no big deal. Just keep our phone number close by as we will likely have to come in to fix it up – in the end of the day who doesn’t like paying for the same project twice?

Want more information about recovering from a failed implementation? Check out our Project Recovery Page.