Programmes are heavily instrumented up to go-live and almost entirely uninstrumented afterwards. Attention, funding and senior interest peak at launch and then move to the next thing — usually before anyone knows whether the launch achieved anything.
This is why organisations accumulate systems that technically work and practically have not changed the outcome they were justified by.
Delivery metrics stop being useful at launch
During build, velocity and burndown tell you something. After release they tell you almost nothing, because the question has changed from “are we building it” to “is it being used, and is it working”.
Those need different measures: how many of the intended users are using it, on what proportion of relevant transactions, where they abandon it, and whether the business outcome has moved. Most teams have no instrumentation for this because it was nobody’s deliverable.
Measure the baseline before you change it
The most frequently skipped step, and the most expensive to skip. Once the new process is live, the old one is gone and nobody can say with confidence how long it used to take or how often it went wrong.
Capturing the baseline costs very little before launch and is impossible afterwards. Without it, every subsequent conversation about benefit is a matter of opinion — which usually means the programme is judged on whether it was delivered on time rather than on whether it worked.
Someone has to own the thing, not the project
Projects have owners by construction. Live systems frequently do not. The sponsor’s accountability ended at go-live, the delivery team dispersed, and operational support handles incidents but not decisions.
The result is a system nobody is improving. Questions about whether it should do something differently have no natural recipient, so they accumulate as complaints. Naming an owner before launch — someone accountable for whether it delivers value, not merely whether it is running — is a small organisational act with an outsized effect.
Leave capacity for the second release
Almost everything learned about a system is learned in its first weeks of real use, and the most valuable changes are usually small and obvious in hindsight: a step in the wrong order, a default that is wrong for most users, a message that causes support calls.
If all capacity has been allocated to the next programme, these fixes wait for a funding cycle. Users conclude that feedback goes nowhere and stop giving it, which is a hard thing to reverse. Holding back a modest slice of capacity for eight to twelve weeks after launch tends to deliver more value per day than anything else the team could be doing.
Keep the feedback loop visible
People give feedback when they see it produce change. A short, regular note saying what was raised and what happened — including what will not be changed, and why — sustains that loop far better than a survey nobody sees the results of.
Close things honestly
Some initiatives do not deliver what was expected. The useful response is a clear-eyed account of what was learned, not a quiet reallocation. Organisations that can say plainly that something did not work make better decisions afterwards, because their record of what happened is accurate.
Sustained delivery is not mainly a methodology question. It is a question of whether anybody is still paying attention eight weeks after the launch email.