What-If Scenario Analysis

Goal

What-if scenario analysis applies a named condition to the schedule and then recalculates it to measure the effect on the project's objectives. The question is always the same: what happens if scenario X occurs? A scenario is a condition that can be described: a major component delivered late, an engineering duration lengthened, a strike or a change in the permit procedure.

It supports two decisions. The first is the sizing of the schedule reserve, the contingency buffer the project manager holds for the unexpected: the analysis replaces a flat percentage with a number of weeks tied to identified conditions. The second is the response plan per scenario, an action decided in advance. Its deliverable is a register of the scenarios run, carrying for each one the change to the network, the float available, the recalculated finish date and the decision taken.

The PMBOK Guide files it among the data analysis tools of schedule development (§2.3.2.2) and schedule control (§2.3.2.3). It is therefore used at two moments: before the commitment, to judge whether the promised date holds under conditions less favourable than those of the plan; during execution, to compare recovery options.

Usage

When to use it

• An identified external threat: quantify what a permit delay, a strike or the failure of a sole supplier would do to the finish date, starting from the entries already rated in the risk register.
• A schedule reserve to defend: bring the steering committee a number of weeks that comes out of the network rather than a negotiated flat allowance.
• An imposed finish date: test the commitment under degraded conditions before signing up to it.
• A variance observed during execution: compare the recovery options on the network before committing to one.

When not to use it

• No schedule network: a bar chart with no dependency links recalculates nothing; the network has to be built first.
• A question of ranking between variables: which one has the largest effect on the outcome is answered by sensitivity analysis.
• The probability of meeting the required date: a scenario gives one case; Monte Carlo simulation gives a distribution of finish dates.

Description

Naming the scenario

A scenario is written in words before it becomes a number. It names a trigger, a scope and a duration: "an objection is filed during the public inspection and the building permit taking legal effect slips by eight weeks", "the lift manufacturer's plant stops for two weeks and delivery slips by three weeks". Put that way, it translates into a change to the model with no ambiguity. Put vaguely, "the supplier is running late", it does not translate.

Scenarios come from the risk register, from external threats seen on comparable projects, from contractual constraints and from the regulatory framework. In practice, three to six are kept on a mid-sized project, chosen for their plausibility and the size of what they threaten. Going through every activity in the network belongs to sensitivity analysis.

Translating the scenario into a change to the network

The schedule network is the model that links the activities by their dependencies and whose calculation produces the dates. Translating the scenario touches a small number of elements in it: one or more activity durations lengthened, a dependency link added or removed, a milestone date moved, a resource taken out of a time window.

Nothing else changes. The baseline is the only point of comparison available, and a scenario that takes the opportunity to correct a duration known to be wrong produces a variance nobody can split between the scenario and the correction. Corrections to the model are made outside the analysis, on the baseline, and the analysis starts again from there.

Recalculating the network

The modified network goes through the same calculation as the original schedule: the forward pass, which carries the early dates forward from the start of the project, and the backward pass, which carries the late dates back from the finish. The gap between the two gives each activity's total float, the delay it can take without pushing out the project finish date, distinct from free float, the delay it can take without moving the early start of the next activity. The critical path is the run of activities whose total float is zero.

The calculation returns two results and the second is easily lost. The first is the new finish date. The second is the new critical path, which can switch to another branch of the network even though the finish date has not moved. That switch changes the list of activities to watch for the rest of the project, and a reading limited to the finish date wrongly concludes that there is nothing to do.

Two model settings distort the result when they are forgotten. A hard date constraint, of the "do not start before a given date" kind, absorbs part of the shift or amplifies it depending on where it sits. Active resource levelling redistributes the activities at every recalculation, so the variance observed mixes the effect of the scenario with the effect of the levelling. Both points are checked on the baseline before the first scenario is run.

Comparing against the baseline

The outcome turns on the float of the affected activity and on its position in the network. Three weeks of delay on an activity that has four weeks of total float do not move the end of the project; eight weeks on an activity with zero float move it by eight weeks.

Float is a shared resource that the first scenario consumes. Two scenarios absorbed separately are not necessarily absorbed together. Their combination is therefore a separate case, to be run as a scenario in its own right when the conditions are correlated: the same strike at a transport company often delays several deliveries. Adding the individual results does not give that combination, because there is only one float to count.

Deciding: reserve and response plan

The schedule reserve is sized on the scenarios judged plausible. Adding them all together would give a schedule nobody funds. The choice of which scenarios are covered is an explicit trade-off, justified to the sponsor, and the reserve stays under the project manager's control with a release rule everyone knows. A reserve whose origin is not documented is the first one cut when the schedule tightens.

The response plan concerns the scenarios that would push the finish date out. It names the action, when it has to be triggered and the person who decides: resequence two work packages, overlap two previously sequential activities, place an order before the expected validation, escalate to the authority concerned. A scenario absorbed by the float calls for neither reserve nor plan, but the float it would consume is recorded.

The network described at launch no longer exists three months later: activities have finished, durations have changed, float has moved and a scenario that came through harmlessly no longer does. The analysis is therefore run again at every schedule review and after any change to the critical path. Once the first set of scenarios is written, that re-run costs little.

Named scenario, sensitivity, simulation

Three techniques deal with uncertainty in a schedule and answer three distinct questions. What-if scenario analysis runs one named condition in full against the network to see what holds and what breaks; it is deterministic and produces no probability. Sensitivity analysis ranks: it measures which source of uncertainty, taken on its own, is the most correlated with the project outcome. Its result is read on a tornado diagram. Monte Carlo simulation samples: it draws a large number of duration combinations from probability distributions and produces a distribution of finish dates, from which a confidence level on a target date is read.

The PMBOK Guide keeps the three apart in its own structure. What-if scenario analysis is a tool of the scheduling processes themselves, which the planner runs on their own network. Sensitivity analysis and simulation belong to the risk analysis process (§2.7.2.3) and feed its quantitative model. The schedule receives their results from outside. The three combine: sensitivity says where to look, the scenario describes a condition worth running, the simulation says what date can be committed to.

The same reasoning is used outside scheduling. In business process analysis, a named condition is applied to a process's parameters (throughput, cost, variability) to observe its response, with no activity network and no finish date (BPM CBOK §4.6.3).

AI considerations

Assistance covers two things: volume and translation. A model proposes a first list of candidate scenarios from the risk register and the history of comparable projects. It turns a scenario written in ordinary language into a change to the network, naming the affected activity and the size of the shift. It runs the series of recalculations and lays out the comparison table. It also spots the coverage gaps: the low-float activities that no chosen scenario touches.

Judgement stays human on what the analysis commits the project to. The plausibility of a scenario depends on the environment of this project, this supplier, this authority, this season. A model trained on general data produces plausible-sounding conditions that do not exist in this project. Sizing the reserve is a commitment to the sponsor and is defended by the reasoning behind it. An assistant that corrects an inconsistency in the network on its own initiative while it applies a scenario invalidates the comparison without warning. The request sent to a hosted service carries supplier performance data and the contract's penalty clauses out of the organisation.

Examples

Extension of a day-surgery unit in a cantonal hospital. The baseline gives a finish on 15 May 2027 and its critical path runs through the building permit taking legal effect, site preparation, the structural works, the building services, the cantonal safety inspection and handover. Two scenarios are drawn from the risk register and run against the network.

Visualisations

A scenario register gives the results; the network gives the mechanism that produces them. Stacking the baseline and the same network under each of the two scenarios, on a shared time axis, makes visible the path along which a delay propagates: where the affected activity is on the critical path, the extension reaches the finish milestone and pushes it out by the same amount; where the activity has float, it stops inside that float and the rest of the network does not move.

Cost

Tooling

The technique assumes a tool that holds a network and can recalculate the forward and backward passes: project scheduling software. Common practice is to duplicate the baseline file per scenario. Tools with a baseline comparison function display the date variance activity by activity and save that back-and-forth.

A spreadsheet carries the analysis for a network of about ten activities; the backward pass computed by hand is where the errors slip in. Beyond that, the scheduling tool is safer and faster. Schedule risk analysis modules add sampling-based simulation and the tornado diagram on the same network, which allows all three analyses to be run without re-entering the model. To formulate the scenarios, a whiteboard and an hour with the client, the general contractor and the permits lead give a better list than any template.

Sources

• Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8th ed., PMI: what-if scenario analysis as a data analysis tool of schedule development (§2.3.2.2) and schedule control (§2.3.2.3), the question the scenario asks, the recalculation of the network and the use of the result for reserves and response plans; the separate definitions of sensitivity analysis and simulation (Section 5) and their attachment to the risk analysis process (§2.7.2.3), whose quantitative model they feed.
• U.S. Government Accountability Office, Schedule Assessment Guide: Best Practices for Project Schedules (GAO-16-89G), GAO: the separation, within schedule risk analysis, between ranking the variables by correlation and the iterative simulation that produces a distribution of dates.
• ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), §4.6.3: the same reasoning applied to the parameters of a business process, outside a scheduling context.