Templates for FMS Software Selection rfp mistakes

How to Choose Facility Management Software

Overlooked FMS Requirements Instructions

Instructions on How to Select FMS software More Accurately!
 

 

 

 

 

  Software Selection  >  RFP Template List  >  How to Choose Facility Management Software


 

How to Select FMS Software

The Most Overlooked FMS Selection Instructions

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

But one critical item is missing in all those How to Choose Facility Management Software articles, and that is a detailed instruction set about HOW to FMS identify software requirements.

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

  • How is a FMS 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 FMS software?
  • How about the adequacy of exisitng data collection tools such as paper and web-based forms?
This article is about how to select FMS 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 transportation management software implementation.

How Just One Poorly Defined FMS 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 FMS 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 FMS system must provide an Carrier / Agent Payables Report."
"The Carrier / Agent Payables Report must provide the ability to specify a Starting and Ending Carrier and/or Agent."

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" Carrier / Agent Payables Aging report, something any good FMS 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 FMS system is started.

Problem #1 Appears

Very quickly it become apparent there are problems with the Carrier / Agent Payables 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 Carrier and/or Agent, and there are many, many Carrier and/or Agents. The report show balance due and all transactions that have been created and sorted by carrier, reference the pro number, trip number, group number) and C/L number. All of a sudden there is now a new, unforeseen problem with the new transportation management 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 Carrier / Agent Payables Report. The solution is to add a new report setup parameter (control) enabling the user to specify if the DETAIL for each Carrier and/or Agent account should be printed or not. This is ideal since the Carrier / Agent Payables Report already includes a summary-level aging analysis that shows which accounts are past their Due Date.

The additional, totally unforeseen cost of adding the new new report setup control is not welocme, but neccessary. The new TME 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 Carrier / Agent Payables Report is uncovered. Write-offs must be done reconciled individually, rewqiring significant extra time compared to the old way of doing them as a group. 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 only solution to this problem is to modify the source code so they can be done as a group. Also, a new report setup control must be added to enable the user to fo this.

The UNEXPECTED COST of the solution to this new problem is VERY LARGE since it involves significant changes in Carrier / Agent Maintenance and other DB records abd also the Carrier / Agent Payables Report Setup and Report processing. This is totally unacceptable since it now threatens to significantly REDUCE the financial benefits iof the new system.

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 Carrier / Agent Payables Report. Note that we have not yet talked about the need for "User Defined" Account Aging Periods, Aging by Region, Aging by User-Defined Carrier / Agent Categories, User-Defined Transaction Notes, and many others related to truly useful Carrier / Agent Payables 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 can make up a transportation management software (FMS) system! Just imagine how many there are, and what could be happening, throughout the entire FMS 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 FMS 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 FMS 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 FMS Software | The Best Way

What is the best way to identify all your true FMS 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 FMS 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 FMS 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 FMS problem areasFMS 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

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

FMS Software 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 the Infotivity Facility Management System RFP template into an RFP customized to communicate your unique needs to a vendor.

Preparing a meaningful FMS 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 FMS 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 FMS RFP responses (proposals).

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

Vendor FMS 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 FMS Software Demonstration Script Template capabilities.

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

Webutation

"The detailed requirements we found in the RFP template for transportation management software, as well as Infotivity's effective help, enabled the successful outcome of our FMS software selection project."
      - T. H., LALA Foods.


Frequently Asked Questions

RFP Features Checklist

View the RFP Template List RFP Templates Available

How NOT
to Choose FMS Software!
ERP Software Selection Mistakes

 

FREE TOOLS

SELECTION READINESS TOOL

WHAT USERS SAY...

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

Telenor
Mobile Communications
5,200+ Facilities Worldwide

--------------------
"The most comprehensive &
detailed RFP I have seen
anywhere."

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

--------------------