Share
Explore

What is PERT and how to use it in project management?

A project management methodology to help you make sense of large projects.
Even though PERT might sound funny to say out loud, its application to serious, complex projects is anything but. The program evaluation and review technique (PERT) is
the
method for project managers that need to juggle competing priorities, a byzantine project schedule, and dozens of big-wig stakeholders. Here's what PERT is, how you can use it, and when to use it (or not).

What is the program evaluation and review technique (PERT)?

PERT is a method for project management that uses task duration estimates to determine the minimum amount of time a project will take. Project managers often use PERT in conjunction with
to both identify the project duration and the critical tasks that most impact its on-time completion.

When you use PERT, you break your project down into its main tasks, map out those tasks, and make estimates for how long it'll take to complete each task. To do all this, you use
where each task is a node and with arrows denoting task dependencies. Above each node is the task's time duration. PERT charts tend to be pretty dense and inscrutable to someone who's not well versed in the practice:

image.png
Image source:

This complexity is for a good reason. The US Navy created PERT in the 1950s to manage the construction of
Polaris
nuclear submarines. As you can imagine, building submarines is a bit more complex than a website launch (though perhaps
?).

As you're evaluating the right project methodology for yourself, keep in mind PERT's origins as a massive, complex tool for big, important projects. It's powerful, but for most projects, you'll need
to PERT, so it fits the project you're managing and not the other way around.

One example of this customization may be the use of a
to manage daily tasks rather than a PERT chart. You might start with a PERT chart on a whiteboard but then translate it into a Gantt chart using a spreadsheet. If you'd like to go this route, boy howdy, do we have the template for you.

👉

But before you run off to give PERT a try, let's get into some of the finer details.

PERT terminology to know.

There is a set of terms that are fairly unique to PERT, which will help you follow along. Fortunately, most of them are either well-known project management concepts or are pretty simple to grasp.

Events, predecessor events, and successor events.

Events are milestones that mark the progress along with the life of a project. An easy way to describe the relationships between events is by referring to them a predecessor or successor events. An example of an event might be "Mockup approval."

Predecessor events are events that must be completed before the next set of activities start. Successor events are events that can only start after preceding activities are complete. Another way to think about these two terms is as
. An example of a predecessor event for our earlier "Mockup approval" event might be "Design mockups." A successor event example might be "Web design kickoff."

Understanding which tasks precede and succeed another allows you to plan them out into a cohesive flow chart and aligns your team around the order of tasks.

Activity.

Activities are the tasks for which you estimate how long they'll take to complete. A series of predecessor and successor activities lead up to the completion of a PERT event. For example, for the "Mockup approval" event example to complete, several activities much complete beforehand:
Package mockups into a presentation.
Write presentation.
Practice presentation.
Schedule presentation meeting.

In this way, each activity might have a predecessor activity and a successor activity (see how this can get pretty complex?). To sum up, a PERT event marks the start date or end date of a series of activities. Both activities and events have the potential to have and be predecessor or successor activities or events.


Slack time.

Slack time, also known as float time, is the amount of flexibility an activity has before it starts to derail the project. For instance, based on the time duration estimation of predecessor activities, you can tell that you have a time window of two weeks to get mockup approval. In this case, your slack time is two weeks. The less slack time activity has, the more critical it is to the on-time project completion.


Lead time and lag time.

Lead time is the latest date at which you must complete a predecessor event for successor activities and events to start on time. Lag time is the earliest date at which a successor event can start following its predecessor event.


Critical path.

The critical path is technically a CPM term, not a PERT term. It's so often used in conjunction with PERT that it's important to know.

If an activity has zero slack time, it's a "critical task." A series of dependent activities that each have zero slack time is the critical path to a project. If any of the activities along this path miss a deadline, the entire project will miss its deadline.

The four time estimates used in PERT.

Time estimates are where CPM and PERT diverge. CPM, created by DuPont, only uses one estimate, while PERT uses four. PERT doesn't prioritize identifying a critical path, but it's very effective at doing so. As such, the two approaches are often used together as one, using PERT's time estimates and CPM's critical path analysis.

There are four time estimates in the PERT methodology: optimistic, pessimistic, most likely, and expected.

Optimistic time estimate.

The optimistic time estimate is the ideal timeline for activity completion time. This is your best estimate for when everything goes right, and the whole team functions like a well-oiled machine.

Pessimistic time estimate.

The pessimistic time estimate is the worst-case scenario estimate for activity completion time. This estimate is where everything that can go wrong does.

Most likely time estimate.

The most likely time is the middle-ground estimate that takes the realistic approach to activity completion time. This estimate is how things are in "normal" circumstances.

Expected time estimate.

The expected time estimate is how long you expect activity to take while taking into account outside factors. For example, maybe the design director is busier than normal this month, so you'd make an estimate to account for their potential delay. This estimate is not as widely used and documented, so it's not as necessary as the other three but, it's still useful if your project demands it.

Three advantages of PERT.

PERT is great for large, complex projects that need to deal with and quantify timeline uncertainty. When there are a lot of team members who are depending on the on-time completion of an important project, PERT is a great option.

PERT helps with sensitive timelines.

Projects where time has a direct impact on the budget can greatly benefit from using PERT. You'll have a good idea of how long the project will take, whether everything goes right or wrong. Most importantly, you can easily communicate all this information to relevant stakeholders.

PERT makes sense of complex projects.

Projects that have a lot of complex dependencies and milestones should use PERT. Specifically, PERT diagrams help outline the relationships all activities and events have with each other in great detail.

PERT makes large projects manageable.

As we mentioned above, PERT originally helped the US Navy construct submarines. It's now a very popular tool for construction project management as well. Big projects that have a lot of moving parts also benefit from PERT's ability to outline the relationships between activities and events.

Disadvantages of PERT.

PERT is a big tool for big projects. If your project isn't big enough or if it requires flexibility, PERT might be more work than it's worth.

PERT is relatively inflexible.

Once you lay out a PERT plan with all your estimations and predecessors and successors laid out, it's very difficult to change. PERT charts are pretty inflexible, and if you need to tweak one activity, you'll end up needing to tweak almost all subsequent activities because they're all so closely tied together.

PERT time estimations are subjective.

Time estimations in PERT are made by humans. And (I know this is a surprise), humans aren't perfect. Your estimations can be wrong. It's also important to note that not only can estimations be wrong, but the voices in the room that are loud and wrong can also drown out those that are quieter and right. Time estimations can become subject to tricky office politics games just like anything else in the project management world.

PERT isn't very beginner-friendly.

Not only are PERT charts super complex, but they're also hard to share and communicate. People who aren't well versed in the method might get lost. And if those managing the project using PERT aren't well versed in the method, the whole project might quickly derail from incorrect setup and estimations.

How to build a PERT diagram.

All this said the first step of running a PERT project is creating a PERT diagram. There are four overall steps you should follow. Major project management tools can automate much of this for you, but if you don't want to pay for enterprise-grade software to test it out, you can use our
to do all this for you.


1. Identify work breakdown structure.

List out all events and activities involved with the project. Then assign predecessors (i.e., predecessors) to each. We have a deeper breakdown in our
, but to summarize: In a spreadsheet, you need to assign a label to each event and activity, then assign those labels as dependencies.

Screen Shot 2021-10-25 at 8.18.22 PM.png

2. Determine event sequence.

Next, order each of your events and activities into a sequence based on their dependencies. There might be events and activities that overlap. That's OK. In those cases, the actual diagram is handy.

3. Construct a network diagram

If you're following the traditional PERT workflow, now you lay out all activities as nodes in a network diagram. Each node should connect to another in a web of preceding and succeeding activities.

4. Determine the amount of time required

Now, make your three (or four if you're using expected estimation) estimations for each activity. Then use the following formula to calculate the activity duration:

O + (4 X M) + P)/6 = PERT Estimate

O = Optimistic estimate
M = Most likely estimate
P = Pessimistic estimate

Then, assign this final estimate to each node. Now, you'll not only have the dependencies mapped out but also the overall timeline.

5. Determine the critical path

Again, a critical path is
, but CPM and PERT are used so interchangeably it might as well be. Your critical path will be the series of nodes that have the longest path to completion. This series of tasks determines how long it will take to complete the project.

When to use a PERT chart for project management

If you want to use a PERT chart, you should go ahead and use it. It's a very popular methodology for a good reason, and if it works for your organization, there's nothing better out there. But, if it doesn't work, it can be a very time and resource-intensive dead-end. Otherwise, most projects will be fine with a PERT Gantt chart, like
uses.

Use a PERT chart if you have the tool for it.

PERT charts are hard to create in a clean and easy-to-understand way. Use a specialized tool or whiteboard if you're really set on using a PERT chart.

Avoid PERT charts if you need something quick and customizable.

Gantt charts created from PERT data will work just fine for most projects.
will even create one automatically for you based on its source spreadsheet. When you update the sheet, you update the chart at the same time.

PERT chart FAQs

What's the difference between PERT and CPM?

What's the PERT chart formula?

What's the difference between a PERT chart and a Gantt chart?


A few of the 25,000+ teams that 🏃‍♀️ on Coda.

a77eed08d9f915aabec0346b67a40b7ec93457a9864e51bde1e9239fad175c59624ad1bd252ec5041198bc8e9a52ce31b441ab4767fbb714b9172474278d0b29434f118c46abc5c7a7377f4ad1ea733677ca74d97bc8661e4bbfde8d9cdafabc285f5616.jpeg
Coda is an all-in-one doc for your team’s unique processes — the rituals that help you succeed. Teams that use Coda get rid of hundreds of documents, spreadsheets, and even bespoke apps, to work quickly and clearly in one place. This page is a doc published on Coda.

Find out how to Coda-fy your rituals.
Connect with a Rituals Architect
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.