10 Mistakes to Avoid in Selecting and Managing LIMS/Laboratory Informatics

10 Mistakes to Avoid in Selecting and Managing LIMS/Laboratory Informatics
by Gloria Metrick

If you have not yet selected your LIMS or LI (Laboratory Informatics) product nor began managing it yet, here are ten of the major mistakes that companies should avoid. This is your chance to learn from some of the mistakes of others. The items in this list are not in any particular order:

1. Fluffing 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.

2. 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 or another. Skip a step to save time only after you’ve honestly assessed it as being a less risky step to skip than others. 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.

Skipping reference checks (see # 1).
I’ve worked in the LIMS industry for many years, and almost every year, I hear of at least one company that purchased a software product, hired a consulting services firm or a consultant and was told they didn’t need to check the product’s or consultant’s references. The client company invariably ended up wasting a large amount of money on something or someone that didn’t work out. Sometimes, the customer cuts corners and shortens the length of their selection process this way, or they deem it unnecessary because the account rep was so “nice” (see the next item). Sometimes 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 we almost always refer new clients to former ones who say only good things about us, 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 or account manager is “nice.”
Customers sometimes tell me they’ve selected one software product over another because one company was really “nice” or 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, but it’s provided by a vendor that treats you like dirt, either. That’s not a good harbinger of the support you’ll get from them nor 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 on. The people on the other side of the table will try to threaten you with various scenarios if you don’t give in and sign the contract right away. Some of what they say is just empty threats, but others describe 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 the 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 who also provides services. However, 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–who is less than professional–may hold a grudge, and that could lead to some unfortunate results.

5. Handing your money to the payee without checking the 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 move along. Most companies know not to make one lump sum payment up front, anymore.

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. Merely setting a milestone isn’t going to protect you—like the safety belt–unless it’s actually used for the purpose for which it was intended.

6. Believing the people involved are experts because they said so.
It surprises me how easy it is for any of us in the industry–software vendors, 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 they’re experts in.

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 this 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/LI project is not a software project.
I sometimes hear customers say that they’ll implement their LIMS/LI software without 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.
Assigning blame on a project causes resentment. It can 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.

The difference is blaming people is counter-productive; while the search for the cause of problems can occur 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’re doing on your current project, they won’t be fooled. Just because you call it a “process” and assign a fancy name to it will not be enough to win their trust. Instead, they’ll continue to resist.

9. Skipping the project audit.
By reading this article, you can learn from some of the mistakes others have made. Then, plan 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 do the right things again on your next project and to change or avoid the problems you had during this project.

However, reviewing every detail is too time consuming to be useful. After all, some details are too small to be of real interest. But by focusing on the major issues, both good and bad, your team can learn from these significant experiences.

For example, a company I know of that shall remain nameless 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. When that dawned on them, only then were they finally able to make progress in the next implementation, their seventh.

More specifically, they finally realized that they hadn’t treated their LIMS implementation as a software project (see # 7) and hadn’t properly managed the project scope, among other factors.

10. Ignoring lists like these.
For those of you convinced that you won’t make the same mistakes everyone else does, 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 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.

  •  

    Reprinted with permission from Scientific Computing 2008.