INDUSTRIAL | RESEARCH | TEACHING | MEDICAL
Why LIMS Implementations can FAIL
lab solutions without compromise
The main reasons that LIMS implementations fail
If you’ve reached the decision to push forward with implementing LIMS in your laboratory, then it’s hugely important that you’ve considered and analysed all aspects of the process as thoroughly as possible. Since these kinds of systems can be very time-consuming to set up, as well as running the risk of putting a fairly sizeable dent on company finances, it’s critical that they’re implemented correctly the first time around.
Since it’s a system that looks after so much data and information, careful planning and management are key to successful LIMS implementation. Without these, you run the risk of wasting a large amount of time and money, as well as having a confused – and possibly very annoyed – workforce wondering what’s gone wrong with the project. Problems with setting up a LIMS vary but, nevertheless, they are easily avoidable pitfalls on the path to implementation – you just have to know what you’re doing.
If you’re planning on acquiring a LIMS for your lab, be sure to familiarise yourself with these important, but surprisingly common, reasons for LIMS implementation failure.
Not fully understanding your needs
What do you need now and what do you need in the future? If you’re looking to invest in a LIMS, these are the things you should be asking yourself and planning for. The success of the project is based on the specific usage of a LIMS.
The actual expense of the LIMS itself can be very costly; the effort to implement and maintain the system is largely determined by the quality and clarity of the requirements that have been drawn up. An analysis of the requirements without the appropriate time and effort is going to have lasting consequences as a result.
Avoid ignoring future technological advancements and solely basing your requirements on the immediate state of the business. If you choose to ignore potential developments then you effectively negate the purchasing of a new LIMS in the process because you’re forcing it into the constraints of how you previously did things. As a result, the LIMS you’ve implemented has a limited lifespan – so you repeat the same thing again when it’s time to buy a new one.
Not understanding the scope and size of the Project
From the outset, implementing a LIMS might seem like a smaller task than it actually is. The ostensible ease of a project means things you might perceive as straightforward actually end up taking longer to implement than you originally planned. As a result, many requirements get added to the project scope that aren’t necessary, while much less time is allotted to accommodate problems that crop up over the course of the implementation. Because of this, functionality is poorly implemented or dropped altogether to meet the deadline.
For example, one of the largest sources of underestimation is the effort required in configuring core static data entities. Products, analyses and sample plans are the foundation of your LIMS and are handled very differently in each LIMS product. While these elements might seem simple, the subtle differences within these entity classes can complicate implementation. Using a phased approach to your implementation can be beneficial; the first phase deems what is necessary, while each subsequent phase addresses what are good to have but may be surplus to requirements.
Making a LIMS purchase based on word of mouth or the recommendation of a colleague is almost always a bad idea. In a process based so much on quantitative data, using qualitative assessments to determine your LIMS is very much inadvisable; you’ll merely end up buying something which worked for your colleague, but is unlikely to meet your specific requirements.
Be careful during supplier demonstrations of LIMS, as it’s a common occurrence for companies to base their decisions on the “flashier” aspects of the system as opposed to the comparatively duller but ultimately more important elements. This means gaps between capabilities and requirements form during implementation, which results in an implementation that’s compromised and unsatisfactory.
Beginning with insufficient budget
It’s surprisingly common for companies to budget for their LIMS project before fully documenting their requirements. This can lead to a situation where the project ends up being confined by a random number that doesn’t allow for goals and objectives to be met; decisions end up being centred around cost rather than requirements.
Thus, the lower cost system is opted for, and the scope of the project is cut, meaning testing and training are scaled back. To avoid insufficient budget, companies should perform a business case analysis to set the budget for the LIMS project. This is used to define goals and objectives, describe the project’s benefits to your organisation and develop accurate costs both internally and externally.
Imposing a timeline on the supplier
It’s surprisingly common for companies to budget for their LIMS project before fully documenting their requirements. This can lead to a situation where the project ends up being confined by a random number that doesn’t allow for goals and objectives to be met; decisions end up being centred around cost rather than requirements.
Thus, the lower cost system is opted for, and the scope of the project is cut, meaning testing and training are scaled back. To avoid insufficient budget, companies should perform a business case analysis to set the budget for the LIMS project. This is used to define goals and objectives, describe the project’s benefits to your organisation and develop accurate costs both internally and externally.
