Running an ITP Inspection Workflow

Structuring an ITP document

An Inspection and Test Plan mirrors the shape of a requirements document: headings organize the work, and rows underneath them carry the actual inspection items. Keep the structure shallow (two or three levels is usually enough for a facility-level ITP).

An ITP register: inspection items under their headings, with the result of each recorded inline.

Headings vs inspection items

Headings never carry a result; only the inspection item rows underneath them do. If you find yourself wanting to mark a heading pass or fail, it's a sign the heading should be split into the inspection items it's actually standing in for.

Use the Edit sections button to reorganize headings once the document has grown past its first draft. Drag one heading onto another on the canvas to nest it, instead of recreating rows to match a corrected structure. See "Nesting Sections with the Section Editor" for details.

Recording pass/fail results

Each inspection item accepts one of four results: Pass, Fail, Pending, or Not Applicable. Record the result as soon as the inspection happens. Backfilling results from memory at the end of a shift is where most transcription errors creep in.

An item's detail panel carries the full inspection record: the acceptance criteria, the method, the reference standard, the result, and the sign-off. It also links back to the requirement the item validates, so the "why" of an inspection is one click away from the "did it pass".

An inspection item's detail panel: acceptance criteria, method, reference standard, result, and sign-off.

Sign-off and audit trail

Every Pass or Fail result should record who signed off and when, in the Signed off by and Signed off at fields on the detail panel. This pair is what makes the ITP register usable as an audit record months later, when nobody remembers who was on site that day.