Search

RFP's Stink: Getting to the Can and How

Updated: Feb 28



RFP's Suck in Software Selection for Nonprofits

 

Software tools are key to a business enterprises success. And, associations are no exception! I believe that every executive should think of their software vendors as partners in helping support every facet of their organization. Therefore, from time to time executives should take a step back and ask yourself, how is my software partner doing? In this article, I cover some thoughts on how to choose a software partner wisely by looking at "how" and "can" in software selection.

The Best Process Leads to the Best Software Selection

Let’s agree, to start with, that relying on a solid process will get you to the right software decision for your Association—software that meets your Association’s needs now, into the foreseeable future, and fits into your budget.

“There are two possible outcomes: if the result confirms the hypothesis, then you've made a measurement. If the result is contrary to the hypothesis, then you've made a discovery.” - Enrico Fermi

In other words, start with an open mind and a phased narrowing process: an effective RFI (Request for Information) followed by an efficient RFP (Request for Proposal) & then the demo.

The Role of an RFI—The “Can”

In my opinion, with all the vendors and all the software choices out there, jumping headfirst into an RFP is akin to sending out your wedding invites without dating your mate first. Certainly, you may have a pretty good idea by just looking at their online dating profile. But, it’s a hit or miss proposition at best. Yet, sending out blind RFP's from no more than a website session still remain the standard procedure for many organizations today.

That is why I am so committed to an RFI, Request for Information, before an RFP. The RFI is a less formal but still systematic and efficient way to narrow the field of choices. It’s a method that enables you to learn which potential vendors "can" possibly meet your software requirements.

  • First, RFIs require you to be crystal clear about listing all of the functions for which you need integrated software support—such as marketing, membership management, fundraising, event planning, financials, and reporting.

  • Second, RFIs require that you narrow your field of possible vendors.


An RFI should include:

  • Table of Contents

  • Executive summary, or introduction and purpose of the RFI

  • Describe the business use case of the project

  • Outline the key requirements of the organization and even departments

  • Explanation of scope of the software requirements

  • Glossary of abbreviations and terminology

  • Template for the vendor to complete

  • Details of your next step: an RFP or RFQ.

Why is an RFI a valuable step for both software buyer and the software vendor?

  • The RFI minimizes the costs in the process (both hard costs and soft).

  • The RFI allows the vendor to truly understand what is required.

  • The RFI should be a tool to help minimize your time to "explain" to the potential candidates your situation and allow them to determine if they want or are able to participate in an evaluation with your organization.

Think of the RFI as the information step of probing. The final product of your successful RFI is a short list of five or so vendors whom you invite to respond to your RFP.

By the way, if you work with a software consultant who is a specialist, he or she should already have a good knowledge set for the options in your market and be able to avoid time in the software identification area. And, will in many cases eliminate this step entirely!

The Role of an RFP—The “How” explained

I have a confession. The RFP, Request for Proposal, process stinks! I realize that these are blasphemous words coming from a software consultant. But, I truly believe that most if not all RFP's received by software vendors are premature, rigged and a guessing exercise for most software searches today.

In my opinion, the traditional software RFP process is a time drain and broken down process. In fact, when it comes to purchasing software as a service solutions, this process never worked properly in the first place. I believe it is the reason stories about software failures regularly appear in the technical press. These stories are only the tip of the iceberg; people don't talk about most partial or outright failures because they don't want to be associated with them.

But, no matter how hard you try to avoid them, you can't. The RFP is the formal procurement process most familiar to executives and likely you too. I admit that the process will not change but for many nonprofits it should.

If you do decide to produce a formal RFP, you should be targeting a select few vendors to send your well crafted proposal. That alone will boost the success of your outcome exponentially. Please don't waste your time or the software vendors in sending it out to a plethora of options without an RFI already completed.

The Best RFP for Your Software Selection

So, if we have to live with them. Here is what I believe the best RFP's should accomplish:

  • The best RFPs provide a great deal of specific information about your Association—for instance, its mission, its daily work, its internal organizational chart—to invited vendors in order to help them grasp how they can provide the software support you need.

  • The best proposal never lacks specifics: they step you through exactly how that vendor plans to partner with your Association now and into the future to ensure that your new software system offers all the functionality you require in a user-friendly package.

Minimally, an RFP includes the following items:

  • Table of Contents

  • Confidentiality or non-disclosure agreement

  • Information about your nonprofit and the process for selection

  • Detailed extent and scope of the software requirements.

  • Write requirements as closed questions that the vendor can answer with a selection from a drop down list if possible.

  • Ask the vendor to rate how well their products meet your requirements.

  • Priorities of features requested rather than just features requested

  • Proposed time frame for selection

  • Detailed design information and requirements

  • Budget Expectations and considerations

  • Outline your availability to discuss the proposal

  • Evaluation process and award criteria

  • Submission instructions

The RFP audit-The Fail-Safe Step

If an RFI is effective, you should request vendor proposals only from quality vendors who provide what they say they will. But how do you know for sure? The answer is an RFP audit.

  • After reviewing the proposals, ask the vendors follow-up questions, being sure to note down what the vendor responded and how (phone or email, for example).

  • Require each vendor to provide evidence that their software does what they claim in their proposals. Evidence can be in the form of documentation, videos, or a test account online.

  • Go back to your rating sheets and review (or change as needed) your scores according to the responses in the audit process. Annotate your changed or verified scores with audit-related comments.

The Role of the Demonstration-The How Displayed

I could write a book on the value of demonstrations in terms of winning the mind share of my clients. In addition, I could also write about the pain associated with sitting through ones that sucked too. But, demonstrations are critical in finding out the "how". Demonstrations, or demos, will let you see how the software explained comes to life. There are several different types of demos:

1. Self-running Demos: