PERT vs. CPM in Waterfall planning

Posted On 22nd February 2018

In this post I discuss two core Waterfall project management techniques: Critical Path Management (CPM) and PERT; the differences between these methods and why the CPM-method never should be used if a team lacks previous experience from similar projects.

“Critical Task Analysis’ is a methodology of project management which has its roots in the mid-50s and was invented as a way to cope with delays in plant turnarounds, to help to solve critical delays and to determine how to “best reduce the time required to perform routine and repetitive tasks that are needed to support an organization” [Stelth and Roy, 2009, p. 17].

Interesting to note is that the method was developed simultaneously by two unconnected organizations; The US Navy’s Fleet Ballistic Missile Program’ whose approach was named ‘Project Evaluation and Review Technique (PERT); and DuPont, an American chemical company who called their approach ‘Critical Path Method’ (CPM) [Esposito, 2018].

While many project managers use the terms PERT and CPM interchangeably, and both methods share the same general assumptions that a project can be broken down into identifiable and quantifiable tasks and that some of these tasks might be dependent on the completion of previous tasks while others might be independent of the tasks ahead and thereby can be undertaken at any given time [Lowe, 1971]; the PERT and the CPM methods have some significant differences and also are created to solve fundamentally different problems. Consequently; any discussion about Critical Path Analysis need to cover both the PERT and the CPM method, and for project managers, it is therefore vital to learn about both methodologies to enable educated decisions of which method is most suitable for the projects they work with.

Key differences between CPM and PERT

The most notable point of difference between CMP and PERT is that in the former you only do one estimation for each identified task while in PERT you use three:

P: The most pessimistic

O: The most optimistic

M: Most Likely

As such, PERT is the preferred method to use when control of time is of primary importance, if there are many unknowns such as if an organization little experience from similar projects and if the project is “non-repetitive”. CPM, on the other hand, is the preferred method if a project is recurring in nature, when time estimations can be grounded in historical data and/or if the cost control is of primary focus [Stelth and Roy, 2009, p. 11; McNeil, Frey and Embrechts, 2015; Surbhi, 2018; Emelda, 2011].

Fig 1, below, illustrates some of the key differences between PERT and CPM:

Conclusion

As noted by Stelth and Roy [2009]; Surbhi [2018] and McNeil, Frey and Embrechts [2015], the CPM and PERTH techniques serve the same core purpose in project management of reducing risk, identify most important tasks and predict project completion times. While the CPM technique is a deterministic tool which allows planners control of cost as well as time the method is aimed to be used in projects with predictable activities and tasks, thus, as noted by Stelth and Roy [2009, p. 18], also demand experience from similar projects and tasks to enable informed estimations. PERT, on the other hand, is a probabilistic tool aimed at projects with unpredictable tasks and utilizes three time estimates compared to one in CPM to control activities and determine time completion.

While the fact that PERT-estimations are based on three different time estimations which, hypothetically, should result in accurate time estimations; a matter of fact you still are still just guessing which in large projects with hundreds of or thousands of tasks, consequently, rarely will reflect actual outcomes and as such, if a project has many unknowns, I always recommend that the project is performed in LEAN/Agile.

If an organization has historical data from similar projects and consequently time estimates can be made on empirical data, the CPM method supported by a project management platform such as Microsoft Project, though, can be an excellent method to quickly build a rough understanding of a project’s resource requirements (time, budget and staff) and to help stakeholders to evaluate if the organization has the necessary resources to perform the project or not which in my experience can be very difficult when working “strictly Agile” which open-ended structure and no definite “end”, so to say; often agitate budget minded managers and making them reluctant to employ the Lean philosophy.