A project is a network whose arcs carry precedence and whose nodes carry durations, and nothing flows along it at all. A forward pass gives the earliest each activity can start, a backward pass the latest it can start without delaying the project, and the difference is slack. The activities with none form the critical path — and shortening one of them stops paying the moment a second path draws level.
Core ideas
The arithmetic is two sweeps and is over in a minute. The three ideas are about what the numbers mean and what they stop meaning as soon as you act on them.
Adding the durations up gives the time to do everything one at a time, which is not the question. The finish date is the longest chain of activities that must happen in order, and the forward pass computes it by taking a maximum at every node. On the lab's nine-activity project the durations add to 21 and the project takes 12.
An activity with slack can start late without moving the finish date. But the slack is not private: two activities on the same non-critical chain share it, and spending it on one leaves none for the other. That is why the useful object is the critical path rather than the list of critical activities — and why the lab counts distinct critical paths rather than just naming zero-slack activities.
Take a day off a critical activity and the project shortens by a day — once. Then some other chain, previously a day shorter, is the same length, and the next day off buys nothing at all. The lab draws the whole curve, and the interesting number on it is where it goes flat rather than its first step.
The material
The definitions, the two sweeps in full on a nine-activity project, then slack, then the crash curve and the case where the first day already buys nothing.
A project is a set of activities, each with a duration and a list of predecessors that must finish before it starts. For each activity: ES is the earliest start, EF = ES + d the earliest finish, LF the latest finish that does not delay the project, and LS = LF − d the latest start.
The slack of an activity is LS − ES, equivalently LF − EF. An activity with zero slack is critical: any delay to it delays the whole project.
Nothing flows here. The arcs are precedence, the numbers on the nodes are times, and the quantity being computed is a longest path rather than a cheapest one. It is on this course because it is a network with a duality reading of its own: the critical path is the certificate that the project cannot be finished sooner, in the same way that a cut certifies a flow.
Read the forward pass off the predecessors: F waits for both D and E, which finish at 7 and 10, so F starts at 10 and not at 7. The maximum is the whole of the rule. The backward pass is the mirror image: G is followed only by H, which must start by 9, so G must finish by 9 — and since G can finish at 8, it has a unit of slack.
C is critical, so shortening it by one takes the project from 12 to 11. Shorten it by two, three or four and the project stays at 11. The lab draws the curve 12, 11, 11, 11, 11 and reports that the return stopped after one unit.
The reason is on the screen at the moment it happens: with one day off C the project has two critical paths rather than one, and past that the length is held by A, G, H, I — a chain that C is not on. Every further day taken off C is spent on an activity that no longer controls the finish date.
This is the single most useful thing the method produces and it is not the critical path itself. Knowing which activity to shorten is easy; knowing when to stop shortening it, and which chain has become binding instead, is what keeps a schedule from absorbing money for nothing. The lab reports the slack of the chosen activity, what shortening it is worth, and after how many units it stops paying.
Six activities: A for 3, then two chains of two activities each, joining at F. Both chains take the same time, so the project length is 8 and every activity is critical — two distinct critical paths, A B D F and A C E F.
Shorten B by one and the project is still 8, because A C E F is untouched and still takes 8. The return stops after zero units. With parallel critical paths, shortening one activity is not enough; you have to shorten one on each path, or shorten a shared activity like A or F.
The forward pass needs an order in which every predecessor comes before its activity, and such an order exists exactly when the precedence graph has no cycle. Write A after C, B after A, C after B and there is no order at all: each of the three is waiting for one of the others. The lab names the loop rather than reporting a length, because “the project takes zero” would be a lie and “error” would not say what to fix.
Two smaller refusals are worth the same treatment. An activity waiting on something that is not in the project is refused by name, and so are two activities sharing a name. Both are typing errors, and both would otherwise produce a schedule that looks complete.
What this lesson does not do is cost anything. Real project crashing trades money for time, with a cost per day for each activity and a budget, and that is a linear programme of its own — a perfectly good one, and not this course's. What is here is the structural half: which activities can be shortened usefully at all, and for how long.
Interactive
Shortening a critical activity helps — until a second path becomes critical, and then it does nothing
Method
Order first, then forward, then backward, then subtract. Only after all four does any decision get made.
If you cannot, the precedence graph has a cycle and there is nothing to compute. Find the loop and fix the data; no amount of care with the arithmetic will help.
Start at zero for activities with none. Take the maximum, not the sum and not the most recent; an activity waiting on three others waits for the last of them. The largest EF in the project is its length.
Start at the project length for activities with none. Take the minimum: an activity feeding three others must be done in time for the earliest of them.
slack = LS − ES. Zero means critical. Then chain the critical activities together into paths — there may be more than one, and how many there are is what decides whether shortening any single activity is worth anything.
Do not assume the saving continues. Re-run the passes after each unit and watch for a second path reaching the same length; that is the moment the return stops, and it is usually much sooner than expected.
The whole schedule, then what happens when the obvious activity is shortened. Every figure is what the lab reports as the crash control is moved.
The row of path counts is the row to read. It goes from one to two and back to one, and the two is where the improvement ended: a second chain reached the same length, and one more day off C left that chain untouched.
For a rehearsal, shorten G instead. It has a unit of slack, so the first day buys nothing; the second and third then start to matter, because by then the chain through G has become the binding one. Slack is a budget that has to be spent before anything else happens.
The harder rehearsal: on the two-path project, shorten F — the activity both chains pass through. One day off F takes the project from 8 to 7, because both paths shorten together. A shared activity is worth more than a private one, and the crash curve is where that becomes a number rather than an intuition.
You should be able to order the activities, run both passes taking a maximum forwards and a minimum backwards, compute slack, list the distinct critical paths rather than just the critical activities, and find the point at which shortening a chosen activity stops reducing the project length.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.