How to Avoid ERP Implementation Failure

Juliette:

Everyone, thank you for joining us for today's call, “How to avoid an ERP implementation failure.” Shawn Windle is one of our speakers for today. Hi Shawn! Shawn is the Founder and Managing Principal of ERP Advisors Group, based in Denver, Colorado. Also joining us today is Curtis Wait, Principal Consultant at ERP Advisors Group. Hi Curtis.

Curtis has over 25 years of experience as a business consultant and assists clients in a variety of industries with their project implementation needs. On today's call, Shawn and Curtis will discuss the underlying reasons why implementations go off the rails and provide guidance on how to identify the warning signs ahead of time. Thank you both for joining us.

Thank you, it's good to see you. OK, Shawn, if we’re ready to jump in, I'm going hand the first question off to you on today's topic. It could actually cover a few different scenarios. What would you say would generally qualify as an ERP implementation failure?

Shawn:

Oh man, that is a good question. Failure is — sound like a salesperson. “Ah, it's, it's one of those words. What does it mean?” But I think what, Curtis and I and everybody else on the team — we have worked together for a long time — but what we've experienced is that ultimately a failure is a project that doesn't go live with what management or the owners expected. So if you think about it, budget, scope, resources, everything that goes into a project — functionality — there's all these things that go into a big ERP project.

It's sort of like a construction project or a building or a bridge. Except you can't touch it and feel it and look at it and say, “that's exactly what's going on.” So what we've seen many, many, many, many times over the years is that clients get into these big projects.

They start working on it, they have an idea of what they want, they start building it, they start working on it. I get the vendors to come in and start implementing it and then they keep working on it and they keep implementing it and they keep configuring it and they keep implementing. And then they test and then they do some training. And then they go back and they configure, and then they test and they configure, and they say, “Oh my God, what are you doing?” Right?

That's really, frankly, a failed project in in our mind. Because again, the scope of the software: maybe they don't get what they paid for, maybe the client spends too much time on the project itself. Oh, we want to go live in December. Well, what year right? Like, it can go two or three years out.

And then like I said, from a time, money and scope perspective, those are the three factors that come into the failure.

But here's the thing: all three of those are negotiable items. When you when you start a project, an ERP project, is everybody knows — Curtis knows more than anybody. Curtis is the sage ERP guy as you'll find out here. It's kind of true! But those three things are also negotiable. They can move. And sometimes you need to move them.

For instance, “OK, we think the scope looks like this at the beginning of the project.” And then you get into it and you talk to some of the key users. “Well, we probably should have included payroll and we didn't think we needed it up front.”

OK, fine. Did we miss that up front and we should have known? Yeah, for sure. But whatever. Like, I mean, this is all we do day in and day out, so we know those questions to ask. But clients that are in the businesses of — from flowers, to building data centers, to building airplanes, or aluminum — sheets of aluminum. We have clients all over the place: community foundations, you name it, we work with them. That's not their business is to know these ERP projects, it's our business.

But, figuring out what that scope is right up front, getting a really good estimation of the time required to do all the work, and then the dollars to pull it all off, is very, very difficult. So all I'm trying to say is they’re a little bit negotiable. You may get into a project and realize, “well we actually do need that extra module.” Fine, you do it.

And then you go through and you look at the resources. Did we get the right people to do it too? That can change when you get into the project, and it's like, whoa, “we thought we were getting this team, but you gave us this other team.” The other team isn't as qualified or whatever, so the date and the whole delivery gets pushed out.

But again, to give a very succinct answer here: A failed project is one that never goes live with the promised functionality. If it goes live five years later and it's 10 times over cost, it was probably a failure.

But, we really look at like plus or minus 20% on budget and time. If we can hit in that category, if it's a couple of months later because the client needs more time to test — I don't know, Curtis, if you've ever experienced that. (Like 5 minutes ago on your last call.) But, if the client needs a little more time to do some things to make them 100% on the software, then do it for heaven sakes. Absolutely a little more training, a little more testing, it can't hurt. But if we're like nine months in and the scope changes, and we have to go out and basically reimplement the project, that's a failure. It shouldn't be that way. We know more about ERP. We can avoid those kinds of problems.

So really, getting a project up and running, getting clients into software, getting the software running and folks using it, and that plus or minus 20% in that range, that's what we consider a success. Fortunately, we're super good with that as an organization.

Juliette:

It sounds like you have to be flexible, but then going in and changing something every day all the time just creates more problems and you start from square 0 again.

Shawn:

That's exactly right.

Juliette:

It seems simple, but it's not, right? So Curtis, we're happy to have you join us. Thank you.

So it's safe to just say, I think, that you've been on more than a few projects for implementations, correct? What do you feel are the most common causes for an ERP implementation failure?

Curtis:

So there's probably 3 things that I would say are kind of big. Because the complexity of projects is so great and the length of time and the software is complicated and those things change overtime. You have to really work hard to be successful at these ERP projects. They're not easy.

The three things that I've seen that that cause trouble is: number 1, you don't have an experienced team. So because things are changing and it's complicated … I've seen project teams where, “well if everything goes perfect, we're going to make it.” And it's like, well, it's not going to go perfect. I can tell you that right now that something always comes up.

I've been fortunate, I'd say my whole career, every project I'm on, there's at least 50 years of experience on the project, sometimes double that, between myself and other people on product.

But when I look at some organizations trying to just kind of, as Shawn was saying, they're not in the business of doing this kind of thing. They don't do a lot of projects. They might be attempting a project with three years of experience, five years of experience. You're going to get into trouble when you do that.

The second thing I was thinking about was, the team and organizing the team. You need to have a structure for that team that's different than your business, so it can run efficiently and effectively. Not everybody going up the chain of command up and down every time there's a decision to be made, but you have a great executive leading it as a sponsor who can make decisions quickly. And if they need a little time to check with other executives, OK. But on the whole, if you're waiting a long time for each decision, that project will stretch out and fail.

And, I hope there aren't any Senior VPs on the call today, because you don't want to staff your project with all senior VPs. You want the people who are going to be working through the detail because you're going build that application up from the ground. There's a lot of details to be worked and your best people who can do that work are the ones you want on the project. And they are also the ones who are the busiest.

So you have to find a way to pry them away from their day-to-day work, backfill them or spread out the responsibilities, or somehow find a way to get them to work. If you don't have those people and you don't have them for enough time, your project fails.

And the last one I wanted to say is, you have to write things down. If you can't write things down, you will fail because there's thousands and thousands of decisions and activities and steps, and you really need a method to what you're doing. And there's so much stuff — or a plan, a written plan. And if you can do those things, then you're more likely to succeed.

Because otherwise, Shawn was describing people bouncing all over the place. It's like boiling the ocean. You can't boil the ocean, but if you take and focus on your plan, each piece at a time, you can be very successful and then build on that success and succeed, and succeed, and succeed. And you have to have that if you're going to avoid a failure.

Juliette:

I'm sure there's a lot more to it, but those are the three main important ones, like having a good team is huge. Not just for implementations, but for everything.

So Shawn, this ties together with our last episode of The ERP Advisor. We discussed how it's not just the software, it's the people. What can you tell us about the role of the implementation team in a project’s success?

Shawn:

To be specific, there's basically — well, I guess there could be 3 sub-teams on the implementation team.

One I want to talk about is the client side. And that usually consists of an executive sponsor, project manager, maybe a business analyst and a technical lead, or business lead and a technical lead. And then there's subject matter experts, and then there's end users: the people that are using the app when the software goes live. So you have this kind of hierarchy of people that — “Let's go out and hire all those people. Let's put an ad in the paper, or wherever people put ads, and LinkedIn, and Indeed, and go find that team.”

Sorry. Curtis said it: Those people on your team are some of the most important people in your organization today. It's probably some of the people on the call that are like, “hey, I want to go switch software”. Like we had a guy great out of Dallas who originated to the owners, “I really think we need to change our ERP system.” And they're like, “Really?”

He's like “yes!” And they say, “good, go do it.” And he's like, “Ahh!” He's great, but he's willing and able to balance his day job with his other job of pushing forward the software. And look, was it 80 hours a week when you put the jobs together? No, but there does need to be a little bit of play.

Again, Curtis touched on this, that you need these key people to spend time on the project, working on the project. And if they write things down and have like a list of tasks, that's even better. Sometimes they don't, fine, but that's the really key thing: is that you have to have these key people, even from the sponsor. It's usually a CFO, or it's a C-level person that's already busy, and “oh hey, by the way, we're going to give you an ERP project.” You have got to find time to manage that project and put together the team and everything.

And the PM is usually a middle-level person in the organization because they know quite a bit. They know a lot of people. It may be more of a traditional project manager, but that person is responsible for getting people to show up at meetings.

So if you get a lower level person, that's telling the SVP of sales we need you to show up for this meeting so we can understand your high level requirements — that VP of sales, that email just went right past that person. So that PM needs to have somebody with some influence and some capabilities to talk to people and say, “Hey, I need you to put some people on this.”

Then you have this Business Analyst. And this is a position — I don't know Curtis, I mean, we probably on our projects — I mean, we end up being that person, frankly. Curtis is doing it between him and I on a big project we're doing right now, where we’ll bring in a specialist, like at that steel company. But this is somebody who really understands how the business operates.

So “procure to pay,” “order to cash,” “record to report,” “lead to close,” whatever these business processes are — “plan to make” — whatever they are depending on the type of business, this person understands flows and activities that happen and can go meet with the subject matter experts: the people who really know those areas, but can understand what they're saying.

And then communicate that to the coders, to the people that are developing. That BA is like 50% of their time during the project. That function has to happen. It's that important. And if you don't have that, you'll start to see some gaps in the project that lead to some major issues with, “What are we building this for?” Oh my gosh, what do you mean, what are we building this for?

That Business Analyst hat wasn't being worn. Same thing on the technical side that you got this — you need a person, a gal or guy who can go in there and understand the data today that we have. What's the format of the data? What does it look like? How do we extract it and clean it and put it into the new system? What integrations do we have? What kind of local configurations do we have for offices, or even countries, or, now, work from home? How are people going to be working from home with ERP? That's a technical view.

So then you have the subject matter experts who know each of their functional areas and the end users like I talked about. So you have all these people that — we talk about this a lot, that if all of these people aren't on the same page with why we're looking to change, you're sunk. You're in the Titanic. And you bought a ticket and you're getting onto the Titanic, and you know it's going to sink. Don't do that.

Get all those people on the same page, because they are the most important thing in our minds on a successful implementation. But that's also because we know the good apps. And we know the good implementation partners that are committed and know the industry.

So that one factor of the client-side team means everything. And I think having people that are set up to succeed — Curtis mentioned backfilling, adjusting schedule so people can put the time into the project — you're almost guaranteeing your success with that.

Because then the people will talk. Because like we always say, Curtis, when we kick off projects, the most important thing is to communicate, communicate, communicate. And so if you have a team that's willing to talk to each other, has the time, can work on it, you're going to be in great shape. So it's really, really, really important.

Juliette:

So Curtis along those lines as well, you have done many ERP implementations. What lessons have you learned that would be valuable to share with our listeners today?

Curtis:

Well, I think Shawn may disagree with me on this one, but in order to have a great team, you have to build it. You have to build relationships and that's part of the puzzle. And the application is part of the puzzle. So if you like to do puzzles, these are huge puzzles for you to work on.

For me as a project manager, I use — deliberately — humor to build teams. And sometimes — well, I know I've been successful, and I'm in trouble, when everyone on the team starts chipping in and making cracks about, what's going on, or what I'm doing. Then I know we've made it. We're going to succeed in this project.

And it's meant to be fun. If it's just drudgery, there's no way you can get a good team to go for six, nine, twelve months with drudgery. So I think one of the things that I envy in other people is they're good at rewarding people and taking a moment to celebrate. Or doing the things that it takes to recognize other people as they go.

I'm usually in a PM role, and the PMs are just about getting things done. And I'm not here to be polite or make you get a promotion or anything else.

I think another thing that's valuable is to have people who can be lightning rods. And a lot of — I've had sponsors come up to me all the time, I've had this within the last three weeks: a sponsor will say to me, oh, we can't say that. We can't say that. But you could say it.

So you have to be honest about what's happening in order to get solutions, and if people are afraid of you, afraid to speak out, they're not going to be honest. I'm not going to share and then you're going to get surprised by things.

Juliette:

That's right, you have to be approachable and be able to hear what everyone has to say about what's working and what's not working.

Curtis:

“Funny,” Juliet, you have got to tell me how funny I am.

Juliette:

So funny Curtis, always funny.

Shawn:

Very funny.

Juliette:

That's what is makes you so endearing, Curtis.

So I'm going to ask this question to both of you. Let's say you are at a point where a disaster has already occurred with the implementation, what can be done to recover from an ERP implementation if so?

Shawn:

I can start on that. We had a great client, actually had a perspective client come back to us recently who we talked to a couple of years ago, and they decided to go with another firm for their selection work. And it's disappointing to lose the work for sure, but you go on. And then they called a couple weeks ago, maybe a month or so, or two months ago, and said, “Hey, we need your help on the implementation.

And I was like, “OK, what's happening?” And it was one of the things that we talked about earlier where the project had just gone on and on and on and on. And the implementation partner was pretty good, the software was pretty good. There were some gaps on both sides, but the client side — what it turned out is they weren't really staffed for success on their side, that's what I spotted from the get go. That’s a good way to say it.

So what we did is we came in — and this is a great framework — like I always think on these calls, Juliette, and think about the people listening and those that will hear this later. Like what can you take that's a nugget. This is a nugget: what you have to do on these projects is you have to assess four areas if you're inside a project, and then you're going to reset the timeline.

OK, so I'm going to tell you exactly what that means. You have to look at functionality. What are the functional areas of the business that we're looking to run our software in, and how well does the software match up to that functionality today?

So let's say you're two years in, and you just can't quite finish. You have got to look at functionality first and say, “OK, well it was sales and it was manufacturing, and quality, and inventory, and financials, and purchasing. However you want to describe those seven areas.

Then you've got to look at each one of those seven areas and do an objective assessment to ask where are we at with each of those seven areas? Oh, procurement hasn't had good training, and finance is saying that requirements don't meet what we're looking for. Manufacturing is still testing, testing, testing, wow.

We're all over the place. It's on this project. So you have got to assess each functional area. That's the first thing to do and see where it's really at on the life cycle of the project. OK, then you have to look at your data. Did you just cringe when I said that Curtis, “data?” No, no data is tough, man. It is hard, and you have got to get a list of all the data records, the elements, the entities, whatever you want to call them, different vendors call them different things.

But we're talking about customers, vendors, employees, transactions, purchase orders that are open, or open bills that haven't been paid, or invoices that customers haven't paid on yet. Whatever those things are, chart of accounts, or journal entry, end-of-month balance things. You have got to look at each one of those and you have got to figure out where you're at for real. Like, “we don't have a clue how to get our customers together.” Well, that's not good if you're going to have customers in your new system, because guess what? These systems are all about the data, so you have to assess the data and see where you're really at.

Then you have to look at integrations and you have got to say, OK, what integrations does this application really need to function? Oh, it doesn't need any. Oh really? Well how are we getting those EDI transactions to our vendors who are sending us our supplies? Or, our customers are requiring certain integrations. Or yeah, our ecommerce site has to talk to our ERP.

Or whatever it is: our shipping companies all talk to the ERP. There's always integrations. Very rarely are there not integrations anymore. So assess where those are at also.

The last thing you can assess — and this is a bit of a technical view. But it's also the infrastructure and the technology required to run the application. Like, do we have the iPads at the factories? Curtis. For that one project, we'll talk about that later: “Get the iPads!”

But you really do have to look at that. Like, do end users have the machines they need to run this? Are the servers set up? If it's on-prem, or maybe it's hosted somewhere, OK, is the data center provisioned and we have space and racks and all that stuff? If its cloud-based, that makes it easier for sure. But you still have to think about our printer setup. What's the technical configuration?

So the functional areas, the data, the integrations, and the technical setup. Look at those four areas and then figure out where they are in a normal, cascade software development process of: analysis, design, build, test, change management, training, documentation, all that stuff, cutover prep, and then go-live. There's a couple other things in there, but I'm going to leave them out. Look at those basic steps and if you need to go back on the recording to get all those you can, but go back to each one of the functional areas and figure out where you really are with each of those topics.

And what turned out with this client, we realized that they were really back at requirements definition. The vendor came in and said, “OK, we're ready to implement this software, and here's how you're going to do it.” They start building stuff and the client’s like, “well, I think that's going to work. Well, let's see. OK, yeah, OK, it's done. Throw it over the fence, go test it.” The end users don't test it, the subject matter experts don't test it because they don't know what the hell is going on. It's like well, this purchasing doesn't work anything like we do it.

And then the couple of people running the project are like, “Hey vendor, you need to go fix that. We paid you to go fix that.” They're like, “no, we just give it out of the box.” Two years later, here we are.

So when you reset that timeline, remember I mentioned that you've got to say, OK. If we look at those four areas, and we go back to where we really got requirements definition, then we can move our way forward and go through those steps comprehensively and get to a successful go-live.

A lot of folks that are in these projects that are just stalled, they don't even know why it stalled, so look at those four areas. There's user adoption and training, and some of those other things, but I can tell you that's all going to go back to: Do the feature functionalities fit the functional areas of the business? The better they do, the least amount you have to train, by the way.

So go through those areas, figure out where you're at, and then it's like the blocking and tackling. You can't skip any of those steps, even though sometimes our clients try to skip testing at go-live. Go-live becomes “user acceptance testing.” You have to go through all those steps and you'll make it and you'll get there for sure.

That was a long answer, sorry.

Juliette:

Would you like to add anything?

Curtis:

Yeah, I think the key is often to find the problem. And then to fix it. I can remember a project that I was brought in because it was in trouble. This is the least favorite kind of project I want to be on. It's a big disaster, and you're coming in, and the whole teams demoralized and it's hard to go.

Well, I start meeting with the team and figured out that the guy who was going to make this or break this was the DBA. And he was very grumpy and he would just tell me all the problems over and over and over again. Well, I started making a list.

And he would say something and like I got it's right here. I got the problem. Eventually we built a bond and he said to me, “we're never going to succeed on this project until we get our own test server. We're sharing this test server with three or four other projects. They're jerking it around. We can't get anything done or making no progress.”

I said, OK, I'll go get a test server. He laughed at me. He said, “you will never get a test server. They're not available.” I walked into the sponsors office and I said this project will fail unless we have a test server dedicated to this project. “Oh no problem. We got an extra one over here. We’ll turn it on. You guys will be up in 2 days. Project succeeds.”

Juliette:

Is it that simple? I don't know.

Curtis:

We have got to find the problem, Juliette.

Shawn:

Definitely the hard part though, isn't it, is finding the problem.

We've got so many tools and things, and whatever's on our website, that if folks look at that and see what should be, that's what it is. That's that I've really understood this over my careers. Like here's what you have today. Where's the problem? So you don't know where the problem is, because you don't know how ideally it should look.

And if you understand the ideal scene and then you look at today, and you're like oh there it is, we just need a test server.

Juliette:

Well this is a great start to a very big question, and how to find the problem and find the solution. So thank you, Curtis. Thank you, Shawn, for sharing your expertise and your time.

Shawn:

Thank you, you're welcome.

Juliette:

Thank you everyone for joining us for today. Please let us know if you have any questions. We're here to help answer any questions you can. Call us, email us, whatever, we're happy to help in any way we can. We will have this podcast in a couple, probably a day or two, ready for anyone to listen or share if they'd like to. So definitely check our website for that.

And we'd love for you to join us on our next call Wednesday, October 14th. Cybersecurity Special: The Brave New World of ERP Security. We will discuss the importance of ERP security from penetration testing to system access and permissioning. Please go to our website, www.erpadvisorsgroup.com for more details and to register.

Thanks again everyone for joining us. We appreciate it. 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. Thanks again for joining us. This has been The ERP Advisor.