(or Why You Need a LIMS Requirements Scorecard)

Most lab managers and scientists understand why they would want a LIMS. Less obvious to all is how they should go about the process of identifying a shortlist, vetting platforms and selecting a LIMS.

We caught up with one of our customers and asked her to share the process she used when evaluating LIMS vendor options. Leadership at an industrial chemical manufacturer with 200+ facilities worldwide tasked her to lead the Company through the acquisition decision-making and change process for a new informatics platform.

This post shares how she successfully drove the LIMS selection process for multiple labs on multiple continents, with numerous stakeholders and few standardized workflows or practices in place.

***

What You Need to Select a LIMS

Do you want to buy a LIMS? Build a requirements checklist or score card.

Are you in the midst of buying a LIMS? Use a requirements checklist or score card. 

Are you evaluating different LIMS vendors? Create a requirements checklist or score card.

You should be seeing a pattern at this point.  

LIMS requirement checklists are a must for lab teams looking to upgrade or choose a new LIMS. While a few aspects of the decision-making process might be subjective, we found that it is pretty eye-opening how much of it is objective…and potentially quantifiable, or ‘scorable.’

So, before you read any further – remember this key takeaway: you need a LIMS requirement checklist.

Global Brand, Local Science

My employer was a major chemical supplier. They supplied the airline, aerospace, automotive and many other industries, doing about $20 billion in annual turnover. We had labs spread around the world. Some were R&D focused, while others were attached to various manufacturing sites – including quality labs.

I had raised the issue of limitations in our data collection practices (which included a legacy LIMS that was released around the same time Back to the Future first hit theaters). Because the pandemic had nixed plans to bring in a dedicated Change Manager for the process, I was asked to lead the project. While I had previously evaluated LIMS demos, I had never headed up a start-to-finish selection process.

Unifying Scientific Documentation

When it came to data collection, we were an everything-based company. Some labs had physical notebooks. Others used spreadsheets. There were different preferences among scientists, so two people in a lab side-by-side may have been recording things in vastly different ways. Going to a LIMS, we weren’t switching from an outdated methodology to a new one. We were switching from every methodology to a single method.

The objective was to centralize the data and have it be mineable and reusable, while setting labs up for the future – including the use of AI or machine learning to further automate tasks. But at this early stage, data centralization was priority number one – we wanted (and needed) to create a single source of truth.

Aligning Stakeholders on Data Centralization

Once tasked with shepherding the new LIMS acquisition, I met with as many lab managers, IT team members and key decision-makers as possible. But, perhaps more importantly, I also met with scientists and lab techs – the people who were going to be interacting with the LIMS and ELN. They would be the critical day-to-day users, so the platform needed to align with their needs and answer their concerns.

Understanding those needs and concerns enabled the creation of a detailed requirements score card that addressed our collective needs, wishes and no-go’s.

That was our first challenge, since – as I mentioned above – there was no single, uniform ‘need.’ Even among those scientists using common methods – spreadsheets, for example – data collection was sometimes completely different from one person to another…including within the same lab or team.

For example, I found one single data point that was stored in 14 different locations. What do you think the chances are that if you had updated one of those data points it would have been updated in all 14 places? This one example drove home to the management team that we needed a single source of truth (SSOT) – that we needed data centralization.

More Science, Please!

Some of the biggest LIMS project pushback, at least initially, came from those who would have benefited from it most: researchers and workers at the bench. There was a fear that automation – for example, of reports – would mean layoffs and downsizing. If a task no longer required five hours, what would they be doing?

In some organizations, this might have been a valid concern. Our leadership, however, was clear: give us more science! They didn’t want teams wasting time repeating experiments that had failed in the past because the Excel data was locked on someone’s desktop, unavailable. They wanted to be able to do more things, learn from failures to move products forward, launch more projects, start more research, get more resources to accelerate time-to-market.

Gathering Information and Getting Buy-In on a LIMS

Getting buy-in and overcoming concerns (such as downsizing) is a big part of a LIMS change management and the messenger is as important as the message. As an IT project manager, telling a scientist “you need to use this new system” has far less impact than them hearing it internally from colleagues in their respective business units. Sharing business cases and exploring the what’s and why’s of their needs is much more effective when they perceive internal support.

If you’re going to ask scientists to change how they work – and how they go about documenting their work – there are a variety of approaches to extracting the right information from them.

We used focus group interviews in which the same questions were asked of different audiences. This encompassed everyone from senior management to lab managers and directors, to Group leaders, PhDs, chemists and lab technicians.

The difficulty, as discussed above, was getting buy-in from the exhaustive list of stakeholders on a single, unified approach that would be feasible and effective for everyone.

We ran Voice of the Customer workshops where we brought in groups of people in the same positions but from different departments and sites. We asked questions and gave them a defined timeframe in which to write down answers. These answers were then put up on a screen and the group voted on them. Interestingly, most people didn’t vote for their own answer but rather they built off each other and were able to distill what they really needed in a LIMS – giving our team the information needed to scope out a platform.

One of the most valuable things we learned through the process was that the team in charge of the process should include people who will actually be using the LIMS. Other scientists and bench workers who will be using the system see such people as an advocate (“Suzie over in QA helped select the system, and she’s really good so this must be the best solution”), and it goes a long way towards overcoming resistance.

From all of these stakeholder interactions, I created our LIMS requirements checklist score card.

Narrowing the LIMS Vendor Field

We narrowed down to a shortlist of potential LIMS using a basic checklist of requirements.

Chief amongst our needs was an integrated ELN that could handle both structured and unstructured data and could seamlessly transfer projects, tests, or data to another department. We wanted to avoid the need for someone to log in to another system to submit a request to the analytical department, for example. And since this was such a key need across our entire organization, it served as one of the single best criteria for narrowing our extensive list of LIMS vendors down to five.

Using a Score Sheet to Rank the Final Five LIMS Platforms

From the pain points identified during the requirement gathering sessions across the organization, I created a spreadsheet with our requirements, which were then scored.

Our scorecard worked on a 3-point system – with a value of 0 (no/poor), 1 (neutral) or 2 (yes/good) assigned.

If the prospective LIMS didn’t have a functionality, it received a zero score. If it possessed the functionality but wasn’t really what we were looking for but we could probably make it work, it received a score of one. Systems that offered the functionality out-of-the-box exactly as we wanted it were given a full score (two).

Initially, we thought subjective criteria might prove problematic, but there were few truly subjective decisions. Arguably, user interface can be subjective – but we looked at it from an efficiency/workflow standpoint in order to be able to quantify it as a ranking factor. Some of the sample criteria included:

• User experience and user interface
  How many clicks does it take to complete a task? Was the platform well-organized?

• Configurability
  Could we perform internal, self-service configurations?

• Extensibility & integration
  Could it easily integrate with other instruments or software platforms such as SAP?

• Customer support
  Was support regional or global? Was it multilingual?

• User training
  How many courses were available? How often and where were they offered?

• Features
  What additional features are available as part of the LIMS – SDMS, ELN, LES, chemical inventory management, export control data, external Portals, instrument interfacing, security, etc.?

• Implementation
  Could we customize workflows, reports, labels, etc. while staying on a realistic implementation timeline?

• Project management
  Did the vendor provide a project manager?
• Upgrades
  Are upgrades available for future consideration, and what were the costs?

• Infrastructure
  What setup is available – on premise, cloud, SaaS? What server architecture is needed? Does the opportunity exist to migrate from on-prem to cloud in the future?
• Licenses and service contracts
  What services are available, how much do licenses cost?

At the end of the process, we had a clear winner: we selected and successfully implemented LabVantage LIMS.

Two Final LIMS Selection Recommendations

The use of a requirements score card helped level the playing field, allowing data-driven decision-making in our selection process. But there were two additional takeaways from our selection and implementation process that bear mentioning:

1. On the LIMS selection side, there tends to be an emphasis on getting buy-in at the highest levels of an organization – and yes, it’s important since they control the purse strings and project go/no-go oversight. But ensure your process engages with the scientists and techs who will actually be working with the LIMS. Making sure the system you choose answers to their needs is the key to their support…and ultimately project success.
2. Prior to LIMS implementation, give yourself enough time to standardize your master data and workflows. In our case, the ‘little things’ added up. Standardizing chemical inventory naming conventions, for example, required sorting line-by-line tens of thousands of lines of data. Consider one particular chemical: some scientists label it ‘ethanol,’ others ‘ethyl alcohol’ and still others ‘ETOH.’ Another case in point: scientists in one lab were measuring experiments based on milligrams per deciliter, while their partners in a different lab were measuring grams per liter, leading to data that was not standardized.