Dependencies, Slack & the Critical Path You Can Maintain
Most project plans are a list of tasks with dates typed next to them, which is a wish rather than a schedule. What dependencies actually buy you, how slack tells you which delays matter, and the honest limits of a critical path computed from your own task graph.
A project falls behind one task at a time, and the reason nobody notices is that most delays genuinely do not matter. The signage arriving four days late is fine. The slab pour slipping by one day moves the handover date. From a list of forty tasks with dates beside them, the two look identical — both are red, both generate a message in a group chat, and both get the same amount of attention.
Distinguishing between them is the entire practical value of scheduling, and it requires exactly one thing your task list probably does not have: a statement of what depends on what.
A date is not a schedule
Typing a due date on a task records an intention. It does not record why that date was chosen, so when reality moves — and it always does — nothing else moves with it. Every subsequent date has to be re-thought by a human, which in practice means they are not re-thought at all and the plan drifts out of contact with the work.
A dependency records the reason. "Plastering cannot start until the wiring is inspected" is a fact about the work rather than about the calendar, and it stays true when the calendar changes. That is the difference between a plan that survives its first week and one that becomes a document people stop opening.
Dates typed on tasks
- Every delay looks equally serious
- Knock-on effects live in the project manager's head
- Re-planning means re-typing forty dates
- The plan is abandoned by week three
- Nobody can say what the delay costs in end date
Dependencies between tasks
- Delays sort themselves into serious and survivable
- The chain is explicit and shared
- Re-planning is a conversation about one link
- The plan stays usable because it stays true
- The end-date impact of a slip is visible
Slack is the number to manage
Once dependencies exist, the arithmetic gives you something no task list can: how much each task can slip before it moves the end of the project. That is slack, and it is computed by working forwards through the chain to find the earliest each task could start and finish, then backwards to find the latest it could without pushing anything.
Tasks with zero slack form the critical path. Everything on it moves the project when it moves. Everything off it has a cushion, and knowing the size of that cushion is what lets a manager say "yes, that is late, and it does not matter this week" with confidence rather than optimism.
Two delays, one week, very different consequences
Illustrative. The point is not that Task B does not matter — it will matter once its slack is used up. It is that a project manager has a fixed amount of attention, and without slack they spend half of it on delays that were never going to move the date.
Every project manager has a fixed amount of attention. Without slack, half of it goes to delays that were never going to move the date.
Milestones are for other people
Dependencies and slack are working instruments for the person running the project. Milestones are a different tool with a different audience: the client, the funder, the board, the person who wants to know whether things are on track without reading forty task rows.
The discipline that makes milestones useful is keeping them few and making them verifiable. "Design complete" is a milestone if there is a signed document behind it. "Making good progress on design" is a status update wearing a milestone's clothing. Five or six per project is usually the right number — enough to show shape, few enough that each one means something when it is hit or missed.
Milestones and payment
Where payment is tied to milestones — common in construction and consulting alike — the milestone is a commercial event, not just a progress marker. That makes the evidence behind it worth more attention: what exactly constitutes completion, who confirms it, and what document proves it. A milestone that is ambiguous is an invoice that will be argued about.
Keeping the graph honest
A dependency graph decays in a specific and predictable way. People add dependencies enthusiastically at the start, then stop maintaining them once the work is underway, and within a month the schedule describes a project that no longer exists.
-
Only record dependencies that are real
The test is whether the second task is genuinely impossible before the first finishes. "We would prefer to do them in this order" is a preference, and preferences recorded as dependencies produce an artificially long critical path that everybody learns to ignore.
-
Keep durations honest, not optimistic
The schedule is arithmetic over durations. Optimistic durations produce a confident schedule that is wrong from day one, and the arithmetic cannot save you from your own inputs.
-
Update on completion, not at the review meeting
A task marked complete three days after it was is three days of false slack for everything downstream. This is the single most common cause of a schedule that looks fine until it suddenly does not.
-
Re-read the critical path weekly
It moves. As tasks complete and others slip, a chain that had comfortable slack becomes the one that matters — and the whole point is knowing that before, rather than after.
What we do and do not do
What AWRA OpsHub does today
- Finish-to-start dependencies between tasks, with cycles guarded at the point of creation.
- A computed critical path — a forward pass for earliest start and finish, a backward pass for latest, and slack as the difference.
- Slack per task, so the delays that matter are distinguishable from the ones that do not.
- Milestones per project with due dates, status and ordering.
- Sprints with metrics, for teams that work in iterations rather than to a fixed plan.
- Recurring tasks and project cloning, so a repeatable programme is set up once rather than rebuilt each time.
What it does not do
- Finish-to-start only. Start-to-start, finish-to-finish and lag or lead times are not part of the dependency model, which matters if your planning practice relies on them.
- Day offsets, not calendar dates. The computation works in relative days from the project's earliest task — enough to identify the critical path and slack, not a calendar-accurate scheduler that understands weekends and public holidays.
- No resource levelling. Nothing checks whether the same person is on the critical path of three tasks at once, which is the most common real-world cause of a schedule failing.
- No automatic rescheduling. A slipped task does not push its successors' dates; the arithmetic tells you the impact, and moving the plan is a human decision.
The second and third limits are the ones to weigh honestly. If you need a calendar-accurate, resource-levelled plan for a large contract programme, this is a decision-support layer rather than a replacement for a dedicated planning tool — and we would rather you knew that during evaluation.
The dependency nobody records
One last thing, because it is where most Kenyan projects actually slip and it is not in any task graph: procurement lead time. The wiring cannot be inspected until the cable arrives, and the cable is a purchase order raised six weeks ago against a supplier who has not acknowledged it.
The practical fix is to make material delivery a task in its own right, with a duration equal to the honest lead time, and to hang the work that needs it off that task. It feels artificial for a week and then it starts predicting your delays, because the plan finally contains the thing that actually causes them. Costs following the same route are covered in charging costs to the right job.
Our take
Record only genuine dependencies, keep durations honest, mark tasks complete when they complete, and read the critical path weekly. Then add material lead times as tasks — that single habit converts a schedule from a document you defend into one that warns you, which is the only useful kind.
See project planning in AWRA OpsHub
Task dependencies with a computed critical path and slack, milestones, sprints, recurring tasks and project cloning.
Explore project planningFrequently asked questions
What kinds of dependency are supported?
Finish-to-start — the successor cannot begin until the predecessor completes — with cycles guarded when a dependency is created. Start-to-start, finish-to-finish and lag or lead times are not modelled. For most operational and delivery projects finish-to-start covers the real constraints; if your planning practice depends on overlapping relationships or explicit lags, weigh that during evaluation rather than after.
Does the critical path account for weekends and public holidays?
No. The computation works in relative day offsets from the project's earliest task rather than in calendar dates, which is enough to identify the critical path and the slack on every task but is not a calendar-accurate schedule. Read it as "this chain has no room and that one has eleven days" rather than as a promise about a specific Thursday.
What happens when a task on the critical path slips?
The arithmetic shows you the consequence; nothing reschedules automatically. Successor dates are not pushed for you, which is deliberate — an automatic cascade tends to produce a plan that is technically consistent and commercially impossible, because the real response to a slip is usually resequencing, adding resource or renegotiating, not sliding everything right. The value is in seeing the impact immediately and deciding.
Will it warn us if one person is on three critical tasks at once?
No — there is no resource levelling, and this is worth stating plainly because over-allocated people are the most common reason real schedules fail. The graph knows what depends on what, not who has capacity. In practice the workable discipline is a weekly look at assignments on critical-path tasks specifically, which is a short list by definition.
How many milestones should a project have?
Five or six for most projects. Milestones exist for the people who will not read the task list — the client, the funder, the board — and their value comes from being few and verifiable. Each one should have something behind it that proves completion: a signed document, an inspection, a delivery. Where payment is tied to a milestone, define completion precisely in advance, because an ambiguous milestone is an invoice somebody will argue about.
