Tuesday, 10 a.m. Change request forty-seven: a customs declaration field the biggest customer needs before go-live. The business case is solid, the estimate says three days, and the change control board approves it five to nothing. It is the eleventh approval this quarter, and every single one of them was reasonable. The release is now three weeks past the date everyone shook hands on in January — and nobody can point to the meeting where that happened.
That is the uncomfortable thing about change control: the process usually works exactly as designed. The problem is what the design leaves out.
The board is doing its job
A change control board exists to stop scope from wandering into a release unexamined, and at that job it succeeds. Every request gets a business case, an owner, a review, and a recorded decision. This is the front door of scope management, and unlike the side doors — the “small ask” folded into an existing ticket, the polish nobody requested — nothing gets through it unnoticed.
But read the minutes of any change control board and notice what they contain: a ledger of decisions, not a ledger of schedule cost. Each change is judged on its own merits, one meeting at a time, as “small” — and small is measured against a delivery date that was priced months ago, under different assumptions. The change log fills up. The committed date, on paper, stands perfectly still.
The vote priced a scope. The approvals changed it.
When your team committed to that date, the commitment was a confidence vote: expert engineering judgment pricing a specific scope against real delivery evidence. That judgment was sound on the day it was given, and it stays sound as long as its assumptions hold. An approved change re-opens the biggest assumption of all — what is in scope. It is one of the three things that quietly erode a committed release date, wearing its most respectable outfit: scope change with a signature on it.
And approved changes rarely travel alone. The customs field needs a data migration from the platform team — a dependency that did not exist at commitment. The one engineer who knows the customs API gets pulled off other committed work — a capacity change nobody wrote down. Approval is a governance event; absorption is a schedule event. The board confirms the first and quietly assumes the second.
Give the board a price tag
Release Management, Roadmaps & Product Portfolio for Jira keeps a release’s committed date next to a live forecast: Monte Carlo simulation runs on your team’s own delivery history and draws a 50/85/95% confidence band that re-computes as Jira data changes. The team still owns every assumption that matters — which throughput window is representative, whose capacity counts, what is in scope. The app’s contribution is arithmetic at a scale no meeting can do by hand, kept current between meetings.
For a change control board, that changes the question on the table. Add the candidate change to the release scope and the forecast re-prices the committed date immediately — in days, attributed to what moved. “Is this change justified?” becomes “this change costs four days of confidence at the committed date — is it worth four days?” Often the answer is yes. The point is not to refuse change; it is to approve change at its real price instead of at zero. Eleven small approvals stop being eleven separate roundings-down-to-nothing and show up as one honest, cumulative number against the date the team promised.
When the board becomes the renegotiation forum
Sooner or later, a quarter’s worth of approved change pushes the committed date below the confidence level the team voted on. That is not a failure of the board — it is the signal that the conversation in the room has changed. The board already gathers the people who own scope, capacity, and dates, which makes it the natural venue to renegotiate the release date before it slips: trade lower-ranked scope back out, adjust capacity, or re-commit to a new date with its confidence stated out loud.
Boards that re-price every change as they approve it get one more thing for free: they never have to discover the whole slip at re-baselining time. The drift was on the record all along — in days, with attribution, one decision at a time.
The paperwork that feeds the board has the same blind spot: a change impact analysis that reports effort against the original baseline will say “no schedule impact” for every one of those forty-seven requests.
Put a price on the next change request
Before your board’s next meeting, see what an approval actually does to your date. Release Management, Roadmaps & Product Portfolio for Jira shows the committed date and its live confidence band side by side, so every change request arrives with its schedule price attached. See how the renegotiation workflow reads the band in the feature docs, or try it on your own Jira data from the Atlassian Marketplace.
3 Comments
Leave your reply.