Cool Verification

I was cleaning out my inbox this afternoon and came across a mail thread I'd exchanged with Gary Smith just after DVCon 2011 on project planning. Gary had mailed me a couple of slides, the contents of which he graciously gave me permission to share. The first described Gordon Bell's Law of Project Management:

A = Actual time to reach first milestone
S = Scheduled time to reach first milestone 

Bell Factor = A / S

Then, multiply the program schedule by the "Bell Factor." This gives you the actual time it will take to complete the design.

If the Bell Factor is 1.0, the schedule has too much fat.

If the Bell Factor is 1.2, you have a well-run program.

If the Bell Factor is over 1.8, (fire everyone and [*]) start over.

[*] added by Gary.

The second described Jen-Hsun Huang's "Three Miracle Law":

0 miracle design: You will drop behind your competition.

1 miracle design: You will keep up with your competition.

2 miracle design: You will leap ahead of your competition.

3 miracle design: Your design will fail, your start-up will fail, and you will be out of a job.

Both of these quotes are especially relevant when I work with companies to enhance project planning capabilities. One of the biggest roadblocks to accurate project planning, in my view, is the belief that it is possible to give an exact date when a specific task will be completed. In my experience, the only way to be able to predict exactly how long something will take is if you've done it before. And if you've done it before, you are likely operating with a "0 miracle design". And clearly, we don't want to drop behind our competition. 

So is there a better way? Agile planning gives us another option - planning poker, combined with continuous data collection of how much time it actually took to complete estimated tasks. The idea is to separate the estimation of relative magnitude of tasks from the actual calculations to determine task end dates. During a planning poker session, engineers use unitless cards to estimate magnitude. The group then determines how many estimated tasks they would like to try to accomplish during a given 2-3 week period. And at the end of the period, the project manager keeps track of how many tasks (and thus, points), were completed. Over time, it is possible to start estimating how long the team as a whole will take to complete a certain number of points-worth of tasks. Though it is probably useful to point out that it is not really possible to exactly estimate a single tasks. This is a technique that works at the team level.

I consistently find that planning meetings are much less stressful and provide more accurate results if planning poker is used vs. something such as ideal person days. Why? Because it is impossible to game the system. If everyone thinks they are being clever by picking low numbers in order to please management, it will simply change the number of points that is completed during each planning period. So as long as the team remains consistant in the types of point values they assign to certain tasks, the time it will take to finish a group of tasks will become clear.