In a recent post, we shared a customer’s perspective on building a LIMS Requirements checklist to create shortlist of LIMS vendors and ultimately choose a platform. In this post, we’ll discuss one of the top challenges lab managers and IT teams encounter when sending out an RFP for a new LIMS: confusing terminology.
***
Purchasers of Lab Information Management Systems (LIMS) are inevitably exposed (by vendors, admittedly!) to an overabundance of buzzwords.
Some of them are widely understood – take configuration versus customization – for example. Every reasonably sane person in a lab wants a LIMS that requires minimal-to-no customization and offers great flexibility in terms of configurations.
LIMS customizations can be useful – but they have well-known downsides. Customization is generally only done by the vendor and often uses coding languages only known to the vendor or expert resources. These customizations generally fall outside of the vendor software support and maintenance contracts.
On the other hand, configuration generally means changing system settings and building Master Data within the application itself – and it can be done by the vendor or a trained user. 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. Most importantly, configurability is included in the vendor software support and maintenance contracts. Configurations remain in your future software versions and won’t cause issues during upgrades or patches.
But beyond this distinction between (bad-word) customization and (good word) configuration, it’s critical that you understand what your LIMS vendor will actually provide on your go-live day.
And here’s where the buzzwords and terminology I mentioned earlier pose a challenge.
For any team going through the process of purchasing a LIMS, arriving at an understanding of expectations can be tough due – in part – to the various terms employed throughout LIMS RFPs. Much of this terminology is often ill-defined. Because of this, proposal responses from vendors can be misleading – sometimes intentionally so.
There are two specific topic areas that generally are the source of confusion: System Capabilities and Out-of-the-Box (OOTB).
System Capabilities and Abilities
RFPs will typically signal user and technical requirements by citing that the LIMS must “be capable of,” or “have the ability to,” followed by a list of various requirements.
But what does “capable of” or “ability to” mean? Either can be understood to mean that the system “is able to be built or configured at some point by someone” to perform some task or function. This differs significantly from “the LIMS Vendor must do this and provide it during the project before go-live.”
Such loose language by the requesting team easily leads to confusion. Suddenly, when you are evaluating the LIMS RFPs, you see response requirement grids marked “Yes” everywhere. This leads you to believe that the system in question will include all the functionalities referenced by your team’s requirements – which is often not true.
It is important to understand that this deception may or may not be intentional. [The LIMS vendor may be working from a different understanding of what is described.] But unfortunately, the result of this disconnect is that you select a vendor, only to later learn that:
- You won’t go-live when expected.
- You will need additional resources to perform this work.
- You will have to amend the original LIMS contract to have the LIMS Vendor perform the work.
- You will be spending a lot more money than expected.
Apples-to-Apples Comparisons
There are far too many examples of requirements where this lack of clarity occurs. A common – and relatively basic – example involves instrument interfaces.
An indication that the system “be capable of or have the ability to interface to numerous GC-MS instruments” may mean that you want the ability to build those interfaces at some point, or that you want them to be installed and working the day that your system goes live. Writing the requirement like this means vendors can choose to assume you intend the former. They can then build an impressive pricing model accordingly, because they are not planning to do the work as part of the quoted project.
Remember, “capabilities and abilities” that are to be provided later – as opposed to Day One of system usage – are likely to be things your staff will be expected to build and configure. While this may superficially save you money on paper, make no mistake: your resource utilization to make those changes happen will detract from your team’s ability to fulfill normal job responsibilities. The final configuration will also likely be inefficient due to your minimal working knowledge of the system and will not meet the needs you specified from the outset.
“Out of the Box” LIMS
This phrase is often used in RFPs without explanation. Two common reads of the phrase are:
- 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. Because of the lack of upfront clarification in the RFP, how much configuration is needed (or included) is often open to interpretation. LIMS vendors will answer according to the way they read the question. You, the customer, may not receive an apples-to-apples answer to compare, and it may be difficult to understand what you’ll receive as part of your project.
You’ll need to ensure that any vendor using “OOTB” tells you precisely what they mean by it. They should provide clarity on what will be installed and ready to use on the day that your system goes live, and what will occur at a future date.
How to Specify LIMS Requirements Terms
Here are the relevant terms you should ensure are clearly addressed in your RFP.
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. It’s imperative that you have clarity as to whether each item in your RFP checklist is a functionality their system really will provide at go-live.
Our Commitment
LabVantage prefers clear RFP language to avoid potential misunderstandings. We always commit to:
- Delivery of a comprehensive solution that provides your required functionalities on your go-live date.
- Delivery of a concise description, via RFP response or otherwise, that clearly indicates what that Day-One solution will be, and whether there are other capabilities that will be addressed at some later date.
- A price point that is consistent with actual work to be done, along with detailed explanations of that work in the quote.
If you do not receive these types of commitments from a LIMS vendor, it is likely that you will pay considerably more and expend more time than you expected at the time the contract was signed.
