How To Make A Network Diagram In The Project Management

What Is a Project Schedule Network Diagram?

A project schedule network diagram is an output type of the process ‘sequencing activities’ according to PMI’s Guide to the Project Management Body of Knowledge.

The order in which activities should be scheduled to address logical relationships between these activities is shown by project schedule network diagrams.

Usually, it consists of nodes for activities and arrows for dependencies and sequences. Activities on nodes (AON) diagramming is another name for this method of presentation. The project schedule network diagram of this kind is presumably the most prevalent.

The “activities on arrows” (AOA) method is a different way to present information; as the name implies, activities are shown as arrows, and nodes stand in for the logical relationships.

The precedence diagramming method, which we are describing in this article (including examples), is a way to make project schedule network diagrams. example).

Logical Relationships

The diagram is based on information about the kind of logical relationship between activities, which is frequently added to and enhanced by it. The 4 types of dependencies are

• Finish to finish (FF),
• Finish to start (FS),
• Start to start (SS), and
• Start to finish (SF).

The status that the predecessor activity must attain according to the first part of these terms before the successor activity can have the status mentioned in the second part. In a finish-to-start dependency, for example, the predecessor must have completed before the successor can begin.

Types Of Project Network Diagrams

There are two main types of network diagrams in project management: the arrow diagramming method (ADM), also known as “activity network diagram” or “activity on arrow”; and the precedence diagramming method (PDM), also known as “node network” or “activity on node.”

Arrow Diagram Method (ADM)

Arrows are used to represent project-related activities in the ADM, or activity network diagram. It’s crucial to remember that the ADM is no longer commonly used in project management due to its drawbacks. To be able to identify these diagrams should they appear in your workplace, it’s still helpful to understand ADMs.

In ADM:

• The activity’s head and tail are represented by the arrow’s tail and head, respectively.
• The duration of the activity is usually indicated by the length of the arrow.
• Each arrow connects two boxes, known as “nodes.” The beginning or conclusion of an activity in a sequence is represented by a node. The starting node of an activity is sometimes called the “i-node,” with the final node of a sequence sometimes called the “j-node.”
• The only relationship between the nodes and activity that an ADM chart can represent is “finish to start” or FS.

Occasionally, “dummy activities”—arrows that do not represent a direct relationship—need to be included in ADM network diagrams: In the diagram below, activity C can only happen after activities A and B are finished; in the network diagram, you’ve linked activity A to activity C. Maybe we’re talking about tiling a floor (activity C): It can only start once the concrete is poured (activity A) and the permits are obtained (activity B). Since activities A and B are not directly related—A doesn’t lead to B, and B doesn’t lead to A—you’ll need to draw a dummy activity between B and C to show that C is dependent on B being completed. An ADM chart also does not have a way to encapsulate lead and lag times without introducing new nodes and activities

Precedence Diagram Method (PDM)

As a more effective alternative to ADMs, PDM network diagrams are widely used in project management today. The precedence diagramming method for creating network diagrams uses boxes, or nodes, to represent each activity, with arrows serving as connections between the various activities. The arrows can therefore represent all four possible relationships:

• “Finish to Start” (FS): When an activity cannot start before another activity finishes
• “Start to Start” (SS): When two activities are able to start simultaneously
• “Finish to Finish” (FF): When two tasks need to finish together
• “Start to Finish” (SF): This is an uncommon dependency and is only used when one activity cannot finish until another activity starts

Lead times and lag times can be written next to the arrows in PDM. If a particular activity is going to require 10 days to elapse until the next activity can occur, for example, you can simply write “10 days” over the arrow representing the relationship between the connected nodes.

Why Would Someone Use A Project Network Diagram?

The sequence of tasks is created and documented using a project network diagram. It is a part of the “project schedule management” knowledge area and is used as an input for critical path method and schedule network analysis, two scheduling techniques (PMBOK®, ch. 6.5.2.1).

The discussion of sequences and dependencies in a project, as well as stakeholder communication, can also be done using this kind of diagram. To link the dependencies and sequencing of all activities to the overall project schedule and duration, however, it is frequently a fairly detailed and complex working document in larger projects. In many organizations, schedule network documents are less common than other methods of presentation (like Gantt diagrams) and a more aggregated view for communicating the project schedule.

In order to record the leads, lags, and slacks of activities, schedule network diagrams are also used. They provide the framework for determining the critical path, which is the chain of activities with the longest duration.

How To Make A Network Diagram

The list of specified activities, their estimated durations, and the logical connections between them (also known as dependencies) are pertinent inputs for the schedule network diagram.

To draw a schedule network diagram (in line with the AON method), you will need to

1. Draw a starting point,
2. Insert activities on the (future) nodes of your diagram, including details and additional data (see explanation below),
3. Connect the activities with arrows that represent the type of logical relationships (as explained in our article on the precedence diagramming method),
4. Include information about each connection, such as the kind of dependency (e.g. SS, FS), whether it is required or discretionary, leads and lags, as well as other data relevant for your scheduling, and
5. Make the diagram’s endpoint.

In the section after this, you’ll find an example.

The earliest start date and latest finish date, an activity’s criticality, and any mentions of work packages or the work breakdown structure are examples of details that are frequently added to the activities. Slack or float, also known as waiting time for activities, can also be included.

When creating your schedule network diagram using the activities-on-arrows (AOA) method, you should represent activities as arrows and dependencies as nodes.

Typically, such diagrams are produced by the scheduling software in projects where it is used to support project management. But the requirements for the input data, i.e. the list of activities, logical relationships, and leads and lags, are the same and need to be provided by the user. Following that, the program can create the diagram and decide on the best order for the various tasks.

You can also draw the diagram by hand using common office programs like Visio or PowerPoint (which we did for the example diagram below) if you don’t have the appropriate software on hand or if you work on smaller, less complicated projects.

Example Of A Schedule Network Diagram

A (simplified) set of tasks that must be organized in a project schedule network diagram and documented are introduced in this section. In our example of the precedence diagramming technique, this case study is also used in part. It is included in our PDM article along with more information on how we were able to recognize and classify the logical connections between these activities.

The IT development and implementation project in question is described in this example. Regardless of the subject matter of the project, the creation and use of a schedule network diagram is the same for all project types.

Activities and Logical Relationships

The project comprises the phases

• designing,
• developing,
• implementing,
• testing and
• deploying the software.

The activities are as follows:

1. technical design of module A (duration: 10 days),
2. technical design of module B (duration: 5 days),
3. development of module A (duration: 15 days),
4. development of module B (duration: 20 days),
5. development of feature F in module B (duration: 1 day),
6. implementation of module A (duration: 5 days),
7. implementation of module B (duration: 7 days),
8. testing of module A (duration: 6 days),
9. testing of module B (duration: 10 days),
10. integration testing (duration: 5 days),
11. deployment (1-day duration).

FF, FS, SS, and SF are the logical relationships among the first five activities. To learn how we identified these dependency types, see this example in our PDM article.

In addition to those logical relationships, there are leads and lags in this sequence of activities:

• It is an SS dependency with a lag time of 4 days because testing for Module A can begin 4 days after that module’s implementation has begun.
• Generally speaking, the integration test is planned to begin after the module testing (FS relationship). This is not, however, a logical conclusion because integration tests can start as soon as module B’s testing is 80% complete. There is a 2-day lead time for the successor as a result.

Read this explanation of lags and leads, which also includes an example with illustrations, if you are not yet familiar with this method.

Creating and Understanding the Project Schedule Network Diagram

Transferring this into a project schedule network diagram leads to the following result:

Finding the logical connections between these activities is the first step in drawing such a diagram. The arrows in this diagram signify these relationship types, which define the order of the activities. It is common to write the appropriate dependency type next to the arrows for easier comprehension.

In the most straightforward instance of dependency, i.e. the finish-to-start relationship, the predecessor activity must finish first before the successor can start. An arrow from the predecessor activity to the successor activity is drawn in the diagram to represent this. This has been done, for instance, in our example. for the technical design and the development of the module In the diagram above, it’s A.

The lag of the activity “testing of module A” (lag time 4 days) is displayed as a positive number because it lengthens the total duration of that path of activities.

The opposite reason is given for the negative number in the lead of the “integration testing” activity.

Implications for Project Schedule Management

To calculate the length of a path, add the durations, lead and lag times, and follow the arrows along each sequence of activities. The path of module A, from its design to its deployment, consists of the following activities:

• technical design of module A (duration: 10 days),
• development of module A (duration: 15 days),
• implementation of module A (duration: 5 days),
• testing of module A (duration: 6 days),
• integration testing (duration: 5 days),
• deployment (lasting a day).

The total duration of that particular path, if it were a project on its own, would be 44 days (10 + 15 + 5 + 4 + 4 [for testing: it takes 6 days, however, due to the Two days of the testing period are run concurrently with the implementation over a 4-day lag and SS relationship. Thus, only 4 days of additional time are needed, hence 4 days added to this path] + 5 + 1).

But for our example project, this is the incorrect timeframe!

The path for module B takes more time to get to the condition that the integration test can begin, which is “testing of module B 80% finished” (45 days). Since the path of module A completes the integration test’s predecessor activity in a minimum of 34 days (i.e. testing of module A), this path would need to “wait” for the path of module A to complete testing its module. This “waiting time” is also called slack or float.

Network Diagram Best Practice

Keep in mind that clarity is essential as you explore the world of network diagrams. A diagram that is overly complicated will confuse your stakeholders and stop serving its purpose as a planning tool. Your team might carry out the project incorrectly if everyone isn’t on the same page. The best ways to use a network diagram in project management to prevent this are as follows.

• Only use one start point and endpoint. Multiple networks will result if there are multiple starts or ends. The interdependencies between these activities won’t be possible to map with accuracy. Simply draw separate diagrams if your project consists of several concurrent activities that aren’t at all interdependent.
• Don’t overlap arrows. Multiple starts or ends will confuse people, as was already mentioned. To reflect the relationships between nodes, you would frequently need to crisscross arrows. Always strive to maintain a network diagram that is visually simple, linear, and arranged from left to right.
• Find the critical path. Apply the critical path method to a high-stakes project to pinpoint the series of actions that will have the biggest influence on the result. To keep your project on track, you must closely monitor the task with the greatest number of dependencies and the longest time frame.
• Stay consistent with the symbols. To avoid confusion, use the same method to represent nodes throughout the diagram, whichever one you choose.

Final Thoughts

Whatever your project, drawing a network diagram can greatly improve your understanding of how various tasks are related to one another.

To assist you in drawing your network diagrams, you must invest in a reputable diagramming tool. With the aid of pre-made templates and shapes, you’ll not only be able to draft them quickly, but you’ll also be able to share them with your team quickly, particularly if you opt for a cloud-based solution. Your role is interconnected, just like the tasks in a network diagram. The more you work together as a team, the more likely you are to get everything done correctly the first time.