Project Network Diagrams

Posted on 26th December, by JimYoung in Blog. Comments Off on Project Network Diagrams

A project could be described as a number of tasks that are performed in a certain sequence. A network diagram is a useful project planning tool that enables us project managers to determine and graphically illustrate this sequence of tasks and the relationships between the tasks that comprise our project. So it’s not a railway schematic diagram, but rather it’s a diagram defines project task dependencies and is a prelude to producing a schedule or Gantt chart. Such diagrams, first used in USA and Europe during the 1950’s, are referred to by a confusing variety of names:

  • – Network Chart
  • – Activity Sequence Diagram
  • – Programme Evaluation and Review Technique (PERT) Chart
  • – Critical Path Method (CPM)
  • – Dependency Network
  • – Precedence Diagram
  • – Arrow Diagram
  • – Logic Diagram


With regard to our overall “CDEF” project process chart shown below, producing a network diagram is the output at Step 8 (“Sequence Work”).  The Post-it Notes possibly used for the preparation of the Work Breakdown Structure (WBS) at Step 6 (“Identify Work”) could now be used to prepare this network diagram given the task durations determined at Step 7 (“Analyse Work”).


In particular, the network diagram helps us project managers to figure out two very important things – how long it will take to complete the project and what tasks must be completed before starting other tasks. Further, the network diagram allows us to:

  • – Present a graphic depiction of the interdependencies of project tasks
  • – Prepare a task schedule (eg, Gantt chart) confident that task dependencies are correct
  • – Consider the effects of time and resource constraints on a task or project (eg, sensitivity or “what-if” analysis)
  • – Identify critical tasks and the critical path
  • – Predict project durations
  • – Calculate task float times
  • – Identify and eliminate unnecessary tasks and dependencies.

A network diagram may be produced using the PERT formula or the Critical Path Method (CPM) when task durations can be more accurately estimated: 

1. PERT was first developed by US Navy for the Polaris missile project. The UGM-27 Polaris missile was a two-stage solid-fuel rocket nuclear-armed submarine-launched ballistic missile (SLBM) built during the Cold War by Lockheed Corporation for the United States Navy. Many new project management techniques were introduced during the Polaris missile project. These techniques included the use of the Program Evaluation and Review Technique (PERT).  This PERT weighted-average formula is particularly useful in when task durations are difficult to estimate, where:

  • – Best Estimate of Time (BET) = (O + 4ML + P)/6
  • – Optimistic Time (O) when things very occasionally go extremely well
  • – Most Likely Time (ML) when things go as normal
  • – Pessimistic Time (P) when things very occasionally go considerably wrong.


2. CPM or Critical Path Method was developed by a civilian firm, DuPont in 1956. CPM relies on a single time estimate for each task. CPM works best when time can be accurately estimated. However, the PERT formula may be used to calculate a single time for any task within the CPM.

Both tools lead to the same end – the identification of the critical path and critical tasks. The difference between these tools comes from how they treat task durations. PERT treats duration pretty much as a random variable, whereas CPM requires a single deterministic duration for each task. PERT is more appropriate for research and other pioneering projects where through various variables and lack of history it is difficult to accurately estimate task durations. So in practice we use the CPM and wherever task durations are less definitive we may apply the PERT formula in order to produce a single time estimate.

The network diagram may be drawn in two different ways:

  1. AOA or Activity on Arrow, where the arrow represents the task (activity), and the event nodes show the start and the finish of the task:


  1. AON or Activity on Node, a much more common network, where the node represents the task (activity) and the arrow merely shows the path:


Thankfully all modern scheduling software uses AON, which means we don’t need to worry about the confusing phenomenon called “dummy arrows”. For more about AOA check So armed with the tasks that comprise the project and their estimated durations we construct the AON diagram as follows:

  1. Prepare Post-it Notes or equivalent sticky notes for each task briefly describing the task and recording its estimated duration
  2. Arrange Post-its Notes into sequence according to task dependencies, but ignore resource constraints at this point in the planning process. To determine the correct sequence of the tasks we might ask three questions for each task: which task(s) must happen before this one can begin, which task(s) can be done at the same time as this task, and which task(s) should happen immediately after this task? For example, we can’t plant a tree until we’ve dug a hole
  3. Draw the network diagram
  4. Codify the tasks, if not already done when the WBS was developed
  5. Identify the network diagram critical path – the longest time route or routes through the network diagram, and will show how long a project is expected to take if the project scope does not change and everything goes according to plan.
  6. Calculate float times for non-critical tasks
  7. Insert milestones at important events.

When we draw the network diagram, keep in mind that:

  • – The length of the arrow is irrelevant
  • – Arrows normally start/finish at nodes
  • – Diagrams usually read from left to right
  • – Each task has a unique WBS identification code, otherwise tasks may now be coded from left to right, top to bottom, of the network.
  • – Common time units are used for all tasks throughout the network. We can’t mix days, weeks and months.
  • – There is only one start and one finish event node for each network.
  • – Milestones may be shown as a zero duration task or depicted with a flag:


Nodes can vary in their complexity and in this example the node contains a lot of information:


There can no looping sequences of tasks. A loop is illogical:


There must be no “dangling nodes”. This would break the rule of dependency which governs the logic of a network:


No redundant precedences. The arrow A-C is not needed:


A network should feature just the right amount of detail for the people using it. Thus, something that appears as a single sub-project in one network diagram (strategic level) may become a network diagram in its own right (tactical or operational level). Use 3M Post-it Notes or equivalent to develop the network diagram, then computerise the result for easy updating and what-if analysis.


“Critical path” is an often misunderstood term.   It dictates project duration. A critical task is on the critical path. It is critical in terms of project completion time. The critical path is simply all the tasks that determine the end date in our project schedule. If one of those tasks is late by one day, then our project end date will be extended by one day.

Our project’s critical path is important since:

  • – It tells us the shortest time in which our project can be completed.
  • – It shows us those tasks, which if delayed, will cause a delay to our entire project.
  • – It shows us those tasks that must be completed more quickly in order to accelerate project completion.

A project can have more than one critical path, and sometimes the critical path changes during project execution when actual task durations become apparent. Another term we should be familiar with is float (slack), which is the amount of time that a task can be delayed without causing a delay to subsequent tasks (free float) and project completion date (total float).  A critical task is a task with zero float, a delay to which will cause a delay to project completion time. To determine the Critical Path and conduct Critical Path Analysis, we need to:

  1. Identify all the paths through the network diagram from start node to finish node
  2. Calculate the duration of each path
  3. Identify the longest path and this is the critical path.

The following three diagrams show the relationship between a project’s Work Breakdown Structure (WBS), network diagram and Gantt chart.



To construct a network diagram, using activity on node, for making a mug of instant coffee that includes sugar and milk.


  1. Complete the Task Analysis Worksheet shown below
  2. Write each Task ID, Description and Duration on a separate Post-it Note
  3. Prepare a network diagram that observes the immediate predecessors already identified
  4. Identify the project critical path, project duration, and float times for the non-critical tasks.


Once our network diagram has been completed we can:

  1. Identify critical path
  2. Calculate project duration
  3. Calculate float times
  4. Decide how the project might be accelerated.


The solution should look something like the diagram shown below. The critical path is “START-C-H-K-L-N-O- Finish”. Task O is somewhat frivolous but recognises the need to clean the worksite before declaring our project finished. Consuming the finished product would represent the product life cycle.

Float for non-critical tasks is rather more difficult to determine. It is the time by which we can delay a task without causing a delay to the project finish date. Without scheduling software, I find the best way to determine float is to compare each non-critical path with the equivalent portion of the critical path, the time difference being the float for that path. This time difference we then assign to each task on that particular non-critical path. Phew – even I’m confused, but an example may help. Regarding the diagram below, the float for path Start-F-J-N for example is 190. To get this figure we added together the durations of Tasks F and J (10 + 10 = 20 seconds) and subtracted this from the sum of Tasks C, H, K and L durations (10 + 10 + 180 + 10 = 210 seconds). We then assign the resultant 190 seconds float to both Tasks F and J, recognising if we were to delay Task F by say 100 seconds, the float for Task J would be reduced to 90 seconds. In this example each non-critical task coincidentally has a float of 190 seconds. However, if Task J took 20 seconds, the project duration would be unaltered, but the float for Tasks F, G, E and J would be reduced to 180 seconds. Then again scheduling software will do these calculations for us.


To accelerate the project we must accelerate one or more critical tasks – usually the earlier, the longer, and the cheapest tasks to accelerate are the best candidates. There is no point in accelerating non-critical tasks in order to accelerate a project’s completion – doing so would probably only add to the cost of the project. The best candidate for acceleration in this exercise would be Task K (“Boil Water”, 180 seconds), which might be achieved by boiling only the very minimum amount of water needed, getting a faster boiling jug (eg, the Japanese Tiger PCH-G jug shown below boils water in 45 seconds), or perhaps settling for hottish water only.


While task durations measured in seconds is most unusual, the exercise does familiarise us with the principles involved. A more realistic situation would express task durations in say days or weeks as the diagram below shows, where the difference between the critical path duration (152 days) and the actual (estimated) duration (179 days) is due to weekends and statutory holidays, which for this project are not work days.


And yes a network diagram can be developed using MS Project and other scheduling software as shown below (showing two critical paths), but the whiteboard manual approach is usually much better if we wish to involve others in its preparation. it’s a useful group activity, which boosts understanding and communication, as well as facilitating important buy-in from the whole project team. Once completed we can commit the solution to software for ready updating, sensitivity analysis and conversion into a Gantt chart. To get the most out of critical path analysis, we should do the following:

  • – Regularly view the critical path.  The critical path can change from one series of tasks to another as we progress through the schedule. The critical path can change as critical tasks are completed more quickly than estimated or non-critical tasks are delayed.
  • – Closely monitor critical tasks. Any task on the critical path is a critical task. We monitor these tasks regularly to see if any of them slip. If a critical task slips, so does our project finish date.
  • – Protect yourself by viewing tasks that can slip without affecting the critical path    By default, the critical path shows the tasks that cannot slip at all or the project completion date will slip. We may want to view those tasks that currently can slip by only a day without affecting the critical path, because if they slip by more than a day, they will become critical tasks. Viewing the tasks with float helps alert us to tasks that are becoming critical.


There aren’t many disadvantages to using a network diagram, but here are a couple of points:

  1. For large and complex projects, there may be be hundreds of tasks and dependency relationships. Without softwareit can be mighty difficult managing this. To make matters worse, if the plan changes during project execution then the network diagram will have to be redrawn. Fortunately, scheduling software can handle these issues with ease, and we can also develop our network diagram to show different levels of work breakdown – strategic, tactical and operational.
  1. The validity of the diagram relies on the accuracy of the duration we assign each task. For new types of projects this duration is not well known. And associated with this concern is that we project managers are inclined to pay special attention to the tasks on the critical path. But sometimes a parallel path is almost critical and, when a delay occurs in one of the tasks, that path now becomes the sequence with the longest duration and the new critical path. In this case, our focus has been on the wrong tasks, and the project suffers a delay despite the fact that all tasks on the original critical path are on schedule.

Some further stuff

A predecessor to an task is an task that determines when work on the next task can begin. We usually minimise task dependencies to avoid delays caused by one task waiting for another to be completed. Although most tasks cannot start until their immediate predecessor task(s) is completed, in theory at least there are four possible relationships could between tasks:

  1. Finish-to-Start (FS).The predecessor must finish before the successor can start. For example, if we have two tasks, “Dig foundation” and “Pour concrete,” the “Pour concrete” task cannot begin until the “Dig foundation” task is complete.
  1. Finish-to-Finish (FF).The predecessor must finish before the successor can finish. For example, if you have two tasks, “Add wiring” and “Inspect electrical,” the “Inspect electrical” task cannot be completed until the “Add wiring” task is completed.
  1. Start-to-Start (SS).The predecessor must start before the successor can start. For example, if we have two tasks, “Pour concrete” and “Level concrete,” the “Level concrete” task cannot begin until the “Pour concrete” task begins.
  1. Start-to-Finish (SF).The predecessor must start before the successor can finish. It is the least common of task dependencies. For example, the roof trusses for our construction project are built offsite. Two of the tasks in our project are “Truss delivery” and “Assemble roof.” The “Assemble roof” task cannot be completed until the “Truss delivery” task begins.

Finish-to-Start (FS) is by far the most common relationship. It is the default dependency with all scheduling software. Also, there can be mandatory, discretionary and external task relationships:

Mandatory dependencies. These relationships must be observed if project work is to be a success. They include:

  • – Legal requirements:  laws or regulations may require that certain tasks be done before others.
  • – Procedural requirements:  organisation policies and procedures may require that certain tasks be done before others.

Hard logic. Certain processes must logically occur before others. For example, when building a house, we must pour the concrete for the foundation before we erect the frame.

Discretionary dependencies.  We may choose to establish these relationships between tasks:

  • – Quality dependencies: sometimes product quality will be more assured if tasks are completed in a certain sequence.
  • – Logical dependencies: performing certain tasks before others sometimes seems to make the most sense.
  • – Managerial choices: sometimes you make arbitrary decisions to work on certain tasks before others.

External dependencies. Starting a project task may require that a task outside the project be completed first. For example, we may need a particular piece of equipment currently being used in another project.

Practical Exercise

Here’s a more realistic exercise. Prepare the network diagram, determine project duration and enter float for each task given the following information:


If it’s 2015 and today is day one, on what calendar date would the project be completed if no work was scheduled for weekends and statutory holidays? Check the calendar for dates, weekends and statutory holidays. And check here for the answer.


Comments are closed.


My latest thoughts on Project Management and life.


My big thanks to the coronavirus lockdown that provided me with an undisturbed opportunity to put together this 104 page booklet on Earned Value...

Project Estimating Checklist

Hofstadter’s Law: “It always takes longer than you expect, even when you take into account this law.”

Hofstadter was right....

Earned Value Management Misconceptions and Limitations

Although EVM offers excellent benefits, and is undoubtedly a very clever thing, it’s not perfect. In this final chapter I’ve discussed in detail a...