Selecting the right LIMS is an important step, but it doesn't guarantee a successful implementation. Even the right platform and vendor partnership can fall short without the people, planning, and commitment needed to bring the system into day-to-day laboratory operations.
In Part 1 of this series, we explored the organizational realities that influence implementation success, including user adoption, change management, workflow complexity, and future scalability. In Part 2, we turned to the vendor evaluation process, looking at what labs should consider when assessing potential LIMS providers and implementation partners.
But once you've selected a vendor and the project is underway, what does it actually take to get implementation right?
For the third installment, we continue with our interview with Labbit customer Ann Chatelle, Implementation Specialist III at Ancera, about the practices and decisions that separate smooth implementations from challenging ones. Drawing on her experience across numerous LIMS implementations, Ann discusses the importance of customer engagement, involving bench staff, meaningful testing, validation, and designing a system that can grow with the lab.
Q: What do the implementations that go well have in common? Is there a pattern you've seen consistently on the lab side?
Ann: After being involved in so many implementations, I've started to notice the same pattern. The projects that go well have a customer that's engaged from day one and stays engaged through go-live.
They show up to meetings, ask questions, make decisions, and test what's being built. They don't expect the vendor to disappear for six months and come back with a finished system. Implementation is a collaborative process, and the customer has to be an active participant.
Requirements changing doesn't bother me. That's just labs being labs. What matters is having a team that can make decisions and keep the project moving rather than debating every detail or trying to solve every possible future problem in phase one.
Honest communication is just as important. If something isn't working or the timeline needs to change, I'd much rather know early so we can address it than have everyone pretend things are on track.
Q: What does good internal project leadership look like on the customer side? What separates the labs whose implementations go smoothly from the ones that struggle?
Ann: I don't think good project leadership means one person running the entire implementation. If the lab has real buy-in, everyone has a role to play. That said, there should always be someone accountable on the customer side, and projects tend to run more smoothly when both the customer and LIMS provider have dedicated project managers.
The two Labbit implementers I worked with brought experience that was helpful throughout the process. They took the time to understand how we approached our work, asking questions about our processes and offering suggestions based on their experience with other labs. Those conversations helped us think through different ways of doing things and identify opportunities to improve our workflows. It was helpful to have people who understood the system and could also look at our processes from an outside perspective.
One thing I've noticed is that the labs willing to give their staff time to participate almost always have better implementations. If people are expected to do their full-time jobs and somehow fit implementation work in around them, something is going to suffer.
Leadership also needs to recognize that not every workflow decision should come from management. Leaders understand where the lab is going, but bench staff understand how the work actually gets done. If you want a system people will use, let the people doing the work help design it.
The LIMS administrator is important, but they can only build what they're asked to build. The more bench staff understand how the system works and have opportunities to contribute, the better ideas they bring to the table.
The best leaders don't try to own the whole implementation; they make sure the right people are involved and have the time to contribute.
Q: How important is the lab team's willingness to actually test the system, and what does meaningful testing look like versus going through the motions?
Ann: Testing is one of the most important parts of an implementation. I've seen great builds struggle because the lab didn't spend enough time testing, and I've seen average builds become great because users found ways to improve them before go-live.
Meaningful testing isn't just clicking through a workflow to confirm it works. It's trying to break it. What happens if someone scans the wrong barcode? What if QC fails? What if a sample needs to be rerun or an instrument file is missing? Those are the situations that happen in a real lab every day.
This is also why I like having bench staff do as much of the testing as possible. They're the ones using the system every day, and they'll find things an implementation team or LIMS administrator may never think to test because they know the workflow inside and out.
The goal isn't simply to confirm that the system performs as expected. It's to identify problems and opportunities for improvement while the implementation team can still address them.
"Meaningful testing isn't just clicking through a workflow to confirm it works. It's trying to break it."
Q: How do you get bench scientists to actually adopt a new system rather than quietly routing around it?
Ann: I don't think you get bench scientists to adopt a system after it's built. You get them involved while it's being built.
The earlier they're part of the implementation, the more ownership they have. Let them help design workflows, answer questions directly, test the system, and request changes while things are still relatively easy to adjust.
Most bench scientists don't want to fight the software. They want a system that helps them do their jobs and captures the data they need. If they feel like they've had a voice in the process, they're much more likely to embrace it instead of finding workarounds.
I've found that when bench staff are involved early, they often become some of the biggest advocates for the new system. They understand why it was built the way it was and know their feedback helped shape it.
“I don't think you get bench scientists to adopt a system after it's built. You get them involved while it's being built.”
Q: There's almost always pressure to go live fast. What gets sacrificed when that pressure wins, and is speed ever actually worth the trade-off?
Ann: I've worked in regulated labs most of my career, and I've learned that trying to rush go-live usually creates more work than it saves.
If the system isn't properly tested, users aren't adequately trained, and validation is rushed, you're going to spend the first few weeks after go-live fixing preventable problems. Support tickets pile up, the lab loses confidence in the system, and everyone ends up frustrated.
I'd rather spend a little more time up front testing real-world scenarios, making sure workflows work the way the lab expects, and ensuring users are comfortable before go-live. That almost always results in fewer support calls and a smoother transition.
In regulated environments, validation isn't just paperwork. It's proving the system is ready for production. If you skip those steps to save a few weeks, you'll usually spend that time back after go-live dealing with issues that could have been caught earlier.
Q: In regulated environments, how do you balance validation requirements against the push to get live quickly?
Ann: I've never looked at validation as something you do just because you're in a regulated environment. To me, it's about proving the system is ready before you ask the lab to depend on it every day.
The key is making validation part of the implementation plan from the beginning rather than treating it as a final hurdle before go-live. That means understanding the system's intended use, identifying what needs to be tested, and building the time and resources for those activities into the project timeline.
If workflows haven't been thoroughly tested and users haven't been properly trained, you'll know almost immediately after go-live. Support tickets start piling up, users make mistakes, confidence in the system drops, and everyone spends more time fixing problems than processing samples.
I'd much rather spend a little extra time validating real-world workflows and making sure the lab is comfortable with the system than rush into production. In my experience, that time is almost always earned back through fewer support issues, fewer user errors, and a smoother transition.
Good validation isn't about slowing a project down. It's about making sure the lab can trust the system on day one.
Q: How do you design an implementation for the lab you'll be in five years, not just the lab you are today?
Ann: This is probably one of the biggest things I've learned over my career: you have to build for where the lab is going, not just where it is today.
Labs never stand still. New assays get added, instruments change, regulations evolve, acquisitions happen, and everyone wants more automation and better data. If you build a system that's only designed around today's workflows, you may find yourself redesigning it again in a year or two.
When I'm designing a workflow, I'm always asking, "How is this going to grow?" Can we add another assay? Another site? Another instrument? Can we automate this later? Will this still make sense as the lab's data needs evolve and AI becomes more integrated into laboratory operations?
That's also why I try to avoid one-off customizations whenever possible. I'd rather build something flexible that can grow with the lab than something so specific it only solves today's problem.
Of course, that doesn't mean trying to build every possible future requirement into the first phase. It's about making thoughtful decisions now that leave room for the lab to evolve.
"You have to build for where the lab is going, not just where it is today."
Conclusion
A successful LIMS implementation takes more than choosing the right software. It depends on an engaged customer team, leadership that makes room for meaningful participation, and a commitment to thorough testing, training, and validation before go-live. Having an experienced implementation partner who understands laboratory operations and can offer practical guidance along the way also makes a difference.
Ultimately, a smooth implementation isn't just about getting a new LIMS into production. It's about building a system that meets the lab's needs today and can adapt as those needs evolve.
Learn more about Labbit’s implementation services -> https://www.labbit.com/services
