Project Management Best Practices for Laboratory Projects

Introduction

In this article, we will be going over project management best practices. We will begin by first defining what project management is. This is followed by explaining the typical categories of project management: waterfall, agile and hybrid. We will then be explaining the best practices and qualities a project manager should have according to the Project Management Institute. After all the basics, we’ll be going into more detail about the challenges and necessities when performing project management practices in regulated industries. Finally, we’ll be walking through the steps for an hypothetical project: investment in new laboratory GxP system in the pharmaceutical industry.

Chapter 1. What is project management?

The Project Management Institute (PMI) defines a project as a temporary initiative undertaken to create value. This indicates that a project always has a specific beginning and end. It possesses a distinct goal, environmental conditions, approaches, and stakeholders. As such, the routine operations an organization performs are not projects, as they are typically performed continuously without a defined conclusion. In a laboratory context, examples of a project include installing completely new equipment, developing and validating a new analytical method, building a lab from scratch, or implementing a LIMS.

What, then, is project management?

The PMI defines it as the application of knowledge, skills, tools, and techniques to project activities to meet or exceed the intended value. A project manager is responsible for ensuring this value is realized. Because projects create something new, project management is essentially value creation through organizational change: transitioning an organization from its current state to a desired future state.

In addition to projects, it is important to understand two other terms: programs and portfolios.

  • Program: A group of related projects managed in a coordinated manner to obtain benefits not available from managing them individually.

  • Portfolio: A collection of programs, projects, and operations managed as a group to achieve strategic objectives.

To continue our previous example, a portfolio could be the collection of all new capital investments an organization intends to implement. A program might be the rollout of an ERP system across various global business units, where each local implementation is an individual project.

Next, let’s go into more detail and explain what the different project management approaches are.

Chapter 2. Project management approaches

Project management approaches can be categorized into three different types: predictive (waterfall), adaptive (agile), or hybrid. Let’s dig deeper into the similarities and differences of these approaches.

Predictive Project Management

A predictive project management approach is also known as plan-driven, waterfall, or traditional project management. It is the preferred methodology when the project scope is well-defined and stable during the initiation phase. Due to the extensive upfront planning required, it is the most reliable option for projects involving significant financial investment or those where regulatory oversight is mandatory.

In this approach, the scope, schedule, cost, resource needs, quality requirements, and risks are baselined (locked) early in the project life cycle. To maintain control, several phase gates are typically implemented to assess whether the project is proceeding as planned. This structured environment is common in high-stakes industries such as developing new pharmaceutical drugs, manufacturing medical devices, or constructing a skyscraper.

A predictive project can be executed in a strictly linear manner, where one massive deliverable is handed over at the very end. Alternatively, it can follow an incremental path where the final result is delivered in pre-planned, phased stages. At the heart of the predictive approach is the triple constraint: scope, time, and cost. Because the scope is fixed early on, it acts as the primary driver. The schedule and budget are calculated specifically to fulfill that fixed scope.

Consequently, any deviation from the agreed baseline requires a formal change control process. Key stakeholders or a change control board must review and approve any major changes to ensure they do not negatively impact the project integrity. While this makes the approach documentation-heavy, the high level of accountability is precisely why it remains the standard in the healthcare and pharmaceutical industries.

Adaptive Project Management

An adaptive project management approach is also commonly known as agile or change-driven. It is the preferred methodology when the project scope is expected to evolve or contains high levels of uncertainty. Unlike the predictive model, this approach does not require a fully defined plan at the start. Instead, it relies on continuous feedback and iterative development to refine the final product.

In this environment, work is organized into short, time-boxed cycles called iterations or sprints. At the end of each cycle, the team delivers a functional increment of the project for stakeholder review. This structure allows for rapid adjustments based on user needs or market shifts. Adaptive methods are standard in industries where innovation and speed to market are critical, such as software development, tech startups, or medical software applications.

Due to the heavy involvement of stakeholders and clients, customer value is at the forefront of this approach. As such, teams often focus on developing a Minimum Viable Product (MVP) first. An MVP is the smallest functional version of the product, containing just enough features to satisfy early adopters. Its primary purpose is not to be the final solution, but rather to serve as a low-risk tool for gathering validated learning from real user feedback to guide all future development iterations.

The adaptive model effectively inverts the triple constraint used in predictive management. In this approach, time and cost (resources) are usually fixed for each iteration, while the scope remains flexible. This allows the team to prioritize the most valuable features first, ensuring that the project always delivers maximum value even if the total scope changes over time.

Because change is expected, a formal change control board is rarely used. Instead, the project relies on a product backlog that is constantly reprioritized by the stakeholders. While this approach is less documentation-heavy than the predictive model, it requires high levels of collaboration and transparency. Furthermore, it empowers self-organizing teams to continuously evaluate their performance and adjust their internal processes at regular intervals (often called retrospectives) to maximize efficiency. This flexibility is the primary reason adaptive management is the standard for projects where the final solution is discovered through experimentation rather than pre-planned execution.

Hybrid Project Management

A hybrid approach is a combination of predictive and adaptive techniques. It is used when a project contains both well-defined requirements and elements that are high in uncertainty or complexity. By blending these styles, teams can gain the stability of a long-term plan while maintaining the flexibility to pivot where needed.

In a hybrid environment, the project is often structured with a predictive framework for the overall lifecycle, while specific work packages are executed using adaptive methods. For example, a project to develop a new medical device might use a predictive approach for the hardware engineering and regulatory filings, as these require strict sequences. Simultaneously, the software interface for that device might be developed in agile sprints to allow for frequent user testing and interface refinements.

The hybrid model requires a high degree of tailoring to determine which parts of the project should be fixed and which should remain fluid. Often, the triple constraint is managed in a split fashion: the overall budget and final deadline are set at the project level, while the scope of individual software modules or design features is managed through a prioritized backlog. This allows the organization to provide stakeholders with a predictable roadmap while still fostering innovation in the development process.

Because this approach mixes two different ways of working, the role of governance is critical. A hybrid project might still use a formal change control process for its core architectural baselines but allow for decentralized decision-making within the agile teams. This ensures that documentation-heavy requirements for compliance are met without slowing down the creative or technical iterations. This balanced flexibility is why the hybrid approach is increasingly becoming the global standard for complex, multi-disciplinary projects.

Let’s use what we have learned so far and move into project lifecycle management for an actual project.

Chapter 3. Project lifecycle management for a new GxP laboratory system

In this exercise, we will be taking on a hypothetical project: our QC laboratory following GMP is planning on investing in an entirely new laboratory technique, quantitative Nuclear Magnetic Resonance (qNMR) for determining the purity of a drug compound. We will be going through all five major project lifecycle phases: initiation, planning, execution, monitoring and controlling, and closing.

Let’s begin. See below for a sneak peak of the phases we will be going through:

Initiation

Project initiation is required to obtain formal authorization to start a project or a phase. The purpose of this phase is to align stakeholder expectations, define the project’s purpose, and inform stakeholders of the initial scope and objectives while discussing how their participation is needed. In this phase, the initial scope and financial resources are defined, and a project manager is officially named to lead the project. Two major steps are needed in this phase: creating your project charter and identifying your stakeholders.

Let’s begin by defining what a project charter is.

  • Project Charter: This document formally authorizes the project and grants the project manager the authority to use organizational resources to meet project goals. It outlines high-level requirements, measurable objectives, and the overall purpose to ensure the study or validation project aligns with organizational strategy. By defining the why and what, it serves as the foundational agreement between the project sponsor and the team.

With our project charter we begin by asking the following questions:

  • Why? Our stakeholders have performed a feasibility assessment with a Net Present Value (NPV) calculation comparing the use of HPLC vs. qNMR over a 10-year period. The calculations suggest that the initial CAPEX costs of qNMR are far larger than HPLC, but due to lower consumable costs and a 75% reduction in labor, we reach profitability after 7 years of use, with annual savings reaching 100,000 €. We have a clear business case.

  • What? Our project covers the purchase, installation, and validation of a 600 MHz NMR system with 21 CFR Part 11 compliant software. A need for laboratory renovation is also recognized due to the large size and weight of the system and the requirement for liquid nitrogen and helium.

  • Who? A project manager (you) and a project sponsor are named (Head of QC).

  • When and where? We set a high-level timeline: the new equipment must be validated and ready for routine QC by Q4 2027.

  • How much? We establish a preliminary budget of to understand the investment required. Our initial offer from a vendor is quoted at 800 000 € prior to comparison of different providers and their bids. This preliminary budget should cover the entire scope: including possible layout changes to your laboratory and necessary cryogenic cooling infrastructure.

Next, we move into defining what identifying stakeholders mean:

  • Identify Stakeholders: This process identifies all individuals or groups impacted by the project and documents their interests, involvement, and potential influence on success. These findings are captured in a Stakeholder Register to guide communication and ensure that critical technical or compliance requirements are recognized.

For our project, our stakeholder register will include at least the following:

  • Laboratory chemists/scientists: The qNMR technique is new to our laboratory, so our analysts need to shift their mindset from chromatography to nuclear magnetic resonance.

  • Facility Management: These professionals need to design and plan how to fit an NMR system into our laboratory, including all the piping for nitrogen and helium cooling.

  • EHS: Our EHS organization needs to ensure the use of liquid nitrogen and helium does not cause danger to our laboratory analysts (e.g., by installing oxygen-depletion sensors).

  • IT: Our IT professionals need to ensure the NMR software can be integrated with the laboratory LIMS, the workstation is suitable, and all backup and restore functions work as planned.

  • Validation Specialists: These stakeholders must execute the validation of our GxP system and ensure that our software and validation protocols follow GAMP 5 and ALCOA+ principles.

  • QA: Our most essential stakeholder in a regulated laboratory. They define the rules and criteria needed to meet our regulatory requirements.

  • Vendor: The vendor sells us the system and ensures it matches our initial URS. They also provide installation and IQ/OQ and/or possible FAT testing at our laboratory site. Additionally, they help us troubleshoot and are essential to ensuring the qNMR system functions for its entire lifecycle.

  • Management: Our Head of QC will act as our project sponsor.

Alright! We have recieved a green light for our project charter. Next, we can move towards more detailed planning.

Planning

In this phase, we’re performing a detailed planning of our project. We will be defining the total scope of our project and begin planning the steps needed to meet this scope. We will be developing a detailed project management plan other necessary project documents. Remember, planning is never done only in the start of the project: planning is an ongoing process and changes in your project may require revisiting the current plan. The absolute key deliverable of this phase is developing the project management plan, which defines how the project is executed, monitored and controlled, and closed. The content and the complexity of the plan should be tailored based on the application area and complexity of your project.

Below, you can see some examples of what we need to define for our project. The list is not complete. For those interested digging deeper into the subject, I suggest checking out material provided by PMI and other textbooks provided in the sources section (e.g., Process Groups: A Practice Guide.)

  • User Requirement Specifications: Here we will need to document all the specific needs for our new qNMR system. What MHz system do we need? What is the required signal-to-noise ratio? What data integrity requirements do we need to meet? What requirements for the software do we have? What size and weight of the system can our laboratory manage? The requirements might have different categories depending on your quality system: business requirements, functional requirements, safety requirements, quality requirements etc.

  • Work Breakdown Structure: When we have developed our URS, we also need to starting breaking our entire project into smaller parts to be able to understand the scope and required timeline better. We begin by defining our key milestones. These milestones can then be further divided into smaller parts to get a better grip on our actual scope, resource and timeline needs. For our project, we have defined our milestones as follows:

    • (1) Requirements gathering (URS) and project initiation

    • (2) Vendor bidding and procurement

    • (3) Site preparation

    • (4) Validation planning

    • (5) Installation and Installation Qualification (IQ)

    • (6) Operational Qualification (OQ)

    • (7) Performance qualification (PQ)

    • (8) Approval of system for production

    • (9) Method development

    • (10) Method validation

    • (11) Acceptance to routine use

  • Schedule and resources: After creating our WBS, we can begin to estimate the timeline and duration for each task. In a qNMR project, timing is everything because many tasks are dependent on one another. This is called logical sequencing. For example, you cannot begin your installation before the qNMR has arrived at the facility.

    To manage this, we must identify our critical path. This is the sequence of tasks that determines our final project deadline. If a task on the critical path is delayed, such as the floor reinforcement or the magnet ramping, the entire project timeline slips. We also need to map our human resources: do we have enough analysts to perform the method validation while still keeping up with the day-to-day release testing? Is IT and facility management committing enough resources to meet our timeline needs? Is QA aware of our project so that they can be ready to approve your quality documentation? By focusing on our critical path and resource availability, we ensure the project stays on track.

  • Risk management: To be a good project manager, we must proactively recognize risks for our project and plan for mitigating actions. The risks can be, for example technical risks (e.g., related to NMR performance or location), logistical risks (e.g., global shoratge of liquid helium, lead times for NMR tubes, delays in vendor timelines or lack of resources able to fully comit to the project). Risk management can be qualitative or quantitative in nature. Your aim as a project manager is to proactively reduce risks to an acceptable level and maximize any possible opportunities determined during your risk management planning.

  • Quality management: We need to identify all necessary quality requirements for our project. We begin with our URS, but it is our validation plan and IQ/OQ/PQ that will ensure how quality is actually managed with our project. We need to determine all the software data integrity requirements (21 CFR Part 11). We need to define and plan how we will verify the laboratory environment matches the vendor’s specifications, we need to ensure floor is stable, oxygen-depleing sensors are installed, computer and software is installed according to vendor’s protocol. We need to define the tests needed to ensure the system functions as intended. Finally, we need to plan the tests that actually prove the system an accurately measure the purity of our specific drug compound in our routine lab conditions we plan to use the system to measure.

Before moving to execution phase of our project, I want to empasize on the necessary of communication in projects with large impact. If our communication fails, we risk delays, safety hazards and major issues with compliance.

  • Communication management plan: We must ensure the right people get right information at the right time for our project. In our initiation phase, we have recognized all the major stakeholders in our project. We next have to define the best way to communicate progression, escalation needs, resource needs. You need to determine if regular team meetings are needed with your key resources. If your organization prefers communication by email, teams/zoom/slack, live, text message. With communication, you cannot be a good project manager if you stick to just what you prefer. You must keep your stakeholder needs in mind and how they prefer to communicate. Think it like this: if you know your head of QC is drowning with emails and does not have the time to read them, is an email really to best way to communicate with him to ensure alignment? Tailor your approach depending on your project and stakeholder preferences. It is worth the time.

Alright, so now we have defined all main details you have to take into account when planning your project. Let’s next move how to execute your plan.

Executing

In this phase, we are done with our planning, and now we focus on actually excecuting our project acccording to the plan. Our job now is to ensure our work, timeline and quality requirements match to our plan.

  • Directing and managing the project work: We oversee the installation of our qNMR system. We ensure vendors are working according to GMP requirements. We ensure the site is prepared sufficiently for the installation.

  • Conducting procurements and acquiring resources: We ensure budget is approved and qNMR delivery time is according to our project schedule. We secure the time for our internal laboratory staff, QA and technical departments to make sure they actually have the time to work on the project when their work is needed. We discuss these resource and timeline needs with the necessary stakeholders (e.g., direct supervisor, head of department).

  • Manage and develop your team: We focus on building the specialized know-how required for quantitative NMR. We organize vendor-led training sessions to ensure every analyst understands the complex pulse sequences and integration logic used for purity determination. We facilitate a mindset shift from traditional chromatography to qNMR by creating internal key users who can troubleshoot the new software and support the rest of the group during the transition.

  • Manage communication and engage stakeholders: We keep all laboratory personnel informed through regular status updates and safety briefings. We maintain constant alignment with the IT department regarding data integrity and work closely with QA to ensure our validation protocols meet their expectations before the final testing begins.

  • Manage risks: We execute the mitigation strategies defined in our planning phase whenever challenges arise. If the vendor informs us of a delay in equipment delivery, we initiate discussions with management to adjust the project timeline or add resources to make up for the lost time. We also manage technical risks in real-time, such as addressing environmental interference or software connectivity issues, to ensure the 600 MHz system remains on the path to successful GMP validation.

Next, let’s move into monitoring and controlling!

Monitoring and controlling

In reality, monitoring and controlling is performed in parallel with execution phase. We ensure our project stays within the boundaries of our original plan. We detect any deviations from the plan early and take corrective actions before they affect our project timeline.

  • Managing change, scope and validation: When following a predictive project management approach, we always follow a formal change control process to adjust our initial project managemement plan. For example, if our vendor proposes a new software update, we evaluate if it alighns with our URS: We actively control the scope of our project to ensure it doesn’t blow up (e.g., shift from 600 MHz NMR to 900 NMR when we have already approved the URS and approved our project deadline. This is why it’s essential to keep your stakeholders aligned: they must understand and approve our project scope, progress and deliverables. Beyond controlling changes, we perform scope validation. Scope validation involves getting formal, written sign-offs from stakeholders as we complete specific milestones, such as a formal approval for IQ tests after executing them. This ensures everyone agrees that a deliverable is truly complete and meets the requirements.

  • Tracking schedule, costs and performance: You and your team monitor the progression of our project phases against our planned timeline. We update our project schedule regularly to ensure any delays in one area do not impact the critical path or the overall project delivery deadline. We ensure our project costs remain within the approved budget by performing variance analysis. If we notice we are spending more on liquid helium or facility modifications than planned, we investigate the cause immediately. In case of escalation needs, we ensure we follow the formal change control process to maintain financial transparency.

  • Monitoring quality, resources and communication : We keep a close eye on the results of our quality activities, such as IQ, OQ, and PQ tests. We ensure method development and validation is progressing according to plan. When we notice any performance deviations, we document the findings and react by initiating discussions with the vendor or QA. We also monitor the use of physical resources and experts. If a project team member shares that they are swamped with work from another project, you take corrective action and discuss the conflict with their manager to ensure the project timeline does not slip. Additionally, we monitor our communications to ensure they are effective. It is not enough to just send an update; we verify that the stakeholders actually understand the technical risks and safety requirements related to the new magnet.

  • Monitoring risk and stakeholders: We keep a close eye on our risk response plans and continue to identify any new threats to the project, such as a sudden change in the regulatory landscape for drug purity testing. You ensure everyone remains aligned and informed of our project status through regular performance reports. We also ensure all contract terms with the vendors are met, especially regarding the delivery of validation documentation and technical support during the initial ramping of the magnet.

We have planned, executed and monitored and controlled our project effectively. Everything has executed perfectly after responding to any threats we faced during our project. The project is almost finished. Next we can move to closure.

Closure

The closing phase is the final step where we formally finish all project activities and transition the qNMR system to the laboratory for routine use. A project in a GMP environment is not complete until the paperwork is archived and the equipment is officially part of the lab’s daily use. Let’s look at all the steps we need to ensure the project is actually ready to be closed:

  • Project handover and final acceptance: We ensure that the laboratory department formally accepts the new system. This involves the final sign-off of the Validation Summary Report by the QA department, confirming the qNMR is fit for its intended purpose of drug purity testing. We also ensure that all Standard Operating Procedures (SOPs) are finalized and that the analytical method is ready for daily release testing.

  • Closing procurements and finances: We finalize all outstanding payments to the NMR vendor and any external contractors involved in the site preparation. We ensure that all contract terms have been met and that any warranties or service level agreements are officially active and handed over to the equipment owner. We close our project budget and report the final financial status to the project sponsor.

  • Releasing resources and team: We officially release our project team members back to their original departments and routine duties. We ensure that their managers are aware the project work is complete so they can be fully utilized elsewhere in the laboratory.

  • Lessons learned and archival: We gather the project team to document what went well and what challenges we faced during the installation and validation. For example, we might note if the helium delivery logistics were more complex than expected or if the software training required more time for the analysts, because the user interface wasn’t logical to use. We archive these lessons learned along with all project documentation, such as the charter and the project management plan, to ensure we have a complete record for future audits or upcoming laboratory investment projects.

Good job! Our project is now formally approved and closed. Next, let’s look into some tips and tricks on how to utilize Lean principles to tailor your project management approach.

Chapter 4. Lean (tailor) your approach

The example we showed in Chapter 3 largely followed a predictive approach. In reality, you should be tailoring your approach based on the needs of your project. If you are purchasing a laboratory system your personnel have already used before, the complexity and risk of the purchase is much less significant. For our qNMR project, the complexity was high due to the infrastructure needs and it being a new analytical technique.

For a complex project, it’s easy to create a WBS with 100–500 subtasks and an absurd amount of dependencies affecting your critical path. Always try to keep your project as simple as possible so that it's manageable. Remember, an exceptionally detailed project management plan does not bring value to your customer: the qNMR system approved for routine use does.

Below are my thoughts on how to utilize Lean principles to tailor your approach:

  • Simplify your plan by focusing on the Value Stream: Every activity in your project should add value to your customer. In a GMP laboratory, the customer is the person or department that needs the final analysis data (or even the doctor prescribing your drug or the actual patient using your drug). We should ask ourselves if every meeting or document directly supports the goal of getting the qNMR system into routine use. If an activity doesn't improve quality, safety, or the final delivery, we should consider it for removal. This helps you simplify your plan by focusing your tracking on high-risk areas like installation and validation protocols rather than over-complicating administrative tasks. If a project plan is too complex to read, it will likely be ignored. One example is project communication: if the communication plan of your organization is standardized, you could be using a dashboard with live project updates any of your project stakeholders can view at any time.

  • Use Systems Thinking to find the real bottlenecks: Lean is most effective when we view our project as one piece of a larger laboratory ecosystem. We must realize that the 600 MHz qNMR system interacts with our QC laboratory, our IT infrastructure, our LIMS system, our ERP system, and our final quality review process. Using systems thinking allows us to identify where the real bottlenecks are so we can make the entire laboratory flow more efficient. For example, if we only focus on the speed of the NMR acquisition but ignore the time it takes for QA or QC to review the complex new data, the overall lead time for our drug purity results will not improve even if the technique is faster than HPLC. Similarly, if your team responsible for method validation discovers that the actual validated GxP system does not possess sufficient accuracy and precision to pass your method validation performance characteristics, you have a disaster at hand.

  • Remove waste by standardizing your processes: To truly Lean your project, you should standardize your processes so the team doesn't have to rediscover how to manage a project from scratch every time new GxP system is purchased. This is where standardization becomes your best tool for simplification. If your department handles dozens of new equipment validations per year, collaborate with your QA department to create a standardized URS and IQ/OQ/PQ protocols based on your GAMP 5 classification. Standardizing these administrative parts of the project will save a huge amount of metawork and makes training new personnel much easier. Similarly, you could create standard project management plan templates. This will reduce waste and prevent you from having to create new approaches when someone has already done the work. Pro tip: Regularly review your lessons learned materials to find recurring bottlenecks.

  • Use a hybrid or adaptive approach: While laboratory GxP system projects often require a predictive approach for physical installation or the overrall timeline, we can be more adaptive in other areas. For example, our method development phase can be iterative. The same applies to the initial URS development when requirements aren’t yet fully defined. Even your validation activities can be completed using an Agile approach if you shift from testing every single requirement, as in traditional Computerized System Validation (CSV), to a more modern, risk-based Computerized Software Assurance (CSA) approach as recommended by GAMP 5, Revision 2. This allows you to focus your positive and negative validation testing on the high-risk requirements that actually impact product quality and patient safety. Testing of low-risk requirements can be drastically reduced or limited in scope, or you could simply rely on vendor expertise.

That’s it! Good job making it to the end. Hopefully, this article brought you some ideas on how to run your laboratory projects. In the future, I will be digging deeper into different project management techniques, such as how to create a Work Breakdown Structure, task tracking tips, and how to actually estimate the work needed to complete your projects.

Stay tuned!

Sources:

Project Management Institute (2025) A guide to the project management body of knowledge (PMBOK guide). 8th edn. Newtown Square, Pennsylvania: Project Management Institute.

Project Management Institute (2023) Process Groups: A Practice Guide. Newtown Square, PA: Project Management Institute.

Project Management Institute (2017) Agile Practice Guide. Newtown Square, PA: Project Management Institute.

ISPE (2022) GAMP 5 guide: a risk-based approach to compliant GxP computerized systems. 2nd edn. Tampa, FL: International Society for Pharmaceutical Engineering (ISPE).

FDA (2023) CFR - Code of Federal Regulations Title 21, Part 11: Electronic Records; Electronic Signatures. Silver Spring, MD: U.S. Food and Drug Administration. Available at: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=11 (Accessed: 15 March 2026).

FDA (2026) Computer software assurance for production and quality management system software: guidance for industry and Food and Drug Administration staff. Silver Spring, MD: U.S. Food and Drug Administration.

The visualizations in this article were generated using user prompts by Google Gemini (2026) based on the factual content in the article.

Previous
Previous

From CSV to CSA: Implementing Risk-Based Software Validation in Pharma & MedTech

Next
Next

Modern AI Tools for Laboratory Process Improvement: A Practical Guide