How to Write a Method Statement That Passes Review
If you've ever had a method statement bounced back by a principal contractor with "not suitable for the works" scrawled across the top, you'll know it's rarely because the site team don't know how to do the job safely. It's because the document didn't say so clearly enough. A method statement isn't there to prove you're careful, it's there to prove it in a way a reviewer who has never seen your site can follow in five minutes flat.
Here's what actually gets a method statement through review first time, and what gets it sent back.
Start with the sequence, not the hazards
The most common mistake is writing a method statement as a list of hazards with controls bolted on, rather than a description of how the work is actually going to happen. A reviewer wants to see the job broken into a logical sequence of steps, in the order they'll happen on site. Something like:
- Site set up and welfare checks
- Isolate and permit
- Erect access equipment
- Carry out the works
- Inspect and sign off
- Strike down and clear
Once you've got the sequence right, the hazards and controls attach naturally to each step. A reviewer reading step 3 wants to see the access equipment risks addressed right there, not three pages later in a generic hazards table.
Be specific about who does what
"Operatives will wear appropriate PPE" tells a reviewer nothing. Which operatives, doing which task, wearing which PPE? A method statement that says "the two operatives erecting the tower scaffold will wear a harness clipped to the internal ladder at all times above 2m" is a document a reviewer can actually check against, and it's a document your site team can actually follow. Vague language is the single biggest reason method statements get rejected, because it reads as though the author hasn't actually thought through the task.
Match it to the RAMS, and to reality
A method statement and its risk assessment need to agree with each other. If the risk assessment identifies a hazard, the method statement needs to show the control for it in the sequence of work, not just repeat it as a bullet point. Reviewers cross check the two, and a mismatch (a hazard with no corresponding step, or a control mentioned in the method that never appears in the risk assessment) is one of the fastest ways to get sent back.
It also has to match what's actually going to happen on site. Copying and pasting a method statement from a previous, similar job is fine as a starting point, but only if you then go through it line by line and change anything that doesn't apply. Reviewers who've seen a lot of RAMS can usually spot a template that hasn't been adjusted, and it undermines confidence in the whole document.
Name the plant, not just "plant"
If you're using a specific piece of equipment, name it. "A 3.5 tonne excavator fitted with a quick hitch" is checkable. "Excavator" is not. The same goes for materials, chemicals and access equipment. Specificity is what turns a method statement from a generic safety document into one that describes your actual job.
Cover the edges: emergencies, weather, and what happens if it goes wrong
A method statement that only covers the job going to plan is incomplete. Reviewers look for:
- What happens in an emergency (nearest muster point, who raises the alarm, first aid provision)
- What stops the work (adverse weather limits, especially for work at height or lifting operations)
- Who has the authority to stop the job on site if conditions change
These sections get skipped surprisingly often, and they're an easy thing for a reviewer to flag.
Keep it as long as it needs to be, and no longer
A ten page method statement for a straightforward task doesn't look more thorough, it looks like nobody has edited it. Reviewers are reading dozens of these. A tightly written document that covers the sequence, the hazards, the controls and the responsible people, without padding, is far more likely to get approved quickly than a bloated one that repeats itself.
If you keep getting RAMS rejected
If this is a recurring problem on your sites, it's usually not a competence issue, it's a documentation issue. The people doing the work know how to do it safely; the paperwork just isn't communicating that clearly enough for someone outside the team to see it at a glance. That's a fixable problem, and it's worth getting a professionally written RAMS document as a template you can adapt job to job, rather than starting from scratch (or from a tired old template) every time.
I write RAMS and method statements for UK construction sites for a living, built around how your specific job actually runs rather than a generic template. If you'd rather have one written properly than keep sending documents back and forth with a principal contractor, you can see the RAMS writing service here.
Comments
Post a Comment
Got a question about your own situation? Ask below and I will get back to you. Comments are checked before they go live so there may be a short delay.