Why It Still Hurts: Map the Pain Before the Demo

Welcome to InCogSights^™, Issue Five.

A few months after go-live, I asked a lab manager how the new LIMS was working. "Great," she said. Then she added, "The only thing is, some of the chemists are still using this one spreadsheet."

It had been in the lab for years. Everything it did could have been done in the LIMS, but it never came up in the requirements meetings, so it never made it into the system.

The LIMS wasn't broken. It did exactly what it was configured to do. The problem was everything that never got written down before the project started.

A LIMS only fixes the pain you mapped

Every LIMS sales cycle starts with the same promise: fewer lost samples, no more re-typing, audit prep in hours instead of days. The software can deliver all of that, but only for the problems someone identified, described and configured for.

The rest don't disappear at go-live. They move into a more expensive system, usually as a workaround sitting right next to it.

This is the part vendors can't say out loud. Their job is to show you what the system can do. Your job is to know what your lab needs it to do, before anyone shows you anything. Requirements written as a feature list ("barcode support," "instrument integration") don't capture pain. They capture capabilities. Pain is specific: who calls whom, how often, and what it costs when it goes wrong.

In my experience, the labs that are happiest a year after go-live are the ones that walked into selection with a ranked list of what hurt.

Where it usually hurts

Most labs I've walked into have at least five of these, and they cluster in six areas:

• Sample tracking: the "where's that sample?" phone call; chain of custody rebuilt after the fact.
• Testing and data capture: instrument results re-typed by hand, then re-checked by someone else; calculations living in personal spreadsheets.
• Workflow and visibility: nobody knows the true backlog until someone counts it; one rush request throws off the whole week.
• Reporting and customers: COAs built by copy and paste; customers calling to ask for status.
• Quality and compliance: audit prep that eats a weekend, every single audit; signatures chased by email.
• People and risk: the one person who knows how the master spreadsheet works, and who's retiring next year.

The last one is the most dangerous, because it hides the others. If one person quietly absorbs the pain, nobody else sees it, and it never makes the requirements. That leaves more than one system controlling the data. It also opens the lab up to audit findings, because everyone assumes the LIMS is the lab's official data record.

Score it: frequency × impact

A list of complaints isn't a requirement yet. Ranking turns it into one. For every pain point that's true in your lab today, give it two scores from 1 to 3:

Multiply them. Anything scoring 6 or 9 is a priority. A daily annoyance and a monthly compliance risk both score 3, and that's the point: frequency alone over-ranks the noisy problems, and impact alone over-ranks the rare ones.

If you saw my pain points post last week, this is the same scoring from the Where It Hurts worksheet I shared with it. The worksheet lays out all six areas with space to score each item, so your team can fill it in together. It's free to download at the end of this issue.

Score it as a group, not alone. The analyst, the QA reviewer and the lab manager will rank the same item differently, and that gap is useful information. It's often the first sign that one role has been absorbing a problem the others never see.

Turn your top three into the demo

Your three highest scores become the script every vendor has to follow. For each one, write down:

1. What happens today: who does what, how long it takes, and what goes wrong.
2. What good looks like: the outcome you want, not the feature. "I know where every sample is without asking" beats "barcode tracking."
3. The demo test: "Show me this, with our sample types and our workflow."

Hand these to every vendor before the demo, not during it. A vendor who can fix your top three will be glad to show you. A vendor who steers back to the standard script has told you something too.

The pain points that don't make the top three still matter. They go into the requirements with their scores attached, so when scope gets cut (and it will), you're cutting the 2s, not the 9s.

Map the pain before anyone shows you a demo

A LIMS is only as good as the list you bring to it. Write down what hurts, score it, and make your top three the test every vendor has to pass. Whatever isn't on the list will still be there after go-live, usually in a spreadsheet.

Find out where it hurts in your lab. Get the free Where It Hurts worksheet: a two-page checklist covering all six areas, with frequency × impact scoring and a page for prepping your top three for demos.

Want a second set of eyes on your list? Schedule a free 30-minute consultation.

Thanks for reading, and I'll see you in the next issue.

Matt