How do you define success for a LIMS implementation? The obvious metrics include staying within budget, getting done on time, and getting the features you expected. These are the keys to any kind of major software implementation from LIMS to WIMS, and from ERP to CRM.
At the end of the day there is an even more important measure of success—did you improve operations with the implementation? If you are more productive and/or provided greater access to information and improved quality in some demonstrable way, the implementation should be considered successful.
So how do you assure that your implementation project will be successful? Focus on these six success factors and your chances will increase.
Just because you think you can self-implement, doesn’t mean you should. There are a variety of LIMS offered today—some are no doubt easier to implement than others. But it is highly unlikely that any system will perfectly match your business rules and lab practices. There will be configuration changes, tables to set up, nomenclature to modify and myriad other nuances you will want to incorporate. And let’s not forget there is another constraint, you already have a day job. Implementing even the simplest system requires a fair amount of time dedicated solely to transitioning procedures, data, networks, and other systems.
To assure a positive outcome, you need a thorough understanding of three very specialized disciplines, 1) lab operations, 2) LIMS functionality, and 3) IT infrastructure management. Do you have that kind of time? Certainly you have the laboratory knowledge. But do you have the other skills? A trained implementer will have at least some experience in all three areas and can provide the quickest path to a successful implementation. They will also provide the necessary project management skills to develop a plan and meet the schedule. If possible, that implementer should come from the LIMS company. There may be good third-party implementers for some products, but a company-based implementer is more likely to be intimately familiar with the latest system functionality and best practices.
Training is often the first line item cut when you go over budget. It is tempting to try and get by without it, taking a learn-on-the-job approach. But even using the most intuitive system will be a new experience for lab workers. There will be new practices, new terminology, and new workflows. You don’t want chemists fumbling around in a manual while they’re filing a beaker with hydrofluoric acid. The subsequent problems caused by under training tend to linger well beyond implementation. An inverse relationship develops between the amount of training and the number of calls to the LIMS Customer Support Help Line. This is not the most productive way to deliver training.
Formal training provides step-by-step instructions and exposes people to the overall flow of the product. The team needs to have at least three levels competency. First, anyone who will use the system needs a basic understanding of core capabilities. Even with the most intuitive system, training on basic functions will accelerate the improvements in productivity and reduce downtime. Second, you do need at least one or two power users who understand the full capability of the system. These folks can serve as in-house trainers, administrators, and troubleshooters, and will help other users with more sophisticated features. And third, you need some form of IT support so that network and communications infrastructures are managed properly. A well trained team will take ownership and responsibility to implement changes.
Customization is seductive. As the famous slogan goes, you get to “have it your way.” Unfortunately, a LIMS isn’t a hamburger. When you customize a system you are actually creating a one-of-a-kind piece of art. Every change must go through additional integration testing to make sure you didn’t break something else. Truly custom development—customizing the code to specifically match your workflow—requires an engineering learning curve. You are potentially having code written that’s never been compiled before. This process often results in an open-ended implementation because one change frequently leads to another. That’s when you run smack into the evil cousin of customization, named “scope creep.”
Plan, plan, plan. Make sure you thoroughly document requirements before the system is implemented. Be deliberate about determining where the system needs to change in order to match lab practices, and be open-minded about when to change lab practices to follow the more efficient flow in a LIMS. And if there isn’t a good match between core functionality and your needs, don’t try to “customize away” the issues. When customization ends up driving implementation, you are essentially designing your own LIMS from scratch. Conversely, a highly configurable system typically has favorable cost and time factors. There is just less to do and it’s generally easier to make changes. And because a configurable system has a well-defined set of features and functions, it is easier to develop achievable schedules and budgets.
You see your LIMS as an exciting new tool. Others in the lab may see it as threatening. People get into a rhythm with their job and disrupting that rhythm disrupts the flow of work in the lab. Change is difficult, especially when you have no control over it. Too often the team is shielded from the distraction of the implementation and not engaged in the process. But the success of the project depends on their acceptance, enthusiasm and expertise. And if the team isn’t involved, they may resist the effort and even undermine your chances for success. They will pick at the system, accentuating any weaknesses rather than looking for ways to create a smooth transition.
Inform and involve. For a lot of folks, that may simply mean that you keep them up to date on the business objectives and status of the project. Not just status but milestones that impact them. Everyone needs to understand what’s in it for them. For others, you should have them think about their work domains and consider how they can help the implementation. What prep work can they do? What potential issues do they see—and how could they solve those issues. You don’t want twenty people on the implementation committee, but keep the larger team engaged. Get their feedback on functions that will impact them and be sensitive to the fact that you are making changes that will affect their daily life.
A LIMS is one of the largest and most important investments for the lab and shortchanging the implementation by trying to squeeze it in between other priorities will have long-lasting effects. The project will be delayed every time the team gets busy and it will never be fully implemented. Schedules will be revised, corners will be cut and in the end, a poor implementation will lead to poor results.
There is no good or bad time to implement a new LIMS. The key is to be proactive. First, you have to make the implementation a priority and allocate adequate resources. LIMS implementation must be an imperative for the company. Second, there needs to be a point-person who will take responsibility and make decisions. Otherwise the project will meander. And third, work closely with your LIMS company to build a realistic plan. Make sure you understand the phases of the plan and agree on the deliverables. This is not just an investment of dollars, it is an investment of time and you should expect it to payback more than it costs.
No LIMS is going to address one hundred percent of your needs right off the shelf. Even with a well-thought-out plan you will still run into the occasional problem that can’t be quickly solved. Maybe a manual process that can’t easily be automated. Or a function that doesn’t quite work exactly as you thought it did. Or a database translation issue. These are all important issues that ultimately must be addressed. But should you shut down the project or scrap the new LIMS because of these issues? Your business is too important to delay progress.
Pick your battles. Keep perspective and don’t lose momentum over what could be just small bumps in the road. Yes, you should absolutely hold the LIMS vendor accountable to make sure you get what you paid for. But think big picture and prioritize the issues. Put the issues into four categories: 1) cannot go live without (i.e. there is no workaround), 2) serious issues that have short-term workarounds, 3) minor issues that will be an inconvenience until resolved, and 4) minor issues that will have no material impact. Only the items in the first category should hold up your implementation. Before moving forward however, all the items must have a plan of action. Don’t leave any issues unaddressed.
Focusing on these six success factors will build a strong foundation. Be proactive, inclusive, and persistent and you will more quickly realize the productivity and quality benefits of your new LIMS.
