[10] Variation & Sequences of Tasks

To understand how variation changes as the number of tasks in a sequence increases, we begin with a computer model of a single task (section a of the figure). The one task is our entire project, initially. We model it as a log-normal distribution, with a mean duration of 10 days and a standard deviation of 5 days, values that are quite realistic for product development organizations today. The figure below shows how variation is affected by the number of tasks in a sequence.

Notice that as the number of tasks in the sequence increases from 1 to 2, 4, and 8, the degree of variation in the duration of the entire sequence increases dramatically. In fact, the degree of variation increases linearly with the square root of the number of tasks. Clearly, to be of any use, our models of projects must take into account variation. Were we to ignore the effects of variation, we would be omitting vastly important pieces of information from our predictive models. Yet, today the most popular project management tools virtually discourage project managers from even attempting to represent variation.

Now, let’s discuss interpretation. How should we interpret the sort of model shown in, say, Section (d) of the figure? Let’s begin by outlining the current, extremely widespread practice. Today, project managers and executives alike glance at the completely deterministic representations of their projects; they identify the so-called last scheduled day of work; and they make a commitment for that deterministic, wrong, and even boneheaded estimate of project duration. By allowing this practice, a project manager pretends that there is only a single value in that magical duration bucket, when, in fact, there is an infinity of values.

The histogram above the representation of eight tasks indicates that the actual duration of the sequence is entirely unpredictable over a very wide range of values. The operative word is unpredictable. This is the effect of variation. It makes it impossible for us to specify precise durations and to make precise commitments, without offering up bold-faced lies to executives and customers alike. At any time before a project is completed, we cannot possibly know the final duration of the project, no matter how emphatically we pretend that we can. So how should we interpret the 8-task model?

We should interpret the model, the histogram, and any desired or target value of duration in terms of our confidence that the sequence might be completed within the desired value of duration. For example, the histogram tells us that the probability of completing the entire sequence in 50 days or less is nearly zero. We know this, because nearly all of the histogram lies to the right of the 50-day mark. Consequently, the expectation of completing the sequence of tasks in 50 days or less comes with a near-zero level of confidence. Conversely, the expectation that the 8-task sequence can be completed within a duration of 110 days comes with an extremely high level of confidence. We know this, because nearly all of the histogram lies to the left of the 110-day mark.

We see, therefore, that we really cannot specify just one value of duration for the sequence of tasks. If it were possible for us to specify a single value of duration, we could display not a histogram but a vertical line at the corresponding value. However, within our very real universe, where variation abounds, this is simply not true to reality. Instead of specifying just a value duration, which implies the complete absence of variation, we and our customers are far better served if we identify the level of confidence that we prefer to maintain. Then, we can identify and communicate the corresponding estimate of duration, which supports our confidence level. In other words, either we specify a desired duration value and a corresponding level of confidence, or we are lying to ourselves and to our customers.

Unfortunately, this is not the widespread practice at this time. Today everyone simply looks at what appears to be the last scheduled day of work, for the project of interest, and makes a commitment for that date. This completely deterministic and equally boneheaded approach ignores completely all forms of variation in task duration and in project duration. Further, the deterministic estimate is itself extremely optimistic in virtually all cases, since all the effects of variation are excluded from the model of the project. Thus, commitments consistently correspond with exceptionally low confidence levels. The risk to customers and to the enterprise is extraordinarily high.

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

[9] The Mean of a Sum

In addition to representing individual tasks, within our project models, we also need to represent sequences of tasks, and we need to estimate the likely duration of each sequence. This brings us to our second guideline: The mean of a sum equals the sum of the means. The expected duration of a sequence of tasks equals the sum of the expected durations of the individual tasks. This simple rule is illustrated in the next figure.


This guideline is always true, so long as we are talking about sequential tasks and not parallel tasks. But already it is becoming evident that we need to focus on much more than just the sum of task durations. Variation is a strong function of the number of tasks in a sequence, as the figure suggests. Therefore, let’s begin to explore the role that variation plays, as we strive to construct our predictive models of projects.

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

[8] Variation &Accuracy Relative To Duration

The greatest contributor to the inaccuracy of today’s models of projects is the overwhelming ignorance of all the stakeholders, regarding the effects of variation. Consequently, this section discusses variation, its effects, techniques for modeling it, and techniques for managing it. This section also covers how to interpret the predictions made with our models of projects. This is vitally important, since the interpretations of virtually everyone today are entirely deterministic and wrong.

We begin with two simple rules with which to estimate the expected duration of sequences of tasks. Later in the section we expand our modeling techniques to include models of projects with parallel sequences. We will see that the role of variation is to counteract the widespread best practice known as concurrent engineering. But, for now we start with small steps.

When creating a new project plan, how should the duration of a single task be represented? We begin by recognizing that the duration of any task is a statistical (read that as unpredictable) quantity. As such, when we speak of the duration of a future task, necessarily we must speak in terms of statistical distributions, such as the distribution shown below.

For the purposes of mathematical modeling, the duration of a task is properly represented with the expected value of the distribution that corresponds to that task. The expected value of the distribution is the only unbiased estimate of the process time of any task. The mean of available data is our best estimate of the expected value.

However, within every organization there exist several forces that would have us represent the duration of a task with estimates other than the mean duration. Self-preservation is one such force. Self-preservation forces, created by counterproductive management policies, often motivate developers to provide estimates of duration that correspond to very high confidence levels. These longer estimates fall far to the right of the mean duration. Using such estimates yields gross overestimates of the duration of tasks and of sequences of tasks.

Another such force is the coercion created by executives and resource managers, who seem always to want the shortest possible representations of projects. These inappropriately short estimates of task duration fall far to the left of the mean duration.

Of course, both types of estimates are wrong and equally useless. The only unbiased estimator of the duration of any task is the expected value of the corresponding distribution; the mean of any corresponding data (in the rare cases where such data are available) is our best estimate of the expected value. Therefore, our first modeling guideline is: model the mean.

Now, let’s get practical. Our reality is that we almost never know the distribution associated with any task, for two reasons. First, even when task duration data are available, the data are already corrupted by the effects of widespread multitasking, which seems to plague every product development organization throughout the world.

Second, nearly every task of every new project is an entirely new task for which we have no data. Thus, each new development project constitutes a sample of size one, from an unknown and unknowable family of projects. Blame the word “new” in new-product development for this.

These observations may raise a question in you. What’s the point of using Robust Project Design, if we cannot even know the distribution of project duration that corresponds to any particular project? Let’s answer this question now, or surely it will become a serious obstacle to your continued learning.

Imagine that you can reach into a bucket of numbered poker chips and draw a single chip. Magically, the number on your chip becomes the actual duration of your project. However, you have a decision to make, before you reach into the bucket. The variation among the numbers contained in the bucket is astronomical. You can reach into the bucket without taking any prior action and live with the outcome, or you can first apply some of your own magic to the bucket. Your magic has the effect of reducing the variation among the numbers contained within the bucket. Should you work your magic before reaching for your one number?

All other factors being equal, choosing one number from a bucketful with astronomical variation leaves you exposed to all the adverse effects of that variation. You might get lucky and draw a small number. But there’s a much greater chance that you’ll draw a damagingly huge number. If by working your private magic you can reduce the degree of variation in the bucket, then you also reduce your risk of drawing a huge number.

Managing a project is tantamount to drawing a number from such a bucket. Robust Project Design is your private magic. Each time that you manage a project you draw one (and only one) number from a completely new bucket. Further, there will always be substantial variation. But Robust Project Design helps you to reduce the variation in every new bucket, before you draw your one number. It gives you the ability to reduce the impact of variation and the risk that variation creates for you, your developers, your management team, your customers, and your shareholders.

To begin using Robust Project Design, we model the duration of each task with the best available estimate of the mean duration. How can we arrive at estimates of mean duration? Initially, all we can do is ask the people who will be performing the tasks. As we and they gain experience with Robust Project Design, we can begin to improve our estimates of task duration. But, at all times we have to accept the reality that the estimates come with their own significant degree of variation.

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