Picture this—it’s the day that the lab informatics system you’ve needed for years finally goes live. You hear the cheers, you see the smiles on everyone’s faces, there’s excitement from the end users to learn the new system, and your boss can see the value of the system you implemented. It’s a happy day.
If you want that picture to become reality, to get to the end of your project and make sure that everyone sees the value that your lab informatics system has brought to your business, insist on having a lab informatics project leader on your team. A Project Leader has the knowledge of many past laboratory informatics projects to draw experience from and make your project a success.
Yes, we said project leader. Not project manager.
Most project managers do a fine job of managing tasks and activities…once the laboratory informatics project starts. They ensure that the implementation project meets the estimated timelines, stays within the agreed-to scope, and comes in around the estimated budget.
However, a project leader begins their work before the implementation kicks off. Using their experience gained from previous lab informatics projects, a project leader ensures the new system meets the goals you set for the project. They take steps to ensure the new system brings your team value once you go live rather than just being a data collection and reporting system. A project leader ensures that your newly implemented lab informatics system will provide the efficiencies your lab needs. A project leader helps you avoid wasting time, money, and energy implementing functionality that doesn’t bring value to your team. Trust us, this happens all the time and is something many clients don’t think about.
If you want your lab informatics system to be fully embraced by end users, with every bit of functionality it needs and that meets the goals and objectives of management, read below to learn how a project leader ensures value is brought to your lab informatics system implementation.
Ensuring that your new lab informatics system, whether it be a LIMS, ELN, LES, or CDS, provides the value you seek is a process that should start during the inception phase of your project. It is extremely important that expectations are managed from the beginning. Otherwise, project resources, end users, or company managers will ask, “Why doesn’t the system do…?” or “I thought that we were getting…?” These types of questions can be detrimental to system acceptance well before it is even close to go live and can also cause scope creep. This is the perfect place to include a Project Leader because they know what needs to be done in the early phases in order to provide clients with the value at the end of the project that they were anticipating.
Well before the implementation phase of the project kicks off, project leaders begin working with the stakeholders to define both the project and system goals. These goals will help the team focus directly on the activities and configuration of the system that are necessary to meet the laboratories’ needs.
The key is to get agreement from all stakeholders on what the project goals are, and publish them for all current and future team members to access when needed. This agreement helps manage expectations throughout the implementation project. The goals are especially useful when important decisions on new requirements and change requests are to be made during the project.
Before project kick off is also a good time for a project leader to explain what not to expect from a new or updated lab system. For example, the system will not make all decisions for the users, nor automating manual processes like making the coffee before the shift starts. These types of requests require a large amount of customization that increase the cost of configuring, testing, documenting, and training on the new system. Users should learn how the system works as is before they request functionality that doesn’t necessarily provide value or that isn’t achievable.
If stakeholders are aligned on the project goals and expectations before any configuration or customization starts, lab informatics implementation projects have a much better chance of meeting the intended purpose without scope creep, inflated costs, and unnecessary change requests. Early stakeholder engagement allows project leaders to identify potential resistance and to develop plans to mitigate any such resistance. Written user requirements alone cannot ensure that your project provides the value you need.
No project is complete until the paperwork is done. System documentation can be a costly part of the project if missed, skipped, or done incorrectly—resulting in a system that doesn’t do what the client needs. Ensuring that necessary documents are defined from the outset will mitigate wasted hours spent writing documents that aren’t needed to support the system or save time from having to go back and start over.
The value comes from what is written in the system documentation. The documentation supports the system as built and will help guide your implementation to be a successful system adoption.
But this step doesn’t just happen on its own. Project Leaders work with stakeholders to define which documentation is required to be developed for the project and will bring value to the users. For example, is it necessary to have an SOP for System Administration or is the vendor admin training and manual enough? What kind of training documentation and materials are required? Determining these documents at the outset ensures that time is well spent during the implementation.
Once the goals for documentation are set, the project leader and the stakeholders will need to review and prioritize the user requirements to determine which will bring the most value to the lab. This step sounds fairly straightforward, but the majority of lab informatics projects are estimated to last a year or more due to the extensive number of approved requirements to be implemented, many of which provide little business value.
Experience from previous lab informatics projects have made project leaders aware of this pitfall, and therefore, have methods and a manner for getting through this step successfully. They will break up the requirements based on functional areas and determined value that each will bring to their client. Then the project leader can recommend ways to divide a large project into smaller phases, where each phase adds value to the entire organization or to specific sections of the company.
The end goal is to get the client’s system configured to be used is the most efficient manner and that can’t happen if the requirements are not identified and prioritized properly.
All projects have new requirements or changes to requirements after the implementation begins. Project leaders work with the stakeholders to determine the value of the changes or new requests and to gauge the value they bring to the use of the system, if any. The same review and prioritization methods used to determine the value of the user requirements is used each time a new requirement or change to a requirement is brought up. The team must agree on whether the new or changed requirement brings value to the current phase or should be deferred to a later phase.
An experienced project leader has seen and heard it all before and can explain the reasons why the client should/should not do the change and pay/not pay for the changes. They will know when something adds value, when something will never get used, or that it will be harder to use than it’s worth.
Without the guidance of the project leader to work through the changes, you could be faced with a prolonged decision process, biased stakeholders may force their decisions on others, and the money will be spent on things that provide limited value to the organization.
Besides the usual suspects of status reports and team and steering committee meetings, the project leader looks to communicate with all stakeholders early and often. The early adopter mentality is contagious, and spreads through formal and informal communications channels during the lab informatics project. The project leader controls the messaging and can prevent the spread of inaccurate information by reminding everyone of the agreed-to goals, objectives, and value that the completed project activities will bring to the organization. The messaging can be spread through communication channels that are tailored to the audience, such as demonstrations, lunch and learns, and email updates.
Can you think of other ways in which a project leader can or has added value to your lab informatics project?