"We are becoming, whether we want to or not, an electronic, data-based workforce," says Martin Brooks. "In the past safety and health managers have recorded cryptic records on paper, stored them in three-ring binders and left them to rest on dusty shelves, like precious ancient scripts, until something goes wrong and we need them. Safety and health information needs to be made available for others to use, review and feed back on its effectiveness."
Brooks is a consulting safety and health manager, and was involved in developing a helpdesk system for managing safety issues and facilities functions for local education authorities.
He is right that the familiar safety and health arrangements based on paper-based assessments, checklists on clipboards and meetings to chase accident reports and outstanding actions are passing.
A minimalist approach to digitising safety and health management systems has come about. Documents are produced in Microsoft Word, actions are tracked in Excel, and communication is by email. Some organisations have shared these virtual documents using collaboration tools such as SharePoint or Google Docs.
Smarter organisations have gone further and built or bought in systems that use workflows to integrate safety documents and actions. A check identified as a necessary control on a risk assessment can appear in a checklist accessible on a tablet when the job is under way; when an accident is investigated, all related documents can be linked, with automatic flagging of the need to review the risk assessment and method statement. Reports can also be semi-automated -- no more sorting through all your emails for attachments because all the data is stored on the system.
But we can learn more from software developers than just adopting the digital tools they offer. Processes and mindsets have changed enormously in the software industry in the past 30 years, and some of those new practices could be adopted in managing safety and health.
Dump the manual
A line from a 1970s user manual for a word processor reads "Ctrl-K-V works as would be expected". The manual for a system that could produce only black text was the size of a Penguin paperback. Manuals for anything more sophisticated were the weight of two house bricks.
Safety and health documents can still run to several folders of yellowing paperwork on a shelf (or gigabytes of data on a shared drive) but the user manuals for computer applications have disappeared. Did you read a user guide for Word? Or for any of the apps on your phone? Darragh Geoghegan, CEO and co-founder of Effective Software, says the first version of the company's product in 2010 had a user manual, but since then the developers have made the system more intuitive, obviating the need for a guide. If there is a screen-button marked "indent" you don't need a manual that explains what Ctrl-K-V does.
But at induction many staff are still issued with a manual, which includes safety rules and procedures. The information might be on an intranet rather than on paper, but this doesn't make staff any more likely to read and remember everything.
So can we reduce the training and documents needed for people to carry out their work safely by designing the job environment to be more intuitive? Perhaps workers would benefit from a fixed ladder being installed at a location where frequent access is needed to a height rather than being furnished with instructions on where to find the correct ladder; smaller waste sacks could be introduced, precluding the need for workers to refer to rules on filling the bags to half way to minimise handling loads. But if there is a handrail on the stairs, perhaps its use is intuitive, and it doesn't require instructions.
Another lesson from software developers here is context-dependent help. Rather than the "read the whole manual, and then get on with the job" approach, most computer applications offer chunks of information online for when you need them. With some systems you might have to search for what you want to know, but more sophisticated systems guess your problem from where you are in the system and what task you were doing.
Effective Software is planning to use artificial intelligence to better understand the user journey. Behavioural patterns can be used to recognise when a user wants to create a periodic report, and image recognition can suggest how to categorise a photo in a hazard report.
If a task isn't intuitive, we need to provide information when it is needed rather than rely on reading the manual. Think of usage instructions on bottles of chemicals, reminders on equipment of which PPE has to be worn or posters in a warehouse that illustrate good manual-handling techniques. People are the best form of context-sensitive help -- we need to create a culture in which one worker can remind another to follow a safety precaution that has been overlooked, or where colleagues can ask each other for advice without fear of looking foolish.
Agile and iterative
The old approach to software projects used the waterfall model, in which a development was divided into phases, and each could not start until the previous stage was complete. Planning was pigeonholed into a phase at the start, and for long IT projects this created enormous problems. If requirements changed, the team could either ignore the new requirements and plough on to finish on time, or try to reschedule the remaining phases, which led to overruns and errors. The waterfall process was easy to understand, but was inflexible.
Prototyping was introduced to overcome some of these problems -- users could be shown what a system might look like before time and money were ploughed into the main development, but the extra cost of prototyping was off-putting.
As software development tools improved, developers moved to iterative and incremental processes, in which part of the system could be built and tested, and lessons could be fed into the next phase.
Marek Zapach, IT solutions architect for an e-learning developer, describes the "minimum viable product" (MVP). Instead of planning the whole system, the MVP is the minimum feature set that provides something usable. Rather than a prototype that is thrown away, the MVP is a building block of a more developed product. Zapach explains that this approach means you can deploy it earlier "and improve it as you go. Early feedback from users helps you to focus on important features and very often filters out unnecessary complexities".
The agile model accepts that our initial plans may not be right first time or that the scope can change
The use of these more flexible approaches was packaged up in the term "agile." Although this term has been used as a catch-all for new ways of working, for software developers it has a specific meaning best summarised by the "agile manifesto" at www.agilemanifesto.org (see table above for a summary of the requirements, and how it could be used to challenge how we manage safety and health).
When we implement a process intended to improve safety or health, do we have an agile model? Or are we convinced that we have the right answers to an unchanging problem? The agile model accepts that our initial plans may not be right first time or that the scope can change. The MVP can be piloted, feedback collected and taken on board.
Talk to users
With the waterfall model, the planning phase was intended to capture the needs of the users, who would be consulted again only during the final testing phase. Unfortunately, many users were represented by their managers or others, not the staff who would ultimately have to use the system. Waterfall left little scope for users to express their views during development.
The agile process provides earlier systems for those who will be using the final product to try out and respond to. Agile makes it possible to try two or more user interface solutions for the same function. It also lets developers fail quickly, so they can learn quickly.
The degree to which OSH professionals are willing and able to involve their users varies. Sometimes the lack of willingness comes not from the safety and health team but from managers who don't want frontline staff to "waste time" or from workers who, having never been asked before, are uncomfortable giving their opinions. Software developers have overcome these problems by writing into the contract that users are involved and using various techniques to engage them. Sitting people around a table and asking them what they want is not recommended. Card sorting is a simple approach to decide how to organise information on a website and can also be used for OSH programmes (for more, see bit.ly/1L6ekfC).
Variable definition
A final thought on how we can learn from software developers is not based on new processes, but on the basics of how computers work.
Although Tom Sweeney, safety officer at John Paul Construction in Cork, has worked in construction and civil engineering, his first degree was in computer science. He sees a clear difference between how safety is managed and how software is written.
"With software, it either works or doesn't work -- it either complies or it doesn't. You can't blur the edges. In my experience in construction safety, people are very quick to jump to solutions or conclusions without that same certainty."
In programming languages it is essential to be clear about what each word means. A variable cannot mean one thing in one place and something different elsewhere; a command that has one action the first time it is used will have the same effect the next time. Yet in many safety documents the variables are not defined. A sentence such as "managers are responsible for suitable and sufficient risk assessments" needs the terms "manager", "risk assessment" and "suitable and sufficient" to be defined unambiguously. Another long-standing principle of computer programming is that if you define something in one sub-routine, to be available in another sub-routine it has to be passed on. The second sub-routine cannot guess what is needed. So when a document is written requiring "all workers to carry out a dynamic risk assessment before each job", is that requirement passed to "all workers"?
Software developers have changed how they worked. The waterfall model doesn't reflect the unpredictable nature of business, so developers adopted an agile approach that relishes change and volatility; users became more sophisticated and more demanding, so software had to become more oriented to the user experience, and less dependent on expecting the user to read a manual or attend a training course. Similarly, safety management systems, generic risk assessments and method statements cannot be written once and set in stone. Workplaces are changing faster than ever and new technologies provide new hazards, and new solutions to managing hazards. In response, safety and health management has, like software development, to become more agile and more user-focused.
