Navigating change successfully in the lab?

Change is both inevitable and constant in the modern lab – evolving regulatory requirements demand greater analytical sensitivity or more rigorous reporting; new instruments are launched to tackle increasing analytical problems faced by scientists; and digital transformation is now considered a necessary step for labs processing and communicating huge amounts of data between systems and software.

Despite its importance, change can be daunting for scientists. Change management is crucial to implementing meaningful and successful change, yet it is often neglected or not applied in full across the lab.

Our infographic highlights the key considerations labs should take when embarking on change, and how to ensure that change is managed successfully across all facets of the lab environment.

Scimcon describes key change management factors for lab managers to consider when undertaking an informatics software implementation.

For more recommendations about how to successfully manage change in an informatics software project, visit our blog: Breaking the change management mould – leading successful laboratory information system projects and digital transformations – Scimcon

Breaking the change management mould – leading successful laboratory information system projects and digital transformations?

Laboratory-based organisations have consistently undergone change, whether provisioning new analytical techniques, instrumentation, information system implementations, or incorporating new regulatory requirements. This is especially true today, when we are undertaking initiatives such as digital transformation and the introduction of AI/ML. In fact, one definition of transformation is ‘a radical change’.

What’s clear is that change is constant. However, managing change effectively is essential to success when undergoing these types of projects. Well-run lab informatics projects manage change within the software project lifecycle. Examples of project change include adjusting functional scope; raising change requests as functionality is demonstrated; and variation of costs. Yet, one key area of change is often neglected.

The problem arises when change management for lab informatics projects focuses solely on the technical delivery of the software. In these cases, very little effort is allocated to the change that will need to occur within the laboratory to accommodate the new system. If lab change management is considered, it is often dealt with ad-hoc and separately from the software delivery part of the project, leading to misalignment, misunderstanding, and missed timelines.

75% of the lab is indifferent to your project.

Lab Manager reports that in a typical change environment, 25% of staff will be early adopters, 25% will actively resist change, and about 50% will be ‘on the fence’ in the early stages.1

These statistics are backed up by experience. Scimcon is often called in to resolve issues within ‘in-flight’ informatics projects. All too often, the route cause analysis reveals the lab community only understood the true impact of the new system too late to adopt it, adapt lab workflow, and change procedures. Rectifying the issues after the fact is seldom quick or low-cost.

Informatics projects don’t operate in a vacuum.

Informatics software does not function in isolation, so change management needs to consider the physical working procedures, workflows, SOPs, job roles, quality system, and other areas that will be impacted within the laboratory.

For example, the implementation of a new LIMS could trigger changes such as:

Given that a lab informatics project will generate a large number of change items similar to the above examples, they must be managed appropriately.

In many respects, these changes are very similar to a system’s user requirements, except they are related to the lab processes as opposed to software functionality. With this in mind, they need to be handled in a similar fashion. Create a team with a project lead and subject matter experts who represent the laboratory. The lab change team should be tasked with actively gathering and maintaining the backlog of change items throughout the project life cycle. Each change should be assessed for impact and priority, added to the change management plan, and allocated to team members to be actioned.

Planning for change starts early.

Before making any significant lab Informatics investment within an organisation, it is likely a business case will be required. If you are serious about managing all aspects of change this is where you should begin. Business cases generally do an excellent job of covering benefits, costs, and ROI – however, change management, specifically within the physical lab, is often not called out in terms of impact, approach or importantly the resources and associated costs.

Not highlighting the lab change management process, resources and costs at this stage will make it considerably more difficult for change management to become embedded in your project at a later stage.

Benefits of effective change management.

The benefits of effectively integrating laboratory change management alongside traditional change management for lab informatics project cannot be ignored. New systems can get up and running faster, and can, importantly, deliver improved lab processes and be met with enthusiasm rather than reluctance, scepticism, or apprehension.

Scimcon consultants are on-hand to support lab leaders overseeing change. As many of our consultants have lab experience themselves, they have seen first-hand the impact of change in the lab, and can provide in-depth knowledge on how to ensure success.

For more information about how Scimcon can support your next big project, contact us.

References:

  1. ‘A Guide to Successful Change Management’ Lab Manager, https://www.labmanager.com/a-guide-to-successful-change-management-27457 [accessed 02/11/23]
In order to work as intended, this site stores cookies on your device. Accepting improves our site and provides you with personalized service.
Click here to learn more