Six months ago, two organisations signed the same sentence. It sits in section 4 of the statement of work, between the deliverables list and the payment schedule: delivery by the fourteenth. Your signature is on it. So is theirs. Since then the backlog has been refined nine times, two engineers rotated onto an incident, and a partner API landed a fortnight late — and section 4 still reads the fourteenth, because nothing inside a signed document updates itself.
That date was not invented by the contract. It came out of the team’s commitment confidence vote: engineers and a delivery lead weighing a scope they had read, a dependency set they had mapped and a roster they knew, then saying what they could hold. That was sound engineering judgment, and it still is. The problem is what the document had room for. The vote produced a date and a confidence. A statement of work has a field for the first and no field at all for the second.
A signed date is the most expensive one you hold
Every other planning artifact gets re-derived. A release plan is replanned. A schedule baseline is re-baselined. A status report re-asserts itself every Thursday. The statement of work is different because it is countersigned: it moves only by change order, a commercial conversation involving the other party’s procurement, their budget and sometimes their legal team. The same erosion that costs an internal plan a planning meeting costs a statement of work a renegotiation.
Which leaves an odd asymmetry worth saying out loud. This is at once the date with the highest cost of being wrong and the one nobody re-forecasts. The release plan you build in Jira gets looked at every week. Section 4 gets read twice — once at signature, and once when it is missed.
Three things move it after signature
Post-commitment erosion is not mysterious, and it is not a failure of the vote. It is three specific things arriving after everyone stopped looking:
- Scope added after signature. Rarely as a new deliverable — it arrives as interpretation. That was always implied by the integration requirement. No line in the deliverables list changes, and the Fix Version quietly grows.
- Dependencies surfaced late. Frequently the counterparty’s own: their test environment, their data migration, their sign-off. At signature none of it looked like work, so nobody wrote it into the schedule.
- Capacity changes. A roster move, parental leave, an incident load — none of which appears anywhere in the deliverables list. The other party never sees your roster. They see the fourteenth.
Each one is measurable the day it happens. What makes them dangerous is not that they are hidden — it is that nothing converts them into the only unit the contract cares about: days against the fourteenth.
Put a live number beside the signed one
This is the gap release planning in Jira is meant to close. Release Management, Roadmaps, Portfolio PPM & Timeline reads the team’s actual throughput, real capacity (time off, working days) and live dependency state from Jira, runs Monte Carlo simulation across them, and reports the release as a date at 50%, 85% and 95% confidence — re-forecast continuously, not at the next planning boundary.
The signed date does not move. It is a contractual fact and it should stay exactly where it is. What changes is that it stops standing on its own: beside it sits today’s forecast at the same confidence level, the gap between the two in days, and which of the three drivers produced that gap. Scope added since commitment, dependency movement and capacity change are tracked separately, so the answer to why arrives with the answer to how far.
The division of labour matters here. The team still owns the assumptions — which throughput window is representative, whose capacity counts, what is genuinely in scope. Those are judgment calls, and no forecast should make them for you. What the app does is the arithmetic, at a scale and a frequency nobody is going to reproduce by hand, and it keeps doing it every day after the vote rather than once on the day of it.
Renegotiate at eleven days, not at the delivery review
A change order raised in week three, carrying eleven days of drift attributed to scope added after signature, is a professional conversation with evidence attached. The same change order raised in the delivery review is an apology. Internally, a change control board is supposed to play this part; across a contract boundary the change order is its commercial twin, and it needs the same input — the schedule cost of the change, in days, before anyone agrees to it.
None of this calls for a different statement of work template, or a new column in the one you have. The document can stay as it is; what it needs is a live reading next to it. The same is true of the project charter that preceded it — both write a date at a moment of limited evidence, and both are then read for months as though the evidence never changed. Keeping a confidence band current is what turns a signed date from a promise you defend into a commitment you can actually manage.
See how release planning and forecasting in Jira keeps a committed date current, or read the feature documentation on what the forecast supplies to a statement of work.
1 Comment
Leave your reply.