Writing an RFP for Your Enterprise Resource Planning (ERP) Project? Avoid These Five 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.

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 and instead 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.

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, if there’s an underlying cause, like you’re looking to raise capital and need more robust internal controls and a developed financial reporting system, be transparent. This documentation should help ensure your needs are articulated and help eliminate gray areas.

Thinking a detailed list of requirements is enough

While clear 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 or 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.


Not understanding your total costs

One of the goals of an RFP is to get a high-level cost estimate early on. 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 you didn’t fully understand all the variables related to software acquisition and deployment.

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 even possible.

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, not to 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.

Now that we’ve reviewed five all too common stumbling blocks, do you fully understand the costs attributable to building an RFP? How about the cost of interviewing, scoring and decision making? And then there’s the difficult realization that going through this arduous process doesn’t guarantee success.

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 the world’s most trusted ERP advisor without learning a few efficiencies along the way.