This document has two purposes:
In a study of more than 8,000 software projects, the Standish Group found that many (40% or more) software projects failed outright, or failed to achieve their projected savings and benefits goals, because the software selection and implementation decision were based on
Unlike a simple RFP sample or an online software features comparison web site, the tools in each Infotivity RFP Template Toolkit utilize detailed requirements criteria and proven software selection & evaluation techniques to provide actionable, time saving information and assistance at each step of the software selection process. These steps are:
Importance of an "Integrated" Approach
But before going any further, the term "integrated" should be examined as it relates to eliciting vendor proposals and selecting a software system correctly. The term "integrated" is appropriate due to the fact that any large business system is comprised of many things other than the software used to implement it. Examples are many:
The Steps Needed to Select Software Correctly
Save time and improve the results obtained during each step of the software selection process using the tools found in the Infotivity RFP Template Master & Response Evaluation Toolkit.
Selecting the best software to meet the needs of a specific organization requires much more than simply comparing the features of competing software products and then picking the one with the most "must have" features. This is especially true if the features lists being compared were created by a third party who does not know anything about the organization's internal workflows, or worse yet, by the product vendors themselves. The software features lists available on the Web or through most commercially available software evaluation tools are done at the summary level, which mandates a very loose definition of what makes up a specific feature or function. This loose definition overlooks many major issues that must be taken into account when making a software selection decision.
The steps that make up the process of selecting the correct business software for a given organization are many, as illustrated in the flowchart shown in Fig. 1.0 below. Each block in the flowchart is numbered for cross-reference to each step discussed in this document.
Fig 1.0 - The Software Selection Process (Not Including Demonstration)
A software selection project usually starts at the Initial Discovery step (Flowchart Box 1 above), during which the information used to justify the need for a new system is collected and project approvals are obtained. The project then moves on to the Requirements Identification step for more detailed requirements identification. Each step is completed all the way to the last step of making the final selection decision.
The use and benefit of each executable file found in an Infotivity Software Selection Toolkit is discussed as needed for each step in the software selection process. There is no requirement to use all of them.
The sequence in which these tools are used usually follows the steps of a typical software selection project, discussed below. A cross-reference to the corresponding box number in the RFP Process Flowchart above is shown in blue.
Step #1 - Initial Discovery ( See Flowchart Boxes 1, 2 )
Many software system acquisition projects start because of user dissatisfaction with the system currently in use. Questions such as "How can we improve things?" or "Should we buy a new system or fix the one we have?" are heard quite often. None of these questions can be answered until the problems causing the dissatisfaction are identified. The old saying "You can't fix it if you don't know what's broken" is very true indeed.
It is very tempting to jump right in and start creating a list of "software requirements" at this point, but that would be a serious mistake leading to an incomplete and/or incorrect requirements list, or even worse. Why? Most users do not have the knowledge needed to generate a true software requirements specification up front. But they do know about what the current system does NOT provide to help them do their job better, and what is causing them to loose time, on an every day basis. It is better to first identify those things, then use them as a guide to more extensive, more thorough, analysis in a later step.
The two tools discussed below, the User Needs Survey, and the Work Distribution Chart (WDC), enable users to easily document their problem areas in terms they already understand. Both collect information that identifies how much time is wasted, and where that time is spent, on a daily/weekly/monthly basis. This is very useful in determining the true scope of a software project, and identifies all problem areas where additional research must be done. Very simple and very effective.
User Needs Survey
The purpose of the activities performed during this step is to gather the basic information needed to identify just what a new system could (should) do compared to the system currently in use. What is needed is to accurately and quickly identify, document, and quantify business and user problems and their causes. The best way to is to conduct a USER NEEDS SURVEY (also called "user needs gathering") with the User Needs Survey that comes in the Toolkit (user-needs-survey-mm-yy.xls). This extremely easy-to-use survey tool requires no training or prior knowledge of software system features, and should be sent to all users. The questionnaire enables each user to easily document the problems they encounter on a daily/weekly/monthly basis, and estimate how much time is wasted on each.
NOTE: The Infotivity User Needs Gathering Survey shown below in Fig 1.1 enables end users to document their day-to-day problems, and automatically calculates the TOTAL time wasted so you have good data to use in the feasibility analysis discussed later Step #2, the Feasibility Analysis.
Fig 1.1 - User Needs Survey
Using the User Needs Survey shown above is more cost-effective and productive at this stage, especially when compared to the practice of using a stripped down version of an RFP as the source of survey questions. A stripped down RFP can be very intimidating to end users, who at this point must be given something less overwhelming and more understandable than technical RFP criteria. Why is this so? The answer is that most users do not know about detailed software features or database techniques. What they do know about are the problems they face when doing their jobs each day.
NOTE: Since the information collected by the User Needs Survey is specific to a given user and business process, it can be used directly for establishing benchmarks to be used for measuring ACTUAL productivity, performance, and cycle time improvements after the new system is implemented. Using an RFP is much more difficult, since an RFP collects more software feature specific data that must be interpreted and filtered before benchmarks can be created.
The User Needs Survey Questionnaire is ideal because it allows users to respond in their own way, and it is not written in "software feature-speak" that many users simply do not understand. The goal is to quickly collect user needs along with a good estimate of potential time-savings, not bury the users under hundreds of unfamiliar software features. Even worse, many users simply put off completing a survey they do not understand. The User Needs Questionnaire is designed to alleviate these problems. This tool as a "memory jogger" and input collection tool to all users to follow when listing their needs and problems. Remind users to enter the average amount of time that could be saved at each point.
Work Distribution Chart (WDC)
Another tool that is also extremely useful during the Initial Discovery step is the Work Distribution Chart (WDC). The WDC (wdc-iti-yy.xls) is part of the RFP Template Toolkit, and it enables users to quickly identify and record how their work time is spent by activity type. Use this simple, easy to use tool to quickly identify workflow bottlenecks and their causes. A typical screen is shown below in Fig. 1.2 - Work Distribution Chart:
Fig 1.12 - Work Distribution Chart
Users simply select the activity type, enter a description of the specific task, the business process, and then how much time they spend on average doing that task along with their opinion about how efficient the task is. Completing a WDC produces precise, actionable information very useful for identifying:
Step #2 - Feasibility Analysis & Justification ( Flowchart Boxes 3 & 4 )
The next part of the Initial Planning step is to perform a financial FEASIBILITY ANALYSIS of "Fixing the Current System" versus "Buying a New System", based on the data collected in the needs survey. You can obtain a summary analysis of how a potential new system will impact your operations financially by entering the time saved results and your organizations investment criteria into the Cost-Savings analysis tool (cost-savings-analysis-yy.xls) to generate data needed for cost justification of the new project.
Fig 1.21 - Cost Savings Analysis
The results of this study are usually presented to top management for official, formal approval of a project to either acquire a new system, or simply fix the current one, as required.
In most cases the step of identifying and collecting detailed software system requirements officially begins once the project becomes approved and sanctioned by top management.
Step #3 - Requirements Identification ( Flowchart Boxes 5, 6, 7, 8, 9, 10, 11 )
Most new system acquisition projects will need to expand on the information already collected during the Initial Discovery step (described above) to prepare a full system requirements list. It is during this step that the Project Scope and a detailed system functionality list is finalized. So the first thing to do is to document the existing system and all of the problems users encounter when trying to work with it every day. The resulting document is known as the "AS-IS" state of the process.
One of the best ways to document the "AS-IS" state of the systems currently in place is through the use of what is known as GAP-Fit analysis, a formal process of identifying how well an organization's current system fits its requirements on a day-to-day operational basis. GAP-Fit identifies WHERE problems are occurring, WHY they are occurring, and HOW BAD is each problem? Places the current system does NOT Fit, i.e., meet, a certain requirement is labeled as a GAP. The term GAP is derived from the early fit assessment terms Good, Average, or Poor. A typical GAP-Fit matrix is shown below. Users respond to each requirement with information about the existence of a GAP, their opinion about where the GAP is located, and what it affects. A GAP Score is calculated to indicate the severity of the GAP.
Fig 1.31 - GAP-Fit Analysis Matrix- Overview
Please see the file "gap-fit-appname-mm-yy.xls" for a GAP-Fit Matrix using requirements specific to each application. More detailed GAP-Fit information is available at http://www.infotivity.com/fit-gap.html.
Infotivity provides the GAP-Fit matrix above combined with the hundreds, or thousands, of functionality requirements contained in each Infotivity RFP. This results in a very detailed GAP-Fit Requirements Checklist. As an example, one section of the Document Management Requirements Checklist is show below in Fig. 1.32 ( http://www.infotivity.com/http://www.infotivity.com/dms-requirements-checklist.html ).
These detailed checklists allow users and/or business analysts to quickly and easily create very detailed, accurate, and well-documented software requirements.
Fig 1.32 - GAP-Fit Analysis - Importance
The information gathered in the User Needs Survey, Work Distribution Chart (WDC), and Requirements Checklist w/GAP-Fit checklists, discussed above, describe the "AS-IS" state of the software system currently being used. The "AS-IS" state of the current system is key to IDENTIFYING YOUR SYSTEM REQUIREMENTS. You can't fix something unless you know where it is broken, and the "AS-IS" statement does just that. Even if it is an entirely manual and undocumented system, it is still a "system" making up a part of the business. It is still a "system", for example, even if the maintenance schedule for each vehicle is on a spreadsheet, and the time spent on each maintenance task is picked up through your Time and Attendance system, and tracking all warranties and parts inventory is done manually. A key employee knows how all the pieces of this system fit together - it is job security. The "AS-IS" study should uncover many known and hidden requirements, and should identify which problems are encountered at each step of the process. Each problem should be analyzed in terms of how much time is spent dealing with it each week, month, or year, (as appropriate) and WHY the problem occurs.
Once the "AS-IS" state is known the task of identifying the "TO-BE" state, i.e., what is needed to correct each problem area, is straightforward. A change in procedure and the system functionality needed, if any, is easily determined. The Infotivity Requirements Checklist with GAP-Fit Analysis can be used at this step to accomplish the following:
PROJECT SCOPE - the Requirements Checklist contains many criteria about vendor capabilities, system interface, system functionality and reporting needs, security, implementation, and support needs. These can be used as a checklist to determine just what is needed and from who and/or what it is to be obtained from. This is the Project Scope.
BUSINESS PROCESS REENGINEERING/ENGINEERING (BPR) - may be required to fully identify all the requirements of a given business process. This is especially true if this is the first time a business process is being automated. The Workflow and Activity Checklists (wf-requirements.xls), shown below in Fig. 1.33, and (activity-data-wf.xls) provide templates for the tasks involved in a typical BPR project.
Fig 1.33 - Workflow Requirements Checklist
Step #4 - Finalizing the Request for Proposal (RFP) ( Flowchart Box 12 )
Once the "TO-BE" has been identified the task of modifying the RFP questions (criteria) needed to address special "TO-BE" issues comes up. The Infotivity RFP is designed specifically for ease of modification. "RFP-usage-mm-yy.doc" contains an MS Word document describing the organization and usage of the RFP. Online Help is also available throughout the RFP, especially Row 2 of the RFP Tab.
This documentation explains how an Infotivity RFP Template enables you to quickly and easily send an RFP to vendors that accomplishes the following:
1. Queries Vendors using RFP Requirements Tailored to Your
2. Obtains Concise, Consistent, & Easily Compared Vendor
3. Automatically Calculates the Weighted Grade Score of each
4. Automatically Determines the Supportability (Quality) of each Proposed
5. Enables You to View "Side-by-Side" Detail Response Feature Comparison of Vendor Proposals
6. Enables You to View "Apples-to-Apples" Evaluations of Vendor Proposals
7. Impartially Identify the Best Solution
All RFPs are organized so that it is very easy it is to use basic Excel commands to modify the RFP to suit a specific organizationís needs.
Details about the layout of the RFP document and HOW the above capabilities are provided are discussed in "RFP-usage-mm-yy.doc". Please refer to that document for more details.
EMBED YOUR "TO-BE" REQUIREMENTS - the RFP (rfp-app-name-mm-yy.xls) can be easily customized using the basic Excel commands for Adding, Changing, and Deleting rows. To delete a row simply highlight the entire row then delete it. Inserting a new row is done with "Copy and Paste Special", and so on.
Space is provided in the RFP for a Project Background section. Some people prefer to have a large background section while others do not. The need for this is dictated by the project. If you are writing a large background section the Infotivity RFP provides space for both types. A Project Background Outline template is found in " background-mm-yy.doc".
The Request for Proposal (RFP)
The RFP itself is found in the Excel file "rfp-app-name-mm-yy.xls". This is the actual RFP, and is the only file you need to send to vendors. Each RFP Template Master is extremely detailed, and comes pre-loaded with more questions and criteria than any other RFP template in its given industry.
The RFP is designed to be CUSTOMIZED quite easily, and as such, all the security is turned OFF to ensure you can modify it quite easily. You can turn the security ON again prior to sending the RFP to vendors,
You can send it to vendors as a Zipped or Unzipped email attachment, or let the vendors download it from a password protected page on your web site or ours at "infotivity.com".
The MS Word file "RFP-usage-mm-yy.doc" contains an MS Word document describing the organization and usage of the RFP. Online Help is also available throughout all Infotivity RFPs, especially Row 2 of the RFP Tab.
Step #5 - Sending the RFP to Vendors ( Flowchart Boxes 11, 12, 13, 14 )
There really is not too much to say about this step. There really are not that many issues to discuss. The Infotivity RFP document can be distributed to vendors as needed for your or your client's software acquisition projects, in either Zipped or Unzipped form as email attachment, on a CD, or let the vendors download it from a password protected page on your web site or ours at "infotivity.com". The only thing you cannot do is resell or distribute the RFP or any of the other tools to the general public, for free or otherwise.
Templates for various RFP cover letters are found in the following MS Word files:
Generally, vendors are given anywhere from two to four weeks to respond, depending on the complexity of the project as reflected in the RFP. We usually suggest three weeks for most projects.
Step #6 - Evaluating Vendor Responses to the RFP
The Vendor Response Comparison and Evaluation Matrix is found in the file "matrix-app-name-mm-yy.xls". A typical Matrix screen is shown below in Fig. 1.34 (CMMS software features used in sample).
The MS Word file "eval-score-usage.doc" contains an MS Word document describing the organization and usage of the Evaluation matrix.
This spreadsheet provides many side-by-side comparisons, plus financial and quality analysis ratios used to compare Vendor RFP Responses (Proposals) Side-by-Side at the individual feature detail level and also to graphically compare key Response Analysis Ratios that analyze the quality of each response (proposal). The easy to use "Copy and Paste Special > Values" command is used to easily copy vendor responses into the matrix.
Fig. 1.34 - The Vendor RFP Response Comparison and Evaluation Matrix
A Detail Response Analysis illustrates How the Vendor is Delivering the Proposed System - learn if the proposed system is actually DOABLE, or is it going to be a never-ending stream of bug fixes and support nightmares?
A Comprehensive SCORECARD Compares All Competing Systems in Detail:
Weighted Grade Score Graph - Compares the Weighted Grade Point Score calculated for each proposed system. This is calculated as follows: The vendor response to each RFP question is assigned an un-weighted "raw" score. This raw score is then multiplied by the weight factor you entered previously (default = 1) for that RFP question to calculate the weighted score for each response. All of these individual scores are then totaled for use in this comparison. This score is essentially a measure of how well a proposed software system fits your business and software needs, prioritized by the weight (importance level) you assigned to each question in the RFP. In essence, this score measures the SUITABILITY of each proposed software system to your overall requirements.
Feature Delivery Method Comparison - This is an analysis of how each vendor will deliver the functionality listed in their proposal. This graph shows how much, in percentage terms, is Fully Supported functionality available "out-of-the-box", the percentage that will be done using the Report Writer, how much will be done using Configuration Parameter changes, or with a Third-Party add-in, versus the percentage to be done by Custom Coding, whether it be Scripting or actual source code modification. This information is extremely useful for identifying the RISK inherent in each proposal, since a Fully Supported feature or function is far less risky than that same thing implemented through a scripting or custom programming task.
Supportability Index Graph - The Supportability Index is a forecast of how much system support and maintenance may be required to keep each proposed software system running at full potential over it's lifetime. This score is determined by how much custom coding is required to implement the proposed software system, and which business processes depend on the customized system.
Overall Comparison Graph - This graph compares both the Weighted Grade (Suitability) Score, Supportability Index, and the Vendor Capabilities Profile side-by-side for easy reference. It is important to see how much custom coding is in a proposed system that also has a high Weighted Score, along with the Vendor Profile. The more custom code, the higher the risk posed by that system. Therefore, the more custom coding, the more expertise and capabilities a vendor should have.
Vendor Profile Score Graph - The backgrounds, expertise, capabilities, and certifications of each vendor is obtained in the Vendor Global Issues section of the RFP. The vendor responses to this section are totaled separately from the software functionality topics, and this data is used to calculate the "Vendor Profile Score". The higher the score, the more CAPABILITIES a vendor is probably going to be.
A complete set of Financial Ratios is available in the file "cost-savings-analysis-yy.xls".
There are several optional activities as this point. There is no requirement to do so, but if you wish to inform vendors they were not selected to be finalists the Infotivity Toolkit does provide a "Rejection Letter" template in the file "RFP_rejection.docx".
If you wish to go through a "Best and Final Offer" negotiation process with the finalist vendors a letter template to initiate that is provided in the file "BAFO_Letter0-mm-yy.docx".
Use all of the above information to determine which vendors should be invited to demonstrate their solution. We suggest this should be limited to three (3) finalist vendors.
STEP #7 - Invite Vendor Finalists to Demonstrate Their Proposed System
Fig 1.70 - Components of a Software Demonstration Script (Mfg. ERP shown)