Select Software Accurately rfp mistakes

How to Choose Software

The Overlooked Requirements Instructions

Use these Instructions to Select Software More Accurately!





  Software Selection  >  RFP Template List  >  How to Choose a Software System


How to Select Software

The Most Overlooked Selection Instructions

A quick search on Google for information about How to Select Software finds many articles talking about how to identify stakeholders, how to determine budgets, and do other things important in any effort to evaluate and select software.

But one critical item is missing in all those How to Choose Software articles, and what's missing are detailed instructions about HOW to identify software requirements.

All the pundits/experts provide how-to instructions that say "identify your requirements" before making a software selection, but they don't go into any detail about how to identify those requirements. What exactly does "identify your requirements" really mean? No one takes the time to explain what is required, or what is involved, to "identify your requirements". How are they collected? There are many issues that can impact how a "requirement" can be identified, so what is the best way? Some of these issues are:

  • Just what is a "requirement"?  Is it a software feature or a business process need?
  • Should "requirements" specify features or capabilities?
  • At what level of detail should a "requirement" be at?  For example, the statement "The new system must provide an Accounts Receivable (AR) Aging Report" identifies a very basic, "standard" requirement. Something that almost any vendor can say YES to. That is not much help in identifying the BEST system though. Instructions on How to Choose Software should address this.
  • Should a "requirement" only specify what is currently needed, or should it be about potential future needs as well?
  • How should Business Process Reengineering (BPR) be treated?
  • What about workflow? How does it relate to your effort to select software?
  • How about the adequacy of exisitng data collection tools such as paper and web-based forms?
This article is about how to select software based on well-defined requirements, and answers the above questions regarding requirements and their impact on the software selection process. Let's start off with an example of how badly just one ill-defined requirement can affect the outcome of a software implementation.

How Just One Poorly Defined Requirement Impacts a Project

Just to show how important the act of correctly identifying requirements can be, let's go back to our previous example requirements statement "The new system must provide an Accounts Receivable (AR) Aging Report."

Since this appears to be a basic requirement many people in your company might consider that to be good enough for use in an RFP. Others may want to add "with the ability to specify a Starting and Ending Customer" because of the large number of customers, so the full requirement becomes:

"The new system must provide an Accounts Receivable (AR) Aging Report."
"The AR Aging Report must provide the ability to specify a Starting and Ending Customer."

The above looks good to all, it seems to go into enough detail, so it goes into the RFP. Especially since many people are thinking, "this is good enough, this is just a "standard" AR Aging report, something any good system should be able to do".

All the vendors respond with YES to both of the above requirements, since they are very easy to do for almost any system. A system is chosen, partly because of the large amount of detail in its database, and implemention of the new system is started.

Problem #1 Appears

Very quickly it become apparent there are problems with the AR Aging Report. It is VERY long, it uses up tremendous amounts of paper, and takes a very long time to finish, all because it includes a DETAIL transaction listing for every customer, and there are many, many customers. All of a sudden there is now a new, unforeseen problem with the new software, one that will cause a delay in its implementation while waiting for the problem to be solved.

It takes several emergency meetings to determine the best way to solve the problems caused by a lengthy, unwieldy, and almost unusable AR Aging Report. The solution is to add a new report setup parameter (control) enabling the user to specify if the DETAIL for each customer account should be printed or not. This is ideal since the AR Aging Report already includes a summary-level aging analysis that shows which accounts are past due.

The additional, totally unforeseen cost of adding the new new report setup control is not welocme, but neccessary. The implementation is re-started with a new GO-LIVE date.

Problem #2 Appears

The implementation moves into final testing, where yet another deficiency in the AR Aging Report is uncovered. The company sells its products DIRECTLY to customers, and also through a network of Manufacturer's Representatives (Reps). The problem is that it takes a very long time to sift through the report looking for ONLY those customers sold through a Manufacturer Rep. The Rep is responsible for managing that customer account, so this is very important. So now there is another unforeseen problem that must be solved, calling for yet another series of unplanned, emergency meetings to resolve this new problem.

The solution to this problem is to automatically label (categorize) each customer account with its source of origin, i.e., either as a DIRECT or REP account. Also, a new report setup control must be added to enable the user to indicate if they want to see just DIRECT accounts, or just REP accounts,. or ALL.

The UNEXPECTED COST of the solution to this new problem is VERY LARGE since it involves significant changes in Customer Maintenance, Sales Order Entry, abd also the AR Aging Report Setup and Report processing. This is totally unacceptable since it now threatens to significantly REDUCE the financial benefits iof the new system.

Problem #3 Appears

The new system goes LIVE, and yet another NEW deficiency is reported by the people responsilble for collecing severely overdue accounts. They want to see a report of just those accounts that are 60 days or more past due, since it takes far too long to sift through the full report looking for just those accounts over 60 days past due. Again, another significant EXTRA COST is required to add a new control and modify the AR Aging Report (again!)

Problem Summary

The above illustrates how UNPLANNED requirements can drive up the actual COST of even a so called "run of the mill", application standard function such as an AR Aging Report. Note that we have not yet talked about the need for "User Defined" Account Aging Periods, Aging by Product Category, Aging by User-Defined Customer Categories, User-Defined Transaction Notes, and many others related to truly useful Accounts Receivable Aging Reports! These are not standard, nor are they something "any good system can do"!

And the above are all in just one small functional area of the many that make up software system! Just imagine how many there are, and what could be happening, throughout the entire system. No wonder the majority of all system implementations fail to achieve their operational and/or financial objectives! How software selection requirements are defined does matter!

What is the Solution?

There are so many functional areas in a typical software system the entire task of "identifying requirements" can be quite overwhelming. That is why some software selection hubs and technology evaluation centers sell pre-populated RFPs. But, as we have illustrated above, an RFP software requirement may not adequately define your needs, especially a static software features list created in a backroom 3 months or 3 years ago. What is needed is a list of software RFP requirements that truly reflect all your software configuration, operational (control), and management needs. The best, most efficient way to do that is described below.

How to Select Software | The Best Way

What is the best way to identify all your true requirements at the detail level without wasting significant amounts of time on in-significant or irrelevant issues? The answer is to use proven, time-tested tools such as a Work Distribution Chart (WDC) followed by a Fit-GAP Analysis. These will uncover the information needed to create a meaningful RFP, and an actionable Demonstration Script, that will be very useful in your efforts to select software best suited to your organization. All is explained in the sections below.

Work Distribution Chart (WDC) | Usage

Any of us who have collected user needs knows how difficult that can be. Most end users know very little about "software requirements" but they do know WHAT they do each working day and HOW MUCH time they spend doing each task (on average). There is NO user training required in order to use a WDC, because the user already knows the answers! All users need do is enter their name, position, and a list of those activities they perform each day along with how much time they spend doing them on average. Easy!

Obtaining this information from each user will enable any person knowledgeable about the operation (such as a Business Analyst or Dept Mgr) to immediately identify unusual amounts of a specific activity, and/or where too much time is being spent. These indicate potential software deficiencies, workflow roadblocks, and compliance problems, and should be flagged for further investigation using the Requirements Checklist with Fit-GAP Analysis.

You have now started to identify where your operation's real problems are. The next step is to interview the users who have reported those problems or unusual activity on their WDC responses and further investigate the reasons why they are occuring. These are the areas where special effort must be made to identify and document their cause and possible mitigation efforts. This saves you a lot of time, and is where the Requirements Checklist with Fit-GAP Matrix becomes a very useful, time-saving tool.

End User Interview

Requirements Checklist with Fit-GAP Matrix | Usage

The goal of interviewing end users about the problems, productivity issues and/or other unusual activity reported on their WDC responses is to collect information describing each issue/problem, then document the CAUSE, i.e., is it caused by a deficiency in the current software, or a workflow bottleneck, or a compliance requirement, or other operational or process problem. Once an issue has been documented, information regarding HOW IMPORTANT it is, i.e., it's PRIORITY, and possible ways to MITIGATE or RESOLVE the problem, should be collected.

Infotivity provides a Requirements Checklist with Fit-GAP Matrix, to help with this step of the software selection process. These comprehensive checklists are pre-loaded with hundreds of criteria, tasks, and process questions pertinent to end user system system or operational needs, each paired with matching Fit/GAP attributes. This enables you to meet with an end user and immediately ask key questions focused on the activity area they reported on their WDC response, record their answers, and identify possible solutions to their reported problem.

Fit/Gap Analysis is a proven software industry methodology used to evaluate each functional area in a business process to achieve a specific solution. It includes identifying key data or components that fit within the desired business system and GAPS that need solutions. Learn more about Fit-GAP Analysis.

The Requirements Checklist enables you to record both the problem found in a specific business function, process, or software module, and also the "Importance Level" (Priority) of that problem. Learn more about the Infotivity Requirements Checklist with Fit-GAP Matrix benefits.

The Checklist then enables you to record WHERE, WHEN, and HOW MUCH of a GAP exists between your organization's current needs and and the software system it currently has in use, and just as importantly, WHY. Following this proven Fit-GAP process identifies the software requirements UNIQUE to your organization at all levels - Software Functionality, Workflow, Business Process Reengineering, Data Collection, Reporting, and Compliance, ensuring an effective RFP is used to query vendors.

RFP Development and Processing

The information collected from the end user WDC responses, user interviews, and derived from Fit-GAP analysis, all as described above, can be used to very quickly convert any Infotivity RFP template into an RFP customized to communicate your unique needs to a vendor.

Preparing a meaningful Request for Proposal (RFP) containing the information obtained in previous steps, and then using it to query vendors as needed to obtain consistent, easily compared vendor proposals is an extremely important step in the "How to Select Software" process for two reasons:

The first reason is that it documents at the detail level exactly what a vendor has made a commitment to do, and at what cost. An software system is very complex, and it is impossible to ask about every feature and function pertinent to your operations. Documenting the vendor proposal, their commitment to you, is very important.

The second reason is that a properly formatted RFP, i.e., one that presents its questions in quantitative format, will enable very fast and accurate evaluation and comparison of all vendor RFP responses (proposals).

Infotovoty RFP Templates with matching Software Selection Toolkits enable you to accurately issue an RFP conveying your specific, unique needs, then evaluate and compare vendor proposals at the detail feature, weighted grade score (suitability), supportability, and financial levels.  Learn more about Infotivity RFP Templates with Software Selection Tools RFP Templates with matching Software Selection Toolkits.

Vendor Demonstratin Scripts

Inviting those vendors presenting the most promising proposals (RFP responses) is a very good way to resolve any questions arising from their proposals, if needed, and also to view first hand how the proposed system's user inteface works, how intuitive it is, and easily a proposed system can be adapted to changing operational and workflow requirements.

Learn more about Infotivity Software Demonstration Script Template capabilities.

 Return to the TOP of the How to Select Software Page.

  More Details

"The detailed requirements we found in the RFP template for process manufacturing ERP, as well as Infotivity's effective help, enabled the successful outcome of our ERP software selection project."
      - Diane H., Natural Cosmetics Mfr.

Frequently Asked Questions

RFP Features Checklist

View the RFP Template List
RFP Templates Available

to Choose Software!
ERP Software Selection Mistakes





"Using your RFP template,
we did in 4 weeks what it
took others almost a year
to do."

Mobile Communications
5,200+ Facilities Worldwide

"The most comprehensive &
detailed RFP I have seen

Memphis Light (MLGW)
2,500+ employees

"Thank you very much! I
have to say it's quite
extensive and well laid
out, this is exactly what
we were looking for!"

J. P.
Certified SCM Consultant