Plan scenarios that reveal what changes and why

Start with one decision after a change

A team is preparing a fictional seasonal campaign. Approval is expected to take four working days; production begins after approval and takes five; quality assurance begins after production and takes two. Every duration, deadline and numbered day in this example uses the same illustrative working-day calendar, starting at day 0 kickoff; weekends and holidays are not modelled. The preferred plan finishes on day 11, before a day 12 launch deadline. If approval takes seven days instead, where does the extra time flow, and does the plan still meet the deadline? That is the question a scenario planner should answer.

The job is to expose the chain from changed assumption to changed decision. A calculator specifies arithmetic and produces an estimate. A fixed-option comparison describes options against common criteria. A configurator keeps selections compatible. A recommendation tool matches stated needs to choices. This planner keeps a baseline and tests whether a proposed plan survives changed conditions. It should not call an explored scenario a forecast, a probability, or a commitment.

Give the baseline an identity and an owner

Record the decision, preferred plan, start point, unit, relevant stages and deadlines before offering a slider. Each assumption needs a named source, source version or checked date, owner and review trigger. State whether it is a verified fact, a user-entered planning value, or an illustrative assumption. Save the baseline version separately from each scenario so changing an input cannot silently rewrite what the team originally approved.

The UK Treasury Green Book describes business as usual as the benchmark against which proposals are compared and says assumptions should be stated transparently. Its 2026 guidance calls for sensitivity analysis of uncertain or changeable assumptions and switching values for the preferred option. This page borrows those disciplines for a small planning interface; it does not claim that a fictional marketing schedule is a UK public appraisal or that Green Book requirements automatically apply to private projects.

• Baseline ID and decision: what plan was preferred and for which goal?
• Input register: value, unit, source, checked date or source version, owner, and review trigger.
• Dependency: which stage or outcome reads each input, and in which order?
• Constraint: the exact condition for passing, including equality and any hard stop.
• Output: changed downstream values, binding constraint, decision state, and next verification action.

Propagate only changes that have a declared link

Draw the dependency chain in plain language before implementing it: approval completion sets production start; production completion sets quality-assurance start; quality-assurance completion sets readiness. A change to approval duration shifts all three downstream dates. A deadline is a constraint on readiness, not an instruction to squeeze work into the remaining time. If work can overlap, document the exact handoff and evidence for that overlap instead of inventing it to rescue a result.

The GAO Schedule Assessment Guide explains why schedule logic, handoffs and changes to dependencies need to remain visible for an updated schedule to be credible. The GAO Cost Estimating and Assessment Guide says a one-factor sensitivity test holds other factors constant, documents the results, and uses documented ranges rather than arbitrary percentage swings. Apply the same discipline here: first change only approval duration. A later production acceleration is a separately labelled proposed intervention, with its own source and conditions.

Hypothetical example: the preferred launch plan stops holding

In the downloadable worksheet, baseline H-B0 uses approval 4 working days, production 5 working days and quality assurance 2 working days, all sequential from day 0 kickoff on that same illustrative calendar. Readiness is day 11; the day 12 deadline leaves one working day of margin. These numbers and the campaign are invented solely to show the method. They describe no Kinetivy client, supplier promise, observed outcome or probability of delivery.

Scenario H-S1 changes only approval to 7 days. Production now starts on day 7 and ends on day 12; quality assurance ends on day 14. The deadline is breached by two days, so the preferred plan cannot be presented as meeting it under that assumption. Scenario H-S2 proposes shortening production from 5 to 3 days as an additional intervention. Readiness would be day 12, exactly on the deadline, but supplier evidence for three days is marked unknown. The result is conditional, not a recovered plan. An owner must verify the production duration and any effect on quality before using it.

The boundary test H-S3 asks how far approval can extend while the original downstream durations remain fixed: 5 days reaches readiness on day 12 and meets the illustrative “on or before day 12” rule; any approval duration above 5 days fails that rule. This is a switching point for this invented schedule, not a safety margin or an assurance of launch. H-S4 resets approval to 4 days and removes the proposed acceleration; readiness returns to day 11. Reset should restore every baseline input and its source state, not merely the displayed total.

Show breach, unknown and invalid as different states

A confirmed breach means the documented inputs and rules produce a value outside a hard constraint. Unknown means a material input lacks current evidence, so the plan cannot be confirmed. Invalid means the entered case contradicts the model, such as quality assurance starting before production is complete when the declared dependency requires a finished production handoff. Do not turn any of these into a green “feasible” badge through an unstated default.

Source expiry matters as much as an empty field. If the supplier duration was checked for a previous production method, label it stale when the method changes. Keep the changed value, the old source version, the reason for expiry and the person who can recheck it. A scenario that reaches the boundary on stale evidence remains unresolved. Give users a correction route and preserve the baseline while the source is reviewed.

Make each change inspectable and reversible

Show the current baseline beside the active scenario. Label the changed input, the downstream fields it affects, the constraint and the decision state in text. A compact dependency view can help, but a readable ordered list or table should carry the same information. Do not rely on color or animation to communicate a breach. Offer “reset to baseline” and a way to undo the last change; make their scope explicit. Keep hypothetical examples separate from real user values.

Use visible labels and units, keyboard-operable controls and specific validation messages. W3C’s form-validation tutorial calls for understandable feedback and a way to review or correct input. When an in-place recalculation changes the decision state, a concise status message such as “Deadline breached by two days; review the changed approval duration” can notify assistive technology without moving focus. Keep the full dependency explanation in normal page content. Test narrow screens, zoom, focus order and reduced motion against WCAG 2.2 AA.

Test decisions, sources and reset together

Have someone outside the implementation reproduce every worksheet row from the written dependencies. Test baseline, one changed assumption, linked intervention, exact boundary, just-over-boundary, breached constraint, missing or stale evidence, impossible ordering and reset. Check that the interface lists all affected stages and does not quietly mutate an unrelated input. Version the dependency rules and source snapshot so a later correction can explain why an earlier scenario differed.

A local planner may calculate without saving visitor inputs. If storage is necessary for a separate task, define purpose, access and retention first. Keep exact scenario values, free text, personal details and full result traces out of analytics. Measure only approved aggregate journey events under the site’s consent rules; the privacy-aware measurement guide covers that design. The complete result and worksheet should remain available without an email gate.

• Can a reviewer reproduce every affected downstream value from the baseline and one change?
• Does equality at the deadline pass only because the documented rule says “on or before”?
• Does missing or expired supplier evidence prevent a confirmed recovery claim?
• Are changed dependencies or sequencing rules themselves versioned and reviewed?
• Do keyboard, screen-reader and mobile journeys expose the same constraint and uncertainty?
• Does reset restore values, dependency rules and source status from the baseline snapshot?