How NOT to Write an RFP for ERP Software: Death by RFP

Mark Canes

Just in time for Halloween we have “Death by RFP”

[Guest post by David Michaelangelo Silva]

RFPs can, and should be, an effective way to outline your requirements to potential vendors. Unfortunately, they can also get in the way of the process. Let’s take a look at some of the problems overly complicated RFPs can pose. (For the uninitiated, RFP = Request For Proposal.)

Too Much Detail

An RFP can be a great way for vendors to get a glimpse of your requirements and business processes. However, sometimes an RFP can get carried away in the details. Sending out a 14 page RFP, for example, may result in very few responses from vendors. Many vendors have policies around the size of the RFP they are willing to respond to, so if you want a good mix of interested vendors it is best to keep the size and details at a reasonably high level.

Large organization with complex requirements and business processes may require a lengthy RFP; however, small to medium businesses would not require the same level of detail. For a small business, an RFP need only be a few pages in length.

Too Specific

Sometimes software seekers get carried away I what they include in an RFP. An RFP should be used to outline business requirements but frequently include specifics such as exactly how they would like a system to work. For example, instead of outlining how they deal with customer information, they might specify that the software needs to have a “customer review screen” that includes “past sales history, contact information and credit limits”. This is often too specific as each software system is different and may present the information in different ways. These specific requests are more appropriate at a later stage such as during a demo when the vendor can show you how the information is required.

To reiterate, it is important to write the RFP from a “business requirement” point of view, rather than a “software functionality” point of view. After all, it is only important to know that the vendor can provide you with the information you need. How they each do so is what will set them apart.

Not Enough Detail

This is rarely a problem but still occurs. For example, you may be searching for software for a primarily distribution business, however, it has not been clearly stated that there are also manufacturing requirements as well. Software to meet manufacturing requirements is often magnitudes more expensive than distribution software so it is important to clearly identify these requirements. In this case, you may consider implementing distribution software to address the vast majority of needs excluding manufacturing, or include it understanding that there is a significant cost difference.

Making overall business processes crystal clear can help eliminate surprises while always remembering to minimize the level of specifics.

Unrealistic Expectations

A common problem, often compounded by one of the others mentioned above, is the desire for significant functionality for very little cost. It is very useful to include budget figures in an RFP to indicate to vendors the range in which you are willing to spend. However, some preliminary research should be performed to ensure your budget is realistic for your expectations of the software. For example, you will not find an integrated inventory, accounting, customer relationship management and eCommerce system for $10,000. Often your budget will have to fall in-line with your requirements or, less optimally, your requirements must fall in-line with your budget.

RFPs with unrealistic expectations will often generate few responses and little engagement but if they do, be warned – you may find a vendor that says they can do what you ask for that price when they cannot. The project will far exceed your budget or their delivery will fall far outside your expectations.

Soliciting Too Many Vendors

A common problem, that usually accompanies an overly detailed RFP, is that too many vendors are solicited. Depending on your requirements, if you send out RFPs to 30 vendors you may get a response from at least 15 which is too much to deal with. Looking at that many vendors may lead you to shop purely on price instead of overall fit. In order to avoid this, you might try to do some preliminary research and only send out the RFP to vendors who seem to be a good fit from some basic research. You might also try software comparison sites to help narrow down whom you speak with.

Aiming for a maximum of 5 or 6 vendors to be short-listed to 2 or 3 is ideal. More than 5 or 6 initially will make it more difficult to pick apart the differences.

Due to the number of possible problems with the RFP process, it is often good practice for small businesses to skip it altogether. It is important to have a good understanding of your requirements but they do not necessarily have to be written down in a formal manner. They can then be taken to a select few vendors whom preliminary research has been accomplished to begin discussions allowing for a personal and dedicated approach which is beneficial.