Requesting Exceptions
A framed exception request asks for a one-time, time-bounded exception, not a permanent change to the standard process.
Try it: try / except / else / finally
How an exception jumps out of a try block to the first matching except clause, when else runs, and why finally always runs.
How it works
- Statements in try run until one raises an exception; the rest of try is skipped.
- Python checks the except clauses in order and runs the first one whose type matches.
- If nothing was raised, the else block runs instead.
- finally runs in every case.
Default run (9 steps): Call safe_divide('4'). … Return 25.0. Output was: Worked: 25.0 / Done.
Simplified: One fixed function; int() and / are modelled exactly (including how Python prints floats), but nothing is executed as Python.
Loading the simulation…
Why the Wording of a Request Matters
Suppose you are on a project with a deadline that the standard IT process cannot meet. You need IT to make an exception. The way you describe that exception will shape the answer you get. A request that sounds like a request to rewrite the rules invites a long review, and a refusal is easy to justify. A request that sounds small, bounded, and accountable is much easier to approve. This article looks at how to frame an exception request so that it is easier for the IT team to agree to it.
What do you think happens?
Two people ask IT for the same exception. The first asks IT to change how all future projects are approved. The second asks for a single exception for one project, with a named owner, a way to undo the change, and an end date. Which request is easier for IT to approve, and why?
Reveal answer
The second request is easier to approve, because it is smaller and bounded.
The source states that framing makes the request smaller, and a smaller request is easier to grant. A request that sounds like a rewrite of the rules invites a long review, while a request that is small, bounded, and accountable is much easier to approve.
Tracing Where the Exception Branches Off
The diagram below shows the path a project takes when it needs an exception. Most work follows the standard process. When that process cannot meet a project's deadline, the project asks for a framed exception. If IT approves it, the work takes a temporary branch away from the standard process. When the deadline arrives, the exception is either adopted into the standard process or closed, and the work returns to the standard path.
Read the diagram from left to right and notice what does not happen. The standard process itself is never rewritten. The exception is a detour that has a start, a revert point, and an end. That is the core idea behind the framing discussed in the rest of this article.
Framing a Request as One-Time and Time-Bounded
A framed exception request asks for a one-time, time-bounded exception, not a permanent change to the standard process.
Start by being clear about what you are not asking for. The person making the request, referred to in the source as the FDE, is not asking IT to permanently change the standard process. The request is not a proposal to rewrite the process for every future project. It is a narrower ask about one situation, for one period of time.
A framed exception request is built from three elements. The source describes each one as answering a question the IT team will naturally ask. Who is responsible for this? How do we undo it? When does it stop? The three elements are covered in the subsections below.
Why Framing Helps the IT Team Say Yes
The three elements work together. Ownership gives the IT team a contact. The revert path shows the change can be undone. The deadline shows the change will be decided rather than left to drift. Remove any one of the three and the request starts to look like the open-ended change that the FDE is trying to avoid.
The source makes a point that is easy to skip past. Framing makes the request smaller, and a smaller request is easier to grant. It also gives the IT team a way to agree without weakening its position. If the team approves a bounded exception with an owner, a revert path, and a deadline, it has not set a precedent that obliges it to approve every later request for the same thing. The bounded framing protects the IT team's standards while still allowing the project to move.
Tracing an Approved Exception Through Its Lifecycle
Once a framed request is approved, the exception passes through a short sequence of states. The diagram below follows it from request to decision. Notice that the only event that moves an active exception off the path is the deadline, at which point someone decides whether it is adopted into the standard process or closed.
The source does not describe any state beyond the deadline outcome, so the diagram stops there. The key point for a learner is that an active exception is never open-ended. Its path is set by the deadline, and that is what keeps the exception one-time.
A Clinical Documentation Engagement
The source illustrates these ideas with a clinical-documentation engagement at a regional health system. The customer wanted to deploy an agent that drafted clinical notes from the audio of a patient visit. The promise to clinical staff was a forty-minute reduction in after-hours charting per clinician per day. The promise to executives was a reduction in clinician burnout and in the cost of locum coverage for staff who were leaving.
The source notes that this project had a clear value case, and also the largest compliance surface of any project the team had attempted. That combination is exactly the kind of situation in which an exception request may be needed, and in which its framing matters. A strong value case makes the request worth considering. A large compliance surface makes an open-ended request hard to approve. A framed request lets the team pursue the value while keeping the compliance risk bounded in scope, owner, and time.
Mistakes When Writing an Exception Request
Common mistake Asking IT to change the standard process for all future projects
What it looks likeWe need IT to let us skip the standard review for our project and for future projects like it.
Why it failsThis sounds like a request to rewrite the rules, which invites a long review and makes refusal easy to justify.
Do this insteadLimit the ask to one situation and one period of time, and state that the standard process is not being changed.
Common mistake Naming a team instead of an owner
What it looks likeThe project team will be responsible for the exception.
Why it failsIf the exception causes trouble, the IT team has no single person to contact.
Do this insteadName the individual who is accountable for the exception.
Common mistake Leaving out the revert path
Why it failsWithout a way to undo the change, saying yes feels like an irreversible commitment.
Do this insteadDescribe how the change would be reversed if the exception causes problems.
Common mistake Omitting the deadline
Why it failsWithout an end point, the exception can drift into permanence without a decision being made.
Do this insteadState the date by which the exception will either be adopted into the standard process or closed.
Rewriting an Open-Ended Request
The diagram below compares two versions of the same need. The left side is an open-ended request. The right side is the same need framed with an owner, a revert path, and a deadline. Pay attention to how the framing changes the decision the IT team faces.
Reframing a Vague Request
A project manager writes: We need IT to skip the security review for our tool so we can keep up with the schedule. Rewrite this as a framed exception request.
- 1Identify the scope
Narrow the ask to one project and one period of time. The revised request should not propose changes to the standard security review for other projects.
- 2Name the owner
Add the name of the individual accountable for the exception, so the IT team knows who to contact if problems arise.
- 3Describe the revert path
State how the exception would be undone, so the IT team can see the change is reversible.
- 4Set the deadline
State the date by which the exception will either be adopted into the standard process or closed.
- 5Check the result
Read the rewritten request and confirm that it is small, bounded, and accountable, and that it does not ask IT to rewrite the rules.
Request an exception for this one project, owned by a named individual, with a stated way to revert the change and a deadline by which the exception is adopted into the standard process or closed. The standard security review remains unchanged.
Rewrite this open-ended request as a framed exception request: We want IT to exempt our team from the standard change approval process from now on because our releases are urgent. Your rewrite must include an explicit owner, an explicit revert path, and an explicit deadline, and it must not propose a permanent change to the standard process.
Hints
- Start by stating what you are not asking for, namely a permanent change to the standard process.
- Ask yourself who the IT team would contact if the exception caused trouble.
- Ask how the change could be reversed, and when the exception should be adopted or closed.
Key Takeaways
- A framed exception request asks for a one-time, time-bounded exception, not a permanent change to the standard process.
- A framed request has three elements: explicit ownership, an explicit revert path, and an explicit deadline by which the exception is either adopted into the standard process or closed.
- Each element answers a question the IT team will ask: who is responsible, how do we undo it, and when does it stop.
- Framing makes the request smaller and easier to grant, and it lets the IT team approve without setting a precedent that obliges it to approve every later request.
- An open-ended request invites a long review, while a framed request keeps the decision bounded in scope, owner, and time.