A computerised system has a life — concept, selection, design, build, release, operation, retirement. Treating validation as a gate near the end is what makes it expensive. We work across the whole lifecycle, on three levels: hands-on delivery, the strategy that shapes it, and the governance that keeps it consistent.
Nothing about a regulatory requirement changes as a project progresses. What changes is how much has been built on top of the assumption it contradicts. A requirement corrected during specification costs an afternoon. The same correction after qualification costs a deviation, a change control, a retest and a delay.
The model is the same whether the system is an on-premise PLC, a validated cloud service or an MES spanning both. What changes is where the evidence comes from and who owns it.
What problem is being solved, and whether the system touches a GxP record at all. The determination made here sets the cost of everything after it, and a correct determination that something is out of scope is among the largest savings available across the lifecycle.
The URS, written as requirements expressed from the user's perspective. Regulatory requirements stated alongside functional ones, rather than appended as a separate compliance annex.
Assessment and, where warranted, audit. What qualification evidence you can inherit, what you cannot, and which clauses need to be in the contract — notification of change, data ownership, exit and retrieval — while you still have leverage.
Architecture, data flows, interfaces, access model and audit trail design. Security and data integrity decided here rather than assessed later, because retrofitting either into a qualified system is the expensive path.
Risk-based testing with a rationale that survives challenge: supplier evidence leveraged where it is credible, effort concentrated on what is configured, custom or critical. IQ, OQ, PQ sized to the risk.
Data migration and its verification, training, cutover, and a release decision somebody can defend. Migration is frequently underestimated, and is often the first area an inspector examines.
Where a system spends most of its life: change control, patching, audit trail review, access recertification, backup and restore testing, periodic review. Validation is a state to be maintained, not an event that happened.
The phase most often left undefined. Records must remain readable and retrievable for their full retention period after the system that produced them is gone — which is a decision about format and migration, taken years before anyone needs the data.
Some clients need hands on documents. Some need a framework so their own team can work. Some need someone who can hold a programme together across vendors and departments. Frequently the same client needs all three at different moments.
The deliverables themselves — URS, functional and design specifications, risk assessments, IQ/OQ/PQ protocols, traceability, SOPs, migration verification and periodic review records. Written to be read by an inspector, and produced at the pace the project runs.
Validation policy and master plan, risk approach, CSA adoption, system inventory and categorisation, supplier assessment framework, data integrity governance, and the roadmap that sequences it. The aim is that your team can run the process afterwards without us.
Owning the validation workstream across vendors, integrators, IT, engineering and QA — the role that frequently has no owner. Vendor management, review and approval flow, escalation, and readiness for the audit or inspection the work is ultimately for.
The phases hold. What changes is where the evidence lives, who can produce it, and what a change looks like.
Well-trodden ground, and the risk is complacency: template packages applied without adaptation, configuration treated as if it were vendor-standard, and interfaces to other systems left outside the validated boundary.
Long lives, obsolete components, and a qualified state that any change disturbs. Version control of automation software is frequently missing, and the supplier who built it may hold the only copy of the source.
The system changes when the provider decides, not when you do. That breaks the assumption underneath classical change control, and it makes the supplier assessment and the notification clause part of the validation, not paperwork beside it.
That one answer usually tells us what the engagement should be — and whether it is two days of review or something considerably larger. Either is a fine place to start.