Most SMS documents are written to satisfy a regulator or a corporate template, then filed away until the next audit. A management system only works if the people executing the work recognize themselves in it, if the hazard analysis reflects the actual job, not a generic version of it.
This isn't a document library assembled from a template. It's built section by section around the operation it needs to govern, informed by nearly three decades of having worked inside the operations these systems are meant to protect.
Management systems written from a template, then filed away until the next audit
Hazard analyses that describe a generic version of the job instead of the actual one
Systems built around corporate liability instead of the conditions crews actually operate in
No clear owner for keeping the system current as equipment, personnel, or operations change
“A safety program only works if the people doing the work trust it. Systems designed around real operating conditions get used. Systems designed around corporate risk get filed.”— SMS Design Practice
Closing that gap takes someone who's worked the job the system is supposed to govern, not just written about it.
That's the difference between a system built to satisfy an auditor and one built to actually run your operation, and it's the difference every SMS build at Black Swan is designed around.
Every SMS engagement follows the same sequence, so the system reflects the operation, not a template:
Understand the actual job, equipment, and hazards before writing a word of the system.
Construct the SMS around real operating conditions, grounded in HOP principles.
Establish who owns keeping the system current, so it doesn't go stale the day we leave.
This is a complete SMS engagement, not a document handoff. Specifically, that includes:
Full operational discovery across the phases your SMS needs to cover
A written management system built or revised section by section
Field validation: checking the system against a real shift before calling it done
Training materials to introduce the system to your team
A defined ownership plan so the system stays current after handoff
Either. Some operators need a full build; others have a reasonable foundation that needs the gap between paper and practice closed. The initial review determines which.
It depends on scope and the number of operational phases covered, but most engagements run several weeks to a few months, not a single deliverable dropped after one visit.
Sometimes, but the goal is a system that matches how work already succeeds safely, not one that forces an unfamiliar process on top of it.
No. Many operators start with the highest-exposure phase and expand the system from there rather than trying to build everything simultaneously.
In most cases yes, since the underlying content overlaps significantly. We'll flag anywhere a specific third-party requirement needs additional documentation.
That's what the ownership plan is for. It defines who's responsible for updating the system and how often, so a change in equipment or personnel doesn't make the SMS stale on day one.
That's available if useful, but the system is designed to run without ongoing dependence on Black Swan. Ownership stays with you.
Every engagement starts with a direct conversation, not a proposal. Tell us what's happening and we'll tell you what we'd actually do about it.