Method Statement (UK Construction) + (DOCX) Template

The method statement is a system, not a narrative

Our example shows what reviewers actually check first: control, ownership, and traceability. This is consistent with HSE’s framing that a method statement describes a job in a logical sequence and includes control measures.

In practice, the “system” is the link between sections. The project background links to the risk assessment. The scope links to interfaces and restrictions. The key controls link to hold points and the step-by-step method. The review triggers link to revision history. The briefing record links to evidence you can produce in an audit.

To keep it structure-first, treat each section as answering one question:

• What job is this document controlling

• Who owns it and who approved it

• What is the site context and what could change

• What are the critical controls and where do we stop if they are missing

• What evidence proves it was briefed and reviewed

1) Overview and project information fields

The “Overview / Project Information” block is where you prove this is a live, controlled document for a specific job. Reviewers look for identity, revision, and traceability before they read the method.

Your template’s required fields in this block are all defensible because they each reduce ambiguity:

• Title, contractor, project, job number, MS reference, revision, issue date: establishes identity and current version.

• Linked RA and revision: proves the method is aligned to current risk controls, not an old assessment.

• Site address or location: stops “copy across sites” failures.

• Client, principal contractor, principal designer: clarifies dutyholder context without turning the MS into a legal essay.

• Distribution: shows who must receive it and who must be briefed.

When writing this section, the key decision factor is whether the MS can be mistaken for another job. If the answer is yes, add more specificity in the location and scope fields, not more generic prose.

If you want context on how risk assessment outputs should feed into a method statement, use the wider combined governance guide. Risk Assessments Statements Guide

2) Author and approval fields, plus revision control

The “Author and Approval” table is a control, not a formality. It answers who created the method, who reviewed it for safety, and who approved it for delivery on that site. CITB’s method statement guidance explicitly frames a method statement as a communication tool that reflects risk assessment findings, which makes sign-off and review a practical requirement, not a box-tick.

Your table structure is strong because it separates roles:

• Author: usually the person who understands the task sequence and site constraints.

• Reviewer: typically checks adequacy of controls, interfaces, and whether the MS reflects the RA.

• Approver: confirms it is current, workable, and aligned with site rules and permits.

Link this approvals table to two later sections:

• Review and change management: who signs planned reviews and triggered reviews

• Revision history: what changed between revisions and who approved the change

A common operational risk is “silent revision drift”, where the header shows Rev C but the method text has not been updated, or the linked RA is still Rev A. Your header field “Linked RA and Revision” is what prevents that.

3) Scope, interfaces, restrictions, standards, and timing

This is where most method statements either become genuinely site-ready or collapse into generic text. The trade-off is simple: the more specific you are about location, interfaces, and restrictions, the less you need to over-explain.

Your template correctly breaks this into usable fields:

• Location, plots or zones: define where the method applies.

• Working hours: helps interface planning and supervision.

• Start and end dates, duration: useful when conditions could change over time, for example seasons and weather exposure.

• Scope of works: define inclusions in one paragraph, not a list of everything the company can do.

• Interfaces: other trades, deliveries, pedestrian routes, scaffold alterations, crane lifts.

• Restrictions: weather dependency, permit conditions, access rules.

Then you reinforce it with narrative fields:

• Site description: short description that matches the site reality.

• Site layout summary and access arrangements: where welfare is, where laydown is, delivery booking rules, visitor controls.

Finally, you anchor it to references:

• Applicable specifications and standards and Reference documents: drawings, manufacturer instructions, TMP, lift plans, temporary works checks.

This section aligns well with work at height planning principles, where the requirement is to assess risk and then organise and plan the work so it is carried out safely.

4) Key controls, resources, competence, and responsibilities

Your “Key Controls Summary” is one of the most valuable structural sections because it pulls critical controls out of the method text so they can be briefed and checked. It is also where reviewers quickly see whether you have identified what must not fail.

A strong key controls table usually does three things:

1. Groups controls by hazard theme, like work at height, falling objects, manual handling, traffic

2. Uses control language that can be checked, like “tagged scaffold” rather than “be careful”

3. Matches the controls that appear later in the method sequence and hold points

Then your template backs it up with delivery capacity:

• Resources: people, plant, materials, PPE.

• Competence and training: working at height awareness, manual handling, tool competency, banksman where required, site induction and MS briefing.

Your “Roles and Responsibilities” table is the ownership layer. The real-world constraint here is supervision bandwidth on a busy multi-plot site. If the supervisor is responsible for permits, briefings, and interface control, the method needs to make those responsibilities obvious and limited, not scattered.

One practical addition you already implied is stop-work authority. In your responsibilities section, make clear that operatives can stop work if hold points are not satisfied, then the supervisor confirms whether work resumes.

5) Permits, hold points, and the methodology sequence

This is the part that makes it “site-operable”.

Permits

Your permits table fields are exactly what supervisors need to run the day:

• Permit type

• Permit reference

• Issuing authority

• Validity

• Status

The key decision factor is whether a permit is required to start work, required only for certain methods, or conditionally required if a trigger occurs. Your “Hot works permit (if used)” is a good example of conditional permitting.

Hold points

Hold points are where the method stops until a condition is true. Your example uses hold points well because each one prevents a predictable failure, such as going onto a roof before confirming scaffold tags and weather.

For work at height tasks, planning and organisation requirements are explicit in HSE guidance, and hold points are one practical way to demonstrate that planning in a deliverable sequence.

Methodology and sequence of activities

Your seven-step structure covers the expected lifecycle:

1. Pre-start, induction, mobilisation

2. Deliveries, unloading, storage

3. Access set-up and controlled entry

4. Inspection and setting out

5. Material transfer and safe storage

6. Installation works

7. Completion, housekeeping, demobilisation

To keep it “fields-first”, each step should do three things:

• State the action

• State the controls that apply in that step

• State the evidence or check that proves it was done, even if that evidence is just “supervisor confirmation” recorded in the briefing notes

Plant and equipment inspection records

Your inspection records table is the proof layer for access and lifting equipment. It prevents the common assumption that “scaffold exists, therefore scaffold is safe”.

The fields you included are correct:

• Item

• Inspection type

• Frequency

• Evidence reference

• Status

In the example, the evidence reference is “To be confirmed”, which is fine for dummy data, but the structure is what matters.

6) Environment, COSHH, emergencies, review, revisions, and briefing evidence

These sections are often omitted from templates, which is why including them is a good structural signal.

Environmental controls and COSHH

Your template handles the trade-off well:

• Environmental controls: include the essentials that affect this task, like waste segregation and fuel storage.

• COSHH: include only if hazardous substances are used.

That “include only if used” rule keeps the MS short and avoids irrelevant content.

Emergency arrangements

Your emergency table includes what site teams actually need in an emergency:

• Emergency services number

• Site emergency contact

• Assembly point

• Height rescue plan reference

• Nearest hospital and access route

• First aid provision

The operational risk here is that people assume “work at height rescue exists” without referencing it. Your “Height rescue plan” field forces the plan reference into the document.

Review and change management

This is where you lock the method to reality. Your review triggers are exactly what should force a re-brief:

• scope or location change

• incident or near miss

• new equipment or interfaces

• adverse weather impacting work at height

Then you add a planned review interval and sign-off. That makes it auditable.

Revision history

Your revision table structure is correct:

• revision

• date

• change summary

• changed by

• approved by

The discipline is in the “change summary”. Keep it specific, like “Added methodology hold points”, not “updated”.

Briefing and acknowledgement

This is your final proof layer, and it should never be treated as an optional add-on.

Your table captures:

• name, company, signature, date

• RA briefed yes or no

• MS briefed yes or no

If you are capturing briefing evidence digitally, this is the point to connect the method statement document to briefing workflows and sign-off records. Safety Briefing App