In the discipline of Safety Engineering (indeed ALL engineering disciplines) it is vital that all stakeholders share a common, and explicitly understood language. This language, and its lexicon must be unambiguous if we are to accurately, succinctly, and explicitly state ‘who needs to do what, when and why’. By doing so, in turn we can explicitly define ‘what they need, by when, in what format, to what end’…so the interested parties can receive it ‘in the right format, at the right time, for the right means’.
This need for a common lexicon is as pressing within the ‘ivory towers’ of safety science research as it is in the realities of safety engineering practice – not least as it must accurately and succinctly define and articulate the overarching intent and aim of a piece of research, or article of work.
Consider if you will the term ‘framework’…which I had considered to be interpreted (by all) as a ‘structure on which something is built’ (roughly). However, the state of safety science literature considers a framework as either a set of concepts (which I understood combined with categories to form an ‘ontology’), or notations, or new tools, or new models, or a set of principles, checklists, or even an ontology. Separated by a common language I hear you (me) cry…?
Now I know I should have raged against the machine (great band, by the way) and fought to reclaim the term framework…I didn’t. Instead, I have couched my research of understanding safety engineering practice by arguing the provision of a ‘process’, which consists of ‘activities’, which are fulfilled by ‘methods’, for which ‘tools’ may be used.
This specific lexicon is what I want to major on in this article. Process…activities…methods…and tools. Misuse of these words really irks pedants such me, but it is more than mere irritation that motivates this article, as misuse and misunderstanding risk driving potentially inappropriate activities (note the correct use of the term activity if you would be so kind).
For example, a desired activity of safety engineering practice could be the ‘identification of hazards’. A method to identify hazards could be to use a HAZID (for which there are commercially available support tools). Regrettably the terms HAZID (method) and ‘hazard identification’ (activity) are becoming increasingly synonymous, and this must stop. When writing/reviewing your safety engineering processes, you may know what YOU mean by ‘HAZID’ (or perhaps ‘hazard identification’), but does the engineer you wish to carry ‘this’ out share your understanding?
Getting this wrong (i.e. creating ambiguity) could be wasteful at best, and potentially dangerous at worst, because:
- One could inadvertently dictate a specific method is instantiated that is wholly inappropriate for the complexity of the system, and/or the technology used to instantiate the design, OR
- One could actually want a HAZID to be the method of choice, but the engineer chose a different method (that is wholly inappropriate) as they believed that the request was for an activity (and thereby selected a different method from the plethora at their disposal).
Neither outcome is desirable.
So how do we nip this confusion in the proverbial bud? We could do a lot worse than creating a unified language and lexicon, but perhaps a simpler task would be to first ensure that our processes are not conflated with activities, and our activities remain distinct from methods. Until then, please don’t mix up your taxonomy with your ontologies, nor your syntax from your schemas (but perhaps that is better left for another article).