Every project starts with a schedule and very few finish on one. The usual explanation points at the site — a late supplier, weather, a permit that took three weeks longer than promised. But the real damage shows up somewhere else: in a schedule that has no way to translate a two-week delay on one activity into a new handover date. The activities sit side by side with no logic between them, so the finish date on paper holds perfectly still while the reality underneath it moves.
Key takeaways
- A schedule is a network of logic, not a list of dates: if moving one activity moves nothing else, what you have is a drawing of a schedule.
- The critical path is a calculated result, not a manual label — a forward pass gives early dates, a backward pass gives late dates, and the gap between them is total float. Zero float is what makes an activity critical.
- The number that runs your week is float, not the critical flag: an activity with 12 days of float can slip 11 days for free, and becomes the problem on day 13.
- A schedule that calls every activity critical carries no information at all — criticality that includes everyone is identical to no criticality.
- Without a saved baseline you cannot prove what slipped: the live schedule rewrites itself with every update, and an extension-of-time claim is built from the gap between an approved plan and a documented reality.
A bar chart is not a schedule
Most site schedules begin life as one bar per activity, with a start and a finish typed in by hand. It looks convincing — coloured bars, phases, a handover date at the end of the page. Then excavation runs two weeks late, its bar gets dragged, and nothing else moves: not the foundations, not the structure, not the handover date. The file has no idea the activities are connected, because nobody ever told it they were.
What turns the drawing into a schedule is the logic: a statement that this activity cannot start until that one finishes, and that a third can run alongside both. Once that logic is recorded, the finish date is derived from the network rather than typed beside it — and that alone is enough to make the date move on its own when something early slips.
The four dependency types, and the lag everyone forgets
Finish-to-Start is the one everybody knows: painting does not start until plastering is done. Relying on it alone forces the planner to sequence everything end to end, while half the work on a real site overlaps. The four types exist because they describe what actually happens out there:
| Type | Constraint | Site example |
|---|---|---|
| Finish-to-Start (FS) | The successor cannot start until the predecessor finishes | Foundations cannot pour until excavation is complete |
| Start-to-Start (SS) | The successor cannot start until the predecessor starts | Pipe rough-in starts two days after blockwork starts |
| Finish-to-Finish (FF) | The successor cannot finish until the predecessor finishes | Electrical inspection cannot close before the wiring does |
| Start-to-Finish (SF) | The successor cannot finish until the predecessor starts | Temporary power cannot end before permanent power is energised |
Then there is lag: two days, or seven, between two activities where nobody works but the wait is mandatory. Seven days of concrete curing is not an activity you assign to anyone, yet it is seven real days in the schedule — recorded as a lag on the relationship itself. A negative value is a lead: start the electrical rough-in three days before blockwork finishes.
The critical path is a calculation, not a label
Once the relationships are recorded, the critical path stops being an opinion. It is computed with two passes over the network, and the output is a number per activity:
Forward pass: the earliest anything can happen
Working from the project start, each activity gets an early start (ES) — the largest constraint its predecessors impose — and an early finish (EF = ES + duration).
Backward pass: the latest it may happen
Working back from the project finish, each activity gets a late finish (LF) — the latest it can end without delaying the project — and a late start (LS = LF − duration).
Total float: the gap between them
Total float = LS − ES. It is the number of days the activity can slip before the handover date moves at all.
Critical: whatever has zero float
Activities with zero total float form the critical path — one day late on any of them is one day late on the project.
| Activity | Duration | Total float | What it means this week |
|---|---|---|---|
| Excavation | 10 days | 0 | Critical — a day lost is a day lost on handover |
| Foundations | 14 days | 0 | Critical — no margin whatsoever |
| Boundary wall | 6 days | 12 days | Can slip 12 days for free; on day 13 it becomes critical |
| Guard house | 4 days | 28 days | Wide margin — safe to defer and release a crew onto the critical path |
The number a project manager actually runs their week on is float, not the critical flag. The boundary wall with 12 days of float is not a problem today, and is a problem on day 13 — a schedule that shows float tells you exactly when, while a schedule that shows a binary label says "no" right up until it suddenly says "yes".
When everything is critical, nothing is
There is a failure mode in scheduling tools worth naming, because it passes unnoticed: flagging every activity that has a due date as being on the critical path. The screen looks entirely correct — red bars, warnings, a list of critical activities — and carries zero information. A manager looking at forty critical activities cannot prioritise between them, so they fall back on ranking by instinct, which is precisely what the schedule was supposed to replace.
On a project whose logic is built properly, the critical path is a minority of the activities — commonly 10% to 20% of them. If your schedule says otherwise, either the network is strung end to end with no real parallel work in it, or the tool is not computing float at all.
The baseline is the only way to prove what slipped
A live schedule rewrites itself continuously: dates get updated, activities get added, durations get revised. Six months in you have exactly one schedule, perfectly consistent with reality, and no idea what it looked like on the day it was approved. That is where most extension-of-time claims die before they start — a claim is built on the gap between an approved plan and a documented reality, and if the plan has been rewritten there is no gap left to measure.
A baseline is a frozen snapshot of the schedule at a moment in time: every activity with the dates and percent complete it had then. The schedule keeps moving afterwards; the snapshot does not. Every later view can then put "planned" and "actual" on the same row.
That difference — baseline date against current date, activity by activity — is the raw material for both an extension-of-time claim and the schedule performance index (SPI) in earned value analysis. The two read the same number from opposite ends.
A schedule nobody updates is worse than no schedule
An abandoned schedule does not stay neutral, it turns misleading. A manager reading a three-week-old percent complete makes a decision about a situation that no longer exists, which is worse than reading nothing and phoning the site. So the practical question in scheduling is never "which planning tool?" — it is "who enters progress, when, and at what cost to their day?".
- Site engineer or foreman: percent complete on the activities they run, from a phone, at the end of the day.
- The daily report: weather, crews, equipment and obstructions — the record that later explains why a specific activity slipped.
- Project manager: the logic, the durations and the baseline. Those are planning decisions, not data entry.
- Finance: actual cost against planned, because schedule slippage and cost overrun usually surface together.
One operational condition governs all of it: the entry has to work with no signal. An update that needs a stable connection does not happen on the third floor of a concrete frame — it gets deferred to the office, then to tomorrow, then written from memory on Thursday.
How this works in muqawil
Scheduling in muqawil is built on the network rather than the bars: tasks carry a start and finish or a duration in days, they get linked by dependencies, and the critical path is computed from the network itself every time the view is opened.
- All four dependency types (FS, SS, FF, SF), each with a lag — or a negative lead — in days.
- A full critical-path calculation: forward pass, backward pass, total float, and criticality meaning zero float rather than "has a date".
- Network-computed dates shown alongside the planned ones, so adding a dependency genuinely moves the bar.
- Named bilingual baselines, compared against the current schedule task by task in the same view.
- Three guards on every link: no task depends on itself, none links across projects, and no cycle can close in the network.
- Progress entered from the field and working offline, syncing itself once the connection comes back.
Frequently asked questions
How is the critical path different from the longest list of activities?
The critical path is the longest chain of logically linked activities from start to finish, not the longest list. A very long activity with 30 days of float is not critical, and a two-day activity with no float is.
Do I have to enter a start and a finish date for every task?
No. A duration in days plus the dependencies is enough — the network derives the start from the predecessors and lays the task out for its duration. Entering both ends by hand is useful for tasks pinned by an external date, like a site handover or a permit.
Can a task depend on a task in another project?
No. A dependency only has meaning inside one project; linking across two would pull dates from a foreign schedule into this project's critical path, so it is refused explicitly.
If we revise the schedule after taking a baseline, is the baseline lost?
No. A baseline is an independent snapshot stored with its own name and date; editing the schedule afterwards does not touch it, which is the entire point of taking one.
How many baselines should a project have?
One at the original approval, then one after each formally approved extension of time. Taking a fresh baseline every time the project slips erases the evidence of the slippage — which is exactly what removes the basis for a claim.
Does the critical path replace the schedule performance index (SPI)?
No, they answer different questions. The critical path says which activities move the handover date if they slip; SPI says whether the project as a whole is ahead of or behind its plan in value terms. They are read together, not instead of one another.
Make your schedule move when the site moves
Link your project tasks with real dependencies in muqawil, save a baseline, and let the critical path be calculated instead of guessed.