c

c



 
 

ARROW LOGIC DIAGRAMS

The heart of any activity-on-arrow system Is the arrow diagram or 'network', itself. This differs from the more
familiar Gantt chart In several important respects. Arrow diagrams, in common with all other network
methods, are not drawn to scale. Every network is, however, constructed with careful thought to show as
accurately as possible the logical relationships and interdependence of each activity or task with all the other
activities in the project. Indeed, it is for this reason that networks are sometimes called 'logic diagrams'.

ACTIVITIES AND EVENT S IN ARROW DIAGRAMS

Figure 1 shows a very simple arrow diagram. Each circle represents an event in the project. An event might he
the start of a project, the start of an activity (or task), the completion of a task or the end of a project. The
arrow joining any two events represents the activity, task or time delay that must take place before the second
event can be declared as achieved. Events are usually shared between tasks, so that a single event might signal
the completion of one or more tasks and the start of one or several more tasks. In Figure 1 it can be seen that
that 10 events are linked by 11 activities.



DIRECTION

By convention, activity arrows arc always drawn from left to right. This means that the arrowheads are not
strictly necessary and could be omitted. However, when a network Is altered or when space is limited It might
be Impossible to avoid drawing an arrow vertically or even from right to left. In those exceptional cases the
arrowheads must be shown so that there can be no ambiguity about the direction of any arrow.

SCALE

Unlike Gantt charts, network diagrams are not usually drawn to any scale. The length of the arrows and size of
the event circles have no significance whatsoever.

IDENTIFICATION NUMBE RS IN ARROW DIAGRAMS

The numbers written in the event circles are identifier codes that label the events: they allow the events and
their associated activities to be referred to without ambiguity. In Figure 1 the arrow from event 1 to event 2,
for example, can be described as activity 1,2 or 1-2, This labeling is convenient for all arrow networks and is
essential for anyone who still has software capable of processing arrow networks.

LOGICAL ACTIVITY DEP ENDENCIES AND CONSTR AINTS IN ARROW DIAGRAMS

In any arrow diagram, no event can be considered as achieved until all the activities leading into it have been
finished. Activities leading out of an event must wait for that event to be achieved before they can start. This
can be demonstrated by reference to Figure 1. Event 9 cannot be considered as being reached or achieved until
all three activities leading into it from the left have been achieved. Only when event 9 has been achieved, and
not before, can activity 9-10 start. Similarly, activities 2 -3, 2-4 and 2-5 must all wait until activity 1-2 has been
finished before they can start.

Now, applying the arrow diagram method to an everyday project, suppose you want to plant a tree. If you were
misguided enough to consider an arrow diagram necessary (or this simple project, the result would look
something like the sequence shown in Figure 2. The interdependence of activities Is clear In this case, and only
one sequence Is possible. The tree cannot be placed in the hole Mba the hole has been dug, and there would
be little point in filling In the hole before putting the tree Into It.



ACTIVITY DURATION ES TIMATES AND DESCRIP TIONS

One of the most important tasks in any planning operation is to estimate how long each task will take. This is
an estimate in units of elapsed time, not necessarily connected with man-hours or other units of work.
Estimates for the duration of each activity have been made for the simple tree project, as follows:

Activity Description Estimated duration

1-2 Dig the hole 20 minutes

2-3 Position the tree 1 minute

3-4 Fill the hole 5 minutes

Noone needs network analysis to realize that this project is going to take a minimum of 26 minutes to
complete. Notice, however, that the estimated duration for each arrow Is written above Us arrow.
The description of each activity (or task) Is written below its arrow. Space Is limited in all network diagrams and
In subsequent computer reports, so planners must become adept at describing tasks In the least possible
number of words.

The estimated achievement time for each event (written above the event circle) Is calculated by adding up the
estimated durations of all the preceding activities from left to right along the arrow path. These event times arc
the earliest possible times by which the events can be achieved.

DUMMY ACTIVITIES

The network in Figure 3 represents a slightly more complex project (shown here without its activity
descriptions). Now the configuration is actually seen to be a network of activities, and run just a simple
straight-line sequence. As in all project networks, there Is more than one path through the arrows from project
start to finish. In this example there are three possible routes to the final event 6, one of which flows through
the dummy activity arrow linking event 4 to event 3.

Dummy activities (called dummies for short) do not represent actual work and almost always have zero
duration. Rather, they denote a constraint or line of dependence between different activities. In Figure 3,
therefore, the start of activity 3-6 is dependent not only upon completion of activity 2-3, but it must also await
completion of activity 1-4. Alternatively expressed, activity 3-6 cannot start until events 3 and 4 have both been
achieved.The arrows for dummy activities arc always drawn with dotted or broken lines.

PROBLEM SITUATIONS:

—Y Two simultaneous tasks start and end at the same events. Solution: Use a dummy and an extra event
to separate them. In Figure 1, event 2 and the dummy between 2 and 3 have been added to
separate tasks A and B.

—Y Task C cannot start until both tasks A and B are complete; a fourth task, D, cannot start until A is
complete, but need not wait for B. (See Figure 2.) Solution: Use a dummy between the end of task
A and the beginning of task C.

—Y A second task can be started before part of a first task is done. Solution: Add an extra event where the
second task can begin and use multiple arrows to break the first task into two subtasks. In Figure
3, event 2 was added, splitting task A.

Dummy separating simultaneous tasks

Dummy keeping sequence correct

Using an extra event

TIME ANALYSTS WITH A RROW NETWORKS



TIME UNITS FOR ACTIV ITY DURATIONS

In Figure 3 (as in the simple tree project) numbers have been written above the activity arrows to show their
estimated durations. Planners should always choose these time units according to their suability for the
project. In the tree project, minutes were the most appropriate unit of time. Days or weeks are most often
used in practice for project plans, and weeks have been chosen for this example. The best computer programs
will accept any unit of time from minutes to years.

Some computer programs allow different units of time to be mixed in the same project network but I cannot
ncommoid this practice. Mixing time units In the same network can lead to some wry peculiar results and
messy tabulations when the computer prints out the results. Best practice has always been that the planner
chooses a suitable tinil and uses it consistently throughout the network.

FORWARD PASS THROUGH THE NETWORK

In the project network of Figure 3, the earliest possible time for each event and the earliest possible time for
project completion at event 6 have been calculated by adding activity duration estimates along the arrows
from left to right. This is always the first step In the full lime analysis of any network and is known as the
forward pass.

The forward pass process Is more complicated In this case than it was In the simple tree project because there
is more than one possible path through the network. The earliest time indicated for each event might appear
to depend on which path is followed, but only the longest preceding path will give the correct result. The
earliest possible completion time for event 3, for instance, might seem to be 1 + 2 ’ 3, if the path through
events 1, 2 and 3 is taken. Event 3 cannot really be achieved, however, until the end of week 5 because of the
longer path through the dummy, lit is also means that the earliest possible start time for activity 3-6 is the end
of week 5 (or, for more practical purposes, the beginning of week 6).
Thus the earliest possible time for any event is found by adding the estimated durations of all preceding
activities along the path that produces the greatest time. By following this procedure through the network to
the end of the project at event 6 it emerges that the earliest possible project completion time is estimated as
nine weeks.