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.
What are some of biggest pitfalls that you’ve encountered during your LIMS implementation?
I agree with much of the above, but it also naive. The first reason assumes your have enough forward view to anticipate requirements. This can lead to the second failure, which leads to a failure in the 3rd reason because you may have over planned you LIMS. Together 3 and 4 expect a high level of experience and maturity, and understanding of time required. Few groups have the capability and capacity to work with prototypes (you have to use the system, but not really), and understand the nature of prototyping, to provide reasonable feedback.
To me, after 20 years designing, building, selling, evaluating, and using LIMS, the biggest challenge is getting started in a way that allows for future unanticipated growth. With getting started being the single greatest obstacle to overcome. In all my failures, getting started was the predominant factor – we called this the two year rule.
I agree with the titles of each topic.
However the content is different from my experiences.
1. The tendency is to look art individual user requirements where the business process should be leading. First step should be to analyze optimize business processes and configure the LIMS accordingly. Projects fail often because of to much detailing the requirements into ” I want this and that” .
2. Too much biting off is never good. But too much to implement neither. Determine the scope carefullly and use modern approaches like Agile to deliver small working pieces.
3. I tend to assume that the l;arge vendors all deliver the same functionality. Cost of ownership should be a leading factor in choosing the vendor.
4. Agree with the content. However not sure if prototyping is the solution alone. The topic is more about user involvement and the project team that should have in depth knowledge of the business. Maybe the lack of knowledge is the main cause of failures or delays in IT projects.
Thanks for your comments Corné. We agree with your first point. In fact when working with a client to develop and document their needs we routinely perform a process and workflow analysis of the current state followed by a workshop to get all stakeholders to agree to the future state. During the latter process we always work on optimizing the business processes with the client while ensuring that proposed changes do not overly affect how they run their labs and businesses. On your second point we also find that it is common to follow a Phased Implementation Approach. In this way the optimal amount of implementation is done in each phase. Utilizing a prototypical methodology (i.e. Agile) to do the implementation is also common and considered by many to be a best practice. We disagree somewhat with your third point. It does often appear that the leading vendors all deliver the same functionality but there are many differences especially in purpose-built vs generic systems. More importantly we find that how the functionality is supported is very different in each system and this can be a major deciding point. You again make great points on the forth item that we are in agreement with as well.
I agree with much of the above, but it also naive. The first reason assumes your have enough forward view to anticipate requirements. This can lead to the second failure, which leads to a failure in the 3rd reason because you may have over planned you LIMS. Together 3 and 4 expect a high level of experience and maturity, and understanding of time required. Few groups have the capability and capacity to work with prototypes (you have to use the system, but not really), and understand the nature of prototyping, to provide reasonable feedback.
To me, after 20 years designing, building, selling, evaluating, and using LIMS, the biggest challenge is getting started in a way that allows for future unanticipated growth. With getting started being the single greatest obstacle to overcome. In all my failures, getting started was the predominant factor – we called this the two year rule.
I agree with the titles of each topic.
However the content is different from my experiences.
1. The tendency is to look art individual user requirements where the business process should be leading. First step should be to analyze optimize business processes and configure the LIMS accordingly. Projects fail often because of to much detailing the requirements into ” I want this and that” .
2. Too much biting off is never good. But too much to implement neither. Determine the scope carefullly and use modern approaches like Agile to deliver small working pieces.
3. I tend to assume that the l;arge vendors all deliver the same functionality. Cost of ownership should be a leading factor in choosing the vendor.
4. Agree with the content. However not sure if prototyping is the solution alone. The topic is more about user involvement and the project team that should have in depth knowledge of the business. Maybe the lack of knowledge is the main cause of failures or delays in IT projects.
Thanks for your comments Corné. We agree with your first point. In fact when working with a client to develop and document their needs we routinely perform a process and workflow analysis of the current state followed by a workshop to get all stakeholders to agree to the future state. During the latter process we always work on optimizing the business processes with the client while ensuring that proposed changes do not overly affect how they run their labs and businesses. On your second point we also find that it is common to follow a Phased Implementation Approach. In this way the optimal amount of implementation is done in each phase. Utilizing a prototypical methodology (i.e. Agile) to do the implementation is also common and considered by many to be a best practice. We disagree somewhat with your third point. It does often appear that the leading vendors all deliver the same functionality but there are many differences especially in purpose-built vs generic systems. More importantly we find that how the functionality is supported is very different in each system and this can be a major deciding point. You again make great points on the forth item that we are in agreement with as well.