Why the freeze gets approved
The freeze gets approved because it costs nothing on the spreadsheet that the steering committee is looking at. The features that would have shipped are not in the plan. The team is already paid. The risk being avoided is large and visible. The risk being accepted is diffuse and easy to discount.
Six months after launch the post-mortem looks different. The features that did not ship turn out to have been the ones the commercial team had been pushing for. The team that lost momentum took two quarters to get it back. And the launch risk that the freeze was supposed to reduce showed up anyway, because the bugs found during the freeze were the bugs the freeze was supposed to prevent.
Putting a number on it
There are four numbers worth calculating, and none of them are difficult.
Lost feature revenue. The reasonable estimate is the trailing six-month average uplift from shipped features, prorated for the freeze period. For most commerce teams this is one to three per cent of revenue per quarter of freeze. The number is rarely small.
Team productivity tax. A team that has not shipped for four weeks takes about two weeks to return to its previous velocity. That is a six-week cost for a four-week freeze. It is real and it is rarely accounted for.
Concentrated launch risk. Every bug that would have been found and fixed in the normal cadence is now found in the launch window. The cost is not the bug, it is the decision-making overhead of fixing it under pressure.
Opportunity cost on the commercial calendar. The campaigns that were planned around the freeze, the supplier negotiations that were timed to it, and the operational changes that were deferred until after it. These are real and they are easiest to quantify by asking the commercial director what they would have done without the freeze in the plan.
"A freeze trades a series of small course corrections for one large gamble on launch day. That trade should be priced."
When a freeze is still the right answer
A freeze is the right answer when the alternative is worse. Specifically, when the data migration is genuinely one-shot, when the team is too small to run two parallel cadences, or when the regulatory environment requires a clean launch with a documented change window.
In those cases the freeze is a tool, not a failure. The honest version of the plan names it as a tool, prices it properly and tells the business what it is buying. The dishonest version hides the cost and pretends it is free.
The conversation worth having before the next one
The most useful artefact a programme can produce is a one-page freeze cost model, calibrated against the last freeze the business ran. It does not need to be sophisticated. It needs to be defensible enough that the next time a freeze is proposed, the conversation starts with a number rather than an assumption.
The point is not to ban freezes. It is to stop them being free.
