Normalisation of Deviance

A little I.T. digression from the normal History stuff. I came across the term "normalisation of deviance" recently in an article about the Hubble Telescope mirror fiasco. It's a term that has application in the I.T. world, and one that any good support person or company should strive to notice and avoid.

We run into it a lot when there's a rush to complete a project, or when there's a great number of tasks firing at the same time. The trick is to keep track of all the open items and not let them fester. Not only can they lead to loss of data and heartache for a client, but as an outsourced IT consultant, it can lead to loss of a client even if nothing "bad" happens and the aberration is discovered in advance of a catastrophe.

I always tell our new consultants, "backups are your most important insurance policy." Yet since they are pretty boring they're one of the most overlooked. It's the first thing I look at when taking over a new client from another company, and I'd say about a third have some sort of issue, from a particular server that doesn't back up successfully, to in one case, an entire very expensive infrastructure that had no backups even after 18 months of implementation!

They are a regular "target" of normalisation of deviance; but often we see things like patching and anti-virus that doesn't update properly in a state of deviance. Like a space disaster, things go fine until all of a sudden the IT support group gets into a cascade of failures, where one small failure begets a larger group that winds up unhappily for everyone involved.