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.
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:
The sample receipt area’s benches, desks, and workspace may need to be rearranged to support barcode scanning and sample labelling.
New sample storage and chain of custody functionality could trigger a significant rewrite of one or more SOPs.
The need to create and manage tests, methods, results and specification templates may require a new master data management role to be created and in larger systems this may necessitate a new team or even a new department.
Integration of automated sample preparation and communication with instruments may necessitate the lab working with instrument vendors to update or replace equipment/instrumentation.
The implementation will trigger a myriad of changes to lab workflows with implications ranging from trivial to significant.
If the LIMS includes auto-approval of results that are within agreed limits, this could require detailed discussions with the QA team.
If the system generates certificates of analysis (CofAs) for internal or external clients, this could mean the new format needs to be agreed upon with the clients. Incorporating electronic signatures on CofAs may also need consultation with external clients.
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.
Do you start a business with the intention to divest, or is this something that becomes clear as the business grows?
I find building a company from the ground up very exciting, so that is always a leading factor behind starting a new business. Divesting is never the intention when building a business, it is more something that becomes clear over time. The motivation behind starting my businesses is to create value and deliver a meaningful impact into the pharmaceutical and life science space, in whatever shape that may take.
Take Sciformix, for example. As with my other businesses, Sciformix was created in the right place at the right time, offering our ability to combine science and process at a time when other outsourced businesses were only offering one or the other. When creating Sciformix, the intention was not to divest at a later stage, but to deliver value in what was, at the time, a new area in science.
CROs and regulatory consultants had been around for a long time when I founded Sciformix, but pharmacovigilance (PV) was a relatively new area in the industry. As regulations tightened on the reporting of adverse events within clinical trials, the pharmaceutical industry sprang into action, and it soon became clear that the new pharmacovigilance processes were too much, and too lengthy to all be completed in-house within the 15-day deadline for reporting serious reactions. These regulations were very new when we built Sciformix, and as a result we grew very quickly and worked through roughly one and a half million cases per year. When the time was right to divest, Sciformix was acquired by Covance, and it was time to move on to the next venture (Scitara).
How do you know when it is time to divest and move onto your next project?
When you are working on your business, there is not a conscious decision to divest. You know when the time has come to move on – it is like you flip a switch and realise it is time for something new, and you begin to ask yourself “why would I sell?”
Timing is critical when considering divesting. Is it the right time for your customers? Is it the right time for your employees? And is it the right time for your investors? If it is the right time for all three of these areas, then you can begin the transition fairly quickly. However, if only one or two of these areas are ready for this change, you need to step back and ask yourself “how can I make it the right time for all three?”. Thankfully, all of my exits have been at a point where the time has been right for all three parties, so I have left my businesses smoothly and on good terms.
Does divesting affect the company’s customer base, or is there a smooth transition?
Interestingly, a lot of our customers often prefer to work with smaller companies, such as those which I founded, over larger companies who offer similar services. The benefit of smaller outsourced companies – well, small in comparison to the customer – is that the culture is quite different. Smaller companies and agencies can offer a level of flexibility and innovation to customers that can be difficult to pass through larger organisations. In addition, there is a real sense of an “I have your back” attitude, as you are able to work closely with your customers. Culturally and contractually, my companies have been able to offer something different to larger companies, and we have been willing to do anything and everything our customers needed, which is why they would often choose to sign up with us.
However, as the business grows, those customers tend to stay. When customers become a part of your journey, your relationship with them evolves and your company becomes better equipped to protect their business. Because I aim to divest at a time when my customers are ready for it, there is generally a smooth transition.
You mentioned in our last blog that Scitara was your ‘finale’ – what do you mean by this?
As my previous three ventures were in tech, services, and global delivery, Scitara is the summation of all of my previous projects. As I mentioned in the last blog, Scitara aims to solve the major problem within the lab industry of data connectivity and is leading the digital revolution in labs to address this issue. To do this, we will require the cooperation of every connection we have made over the years, as by helping us, we can help them. If we can reach out to everyone in the ecosystem, we will be able to help companies take a huge leap into their digital transformation projects by creating a platform through which they can communicate their lab data through their digital systems, something which at present is proving a real hindrance to digital transformation projects.
This is why I believe Scitara is my finale. It is almost as if we have come full circle, as Scitara pulls together the skills and relationships I have built over my entire career – into creating a final solution. I intend to go out with a bang!
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
