Software Selection
Step-by-Step!
Infotivity Logo

Quantitative Comparisons Accurately Evaluate
Vendor Proposals. Select the System
Best Suited to YOUR Needs!

 

Software Selection Guide

Successful software selection and implementation begins with a comprehensive project domain specification. This is comprised of four major components:

  • a well-defined list of goals to be achieved by using the planned system
  • a prioritized user requirements description,
  • a system environment specification detailing how, and from where, information flows into and out of the planned system, and
  • a well-organized Request for Proposal (RFP) that effectively documents these requirements to vendors.
The RFP must be done correctly since it will affect almost all subsequent steps in the software system selection process. Many complex tasks must be performed to:
  • prepare an RFP (Request for Proposal) that accurately communicates your organization's software requirements to vendors,
  • distributing the RFP to qualified vendors,
  • use quantitative evaluation techniques on all vendor RFP responses to select the software system best suited to your organization

The five (5) key steps required for proper RFP preparation and response evaluation are described below, and an RFP Master with it's easy-to-use RFP response evaluation toolkit can help you reduce research time, eliminate time-consuming data entry, or make more accurate decisions, during each step as follows:

STEP #1: USER REQUIREMENTS SURVEY - Identification of the business and procedural problems faced by users is one of the keys to selecting and implementing any type of information system successfully. It is during this step the data needed for a quantitative analysis of each vendor proposal is identified or collected, and this will determine the questions that must be in the RFP (request for proposal).

Situations where users must spend valuable time searching for, or correcting, data needed to complete a given task must be identified. Some examples of this situation would be manufacturing order entry on one hand, and document capture in a document management system on the other. Many other examples exist. Imagine the benefits - users can conveniently respond to the survey from their desktop, laptops, and tablets, over your LAN/WAN, intranet, email, or the Web. And you can instantly merge their response into your database without any tedious data entry.

STEP #2: SHORTLIST IDENTIFICATION - It is very time-consuming to review vendor responses to a fully detailed RFP, attend lengthy software demonstrations, and compare all of the proposed systems features. One way to reduce this time drain is to send all potential vendors a brief list of key questions (known as a Request for Information or RFI) covering just the mandatory, "must-have" features needed to satisfy your major requirements. You can then "weed out" those vendors or products that do not have a close fit to your needs, reserving your time to deal only with the vendors who submitted the best 3, 4, or 5 responses to the RFI, i.e., those vendors most likely to meet your needs the best.

Coming up with a list of "must have" mandatory issues can be done rather easily using the information collected in the User Requirements Survey step above. This is also where system constraints can be imposed. For example, if the new system must interface with an existing legacy system, or must used on an existing database, or must provide a certain key software feature, that mandatory requirement should be listed here and used as a means to weed out vendors who do not support that function early.

Use a quantitative, weighted grade point scoring system to determine the best RFI responses. This is very important when a software selection committee is involved because it can incorporate all member comments in a standard procedure. The RFP Master utilizes a powerful, automated weighted grade point scoring function to automatically SCORE all RFI responses to determine which vendors or products should be on the short list!

STEP #3: RFP PREPARATION - Once those vendors and products with the highest potential for being well suited to your needs are placed on the shortlist, the task of preparing a fully detailed Request for Proposal (RFP) begins. Overall, the RFP must do two things - accurately communicate your organization's needs to vendors, and elicit vendor proposals with the least amount of unplanned Q & A sessions from the vendors.

Accurately communicating your organization's needs involves much more than simply presenting a series of questions regarding system features and company history to each vendor. Why? A simple list, no matter how detailed, provides no means of cross-referencing your organization's goals and procedural priorities with vendor responses to the RFP. In addition, a simple list provides no means of enabling consistent vendor RFP responses to be obtained, or analyzed and compared on a quantitative basis. For best results, the questions found in a detail RFP should:

  • be categorized by major organization business and procedural goals
  • be answered with clearly defined vendor responses
  • cross check each other to verify the vendor's understanding of your unique needs (see legal benefits)
  • be directly related to the high level business procedures important to your organization

Obtaining consistent vendor responses is extremely important if you want to compare them to each other! If 3 different vendors answered a given question with YES, NO, and 1st Quarter of Next Year, what do you do with the "1st Quarter of Next Year" answer? How can that vendor's proposal be evaluated? All questions in an effective RFP must be clearly stated so there is no vendor confusion, and they must be worded to elicit a focused answer.

  • Use either YES/NO or multiple choice formats
  • In those cases requiring essay type answers, make the questions detail oriented
  • Electronic or Web RFPs must offer vendor input validation
  • Be sure options such as Not Available (NA) or Not Supported are clearly identified

STEP #4: RFP DISTRIBUTION - A full Detail RFP should only be sent to those vendors with the best RFI responses, 3 to 5 vendors at the most. (see shortlist above). This is because of the time required to distribute RFPs to vendors, and the need for one or more software demonstrations.

Manually copying and assembling a Request for Proposal that is 20, 30, or 50 pages long is no easy task. But even this time-consuming task pales in comparison with the daunting task of manually entering all of the vendor responses accurately! There is no question that electronically distributing an RFP to vendors, and receiving their responses back in an electronic format that can be quickly merged into a database, is needed! But be sure no special software must be installed by the vendor simply to respond to your RFP, since that could require significant support on your part!

STEP #5: VENDOR RESPONSE EVALUATION - Having a well-structured RFP is one thing, but evaluating the vendor responses quickly and effectively is another. Anyone who has manually entered even one RFP for an enterprise-wide system can tell you it takes tremendous amounts of time ! And the issue of saving time is just a small piece of the problem. What about all the formulas needed to calculate financial ratios, or weighted grade point suitability scores, or compare several different responses feature by feature, side-by-side? Just coming up with all the required spreadsheet formulas will take days, unless of course you are a spreadsheet wizard, or wish to rely on an untried and non-integrated collection of stuff found on the Web. The following are required to efficiently analyze and compare vendor RFP proposals:

  • Consistent vendor proposal format that allows for fast electronic processing.
  • Consistent input response types that allow for easy "apples to apples" comparisons.
  • Detailed weighted grade point scoring algorithms that allows for scoring at the individual question level.
  • Financial ratio calculation algorithms for Internal Rate of Return (IRR), Present Value (PV), Net Present Value (NPV), and Payback Period that can be presented in Detail or Bar-Chart format depending on need.

Attending a demonstration of a major software system is usually no small task. All the members of the software selection committee must free their schedules, and time must be spent with each vendor to coordinate the issue of moving equipment and building the demonstration around your organization's data (see why you should always see your own data).

(NOTE: Additional information about using an RFP to collect relevant cost/benefit data is available in the Optimized RFP Guide, available FREE with every RFP Master. Please click this link Optimized RFP Guide Details Form to order separately.)


      
            
      
      

Infotivity Technologies, Inc.
Dandridge, TN 37725-1460
USA

E-mail us at info@infotivity.com

 


       

All RFP examples and content, example templates, and RFP samples questions are:
Copyright 1993 - 2013 Infotivity Technologies, Inc.
Excel is a trademark of Microsoft Corp.
Ready-to-Use RFP, RFP Master, RFP Toolkit,Demo Masters, Example RFP
Demo-Script Template, and IT RFP Template are trademarks of Infotivity Technologies, Inc..

More information about the best methodologies for software evaluation & selection
may be found at the Carnegie Mellon Software Engineering Institute and CMMI Institute