Contents5 sections
Hold: Why the Process Gets Frozen Before It Gets Measured
Measuring a process that is still being changed produces a baseline nobody can defend. Hold stops the drift for long enough to get a real number.
The stage nobody wants to pay for
Hold sits between the diagnosis and the measurement. It ships nothing. It produces no diagram anyone will put in a deck. It is, reliably, the first stage a client asks to skip, and the request is reasonable on its face: the problem is understood, the candidates are chosen, why are we not building.
Because the number that justifies the build has not been taken yet, and it cannot be taken against a moving target.
Processes move while you watch them
Every operation is being informally redesigned all the time. Somebody adds a check after a bad week. Two of four people adopt a shortcut. An exception path invented for one awkward client gets reused for nine more.
None of that is misconduct. All of it is invisible, because nobody announces it, and all of it lands in the middle of a measurement window.
The result is a baseline that is an average of two processes, weighted by how long each one happened to run, with no way to separate them afterwards. You will not know. You will find out after go-live, when the honest re-measurement makes the automation look like the thing that underperformed.
What Hold actually freezes
The definition, not the work.
- Which steps are inside the workflow and which are outside it.
- What counts as an exception, written down rather than understood.
- Who may change either of the above while measurement is running.
Alongside that, the data-quality holes that would corrupt the measurement get closed: the field populated half the time, the two systems that disagree about the same record, the timestamp that records when someone got round to logging the work rather than when the work happened.
What breaks without it
The failure is not dramatic, which is exactly why it survives. The project proceeds, the build ships, and somewhere in month two the numbers stop agreeing with each other. The team remembers the old process being slower than the baseline says. The vendor remembers it being faster.
Neither can prove anything, so the argument is settled by seniority, and the honest answer - that the baseline was taken against a process that no longer existed - never gets said out loud because nobody has the evidence to say it.
The alternative is a fortnight spent on nothing visible. That is the trade, and it buys the one thing that makes the measurement afterwards worth taking: a process that will still be the same process when the numbers come back. The wider discipline this sits inside is in the audit before automation.
Where it sits
Hold is the second of six stages. The one before it decides what is worth measuring, and the way that decision is made is described in what the Break map shows. The whole sequence, applied to one deployment, is in the protocol end to end.
01What is actually being frozen?+
The definition of the workflow, not the work. Nobody stops doing their job during Hold. What stops is the informal redesign that runs continuously in most operations: a step quietly added last month, a rule that two of the four people follow, an exception path invented for one client that has since been used for nine. Those changes are usually improvements, and they are still fatal to a baseline, because the thing being measured in week three is not the thing that was mapped in week one. The freeze is a written statement of which steps are in scope, which cases count as exceptions, and who is allowed to change either during the measurement window. It expires when Track ends.
02Why not measure first and stabilise later?+
Because you cannot un-mix a measurement. If the process changed halfway through the window, the number you have is an average of two processes weighted by how long each one ran, and there is no way to recover the components afterwards. You will not even know it happened, because the change was not announced - it was somebody being sensible on a Tuesday. The cost of finding out later is not just a wasted fortnight: it is that the build has already been scoped against the corrupted number, and the first honest re-measurement lands after go-live, when it reads as the automation underperforming rather than the baseline being wrong.
03Does Hold ever change the plan from Break?+
Regularly, and in both directions. A candidate that looked feasible turns out to depend on a field that is populated correctly about half the time, which moves it down the queue or off it. Equally, a workflow deferred at Break specifically because its data was too dirty to automate against can become viable once Hold has closed the holes, and it gets re-scored rather than left for dead. This is why the priority matrix from Break is a document rather than a decision: it is meant to be revised once, on evidence, before anything gets built, and never again after.
04What does the client see for the money in this stage?+
A written scope for each target workflow, a list of the data problems found and what was done about them, and an agreed exception policy - which is usually the first time anyone has written down what the team already half-knows. Operators tend to find the exception list the most useful artefact of the whole engagement, because it is the document that reveals how many special cases the process is quietly carrying. It is also the reason the build later comes in on time: an exception discovered in week three is a paragraph, and the same exception discovered in week nine is a change request.
