Link your web site to this page, and you can share this material with your own audience.  If your IT department doesn't permit such a link, call me, and I'll provide written permission for you to make a local copy of this page.
Tony Rizzo, +1 908.264.8520

top

Introduction

Despite the work of W. Edwards Deming and more recently that of Russell Ackoff and of Don Wheeler, not to mention the work of others of comparable caliber, many who are responsible for the performance of knowledge-work companies continue to behave as if we existed in a universe devoid of variation.  Consequently, the estimates of project-duration, which these well-meaning individuals often use as the basis for commitments to the customers of their companies, are treated as deterministic values.  Worse, the estimates of project-duration also fail to reflect many of the first-order effects of variation, on the expected value of duration.  Therefore, in addition to being treated as deterministic values, the estimates of project-duration also are grossly optimistic, as inevitably are the resulting commitment dates that appear in proposals from such companies. 

The role of the project-managers of our day, within knowledge-work companies, is drastically different from that of the project-managers of fifty years ago, prior to the widespread adoption the shared-resource models.  Today's project-managers have no authority over resources, and their projects are no longer blessed with dedicated teams of resources.  Consequently, you and the others, who continue to be held accountable for managing the projects of knowledge-work companies, no longer control any resources.  You control instead only how the answers to a limited number of important questions are determined, with respect to each project.  These questions are:

1. Do we have the requisite skills for this project?

2. How long could we expect this project to last, if the project had a dedicated team of resources?

3. What duration could we propose to the customer, with a high degree of confidence, if the project had a dedicated team of resources?

4. What marginal cost could we expect our company to incur, if we performed this project?

Additional answers, such as the optimum start-date for a project, the project's expected value of duration in a shared-resource operation, its expected completion-date, and its commitment-date, are beyond the reach of any mere mortal in role of project-manager, at this writing.  These answers require a role that does not exist and skills that are not available to the knowledge-work companies of our day.  They require someone in the role of enterprise-analyst, whose skill in building models of physical systems extends well beyond the skill required to build models of individual projects.  There is that responsibility to fulfill  your  role.  That's where Robust Project Design can help. 

Robust Project Design is the practice of creating models (representations) of real projects, models that yield unbiased estimates of project duration and that also reflect the effects of variation.  The critical-chain model for individual projects is the basis of Robust Project Design.  However, unlike the apparent objective of many who advocate using the critical-chain model, the emphasis throughout this content is on building unbiased models that reflect the current state of a project. 

top

To Plan or to Iterate

Today there is a growing realization that effective product development requires an iterative process. This realization is greatest in the area of software development, where feedback from the users of software products is relatively quick and decisive.  Developers of software have learned that they cannot know at the beginning of a large development effort all the use-cases and all the preferences of their target customers. At the time that a large development effort is started, information about the needs of the target customers is incomplete. Hence, there is now a movement away from defining complete sets of specifications and, consequently, from designing models of entire development efforts.

However, this in no way means that we can do without plans and models. Quite the contrary is true. Our need to coordinate the efforts of many contributors toward a common goal persists. Creating a product that meets the needs and expectations of customers is still a requirement; it will remain a requirement forevermore. The need to develop products rapidly also persists. Speed is every bit as important as effectiveness, in product development. Thus, the job of project managers remains unchanged: to aid the many contributors, so that they might work together in the most effective manner possible and create the right products rapidly and cost-effectively.

The conflict between those who would use an iterative approach and those who would define specifications and develop appropriately detailed models of projects is really no conflict at all. Both sides of this conflict are correct. An iterative process is needed. But we also need project plans and well-designed project models. We simply must recognize that we cannot plan an entire, large development effort to the same level of detail. Instead, we design a strategy for the overall development effort, and we construct plans and detailed models only for the few steps immediately before us. Therefore, little has changed really, other than the scope of our project plans and the corresponding models. Instead of trying to define the mother of all project plans, we define many smaller project plans, in rapid succession. We then use these to model our systems of resources and their work, so that the leadership of an enterprise might make its predictions with an appropriate degree of accuracy and, more importantly, so that the entire flow of projects can proceed expediently.

Four Forms of Accuracy

In the book titled The New Economics, W. Edwards Deming states unequivocally, "Management is prediction."  Deming is on target. Executives and managers make predictions regularly, to shareholders, to customers, to banks, and even to the IRS. Some of these predictions involve the use of financial models (albeit many such financial models in use at this writing are highly questionable). The predictions required of executives are based in large part on the models of their projects, hence the need for unbiased, predictive models of projects.

Our need for predictive project models requires that our project models exhibit four forms of accuracy. These are:

Any one of these factors is enough to prevent you from building models that exhibit accuracy relative to duration. It is very likely that you face all these factors do today.  Although in this content I discuss the Total Matrix Planning process, I focus purposely on achieving accuracy relative to duration, by addressing variation at every step of the modeling process. In my opinion, this is where the understanding of project managers falls short to the greatest degree at this writing, as does that of resource managers and executives.

The final form of accuracy is accuracy relative to the marginal cost to the company. This is at the top of the hierarchy of accuracies; it relies upon all the earlier forms.  Thus, it is compromised to the greatest degree.

top

Resistance to Planning

There are several reasons why today project plans leave so much room for improvement. Not the least of these is a certain degree of resistance, on the part of developers, to contribute to project plans.

“We don’t plan R&D.” These were the words spoken to me by an otherwise intelligent and highly educated individual, a man with a Ph.D. in physics, of all things. This misconception is a major source of inadequate project plans, because it prevents so many developers from even trying to create a project plan. You can expect to encounter this sort of resistance among the more highly educated contributors, who normally tackle the most intellectually challenging work of your projects. The difficulty of the technical challenges that these people face regularly, particularly with problems that require inventive solutions, causes them to conclude that planning projects is nothing more than a fruitless waste of time. They could not be more wrong on this particular issue.

At the core of all these forms of resistance there is the complete lack of a planning process. Most people, even those who contribute to the plans of new projects willingly, don’t know how to create a useful project plan. This is not surprising. After all, none of us was ever offered an elective on project planning, in college. Nor were we offered such training by our employers. As a result, most of the people who contribute to your project plans do so simply by describing their activities, using a forward-going workflow description approach. As you read the next article, contrast the results of this simplistic approach with the results of the Total Matrix Planning process.

top

Total Matrix Planning

Accuracy relative to logistics is achieved best with reverse planning, which defines a necessity-based logistical network of activities and of the necessary exchanges of tangible items among the members of a project team.

When the first cluster of your logistical network is done, simply select one of the tangible inputs defined by as part of that first cluster, and continue asking the set of five questions.  Then, rather than moving across to one of the other tangible inputs at the same level, keep going deeper into the logistical network. Experience shows that this depth-first-search for information helps to keep team members focused, whereas a breadth-first-search for information (jumping from branch to branch) causes considerable confusion and compromises the quality of the resulting project plan.

The Total Matrix Planning process is the knowledge-work equivalent of Value Stream Mapping.  The process creates a flow of information that begins with the needs of the customer of the project. The information flow moves upstream, ever deeper within the organization as illustrated by the next figure. As the flow of information progresses, it identifies simultaneously all the required team members and all their tangible inputs and outputs. Thus, it identifies all the interactions among team members, which the project manager must monitor and manage.

When building a project plan, it isn’t necessary to gather the entire team at one time. It is sufficient only to bring the team members into the process individually, in a timely manner, and only for brief periods. Thus, creating consistently effective project plans that exhibit accuracy relative to logistics need not be time-consuming.

Admittedly, the Total Matrix Planning process can become slightly tedious at times. It is your responsibility, as project manager, to create the right level of discipline in your team members. You do this by being a master of the Total Matrix Planning process. Your skill with the process makes it that much easier for your team members to contribute successfully and quickly.

Once the logic of your network is complete, it’s time to bring your team members back into the planning facility, so that they can estimate the duration of their tasks.  If you've built your logistical network manually, with Post-It notes, you can make this part of the Total Matrix Planning process equally productive for your team members.  Prepare each of the large sheets of flipchart paper by numbering all the Post-It notes and by writing in the corner of the each sheet of flipchart paper the names of the team members whose contributions are contained on the sheet. This allows the team members to scan the larger sheets of flipchart paper quickly, rather than forcing them to read the individual Post-It notes, which at times can number in the hundreds.

As each team member comes back for this second pass at the plan, have him/her provide two estimates of task duration: a safe estimate with which the team member feel comfortable making a commitment, and a shorter estimate of the process time of each task. These estimates become the basis of your plan’s accuracy relative to duration, which is discussed in much greater detail in the next section.

Variation And 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.

top

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.

top

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.

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.

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 tolerances 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 tolerances. 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 article we explore how variation and the parallel structure of project models interact. The strength of their interaction will surprise you.

Psychological inertia is perhaps the greatest impediment to the creation of shareholder value. Let me use a brief example of to illustrate what I mean by psychological inertia.

Recently an otherwise intelligent individual on the eastern side of the pond (the Atlantic) argued that all entry tasks of a project should be scheduled to start as late as possible, a.l.a.p. This is the dogma for all who deploy Dr. E. M. Goldratt's critical chain model without thinking. The reasoning is that this practice keeps the number of tasks in process to a minimum. Unfortunately, this a.l.a.p. approach is nothing more than a vestige of the moribund TOC people's much earlier experience in manufacturing operations, rather than being an indication of experience in multiproject operations, such as those of product development organizations.

Prior to the introduction of the kanban method of manufacturing control, many manufacturing operations found themselves drowning in work in process (wip). The effective solution to this problem, of course, was to convert manufacturing operations from PUSH to PULL. The switch to PULL essentially withheld materials from the manufacturing operations until the materials were needed. This is where the a.l.a.p. approach breathed its first breath.

The a.l.a.p. approach also appears to make sense in the world of projects, but only if one's paradigm is limited to one-project thinking.  Per Goldratt's critical chain model, the sizes of component tolerances (feeding buffers for moribund TOC folks) are based solely upon the estimates of variation of duration in their respective component sequences (feeding chains for the TOC folks). Each time that a component tolerance is calculated, only the respective component sequence of tasks in that one project is considered. Interactions among projects, through the shared resources of a multiproject environment, are not considered. And there's the rub.

In an effectively managed multiproject environment, projects are scheduled according to the availability of a few rate-limiting resources. The multiproject scheduling process ensures that these rate-limiting resources are not overcommitted across projects. But no such attempt to prevent the over-commitment of non rate-limiting resources is made, because none is needed. All the non rate-limiting resources have lower relative utilization levels than the rate-limiting resources.

Since the non rate-limiting resources have lower relative utilization levels, these resources need only the ability to properly prioritize their tasks, in real time, which inevitably they do. With each task prioritization decision, a non rate-limiting resource chooses among several tasks, each of which may be associated with a component sequence of a different project. The decision to focus on one task (the right task) inevitably delays the starts of all the other component tasks earmarked for that same resource.

Each such delay expends a portion of the component tolerance associated with the delayed task. Since the sizes of the component tolerances are based solely upon the variation in the respective component sequences, per the a.l.a.p. approach, the tolerances are insufficiently large to absorb the inevitable delays experience by the many less urgent tasks. Thus, variation yet again is allowed to have an unfavorable impact on the probability that all projects might be completed in a timely manner.

A much sounder approach is to forgo the vestigial concept of a.l.a.p. and to schedule the entry tasks of each project to start as soon as possible, meaning as soon as the project is released to the system of resources. This approach causes the effective component tolerances to be much larger and much more able to absorb the impact of the delays, as the non rate-limiting resources properly prioritize their queues of tasks.

What about the possibility of starting tasks so soon as to create rework? The few tasks that might cause such rework can be identified readily by the project team, at the time that each project is planned. These few tasks can be positioned as needed relative to their projects, with precedence dependencies specified precisely to prevent such rework.

So, what does all this have to do with shareholder value? Nothing, and everything! This is just one example where our psychological inertia causes us to make decisions that are counterproductive. By no stretch of the imagination is it the only example. Our organizations are chockfull of policies, measurements, and management practices that limit their ability to create wealth for shareholders. It is wise to hunt down such policies and to question their continued existence. Inevitably we'll find that many of the policies that drive day-to-day decisions are in need of replacement.

We begin with a simple example of a project model with a parallel structure. This is shown in the next figure. For the sake of simplicity, every task in the model has an expected duration of 10 days and a standard deviation of 5 days. The primary (longest) sequence consists of 8 tasks, the last of which is an assembly task. The assembly task is shown in light yellow. The model also includes two component sequences, the outputs of which are required at the start of the assembly task. While this model is indeed very simple, it is sufficient to demonstrate the strength of the interaction between variation and concurrent sequences, which create the parallel structure.

The next figure shows the partial numerical results of a Monte Carlo analysis. Section (a) of the figure shows the results of the first seven tasks of the primary sequence alone. Notice that the mean duration is 70 days. The variation about that 70-day mean is significant. Sections (b) and (c) of the figure show the partial results for the two component sequences. Notice that each of the component sequences is modeled as starting on day 30 of the Monte Carlo simulation. Each of the component sequences has an average duration of 40 days and a degree of variation that rivals that of the longer sequence. The mean value for the duration, from the start of the project to the completion of the two component sequences, is also 70 days.

Now let’s ask the difficult question. The partial numerical results show that the mean duration from the start of the project to the completion of the 7 task sequence is 70 days. The partial results also show that the mean duration from the start of the project to the completion of the two component sequences is also 70 days. What might most people expect as the mean duration from the start of the project to the start of task no. 8, the assembly task?

Given the current, extremely widespread practice of selecting a commitment duration that matches what looks like the last scheduled day of work, we have to conclude that most executives, who rely on the models crafted by their project managers (as well as the project managers), would expect day 70 to coincide with the mean start time of the assembly task. Most executives and their project managers would be wrong.

To understand just how wrong, consider an even simpler project, which consists of just two tasks in parallel. The project is shown in the next figure. Each task is modeled with a Log-Normal distribution, with a mean duration of 30 days and a standard deviation is 14 days. The mean duration is indicated by the thick blue lines over the histograms. These coincide with the ends of the task bars.

For this even smaller project, the mean duration is certainly not 30 days, as the current widespread practice suggests. Since the two 30 day tasks are in parallel, the project isn’t finished until both tasks are finished. Consequently, the longer of the two tasks always determines the duration of the little project, and the parallel structure acts as a highest-only-pass filter. The result is a two-factor interaction between variation and the parallel structure of the model. The strength of this two-factor interaction is apparent in the next figure, which shows the histogram of project duration, in yellow.

The yellow histogram is the statistical equivalent of the two tasks in parallel. The mean duration indicated by the statistically equivalent representation is 38 days. This corresponds to the mean start time of the subsequent assembly task.

The interaction between variation and the parallel task structure appears to add 8 days to the mean duration of the little project. The mean start of the subsequent assembly task appears to be delayed by 8 days. Of course, in reality there is no delay. It only appears that there is a delay to us, because our expectations have been shaped by an incorrect model, a model that ignores the interaction effect entirely. The expectations of decision-makers are continually shaped by similarly incorrect models of their projects.

Now let’s look at a slightly more realistic model. This time we use a model that has 10 parallel tasks, all with a mean duration of 30 days, just like the tasks in the previous case. The results for the 10 task model are shown below. The upper histogram shows the mean duration and the degree of variation associated with each of the ten tasks. The yellow histogram shows the statistically equivalent representation of the entire project.

The mean duration for the entire project is 56 days, nearly twice the 30 day commitment duration that the current, widespread practice causes decision-makers to specify. In fact, the probability of having the entire project completed within a 30 day interval is less than 1%. Further, the mean duration for the entire project comes with a confidence level of less than 60%, entirely too low for any customer whose millions of dollars may be at risk. To achieve a comfortably high confidence level of, say, 95%, we would need to select a commitment duration of 83 days, nearly three times longer than the duration suggested by the current practice.