Method statements

A safe work method statement breaks a job into its steps, names the hazard in each one, and says what will be done about it. Whatever your jurisdiction calls it, SWMS, JSA, JHA or a safe operating procedure, the structure is the same and so is the obligation: it has to exist before the work starts, the people doing the work have to have read it, and it has to still describe the job they are actually doing.

Teralo is built around the second and third of those, which are the parts that go wrong.

One document, many projects

This tool is shaped differently from everything else in Quality & Safety, and the difference is worth ten minutes up front.

A method statement belongs to an organisation, not a project. Your scaffolding method statement is one document you wrote once. Submitting it to a project creates a separate submission record, which is what carries the SWMS number for that job, the review, the acceptance and the worker sign-ons.

So the same document can be on six projects at once, each with its own number and its own review outcome, and there is exactly one copy of the actual method to keep current. Update it and every project is looking at the same revision rather than six drifting Word files.

That is why Method Statements appears at both organisation level and project level. The organisation register is your library, and the project register is what has been submitted here.

Writing one

The document carries the activity name and its activity type, who provided it, a description of the work, and whether it is high risk work.

Job steps, hazards and controls

The heart of the document, and Teralo keeps it as structured data rather than a block of text. Each step lists its hazards; each hazard carries a risk level before controls and a risk level after controls, high, medium or low; and each hazard carries the control measures that get it from the first to the second. Recording it that way is what lets a reviewer see at a glance whether a high risk has actually been brought down or just described.

Alongside that sit the PPE requirements, the licences a worker needs to do this work, references to the safety data sheets for the substances involved, references to the equipment used, whatever custom fields the activity type adds, and the signed PDF if you have one. A review date records when the document itself is next due to be looked at.

Submitting to a project

Submitting takes the document to a project, where it gets a SWMS number, numbered per project with the activity type's prefix, and enters review.

A submission is Draft, For review, Accepted, Rejected or Not in use. The reviewer works through the review checklist the activity type defines, so two reviewers on two projects are asking the same questions, and leaves comments with the decision.

The project's public portal publishes accepted method statements, so a worker can read the one covering their task from a phone at the gate.

Worker sign-on

Signing on records that a named person has read the method statement, and it records which version they read.

There are two ways to sign. In person is somebody signing on the device in front of them, at a pre-start or a toolbox talk. By email link sends a tokenised link that expires, and the sign-on records the IP address it came from, which is what makes a remote sign-on worth having as evidence. Workers being inducted onto the project can also sign the relevant method statements as part of the induction.

Then the part that matters most:

Issuing a new version invalidates every existing sign-on. The previous submission moves to Not in use, its review run is cancelled, and every sign-on against it stops counting. Everybody signs again.

That is severe on purpose, and it is the behaviour to design around. A method statement people signed in March does not cover a method changed in June, and a tool that let those signatures carry over would be manufacturing a false record of exactly the thing a regulator asks about. Version deliberately, in one pass, rather than tidying wording in the live document a fortnight into the work.

Every version stays readable as history, so the chain shows what was signed and when.

SettingsHost only

Tools, then Method Statements holds the activity types, and an activity type here carries much more than a name. Each one has a colour, a numbering prefix, a default hazard library of hazards with their risk levels and controls, default PPE requirements, default required licences, its own custom fields, the review checklist the reviewer works through, and the workflow bound to it.

Filling the default hazard library in is the highest-value thing you can do in this tool. It is the difference between every subcontractor inventing their own wording for the same hazard and everybody starting from the organisation's agreed set, and it makes the resulting documents comparable.

Types are written at organisation level and activated per project, and they can be archived when a type falls out of use rather than deleted, so historical documents keep their type. See Organisation level and project level and The tools catalogue.

PermissionsHost only

• Can view method statement register and details shows the registers
• Can create and submit method statements allows writing one and submitting it to a project
• Can approve, reject, and manage all method statements is the reviewer's permission, and covers the tool settings
• Can permanently delete method statements is separate and not implied by managing

Subcontractors need the create permission, because they are the ones who own the method for their own work. The manage permission belongs with whoever is accountable for accepting it. See How permissions work.

WorkflowsHost only

The review workflow is bound per activity type, so a high-risk activity can require a different review from a routine one without either of them being a special case. An organisation can lock the binding so a project cannot override it, which is the right setting where the review is a group policy rather than a project preference.

The run belongs to the submission rather than to the document, which follows from the model above: one document submitted to three projects has three independent reviews, and an acceptance on one says nothing about the others.

Build the reviews in the workflow builder and attach them as described in Binding a workflow to a tool.