Between the score and the proof lie five steps and several owners.
The question that follows an accepted diagnosis is always the same: now what? The answer is a sequence, not a tool. Most programs that stall do not stall on technical execution; they stall because they skipped one of the steps that make the result demonstrable.
1. Fix the scope before touching anything
Scope is the exact list of what will change: which domains, which services, which termination points. It has to be written before the change because it defines what the final measurement will compare against. A scope defined after execution tends to coincide with whatever worked, and a comparison built that way does not survive careful reading.
2. Record the prior state
A measurement on the ruler, with cutoff date, run identifier, coverage achieved, and calculation mode. Without that record, the later measurement is a loose number: there is no way to tell a real improvement from a collection that simply reached different points.
3. Execute with reversibility
The change happens in the client's environment, carried out by whoever operates it: internal team, integrator, equipment vendor. Two properties matter more than speed. The first is being able to roll back. The second is making sure the change does not silently degrade to a state incompatible with the defined policy. A cryptographic negotiation that falls back to an old version when the client does not support the new one is a rollback nobody asked for.
4. Re-collect under the same conditions
The same collection infrastructure, the same modules, the same engine version, the same calibration. Re-collecting with a different version produces a delta that mixes environmental change with methodological change, and there is no separating the two after the fact.
5. Compare with everything declared
The final comparison has to carry scope, mode, coverage, version, and run for both ends. This is not bureaucracy. An auditor, a board, or your client's client needs to be able to read the result without having taken part in any of the earlier steps, and can only do so when those five fields are written down.
Does GWK carry out these five steps?
What this supports
- Building the plan with the right owner at each step, instead of expecting one vendor to cover them all.
- Requiring a record of the prior state as a condition to start, not as a final deliverable.
- Including reversibility and no silent downgrade in the change's acceptance criteria.
See what is outside the scope of this text
- The sequence describes the path to a demonstrable reduction within the changed scope. It does not estimate cost, timeline, or feasibility of any specific change.