delivery-retro

Delivery Retro

Every rate the founder charges is downstream of an estimate they made once and never checked. This is where the checking happens. It is also the only skill in this company that reliably changes the price, which is why it gets skipped.

When to use

Within five days of shipping. After five days the founder remembers a story about the project, and the story is always kinder than the timesheet. Also at any milestone that ran more than a week over.

Inputs

Read first, in order — house rule 1:

• clients/<client>.md — the estimate, the scope log, the absorbed asks
• pipeline.md — the proposal: what was quoted, in hours and in money
• metrics.md — the target effective rate to measure against

Beliefs

• The overrun is never in the phase the founder remembers. Memory keeps the phase that was stressful; the timesheet keeps the phase that was long, and they are reliably different phases. When the file and the recollection disagree, the file is the project.
• A project delivered on time by working the weekend is an overrun. It settled the bill in a currency nobody logged. "We shipped it" is not a variance, and a retro that accepts it as one is how a phase stays mispriced for three consecutive projects.
• An estimate is a claim about the founder, not about the work. Two people quoting this project honestly produce different correct numbers. So "the estimate was too low" is usually false and "I was not yet the person that estimate described" is usually true — and only one of those has a fix that isn't a price rise.
• Revision rounds diagnose the brief, not the client's taste. Three rounds means the client was not shown the thing early enough to be cheaply wrong about it. The fix is upstream in what was agreed, never downstream in more polish.

Steps

1. Recover the actual hours, including the ones nobody billed. The estimate covered delivery. The actual includes sales calls before the deal, scoping, revisions, the "quick calls", the Slack answered on a Sunday, and the invoice chase. Leave those out and the retro proves the estimate was fine — which is exactly how the rate stays broken for another year.
2. Compute variance per phase, not per project. "20% over" is unactionable. "Discovery on target, build 15% over, revisions 210% over" names the thing to fix and prices it.
3. Answer the one question that matters: scope, estimating, or unfamiliarity? These have three different owners, and confusing them is precisely why the same overrun repeats. Pick one — the dominant cause of the worst phase, not a blend. A retro that says "a bit of both" routes to nobody.
   • Scope → the work grew and nobody charged for it. That is a scope-guard failure and it belongs to the Delivery Lead. Fix the boundary, not the estimate.
   • Estimating → the work was correctly bounded, the founder had done this kind of work before, and it still took longer than quoted. Then offer.md is mispriced, and that is the Positioning Advisor's file.
   • Unfamiliarity → the work was correctly bounded and the estimate was fair for someone who had done it before. The founder had not. That is a capability gap, it belongs to the Skills Mentor, and skill-gap reads this exact field to find it.