Policies, Standards and Exception Workflows

Policies, Standards and Exception Workflows

Policies set the default; the exception workflow keeps the default survivable.

Why it matters

A policy with no exception process is a policy people quietly route around. DMBOK's discipline: every policy has a documented exception path with an SLA, an approver and an expiry. That's the difference between enforced and theatre.

Going deeper

Anatomy of a survivable policy (3-page template, no more):

• Statement — one sentence, an outsider can paraphrase it correctly.
• Scope — what's in / out (don't apologise; be explicit).
• Standards — measurable rules that operationalise the statement.
• Exception path — who requests, who approves, what the SLA is, when it expires.
• Owner + review date — every policy ages; without a review date it rots in place and quietly becomes a lie.

Anti-pattern: a 40-page policy with no exception workflow. Teams will create an exception by ignoring it — and now you've lost visibility instead of enforcing anything.

Policies without an exception workflow are a locked emergency exit.

A locked exit is worse than no exit at all: people still want to leave, so they smash the glass or prop the door open, and now neither the lock nor the alarm works. The civilised answer is a push-bar with an alarm: it opens when needed, the alarm preserves your visibility, and the building stays compliant.

A well-built exception workflow is that push-bar. Teams that need to deviate can, the deviation is logged + time-boxed, and you keep the visibility that a blanket ban would destroy.