---

Several years ago, a similar article was written for this very magazine on how to select a LIMS. For those the read the previous article, this is an expansion of it, but you will recognize some of it.

That initial article was written specifically about selecting a LIMS, but consider that some of this advice applies to selecting other things that you will purchase to be part of your implementation. In the modern “cafeteria-style” of selecting different companies to provide services from the ones selling the software, or of purchasing several software packages to work together, it is often the case that it is not just the LIMS, itself, for which you will need to budget and contract.

Defining Your Needs
First, you need a strong understanding of your own needs. Some questions to ask yourself and issues to consider are:

• Do you have buy-in from all parties that need to be involved? Try to finish this step, first, before spending too much time (and budget) on the others.


• How many laboratories will be included in this project? In what order will they be implemented? How many people will need to be supported in each laboratory? How similar are these laboratories’ needs? Will this number be extremely large and possibly in flux, such that you will desire some type of site license or flexible licensing strategy?


• Do you understand your laboratory and internal support processes so that you understand why you do things the way you do? Do you know which of your processes are flexible? Have you documented your requirements and their priorities? These will put you in a better position to explain your needs to the vendors.


• What other requirements do you have besides functionality? For example, are you trying to meet a specific calendar date for production, or prefer to run on a specific hardware platform?


• What is the financial situation of this project? Be realistic about the amount of functionality you can get for the amount of money you are spending. That is to say, be realistic about which functions are mandatory and which ones you might postpone for a future phase or that you might live without. This consideration should include all activities and resources, both internal and external. The more customized your final LIMS is, the more overall resources you will usually need to produce, maintain and upgrade it.


• What are your needs for both internal and external resources? How many of each can you count on? Put another way: Try to determine how many internal resources can be committed to the project at what percentage. Try to determine the number of external resources that you can obtain. These are both difficult to determine as the availability of resources changes as time passes. By the time you begin your project, the external market can have entirely changed from the time you began it, as can your internal staffing situation. Nonetheless, this will give you a general picture of your resource needs.

Creating a List of Vendors
Here are some starting tips to aide you in creating an initial list of vendors of both software and services:

• Look on web sites that give lists of product vendors, such as www.scimag.com
.

• Look at the web-sites of vendors that you already know about. Some give detailed information on the types of industries they focus on and the types of services they can provide.


• Subscribe to the LIMS list server and ask for help from other users.


• Attend conferences such as Pittcon. Before you attend, make a list of specific questions you want to ask. Prioritize which questions are most important in case you find yourself running out of time. For the same reason, plan which vendors to see first.


• Ask someone you know and trust if they can suggest a vendor for you to consider.

Call the vendors to have them send you a packet on their products if you do not already have this information. Clarify anything you see in the brochures or on the web-site that you need more basic information on or are not clear about.

Now, narrow the list down to a “manageable” number. These are the companies that you are seriously considering and will ask for details and estimates from, as well as Sales demonstrations. This list needs to be a small-enough subset of the original list that you can make comparisons. There is no magic number, but four to six seems to be the norm by the time you get to the product demonstration stage. In fact, this could be the number of RFPs you send out if you can get enough information from the vendors in which you have an interest in order to understand what they are offering.

“Four to six” is suggested as a manageable number for each RFP sent out, if you are separating the system implementation from the services or the system into several pieces.

Creating RFPs (Request for Proposal)
Issuing RFPs gives each vendor a chance to respond to you in a formal way and gives you a basis for comparison. At this point, you should already have assembled your team that will put together this document and work together at least through the selection process.

An RFP also helps in further steps of the project. Although the exact items mentioned in the RFP might not end up in the final implementation of the project, it can still be a rough guideline to aid in a cost-benefit analyses or in the budgeting process. It can also provide a guideline to return to when trying to determine the initial intentions of the project.

Preparing to Write the RFP
Before you write the RFP, consider these items:

• Spend as much time as you can thinking about what is “special” about your own needs. Many people think that they are just doing what everyone else is doing, not realizing that there are many things they are doing that might be special. Having 1000s of products that have specifications that must be included in the system and which need easy editing is special. Needing Drug Metabolism functionality is special. Doing multi-level tests such as Dissolution or Content Uniformity is special, and is more special when you do any but the most common methods. Keep in mind, too, that part of what differentiates a company from its competition is that its business process will be different, which will affect the final system implementation. Especially with the larger systems, no two systems will be alike, just as your company is not a mirror-image of your competitors.


• Create a numeric scale to evaluate the requests from high to low. For example, something that is just nice-to-have might be rated a zero (0) while a critical item might be rated a five (5), and other items being ranked in-between. By using numbers, you can weight the answers and create weighted sums to compare against by product. Do not use a scale with fewer than three categories.


• Try to get example RFPs from other projects. Try to get them from projects internal to your company, hopefully one that was buying a third-party software that would be implemented in a similar way to the system you might purchase, or one that was buying services similar to those you wish to contract for. Discuss the successes and failures of the RFP process with the people that created the RFP and get as many tips as possible.


• Create a format for the RFP that the vendors can use for responding. Think about how you want to use this to make comparisons visually easier for yourself. Either create a form that cannot be modified or simply ask the vendors not to modify your spreadsheet and explain that it is for the purpose of formatting the final responses. Make sure to allow sufficient areas for the vendors to respond with comments. As part of this format, write down any instructions that you want the vendors to follow.


• If you feel overwhelmed by the process of writing an RFP, there are RFP books and workshops to help you. There are also RFP software programs that can aid you in the organization and questions for the RFP. Go out on the web and you will find a number of them to select from. As with anything else, there are consultants that specifically consult on writing RFPs.

Writing the RFP
When writing your RFP, consider the following:

• The vendor does not “know” what you want unless you ask for it.


• When asking for overall functionality, mention in what way what you want to use it for might be special. Do not assume others in your industry are doing exactly the same thing. If it seems repetitious that this was mentioned above, as well, it is because this is a something critical to focus on.


• There are some items you might ask for overall descriptions of rather than asking specific questions, such as, “Give us an overview of the security provided with the system” or “Discuss your process for screening the personnel you will supply for our project.”


• Be careful about writing the RFP in a way that would require the vendor to recreate your manual system. After all, the purpose of having these systems is to create some level of automation.


• Ask for references. Have the vendor indicate what each reference has in common with you. Some references should be of a similar project size, rather than by company size. Ask for some references to be in your own industry and implementing similar laboratories. For product purchases, get a reference that will be using the same hardware/OS/network configuration, if possible. For example, some customers are planning to use Citrix in their installations and desire to speak with a current customer of the vendor that is using Citrix. For service purchases, ask for references on the services you are buying so that if you are contracting for personnel to be project managers, you get references on their project management skills not their implementation skills. Ask for both good and bad references. Believe it or not, some vendors are willing to let you talk to the bad references as part of a fair and open evaluation. After all, even the best companies with the best systems or services have unhappy customers.


• Make clear what functions you expect to purchase in a LIMS versus those that you expect to obtain elsewhere, such as instrument interfacing or Stability study management.


• When purchasing services directly from the software vendor or from a separate service provider, ask for examples of their software implementation methodology and the experience of the personnel involved. Whether you expect them to provide their own methodology or follow yours, you need to get an idea whether they can operate at your level. Remember that the methodology a company uses to develop their software is not necessarily the same as the methodology they will use to implement the system. If the vendor answers that all their people are “good” you have not found the right question to ask, yet.


• Ask if the vendor can assign people with some specific experience in your industry. Ask whether the vendor thinks this is important and why. One reason that this might not be important is if your installation truly has little to it that is out-of-the-ordinary.


• The two most misunderstood words in the LIMS industry are “customization” and “configuration.” Never assume that you know what anyone means when they use these words. You can define them in your RFP, but everyone has their own definitions and you will find that they cannot (or will not) necessarily adjust to a different definition. Instead, ask for thoughts on how difficult something would be to “configure” or “customize.” When you narrow-down your list and get your product demonstration, you can ask the vendor to show you exactly what it took to configure specific items in which you are interested.


• Make your best effort on writing the RFP. Although it will not be perfect, and you should expect questions both from the vendors on the RFP, as well as to question them on their responses, you want to minimize the number of times you have to pass it back-and-forth as this can take more time than spending the time up-front to get the RFP as tight as you can.

Some items to include in the RFP:

• Instructions on how to answer the RFP questions and how to submit it, including dates and contact information.


• An Executive Summary: This gives an overview of your company. It includes a general summary of your project and what you are looking for in a system.


• Include a section for the vendor to tell a bit about their company if you have specific items for them to address or discuss, or simply ask them to include something general about their company. Many customers ask specific questions on the size or age of a vendor, but you should only ask these questions if you have a purpose behind them.


• It goes without saying that there would be a section on functionality. Separate main sections to make this manageable, such as security, sample login, reporting, labels, search abilities, and data conversion.


• Include sections that relate to hardware, operating systems, contracts, services, support, database, prices, discounts, interfaces, and any other item that might be of importance to you. Include a copy of the contract.


• Some, or all, of those items that you defined in “Defining Your Needs” will potentially be included in the RFP.


• A potential project plan: This should indicate each task in the process that could possibly be of interest to the vendors, such as receiving the RFPs from the vendors, evaluating the RFPs, contacting the vendors, the product demonstration period, the auditing of the final choice, and the planned project start.

Once you Receive the RFP Responses
Have the LIMS team review the responses to make sure that each vendor understood and answered your questions. If not, go back to the vendors to clarify issues, and ask for a further response.

Check the references. See if you can find some others on your own, if you did not do this before the RFP process. Call or visit the reference sites. If the reference project is in-progress, call them again later in their process to find out what issues might have surfaced. Consider whether your situations and project size will be similar. If they are in your industry, how well did the vendor understand the unique industry issues that came up during installation and does the reference site think this was important? How experienced and professional did the vendor’s personnel seem and what value did they add to the project?

Ask the references about the overall support they have received. How well does the vendor support the product on a day-to-day basis? How well do they handle the occasional bug? How organized are they with shipping the appropriate upgrade products and materials? Ask about any services you are purchasing, such as project management, implementation or training, and for details on how each of these services was provided.

Once you think you know which vendor you want, have your LIMS team try the product. The Sales demonstration you saw does not give you enough information to know if it will be what you expect and were promised. Keep in mind that this is a rough example of your final installation. This is a step that companies skip because it is considered an expensive and time-consuming step. Compared to the cost of the entire project, it can be a minute portion of the overall cost. Not only can there be misunderstandings about functionality, but sales personnel can also make mistakes on which features exist in which version of their software.

When the RFP responses are being evaluated, it is a bad sign when a vendor replies “yes” to every question without going into detail. Vendors will not always have more than that to say for every question you ask, but the ones that have put some thought into the response will have some answers that indicate it.

It is often difficult in the RFP responses to determine how much effort will be needed to create some of the functionality desired. When there is a question pertaining to functionality that is answered as being configuration, once again, realize that that could mean that one button is clicked to accomplish it, or thousands of lines of code must be written, as most of the vendors like to refer to their proprietary coding languages as “configuration.” In essence, you must try to look past the “words” that you get back.

---