The Software Selection Process

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

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

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? 

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.

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.

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.  

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

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.

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 Fit-GAP analysis, a formal process of identifying how well an organization's current system fits its requirements on a day-to-day operational basis.  Fit-GAP 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 Fit-GAP 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 - Fit-GAP Analysis Matrix - Overview 

Please see the file "Fit-GAP-appname-mm-yy.xls" for a  Fit-GAP Matrix using requirements specific to each application.  More detailed Fit-GAP information is available at https://www.infotivity.com/fit-gap.html.

Infotivity provides the Fit-GAP matrix above combined with the hundreds, or thousands, of functionality requirements contained in each Infotivity RFP.  This results in a very detailed Fit-GAP Requirements Checklist.  As an example, one section of the HR, TA, and PR Requirements Checklist is show below in Fig. 1.32  ( https://www.infotivity.com/software-selection-process-steps.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 - Fit-GAP Analysis - Importance

The information gathered in the User Needs Survey, Work Distribution Chart (WDC), and Requirements Checklist w/Fit-GAP 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 Fit-GAP 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

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)

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.   

• An Initial Request Cover Letter is found in "RFP_invitation-mm-yy.docx". 
• A "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.