Pert Estimation Photo

PERT Estimation

Estimating Time required

Pert Diagram Example
Related Articles

One of the most critical tasks before any manager where resources are going to be utilized - be they manpower, money or material - is to carry out accurate, upfront estimations of the time required to complete the given activity, task or project.

Indeed, developing such estimates is a complex exercise, and has engaged the attention of a lot of management thinkers, generating copious literature in the process.

In response to such situations, management personnel racked their brains and came up with several techniques that would give a semblance of scientific structure & rigor to the entire exercise of estimation. CPM, PERT, Delphi, Extrapolation, Function Point Counting, Historical Comparison, Object-based technique, Scheduling Heuristics, Top-Down Estimating, Weighted Average (WAVE), are all an outcome of such brain-storming. While some are radically different, others are mutations of some basic concept, and the differences are sometimes too subtle to discern.

Additional Resources

PERT - A well-entrenched technique

PERT - short for Program Evaluation & Review Technique - is an outgrowth of research work carried out by the U.S. navy in the late 1950s, when they were trying to put the Polaris Fleet Ballistic Missile Project on schedule. There were thousands of contractors and agencies involved in this project. Earlier askance at this technique gave way to respect when the program ended two years before its scheduled completion date.

Soon, news about this technique spread in the management circles. This technique came to be adopted by the private industry, and more and more dramatic results began getting reported in contemporary management journals and forums. When top management personnel began swearing by its success in cocktail parties and social get-togethers, it became clear that PERT had well and truly arrived on the world stage, and was here to stay.

The Basics

Stripped off its glamour, PERT at its core is a management of probabilities, which it handles quite elegantly through simple statistics.

People often speak of PERT and CPM in the same breath. CPM, or Critical Path Method, too has the same mandate as PERT, though the focus of CPM is slightly different.

The basic take-off stage in both CPM and PERT is to identify the tasks (or activities) required to complete the given project. A Gantt chart may be deployed to list the activities in a structured fashion, along with their interdependencies. This logically flows into the next stage, where a "network" of the activities and their dependencies is drawn up. In this network, each event may be represented by a node. Activities form arrows, with their tail touching one predecessor event, and their head touching the event that logically follows it (or is subsequent to it). Before any activity can begin, all its predecessor activities must have been completed.

In both CPM and PERT, the time required to complete each activity is estimated. Now, while in CPM, a single point estimation of the completion time is sufficient; in PERT, the simplest form involves determining three estimates of the time required to complete each activity. In mathematical terms, activity times in CPM are taken to be "deterministic"; while in PERT, they are taken to be "probabilistic". This is where the differences begin between the two.

With each event are associated two important times:

  • The earliest time TE, which is the calendar time when the event can occur if all the predecessor events reach their completion at earliest possible times.
  • The latest time TL, which is the latest time the event can occur without causing any delay in subsequent events, and without delaying the project's completion at all.

The slack time for the event is the difference between its latest and the earliest times. This is the upper limit that an event can be delayed, which if exceeded or crossed, shall surely delay the entire project.

Activity time is the elapsed time required for an activity. The entire effort of PERT - indeed, its very raison d'ętre - is geared towards arriving at this Activity time as accurately as possible. PERT takes the statistics route to do this.

Your 3 chances

As mentioned above, there are three numbers that each activity time in PERT is associated with. Put simply, managers can give three time estimates for completion of every activity. (Just as well. You can't tie a self-respecting manager down to one single, rigid time estimate for each activity, and then expect the project to be completed on time, can you?!!!) These estimates are:

  • Optimistic time estimate (TOPT) - This is the minimum time period in which the activity can be accomplished, with the presumption that everything will proceed better than expected.
  • Most likely time estimate (TLIKELY) - If the manager were asked for, not three, but only one estimate, then this is the value that they would have given.
  • Pessimistic time estimate (TPESS) - This is the maximum time period required for an activity to be completed. From an inclement weather, to the prototype or design review being rejected for reworking all over again; managers can think of everything that can go wrong, when arriving at this value.

Of course, since PERT hinges on these three values, managers would do themselves a favor by giving as good guesstimates as they possibly can, in order for overall project estimation to be as accurate as possible.

There is one more concept that is associated here - the Critical Path. This is the longest path - from start to end - in the network that we drew above. This is also the path strewn with activities whose slack times are zero. In other words, they must each start at their earliest possible start time and be completed within their estimated time. By doing so, the Critical Path activities would ensure that the project is completed on time.

Now, here is the crux of the whole matter. The three estimates together determine the probability distribution of the completion time on the critical path.

And now the math...

This is how the math behind PERT pans out. PERT assumes a BETA Probability distribution of the time estimates. The Expected Completion Time, or μ, is calculated as a weighted average of the three times, as follows:

μ = (TOPT + 4 X TLIKELY + TPESS) ÷ 6

Correspondingly, the Variance, is calculated as follows:

Variance = [TPESS - TOPT]^2 ÷ (6)^2

Now, what do we do with all this math? Here is the process we follow:

  • For every activity on the Critical Path, we calculate the Expected Completion Time and Variance.
  • Next, we total the Expected Completion Times. This sum gives overall Expected Completeion Time for the project.
  • Now we add the corresponding variances for each activity on the Critical Path. This gives the variance for the entire project.
  • Obtain the standard deviation for the entire project, which is the square root of the variance.
  • Using normal probability distribution for the critical path, we calculate a factor of the overal variance that will yield a desired probability. This factor of the variance, added to the Expected Project Completion Time, gives the total estimated time required for completing the project with the desired probability.

 

Pert Limitations

As with everything else in life, PERT too is not without its warts. While going through the process of analyzing project and activity completion times, we made quite a few simplistic assumptions. We have assumed, for example, that the critical path, once identified earlier on in the game, does not change. However, it is possible that the critical path that was identified based on the most likely or expected completion time will not necessarily end up being the critical path. Scenarios in which another path takes longer than the identified critical path may be ignored. There might be a tendency to understate (it is quite human, after all) the expected completion time, and this will definitely underestimate the probability of late completion

Conclusion

The best part about PERT is that it recognizes uncertainty in project time estimation as it is - there is no attempt to sweep it below the carpet, and pretend that it does not exist. On the contrary, PERT gives a rough approximation of the uncertainty in the final completion time. Of course, the simplifying assumptions made during the analysis do lead to an underestimation of the probability of long project completion times.

In the end, working with some form of estimate, is far better than working without one at all!

     


© Copyright 1998-2005 Envision Software, Incorporated Tampa, Florida
This work is licensed under a Creative Commons License .
Questions? Comments? Send them to the Webmaster