At this writing, three methods for calculating tolerances enjoy some measure of support. They are: the Cut & Paste method, the Control Chart method, and the Root Square Error method. We discuss these now.
The cut and paste method of determining component tolerances is popular among the followers of Dr. E. M. Goldratt. According to this method, a project manager gathers the inflated estimates of task duration typically provided by developers and cuts these in half. The model of the project, then, is based upon the reduced estimates of duration. The component tolerances are estimated as a percentage (usually 50%) of the deterministic estimates of duration of their respective sequences of tasks. The project tolerance is estimated as percentage of the deterministic estimate of the duration of the longest sequence of tasks. Goldratt's followers refer to this longest sequence as the critical chain.
What’s good about the cut and paste method? It is overwhelmingly simple to use, as it requires only grade-school arithmetic. This simplicity seems to be of paramount importance to Goldratt and many of his followers, since the method can be taught even to the highly uneducated among us.
What’s not so good about the cut and paste method? The cut and paste method provides a linear model of variation. Unfortunately, so far as sequences of tasks are concerned, variation does not add linearly – only variance adds linearly. Variation increases with the square root of the number of tasks in a sequence. Thus, the linear model provided by the cut and paste method is inconsistent with sound mathematics.
Worst of all, the cut and paste method appears to codify the very practice that for decades has plagued the developers of virtually every product development organization: managers reduce the estimates of duration provided by the developers. Thus, it destroys trust between developers and managers, rather than building trust. It alienates the very individuals whose behavior has a direct and significant impact on the logistical performance of a product development enterprise. This alone makes the cut and paste method undesirable.
A second approach is to use a control chart. By this approach, we simply graph normalized values of project duration on a control chart. The planned (baseline) duration estimates of the projects are used as the normalizing values. For example, a project that had a planned duration of 100 business days and an actual duration of 140 business days would be represented in the control chart with a normalized duration of 1.4. The difference between the control limit and the mean of the normalized duration values serves as the basis for calculating subsequent project tolerances.
What’s good about the control chart method? It captures all the variation in project duration exhibited by an organization. Thus, the method gives us an accurate estimate of the required tolerance value.
What is unacceptable about the control chart method? Today, the resulting tolerance calculations would be impractically large and entirely unacceptable for all concerned. At this writing, finding even one product development organization that can be considered in a state of statistical control would be a very daunting task. The degree of variation in project duration exhibited by virtually every product development organization is unpredictable and astronomically large. Therefore, the control chart method, while sound and reliable, is simply impractical at this time. Perhaps it will be in use by the time that the two of you become interested in the subject of this book. I can only hope that the state of project management improves before then.
The third method for calculating tolerance values is called the Root-Square-Error (RSE) method. The RSE method is the same mathematically valid method that has been used by engineers for many decades, for the tolerance design of physical products. It is directly adaptable to the tolerance design of projects.
The RSE method is illustrated in the next figure. In support of the RSE method, each developer provides two estimates of duration per task. First the developer provides an estimate that corresponds to a high level of confidence. We call this the “safe” estimate. Then, the developer provides an estimate of the mean process time. We call this the “average” estimate. The difference, D, between safe and average estimates for each task gives us a measure of the expected variation for the task. The component tolerance is calculated as the square root of the sum of the squares of the differences, for the tasks in each component sequence. The same calculation also provides an estimate of the project tolerance, with the difference values being those that correspond to the tasks of the primary sequence in the project.
A sample calculation is provided in the next figure. For that example, the sum of the differences squared equals 758 business days. The corresponding project tolerance is 28 business days. Notice that the 28-day tolerance value provides a commitment duration that corresponds to a comfortably high confidence level for the entire project.
Project tolerances calculated with the RSE method should be considered the absolute minimum values, since the RSE method takes into account only task-level variation.
Further, since the amounts of variation in project duration experienced today by virtually all product development organizations are tremendous, the tolerance values calculated with the RSE method are as inappropriately small as the values calculated by any other practical method. Given this observation, it remains for us to choose the one method that gives us the greatest benefit with the least amount of harm. For me, this is the RSE method, because it gets developers involved in the process of constructing the models of our projects. Developers contribute the two estimates of duration for each task; their contributions enhance trust, rather than destroying trust.
[So that others also might subscribe to The Project Management Soap Box, please share the following link with friends and colleagues.Subscribe!]