What You Need to Know Before Taking the Costly Plunge

If you intend to purchase a major piece of software to service your entire division or organization, or a large laboratory, you need to follow a process to ensure that you make the right purchase for your situation. For example, if you are purchasing a LIMS (laboratory information management system), an ELN (electronic laboratory notebook) or a CDS (chromatography data system) on a fairly large scale, it is not a trivial purchase. These purchases tend to be relatively expensive, involve comparing many features between systems and usually require a comprehensive understanding of your needs so that you can justify the massive purchase.

Getting started

First, start by deciding what you want to achieve by purchasing the software. By gathering a list of requirements and ranking their importance, you will get an idea of what you’re looking for.

If you haven’t done so already, this is also an excellent time to map your processes. Mapping your current processes (known as “as is” processes) will indicate what you’re doing in the laboratory. Review and understand your process map. This task also gives you a good picture to show to others, such as your management, in order to be able to point to problem spots or areas where you plan to achieve change. If you are replacing software, make sure you note in your process map where that software is currently being used.

With a depiction of the workflow of your laboratories and associated areas as well as a list of ranked requirements, your organization should now have the “big picture” of what you’re looking for in a new software solution.

Creating the “to be” workflow

You can begin to put some work into your desired future workflow (known as the “to be” workflow). After all, you now have an idea of where some of the bottlenecks are in your process and what parts of the process should be modified. However, you cannot finish this task until you purchase your software

Many things can be identified within your process map. You will want to indicate where the new software is going to be used, but until you purchase software, you will not entirely know where that will be. Once you purchase all the appropriate pieces of software, you must come back to the process map to decide where the software will be used. For example, if you are purchasing multiple systems, such as a LIMS, an ELN and a CDS solution, you will need to make decisions on what software is used where and by whom and you will note some of this information on the process map. Even if you purchase a single piece of software, without knowing the brand, you must be cautious about deciding what the software will do and, accordingly, knowing what features you’re purchasing.

Is this a good time to remap the process?

Absolutely! If you don’t work on your process design when you purchase a major piece of software, you probably won’t get another chance. You can justify this cost along with the cost of the rest of the project, plus you won’t want to do this once you’ve implemented your software and thus have to change the software.

While there might be minor process changes to be made after implementation that will require software changes, your goal is to minimize this by doing a thorough job up front. Although this is not an easy task, it is much easier to do during the planning stages and before implementing the software than after it’s implemented.

More preparation

You now have most of what you need to create your RFP (request for proposal) or RFQ (request for quotation). Think of an RFP as an invitation to a software vendor to propose a solution, while an RFQ is asking for a quotation. Sometimes, we combine these into one step in the process.

Here are some steps to take to create your RFP/RFQ:

• Take your requirements and turn them into questions. Put them into some type of table format, and give the software vendors a place to respond.
• Include any IT, legal, support or regulatory requirements that you didn’t gather as part of your RFP process.
• Group the questions into sections. That way, if a software vendor has a general comment on the section, it can make comments at the end of the section.
• Give some background to your project and company
• Give specific instructions and deadlines, including a specific contact to whom the software vendor should send its questions, concerns and final response.
• Ask questions about any required implementation services, as well as product questions.
• Ask about integration with other software if you think you will integrate this piece of software with other systems.

Do not include your rankings for your requirements in the copy you will send to the software vendors.

Creating a vendor list

While you’re creating the RFP, you should be able to start building a list of software vendors. Unless you have an extremely specific situation, you shouldn’t be writing to one vendor and waiting to see what it has to offer before writing to another. Instead, search for vendors that have appropriate software and start contacting them. Create a list to keep track of which ones you’ve heard from. Keep working on this list until you feel you have enough appropriate vendors to send your RFP to once it’s created.

Here are some ways to find vendors with which to create your list:

• Do a general Internet search.
• Find an industry website appropriate to the type of software you wish to purchase, as some of these websites will have lists.
• Attend a conference where these vendors are showing their products.
• Ask your employees and/or co-workers what they’ve used in other places they’ve worked.
• When you’re at your next industry-related professional meeting, ask your competitors what they’re using.

Sending out and comparing the RFP

Whatever the initial list of vendors you were considering looked like, the list you send the RFPs to should be smaller. The more responses you get back, the longer the comparisons will take you. Unless you’re serious about looking further into products, it’s a waste of both your time and the software vendors’ to send them the RFP and ask for a response.

Once you have all the RFP responses in, you will start to narrow the final list down to two to three vendors from which to get demos. Looking at more products than this can be confusing, as they start to blend together when you’re trying to compare them. So, keep the number that you’ll compare small. You can add another vendor to your demo list later if you need to.

In order to narrow the list down, have your team compare the responses from the software vendors and discuss them. One way to split this up is to discuss each section separately, then come back and summarize the comments for each product. Another way to approach this is, if you have someone who is already an expert with the systems you are considering, to have that person create a summary document that discusses the general pluses and minuses for each product, per section. That document can be given to team members to assist in their comparison. Be cautious by ensuring that this summary document is based on the impressions and facts given by the document as opposed to the personal preferences of the person doing the summarizing.

Seeing product demos

Before you invite the software vendors to give their demos, prepare a sample workflow and some sample data that represents some of your key needs and ask the software vendors to customize their demos to focus on your situation. Also ask them to focus the demonstration based on their knowledge of your industry.

Work with your team to create this sample workflow and to create a list of questions that you will ask during the demo. Prepare your team and any additional attendees by discussing the background of what got you to the point you’re at and why the vendors being demoed were selected. Prepare attendees to view the offerings with a critical eye and to write down their impressions either during the demo or right afterward.

After the demo

Bring everyone together to discuss their findings on how well each product meets the requirements. Make sure you consider the priority of your needs. Many teams will fill out charts grading each product’s ability to meet their needs, and then the team will collate these and discuss them.

Check the references. While the other portions of the process are difficult because they can be tedious, this particular aspect is just tricky to get useful information from. Although companies will usually give you references who they think will say good things about their product, you’ll be surprised how many of these references are useless.

Watch out for these:

• References who say nothing but great things about the product but have no real understanding of it. Once you realize this is the type of reference you’re dealing with, don’t waste any more time with them.
• References who say nothing but great things about the product but seem to be quite knowledgeable. If you dig a bit with careful questions, you can sometimes get past the shallow answers that the system is “great” to find out whether it truly does anything for this company and, if so, what it is.
• References who have some negative things to say and don’t sound all that impressed. Some people are so realistic that they’re actually great representations of the true experience you’ll have. Don’t be put off by this. Embrace this as a chance to find out both the good and the bad you can expect. You won’t get many of these chances, so take advantage of it and don’t use it to immediately reject this particular software.

I could caution you to beware of those references who have nothing but terrible things to say about the software, but you won’t have to deal with many of these. Some people know to ask for both positive and negative references from each software vendor, but almost all vendors will tell you something like “We’d be glad to, but that’s so hard because all our customers really love us.”

When you’re fairly sure of the product you’ll select, you can start the process of sharing contracts. Depending on the lawyers, this part of the process can take longer than you might expect.

Finally

This is not an exhaustive list of activities, but it should be enough to get you started if you haven’t done this before. For more help on how to do this, especially on creating an RFP, there are software packages, books and workshops that will specifically take you through some or all of this process. A search at one of the major booksellers or on the Internet should produce a list, or you can post a query in an appropriate discussion group. If you do not wish to do this yourself, you can, of course, find consulting firms to work with.