ERP Implementation Failure | ERP Advisors Group

Implementation failures are just a consequence of the industry we work in. We like to be involved and upfront with clients…

Implementation failures are just a consequence of the industry we work in. We like to be involved and upfront with clients — and we do all we can to avoid ERP implementation failures — but all too often, we get called in to help save an implementation that has gone astray. Suffice it to say, we have become experts in the art of bringing botched implementations back to life.

Here are the top 4 ways how to avoid an ERP implementation failure.

1. Make sure you know what you’re implementing in the first place

While that sounds fairly obvious, it’s a very real issue that we run into with many companies. Typically we see companies decide they need to upgrade their ERP or their software applications because of a problem that arises within the company, so they choose a certain software application to solve said problem. Perhaps they are adding a new entity or expanding overseas and need to add new currency. Perhaps a mandate comes down from a higher level in the company that requires new software. Either way, management starts shopping for a new application.

Once they start the implementation process, however, sometimes folks discover that the tool they bought doesn’t solve the problem the way they thought it would, if at all. It’s as if you went shopping for an apple but when you got home from the grocery store, your bag was full of oranges.

To prevent this failure of ERP from happening, it is important to really dive into the ERP software vendor’s contract, their website, the sales order form, and really understand — line by line — what you are buying. You can even call the implementation partner and have them explain it to you, and if they don’t understand certain aspects, then you really have a problem. It’s critical to understand every aspect of the software application and make sure your implementation partners understand every detail, to do as much ERP implementation risk mitigation as possible.

2. Get the appropriate implementation resources

Sometimes the highest quality implementation resources are too bogged down by other projects, and do not have enough time to devote to your project and to deliver it in a timely matter. One of the advantages that our team at ERP Advisors Group brings is that we can be “on scene” and look out for your best interests. We gain access to timesheets to see how many hours per week a resource is billing to the project to make sure they are devoting adequate time to ensure on-time delivery. We are also able to monitor if they are billing too much and not doing the work. Basically, we watchdog the whole process to ensure the implementation partners are doing the work they promised and in a timely manner

We’ve seen a LOT of ERP implementations where the resources hired are just too busy to dedicate time to your project. Months go by, costs continue to build, and expectations are not met. Ask for a time sheet from your implementation resources and track their time to ensure that your implementation does not get botched.

3. Make sure internal resources aren’t too busy (and know what they’re doing)

This is a hard topic to discuss with clients, but again, it is something that we come across often.

When a company undertakes a software implementation, they don’t often realize that the key people in the organization are the same people that need to be involved in the implementation process because they know the business, the processes, and the way systems are currently used. These are the same people that need to talk to the vendor, communicate business requirements, check all the configurations, do the testing, and even help with training. However, they still have their full-time day jobs so it can be difficult to add this project to their plate and expect the implementation to be successful. Hire temporary help, promote people into new roles, and just watch out for the people who are too busy and help support them.

The other aspect of this is when an employee doesn’t really know what they are doing. This is not to say that they are not competent or able to do their job within the organization, but they may not have the right implementation methodology for implementing a complex ERP system. This can be especially true if they have never gone through an implementation process — they will have no idea what to expect. They might not know that they’re responsible for telling the implementation partner exactly what they need, asking all the right questions, providing a certain amount of information. So when the implementation team starts building everything out and it’s not correct, your only line of defense may be someone who isn’t experienced enough to catch that issue.

If you don’t have the right people on the project, it could result in a botched implementation. You’ll want to mitigate that risk by making sure your key employees that should be on the project are readily available to assist in the project and know exactly what they need to be doing in order to make the project a success.

4. Ask yourself if you actually need new software

Sometimes the problem that you are trying to solve in the first place cannot be solved by software. Again, this may sound painfully obvious that you shouldn’t go out and buy new software if you don’t actually need it, but a lot of companies do this out of desperation. For example, a company gets consistently bad marks for customer support so they implement a new customer support application that integrates with the telephony system, tracks the customer support representative’s activities, provides them with recommended phone calls, and is an all-around elegant and detailed application. However, the go-live process doesn’t go well and it doesn’t actually fix anything.

The “real problem” may not be process, tools, or efficiency but that perhaps the customer support resources themselves are not very strong, or the manager isn’t ensuring that work is dealt out, tasks are defined, and appropriate people are doing the work. Perhaps the issue is cultural within the organization. New software will not solve those types of problems.

These are four of the most common instances we see that can lead to a botched ERP software implementation. It is important to watch out for these early on, and mitigate any of the risks before you spend the money on implementing the software and have it go terribly wrong.

Juliette Welch: Thank you everyone for joining us today for our ERP Advisors Group monthly conference call series. Today's call: Can a Botched ERP Implementation be Salvaged? Shawn Windle is going to be our speaker for today.

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

ERP Advisors Group 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 has gained while helping hundreds of clients across many industries with selecting and implementing a wide variety of enterprise software solutions.

On today's call, Shawn will discuss how even the most delayed and over budget implementations can be salvaged so that you can get your company past the finish line to go live with the new system that you set out to have.

So, Shawn may I introduce you?

Shawn Windle: Yeah, thank you, Juliette and thanks everybody for being on the line, too, always appreciate y'all dialing in.

Juliette, the sound’s okay?

Juliette: Yes, yes sounds great.

Shawn: Perfect, okay, good, well let's uh let's jump into this — probably one of my least favorite topics to talk about.

We prefer to be involved upfront with clients and people to not have botched implementations, but the reality is not only do we get called often to help out, but there's projects that we're implementing that start to go astray.

And so, we've learned over the years how to bring them back and herd the cats back into the corral, so to speak — feeling kind of Western today I guess.

What I thought we would do first with this discussion is talk about a usual thing we cover on these calls is what is ERP. And what does that really have to do with what we're talking about here?

ERP is enterprise resource planning to software applications that businesses use — nonprofits, government agencies — what they really use to run their operations.

And that can be anything like accounting or inventory or revenue management or even customer relationship management or warehouse management systems or human capital management.

And when we look at ERP, we really think about the software that the organization is using across its entire organization to run its operations.

And it's not just accounting. And that also means that it's not just Oracle or SAP, or these gigantic systems that companies implemented years ago. It means the applications that a small startup could be running to do revenue recognition all the way to a fire department that uses software to manage their patient care reporting when the emergency medical services folks are out helping a patient.

So, we really look at ERP as the general concept of software that organizations used to run their operations. So, we're not just confined to a certain area.

And I wanted to go through that on purpose because what we're going to talk about is not just contained or specific to a specific area of application software. It's really across the whole breadth of applications out there.

So, with that defined, let's talk about what it means to have a botched implementation.

If you've been in software for a while or have had a software project that was maybe under your direction or you were part of a software project that was being implemented, you have experienced a botched implementation. I guarantee it.

Unfortunately, in our industry, according to Gartner Group, which is the IT analyst group — and there's other organizations out there as well — but they basically say the vast majority of software implementations fail to meet their original objectives. And that's kind of what we consider to be a botched implementation.

Now I think we go probably a little bit more extreme today and talk about what makes a botched implementation. And then we'll talk about how to fix it, but it's basically it's an implementation that doesn't go right — that's a very simple way to think about it.

So, we know what we're implementing here, we know what ERP is, and we know that we're talking about an implementation that doesn't go right.

So, let's talk about what really causes these implementations.

And there's four different things that I'm going to go through today on the causes of a botched implementation.

The first one is we really didn't know what we were implementing in the first place.

A lot of these things I'm going to say sound pretty obvious, but as always on our calls, I think we touch on some very practical things that are very real.

So, when you think about that, we didn't know what we implemented in the first place.

What can happen is companies — and really it's individuals, so I'm not going to say companies or clients, I'm going to talk about people, like real people. There may even be some people on this call that that have done this in the past or in the position where they're in an implementation, so it's really geared basically towards you, because that's who we're trying to help here.

What can happen is you can get into a position where you have a problem in the business and you, through whatever mechanism, decide that there's a problem with the software.

It could be something as simple as well QuickBooks doesn't support multi-currency functionality and you now have an entity in the UK because the sales operations went overseas and they're selling like crazy over there and you have to have a separate entity and it has to be in euros — or I guess now Great British pounds — and you're kind of stuck.

You have to have another entity and QuickBooks doesn't do it. And you've been doing in the spreadsheet, and it's not — then the business is growing and it just needs more automation there. So therefore, we need more software. It could be a reason why you do it.

But it could also be that there's a mandate that comes down from a higher level within an organization. It could be that there's somebody in a different group in the organization who says, hey, we need new software and wo whatever reason they have the power to go out and get it, and then you get stuck with it.

Preferably we'd like it where an organization has looked at their needs holistically and realized what their problems were and what they were trying to solve, and if they could be solved by software or not, and then go look at software solutions.

It doesn't happen all the time, but what we often run into in a client is that when there is a botched implementation, the first thing is that they have gone out and they have bought software and they start implementing it.

And they say, oh my gosh — they actually say a lot stronger words — we just spent a lot of money and we're into it, and we have no idea what we're implementing here. They thought it was one thing and it turned out to be another.

So, the warning here — you know we always try to give you guys nuggets, like little things that you can take that can make a big difference even today if you're looking at software and an implementation.

And this is probably the first nugget we'd say, which is really get into the vendor’s contract. Really get into their website even and look at the name of what you bought.

So, if you think about the Intacct solution, they've got some products, like they have a thing called a Salesforce connector. I was just looking at this for a client. What the heck is that thing? Well, it just showed up on the order form when we bought Intacct and the salesperson told us we needed it and we have Salesforce — so yeah, let's of course we need it, but you don't know why.

So really, go out and look at that sales order form of the software that you bought and understand every line of that sales order form and research it online or call the salesperson and have them walk you through it.

Or better yet, the people that are implementing the software — find out from them what each of those items are. And if they can't tell you what they are, you got a problem, because those are the people that are supposed to be implementing those things, and if they don't even know what they are then we got a problem.

So, you can see how that can then lead to somewhere down the line and something doesn't work, there's — the project gets botched and you realized why I didn't even know what we were implementing here.

So, at a high level, you're going to have a good idea. But I'm saying you got to get down to the detailed level on that that order form to understand what each item is so you know what you bought. And that's going to help you to prevent a botched implementation.

The second thing that we've run across, especially of recent, is implementation resources are too busy for your project.

This is when — I just talking to one of my guys today — seasoned guy, 30 plus years and IT applications — he's super frustrated. I love this guy — Curtis if you guys have worked with us before. We're on a project right now and the implementation partner is a challenge to work with.

And when we start digging under the covers we can see that the implementation resources the consultants. They're too busy on other projects to do our work — now we will correct this.

This is one of the benefits of having an ERP advisor firm like ours on the scene and watching out for your needs.

Is that we're on it. We actually have gained access, and they've given us access — I should say — to their timesheets — so, we see how much they're billing every week, so we know if they're not billing enough, or if they're billing too much and can actually see what they're doing for our client.

I mean in this case it happens to be a little bit lower than we expected it, so Curtis is all over them.

So what could end up happening here is if we weren't watching — and you just expect when you hire a company they're going to do the work right?

And that's fine for a plumber in your house if you have a stuffed up drain, you hire a plumber. They come in; they check it out. They go to their truck, they do whatever, they go back to the truck. Then they make some custom fitting that's going to cost you $500. That just happened to us recently — but that’s a different story — but basically they fixed it. They actually fixed the drain right and you could see because the water runs down so fine, you pay him, and he goes.

It's not like that for software because a lot of our people — a lot of the people that are implementing software applications now are remote, so you don't really see them.

I mean, if they're at least in the office, you can see if they're pretending to be working in front of their computer, whether they're working or not, you never know. But when folks are remote, you really don't know what they're doing.

So, it's hard to watch and see what the consultants are doing, even though they have a contract, even though they want to make money and they should be billing you, they're not because they're over busy.

So, what then ends up happening is you're going down the line. The time continues to go by, the calendars and pages, flip, and products aren't being delivered. But yet you're incurring costs, too, and the delivery is not happening. And you've set an expectation with folks internally in your organization that software is going to be ready by a certain date you get closer and closer to that date, and it's just — it's not done.

And if you trace it back, you can look to the times where the implementation consultant was just too busy with other projects and didn't take the time to actually get your work done.

So again, a little nugget there is ask the implementation resources for a weekly timesheet from them. Just say look just do a simple little download, we know you're tracking your time anyway but just do a little down. I don't care if it's what you bill me for or not, because sometimes they’ll write time off at the end of the month when they bill or every other week or whatever. Just send us your time and I just want to see what you're up to.

And that can help you to ensure that the project doesn't get botched because you don't have too busy implementation resources.

Now the next one is the hardest. It's the one that — it's kind of hard to talk about, especially on the client side. When we have folks that are involved with a company or a business or organization not for profit, whatever the organization form is — that it's so our clients we have to have this discussion and it's tough and that is the third reason is because the client resources are just too busy or they don't know what they're doing.

That's a real interesting question, especially that don't know what they're doing.

But let me break it down into those two areas of too busy versus they don't know what they're doing.

So, when a company decides to undertake a software initiative, what they often don't realize is that the key people in the organization are going to be the same people that have to be involved in the implementation.

They know the businesses, they know the processes, they know the way systems are currently used, they know all the ins and outs and those are the same people that have to talk to the vendor and the requirements and check all the configurations and do the testing and help even with training.

Well, those people are usually working 30, 40, 50, 60, 70, 80 hours a week already, and so now we're going to put a 30-40 hour project on them. It's tough. It’s very hard.

We have had some clients, we actually had — I don't think she'd mind me sharing — we had a great client on the phone several months ago that was involved with an Oracle implementation. She actually was pregnant during the implementation and she was working — she's a workaholic.

She's an amazing lady and really keeps that organization together and she was pregnant during the implementation. Her doctor’s like, look I'm not just like prescribing you to be on bed rest, you have to do this, like you can't leave your bed, you have to just lay down and let the baby do its thing here and just like relax or something is going to happen.

She did great. It's actually pretty cool to have a little baby born during the project. Fortunately, she was in the hospital and everything was fine.

But very often folks like her and others, they're key contributors. They might not be your top salespeople or your senior executives, but they're the people that make things run on a daily basis really smoothly. Those are the people, unfortunately, that we have to pull onto a project.

And if you don't make enough time with them, that project is not going to work. Like you're going to have a botched implementation. You're going to go live, and it's not going to work.

And those people are going to say, gosh, I was just too busy to be able to help out.

So, again, a little nugget here is try to backfill those people as best as you can. They're your best people, but maybe take a couple hats off for their heads. They wear a lot of hats. They do a lot of things. Maybe there's a couple things that you can get a temp person to do during the project.

Or maybe you promote them into a new role that's related to the new software application, so they've got a neat opportunity going forward that’s a little bit different, and then you you're bringing up people underneath them.

But really watch out for folks that are just too busy. It can really get you.

Now the other part of that, as I mentioned earlier, is that that sometimes we have client resources that they just don't know what they're doing.

We have people that are very competent and very capable within the business. But then when it comes time to doing a software project, they've never done it before and so they don't know that they're responsible for telling the implementation partner what they really want and what they really need.

And maybe the implementation partner isn't very good at communicating — which fire them if that's the case by the way — but potentially you can have a weaker implementation team from the technical team, and then they're not asking the right questions.

And then your people don't know that they should be providing a certain amount of information. And then the implementation team goes ahead and starts building a bunch of stuff and then you get it back and it comes time to test. And you're like, this is wrong. This is the wrong thing. What were you doing?

Well, it turns out that your people who were involved, they really didn't know what they were doing. So, I really mentioned that as a risk is something that you can mitigate and just pay attention to making sure you put the right people on the project.

Now the fourth thing — I don't think it's as hard as the last one. But what can really lead to a botched implementation — I definitely try to talk to you guys kind of informally on these calls so that it — I want to communicate so you don't run into these things — is you don't have the right scenario to need software.

Now what I mean is that the problem that you're trying to solve in the first place has nothing to do with software and I can guarantee you that if you implement a software solution, let's say it's a brand-new customer support application, it's integrated with the telephony system, it has pop up on the screen, and tracks the customer support representatives every activity, it provides the recommended phone calls for them to make — it's this elegant application you spend a lot of money doing it and you go live and it doesn't go very well.

You have to really look at is that what was really the problem in the first place?

So again, seems obvious. Why in the world would you ever buy software if you don't need to? Or why would you go through the changes that are required by new software?

And it's probably because you got a little desperate, meaning the real problem was the customer support processes. The business processes are completely broken. Or the customer support resources themselves are not very strong. Or maybe it's the manager or the group who's not doing a very good job of ensuring that work is delved out and that the paths are well defined and that we have the right people in the chairs and getting the right calls to them.

It can almost guarantee you that the worst batches of software that you will ever read about — the Shane Company, there's been other organizations in the past, some big ERP implementations with Hershey or some of these other areas — other companies there was one when I was back at Accenture with Sunbeam where tens of millions — if not even more — software is being implemented and the reality is the problem they were trying to fix wasn't fixable by software.

So, you really have to make sure the problem that you have in your organization can be solved with software before you implement software.

So, those are the four causes that we've seen — unfortunately, fairly recently too, of some botched implementations. So, watch out for those, please.

I want to wrap up the call with something I think is pretty practical here, which is when do you pull the plug versus when do you keep going on a project?

Because a project is — a software project that's going on and on is kind of like a money pit. Like I think there was an old movie — now it wasn't that old, maybe I'm dating myself — called “Money Pit” and it was maybe Tom Hanks or Steve Martin and he and his wife were remodeling a home and that home just kept requiring more and more money.

I think if you've been through a major home project, maybe even experience, that seems to sting at least to me a little more than software projects even.

But you get into a point where you've put in so much money that it feels like you can't stop, but you also know that to continue means that you're going to have to put in more. And I think the real key indicator there to look at is it's always best to stop.

If you have questions about a software project and it's not going well. I'm 99% sure it's only going to go worse unless something material changes where maybe the implementation partner reassigns or assigns a stronger resource to run it.

Or maybe you have another resource internally that you're able to put on it who's got more experience or has a different viewpoint or something that's more valuable to the project. Or you bring in a consulting firm like us.

If there's not going to be a major change, it's only going to get worse, and you can mark my words on that.

If you experience something different or you have, please let me know. I'd be very interested to get your feedback, but it's always better to just stop the project, and I mean full halt. Send an email, send a certified letter, whatever you have to the resources that are billing you for the project and say you need to stop billing me right now. I will not pay you a dime beyond this point. And maybe it's not right now, maybe it's the end of the week or something.

And what that will do is it will get everybody's attention from certainly the vendor side, and even internally to review where everything that really — take a look at what's happening now in this present time. Where are we supposed to be on the project plan? Where are we actually? Where's the scope? Where is everything — dollars, time, scope, everything, resources?

And they'll do it on their own dime because they don't want to lose the project.

And if you can, if you've got the guts — sometimes it's hard because you can have multi-million-dollar projects that have very tight timelines and a lot of pressure to get things done. But if you know that it's not good, I'm telling you to put the brakes on. It could be for a day.

We did this recently with a client and it was one day where actually the vendor and I were talking at midnight to one o-clock in the morning trying to go through what was happening and by the morning he had a plan. We reviewed the plan in the morning and in the afternoon the client looked at and said, okay, this is good. Let's go.

We've had other circumstances where we've stopped for an entire week and the vendor has to come back with how they're going to make things better, and we can take a look at that and say, you're not going to do it.

We had a very big project where we basically did that and told the client told the vendor we weren't going to pay another dime.

But the vendor kept working and trying to make up for what had been done, and they ended up investing quite a bit of money in the project and they did get paid for it because they weren't able to ever recover. So, at the same time we had to find another vendor. It was a very ugly circumstance.

But I'm telling you guys when you just pull the plug versus when you keep going.

Most times you just pull the plug, you just stop really figuring things out and then if you get a good plan, you get the sense that folks know what they're doing going forward and there's some accountability back to a new timeline that you can track, move forward, but if you don't have that, you've got a botched implementation and just stop and suffer the consequences now because it's only going to get worse in the late in the future.

And again, I wouldn't go into all this stuff with y'all if I didn't have some hope that there was help out there. We can help you. There's other folks that can, too.

But if you get into these circumstances, please give us a call, I mean, we'll talk for free and would much rather have circumstances better off than not in just a call with one of our guys can make a big difference.

So, appreciate your time today. Juliette, I'll pass the baton back to you.

Juliette: Okay, great Shawn. Thanks very much. That was great information.

Thank you everyone for joining us today. Please let us know, as Shawn said, if you have any questions, definitely reach out to us. We would be happy to help you.

Our next call is January 16^th: Leveraging a Reporting and Analytics Tool to Fully Realize the Potential of Your ERP. On this call, we will discuss using your ERP to its fullest potential as it relates to enterprise performance management. Please go to our website erpadvisorsgroup.com for more details and to register.