Three Point Estimates, PERT and Microsoft Project
I have managed a project or two in my past. Some completed early, some right on time, and some completed well beyond the target date. But my latest project is different. I wanted to develop a schedule that was as accurate as possible with respect to the projects finish date. I knew that in order to do this right would require gathering effort estimates for each task. However, this organization is not quite ready for that. They are accustomed to giving only duration estimates. I did not have the time, energy or influence to change the culture and request effort estimates for each task.
In the past, I worked with my team of subject matter experts to determine the various activities that must occur. As a group, we would then determine the sequence of those activities. When gathering the duration estimate for each task, I asked the subject matter experts for their estimate. They gave me one number for each task. The question I always had was, “how precise was this one number?” Did the person who gave me the estimated duration “pad” that estimate? In other words did they include extra time to allow for various uncertainties? Were all of the estimates padded? Which ones were padded and which ones were not?
When reading my copy of
PMBOK (the third edition) one night in bed, I stumbled into a section in
Chapter 6 – Time Management about
Activity Duration Estimating. One of the “Tools and Techniques” listed for developing a duration estimate was
Three Point Estimates. It states that determining this estimate involves gathering three different estimates; Optimistic, Pessimistic, and Most Likely, and then averaging those three estimates (p. 142). Just before falling asleep, I thought: “This would be a better approach.”
In the shower the next morning, I remembered a gentleman giving a presentation a few years ago at a local PMI meeting around PERT estimating. I ran to the office and pulled out my older version of PMBOK (2000 edition). I skimmed through it and found the section on PERT estimating. I found that PERT stands for Program Evaluation and Review Technique and it uses a weighted average to determine duration. (p. 75). I even found the formula: (Optimistic + 4 x Most Likely + Pessimistic)/6.
I thought about this for a moment and came to the conclusion that the weighted PERT average duration estimate would be an even better approach than a simple average since it is putting more emphasis on the Most Likely outcome.
The day progressed and I decided to load my tasks into Excel then ask the team members to give me their three different duration estimates. I could put those into three different columns and create the formula to derive the PERT estimate. I would then transfer this one number into the Duration for each task within MS Project. As I opened up my
Microsoft Project schedule and began to extract the tasks into Excel I paused. I remember thinking; “Wouldn’t it be nice if I could somehow capture the three different estimates right here within Microsoft Project. Perhaps then I could look at an over-all Best Case (Optimistic), Worst Case (Pessimistic) and Most Likely schedule.” So I began to poke around the different options within Microsoft Project. Low and behold there IS an option for PERT Analysis!!
If you click on >View, >Toolbars, >PERT Analysis, a fancy little toolbar will appear.
“So what do I do with it now?” I thought. The first thing I decided to do was click on the “Set PERT Weights” option.
Amazing!! The default values presented here align to the values given within PMBOK!
“Well this is cool” I said to myself. But I wonder how it works. So I decided to test it.
I created “task 1” within MS Project, and then clicked on “PERT Entry Sheet”:
That brought up a view within MS Project that contained the Task, Duration, Optimistic Duration, Expected Duration* and the Pessimistic Duration:
*Note Expected Duration within MS Project is equivalent to Most Likely within PMBOK.
I then input 2 into the Optimistic Duration, 4 into the Expected Duration and 12 into the Pessimistic Duration:
At this point, nothing happened. But then I clicked on “Calculate PERT”:
I received the following dialogue box:
I chose Yes.
Note that the Duration changed from 1 day? to 5 days?
“This is great”, I thought, “but is it accurate?” I decided to test Microsoft Projects calculations by completing the formula manually:
Original Formula:
(Optimistic + 4 X Most Likely + Pessimistic) / 6 =
(2 + 4 X 4 + 12) / 6 =
(2 + 16 + 12) / 6 =
30 / 6 =
5
“Way Cool!!” So the moral of the story thus far is; if I can get my team to give me 3 different duration estimates instead of one, I can use the PERT calculation within MS Project to automatically provide me with more accurate duration estimates.
So I began to work with the various subject matter experts. I told them I wanted to do a better job on estimating the duration of this project and asked them if they could give me three estimates:
Most Likely (Expected Duration) – The duration of the schedule activity, given the resources likely to be assigned, their productivity, realistic expectations of availability for the schedule activity, dependencies on other participants, and interruptions.
Optimistic Duration – The activity duration is based upon a best case scenario of what is described in the Most Likely estimate.
Pessimistic Duration - The activity duration is based upon a worst case scenario of what is described in the Most Likely estimate.
I asked them to use ½ day increments to establish these duration estimates.
Believe it or not, they played along!! When complete, I ended up with something like this:
So now to let MS Project go to work! I clicked on “Calculate PERT” and said Yes.
I switched over to the Gantt View and noticed that the Duration field for each task had in fact been populated by the output of the PERT calculation:
At this point, I felt a little more comfortable in committing to the Project Finish Date of 4/26/05.
In next months article learn how we built buffers or schedule reserves into this project to account for the unwanted, but anticipated delays (or Risks!).