Topic
After the commitment: tracking, closing and learning
The short answer
Once work is committed, three things keep the promise honest. Report status as a judgement with a reason rather than a colour, so that green means someone decided it was green. Close the commitment with an explicit outcome that names what shipped and, when the result was not clean, what differed from what was promised - not a binary done. And require a written lesson before a demand is complete, because a thumbs-up records that a retrospective happened rather than what was learned. Each of the three exists to stop the previous one from quietly becoming a formality.
Almost everything written about delivery governance stops at the moment the commitment is made. That is where the interesting decision is — but it is not where the promise is kept or broken, and a process that goes quiet after the yes is a process that cannot tell you whether its yeses were any good.
Status has to carry its reasoning
A colour on a board decays fast, because reporting amber costs a conversation and reporting green costs nothing. Everything drifts green and then goes red without passing through amber, which is the tell. What survives is the sentence underneath: what changed, what is now different from the plan, and what decision or help is needed. Ask for those and the colour becomes honest as a side effect, because it is hard to write "green" directly above "the security review is unscheduled and needed by the 14th".
Closing is a comparison, not a checkbox
"Done" throws away the only data worth keeping: how the outcome differed from the promise. Without that delta you cannot answer whether your estimates run light, whether early commitments miss more often, or whether one team's "high confidence" means what another's does. Three closes rather than one — delivered as committed, delivered with exclusions, not delivered — and the difference recorded whenever the result was not clean.
One written lesson beats a full report
Retrospectives fail by producing alignment rather than memory. The narrow fix is a single sentence answering what you now know that you did not know when you committed, attached to the demand it came from rather than filed under the ceremony. Required, so it happens; cheap, so it happens honestly. A verdict alone records that a retrospective occurred, not what was learned.
Each of the three exists to stop the previous one becoming a formality: reasoning keeps status meaningful, an honest close keeps the reasoning checkable, and a required lesson keeps the close worth having a year later.
The full argument
Keeping a promise visible while it is being kept, closing it honestly, and learning something the next demand can use.
- What "complete" should mean
Most systems call work complete when it stops. A more useful definition: complete when the outcome is recorded and something was learned.
- Green is a judgement, not a colour
Status reporting decays into a colour nobody believes. What makes it useful again is requiring the reason, not the rating.
- "Delivered" is not an outcome
Closing a commitment with a checkbox loses the only information worth keeping: what shipped, and how it differed from what was promised.
- A retrospective that isn't theatre
Most retrospectives produce agreement and no memory. The fix is narrow: require one written lesson, attached to the work it came from.
I'm Tan Gravam. I build DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.