A dedicated lab informatics project leader is an invaluable addition to your team. There are simply too many tasks to oversee for the role to be filled by ad-hoc lab personnel with day jobs. Even if you assign one of the lab staff to the project as their job for the duration, if that person hasn’t got experience with leading complex lab informatics projects, they will struggle.
No matter how experienced a project leader is, there are always going to be things that go wrong. The project leaders at CSols have seen their fair share of mid-implementation disasters. You wouldn’t be reading this if you didn’t want your lab informatics system to be a complete success; fully embraced by end users, with every bit of functionality it needs to meet the goals and objectives of upper management despite any hiccups along the way.
The idea for this blog post was based on a poll we ran last year that listed all of the tasks a project leader needs to manage in the course of a lab informatics project. We asked our project leaders the following questions about their work to provide some insight on what is necessary to lead a successful lab informatics project.
The answers to these questions fell broadly into the categories of proper resourcing for the project, ensuring user adoption, implementing Agile methodology, and appreciation for the complexity of the project. In reading this, you will learn some tips to ensure that the end users get the most value possible from their LIMS implementation.
First and foremost, among the takeaways from the CSols project leaders is the importance of deep technical experience. Each of the selected resources should have familiarity with the systems that will be integrated with or supplanted by the LIMS, if not with the LIMS itself. This technical know-how will help the project avoid common pitfalls. The designated project leader’s work begins before the project kicks off, with detailed planning and interviews with all stakeholders to understand the requirements that must be met.
Experience with previous LIMS implementations is also advantageous in a project leader and, although it’s not a requirement for success, it is a good reason to consider using a third-party consultant to fill that role. A project leader without previous LIMS experience may not know the right questions to ask the vendor, the end users, or the other members of the project team. Inexperienced LIMS project leaders also may not recognize the baked-in dependencies between tasks that can lead to scope creep.
An important part of resourcing is to do the planning upfront so that you have the right resources in place when it’s time for their piece of the work. One of the missteps that our project leaders identified is when planning fails to fully ensure that the application of the LIMS is fully considered, in terms of how it will be used, by whom, when, and in what way. This kind of planning takes your LIMS project from just something that could potentially meet the lab’s needs to something that enhances user adoption rates, usability, and workflow needs.
Proper resourcing sometimes means that less is more. Having fewer dedicated resources in preference to large numbers of part-time resources is critical as the LIMS project evolves. Changing people on the team can hinder success because of the learning and understanding that leaves with the former team members. How a project will play out on a day-to-day basis also depends on the rapport between all team members. This takes time to develop and is as critical as the list of tasks to be accomplished. Proper resourcing must also address funding, of course. None of this comes cheap. It is important to get buy-in from the business to ensure project success.
No matter how much thought and care goes into planning your LIMS project, without user adoption there is no success. The most important way to ensure that the end users adopt the LIMS is to get their input at the beginning. Our project leaders have found that the traditional User Requirements Specification document has limited use; instead, use cases and user stories really help with adoption because they translate the requirements into situations the users have experienced. These kinds of stories also facilitate the use of Agile methodology. The process of developing use cases or user stories provides clarity and has the following benefits:
Another important step toward user adoption is to ensure that robust communication plans are in place and that a single point of entry/retrieval has been established for project communications. An intranet site, Slack channel, or weekly lunch and learns are some of the ways our project leaders have handled communications. The communication style is not as important as the frequency and transparency. Maintaining stakeholder, especially end-user, engagement throughout the project prepares the way for user adoption. Agile methodology and effective organizational change management (OCM) help with this.
Quite likely the biggest factor in user adoption is proper OCM. In your initial planning, be sure to address training and communication needs to foster goodwill and prepare the end users for the necessary changes to procedures and workflows. Your preplanning should anticipate the kinds of OCM issues that will be encountered and consider how they will be addressed. If OCM isn’t handled properly, user adoption will be low. Developing the use cases or user stories should be seen as part of effective change management, as well. In a recent implementation project, the CSols project leader worked with the stakeholders on change management by providing process harmonization input and comprehensive training.
Experience has shown that typical waterfall methodologies won’t work for lab informatics projects; an iterative approach is required. Traditional lab informatics project structures often aren’t fully prepared to support an Agile approach, where change is made quickly and information is disseminated through a single point of contact. Capturing data and feedback once for retrieval in a minimal number of ways ensures efficient knowledge transfer. In an agile approach, instead of developers developing then handing work or information over the fence to testers, the testers and business analysts are part of the development meetings with the client. Alternatively, all parties input notes, design details, or requirement changes to the same system to reduce the need to seek out and synchronize information.
Implementing an Agile approach to project management is still relatively new to some aspects of lab informatics, particularly in regulated industries. Our project leaders were early adopters of the Agile approach and have used it successfully in a wide range of projects. Making this approach work for a LIMS project depends on proper resourcing, because you need a cross-functional team that can be available for each scrum and sprint. However, adopting an Agile approach increases the chance of project success because stakeholder buy-in is obtained before the project begins.
If it hasn’t become clear by now, your LIMS project has many interconnected pieces that all need to work together to ensure success. Underestimating the amount of time and effort that the business resources will need to spend on the project is a key failure point. To mitigate the risk of such an underestimation, there are some smart moves you can make.
The advice shared here will help your LIMS project be successful. These are complex projects, but they aren’t impossible. Of course, if you do decide that bringing in an experienced project leader is the right move, CSols can help.
Have you led a lab informatics project for your business? What else would you add to our list of tips?
Comments