Software is key to an Association’s success. I believe that every executive should think of their software programs 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 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. How? Best practice: partnering with a specialist experienced in both off-the-shelf and made-to-order software systems. However, if you do not have a resource it also pays to reach out to your network, read online reviews of relevant software providers, and talk to some providers.
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 from you. It's so critical to explain your situation and what you intend to accomplish before each of you begin the "dating process".
Think of the RFI (request for information) as the information step of probing. The final product of your successful RFI is a short list of five to seven vendors whom you invite to respond to your RFP.
By the way, if you work with a software consultant, 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.
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 do:
The best RFPs provide a great deal of specific information about your organization—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:
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:
Self-running demos:
Most companies will provide a self-running demo on a CD or Web site. These demos often show basic functions and let you examine the look and feel of the software. They can be useful for a preliminary evaluation during your RFI process, but they generally cannot cover functionality in great depth. You may find these of value in the “can” during your RFI process.
Live demos:
A live vendor demo lets you see more features, and ask questions while you are reviewing the product. Prepare questions in advance that relate to your organization’s needs, such as those on your checklist, or ask for some hands-on time with a fully functioning system.
I always suggest that the initial demo is about an hour and should be focused on the key priorities outlined in your RFI and RFP. An agenda with each area requested should be provided to the vendor for preparation. If warranted, the second and subsequent live demonstrations are built on the findings of the first and further exploring more specifics.
Demonstrations are so important in a software selection project. As with all steps in software procurement, a good process matters in getting the best results out of a demonstration.
The Role of the Hands On Experience-The How Revealed
I know that this is going to kill a lot of vendors to hear. But, I believe that today it’s important for an individual evaluating software to get their hands on the product. When we are asked to consider making a decision on thousands of dollars and the stakes are so high, I believe it’s paramount.
Granted, their needs to be some parameters in place. For example, a vendor should insist on spending time with the client before handing over the keys. Further, I suggest putting a time frame on the experience too.
I can’t tell you how many times this has eliminated the sales cycle time. And, I believe the challenge of not knowing until after the purchase has been made.
So many software vendors, so Little Time
Market leaders or challengers? Cloud or data center? Evaluating enterprise software is difficult because there can be thousands of requirements and thousands of options too. Ultimately the selection comes down to this: how do you measure the gap between your particular requirements and potential software products?
For many, this can be answered by taking the time up front to step through the right process focused on what can be done but also how it is done too.
Do you have any questions or comments on the software selection process? Please let us know how we can assist you.
Until next time, keep SmartThoughts in mind.
Comments