[12.1] A Brief Discussion On Psychological Inertia

Dear Reader,

The article to which the link below will take you discusses an example of psychological inertia that you'll find interesting, particularly if you anticipate deploying the critical chain model throughout your multiproject enterprise.

http://www.pdinstitute.com/shareholder_value/2004/10/10-alap-versus-asap-case-of.html

[So that others might also subscribe to Shareholder Value, please share the following link with friends, colleagues, and your boss. :-) Subscribe!]

[12] Project Tolerance

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!]

[11] A Truer Representation

One may wonder why so many executives make project commitments that are overwhelmingly optimistic and associated with exceptionally high risk. Consider the next figure, which shows only the 8-task sequence and the accompanying histogram. The histogram suggests that the common practice of making a commitment for what appears the last scheduled day of work, time T1, leads to unacceptably high risk. The probability of completing the 8-task sequence by time T1 is only 50%. Yet, this is precisely what nearly all project managers end up with today. Why does virtually every executive require this obviously wrong approach to estimating project duration?



The reason is provided by a brief scrutiny of our project management software tools. Except for the rarest of cases, every project plan that is created with today’s project management software tools is displayed as a stack of task bars, much like the task bars shown in the above figure, and the histogram never accompanies the display of task bars. Decision-makers see only the task bars with clearly defined starts and ends. Worse, our software tools go so far as to display dates, which appear to coincide unquestionably with the starts and ends of the task bars. Inevitably, this totally deterministic display of erroneous information fools decision-makers into thinking that they and their project managers are capable of causing events to take place on specific dates. Our models of projects, in other words, are consistently and significantly misleading the decision-makers. Hence, the widespread practice today is for decision-makers, project managers, and at times even customers, to participate in what is nothing short of a grand self-deception.

How should information be displayed instead? Consider the next figure. If any event related to a project can be specified at all, that event is the start of the project. This indeed is a deterministic event, as are the starts of all the various sequences of tasks that one finds in a real project. However, once a sequence of tasks is underway, all subsequent task-start events within the sequence and all subsequent task-finish events within the sequence are entirely unpredictable. An appropriate display for a sequence of tasks should not pretend to predict precise times for these events.

A far truer representation is provided by the next figure, which shows a clearly defined edge only at the left-and end of the sequence. All the other task-start events and task-finish events associated with the sequence are omitted from the representation. Further, the color of the task bars is shown steadily and smoothly fading, from left to right, to indicate the increasing degree of uncertainty in our estimates of the downstream events.



The histogram, too, is depicted in a more appropriate manner. Rather than being displayed in solid colors, varying shades of red indicate the increasing risk associated with increasingly optimistic estimates of duration. The right-hand end of the histogram is shown with vanishingly small levels of red, indicating that this portion of the histogram and the corresponding estimates of duration can be associated with correspondingly low levels of risk.

If decision-makers were provided with this sort representation of their projects, their tendency to favor optimistic, high-risk estimates of duration would be greatly diminished. After all, how many ambitious executives would expose their careers to unnecessary risk?

We see, therefore, that the sadly deficient state of project models today is driven by the grossly deficient tools in widespread use. These tools have been designed and developed by people who lack even a rudimentary understanding of variation. The grossly deficient tools are used regularly by project managers whose understanding of variation is equally lacking. Further, the reports created with the tools consistently mislead decision-makers. The erroneous reports regularly lull decision-makers into a false sense of optimism, which exposes them, their businesses, and their customers to inordinate levels of risk.

[So that others might also subscribe to Shareholder Value, please share the following link with friends, colleagues, and your boss. :-) Subscribe!]