← Insights

Safe systems of work

Method statements the crew will actually follow

July 2026 · 6 min read

Most sites have a method statement for the job in front of them. Fewer sites have a method statement anyone has actually read since the day it was printed for the file. It sits in a folder in the site cabin, or in an email attachment nobody opened twice, proving to whoever asks that paperwork exists - while the crew works from memory, habit and whatever the last person on the tools happened to say. That gap between the document and the doing is where a method statement stops earning its place and starts being a liability with a logo on it.

A method statement that gets followed looks different from the start. It is written for the crew, not for the file, and it is built around one idea: the order you do things in is itself a safety control.

RAMS: two documents, one job

RAMS stands for risk assessment and method statement, and the two halves do different work. The risk assessment asks what could go wrong on this task and how bad it would be if it did - the falls, the trapped services, the substances, the moving plant - and rates each one so the worst risks get the most attention. The method statement answers the question the risk assessment raises: given those risks, how will this job actually be done safely, step by step, by this crew, on this site, this week.

Treated separately, the two documents drift apart - a risk assessment that lists hazards nobody's method addresses, or a method statement written before anyone thought hard about what could go wrong. Treated as one system, with the risk assessment's key hazards summarised inside the method statement rather than filed elsewhere, the sequence and the controls stay honest against each other.

A safe system of work, not a compliance file

Strip away the paperwork language and a method statement is instructions: it describes the safe system of work so that everyone doing the job does it the same way, and that way is the safe one. That is a different document from one written to satisfy a pre-qualification pack or sit ready in case an inspector asks. A method statement written for the file reads generally, covers itself broadly and is quietly never opened again. A method statement written for the crew reads like a briefing, because that is exactly what it is.

The sequence is the heart of it

Everything else in a method statement supports one section: the sequence of work. Get the order of steps right and the job is controlled from start to finish. Get it wrong, and every other section can be perfect - the right PPE listed, the right permits referenced, the right plant specified - and the job is still dangerous, because the danger was never in what equipment was used, it was in what happened before what.

Isolate before you cut. Prop before you remove. Test before you energise. These are not general safety slogans, they are the actual shape of a sequence: each step exists to make the next one safe, and skipping or reordering one removes the protection the next step was relying on. A first-floor joist replacement that props the floor after cutting the joist rather than before has not made a small scheduling error, it has removed the control that kept the floor up.

This is also why the format of the sequence matters as much as its content. Steps numbered by hand drift out of order the moment someone inserts a step during a revision, and a sequence with a missing or duplicated number is one nobody can trust at a glance. Auto-numbered steps that renumber themselves when a step is added or removed keep the sequence honest through every edit, on site or back in the office.

Why the supporting sections earn their place

Everything around the sequence exists to make that sequence achievable, not to pad the document out. A method statement that is more than a sequence with extra sections attached usually has sections nobody wrote for a reason.

• Plant and equipment. What is being used to do the job, so the sequence can be checked against what is actually available and fit for the task.
• Materials. What goes into or comes out of the job, including anything that needs particular handling or storage.
• PPE. The protection specific to this task, not a generic list copied from a different job.
• Competence and training. Who is allowed to do which step, so the sequence is not just correct on paper but assigned to someone qualified to carry it out.
• Supervision. Who is checking the work is going to plan, and at what points.
• Permits to work. Where the task depends on a separate authorisation - hot work, confined space, isolation - the method statement should say so and reference it, not assume it.
• COSHH and substances. Anything hazardous going into the job, cross-referenced rather than re-assessed from scratch.
• Emergency arrangements. What happens if the sequence goes wrong anyway - first aid, evacuation, who to call.

None of these sections make the job safe on their own. They make the sequence achievable by the people, equipment and supervision actually available - which is the only way a method statement stops being aspirational.

The briefing and the signature

A method statement that has been written but not briefed has not yet done its job. Writing it down is necessary but not sufficient - the moment the document becomes a safe system of work is the moment the crew is briefed on it and confirms, in writing, that they understood it.

A method statement nobody was briefed on protects nobody and proves nothing - it is a well-written description of a job that is about to be done a different way.

That is what a briefing register is for: a simple record that names each person on the task, the date they were briefed and their signature. It is not there to catch anyone out. It is there because if the sequence in the document and the sequence in people's heads have to match for the job to be safe, someone has to check they actually do.

Two ways a method statement fails

• Written once and never briefed. It exists, it is thorough, and it lives in a folder. The crew works from experience instead, which is fine until the job has a hazard experience has not met before.
• Written so generically it could be any job. A method statement copied from a previous job with the dates changed reads plausibly but guides nobody, because it describes a sequence for a task that is not quite the one in front of the crew today.

Both failures look identical from the outside - a completed method statement exists, filed and available. Only the sequence and the signatures reveal which kind you have.

Reused as a template, not copied blind

A well-built method statement is worth keeping for the next similar job - the section structure, the phrasing, the shape of a good risk summary all transfer. What does not transfer is the sequence itself, the specific plant on this job, the specific crew and their competencies, and the specific risks of this site on this day. A method statement built in Word, fully editable with no locked fields, makes that reuse straightforward: start from the last good one, then rewrite the parts that make this job the job it actually is.