Beware of "Normalization Of Deviance"

Normalization of Deviation is behind a great many accidents, mistakes, and it has robbed many of their lives. However, Deviation is also required, and without deviation, we also risk removing the tools necessary to prevent such things.

5 min read

It's Sunday, which for me means it's a research day. Often, I'll research Aviation, Boating, or other Industrial accidents and failures. I find that when discussing Digital Transformations or processes, real world failures if not always, often, correlate to failures in technology.

Normalization of Deviance is "the process in which deviance from correct or proper behavior or rule becomes normalized in a government or corporate culture."

"The Deviation Spiral" - https://www.cirrustraining.com.au/normalisation-of-deviance-and-the-80-rule/

Over time, as you deviate from a process further and further, your safety margins shrink. Your actions become less resilient to failure, and more accident prone. As pictured above, a normalization of deviance, or a culture of deviation often results in a spiral. The deviation becomes the new normal, and further deviance continues.

At some point, that Deviance becomes codified further shrinking your failure, safety, and accident margins. As was the case with the Aleutian Trade Act of 1990; Where boats whose primary purpose it is engage in fishing commerce; were allowed to bypass inspections related to cargo for hire boats. Those fishing boats were then allowed to haul cargo. In the case of the FV Northern Belle, this led to overloading of a fishing ship aswell as incorrect load and balance calculations. Those two items, combine with a poorly maintained ship, with rusty watertight bulkheads; resulted in it's rapid sinking, unfortunate death of it's captain, and complete hull-loss.

And yet - Deviation from normal process is in some cases necessary. How do we design systems and processes that allow for deviation when necessary, but do not fuel a culture of deviance? A key component of resilience is flexibility; How do we design systems of delivery that are safe and secure, while remaining resilient and flexible?

Deployment of UN's FPIC Framework

The United Nations has a policy for working work Indigineous Peoples. This framework is called FPIC, or Free Prior Informed Consent. The purpose of this is to respect the decision and input of Indigenous Communities. By implementing this framework, we can work to ensure that Indigenous Communities are able to make informed decisions, without fear or pressure of coercion. However, as a side-effect of this framework, we ensure that the decision being made is fully weighed and understood. That it's benefits, costs, detriments, weaknesses, and downsides are fully understood. That the outcome of said action is understood to the best of everyone's ability, and any unknown outcomes that occur, are in good faith unknown to all.

With this, any actions or agreements we undertake are performed with a full understanding of the potential outcomes.

Which is exactly what a deviantion of process requires to insulate and prevent against creating a cultue or normalization of deviation. More importantly, because a deviation is a risk event, having informed consent is required to guard against adverse outcomes. Every deviation should include FPIC, so that the deviation and it's outcomes are fully understood and weighed, every time that it occurs.

Jenkins Skipped Pipeline - https://comquent.de/en/skipped-stages-in-jenkins-scripted-pipeline/


An example of this would be skipping security tests for a software deployment, because the security scanners are offline. A resilient process is flexible, and it may be necessary to ship software for legal, finance, or other reasons. However the inability to skip security scans is a blocking function, because it's critical to the process. So in order to deliver, we need to deviate.

In this scenario, we would involve the Security Team, Management Team, QA Team, and Development Teams. We would sit down and collect all the evidence we have of previous security scans, any changes that are made, and all information we have on hand at that moment.

Then we allow said teams to process this information, become informed, and provide their consent. With all consent, the security scan is skipped, but the remainder of the process remains in effect. Without all consent, the delivery is scrapped, without backlash or political fallout.

A key component of Informed Consent is the lack of pressure or force. Consent is automatically invalidated the moment coercion is introduced. If we look at many Aviation or Boating incidents, we can find that respecting the single voice of a single dissenter, it could have (and has!) resulted in the avoidance of diaster.

Rejection of Process, and Setting things on fire

Bill from Gravity Falls

Now, if you've gotten this far, I know some of you like me are going "But Chris, when do we set the entire thing on fire."

When you reach a point where requests for deviation become the normal. That is a key indicator your process is broken and not working. That it's no longer meeting it's current purpose and requires reconsideration. Without changing the process, you risk making deviations normal, and inadvertently create a culture where your folks accept deviation as normal. This is a unwanted outcome even if FPIC is utilized, every deviation from process increases your risk. Over time, small dangerous events, can result in a high risk level.

So, instead of burning the process down. You take it, study it, identify what works and does not work, finally you slowly iterate on it to improve it. Process exists for a reason; just because a process no longer benefits you, it does not mean that reason ceases to exist. So, respect your prior process and the lessons that process was born from.

Collect metrics on the deviations from your current process, categorize them, identify them, and understand why they occurred. Take those lessons and build them into your next process so that you have less deviation events. In our security scanner example above; Maybe we build a testing environment for our security tools, and maybe we only allow maintenance on the production tools on Mondays... Unless a deviation is required.

In Closing

My goal of editorials on my blog are to get you thinking. To get you to wonder about things, ask questions, and challenge yourself. I aim to be as factual as possible, and I aim to never give you information that can not be actionable.

Normalization of Deviation is behind a great many accidents, mistakes, and it has robbed many of their lives. However, Deviation is also required, and without deviation, we also risk removing the tools necessary to prevent such things. I hope after reading this it has you wondering where deviation occurs in your process, and how you can improve it.