The argument
I · THE BEFORE
Before, everything is legible.
The business case is approved. The plan is clean, the vendor demo went well, the
integration architecture has been reviewed twice. The risk register names data
migration, interface stability, budget, resourcing.
It rarely names the risk that reliably materialises: that the organisation will carry on
working exactly as it did, using the new system as a more expensive version of the old one.
II · THE DURING
During, everything is loud.
Workshops, sprints, war rooms, a steering committee every three weeks, a newsletter
nobody opens. Attention is abundant, and for a few months the programme is the most
important thing in the building.
This is when change management usually gets bought, and where it usually gets reduced to
communication and training. Those are two levers. They are not the mechanism.
III · THE AFTER
After, everything is quiet. That is when the answer arrives.
The consultants have gone. Hypercare has closed. A depot supervisor with a shift to fill,
or a controller closing a month, decides whether the new process is worth the extra
clicks, or whether the spreadsheet that always worked is still on the shared drive.
Nothing about that decision appears on a milestone chart. It is the only thing that
determines whether any of it was worth doing.
That moment is what my company is named after, and it is the part of a programme I
design backwards from. Everything that comes before it, from the plan and the governance
through to sponsor work, manager enablement and training, exists to change what happens
then. Programmes that are built this way hold.