The mean duration of a sequence of tasks, often called the expected value of duration, is a valid and useful concept. However, the probability of observing exactly the mean of any distribution is exactly zero. Therefore, we must be careful not to interpret the mean in this deterministic manner. Instead, it is more useful to interpret the mean value merely as a positional parameter for the corresponding distribution, an anchor point about which we can expect considerable variation.
Further, the confidence level associated with the mean value of duration is rarely acceptable in business settings. That confidence level can be as low as 50%. A more useful confidence level might be, say, 95%. The duration that corresponds to the greater confidence level becomes the promised or committed duration. Therefore, we need a new concept, one that helps us bridge the difference between the mean value of duration and the committed duration. I call this the project tolerance.
The project tolerance is a necessary component of any project’s design. It indicates our estimate of the variation in duration, to which the project is exposed. Some refer to this design feature as the project buffer. However, the word buffer brings with it a number of unfortunate connotations, particularly among high-level managers and executives. To these busy people, the word buffer smacks of padding and sandbagging. Frequently their instantaneous response, upon hearing the term buffer, is to mandate that such buffers be removed immediately from the designs of their projects. The inevitable result is that yet another grand lie is fabricated, since the resulting committed duration corresponds to the mean value and brings with it unacceptably high risk.
The term tolerance, however, is a technical term. For example, mechanical engineers use the concept of dimensional tolerancing when specifying the dimensions for components and products. Indeed, even engineers who have embraced the practice of robust product design continue to use the concept of dimensional tolerancing. They do so in an environment where variation in component dimensions at times is imperceptibly small. In the world of projects, where the degree of variation that we encounter is three to four orders of magnitude greater than that encountered in product design, the concept of project tolerance makes even more sense. I would go so far as to say that the project tolerance is an indispensable design component of every robust project model.
With the model of a simple sequence of tasks we have addressed the subject of variation, at least to the extent that variation affects such sequences. We have even taken a first important step toward managing that variation, by defining the concept of project tolerance. However, no real project ever consists of a single sequence of tasks. Real projects always include multiple parallel sequences of tasks. With the next chapter we explore how variation and the parallel structure of project models interact. The strength of their interaction will surprise you.
[So that others might also subscribe to Shareholder Value, please share the following link with friends, colleagues, and your boss. :-) Subscribe!]