Method · From the series on measurement and adequacy
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.
The objection
Does GWK carry out these five steps?
Steps 2, 4, and 5 are measurement, which is what GWK does, including the later re-collection when contracted for it. Steps 1 and 3 are decision and execution inside the client's environment, carried out by whoever has access to it and responsibility for it. The bridge between the two halves exists as a GWK engineering project, not as a contractable capability, and this site does not present it as available.
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.
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.
From the series on measurement and adequacy
Why measuring does not reduce exposure
A diagnosis does not alter the environment it describes. What measurement solves, what it never touches, and why the separation between the two matters to whoever is buying.
How to verify risk reduction without changing rulers
Five conditions make two measurements comparable. Break any one and the delta measures method instead of risk, and the error never shows up in the final figure.
Discuss an assessment
If this text described a problem you have, the conversation starts from the scope you need to measure, with the limits written down before any proposal.