How to sequence a validation timeline: protocols, execution and deviations
Sequence validation work on a Gantt chart: approve the plan before execution, write test scripts beside the build, allow for deviations and retests, and gate release on an approved report.
A validation timeline is mostly a question of order: what must be approved before testing starts, what can be written while the build is under way, and what has to wait for the report. This guide shows how to lay that order out so the dates follow from it.
The short version
- Enter what each task waits for and let the dates be calculated.
- Write test scripts beside the build, not after it; they wait for the specification, not for the system.
- Make approvals milestones of length 0 so a late sign-off visibly moves everything behind it.
- Give deviations and retests their own task and length before you need them.
- End on an approved report that release depends on. The chart schedules this; it does not validate anything.
Order first, dates second
Validation schedules usually go wrong in the same few places. Test scripts are written after the build because nobody thought they could start earlier. Execution begins before the plan is approved, so results have to be repeated. A deviation turns up in the middle of testing and nobody has allowed time for it. Each of these is an ordering problem, and each is easier to see in a Gantt chart than in a list of due dates.
The approach is to write down, for every task, what it waits for. Writing a script waits for the specification it tests against, not for the system to be finished. Executing it waits for the script and for the system. The summary report waits for the execution being complete. Once those links are entered as dependencies, QueryChart calculates the dates, and the sequence you argued about in a meeting becomes something you can open and check.
Two things the chart cannot know are lead times and failures. A reference standard that takes weeks to arrive, or a calibration slot, has to be entered as a task of its own with a length. A deviation that sends a step back for a retest has to be given time before you know it will happen, usually as a task for resolving deviations. Both are judgement calls, and the chart only makes them visible.
A timeline schedules the work. It does not make a system, method, device or study validated, compliant or approved; that rests on the evidence you produce and on your quality system. The example below follows the computer system validation template. If your subject is an analytical method, the same ideas apply and /templates/method-validation-gantt-chart has the task list for it.
A system validation timeline, built in stages
Twenty tasks and five milestones. Durations are illustrative; set your own. Open the spreadsheet panel to see the rows behind each stage.
Plan, requirements and risk, then the approval gate
"Write validation plan" (5 working days) and "Draft user requirements" (6) can start together. "Assess risk to patients and data" starts two working days after the requirements start (SS+2). "Validation plan approved" is a milestone that waits for the plan and the risk assessment.
Scripts written beside the build
"Write functional specification" follows the approval gate. "Configure the system" (10 days) starts three days after it starts (SS+3), while "Write installation qualification script" and "Write operational qualification script" follow the specification. "Write performance qualification script" waits only for the risk assessment.
Execution, deviations and the end of testing
"Execute installation qualification" waits for the configuration and its script. "Execute operational qualification" (8 days) follows it, and "Resolve test deviations" (5) starts three days into it (SS+3). "Execute performance qualification" waits for the deviations and its script, and "Execution complete" is the milestone after it.
Traceability, report and release gate
"Review requirements traceability" (3 days) finishes one day after performance qualification does (FF+1). "Write validation summary report" waits for it and for "Execution complete". "Release system for use" is a milestone that waits for "Validation report approved" and for "Train users on approved procedures".
How it works
List the activities and what each waits for
Write one task per activity: plan, requirements, risk, specification, build, each script, each execution, deviations, report, training. For each, note what must exist before it can start. Do this before you think about dates.
Put approvals in as milestones
Add a task of length 0 for each approval gate, such as plan approved or report approved, and make the work behind the gate depend on it. If an approval is late, every task that waits for it moves, and the chart shows by how much.
Start scripts in parallel with the build
Make script writing depend on the specification, not on the finished system. Where work can begin a few days after another task starts, use start-to-start with a lag in Depends on, for example 5SS+3, so the overlap is on the chart.
Add lead times and rework as tasks
Enter a task for anything you wait on from outside, such as a reference standard, a materials delivery or an instrument booking, and give it a length in working days. Add a deviation task and make the next execution step depend on it, with a length based on past runs.
Gate release on the report and group by phase
Make the release milestone depend on the approved report and on anything else release needs. Group tasks by phase, put the owner in People, and switch on the critical path in the View menu to see which chain sets the release date.
Share it and export for the record
Share the chart as a link with the people doing the work, update progress as steps finish, and export a PDF when you need a copy for the project file or a review.
Mistakes to avoid
Executing before the plan is approved
If execution tasks do not depend on the approval milestone, the chart will happily schedule testing ahead of the approval. Link the work to the gate, and keep it there when you edit the chart.
Planning a clean run with no deviations
A schedule in which every test passes first time is rarely accurate. Give resolving deviations a real length, and consider a second pass of the affected tests as a task, so a failure does not silently consume the buffer for report writing.
Hiding external waits inside other tasks
A delivery of materials folded into the length of an execution task cannot be seen or challenged. Enter it as its own task so a late delivery moves the right dates.
Taking the chart for evidence
A timeline shows when work is planned. It does not show that a system or method is validated; that comes from the executed records and your quality system. QueryChart does not keep a baseline, so export a PDF before you change dates you may need to explain later.
Open the validation Gantt chart
Open the computer system validation template, set the durations to yours and see the release date move.
Related guides
Frequently asked questions
Can test scripts really be written before the system is built?
Often yes, because a script tests against a specification, not against the finished system. In the example the installation and operational scripts follow the functional specification and overlap with configuration. Check what your own procedures require before copying that order.
How do I show that a protocol must be approved before execution?
Add an approval milestone of length 0 and put it in Depends on for the first execution task. If the milestone moves, the execution tasks move with it.
How long should I allow for deviations and retests?
Use what your own past runs show. Enter the allowance as a task, such as resolving deviations, so it is visible and can be reduced deliberately. If you have no history, plan a modest allowance and review it after the first execution step.
Does QueryChart handle holidays or lab closures?
No. The calendar is Monday to Friday and there are no holidays. Add a task for a closure or a booking window, or fix a Start date for work that cannot begin before one.
Is there a template for an analytical method instead of a system?
Yes. /templates/method-validation-gantt-chart covers a method validation. For the wider product and filing context see /templates/medical-device-development-gantt-chart and /templates/regulatory-submission-gantt-chart.