A network diagram in project management is a visual map of every task in a project, connected by arrows that show the order tasks must happen and how they depend on each other. Unlike a simple task list or timeline, it reveals which activities can run in parallel, which ones must wait for others to finish, and which sequence of tasks will determine how long the entire project takes. Project managers use network diagrams to plan realistic schedules, spot bottlenecks before they cause delays, and understand the ripple effects of any single task running late.
How a Network Diagram Works
At its core, a network diagram is a flowchart of your project’s tasks. Each task appears as a shape (usually a rectangle), and arrows connect those shapes to show the sequence. If Task B can’t begin until Task A is done, an arrow runs from A to B. If three tasks can all start at the same time, they’ll branch out from the same point. The result is a web of paths from the project’s first task to its last, with every dependency visible at a glance.
The diagram typically includes each task’s estimated duration, its earliest possible start date, its latest allowable start date, and how much scheduling flexibility (called “float” or “slack”) it has. When you trace the longest path through the network from start to finish, you’ve found the critical path: the sequence of tasks that directly controls the project’s end date. Any delay on the critical path delays the entire project. Tasks not on the critical path have some float, meaning they can slip by a certain number of days without pushing back the finish line.
Two Main Diagram Types
Network diagrams come in two formats, and the difference is where the tasks live in the picture.
Precedence Diagram Method (PDM), also called Activity on Node, is the more common format today. Each rectangular node represents a task, and the arrows between nodes represent dependencies. PDM is popular because it handles complex relationships well. It supports four types of task dependencies (covered below) and focuses on the relationships between activities rather than just their durations.
Arrow Diagram Method (ADM), also called Activity on Arrow, flips the convention. The arrows represent the tasks, and the nodes represent events or milestones. The length of each arrow indicates the task’s duration, and the connections show the logical sequence. ADM is simpler visually but more limited. It can only represent finish-to-start relationships, which makes it a poor fit for projects where tasks overlap or run concurrently in more complex ways. Most modern project management software defaults to PDM.
Four Types of Task Dependencies
Dependencies are the rules that govern which tasks can happen when. Every arrow in a network diagram represents one of these four relationships:
- Finish to Start (FS): Task B can’t begin until Task A is completed. This is the most common type. Example: you can’t paint a wall until the drywall is installed.
- Start to Start (SS): Task B can begin once Task A starts. Both tasks can run at the same time, but B can’t kick off independently. Example: quality testing can begin as soon as manufacturing starts.
- Finish to Finish (FF): Task B can’t be completed until Task A is completed. Both can be in progress simultaneously, but they must wrap up in a specific order. Example: final documentation can’t close out until the feature it describes is finished.
- Start to Finish (SF): Task B can’t be completed until Task A starts. This is the rarest type. Example: a night security shift can’t end until the day shift begins.
ADM diagrams only support finish-to-start relationships. PDM diagrams support all four, which is a major reason PDM became the standard.
How to Build a Network Diagram
Creating a network diagram follows a logical sequence that starts with your project’s work breakdown structure, the list of all deliverables broken into individual tasks.
First, define every activity and estimate how long each one will take. Next, identify the dependencies between them: for each task, determine which tasks must come before it (predecessors) and which follow it (successors). Then create a node for each activity and place them on the diagram according to their precedence relationships. Tasks with no predecessors go on the left. Tasks that depend on them go to the right, connected by arrows. Enter the duration for each task inside its node.
With the structure in place, you run two calculations. The forward pass moves left to right through the diagram, calculating the earliest possible start and finish for every task. The rule is straightforward: a task’s early start equals the highest early finish among all its immediate predecessors. Its early finish equals its early start plus its duration. When two paths merge into one task, you take the later date, because both predecessor tasks must be done before the next one begins.
The backward pass moves right to left, calculating the latest allowable start and finish for every task without delaying the project. The last task’s late finish equals its early finish (since that’s the project’s end date). From there, each task’s late start equals its late finish minus its duration. When one task feeds into multiple successors (a “burst point”), you take the lowest late start among those successors as the predecessor’s late finish.
Finally, calculate float for each task. Total float is the difference between a task’s late start and its early start (or equivalently, late finish minus early finish). Free float measures something narrower: how long a task can slip without affecting the start of the very next task, calculated as the lowest early start among successors minus the task’s early finish. Any path through the diagram where total float is zero is a critical path.
Reading the Critical Path
The critical path is the longest sequence of dependent tasks from start to finish. “Longest” refers to total duration, not the number of tasks. Every task on this path has zero float, meaning there is no room for delay. If a critical path task takes two extra days, the project finishes two days late unless you shorten something else on the same path.
Tasks off the critical path have positive float. A task with five days of total float can slip by up to five days before it starts affecting the project’s end date. This is valuable information for resource allocation: if you need to pull a team member off a non-critical task for a week, you can check the float to see whether that’s safe.
A project can have more than one critical path, especially in complex schedules. Multiple critical paths actually increase risk, because a delay on any one of them will push the end date. The network diagram makes all of this visible in a way that a flat task list never could.
Network Diagrams and Gantt Charts
Gantt charts and network diagrams serve different purposes, and most project managers use both. A Gantt chart displays tasks as horizontal bars on a timeline. It’s easy to read and great for communicating the schedule to stakeholders who just need to see what’s happening when. You can draw one quickly to get a rough estimate of the time each phase will take.
A network diagram, by contrast, emphasizes the logical relationships between tasks. It shows why tasks are sequenced the way they are, where the risk points sit in the schedule, and how a change to one task cascades through the rest. It’s the analytical backbone behind the schedule. In practice, project managers often build the network diagram first to identify the critical path and calculate float, then translate those findings into a Gantt chart for day-to-day tracking and team communication.
Think of the network diagram as the engine and the Gantt chart as the dashboard. The network diagram does the heavy analytical work. The Gantt chart presents the results in a format that’s intuitive for everyone on the team.
When Network Diagrams Add the Most Value
Network diagrams are most useful on projects with many interdependent tasks, where missing a dependency could silently derail the schedule. A small project with ten tasks in a straightforward sequence may not need one. A construction project, software release, or product launch with dozens of parallel workstreams and handoffs between teams almost certainly does.
They’re also valuable during schedule compression. If a stakeholder asks you to finish a project two weeks early, the network diagram shows you exactly which tasks sit on the critical path and where you’d need to add resources or reduce scope. Without it, you’re guessing. With it, you can model specific scenarios and see their effects before committing to a new deadline.