Realistic Timelines
for Pharma Validation
Projects

Why Pharma Validation Projects Run Late

The root cause of timeline overruns on pharma validation projects is almost never the engineering. It is the document approval cycle — and specifically the failure to budget for it correctly at the start. Most SI project plans show engineering tasks with realistic durations and document production tasks with realistic durations. What they systematically underestimate is the time between a document being submitted and a document being approved.

A URS that takes three days to write can take three weeks to approve if the client's QA team has a two-week review cycle, sends back comments, requires a formal response, and then takes another week to countersign. Multiply this across the ten or more controlled documents in a full validation package, and you have a project that is running to schedule on engineering hours but slipping by weeks on calendar time.

The Eight Phases and Their Real Durations

The GAMP 5 Validation Plan structures a project into eight formal phases, from planning through to GMP lifecycle. Each phase has a phase-gate — a set of conditions that must be met before the next phase begins. Understanding what creates delay at each gate is the foundation of a realistic schedule.

Phase 1 — Planning: The Invisible Start-Up Cost

The planning phase — producing the Validation Plan, Project Quality Plan, Risk Management Plan, and Supplier Assessment — is consistently underestimated because it feels like overhead rather than engineering. In reality, this phase establishes every subsequent project constraint. A VP that defines the wrong system boundary, or a PQP that commits to an approval cycle that does not match the client's actual QA process, will cause problems at every subsequent phase gate.

Allow two to three weeks for planning documents to be produced and approved. If this is the team's first project with this client, add one to two weeks for the client's QA team to review the VP and understand what they are signing — particularly if they have never worked with an external SI on a validated project before.

Phase 2 — Specification: The Longest Phase and the Most Variable

The specification phase — URS, FDS, HDS, SDS, Risk Assessment, and Traceability Matrix — runs in parallel with engineering design and build. This is where timeline assumptions most commonly fail. The engineering tasks (PLC build, SCADA configuration, panel design) are visible and trackable. The document production and approval tasks are invisible and slow.

A realistic specification phase for a mid-size system is six to eight weeks from kickoff to approved design documents. The variables are: how mature the client's requirements are when the project starts, how quickly the client's QA team reviews documents, and whether the URS goes through one round of comments or three. On first-time pharma clients, three rounds of URS comments is not unusual — they often don't know what they need from a URS until they see what they asked for.

The practical mitigation is to submit the URS first, early, and explicitly request a two-week review cycle with a structured comment-response format. Establish upfront whether the client has a standard comment resolution format (many sites do) or whether comments will arrive as tracked changes in the document (which creates version control confusion). Both are manageable if agreed in advance; neither is manageable if discovered at the first review cycle.

FAT and SAT — Where Slippage Becomes Visible

The Factory Acceptance Test is the first point in the project where the client is physically present for an extended period. This is also where accumulated engineering slippage from the specification phase becomes apparent. Systems that were nominally complete on paper but required a week of remediation work after QA comments often arrive at FAT with outstanding issues — and outstanding issues at FAT are deviations.

The FAT protocol must be approved before the FAT starts. If the protocol was submitted for approval during the specification phase (best practice) and approved before FAT week, FAT can begin immediately. If the protocol is still under QA review on FAT week — which happens when document production was delayed — FAT cannot legally begin. This single dependency can push a FAT by one to two weeks with no engineering input required.

The Site Acceptance Test that follows FAT is shorter but has the same dependency: the SAT protocol must be approved before execution. Budget one week for SAT execution on a typical system. Budget an additional week for the SAT report to be reviewed and approved before IQ can start.

IQ and OQ — The Sequential Dependency Chain

IQ cannot begin until SAT is approved. OQ cannot begin until IQ is approved. Each approval typically takes one to two weeks on the client side. This creates a mandatory minimum calendar gap between the end of SAT execution and the start of OQ execution — even if there are zero deviations and engineering is standing by ready to proceed.

For a standard IQ with no deviations: two to three days of execution, one week for the IQ report to be written and submitted, one to two weeks for QA approval. That is three to four weeks from the last day of IQ execution to the first day of OQ execution — calendar time that cannot be compressed regardless of how efficient the SI is.

OQ execution is the longest on-site phase. A comprehensive OQ for a mid-size PLC/SCADA system — covering all functional requirements, alarm testing, data integrity verification, user management, and report testing — takes three to five days of on-site execution. Deviations found during OQ require real-time logging in the MDL, root cause assessment, and formal retesting before OQ can be signed off. Budget one week of post-execution time for OQ report production and QA review before PQ can start.

PQ — The Phase That Cannot Be Rushed

Performance Qualification runs under real production conditions for a defined study period — typically two to four weeks of continuous operation, or a defined number of batches. This duration is set in the Validation Plan and cannot be shortened without a formal change control and QA approval. No amount of commercial pressure from a client who wants the system to go live faster changes the PQ study period.

The practical implication is that PQ sets a hard minimum on the total project duration. If a system has a four-week PQ study period, the earliest possible GMP release is four weeks after PQ start — regardless of how everything else went. Build the PQ study period into the project timeline at the start, and manage client expectations accordingly.

Building a Realistic Project Schedule

A realistic schedule for a mid-size PLC/SCADA pharma project (50–150 I/O points, Category 4/5 software, standard IQ/OQ/PQ lifecycle) runs to approximately 22–26 weeks from kickoff to GMP release under normal conditions. Complex systems, multiple suppliers, or first-time pharma clients add four to eight weeks. The breakdown of that calendar time looks like this:

Managing Client Expectations on Timeline

The most damaging timeline conversation in a pharma project is the one that does not happen at the start. When a client asks "how long will this take?" and the SI gives an optimistic answer to win the contract, every subsequent delay is experienced as a failure rather than as a realistic project outcome. The client who was told four months and received seven has a worse perception of the SI than the client who was told six months and received seven — even though the actual delivery was identical.

Present the realistic timeline at kickoff, explain the phase-gate structure, and explicitly name the approval cycle buffers as a client-side constraint. Frame it as information the client needs to manage their own internal planning — production scheduling, site validation resources, QA workload — rather than as a negotiating position. A client who understands why the timeline is what it is will manage schedule slippage far more constructively than one who was given false confidence at the start.