Scheduling: task networks, the critical path, and tracking

The thinking move: a schedule is a claim about dependency, not about diligence

When a project is late, the instinctive explanation is that people were not working hard enough. Almost always the real explanation is structural: some chain of tasks had no slack in it, one link in that chain moved, and every date after it moved with it. A schedule exists to make that chain visible before it moves. Everything in this lesson serves that one purpose, and the exam questions in this area are all versions of "which artefact shows you what?".

Software scheduling has seven governing principles, and they are worth knowing by name because each one is a distinct way schedules fail. Compartmentalization — decompose product and process until you have manageable tasks. Interdependency — determine which tasks must follow which and which can run in parallel. Time allocation — give every task work units and a start and a finish date. Effort validation — never schedule more concurrent effort than you have people; three engineers cannot deliver seven concurrent half-person-day tasks in a day, however good the plan looks. Defined responsibilities — every task is assigned to a named person. Defined outcomes — every task produces a work product. Defined milestones — every task or group of tasks ends at a milestone, and a milestone is only reached when its work products have been reviewed and approved, which is what stops "ninety per cent done" from lasting three weeks.

People and effort are not interchangeable

The most quotable result in project management is that adding people to a late project makes it later, and the marks are in the mechanism, not the slogan. New people must learn the system, and the only people who can teach them are the people currently doing the work — so during the handover, output does not merely fail to increase, it falls. On top of that, every added person multiplies communication paths, and each path costs real time. Schedules are somewhat elastic: you can compress a delivery date by adding resources, but the effort required rises non-linearly as you push the date earlier, and past a certain point no amount of resource buys any more compression. If you must add people late, give them work that is highly compartmentalized — a task with few dependencies and a defined outcome — because that is the only kind of work that does not require teaching the whole system first.

From WBS to task network to critical path

The work breakdown structure is the decomposition: the project's tasks, named and sized. The task network (or activity network) takes those tasks and draws the dependency between them — an arrow from a task to every task that cannot start until it finishes. Once the network exists, the critical path falls out of it mechanically: it is the chain of tasks whose total duration determines the project's duration. Every task on it has zero slack, meaning a day lost on any of them is a day lost on the delivery date. Tasks off the critical path have slack, and slack is a resource — it is where you can absorb a surprise without moving the end date.

This is why "everything is critical" is not a statement of urgency but a confession that the network has not been built. If every task were critical there would be no slack anywhere, and the only management action available would be to work harder.

The time-line chart, and what it cannot show

A time-line chart — a Gantt chart — takes the same WBS and lays the tasks along a calendar as bars, with milestones marked and resources assigned. It answers a different question: not what determines the end date but who is doing what, this week. It is the better artefact for a status meeting, for spotting an overloaded person, and for talking to a stakeholder. What it structurally cannot show is dependency. A Gantt chart of a project whose critical path is slipping looks exactly like a Gantt chart of a healthy project, right up to the moment the bars stop lining up.

Tracking: how you find out early

Tracking is how the schedule stays true, and it is several overlapping techniques used together: periodic status meetings; evaluating the results of every technical review; checking whether formal milestones were reached on their dates; comparing each task's actual start date against its planned start date, which is the earliest reliable signal of slippage and the one most teams ignore; informal conversations that surface what people will not say in a meeting; and, on an agile team, velocity. Under real deadline pressure, time-boxing is the control of last resort: put a box around each task, and when its boundary is reached, work stops and the next task begins with the remainder deferred to the next increment. It works because by the boundary most of the task is done, so the project keeps moving instead of becoming stuck.

Earned value analysis: a number for how far along we actually are

Every tracking technique above is qualitative — a meeting, a review, a date compared with a date. Earned value analysis (EVA) is the quantitative one. It treats each task’s budgeted effort as the value that task is worth, then asks how much of that value the project has actually banked.

Four quantities do all the work, and each is measured in the same unit — person-hours, person-weeks, whatever the plan was costed in.

• BCWS, the budgeted cost of work scheduled: the planned effort of every task the schedule says should be finished by this date. It is what the plan promised.
• BAC, the budget at completion: the BCWS of the entire project, which is to say the total planned effort.
• BCWP, the budgeted cost of work performed: the planned effort of the tasks that are actually finished. This is the earned value the technique is named after — and note carefully that it is priced at the budgeted rate, not at what the work really cost.
• ACWP, the actual cost of work performed: the effort genuinely expended on that completed work.

From those you compute two indices, and both are ratios centred on 1.0.

• SPI = BCWP / BCWS, the schedule performance index. Of the value the plan said we would have banked by now, what fraction do we hold? Below 1.0 means behind schedule, and the shortfall is the size of the problem, not merely its existence.
• CPI = BCWP / ACWP, the cost performance index. For every unit of effort actually spent, how much budgeted value came back? Below 1.0 means the work is costing more than it was priced at.

Their subtractive twins are sometimes wanted too: the schedule variance SV = BCWP − BCWS and the cost variance CV = BCWP − ACWP say the same things in absolute effort rather than as a ratio. Two progress percentages complete the set: percent scheduled for completion = BCWS / BAC, and percent complete = BCWP / BAC. The gap between those two numbers is the schedule slippage.

The reason this matters for the exam is the contrast with a milestone review. A milestone is binary: reached, or not reached. That tells you a problem exists but says nothing about its size, nothing about cost, and nothing about partial progress on tasks genuinely underway. EVA answers all three, using numbers the plan already contains — no new estimation is required.

Worked example — BorrowBox release 1

Release 1 decomposes into five schedulable tasks: the reservation API (4 weeks), the locker driver built against the vendor SDK (6 weeks), the mobile UI (4 weeks), wire-up and smoke testing (2 weeks, needing all three), and a field trial on bank 1 (4 weeks, needing wire-up). Three paths run through the network. Through the API: 4 + 2 + 4 = 10 weeks. Through the UI: 4 + 2 + 4 = 10 weeks. Through the locker driver: 6 + 2 + 4 = 12 weeks. So the critical path is driver → wire-up → field trial, the API and the UI each carry two weeks of slack, and the release is twelve weeks long because of one task.

That conclusion changes decisions. It says the integration developer is the person who must not be interrupted, that the two weeks of slack on the UI are the right place to absorb a usability finding, and that if the vendor SDK is late the whole release moves — which is exactly the risk the next two lessons make into a table row and then a plan. Now look at the same twelve weeks as a Gantt chart. Every bar is populated, nobody is overloaded, the UI has been started late to use its slack, and the picture looks entirely healthy. Nothing in it tells you that one of those five bars is the release date and the other four are not.

Now run earned value on the same plan. The five tasks are costed at 4, 6, 4, 2 and 4 person-weeks, so BAC = 20. At the end of week 6 the schedule says the API (4) and the locker driver (6) should both be finished, so BCWS = 10. In reality the API is done and the driver is about two-thirds built, so the budgeted value actually banked is 4 + 4 = BCWP = 8, while the team has burned ACWP = 11 person-weeks getting there. That gives SPI = 8 / 10 = 0.80 and CPI = 8 / 11 = 0.73: the project has earned four-fifths of the value it planned to earn by now, and each person-week spent is returning about three-quarters of a person-week of budgeted value. Percent complete is 8 / 20 = 40% against 10 / 20 = 50% scheduled. Compare what a milestone review would have said on the same day: the milestone locker driver complete was missed. True, and nearly useless — it does not say the slip is twenty per cent, it does not say the work is also running a third over cost, and it gives the finished API no credit at all.