Build a PERT Diagram: The Method to Visualize Your Project’s Dependency Network

The project network, or PERT diagram, is used for planning, scheduling, and tracking a project’s progress. It is a graphical, visual diagram that complements the Work Breakdown Structure (WBS) of the project.

In this diagram, the project manager visualizes the links between elementary tasks, also called dependencies, which describe the project’s logical sequence of activities.

Why Create a PERT Diagram?

Is creating a PERT diagram really worth it? The answer is almost always yes.

It’s a very visual representation of the project, accessible to everyone, and once built, it can be easily modified to account for unexpected events. This diagram allows you to quickly assess the impact of a delay on the entire project, fostering clear and responsive communication among the teams involved. It provides a precise estimate of the project duration, shows the possible start and end dates for tasks, the floats, as well as the critical tasks—those that must not be delayed if the overall schedule is to be met.

In short, building, tracking, and updating the PERT diagram are among the most powerful planning tools in project management.

From WBS to PERT: Scheduling and Planning

The PERT diagram works hand in hand with the Work Breakdown Structure (WBS). It graphically represents the sequence, dependencies, and logical relationships between the activities needed to complete the project. These activities are the elementary tasks derived from the WBS: concrete actions to produce a deliverable, detailed enough to assign a duration, a cost, and an owner.

The goal of the PERT diagram is to position these tasks over time, according to their logical sequence. Thus, once each task has been assigned a duration (when creating the WBS), choosing a project start date and building the PERT diagram provides an accurate project schedule, task by task.

In this diagram, each task is represented by a rectangle, and dependency links are shown with arrows.

PERT Diagram: Terminology

• Elementary task: an action to be performed to produce a project deliverable. It is specific enough to assign a duration, a cost, and a responsible person.

• Blocked task: a task that is preceded by another. We say the task is blocked by its predecessor(s).

• Blocking task: a task that is followed by another. We say the task is blocking for its successor(s).

• Converging elementary task: a task immediately preceded by several others. It therefore receives multiple incoming dependencies and can only start when all predecessors are complete.

• Diverging elementary task: a task immediately followed by several others. It has multiple outgoing dependencies. Its progress conditions several subsequent activities.

• Parallel elementary tasks: tasks independent from each other that can be performed simultaneously, provided their predecessors are complete.

• Path: a sequence of tasks linked by logical dependencies. It represents a coherent chain of activities in the project network.

• Critical path: the longest path (in duration) through the project network. It determines the project’s minimum duration.

• Critical elementary task: a task belonging to the critical path. Any delay in its execution automatically delays the project.

In the example here, X, Y, and Z are elementary tasks. X is a diverging task; it is blocking for Y and Z. Tasks Y and Z are therefore blocked by X and can be performed in parallel. There are two paths in this example: path X > Y and path X > Z.

The 8 Basic Principles for Building a PERT Diagram

• The diagram is drawn from left to right, in the direction of time.

• Each elementary task receives a unique identification number.

• Arrows representing dependencies should cross as little as possible to keep the network readable.

• The diagram follows the precedence method principles: a task starts only when its predecessors are finished.

• No loops are allowed: you never pass twice through the same set of tasks. The network is acyclic (no cycles).

• There are no logical conditions in a PERT diagram: statements like “If X then Y, else Z” are not allowed.

• A project start task and a project end task are added to explicitly mark the project boundaries.

• A task can only start when all preceding tasks (according to the dependency links) are completed.

The Precedence Method and the Basic Relationships

In the precedence method, there are three fundamental logical relationships between elementary tasks.

To determine the right relationship, just answer three simple questions for each task from the WBS:

• Which tasks must be completed immediately before this task? → These are the predecessors, also called blocking tasks.

• Which tasks can be performed immediately after this task? → These are the successors, also called blocked tasks.

• Which tasks can be carried out at the same time as this activity? → These are parallel tasks that can be done without a direct dependency.

In practice, answering questions 1 and 3, or questions 2 and 3, is usually enough to build the entire PERT diagram, provided you review all elementary tasks.

Once all logical relationships are established, you can connect all tasks from the beginning to the end of the project. The resulting diagram then serves as the basis for the project schedule.

With this network, a set of simple calculations then allows you to:

• determine the project’s forecast end date,

• calculate floats (total and free),

• and identify the critical path, i.e., the sequence of tasks that cannot suffer any delay without impacting the overall deadline.

Getting Closer to Reality: A More Flexible PERT Diagram

In reality, the eighth principle of building a PERT diagram — “a task cannot start until all preceding linked tasks are complete” — can sometimes prove too rigid.

This becomes particularly apparent when a task is very long and needlessly delays the start of another task that could begin partially or in parallel.

Consider a project with the following three tasks:

• Dig the trench

• Lay the pipe

• Backfill the trench

If we strictly follow the PERT principle, we would first dig the trench for the entire kilometer, then lay the pipe for the entire kilometer, and only then backfill.

In practice, we often perform the three tasks in progression: we dig 100 meters, we lay the pipe for those 100 meters, while we continue digging farther ahead.

What’s happening here is that the project’s elementary tasks are not sufficiently decomposed; these elementary tasks can be broken down into segments as in the example below.

This decomposition and pattern in the PERT diagram is called, due to its shape, a ladder formation. The ladder formation allows further decomposition of elementary tasks. However, this ladder approach can sometimes introduce a level of detail that is too complex to manage within the project.

To avoid this, you can introduce the notion of lag into the network diagram.

This notion allows defining three relationships in the PERT diagram.

Finish-to-Start Link

The finish-to-start link is the basic relationship in the network diagram, the one we’ve applied since the start of this article. If task Y is blocked by task X, then it can only start when task X is finished.

Within this relationship, it may be relevant to add the notion of lag. A lag "d" introduced between Y and X means task Y can start only when task X has finished and a delay "d" has elapsed.

A concrete example of this type of lag is a material order: placing the order may take just one day, but it might take ten days to receive delivery. This allows you to indicate, in the PERT diagram, that between the start and end of the elementary task “Order the materials,” eleven days will elapse, but only one day is actual work; the other ten represent waiting time.

Special care must be taken with this practice: the idea is not to use lag to introduce a “time reserve” to absorb delays, but to model a real, justified delay that faithfully reflects the project’s flow.

Start-to-Start Link

The start-to-start link describes a situation where it’s possible to execute part of task X, then start the subsequent activity Y before the first one is complete.

This is the link to use in the earlier pipe example. Converting finish-to-start links into start-to-start links allows tasks that were initially blocking or blocked to run in parallel, which can help reduce the duration of the path they are on.

If this is done for tasks on the critical path, then the start-to-start link can effectively compress the project’s total duration.

Introducing a lag "d" in this link means task Y can start only after task X has started and a delay "d" has elapsed from that moment.

Finish-to-Finish Link

The finish-to-finish link describes a situation where the finish of one task depends on the finish of another. Although rarer, this link can be used when continuity or synchronization is required between two task completions.

For example, in a server migration project, task Y “Shut down the old system” can only finish when task X “Commission the new system” is also complete.

Introducing a lag "d" in this link means task Y can finish only after a duration "d" has elapsed from the finish of task X.

PERT Diagram Example: Launching the Orchesia Website

Let’s revisit the example presented in the WBS article about launching the Orchesia website.

The elementary tasks listed in this example are as follows:

1.1.7.1. Build the landing page color palette

1.1.7.2. Choose the various typefaces

1.1.7.4. Define the visual style and iconography

1.1.7.5. Create button and interactive element patterns

1.1.7.3.1. Benchmark and select a graphic designer

1.1.7.3.2. Present Orchesia’s concept, needs, and values to the designer

1.1.7.3.3. Select a logo from the proposals

1.1.7.3.4. Approve and obtain the final logo in all required formats

1.1.7.3.5. Test the logo with a small user panel

In our example, let’s ask, for each task, the three fundamental questions for building a PERT diagram:

• Which tasks must be completed immediately before this one? These are the predecessors, which we call blocking tasks.

• Which tasks can be performed immediately after this one? These are the successors, which we call blocked tasks.

• Which tasks can be carried out at the same time as this activity? These are parallel elementary tasks.

I know that creating the logo with a graphic designer is the central element that will allow the Orchesia brand to confirm its visual identity and determine its fundamental graphic elements. The tasks related to logo creation follow one another logically, without any possible parallel work, in the following order:

1.1.7.3.1. Benchmark and select a graphic designer >

1.1.7.3.2. Present Orchesia’s concept, needs, and values to the designer >

1.1.7.3.3. Select a logo from the proposals >

1.1.7.3.5. Test the logo with a small user panel >

1.1.7.3.4. Approve and obtain the final logo in all required formats

This chain represents a direct succession of blocking and blocked tasks, leaving no room for parallel processing. The other graphic design tasks—such as building the color palette or defining the visual style—cannot start until the logo has been approved, and are therefore entirely dependent on this path.

Next, task 1.1.7.1 – Build the landing page color palette is directly blocked by task 1.1.7.3.4 – Approve and obtain the final logo in all required formats. In fact, building the palette must rely on the colors, tone, and graphic universe defined by the logo to ensure consistency in Orchesia’s visual identity. It therefore makes little sense to start this task before the logo is definitively approved.

In parallel, task 1.1.7.2 – Choose the various typefaces can be completed independently of the other tasks. It is not blocked by any prior task, nor does it block subsequent ones, and can thus be executed alongside all other tasks.

Task 1.1.7.4 – Define the visual style and iconography is blocked by task 1.1.7.1 – Build the landing page color palette. Indeed, defining the overall style and visual language cannot be done without first setting the primary and secondary colors that will make up the project’s graphic universe. This task therefore directly depends on the choices made in the palette.

Finally, task 1.1.7.5 – Create button and interactive element patterns is itself blocked by task 1.1.7.4 – Define the visual style and iconography. UI elements must be designed in line with the overall graphic style to ensure visual and functional consistency across the landing page. This task can only start once the style is defined.

And so on—this exercise should be performed for all elementary tasks in the project. A task can be blocking for several tasks, and a task can be blocked by several others. This work allows you to schedule the project and visualize the logical sequence of the various tasks.

Orchesia: Software Designed to Structure and Create Your Projects’ PERT Diagram

With Orchesia, the dependency view lets you build your PERT diagram in just a few clicks. The elementary tasks in this tab are pulled directly from the WBS created in the mind map view. This ensures nothing is forgotten and that all tasks are placed in the logical execution order.

Two rectangles—project start and project end—are created automatically: all you have to do is indicate how tasks are linked.

A simple click on a task lets you choose whether it’s blocked or blocking; by then clicking a second task, the link is created immediately. Tasks position themselves one after another optimally, and an arrow is drawn to connect them.

By default, Orchesia treats links as finish-to-start with zero lag. Click the link of your choice to change its type or include a lag between the linked tasks.

Automatically, Orchesia performs all PERT diagram calculations: critical path, floats, start and end dates for each task, and the project’s total duration.

Try our project management software Orchesia free for two weeks, no commitment!