Activities versus events — An activity is a task taking time and possibly workers; an event marks completion of all activities entering a node. In the required activity-on-arc model, activities are arrows and events are vertices. An arrow's direction expresses precedence, not the physical direction of a worker's travel.
Immediate predecessors — A precedence table lists only the tasks that must finish immediately before a task may start. If A precedes B and B precedes C, A is an indirect predecessor of C and need not be listed again. Do not omit a genuine separate immediate requirement or add one merely because two arrows cross in a drawing.
Constructing the network — Start independent activities from the initial event, merge required completed prerequisites at appropriate events and finish all terminal tasks at a common final event. Preserve every stated dependence and avoid introducing extra ones. Number events in a topological order: arrange prerequisite events before the events that depend on them, with arrows moving from lower to higher numbers where possible.
Dummy activities — A dummy is a directed zero-duration, zero-resource link used to express logical dependencies or distinguish activities that would otherwise share the same start and end events. Draw it dashed and label it clearly. It does not represent a real task and contributes no work hours to a worker bound.
A dependency dummy example — Let A and B start independently, C require only A and D require both A and B. Use A:1→2, B:1→3, dummy:2→3, C:2→4 and D:3→4. Event 2 releases C as soon as A finishes; event 3 waits for both A and B before D. Sending C from event 3 would incorrectly make it wait for B.
Why cycles are invalid — A directed cycle of strict prerequisites would require a task to finish before its own prerequisite chain could begin. Standard project networks must therefore be acyclic. A dummy's zero duration does not make a circular dependency valid; inspect the directions rather than the visual shape alone.
Read a network back into a table — For each activity, identify the real tasks whose completion is required at its start event, following dummy dependencies as needed. Remove merely transitive predecessors to state the immediate table. Verify the reconstructed table against the intended dependencies; a graph's visual proximity does not establish precedence.
Forward and backward passes
Earliest event times — Set the start event to time 0. For event j, e_j = max(e_i + d_ij) over all incoming activities. The maximum is needed because every incoming task must be complete. A zero-duration dummy still propagates its predecessor's time into this comparison.
Project duration — The earliest time of the common final event is the minimum completion time permitted by precedence and durations alone, assuming sufficient resources. This critical-path duration is a lower bound on a real resource-limited schedule's finish time; too few workers can force a later finish.
Latest event times — Set the final event's latest time to the required completion time, usually its earliest time for the shortest-duration analysis. Work backwards with l_i = min(l_j − d_ij) over outgoing activities. The minimum ensures no successor is delayed beyond its permitted latest event time.
The worked precedence table — Take A 3 and B4 with no predecessors; C2 and D5 immediately after A; E3 immediately after B and C; F2 immediately after D and E. Durations are in hours and each real activity initially requires one worker. Total task time is 3 + 4 + 2 + 5 + 3 + 2 = 19 hours.
A compact activity network — Use events 1 to 5 with A:1→2 duration 3, B:1→3 duration 4, C:2→3 duration 2, D:2→4 duration 5, E:3→4 duration 3 and F:4→5 duration 2. Event 3 correctly waits for both B and C; event 4 waits for D and E. No dummy is necessary for this particular table.
Forward pass in full — The earliest times are e₁ = 0, e₂ = 3, e₃ = max(4,3 + 2) = 5, e₄ = max(3 + 5,5 + 3) = 8 and e₅ = 8 + 2 = 10. Thus the precedence-limited project duration is 10 hours. Taking the minimum at a merge would wrongly allow an unfinished prerequisite.
Backward pass in full — Set l₅ = 10. Then l₄ = 8, l₃ = 5, l₂ = min(5 − 2,8 − 5) = 3 and l₁ = min(3 − 3,5 − 4) = 0. The paired earliest/latest times are (0,0), (3,3), (5,5), (8,8), (10,10), but this does not make every activity critical.Arrows carry activity labels and durations; circled numbers are events. Orange values are early/latest event times. Any uncircled line crossing is not an event. The two critical chains are A–D–F and A–C–E–F; B has one hour total float despite its endpoint events being fixed.
Activity times, float and critical paths
Earliest and latest activity times — For activity i→j of duration d, earliest start ES = e_i and earliest finish EF = e_i + d. Latest finish LF = l_j and latest start LS = l_j − d. Do not use e_j automatically as EF: the end event may also be waiting for another, later-finishing incoming activity.
Total float — Total float is TF = l_j − e_i − d = LS − ES = LF − EF. It measures the maximum delay available to that activity's start, relative to its earliest start, without delaying the project under the original precedence analysis. Delays in related activities can consume shared flexibility, so floats cannot all be used independently without checking the resulting schedule.
Float in the worked example — For B:1→3 with duration 4, ES = 0, EF = 4, LF = 5, LS = 1 and TF = 1. Every other activity has zero total float. Event 3 has equal earliest/latest time 5, yet B is noncritical because it can finish at 4 and wait one hour for C.
Critical activities — An activity is critical when its total float is zero for the specified project completion time. It must lie on a start-to-finish chain whose total duration equals the project duration in the standard acyclic analysis. Checking e_i = l_i and e_j = l_j alone is insufficient without including the activity's duration.
Multiple critical paths — The worked project has A–D–F of length 3 + 5 + 2 = 10 and A–C–E–F of length 3 + 2 + 3 + 2 = 10. Both are critical, so shortening D alone does not reduce the project below 10: the other critical chain still takes 10. A delay in either critical chain can lengthen the project.
Free float as a useful distinction — Free float, a supplementary scheduling concept, is e_j − e_i − d: delay that does not push the earliest start of a successor beyond its currently computed value. It is no greater than total float in the usual analysis. Total float is the specification's required measure; use the formula requested rather than treating every type of spare time as identical.
Recalculate after changes — If a duration or precedence relation changes, repeat both passes and recompute the critical set. For the example, increasing B from 4 to 6 makes e₃ = 6, e₄ = 9 and e₅ = 11. An activity formerly noncritical can become critical; old floats do not automatically remain valid.
Gantt charts and resource histograms
Gantt representation — A Gantt or cascade chart plots each activity against a common time axis, usually as a duration bar from its chosen start to finish. Show float separately with the required convention rather than drawing the whole float interval as working time. Bars must obey every predecessor and the project deadline.
An earliest-start chart — For the example use A[0,3), B[0,4), C[3,5), D[3,8), E[5,8), F[8,10). Here [a,b) includes start time a and excludes finish time b. This half-open interval notation counts a finishing task and a newly starting one at the same instant without double-counting their workers over a positive time interval. E starts at 5 because it waits for C as well as B.Bar positions and lengths represent the stated earliest-start schedule. B is highlighted because it has one hour total float; the coloured bar shows four hours of actual work, not five hours including float. Adjacent start/finish instants do not create a positive-duration worker overlap.
Resource histogram — At each time interval, add the worker requirements of all tasks active then. For the one-worker example, the earliest-start histogram has heights 2 on [0,3), 3 on [3,4), 2 on [4,8), and 1 on [8,10). Its area is 2×3 + 3×1 + 2×4 + 1×2 = 19 worker-hours, matching the task total.
Non-unit worker requirements — If activity i needs r_i workers for duration d_i, it contributes r_i during its active interval and r_id_i to total worker-hours. Do not sum durations alone when different requirements are given. A task needing three workers cannot be assigned to a single worker simply by drawing a narrower bar.
Resource levelling — Shift noncritical tasks within their valid float to smooth the histogram or reduce a peak without delaying the required project finish. Respect all predecessors, task durations and any stated nonpreemption requirement (a task must continue without interruption once it starts). Moving one task can alter the flexibility available to successors; recompute or check the whole schedule rather than moving bars independently.
Worker bounds and actual scheduling
The workload lower bound — For required completion time T and total worker-hours H, at least ceil(H/T) workers are needed, where ceil means round upwards to an integer, because N workers provide at most NT worker-hours. This necessary bound assumes all available time could be used effectively; precedence and simultaneous critical tasks can require more. It does not itself construct a schedule.
A bound that is not attainable — For the example, H = 19 and T = 10 give a workload lower bound of 2. Yet both C and D must start at time 3, and B must start between 0 and 1 and run for 4 hours, so B overlaps them for at least part of [3,5). At least three workers are therefore necessary to finish in 10 hours.The histogram follows A,B,C,D,E,F at earliest start with one worker each. B overlaps both critical C and D after time 3. Since B can only start between 0 and 1 and lasts 4 hours, moving it cannot eliminate all three-way overlap while preserving the ten-hour finish.
A three-worker schedule — Worker 1 can do A[0,3), C[3,5), E[5,8), F[8,10). Worker 2 does B[0,4) and worker 3 does D[3,8). Every task is assigned once, prerequisites hold, no worker has overlapping tasks and the project ends at 10. Combined with the overlap argument, this proves three is the minimum for the 10-hour deadline.
Scheduling rule and task indivisibility — Unless the question permits splitting, assign each activity as an uninterrupted block using its full required number of workers. A heuristic such as choosing an available task with least float can help construct a schedule, but its result alone does not prove minimum workers. Check the actual resource requirement of each activity, including stated specialist or multi-worker constraints.
Deadline versus resource optimum — The fewest workers for the shortest project duration is a different objective from the fewest workers with any finish time. One worker could do the six tasks in a valid sequential order taking 19 hours, but this does not meet the 10-hour requirement. State the deadline and objective before making an optimality claim.
Interpretation and limits — A critical path identifies precedence bottlenecks under fixed durations and assumed resource availability; it is not a guarantee that real work takes exactly those times. Uncertainty, breaks, skills and resource shortages need extra modelling. Submit the network, passes, activity times, floats, Gantt/histogram and a feasible worker schedule with a justified bound when requested.
Test yourself
50 questions · Random sets of 10. These quick checks support revision; practise longer explanations and justified judgements too.