D1 4.1, D1 4.2 - Activity networks

D1 4.1, D1 4.2 - Activity networks

D1 4.1 turns a project's immediate-predecessor table into an activity-on-arc network, including dummy activities when needed. D1 4.2 reads the network backwards to recover its table. Both directions let you check that the model imposes exactly the intended dependencies.

Immediate-predecessor tables

If a final inspection depends on assembly, and assembly depends on cutting, must the table list both assembly and cutting before inspection? Listing the immediate dependencies is enough; the earlier ones are already enforced by the chain.

Precedence and immediate predecessors

A precedence constraint says that an activity must finish before another can start. An immediate predecessor is a directly required preceding activity, excluding earlier activities whose completion is already forced through another listed predecessor. A dash means no predecessor: the activity may start when the project starts.

All activities in a listed set must finish, not just one of them. Being available to start does not mean starting is compulsory at that moment. No resource limitation is assumed unless supplied.

Worked example 1: direct and inherited requirements

Activities A,BA,B may start immediately. CC requires AA. DD requires A,BA,B. EE requires C,DC,D. Write the immediate-predecessor table.

Plan. Enter direct requirements and leave inherited earlier activities out.

ActivityImmediate predecessors
AA—
BB—
CCAA
DDA,BA,B
EEC,DC,D

Answer. The table above. In particular EE's row is C,DC,D, not A,B,C,DA,B,C,D.

Check. Completing CC guarantees AA has finished; completing DD guarantees both A,BA,B have finished. Nothing from the full history has been lost.

Change only one requirement: DD must now wait for CC as well. This introduces an inherited dependency which changes the immediate table.

Worked example 2: removing redundant entries

Use the revised requirements, keeping EE dependent on completion of C,DC,D.

Plan. Follow the new CC-before-DD link before deciding which table entries are immediate.

CC already requires AA, so DD's immediate predecessors are B,CB,C, with AA inherited through CC. Once DD finishes, CC has finished too, so EE's only immediate predecessor is now DD.

Answer. Rows A:none,B:none,C:A,D:B,C,E:DA:\text{none}, B:\text{none}, C:A, D:B,C, E:D.

Check. Both versions still force A,B,C,DA,B,C,D before EE. The revised version additionally forces CC before DD, exactly the one new requirement.

The table represents a partial order. Independent activities may run together; their alphabetical order does not add precedence.

Activity-on-arc diagrams

In an activity-on-arc diagram the work is represented by arrows, while the vertices represent events marking completion conditions.

Activity on arc

An activity is a labelled directed arc. An event is a vertex: it occurs only when all incoming activities have finished. Every outgoing activity must wait for that event. The event itself takes no time.

Use one start and one finish event for the whole project. Draw every activity once, with a clear arrow; place the arrowhead away from the event circle so its direction remains readable. Number events consistently in a forward order. The network must have no directed cycle: a cycle would require an activity to finish before it could begin. Different valid drawings can represent the same table.

To construct a network, place independent starting activities first. Split outgoing arcs when activities share a prerequisite. Merge arcs only when all their completions are required for every outgoing activity. Finally connect all terminal work to the finish. The diagram describes dependency, not the time spent or the number of workers.

[DIAGRAM: asset_name: Activities are arcs, events are vertices; asset_slug: activity-on-arc; caption: E starts only after both C and D have finished.; description: One start event 1, A from 1 to 2, B from 1 to 3, C from 2 to 4, D from 3 to 4, E from 4 to 5. Activities appear on directed arcs, with one finish at 5.]
E starts only after both C and D have finished.

Worked example 3: joining two branches

Represent A:none,B:none,C:A,D:B,E:C,DA:\text{none}, B:\text{none}, C:A, D:B, E:C,D as an activity-on-arc network.

Plan. Build the independent branches and merge only at EE's start.

Use arcs

A:1→2,B:1→3,C:2→4,D:3→4,E:4→5.A:1\to2,\quad B:1\to3,\quad C:2\to4,\quad D:3\to4,\quad E:4\to5.

These are the arcs in the diagram. AA finishes at event 22, making CC available; BB finishes at event 33, making DD available. Event 44 waits for both C,DC,D.

Answer. The five listed arcs, with start 11 and finish 55.

Check. CC does not wait for BB, and DD does not wait for AA. Only EE has both branches as prerequisites.

Change only EE's predecessors from C,DC,D to CC. DD remains part of the project, but must no longer delay EE's start.

Worked example 4: an independent terminal activity

Construct the revised network.

Plan. Keep EE's start after CC, and move DD's finish to the project finish.

Use

A:1→2,B:1→3,C:2→4,D:3→5,E:4→5.A:1\to2,\quad B:1\to3,\quad C:2\to4,\quad D:3\to5,\quad E:4\to5.

Answer. Event 44 now depends only on CC; finish event 55 waits for both D,ED,E.

Check. EE can start while DD is still in progress, but the project cannot finish until DD has finished. Leaving D:3→4D:3\to4 would incorrectly retain DD-before-EE.

An arc list is also a precise way to specify a network: its activity label and start/end event numbers identify each connection.

Continue this lesson.

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

Create free account