The Network Diagram and the Critical Path Method
This article provides participants in the Project Management Concepts course with the basic understanding of the Network Diagram. The context of the Network Diagram is explored in the Study Group Forum and Formative Tests. In Module 3 of the PCP, larger Network Diagrams are created for real projects, using software.
Conventions used in the Network Diagram
Many modern Project Management systems incorporate the use of Network Diagrams which show each task (activity) in a box (node). (There are other ways of doing it too, but let’s not confuse the issue for now!)
The convention of putting the activity in a box and connecting the boxes with arrows is now the common standard used for the Critical Path Method.
The arrows indicate the sequence of the tasks. This task sequence is also called the activity logic.
There are many ways of drawing a Network Diagram. Project planning software such as Microsoft Project has its own default styles for the sizes and shapes of the various types of boxes and the information displayed in them, but it’s also possible to customise these attributes.
The conventions which have been used in the diagram on this page are explained in detail below.
Work Breakdown Structure (WBS)
A, B1, B2, C1.1 and so on are WBS numbers.
Each activity has a unique WBS number.
Summary tasks (tasks which have subtasks on the WBS) are preferably not included in the Network Diagram.
Regular tasks and milestones
Phone up some friends and Guest list finalised are task names.
The rectangular boxes (such as the box for D1) indicate that some work must be done. These boxes indicate ‘real’ tasks.
1d is the estimated duration of task D1. It’s an abbreviation for 1 working day.
What exactly is a ‘working day’? Let’s not worry about that for now, because you’d have to ask the person who drew up the diagram whether they meant 8 hours, whether Saturdays count as half-days and so on. For now, that level of accuracy is not important, but later on, it would be very important to know.
The hexagonal boxes (such as the box for D2) are called milestones or milestone tasks. In this diagram, though, they are not tasks in the true sense of the word, because a task is something that someone must do, and tasks take time. In other words, each task should have an estimated duration. The milestones here have no estimated duration. A milestone is simply a point in time. A milestone is just a marker telling us something about the status of the project at that point.
Lag
The text next to the arrow, FS+10d, is made up as follows:
FS means Finish to Start. D2 can start only once the D1 has finished.
In this diagram, all the tasks are linked by means of FS dependencies. However, the convention is that we don’t write in the dependency type unless there’s an exception, such as an FF dependencies (i.e. a Finish-to-Finish dependency, which requires that the tasks must finish together), or unless we want to indicate lag time. In this case, we’re allowing for 10d lag between D1 and D2. In other words, once we’ve spent a day phoning up some friends, we’re going to wait for ten days until everyone has made up their mind and confirmed whether they’re coming to the party or not. Whoever hasn’t replied with a “yes” by that point, is not on the final guest list.
The Critical Path Method
When we’re using the Critical Path Method to determine the duration of the project, the lag time must be included when we add up the durations of the activities to determine the duration of a specific path.
In this example, the duration of D1 is 1d and the duration of D2 is 0d, but the duration of this segment of the path is 11d, because it includes this waiting time. You’ll see in the diagram below that D1 and D2 are actually on the Critical Path, i.e. that sequence of activities that determines the overall duration of the project.
If we wanted to shorten the overall duration of the project, we could insist that our friends to say yes or no immediately when we invite them to a party that will be held fewer than two days from the time of the call. That would get rid of the 10d lag, but it may not result in such a nice party, because many people may not be able to come at such short notice, and the ones that can may be a bit annoyed with the whole thing. (Either that, or we’ll get only the people who have nothing else happening in their lives anyway!)
Alternatively, we could change the activity logic (the sequence of the tasks) by incorporating D1 and D2 earlier on in the project, in parallel with other tasks.
Project scheduling software such as Microsoft Project allows for many types of lag. It would not be unusual to see two tasks linked by a Start-to-Start dependency, where the lag is indicated as SS+50% (i.e., the second task should begin only once the first task is already halfway).