Managing Change in Lab Operations

Managing Change in Lab Operations | LabLynx Resources

Download PDF

During the first week of August 2022, the Houston Astros played the Red Sox in Fenway Park (the Sox’s home field). Christian Vazquez had been a catcher playing on that field since 2014. On August 1, he found himself playing on the same field but in a different uniform, that of the Astros. He had been traded just as the series was going to start; this change elicited a reaction of “baseball is a business”.

Change is one of those things we all have to deal with, and a good approach to it requires constant preparation. Most discussions of change management stress leadership styles and personnel management concerns such as communicating effectively, managing change processes, determining methods of implementation and creating a culture of change. These reasons, and others discussed in Lab Manager 1 2 3, are important, but we’re going to come at the subject from a different direction: the necessary preparations for successfully managing and implementing change.

We’re going to first look at the sources of change and then the preparation it takes to meet it. That preparation will require having the right people in place with the right backgrounds who are able to meet whatever challenges may come. That last sentence is management’s responsibility.

The sources of change

Change can be driven from three directions: changes generated by upper management; within the lab to improve its operations or meet changes in organizational goals; and changes driven by competitive pressures, regulatory agencies, and other organizations.

The following change is generated outside the lab, often by upper management.

  • In a manufacturing/production organization, there can be changes in existing product specifications, entirely new products being introduced, organizational changes to improve operations, or new/updated regulatory requirements.
  • In a research environment, there can be changes in project directions, new projects being started, and existing projects being terminated, as well as organizational changes.
  • Corporate policy groups can affect changes in operations in response to competitive pressures, new directions, financial constraints, and new/updated regulatory

The following changes are driven from within the laboratory:

  • Changes can occur at the informatics level4 (e.g., major database systems, shared access). The figure below shows a possible implementation development for laboratory-wide informatics systems.

In most laboratories planning for informatics systems is done on an as-needed basis rather than during the lab’s founding. The most common approach is to start with paper notebooks and then migrate to spreadsheets and word processors as the lab’s needs grow and the demand for more efficiency occurs.

However, sample and test management via spreadsheet can become unwieldy as the number of people and samples grow, and generating a need for a laboratory information management system (LIMS). The need for shared records and the overall efficiency of operations in research can drive the need for an electronic laboratory notebook (ELN).

As the lab’s work expands, it may find a need for additional systems like laboratory execution systems (LES) and scientific data management systems (SDMS) to support experiment execution and data/information management. There may also be a need for statistical packages and other support systems.

  • Changes can occur at the lab bench4. This includes the need for:
    • New instrumentation;
    • New methods/revisions to existing methods;
    • Significant upgrades to instrument support software, reworking how instruments are being supported (e.g., moving from a single instrument per computer to multiple instruments per computer);
    • Changing personnel responsibilities, and
    • Revising the handling of methods for reference materials or introducing new reference materials.

There is also a third cause of change: external drivers. These can come from a variety of sources including regulatory agencies, and increased competition (e.g., contract testing labs, contract research organizations).

Addressing sources of change 

As previously noted, drivers for change can be found in the upper levels of an organization as well as internally in the lab. How do we address these drivers of change? Through anticipation and preparation.


It’s rare that a need for a change will be a complete and total surprise (except sometimes in baseball). In most cases, during the normal course of a company’s operations, the need for change develops over time, and being aware of the technical and political landscape of your organization can prepare you for that change. However, there are times when things come as a complete surprise to parts of the organizational structure because they were intentionally structured that way. Reworking of organizational charts and layoffs are two examples; those represent disruptions to the normal course of business.

The potential need for changes coming from more senior management usually can be inferred by laboratorians by maintaining good communications with those higher in the organizational chart, reviewing monthly reports, and talking with your peers. At the same time laboratorians should ask:

  • What new projects are starting up? If you manage a testing lab, upper management may set the stage for new method development and analysis/testing.
  • Are frustrations growing with an existing project? What are the impacts of its termination or changes in direction?
  • Is there evidence of problems with your lab’s work, or, are people pleased with what is going on?
  • Is the workload in your lab going to change? How do you prepare to address it?

Overall, good communication with those around you in the organization, including those working with you, is a good way of anticipating change and making plans to account for it.

Anticipating changes within your lab should ideally be easier because more information is available to you. However, bottlenecks may develop that impact productivity. “Fix the bottleneck” is a common response to this, but not always the right one. Suppose the bottleneck is occurring in the middle of a procedure; focusing on that point may just shift the problem further down the sequence. What may be needed is a review of the overall process that includes both fixing the bottleneck and understanding the impact that it will have on the rest of the procedure. Further changes may even be warranted.

Other red flags can include (partial list):

  • Excessive equipment maintenance/failures
  • Changing requirements for a particular method (an increase in demand may set the stage for new equipment or upgrades which could require re-validation of the procedure);
  • Excessive use of third-party labs for testing (requiring analysis of whether or not the tests should be brought in-house); and
  • The lab’s informatics strategy doesn’t appear to be holding up (ask whether a revision needed, particularly from paper-based methods or spreadsheets to LIMS or ELN).

Keeping track of monthly requests for work can help you anticipate the need for change, and so can talking to those working in the lab on a regular, informal basis to find out what they see and hear.


How do you prepare your organization for having the right people with the right skill sets who are able to fully support operations while being flexible enough to accommodate change without significant stress? There are two important components: planning and people.

First, have a strategic plan and the people in place to execute it. What is a strategic plan? It’s based on the kind of lab you’re operating. Is it a research or service lab? The difference is the nature of the workflow (service labs being more structured, with research operations being more varied). Next, ask what are the trigger points are for moving the plan from one stage to another? The plan should include:

  • Statements of purpose: What type of work will the lab do? Will it conduct service testing (in- house or contract) or research?
  • Statements on startup activity/experiments/tests: How is your lab going to start its operations? This sets the basis for future If you have an existing operation, this step would be replaced with a snapshot of current operations and issues.
  • Equipment requirements: What equipment do you need/have and what is the next set of additions? What capabilities will the equipment provide and how will it affect operations?
  • Data management requirements: What is your data management strategy? Address data capture, backup (local, online), system upgrades, and support?
  • Informatics requirements: What are your plans for implementing LIMS, ELN, or as well as other informatics support systems?
  • Growth potential: What are the next steps in the lab’s development and what will trigger those steps?
  • Risk management: What are the vulnerabilities and risks in your plan and how will they be addressed? These are likely sources of internally driven change.

The main point of this planning is to think things through that you may not have considered like data and power backup. Of course, you can and should revise your plan as changes occur. The plan should periodically be reviewed by lab personnel and support groups to get their points of view.

Of course a plan is not made in a vacuum, it requires knowledgeable people. Those most likely to be involved in developing and implementing your planning include the:

  • Organizational director/senior management, or someone who has direct oversight for the lab and budget approval authority;
  • Lab manager;
  • Lab personnel;
  • IT support;
  • Laboratory systems engineers5; and,
  • Vendors.

For the sake of simplicity, we are going to break people’s backgrounds in lab technologies into two levels (you may add finer granularity as needed) the user and technical levels. It is assumed that laboratorians have a solid grounding in the science appropriate to the lab’s operations.

The user level implies that laboratorians are competent users of technology, able to not just “push this, then that” but also understand what the technology does, how it functions (often referred to as “theory of operations”), and how to perform basic troubleshooting if problems occur. The technical level is the user level plus the ability to make adjustments/changes to product operations within the limits set by the vendor. The laboratorian at the technical level would also be the point of communication with the vendor’s technical support and have access to more depth of knowledge for solving problems.

The lab manager is one of the critical stakeholders of the plan and is responsible for developing and managing the overall plan with input from those working/supporting the lab’s work. They should have at a minimum user-level knowledge of the technologies used in lab work and understanding of their inter-relationships. They should also have clear communications skills when working with people in the lab, and their peers in other parts of the organization as well as upper management. Finally, leadership skills are necessary to help the lab set and achieve its goals, as well as represent the lab to the rest of the organization. That leadership also extends to getting lab personnel to extend their skills beyond basic lab science to embrace informatics and lab technologies that impact their work.

Lab personnel should have: user-level knowledge of lab informatics, working with lab devices, instruments, and instruments data systems. In smaller labs, the knowledge base may have to extend to the technical level if another support source isn’t readily/reliably available. They should also be aware of technology trends in the equipment they are working with, look for opportunities to improve lab operations, and be ready with suggestions for replacement technologies/products when necessary.

Whether internal or external, IT support will likely be focused on computing equipment, networks, and support below the applications level, particularly if they are contractors. You may have leverage for a higher level of support if they are internal personnel. There should be clear communications between lab management and IT management on responsibilities and support requirements. One common area of conflict is corporate goals on equipment and operating support that can conflict with lab operations. For example, a goal of updating all computers to the same OS level may cause instrumentation to fail if it hasn’t been certified by the vendor.

Laboratory systems engineers– these fill the gap in laboratory and technology expertise that often exists between lab personnel and IT support. They should understand the science appropriate for your lab, the equipment used, and the technologies that apply to lab work. Part of their role is to advise lab personnel on overall trends in technologies and assist them in choosing products for new/updated lab procedures. They may be responsible for developing systems for lab use, or, working with vendors on implementing systems. Their knowledge should be at the technical level for all the lab’s technologies.

While vendors may not be directly involved in your planning, the complexity of today’s technologies make them a supporting stakeholder for both advising on new products/technologies and technical support. As a result, a serious effort should be made to establish good working relationships with key vendors, particularly those with LIMS, ELN, and other informatics products used in the lab. The lab should provide the vendors with input on their future needs while expecting the vendor to keep them abreast of their development efforts; this may require NDAs for key technologies.

One critical aspect to the above is ensuring that those working in the lab have the appropriate education in the science and technologies used and anticipated for use in lab work. Part of management’s goals should be programs for formal and informal education of all lab personnel.

With this foundation of awareness, anticipation, planning, and personnel, change can be managed as part of normal lab life. It isn’t something to be apprehensive about but rather expected and handled on a basis of solid preparation.


1 “A Guide to Successful Change Management”, management/a-guide-to-successful-change-management-27457

2 “Change Management”, management-995

3 “Managing Change in Clinical Laboratories”, staffing/change-management-995

4 These changes may require method development, validation, documentation, and training.

5 See “LII:Laboratory Technology Planning and Management: The Practice of Laboratory Systems Engineering”,

Share this Article

Contact Us

"*" indicates required fields

I am interested in:*
This field is for validation purposes and should be left unchanged.