The forty minute board that approves everything
A change advisory board that clears thirty-one records in forty minutes has not reviewed anything. That works out to seventy-seven seconds per change, most of it spent reading the short description aloud while the requester nods. I sat in that meeting every Thursday for two years before we admitted the board existed to collect signatures.
The change that forced the issue said routine patch. A minor version bump on a middleware server, submitted by an engineer who had done the same thing eleven times. Nobody in the room owned the two file transfer jobs running through that box at two in the morning. The patch restarted a service with a changed default timeout, and the nightly order feed to the warehouse failed quietly for three nights.
The board approved it because nothing in the record told anyone to look harder. Risk read Moderate, which is what the form defaults to. Impact read Low. The backout plan read uninstall patch and reboot. Every field was populated and none carried information. The fix runs in two parts, a shorter agenda and a record format that refuses vague answers.
Take the proven work out of the room
Start by shrinking the agenda, and the mechanism ServiceNow already ships is the standard change catalog. A standard change is pre-approved work with a published template and a fixed set of steps, so it never reaches the board. Most shops have it enabled with four vendor-supplied templates sitting in it, because nobody wants to own the promotion process that would add more.
Set a real bar for promotion and publish it. We required that the change type had run at least ten times in the previous twelve months, closed successful on every one, carried a verification step someone other than the implementer could run, and had a backout that needed no judgment call. Proposals went to a three-person review rather than the full board.
Inside one quarter we moved certificate renewals in non-production, scheduled index rebuilds, firewall rule additions from an approved source list, and DNS record adds into the catalog. Thursday's agenda fell from thirty-one records to nine, and the nine got actual discussion. None caused an incident in the eight months that followed, which is the number that stops people dragging work back into the meeting. The same discipline that turns a service catalog into an operating contract applies here.
Risk scoring that gets applied instead of defaulted
Risk on a change record is usually whatever the requester picked to avoid extra approvals. If the field is set by hand and ninety percent of your changes arrive at Low or Moderate, the field records preference and nothing else. Pull your last ninety days before you argue with me about that.
Derive the score from things the requester cannot shade. Risk conditions in ServiceNow read the configuration item, so score on the business criticality of the affected service, the count of downstream items in the relationship map, whether the change touches an integration endpoint, and whether this implementer has run this type before. Weight the downstream count heavily, because that field would have flagged the middleware patch.
That only works if the CMDB knows what depends on what, which is the uncomfortable part. A relationship map that stops at the server layer scores every application change as isolated. Service mapping accurate enough to drive approvals is a real project with a budget line, and it carries the same argument for why the CMDB has to be right before anything reads it. Score with what you have and publish the gaps beside the scores.
What the backout field has to say before approval
Reject any change whose backout plan fits in one sentence. Restore from backup tells the board nothing about whether restoring is possible on a Tuesday afternoon. A backout plan has to name the artifact being reverted to by version number, the person who executes it and the person who authorizes the call, how long reversion takes, and the point after which it stops being possible.
That last item is where boards get caught. A schema migration that has already accepted writes cannot be undone by redeploying the previous release. If the change contains a one-way door, the record has to say what time that door closes and what the recovery plan becomes afterwards. I have held changes in Assess until the implementer added a pre-migration snapshot and a fifteen-minute hold before the first cutover write.
The other field worth defending is verification. Who confirms the change worked, using which check, inside what window, and the answer cannot be the implementer saying it looked fine. The warehouse feed would have been caught by one verification step owned by the integration team, and nobody wrote one because nobody knew the feed existed. That is an ownership gap before it is a process gap, and it runs straight through the argument over who owns the CMDB.
Emergency changes and who gets to declare one
An emergency change means one thing. An active severity one incident, or a credible and imminent one, where the normal approval path would make the damage worse. A release that slipped past Friday's window does not qualify, however loudly the project manager says otherwise.
Name the roles allowed to declare it. At that client the on-call incident commander and the duty service owner could, two people per shift, and no one else. The requester could ask, but the declaration was not theirs to make. The emergency board was three people on a bridge inside twenty minutes, with the record written within twenty-four hours and reviewed the following Thursday.
Then measure the rate, because that number says something the meeting never will. Emergency changes running above roughly eight percent of monthly volume point at a planning failure upstream. We ran at nineteen percent for half a year, pulled the records, and found two thirds were security patches that missed a normal window because patch triage had no owner. That is a scheduling problem, and ranking patches when everything is marked critical is where the fix starts.
Post implementation review only where it pays
A post implementation review on every change guarantees you run none of them properly. Trigger it on four conditions, the change failed, the change was backed out, the change was declared an emergency, or the change preceded an incident on the same service inside seventy-two hours. Everything else closes on its verification step.
The review runs thirty minutes and answers four questions. What did the record say would happen, what happened instead, which field would have exposed the gap had anyone filled it in honestly, and what has to change in the template or the risk conditions so the next one scores differently. That last question is the entire reason for holding the session.
Feed the output in both directions. Change types that keep passing cleanly become candidates for the standard catalog. Types that keep producing surprises earn a new risk condition or a required extra approver. We added an integration owner approval on anything touching an item with an outbound interface, which cost four minutes of average lead time and caught eleven changes in a year with no owner listed for the thing they would break.
Before your next board, pull the twenty records the meeting spent the least time on and read their backout plans. A change sent back for a better record costs the requester a week. The one that took down the order feed cost three nights of missed shipments plus a weekend of reconciliation, and most of the first thirty minutes of that incident went to working out which change had caused it. What is on Thursday's agenda that nobody in the room owns?
