Reasons LIMS Fail

Top 4 Reasons LIMS Implementations Fail

Implementing a new LIMS can be a huge challenge. There are so many aspects to consider and moving parts to manage that LIMS implementations can and sometimes do fail. The reasons why they fail vary widely but the fact remains that a failed LIMS implementation can be a financial disaster and a huge waste of time. Getting things right the first time is critical for your return on investment because let’s face it, these systems take considerable time and effort to implement! Here is a list of the top four reasons why LIMS implementations fail.

1. Not fully understanding what you need

It is not uncommon to see a recently implemented LIMS need to be fixed because either a key requirement was missed or no plan for expansion was made. For example, a sample approval process can be implemented and work at go-live but then need to be completely changed later because a new business unit was added to the LIMS system. It is very easy to get tunnel vision and base your requirements on the immediate needs of the business, thereby overlooking important details and flexibility that may be needed in subsequent phases.

Having a good understanding of what is actually needed now and in the future, based on your specific usage scenario, is critical for the success of the project. One of the largest expenses incurred when implementing any LIMS is the cost to actually implement the solution. The effort to implement and maintain the system is greatly influenced by the quality and clarity of the requirements that have been gathered. If you feel that you can’t afford the time and effort to do a proper analysis of the requirements, think of the cost and consequences if you don’t.

2. Biting off more than you can chew

Implementing a LIMS has a sneaky tendency to seem like a smaller task than it actually is. Often times, things that seem easy and straight forward take much longer to implement than was originally planned. Because of this, many requirements are added to the project scope that aren’t actually “needed” for go-live and not enough time is allotted in the project plan to accommodate problems that may arise during the course of the implementation. That’s when functionality tends to be poorly implemented or dropped all together to meet the deadline.

One of the largest sources of underestimation can be the effort needed to configure the core static data entities. Products, analyses, sample plans, etc. are the foundation of your LIMS and are handled very differently in each LIMS product. While configuring these entities may seem straight forward, slight nuances within an entity class can complicate implementing them correctly. To minimize this, using a phased approach to your implementation can be beneficial. In this way the first phase will include what is absolutely necessary with subsequent phases addressing the remaining “nice to haves”.

3. Failure to properly evaluate and select a LIMS

Ok, so you’ve done a complete analysis of your user requirements and you have a great idea of what your needs are, now what? How do you figure out what is the best LIMS for you? Do a Google search for “best LIMS”? Many LIMS implementations fail because the correct LIMS system was not selected to meet the specific needs of the business and lab. More often than not, LIMS systems are selected based on price and sales promises. By the time you realize that the wrong one was selected, you are too heavily invested and turning back is not an option. Following a well thought out, formal selection process including RFPs, scripted demos, vendor audits, and reference checks is industry best practice. Doing so will guarantee that the selected LIMS will be able to meet your needs. If this is something that your company does not have experience with or doesn’t have the resources to do, securing Subject Matter Experts with experience and expertise in this space is essential.

4. Not enough prototyping

Have you ever deployed something that you thought would be fantastic, only to have your users feel completely different about it? For example, maybe you’ve put together a stability summary report that took a significant amount to time to develop. That report goes all the way through validation before the users actually see it and they end up hating it. Would this example make the implementation of the stability system fail? Maybe, if there isn’t enough money or time left in the project to fix it.

Prototyping frequently during the implementation process will avoid this type of situation. It can also greatly increase the end users’ acceptance of the system and it will also reduce the amount of rework by helping to identify problems earlier. By not prototyping often during the implementation process, you are unnecessarily increasing the overall risk of the project and the chances for failure.

Source taken from: CSols