The Paradigm Shifts Toward Risk-Management

If we were to cite a single overwhelming challenge in becoming a commercial powerhouse, it would end up being expressed by something along the lines that what we have in terms of solution-set requires a paradigm shift in thinking before any paradigm shift in operational actions can come about.

Basically, we are in the unenviable position that we are too small to get the message out to a broad enough audience in a short enough time to generate the momentum that comes from a sudden grasp of the opportunities found in risk-management. Perhaps worse, we are trapped in a cycle where momentum is regularly drained by having to redirect limited educational resources toward operational imperatives. When starting a process with a new client has to be deferred to help an existing client find some way to aggregate data from their clumsy information systems, the limitation on our internal resources shows.

If we were a Google-size company, the reality would be different, because scale actually does drive adoption – we would be able to educate through multiple points of contact, on an immediate broad scale, and draw on the necessary commercialisation resources to create buy-in prior to deployment, rather than running these simultaneously and inefficiently. Infrastructure is key to mass adoption and capitalising on a massive untapped revenue stream.

The related problem with this paradigm shifting is that unlike many such shifts, this is a discrete two-stage shift: not only do we need to shift the thinking of the client, but we need to shift their understanding of technical tools. We need them to recognise the serious problems of existing information sources, commit to changing those to better meet their needs, and at the same time commit to using the new tools correctly.

Somewhere in our development we ran into a real conundrum related to dependent systems. We found, for example, that almost no one with a Human Resources (HR) system manages to keep it updated since it tends to be overly complex, and those who do cannot ever get data back from it in a reasonable timeframe. This meant that for our tools to work right, we needed to frequently ask them about why their current tools were hampering them. Try shifting tool use to a new and more powerful level in the face of statements like, “We can’t get a list of employees from our HR system.” Invariably the statement is true just because it actually means, “We don’t know how and no one will show us without extra costs.”

We can be as smart as we wish, we discovered, and even develop the three-step plan toward making the shift to risk-management, but ultimately size hampers adoption. It is very easy to say:

1. View your “safety” as a by-product of normal operational management;

2. View your information systems as a service-points; and

3. Rectify problems with any uncooperative systems before proceeding with the new approach.

Now, try applying those three simple steps when after step one, the overwhelming number of information systems they already depend upon can’t even reliably generate the same list twice. When our tools are deployed, and we hear that our miniscule nod to Human Resources profiling exceeds the value of the enormous system they spent millions on (since from our end they get out what they put in and more), there are obvious barriers to managing step three forward. Abandoning the sixteen million dollar HR system that hasn’t worked right in years is seldom an option, even if it is obviously a barrier to efficiency unrelated to anything to do with risk-management.

Pushing this back in the cycle exposes our main challenge, of course, and HR provides us the perfect example. We have over one hundred various requests to enhance and expand our HR profile model, almost all beginning with statements along the line, “if it just did this we wouldn’t need our old HR system at all.” Try being a gnat in terms of resource scale (or something smaller than a gnat), and hearing that, knowing full well there is no way you can expand fast enough to meet those requests without crippling your ability to deliver what you already have.

To shift someone to risk-management, away from traditional safety, isn’t so much costly as it is complex by virtue of dependencies. Often the first request we make stymies adoption for months, which is, “give us a basic employee list.” The second one, “tell us what their occupations are” invariably slams the process into reverse for a while when clients discover they simply can’t fulfil that demand from any system they have online.

Of course, if we had the scale to educate ahead of the deployment curve, expand to encompass the minor variations that prevent just replacing antiquated systems wholesale, and the reach to attack multiple client targets simultaneously this two-shift process would become a single longer curve.

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.

Semantics 101: My Risk Factor is Not Your Hazard

We began our journey many years ago focused on the idea of hazards, and over time began to reject them as limiting not because the term itself isn’t descriptive, but because traditional safety practitioners had a weird belief that hazards were what they claimed them to be, rather than what the word implied. In essence, the term came to be so restrictive and categorised as to become almost useless as a management tool. And while the best safety managers always viewed this suspiciously, the larger industry embraced the limitations of the hazard to excuse bad practices. We eventually rejected the term hazard not because it was wrong but because it had been co-opted to explain away failures of management. We introduced in its place the more generic term “risk factor.”

Part of the drive to escape the focused term hazard was that because of its common use for so long it had become too subjective. It obscured the fact that operational risk-management was about managing risks, not perceived hazards, which had by the time we walked the path of the risk factor been relegated to symptomatic expressions rather than causal ones. Prosy terminology aside, what we were discovering was that people actually expressed nonsense like “hard hat hazard” as if it meant something intelligent, forgetting that what they were actually describing in such a statement was a control of sorts. How could anyone apply controls to “hard hat hazard?” The obvious one, of course, was “wear a hard hat.” But then you create a peculiarly awkward construct to describe the actual risks someone can encounter, because you are simply stating the control twice in a clumsy way. This imprecision was rendering hazards useless as control envelopes.

Under the changed model we began to construct we used the term “risk factor” precisely. We could then say something like the risk factor is “falling objects.” Part of the control set for that becomes “wear protective headgear.” This separating effect has a further value in that now that we have a generic risk factor for falling objects we can actually describe a real “hazard,” without imparting clumsy associated control. We could say, for example, “This project site has a falling objects risk, and all controls to avoid or suppress that risk upon encounter must be obeyed.” Fancy as that sounds, it is significantly different from saying, “hard hat hazard,” which implies little of value and limits us to a control that is probably always going to be inadequate. There is, in essence, no way to contextually qualify that “hazard.”

Contextual qualification was a breakthrough we all knew about for at least a decade, and one of the dirty secrets of the safety industry. It is what leads to safe practices manuals where the same basic control is listed fifty times under fifty separate hazards. It is what makes managing the documentation almost impossible, and keeping it updated practically impossible. Every time a basic control (wear a hard hat, perhaps) was tweaked, the manual was changed in fifty places or became contradictory. Worse, this lead to improper aggregation of protocols for safety – who wants to maintain a separate manual for every occupation?

By divesting the hazard term, which was really a rejection of how it was being used, we created a model where we could focus on actual risk factors (things that impart risk), and apply controls to them in a rational way. So, in our “falling objects” risk factor, we end up with controls that are far more effective by being rationally comprehensive. We have the standard “wear protective headgear,” and perhaps also “ensure posting signs” (and more) to guarantee when the risk is actually extant the entire spread of controls is applied.

The proof of this semantic shift is easily found in asking a worker one of two questions. If you ask, “What hazards do you face?” the response will be mostly mechanical, and almost never go beyond direct physical risks. Ask them “What risks do you face?” and they will almost always include a broader range of management opportunities. The reason is simply that years of traditional safety has reduced hazards to some specific meaning, and the term risk is considered broader.

Another side-effect of focusing on risk by way of the “risk factor” is that the control sets are not only broader, but the imparting of the knowledgebase is made easier. Worker orientation can be more easily broken into risk exposure based upon demands via job tasking, and even by project sites, etc. So, instead of handing someone the five-hundred page manual they will never read, you hand them a list of risk factors they are likely to face, followed by a reduced list of controls. This reduction comes through both the use of something called synonymous risks, and via the discrete association of controls of like form. Or, in English, if six risks they face require them to wear a hard hat, that control is mentioned once rather than six times under six different sections. Less is more, when the reduced controls focus the workers on actual compliant behaviours.

This also increases the opportunity for competency to generate qualified feedback. A worker exposed to a limited expression of their risks based upon job tasks is going to see the missing elements instantly, rather than have them obscured by five-hundred pages of repetitive drivel. And when seen, the culture that generates job-focused risk awareness will be such that the worker will reveal the deficit, leading to better controls that suddenly express themselves across the entire organisation.

“Hazard” is simply too tired a term to encompass the value found in the idea of the “risk factor.” We abandoned it because it rejects returning maximum value.

Training as a Control Mechanism

One of the focal points of any solution-set for better safety is always training, and risk-management is no exception, though it has the unique recognition that training is a control mechanism and not something in and of itself any different from a physical control. Yet given the supreme importance attached to training, our direct experience has been that we have never yet dealt with a company that can produce a valid set of training records on demand, either because they cannot be validated, or in some cases because the data simply doesn’t exist. What they can do is produce plenty of spreadsheets, though none of them are related or even passable as proof of anything.

We call this basic problem with proving training metrics evidence a company relies upon the “safety ACE.” That is, expanded, the “safety Ass-Covering Effect.” And companies that rely upon the safety ACE invariably have a challenge when a disaster strikes, forcing them to create evidence to support the low-quality data they have available. At best they can provide anecdotal evidence, and at worst they intentionally manufacture supports for claims of training that cannot otherwise be relied upon to have been true. The argument against such a statement is the existence of certificates, but the reality is that the assumption of validity is the problem. Is the certificate real, proved and validated to the present workplace environment?

Training is one of the most costly elements of any safety program, and the most useless of most, since training tends to be reactive or regulatory rather than productively defined, and training tends to be inconsistent by the very fact it ends up applied in bulk. After a serious accident, how many times has a review of training data shown that while all employees had some hare-brained course or other, not a single one had any training that could have turned a serious accident into something mundane? How many times has an investigation revealed that the nine apprentices were waiting on training that got pushed back by some horrifically inappropriate budget gaffe that resulted from mass-applying training the last accident improperly defined as critical? How many times has a deep investigation shown that the workers affected had never heard of half the safety protocols they were supposed to follow, because no one had ever cracked the miraculous five-hundred page manual for operations?

Training is almost always governed by perceived business needs rather than real business needs. After an embarrassing accident, you can always see a company scramble to “refresh the employees on safety protocols.” These knee-jerk reactions happen because the perceived business need is to rectify the effect of the accident, and almost never in deep analysis does the reaction address the underlying cause. What is the point, after all, of spending a hundred thousand dollars refreshing all employees on the use of harnesses, even to the point of showing them how to put them on to prevent high-fall deaths if a proper investigation observes the dead worker wilfully ignored the rules? Wilful ignorance as a cause for violation of basic safety protocols is no reason to show people who already wear their harness how to put it on. Harsh though it may be, that is money ill-spent.

Understanding cause is the main problem. What is good for a business, what it needs, is to understand the cause of an effect, not react to an effect. It is no more suitable than treating a symptom of an illness rather than the illness itself.

Training has to be viewed as a control mechanism to provide effective suppression of negative outcomes when risks are encountered, or to provide risk avoidance opportunities. That means training has to be focused, has to have measureable effect, and has to address actual underlying causes. Otherwise, you are training at a high cost to scattered effect, and you can never measure it against the outcomes you experience.

What is most peculiar about training is that traditional safety considers it an activity despite all the evidence that activity counts have no impact on bottom line results. Traditional safety would ask, “How many people were trained in harness use and maintenance?” Risk-management would ask, “How many people who required the training got it in a timely fashion, and based upon recent incidents how likely is it a refresher would reduce those incidents?” Traditional safety uses counts and has no metric to impart a value return indicator; risk-management applies training as a control, and consequently measures against actual outcomes.

Traditional safety cannot apply training as a control because it maintains an ignorance of the causes that motivate focused training. The answer to why training is done is almost always, “because it is regulated, or required.” Asking even the one further question (“Why is it required?”) produces a baffling silence in almost every circumstance.

Training is a control mechanism, and in risk-management it produces results by being focused, measurable, and reinforcing of productivity.

Resources…Where Art Thou?

Resource dearth is something we, as a company, have suffered so regularly we often chuckle at the fact we have survived at all. At the same time, we have learned a lesson along the way that directly affected our solution-set: resources are the key reason for safety failures, either because the resources are lacking or, more often, because they are misapplied.

If the emptiness of words gets in the way of correct actions, and mistaken focus on the wrong details drives resource scarcity, the real killer for most unsafe workplaces (in the literal sense) is that the human beings applying the resources are doing so poorly. Even the best safety personnel do so, because they are applying them almost always in the near timeframe, often reactively, and almost never with any ability to directly connect the outcomes with valuable metrics.

Try selling any system to an executive who manages on quarterly returns (almost all in this age), where the execution is being left to a group that is viewed as pure-cost. Even asking for a hundred thousand dollars to deploy a perfect solution exceeds tolerance when that hundred thousand dollars is viewed as being thrown away in a pure-cost activity. Take a qualified, capable, smart safety person into the position of having to manage a group that has been reactive for years, and no one would envy them the task of selling that this time it will be different. It is no wonder that status quo is so acceptable, given the focus ends up being cost suppression rather than operational risk suppression.

The reality though is that resource dearth is often illusionary, since we hear people say “it costs a million dollars to do safety right.” The entire statement is flawed deeply because it creates a mistaken view that safety is done. It will always cost endless millions to pour money into a false process, because ultimately you are not building anything to return value. You are pouring cash into a money pit. Lack of metrics does that every time.

The actual resources to implement risk-management are significantly smaller than maintaining status quo safety, because risk-management is an integrated process model – it makes safety a by-product of required operational management that has inherent value outside “safety.”

We have been guilty of saying aloud, “Safety personnel need to focus on important realities, not fumbling in the dark.” The first step to refocus is to recognise that safety isn’t a process, but the outcome of the larger process of risk-management. As soon as that happens, we can observe three factors that come into play to reduce resource consumption: first, you can measure value returns, meaning you won’t continuously expend resources against poor value; second, you raise the profile of the safety concept to engage all operational management aspects, reducing the workload at any one point and enhancing the productive shared value; and, third, you commit existing resources so much more effectively the trend is toward cost reduction over time, often rapidly, since the entire organisation creates a self-reinforcing model of operational risk awareness and management.

It is easy to forget that all of it boils down to a simple statement: the resources already exist to risk-manage because more is spent on crisis handling than will ever be spent of avoidance and suppression. The simplest proof of that is an example found in a single fire extinguisher. You invest in an extinguisher to put out fires, not because you expect a fire, but because when one happens it costs many times more than the cost of being prepared to put it out.

The ten minutes a safety person spends on meaningless paperwork rather than actually conveying knowledge is wasted time, because the return on the time invested is not measurable. The same ten minutes spent talking to a supervisor about new ideas for reducing a primary workplace risk, and asking them to put their ideas down in writing for distribution is invaluable – and if even one accident is avoided by it, you can measure the effect. Accountability imparts trust, and trust develops a relationship model where the resources wasted in pure expense today are deployed to prevent losses tomorrow.

Unlike our experience, which is that resources are simply not easy to generate, most of the client companies we have dealt with (all, in fact) have fallen into a resource trap where they spend enormously to stay in the same place, avoiding disaster more by happenstance than planning for better controls. They tend to be stunned when the disaster strikes, though predictive analysis of their systems always makes the failure inevitable – when analysis has any data to be performed upon.

Outside the idea of pure costing, the resource being cash, our experience has created a strange awareness that another enormous resource is ignored, and in fact often creates even higher cost/loss ratios. This is the knowledge base that can be generated by risk-management. The creation of safety as by-product is achieved by generating data that can be analysed to focus resource application, and that cycle creates consistently higher quality data that can be used to manage risks more effectively over time.

We have yet, in a decade of analytical effort, to encounter a single company that can quantify what their employees actually do. In most cases they cannot even list a set of occupational names that makes rational sense. In many cases the list of “occupations” will number in the hundreds for workforces that number in the hundreds, with dozens of variations, making or thousands of scraps of paper that cannot even be related, let alone analysed. Even when those occupations can be quantified, the quality consideration that comes into play is instructive: almost no real description exists to assist Human Resources in hiring personnel to positions, creating a pre-hire analysis fault, increasing the risk of untrained personnel on the operational floor. But then again, since we have yet to find a single company whose training records are even accessible, let alone probably correct, perhaps this is an irrelevant concern.

The point is that resource dearth can be real, but it is almost always imagined in the realm of safety. It isn’t that resources don’t exist, but that they are misapplied, immeasurable as to effect, and represent a pure irrecoverable cost of operations.

The Hard-Sell of Risk-Management?

The real challenges of deploying the solution-set we created, through so much research and development, breakdown into a few specific extant realties:

· Management by verbiage is so common that the words defy any action being taken that proves the lies accepted, and there is a serious fear factor because executives who know something is amiss are often convinced the “safety group” is best left buried in shadows.

· There is so much mistaken focus on irrelevancies in safety that shifting the thinking of people to grasp the larger context of how safety comes from risk-management is often impossible, and because resources are so poorly expended in that context there is a real resistance to exposing the grievous failures of the past and present.

· There is such an obvious misunderstanding about how safety is created and by whom that the end-result of any discussion is that it is nearly impossible to get to the right people in a reasonable amount of time.

One of the most distressing aspects of our movement away from the purer research and development of the product-set has been deploying it. Even when we have an eager, accepting company, we have found that it can take endless months to get past the “safety personnel” to the people who can make the change function. In the past, so many predestined failures in the shifting safety landscape have created a “don’t bother me” attitude at the executive levels that the idea is seen as another “flavour of the week.” So, even when a good safety manager wants the change, one who actually understands the paradigm shift as necessary, they have a serious challenge climbing into the executive suite long enough to identify the value for their top-level managers.

To change someone from a reactive crisis model to actual risk-management is also troubled by the fact that the lies being told crumble the instant the depth of crisis is exposed. We have had direct problems that highlight the awful management that seems to extend into almost every aspect of even well-managed companies. The most frequent barrier to adoption to the idea of operational risk-management is that the entire process can come to a dead stop as soon as the question, “Who works for you and what do they do?” is asked. Getting an employee list from any company, large or small, is almost impossible; and getting one that actually is right is impossible. In over a decade we have yet to receive even a basic list of worker names that has been correct on the first try, with the average number of cycles to get anything even reasonably accurate being four. That means, operationally, no one is even able to generate a reliable list of worker names; it is no wonder when serious disasters occur, we hear phrases like, “the missing employees have not been identified.” We used to believe it was to assist contacting families, but experience has proved the actual problem is more basic – no one can reliably place a name to the body.

When the executive is onboard the process is not necessarily much smoother, because often they rapidly receive the hard education about how poorly structured their company is. We have occasionally had executives red-faced at the realisation no one in their Human Resources group can produce a list of supervisors and subordinates, or even tell them with reliability what someone was hired to do. When this happens the problem presented is that even if the executive is desirous of making safety extend from management processes, they have to recognise the deep flaws in their general management of information cripple the deployment. This failure-by-a-thousand-cuts scenario makes deploying our solution-set sometimes impossible, and always time-consuming.

To deploy the solution-set then requires education first, and that creates a bizarre situation where our raw time investment often exceeds the value of the contracts given that we can seldom sell an entire enterprise in the first deployment exercise. (We could try, but past efforts have exposed another conundrum, which is that internal information systems are usually so bad that attempting to deploy to a complete company, even of a few hundred employees, creates a deployment track with no reliable timeline – people simply cannot gather basic information.)

Risk-management itself is an easy sell, though, which is an oddity given how much resistance meets the deployment of the same within an enterprise setting. It is easy to get almost every listener to nod to a statement along the lines: “We are talking about a management model that identifies and manages operational controls on a per-risk basis, and scores the risks against your actual operations, which allows you to plan resource applications and measure those results over time, creating cycle of improvement where your highest risks are suppressed most aggressively in a fairly short timeframe.” No one argues the wisdom in that statement, which is a single sentence that actually describes the broad concept exactly.

The resistance begins as soon as the first of many barriers is encountered, when everyone in the communication chain hears something along the lines, “Your multimillion dollar Human Resources system hasn’t been able to give an updated, correct list of employees in the six months since deployment began; your safety personnel cannot find training records for the last five years to confirm the spreadsheet they have that purports to track training; and historical data for incidents appears not to be available, at all, for certain spans of time.” The effect of any statements along those lines is devastating, because while any of them can be surmounted, the reality usually sinks in that the core problem faced in implementation is not with our method or our solution-set, but with generic information systems it depends upon to function.

It is almost impossible to maintain momentum without heavy direct support, and for a company consisting of four bodies, this severely limits simultaneous client deployments. Because of this, the chicken and egg cash flow problem always drives the company in jumps and starts, with almost no room for investing in the resource expansion necessary to harness multiple client deployments.

Executives are willing to expose the lies in the words tossed inside their company if the end result is an improvement that can be measured, but they are resistant to exposing their company to ridicule when the process itself reveals the deep flaws in their overall information management substructures. Ultimately, to engage and maintain their momentum requires direct application of expertise we have, but that in turn limits us as a company, creating a preferred client status for the clients we have, but ensuring our growth curve as a company remains abysmally shallow.

The hard-sell is all about resource dearth.

Misunderstanding Who “Creates Safety”

A fundamental challenge of selling a validated management methodology for risk into any enterprise is that almost universally there is a deep misunderstanding about who “creates safety.” The most basic mistake , believing that safety is more than a side-effect of management is a complex enough misunderstanding to overcome, but when combined with an ignorance about whose authority, responsibility and opportunity it is to engender the creation of safety, we see an almost intractable resistance to actually implementing an effective management model.

A frequent refrain heard in safety circles is that safety begins with the frontline workers, but the problem is that the statement is misdirected. It is entirely true that the actions of the frontline operational employees will dictate the safety of the workplace in a practical sense, but it is truer still that those employees will execute their workplace duties not based upon some grasp of an obscure set of rules and regulations, but within the context of the culture of the workplace. So, in essence, while safety results from their actions, their actions are predicated upon what they believe is acceptable within their workplace culture – or, put bluntly, safety expectations are dictated from the top.

If you want evidence of how unsafe workplaces are, and why, you can watch any episode of a half dozen or so “reality workplace programs.” A recent one about ice-bound oil fields racks up a half dozen life-threatening acts of faith in the first ten minutes or so of the initial episode, where we witness employees behaving in a cavalier fashion around machinery that could kill not only them, but their coworkers. While never asked to explain themselves in context of unsafe behaviours, the repeated queries throughout obviously are about the “hard drive” to “get it done.” These are invariably tied to productivity, though usually with appropriate pithy phrases. You never hear the words, “I am willing to risk myself and my coworkers doing something patently stupid on camera, because my employer condones this stupidity to reduce the cost of producing the end result.” No one would allow that past the editing booth, though translated that is always the fact being used to excuse foolish unsafe behaviour.

To adhere to the myth that “safety is created by frontline employees,” you would have to believe that not a single such worker has any interest in safety, surviving their workplace, or living long enough to see their children graduate pre-school. Since it is unlikely that such disregard for life and limb is somehow universal, it raises the question why then we see so much operational chaos? If the frontline is the safety generator, why is it so common to see behaviours that enhance risk so dramatically?

The reality is that the problem lies above the frontline employees.

One of the main challenges in safety groups is that the de facto ‘safety manager” is not a professional manager, of safety or otherwise. They are generally people who were promoted up into that position, often with a world of practical experience but with no training on how to manage. Consequent to that there are two failures evident in groups where that is true: the first is that the safety supervisor is generally focused within the frame of their personal experience, or, put in simpler terms, knows only the risks within the scope of the experience they gathered through their immediate past experience; and, in the second place, the group is reactive, because there is no management experience imparting an ability to manage scarce resources, plan effectively, or otherwise avoid crisis reaction becoming the principle stance. The reaction to this, a recognised problem, has of course created the opposite problem in some enterprises, where a safety supervisor with no actual workplace experience sits in an office doing paperwork with no contextual understanding of the scope or risk, its position within the company, or its true potential for exposure and injury.

Blaming the “safety manager” for the failure of safety systems is problematic when they are disarmed from the outset by a lack of appropriate professional standards, or a dearth of experience. The problem lies above this rank.

The problem is cultural because it is imposed from the highest management circle of any company. Based upon past cost performance, safety is often viewed as a productivity drain, largely because risk has never been managed at the operational level. What has happened in the past is that costs associated to “safety” rose out of proportion, always, because the resources were distributed reactively. Post-accident, for example, one might suddenly feel the need to refresh certain training, and because the pitch of fear about it is so high, the budget gets expended to achieve a refresher there, wipes out any planned management activities that might have enhanced safety, and drives the next accident. Any executive who sees this cycle from the outside-in blames the concept of “safety” for two reasons: first, they perceive what they do see from the group as busy work (piles of regulatory compliance paperwork with no essential internal value); and, second, they perceive repetitive cost overruns that produce no long-term benefits. It is no wonder they ignore the “safety” groups.

The buck actually does stop at the executive level, in all cases, but the problem is that even the most well-meaning executive is frequently facing such an obtuse mess when judging ‘safety” that they can hardly be blamed for devaluing what they see.

Safety extends from management activities not terribly different than those a good corporate accountant deploys to plan for operational matters. The problem is that safety has shot itself in the temple with such regularity, by adhering to practices that guarantee it is always in crisis mode, and so has never shown any ability to manage. Even clumsy attempts to manage end in costs that exceed measurable value, almost always, because the metrics matrix is unclear. A frightening ignorance about cause and effect cripples the ability to measure resources against results.

Safety is created when five realities exist for a company:

· Executive management rejects the idea that safety is a process, and understand it as an outcome of a management process;

· Executive management continuously demands better communications, and requires metrics that show value from the management process that imparts safety;

· Mid-level management grasps that operational productivity is directly tied to the same management processes that impart safety, and views these processes as integrally bound;

· Safety personnel recognise their experience is limited, seek frontline operational cooperation to understand risks of operations, and refocus their efforts on managing to avoid risk encounters or suppress outcomes of risk encounters; and

· Frontline workers recognise that controls (safety rules and policies, training, etc.) are being applied to mitigate real provable risks, know management recognises these controls enhance productivity, and feel comfortable contributing to the productive model by enforcing and enhancing controls actively.

An enormous amount of lip service is paid today to the idea of teamwork, and the sad reality is that teamwork is usually superficial, or, quite often, pure fantasy. And yet risk-management, which produces safety as a by-product of its application, is an example of when true teamwork counts.

In every organisation we have reviewed, we have found that real safety is generated not by a policy manual, but by engagement at all levels of management and operations. The engagement factor dictates productive enhancements, and makes it possible to manage risk rather than react to crisis conditions. The former prevents egregious failures, and the latter only creates the environment to produce continuous cycles of collapse.