Report & learn · Process guide

Root Cause Analysis & Action Plan

After an incident or serious near miss, teams need two outputs: a clear view of why the event was possible, and an action plan that changes conditions — not only a reminder to be careful. This guide moves from facts to causes to owned, verified actions.

Purpose

Root cause analysis is a structured way to move past the first convenient explanation. The action plan is how learning becomes less risk next week: owners, dates, definitions of done, and proof that fixes held. Together they turn reporting into improvement instead of paperwork that dies in a folder.

When to use this depth

Use a full RCA and action plan when harm occurred or was narrowly avoided, when the same pattern repeats, when high-risk work was involved, or when leaders need a defensible record of what changed. Smaller events can still use a short cause note and two or three actions so learning is not lost in chat threads.

Step 1 — Protect facts

While it is safe, capture time, place, task, roles (not blame theatre), equipment, environment, and what was supposed to happen versus what did. Photos, sketches, and a first-person timeline beat memory a week later. Separate observation from interpretation in the notes. Store the first report so you can see how understanding evolved.

Step 2 — Build a timeline

Order the work from normal to the event. Mark decisions, handovers, delays, and missing controls. Gaps in the timeline are clues: missing permits, skipped checks, unclear ownership, or tools that were usually fine until they were not.

Step 3 — Find system causes

Ask why each critical step failed until you reach factors the organisation can change: design of the job, staffing, procedures as used (not only as written), maintenance reality, procurement, planning pressure, layout, or training that never matched the task. Human error can label the last act; it is rarely a complete cause. If the only idea is retraining, keep digging.

• Prefer causes you can act on within a realistic horizon.
• Name conditions that made the error easy or likely.
• Avoid vague slogans such as lack of awareness without a controllable mechanism.

Step 4 — Draft the action plan

Every action should answer: what will change, who owns it, by when, how we will know it is done, and how we will verify it still works later. Prefer stronger controls where realistic (remove the hazard, redesign the job, engineer a barrier) and use procedures and PPE as support — not the whole plan.

Step 5 — Immediate vs longer work

Split the plan: controls that reduce risk before the next shift, and projects that need budget or design time. Do not leave people exposed while a perfect project waits. Park big ideas so they do not block simple fixes that can land today.

Step 6 — Verify and close

Close actions when verification is recorded — a photo, a walk-down, a revised checklist in use — not when the email was sent. If the same near miss returns, reopen the cause and strengthen the action. Feed stubborn patterns into planning, design, or contractor controls.

Worked mini-example

A pallet jack clips a pedestrian route. First story: operator was not looking. Timeline shows peak dispatch, a blocked mirror, and temporary storage that narrowed the aisle for three days. Causes: layout change without a walk-through; no temporary barrier rule; pressure to clear trucks before break. Action plan: restore width same day (shift lead); cone standard for temp stacks (area supervisor); aisle check after layout changes (supervisor); staggered release trial for one week (dispatch) — each with a verification date.

Who should be involved

Someone who does the job, someone who owns the area, and someone who can change conditions. A neutral facilitator helps. Keep the group small enough to finish in a working session. Large committees often produce vague actions nobody owns.

Timeboxes

Aim for a first-pass cause picture within days for serious events, not months. Immediate controls can land before the full write-up is pretty. Schedule verification dates when actions are set. A review with no calendar becomes archaeology.

Share learning

Publish a short note: facts, causes, actions, what others should watch for. Avoid naming-and-shaming. If people believe RCA exists only to punish, reporting dries up and the next event arrives without warning.

Common failure modes

• Stopping at the first convenient cause.
• Actions with no owner, no date, or no verification.
• Copy-paste retrain all staff for every event.
• Investigation so slow the job has already moved on.
• Reports that never reach the crews who do the work.

One-page checklist before you publish

• Facts and timeline separated from opinions.
• At least one system cause named.
• Each action has owner, date, and verification method.
• Immediate risk controls in place even if longer projects remain open.
• Learning note ready for the floor.

Link to everyday reporting

Cause reviews starve without decent inputs. Capture facts early in incident and near-miss forms: conditions, sequence, photos, and what stopped the situation from being worse. When reports are thin, investigations become guesswork. When investigations only punish, reports become thinner still.

What this guide is not

Not a jurisdiction-specific legal pack, not a requirement to use one branded method, and not a compliance guarantee. Match depth to risk and to your organisation rules; keep the spirit: facts, system causes, owned action plan, verified close.

Evidence habits

Photos, permit copies, training records that show what people actually received, and maintenance logs beat slideware. If evidence is missing, say so — that gap may be a cause of its own. Write the action plan so a stranger could verify it next month without calling the author.

Keep the plan alive

Review open actions in the same meeting where you review incidents. Overdue items without a new date are theatre. Celebrate verified closes the same way you would recognise other safe work so follow-through stays visible.