Introduction
Temporary decisions, if not revisited later, become part of the process. Almost every team has heard it at least once.
Just this once, we have to do it this way.
Exceptions are not an issue. Sometimes they're necessary, but once you become addicted to them, you won't be able to stop.
The Exception
In a perfect world, you would build a process once and never need to change it.
However, we're not in a perfect world. Exceptions happen because of several factors, such as:
Production incidents.
Regulatory deadlines.
Dependency.
Business pressure.
The problem with exceptions is that they make things seem easy. An exception is made to skip part of the process to meet a deadline, which speeds things up. Once things slow down again, the exception made earlier is mentioned again.
We did it before. Why can't we do it again?
Once another exception is made without a valid reason, then it becomes a rule or almost one.
Because it's easy, it's fast, and it makes things appear smoother. But it's not.
It breaks the process and changes the rules. Until eventually the exception becomes the actual process.
The Exception Becoming a Rule
Exceptions are rarely done once. They become a habit to speed the process.
Eventually, people start second-guessing the process. Because compared to the exception, the process is making things harder than they need to be.
But a process and a rule are not usually made out of nothing. Something happened in the past that made this rule a must. When ignored, you risk falling into the same issues that made the process and rules in the first place.
When an exception becomes a rule, when it becomes a process. It breaks the original rules.
Eventually, you forget that it was an exception. It becomes part of the process itself.
The Cost Behind The Exception
The cost behind the exceptions is not immediate. You won't feel the impact until it's too late.
It accumulates over time, until the process becomes inconsistent.
Exception
↓
Another Exception
↓
Lost knowledge about the original process
↓
Chaos
When the exceptions accumulate over time, the knowledge gets lost.
Eventually, nobody knows the original process, and nobody knows which rules apply.
New people don't learn the actual process. They only know about the exceptions.
What's worse is if these exceptions are not tracked, they're just known.
Why is this part of the process?
Because we've always done it this way.
And that is the actual problem and cost of the exceptions.
The most dangerous exceptions aren't the ones everyone knows about.
They're the ones everyone believes are part of the original process.
Why Exceptions Become Permanent
An exception is usually created during urgency. Once the urgency is done, the team moves on to the next thing. The exception remains undocumented, and nobody goes back to it.
That's why temporary fixes become permanent until they eventually become part of the process.
Ownership of implementations is important. Every temporary exception should have an owner responsible for documenting it, reviewing it, and ensuring it is reverted when it is no longer needed.
Otherwise, it becomes permanent, since it resolved the issue and made things easier. Nobody will look into it anymore.
Temporary fixes without an expiration date become part of the process in the future.
When is an Exception Justified
Exceptions are not an issue in themselves. The issue is only when they become permanent and become part of the process. In some situations, an exception is justified.
When?
- Production incidents.
- Regulatory deadlines.
- Financial risk.
But if someone wants to make an exception just to speed things up, then is the exception really necessary, or is it simply more convenient?
Before making an exception, ask why it is necessary. Is there a situation that genuinely requires bypassing the normal process, or is the original process simply inconvenient?
Exceptions should be made under clear guidelines and rules.
Otherwise, you risk the original process.
Evaluate the Process
If the same exception keeps being necessary to the point where it becomes part of the process, then maybe the original process needs evaluation.
Processes are not made to be difficult. They're designed to streamline work and prevent issues that were identified previously.
The parts of the process that are slowing the delivery should be reviewed and improved, rather than relying on shortcuts and exceptions to move things more quickly.
Managing Exceptions
To manage exceptions, a clear guideline and ownership are required.
Is the exception genuinely required?
When is the end date for this exception?
What possible issues could be introduced by implementing this exception?
Who is the owner of this exception?
Defining clear guidelines and ownership is important. Guidelines help in managing and minimizing the risks that come from implementing several exceptions over time.
Ownership does not mean that any issue caused by the exception is solely the owner's responsibility, nor does it mean they must personally revert it. Their responsibility is to document the exception, track it, and ensure it is reviewed and reverted once it is no longer needed.
Conclusion
Exceptions are not an issue if managed properly with clear guidelines and ownership. They become an issue once they're ignored after implementation. If not revisited, they become part of the process and might affect it.
Sometimes, exceptions are necessary and cannot be avoided, especially if there's a production incident.
However, if the same exception and shortcuts are needed over and over again, they become an indicator of a flaw in the process.
Review the process, document the exceptions, and give clear ownership.
Otherwise, "just this once" eventually becomes "this is how we do it".