Everything old it seems is new again. One of the earliest programmatic approaches to project scheduling was invented in the heyday of the Cold War. Propelled by inter service rivalries on one side and by the threat of Soviets in the arms race on the other, PERT was born. The Program Evaluation & Review Technique looked beyond a simple Critical Path Methodology (CPM) analysis to introduce the notion of risk into the project schedule. The method was tremendously successful. It was used on the Polaris missile project in the late 50s and early 60s and was credited with enabling the first test launch only 18 months after the start of the project.
The PERT method asks the scheduler to provide three data points for each activity rather than one. Each activity has a best-guess duration but also an optimistic and pessimistic duration as well. The idea is to start by doing the schedule based on only the optimistic, then only the best guess and then finally only the pessimistic durations. As the project progresses and actuals replace the optimistic, best guess and pessimistic durations, the range of risk at project completion decreases.
Why should this matter? Well, if you’re looking at the schedule for any significant-sized project and the result of that schedule says something like “We’ll be done with this project in 2 years, 3 months 6 days and 4 hours, everyone knows that’s a lie. The more likely scenario is that you will be able to estimate within a couple of months yet that’s not how we talk about the schedule. It we had followed the PERT method, we’d have gotten the easiest schedule range from just adding up the optimistic, pessimistic and best guess durations to be able to add “Our most optimistic projection is 2 years and 12 days and our most pessimistic projection is 3 years, 6 months and 4 days”
A range like that may not be what management wants to hear. We know what the reaction from management is likely to be: “You will finish the schedule then based on the most optimistic projection!” But, if you introduce this kind of analysis into every schedule, then you reveal several things straight away. First of all, is the scheduler an optimist (like the one above) or a pessimist? This isn’t trivial. It’s a terribly important thing to know. Also important is the increased credibility of giving a range of dates. It says to the reader that you’ve considered things that could happen to this project (both good and bad) and have given your best possible answer.
For those who spend time in such an analysis, it is also interesting to keep track of the progression of the range. Think about it like this. The day before the last day of the project, the range of possible finish dates is probably very narrow. “We’ll finish tomorrow or maybe the next day,” you might say. On the first day of the project, you would expect the widest range because we have the most number of tasks, which still have optimistic and pessimistic numbers that we’re considering. It’s logical then to expect that the two endpoints (the optimistic and pessimistic) will migrate towards each other as the project progresses. That indicates a healthy advance.
If the endpoints start to move apart during the project, this indicates that we’ve introduced an element of risk into the project that wasn’t there when we started. The endpoints can only move apart when we either add tasks or re-assess the optimistic and pessimistic durations of the remaining work. That’s an easy-to-watch-for warning sign for management that should spark some kind of project review.
We seem to have come a long way since the Polaris missile project but, while PERT did find its fans, it never took off the way that we talk about CPM analysis. Only those esoteric schedulers in the Risk Analysis industry seemed to take any notice and they were working on other things. If you’re interested in schedule and budget risk then you’re probably talking more about statistics that come out of a Monte Carlo analysis, or something much more involved. (“What’s Monte Carlo analysis?” you ask. That’s a subject for another day but suffice to say that the result of such analyses are S-Curves, Bell Curves and probability statistics.)
We still see PERT analysis available in a wide range of project scheduling tools. Some vendors probably wonder why they’re still supporting something that hasn’t got a huge following.
PERT suffered in its popularity not because it was a bad technique (I think it’s a great technique) but because it takes more work. Remember, we’re talking about adding additional elements of data for every single task during the planning process. In some organizations it’s hard enough to get a single data point, never mind three. So given there was more work and no incentive for most project managers to implement the technique, it gradually fell from favor.
So? It’s ancient history right?
Wrong.
While enjoying a quick four-day visit to Sydney, Australia (I’m kidding of course, while I do love Australia, it’s impossible to fly the 26 hours there and the 26 hours back and enjoy only four days in between), I got to meet with and listen to some of the top project managers in the Defense Industry. I took great interest in the sessions on Risk Management, as it’s something I know something about and it’s not often talked about in those terms.
In Australia, defense projects (and other major capital projects) must comply with the AS4360 standard. This standard was first introduced down under in 1995 and thanks in part, I think, to a red-hot economy and a government committed to expanding its defense spending, the AS4360 standard took hold in a big way and has become a staple of large projects there. That might have been the end of this story except that the standard has done so well that there is now talk of the US adopting AS4360 for major capital projects. The Americans will not simply implement AS4360 of course, but those in the know say that the AS4360 promotes a “risk analysis lite” culture that will be quite acceptable to the Defense, Aerospace and Energy projects that should be implementing such techniques.
In particular, one of the components of AS4360 that we’ll likely see promoted is the notion of three-point estimates for schedules, and that is PERT.
As is the case with many project management techniques, if this kind of standard is adopted, it will likely result in the promotion of more risk analysis attention across the US and, ultimately, everywhere else.
If you’ve never done PERT analysis before, it’s almost certainly available to you. Try implementing it with any copy of Microsoft Project. Right click on your menu bar to reveal the PERT toolbar. It will show you how to enter your optimistic and pessimistic analyses and show you a view with the result of your three-point analysis. It’s a worthwhile exercise if you’ve not tried it before and, if you do, you’ll be ahead of the pack and have a taste of project management life from Down-Under.
G’day mate!
Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected]. This e-mail address is being protected from spam bots, you need JavaScript enabled to view it.
It’s hard to believe that another year is behind us. And what a year it’s been at Project Times. We started out as a quarterly, became a monthly in late spring, and here we are now, coming to you twice a month.