A change request process that fits on one page

Search for a change request process and you get one of two things: a change control board with a form, a log and a fortnightly meeting, familiar from regulated IT; or nothing, which is what most engineering teams actually run. The first is too slow for a team that ships weekly. The second is how a commitment ends up twice its size with nobody able to say when that happened.

There is a version in between that fits on a page. It rests on one idea: a change is anything that alters what was promised, and it gets recorded against the promise.

Two things this is not

It is not the handling of a new urgent demand that arrives mid-quarter and needs capacity. That is a displacement between commitments, and the mid-quarter ask covers it. This essay is about changes inside a commitment that is already being delivered: the extra report, the additional market, the "while you are in there".

It is also not a cure for scope creep, exactly. Creep is defined by being unrecorded. A change request is the same addition made on the record. The process below does not reduce the number of changes. It converts creep into changes, which is the only conversion available.

First, a baseline to change

A change is only visible against a written baseline. If the commitment was "do the invoicing thing by November", every later request is arguably inside it, and the argument will be settled by seniority.

The baseline needs four things in writing: the outcome, the capacity each delivering team agreed to, the target date, and the out-of-scope list, the short set of adjacent things that were explicitly excluded and why. The last is the one that does the work. When a request arrives for something on that list, the conversation is not "can we add this" but "we decided not to, for this reason; has the reason changed?"

What a change request must state

Five things. If the person asking cannot supply the first two, it is not yet a request. If the team cannot supply the third and fourth, it is not yet decidable.

1. What changes, in outcome terms. Not "add a CSV export" but "finance can reconcile carrier invoices without asking engineering for a data pull". The outcome form is what lets the team propose something cheaper.
2. Why now. What has happened since the commitment was made. New information is a good reason. "We forgot" is also a legitimate reason, and worth writing down because it is a finding about how the work was shaped.
3. What it costs, per team. In FTE-months, from the team that would do it. Never from the requester, and never "it's small".
4. What it does to the date. Including "nothing", if that is the team's answer.
5. What is given up in exchange. Something else in scope dropped, the date moved, or capacity taken from a named other commitment. "Nothing" is only allowed when the third answer is close to zero.

That is a paragraph of writing, not a form. If your process needs more than this, you are either in a regulated context where it genuinely does, or the extra fields are there to discourage requests. Discouragement works on the polite requesters and not on the ones you were worried about.

Who decides

One person: the owner of the commitment. A person, not a team and not a board. The roles around them are narrow. The delivering team supplies the cost and the effect on the date, and that figure is not the owner's to negotiate down. The person who was promised the original outcome is consulted if the change touches the date or the outcome, since it is their promise being edited. Everyone else is informed.

The decision should take a day, not a cycle. A change request waiting two weeks for a meeting gets built in the meantime by an engineer being helpful, and then the meeting is ratifying a fact.

Three answers, and the one to eliminate

Absorb it, on the record. The change is small, the date and outcome hold, and nobody outside the team would notice. Do it, and write one line: what was added, when, at whose request. The line matters more than it seems, because absorbed changes accumulate. Five one-line absorptions on a commitment is a re-baseline that has not been admitted yet, and the list is how you see it coming.

Re-baseline, with a reason. The change moves the date, the capacity or the outcome. The commitment is restated, the delivering teams re-agree their figures, and the reason is recorded next to the original, which stays visible. The people who were planning against the old baseline are told the same day. A re-baseline is not a failure. It is what an honest record of a changed promise looks like, and a quarter with several of them, each with a reason, is more trustworthy than one with none.

Refuse it, and let it return as its own request. The change is real work but does not belong in this commitment. It goes back through the door as a new request, to be shaped and decided on its merits. That is not a dismissal. Many changes are better as the next piece of work than as an appendix to this one.

The fourth answer is the silent absorb: agreed in a thread, built, never written down. It feels like good service. It changes the promise without changing the record, so when the date slips the record says the team missed, and the decision that caused it has no author. Removing that answer is the entire purpose of the process.

Absorb or re-baseline: where the line is

Use a test instead of a threshold number. Would anyone outside the delivering team notice the effect, in the date or in the outcome? If not, absorb and note it. If so, re-baseline. Add one counting rule: when the absorbed notes on one commitment add up to something that fails the same test, re-baseline then. Each addition being "only a day" is the whole mechanism of creep.

The checklist

Copy it as it stands.

• Is there a written baseline: outcome, capacity per team, date, out-of-scope list? If not, write it before deciding anything.
• Is the request already on the out-of-scope list? If so, has the reason for excluding it changed?
• What changes, stated as an outcome?
• Why now: what is different from the day we committed?
• Cost per team in FTE-months, given by the delivering team.
• Effect on the target date, given by the delivering team.
• What is given up in exchange?
• Decision by the owner: absorb and note, re-baseline with a reason, or refuse and send to intake.
• If re-baselined: teams re-agreed their figures, the reason is recorded, the original is kept.
• Who was planning against the old baseline, and have they been told today?

What the record buys you at the end

When the commitment closes, the comparison between promise and result is only fair if the promise is the current one. A team that delivered the re-baselined scope on the re-baselined date kept its word, and the ledger should show both that and the changes that got it there. Without the change record the same delivery reads as a miss. The process protects the team at least as much as it protects the plan.

Where DeliverySheet sits

DeliverySheet does not run this process for you. There are no change notifications (the only email is an optional weekly summary to the workspace owner), so nobody is told automatically that a commitment changed; telling them is still your job. What it holds is the baseline and the record of the change: a commitment has an owner and capacity estimated per team in FTE-months, re-baselining it requires a reason, and the re-baseline is kept on the commitment ledger. At the close, the delivery outcome is recorded as delivered, delivered with exclusions or not delivered.