Frank Patrick is doing an excellent job of describing the ideas behind Critical Chain Project Management (CCPM), specifically around estimates and buffer sizing. The latest entry
in the series of articles discusses some curious comments from Dr. Goldratt on the technique of using 2-point estimates for task durations.
Goldratt in CC@Work (a webletter of Critical Chain software provider Realization):
50/90 is useless. In projects, no one will ever know what the distribution curve of task duration looks like for any task. Moreover, with chaos all around them, people cannot distinguish between the real variability of a task and the variability resulting from chaos...When implementing CC for the first time, the way to get safeties out of the estimates is to take the current task estimates and cut them in half. As an implementation matures, people get experience in giving tighter estimates and you want to cut the estimates by a number that is less than half.
I recommend reading Frank's excellent discussion of the issues, if you are at all interested in Critical Chain Project Management.
The thing I missed in my original read of this newsletter is the recommendation "when implementing CC for the first time" to remove the safety by cutting tasks in half. I originally read this as saying "always cut the tasks in half" and use the remainder to estimate buffer size. (The article goes on to say that as the CCPM implementation continues, that teams get better at estimating, so less needs to be cut from the tasks.)
Goldratt is right at a certain level. Task estimates frequently are this bad that cutting them in half creates no major problems, partiuclarly when coupled with the buffer and other changes that CCPM creates. The problem is that there is no way a team will stand for this. Goldratt (and others) developed CCPM in response to the way people behave in project environments. Throwing this kind of edict on them is going to convince them that their behavior has been correct all along, and the cultural change will be more difficult.
Two-point estimates, communicated well, get people thinking about the fact that no task is 100% knowable. This is where the behavioral change starts in the implementation teams, by building trust.
In the end, these projects are executed by the team members. The value of the approaches to estimating tasks and buffer sizing is in the ability of the team to focus on what is important - the success of the project. Removing trust at the beginning pulls focus away from success and towards "I told you so" behavior when things fail.