You built the stakeholder register in the first week. Name, role, influence, interest, preferred channel, update cadence, maybe a column for concerns. It went into the project folder, everybody agreed it was thorough, and it has been accurate ever since.
That is the problem. A document that never needs updating is usually a document that never tells you anything.
The register is correct. That is not the same as current.
A stakeholder register answers one question well: who cares about this release, and how do they want to hear about it. It does not answer the question that actually generates the phone call: has anything happened that they need to hear about.
Those are different questions, and only one of them has an answer that changes between commitment and delivery.
Every name on it is holding a copy of your date
Walk out of PI planning after the confidence vote and something has happened that the register cannot see. The team looked at throughput, at the roster, at what was in and out of the Fix Version, and said how confident they were. That is expert engineering judgment: the people who will do the work, pricing the work. Nobody in that room was guessing.
Then the date went out. Into the monthly status report, the roadmap slide, the customer email, the sales forecast. Every row in your register now holds a copy of a number that was true at four o’clock on a Thursday.
The register recorded the audience. Nothing recorded that the number was perishable — the same quiet failure as the assumption log that was true on planning day and never re-read since.
Three things move the date. None of them writes a row.
Committed dates rarely break. They erode, from three directions:
- Scope creep. Items get added to the Fix Version after the vote — small ones, individually defensible, cumulatively expensive.
- Dependencies surfaced late. A blocking link appears in week four for work that looked independent in week one.
- Capacity changes. Someone leaves the team, a holiday lands mid-iteration, an on-call rotation quietly eats an engineer.
Each is measurable in days against the committed date. Each happens on an ordinary Tuesday, to a release plan nobody is currently looking at. And each changes what the people in your register should be told — without changing a single cell in the register itself.
The communication-frequency column is the tell. Monthly. Fortnightly. As needed. That is a schedule for talking, not a trigger for it. So the update goes out on the fifteenth whether or not anything moved, and the thing that moved on the ninth waits six days for a slot it has to share with everything else.
What the register’s fields should point at
The fix is not a better stakeholder register template. It is making the columns reference something live instead of something recorded.
| Register field | What it usually holds | What it should reference |
|---|---|---|
| Stakeholder / role | A name | Unchanged. This is the part the register gets right. |
| Interest | “Delivery date” | The committed date and today’s forecast at the same confidence level |
| Influence | High / medium / low | Which of the three drivers this person can actually act on |
| Communication frequency | Monthly | Monthly, plus a threshold: tell them when the forecast drifts below the committed confidence level |
| Notes / concerns | Free text from week one | Days of drift since the vote, attributed by driver |
Advanced Release Planning for Jira does not store a stakeholder register, and it has no contact, audience or notification object. What it supplies is the content those columns are missing: a committed date carrying a confidence band at 50%, 85% and 95%, recalculated from the team’s real throughput at Monte Carlo scale, and the gap in days between where the date stood at the vote and where it sits today — broken out by which of the three drivers moved it. The field-by-field mapping is written up in the stakeholder register reference doc.
The register still tells you who to call. The forecast tells you when the call is worth making, and what you would say when they pick up.
Renegotiate on a reading, not on a deadline
The difference between a release that slips and a release that gets renegotiated is usually about three weeks of notice. Erosion shows up early and small — four days here, six there — long before it shows up as a missed date. By the time the register’s monthly slot comes around with bad news, the cheap options are gone.
A stakeholder register with a live reading behind it turns an awkward apology into an ordinary week-five conversation: here is where the date stands, here is what moved it, here are the three levers. The team’s judgment still owns the assumptions — which throughput window, whose capacity, what is in scope. The arithmetic just stays current underneath it.
Keep the vote live
A confidence vote is a snapshot. Advanced Release Planning keeps it live — tracking scope, dependencies and capacity against the committed date, in days, in real time, so you renegotiate before you slip. See release and PI planning in Jira, or find the app on the Atlassian Marketplace.
1 Comment
Leave your reply.