Inspection and test plan (ITP): how to prepare one for construction
Quality on a construction project is not verified at the end; it is verified continuously, at the moments when it can still be corrected. The document that makes those verification moments deliberate rather than accidental is the inspection and test plan, or ITP. Sitting alongside the method statement and the risk assessment, the ITP lists every inspection, test and verification activity a work package requires, states when each happens, and names who performs it and who witnesses it. When it is prepared well, it becomes the backbone of quality records at handover. When it is prepared badly — or skipped — defects surface late, where they cost orders of magnitude more to fix. This guide walks through what an ITP is, how to build one that works, and the practical details that separate a useful plan from a shelf document.
What an inspection and test plan actually is
An ITP is a sequenced schedule of quality control activities mapped onto the stages of a work activity. For a concrete pour, it covers pre-pour checks such as formwork dimensions and reinforcement inspection, the pour itself with sampling and cube testing, and post-pour activities such as curing verification and strength testing. For structural steel, it covers material certificates, weld inspection, bolt torque verification and coating thickness measurement. Every inspection and test the specification demands appears in one place, in the order the work happens.
The document is more than a checklist because of the columns that accompany each activity. A complete ITP records, for every stage: what is being verified, which specification clause or standard it must satisfy, when the check occurs, who performs the inspection, who reviews or witnesses it, what records are produced, and what must happen if the check fails. It is this last dimension — the response to failure — that turns a list into a control system.
Why hold points and witness points matter
The mechanics of an ITP revolve around a small vocabulary of inspection types, and understanding them is essential to preparing a plan that functions on site. The terms are these.
- Hold point (H). Work must stop until the named authority — typically the client’s representative or the engineer — inspects and releases the activity in writing. Proceeding past a hold point without release is a non-conformance in itself.
- Witness point (W). The named party is notified and given the opportunity to witness the activity, but if they fail to attend, work may proceed after the notice period.
- Review (R) and surveillance (S). Document checks and ongoing monitoring of processes that do not stop the work but feed the quality record.
- Verification (V). Confirmation that an activity complies with the requirements, performed by the contractor’s own team unless otherwise specified.
The distinction between a hold point and a witness point carries contractual weight, and getting it wrong in either direction creates friction. Specifying hold points too liberally floods the engineer with inspection demands and stalls the programme; specifying them too sparsely leaves critical stages unverified by the party who must ultimately accept the work. Skilled ITP preparation is largely the art of choosing the right point type for each activity.
A worked example: ITP for a structural concrete pour
Concrete is the classic ITP subject because its failure modes are irreversible: once the pour happens, formwork coverage, reinforcement placement and cover cannot be rechecked from the surface. A representative extract for a foundation pour shows how the structure comes together.
| Stage | Activity to be verified | Requirement reference | Point type | Performed by | Reviewed by | Record |
|---|---|---|---|---|---|---|
| Pre-pour | Formwork dimensions, line and level against drawings | Drawings, dimensional tolerances spec | H | Site engineer | Client rep | Dimension survey sheet |
| Pre-pour | Reinforcement size, spacing, laps and cover | Bar schedule, cover spec | H | Site engineer | Client rep | Reinforcement inspection record |
| Pre-pour | Concrete mix design and delivery ticket review | Specified grade and workability | W | Site engineer | QA manager | Delivery ticket, mix design |
| During pour | Slump or flow test on delivered batches | Specified workability limits | R | Site technician | — | Test record per delivery |
| During pour | Sampling for cube or cylinder tests | Testing frequency per specification | R | Site technician | QA manager | Cube register, lab reports |
| Post-pour | Curing method and duration as specified | Curing specification | S | Site supervisor | — | Curing record |
| Post-pour | 7 and 28-day strength results | Specified characteristic strength | H | QA manager | Client rep | Lab certificates |
Reading down the point-type column reveals the plan’s logic. The client holds points before the pour, because after concrete arrives there is no turning back; the during-pour checks are the contractor’s own responsibility, recorded for evidence; and the strength results return to a hold point because acceptance of the completed element depends on them. That rhythm — tight control before irreversible steps, documentation through the process, acceptance on outcomes — is the template for ITPs in every trade.
Building an ITP step by step
Preparing an ITP from scratch follows a repeatable sequence, and teams that follow it produce plans that pass review with minimal rework. The steps are these.
- Gather the governing documents. Project specification, drawings, standards and client quality requirements define what must be verified; the ITP cannot be written before these are in hand.
- Break the work into stages. Sequence the activity chronologically — preparation, execution, completion — so inspections sit where they can influence the outcome.
- List every inspection and test. Walk each specification clause and ask what evidence proves compliance, then add the check to the plan with its requirement reference.
- Assign point types deliberately. Reserve hold points for irreversible or acceptance-critical stages; use witness and surveillance points elsewhere; avoid making everything a hold point.
- Name responsibilities. Identify who performs, who reviews and who accepts for every line — unnamed columns are the most common reviewer objection.
- Define failure responses. State what happens when a check fails: rework, retest, raising a non-conformance report, and who decides.
- Submit for approval and revise. Walk the client or engineer through the plan, incorporate comments and freeze the approved version before work starts.
The order matters more than it appears. Teams that start by writing the ITP and reach for the specification afterward produce generic documents that omit the client’s specific requirements. Teams that start from the specification produce a plan that mirrors the contract — which is exactly what an approver wants to see.
Common pitfalls and how they show up
Certain failure patterns recur across projects of every size, and most of them trace back to the same handful of causes. The recurring problems are these.
- Copy-paste from a previous project. Requirements references pointing to the wrong specification, tests that this project does not require and inspections missing that this project does — all instantly visible to a reviewer who knows the contract.
- Everything marked as a hold point. A plan that stops work for client inspection at every stage will be renegotiated, diluted and eventually ignored, undermining the few hold points that mattered.
- Missing failure procedures. Without a stated response to failed checks, non-conformances are handled ad hoc, and the quality record at handover develops gaps exactly where problems occurred.
- No linkage to the programme. An ITP whose inspections cannot be scheduled alongside the work programme will not be followed in practice, regardless of its content.
- Records never collected. The most common real-world ITP failure is a plan whose boxes are ticked retrospectively rather than at the time, producing a handover file that collapses under scrutiny.
Each pitfall shares a root cause: the ITP was treated as a document to be produced rather than a process to be run. The remedy is the same in every case — write the plan from the specification, agree it before work starts, and collect the records as the work proceeds.
Keeping the ITP alive during the work
An approved ITP is a starting position, not a finished product. Site conditions, design changes and programme adjustments all modify what needs checking and when, so the plan must be a living document with visible revision control. Changes are handled through a formal amendment process: the need is identified, the client reviews the change, the revised plan is re-issued with an incremented revision number, and the site team is briefed on what moved. Handing over with an outdated revision in circulation is a favourite audit finding, and avoiding it costs nothing beyond discipline.
Record collection deserves equal attention. Every completed inspection line should generate its record immediately — signed off, dated and filed against the ITP reference. Digital systems have made this dramatically easier, with inspection records captured on tablets and flowing directly into the quality file, but the principle predates the software: a check that produced no record did not, from the contract’s perspective, happen.
From paperwork to proof
An inspection and test plan earns its keep by making quality verifiable at the moments that matter. Its hold points protect the stages that cannot be redone; its witness and surveillance points build the evidence trail that acceptance at handover depends on; and its failure procedures ensure that problems are caught as non-conformances rather than inherited by the next trade. Preparing one is neither complicated nor glamorous — it is a matter of reading the specification, sequencing the work and naming responsibilities honestly. Projects that run their ITPs as genuine control documents close out handover with complete records and few surprises. Projects that treat them as submissions carry their quality risk unmanaged to the very end, and pay for it there.