Treat near-misses as free lessons. Define what to report, take immediate actions, and follow a notification tree. Capture evidence/statements (716), run root-cause analysis, and implement corrective actions that tie back to RAMS (722), LOTO (725), and interlocks/controls if relevant (352, 342). Verify fixes, respect timelines, and retain records so HVM bollard reliability and crash-rated bollard compliance improve over time (719). Include one-sentence context that naturally links upward to the parent hubs (this section and the chapter hub). Add SIRA context with a link to SIRA Bollards (UAE) when relevant. Link installation pages only if helpful: What to Expect and Installation Guide.
727.1 Definitions
Clarify incident vs near-miss vs hazard. Clarity increases HVM bollard reporting.
An incident is any unplanned event that results in harm, damage, or significant disruption. A near-miss is an unplanned event that could have caused harm but did not—these are gold for prevention. A hazard is a condition or action with the potential to cause harm. In the context of interlock matrices (352) and control logic (342), label events precisely so engineers can trace them to states, inputs, or operator actions.
Define scope upfront: construction vs operations, public interface vs controlled works, and whether the event touches HPUs, energized panels, lifting plant, or traffic control. Clear definitions reduce debate and speed learning.
| Aspect | What matters | Where to verify |
|---|---|---|
| Performance | Tested system (bollard + footing) | Global crash ratings |
| Operations | Duty cycles, fail-states, safety devices | Installation Guide |
727.2 Immediate actions
Make safe, first aid, isolate (725). Actions contain crash rated bollard risk.
First, stop and make safe: establish an alarm/annunciation path if present, set an exclusion zone, and halt movements. If anyone is injured, provide first aid and summon medical support. Then perform LOTO and zero-energy verification on panels, HPUs, or drives.
For public-interface events (e.g., a tripping hazard at reinstatement), use temporary controls that match your reinstatement plan (629). Record any change to bollard state, including E-Stops, manual releases, or gate closures, in the site diary (729).
727.3 Notification tree
Who to inform, how quickly (131). Tree accelerates HVM bollard response.
Trigger a simple, time-bound notification tree tailored to the site. At minimum: site supervisor → project manager → HSE lead → client representative. Add specialist nodes for controls faults (controls lead) or civil works (site engineer). Align response times with stakeholder responsibilities (131) and include an escalation path for unacknowledged alerts.
For events with regulatory implications, pre-flag who informs authorities and who prepares the formal report (see 727.8). Keep contact lists current in the file index (911) and embed them in the Method Statement (721).
727.4 Evidence capture
Photos, sketches, witness statements (716). Evidence supports crash rated bollard learning.
Capture evidence while conditions are fresh. Use the Evidence Capture Standards (716) for wide→detail photo sets, timestamps, and geo-tags. Sketch the scene showing bollards, lanes, signage, and approach vectors; attach panel logs and first-out alarms where controls are involved.
Take short, factual witness statements (who/what/when/where). Store everything against a stable event ID and file path per File Index & Naming Rules (911). For damaged assets, reference post-incident inspection (735) and raise an NCR (719) if criteria are met.
727.5 Root-cause analysis
5-Why, fishbone, timeline. Analysis prevents repeat HVM bollard failures.
Use proportionate tools: a quick 5-Why for simple cases, and a fishbone (Ishikawa) for multi-factor events (people, process, equipment, environment). Build a timeline from evidence and SCADA/BMS logs (533) when controls are implicated. Tie every causal factor to a specific control, interlock, or procedural gap.
Summarize with a one-page bowtie or fault-tree if helpful. Link findings to the risk matrix and update RAMS (722) so residual risks and mitigations are explicit for similar tasks.
727.6 Corrective & preventive actions
Assign owners, deadlines (719). Actions harden crash rated bollard processes.
Record containment actions (make safe now), corrective actions (remove the root cause), and preventive actions (stop recurrence elsewhere). Assign an accountable owner, due date, and verification method per NCR workflow (719). If controls are affected, update the Change Control & Versioning plan (537), refresh the FDS (711), and revise the SAT script (638) where needed.
Document training or signage changes and push updates to the O&M manual (733) and Client Training Plan (737).
727.7 Communication & briefing
Share lessons in toolbox talks (723). Briefings uplift HVM bollard culture.
Convert lessons into a short toolbox talk with photos, the key “avoid” and “do” points, and any changed steps in the MS. Capture attendance with the PTW & Toolbox Talks page (723) forms. For operator-facing sites, add concise HMI prompts or operator recovery hints to reduce repeat errors.
727.8 Authority reporting
File statutory reports where required (133). Reporting protects crash rated bollard compliance.
Some jurisdictions require formal notification for injuries, public incidents, or certain utility strikes. Check your project’s authority variations (133) and include local steps (e.g., Dubai SIRA context for security sites). Keep submissions consistent with your Authority Submittals pack (717) and maintain the transmittal log (917/938).
727.9 Closure & tracking
Close actions; verify effectiveness. Closure sustains HVM bollard improvement.
Use a simple register: event ID → status → owners → due dates → verification of effectiveness. Link every closed item to evidence (716), updated RAMS (722), and NCR disposition (719). Summarize trends monthly and feed systemic lessons into Common Pitfalls & Lessons (844). Archive per your retention policy (739).
