5 Tips for Writing a Successful Software RFP

“Between calculated risk and reckless decision-making lies the dividing line between profit and loss.”

Charles Duhigg, Pulitzer-prize winning reporter, New York Times

This statement is very relevant to the process of buying and implementing software. There’s always risk involved with any new investment—but there’s a way you can lessen that risk and make a more informed decision when it comes to your new system.

How? Create a request for proposal (RFP) that outlines your requirements and send it to potential software vendors. They’ll tell you how their systems can meet your needs, and you can evaluate each option to choose the best fit.

To help you create an effective RFP, we’ve made a list of key tips and important considerations.

Here’s what we’ll cover:

Is a Formal RFP Right for You?

Tip # 1: Provide Context Right off the Bat

Tip # 2: Cloud vs. On-Premise: Know Your Deployment Method

Tip # 3: Use a ‘Reverse Engineering’ Approach to Create a List of Requirements

Tip # 4: Make a Requirements Spreadsheet

Tip # 5: Separate Top Requirements From Wish-List Items

Key Considerations

Is a Formal RFP Right for You?

Writing a formal RFP takes a lot of effort. Before jumping in, examine whether the time and expense involved will significantly delay the return on investment for your new software.

You may want to skip (or delay) a formal RFP if:

If you aren’t ready for a formal RFP or are unsure whether you need one, Uder suggests a request for information (RFI): a one-page list with a few bullet points describing what you want to accomplish with new software. Alternatively, you can simply request a demo.

If you are ready to write a software RFP, simply follow these five tips…

Tip #1: Provide Context Right off the Bat

Your RFP is a tool for finding the best software for your situation. If you don’t include all the details of that situation, vendors won’t know if they can give you what you need.

Michele Ellner, director of marketing at Montage Talent, an interviewing-technology vendor, says it’s important for her team to understand a company’s motivation for change.

“The more we know about their hiring landscape today [and the] processes and tools [they have] in place, the better we are at constructing a solid response that emphasizes the right things,” Ellner says.

John Uder, business development manager for software deployment agency AVF Consulting, agrees it’s important to understand a buyer’s context up front.

His team wants to see a summary on the first page of the RFP that includes:

• The main goals and objectives of this project

• The desired timeline

• Any existing software and licenses

• Any existing hardware

• Availability of IT personnel

• Your operating system

Tip #2: Cloud vs. On-Premise: Know Your Deployment Method

When writing your software RFP, you should understand the basic differences between on-premise and cloud-based deployment. In simple terms, on-premise means you host the software on your own servers, while a cloud system is hosted on the vendor’s servers.

Whether or not you know which deployment method is best for you, provide a thorough description of your existing IT infrastructure and capabilities in the RFP. You can state whether you’re leaning toward one method or the other, but be sure to explain why. This should give the vendors enough information to make a recommendation.

Ellner says she often receives RFPs that are contradictory in this regard.

“We see many prospective clients describe in their narrative their intent to buy a [cloud] solution, yet the nature of the questions that follow are clearly written for an on-premise purchase.”

Michele Ellner, Director of Marketing, Montage Talent

Tip #3: Use ‘Reverse Engineering’ to Create a List of Requirements

Your list of requirements is the “meat” of your document: Uder describes the RFP as “a requirements-gathering” or “gap-fit analysis.” The challenge is to accurately identify your requirements and communicate them to the software vendors you’re considering.

One approach is to use a reverse engineering technique: Instead of just listing all the requirements you can think of, first research relevant vendors and see what capabilities their systems offer.

Chris Doig, CEO of software evaluation and selection agency Wayferry, says you can learn about vendors’ functionality by:

• Searching the Web

• Checking vendor websites for documentation or product demo videos

• Contacting vendors directly

You can also learn what features and functionalities are offered by reading online reviews from other users. Check vendors’ sites for product forums, which contain testimonials from actual customers. Visit online review sites, or check out Software Advice’s website: We have product pages for thousands of software solutions, which contain real user reviews.

Tip #4: Make a Requirements Spreadsheet

According to Uder, a RFP requirements list can contain 800 to 1,000 line items. He recommends organizing them in a spreadsheet that vendors can enter their responses in directly. This will also make it easier for you to compare vendors side-by-side.

Create a requirements spreadsheet by following these steps:

• Use separate tabs for different functional areas, such as general systems, accounts payable and receivable, reporting etc.

• Within each tab, list all the requirements for the given functional area in one column. For example, “reporting” might have requirements such as custom reports and chart/graph creation.

• Make a second column for the vendor to fill out, indicating whether their software offers the functionality to meet each requirement. If it does, have the vendor enter “yes” or put a check mark; “no” or an “x” if it does not; or “customization,” if the software can meet the requirement, but not right out of the box.

• Create a third column for “comments.” This is where the vendor can elaborate on any of their responses in column two.

Sample RFP requirements matrix via AVF Consulting

Tip #5: Separate Top Requirements From Wish-List Items

Be sure to distinguish top requirements, or “must-haves,” from “wish-list” items, or items that would be nice to have. Not doing this can waste time as the vendor scrambles to figure out a way to meet all your needs—even the less crucial ones.

When you create your requirements spreadsheet, consider adding a column to indicate the priority level of a requirement. This allows you to sort the list by priority level. It will also show you which vendors deliver the greatest number of must-have items at a glance when evaluating proposals.

Uder estimates 10 to 20 percent of items listed as “requirements” are actually wish-list items, and speculates that this information is sometimes left out so vendors will not ignore those items or give them less weight. However, this lack of communication and context could cause you to miss out on a good software fit.

Key Considerations

Here are a few more things to consider as you create your RFP:

Create a glossary of terms. Creating a glossary of the terms that appear throughout your RFP can eliminate confusion. Uder says a lack of clarity leads to hours of back and forth.

“Because they’ve been using a system for, on average, 10 years … the terminology is very product-centric. For example, for grants, everyone names [them] something different. Some call [them] contracts; some call [them] projects; so it’s very confusing. It would be wonderful if they could define … what do they call a project? What do they call a grant?”

John Uder, Business Development Manager, AVF Consulting

Don’t send your RFP to too many people. The more people you solicit for a proposal, the better chance you have of finding the best match, right? Actually, this isn’t true. Silva points out that sending your RFP to too many vendors will dilute the results and make it difficult to narrow them down to the best match.

Do in-depth research and send the RFP to no more than five or six vendors, so you will not be too overwhelmed to perform a thorough analysis of the candidates.

Don’t rush the responses. Uder says it takes a minimum of three weeks to prepare a thorough software proposal—so give vendors at least three to four weeks to respond. Be wary of any vendor that responds in two weeks or less. This could be a sign the vendor didn’t perform a “healthy analysis,” and rushed the proposal out with promises they can’t necessarily deliver just to be competitive.

Want some help finding a software solution? Call Software Advice at (855) 998-8505 to speak to one of our Advisors. In less than 15 minutes, they’ll send you a detailed list of recommended products, for free.