IT in the Lab: Cloudy Solutions -- Part 2

Part 2 of a two-part article. Click here for Part 1.

By Trevor De Silva
Scimcom

Too often laboratory managers do not attempt to examine existing information systems and rely on IT or IT people to find solutions.

The purchase of an Information Management system such as a LIMS (Laboratory Information Management System) is one example. In this situation too often the justification is valid but the embedded information systems are not understood, the specification is incomplete. Subsequently, regardless of the success of the implementation project, the resulting system will fail to meet all expectations. Sure, the laboratory may be happy or alternatively the system will address the company's higher level needs but unless both parties are treated as stakeholders at the outset, the system cannot be a measured success.

Remember, the aim is not "A successful LIMS implementation," but rather "To implement a successful LIMS."

Taking the above into consideration, and in hope of inspiring good-natured debate here are a few must-do's for those of you considering a LIMS purchase, that can be applied to any similar IS purchase for the laboratory.

Use an external consultant. Typically, most laboratory managers justify, specify, and implement at most one LIMS in their career. How can they possibly know what to expect from a product, or what common pitfalls exist? Used correctly, a consultant can bring value to your project.

Remember, as the third party, your chosen consultant needs to bring something extra to the project. Today's labs are dynamic environments where business and individual needs change, so remember to ask your consultant how long it has been since they were last in a working laboratory. (You would be surprised at the answers from some!) They must be able to demonstrate practical experience of what you are trying to achieve. Theory is all well and good, but ask them how many successful systems they have actually implemented themselves.

Spend as much time as necessary identifying your business needs. Only when you have identified your business needs can you begin to consider whether you need a LIMS and the benefits it could bring. You must be able to answer the question "Why do you need a LIMS?"

People purchase LIMS for numerous reasons—many of them valid. But whatever you are looking to do, remember that the business needs should take precedence.

Prepare a "user requirement specification" (URS). You can talk to vendors and review systems before you start the URS, but please create the document before you ask for quotations. The document should not simply reflect your current working practices, but if possible, take the opportunity to review who is doing what and why. System analysis takes experience so even if budgets are tight; consider using a consultant at this stage.

The URS needs to focus on "What you need" and perhaps "Why you need it," but try to leave the "How to do it" to the vendor. Regardless of how experienced you or your consultant is, the vendor will know his system best, so let them have the opportunity to show you how they can meet your requirements. Most vendors much prefer the structured approach of quoting against detailed requirements.

Two final notes of advice here:

• Do not fall into the trap of making your initial URS too detailed, or the chances are that during the life of the project it will require too many amendments.
  
• If a vendor offers to write your URS, then try not to laugh, but smile and politely decline the offer!

Look beyond the product when selecting a system. It may surprise those of you who are unfamiliar with the LIMS market, but there really is not that much difference between the offerings from the market leading vendors. If you specified your requirements correctly you will soon know what is and isn't possible and the choice will come down to factors beyond the functionality of the product. You should investigate the quality and scope of additional services offered, and plans for future development.

Carefully select your project team. Take time to ensure that everyone on your project team is a stakeholder committed to the project's success. Avoid people who are simply "available."

Project manage the implementation. Typically, implementing a LIMS still takes too long. There are a few projects that last only 12 weeks but conversely several take many years. You should aim for a 6–12-month timescale and manage the project accordingly. If no one from the laboratory team has project management experience, then again call in a consultant. Without correct management of the "time-functionality-cost" triangle your project will flounder.

In summary, did I say earlier that we are simply trying to inspire a good-natured debate?!

I am sure we are all looking for clearer solutions. Whether it is the receipt and subsequent analysis of samples, the sharing of information, or the need to communicate with other systems, we should focus on understanding our business needs in the laboratory and identify the information systems in place. Without this knowledge, cloudy solutions will be commonplace; continued investment in IT will simply lead to duplication, inefficient information systems and the absence of any meaningful ROI calculations.

End of Part 2.

About the author: Trevor De Silva is general manager of Scimcon (Cambridgeshire UK). In 1998 he formed a new "LIMS consultancy" business unit within HFL (launched as Scimcon in 2000), from where he and his colleagues market their services externally to a worldwide market. As a consultancy service, Scimcon offer a unique perspective by providing consultants who actively develop and support IS services within an GLP compliant sports testing and pharmaceutical contract laboratory.

A graduate chemist, Trevor has been working in forensic science since 1980 and with LIMS and laboratory automation since 1987. He successfully completed a second degree in computing science in 1990, and since then has been involved in Information Technology, successfully implementing two LIMS for the Horseracing Forensic Laboratory in England, and consulting on additional projects worldwide.

Trevor has written several articles on information systems and laboratory automation, and today Trevor divides his time between Scimcon and his role as head of information systems for HFL.

HFL is a totally independent laboratory, with comprehensive expertise in pharmaceutical drug detection.

For more information: Trevor De Silva, Scimcon, Newmarket Rd., Fordham,
Cambridgeshire CB7 5WW, United Kingdom. Tel: 44-1638-720204. Fax: 44-1638-724206. Email: tdesilva@scimcon.com.