Successful software selection and implementation begins with the identification of a comprehensive project scope (domain) specification. This is comprised of three major components when fully assembled:
Choosing software is done most effectively by using a well-organized Request for Proposal (RFP) that accurately presents ALL software and system requirements to vendors. The RFP must be done correctly since it will affect almost all subsequent steps in the software system selection process. The RFP is the cornerstone of the entire process, and requires the following tasks to be performed:
The major steps required to accurately select a new software system are described below. Each RFP Template Master, and it's matching Software Selection Toolkit, can help you reduce research time, eliminate time-consuming data entry, and make more accurate decisions during each software selection step, as follows:
STEP #1: INITIAL DISCOVERY - This step requires the preliminary identification of all organizational departments, user groups, business processes, software interfaces, and external entities that will be, or should be, affected by a new system. Due to the level of detail involved at this step, it is wise to use a Project Scope Checklist.
Identification of the business procedural and software problems faced by users in each affected department is key 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 and collected, and this will determine the questions that must be in the RFP (request for proposal).
User needs can be quickly identified during this step by using the Work Distribution Chart (WDC). The WDC identifies situations where users must waste valuable time waiting for, or searching for, or correcting, data needed to complete a given task and other productivity roadbloacks and time wasters.
Both the WDC and/or User Survey enable the collection of both productivity roadblocks and estimated time savings over your LAN/WAN, intranet, email, or the Web.
STEP #2: FEASIBILITY ANALYSIS & JUSTIFICATION - You should have accurate information on where productivity can be increased, and how much labor time can be saved, at the end of step one. This can be quickly converted to expense/revenue streams and used to accurately project the economic impact of a new system in each year of its expected useful life. Use the Cost Savings Analysis Tool to quickly calculate important financial ratios such as Payback, Net Present Value (NPV), Internal Rate of Return (IRR), and others neded to PASS or FAIL the proposed software based on its financial impact. This step tells you if the project is worth the trouble. Why proceed with a project if you can earn more simply by putting the money in the bank?
In addition, 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: SYSTEM REQUIREMENTS IDENTIFICATION - User needs are translated into detailed software system requirements during this step. It is crucial that all issues identified in step one are broken out into detail software requirements, workflow logic, and/or other business needs. This task is made much easier by the Requirements Checklist with Fit-GAP Analysis and Workflow Planning Checklist.
The following specific applications are are addressed by:
Customer Relationship Management - CRM Requirements
STEP #4: 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, and then analyzed and compared on a consistent, quantitative basis. For best results, the questions found in a detail RFP should:
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.
STEP #5: RFP DISTRIBUTION - The full detail RFP should only be sent to those vendors with the best RFI responses, three (2) to five (5) vendors at most. (see shortlist above in Step two). This is because of the time required to distribute RFPs to vendors, and the need for one or more software demonstrations per vendor response.
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 imported (merged) into a response 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 #6: 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:
STEP #7: VENDOR ON-PREMISE DEMONSTRATION - Having each finalist vendor prepare and present an on-premise demonstration of tyheir proposed software system is a major step in understanding just what is being offereda 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 preparing the demo area and building the demonstration around your organization's data (see why you should always see your own data). It is extremely important that all vendor demos follow the same format, presenting data in the same order, to make evaluating and comparing the demos easier. All of these tasks are made easire by using a advanced system demonstration script
(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.)
Learn Why These Great Organizations (& many others!) Used Infotivity:
Evaluate & Select Software Systems Accurately!
Return to Top of Software Selection Page
Simplifying Software Selection!
View the RFP Template List
Software Selection Planning Tools:
FREE TOOLSSELECTION READINESS TOOL
WHAT OUR USERS SAY...
"Using your requirements checklist, we did in 2 weeks what it took others three months to do."
5,200+ Facilities Worldwide
Memphis Light (MLGW)
Certified SCM Consultant