The 5 Biggest ERP Implementation Pitfalls

Juliette Welch: Good afternoon, everyone. Thank you for joining us for today's call: How ERP Implementations Fail.

Shawn Windle is our speaker for today.

Shawn is the Founder and Managing Principal of ERP Advisors Group based in Denver, Colorado. ERP Advisors Group is one of the country's top independent enterprise software advisory firms.

Shawn advises mid to large sized businesses on selecting and implementing business applications from enterprise resource planning, customer relationship management, human capital management, business intelligence, and other enterprise applications which equate to millions of dollars in software deals each year across many industries.

There are only a few people in the world with the practical experience that Shawn is gained with helping hundreds of clients across many industries with selecting and implementing a wide variety of enterprise solutions.

On today's call, Shawn will help you identify the five biggest pitfalls for implementing an ERP and how to avoid them. Knowing these pitfalls and how to avoid them can not only save your ERP project but also your job. After this call you will rest easier knowing your project will be a success.

Let me introduce Shawn Windle.

Shawn Windle: Thanks, Juliette. I always appreciate your intros.

So, this is Shawn Windle with ERP Advisors Group, I’m the Managing Principal and Founder and I usually don't talk about things like why things fail. We talk about how to make things better and what it takes to make things successful — try to keep it on the positive side.

But the reality of what we do — and there are times when I ask myself, are we really in the right business? Because in our industry, experts from Gartner, Giga, or Forest all these IT analyst folks out there that get paid to basically criticize the IT industry.

But they're right when they say that over 60% of all software implementations that are pretty big fail. And I've read a book about a year ago on software implementations and methodologies in that and the author at the time had a really good point that for folks that are even closer to the industry, they would say that number is bigger, whether it's 70 or 80%.

Now, software salespeople won't talk about that — the good ones will. They'll definitely talk about what the risk is but the reality is when you start looking at enterprise software — and we say why ERP implementations fail — but the same goes for human capital management, HR software, supply chain management, CRM — customer relationship management — all these different kinds of enterprise applications don't have a very good success rate in being implemented before.

Fortunately our success rate with our clients is very high doesn't mean we don't have problems. We always do, but the reality is just very complex stuff. Yet at the same time I was just chatting with gentleman this morning that there's over $50 billion spent in software and services in just North America alone, for mid-sized companies.

So, you have this mix of well, we know we need software, but there's a lot of failures out there, but we're going to buy it anyway.

So, what do we do about it? Like that's what we really care about as a firm, but definitely me as just who I am is — I really do want to help you avoid the biggest pitfalls for an ERP implementation.

So, that's the basis for the call today, and we're going to go through five items with a bonus — there's actually a bonus at the end, too, of some things that you definitely need to avoid and how to avoid them.

And I think after this call I can guarantee you that if you're doing a project now, it's going to go better after the next 15-20 minutes that we spend together.

So, here's the first reason why implementations fail. It basically comes down to you don't know what you're implementing.

So, I can use phrases like wrong scope and the statements of work were wrong and the approach and the resource planning and da da da, but it ultimately comes down to you don't know what you were implementing in the first place.

And that's a pretty raw way to say that, but what I mean by that is — well, we're implementing software, so we — let's just say we're a growing organization, we have multiple entities throughout the country, we're going national or international and we need software to support our international growth.

That’s a good reason to look for software. We actually have a list of reasons why you should switch software, and that happens to be one of them, is growth.

So, let's say you go to the market, you start looking at software applications, and you immediately get confused. Because there's just a lot of apps out there unfortunately, and you tell the vendor, hey, I need software to help me support my international growth.

So, they say, well, yeah, we can support international requirements, multi-language, we can support number formats, we can even support different currencies and the translation and so on and so forth.

Okay, that's basically what we're going to need. So, great.

But the reality is that a lot of discussions of when you're starting to look at software really go into functionality and what the functionality is that you're looking to buy, and when you start diving into the details, you start to lose the viewpoint of what the overall solution is that you're implementing.

You're basically implementing — and this is important; I really want everybody on the phone to get this — you're basically implementing tools to help your people be more productive with what they do. That's it. You can snazz it up and jargon it and acronym it, but that's all you're doing is you're buying tools that make your people more productive.

So, if you happen to be doing the international instance like I'm talking about, your accounting department is going to be running into a lot of issues with currency translation.

If you're doing currency and multiple languages, and then you have regulatory reporting that you need to do in different currencies, functional books, and all that so great, you're actually ending up helping the accounting department in that instance a lot.

You're not really doing much for the rest of the organization, so it's really important that you understand though what it is that you are implementing, what tools you're putting in place, for whom in your business.

That's the first why implementations fail. They just don't realize what they're doing.

The second reason why implementations fail is also kind of obvious, but it's often the problem is that you picked the wrong app.

What I mean by that is again, using the scenario of the international business you went out and started talking to customers or department took two to salespeople and maybe even current customers of those applications. And okay, this is the application that we want to make sense and let's go ahead and buy it.

But what can happen though, is that you didn't understand the detailed requirements enough for your business and for your problems that you're trying to solve that you made your decision based off of what was best for other kinds of companies.

Maybe even your best friend who happens to be the same position at another company that's similar that said, oh yeah, Microsoft Dynamics GP was the app. It worked perfectly for us. You should just go with that.

Or you implemented Infor Syteline or CloudSuite Industrial at the last company, you're at the new company and CloudSuite Industrial going to be right. And oh, everybody’s buying Netsuite — we're going by next week and so you end up picking the software based off of decisions that aren't related to your company and where things are going and what your requirements are currently.

That is seriously one of the major reasons why implementations fail because you have the wrong application in the first place, so there's lots of things you can do to ensure that you have the right application, you can take the time to understand your business requirements, you can force the salespeople to show you the software around your business requirements, and you can see it in the application, you can make sure the contract says they're going to deliver exactly what your requirements are, so there's ways to get around that reason. But it's a big one.

The third one is a little bit tricky. A lot of selection process is for software — before we get into the implementation, focus on the software.

Just like I said, lot of selection process for software focus on software. But what they forget is that you know software is just like a thing. I mean, it's a nebulous thing and that it resides in cyberspace if it's in the cloud or on a server somewhere.

But it means absolutely nothing. I mean, it's like a piece of wood. It doesn't do anything, but what makes software a tool for your business are the people that implement it.

So, the third reason why implementations fail is because you didn't have the right vendor — the right implementation partner — to help you with your implementation process. So, what does that mean to have the right implementation partner?

There's three things. There's always three things.

The first one is they have to have experience in the application that you've selected. If they don't have that, then that's a silly conversation to even have with them.

So, like SAP ByDesign. It meets your needs, you've demo'd it, you got past our second implication reason why they fail, you've gotten all the contracts in. You’re great, that's fine.

So, now you need somebody that does SAP ByDesign. Most likely, whoever demo'd it has implementation people, so that's fine, that's good.

So, they get to know your requirements there, but they have to know the software. Don't go out and select an Intacct partner to implement SAP ByDesign.

Well, come on Shawn, that's obvious, why would I do that? Well, it may be obvious, but when you really start digging beneath the covers on what an implementation partner’s capability is, it may surprise you.

For instance, we had a deal recently where we were working with a large company and helping them with their selection process, and we had brought in a vendor that was really good on what we thought was the biggest business unit as part of our client, but then the client bought another business that’s completely different, like totally different and the implementation partner that we had brought in had very little experience with that other business.

And we're like 3/4 of the way down the road here. Like, what do we do? And it turned out that the implementation partner ended up buying another implementation partner that brought in those resources that were needed for the whole deal.

So, they can work around it, but I don't care if we would have had contracts — even contracts signed — and we were ready to start and if something happened with the implementation partner where they didn't have the ability to do the project, for instance, we contracted for a specific resource at the implementation company and then that person —

We had one deal was terrible where the guy had cancer and he wasn't able to do the project and it was like I'm sorry. I'm part of the contract for him to be here. Who else can you bring? And we've vetted those people and they weren't as good, and so we put the project on hold.

So, picking the wrong vendor that's going to get you through your implementation is a huge mistake.

Please avoid that by getting to know the vendor, building a personal relationship, having the cell phone to whoever the lead person is, and then their boss’s boss and tell him look, I'm probably going to call you at 2:00 AM in the morning if this project is going bad, and if you're not willing to take my call at that point, I don't want to talk to you. I don't want you to be here in helping me.

So, I could harp on that one for three weeks, but that's enough on the third issue of picking the wrong implementation vendor.

Okay, so now let's say we know what we're buying and we really understand that we got the right software and we have the right implementation. Well, geez, what could go wrong from there?

Well, now we take the focus from external stuff that can happen, and we put it more on you and your subject matter experts in the business.

So, the fourth reason why implementations fail is because we did not staff it appropriately from the client side — from the customer side.

So, what I mean by that is okay, great, we go out — we, again, we do all the things we just talked about there we shouldn't do. We do all the right things. We start the project.

Okay, let's get to it. And the implementation partner comes in and says, okay, well I understand what you want from this scope and I need to know some specifics in this area of procure-to-pay and exactly how do you do your RFQ process? I don’t know if that’s the right acronyms, but how do you do your purchasing process and how can we bring — how do we build this into the software?

This is what we're thinking. And then the consult looks up and there's nobody in the room, because the key procurement person is out dealing with some supply chain issues with some vendors that they have right now.

Okay, well we'll reschedule.

So, then the consultant reschedules. And then the person goes, oh my gosh, I'm so sorry, you know I'll definitely be at the next meeting. They set up the next meeting and a consultant shows up. There's nobody there again. Oh, I'm so sorry, we're so busy, we're making this acquisition, we're doing this round of financing, we're changing our quality assurance standards, and so we're putting our vendors through whateve,r we're doing, cycle counts or da da da da.

They have a day job. I get it. But if there's not the right resource there internally — a subject matter expert who knows that area — you are wasting money on the consultant who's sitting there for $200 an hour, $225, $300, even the $150 doing nothing because the people that you needed on the project are not available to help them, so I mean it's a really important aspect to think about is to ensure that the people that are going to need to tell the vendors — the implementation people — what to do need to be available to tell them.

And there's mitigations on that too, right? You can have — you can backfill people, so if they have a controller is usually the one who gets hit the most on most projects because they know a lot about everything, right?

And if you can take some of their job, maybe it's the month end close or some of the normal tasks that they do during the week and get somebody, maybe it's a temp, maybe it's a junior person — even better — who can step up and take over some of those tasks to free that controller to be able to participate in the implementation.

I mean, that's optimal because then you've got a person that you're bringing up internally in the company versus — we do have clients that are bringing temporary folks that'll come in and do some things, and then they go.

But again, making sure that your key people have time available for the implementation is a huge mistake that I want you all to promise to me that you will avoid when you go through these projects.

So, the fourth reason why implementations fail is a little bit more technical. I usually keep these calls pretty high level, but I'm going to go down to the next level here on this one and then again, I have one more bonus for you here just from sticking on the call this late.

There's three reasons technically why implementations fail, and if you've ever been through these when I say these, you will cringe because you've felt them in your past. The first one is data migration, the second one is integrations, and the third is customizations.

I sound like — I think it was Cajun Man from Adam Sandler on Saturday Night Live when I use those phrases like that.

But it's really true that from a data migration perspective — let me take that one first. So okay, we want to switch systems again. You got the right scope, you got the right software, you got the right external implementation people, you got your people signed up.

Okay, great. Let's start doing this project. Oh, okay, well we need to get data from the old system and bring it over to the new one, right?

And there's core data that you just have to bring over, and we have lists of what that is. But it basically boils down to any open transaction that's in the old system has to be brought over to the new system.

And your master data, like your customer list, vendor list, employee list, all that of course has to come over, too.

But then you start looking at like historical data and for an instance with a client, there was a manufacturer that we worked with several years ago — actually natural resources firm spending hundreds of millions of dollars per year on — it was a mining company, and so they're buying everything from gloves to multi-million trucks so their purchasing system is extremely complex. And we had to bring over their open purchase orders.

No problem, we've been through a million things before we different kinds of systems. We know how to do that. But then we start looking at their open purchase orders and they're a mess. I mean, an absolute mess.

They have purchase orders that are left open from three or four or five years ago. They don't know if they received it or not, and that's probably why they had some Sarbanes Oxley issues with internal controls.

But we've got this historical or open data — open transactional data — that has to be brought over that's just filthy.

So, great, we have to clean it. Okay, that takes time to clean it. Do we have the right person that's available to clean it?

You know, fortunately, in their instance they did — they were able to clean it. We were able to pull the data and move it into the new system.

Now another client of ours, a software firm in the Midwest. As we started the implementation or rolling along, the vendor says, okay, I need all your contracts so that we can do your ongoing billing — like I need to know what you've sold and how much and what your renewals are, what your discounts are, and what your da da da and everything for your contract terms.

They're like, okay, well, we'll pull that together. And a year later, and about a quarter of a million dollars, they were about halfway through.

And it's easy to say, like you know, oh my gosh, what was that all about? Well, they were a successful software company. They had about 10,000 customers and every single one of their contracts was in Word.

So, they literally had to hire very expensive CPAs to go in and go through each contract and basically build the terms for each deal into a spreadsheet that then was reviewed by their revenue assurance officer to make sure that they could even do that. So, then they had to renegotiate with some customers and then fine.

Now here's the final terms now, put those into NetSuite. It turned out to be — and, oh by the way, once we got to that point, it turns out that we didn't support some of the terms that the client didn't even know they had when they bought NetSuite. So, there's a bunch of customizations in that.

Data migration is a big reason why implementations fail, so you really have to get on that right away.

We actually do that even before the project starts. We will start talking to clients about data migration on literally day one of the implementation.

The other two areas within this area of the technology is not set up right is integrations where you get in, you start a new implementation, and you start pulling out the old system and well, it turns out that our biggest customer is Walmart and they require EI transactions sent through this specific dan, or in this specific format or whatever, and we didn't think about that before we started the project.

So, oh my gosh, we got to get that in place now, too.

So, really understanding what your existing system, what other systems it works with is very important.

And then the third area, like I said of customizations, that one is when you're going through the demonstration process, you really have to see, does the software support all the areas of the business or not, and if it doesn't, that might still be okay. It's just how can they do it?

Well, they're going to have to build customizations on it. So, really understanding big areas of customizations, for instance on like a sales system if you do configure price quote where you got — you're working with a customer and you're like, oh yeah, you want a forklift?

You want a forklift that looks like this. Here's the different parts and options, and here's how it comes together. This is what the price is; let me get your quote and send that over. That area of a business usually requires a lot of customization because it's often different amongst businesses.

So know those areas of customization in the demonstrations identify those areas and scope them out before you even start the project, because to get 3/4 the way through a project and realize you have a big customization can kill your budget and your timeframe.

So, watch out for data migration, integrations, and customizations.

Okay, so the fifth area of why implementations fail — it's probably the most obvious one that's on here is training.

So, you buy a new tool. You got to make sure the person that's using it knows how to use it.

Oh yeah, we'll do training and the implementation partner has a training plan and we've identified well, the people are need to get training and they're all in the training and we're tracking the training and they're in the training.

We hear this over and over and then you talk to a key person about, well, how are you feeling about the system? They're like, I have no idea how to use it.

You say, but you were in a training sessions, right?

Well yeah, okay, alright, got it.

So, then you go to the next training session and everybody has their laptops and you hear while the trainer is talking and you just walk around and you maybe look at the screens and everybody’s on email.

If I had a dime for every time I saw that — I mean everybody is busy, right? So, they got to do their job, but then they don't get the training done.

So, here's the secret to training is you have to put accountability on the person who's learning the new software to learn the new software.

That sounds extremely obvious, but it's really true and what we continue to see over and over that really helps people is to twin people up during the training.

So, here's an example — you got the trainer at the front of the course room. Let's say it's for customer service representatives that are going to be entering orders over the phone in the new system.

So, you've got 30 people in the room and they’re listening — you got a trainer upfront who's pointing at the screen and saying you do this, you do that. Okay, as soon as you said this, you lost them. Like you literally lost them and they're good people. They want to know the system. They want to be able to do their job, but they have no clue what you're talking about and maybe they don't want to raise their hand and look stupid in front of the rest of their peers so they don't say anything, right?

Okay, fine, so better than having somebody blah blah blah like the Charlie Brown teacher. My daughter thinks — I think all of her teachers are Charlie Brown teachers.

But instead of doing it that way, have the instructors say, okay, here's how you enter an order showing how you enter an order up front.

Now I want you to do it with a twin, so twin up. You get everybody in twos or threes — whatever — and then person may you know have an AB, whatever amongst the group.

The first person, go ahead and enter an order and then the second person watch them and tell them if they did it right and they're like, oh my god, I actually have to know what I'm doing.

So, it just changes things so much and you put the accountability back on the person has to learn the system.

So, that's the key strategy for the fifth item of why implementations fail is put the accountability back on the person.

Okay, so then there's one more thing that I've been sandbagging that has probably taken me 22 years of doing nothing but software to really understand about why implementations fail.

And I'll share that with you now, and I could say, well, we'll do it on the next call, but I really — I do want you guys to know this. At the end of the day, the reason why projects really fail is because you have one or two people on the project that really don't want the project to succeed.

That sounds so simple. But it is the absolute positive truth, and those people can be very hard to find.

I mean I am — I'm very fortunate that in a very short amount of time I can find the person that is — they might not be the one sitting in the room saying no, I'm not going to do this. I love those people. I love him. I go over and I hug him and I'm like thank you for telling me this, what's your concern?

Well, I know that the way our business works is not going to work in this software, because when I saw the demo, it didn't do it. I'm like thank you, thank you for telling me. Now we can do something with that.

It's not those people, nor is it the people that are like, well, alright, fine, I guess I have to change and I can see how it's a little bit better for the company.

It's the people that aren't saying anything and it's the people who are covert and that are already probably causing some problems in their area.

Or maybe there's an area that just doesn't seem to be doing very good in the business and we can't figure out why, and it's not obvious and there's probably some early indications, maybe they've already been kind of — we used the word matter and then they're blah blah blah about whatever, maybe just quietly. They're kind of like starting to get a little reared up.

If you've been an industry expert for a long time, you can start to see these — the people that just don't want to change, but it's more than that. It's that they really don't want this project to be successful.

So, I mean, I really mean it like this is why projects fail, at least when we're around, honestly, because we know all this stuff and we made sure that you got the right software and the right vendor and the right project plan and the budget trackers and the status notes and all that stuff.

We know that that's going to work, but inevitably there's this person that ‚ we basically call them the covert hostile person who is hiding their true intention, which is to crash your project.

And so, the one thing I can say to you is, if you look directly at the individual, you won't see it, but if you look at their results and their statistics and what they're doing otherwise they — things around them just for some reason don't go very well.

So, how do you think a — what could be a multimillion-dollar biggest change that the company's ever made and they happen to be a key person — maybe they're the controller, maybe they're the lead customer service representative, or maybe they're the person in HR or manufacture don't care where they're at — find that person and handle them which could either mean tell him, knock that off and I'll watch my language.

I want to get more strong than that, but I won't right now, but I will — you're my client, knock it off and either get to it — and get to it, like we need you on the team. Get moving or they're out and don't be afraid to let somebody like that go.

Because you're basically not only protecting the software implementation, but also the company and even your own job so I mean — I really mean it that that bonus is the thing year after year that I keep seeing is the thing that kills the project is that you have this person that has this attitude that's just toxic and they're going to kill your project.

Because this is it: the software is about people. It's never about the technology, it's about the people that are using it.

So, look at the people, understand how they're doing, help them out through the whole process, make sure you get the right apps and the right vendor, and you're golden.

Find these people that are idiots that are just nasty people that should be moved to a far isolated island anyway.

I guess I should probably tone it down a little bit. But when it's my client and I see this, I will do anything possible to ensure a successful implementation, even if it means taking this person that's been around for 20 years and saying to the CEO, you need to let them go.

I'll be the bad guy on that because I want the right things for our clients but also this is why we do these calls is to share these kinds of tips and tricks from the trenches for you all, so I appreciate it.

We will definitely make this this conversation available on the website.

But thanks for listening and going through that, Juliette.

Juliette: Sure, Shawn, thank you. That was a lot of great information.

Thank you everyone for joining us for today's call. Please be sure to let us know if we can answer any questions you have. If you'd like a summary of today's talk, be sure to email us and we can send it out to you.

Our next call is Tuesday, October 17^th: When do I need to upgrade my ERP?

In this next edition of The ERP Advisor, find out the four most common reasons why companies upgrade their ERP system. Please go to our website erpadvisorsgroup.com for more details and to register.