---

---

First of all, make every effort to ask a question the vendor cannot answer "yes" or "no". Instead ask, "How can X be accomplished?", forcing the vendor to elaborate, at least a little. Then when the vendor responds (sometimes too briefly &/or with terminology you don't understand or that is vague), ask the follow-up question "How can X+1 be accomplished?". Be prepared to ask "How" follow-up questions at least five times to ensure you've drilled down to the heart of the matter. Along with this, we need to be aware when we're talking with a salesperson what their objective is (the sale) which is different than our objective (to understand the vendor's product before buying it). It may require bringing in a technical person from the vendor to help bridge that communication/knowledge gap.

This is advice I had been given or had read years ago, and have found works very well for me. I sometimes feel pretty stupid having to ask & ask questions, but it's much better to suffer a little short term embarrassment than to end up with a product or system that doesn't meet, or requires a great deal of extra resources to meet, your needs. Often times the communication gap occurs because the salesperson subconsciously assumes you know what he/she knows, so they don't provide the details you require initially. Here to, a few "How" questions may help them recognize they need to be more complete in their answers, and they may begin to provide more info with you having to ask so many "How do we get X done?" questions. And if it turns out the vendor is in fact misleading or even out-and-out lying to you, it will likely become very obvious after a few "How" questions; then you can decide if you really want to deal with them or not.

---

I would certainly investigate the support group of any potential LIMS vendor and what kind of support they offer during and after implementation. This would include how they handle bug reporting and fixing as well as how they handle upgrades to their software. LIMS is rarely a turn key system, so I find a quality support team from the vendor a "must have."

---

Always have in mind what you need to report from a LIMS. This will ensure that the basics are met.

---

Insist on a configured demo with some critical issues that are specific to your business included in the demo - verify anything a sales person tells you!

Carefully determine what market segment you fit into (e.g., small lab, world-wide, networked concern), so that you pick from the appropriate system choices

Spend time, then more time, on the planning end, in this case on defining User Requirements

---

Here is a bullet proof way to select a new LIMS:

• Document your processes preferable by flow chart.
• Create a demo scenario.
• Get quotations.
• Evaluate and select 5 vendors (price tag is not relevant yet).
• Invite them to show their product based on your scenario.
• Evaluate and select 2 vendors.
• Create new scenario for a test case and test installation.
• Make at least one test installation with you favorite vendor.
• Negotiate price and terms (Before you buy get the prospective vendor project manager known).
• Make sure you have a professional project manager (could be done by an external consulter) don't always look at pricing - cost as the main indicator. Pricing can be deceiving.

---

Have your requirements written down and signed off by the business owners before you start a selection. Provide use cases to the vendors ahead of time that exemplify your expected process. This should allow you to compare and contrast vendors on a level playing field and minimize the risk to your org when the implementation starts.

---

Set up a User Requirements document before looking at systems. A "Road Map" is important in setting the path going forwards, and finding out what is needed can be a big step in determining a system. Get input from all stakeholders (or as many as you can). A system without buy-in from the stakeholders may wind up being a failure. Keeping people apprised of how the project is going is important for a LIMS setup. A Proof of Concept can be helpful in finding whether a product will fit the organization's needs, and to actually see the product in use. A "Road Map" detailing the long range plans for a LIMS system can give an indication on how to roll out the product, and also which code will need to be customized for the organization. Depending on use, a transfer strategy for old data may be needed. Do you need to keep an older LIMS system in place, while getting a new instance? The LIMS company itself is also something to consider. LIMS support, company history, and financials should be looked at, and especially the LIMS company's long term strategy.

---

Get the users involved from the very beginning of the project. The URS Catch 22: Many users don't know what are the full capabilities of a LIMS; how then can they provide their requirements? Give product demos and information to the users early on in the selection/development stage.

---

• Get copies of the ASTM E2066-00 Standard Guide for Validation of Laboratory Information Management Systems and the ASTM E1578-93 Standard Guide for Laboratory Information Management Systems (LIMS) and read them before you start the project.
• Be sure you thoroughly understand and document your requirements and the requirements of your customers before you start the project.
• On your detailed RFP ask the vendor the correct questions. Does the line item come:
• Standard with your LIMS and within quoted price.
• Available as an optional module available at separately quoted price.
• Can be developed as custom code at separately quoted price.
• Not available or can't be done.
• If this is your first experience at installing a LIMS make your best cost estimate and then double it and you will be a lot closer to the real cost of purchasing and configuring/customizing the system.
• Understand your business rules and know what other systems within your company the LIMS will need to communicate with before you start the implementation.
• Conduct phone interviews with users of the system(s) under consideration. Where possible, conduct an on site visit with a user who is actually using the system and if possible this site should be in the same type of business as you are. You can learn a lot about the system and the vendor from an actual customer, even though the customer list from the vendor may not include dissatisfied customers.
• Make a visit to the vendor's facility to see first hand how they work and get to know their staff. This relationship will be more like a marriage than a quick affair.
• Determine if the vendor offers sufficient training on their system so that you are competent to run/configure the system when you're through with the training.
• Be sure to get an ER diagram of your LIMS from the vendor. Seeing how the system is actually laid out will help you better understand the system and especially helps when you have to trouble shoot a problem.
• Have the lab intimately involved in the system from the start -- you will need their buy in to make it work.
• Make sure you have adequate staffing for the project and support from upper management.
• Have the authority to make the decisions needed, if you don't it will greatly delay the project.
• Make sure the LIMS vendor follows ISO standards, ideally ISO certified, for their programming.
• Make sure the LIMS vendor is financially sound and has the customer base to remain that way.
• Does the vendor have an active user group? If it doesn't you might want to think twice about buying the system.
• Make sure the system (software and hardware) will support the sample load your lab(s) routinely run and that it is fast enough to actually use. This is very important on multi site installations.
• Test the vendor's technical support. Look at how they continue to support previous versions of their software. Are upgrades part included in your support cost?
• Make sure your hardware is correctly sized; the hardware is by far the cheapest part of your LIMS investment so make sure it is as fast and as large as you can afford. I have never been criticized for having too fast a screen turn around or a query that run too fast.
• Remember that once you have the system configured you are only half way through the project you still have to validate the entire system.
• Don't forget to test your backups, you will most likely need them at some point in time.
• Don't ever use your production server for testing, have a test and/or development system for conducting your testing. Make sure it works before you put it into production.
• Make sure you have a good DBA on staff that knows how to tune your database to get optimum performance.

---

Think about what you want in an ideal system. Don't artificially place limits on your requirements based on your current processes and/or system. After getting all your requirements, rate them as must have, nice to have, wish list.

---

• Document all your requirements; rank these as necessary and desired.
• Gather information on existing systems and how they work.
• Visit sites using these systems if possible.
• Adjust your requirements list based on what is available.
• Score any systems that meet your necessary requirements and are within your budget.
• Look for systems that are flexible, but be prepared for a long slow period of gradual modifications to meet your needs.

---

• Get buy-in from all stakeholders upfront and include them in the process of specifications through vendor reviews.
• Be realistic in setting expectations as to project length as it always takes longer than you think.
• It often takes longer than expected due to change: from process optimizations to behavior modifications. Expect to make policy changes along the way and before you go live.
• When judging products, make sure the chosen products map to your vision going forward. Do you simply need a point solution as there will be few changes? Are you a minimalist so that an out of the box product will work? Do you want the "keys to the car," Then be sure to choose a product that has an open and robust SDK as well as an open and documented API layer (interfaces).
• Do reference checks and site visits to get a truer flavor of a vendor's offering and customer experiences.
• Document and prioritize all user requirements before speaking with vendors, capturing all workflows, instrument integrations as well as interfaces to existing systems.
• Be sure that the lab user interfaces are flexible enough to work the way your lab workers actually work. While changes may be required, change for change sake makes no sense. The meaning here is that if the lab process already works efficiently, choose a solution that maps to it rather than changing the way the lab works. Choosing the wrong solution in this context will exacerbate resistance and even open hostility.
• When choosing a vendor and a product, make sure that you also factor in the reputation of the chosen vendor's professional services people, as this is the group that you will work most closely with. Never pay a professional service person who is totally green as training vendor people is the vendor's responsibility, not yours.

---

Is the LIMS capable of customization to fulfill exactly the needs of my laboratories? I definitely would check this with any vendor of choice and would ask them to show me at least one or two of my special needs.

---

Many LIMS evaluations today fall into IT Sponsorship. We find more and more of these evaluations are driven by IT requirements irrespective of the functional requirements of the organization. Functional requirements should be the primary driver.

My main advice is to get references for operations with requirements similar to yours. Make sure the references are running the same version of the application you are evaluating. Don't accept a reference that is running a previous version of the application. Be specific - many application are the same in name but version differences make them completely different applications. Make sure the application you intend to implement is proven to work for your needs.

---

---