10 Mistakes to Avoid in Selecting and Managing LIMS and LI Software

Better to be safe than sorry — especially when ‘sorry' means a lot of time, energy and money lost 

If you have not yet selected your laboratory information management system (LIMS) or laboratory informatics (LI) product nor begun to manage it, this is your chance to learn from some of the mistakes of others. Distilled from my personal experience of working with LIMS for over 20 years in a variety of industries, products and activities, here are 10 of the major mistakes to avoid.
1. Cutting corners on product selection steps
Everyone is busy. There's no extra time to go through the entire selection process for a new software product implementation — not even one that might cost your company hundreds of thousands or even millions of dollars to implement. So, you try to fit this task in among everything else you have to do. Naturally, you're tempted to cut corners.

While it's true that no one does a perfect job in product selection in the real world, don't skip a step just because it's onerous. Instead, carefully weigh the risks of skipping one step over another, and decide to skip a step to save time only after you've honestly assessed it as a less risky step to skip than others. Hint: It's better to skip several lower-risk but easier steps than a difficult step that carries more risk to the success or failure of the overall process.
2. Skipping reference checks (see mistake # 1)
Almost every year, I hear of at least one company that purchased a software product or hired a consulting services firm without checking the product's or consultant's references. The client company invariably ends up wasting a large amount of money on something or someone that doesn't work out. Why does this happen?

• Sometimes, the customer cuts corners and shortens the length of their selection process this way
• Or, sometimes, they deem it unnecessary because the account rep was so "nice" (see mistake #3).
• Other times, whomever the customer deals with simply refuses to provide any references. This is not only unprofessional, but should serve as a red flag!

Everyone should and can provide you with references. Even if the product is new or the person is new to consulting, they can dig up some references for you to contact. Even though vendors and consultants will almost always refer new clients to former ones who say only good things about them, it's still useful for new clients to speak with them. It's surprising what some carefully phrased questions will reveal from even the most upbeat and positive reference sources.
3. Buying a product because the company is "nice"
Customers sometimes tell me they've selected one software product over another because one company was really "nice" or because the software vendor's account manager was so "pleasant." Unfortunately, a "nice" sales rep does not necessarily lead to a vendor's ongoing support of your project, nor to "pleasant" (or well-organized) people working with you during implementation. "Nice" and "pleasant" are certainly criteria to keep in your selection process — but they should not be the only criteria you use nor should they be your primary criteria.

On the other hand, I'm not suggesting you buy a software product that's really terrific if it's provided by a vendor who treats you like dirt, either. That's not a good harbinger of the support you'll get from them nor of your experience in any other future dealings with them.
4. Not nailing everything down before the contract is signed
The contract negotiation phase is when your leverage is the greatest. Don't give it away. If you agree to put aside one term or another, consider that term to be gone. Don't expect to revisit it later, whatever it is. If it's not part of the original agreement, it's not part of the agreement at all. If it's not important enough to include in the initial contract, then it's not important enough to bother with later either. The people on the other side of the table may try to threaten you with various scenarios if you don't give in and sign the contract right away. Some of what they say will be just empty threats, but others scenarios could be things you really don't want to happen.

For example, a software vendor might say to you, "If we don't get the contract signed by the end of this month, you'll lose the really fantastic resource we've promised you." This is probably true. That exact resource will probably end up on some other project if you don't move quickly. However, assigning resources before contracts are signed is always a tricky business. Contracts often take much longer to finalize than originally planned, and resources tend to get shuffled many times before the actual start of the project. So, don't get too attached to anyone's name or credentials until you're sure of your start date. There are plenty of good resources out there, and many people are available who work independently of any software vendor to also provide services.

Hint: It is a good idea to investigate alternative services in advance of your contract negotiations. It further increases your leverage. With that said, before you start negotiations with guns blazing, remember that the company you're negotiating with is the company you'll be working with for a long time once that contract is signed. You don't want to alienate them. Someone on the other side of the table may hold a grudge, and that could lead to some unfortunate results.
5. Handing over your money without checking milestones
Similar to contracts, payments are a form of leverage. If you hand over the entire project payment up front, you no longer have payments to use as leverage as your project moves along. Most companies know not to make one lump sum payment up front.

However, if you've created a system of payments based on project milestones, you need to check that the milestones are actually achieved before making those payments, or you've basically given away the leverage this system was designed to maintain. If a milestone is not met

1. payment should not be made at this time, or
2. the milestone should be adjusted.
After all, some milestones are set incorrectly. This issue should be addressed in the same manner that project plan changes are addressed. What I mean is that milestone changes should be handled as soon as they arise and reviewed with regard to the overall project needs and goals.

To put it another way, owning a car with a safety belt isn't protection in an accident if you don't put it on before you start the car. Like the safety belt, merely setting a milestone isn't going to protect you unless it's actually used for the purpose for which it was intended.
6. Believing people are experts just because they said so
It surprises me how easy it is for any of us in the industry — software vendors or consultants — to simply tell a customer we're experts in one thing or another. People or companies aren't experts just because they say so or because their employers say so. Experts, by definition, have the right skills and experience to rise above the crowd in handling whatever it is in which they are experts.

Additionally, we all say great things about ourselves in our resumes and on our company Web sites. But remember that all these great things, which may or may not be true, are just windows into the possibility that we might truly be experts in anything particular. Even if everything you read is true, keep in mind that, just because someone has completed the multitude of projects listed on their resumes or Web sites doesn't mean they did any of them properly. A little skepticism goes a long way to protect your investments.
7. Pretending your LIMS or LI project isn't a software project
I sometimes hear customers say that they'll implement their LIMS/LI software without giving any thought to the usual software installation/implementation issues. "After all," they say to me, "it's not really software — it's a LIMS." The last time I looked at a LIMS — and that was just a few minutes ago — it looked to me just like software, subject to all the pitfalls of any other software project. Just like any other software project, the larger it is, the more likely it can go off-schedule and fail entirely.

For example, as I write this article, I'm also writing a "configuration" item for a major LIMS brand and the item has hundreds and hundreds of lines of code. The software vendor insists on calling this item "configuration," but it's still computer programming and still needs the usual testing and acceptance steps. It doesn't matter what language is used to write code for a LIMS, it's still code! It's updating records; it's prompting the user; and it's quite complicated. Fortunately, my customer is creating a process to verify that this "configuration" has been created with a high level of quality. Just because I'm very experienced in doing this sort of thing doesn't mean I can't make mistakes or misunderstand what the user wants. Nor does it mean that change control won't be needed once this LIMS goes into production.
8. Assigning blame to your team members
Assigning blame on a project causes resentment. It could also cause team members to start lying to you to avoid the blame. Instead, try to determine what caused problems and to find ways to correct them.

While placing blame is counter-productive, the search for the cause of problems can be conducted in an efficient and professional manner. Team members are much more likely to participate in a professional process, which means that problems can be more easily identified and addressed. With that said, there will still be the occasional team member who is either so insecure or who has been burned enough times that he or she will not cooperate in this effort.

Reality Check: if your company has a history of assigning blame and if your team believes that that is all you are doing on your current project, they won't be fooled. Just because you call it a "process" and assign a fancy name to it, it will not be enough to win their trust. Instead, they'll continue to resist.
9. Skipping the opportunity to learn from the project audit
By reading this article, you can learn from some of the mistakes others have made. The next step is to learn from your own mistakes as well. When your project is finished, review both the successes and failures of your project to help you to do the right things again on your next project and to change or avoid the problems you experienced during this project. While reviewing every detail will likely prove too time consuming to be useful, by focusing on the major issues — both good and bad — your team can learn from these significant experiences.

For example, I know of a company that selected a LIMS, but their implementation project failed. They ended up repeating the same selection and implementation process five more times! All six implementations failed, although the sixth product was given a second chance and has had some limited success in its reincarnation.

This company probably spent hundreds of thousands of dollars each time the selection and implementation failed. They then became frustrated with the product they had selected, threw it out, and began the entire process again without understanding the reasons behind the failure. Only after the sixth failure did they finally realize that their implementation process was seriously flawed. Once this dawned upon them, they were finally able to make progress in the next implementation — their seventh.

More specifically, the company finally realized that they hadn't treated their LIMS implementation as a software project (see mistake #7) and hadn't properly managed the project scope, among other factors.
10. Ignoring pitfall lists like this one
For those of you convinced that you won't make the same mistakes everyone else makes, there's probably nothing I've said here that will convince you otherwise. However, please believe me when I say that, each year, I run across companies making exactly the mistakes I've highlighted in this list. I hope that won't include you but, as in everything else, it's better to be safe than sorry — especially when "sorry" means a lot of time, energy, and money lost.

Gloria Metrick is the owner of GeoMetrick Enterprises and publisher of the Out on a LIMS monthly newsletter. She may be contacted at