What-if without the whiteboard: simulating scope cuts, delays, and team changes
Every consequential planning conversation eventually produces the same five questions. What if we cut this feature? What if the supplier slips a month? What if we hire, or lose, one person? What if we take the second project on anyway? What if we delay the launch to fit the conference?
In most teams the honest answer to each is "let me get back to you", followed by an afternoon of spreadsheet surgery: duplicate the plan, hand-shift the bars, eyeball the result, and quietly lose confidence in the copy the moment the original changes. Scenario planning is treated as a deliverable. It should be a query.
Why scenarios are hard for documents and easy for programs#
The spreadsheet version is painful for a structural reason: a hand-maintained plan stores conclusions (start dates, end dates) rather than the logic that produced them. Change an input and the conclusions do not know they are stale. You have to re-derive every downstream cell yourself, which is why each scenario costs an afternoon and why nobody maintains more than two.
An executable plan inverts this. A Topolog plan is a program in TOL: tasks with uncertain durations, dependencies, gates, end states (the case for that). The schedule and the odds are computed from it by the Monte Carlo engine, on every change, in seconds. Which means a scenario is nothing more than an edit, and the cost of asking "what if" collapses to the cost of typing the change.
Some edits and what they answer:
| The question | The edit | What the engine returns |
|---|---|---|
| Cut the feature? | Delete the milestone (or gate it off) | New completion spectrum and end-state odds without it |
| Supplier slips? | Raise that task's estimate, or push its earliest start | The ripple: every downstream quantile, recomputed |
| Lose a person? | Reassign their tasks to the remaining agents | The new serialisation: where work queues behind one pair of hands |
| Take on the second project? | Add it to the portfolio | Cross-plan capacity contention and which commitments move (capacity mechanics) |
| Immovable date? | A deadline on the sentinel | The probability of making it, stated as a number |
The comparison that matters is never bar-versus-bar; it is distribution-versus-distribution. "Cutting the feature moves P80 from 19 May to 30 April and takes the rework branch from 22% to 9%" is a decision-grade sentence. No pair of Gantt charts contains it.
Decision-shaped what-ifs#
There is a class of scenario that deserves better than an edit: the ones you will genuinely choose between, like spending tiers or scope levels. For those, TOL has first-class decisions, and the engine sweeps them for you:
decisions { scope: enum[mvp, full] }
outcome retention_strong: boolean {
default_prior: 0.5
conditional_overrides: [
{ when: scope = full; apply: { default_prior: 0.7 } }
]
}Declare it, and the Pareto sweep evaluates every option against every objective you care about (duration, cost, drawdown, probability of success) and hands back the frontier of non-dominated choices. That machinery has its own article; the relevant point here is the division of labour. Ad hoc questions stay cheap edits. Real decisions become declared structure, and the engine enumerates the whole option space instead of the two scenarios somebody had time to build by Thursday.
Two properties make the comparisons trustworthy in a way spreadsheet copies never are. Scenarios cannot drift, because there is no copy: an edit is reversible (undo, or revert the source text, which is versioned like any code). And comparisons are apples to apples, because evaluations share common random numbers: scenario A and scenario B see the same simulated luck, so any difference between them is the difference you made, not sampling noise.
The discipline this enables#
Teams with cheap what-ifs develop a habit that is almost impossible otherwise: they interrogate the plan before reality does. Before committing to a client date, check what one slipped dependency does to it. Before accepting new work, check what it does to the work already promised. Before a launch, find the task whose delay hurts most and pre-emptively de-risk it.
None of this is sophisticated. It is the planning equivalent of running the tests before merging, and it is exactly as unreasonable to skip once the run costs seconds. The whiteboard was never the bottleneck. The re-deriving was.