Friday, May 07, 2010

Semantics 102: My Control Will Always Beat Your Control

Part of the movement toward the risk factor as a unit of “risk discovery” was a rethinking of what a control really was, and how to best apply one for maximum benefit. The first recognition was that controls have to both discrete and relatable. While those terms often seem exclusive, the real meaning behind such a statement is that no controls should overlap, and they should be self-contained; and that those self-contained (focused) controls have to be generic enough to relate to any number of risk factors, so that when a control is improved, the value of that improvement is spread as broadly as possible across all risk factors affected.

The old controls of traditional safety fail both tests in as much as they tend to end up being so specific they lose any chance of being associated to more than one hazard, and that they are almost always overwritten to end up inscrutable. While not worthy of being listed here, one of the most egregious examples of a traditional safety control was a two-page homily to the hardhat that was so specific it could only have applied to a narrow hazard condition (it specifically mentioned being struck by masonry, and only masonry). It was then edited and maintained against five additional conditions, creating six separate controls of approximately 1200 words each, which were they vaguely applied to all the workers in a way that meant the worker who was conscientious would read the same homily six times, excepting the sentence that specified the actual type of object falling. Of course, these were attached to six separate hazards (one for falling masonry, four for other specific types of falling objects, and one for miscellaneous falling objects). These were then installed in what appeared to be a standard orientation package which was conveyed to the entire set of employees, including office workers. While one might argue value, even a cursory thought inspires one to hear the trainer saying the words, “this doesn’t apply to you, but….”

Controls under our solution-set are not traditional in the sense that they strive to be practical and generic, with little room for overlap. To echo the example about the ubiquitous hardhat, our model would impart it thus: a single control called “wear protective headgear” that might contain a description of the nature of the protection, and a recognition the scope of its application and efficacy will vary depending on the nature of falling objects, etc. This is then linked to any number of risk factors, and when we improve the control (the single control) the associations impart immediate improvements to all associated risk factors.

Of course, this is where the tooling shows its value. Part of the real problem with such a scheme in the past has been the static nature of the protocols for safety. Someone typed them up for a static manual, and then tried to maintain them (tried, and always failed). With better tools, the process is far less cumbersome, because the generation of updates is part of the defined process. It is essentially an automatic value enhancement since the tools track the relationships.

Discrete and simple controls, regardless of tooling, have an advantage – they are easier to convey and grasp. Complex controls increase the time to impart them, and that costs in time and ultimately in money. Just synchronising controls in traditional safety was cost ineffective, never mind conveying them.

No comments:

Post a Comment