7.05a–7.05c - Activity networks and critical paths

7.05a–7.05c - Activity networks and critical paths

Turn a list of jobs into an activity network, then find how quickly the whole project can finish. You will construct activity-on-arc networks in 7.05a, use forward and backward passes to find critical activities in 7.05b, and calculate total float in 7.05c.

Constructing activity networks

A gallery needs five jobs completed before an exhibition opens. Preparing the room takes 33 hours, connecting the equipment takes 44, making signs takes 22, testing takes 55, and opening checks take 11. Must this project take all 1515 hours, and could making the signs take four extra hours without delaying the opening? The order of the jobs matters as much as their lengths.

You already know

A graph has vertices and arcs joining them. A path follows consecutive arcs without repeating vertices. The connections matter, rather than the position of the drawing on the page.

Here the arcs are directed: an arrow records the order in which events must occur, and a directed path follows those arrows. Some jobs can happen together. Others have to wait: the signs require the prepared room, testing requires both the room and the equipment, and opening checks require both signs and testing. The table records only immediate predecessors: jobs which must finish before that activity can start, with no intervening activity in that dependency.

ActivityJobImmediate predecessorsDuration, hours
AAPrepare the roomnone33
BBConnect equipmentnone44
CCMake signsAA22
DDTestA,BA, B55
EEOpening checksC,DC, D11

An activity network records these dependencies without assigning workers. For now, assume enough resources for every available activity to start immediately, with fixed durations and no interruption.

Activity-on-arc network

In an activity-on-arc network, each activity is a directed arc labelled with its name and duration. A vertex represents an event: completion of all activities entering it, allowing activities leaving it to start. An event takes no time. A burst has more than one outgoing arc; a merge has more than one incoming arc. For example, the project start is a burst when AA and BB can begin together. An activity written inside a vertex is activity-on-node, which is a different representation.

Use a single start and a single finish, with all arcs directed. Numbering events so that arrows go from smaller to larger numbers helps prevent accidental directed cycles. A project cannot require a job to precede itself.

Sometimes two dependencies need to be separated. In this project DD needs both AA and BB, but CC needs only AA. Merging AA and BB before both CC and DD would wrongly make CC wait for BB.

Dummy activity

A dummy activity is a directed arc of duration 00, drawn dashed. It records a dependency and represents no actual work. It can also distinguish activities that would otherwise have the same start and finish events. For example, a dummy from the end of AA to the end of BB can make DD wait for AA while leaving CC free to follow AA alone. A dashed dummy is still an arc whose direction must be respected.

Construct from the dependencies, then read the resulting network back as a check. Use a dummy only when it carries necessary information.

Worked example 1: separating two predecessor lists

Question. Construct an activity-on-arc network for the gallery project in the table above.

Plan. Give AA and BB separate finish events, join them for DD with one dummy, then merge CC and DD before EE.

A:1⟶2(3)room starts immediatelyB:1⟶3(4)equipment starts immediatelydummy:2⟶3(0)D must also wait for AC:2⟶4(2)C needs only AD:3⟶4(5)both predecessors now completeE:4⟶5(1)merge C and D\begin{aligned} A &: 1\longrightarrow 2\quad (3) && \text{room starts immediately} \\ B &: 1\longrightarrow 3\quad (4) && \text{equipment starts immediately} \\ \text{dummy} &: 2\longrightarrow 3\quad (0) && D\text{ must also wait for }A \\ C &: 2\longrightarrow 4\quad (2) && C\text{ needs only }A \\ D &: 3\longrightarrow 4\quad (5) && \text{both predecessors now complete} \\ E &: 4\longrightarrow 5\quad (1) && \text{merge }C\text{ and }D \end{aligned}

Why this step? Event 33 can occur only after both BB and the dummy from AA have finished. Event 22 can occur after AA alone, so CC has the correct, shorter predecessor list.

Answer. The left-hand network below has exactly the required precedences and one dummy activity.

Check. Reading backwards from EE gives C,DC, D; from DD gives A,BA, B; from CC gives AA alone. There is one start, one finish and no directed cycle.

Worked example 2 changes one feature: an extra job follows testing alone. A second dummy is now needed, because the new job must not wait for the signs.

Worked example 2: separating a second merge

Question. The gallery adds activity FF, which lasts 22 hours and follows DD alone. The project is complete when both EE and FF finish. All five original activities and their dependencies are unchanged. Construct an activity network.

Plan. Keep the first dummy, separate the finish of DD from the merge of C,DC, D, and use a second dummy to carry DD's dependency into that merge.

A:1⟶2(3)room completion eventB:1⟶3(4)equipment completion eventdummy:2⟶3(0)D still needs A,BD:3⟶4(5)testing has its own finishC:2⟶5(2)signs arrive at the later mergedummy:4⟶5(0)E still needs C,DE:5⟶6(1)opening checksF:4⟶6(2)F needs D alone\begin{aligned} A &: 1\longrightarrow2\quad(3) && \text{room completion event} \\ B &: 1\longrightarrow3\quad(4) && \text{equipment completion event} \\ \text{dummy} &: 2\longrightarrow3\quad(0) && D\text{ still needs }A,B \\ D &: 3\longrightarrow4\quad(5) && \text{testing has its own finish} \\ C &: 2\longrightarrow5\quad(2) && \text{signs arrive at the later merge} \\ \text{dummy} &: 4\longrightarrow5\quad(0) && E\text{ still needs }C,D \\ E &: 5\longrightarrow6\quad(1) && \text{opening checks} \\ F &: 4\longrightarrow6\quad(2) && F\text{ needs }D\text{ alone} \end{aligned}

Why this step? Starting FF at the same merge as EE would wrongly make it depend on CC. The dummy 4→54\to5 lets EE wait for testing without making FF wait for the signs.

Answer. The right-hand network below uses exactly two directed dummy activities and has one finish at event 66.

Check. Reading immediate predecessors gives C:AC:A, D:A,BD:A,B, E:C,DE:C,D, and F:DF:D. Neither EE nor FF depends on the other, and the project waits for both.

Compare the diagrams at the second merge, where the new job needs a different predecessor list.

[DIAGRAM: asset_name: Dummies preserve different predecessor lists; asset_slug: h245_7_05_activity_construction; caption: One dummy separates the dependencies of C and D. Adding F after D alone requires a second dummy before the merge for E; description: Left panel has the original five-event gallery network with dummy 2 to 3. Right panel adds F of duration 2 and uses six events: A 1 to 2, B 1 to 3, dummy 2 to 3, D 3 to 4, C 2 to 5, dummy 4 to 5, E 5 to 6 and F 4 to 6. Both diagrams have all arcs directed, labelled real activities, dashed zero-duration dummies, a single start and a single finish]
One dummy separates the dependencies of C and D. Adding F after D alone requires a second dummy before the merge for E

A correct diagram is judged by its dependencies, not by its shape on the page.

Watch out

Wrong: merge AA and BB and then start both CC and DD. That makes CC depend on BB. Right: keep separate completion events and use a directed dummy to pass only the required dependency to DD.

Now separate both merges in a project with different activities.

Earliest times and the forward pass

At a merge, an event must wait for every incoming activity, so its earliest possible time is the latest of their finishing times.

Return to the original gallery project, with the dummy and CC lasting 22 hours. Write EiE_i for the earliest event time at vertex ii, taking the project start as time 00. The outgoing activities can start at EiE_i, so this is also their earliest start time. For example, CC can start at time 33, immediately after AA.

Forward pass

For an activity i→ji\to j of duration dijd_{ij}, its earliest completion is Ei+dijE_i+d_{ij}. Starting with E1=0E_1=0, calculate

Ej=max⁡i→j(Ei+dij)E_j=\max_{i\to j}(E_i+d_{ij})

over all arcs entering event jj, including dummies of duration 00. The earliest time at the single finish event is the minimum project completion time, assuming sufficient resources.

Not in the formula booklet: learn it.

The maximum is essential: arriving by one short route does not complete the work on the other routes.

Worked example 3: a merge waits for the later branch

Question. Carry out a forward pass for the original gallery network and determine the minimum project completion time.

Plan. Work from the start towards the finish, adding each arc's duration and taking the maximum at each merge.

E1=0startE2=0+3=3complete AE3=max⁡(0+4,3+0)=4B and the dummy must finishE4=max⁡(3+2,4+5)=9C and D must finishE5=9+1=10complete E\begin{aligned} E_1&=0 && \text{start} \\ E_2&=0+3=3 && \text{complete }A \\ E_3&=\max(0+4,3+0)=4 && B\text{ and the dummy must finish} \\ E_4&=\max(3+2,4+5)=9 && C\text{ and }D\text{ must finish} \\ E_5&=9+1=10 && \text{complete }E \end{aligned}

Why this step? Although the signs finish at time 55, testing finishes at time 99. Opening checks cannot begin until both are complete.

Answer. The earliest event times are 0,3,4,9,100,3,4,9,10. The minimum project completion time is 1010 hours.

Check. Activities B,D,EB,D,E must occur consecutively and take 4+5+1=104+5+1=10 hours, so no shorter completion time is possible.

Worked example 4 changes one duration: the signs now take 77 hours. The maximum at the merge may therefore come from a different branch.

Worked example 4: a different branch becomes the bottleneck

Question. Activity CC now takes 77 hours; all other gallery data are unchanged. Determine the new minimum project completion time by a forward pass.

Plan. Keep the early event times before CC, then recalculate from its finishing event onwards.

E1=0,E2=3,E3=4earlier activities unchangedE4=max⁡(3+7,4+5)=10compare the new finishesE5=10+1=11opening checks follow\begin{aligned} E_1=0,\quad E_2&=3,\quad E_3=4 && \text{earlier activities unchanged} \\ E_4&=\max(3+7,4+5)=10 && \text{compare the new finishes} \\ E_5&=10+1=11 && \text{opening checks follow} \end{aligned}

Why this step? The dependency structure has not changed, but the controlling branch has: CC now finishes after DD.

Answer. The project now takes at least 1111 hours.

Check. The path A,C,EA,C,E has length 3+7+1=113+7+1=11, agreeing with the finish event time.

The numbers at events belong to events, not to individual routes. Carry each number to every outgoing arc at a burst.

Continue this lesson.

You’re previewing NovaLearn without an account. Create a free account to read the rest.

Create free account