Best practices for procedure writing (Part 2)

My intention in this blog post is to add an extra layer of reflection. Some of this will be a different angle on what has been said before, going deeper into some areas and providing extra information, other elements will be new.

This blog post builds on Lydea’s earlier post, Best practices for writing SOPs (Part 1), which covers key issues like:

  • The accuracy of procedures and whether they reflect work as it is done rather than how we think it should be done, 
  • Good usability and readability of procedures, 
  • How procedures should be risk informed and 
  • Keeping the procedures up to date. 

My intention in this blog post is to add an extra layer of reflection. Some of this will be a different angle on what has been said before, going deeper into some areas and providing extra information, other elements will be new.

1. What do we mean by procedures?

Generally, procedures are stepwise instructions for carrying out a task. They can be called different things at different sites and different regions, e.g. SOPs or Standard Operating Procedures, OIMs or Operator Instruction Manuals, Work instructions, and Job Aids.

Interestingly their use can also be very different, and one of the things we engage with when reviewing procedures related to critical tasks is trying to understand how they are used. For example, some sites use procedures more for training than to be used on the job itself, this type of procedure might go into more depth and have knowledge and skill requirements for different steps. Another site I visited had procedures only for critical tasks with steps that needed to be signed off, these were expected to be used on the job, and they had a different name for non-critical work instructions.

It is important to try to get clarity around the actual use of procedures and the requirements and expectations of how they should be used.

2. Does every task need a step-by-step procedure?

Quite often the default position is that every task should have a full step-by-step procedure, especially if it is safety critical. However, some tasks are done day in and day out, so do we really expect highly experienced and trained personnel to use a step-by-step procedure when they don’t need the detail? Arguably, they might only need a slimmed down version containing the critical points. Going further they may not need anything and might not use anything in practice. In fact, despite our best intentions, very rarely do we see operators walking around site carrying paperwork with them.

Something we introduce in our Human Factors Safety Critical Task Analysis (SCTA) training is a matrix that Dr David Embrey devised, an early version can be found in his paper Preventing Human Error: Developing a Consensus Led Safety Culture based on Best Practice. It’s aim it to get people thinking about appropriate levels of documentary support for the operator doing the task. Things that are done infrequently, are complex with severe consequences should warrant a step-by-step procedure. However, things that are done frequently, are simple and have a low severity of failure should not require a step-by-step procedure. 

In the middle of the spectrum of permutations we have job aids, which could be shorter forms of procedures and checklists, which contain the critical details but strip out the information that well trained operators will find unnecessary. 

The matrix should only be considered a heuristic and rule of thumb, to get people thinking about the area.

Best practices for procedure writing - a Matrix of Operator support covering procedures, job aids and competence use
Figure 1: Matrix of Operator support covering procedures, job aids and competence use developed by Dr David Embrey

I think it’s really interesting if we go further with these arguments and consider whether we are doing experienced operators a disservice if we force them to use full step-by-step procedures for their tasks, even critical tasks. A story…

One of my colleagues was on a site where they had recently completed some Safety Critical Task Analysis (SCTA) work, and from that the organisation had developed much more detailed procedures. These procedures stretched on for a 100 or so pages. However, most of the information in the procedures covered stuff that the operators did on a day-to-day basis, they did not need this information. The important thing was that within these 100 pages there were some critical elements, but these were swamped with all of the other detail. If operators were tempted to skip past detail, then they might miss some of this critical information. Was this full step-by-step the best form of support for these operators? Arguable not.

Recommending a full step-by-step procedure is used for critical tasks is a default position, it’s the most comfortable recommendation for safety, because we’re giving the operator all the information, whether they like it or not.

Something that might help move away from this approach is to have a more robust competency management system. So, we’re not saying that we can just lose information and keep the same system. There might be a place for a competency management system to step up to show that operators have the right knowledge and skill requirements for specific critical task steps. This higher level of assurance from the training then might make it easier to show how the risk and subsequent supporting information is being managed. 

3. What is best practice for formatting procedures?

A nice exercise to review the formatting of your own procedures is to use the HSE audit tool. This can be complemented by looking at HPOG’s guidance on Best Practice in Procedure Formatting. As a company the formatting of procedures isn’t a huge issue as the SHERPA Software programme incorporates best practice and has different templates that can be exported. Often clients will have their own logos, boiler plates and requirements to create their own standardised designs.

What is important is to follow good Hierarchical Task Analysis (HTA) best practice so the task is already broken down step-by-step, each step if described concisely and starts with a verb, the person responsible for the step is recognised and any additional information is contained in notes.

Good Hierarchical Task Analysis (HTA) practice also allows us to get the content right, which we expand on next.

4. What is best practice for developing procedure content?

By following good Hierarchical Task Analysis (HTA) practice much of the heavy work for writing good procedures should be sorted out, e.g. including precise detail and avoiding bogey words and phrases like ‘as required’, using concise language, starting each step with a verb and doing a proper step-by-step breakdown.

Sometimes procedures we see do not demonstrate good practice because:

  • They have paragraphs of instructions with multiple steps within the same paragraph. This makes procedures harder to read.
  • They do not structure and organize chunks of work adequately, so there might be 60 individual steps with little or no indication that steps 1-10 do X, 11-17 do Y, and 18-25 do Z. This makes procedures harder to understand and navigate. 
  • They lack ‘why’ certain steps should be done so its harder for operators to understand what they are doing.
  • The procedures are dated.
  • The procedures duplicate steps and miss steps out.
  • They are too high level or generic and so do not contain important details, some of which could be safety critical.
  • They do not clearly identify or indicate what are critical task steps, which could lead to a Major Accident Hazard (MAH).

To develop procedures it is important to have the right people contributing. Operators with experience of doing the job are extremely valuable because they are writing the procedures for themselves and their colleagues. Engineers familiar with the task are also invaluable to verify that any changes are appropriate for production and safety – sometimes practice can drift and seemingly innocent workarounds can have hidden risks because the ‘why’ has been forgotten over time.

5. How should one present Warnings in procedures?

A Poorly Written Warning: “Be careful when handling chemicals.

A Well-Written Warning: “Warning: Chemical X is corrosive and can cause severe burns on contact with skin. Always wear appropriate personal protective equipment, including gloves and goggles, when handling Chemical X. Avoid direct skin contact and inhalation of fumes. In case of exposure, immediately rinse affected area with water and seek medical attention.

In the poorly written warning, the potential hazard is vaguely mentioned without specific details on the risks or necessary precautions. On the other hand, the well-written warning clearly identifies the chemical, describes its hazards, provides specific instructions for safe handling, and outlines steps to take in case of exposure. It also emphasizes the importance of personal protective equipment and immediate medical attention.

The HPOG guidance on Best Practice in Procedure Formatting has advice on how to present safety information. However, I don’t particularly like the multi-coloured approach. Should someone take more care if there is a danger, or a caution or a warning? It could also make for quite a colourful and confusing procedure if multiple cautions, dangers and warnings were presented within and across pages. Some experienced Human Factors practitioners I have spoken to recommend just two levels to cover a difference between personal safety warnings and Major Accident Hazard Information; others have said only one level should be used as you either need to be careful or you don’t; and yet another to provoke thought suggested no warnings should be included because the whole procedure is important.

So there are many differences of opinion. Where people agree is probably to use any system of warnings sparingly so they add focus and clarity rather than more noise. 

Best practices for procedure writing - a table showing three different warnings from the HPOG Guidance on Best Practice in Procedure Formatting
Figure 2: Three different warnings from the HPOG Guidance on Best Practice in Procedure Formatting

Warnings should not include task information that should be in the procedure.

Warnings should be placed just before or directly adjacent to the step it is associated with. I once made a Thai Green Curry at home. I was following the recipe on the tub of Thai Green Curry paste. When my wife saw me putting spoonful’s of paste into the pan she remarked that it looked quite a lot. I thanked her for contribution but said that I was following the recipe and continued. I added the meat, the coconut milk and aubergines and followed the rest of the recipe to completion. And that’s when I saw it… underneath the steps of the recipe was a warning. I can’t recall the exact wording now, but something like how the paste was very hot and those who could not handle the heat should not put in so much paste. Thanks for that.

7. Digital procedures

It seems to be becoming more and more common to hear about sites that are experimenting with or introducing digital procedures. So instead of having paper-based procedures to carry round, initial and sign, or laminated procedures that stay within a work area for reference, the procedures will be kept on a computer or some portable device.

Digital procedures can easily include interactive elements mentioned earlier, they can potentially track what is done, where and when through time stamps and the scanning of QR codes for example, they could display different information to different people depending on their experience and role, and they could help with checking and coordination. 

However, there could be challenges if work environments are not conducive to having electronic equipment in, PPE requirements might make it different to use, and paper-based systems do not really run out of battery or crash. 

There are surely many advantages with digitizing procedures, it seems like the direction of travel, but we’re reminded the paperless office had issues when early adopters pushed ahead with that.  

This is an active area of development and implementation for the SHERPA Software, please get in touch if you’d like a demo and to find out more.

Conclusion

As I hope this article has demonstrated procedure writing is an extremely interesting area with its own complexities when you start to delve a bit deeper. It has close ties to risk assessment and competence management, which are taught as part of our Human Factors Safety Critical Task Analysis (SCTA) training.

The basics are relatively easy to get right, but this can be greatly helped if you have the right systems in place for reviewing and developing work. The SHERPA Software covers a lot of the basics and is actively developing and implementing more advanced features. 

If you’d like help reviewing your procedures, please get in touch with our Human Factors consultants.

To learn more about procedures, click here.