Writing an RFP for an ERP Project? Avoid These 5 Stumbling Blocks

Writing a request for proposal for an ERP project is not for the faint of heart. Even experienced IT and project managers struggle with the task. It may well be worth enlisting the expertise of an independent ERP consultant to guide you through this process or offer other options. In this blog we’ve outlined five stumbling blocks we have seen companies inadvertently create for themselves.

Writing a request for proposal for an ERP selection project is not for the faint of heart. Even experienced IT and project managers struggle with the task. It may well be worth enlisting the expertise of an independent ERP consultant to guide you through this process. In this article, we’ve outlined five stumbling blocks we have seen companies inadvertently create for themselves.

1. Not providing enough company background

For optimum results, help your vendors help you. They need to understand your business. You don’t want them to have to search your website to try to understand your company. Give them an insider’s perspective.

Begin an RFP with a detailed overview. This should include where you are and where you want to be in the future. Take time to describe your workforce, how your business is growing (or not), and your customer base. Be sure to include:

High level pain points:
Example: Low inventory continues to plague the production floor as vendors continue to miss delivery dates for raw materials.
A sense of where you fit in your industry:
Example: We are the second largest US based manufacturer of O-rings, and what sets us apart is our ability to make unique sizes and colors.
Who will be working on the initiative from your company:
Will it be defined as an IT project or a company initiative? Who is the project sponsor and is there an oversight committee? Will internal resources be part-time or full-time? How will success be measured?

Poorly-crafted RFPs don’t do this well — instead, they tend to focus on elimination points or checklists. When writing a comprehensive company background, you don’t need to give away your “secret sauce,” but you certainly need to be open. Taking time to do it right will also challenge your internal project team to examine your company’s landscape. The more inclusive, the more likely you are to get quality responses from potential partners and vendors.

2. Neglecting to fully explain your current ERP system landscape

Effectively explain what systems and software you are currently running. Describe why you’re switching and what you hope to achieve. What are your assumptions about the risks vs. rewards of new software? Be sure to communicate your real goals to educate vendors about changes you are targeting. Document what you have today, why you’re switching and what your end goals are.

For example, be transparent if there’s an underlying cause, such as you’re looking to raise capital and need more robust internal controls and a developed financial reporting system. This documentation should help ensure your needs are articulated and help eliminate gray areas.

3. Thinking a detailed list of requirements is enough

While clear RFP technical requirements are important, creating an effective demonstration script is more important. The script should hone in on the functionality you are seeking. Modern ERP software can handle standard business processes (think finance, procurement, human resources, etc.), but it doesn’t know how you want your business to operate — and it can't anticipate unique workflows.

Vendors need to show you exactly what their applications can do via a defined script. A script also helps keep vendor responses consistent. It’s important to keep them on track.

You want the vendor to demonstrate if their software can or cannot perform defined functions. If it can’t, you may need to bring in another tool, customize or choose another software. You want vendors to show how requirements would be executed in real time. If you rely on just a list of requirements, you risk the vendor checking off a set of “yes” or “no” boxes, which in the end might not be terribly helpful.

4. Not understanding your total costs

One of the goals of an RFP is to get a high-level cost estimate early in the process. Less than one third of ERP software implementations come in on or under budget, and the reasons vary as to why. For example, your company may ask for unplanned customizations to meet various business needs. Or perhaps the variables related to software acquisition and deployment weren't fully understood.

Software contracts are complex. Expect a contract to contain a multitude of costs besides the software itself, such as ongoing maintenance costs, licenses, etc. Vendor agreements are not one-size-fits-all and are negotiable, but you need to know what and how to negotiate. You’re not only attempting to understand your current purchase, but how the decisions you make now will impact future updates or releases. You want to fully comprehend the incremental costs you will incur.

Also consider what happens to your ongoing costs if your company grows. What you negotiate today will have an impact well into the future. An independent ERP consultant can be invaluable in helping to understand, negotiate and modify a contract designed to work in your favor. This could include incorporating concessions and throw-ins you might not know were possible.

5. Not fully understanding the team you will be working with

The person who is attempting to sell you software or services is destined to disappear once the sale is finalized. You are then turned over to a service/implementation team. Since you will spend the duration of the project with this team, insist on meeting them and getting them involved early on — before you sign a contract. In a sense, you’re “interviewing” them for technical and cultural fit. This is a very important step that should not be skipped.

The service/implementation team should be able to discuss your pain points and provide technical insight into how their software will or will not accommodate your needs. Ask for examples of where they’ve implemented this software in your industry and ask for references. Determine the specific experience of each person in the group. Are you getting the “A” team or the “C” team? You want to end up with the right people who along with your own internal team will be accountable for success. If you don’t feel good about the team don’t be afraid to call a time out. The seller may be able to substitute other resources, or maybe it’s just not a good fit.

Summary

The cost, time and demands of the RFP process may or may not be the best path for your organization. If you think an RFP is your only good option, talk with us. We’ve introduced other streamlined methodologies with proven results. We didn’t get to be one of the world’s most trusted ERP advisors without learning a few efficiencies along the way.

Juliette Welch: Good afternoon everyone. Thanks for joining us for today's call: Why it seems so difficult to write an RFP for your ERP project.

Shawn Windle will be 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. 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.

Today's call we will touch on how to avoid the stumbling blocks and offer tips for constructing an effective RFP.

It is meant to be interactive. But should you have thoughts or questions after the call, please visit the ERP Advisors Group website and simply hit the contact button to send us a message. We would love to hear from you.

It is now my pleasure to introduce Shawn, would you like to take it away?

Shawn Windle: Sure. Thanks Juliette, I appreciate your introduction and thanks for joining us for our call today: Why it seems so difficult to write an RFP for your ERP project.

So, I will go through a couple things here on the call. I'm going to talk to — a really good background on RFP's, what it is, why companies build one, and why we as a firm do something a little bit different.

But then I'll get into the stumbling blocks that Juliette mentioned here in the introduction on some very specific things to look out for.

So hopefully, as always, you'll get some very actionable ideas from the meeting here to help you with exactly what you're working on in your ERP initiatives right now.

So, let me start with what is an RFP and why is it used?

Of course, the RFP stands for request for proposal and the general purpose behind an RFP, of course is to capture requirements and needs and wants and information that then you send to vendors and those vendors can take a look at the information and come back with some idea of what their solution would look like to meet those needs as well as pricing and timing and other kinds of important information related to what you put in the RFP.

Pretty basic. But the interesting thing about why it's used around ERP selections is because it's a way to normalize the data that you give to different vendors. And when I say normalize, I really mean giving the vendors the exact same information for which they will make their decisions from.

So, if you're on the phone talking to one vendor and then you get on the phone talking to another vendor, you may say different things to them. They may have different questions that lead in different directions, so the purpose of the RFP document is to really give the vendors the exact same information. So super important in that aspect.

The next point here that I wanted to talk to is, what are we really trying to accomplish with this document? And from the ERP Advisors perspective kind of the inside scoop in the trenches what we're really trying to do is to make sure that the vendors have as much information as we can give them about our clients and about their projects.

So, this is a little bit different than you'll see, even with other ERP advisory firms as we've seen their information that they created, like we're really trying to say to the vendors look, this is the problem. These are the problems we're trying to solve with what could be your software if you qualify and make it all the way. Can you really do it or not?

It gives the vendors a very objective way to view what is important to us and to our clients. And then they come back to us and say, yes, we could do this. And yes, this is what the cost is.

So that's what we're really trying to accomplish with the RFP is to communicate information about the project so that the vendor can look at that and make decisions on if they even think they're qualified, and then if they are, tell us what they can’t do as part of the RFP process.

Now something that we do that's a little bit different than — well, maybe it's a lot different actually — than other advisory firms as well as even most clients that are doing RFP's on their own, so it I really want your ears to perk up on this — is we do a request for information versus a request for proposal.

Well, what’s the difference, Shawn? It's an “I” versus a “P” like it's not that big of a deal. Little curvature on the top of the “I” to kind of make it a “P” like that's the difference.

Well, kind of, but here's the reality of most RFP's if not all of them is that the vendors are only given a subsection or subset of information to make a very big decision on for the vendor as well as for you.

And so then, to ask the vendors to give you a proposal off of this subset of information that's in the document is risky. It's actually very risky. I wouldn't bet my job on the numbers that come through in an RFP.

Just recently one of my senior consultants and I were doing a selection for a mining company and we had some RFIs that came back with some pricing and then we started going through the vetting process, got down to the finalists and we’re starting to get the actual price is coming in and the prices are actually lower from what was in the initial RFI.

And it turned out that the scope was just smaller and that we're going to push out some modules for implementation. So, the vendors didn't know that in the RFI — they didn't know what we didn't even know exactly what our timing was going to be for the modules to be implemented; we kind of evolved that as we went through our selection process.

So, that's why we use an RFI document, because we're basically saying to the vendors, here, we want information from you, not a proposal, but we do want high level pricing, timing, your experience, some other things to help us decide if we should even bring you in for a demonstration process.

So that's why we use an RFI. We stay away from RFPs because an RFP again means we're going to put together this detailed pricing and costing. And do we include discounts and all that stuff? And it's like, no, just give us high-level information about your pricing.

That's really what we're shooting for with our RFI process.

So, with that background information, I do want to talk about the stumbling blocks to look for when you're putting together this request for information/request for proposal document.

These are some things that will help you that I really think — I really wish — that everybody understood because of a lot of time if you look at the amount of time that companies spend building RFP's, I'll just say RFP's, and then the amount of time that companies are real people spend answering RFPs and then the amount of time people spend evaluating the responses to RFPs — it's easily in the hundreds of hours for even a midsize selection project.

If you think about all the projects that are happening throughout not just the US but also Canada and even beyond there's millions, if not billions of dollars that are wasted on these RFP processes.

So again, for your sake, please listen to these stumbling blocks and what to do about it. So, I've got five that I'm going to go through here.

So, the first stumbling block is the RFP is too focused on elimination points on the vendors and not enough focused on educating the vendors about you.

So, what I mean there is you really need to provide some company background. I mean you can always point them to the website, but tell the vendors what you do, what your line of businesses are, and tell them what you have today for software as well so they've got some idea of what you're coming off of.

And it's really important to tell them why you're switching. Like what do you hope to achieve by going through this switch, which we know is risky and is going to be expensive, like why are we doing that?

And the last thing to keep in mind here, too, that you should be able to communicate are the real goals that you want to accomplish with the new software.

So, saying we want to get off of QuickBooks and we want to get onto a more robust general ledger system, okay, well we had some clients that have been $100 million in revenue that have still been running QuickBooks, so that's not the real reason why you couldn't get off QuickBooks.

The real reason could be because we're looking to go to market for some more capital and we need to have more internal controls built into our financial system. Therefore, we need to move out of a QuickBooks type application that doesn't have hard closes and we need the ability to have more Sarbanes-Oxley level controls and our financial.

That would be a good example — we should write that down and put in our next RFI. But that's a real goal that we're looking to accomplish with the software.

So again, focus on educating the vendors about you, not necessarily just eliminating them with the documents. Those key points were include your company background, what you have today for software, why you're switching, and then what the real goals are that you want to accomplish with switching.

Now the next one is do not provide just a list of requirements and the criteria of met in the software, customization required, third party bolt-on, or not met. Don't do that. I’m telling you don't do it.

I wish some of the other firms that that we work with would understand that.

What you do want to do is make a demonstration script. So, you need to tell the vendors what functionality you're looking for. They have to be able to see your list and say, well, we don't do that or well, we definitely do that. You have to give it to them.

But do it in the form of a demonstration script and what I mean here is, it's very easy to go online and go get a list of just general requirements or the standard requirements that every app is going to be able to meet, especially in areas like CRM or HCM — human capital management — or even financials for very standardized business processes.

Like you can get a list of requirements pretty easily but that's not really what you want to tell the vendors you want the app to do. You want them — what you want to tell them to do is how you want to operate your business in main software. It doesn't have to be perfect because you might be flushing that out a little bit but go ahead and say for something like human capital management.

Here's how we want to handle the applicant tracking system — we want to be able to create a job request, a requisition. We want to have it approved by a manager. We want the HR group to approve it. Then we want to publish it on these sites. And we want recruits to be able to respond to that and it goes directly into the ATS system.

There's a lot more detailed requirements you may want to put under that, but that kind of a flow. And by communicating requirements in that flow, the vendors will be able to show you exactly what their applications do around that.

And it also tells them like, well, these guys really know what they want here so the vendors can say, well, we have this really kind of lower end human capital management system, but it doesn't do that, so we would have to bring in another tool.

But it tells the other vendors that do have that like, hey, I see what these guys are wanting here and I can show them that.

See that's the difference that we look for in our RFIs is we went to vendors to show us our requirements, show us the script, show us their app can do what we're looking for and not just have some checkbox that says yes. So really important.

Now the next stumbling block that that folks can run into when they're putting together in RFI is they don't really get the experience of the partner that's going to be implementing.

So, the focus becomes more on software and really around the functionality of the apps and much less around what a partner can do, because — I wrote a blog entry several years ago — I think it was the shortest one — and it basically said, choose an implementation partner that you're willing to bet your job on because you are.

And you can have the best software in the world but if implementation partner isn't good, then your projects have to just — it's just you're sunk. There's no other way to say it.

So, in your document, in your RFI.RFP, maybe you really want to focus on, not just here's the software demonstration script we need to see but tell us about the implementation partners and the experience that they have with similar companies in your micro vertical.

So not just oil and gas, but oil and gas field services, or not just professional services, but professional services engineering firms. Whatever it is, ask those very specific questions so that you make sure you have a partner that has those needs.

Now sometimes you will do an RFI or RFP that goes directly to the software vendor. We recommend that pretty early on in your process that you have the vendor choose the partner that's going to be part of your selection process because you want that partner to hear everything that's going on in the selection. Don't have him just come in at the end. You want him involved as early as possible.

So, the second to the last stumbling block I want to talk about is around costs.

You really do want to get a good understanding of the estimated cost that you're going to have to incur to implement each software solution that's responding to your RFI or RFP.

Now we talk a lot about costs on these trusted advisor calls, which I think it's one of the areas that we help our clients out with the most because they don't realize all the variable costs that they're going to get and have to incur as part of the processes.

But your RFP or RFI should have a section that lays out costs in the following categories. It should definitely figure out what's the software cost, and for that you're going to have to provide some user accounts by module.

So, you're going to need to know a little bit about the software to figure out what the users are and what the modules are, but you've got to provide that so that you can get an estimated software cost.

Then you can ask him what the implementation cost estimate’s going to be based on the modules that you're looking at selecting, and what they're telling you you're going to need from them.

You also want to ask about any other kinds of costs related to additional licensing or other software that you have to get as part of their offering. So, for instance, some vendors will require you to license as separate reporting tool, or there may be some other kinds of operating platform apps that you have to get, too.

So you want to ask, are there other software costs that you have to incur.

And then you also want to ask about hosting costs, or if it's software as a service that should be covered, but ask about any technology platform, incremental costs that you're going to have to incur, too.

Then you can always ask the question of just other and then please explain what additional costs we would have to incur with part of your software solution.

So, it's a big roadblock. It's getting really good cost estimates out of RFPs and RFIs, but if you ask those questions you're going to be in a lot better shape.

Now our last item here that we have for stumbling blocks is when you're getting information about the overall solution, you want to make sure that you're in touch with and working with the right people from the vendor.

So, this kind of goes back a little bit to getting the implementation folks involved and engaged early on.

So, here's the deal, most software companies and most software implementation firms will have a sale team, and then they have a delivery team. So, the sale team is focused on the pursuit of the project and getting the deal and working through basically the ERP process and then once it's approved then they'll pass it over to the service team.

And I'll tell you the best thing you can do — I said this earlier, but it's true — get that service team engaged as early as possible.

So that way — again, one of the biggest stumbling blocks with this RFP is cost, like we said. But when you have the right people that are really going to be held accountable to your implementation coming in on budget.

When you have those people engaged early on your RFP process goes so much better because you're ultimately — at some point those people are going to show up in your office and you're going to look them in the eye and you're going to say I remember what Shawn said — I'm betting my job on you.

Well, you're going to look them in the eye and you need to know that they're worthy of your trust, very honestly, and so having those people engaged, getting them involved early, you'll get better cost information than sometimes the salespeople can even provide and you're going to have a much better feel for what you're really about to get into.

So, those are the five stumbling blocks we really want you to look out for how to get around those, but overall the RFP or RFI is a great function to put into a selection.

We help a lot of companies with these. A lot of companies come to us simply to ask us to write these, because we can do it fast. We've got templates, but we just know the process to extract information out of our clients and check it out and put it into the RFI format.

But it's a really good document that that can help normalize the information with your vendors.

You can tell the vendors this is what I want to see from you and from the terms of a demonstration script. You can get a really good feel for their applicable experience in your market. You can get a good idea of costs. And then you can get the right people engaged early on in your selection process.

So, use an RFP. Use an RFI.

We're always here to help. If there's anything that we can do, please don't hesitate to give us a call. We can get you going for sure in the right direction.

Juliette, I think I'll pass it back to you.

Juliette: Okay, great, thank you Shawn. That was a lot of great information. Thank you again everyone for joining us for today's call. As Shawn said, please let us know if we can answer any questions. Call us or contact us through our email.

Our next call is Tuesday, February 12^th: Surprises you don't want to have during your ERP implementation.

In this next edition of The ERP Advisor, we will discuss how to structure your project so you can identify surprises and handle them quickly before they turn into something disastrous. Please go to our website erpadvisorsgroup.com for more details and to register. Thanks again.