A recent article on nationalacademies.org (which certainly sounds like a solid reference) has as its title “Driverless Motor Vehicles: Not Yet Ready for Prime Time” (link below). Since an abundance of media space too often is given to press releases from technology companies, which are then echoed by techno-optimistic bloggers, this was a title that caught my eye. While it would be nonsensical to deny the achievements of technological progress and a mistake to minimise them, there are still reasons to remain cautious about some of the promises made by visionaries of technological progress. If they all would have come through as envisioned, I would already in teenage years have been flying to school in a jetpack and friendly robots would have guided me to fully immersive learning experiences (instead of having to bicycle to school and watch the teacher write on a blackboard – and yes, I am that old, blackboards and overhead projectors were the prime means for display of information back then).

The article acknowledges that the current death toll in traffic could be significantly reduced with increased use of automation for road transportation. However, it does pose two questions often asked in regards to automation: 1) What happens if the automation fails? and 2) What if the automation has to handle a situation that has not been considered by its designers? These questions has been asked throughout the history of automation, robotics and AI and it has been explored by researchers and others thinking about the potential and limitations of technology. In the article, these questions are focused on fully automated vehicles, i.e. self-driving cars but it brings up many aspects which are equally relevant for aviation.

The article goes on to discuss the challenges to achieve the vision of a fully automated road transportation system and references the experiences of automation in aviation. The point made is that in aviation, automation has been an ongoing process for decades, that this has been in a less complex environment than road transport and that still today pilots are not expected to be replaced any time soon. I am not sure that I agree with either of these statements, given the complexity of any airspace environment, especially close to a major airport, and the current developments towards single pilot operations. But perhaps complexity can be a matter of perspective.

Developing autonomous vehicles is, according to the article, more challenging than previously envisioned and will take longer than many of its proponents advocates have anticipated. Also, the many Human Factors challenges experienced in aviation are mentioned, with implicit reference to accidents and experienced related to automation. Special emphasis is placed upon the difficulties of mixing autonomous and human operators and the potential failures of automation. The recent Boeing 737MAX accidents are brought up, so is the “Miracle on the Hudson”, as a counterpoint. While providing a less positive perspective than often encountered in texts about automated transport, it is useful to read this perspective and consider the remaining obstacles to this vision.

The point of the article may be supported by the experience in daily life of interacting with the “chatbots” often used these days for customer service. Even if it is not made clear to us that we are speaking to a bot, it does not take long (a non-standard question is usually enough) until we realise that we are not chatting with another human being. For a range of simple questions (location, opening hours, ticket prices etc.) we would probably not have known the difference. But for anything beyond this they usually create nothing else but frustration. Even as these chatbots gets far more advanced, those last five percent of difference to a human may still be challenging to resolve. The same may prove to be true for both driverless cars and pilotless planes.

Link to article:
Driverless Motor Vehicles: Not Yet Ready for Prime Time

This is the fifth and last eposiode of a series about procedures by Anders Ellrestrand. The previous episodes can be found here: 0 – Introduction, 1 – Design Process, 2 – Memory Aid, 3 – Training, 4 – Collaboration.

Your procedures constitute your organisational baseline. They are the standard and the norm. By that, procedures also limit the behaviour – of staff, the organisation, and of the system.
By this it is possible to monitor the organisation and to notice any variability. There is a possibility to notice the gap between ‘work-as-imagined’ and ‘work-as-done’. We have already established that there will always be a gap but also that it is good if the gap is not too large. A large gap can be the start of a system that drifts into areas where hazards are not pre-identified, and where the associated risks are not assessed and mitigated.

In many organisations, the distance between ‘the blunt end’ (management and support functions) and ‘the sharp end’ (operators) is too large. The gap between WAI and WAD goes unnoticed until a time when there is an incident and where an investigation reveals ‘unacceptable’ non-compliance with procedures. When there is an investigation into an incident, there is often a pressure to quickly find the cause and then to establish an action that will stop re-occurrence. It could be tempting to not spend the necessary effort to find all the contributing factors, but instead point at the human at ’the sharp end’; the ‘human factor’.

If the gap between WAI and WAD instead is discovered as a result of closely monitoring daily, normal operations, it could be easier to ask the relevant questions and consider more options. Are there procedures in place that does not make sense to the people supposed to use them?

In a row of posts, I have pointed at several areas where procedures are important, helpful and where they are necessary for an organisation to function. However, procedures can also make work more difficult. Procedures can restrict flexibility and make necessary adaptations more difficult or even impossible. When procedures are too strict/limited it can become necessary to deviate from them to be able to get the work done.

There is a debate about procedures (and rules and regulations) and you can identify two hard-core schools:
• Procedures are the norms of an organisations. If they are fully complied with, work gets done in a correct and safe way. Most, if not all problems, come from non-compliance, often labelled as ‘human error’.
• Procedures are part of a top-down control and limit the human ability. Procedures are obstacles that makes it more difficult for people to address real-world problems in an ever-changing and complex world.

As usual, the truth is somewhere in a large grey zone between these positions. We should aim at writing procedures in a way that provides the necessary flexibility, for the operator to be able to adapt to different situations, while still following the procedures. At the same time, the procedures must maintain their role of limiting behaviour, maintaining their normative function.

This is, of course, much easier said than done.

In the previous post (link), I argued for the possibility that instructors on a training institute interpret procedures differently and thus train students differently. Having similar ways of interpreting and applying rules have a value and that is especially true when you look at procedures as a most important tool for collaboration and for harmonisation.

A team typically works better if the members know each other well. It is also good if you agree on a row of things, such as what are the goals to achieve, what standards to apply, what methods work best and so on. Procedures take care of some of that. By having good procedures, that everyone in the team adhere to, you will know what to expect from your co-workers, and this makes life easier. The work can be done in an efficient way.

We can find an old example by looking back more than 80 years, to the second World War, when the last obstacle for Germany to conquer Europe was the British Royal Air Force. You may have the view that the German military was extremely well organised and efficient. But the German Air Force were very far from being as efficient and well organised as the RAF.

One example is the ‘Dowding system’. It controlled the airspace across the UK with an integrated system of telephone network, radar stations and visual observation that made it possible to build a single image of the current situation in the entire airspace.

One of the enablers was procedures! Although the airspace was divided in several sectors, the same procedures applied. One effect was that you could move staff between sectors without re-training. Another effect was very efficient collaboration. The end effect was of course the ability to get the fighters airborne at exactly the right time and in the right numbers to provide a persevering and efficient air defence that eventually had Hitler withdraw his plans for occupying Britain.

I think most of us could fine our own examples. I worked in an ATC Centre where most ATCOs agreed that it did not matter what other ATCO they worked with, since there was a general understanding and agreement on how to interpret and apply procedures. I heard ATCOs saying that they were happy with their procedures – they made sense and were useful.

However, I have also visited an ATS unit where ATCOs were divided into teams. The ways of working developed in a way that the teams became quite different. If one ATCO temporarily had to change team, they found that quite difficult. Suddenly they did not know what to expect from their colleagues. That uncertainty influenced efficiency, and perhaps even safety.

The organisation of the work force in teams probably had a role to play here, but I also believe that very well-written procedures could have helped to improve the situation. Procedures that make sense and are useful are more likely to be used in the intended way. That could also contribute to good collaboration.

This is the third part, in a series of six, about procedures by Anders Ellerstrand. The previous parts are here: Part 0 – Intro, Part 1 – Design Process and Part 2 – Memory Aid.

I cannot imagine a training for someone to be a pilot or an air traffic controller if there were no procedures. Large portions of such training programs are spent reading procedures. To learn about them, to know which of the procedures you need to know by heart and where you will find others when you need them.

Once that is cleared, you spend hours after hours in a simulator where you apply these procedures until you can do it well. Then it is time to apply them in real life, first with an instructor and then, finally, as a trained professional.

I have worked many years as a teacher and instructor, but also as a training manager and I have been a project manager for a new training design. None of these roles would have been possible without procedures. They determine how the training program is designed, how the training sessions are scheduled, how the training results are monitored and assessed and how the training results are validated.

However, there are also a few problems with procedures and training. The most prominent problem is how to deal with the previously mentioned gap between ‘work-as-imagined’ and ‘work-as-done’. Do you recognise these statements below?

• “As you are still in training, you have to do it like this. Later, you will find out how it is really done.”

• “In the real world, you often have to ‘bend-the-rules’ or ‘take a shortcut’ here and there, but that is only fine if you first know the procedures properly. You must know what rule you are bending.”

Sometimes it is not really about bending or breaking, but more about interpretation. During training, you typically have several instructors, and you may find that their ways of using the procedures are different. Do you then adapt, changing the way you operate depending on which instructor you have? Is this a problem acknowledged by the training institute and discussed among the instructors? If it is, it might be that the instructors adapt so that they use the procedures the same way as long as they are in their role as instructors.

A consequence could be if the student sees the instructor performing the real job, doing things differently than he explained it to the student. Then you have the classical parent-child issue: “Do as I tell you, not as I do!”

Good luck with your training! 😉

Procedures have an important role to play – as a ‘memory aid’. This is especially true when you run into an unusual situation, perhaps an emergency. For emergencies, and other unusual situations, it is common that the procedures to follow, are written as checklists.

This is especially helpful in cases where a number of different tasks is to be completed, where the sequence is important and where it is crucial that no item is omitted. Examples could be the shutting down or restarting large systems.

I’m not a professional pilot, but I have spent some time in airliner cockpits and my impression is that almost everything is done using checklists, an efficient way to assist with consistency and making sure no item is omitted.

However, the role of procedures as the organisational memory, is not limited to emergency checklists. During my career as an Air Traffic Controller, I have seen this often. There is a discussion about the proper way to handle a certain situation. Someone goes to fetch the ops manual, to find the page where the procedure is explained. There could still be a discussion, whether that really is the best way, but establishing what is the currently valid procedure usually ends the discussion. The only difference I’ve seen over the years is that the thick ops manual binder is today replaced by a computer and a screen.

One problem here is that emergency checklists are hopefully not used too often. Things might change in the systems or in connected systems. It is not always easy to realise that such changes could affect the actions needed to be performed in emergencies or other unusual situations. An effect could be that the checklists become partially outdated. I have seen such examples, but the effect of it was not serious, because as so often, humans are able to adapt. In this case, the actions in the checklist were changed, to fit with the new environment, a report was written, and the checklist was later updated. With a good outcome there was not too much fuzz about it. One could wonder what would have happened if the adaption had led to an incident…

Another aspect is that the importance of procedures as memory aids is not as pronounced with those procedures that are frequently used. The actions performed several times each day are rarely, if ever, invoking a check with the written procedures. Any ‘drift’ when it comes to the application of such procedures is typically done in incremental steps over a long period of time and thus rarely noticed. When, after a long time, this drift has left to a considerable deviation, you might still believe you are working strictly in accordance with the procedures. In these cases, you typically don’t use the procedures as a memory aid.

The use of procedures as ‘memory aids’ is important and of value, but not without problems.

When you design a new system or an addition to an existing system, part of the design is to write procedures. These will describe how the new design is to be used, to perform as intended and to achieve its goal, or typically many goals – like efficiency, quality and safety.

To write the procedures for a new design is however a challenging task. The procedures should describe how the system is to be used, not only in the normal, everyday situation but also in unusual, perhaps hard-to-foresee situations, including emergencies.

It is also important to make sure that the use of the new design is not having unintended consequences. In aviation, there are regulations that require any change to the existing functional system, to be assessed for safety. This is done in a process where hazards are identified, and related risks are assessed. Risks should then be removed or mitigated to reduce the risks to “As Low As Reasonably Practicable” (ALARP).

When writing the procedures, there is a need to understand the context that the design will be used in. However, the context typically changes, over the day, over the week, over the year and over time. It is hard (or impractical or even impossible) to write detailed procedures for every context. A simple example could be to write a procedure for parking a car. You probably adjust your way of parking, depending on if its day or night, if its summer or winter (with snow and ice), and depending on a lot of other aspects.

Other connected systems and the people working with them, will change and evolve. Thus, there will also be a need to update the procedures, during the lifetime of the system. One problem is that the context often changes first and only then do you see the need to update the procedures. Procedures development tends to be running a few steps behind reality. For simple, stand-alone systems, this might still be achievable. For systems that will interact with other systems in a complex environment, it is simply not possible to write the perfect procedures.

As the system is put into operation, the operators will discover the imperfections that are there. Perhaps there is a situation that was not foreseen at the time of design, or something in the context has changed since the procedures were written. In most cases, the operators still manage to get their work done, often by making small adaptions in the way they follow the procedures.

As the design is put into operations, there will thus always be a gap between ‘work-as-imagined’ (the procedures) and ‘work-as-done’ (the reality). Even if it is widely accepted that such a gap will almost always exist, it is also acknowledged that it is good if the gap is as small as possible. If the gap grows, the original procedures becomes less and less relevant and could even become completely redundant. The effect can be that the use of the design is ‘drifting’ from the intended (imagined) use, into areas that has not been safety assessed. This could create situations with threats to the system safety. There is also the possibility that the drift is improving safety – drift is not necessarily negative.

Finally, the procedures will also be used whenever you need to replace the design with a new, or if you want to improve your design. The old procedures can be the starting point for a new design.

In 2013, Andrew Hale and David Borys wrote a paper with the title: “Working to rule, or working safely?”. In it, they compare two different views on rules. One view is a classic top-down view, where rules act as limits of freedom of choice and violations are seen as negative. The other view is a bottom-up view. Here rules are constructions of operators as experts and competence is seen as the ability to adapt rules to the diversity of reality.

Sidney Dekker is debating this topic in many of his books, with lots of examples of poor use of regulations. Dekker´s latest book (I bought it but haven’t read it yet…) is called ‘Compliance Capitalism – How Free Markets Have Led to Unfree, Overregulated Workers’. Robert J. de Boer, in his book ‘Safety Leadership’, has a chapter called: “Alignment between Rules and Reality’.

One of the problems with procedures is this gap between the procedures and how things are done in real life. This is also frequently discussed, for example by Erik Hollnagel when he compares ‘Work-as-Imagined’ (the procedures) and ‘Work-as-Done’ (real life). This is further expanded by Steven Shorrock in his posts about ‘The Varieties of Human Work’ on www.humanistcsystems.com.

The topic of rules, regulations and procedures is interesting and the more you read and think about it the more complex it becomes. Why do we have them? Are they really that important? Who should write them and how should they be used? Could procedures be a problem, perhaps even the problem? This is really a topic for one or several books, but I will limit my attempt to a few posts in this blog, with my own reflections on some of the aspects.

Based on Hale and Bory’s paaper, and on the book by Boer, I suggest five good reasons for procedures (or rules or regulations) and will discuss each one in turn, in coming posts on the blog:
1. Procedures as part of a design process
2. Procedures as a ‘memory aid’
3. Procedures to assist in training
4. Procedures to enable collaboration
5. Procedures as a normative function