The Quality and IT Handoff That Causes Most Validation Delays

Where the Schedule Actually Goes

Ask a validation lead why a system went live eleven weeks late and you will usually get a list of events: an integration defect, a vendor patch, a resource that moved to another project, a round of rework on the test scripts. Each item is true. None of them explains eleven weeks.

The explanation shows up when you stop counting events and start counting calendar. Take any validation project that ran long and mark every day on the schedule as either working time or waiting time. Working time is a person doing the task. Waiting time is a task sitting complete but unaccepted, a decision pending, a document in someone’s queue, a question asked on Tuesday and answered the following Monday. In most projects that overran, working time was roughly what was estimated. Waiting time is where the eleven weeks went, and almost all of it accumulated at points where work crossed from IT to quality or back.

This is not a pharma-specific finding, though pharma has more of these crossings than most industries. A 2002 study by the National Institute of Standards and Technology estimated that inadequate software testing infrastructure was costing the US economy about $59.5 billion a year, and that roughly a third of that could be removed by finding faults earlier in the development process rather than later.¹² The finding that matters here is not the dollar figure, which is old and economy-wide. It is the mechanism: a fault found at requirements review is a conversation, and the same fault found during formal test execution is a documented deviation, an investigation, a possible protocol change, and a re-execution.

Capital project data points in the same direction. Writing in ISPE’s Pharmaceutical Engineering, practitioners describe commissioning and qualification as the activity that most often becomes the critical path on large projects, and report that moving from paper-based sequential review to digital tools has produced schedule gains in the range of 40 to 70 percent on content delivery, with commissioning and qualification typically running at 5 to 10 percent of direct project spend.¹⁰ Read that carefully. The gain came from removing the constraint that only one reviewer can hold a document at a time. The testing did not get easier. The queue got shorter.

The diagnostic question worth asking

Before you redesign anything, run one exercise on your last completed validation. Take the project plan, take the actual dates, and for every task that finished late, write down a single word: was it slow or was it stuck? Slow means the work took longer than planned. Stuck means the work was done and something outside the task was waiting on a person or a decision.

In our experience with pharma and biotech clients, the ratio surprises leaders every time. The tasks that were genuinely slow are usually testing execution and data migration. Everything else is stuck, and stuck is almost always a handoff. That is good news, because slow requires more people and stuck requires an agreement.

What the Regulations Do and Do Not Say About Roles

It is worth being precise here, because both groups tend to invoke the regulations during these disputes and neither is usually quoting them accurately.

What is actually required

EU GMP Annex 11 requires close cooperation between the relevant people, naming the process owner, the system owner, Qualified Persons and IT, and requires that all personnel have appropriate qualifications, level of access and defined responsibilities for their assigned duties.¹ That is the whole of the personnel clause. It requires that responsibilities exist and are defined. It does not say who writes the user requirements.

Annex 11 also contains a clause that most organizations read past. When third parties are used to provide, install, configure, integrate, validate, maintain, modify or retain a computerized system, formal agreements must exist and must include clear statements of the third party’s responsibilities. The clause then adds that IT departments should be considered analogous.¹ The regulator is telling you to define the interface with your own IT department with the same clarity you would use for an outside supplier. Very few organizations do.

Annex 15 is equally direct and equally undirective about structure. It requires that qualification and validation activities be planned and performed by suitably trained personnel following approved procedures, and it explicitly permits validation personnel to report somewhere other than a quality management or quality assurance function, provided there is appropriate quality oversight across the whole validation lifecycle.³ It requires the validation master plan to include the organizational structure with roles and responsibilities for qualification and validation activities.³ Again: define it, document it, follow it. The content is yours.

ICH Q9(R1) is the closest any of them comes to describing how the work should be organized. It states that quality risk management activities are usually undertaken by interdisciplinary teams including experts from the appropriate areas, and it gives decision makers three specific duties: take responsibility for coordinating quality risk management across functions and departments, make sure the process is defined, deployed and reviewed with adequate resources and knowledge available, and make sure that subjectivity in risk management activities is managed and minimized so that risk-based decisions are scientifically sound.⁴ The 2023 revision added the subjectivity material and a full section on managing it, which is new relative to the original Q9.⁵⁶

GAMP 5 Second Edition adds the practical counterpart, introducing critical thinking as a named concept and pressing regulated companies to use supplier knowledge, experience and documentation rather than duplicating work the supplier has already done and documented.⁷ ISPE’s more recent guidance on digital validation makes the same point about method rather than paperwork.⁸

The gap this leaves

So the regulations require a defined operating model and leave its design to you. In most organizations that design was never made. It accreted. Each project negotiates the interface again with whoever is in the room, and the negotiation happens under schedule pressure, at the exact moment when the two groups have the least patience for it.

The rest of this article is about closing that gap deliberately, one handoff at a time.

Handoff One: Requirement Ownership

The failure pattern

A requirement is written. Weeks later, during test script development or test execution, someone discovers the requirement cannot be tested as written. It says the system shall handle exceptions appropriately, or shall provide adequate reporting, or shall support the batch release process. Each of those is a real sentence that has appeared in a real user requirements specification and passed formal approval.

Now the argument starts, and it has a predictable shape. Quality says the requirement is ambiguous and cannot be verified. IT says the requirement was approved by the business and by quality, and the system does what the business asked for. The business owner, who wrote a version of the sentence eight months ago, does not remember what was meant. Everyone is technically right, and three weeks disappear.

The second version of this failure is the opposite problem. The specification is enormous, running to hundreds of statements that mix procurement details, vendor selection criteria, nice-to-have features and genuine quality requirements in one undifferentiated list. Practitioners describing commissioning and qualification breakdowns call this out directly as one of the three places projects lose control, alongside change management failures during commissioning and vendor quality gaps that force duplicate testing.¹¹ An oversized specification is not a safe specification. It is a specification where the twelve statements that actually matter are hidden among four hundred that do not, and the testing effort gets spread evenly across all of them.

Regulators see this too. In a published account of computer system validation deficiencies, an MHRA inspector described an organization that could only produce draft versions of its user requirements and functional specifications, with no final locked-down documentation, which made it impossible to confirm what had actually been built and validated. In the same account, only one of four functions the company itself had called business critical had a test script at all.¹³

The fix

Requirement ownership needs three decisions made once, at the organization level, not per project.

Decide who is accountable, and make it one person. The accountable party for the user requirements specification is the process owner: the person who owns the business process the system will run. Not IT, not quality, not the vendor. IT contributes technical, interface, performance and security requirements. Quality contributes GMP and data integrity requirements and reviews the whole. The vendor may supply a draft. But one name approves it and answers for it. The draft revision of Annex 11 is unusually explicit on this point for a purchased or software-as-a-service system: the vendor may provide the requirements specification, but the regulated user should review it, decide whether the system meets GMP and company processes as delivered or needs configuration, take ownership of the document covering the implemented version, and formally approve and control it.²

Publish a requirement quality standard and enforce it at a gate. One page, written once. Then hold a requirements acceptance review before design work starts, where quality and the validation lead check requirements against the standard and reject the ones that fail. The reject step is the whole point. A review that accepts everything is a meeting, not a gate.

Keep requirements alive. The draft Annex 11 revision states that requirements should be updated and maintained across the system lifecycle so they continue to describe the system accurately as it changes, and that the updated requirements form the basis for qualification and validation.² The current Annex 11 already requires that user requirements be traceable throughout the lifecycle and based on documented risk assessment and GMP impact.¹ A requirements document that was accurate at approval and stale at go-live is a finding waiting to happen, and it is also the reason the next project starts by rewriting requirements from scratch.

Handoff Two: The Risk Assessment Nobody Wants to Own

The failure pattern

This one is less visible than the others, and more expensive, because its effects show up two months later as testing scope rather than as an argument.

The system risk assessment needs two kinds of knowledge. It needs process knowledge: what happens to the product, the patient or the record if this function behaves incorrectly, and would anyone notice. And it needs system knowledge: how likely is this function to behave incorrectly, what does the software actually do under the covers, what controls already exist in the platform, and what would detect a failure.

IT has the second kind and not the first. Quality has the first kind and not the second. So the assessment gets assigned to whoever has capacity, which is usually the validation lead or a contractor, and that person produces a document by inference. The result is one of two things. Either everything is rated high, because nobody in the room felt able to argue a rating down and being wrong in the conservative direction feels safe, or the ratings are inherited wholesale from a template used on a different system.

Both outcomes are expensive. A risk assessment that rates everything high does not reduce testing scope anywhere, which was the entire reason for doing it. A risk assessment inherited from a template does not reflect this system, which means the scope is wrong in both directions: over-testing functions that do not matter and under-testing the two that do.

The fix

Split the assessment along the line where the knowledge actually divides, and put a facilitator in charge of the session rather than the document.

One practical note on scheduling. The joint risk session must happen after requirements are approved and before test planning starts. Organizations that run it late, in parallel with test script writing, get a risk assessment that ratifies decisions already made. That is not risk management. It is documentation.

Handoff Three: Test Evidence Format

The failure pattern

A tester executes forty test steps and captures forty screen images. Quality reviews the executed script and rejects a third of them. The images do not show the system clock. The user name is cut off. Two show a different environment. One is legible but the record it shows was created by a different tester whose name appears nowhere in the script. The rework is not intellectually difficult. It is a person re-executing tests that already passed, for a week, because nobody agreed the format in advance.

This handoff is entirely self-inflicted, which is why it is the easiest of the six to fix and the most common to find unfixed. The evidence standard is knowable before the first test runs. It is almost never written down before the first test runs.

The regulatory position is less prescriptive than most companies assume. The current Annex 11 says only that evidence of appropriate test methods and test scenarios should be demonstrated, with particular attention to system and process parameter limits, data limits and error handling, and that automated testing tools and test environments should have documented assessments of their adequacy.¹ The draft revision goes further and is worth reading closely on this point: it expects qualification and validation to provide evidence in the form of executed test scripts and, where relevant, screen captures, that requirements and derived functional specifications are met.² The qualifier “where relevant” is doing real work in that sentence. The draft also says test cases must be traceable to individual requirements or specifications, and that test cases which do not trace to a requirement do not satisfy the qualification and validation expectation at all.²

GAMP 5 Second Edition pushes in the same direction, asking teams to think critically about what evidence a given risk level actually warrants rather than applying one rule to everything.⁷ For readers whose organizations also make devices, FDA’s final guidance on computer software assurance takes a comparable risk-based position on assurance activities and records for production and quality system software, though its scope is medical device production and the quality management system rather than drug GMP.¹⁴

The fix

Write a one-page evidence standard, agree it between IT and quality before test execution begins, and attach it to the validation plan. It should answer six questions and no more.

Handoff Four: Deviation Handling During Testing

The failure pattern

This is the single biggest schedule risk on the list, and it is worth being blunt about why. When a test fails, the project does not slow down. It stops.

The failed step blocks the steps that depend on it. The tester moves to another script or waits. And meanwhile three groups begin a discussion that can run for days: IT says the test script is wrong and the system behaves as designed; quality says the system behaves incorrectly and it is a defect; the vendor says the configuration is wrong; and somebody eventually raises the possibility that the requirement itself was misunderstood, which is the answer that nobody wants because it reaches back into approved documents.

The discussion is not unreasonable. All four explanations are genuinely possible, and they lead to completely different work. What is unreasonable is that most organizations have no rule for how the question gets settled or by when. The default is that it gets settled when the three people involved happen to be in the same meeting, which on a typical project calendar is once a week.

Multiply that by the number of test failures on a real project and you have your eleven weeks.

What the regulations expect here

Annex 15 requires that results failing to meet predefined acceptance criteria be recorded as a deviation and fully investigated according to local procedures, with any implications for the validation discussed in the report, and that significant changes to an approved protocol during execution, such as acceptance criteria or operating parameters, be documented as a deviation and scientifically justified.³ Annex 11 requires validation documentation to include reports on deviations observed during validation.¹

Both Annex 15 and the draft Annex 11 revision also permit conditional approval to move to the next stage, or to take a system into use, where certain acceptance criteria have not been met or deviations are not fully addressed, provided there is a documented assessment that the deficiency will not affect product quality, patient safety or data integrity. The draft adds that conditional approval must be stated explicitly in the validation report with close follow-up on the outstanding actions.²³

That conditional path exists precisely so a project does not have to halt for a low-impact issue. Many organizations never use it because no one has the authority to make the call in the moment, so it gets escalated, and escalation is slower than fixing the problem would have been.

The fix: a triage rule that produces a same-day decision

The goal is not to resolve every failure the same day. The goal is to classify every failure the same day, because classification determines who owns the next step, and an unowned failure is what actually consumes the week.

Three rules make this work in practice, and all three are about time rather than technique.

Log within two hours, not at the end of the day. A failure raised at 4:45pm is a failure that gets classified tomorrow. A short entry logged at the moment of failure, with the script identifier, the step, what was expected, what happened, and the screen state, is enough to start triage.

A standing triage slot every working day during execution, fifteen minutes, three named people. The validation lead, the IT system owner and a quality reviewer, each with a named delegate. It runs only when there is something to triage, and it is cancelled the moment execution ends. This is the only meeting on the list that needs to be daily, and only for the weeks it is needed.

Classification is a decision, not a consensus. If the three cannot agree within the fifteen minutes, the validation lead classifies provisionally and the disagreement goes to the exception forum described later, with a 24-hour resolution commitment. Provisional classification keeps work moving. Waiting for agreement does not.

Handoff Five: Approval Routing and the One-Person Queue

The failure pattern

Every validation deliverable needs approval, and in most organizations approval is sequential. The document goes to reviewer one, then reviewer two, then quality, then the process owner, then the system owner. Each step is a day of actual reading and four days of queue. Five approvers, twenty-five calendar days, five days of work.

Then there is the specific version of this problem, which almost every mid-size pharma and biotech organization has: one person in quality who reviews everything. They are experienced, they are careful, they are good at it, and they are also on three other projects and in the plant two days a week. The queue is not a process problem. It is a person, and everyone knows it, and nobody says it out loud because the person is doing their best.

The commissioning and qualification work reported in Pharmaceutical Engineering makes the mechanism explicit. Paper routing allows only one reviewer to hold a document at a time, so reviews are inherently sequential, and the recorded gains from moving away from that came substantially from parallel review and immediate notification rather than from any change in what was being reviewed.¹⁰

The fix

• Separate review from approval. Review is parallel and time-boxed. All reviewers get the document at once with a stated window, typically five working days for a protocol and three for an executed script. Approval is sequential and short, because by then the comments are resolved.
• Every approver has a named delegate with equivalent authority, and the delegate is trained and current. A delegate who exists on paper but has never approved anything is not a delegate. Rotate real work through them.
• Publish a decision rights list. For each decision type, one name. Who approves the validation plan. Who approves a test script change during execution. Who authorizes conditional approval. Who accepts a vendor deliverable. Most approval queues are long because people are approving things they were never required to approve, added to the routing years ago and never removed.
• Batch executed evidence review during execution, not after. Reviewing scripts in tranches as they complete spreads the quality effort across the execution window instead of concentrating it in the two weeks when the project is already late.
• Report queue age, not queue depth. Twelve documents awaiting review tells you nothing. The oldest of them being fourteen days old tells you exactly where the project is stuck, and it is a number a leader can act on the day they see it.

Handoff Six: The Vendor in the Middle

The failure pattern

The vendor supplies a package: a functional specification, a qualification protocol set, test results from their own environment, release notes, and possibly a certificate or an audit report. Both IT and quality see it arrive. IT assumes quality is reviewing it for compliance. Quality assumes IT is reviewing it for technical accuracy. Neither reads it fully, and the package proceeds into the validation file on the strength of a signature that means “received.”

The failure appears late and it appears badly. During an inspection or an internal audit, someone asks what the vendor’s test coverage actually included, or which version the protocols were executed against, or where the evidence is for a function the company classified as critical. In the MHRA account cited earlier, the validation report referred to versions of the functional specification that were not available, which made it impossible to confirm that the specified functionality had been captured or validated at all, and the inspector’s summary of accountability was unambiguous: even when a vendor develops the software, the sponsor remains responsible.¹³

The regulatory position is consistent across every document referenced in this article. Annex 11 requires that documentation supplied with commercial off-the-shelf products be reviewed by regulated users to check that user requirements are fulfilled, and that the regulated user take all reasonable steps to confirm the system was developed under an appropriate quality management system, with the supplier assessed appropriately.¹ Annex 15 requires that where protocols and other documentation come from a third party providing validation services, appropriate site personnel confirm suitability and compliance with internal procedures before approval, and notes that vendor protocols may need to be supplemented.³ The draft Annex 11 revision states plainly that relying on a vendor, a service provider or an internal IT department does not change the requirements, that the regulated user remains fully responsible, and that qualification documentation provided by any of them must be carefully reviewed and authorized by the regulated user, who should consider whether it covers the implemented version and supports GMP and company processes as delivered.²

The fix

Treat every vendor deliverable as a project task with an owner, a due date and an acceptance criterion, the same as any deliverable your own team produces. Three specifics:

Name a reviewer per deliverable, not per vendor. “IT owns the vendor relationship” is not a review assignment. The functional specification goes to a named person. The vendor’s test results go to a named person. Both names go on the project plan with dates, before the deliverables arrive.

Use a short acceptance checklist. Does this cover the version we are implementing? Does it cover our configuration or the vendor’s standard configuration? Which of our requirements does it verify, mapped by identifier? What did the vendor test that we can therefore reduce, and what did they not test that we must therefore cover ourselves? What is missing that we need to request now rather than in week ten?

Record the reliance decision. A single documented statement, per deliverable, of what you are relying on the vendor for and why that reliance is justified. This takes fifteen minutes at the time and is the difference between a defensible risk-based approach and an undocumented assumption when an inspector asks why a function was not tested.

A RACI for the Validation Lifecycle

Here is the artifact. Adapt the role names to your organization, but keep the discipline: exactly one A per row, and A means the person who answers for the outcome, not the person who does the work.

Roles used below: PO process owner (business), SO system owner (IT), VL validation lead, QA quality assurance, ITO IT operations and infrastructure, VEN vendor or service provider. R is responsible for doing it, A is accountable, C is consulted, I is informed.

Three notes on using this without it becoming wallpaper

Note the two rows where accountability splits the risk assessment. That is deliberate and it is the most important design decision in the table. Severity is a process judgment and the process owner answers for it. Probability and detectability are system judgments and the system owner answers for them. Splitting accountability across two rows rather than assigning one owner to a single combined row is what stops the assessment being done by inference.

Note that quality is accountable for the release decision but responsible for very little execution. This matches Annex 15, which allows validation personnel to report outside the quality function as long as appropriate quality oversight covers the whole validation lifecycle.³ Oversight and execution are different jobs. Organizations where quality executes the validation work tend to have quality queues, and organizations where quality has no oversight role tend to have findings.

Fill in real names before the project starts, and publish the delegate for each. A RACI with role titles is a policy document. A RACI with names and delegates is an operating tool. The version that gets used has names on it.

A Meeting Cadence That Resolves Things

Most validation projects are over-meetinged and under-decided. The core team meets weekly to hear status that everyone already knows, and the decisions that would move the project wait for a steering committee that meets monthly. Reverse that. Status can be read. Decisions need people.

What makes a cadence work

Two rules matter more than the schedule itself.

Every forum has a stated decision it is allowed to make, and forums that only receive information are cancelled. If a meeting cannot name a decision type it owns, its content belongs in a written update. This is not about saving time in meetings, though it does that. It is about making sure that when a decision is needed, everyone knows which room it belongs in and how fast that room turns around.

Exception forums must have a response commitment, not a schedule. A monthly forum for exceptions is not an exception mechanism, it is a delay mechanism with a calendar invitation. The value is entirely in the 24 hours.

For the Leader Who Owns Both Groups

If IT and quality both report to you, whether as a chief information officer with quality systems in scope, a site head, a head of technical operations or a VP with a combined remit, there are five things only you can do. Nobody a level below you can do any of them, which is why they usually go undone.

One: set the decision rights and publish them. Not the process. The decision rights. Who classifies a test failure, who authorizes conditional approval, who accepts a vendor deliverable, who can change an approved requirement. This is a half-day of work and it removes the largest single source of delay, which is not disagreement about the answer but uncertainty about who gets to give it. ICH Q9(R1) puts coordinating risk management across functions and departments squarely on decision makers, along with making sure the process is defined and resourced.⁴ That is a description of your job, not the validation lead’s.

Two: fund a validation lead who belongs to the project, not to a function. The role in the RACI above that carries the most R entries is the validation lead, and in many organizations that role is a part-time assignment given to whoever has capacity. A dedicated lead with a foot in both camps is the cheapest structural fix available, and the effort is recovered on the first project that does not run eleven weeks long.

Three: refuse to arbitrate individual test failures. This is the hardest one, because you can settle any given dispute in five minutes and it feels productive. But every time you do, you confirm that escalation to you is the resolution mechanism, and the triage forum stays weak. Send it back, and ask why the triage rule did not settle it. If the answer is a genuine gap in the rule, fix the rule.

Four: stop measuring the two groups on metrics that conflict. If IT is measured on go-live dates and quality is measured on findings and audit outcomes, you have designed the argument into the structure and then asked the people in it to behave collaboratively. Give both groups the same top-line measure: validated and in use, on the agreed date, with no open high-impact deviations. Then keep the function-specific measures underneath that, where they belong.

Five: measure the interface, not the functions. Four numbers, reported on every project, tell you whether the handoffs are working.

None of these four are compliance measures and none belong in a quality management review. They belong in your project review, and they should be the first slide rather than the last.

What Changes With Vendor-Hosted SaaS

Everything above applies to a vendor-hosted software as a service system, but four things change materially, and the handoffs that were awkward on an on-premises system can become structural on a hosted one.

You do not own the release calendar

The vendor updates the platform on their schedule, sometimes with limited notice and sometimes without an option to defer. This turns change control from a project activity into a standing operational one, and it moves the IT and quality handoff from something you do once during implementation to something you do several times a year forever. The organizations that struggle are the ones that designed the interface for a one-time project. Agree in advance who assesses a vendor release note, within what window, against what criteria, and who decides regression scope. Environment strategy is closely tied to this and is covered separately in this series.

Requirements ownership becomes a conscious act

When the vendor supplies the requirements specification, the path of least resistance is to accept it. The draft Annex 11 revision addresses this directly, expecting the regulated user to review and approve the vendor’s document, decide whether the system meets GMP and company processes as delivered or needs configuration, and take ownership of the document covering the implemented version.² The practical translation: your requirements document describes your configured tenant, not the vendor’s product. Those are different documents and only one of them is yours.

Your internal IT department is treated the same way as the service provider

This is the point in the draft revision that most repays reading if you own both groups. The draft states that relying on a vendor, a service provider or an internal IT department does not change the requirements and that the regulated user remains fully responsible. It expects effective oversight against agreed service levels and performance measures, documentation that is accessible and can be explained from your own facility, and, where an internal IT department performs the work, approved procedures covering what activities and documentation are provided, which company procedures and regulatory requirements apply, and how regular, ad hoc and incident communication happens.² The current Annex 11 already says IT departments should be considered analogous to third parties in this respect.¹

Read as an operating instruction rather than a compliance clause, that is the regulator telling you to write down the internal IT and quality interface with the same clarity you would use in a vendor contract. Which is, more or less, the entire argument of this article.

Qualification evidence shifts from producing to assessing

On a hosted system, much of the infrastructure qualification evidence exists already and belongs to someone else. The work moves from executing tests to assessing what the provider has done, deciding what you can rely on, and testing your configuration and your GMP-critical functions. The draft revision is clear that qualification and validation documentation may come from a service provider, a vendor or an internal IT department in whole or in part, but that the regulated user is fully accountable and must review and authorize its use, considering whether it covers the implemented version.² GAMP 5 Second Edition and ISPE’s digital validation guidance both support the same approach.⁷⁸ Selecting the vendor in the first place, and comparing a quality management suite module against a specialist tool, is its own decision and is treated separately in this series.

Conclusion

The six handoffs in this article are not a comprehensive list of everything that can go wrong on a validation project. They are the ones that recur, that account for most of the lost calendar, and that are fixable with agreements rather than with headcount or technology. What they have in common is that each one is a place where work crosses between two groups that answer to different measures, use different vocabulary, and hold different pieces of the knowledge required to make the decision. The regulations require that responsibilities be defined and that quality oversight exist. They deliberately leave the design to you, and in most organizations that design was never made on purpose.

The practical path forward is smaller than it looks. Publish the decision rights. Agree the evidence standard before testing starts rather than during it. Put a daily fifteen-minute triage in place for the weeks that testing runs, and hold the line that classification is a decision rather than a consensus. Name a reviewer for every vendor deliverable and record the reliance decision. Fill in the RACI with real names and real delegates. None of that requires a new system, a new procedure suite or a transformation program. It requires one leader to decide these things once, so that no project has to negotiate them again under schedule pressure.

Sakara Digital works with pharma and biotech organizations designing this kind of operating model between quality and IT, usually alongside a live validation project rather than as a separate exercise. If you are heading into a system implementation and want an independent read on where your handoffs will slow you down, or you have just finished one that ran long and want to understand why, we are happy to have that conversation.

For Further Reading