Project Scheduling Formulas

James Bach is running an on-line class for his Rapid Software Testing Course, that I am finding quite enjoyable. More fun than the lectures (which are good) is what I'm learning from the offline forum software he is using.

Recently, someone made a post about project scheduling formulas; I enjoyed it so much that I wrote up a rather long reply, which I wanted to share here:

Hello John. I have heard that formula as well, very recently, from people in the PMI/PMP world - people I respect who consistently have good results.

However, I don't think it's magic. If we take a minute to deconstruct this ...

If a = most optimistic estimate
b = reasonable estimate
c = pessimistic estimate

Then use give an estimate of (a + 4b + c) / 6

Then A is what many projects start with. In "Waltzing With Bears" Demarco and Lister assert that technical folks are really good at coming up with the "Nano Percent Date" - the date which the project could be done if everything goes perfectly - which has a nano-percent chance of happening.

Just moving the conversation past A is helpful.

I've heard different descriptions of C, but it usually comes out to about twice B, which is usually about twice A. In other Words:

C = B*2
B = A*2

Estimate =

(A + (2*4*A) + (2*2*A) )/ 6 =

(A + 8A + 4A) /6 =

13A / 6 =

A*2.166

:-)

In other words, this isn't much more than "Take your original estimate and double it", but it's dressed up in psuedo-science. :-)

----> Now, my less sarcastic answer:

Actually, it's a little more valuable than that. You'll notice that you've got A, 4B, and C - which total six "things" - divided by six. That's a weighted average - weighted strongly towards B. However, C is the gotcha - C is where you weigh in what happens if the entire development team is killed in a hurricane and the team needs to be rebuilt from scratch. That number is usually large enough to drag the average toward the large side. This gives us our 16% buffer past just "2". (Remember, we came out to 2.166.)

Also, there are some projects where C just isn't that large, because you are doing something that is well-defined with commonplace technologies. Those types of projects often have low return-on-investment, but also low risk. In that case, using A, B, and C might be more helpful than just multiplying by a number.

When I run projects, I have two dates - a commitment date back to the business and a goal date for the team. To calculate the difference, I try to take 'most realistic estimate' in one corner and add a buffer for risk - the larger the risk, the bigger the buffer.

So my estimate math is:

Estimate = Realistic * X

Where X is something between 1 (zero risk, I'll have your essay written today, no problem) and 2. X is my risk factor; it's different on every project.

If X is greater than two, I usually suggest an architectural spike to make realistic more realistic, or some change in scope.

Now, I am not accusing you of this, but I have seen people use scheduling formulas without understanding them, and the results, though tragic, are predictable. Actually, to be honest, I find asking the "why" of the formula is far more enjoyable than plugging in numbers ...