The Chain That Decides Your Finish Date
Delay one task by three days and nothing happens. Delay a different one by the same three days and the whole job finishes late. The arithmetic that separates them is not complicated — and knowing exactly what it does not account for is what stops it misleading you.
The site meeting reaches the same impasse every fortnight. Six activities are behind. Everybody agrees they are all important, everybody has a reason, and the discussion becomes a negotiation about who is most at fault rather than a decision about what to do on Monday.
The question that ends that conversation is narrow and answerable: of these six, which ones move the completion date if they slip further, and which ones have room? Two of the six probably have three weeks of float and nobody in the room knows which two.
That is what a critical path is for. It is not a scheduling philosophy — it is a piece of arithmetic that turns "everything is urgent" into a ranked list, and the arithmetic is simple enough to explain in a paragraph.
The arithmetic, in one pass each way
Given a set of tasks, each with a duration, and a set of dependencies saying which must finish before which can start, two passes produce everything you need.
-
Forward — how early can each task happen?
Walk the tasks in dependency order. A task can start as soon as every task it depends on has finished, so its earliest start is the latest of its predecessors' earliest finishes. Its earliest finish is that plus its duration. The largest earliest finish across the whole set is when the job can complete.
-
Backward — how late can each task happen?
Now walk it in reverse from that completion. A task must finish before the latest start of anything that depends on it, so its latest finish is the earliest of those. Subtract its duration and you have the latest it can start without pushing anything.
-
Subtract — that difference is the float
Latest start minus earliest start is the slack: how many days this task can slip before it costs you the completion date. Anything with no slack is on the critical path, and a day lost there is a day lost on the job.
That is the whole method. It has been used on construction projects since the late nineteen-fifties and it has not needed improving, because the logic is not the hard part — keeping the inputs honest is.
Of the six activities that are behind, two probably have three weeks of float. The meeting is about which two, and it usually has no way of finding out.
What it gives a site meeting
The output is a number per task, and three of those numbers change how a conversation goes.
| Figure | The question it answers |
|---|---|
| Slack | How long can this slip before it costs us the date? |
| On the critical path | Does a day lost here cost a day on the job? |
| Earliest start | What is the soonest this can begin, given what it waits on? |
| Latest start | When does this become urgent rather than merely late? |
The fourth row is the one that changes behaviour most, and it is the least discussed. A task with fourteen days of float is not urgent today and becomes genuinely urgent on a specific date that can be calculated. Knowing that date is the difference between a site agent who chases everything equally and one who chases the right things first.
What it does not account for
This is the important half, and it is where critical-path tooling most often misleads people — not by computing anything wrongly, but by being read as answering a question it never addressed.
- There is no calendar. Durations are counted in day offsets from the earliest task, not in dates. Weekends, public holidays and non-working days do not exist in the arithmetic, so a fifteen-day chain is fifteen working units rather than a date three weeks on Thursday.
- Every dependency is finish-to-start. A start-to-start or finish-to-finish relationship is treated the same as any other, and there is no lag or lead — you cannot say "start this three days after that finishes" and have the calculation understand it.
- No resource levelling. If four critical tasks all need the same crane in the same week, the arithmetic will happily schedule them in parallel. It knows about sequence, not about capacity.
- An undated task counts as one day. A task without both a start and a due date is given a duration of one, which quietly shortens the chain it sits on. This is the single most common way a critical path comes out wrong.
- A circular dependency does not raise an error. Tasks caught in a loop are still returned with figures attached, and those figures do not mean anything. Nothing tells you it happened.
Date every task on the critical path before you trust the answer
The undated-task behaviour is the one to check first. A single activity with no dates sitting in the middle of a chain is treated as a single day, which can make a six-week sequence appear to be four. Sort your tasks by whether they have both dates, and fix the ones on or near the chain before anyone quotes a finish date from it.
What AWRA OpsHub does today
- A genuine critical path method computation — forward pass, backward pass, slack per task, and the zero-slack chain identified.
- Computed over your actual task dependency graph, per project, with cancelled tasks excluded.
- Slack per task, so float is a number rather than an impression.
- Tasks carry a baseline due date and a variance against it, so slippage on an individual activity is measurable rather than remembered.
What it does not do
- No calendar. Results are day offsets from the earliest task, not dates. Weekends, holidays and shutdown periods are not modelled, so the arithmetic tells you the shape of the sequence rather than the day it lands on.
- No dependency types, lags or leads. Every edge is treated as finish-to-start regardless of what type is recorded against it.
- No resource levelling. Sequence is respected, capacity is not — the same crew or plant can appear on several parallel critical tasks.
- A task missing either date counts as one day, which shortens whatever chain it sits on without any warning.
- A circular dependency produces figures rather than an error. Nothing flags it, and the numbers for the tasks in the loop are not meaningful.
- No project-level programme or baseline. A project has a start and a due date, overwritten when it moves; the baseline lives on tasks, not on a contract programme with extensions of time.
Not ours, by choice
- We will not present day offsets as a contractual completion date. A programme that has to survive an extension-of-time claim needs a calendar, non-working days and a baseline that is preserved rather than overwritten, and calling this that would be a claim we cannot support.
- We will not level your resources silently. A calculation that quietly moved tasks to fit a crane you never told it about would be inventing a programme, and you would find out the difference on site.
A working calendar with non-working days, dependency types with lag and lead, and a preserved project baseline with revision history, are all scope rather than ceilings. The dependency graph, the pass arithmetic and the task-level baseline all exist and work; each addition is a written specification and a price.
The right way to use this today is as a decision aid inside the project rather than as a contract programme. It answers "which of these six do I chase on Monday" extremely well, and it does not answer "what date do I put in the letter", which is a different tool and a different conversation.
Keeping the inputs worth computing on
A critical path is only ever as good as the dependency graph beneath it, and dependency graphs decay in a predictable way. They are built carefully at the start and then the job changes, and nobody updates the arrows because updating arrows is not urgent on any particular day.
What to check before quoting a float figure
- Does every task on or near the chain have both a start and a due date? Undated tasks count as one day and shorten the sequence.
- Are the dependencies real, or aspirational? "Blockwork depends on slab" is real. "Snagging depends on the project starting" is an arrow somebody drew to make a diagram look complete.
- Is anything missing an arrow that genuinely constrains it? A missing dependency is more dangerous than a wrong one, because it produces float that does not exist.
- Have completed tasks been closed? A finished activity still shown as open drags a chain that has already been walked.
- Does any task depend on something that depends on it? A loop returns numbers without complaining, and the numbers are meaningless.
- Do the durations reflect the crew you actually have, or the crew that was assumed at tender?
The third one is worth dwelling on because it is counter-intuitive. A wrong dependency makes something look more constrained than it is, which is conservative and shows up in a meeting when somebody objects. A missing dependency makes something look freer than it is, produces float nobody questions, and is discovered when the task that was supposedly not urgent turns out to have been holding up two others.
What float is actually for
A common misuse is to treat float as spare time belonging to whoever has it. It is not. Float belongs to the project, and it is consumed by whoever uses it first.
Two tasks in the same chain sharing ten days of float do not have ten days each. If the first one takes eight of them, the second has two, and nobody told the second one. This is why float should be visible to a site agent rather than to the person doing the task — it is a resource to be allocated rather than an allowance to be spent.
It also explains the pattern where a job runs comfortably for months and then goes critical everywhere at once. The float was being consumed the whole time, quietly, by activities that each looked fine in isolation, until there was none left and every remaining task became critical simultaneously.
The costing consequence of a programme that moves is in preliminaries, the variation side in variations and claims, and the task and milestone discipline underneath all of it in BQ versus actuals.
Our take
Use it to decide what to chase on Monday, which it does well and cheaply. Before you quote any float figure, check that every task on the chain has both dates, because an undated one counts as a single day and will shorten your sequence without saying anything. And do not put a date from this into a letter — the arithmetic works in day offsets with no calendar, no non-working days and no preserved baseline, so it tells you the shape of the sequence rather than the day it lands on. Those are two different tools, and confusing them is how a useful internal figure ends up in a contractual dispute.
See the chain on your own project
Forward and backward passes over your real dependency graph, slack per task, the zero-slack chain identified, and a baseline variance on every activity.
Explore project schedulingFrequently asked questions
What does the critical path calculation actually produce?
Per task: its duration, its earliest start and finish, its latest start and finish, its slack, and whether it sits on the critical path. Slack is the number that changes site meetings — it says how many days an activity can slip before it costs you the completion date, which turns "everything is behind" into a ranked list. The latest start is the underused one: it tells you the specific date on which a task with float stops being comfortable and becomes urgent.
Does it account for weekends and public holidays?
No. The arithmetic works in day offsets from the earliest task rather than in calendar dates, so non-working days are not modelled at all. That makes it a good tool for understanding the shape of a sequence and a poor one for producing a completion date you would put in writing. Treat the output as "this chain is fifteen units long and these tasks are on it" rather than as a date, and do the calendar conversion yourself if you need one.
Why does our critical path look shorter than we expect?
Almost always because tasks on the chain are missing dates. A task without both a start and a due date is given a duration of one day, so a three-week activity with no dates entered contributes a single day to the sequence — and nothing warns you. Sort your tasks by whether both dates are present, fix the ones on or near the chain, and recompute. This is the most common way a critical path comes out wrong, and it is entirely fixable in an afternoon.
Can we set start-to-start dependencies or a lag?
Not in a way the calculation understands. A type is recorded against a dependency, but the computation reads only which task depends on which and treats every edge as finish-to-start with no lag or lead. So "start this three days after that finishes" has to be modelled by adjusting the durations or dates rather than by the relationship itself. Worth knowing before you build a graph that assumes otherwise.
What happens if we create a circular dependency?
Nothing visible, which is the problem. The tasks caught in the loop are still returned with figures attached, and those figures do not mean anything — there is no error and no flag. If a set of tasks is producing float that makes no sense, a loop is worth checking for. Ask whether anything on that chain depends, directly or through a couple of steps, on something that depends on it.
Can we use this as our contract programme?
No, and it is worth being firm about that. A contract programme needs a calendar with non-working days, a baseline that is preserved rather than overwritten when the date moves, and a record of extensions of time — none of which exist here. A project carries a start and a due date, and the due date is simply overwritten when it changes; the baseline lives on individual tasks rather than on a programme. This is a decision aid for running the job, and a contractual programme is a different instrument.
