Scope of this guide
For teams adapting an existing generic or trade ITP template to a defined construction work package. Focuses on template triage, customer-form mapping and missing-information control. Project documents and assigned approval roles govern all technical requirements.
Screen the template before editing
Freeze a working copy and note its source and revision. Compare its stated trade, work stages, assumptions, control-point legend, record links and exclusions with the package you have actually been asked to cover. A row that sounds relevant may still assume a different substrate, system, work boundary or contractual role.
Classify each existing row as retain, tailor, remove or confirm. Record a reason for each removal or substantial rewrite so that a required scope item is not lost during simplification. Add new rows only when the project sources identify a real requirement the starting template does not cover.
- Retain rows that match the package and have a source path to project requirements.
- Tailor generic prompts to the actual work area, sequence, client terminology and linked field record.
- Remove out-of-scope rows with a brief scope reason; do not leave irrelevant stages to imply coverage.
- Mark unverified assumptions for confirmation rather than treating them as project facts.
Build a requirement-to-template crosswalk
Before rewriting cells, cross-reference the customer’s submission requirements and controlled documents against the template. This reveals requirements that belong in the contractor form, supporting register or linked procedure rather than in an overloaded ITP row. The project’s required format and document-control fields take precedence over the convenience of a generic template.
| Input or requirement | Template action | Status to show |
|---|---|---|
| Customer ITP form and instructions | Map each mandatory field and document-control item to the working copy; preserve required labels and structure | Form revision and any approved cross-reference |
| Scope and boundary | Keep, split or remove rows to match actual elements, locations, stages and interfaces | Included/excluded scope and affected rows |
| Approved drawing/specification/product documents | Cross-reference exact controlled source and locator to the relevant row | Revision/status confirmed or open-source issue |
| Required quality records and notices | Link the specified field record, report, submission or control point | Named record/notice requirement and assigned role source |
| Template assumptions or blank prompts | Replace only when a project document or authorised decision supports it | Source-backed value or named open decision |
Preserve the customer’s form and make the mapping reviewable
When the client or head contractor mandates a form, keep required headings, revision history, approval blocks and control-point conventions. Use a crosswalk or continuation sheet only where the project process permits it, and identify which source field maps to which row or attachment. Do not return a polished template that quietly omits a customer-required submission field.
Check that a reviewer can move from each retained row to its governing source and then to the form or evidence record that will carry the result. If one row combines requirements with different sources, locations, triggers or roles, split it or make the distinction clear.
Keep missing information visible until it is resolved
Maintain an open-items register next to the draft. Each item should name the missing or conflicting input, affected row/location, source documents already checked, required decision, responsible project role, and status. Do not use a guessed criterion, frequency, release role or product detail as a placeholder that looks final.
A customer may provide a partial package. Continue tailoring portions supported by current documents while isolating unresolved portions; make clear what cannot be finalised and whether the project procedure requires that work to wait. If two documents conflict, route the question through the contract’s clarification process.
Complete a conversion check before submitting
Compare the tailored document against the customer form and the source crosswalk, not only against the starting template. Confirm that deleted rows are genuinely outside scope, added rows have a source, linked records use the same work identifiers and all open items remain visible.
Submit the ITP using the project’s formal review route and record the revision/status. The author prepares the conversion; review, technical acceptance and release belong to the roles assigned by the contract and project procedure.
Fictional example: adapting a generic wet-area template
Fictional teaching scenario only. A contractor receives a hypothetical bathroom package and a head-contractor ITP form. No real project, product requirement, acceptance value or approval is represented.
- Copy the generic ITP to a controlled working draft and record its origin and revision.
- Compare the package boundary and customer form with each template row; remove an unrelated external-area step with a recorded scope reason.
- Map approved bathroom details and selected-system instructions to the relevant remaining rows, recording exact revisions and locators.
- List an unresolved system/detail conflict in an open-items register with the designated decision role instead of filling in an assumed product value.
- Transfer supported rows into the customer form, preserve its required control fields and submit the identified draft revision through the project review route.
Before issuing the plan
- Record the source and revision of the starting template.
- Classify every existing row as retain, tailor, remove or confirm, with a reason for material changes.
- Crosswalk mandatory customer-form fields and submission requirements before transferring content.
- Tie every retained acceptance requirement to an approved project source and locator.
- Track missing or conflicting information with affected row, required decision, responsible role and status.
- Verify added rows have sources and removed rows are outside the defined package.
- Keep customer document control and approval fields intact unless the project authorises a change.
- Show draft/review/approval status accurately; authorship does not constitute approval.
Sources and their limits
Public sources explain the planning topics below. Confirm their jurisdiction, contract context and applicable edition; use controlled project documents for the actual requirements.
- TfNSW Quality Management (Major Works) – QA
Clause 3.8.2 Inspection and Test Plans, especially required stages/frequency, method and criteria, nominated H/W points and time constraints, performing/reviewing roles, nonconformance next steps and lot close-out
Contract-specific example that ITPs sit within project quality planning and carry steps, methods, records and criteria. Does not establish a universal building ITP format.
Source reviewed: 2026-10-07
- TfNSW Guide to Quality Management System (Type 4), NQ4
Clause 8.1.2 Frequency of Testing and cross-reference to Q4 clauses 1.4 and 8.2.4.2
Public infrastructure example connecting ITP entries to specification requirements, testing frequency and review; frequency remains project/specification dependent.
Source reviewed: 2026-10-07
- Construction Quality Australia: Guide – How to Create an Inspection and Test Plan (ITP)
Public industry guide on work scope, requirements, responsibilities and review
Industry context for planning and review workflow; used as guidance, not as a governing project specification or approval.
Source reviewed: 2026-10-07
- ABCB NCC 2022, Part A3 Application in States and Territories
A3G1 state and territory compliance
Supports verifying jurisdictional variations/additions and legislative application rather than assuming one national wet-area checklist applies everywhere.
Source reviewed: 2026-10-07