Contents
A change advisory board is set up to increase control. Past a certain point it starts working the other way: as approval time grows, work does not stop, it reroutes. This article covers when a board turns into a bottleneck, which channels work escapes through, and how to speed up without losing control.
Symptoms of a Bottleneck
A bottleneck rarely announces itself directly. If three of the symptoms below are present at once, the board is no longer producing control, it is producing delay.
The agenda overflows. If a weekly meeting has thirty items and lasts an hour, each item gets two minutes. The impact of a database script cannot be assessed in two minutes. Approval is given, but no assessment took place.
The emergency share climbs. If more than a quarter of all changes are classified as emergencies, the emergency route has become the way around the waiting time. The genuine emergency count is never that high; what rose is not urgency, it is impatience.
Requests arrive in a batch just before the meeting. Teams hold work back to catch the next board and submit at the last minute. The board's rhythm now leads the work's rhythm; work gets scheduled by the calendar rather than by technical need.
Almost nothing gets rejected. A board that has not rejected a request in months does not have flawless submissions, it has no time to filter. As the approval rate approaches one hundred per cent, the board stops being a control and becomes a logging step.
The number to measure
Measuring process maturity by the number of approval steps is misleading. What should be measured is the time from opening a request to executing it. As that time grows, so does the amount of work done outside the process. The relationship is linear, and most organisations track the first number while never measuring the second.
The Moment Work Escapes the Process
When a board becomes a bottleneck, people find ways around it. Changes get pushed without review, documentation gets skipped, and visibility into what is actually changing in the environment is lost. This is not bad faith, it is design; work has to finish and it takes the shortest available road.
At the database layer the escape channels are unusually plentiful, because there are many ways to reach a production database other than the approved one.
| Escape channel | How it gets justified | What it leaves behind |
|---|---|---|
| Emergency classification | "A customer is affected, this cannot wait" | A record exists but the post hoc review never happens; debt accumulates |
| Connecting directly with a management tool | "It is a one line fix, not worth opening a request" | No record at all; nothing but the server log |
| A script tucked inside an application release | "The release is already approved and the script is part of it" | Approval was given to the release; the database change was never assessed on its own |
| Scheduled jobs and maintenance scripts | "This is routine maintenance, it does not count as a change" | Its content was written years ago; nobody has read what it does today |
| Vendor or consultant access | "The product's own updater does it" | The organisation did not make the change but carries responsibility for it |
The most uncomfortable part of this table is that none of these channels is seen as a rule violation. Every justification in it is reasonable in the moment. The organisation does not experience rule breaking, it experiences falling out of scope, and that never shows red on a dashboard.
Approval Fatigue: What Happens When the Board Fills Up
The escape channels create risk outside the process. Inside it a different decay sets in: the approver sees so many items that none of them can genuinely be examined.
The concrete result is that approval detaches from content. The approver trusts the sender rather than the script. "If it came from Ahmet it must be fine" is not a control, it is key person dependency in its purest form. When Ahmet leaves, what disappears is not an employee but the real control mechanism of the process.
The remedy for approval fatigue is not another call for discipline. It is reducing how many items reach the approver, and putting a summary of the assessment next to each one that does. If an approver can see what is risky without reading the whole script, they can focus on three items instead of thirty.
Distributing Authority by Risk
When ITIL 4 renamed change management to change enablement, this was exactly the problem it targeted. What the framework says is clear: approval authority should be distributed by risk rather than routing every change to a central board. Sending standard and minor normal changes to the board is called an anti pattern, on the grounds that it creates a bottleneck without improving change quality.
The same framework states that a change authority can be a person, a team or an automated mechanism. Most organisations miss that detail. Authorisation does not have to be a meeting; a defined, repeatable mechanism that leaves a record also counts as authorisation.
Speeding up is not reducing control
Taking low risk work off the board does not mean that work goes unrecorded. The record is still kept, risk is still measured, the trail is still left; the only thing that changes is who takes the decision. Most organisations conflate the two and clog the board in the name of not losing control, ending up both slower and with wider escape channels.
How to Build It at the Database Layer
The counterpart of risk based authority at the database layer has four parts, and all four have to work together.
Deriving risk from the script. The band is not chosen by a person, it is determined by the content. An unqualified update, touching a table on the critical object list, an irreversible operation: these are all written rules, and the same script always lands in the same band. Key person dependency ends here.
Approval depth by band. A low band passes with a single approval or with pre authorisation. A middle band needs the relevant team lead. A high band requires multiple approvals and a stated reason. Only the top band reaches the board's agenda, and thirty items become three.
Tying approval to a gate. Approval is a condition rather than a field. Execution does not open until approval completes, and an approver cannot execute their own request. Without this, speeding up genuinely does reduce control; with it, speeding up only removes needless waiting.
Measuring the emergency route. The emergency route is not closed, because closing it pushes work entirely out of the record. Instead every change taking it produces a post hoc review record that stays on an open list until closed. If the list grows, the escape channel gives itself away.
Four Numbers to Measure
Whether a board is healthy shows in four numbers. All four can be produced today from your existing records.
| Number | Healthy signal | Warning signal |
|---|---|---|
| Time from opening a request to execution | Hours for low risk work | The same for every band and measured in days |
| Share of changes classified as emergency | Low and stable | Rising quarter on quarter |
| Outstanding post hoc reviews | Close to zero, closed within days | Not even counted |
| Rejection rate | Non zero, with recorded reasons | Zero for months |
If two of these four are off, the problem is not the team, it is the design of the process. Another call for stricter compliance will not fix this table; distributing authority by risk will.
SQL Change Guard builds this model for work that touches the database: it measures risk from the content of the script, sets approval depth by band, ties approval to the execution gate, and keeps the post hoc review debt of the emergency route on an open list. Your board does not disappear; it simply sees only the work that genuinely needs assessing.
Frequently Asked Questions
Should we abolish the change board entirely?
No. The board is the right place for high risk changes that genuinely need assessment, and there its value is high. What should be removed is not the board but the low risk items on its agenda. When thirty items become three, the board starts doing its real job for the first time: actually discussing those three.
If we take low risk work off the board, will that cause an audit problem?
The opposite. ITIL 4 explicitly recommends distributing authority by risk and states that a change authority can be an automated mechanism. What an auditor looks for is not that every change went to a board, but that every change was assessed against a defined authority, recorded and traceable. Pre authorisation does not remove the record; it means the identity of the approver is settled in advance.
Who sets the risk band? What if the submitter picks a low one?
The submitter must not choose the band; that single mistake invalidates the whole model. The band should be produced from the content of the script by written rules: which object it touches, whether it is on the critical list, whether there is an unqualified update, whether it can be rolled back. A user cannot lower the band, only request a justified exception, and that exception is recorded separately. The real benefit of handing assessment to a machine is not speed, it is reproducibility.
If we restrict the emergency route, what do we do in a real emergency?
The emergency route should be measured, not restricted. Closing it does not stop the work, it only pushes it out of the record, which is the worst outcome. The right design is this: the route is always open, every change taking it is logged with a stated reason, and it produces a review record afterwards. That record stays on an open list until closed. A genuine emergency is never blocked, while use for convenience becomes visible.
How do we reduce approval fatigue?
With two things: reducing how many items reach the approver, and putting the assessment summary next to each one that does. If an approver can see at a glance which object the script touches, which rules fired and whether a rollback script was produced, the decision becomes a real decision. An approver forced to read every script in full stops reading after the third item.
Let us produce the four numbers together
Bring your own change records; we will show live how approval depth by risk band speeds the flow up.
Book a Demo →