Conventional safety techniques assume a causal chain of events -- driving the forklift truck too fast caused the driver to hit the pedestrian, causing the injury. A simple investigation determines the cause was the operator driving too fast; a risk assessment determines what is needed to prevent that happening (speed limiters, supervision, inspection).
FRAM (the functional resonance analysis method) was developed by safety academic Erik Hollnagel to assess systems that are non-trivial and non-linear. In two scenarios the same thing occurs, but in the first it does not cause an accident -- driving fast ensures the order is delivered on time, and no one is hit; and in the second there is an accident.
The term "resonance" is more often used when talking about physical systems. A child on a playground swing learns quickly that if they kick their feet at the right moment they can extend the height of their arc. The child has found the swing's resonant frequency.
Hollnagel does not argue that accidents are random, but that often the resonance has not been foreseen
Hollnagel does not argue that accidents are random, but that often the resonance has not been foreseen. We don't understand enough about how materials and people will behave in extreme conditions, or how that behaviour changes over time. Functional resonance arises from the normal ways a system works and can be better understood if we stop looking for the "root cause" of the accident.
"We have used FRAM to help organisations who wanted to understand why they were continuing to have incidents, despite a heavy investment in resources and despite best efforts to prevent drift into unwanted outcomes," says Helen Rawlinson, managing director of consultancy Art of Work. "FRAM helped them to understand the variance that exists in their normal working operations, not as a means to control, but to learn what the dependencies are and to understand how well-supported people were, or were not, to the variance in their work activities."
If you were drawing a standard flowchart, each function would be drawn as a box with one or more input and output. In FRAM, each function is drawn as a hexagon (see figure above), and can have four further aspects as well as inputs and outputs:
Precondition -- a system state that must be true, or conditions that must be checked before a function is carried out. Though an input activates the function, the precondition doesn't.
Resource -- something needed or used up when a function is carried out, such as energy, information, competence, tools or people.
Control -- something that supervises or regulates a function so that it results in the desired output, such as schedules, procedures, our own or management's expectations about how to do something.
Time -- though it could be considered as a resource and as a control, time has a special status. It can describe the order in which functions must be carried out, or that a function has to be started at a stated time, after an elapsed time, or completed before a particular time or within a stated duration.
Not every aspect must be described for every FRAM function, but each function will have at least an input or an output. The resulting FRAM diagram (below) can look like a particularly messy spider's web -- less tidy than fault and event trees -- but a better reflection of the complexity of real systems.
Rawlinson is convinced of the usefulness of the technique. "FRAM has successfully boosted the capacity of organisations we have helped and we continue to watch teams become more aware of the issues that exist before they become problematic."