A thousand tomorrows before breakfast

On most capital projects a quantitative risk analysis happens once or twice: at sanction, and again when something has gone wrong enough to justify the fee. The result is a P80 date and a tornado chart, both true on the day they are printed and both out of date a fortnight later. The limit was never the method. It was that running a schedule ten thousand times took a specialist, a licence and a week.

That limit is gone. A schedule of twenty thousand activities can be recalculated in milliseconds. Ten thousand runs is seconds. A thousand recovery scenarios, each run a thousand times, is a few minutes on hardware that costs less than one day of a delayed site. What used to be an annual event can be the thing the project does every night, and that changes what a decision looks like in the morning. This post works through what that means in practice: what gets simulated, what the result looks like, how a decision is rehearsed, where the method still breaks, and who is still in charge.

The project runs itself a thousand times, every night

Picture the record at the data date: the live schedule, the risk register with its probabilities and impacts, the contract's dates and damages, the model's progress from site, the forecast with its cost lines. Every night, after the day's updates have been approved, the whole thing is simulated. Not once, but as a distribution. Each run draws a duration for every activity from its range, decides for each risk whether it happened in this run, applies the impacts, and computes the finish date of every milestone. By morning the project knows, for every milestone, the spread of dates it is likely to finish on, and which risks are driving the far end of that spread this week, as opposed to last week.

The word whole matters. A simulation run on the schedule alone tells you about dates. A simulation run on the record tells you about dates, the cost that each date carries, the clause that each date triggers, and the area of the model where each run goes wrong. The same run that says M4 finishes on 23 November in this version of the world also says what the standing crew cost, whether the damages clause under 14.2 was triggered, and which tank was still open. That is only possible because schedule, cost, contract and model are one record, not four files that agree on a good day.

Here is what the nightly result looks like for Northgate Terminal, a fictional EPC project with four tanks, a marine berth, and a mechanical completion milestone called M4 that the contract punishes. After Tuesday night's run, the planner, L. Ferreira, opens the brief and sees that M4's median finish is 18 November, that eight runs in ten finish by 26 November, and that the worst tenth of runs finish after 9 December. Last week the worst tenth finished after 2 December. Something has moved the tail by a week, and the brief says what: a delivery letter from Valvex, SUP-0877, raised the probability of a late valve risk, R-0231, and that risk sits on a path that now has no float.

The tail moves, and now you can see it move

This is the part the annual report could never do. The tail moves. A letter arrives, a crane extension is refused, a test fails, and the combinations that produce the worst runs change. A project that simulates nightly sees the tail move the morning after the fact, while the fix is still a sequence change and not a claim.

The useful analysis is not the tornado chart, which ranks risks one at a time. It is the reverse: take the worst tenth of runs and ask which risks happened together in them. On Northgate, after the Valvex letter, the grouping looks like this.

Compare that with the tornado chart from the sanction-stage analysis, which ranked ground conditions first, the hydrotest second and late valves fourth. Each ranking was true for one risk at a time. None of them said that the fourth-ranked risk was the one that appeared in every bad combination, because that is a question about pairs, and the chart does not ask it. A nightly grouping asks it every night, and the answer changes as the project changes.

The planner reads the table and sees the shape of the problem. R-0231 is not dangerous on its own; eleven days late is survivable. It is dangerous because it shares a path with two other risks, and when two of the three land in the same fortnight, the hook-up to T-102 has nowhere to go. The fix is not to chase the supplier harder. The fix is to change the logic so that the risks stop stacking: move the crane-dependent work earlier, or decouple the hydrotest from the valve delivery. That is a planner's decision, and now it is a decision with a reason.

Every decision, rehearsed before it is made

The second half of the idea is that decisions become rehearsals. A planner asks for three ways to protect M4. Each way is not a date; it is a distribution, because each was run a thousand times against the same risks. The option that looks best on its median may carry a fatter tail, because it stacks two risks on one path. The one that looks slower may be the one you can actually promise. Seeing that difference before choosing is the whole point.

On Northgate, L. Ferreira tries three. S-1 puts a second crew on the T-102 hook-up. S-2 prefabricates the spools off-site so the valves go in last. S-3 erects the pipe-rack bents 5 to 8 before T-103, which frees the crane earlier. Each is a copy of revision 14 with one change, and each is run a thousand times against the same register.

S-3 is the one the Gantt chart would choose: fastest median, cheapest. The simulation shows why it is the riskiest promise. Erecting the bents early puts the crane on the critical path during the same window the hydrotest needs it, so when R-0231 and the hydrotest failure land together, which they do in a quarter of the bad runs, S-3 has nothing left to give. S-2 is two days slower on the median and a week better at the tail, because prefabrication removes the valve delivery from the path entirely. The project director, S. Okafor, can promise S-2's 25 November to the client with more confidence than S-3's 22 November, and the brief says so in those words.

The model makes this legible to people who do not read distributions. Each option plays on the 4D twin, week by week, beside the current plan. The steel that moves earlier lights up; the area that waits goes grey. A project director can see, in thirty seconds, why the slower option is the safer promise. The same twin that shows what was built last week shows what each choice does next month.

What is computed, what is written, what waits

It is worth being exact about which part of this is arithmetic and which part is language, because the trust in the result depends on keeping them apart.

1. The critical path engine computes dates for every activity in every run. It is the same engine that computes the live schedule; a run is just the engine with different inputs.
2. The risk draw decides, per run and per risk, whether the risk happened, using the register's probability, and applies the register's impact to the activities the risk is tied to.
3. The cost model prices each run: standing time from the resource profile, damages from the contract's clause and dates, prolongation from the overhead rate.
4. The grouping step takes the worst tenth of runs and clusters them by the set of risks that happened in each, then names the activities those risks sit on.
5. The language model writes the brief: one paragraph per milestone, one per bad combination, one per scenario, each sentence carrying the figures the steps above produced and nothing else.
6. The proposal queue receives any scenario the planner chooses to promote. The live schedule changes only when a person approves that promotion, and the approval is logged with a name and a time.

The model never produces a number. If a reader clicks any figure in the brief, the platform shows the run, the step and the inputs that produced it. If a step fails, the brief says that it failed, and the milestone's paragraph says that no figure is available, rather than offering one.

What cheap compute changes, and what it does not

Cheap compute changes the cadence: simulation becomes continuous, scenarios become plentiful, and the question shifts from “what is the date” to “which of these futures do we want to be in”. It also changes who can ask. When a run took a week, only the risk specialist asked, once a year, in a report. When a run takes seconds, the planner asks on Tuesday, the cost engineer asks on Wednesday, and the director asks in the review, and all three get the same answer from the same record.

It does not change the quality of the inputs. A simulation of a register full of guessed probabilities is a very fast way to be wrong. The nightly run is only as good as the ranges on the activities and the probabilities on the risks, which is why the Risk agent on the night shift takes probabilities from the register's history and flags the ones it had to guess. A result built on a flagged input says so in the brief.

It does not change the logic, either. If the schedule's dependencies are wrong, every run inherits the error. Nightly simulation makes bad logic visible faster, because a tail that refuses to move when a risk is removed usually points at a dependency that should not exist, but it does not fix it. A planner does.

And it does not change who answers the question. Nothing moves onto the live schedule because a simulation preferred it. A person approves one line, with a name and a time.

Where the method breaks

Correlated risks treated as independent. If the register says late valves and the hydrotest failure are independent, but in reality both follow from the same under-resourced supplier, the simulation under-counts how often they land together and the tail is thinner than the truth. What catches it: the grouping step shows which risks keep appearing together across many nights. A pair that stacks far more often than its probabilities predict is a correlation the register has not written down, and the brief points at it.

Ranges set once and never revised. Duration ranges set at sanction stay in the schedule after the work has changed. What catches it: actual durations are on the record, approved day by day, and each night's run compares the ranges to the actuals for completed work. A range that the actuals have left behind is flagged for the planner to revise.

Two humps read as one. Sometimes the distribution has two peaks: one world where the permit arrives on time, one where it does not. A P80 across both is the average of two things that never both occur. What catches it: the brief reports the modes separately when the distribution is clearly bimodal, with the probability of each and the risk that separates them, so the director sees the choice rather than a blended date.

Confidence in the wrong place. A spread of a thousand runs looks authoritative, and a planner can forget that it rests on a register. What catches it: every figure in the brief carries its inputs, and the inputs that were guessed are marked. Authority comes from the sources, not from the number of runs.

What changes for each person

The planner stops being asked for a date and starts being asked for a spread, and has it. The work moves from producing the schedule to shaping its logic so that risks stop stacking. The three scenarios that used to take a week to build and a day each to run are a morning's work, and the question of which to recommend has an answer that can be shown.

The cost engineer gets a forecast that is a distribution too, because every run was priced. The exposure under clause 14.2 is no longer a single number in a letter; it is the share of runs in which the clause triggers, and the cost in those runs. Contingency can be set against the tail rather than against habit.

The contract manager can see which clauses each bad combination triggers and when, and so which notices to prepare before the event rather than after it. The deadline calendar and the simulation read the same contract.

The project director gets to make the promise that the project can keep. The choice between S-2 and S-3 is a choice between a faster date and a safer one, and for the first time both halves of that trade are visible on the same screen, with the model showing what each does to the site.

• Nightly: the whole record simulated, the tail re-grouped by the risks that produced it, the inputs that were guessed flagged.
• On request: any recovery tried as a distribution, not a date, priced per run, and shown on the model.
• Always: figures by tools, with their sources; the choice by a person, on the record.

What you can do on Monday

1. Take the last risk analysis you have and group its worst tenth of runs by the risks that occurred in them. Most tools can export the run-level data. The groups will tell you more than the tornado did.
2. Put a range on every activity on the critical path, even a rough one, and write down where it came from. A range with a source can be revised. A single duration cannot be argued with and cannot be trusted.
3. For your next recovery decision, insist on seeing the slower option's tail beside the faster option's median before choosing. If nobody can produce it, that is the gap this post is about.

Where this stands

Verian is a project controls service run on Verian's own AI platform. Today, Verian's team runs recovery scenarios for clients as sandboxes against the whole schedule, reads a risk analysis and groups its tail by the risks that stack, prices scenarios against the cost model and the contract, and plays the current plan beside a scenario on the 4D model. The client's people log in, see all of it with their own access, and make the decisions. Verian's team does not sit in the client's meetings and does not negotiate on the client's behalf.

The nightly, whole-record simulation described here, every milestone as a spread every morning, every scenario a thousand runs by default, the tail re-grouped while the team sleeps, is the direction we are building in. The pieces are the ones already on the platform. The rule that holds through all of it is the same one that has held since the first release, and the same one the night shift in the first post of this series obeys: the machine proposes, the person decides.