The PERT Analysis – Part 2
October 1, 2014 Leave a comment
In the previous post, we began a formal discussion on PERT analysis and how it is used as a project estimation and flow technique. (Note: if you have not read the previous post, please access it at the following link: The PERT Analysis – Part 1)
As a brief refresher, the idea behind a PERT analysis is twofold:
1) It gives an overview of the various constituent pieces that are part of a given program and shows (graphically) how they relate to one another.
2) The PERT also yields the ‘critical path‘ of the program, which is a mathematical summation of the various paths in the PERT diagram which eventually provides the path with the longest duration. Which in turn becomes the critical path.
One of the main formulas utilized when calculating various completion estimates for tasks that are part of the overall program is the following:
TE = (O + 4M + P) ÷ 6
The variables listed in the formula are as follows:
TE – Time Estimate
O – Optimistic Time
M – Most Likely Time
P – Pessimistic Time
Think of this as an ‘over/under’ technique, whereby the individuals working on the tasks provide three timeline estimates denoting their most optimistic, pessimistic and likely timeframes for the task. Those estimates are then plugged into the above formula to come up with the time estimate for the task. Note that the usage of this formula is not mandatory for PERT and that single estimates can also be leveraged. The most important consideration is that each task (activity) have some estimate associated with it.
To add further granularity to the overall PERT schedule, various estimates on earliest and latest start or finish times for each activity can be calculated. Note that each activity can have all of these estimates associated with it. In order to determine Early Start, Early Finish, Late Start and Late Finish for each activity, one must examine each node and ascertain the values relating to the predecessor nodes. So for example, if the activity between Node 1 and Node 2 is deemed to be 2 weeks, then the Early Start for Node 2 is 2 weeks from the given date. (Assuming Node 1 is the start node) Leveraging these calculations for each node can give both optimistic and pessimistic timescales to each activity as well as take into account potential slippage events from predecessor activities.
Some additional definitions worth mentioning relating to PERT are as follows:
Slack (or Float)
This is the amount of time that a project or task can be delayed without causing slippage to subsequent tasks and overall project completion. Note that if a task is on the critical path, it cannot have a float associated with it since any delay to activities in the critical path will delay dependent activities further downstream. Positive slack denotes the project being ahead of schedule, negative slack indicates the project is behind schedule while zero slack indicates it is on schedule.
This is a technique whereby the most critical activities are performed in parallel. This is a concept that the project manager must engineer up front and should not be attempted once well into the project. The idea is that if critical activities are performed in parallel as opposed to sequentially, the likelihood of one activity causing slippage to subsequent activities is reduced. Note that care must be taken when deriving this solution. Dependencies will exist for various tasks and performing them in sequence may be the only viable option. (Eg. needing to build the foundation of a house before working on its frame) But if performed correctly, fast tracking can streamline a project and give more lead time to any issues that may arise without having to potentially delay subsequent tasks.
Crashing the Critical Path
In cases where the critical path cannot be effectively re-engineered for more parallel development, the project manager may instead decide to add more resources to items in the critical thereby reducing the amount of time for each one. This technique is referred to as ‘crashing the critical path’ and can be leveraged in cases where it is advantageous to utilize resources early in the project cycle to ensure completion of critical activities. (This is also referred to as ‘front loading’ in some cases) Note that this technique is often best performed when new resources have been added to a project, although it can also be achieved through effective re-distribution of existing resources.
The PERT analysis can be an effective means by which to provide a good overview and timeline for a given project or program. As alluded to in the previous post, PERT can have some drawbacks if the chart has so many tasks and dependencies that it becomes unwieldy. In those cases, segmentation of the PERT into more cohesive pieces can assist. It may be possible to create a ‘master PERT’ that serves as a full program overview while smaller PERTs will denote the main portions of the primary PERT.
For further information on PERT and critical path analysis, please consult the following Wikipedia article for additional detail: