Acquiring an Informatics System: Where do Consultants Fit In?

For the modern laboratory, an informatics system to manage samples and data has become almost a necessity.

Whether a Laboratory Information Management System1 (LIMS) or an Electronic Laboratory Notebook2 (ELN), very few laboratories can effectively operate without them.  This is especially true in highly regulated industries.  However, the process involved in planning and selecting an informatics system can be very involved and fraught with risk.  The degree of risk is significant, with The Standish Group3 estimating that 61% of all IT projects fail.  Though some disagree with The Standish Group’s methodology4, by their estimate only 39% of projects are fully successful.  These failures are frequently due to human factor issues rather than technical ones5.  The good news is this failure risk can be minimized by a conscientious risk management process6 and the counsel of an Informatics Consultancy.

The process for planning and acquiring an informatics system is summarized in the graphic below.  It is easy to get the impression from this graphic that this is a very straightforward and simple process, but in reality it can be a very complex time and personnel intensive process7.  Hiding behind this diagram are many concurrent processes and contingent steps that must be performed while simultaneously managing project time and cost.

A consultancy will help your organization avoid the cost of false starts by helping structure and plan your project.  This can include helping to develop realistic goals for the project.  Additionally, members of a consultancy have widely diverse backgrounds and expertise and will have worked in all types of laboratories, making them ideally suited to thinking outside of the box when applying best practices.  Specific project aspects where a consultant’s assistance can prove invaluable include:

  • Analyzing current laboratory processes and identifying ways to optimize workflows by leveraging informatics solutions, eliminating unnecessary steps
  • Identifying system needs, i.e. LIMS or ELN
  • Generating list of potential system vendors
  • Writing the Request For Proposal (RFP)
  • Reviewing returned proposals and vendor selection.
  • Acting as interpreter between the laboratory and their IT group and vendor, as they speak a different language than the laboratory
  • Defusing political issues within the laboratory and any supervisory organizations
  • Training laboratory personnel to use their new laboratory informatics system in the context of their actual processes

With today’s lean organizations, a frequently overlooked detail impacting project success is who will be performing all of this work?  It is usually the most computer savvy analyst within the laboratory who is ‘elected’ to herd this process along.  While bringing someone over from the IT group is another option, it too is generally challenging as laboratory processes are not their specialty. In most cases the person selected will have no experience in laboratory informatics and automation.  Additionally, this person may still be expected to perform their usual job as well, quickly leading to burnout.  The minimal experience and scarcity of personnel resources makes it difficult to generate a complete requirements list, let alone to write a RFP or evaluate the submitted proposals.  Concurrently, they may be tasked with the political problem of acquiring buy-in and cooperation for the project, lack of which can kill an implementation project before it starts.  Even when you are lucky enough to have an informatics specialist on staff, they do not have sufficient time to do it all and the resources of a consultancy can help fill the gap.

The diverse background of people working within a consultancy means that it is less likely that anything will be missed during the requirements gathering phase of the project.  Having generated multiple RFPs, a consultancy is also in an excellent position to help you convert your list of requirements into a meaningful RFP, as they would have the expertise to know what needs to be included and what can be left out.  An effective approach to this would be to leverage a Risk Based Requirements (RBR)8methodology.  This methodology focuses approximately 80% of your overall effort on the 20% of the functionality that is unique to your operation. This is important, as it is these requirements which are most likely to be missing from an off-the-shelf system, therefore, requiring customization. When it comes time to evaluate all of the submitted proposals and vendor demonstrations, a consultancy can assist you to separate what some vendors might imply from what they will actually do. Their expertise helps you avoid demonstration “magic tricks” that can easily fool you with your own assumptions. This will prevent the surprise of having to buy additional modules or contract custom coding to obtain the functionality you thought you’d already purchased!

In the final balance, the selection of the system to acquire will be yours, but consultants can help take some of the mystery and frustration out of the process.  For added value, make this process a learning experience by having your people work closely with the consultants.  It is not uncommon for organizations to be reluctant to add the additional expense of a consultancy to what is usually already a tight budget. However, in this case the investment can actually reduce the overall cost of the project, minimize delays, and, in many instances, make the difference between a successful and a failed implementation.

Whatever your situation, the challenge of a laboratory informatics project is not to be undertaken lightly; it’s something you’ll want to get right, the first time. The guidance from a consultancy will dramatically increase your chances of arriving in the 39% group of fully successful IT projects.

References

  1. Laboratory information management system. LIMSWiki(2013). at <http://limswiki.org/index.php/Laboratory_information_management_system>
  2. Electronic laboratory notebook. LIMSWiki(2013). at <http://limswiki.org/index.php/Electronic_laboratory_notebook>
  3. The Standish Group International. CHAOS Manifesto 2013: Think Big, Act Small. (2013). at <http://versionone.com/assets/img/files/ChaosManifesto2013.pdf>
  4. Eveleens, J. L. & Verhoef, C. The rise and fall of the Chaos report figures. IEEE Softw.27, 30–36 (2010).
  5. Collier, C. LIMS comes of age – information management for every laboratory.  News(2007). at <http://www.labnews.co.uk/features/lims-comes-of-age-information-management-for-every-laboratory/>
  6. McDowall, R. D. Risk Management for Laboratory Automation Projects.  Assoc. Lab. Autom.9, 72–86 (2004).
  7. Devorick, W. Batteries Not Included; Looking Beyond the Informatics Quote. at <http://info.csolsinc.com/batteries-not-included-looking-beyond-the-informatics-quote>
  8. Turnbull, G. Apples to Apples – Selecting the Right Informatics Solution. (2013). at <http://info.csolsinc.com/webinar-request-apples-to-apples-selecting-the-right-informatics-solution-2>