LIMS Gone Bad: Avoiding Pitfalls in Your Implementation

Blog: LIMS Gone Bad: Avoiding Pitfalls in Your Implementation

If Tolstoy had been a LIMS implementation project leader instead of a writer, he might have said, “Every LIMS project is unique, but they often fail in similar ways.” LIMS Implementations can be massive, expensive projects with many competing stakeholders, priorities, and complexities. But don’t worry, this blog post will help you steer around the pitfalls. When undertaking such a huge investment of time and resources, there are many opportunities to get lost along the way. We have learned from experience that some consideration up front can provide a bulwark against common failures.

Control the Scope

Scope creep happens when the project scope widens without consideration and control. This can push your project far over budget, over time, and over the patience of every stakeholder.

For example, we have seen organizations embark on an implementation project with incomplete requirements. Thorough requirements gathering is a foundational step, because it sets the stage for successful implementations. That’s why, when CSols is engaged to do a strategic selection, we spend a lot of time talking to stakeholders, observing workflows, and understanding the lab’s pain points.

To avoid scope creep in a LIMS Implementation, consider the following:

  • Define the relevant data first. What data do you want to capture? What data do you need from the system?
  • Take the time to understand your lab’s specific workflows, processes, and data management issues.
_large_webinar_Right First Time LIMS Implementations

Engage the Lab

You can build and deploy your LIMS end to end based on the informatics industry’s best practices and your organization’s stack of standard operating procedures (SOPs), but if you don’t have buy in from lab personnel, your go live will produce nothing but issues. The LIMS must serve the lab, not the other way around.

CSols worked with a client whose LIMS implementation had gone off track. We were brought in because user adoption had been incomplete. We found that the lab, which was in Québec, was not provided with adequate user training in French, the first language of most of the staff. This was an easy fix, and something that could have been avoided if all the stakeholders had been involved from the beginning.

To avoid a major mismatch between the goals of the project and the needs of the lab, consider the following:

  • Lab staff should be involved in the project from the very beginning.
  • Avoid recording data you don’t have a use for; this creates extra data entry work for the lab, with no benefit.

Consider the Minimum Viable Product

You may be tempted to go for an all-or-nothing go live. After all, you’ve got a shiny new LIMS that can do so much for your lab, and you want it all right now. Besides, every part of your process links to the next, so where would you draw the line anyway?

Let’s say your lab receives and stores samples and then pulls them from storage for in-depth testing and disposal. Is there value in getting specific functions live faster, like inventory management, to help search for and pull samples? Or, is it worth delaying things that would have a real, tangible benefit to the lab while you sort out all the finicky details of the testing process? Would changing everything all at once be overwhelming, both for the project team and the lab? It might be easier to learn the inventory system first, then roll out the more complex testing process once users are already comfortable with navigating the software.

To avoid the risk of overwhelming staff and to get measurable benefits fast, consider breaking your LIMS implementation into phases and/or sprints, which are made live as they are individually completed. When breaking down the project into phases or sprints, keep the following in mind:

  • What is the smallest unit that would provide a tangible benefit to the lab? This is the minimum viable product, and a good way to break up your phases to get good results to the lab as fast as possible.
  • Go-live is the ultimate test of whether your system design will really work for your laboratory. If it turns out you have taken a wrong turn in your design, it’s far easier to course correct early in the project and change the plan for future phases, rather than to discover at the final go live that much of your work must be scrapped and redone from scratch.
  • Having milestone successes that provide tangible benefits quickly avoids loss of momentum and buy in from shareholders.

A LIMS Implementation project is a substantial investment that will always involve some risk of failure. With some careful forethought, you can avoid the major pitfalls. By controlling your scope, engaging the lab early and often, and considering the minimum viable product to get measurable benefits from the project, fast, you can keep your implementation on the right path. Just remember one of the things that Tolstoy did say: “We can know only that we know nothing. And that is the highest degree of wisdom.”

Because LIMS implementations are so complex and so rare in the lifetime of an organization, consultants like those at CSols, with the knowledge and experience of more than one prior implementation, can help you bring your implementation to a successful finale.


What pitfalls have you experienced (or avoided) in major implementation projects? Can these ideas be applied to projects outside of the LIMS space?

Share Now:
Categories:
Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.