Comparing RFP vs. RFQ vs. RFI approaches when purchasing a CMMS

David Berger says determine your user requirements before purchasing a CMMS.

By David Berger

There are many ways to approach the procurement of software, hardware, or services, whenever you decide to replace or upgrade your CMMS and related systems. Regardless of which approach you use, there is always an element of gathering information, obtaining a price, and negotiating terms and conditions based on user requirements. This may involve multiple informal or formal methods as described in this column.

No matter which approach you use, the first and most important step is usually to determine your user requirements. This includes a detailed description of what the users need, as well as a means by which to evaluate and select alternative solutions. The language used to describe user expectations should be consistent and concise, in order for vendors to accurately interpret your needs. In turn, this will enable you to more easily compare vendor options.

Suppose for example, that your company has an older CMMS package that, among other things, does not adequately track warranty information. In fact, you determine that millions of dollars are lost each year because you are unable to keep proper warranty records for assets and parts. In discussions with all stakeholders such as Maintenance, Operations, Engineering, Procurement, Materials Management, and Finance, you develop user requirements for improved warranty management. Wording of the relevant software specification might be something like the following:

1.    Ability for the system to handle warranties for BOTH
     i.    parts, and
     ii.    assets,
including but not limited to:
     a.    Summary reporting of all work orders on warranty
     b.    Preparing a warranty claim
     c.    Recording and tracking multiple warranties per asset
     d.    Recording and tracking warranty for any activity on a single work order (e.g., one work order with two tasks, namely 1. fix brakes and 2. replace tail light, but only the first task “fix brakes” is under warranty)
     e.    Recording warranty types (e.g., manufacturer, vendor, extended)
     f.    Tracking using graphical calendar presentation
     g.    Tracking by meter including start/expiration/threshold readings
     h.    Handling warranty renewals
     i.    Favouring serialized parts closer to warranty expiration
     j.    Favouring non-serialized parts closer to expiration
     k.    Parent/child option (i.e., user can opt to pass warranty to all children such as a three-year, end-to-end vehicle warranty)
     l.    Parent/child option (i.e., user can opt to pass warranty to selected children)
    m.    Handling group/master warranty (e.g., 60 pumps bought on the same day from a vendor, that all share the same warranty info)

Writing a good user requirements document is no easy task. Specifications should be:

  • Very detailed – when in doubt, err on the side of more detail, avoiding simplistic specifications such as "ability to manage warranties," which allows vendors to respond affirmatively even if they have the most archaic warranty capability
  • Without company jargon – avoid acronyms that are not commonly known
  • Supported with examples – provide lots of relevant examples, including use of footnotes, exhibits, or detailed appendices where helpful
  • Bulleted on separate lines – force vendors to respond to each line item, as opposed to responding affirmatively if they can provide only some of the functionality
  • Prioritized – although not shown above, each specification line item should be weighted so that vendors understand their relative importance. If the priority is “nice to have”, and not at least “important”, do not put it into the specification.

Not only should the software be evaluated based on user requirements, so too should the vendor be assessed. For example, is the vendor capable of meeting all of the specifications, or are they proposing partnering with other organizations? What are the vendor’s financial health, experience with similar projects, and breadth and depth of product/service offerings? What are the hardware, architecture, telecommunications, data, and other technical requirements recommended by the vendor in light of your specification? What support services are provided such as help desk, training, implementation, and consulting, and what are the expected service levels?

Vendors will also require some context around the specifications, including a description of the following:

  • Your company (size, location, nature of business, organizational structure, technical environment, future technology plans)
  • The nature of the project and why it was launched (project background, objectives, scope, deliverables, project team structure, key stakeholders, benefits contemplated)
  • The evaluation process (timeline, evaluation criteria and percent weighting, your key contact, submission instructions)

As well, there are typically terms and conditions expected by the Purchasing Department, such as expectations around confidentiality, use of subcontractors, and payment terms. Of course one of the most important common elements is pricing. This includes pricing of various software options based on your requirements (e.g., different modules), hardware alternatives (e.g., hosted versus in-house options), and service offerings (e.g., process engineering and training).

One of the most basic procurement approaches is use of the Request for Information (RFI) to simply troll the market, fishing for information as to what solutions are available at roughly what cost. The RFI is most appropriate when you are exploring less known or more complex solutions, like say, whether there is pipeline integrity software that runs on a mobile device, is linked to both field services and route optimization software, and is all integrated with a full-function CMMS.

If your needs are basic, easily understood, and fairly common, and you are simply looking for a quote, then the Request for Quotation (RFQ) is right for you. Again, all of the relevant common elements mentioned above can be found in the RFQ, but price is typically the focus.

Use of the more detailed and formal Request for Proposal (RFP) process is probably the most appropriate procurement approach for CMMS and related systems, due to the substantial benefits/risk at stake, especially for asset-intensive companies. Other advantages of the RFP approach over the RFI and RFQ approaches for procuring CMMS and related systems/services are:

1.    Typically the RFI process (and sometimes the RFQ process) require two or more steps, as opposed to a single-step RFP process. The first step is to get initial information. The second step is to analyze and evaluate responses and possibly try again with a different approach, depending on initial responses. Eventually, you will have to prepare the more formal RFP when you finally figure out your budget and what you are asking of the market. It is usually just as effective if not more so, to use an external consultant knowledgeable with the market. Alternatively, you can conduct your own research by internet and by phone, prior to releasing a more targeted RFP.

2.    Vendors may not take an RFI seriously, or certainly as seriously as a defined project implied by the more formal RFP process. Some vendors may not even respond – typically the better and therefore busier vendors – because they are thinking "Call me when you stop fishing, get your act together, and have a defined project and corresponding budget, because that is my priority right now."

3.    If vendors do respond to an RFI, you tend to get “brochure-ware” that is no better than what you could uncover doing research online.

4.    In some cases, your organization will be flooded with sales and marketing emails and phone calls upon release of an RFI or RFQ, because now vendors know you are in the market. Given the vulnerability of not really knowing what you want (as evidenced by the less formal procurement process), vendors may attempt to gain inside information, and influence your senior management group. This may ultimately render the whole procurement process unfair, not to mention how disruptive it is for whomever in your company is trying to manage an impartial process.

Read David Berger's monthly column, Asset Manager.