Successful LIMS Implementation: It’s not as Easy as Selecting the “Right” Piece of Software.
Original Article posted on The Analytical Scientist, February 23, 2015
Article #305 | Issue # 0215
As a laboratory informatics consultant working within analytical science, I am exposed continuously to new products, clients, and laboratory processes. Each and every company I’ve had the privilege of working with has had its own unique set of processes and procedures. But while the requirements, groundwork and execution of each implementation may be specific to a given client, the challenges are consistent – and the most common questions revolve around how to overcome them.
Before answering such questions, it’s important to define success in terms of LIMS implementation, and explain why so many projects fail.
Traditionally, a project is deemed successful when it satisfies all three of the following criteria: it’s delivered on time, it’s delivered within budget, and it’s fully functional according to the defined requirements. A word of warning though: even projects that meet all three essential conditions do not guarantee success. Why? The user community has not embraced the end result.
Consequently, a fourth – and arguably the most important – criterion for success is defined by user adoption. Adoption means that the user community uses the new system and that legacy systems are retired. In this regard, it is critical for end-users of the system to be involved in the project early – and frequently – as their input is vital in configuring a system that will be accepted and embraced. Successful implementations are the product of proper planning, alignment and execution, not simply the selection of the right piece of software.
People and organizational issues are prominent points of failure for any IT project – not just LIMS. Lack of proper planning, unrealistic expectations, poorly defined or incomplete requirements, inadequate user involvement, lack of executive management support, lack of experienced implementers and/or poor project leadership are all common pitfalls that lead to project demise. However, because the root of the problem lies within the organization itself (rather than the software being deployed) these issues can be controlled and remedied.
Selecting the right number of highly skilled project team members is vital. Inadequate or insufficient resources will most likely leave a system underdeveloped. In-house personnel may not have the training or skill-set to develop the system that the organization requires, which inevitably results in a lack of confidence and general indifference toward the new system. External consultants are often needed to bridge the skill gap.
When considering a LIMS implementation, it’s important to fully assess and analyze the organization’s current policies, procedures and technology. Documenting current processes and IT architecture will establish the baseline needed to effectively design a blueprint for future laboratory automation when the LIMS is implemented and in place.
Once the current business processes are known and documented, it’s time to start collecting ideas on how to automate and improve processes to make them more efficient and cost effective. The end goal is to design future processes that will alleviate any bottlenecks and inefficiencies in current practices. It’s an exercise that also identifies systems that can be eliminated as a result of a LIMS implementation.
By analyzing your processes and defining your future architecture, it is much easier to develop a business plan for the LIMS implementation. The plan should outline critical factors for success, any dependencies, potential risks and/or constraints. Success factors should include dedicated internal and external expertise, project governance, and executive sponsorship (it is absolutely essential to have managerial commitment through the entire duration of the project). Breaking up large projects into manageable phases enhances success – after all, the larger the project, the greater the chance of failure.
It is important to note that LIMS implementations are not just isolated laboratory projects – there are many stakeholders involved, from IT to QA to manufacturing and distribution. Although lab personnel are the primary LIMS users, others rely heavily on LIMS data to make important business decisions, which is why LIMS implementations are such highly visible projects throughout an organization.
In summary, fully understanding the business case for a LIMS and setting expectations accordingly are the keys to success. In my experience, the best software in the world will most certainly be a disaster if it is poorly implemented; but the worst software in the world? Well, it can still be turned into a success.