Problem: one date hid uncertainty

Leaders assembled status from meetings, messages, Jira, and separate tables. An initiative date looked certain until a dependency or long wait made a delay obvious. By then, reducing scope, changing order, or removing a constraint was expensive.

Team metrics did not answer three management questions: total elapsed time from idea to outcome, which unfinished work was already at risk, and how much the portfolio could finish by a date at a chosen probability.

Method: one unit of flow, several signals

RFC and Epic became units recognised by both business and technology. We separated System Lead Time, narrower Lead/Cycle Time, Throughput, current Aging, and P50/P85 duration percentiles.

The measures were not individual KPIs. Each signal was connected to an action: remove a dependency, reduce scope, reorder work, limit WIP, or stop an initiative.

Monte Carlo as a management experiment

The model repeatedly simulated the future using comparable historical work. A date forecast estimated the probability of completing scope by a date; a scope forecast estimated likely completions by a date.

Work class, historical Throughput, System Lead Time boundaries, WIP, and assumptions were explicit. P50 represented a working scenario and P85 a more conservative risk boundary—not a new deterministic promise.

From dashboard to management artefacts

The system used a weekly delivery-risk digest, portfolio scenarios, a flow-health report, an incoming-RFC quality digest, and a monthly leadership review connecting company goal → team goal → RFC/Epic → expected outcome → delivery signal.

The digest surfaced only work where Aging, a blocker, a dependency, or a changed forecast required a decision. An LLM could prepare the RFC quality check, while the owner remained accountable.

Business impact

The shared view reduced leadership status-collection effort to 1–2 hours. RFC System Lead Time at P85 fell from 295 to 106 days, and Epic throughput rose from 16 to 54 per month.

No single dashboard or Monte Carlo model caused those results. The system combined a shared unit of flow, data quality, visible dependencies, and an explicit decision rule for every signal.

Limits

Monte Carlo does not repair poor data or make an unstable system predictable. Unlike work classes must remain separate, P85 must not be carried between unrelated products, and forecasts must not become individual performance ratings.

Diagnostic questions

  • Does the business recognise the unit whose duration is measured?
  • Are Aging and dependencies visible before a commitment fails?
  • Are work classes separated?
  • Which decision changes when the forecast changes?
  • Is delivery speed connected to expected initiative value?

A delivery diagnostic identifies the minimum data and management rules worth establishing first.