Project Schedule Slippage & Recovery Calculator
Project Schedule Slippage & Recovery Calculator
If this task slips, how far does the whole project actually move — and what wins the date back? Enter your task network once, inject a delay, and watch the finish date cascade while crash, overtime and fast-track are priced against your contract date.
Project calendar
All durations are working days. Weekends are skipped per the work-week setting below, and holidays you list are skipped too — so revised dates stay correct across bank holidays.
Task network
Baseline activities
Predecessors take row numbers: 2 or 3,4. Append a type and lag to override the row default, e.g. 2SS+2. Duration 0 or the MS box marks a milestone.
Optimal for 8–150 activities in a single browser page. Beyond roughly 150 the recalculation still runs, but the on-screen Gantt becomes crowded.
Delay events
Add one or several delays. Each is injected into the network and the whole schedule is recalculated — downstream activities and milestones cascade automatically. Tagging a cause lets you see later how much of the slip each root cause is responsible for.
Delay type explained
Late start
Work begins later than planned but takes the same time. Only successors tied to a start-to-start link feel the full shift.
Duration overrun
Work starts on time but runs long. This is the common construction case and pushes every finish-to-start successor.
What float does
A delay inside a task’s total float is absorbed: the project finish does not move, it only eats contingency.
Recovery levers
Set the parameters once, then combine them into scenarios
Efficiency and rework values are modelling assumptions, not industry constants — change them to match your own site history.
Scenario mix
Which levers does each option use?
Tick the levers each scenario applies. Results are compared side by side against doing nothing.
Levers acting on the same critical activity overlap in practice, so the combined recovery is shown as an upper bound — capped at the slip it is trying to remove.
The headline
—
Before & after schedule
Activity impact
| Activity | Dur. | Base start | Base finish | Revised finish | Moved | TF | FF | Status |
|---|
Milestone impact
| Milestone | Baseline date | Revised date | Slip | Assessment |
|---|
Float consumed by each delay
| Delay event | Delay | Float before | Absorbed | Passes through | Effect |
|---|
Recovery scenarios
| Scenario | Recovered | New finish | Extra cost | Cost / day | Residual risk | Verdict |
|---|
Your next 24 hours
Add a delay to see the recommended action.
Assumptions baked into these numbers
- Durations are working days on the calendar you set; holidays you list are excluded.
- Logic is finish-to-start unless a row or a predecessor token says otherwise; lag is applied as entered.
- Durations are fixed at entry — the tool does not resource-level, so a crew cannot be double-booked here.
- Crash and overtime gains use a linear estimate with the efficiency factors you supply.
- Fast-track rework is expected value only; it is not a schedule, it is a risk-adjusted deduction.
- For contractual or forensic delay claims this output is indicative, not a substitute for a scheduler of record.
Why a slippage calculator beats a critical path calculator
A critical path calculator answers “how long is this project?”. That question is already solved by a dozen free tools. The question a project manager actually asks on a Tuesday morning is different: “the structural works are five days late — does the handover date move, and what does it cost to hold the date?” That is a slippage and recovery question, and it is the one this page answers.
The difference matters because the two calculations use different data. Baseline duration comes from dependencies alone. Slippage comes from the gap between the approved baseline and what execution is actually delivering. Recovery comes from testing compression options against a target date — and being honest about which ones the network will reward.
How the cascade works
Each activity gets an earliest start by pushing logic forward from the project start, then a latest start by pulling logic back from the finish. The gap between the two is total float. Inject a delay and the tool re-runs both passes: activities with float soak the delay up, activities without it pass the delay straight down to every successor, and the maximum finish across the network becomes the revised completion date.
This is why a five-day delay can produce a zero-day slip. If the delayed activity has six days of float, the project finish does not move — but the contingency is gone, and the next delay on the same chain will land in full.
Fast-tracking versus crashing
| Dimension | Crashing | Fast-tracking |
|---|---|---|
| What changes | More resources on the same activity | Sequential activities run in parallel |
| Cost driver | Added headcount, overtime, hiring | Rework, coordination, supervision |
| Risk profile | Trade stacking and lost productivity | Rework and quality escapes |
| Works best on | Long, divisible, labour-heavy activities | Activities with clean, separable handoffs |
| Typical failure | Adding people to a short task | Overlapping design and construction |
| Ceiling | Productivity falls as crew density rises | Reverses if rework exceeds the overlap |
Formulas used in these calculations
1 · Forward pass — earliest dates
\[ \begin{aligned} ES_i &= \max_{p \in P(i)} \big( EF_p + lag_{p,i} \big) \\[2pt] EF_i &= ES_i + D_i \end{aligned} \]
For start-to-start logic the bound is ESp + lag instead of EFp + lag; finish-to-finish and start-to-finish logic constrain the finish and are converted to an equivalent start bound.
2 · Backward pass — latest dates and float
\[ \begin{aligned} LF_i &= \min_{s \in S(i)} \big( LS_s - lag_{i,s} \big) \\[2pt] LS_i &= LF_i - D_i \\[4pt] TF_i &= LS_i - ES_i \\[2pt] FF_i &= \min_{s \in S(i)} \Big( ES_s - lag_{i,s} - EF_i \Big) \end{aligned} \]
Total float is how long an activity can slip before the project finish moves. Free float is how long it can slip before its own successor moves.
3 · Delay effect and float consumption
\[ \begin{aligned} \text{Slip} &= \max\big(0,\; \Delta - TF_i \big) \\[2pt] \text{FloatConsumed} &= \min\big(\Delta,\; TF_i \big) \\[2pt] \text{ProjectSlip} &= \max_j EF_j^{\,new} - \max_j EF_j^{\,orig} \end{aligned} \]
When TFi ≥ Δ the delay is fully absorbed and the completion date does not move.
4 · Schedule slippage percentage
\[ \text{Slippage }(\%) = \frac{\text{Revised} - \text{Planned}}{\text{Planned}} \times 100 \]
Normalising by planned duration lets you compare a four-week fit-out with a two-year build. It is a reporting ratio, not a forecast.
5 · Crashing — duration with more people
\[ \begin{aligned} D' &= \max\!\left( D(1-c),\; \frac{D \cdot B}{B + N \cdot e} \right) \\[2pt] k &= \min\big( \text{needed},\; D - D' \big) \\[2pt] \text{Recovered} &= k \\[2pt] \text{Cost} &= N \cdot R \cdot k \end{aligned} \]
B = current crew, N = added workers, e = efficiency of an added worker, c = maximum compression, R = cost per worker-day, k = days of compression actually bought. You are charged for the compression you use, not for shortening the whole activity.
6 · Overtime
\[ \begin{aligned} g &= \frac{h_{ot} \cdot e_{ot}}{h_{day}} \quad \text{(days saved per day worked)} \\[2pt] \text{Recovered} &= \min\big( \text{needed},\; K \cdot g \big) \\[2pt] k_d &= \frac{\text{Recovered}}{g} \\[2pt] \text{Cost} &= M \cdot h_{ot} \cdot R \cdot m \cdot k_d \end{aligned} \]
hot = overtime hours per day over an 8-hour day, M = people, m = premium multiplier, K = days of overtime available, kd = overtime days actually worked. Cost is charged on kd, so you only pay for the days the recovery really takes.
7 · Fast-tracking and rework
\[ \begin{aligned} \text{Rework days} &= O \cdot r \\[2pt] \text{Recovered} &= \min\big( \Delta,\; O - O r \big) \\[2pt] \text{Cost} &= (O + O r)\cdot C_{day} \end{aligned} \]
O = overlap days, r = expected rework proportion. Risk is rated low below 10 %, medium to 25 %, high above that.
8 · Ranking recovery options
\[ \text{Cost per day recovered} = \frac{\text{Additional cost}}{\text{Slip}_{before} - \text{Slip}_{after}} \]
Any option that cannot reach the target is judged on days recovered first and cost second. A recovery option that recovers nothing has no meaningful cost per day — it is reported as unavailable rather than as zero.
Common mistakes this catches
Crashing a short task
Adding eight people to a three-day activity does not produce a negative duration. The compression cap stops the arithmetic from lying to you.
Crashing off the critical path
Speeding up an activity that is not driving the finish date buys nothing. This tool reports zero recovery instead of flattering the plan.
Counting calendar days
A five-day delay issued on a Wednesday does not resolve on Monday. Dates walk the working calendar, holidays included.
Overtime without a shelf life
Overtime recovers days early and stops paying after a few weeks. The days-available input caps the benefit and the report flags long runs.
Questions people ask before trusting the number
Does a delay on a non-critical task delay the project? Not while it stays inside that task’s total float. Once the delay exceeds the float, the excess passes downstream in full and the finish date moves by exactly that excess.
Why does my slip differ from the raw delay? Because float absorbs part of it, and because the critical path can change. The tool highlights the new critical path when a parallel chain becomes the longest route.
Can recovery ever beat the original date? The engine caps recovery at the slip it is trying to remove, so the revised finish never runs earlier than the baseline. That is deliberate: it keeps the comparison honest.
Is this a delay-analysis tool for claims? No. Time impact analysis for a claim inserts a fragnet into an accepted programme and is done by a forensic scheduler. This tool sizes the impact in seconds so you know whether that exercise is warranted.
Keep going
The delay is sized. These tools turn it into a plan, a budget or a contract position.
