Project Schedule Slippage Calculator — Delay Impact & Recovery

AlamToolKit · Free project controls tool

Project Schedule Slippage Calculator

Enter one delay and see the real consequence: the revised completion date, which milestones move, how much float is consumed, and what each recovery option costs per day it wins back. No signup, nothing leaves your browser.

1Project setup

Project start date

Working days per week 5 — Mon to Fri 6 — Mon to Sat 7 — every day

Target / contract finish optional

Holidays YYYY-MM-DD, comma separated

Cost of delay per day Pro

Durations are counted in working days. Durations of 0 are treated as milestones and are not typed as such separately.

2Schedule — tasks & dependencies

6 tasks

ID	Task name	Duration (d)	Predecessors	Type	Lag	Trade	Remove

Predecessors: task IDs separated by commas, e.g. T1, T2.

3The delay

Free: 1 delay

Which task slipped?

How did it slip? Ran longer than planned Started later than planned Finished later than planned

Delay working days

Delay impact

live

Completion date

—→—

Loading…

Project slip

—

 

Float consumed

—

 

Tasks moved

—

downstream of the delay

Milestones hit

—

zero-duration tasks

Before / after

4Recovery options

2 of 2 scenarios

Each scenario is applied to the already-delayed schedule and re-run through the critical path — so a lever on a non-critical task correctly returns 0 days recovered instead of flattering you.

Export & assumptions

Load project

Efficiency factors (crash η, overtime e, fast-track rework risk) are editable modelling assumptions, not industry constants. Change them to match your project's evidence.

Unlock Pro — recover the date, not just the diagnosis

Free covers a single delay and two recovery scenarios. Pro is built for the moment a PM has to defend a revised programme.

• ✓ Unlimited tasks — no 25-task cap
• ✓ Multiple simultaneous delays (overlay effects)
• ✓ SS / FF / SF dependencies with lead & lag
• ✓ Unlimited scenarios, auto-ranked by cost per day recovered
• ✓ Cost of delay, daily overhead & liquidated damages
• ✓ CSV export, saved templates, scenario archive
• ✓ Negative float & target-date compliance view
• ✓ Branded PDF report for client / leadership

Pro Unlock Pro on Gumroad

Results explained

Slip is revised finish minus baseline finish in working days. Float before / after is how long a task can slip without moving the project end; negative float means the baseline finish can no longer be met. Float consumed means the delay was absorbed without moving the finish.

Formulas used

• Forward pass: ES = max(predecessor EF + lag); EF = ES + duration
• Backward pass: LF = min(successor LS − lag); LS = LF − duration
• Total float = LS − ES; critical when float ≤ 0
• Single-delay slip = max(0, delay − total float)
• Crash: newDur = dur ÷ (1 + (extra/crew) × η)
• Overtime: newDur = dur × regHours ÷ (regHours + otHours × e)
• Cost per day recovered = extra cost ÷ days recovered

Worked example

Foundation 10 days, Structure 20, Electrical 12, Plumbing 10, Finishing 15, Inspection 3. Structure is delayed 5 days. Structure is critical, so the finish moves 5 working days; Plumbing only loses part of its float. Press Load demo schedule to see it.

Frequently asked questions

How is schedule slippage calculated?

Schedule slippage is the gap between the approved baseline completion date and the forecast completion date, in working days. The simple percentage form is ((Actual − Planned) ÷ Planned) × 100, but that ignores dependencies — a 10-day delay on a task with 10 days of float is not a 10-day project slip. This tool re-runs the critical path after the delay, so the slip you see is the one that actually reaches the finish date.

What is float, and why does it absorb a delay?

Total float is how many working days a task can slip before the project completion date moves: Total float = Late start − Early start. If a task has 2 days of float and slips 5 days, the first 2 days eat the float and only the remaining 3 pass through to the project finish. That is why the same delay has wildly different consequences depending on where it lands.

Does a delay on a non-critical task delay the project?

Only if it exceeds that task's float. Inside the float, the finish date does not move at all — the tool will tell you the delay was absorbed. Past the float, the excess passes to completion and the task itself becomes critical, which usually means the critical path has quietly changed and your recovery plan must target a different task.

Fast-tracking vs crashing — which is cheaper?

Crashing adds resources: direct, predictable cost, with diminishing returns as crowding and ramp-up eat the gains. Fast-tracking overlaps tasks that were sequential: usually cheaper, but it carries rework risk and can cause trade stacking. This tool quantifies both against the same network and reports cost per day recovered, so the comparison is like-for-like instead of rhetorical.

How do you recover a schedule that is already 42 days late?

Start from the truth: test recovery only on tasks that actually drive the completion date, quantify each lever in recoverable days, rank by cost per day recovered, and accept that some gaps cannot be closed. If the residual remains, communicate the revised date early — a recovery plan that silently does not add up is worse than an honest delay notice.

Is this a replacement for Primavera P6 or a forensic delay analysis?

No. It is an indicative decision-support tool for planning conversations. It uses deterministic durations, a simplified calendar, no resource levelling and editable efficiency assumptions. Contractual delay claims, time impact analysis and resource-constrained scheduling need professional scheduling software and expert review.

Related AlamToolKit tools

Critical path method, explainedForward pass, backward pass, float — with worked numbers Total float vs free floatWhy two float figures disagree, and which one to plan with Project cost overrun calculatorTurn recovered days into money at risk How to write a delay noticeStructure, evidence and tone that survives scrutiny

Indicative planning output only — not a substitute for professional schedule analysis, resource levelling or forensic delay assessment.
All calculations run in your browser. No schedule data is uploaded, stored on a server, or shared.
© 2026 AlamToolKit.com

AlamToolKit · Project Schedule Slippage Calculator - User Guide

Project Schedule Slippage Calculator — Complete User Guide

This guide explains every field in the AlamToolKit Project Schedule Slippage Calculator, shows exactly what units to enter, walks through a worked critical-path example, and lists the common mistakes that quietly produce wrong answers. If you are new to float and critical path, start at What this calculation is used for.

Figure 1. A 5-working-day delay on Plumbing only pushes the Handover milestone by 3 working days, because Plumbing held 2 days of total float. The calculator runs this exact cascade automatically.

What this calculation is used for

The Schedule Slippage Calculator answers one question that every project manager gets asked, usually in a corridor, with no warning:

“If this one task slips by five days, when does the whole project actually finish?”

That question cannot be answered by adding five days to the finish date. It depends on three things the calculator handles for you:

• Total float — how many working days a task can slip before the project end moves at all.
• Successor cascade — which downstream tasks are chained to the delayed one, and by how many days each of them moves.
• Critical path change — whether the delay has silently promoted a different chain to become the new driving path.

The result is a revised completion date, a milestone-by-milestone slip list, the number of float days consumed, and a comparison of recovery options costed per day recovered.

i

Accuracy note. The calculator uses deterministic durations, a simplified working-day calendar, and no resource levelling. Its output is indicative — accurate enough to make a planning decision, not a substitute for a Primavera P6 schedule, a time-impact analysis for a contractual claim, or a forensic delay assessment. Every number is derived only from the inputs you type; nothing is fetched from a server.

Where to apply it

This tool is deliberately generic — it does not care whether your tasks are concrete pours or sprint tickets. It is used most often in these situations:

Construction & civil works

Testing the impact of a late structural frame, a supplier delay on mechanical equipment, or an extension-of-time scenario before it becomes contractual. Feeds directly into delay notices and revised programmes.

Software delivery

Quantifying what a two-week backend slip does to a launch date, and whether pulling a tester onto the critical path actually recovers the date or just burns cost. Ideal for sprint retrospectives and release planning.

Product launches & marketing

Showing stakeholders the true launch date after a design review slips — and comparing three recovery levers (extra agency days, overtime, overlapping approval and production) on a like-for-like cost-per-day basis.

Engineering & commissioning

Validating the schedule impact of an equipment FAT failure, a permit delay, or a late vendor drawing before signing a variation order. Pairs well with AISC / ASCE / Eurocode compliance schedules.

Step-by-step guide

The calculator has four numbered sections. Work through them in order — each one feeds the next.

1. Set up the project

   Enter the project start date, the working-days-per-week pattern, and — if you have one — the contractual target finish date. These three values define the working-day calendar that every later calculation uses.

2. Enter the schedule

   Add each task with its duration in working days, its predecessors (task IDs separated by commas), and a trade label. Durations of zero become milestones. The predecessor field is the input that makes the cascade realistic — a task with no predecessors starts on day zero regardless of everything else.

3. Describe the delay

   Choose the task that slipped, pick how it slipped (ran longer, started late, finished late), and enter the delay in working days. The slider lets you sweep the delay from 0 to 60 days to see exactly when float is exhausted.

4. Compare recovery options

   Add a scenario, pick a lever (crash, overtime, or fast-track), and the calculator re-runs the critical path with that lever applied. Each scenario is compared on cost per day recovered, not headline cost, so a cheaper scenario that recovers fewer days does not masquerade as the winner.

Field-by-field reference

Every field in the calculator, with its unit, valid range, and what it changes in the output.

Step 1 — Project setup

Field	Unit	Valid input	What it does
Project start date	date	Any calendar date	Anchors working-day 0. Every task date is counted forward from this date, skipping weekends and listed holidays.
Working days per week	days/week	5, 6, or 7	Defines which weekdays are working days. 5 = Mon–Fri, 6 = Mon–Sat, 7 = every day including Sunday.
Target / contract finish	date	Any calendar date, optional	If set, the calculator reports the gap between the revised finish and the target in working days. A negative gap is negative float — the target can no longer be met.
Holidays	YYYY-MM-DD, comma-separated	0 or more ISO dates	Dates excluded from the working-day count. Example: 2026-12-25, 2026-12-26. Applies to the whole project.
Cost of delay per day (Pro)	currency/day	≥ 0	Optional. When set, the calculator multiplies the project slip by this rate to give the estimated cost of the delay in your currency.

Step 2 — Schedule rows

Column	Unit	Valid input	What it does
ID	text	Letters, numbers, underscore	Identifier used in the Predecessors column of other tasks. Must be unique. Examples: T1, CONC-01, MEP-A.
Task name	text	Free text	Label shown in the results table and on the Gantt bars. Length capped at 80 characters.
Duration	working days	Integer ≥ 0	How many working days the task takes. 0 is a milestone — it has a date but no span. Durations are counted in working days, not calendar days.
Predecessors	task IDs	Comma-separated IDs	The tasks that must finish before this one can start (FS links by default). Example: T1, T2. An empty predecessor means the task starts on day 0.
Type	FS / SS / FF / SF	FS free; others Pro	Dependency type. FS = finish-to-start (default). SS = start-to-start, FF = finish-to-finish, SF = start-to-finish. Non-FS types are Pro features.
Lag	working days	Integer, −60 to 365	Extra gap (positive) or overlap (negative) between the predecessor and the dependent task. A 2-day lag after concrete pouring represents curing time.
Trade	text	Free text	Optional. When two tasks of the same trade overlap in time, the calculator raises a “trade stacking” warning — relevant for productivity risk.

Step 3 — The delay

Field	Unit	Valid input	What it does
Which task slipped?	task ID	Any existing task	The single task whose duration or timing has changed. The calculator re-runs the critical path as if this task alone had shifted.
How did it slip?	enum	duration, start, finish	duration = ran longer than planned (extends the bar). start = began later, kept the same length (shifts the bar). finish = finished late with the same start (extends the bar, recorded as a finish delay).
Delay	working days	Integer 0–365	The magnitude of the slip. The slider caps at 60 for usability; the number input accepts up to 365 for larger delays. Zero means no delay — useful to see the baseline only.

Step 4 — Recovery levers

Each scenario can contain one or more levers. Every lever is applied to the already-delayed schedule before the critical path is re-run.

Crash (add crew)

Field	Unit	What it does
Extra crew	people	Additional workers added to the task. Zero means no crash.
Base crew	people	Existing crew size. Used to compute the crew-doubling ratio; larger base crews compress less per extra worker.
Cost / crew-day	currency / crew-day	Loaded cost of one extra worker for one day. Multiplied by the compressed duration.
Efficiency η %	%	How much of an extra crew’s theoretical output actually lands. 60% is a common default on congested sites.

Overtime

Field	Unit	What it does
OT hours / day	hours/day	Additional hours worked beyond the standard day. Cap at 4 h/day for sustainable planning.
People	people	Number of workers on overtime. Multiplies the cost.
Base rate / h	currency / hour	Standard hourly rate before the overtime premium.
Premium ×	multiplier	Overtime multiplier (1.5 = time-and-a-half, 2.0 = double time).
Efficiency e %	%	Output per overtime hour relative to a standard hour. 85% is a common default; drops sharply past four consecutive weeks.

Fast-track (overlap)

Field	Unit	What it does
Overlap with	task ID	Which predecessor to overlap. Leave blank to auto-pick the predecessor with the latest finish.
Overlap %	% of predecessor duration	How much of the predecessor runs in parallel with this task. 40% on a 10-day predecessor = 4 days of overlap.
Rework risk %	%	Probability that overlapping causes rework. Used together with Rework days.
Rework days	working days	Days of rework if the risk materialises. The calculator adds risk × rework days back to the dependent task’s duration.
Overhead / day	currency / day	Daily cost of the rework, used to compute the extra cost of this lever.

!

Units matter. Every number that ends in days is a working day, not a calendar day. Five working days is normally seven calendar days. If you enter calendar days by mistake, your slip will be understated by roughly 40% on a five-day week.

Input validation rules

The calculator runs these checks before any number is displayed. If a check fails, the results panel is replaced by a red warning listing exactly what to fix.

Rule	What triggers it	What the calculator does
Start date required	An empty or malformed date	Blocks calculation and prompts for a valid date.
At least one task	Zero task rows	Blocks calculation and suggests adding a task or loading the demo.
Unique task IDs	Two rows share an ID	Rejects the duplicate; the second row is auto-renamed T1_2 in the internal model.
Valid duration	Negative, non-numeric, or empty	Marks the field with a red border and skips calculation until corrected.
Predecessors exist	An ID that is not in the schedule	Lists the missing ID in the warning panel.
No self-dependency	A task lists its own ID as a predecessor	Lists the task and blocks calculation.
No dependency loops	A cycle exists (e.g. A → B → C → A)	Lists the cycle members and refuses to compute until one link is removed.
Delay within range	Negative days, or > 365	Clamps to 0–365 and continues.
Free-tier task limit	> 25 tasks (free tier)	Blocks the 26th task and shows a Pro prompt.

✓

Pro tip. Press Load demo schedule first. The demo is a valid six-task network that exercises every output — it shows a delay that is partially absorbed by float, an affected milestone, and two competing recovery scenarios. Use it as a template, then overwrite the fields.

Worked example — a 5-day plumbing slip on a building project

This is the exact scenario the demo schedule loads. Every number below can be reproduced by pressing Load demo schedule and reading the results panel.

Inputs

• Project start: a Monday
• Working week: 5 days (Mon–Fri)
• No holidays
• No target finish date
• Delay: T4 (Plumbing install), 5 working days, type = duration

The schedule

ID	Task	Duration (wd)	Predecessors
T1	Foundation	10	—
T2	Structural frame	20	T1
T3	Electrical install	12	T2
T4	Plumbing install	10	T2
T5	Interior finishing	15	T3, T4
T6	Handover milestone	0	T5

Baseline result

• Critical path: T1 → T2 → T3 → T5 → T6
• Project finish: working day 57
• T4 (Plumbing) has 2 working days of total float — it can slip two days without moving the finish.

After the 5-day delay on T4

• T4 runs from 10 days to 15 days.
• Its 2 days of float are consumed first.
• The remaining 3 days push T5 and T6 by 3 working days.
• Project finish: working day 60 — a 3-working-day project slip.
• T4 is now critical (zero float remaining), and T5 now starts three days later than originally planned.

Why the slip is 3, not 5

This is the whole point of running a critical-path calculation instead of adding days to a finish date. T4 had two days of float because it sat on a parallel chain next to T3 (Electrical), which is two days longer. Only the portion of the delay that exceeds float passes through to the project end. The Gantt diagram at the top of this page shows exactly this.

Recovery comparison

Scenario	Lever	Recovers	Cost	Cost per day
A — Overtime on finishing	2 h/day overtime, 6 people, $38/h base, 1.5× premium, 85% efficiency	1 working day	$684	$684 / day
B — Fast-track plumbing into finishing	40% overlap with T4, 20% rework risk, 5 rework days, $900 overhead	4 working days	$900	$225 / day

Scenario B recovers more days at a lower cost per day, so the calculator ranks it first. Scenario A is cheaper in absolute terms but only recovers one day, so its cost per recovered day is nearly three times higher. Ranking by cost per day recovered stops the cheaper option from silently winning the comparison.

Common mistakes (and how to avoid them)

Every mistake below produces a wrong answer that still looks plausible. Read this list before you trust the output.

✕

Entering calendar days instead of working days. A five-day delay entered as calendar days understates the true slip by about 40% on a Mon–Fri schedule. The field is labelled “working days” for a reason. If a task took two calendar weeks, enter 10, not 14.

✕

Leaving the Predecessors column blank. A task with no predecessors is assumed to start on day zero. In a real schedule almost every task has a predecessor — a blank predecessor is the single most common cause of a suspiciously short project duration.

✕

Forgetting the milestone (duration 0). A Handover or Inspection task usually has zero duration. Enter 0 in the Duration field — do not skip it. Milestones are what the calculator uses to count the number of affected contractual dates.

✕

Adding days to the finish date instead of running the calculator. This is the mistake the tool exists to prevent. A five-day delay does not create a five-day slip unless the delayed task was already critical with zero float. Always press the calculator, never add by hand.

✕

Assuming recovery on a non-critical task works. Adding crew to a task that already has float will show 0 days recovered — correctly. Recovery must be applied to a task that is currently driving the finish date. If the calculator returns zero, the lever is on the wrong task.

✕

Modelling overtime at 100% efficiency. Twelve-hour days do not produce 50% more output than eight-hour days. The default efficiency assumption is 85%; use it honestly. If you cannot defend the number to a supervisor, lower it.

✕

Ignoring the trade-stacking warning. When two tasks of the same trade overlap in time, the calculator raises a warning. That overlap is often the reason a crash recovery plan underdelivers in reality. Treat the warning as a real constraint, not a decoration.

✕

Trusting the output as a forensic analysis. The calculator does not model resource levelling, weather, change orders, or acceleration costs beyond the levers you explicitly enter. Its output is a planning estimate for a conversation, not a contractual determination of delay.

Real-world usage patterns

Three concrete ways project teams use the calculator on a weekly basis.

1. The 6 p.m. corridor question

A site manager reports that the concrete pour is three days late. The project controls lead opens the calculator, clicks the affected task, enters 3 in the delay field, and reads the slip straight off the results panel: project slip +1 working day, 2 days of float consumed, no milestone affected. The answer takes 20 seconds and does not require opening Primavera.

2. Preparing a delay notice

Before writing a formal delay notice, the project controls lead runs three scenarios — no recovery, overtime, and fast-track — and screenshots the recovery comparison table. The notice is accompanied by the actual cost per day of each option, which turns the conversation from “we are late” to “here is the cheapest way to recover two of the three days, and here is the residual that cannot be recovered.”

3. Weekly programme review

At the start of each week, the planner loads the saved JSON, updates the durations of the tasks that slipped, and re-runs. The calculator reports which tasks moved from critical to non-critical and which moved the other way. That report becomes the standing agenda item for the programme meeting.

Key user pain points and how this calculator solves them

Pain point	What usually happens	How this calculator fixes it
“I do not know if this delay matters.”	Every reported slip gets escalated to the project manager, who cannot tell which ones are serious and which are inside float.	The results panel shows float consumed vs float remaining on every task. A delay entirely inside float is explicitly flagged as “absorbed” with no recovery action needed.
“Adding five days to the finish date is wrong, but everyone does it.”	Hand arithmetic understates slip because it ignores the parallel critical chain and overstates it when float absorbs part of the delay.	The calculator re-runs a full forward and backward CPM pass, so the slip reported is the one that actually reaches the project end.
“Recovery plans look good on paper but do not deliver.”	Crash plans are added to tasks that are not on the critical path, so the project date does not move even though the cost does.	Every lever is re-tested against the delayed critical path. A lever on a non-critical task returns 0 days recovered and is visibly labelled “recovers nothing.”
“I cannot compare recovery options fairly.”	One plan is cheaper but recovers less; another costs more but recovers the date. The comparison depends on which number the presenter happens to emphasise.	Every scenario is ranked on cost per day recovered — one number that makes the trade-off explicit and defensible.
“I need to communicate the residual delay honestly.”	The team promises to recover everything and then delivers a shorter recovery than promised.	When no scenario closes the target gap, the calculator explicitly reports the residual working days that should be communicated, not absorbed silently.

Accuracy and limitations

What the calculator models accurately

• Forward and backward critical-path passes using the standard CPM equations.
• Total float and free float per task.
• Cascade of a single delay through FS, SS, FF, and SF successors (SS/FF/SF are Pro features).
• Working-day calendar with configurable week length and explicit holiday exclusions.
• Crash, overtime, and fast-track levers, each with an editable efficiency assumption.

What it deliberately simplifies

• Resource levelling is not modelled. Two tasks can be scheduled in parallel even if they would compete for the same crew.
• Weather, holidays from external calendars, and site stoppages are only accounted for through the manual holiday list.
• Productivity decay over consecutive overtime weeks is handled through the efficiency assumption, not by a curve.
• Multiple simultaneous delays (overlay effects) are a Pro feature; the free tier models one delay at a time.

Forward pass → ES = max(pred EF + lag), EF = ES + duration

Backward pass → LF = min(succ LS − lag), LS = LF − duration

Total float → TF = LS − ES; critical when TF ≤ 0

Delay slip → slip = max(0, delay − TF_baseline)

Crash compression → newDur = dur ÷ (1 + (extra/crew) × η)

Overtime compression → newDur = dur × regH ÷ (regH + otH × e)

Ranking metric → cost per day recovered = extra cost ÷ days recovered

Frequently asked questions

What is the difference between total float and free float?

Total float is how many working days a task can slip before the project finish moves. Free float is how many working days it can slip before its next successor moves. A task with 5 days of total float and 0 days of free float can slip five days without delaying the project, but any slip instantly delays the successor. The calculator reports total float as the headline metric because it drives the project finish date.

Why does a 5-day delay show a 3-day project slip?

Because the delayed task had 2 working days of total float. The first 2 days of the delay are absorbed by float; only the remaining 3 pass through to successors and the project finish. This is exactly what a proper CPM recalculation is supposed to reveal — and it is why hand arithmetic by adding days to the finish date is wrong.

Can I enter more than one delay at a time?

On the free tier, no — the calculator models one delay per project, because modelling multiple simultaneous delays correctly requires accounting for how the delays overlay each other. Pro unlocks up to 20 simultaneous delays with overlay handling. For most planning conversations, one well-chosen delay is enough; pick the one that is currently causing the most concern.

Why does a recovery lever sometimes return 0 days recovered?

Because the lever is on a task that is not on the current critical path. Adding crew to a task with float shortens that task, but its finish date was never driving the project finish anyway — so the project date does not move. This is intentional: the calculator refuses to flatter a lever that will not actually recover time.

What is a realistic crash efficiency (η)?

On a well-managed site, 0.6 is a sensible default — each extra crew member contributes 60% of a full-time-equivalent worker. The lost 40% accounts for onboarding, congestion, supervision overhead, and rework. Pushing above 0.75 in a planning document is usually optimistic unless you have measured it on the same type of work before.

What is a realistic overtime efficiency (e)?

85% is a common default for the first two to three weeks. Past four consecutive weeks of sustained overtime, real-world studies show efficiency dropping to 60–70% and rework rates rising. If you are modelling a recovery plan that relies on more than four weeks of overtime, lower the assumption to match reality and plan for a residual delay.

Does the calculator handle non-FS dependencies?

Yes, on the Pro tier: start-to-start, finish-to-finish, and start-to-finish links with lead or lag. The free tier covers finish-to-start with lag, which is what most building and software schedules actually use. If your schedule relies heavily on SS or FF links, the free tier will not model it accurately.

Is my schedule data uploaded anywhere?

No. Every calculation runs in your browser. The only data that leaves your browser is a license key when you press Verify key on a Pro purchase — and even that is only the key, never your schedule. Your saved projects live in your browser’s localStorage and can be exported to JSON at any time.

Can I use the output in a delay notice or a contractual claim?

You can use it to prepare a delay notice, because it gives you a defensible first estimate of the slip and the recovery cost. You should not use it as the sole evidence in a contractual claim. A formal claim requires a fully resource-loaded, properly baselined schedule run through Primavera P6 or equivalent, plus a forensic time-impact analysis. The calculator is a planning and communication tool, not a contractual one.

How do I save my work between sessions?

Your work saves automatically to your browser’s local storage on every keystroke. To move a project to another computer or share it with a colleague, use Save project (JSON) to download a file, then Load project on the other machine. JSON files are plain text and can be stored in version control if you want an audit trail.

How does the calculator fit alongside AISC, ASCE, or Eurocode compliance?

The calculator is schedule-focused, not code-compliant by itself. It is used around compliance work: verifying that the schedule of a code-compliant design still meets a contractual milestone, testing the recovery cost of a design-review delay, or quantifying the schedule impact of a code-mandated hold point. It does not replace any structural, seismic, or geotechnical compliance check.

Related AlamToolKit tools

Critical path method, explained

Forward pass, backward pass, float — with worked numbers for each step.

Total float vs free float

Why two float figures disagree, and which one to plan with.

Project cost overrun calculator

Turn recovered days into money at risk, and compare against liquidated damages.

How to write a delay notice

Structure, evidence, and tone that survives contractual scrutiny.

---

AlamToolKit.com — free project controls tools for engineers and planners. All calculations run in your browser; no schedule data is uploaded, stored on a server, or shared. Results are indicative and should not be relied on as a substitute for professional scheduling software or a forensic delay assessment. © 2026 AlamToolKit.com