The RAMS on file is dated correctly, signed correctly, filed correctly, and describes a job that isn't the one being done today. It is one of the most common findings I raise, and it almost never comes from laziness.
Every auditor has sat across the table from a site manager who has just produced a Risk Assessment and Method Statement that describes a job which, technically, is not the job being done that day. The scaffold configuration changed. A sub-contractor swapped out. The client added a scope of works the night before mobilisation. The RAMS on file is dated correctly, signed correctly, filed correctly, and wrong.
This is one of the most common findings I raise on ISO 45001 and CDM 2015 site visits, and it rarely comes from laziness. It comes from a RAMS process that was built to produce a document once, not to keep pace with a job that changes.
Most SMEs build their RAMS around a template library. Someone, often a competent and conscientious person, assembles a good method statement for a standard task, gets it checked, and it becomes the master copy. New jobs get copied from the nearest match, tweaked, and issued. That works fine until the job itself moves: a last-minute access restriction, a different plant arriving on site, a sequence change because another trade overran.
At that point the paperwork and the work diverge, and nobody owns the gap. The person on site doesn't feel it's their job to rewrite a method statement issued by the office. The office doesn't know the scope changed until the post-job review, if there is one.
The failure isn't the template. Templates are sensible. Nobody should draft a fresh risk assessment from a blank page every time. The failure is having no defined route for a change in scope to reach the document, get re-assessed, and get re-issued before work starts under the new conditions.
Nothing in ISO 45001 or CDM 2015 tells you how to build a method statement, and nothing in either mandates a tool. Anyone telling you the standard requires their product is selling you something.
What ISO 45001 asks for, in substance, is that risk assessment is planned, that hazards are identified before the associated work is carried out, and that the organisation can demonstrate the assessment reflects the work as actually planned, not work as it was planned a fortnight ago. CDM 2015 places a duty on contractors to plan, manage and monitor construction work so it's carried out without risk to health and safety, so far as is reasonably practicable, and for higher-risk work that generally means a written method statement kept current enough to be relied on.
Neither framework specifies a review cadence for scope changes, a sign-off chain, or a tool. That's left to you, which is exactly where most SMEs get caught out. They've satisfied the letter of “we have a RAMS” without building the mechanism that keeps it true.
The contractors who don't get flagged for this tend to share three things, none of which require anything expensive.
Not “if things change,” but a short, specific list: different plant, different sequence, different access, an additional trade working concurrently, weather outside the assessed range. If any of those happens, the RAMS gets revisited before work resumes. Full stop, no judgement call required from whoever is on site under pressure.
A full RAMS rewrite for every scope tweak isn't realistic and isn't what's expected. What holds up under audit is a documented, dated addendum (what changed, what new hazard or control it introduces, who assessed it, who briefed the crew) attached to the original document rather than replacing it invisibly. The paper trail matters more than the format.
A revised RAMS sitting in a folder that nobody on site has opened is not a control, it's a liability with a paper trail. Toolbox talk records, briefing sign-offs, or a dated acknowledgement from each operative are what turn “we updated it” into evidence an auditor can actually verify.
None of that is complicated. It's also the part that gets skipped, because it's the least visible piece of the job and the easiest to defer when the site is moving fast.
PICMS's RAMS builder will let you generate a method statement from a structured library, version it, and move it through a draft, approved and issued workflow, with a timestamped record of when each revision was issued and who it went to, which addresses the second point above and gives you something concrete to hand an auditor instead of a verbal account of what happened.
What it does not currently do is capture the crew side of the third point: a record that each operative saw the amended RAMS before work resumed. Issuing a document and briefing a crew are different events, and only the first is evidenced in the RAMS builder today. If you need the second, it sits outside that tool, and it is worth knowing which of the two you actually have.
What no platform will do is decide when a scope change is significant enough to trigger a re-assessment. That judgement, knowing that swapping a scaffold configuration or bringing in a second trade changes the risk picture, is a competence issue, not a software one. A system can make the re-assessment fast to produce and easy to evidence. It cannot make someone recognise that the job in front of them isn't the job on the paperwork. That's a training and supervision question, and no tool sold as a compliance platform will honestly tell you otherwise.
If your RAMS process currently has no defined route for a scope change to reach the document before work resumes, that's the gap worth closing first, with or without software. If you've already got that route and just want it evidenced properly, that's the part a system like PICMS is actually built for.
PICMS versions your RAMS, moves it through draft, approved and issued, and records when each revision went out and to whom, so a scope change leaves a trail instead of a gap.