What Do We Need When it Comes to Laboratory Informatics Support?

This is a question that is asked more often than you might think – and if it isn’t asked it should be asked whenever a project kicks off.

So what to do – first of all you’ve got to understand what problems you are trying to solve – increase efficiency of the lab operations? Protect the intellectual property more effectively? Reduce the complexity for the business to do its clever stuff – the science? Reduce paper usage? Provide better traceability of samples and experiments? Speed up report generation?

There are many drivers that can be considered but they must be defined up front – as they can then be used to check if the ‘project solution’ will deliver them. They can also be used as success metrics after the project has gone live. What we see working well is that the program of work provides an evolution of deliverables against an evolution of business drivers. The program can and should also last for a number of project cycles/years building as it goes, to deliver more and more transformation, change, and measurable business benefits.

So there we are – that’s one, well proven in our experience, tool for delivering a scientific research and development business change project. But what about getting to the root of what is needed on the system/informatics side. The way to think about it is in terms of ‘capabilities’ and not product acronyms or features and functions.

More often than not when it comes to research and development informatics projects the requirements of ‘what’ is required is defined and talked about in terms of a ’product acronyms’. This means that the names of product families/categories are used to define what is needed in a project – such as LIMS, ELN, SDMS, Analytics, LES, MES, Inventory etc. There isn’t even alignment of what each category of product does in the market place either.

Furthermore, more often than not, we see that the projects themselves are named by product acronyms and categories – but the good ones we see are named by what they are going to deliver to the business and not a product category e.g. The R&D Efficiency and Productivity System (RDEPS). A small but potentially impactful detail.

The other big problem with defining projects by a product category/acronym is that everyone has an opinion and definition of what each of these product types are, what they do and how they can benefit the organization – a real recipe for misalignment and disappointment down the road. The potential pitfall of doing it this way is that the actual needs and demands of the scientists and business are not considered as the requirements of the system – they become lost in the melee of the project and rush to implement something.

By defining a set of high level capabilities that you are looking for helps keep the project aligned to the business requirements. Doing it the other way, by defining what is needed by a product acronym (ELN, LIMS etc.) more often than not leads to immediate descoping/scope creep based on what that product category offers. Essentially we are now in danger of defining a project by a products capabilities – and therefore very likely to have to make concessions right at the beginning, before the project has even kicked of – which is not a good place to be as you are already compromising your ability to deliver against the business deliverables – remember those … those are the things that get measured after the roll out is completed and will make or break the projects longevity and success.

Therefore – two of the things that you can do when starting the project and thinking about what to buy and from who is to step back, look at the business drivers and opportunities you have. Define what capabilities you need from an informatics point of view (not feature and functions) that will impact those drivers, and then and only then, go and look for solutions that provide the capabilities you need – you may end up with a product acronym system e.g. a ELN or a LIMS, but you will know what you need from them rather than bending your requirements to fit what they do.

This approach to setting up and kicking off a project can help ensure that you are driving the project and requirements from a solid foundation and they can help lower the risk of the project missing the mark – although it does not totally remove the risk – there is no silver bullet in this game.