by Bob Hilbert, Director, Government and Forensic Solutions, LabVantage
If you’re researching the various vendors and Lab Information Management Systems (LIMS) available for your forensic labs, you may feel like you’re wading in terminology salad. The chunky bites of proprietary code, layers of acronyms, and technical toppings can add to the overall messiness. Making fair comparisons between very different solutions isn’t easy.
In this article, we’ll take a closer look at the challenges lab managers and IT teams encounter when making purchase decisions and offer tips for decoding the menu of capabilities available.
Both scientists and software vendors love jargon, meaning both request for proposal (RFP) writers and responders may unintentionally contribute to ambiguity. Cynics might argue that confusing terms are intentionally used in RFPs by vendors to make comparisons between vendors difficult and to mask shortfalls. When terms are not clearly defined in the RFP, the purchaser is left to interpret vaguely worded answers. It’s also easy to miss red flags when they are buried under technical terms.
Terms to Know
To avoid misunderstandings and disappointments, be aware of some key terms that are frequently subject to interpretation. These are the terms that, when not clearly defined, can cause surprises, extra costs, delays, and headaches:
Configuration versus customization
Nearly every LIMS RFP will address this issue because of its significance to buyers and the long-term effectiveness of the solution. It’s generally accepted that a LIMS should require minimal-to-no customization and offer great flexibility through configurations. This is the goal.
LIMS customizations can be useful, but the well-known downsides tend to overshadow the few benefits of customizing the underlying code. Customizations typically must be done by the vendor, often using proprietary code language only the vendor or a limited number of resources know. These customizations generally fall outside of the vendor software support and maintenance contracts. When it is time for an upgrade, the customizations can interfere with deploying new releases. You may need to have the customizations updated again. You also risk the ability to find resources who understand how the customization was built, in effect trapping you with limited options. These complications can become frustrating and costly through the lifetime of the solution.
On the other hand, most agree configurations are the better option. With this option, you can change system settings and build Master Data within the application itself – without changing the core code. Configurations can be done by a trained user, or as needed by the vendor. Configurations dictate how your workflows will be implemented but they don’t create changes to the application programming or data structure that constitute the system build. The configured version is included in the vendor software support and maintenance contracts, so you can get help if you need it. Plus, configurations don’t interfere with the future software versions and won’t cause issues during future upgrades or patches.
Tip: When reviewing your RFP responses, note if a vendor says they will provide the feature you need through a customization. Carefully weigh the risks versus the benefits.
System Capabilities and Abilities
Another common source of confusion in RFPs is around the phrases “must be capable of,” or “must have the ability to,” followed by a list of various requirements.
What does “capable of” or “ability to” mean? These phrases can be understood to mean that the system “is able to be built or configured at some future point by someone” who is hired to perform the task. It has an “anything is possible” (for additional money) open-ended vagueness that isn’t reassuring and could be misleading. It differs significantly from “the LIMS vendor must do this and provide it during the project before go-live.”
Vague language easily leads to confusion. When writing your RFP, be very clear if you expect the capabilities to be available out of the box, provided by the vendor, and working before go-live—without customizations.
Tip: Be leery if the RFP response has a grid marked “Yes” on every capability. This is a red flag. You may assume “Yes” means these functionalities are readily available out of the box. The vendor may mean these functionalities are theoretically possible, although extensive time and costs would likely be attached.
Out of the Box
This phrase is often used in RFPs without explanation, but it has two ways it can be interpreted.
- Functions you get when the LIMS is installed, without any configuration specific to your operation.
- Functions you get when the LIMS is installed, with configurations specific to your operation added by the vendor.
It is universally accepted that “OOTB” signifies functionalities you get without any customizations. But there is not a universal understanding of how much configuration can be needed and still be called “out- of-the-box.” LIMS vendors often disagree on this point and will answer according to the way they read the question. You, the customer, may not receive an apples-to-apples answer in the RFPs to compare, and it may be difficult to understand what you’ll receive as part of your project.
Tip: When writing your RFP, tell vendors what OOTB means to you and indicate that they shall adopt that terminology and convey such meaning in their proposal. If you didn’t state this upfront and receive an RFP with OOTB in the answer, clarify the meaning with the vendor.
Clarifying questions to ask before your next RFP
Customization. What customizations are necessary to meet my goals? Will this be done before go-live or after? Is the cost included in the project pricing? Who will do the customization? What are the downstream implications?
Configuration. Who will be expected to do the configuration? Is special training required to be able to do the configuration? Will this happen before go-live or after? How long should it take to set up?
Current ability or future capability. Is the functionality a current, included ability that will be available at go-live or is it a future capability that must be added or configured?
Out-of-the-Box. What percentage of my requirements are delivered without needed configuration (or customization)? Are features described as out-of-the-box ready to be used at go-live, or will it need to be configured to be used? If configuration is needed, who is expected to perform? What level of expertise or training is required and how long will it take?
Final takeaway
No matter what role you play in the purchasing process, you and your team must clearly understand what each LIMS vendor is saying when they submit a response to your RFP. Misunderstandings about the terms or “capabilities and abilities” that are to be provided later – as opposed to Day One of system usage – will likely impact when you can begin fully using your new LIMS, the actual cost realized, and the resource burden your lab has to absorb.
Tip: To make the best LIMS selection, be well informed. Ask questions. Insist on clarity in a documented, concise format. Consider telling the vendors your related definitions and that you expect them to align. Then, you can be sure you are getting the LIMS that matches your expectations and your organization’s needs.