PERT, CPM, and Agile Project Management.
Robert C. Martin 5 October 2003 Some time in the late 60's my father brought home a book that he thought I'd be interested in. The title was Introduction to Operations Research by Frederick S. Hillier and Gerald J. Lieberman, Holden-Day, 1967. I was probably 15 or 16 years old. The book languished on my shelves for perhaps ten years. Then, as a young software professional, I pulled the book down and ,thumbing through its pages, I noticed a chapter on PERT. I had heard of PERT as a method of project management, so I started to read and learn. Since those days in the early 80's I have seen dozens of examples of PERT charts, and tools for drawing PERT charts. They always make me cringe. Invariably these charts a tools missed the nd fundamental principle of PERT that made it such a successful technique: the management of probabilities. PERT (Program Evaluation and Review Technique) was developed in 1958 to help measure and control the progress of the Polaris Fleet Ballistic Missile program. The technique earned considerable respect for assisting in the management of thousands of different contractors and agencies, and is credited with helping to advance the completion date of the program by two years.
PERT: an overview.
PERT is a technique for estimating and planning a large project. One of its most powerful concepts is that project management is the management of probabilities. PERT makes use of simple statistical mathematics in order to come up with a probability distribution for the completion dates of the project milestones. For example, in PERT tasks are estimated with three numbers: The best case, the nominal case, and the worst case. These three estimates are combined into an expected duration, and a standard deviation. Thus the duration of each task is presumed to be a random variable with a known distribution. The math is very simple. Consider a task whose best/nominal/worst estimate is 3/5/9. The expected completion time (µ) is assumed to be (4*nominal + best + worst)/6, or in our case (4*5+3+9)/6 or about 5.33. The standard deviation (s) is assumed to be (worst - best)/6 or (9-3)/6 or 1. Now consider a simple project consisting of three tasks. We represent this as a simple chart with circles and arrows. The circles denote events, and the arrows denote tasks. 3/5/9 start Task 1 a Task 2 4/5/12 b Task 3 7/9/15 end
If the first task begins on day zero, what day can we expect the third task to complete? The chart below shows the expected durations, and we can just add them up. So the expected duration of the project is 5.33 + 6 + 9.67 or 21 days. Task µ 1 5.33 2 6 3 9.67 s 1 1.33 1.33
A more interesting question is the probability of making that date. A bit of simple reflection will convince you that if the estimates are correct then there is a 50-50 chance that the project will finish on time. There is just as much chance that it will be late as early. Clearly we cannot make a commitment
based upon such poor odds, so what can we commit to? The end date for the project is a random variable that has its own µ and s. We already know that µ for the project is 21 days. The s for the project can be calculated by summing s 2 for each task, and taking the square root of the result, or (12 + 1.33 2 + 1.332)½ = 2.13. Let's say we feel comfortable committing to a date that has a 90% chance of being met. A little probability math tells us that we get this certainty by adding about 1.3s about 3 days to the project. So we should commit to 24 days.
One of the more common project estimation schemes is Critical Path Method or CPM. Project managers who use CPM ignore the probabilities and use only nominal case estimates. 5 start Task 1 a Task 2 5 b Task 3 9 end
Following this approach would lead us to commit to finishing the project in 19 days. CPM is the method supported by most project management tools. This has always puzzled me since it seems to me that knowing the...
Please join StudyMode to read the full document