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

As you read this content, please keep in mind this thought:  All the things that we do, which the practitioners and educators of our day group under the heading of project-management, we do for the purpose of managing resources more effectively.  

A Message for Project-Managers

Despite the work of W. Edwards Deming and, more recently, of Dr. Russell Ackoff and of Dr. Don Wheeler, not to mention the work of numerous 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, very often are treated as deterministic values. 

The already adverse effects, of this continually deterministic treatment of statistical quantities, are multiplied by a second factor: The estimates of project-duration virtually always are grossly optimistic, because these fail to account for many of the first-order effects of variation, on the expected value of project-duration. 

A third factor, which interacts with the two already mentioned, renders the task of managing knowledge-work resources virtually impossible for companies across the globe:  This third factor is the severe, ongoing over-commitment of knowledge-work resources, across multiple projects.  Together, these three factors destroy the wealth of shareholders at an astronomical rate, a rate that is second only to that achieved during the recent meltdown of the financial industry. 

However, you do control 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?

The answers to additional, important questions are beyond your reach.  These are:

1. What is the optimum start-date for the next project?

2. What is the expected value of duration-to-completion, for the next project?

3. On what date might we expect the next project to finish?

4. What date should we propose to the customer of the next project, as our commitment-date for the project?

Proper answers, to the latter set of questions, 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.  Nevertheless, you do bear the responsibility of fulfilling  your  role.  This is where Robust Project Design can be most useful to you. 

top

To Plan or to Iterate

Today there is a growing realization that the effective development of new products 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 effort all the use-cases and all the preferences of their customers. At the time that a large effort is started, information about the needs of the target customers is incomplete.  Hence, there is now a movement toward defining minimally detailed models of projects, replacing the more detailed models with processes such as agile and scrum. 

However, the need for an iterative process for developing new products in no way means that we can do without models.  Quite the contrary is true.  The need persists, to coordinate the efforts of many toward a common goal; meeting this need is the role of project-managers; and meeting it effectively requires the use of models of projects.  We simply must recognize that we cannot model a large project to the same level of detail throughout.  Instead, we need to construct models whose degrees of detail reflect our knowledge of the work at the time that we construct the models. 

top

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:

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.

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.

top

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.

top

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.

top

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.

top

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.

top

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.

As a last step, take a look at how the strength of the interaction between variation and the parallel structure increases, as the number of parallel tasks increases. The next figure shows a parametric curve of the strength of the interaction as a function of the number of tasks in parallel. Notice that the greatest contribution to the mean duration takes place when going from a single task to two tasks in parallel. The increase in the mean duration is 8 days in this case. However, although the additional contributions are not as large as the initial contribution, they are incremental contributions. They all add to the mean duration of the project.

Unfortunately, even when the project managers of today might want to correct the models of their projects, by taking the significant effects of variation into account, they find it exceedingly difficult, because the tools available to project managers make absolutely no provision for this. At this writing, the most widely distributed project management tools provide no means of calculating and including a project tolerance in the models of projects. Consequently, today’s project managers and the executives to whom they report would see only the ten tasks in parallel. They would select a commitment duration of 30 days, given the boneheaded misrepresentation provided by today’s tools and today's widespread practice.

Now, let’s return to our original example. Recall. We have a primary sequence of 8 tasks and two component sequences in parallel with the primary sequence. We are striving to estimate the mean duration, from the start of the project to the start of the assembly task. Of course, we’re interested in the mean duration to the project’s completion as well.

The first histogram in the figure shows the true value of the mean duration to the start of the assembly task. Notice that the true mean is 80 days, not the 70 day interval that the deterministic models of today would have us believe. The mean duration to the project’s completion is 90 days.

Now let’s explore the implications of what we’ve just discussed. Specifically, let’s see the degree to which your organizations and your careers are exposed to risk, by your own deterministic models of projects. The next figure compares the commitment duration based on the deterministic model of our little project. Virtually all your peers would propose a commitment duration of only 80 days for this project. By doing so, they would expose their superiors, their customers, and their careers to an inordinate level of risk, as the lower portion of the figure shows clearly.

The 80 day commitment based on the deterministic model comes with an extremely low confidence level. The probability of completing this little project within an 80 day interval is less than 20%. The corresponding risk to customers and to careers is greater than 80%. In fact, the deterministic 80 day duration equals only the mean duration to the start of the assembly task. Further, the mean duration of the project comes with an unacceptably low confidence level of approximately 50%. Whereas, a committed duration that brings with it a comfortably high confidence level (from the perspective of the customer of the project) extends beyond 110 days.

Next, I would like you to consider the following. An error of this magnitude is created by a deterministic model of a very small project. This simple project has but two component sequences in parallel with the primary sequence of tasks. A real project doesn’t have just two or three parallel sequences. It has a dozen or more. Therefore, when we deal with real projects, the effects of variation are far more pronounced than this simple illustration suggests. The deterministic models of real projects are overwhelmingly wrong, all because they ignore the effects of variation. The risks to which project managers, executives, their businesses, and their customers are exposed are correspondingly large.

Clearly, the effects of variation must not be ignored. Instead, variation must be understood and managed, so that its adverse effects might be diminished. In the subsequent articles I’ll show you techniques for limiting the adverse effects of variation.

top

It is clear that the interaction between variation and the parallel structure of our project models is quite strong. The prediction error caused by ignoring this interaction is significant. We have only two courses of action available to us, if we want useful predictive models. First, we can simply estimate the magnitude of the interaction, thereby including its effect in our predictive models. Second, we can take measures to diminish the magnitude of the interaction effect.

To diminish the magnitude of the interaction effect, component sequences can and should be started earlier. Doing so greatly increases our level of confidence that the outputs of the component sequences will be available for the subsequent assembly task, rather than risking a delay of the assembly task. The degree to which we move early each component sequence is called the component tolerance. This approach is illustrated with our small project, in the next figure.

The first task in each path of the project is an entry task. These, necessarily, are scheduled. Component tolerances tell us how to schedule the start of each entry task. However, this method of scheduling entry tasks is useful if and only if we are working exclusively with a single-project system of resources, i.e. a team of resources that is fully dedicated to a single project and whose team members have no significant commitments to other projects. In a multiproject environment, this method is problematic, as it causes us to schedule the starts of entry tasks as late as possible (a.l.a.p.), taking into account the component tolerance. For reasons that are beyond the scope of this writing, the ALEP approach creates problems within a multiproject environment.

Finally, there are other situation where we cannot apply this simple technique directly, even when we are working with a single-project model. We discuss one such situation in the next article.

top

Frequently enough we encounter a logistical network with a diamond structure to it. This happens when a task in the primary sequence provides inputs to two successors, one of which is in the primary sequence and the second is in a component sequence. This is illustrated in the next figure, which shows the primary sequence in red and the component sequence in blue.

The diamond structure doesn’t appear to be a problem, until we calculate the component tolerance and insert it into our model of the network. When we do this, we end up with a significant gap in the primary sequence of the network. This is illustrated in the next figure.

The gap is created by two factors. First, the size of the component tolerance, which is based on the variation associated with the entire component sequence, is large. Second, the precedence dependency between the last task in the component sequence and its predecessor in the primary sequence prevents the component sequence from moving to the left. Consequently, when we include the component tolerances in our model of the project, we end up with a what appears to be a most discomforting gap in the primary sequence.

The knee-jerk response of most project managers today is to force the gap to vanish. Unfortunately, the resulting model ignores completely the strong interaction between variation and the parallel structure. As such, the resulting model is overwhelmingly wrong; it grossly underestimates the duration of the project; and it misleads project managers and decision-makers into making commitments that cannot be met by the resources of the enterprise. But, the resulting picture is strikingly comforting for those who lack any understanding of variation, despite the fact that accuracy relative to duration is destroyed.

There is a solution, of course. Rather than eliminating the gap arbitrarily, we can move the earlier part of the component sequence to the left. Specifically, we move early the portion of the component sequence that precedes the problem dependency. By doing so, we uncouple most of the component sequence from the diamond-shaped feature of the network, and we diminish the magnitude of the interaction effect. This is shown in the next figure.

However, this tactic does not allow us to eliminate the gap entirely. If we did so, we too would be ignoring the interaction between variation and the parallel structure. Instead, our robust project design tactic lets us reduce the magnitude of the interaction, which we model with a smaller but finite gap. The smaller gap (shown in the next figure) provides a correction factor that at this time we can only estimate.

How should we estimate the magnitude of the correction factor? At this writing, the most practical way to estimate it is simply by calculating a component tolerance for the parallel segments that are involved directly in the diamond-shaped structure. This gives us smaller component tolerances, which in turn create a smaller gap. But we can do this only in cases where we can uncouple the earlier segment of the longer component sequence.  If we cannot uncouple the earlier segment of the longer component sequence, then it is best that we leave the full component tolerance and the resulting gap alone. 

top

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.

top

In his 1997 work of fiction, Dr. E. M. Goldratt introduced the Critical Chain concept. The book’s publication triggered a seemingly unending discussion regarding the virtues of the Critical Chain versus those of the Critical Path. The discussions always focused on the one minor distinction between the definitions of Critical Chain and Critical Path, the fact that the definition of a project’s Critical Chain accounts for resource dependencies explicitly, whereas the Critical Path definition does not. This was most unfortunate. The more significant contribution of the Critical Chain model is that it is the first logistical model of projects that facilitates and even popularizes attempts to estimate and manage variation.

The Critical Chain of a project is defined as the longest sequence of dependent events that prevents the project plan from being any shorter. This differs from the popular definition of a Critical Path in that the Critical Chain definition, by stipulating dependent events, opens the door to resource dependencies as well as to precedence dependencies.

The Critical Chain definition is illustrated in the next figure. In that figure, each of the task-bar colors denotes a different skill. Further, for the sake of simplicity, the model in the figure presumes that only one person of each skill set is available.

The Critical Chain includes the tasks denoted by GR10, Blue30, Blue15, and Red15. The sequence of the tasks is determined as much by the limited availability of resources as it is determined by precedence dependencies. For this reason, the tasks in the Critical Chain typically span multiple paths of the project plan, a characteristic that at times creates a certain degree of visual confusion.

A more readily understood representation of the same project plan shows the Critical Chain tasks all at the same (middle) level. This “fishbone” representation (next figure), with each component sequence either above or below the Critical Chain, is most useful when determining where component tolerances are needed.

The Critical Chain model stipulates that a component tolerance is needed wherever a non critical component sequence provides an input for a critical chain task. The component tolerances are indicated by the shorter, blue line segments with round ends.

The commitment duration of the project is represented by the distance from the wall at the left of the figure (which represents the project's start date) to the yellow circle at the right of the figure. The long, blue bar at the right end of the figure denotes the project tolerance.

Notice that in this case the upper component sequence requires a tolerance that “stretches” the Critical Chain. That is, the component tolerance is large enough to create a so-called gap in the Critical Chain of the project. This apparent gap often becomes a point of contention for many managers. But the contention is created more by an insufficient understanding of variation and by a complete lack of understanding of multiproject operations. The latter causes many managers to conclude that all newly defined projects must be started immediately. In fact, within a properly managed multiproject operation, entire projects are scheduled so that they can start well after they are planned. Thus, in such an operation there is no “wall” that would prevent the entire upper sequence of tasks from being moved earlier (to the left), relative to the Critical Chain of the project.

Further, it is worth observing that the concept of a Critical Chain is no less deterministic than the concept of a Critical Path. The very concept of criticality, in fact, is a deterministic concept. Still, the complete Critical Chain model is considerably more useful than the Critical Path model, in large part because it brings with it an explicit reminder of two assumptions that are the foundation of all project models. First, the Critical Chain model assumes that resources work each task at a full level of effort, from start to finish. This runs contrary to the practice of institutionalized multitasking, which today is the most wasteful of management practices, as anyone even remotely aware of queuing theory can verify.

Second, the Critical Chain model assumes that downstream tasks are started as soon as their inputs are available, rather than being started at scheduled times. In other words, the behavior of the resources is event-driven rather than being date-driven, not unlike the behavior of the members of any relay race team.

The Critical Chain model is not the end-all of project models. A skilled statistician with a computer and an appropriately designed Monte Carlo package could do better than the Critical Chain model, but not by much and certainly not with the same minor level of effort needed to construct a Critical Chain project plan.

top

The next figure illustrates many of the features that make up a robust project plan. Specifically, the tasks of the primary sequence of the plan are identified, as are the tasks of the component sequences. Further, the component tolerances and, more importantly, the project tolerance are included as integral parts of the plan. Finally, the commitment date is clearly indicated, after having been selected so as to provide an appropriately high level of confidence that the project can be delivered on or before the commitment date.

However, the most important of these features cannot be shown by any figure. The most important features of a robust project plan are the plan’s four forms of accuracy: accuracy with respect to the stakeholders' expectations, logistics, duration, and marginal cost. These features are the result of discipline, yours and that of your superiors.

This concludes the Robust Project Design content. As I stated clearly at the beginning, good plans are absolutely necessary for successful operations, but they are in no way sufficient. Today, the widespread practice of sharing resources among projects without prioritization ensures that the single-project model is little more than a recipe for disappointment. For truly effective operations in product development today, we need an Enterprise Project Management system.  The Total Matrix Program exists not only to install such a system but also to design the entire corporation around it, so that its full performance can be realized reliably, indefinitely. 

top