Every release has a document that predates the team. It might be called a project charter, a project brief or a one-page mandate, but it does the same job: it names the sponsor, the objective, the budget envelope and a date. It gets signed. It goes in a folder. And for the next nine months, every conversation about whether delivery is on track is really a conversation about that date.
Here is the uncomfortable part, and it is nobody’s fault: the date on the project charter is the least-informed number anyone will produce for this release.
A project charter is written at the point of least information
That is not a criticism of whoever wrote it. At charter time the backlog has not been decomposed into work items. There is no throughput history for this team on this work. Nobody has drawn the dependency map, because most of the things it would contain have not been discovered yet. The date comes from somewhere legitimate — a market window, a budget cycle, a customer commitment, a regulatory deadline — but it does not come from evidence about how fast this team finishes this kind of work, because that evidence does not exist yet.
Decomposition comes later. When it does, a work breakdown structure finally shows what the release actually contains — the work the charter’s date was set without. Even then the WBS names the work rather than pricing it, so the gap between the charter’s number and a defensible one only closes once that decomposition is forecast in days.
Organisations need the date anyway. You cannot authorise funding against “we’ll tell you in a quarter.” The charter’s job is to be a fixed point, and it does that job well.
The problem is not the date. The problem is what happens to it afterwards.
The charter is a baseline. Everything else gets re-derived.
Every other planning artefact is refreshed as you learn. The backlog gets re-ordered. The release plan document gets revised each iteration. The roster changes when someone joins or leaves. The sprint plan is rebuilt every two weeks.
A statement of work sits at the far end of that spectrum: it is countersigned, so it cannot be revised unilaterally at all. A signed delivery date moves only by change order, which makes drift against it the most expensive kind to discover late.
The charter is not refreshed, and it should not be — a baseline you edit continuously is not a baseline. It is the reference that variance is measured against, and its stability is the entire point. But that stability has a side effect: the date written at the point of least information is the date that keeps getting read, long after far better information exists.
The confidence vote produces two numbers. Only one of them travels.
Somewhere after the charter, the team that will actually do the work sits down and commits. In SAFe that is the PI planning confidence vote; elsewhere it is a commitment review or a planning workshop under another name. Whatever it is called, it is expert engineering judgment — the people closest to the work pricing real scope against the capacity and throughput they actually have.
That vote produces two things: a date, and a confidence in that date. “We think mid-March, and we’re about 80% on it” is a complete answer, and a more useful one than a bare date.
Then exactly one of those two numbers leaves the room. The date is carried into the project status report, the steering pack and the charter’s target-date line. The confidence stays behind. The organisation goes back to reading a single unqualified date — the same shape of number the charter held at the point of least information, now wearing the team’s authority.
Three things move the date after the vote
Post-commitment erosion has three drivers, and none of them are visible on a project charter:
- Scope creep. Work added after the boundary was drawn — new tickets, and quiet growth inside existing ones.
- Dependencies surfaced too late. The ones that were never on the map at charter time, because nobody knew about them yet.
- Capacity changes. A departure, a reassignment, a reorganisation, an incident that eats a sprint.
Each of these moves the real finish date by some number of days. The charter’s date does not move at all. The gap between them opens quietly, and in most organisations the first time anyone measures it is when somebody misses.
Keep a live reading next to the fixed one
The fix is not to rewrite the charter every fortnight. It is to stop letting its date be the only number in the room.
Release Management, Roadmaps, Portfolio PPM & Timeline keeps the arithmetic current. It runs a Monte Carlo forecast over the Fix Version’s real scope, the team’s real throughput window and the real roster, and reports a date at a stated confidence level — 50%, 85% or 95%. The team still owns every assumption that goes in: which slice of history is representative, whose capacity counts, what is in scope. The app does the arithmetic, at scale, and keeps it current as the Jira data underneath it changes.
Beside the charter’s date, that gives you three readings instead of one:
- the date today’s evidence supports at the confidence level you committed at;
- the gap between that date and the charter’s date, in days;
- which of the three drivers the gap came from.
The charter stays untouched. It is still the baseline. What changes is that the number beside it is current, and the drift has a cause and a size rather than arriving as a surprise in month eight.
Renegotiate while it is still cheap
The practical payoff is timing. A gap of four days, attributed to scope added last sprint, is a conversation. A gap of six weeks, discovered at a go/no-go review, is an escalation. Same erosion, different moment — and the cost of the conversation climbs the whole way.
So treat the charter’s date as what it is — a fixed reference set before the evidence existed — and carry a live confidence band beside it. When the band says the committed date is no longer supported, renegotiate scope, capacity or the date deliberately, before the slip becomes a fact. That is the method behind building a release plan that survives contact with reality, and the wider practice is covered in our complete guide to release planning.
Key takeaways
- A project charter fixes the release date at initiation, before any throughput evidence for the delivering team exists. That is a property of initiation documents, not a mistake.
- The charter is a baseline by design and should not be continuously edited — but its date keeps being read long after better information exists.
- The later confidence vote is expert engineering judgment and produces both a date and a confidence. Usually only the date travels onward.
- Scope creep, late dependencies and capacity changes move the real date. Keep a live confidence band beside the charter’s date so the gap is measured in days, attributed to a driver, and renegotiated early.
Frequently asked questions
Should we update the project charter when the forecast changes?
No. A baseline that is edited whenever reality moves stops functioning as a baseline, and the variance you most need to see disappears with it. Leave the charter alone and report the current forecast beside it, with the gap in days. Re-commit deliberately and rarely — and when you do, re-commit to a date at a stated confidence level, not to another bare date.
What if the charter’s date was never achievable in the first place?
Then the confidence band will say so on day one, which is the cheapest possible moment to find out. A forecast that lands well past the charter date at P85 is not a failure of the team; it is the first piece of real evidence anyone has had about that date. Take it to the sponsor as a scope, capacity or date decision while all three levers are still open.
See it against your own releases. Release Management, Roadmaps, Portfolio PPM & Timeline for Jira forecasts a committed date with a live 50/85/95% confidence band and attributes every day of drift to scope, dependencies or capacity. The mechanics are documented in The Project Charter and the Committed Release Date, and the app is available on the Atlassian Marketplace.
2 Comments
Leave your reply.