## Representing lagged activities

We might come across situations where we wished to undertake two activities in parallel so long as there is a lag between the two. We might wish to document amendments to a program as it was being tested - particularly if evaluating a prototype. In such a case we could designate an activity 'test and document amendments'. This would, however, make it impossible to show amendment recording starting after testing had begun and finishing a little after the completion of testing.

Where activities can occur in parallel with a time lag between them we represent these with pairs of dummy activities as shown in Figure 6.16. Where the activities are lagged because a stage in one activity must be completed before the other may proceed, it is likely to be better to show each stage as a separate activity.

Figure 6.16 Using the ladder technique to indicate lags. 6.11 Adding the time dimension

Having created the logical network model indicating what needs to be done and the interrelationships between those activities, we are now ready to start thinking about when each activity should be undertaken.

The critical path method is concerned with two primary objectives: planning the project in such a way that it is completed as quickly as possible; and identifying later. It will finish two days after the completion of prototype testing.

Figure 6.16 Using the ladder technique to indicate lags. 6.11 Adding the time dimension those activities where a delay in their execution is likely to affect the overall end date of the project or later activities' start dates.

The method requires that for each activity we have an estimate of its duration. The network is then analysed by carrying out a forward pass, to calculate the earliest dates at which activities may commence and the project be completed, and a backward pass, to calculate the latest start dates for activities and the critical path.

In practice we would use a software application to carry out these calculations for anything but the smallest of projects. It is important, though, that we understand how the calculations are carried out in order to interpret the results correctly and understand the limitations of the method.

The description and example that follow use the small example project outlined in Table 6.1 - a project composed of eight activities whose durations have been estimated as shown in the table.

Table 6.1

An example project specification with estimated activity durations and precedence requirements

Table 6.1

Activity Â»

Duration ( weeks)

Precedents

A Hardware selection

6

B Software design

4

C Install hardware

3

A

D Code & test software

4

B

E File take-on

3

B

F Write user manuals

10

G User training

3

E,F

H Install & test system

2

There are a number of differing conventions that have been adopted for entering information on a CPM network. Typically the diagram is used to record information about the events rather than the activities - activity-based information (other than labels or descriptions) is generally held on a separate activity table.

One of the more common conventions for labelling nodes, and the one adopted here, is to divide the node circle into quadrants and use those quadrants to show the event number, the latest and earliest dates by which the event should occur, and the event slack (which will be explained later).

### Event .number

Draw an activity network using CPM conventions for the project specified in Exercise 6.3 Table 6.1. When you have completed it, compare your result with that shown in Figure 6.17.

Figure 6.17 The CPM network for the example project.

Figure 6.17 illustrates the network for the project specified in Table 6.1.

Figure 6.17 The CPM network for the example project.