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 …