This worksheet accompanies The Quiet Collapse of Standards. Use it in a retrospective, quarterly review, or before a major change.

Normalization of Deviance Audit

Find the standard that quietly became optional

Normalization of deviance begins when a team departs from a standard, sees no immediate failure, and gradually treats the departure as normal. Use this audit in a retrospective, quarterly review, or before a major change. Look for drift in behavior, not villains.

Team or system: __________________________ Review date: ______________

Facilitator: ______________________________ Review period: ____________

1. Name the intended standard

Choose one process, control, expectation, or safety margin to examine.

The standard is: _________________________________________________________

Where is it documented? __________________________________________________

Why does it exist? What failure does it prevent or limit?

Who owns the standard? __________________________________________________

2. Describe current practice

Do not write what the process is supposed to be. Write what people actually do.

What happens in practice?

How does practice differ from the standard?

How often does the deviation occur?

• Once or rarely
• Several times per quarter
• Monthly
• Weekly
• Almost every time
• We no longer know what the original standard was

When did the deviation first appear, as far as we know? ___________________

3. Identify the reinforcement loop

Complete the chain that allowed the deviation to become acceptable.

The original pressure or trigger was: ____________________________________

The first exception was: __________________________________________________

The short-term benefit was: ______________________________________________

The immediate failure did not occur because: ______________________________

The lesson the team accidentally learned was: ____________________________

The behavior became normal when: _________________________________________

4. Listen for drift language

Check phrases that have appeared in conversation, tickets, reviews, or planning.

• “We have always done it this way.”
• “It has worked fine so far.”
• “It is only temporary.”
• “We will fix it later.”
• “It is not worth the effort.”
• “The deadline matters more this time.”
• “Everyone knows the real process.”
• “That control is just for inexperienced people.”
• “Nothing broke, so it was the right call.”
• “We would know if it were really dangerous.”

Other language: __________________________________________________________

5. Assess the exposure

Current exposure:

• Low: limited impact and quickly reversible
• Moderate: meaningful impact or delayed detection
• High: major impact, weak detection, or difficult recovery
• Unknown: we do not have enough evidence to judge

6. Decide what happens next

Do not default to “make people follow the process.” Decide whether the standard is still useful, whether it needs to change, or whether the team needs capacity to follow it.

The right response is:

• Restore the original standard.
• Update the standard because the system has changed.
• Add a documented, approved exception path.
• Add a compensating control or earlier detection.
• Remove the standard after confirming why it existed.
• Gather more evidence before deciding.

Why this response? _______________________________________________________

7. Create an interruption plan

Make the safer behavior easier to trigger next time.

The signal that should interrupt the drift is: ____________________________

The person or role authorized to call it out is: __________________________

The words they can use are:

“We are departing from ____________________. What changed, what risk are we accepting, and who is approving that choice?”

The decision or escalation path is: ______________________________________

The evidence we will record is: __________________________________________

8. Assign and review

Facilitator prompts

Use these when the discussion becomes abstract or defensive:

• What would a new person observe rather than what would the documentation say?
• When did we last make an exception, and what happened afterward?
• What would have to fail before we admitted this was unsafe?
• Are we accepting this risk explicitly, or merely inheriting it?
• Is the standard wrong, or are we under-resourced to follow it?
• What evidence would change our mind?

The goal is not perfect compliance. The goal is to prevent an unexamined exception from becoming the operating system.