KnownShift Decisions
Delay & Recovery Simulator
Methodology & Interpretation Guide
The Delay & Recovery Simulator answers the question a slipped task actually raises: whether the project has moved at all, and if it has, which of the recovery actions genuinely open to you is worth taking.
What the simulator answers
A task slipped. That is not the same as the project slipping, and the difference is usually worth more than the delay itself. This tool takes the remaining plan, applies what went wrong, and works out what actually happened to the completion date. Then it works out what could be done about it, using only the recovery levers you have confirmed are genuinely available.
- Did this delay move the project completion date, or did float absorb it?
- How much of the slack in the plan has been used up?
- What is on the critical path now that was not before?
- Can the original date be recovered, and at what cost?
- If it cannot, how close can I get, and what is left to re-baseline?
The baseline schedule
Everything starts from the remaining work, not from the original plan. You describe each significant activity still to be done, how many working days are left in it, and what it waits for. For work already under way, the figure that matters is what is LEFT, because that is the only number a delivery manager can state confidently mid-project and the only one the remaining schedule depends on. Activities marked complete are excluded from scheduling entirely.
How dependencies are evaluated
Activities are connected finish to start: an activity begins when the last of its predecessors finishes. The whole network is resolved rather than the durations added together, so two activities running in parallel cost what the longer one costs. This is why a delay on a parallel branch may not move the project at all, and why a long activity away from the driving path can turn out not to matter.
Earliest start and earliest finish
A forward pass through the network gives every activity the earliest it could possibly start, which is the latest finish among the things it waits for, and the earliest it could finish, which is that plus its remaining duration. The project finishes when the last activity with nothing after it does. All of it is counted in working days.
Latest start and latest finish
A backward pass from the project finish gives every activity the latest it could finish without pushing the project out, and the latest it could therefore start. An activity in the middle of a long chain usually has no room at all; one on a short parallel branch often has a great deal.
Total float, and why it decides everything
Total float is the gap between the earliest an activity could start and the latest it could start without delaying the project. It is the single most important number in this analysis, because it is exactly how much an activity can slip before anybody outside the team needs to know. An activity with four working days of float can lose four days quietly. The fifth day is a project delay.
The critical path
Activities with no float form the critical path: the chain that is currently deciding the completion date. It is not a fixed property of the plan. A delay somewhere else can hand criticality to a branch nobody was watching, and when that happens the recovery levers people had lined up stop working, because they are pointed at the wrong chain.
How a delay propagates
A delay is applied by lengthening the activity it happened to and recomputing the whole network. It is never added to the finish date, because that would produce the very error this product exists to correct. The project movement is the difference between the new completion and the original one, which may be the whole delay, part of it, or none of it.
Why activity delay and project delay are different numbers
This is the point most worth carrying into a steering meeting. A six-day slip on an activity holding four working days of float moves the project by two days, not six. Reporting the six overstates the problem and invites an expensive over-reaction; reporting nothing at all hides that the plan is now four days tighter than it was. Both figures are shown together, every time, for that reason.
Float consumption and what it costs you
Even a delay that changes no date changes the plan. Float that has been spent is no longer available for the next surprise, and an activity that had room yesterday may have none today. Where the completion date holds but float has been consumed, the result is reported as contained rather than absorbed, because the two call for different management responses.
Fast-tracking
Fast-tracking overlaps activities that were planned to run one after the other, letting the successor start a stated number of working days before its predecessor finishes. It usually costs no budget at all, which makes it the first lever worth examining, and it buys that time with rework risk: work begun against something not yet finished may have to be redone. The simulator only overlaps a dependency you have explicitly marked as overlap-eligible, and never by more days than you allowed.
Crashing
Crashing shortens an activity by adding people, hours or intensity. It is the lever that typically costs money, and it is bounded twice: by the maximum reduction you state for that activity, and by the days actually left in it. The simulator will not propose compressing an activity you have not marked as compressible, and will not propose a reduction your own team has already said is not achievable.
Resequencing
Sometimes a dependency in the plan is not a hard constraint, and the successor could begin without waiting. Where you mark a dependency as one that can be dropped, the simulator evaluates the schedule with that link removed. It never removes a dependency on its own initiative, because reinterpreting somebody's plan without permission produces a recovery that cannot actually be delivered.
Recovery constraints are yours, not ours
Nothing in the plan is assumed to be compressible, overlappable or optional. Every lever the simulator considers is one somebody who knows the work has confirmed, with a limit attached. That is deliberate: a recovery option the team has not agreed to is not a plan, it is a commitment somebody else will be held to.
How recovery scenarios are generated
The simulator combines the available levers and recalculates the whole schedule for each combination. Only levers touching an activity currently on a critical path are explored, because compressing anything else cannot move the finish and would only produce a more expensive route to the same date. The search proceeds by number of actions and stops as soon as adding another buys nothing.
- Combinations that buy no time over the combination they extend are abandoned.
- One activity is never compressed by two different amounts in the same scenario.
- The search is capped, so a large plan cannot make the analysis unresponsive.
Lowest-cost, full-date and balanced recovery
Three questions get three answers. Lowest-cost recovery is the cheapest action that recovers any of the delay. Full-date recovery is the cheapest combination that restores the original completion date, where one exists at all. Balanced recovery is the option giving the most schedule back for each unit of cost, short of full recovery, which is often the sensible answer when the last day back is far more expensive than the first.
Cost per day recovered
Recovery cost divided by working days recovered. It is the most useful single figure in a recovery conversation, because it makes the marginal trade visible: recovering three days for one hundred and twenty thousand and five days for three hundred and sixty thousand are very different propositions, and the second two days are the expensive ones. It is only shown where recovery costs were supplied and something was actually recovered.
Why you are shown a few options and not fifty
An option that recovers no more time than another while costing more, using more actions and carrying more delivery risk is not a choice, it is noise. Those are filtered out, and what remains is the handful of genuinely different trades. Seeing four real options beats scrolling forty variations of the same two.
How ties are broken
Where two scenarios produce the same outcome, the ordering is fixed rather than arbitrary, so the same analysis always presents its options in the same order. Shorter duration wins first, then lower cost, then fewer separate actions, then less fast-tracking exposure, and finally the order you entered the activities in.
When full recovery is not possible
Often it is not, and saying so plainly is more useful than inventing a plan. Where every eligible lever applied together still leaves the project late, the simulator says how much can be recovered, what it would take, and how many working days remain to be re-baselined. A realistic revised date agreed early is worth considerably more than an optimistic one defended for another month.
The working calendar
Working days are Monday to Friday. Public holidays are not applied, so a date falling in a holiday period will move further than the analysis shows. This is stated rather than defaulted to one country's calendar, because inventing somebody else's public holidays would be inventing a fact about their project.
Reproducibility, and what produces the answer
The simulator is a deterministic model. No generative model, no language model and no external service is involved at any point: the same inputs and the same model version always produce the same result, on any machine, at any time, including the order the recovery options appear in. That is what makes it safe to attach the report to a recovery plan, because anybody who has the analysis can reproduce the figures and challenge the assumptions behind them. Every saved analysis records the model version it was produced under.
How to read and interpret the result responsibly
Treat the project movement as the headline and the activity delay as context, not the other way round. Treat the recovery options as priced choices rather than instructions: the simulator knows what you told it about cost and limits, and nothing about whether your people can absorb another compressed sprint. The most valuable output is usually not the recommended option but the gap between the cheapest recovery and the full one, because that gap is the conversation worth having.
What this model does not claim
- This is a model of the remaining plan and the recovery limits you entered. It measures your assumptions; it knows nothing about your project that you did not tell it.
- Only finish-to-start dependencies are modelled. Leads, lags, start-to-start relationships and partial-completion handovers are not.
- Resource availability and contention are not modelled. Two activities compressed at the same time may need the same people, and the simulator cannot see that.
- Fast-tracking and resequencing carry delivery risk that is real and is not quantified here. The simulator reports the schedule effect, not the probability of rework.
- Recovery costs are the figures you supply, treated as linear per working day. Real compression costs often rise steeply towards the end.
- Working days are Monday to Friday and public holidays are not applied.
- The escalation point that separates a project impact from a material one is a KnownShift assumption you can change. It is not an industry standard and carries no certification or endorsement.
Every figure this utility produces follows from the information you entered and the assumptions set out above. It is a structured model of one decision, offered to inform professional judgement rather than to replace it or to substitute for your organisation’s own governance.