Writing a Validation
Project Plan as a
System Integrator

The SI Perspective on Project Planning Documents

Most articles about the Validation Plan are written from the client's perspective — the site owner, the validation lead, the QA team. They focus on what the document must contain for regulatory purposes. That is correct and necessary. But there is a second layer that matters equally to the SI: the VP and PQP are the project's governance framework, and every ambiguity in those documents will eventually become a scope dispute, a missed deliverable, or a phase gate that stalls because nobody agreed in writing who was responsible for the approval.

As an SI writing or co-authoring these documents, your goal is not just GMP compliance. It is contractual clarity dressed as GMP compliance. The RACI matrix, the deliverable register, the acceptance criteria, the phase gate conditions — all of these have direct commercial implications that go beyond their regulatory function.

Defining the SI Role in the RACI Matrix

The RACI matrix in the PQP is the most commercially significant section of the planning documents. It assigns Responsible, Accountable, Consulted, and Informed roles to each quality activity. As the SI, you need to read this with two questions: what are you being made Responsible for, and what are you being Accountable for?

Responsible means you do the work. Accountable means you sign it off. There can only be one Accountable person per activity. If the PQP assigns you as Accountable for the URS — meaning you sign the URS as its owner — you are taking on the liability that the URS correctly and completely captures the client's requirements. That is a significant assumption if the requirements were provided by the client and you are simply writing them down. Accountable for the FDS and HDS is appropriate for an SI — those are your engineering documents. Accountable for the URS typically belongs to the System Owner on the client side, with the SI as Responsible (author).

Scoping the System Boundary Precisely

The most contractually important section of the VP is the system boundary — the explicit in-scope / out-of-scope table. Everything that is not listed as in scope is out of scope. This is not pedantry; it is the only mechanism an SI has to manage scope creep on a validated project without triggering a change control argument mid-project.

Common scope ambiguities that should be resolved in the VP boundary section include: whether site infrastructure (network switches, UPS, server hardware) is in the SI's scope or the client's IT team's scope; whether calibration of field instruments is the SI's responsibility or the site's metrology function; whether the HMI operating system hardening and patch baseline is within the SI's scope; and whether the PQ study is executed by the SI or handed over to the site's validation team after OQ approval.

Each of these ambiguities, left undefined, will surface as a dispute at the phase gate where the relevant activity is supposed to happen. Define them explicitly in the VP as In Scope or Out of Scope, with a brief note on who is responsible for out-of-scope items. Getting the client's QA lead to countersign the VP section that contains this boundary table is the cleanest way to eliminate future arguments.

Writing the Deliverable Register to Protect Scope

The deliverable register in the VP lists every document that will be produced, who authors it, who approves it, and the target completion date. For an SI, the document authorship column is particularly important. If you are listed as author for a document, you are committing to produce it. If you are listed as author for a document that you expected the client to produce — a site SOP, for example, or a PQ report — that commitment is now yours and the client knows it.

The standard deliverable split on a typical SI-delivered project looks like this: the SI authors the VP, PQP, FDS, HDS, SDS, FAT protocol, FAT report, and SAT protocol. The Validation Lead (client side) authors the URS, Risk Assessment, and Traceability Matrix — with SI review. IQ, OQ, and PQ protocols may be authored by either party depending on the contract, but the authoring responsibility should be explicit in the deliverable register, not assumed.

For each document in the deliverable register, include a target completion date and a named approver. Leaving the approver column blank is a common mistake — a document with no named approver can sit in review indefinitely with no accountability. The approver should be a named individual or a role, and the review cycle duration should be specified (typically ten to fifteen working days for GMP-controlled documents).

Acceptance Criteria — Writing Them From the SI Lens

The acceptance criteria section of the VP defines the conditions under which the system can be declared validated. These criteria should be measurable, specific, and agreed before testing begins. From the SI's perspective, the acceptance criteria are also the conditions under which your contract obligations are complete.

Standard acceptance criteria for an SI-delivered pharma project include: FAT test case pass rate of 98% or greater; zero open Category A deviations at FAT sign-off; IQ completed with all installation verification items passed; OQ test case pass rate of 98% or greater with all data integrity and alarm test cases passed; PQ study period completed with no unexplained data gaps exceeding five minutes; and Validation Summary Report approved by QA with all deviations formally closed.

The criteria should not be written in a way that creates an open-ended obligation. "System performs to client satisfaction" is not an acceptance criterion — it is an invitation for scope creep. "OQ test case pass rate ≥98% with zero open Critical deviations at time of OQ report approval" is an acceptance criterion that both parties can objectively verify.

The Supplier Assessment as Part of the Planning Package

On pharma projects where the client's QA team is thorough, the SI will be required to complete a Supplier Assessment Questionnaire before the project formally begins. This questionnaire — typically the SAQ — asks about the SI's GMP experience, quality management system, document control procedures, training records, and validation methodology. The SAR (Supplier Assessment Report) documents the client's evaluation of the SI's responses.

From the SI's perspective, the supplier assessment is an opportunity, not a compliance burden. A well-prepared SAQ response — citing prior pharma projects, describing the template-based documentation approach, referencing GAMP 5 alignment — establishes credibility with the QA team before the first document is submitted. An SI who cannot demonstrate a consistent, repeatable validation methodology in their SAQ will face more scrutiny on every subsequent document submission.

The planning phase is also the correct time to raise any qualification gaps on the SI side. If your team has limited PQ experience or has not previously executed an OQ on the specific control platform being used, saying so in the planning phase — and proposing how the gap will be addressed — is far preferable to having it surface during OQ execution when QA discovers it as a deviation.

Keeping the Plans Alive During Execution

The VP and PQP are living documents for the duration of the project. If scope changes — a requirement is added, a deliverable is reassigned, the PQ duration is extended — the change should be formally recorded as a change control against the VP, not absorbed informally. An approved VP that does not match what actually happened on the project is an audit finding. A VP that has been formally updated via change control to reflect what actually happened is a well-managed project.

Practically, this means reviewing the VP and PQP at each phase gate — not just at the start. The phase gate review is the natural moment to confirm that the plans still accurately reflect the project as it is, not as it was planned. Any discrepancy should trigger either a change control (if the change was intentional) or a deviation (if something went wrong that was not planned).