The Software Selection Process

Making It More Accurate and Reliable
 
 
 
Table of Contents
 
Introduction
    Importance of an "Integrated" Approach
 
The Steps Needed to Select Software Correctly
 
Step #1 - Initial Discovery    
   User Needs Survey
   Work Distribution Chart (WDC)
 
Step #2 - Feasibility Analysis & Justification
 
Step #3 - Requirements Identification
 
Step #4 - Finalizing the Request for Proposal (RFP) 
 
Step #5 - Sending the RFP to Vendors
 
Step #6 -  Evaluating Vendor Responses to the RFP
 
Step #7 -  Invite Vendor Finalists to Demonstrate Their Proposed System
 
 
--------------------------------------------------------------------------------------------------------
 
Introduction

This document has two purposes:

  • Describe each step of the process required to select software successfully.
  • Discuss how Infotivity tools make each step more accurate and easier to do.

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 

  • Incomplete Requirements
  • Incorrect Requirements
  • Changing Requirements
In addition, the above requirements issues can be a factor in other problems cited by the Standish Group, such as: Lack of User Involvement, Lack of Resources, Unrealistic Expectations, and Lack of Executive Support. This document will address these as appropriate.

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:

  1. Initial Discovery
  2. Feasibility Analysis & Justification
  3. Requirements Identification
  4. Finalizing the Request for Proposal (RFP)
  5. Sending the RFP to Vendors
  6. Evaluating the Vendor Responses (Proposals)
  7. Invite Vendor Finalists to Demonstrate Their Software
Complete each of the above steps quickly and accurately using the proven templates found in each Infotivity Software Selection Toolkit.

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: 

  • What about any scripting or custom source modifications that must be done? Who will do those? What are their qualifications? What methods will be used to ensure the scripts/mods will perform correctly?
  • What about the Business Processes that must be automated?  Both a Cloud-based solution or On-Premise software must be configured by someone to support the workflow(s) of each business process.  Who?  What are the qualifications of that someone?  And what about any NEW Business Process (workflows) that are needed? 
  • What about the Data Conversions that will be needed? 
  • What about training, both initial and on-going? 
Obviously, there is much more to choosing a new software system than simply comparing features online.  All of the above, in addition to the software, make up the actual SYSTEM you are trying to acquire, regardless of its SaaS or On-Premise Delivery mode. 
 
This total "integrated" system is what an Infotivity RFP queries vendors about, all in addition to the industry's largest collection of software features.  These tools give you the ability to evaluate a software proposal in terms of it's TOTAL impact on an organization. 

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.

  • Features of the same type &  name will vary wildly between different software products in terms of usability. The information content, presentation, detail level, and flexibility can be very different from one product to another. 
  • No two companies have the same, identical business processes. 
  • The business process dictates the software functionality needed to support it.  
  • Vendors usually oversell the functionality and capabilities of their product,
  • Inaccurate estimates of the true difficulty and cost of configuring their software to meet the unique needs of a specific organization. 

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:

  • Workflow Bottlenecks
  • Redundant Efforts
  • Inefficient Data collection or Retrieval Issues
  • System or Departmental Interface Problems.
The time information collected by the above tools can be used in the next step to more accurately calculate realistic cost savings and financial ratios needed to justify a project, and also just where the new system should provide improved functionality to enhance the organization's workflow and productivity (see Step #3). 
 
 

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

Specific Needs.

 

2.      Obtains Concise, Consistent, & Easily Compared Vendor

RFP Responses

 

3.      Automatically Calculates the Weighted Grade Score of each

Proposed Solution

 

4.      Automatically Determines the Supportability (Quality) of each Proposed

Solution

 

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". 

RFP Documentation

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:

  • An Initial Request Cover Letter is found in "RFP_invitation-mm-yy.docx". 
  • "Change" cover letter template is provided in "RFP_change_notification-mm-yy.docx".  Used if  you changes the RFP after distributing it to vendors.
  • A Best and Final Offer request is found in the file "BAFO_Letter-mm-yy.docx". 
  • A Rejection letter template is found in "RFP_rejection.docx". 

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

Infotivity strongly suggests that all software demonstrations be on your site, using your data (not vendor demo data that is perfect), and be broken out into a series of smaller demos that address your needs on a departmental basis using demo scripts focused on the needs of each department. 
 
The main Software Demonstration (Demo) Script page is shown below in Fig. 1.70 (ERP is used in this example). 
 
Column B contains a list of the things that are to be demonstrated, known as "Demo Tasks".  These can be organized into individual "sessions", e.g. a group of tasks pertinent to a specific department or division of the organization, such as "Back office Accounting" or "Purchasing" or "Inventory Control". 
 
The Demo Script is setup to enable multiple demo "sessions" that start and end at different times throughout the day, and column C, the "Time Schedule", is used to designate this schedule of individual sessions.  For example, a session for "Back Office Accounting" could be scheduled from 9:00 AM to 11:30 AM, and "Supply Chain Management" could be scheduled for 1:00 PM to 3:00 PM.  
 
Column D, the "Importance Level", is used to specify how important a given Demo Task is to the organization.        
 
All other columns are self explanatory. Please visit the following page for detailed FEATURES information:  http://www.infotivity.com/software_demonstration_script.html
 
Please visit the following page for more information about WHY a demonstration is needed:  http://www.infotivity.com/software-demonstration-script.html
 
Please visit the following page for more information about HOW to conduct a meaningful demonstration:
http://www.infotivity.com/software-demonstration-script-problems-to-avoid.html
 

Fig 1.70 - Components of a Software Demonstration Script   (Mfg. ERP shown)

 
 
 
 
Fig 1.71 - Side-by-Side Comparison Heat Map 
 
 
 
 
 
 
 
 
Fig 1.72 - Side-by-Side Score Detail & Bar Chart Comparison 
 
 
 
 
 
 
Fig 1.73 - Functional Fulfillment Comparison 
 
 
 
END
 
 
 
 
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------