The Importance of a Product Roadmap on the Journey to LIMS Utopia

Most large laboratories have embraced implementations of modern Laboratory Information Management Systems (LIMS) over the past few decades. The LIMS, in many cases, functions as the heart of the laboratory and is a significant, long-term investment which is utilized and modified over decades. As computing technology has progressed and testing methodologies have evolved, so too has the need for process changes, workflow automation, and capturing, understanding, and visualizing data. How can laboratories ensure their LIMS implementation will provide them with this level of functionality and continue to live up to ever-changing needs over time? 

Even more so over the past few decades, the expectations for technology have changed. People everywhere want technology to help them perform their daily activities. They want technology to provide them with information before they even know they need to have it. Laboratory management wants much the same for their labs, but in many cases, they just don’t have a clear vision of what LIMS should provide or know where to start to achieve this level of sophistication. 

In many cases, laboratories also find it difficult to admit that they may not be ready for the level of technological augmentation that they think they are. It takes a tremendous amount of dedication, discipline, and planning just to prepare for potential changes from data-directed decision making or fully automated processes, let alone actually implementing the changes. 

Many of the top-tier LIMS solutions can provide fully automated laboratory lifecycles—but getting there is a cobweb of change management, the likes of which most employees and managers haven’t encountered before. This cobweb, intertwined with business politics and a lack of focus on (or vision of!) operational effectiveness can make articulating benefits and justifying forward momentum troublesome, if not futile.

How can a LIMS evolve and continue to operate effectively when there is constant change and additional demands for new functionalities like automation, real-time data visualization, and automated workload planning? How can laboratories justify the time and resources needed to achieve the benefits of LIMS modifications required for these functionalities?

This is where the importance of a clear, concise, and actionable product roadmap comes into play. By organizing overall goals, system needs, and desires into themes with planned, actionable blocks or phases, a path to achieve data dominance and admirable automation will emerge! Continue reading and we’ll explore what a LIMS owner can do to begin the journey of creating an effective LIMS product roadmap regardless of whether you have an established system or are looking to implement a new LIMS.

What is a LIMS Product Roadmap?

A product roadmap is a visualization of a strategic, documented plan of action for a LIMS which is maintained over the lifespan of the system. The intention of the roadmap is to visualize the overall future of system functionality and maintenance needs and also to help ensure that guide rails are created to help maintain a cohesive LIMS over time as the system evolves. Roadmaps are generally created for long term planning (years) and should be visually engaging to help articulate the long-term strategic focus of the LIMS. 

In order to create an engaging product roadmap, a focus needs to be put on not only understanding the capabilities of the LIMS, but also understanding the needs of the user base and management across departments. The IT team, the Information Security team, the individual laboratories, and management will all have different expectations and goals, all of which should be included within the product roadmap to create an overall vision.

Start by taking the time to gather input from all invested parties, allowing for an inclusive vision to form of where the LIMS should be headed. This will help prevent potentially costly surprises during the system life as various new functions and processes are implemented. Although a product roadmap will highlight exciting functionality changes, it should also put emphasis on maintenance items like system and module upgrades, security-related changes, or other infrastructure needs. The Infrastructure team responsible for maintaining critical systems will appreciate the forethought and the laboratory will be able to properly resource because they’ll know what to expect as projects follow the roadmap.

Management may have functionality desires and goals, but so will the end users—and both perspectives matter! Take the different desires for specific functionality and try to group them into functional themes. For example, if users are asking for a method to automatically schedule stability samples and management is asking for real-time information on effort required for upcoming stability tests, then an overall theme may be “implement automated stability testing with real-time dashboards”.  

While gathering input, be sure to document what people are really expecting from the LIMS. This data will be needed to drive further discussions on what the overall LIMS vision should be and what functional themes are needed.  It will be a group effort to take this information and create a strategic vision, but the product owner should use the data to drive effective discussions.

The strategic vision for the product roadmap will be a culmination of all of the input provided by the interested parties. Use the gathered data to your advantage to build context and, eventually, the visualization (your roadmap!) of what is being asked for in the LIMS. Additional context is always useful when presenting the roadmap to management and end users for obtaining buy-in. 

Once the input has been documented, a helpful exercise is to create a high-level vision statement that encapsulates the wants and needs that have been discussed.  The vision statement does not need to be exhaustive but should serve as the guiding principle for the rest of the roadmap.

An overarching vision statement may be something as lofty as:

“Create and maintain a state-of-the-art LIMS that continually evolves to fully automate the sample lifecycle, including data interfaces and customer notifications.” 

Or as simple as: 

“Maintain an efficient LIMS in a way that is cost effective, yet user-friendly.” 

The vision statement will depend on the lab—and the themes of the roadmap will correlate with the vision statement. 

Building the LIMS Roadmap Blocks

Once an overarching vision statement has been defined, the next step is to start defining the details. This is where the data already gathered will pay off as it will provide a starting point. However, it will still take time and effort to fully understand what’s being asked for and what it will take to achieve each functional theme of the roadmap. Break down the information that went into the vision statement as themes into specific, manageable blocks or phases. You’ll need to begin to understand a high-level estimate of effort required for each phase.

For example, if a lab director is asking for real-time data visualization on sample turnaround times by laboratory, what will it take to provide the solution? You may need to ask yourself questions like:

• What actually needs to be done to achieve this? Are there pre-requisites?
• Will master data cleanup be required due to historical processes? 
• Are there any new technologies needed? 
• Will you need the assistance of outside experts, or do you have the right resources in-house? 
• Is the solution available under any sort of extendible module or services agreement you have with your LIMS vendor? 

These are examples of high-level information to gather to try to obtain a general idea of what it takes to achieve a certain phase or block.  This is useful for prioritizing and budgeting, while the fine details will be determined during the applicable project(s).

If an identified phase or block is extremely large, then try to break it down even further into sub-blocks. Try not to break the block into individual modules or functionality. If needed, revise your functional theme to reduce the scope and try to maintain broader topics or themes that can be managed and further refined during the software development lifecycle (SDLC—You have one of those documented for your LIMS too, right?).

Make sure the need for maintenance is accounted for at this stage! This includes hardware, security, and LIMS-specific maintenance (version upgrades, module maintenance, support, etc.). The roadmap should have blocks that specifically address this. Maintenance planning is sometimes overlooked but is incredibly important to understand the long-term requirements of operating a high-performing LIMS. Will this be handled internally or through external service agreements? 

The next step will focus on prioritization, so make sure there is enough data to drive the discussions appropriately.  If there are pre-requisites for certain requests, then that needs to be considered. And remember—you don’t need to create full business requirements yet. You will, however, want to get an idea of how long it will take to gather requirements, remembering that the quality of requirements can have a direct impact on how long development, testing, and deployment take…as well as overall user satisfaction! 

Do your homework and understand the high-level impact of what it may take to achieve each specific phase of the vision. 

Prioritize to Avoid Pandemonium

Once the high-level blocks are defined with a general idea of the effort, it’s time to start putting the pieces together into a defined product roadmap. This is where prioritization needs to take place and the puzzle pieces need to fit together.

Take the information you’ve gathered and get the band back together.  Work with the same group of people that gave you the information (even those busy technicians!) to prioritize the various blocks/phases and themes, considering the detail that you spent time documenting. 

The prioritization effort should focus on strategic objectives for the LIMS, and the timing itself can be determined later as part of the Agile (or other) software development lifecycle. Don’t focus on dates. Focus on strategy and the execution order or each block. 

The more time spent here, the more likely a successful roadmap will be achieved. If all stakeholders are on-board, focused, and agree with the vision, the themes, and the prioritization, then they will understand the needs for each block of the roadmap and be more willing to approve requests or provide assistance when the time comes.

Putting it all Together

This is where the rubber hits the road.  Take all the information that you’ve been able to get agreement on—vision statement and prioritized themes and blocks or phases—and build a visualization.

In some cases, this can be done simply using index cards or a whiteboard. For larger roadmaps and complex LIMS or strategies, anything from PowerPoint and Visio to professional product management software can be used.  

The visualization should be the culmination of the efforts, and it’s important to ensure that all interested parties have their inputs covered. You can utilize individual “cards” to define blocks in a swim lane format, and create bar charts where the line length indicates the amount of effort or hierarchies of blocks that show the interconnectedness of each block. Creativity is good, but make sure to keep things as visually simple as possible to ensure the roadmap is easy to follow. 

A product roadmap is a valuable tool for effectively planning and maintaining an efficient LIMS. The roadmap should be regularly reviewed over the life of the LIMS and maintained with up-to-date information. Use the prioritized blocks of the roadmap to guide the forward momentum of your LIMS evolution ever closer to LIMS utopia.