ConstructionPioneerMaterials · Retrofit · Site
Independent editorial deskEst. 2026
Site & Project

Writing a Method Statement That Survives the Inspector

A method statement is not a description of what you plan to do. It is the document an inspector uses to decide whether you were allowed to do it. Write accordingly.

SASelin Arslan
Site engineer
Engineers reviewing construction drawings together on site.
Engineers reviewing construction drawings together on site.Photo: borevina / Pixabay

Most method statements are written to satisfy a submission requirement, not to control work. You can tell the difference within three paragraphs: the submission version lists materials, plant and a sequence of activities ending in “inspect and hand over”. The working version names who does what, at which point work stops, and what record proves it happened.

The inspector reads a different document from the one the contractor thinks they submitted. They are not looking for elegance. They are looking for the gap between what the specification requires and what the site is set up to demonstrate.

Start with the specification, not the template

The commonest structural weakness in a method statement is that it answers questions nobody asked. A repair specification will state a substrate tensile strength, a minimum ambient temperature, a curing regime and a verification frequency. Those four numbers should appear verbatim in the method statement, next to the activity they govern.

If the specification is silent on a parameter that matters — say, the frequency of pull-off testing — the method statement is where you propose one and get it accepted. Better an agreed number before the job starts than an argument about sampling after the third failed test.

The sections that carry weight

A method statement for a repair or strengthening package is usually built from these blocks:

  • Scope and extent — what is included, what is explicitly excluded, and the boundaries of the work area.
  • References — specification clauses, test standards, manufacturer’s data sheets, by revision.
  • Materials and their acceptance — including how delivered material is checked and what happens to a batch that fails.
  • Plant and access — scaffold, access platform, temporary works, and who has signed off on them.
  • Sequence — the order of operations, written as instructions rather than aspirations.
  • Hold points — where work stops for inspection, and who releases it.
  • Records — the forms, photographs and test certificates that will exist at completion.
  • Safety and environment — task-specific, not a generic policy paste.
  • Contingency — what happens when a test fails or access changes.

Two of those blocks are where good documents differentiate themselves: hold points and records. Everything else is common to every contractor in the country.

Hold points and the inspection test plan

A hold point is a moment where the next activity is physically destructive of the evidence for the last. Surface preparation before primer. Primer before the first ply. Anchor hole cleaning before resin injection. If the inspector does not see the prepared surface, they cannot verify it later, and no amount of photography substitutes for being able to fail it in place.

Activity Hold point Record Released by
Substrate preparation Before primer Pull-off result, surface photograph, profile check Engineer / inspector
Crack injection Before loading Port log, resin batch record, core sample Engineer
Anchor installation After hole cleaning Hole depth, cleanliness photograph, torque log Site engineer
FRP lamination Before protective coating Ply count, orientation, lap positions, cure log Engineer
Waterproofing Before backfill Membrane continuity, moisture reading, detail photographs Inspector

Each hold point needs a named releaser and a defined response time. A hold point whose release takes four days is a hold point that will be bypassed on the third day.

Write the sequence as instructions

“Surfaces shall be prepared in accordance with the specification” is not a sequence. It is an abdication. A working sequence reads more like this:

  1. Isolate the work area and confirm ambient conditions are within range (≥ 5 °C and ≥ 3 °C above dew point).
  2. Remove render and non-structural finishes to expose sound concrete.
  3. Grind substrate to CSP 3–5; vacuum dust immediately.
  4. Survey cover and hammer-tap for delamination; mark defective areas for repair.
  5. Carry out pull-off tests at the agreed frequency; submit results.
  6. Hold point: do not proceed to primer until results are accepted.
  7. Round arrises to the specified radius and fill voids with repair mortar; allow to cure.

Note what the numbered list does: it makes the order auditable. If a failure appears later, the record shows which step was skipped, and the argument moves from opinion to evidence.

Records that are actually produced

A common failure is a method statement that lists records nobody produces. Before naming a form, confirm it exists, that someone is assigned to complete it, and that it is filed the same day rather than reconstructed at handover. Photographs should be taken with a scale and an identifier visible, at named stages, and stored with the corresponding location.

The record set that survives scrutiny is small and boring: batch numbers, temperatures, test results, hold point signatures, and dated photographs of the conditions those numbers describe.

Contingency needs a number, not a sentiment

“We will rectify defective work” is not a contingency. A usable contingency names the trigger and the action: if a pull-off result falls below 1.0 MPa, the area is extended by 300 mm in each direction, re-prepared, and retested at double frequency. If ambient temperature drops below the minimum overnight, cure protection is installed and the cure log is extended by 24 hours.

Write those triggers before work starts, when nobody is defending a decision. Afterwards, every failure becomes a negotiation about programme and cost, and the technically correct action is usually the expensive one.

What an inspector actually checks

Four things, in order:

  1. Does the document match the specification and the approved materials?
  2. Are the hold points defined, and were they released by someone with authority?
  3. Do the records exist in the form the document promised?
  4. Do the numbers in the records meet the acceptance criteria?

A method statement that answers all four is not a long document. It is a specific one. The tell is whether a site engineer can pick it up at 7 a.m. and know exactly what to do next, and what to stop for — without phoning anyone.

That is the whole test. Everything else is formatting.

method statementITPhold pointsQA/QCsite documentation

Keep reading

Related notes from the same sections of the desk.