Once you’ve selected your laboratory information management system (LIMS), it’s time to implement it within your lab’s software environment. A critical part of this process for regulated labs is validating the LIMS and ensuring requirements traceability.
In a nutshell, to meet regulatory requirements, your lab needs to be able to:
- Show that the software does what it was intended to do in how it meets your lab’s process and business needs.
- Trace and document requirements (which define your lab’s process and business needs) as well as any changes made to them from the original requirement statement through to design, implementation, and release.
That means making an important decision: which methodology will you use to manage and trace implementation requirements—waterfall or agile?
Identify the primary liaison between stakeholders
Before selecting a methodology for managing requirements, we recommend labs identify one person who will be primarily responsible for liaising between the LIMS implementation team (whether internal or external to the lab) and other stakeholders—including those who work in the lab, in R&D, on the business side of the organization, and any medical subject matter experts.
This person represents “the stakeholders”. Ideally, they understand all the components in the laboratory software ecosystem and have enough knowledge of the lab’s processes to be able to define the requirements and ensure they are met. They also need to be available and able to answer questions from the LIMS implementation team, be prepared to work in an iterative manner, have access to relevant stakeholders when clarification is needed, and have decision-making power. That decision-making power should be equivalent to the total dollar expenditure possible by the LIMS implementation team between check-in points with stakeholders.
In our work with labs, we’ve found that the most successful liaisons are often:
- A product development scientist (the person who defines the lab’s standard operating procedures).
- Lab managers.
- Former lab technicians who have become analysts or developers (often these people have a well-rounded perspective and are experienced in multiple areas in the lab, so they can see the bigger picture but also understand the nuances of how things work).
Assigning someone to the liaison role frees up the LIMS implementation team members to focus on the implementation work itself. It also gives the team members a direct path to communicate with stakeholders when they need additional context or a decision needs to be made.
We have found it useful for these individuals to attend some professional development in their new role prior to beginning a large project. The appropriate training will depend on the project management methodology selected—see the descriptions below for recommendations. A course of a few days in length will go a long way to empowering this individual, as well as equipping them with tools to manage the diverse stakeholder group they will be working with.
Choose the right methodology for your lab
Managing requirements is important for all software projects, but it’s especially important for regulated software because regulatory bodies generally require that labs submit detailed requirements traceability documentation.
Requirements traceability is the ability to describe and follow the life of a requirement in both a forward and backward direction (i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases).
When choosing either the waterfall or agile methodology, labs face a three-way tug-of-war between:
- The high bar of documentation required by regulatory bodies (i.e., full requirements traceability).
- The current thinking that an iterative process is optimal for modern software development.
- The difficulty in knowing all the requirements for complex laboratory software upfront.
To help you decide which methodology to use, we’ve summarized their main elements, as well as their benefits and limitations.
Waterfall
Using the waterfall methodology, you begin by defining the lab process requirements in an application lifecycle management (ALM) tool. To get started, ask yourself: what does the lab need the software to do? Remember to focus on the lab’s processes, not the implementation details of the LIMS.
Next, you migrate the process requirements to a development requirements management system. This process involves creating a series of “tickets” for development tasks. Depending on which tool you choose for initial requirement documentation, the amount of effort involved here will vary. Tools such as JIRA provide a well-known interface for ticket creation and requirement documentation. Ideally, the ticketing system is bi-directionally integrated with your ALM tool to prevent requirements from becoming out of sync.
With a clear path forward, the implementation begins. Keep in mind that changes will be needed as new requirements are uncovered. For instance, “numbers” can be a big source of change (e.g., any variable calculations required for quality control, the amount of material required for tests, concentrations, etc.). Don’t forget to define a strategy for dealing with these changes.
When coding is complete, testing begins. Quality assurance (QA) work is performed to ensure the feature works correctly, tickets are marked “done”, and the ALM is updated. Once the software is considered code complete and tested by the internal teams, a final system test performed by the implementation team and end-user validation should occur to ensure the code meets the needs of the end-users and accomplishes all goals outlined in the requirements documentation.
This sounds remarkably straightforward, but keep in mind that this is the “ideal” validation process. In reality, the waterfall methodology includes several common pitfalls:
- The scope of the LIMS implementation is locked in from the beginning.
- It can be difficult to measure progress within stages. Once an iteration is complete, there often aren’t plans to go back and address concerns or issues in the next iterations (prior to deployment of the “first version”).
- The process doesn’t easily allow for changing requirements during the cycle. Note that if it takes a lot of effort to update the ALM when something is changed during the development cycle, the implementation can become expensive and cumbersome, hence our previous point about bi-directional integrations with ticketing systems.
- No workable or testable product is produced until late in the development cycle. This often leads to end-users (or even QA professionals) not being involved in code testing until later stages such as validation. Engaging a developer to fix a bug or defect requires that they replicate the issue, investigate it in order to load mental context, and then update the code. Doing this while actively working on a piece of code is one thing; doing this after the software has been built and the developer has moved on to other areas of the system can be a much bigger challenge.
- If requirements changes are made during development, the approval process for these changes can introduce a significant amount of overhead and delay development milestones.
If you already know your lab’s processes—they’re tested, validated, and well-understood—and you can clearly define your requirements, the waterfall methodology can be highly successful and efficient. However, even though you’ve defined requirements upfront, you’ll likely need to finalize the full requirements traceability documentation closer to the end of the build cycle, prior to the validation phase.
Note that laboratory process development does not use the waterfall methodology because of the need for scientific experimentation and iteration. In this case, you can’t know ahead of time whether something will work as you develop a test, and therefore, the waterfall methodology is not a good fit for a LIMS implementation done in tandem with laboratory process development or improvement.
Recommended training: Traditional software project management training will be valuable for the liaison taking on a waterfall project for the first time.
Agile
The agile methodology follows a more iterative process. Instead of trying to anticipate all the requirements upfront and starting with a concrete specification, you begin with a scaffold (a high-level list of what needs to be tracked) and a rigorously defined process to reduce uncertainty and ensure working software. From there, the implementation team maintains a backlog of required changes as they perform iterative implementation sprints. Over the course of the implementation project, as the team works to evolve the system to meet all the lab’s needs, you build test plans, and eventually, you create “as-built” requirements in the ALM tool.
Integration of testing processes during development cycles leads to lower overhead and higher software quality. Fewer issues identified later in the project lifecycle mean fewer iterations, which leads to a lower overall cost. This process is often also preferred by development teams, as it gives them direct feedback on the code they’re currently building as opposed to having to dig through code written long ago to triage and identify defects. Do account for time to fix issues as they are identified in testing and in validation phases around releases. Not budgeting time to address these issues incurs significant timeline risk for any high-complexity projects.
However, many development teams do not focus on detailed documentation as they work through early iterations. This can pose serious challenges when building software for a LIMS, especially in labs that are regulated. Agile principles state a preference for “working software over comprehensive documentation”, but that often doesn’t work in a lab context. If you wait until you’re done building to document requirements or update/analyze your existing requirements in the ALM tool, you’re accruing significant technical debt in requirements and analysis. In a best-case scenario, each iteration has analysis time built in to verify the output of the development iteration is progressing toward meeting project goals and requirements.
When formal requirements documentation is concentrated at the end of the build, it can become a bottleneck—validation cannot be completed until the documentation is complete. Furthermore, if requirements around the LIMS and the lab processes undergo significant and frequent modifications during development, the total implementation effort might be higher compared to using the waterfall methodology with its fixed set of requirements.
Nevertheless, the agile methodology is likely the right approach if you don’t know all the lab requirements upfront. This could be the case if you’re developing or taking the opportunity to redevelop lab processes at the same time as implementing the LIMS. It might also be the right choice if your lab wants the LIMS implementation to be ready as soon as possible once the lab processes have been nailed down since the two are being built in parallel rather than sequentially. Remember though, that by doing this, you might introduce additional overhead and have to manage changes in two systems concurrently.
Recommended training: Agile Product Owner training will be valuable for a liaison taking on an agile project for the first time.
Selecting the best requirements management methodology for your validated lab is a crucial decision. If you’re uncertain, we can help you evaluate the two and make a decision. We have experience with both and understand what the regulatory bodies expect. If you need help with the LIMS implementation, we can handle that too.
Contact us for a free consultation if you have any questions or are finding the task of LIMS implementation daunting.
