A Date Is Not a Forecast

The team gave a date. The data said 70% confidence at that date. The project manager held them to it as though confidence were 100%.

This is not a story about a bad project manager. It is a story about what a date communicates. A date, stated without qualification, is received as a commitment — a binary outcome that either happens on schedule or doesn't. The data behind it, the probability, the range, the conditions — none of that is visible in a date.

When the date becomes the only thing that matters, the forecast that generated it is irrelevant. The team is held to certainty they never asserted.

Three things that look like forecasts but aren't

Most delivery conversations use the words target, plan, date, and forecast interchangeably. They are not the same thing.

A target is what someone wants. "We need this by Q3" is a target. It is a business requirement, not a prediction about the delivery system. A target says nothing about whether the system will produce the outcome by the required date. It is a statement of need.

A plan is an intention. "We will complete this in six sprints" is a plan. It describes how the work will be organized. It is derived from estimates, which are predictions about effort, not about system behaviour. Plans have been wrong since planning was invented.

A deadline is a constraint set by someone else. "The contract requires delivery by June 1" is a deadline. It exists independent of what the delivery system can actually produce. Deadlines have legitimate uses. They are not forecasts.

A forecast is different from all three. It is a probability statement derived from evidence about how the system actually behaves: given items drawn from this system, X% will complete within Y days. It can be right about the distribution and wrong about any specific outcome. That is not a failure of the forecast. It is what probability means.

Translating P85 into a sentence

Probabilistic forecasts are useful to the degree that they can be communicated. "There is an 85% probability that this work will complete by June 15" is an accurate statement. It is also one that most stakeholders will hear as "it will be done by June 15."

The translation requires a contract about what the numbers mean.

For the person receiving the forecast: the 85% date is not the expected date. It is the date by which 85 out of 100 similar items would complete. Some items will finish before it. Some will finish after it. The forecast is not wrong if it finishes on June 18.

For the person giving it: citing a P85 is an act of honesty that requires courage. Giving a single date is easier and carries less visible uncertainty. The P85 is more informative and more easily criticised.

The practical framing: "Based on how our system has been running, there is roughly an 85% chance this will be done by June 15. If you need higher certainty — say, 95% — that date moves to June 28." This gives the stakeholder a genuine choice between timeline and certainty, which is the real decision they need to make.

When to update vs. when to honor

A probabilistic forecast is not a commitment. It is a picture of the distribution as understood at a given point in time. As more work completes and the remaining scope becomes clearer, the forecast should be updated.

A commitment is different. When a date has been agreed upon — with explicit understanding of the confidence level and the conditions — it carries a different obligation. Updating the forecast because circumstances changed is appropriate. Renegotiating the commitment requires a different conversation, and a genuine reason.

The distinction matters because teams sometimes use "the forecast changed" as cover for not delivering on a commitment they could still meet. It also matters because teams are sometimes held to commitments that should have been renegotiated when the conditions changed genuinely.

The test: did the system change, or did the work turn out to be harder than expected? System changes (a key person left, a dependency moved) legitimately affect commitments. Work being harder than estimated is usually what the confidence interval already accounted for.

The question "what's the date?" is reasonable. It deserves a real answer. The real answer includes a confidence level. Without it, the asker is receiving certainty that does not exist, and both sides of the conversation will eventually pay for that gap.

The question "what's the date?" deserves the answer "for which confidence level?"