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.