Planning for a Laboratory Information Management System (LIMS) is no easy task. It requires a substantial amount of time, effort and lots of very careful consideration.

Whether you’re implementing LIMS for the first time, or looking to upgrade legacy technologies, selecting the right solution for your needs and measuring ROI post implementation is going to be a challenge.

Getting things right first time will be critical. Alongside having significant financial and productivity implications – failure will be incredibly disheartening for anyone who invested time and effort preparing for implementation.

Let’s take a look at some of the top reasons why LIMS implementations can fail to deliver.

1# It doesn’t do what we expected

It’s a classic scenario – you saw the demo the vendor wanted you to see and then assumed that what you were buying would do exactly what your business required.

Getting the most out of a system demonstration is an absolute must, so prepare a demo check list to assess against on the day. Don’t let the supplier run the show and walk you through their ‘standard demo’ at speed or deliver a ‘death by PowerPoint’ style presentation and a bunch of videos – you’ll need to see and touch this thing in action doing the things that are important to the needs of your business.

A key objective is to ensure the system you’re viewing can be configured to your exact requirements – along with the cost and the level of difficulty involved in making that happen. Failing to agree an agenda or preparing questions about specific areas of functionality you’d like to explore on the day isn’t an option. What you want to achieve is a system run-through that’s explicitly tailored to the needs you’ve identified.

So, if system configuration is an important issue – and it should be – requesting some live exercises are part and parcel of the demonstration presentation is essential. Even better, ask if your staff can undertake some configuration under supervision – that way you can assess just how well the product’s configuration tools actually work.

Finally, if you don’t get all the answers you need on the day, things felt too rushed or your felt your questions were stifled, make the call as to whether another demo is in order.

2# It cost more than we expected

Another classic that comes down to asking the right questions at the right time. Getting distracted by cutting edge functionality showcased during the demo is all too easy. Ask yourself if these features are important or useful for automating your lab operation. If not, why are you paying for them? Would a lower spec system do the job – at a more attractive price.

Make sure you go through the system specification in fine detail so you are clear what’s included in the standard price and what comes at an additional cost – which may not be clearly outlined up front.

Having expressed your requirements to a vendor, it pays to make sure that ‘we can do that’ doesn’t also mean ‘at an extra cost’. Be clear that any additional or special requests you’ve made (system tailoring) are unambiguously included in the quotation.

Make sure you ask lots of questions prior to requesting a quote. Areas you should explore include, what happens if we want to take advantage of future technology advances; will there be enhancements and what’s the cost of these; how does support and licensing work – what’s the full cost of ownership breakdown.

Finally, build in a cost to cover initial data load and data migration. Do you have resource in-house to do this – or will you need to pay someone to do this for you?

3# All change – we didn’t fully appreciate what we needed

Documenting exactly what’s required and why is a vital first step. The information you gather and define here will form the bedrock for the core documents you submit to potential vendors.

Clearly, undertaking a comprehensive needs assessment and prioritising your top ‘must have’ LIMS requirements is one exercise you can’t cut corners on. Don’t just consider what you want to do today – review what you hope to achieve in the foreseeable future.

The last thing that needs to happen once you start this journey is to discover a LIMS can provide additional functionality that was not included in the original requirements and decide to change direction. This not only de-stabilises the project; it will also put unnecessary pressure on both colleagues and the supplier.

To eliminate the risk of unexpected changes, initiate a change control procedure that captures additional wants and needs for future implementation.

4# We don’t have the right people or skills to run this thing

Make no mistake, making this happen in a controlled and cost effective way will mean assembling a crack project team to plan the entire implementation programme – from initial specification to final go live.

Ideally, you’ll have a top notch project manager on board to manage the entire programme and coordinate communication with internal and external stakeholders. As part of your discovery process, make sure a wide range of users are consulted on what the system needs to do and how, so you can build a detailed overview of the features, functionality and processes involved. Subject experts will bring significant insight and value to the table, as will members of the IT team.

It goes without saying that you’ll need resource a number of implementation tasks, including:

• Preparation of initial user and system requirements
• Procurement and installation of hardware, operating system, database, network and peripherals
• System configuration and review meetings – which must cover integration with other systems and instruments
• User training and development of the SOP
• Data loading
• Acceptance testing and system validation

5# Nobody wants to work with this thing – users are unhappy, really unhappy

Deploying something that isn’t stable or doesn’t meet with user needs is not a good place to be, because retro-fixing and reconfiguration will cost you dear.

To avoid this l risk, ensure you build in plenty of time for prototyping during the implementation process. By ensuring that end users are involved in all validation and acceptance processes, you will be able to identify potential problems and minimise rework costs early on and you’ll build wider user awareness and acceptance of the new LIMS when it finally goes live.

Of course, if you’ve already consulted end-users early on in the process and gathered their input on requirements, then the channels of communication will already be open and you’ll be crystal clear about user expectations.

If you’d like to find out more about how to purchase a LIMS and avoid a potential project failure, then why not take a look at our whitepaper that provides a detailed walk through of every step of the process.