[9] The Mean of a Sum

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


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

[8] 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.

[7] Robust Project Planning(tm) ...continued.

Once your preparations are complete, call in the first few members of your team, and use the Robust Project Planning process. Starting with one of the tangible deliverables from your list, ask the following five questions:

1) “What is this deliverable?” The purpose of this first question is to achieve the same, clear understanding as to what’s expected of the project. The responsibility for achieving this clarity rests with the project manager, even though the answer comes from the recipient, which could be the customer, someone in marketing, or even a high-level manager of the organization. The written description of each tangible deliverable (final or intermediate) is the destination for which the predecessor plans an itinerary. It is vitally important that successor and predecessor, both, plan to reach the same destination.

The answer to this question should be written on a white Post-It note.

2) “Who makes this deliverable happen?” When this question is asked for the first time for a specific tangible deliverable, the answer can come from any number of sources within the organization itself. When this question is asked in reference to any intermediate deliverable, the answer comes from the recipient of the intermediate deliverable. Of course, this question does little more than identify the resource who creates the deliverable. But this is useful information nevertheless.

The answer to this question should be written on new, yellow Post-It note.

3) “What’s the last significant thing that you do?” This question is asked of the resource who is expected the deliverable. Note the use of the word “last.” This is done purposely, to prevent the individual from providing a long list of micro-steps, which have no business being included in the logistical network. Understand, too, that the answer to this third question is nothing more than the label of a task. It could be anything, and it would serve its purpose. Far more valuable information is provided by the answers to questions 4 and 5, below.

The answer to this question should be written on the same yellow Post-It note used for the answer to question 2.

4) “What tangible inputs do you need?” The answer to this question defines the interaction between the team member from whom we expect a specific deliverable and other team members who provide his/her required inputs. This and all similar exchanges of inputs and outputs define the logistical network of the project.

Notice, too, that the answer to this question is very much process-specific. Only the task owner has the experience with which to define the correct set of inputs for his/her task. For this reason, the timely participation of all team members in the creation of the project plan is indispensable.

The description of each of the tangible inputs provided as the answer to this question should be written on a separate, white Post-It notes. Arrows, from each input to the task that needs it, should be used to capture the logistical relationship.

5) “Are these tangible inputs enough?” The final question provides a simple test for logical sufficiency. Usually, the response of the involved team member, to this question, is “Nothing more. I’ve listed all the required inputs.” But occasionally this last question triggers the team member’s memory and causes the contributor to remember an otherwise missing input. Such occasional discoveries typically avoid many months of unnecessary delays.

The description of any additional inputs identified in response to this question should be written on separate white Post-It notes, with arrows to the description of the task (yellow Post-It note) that needs them.

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 confusion.

The Robust Project Planning process creates a flow of information about the needs of the customer of the project. That flow begins at the customer and moves upstream, ever deeper within the organization. This is illustrated by the next figure. As the flow of information continues, 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.

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

Once the logic of your logistical 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. To make this part of the Robust Project 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 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.

[6] Robust Project Planning(tm)

Accuracy relative to logistics is achieved best with reverse planning, which defines a necessity-based logistical network of activities and exchanges if inputs and outputs. Such necessity-based planning processes provide three outstandingly valuable benefits. First, they provide logistical networks that are complete. So long as all the players truly understand their jobs, as they all claim to do, all the intermediate inputs become captured by the planning process automatically. The resulting logistical networks, which are the backbones of project plans, capture all the significant work items. Further, they capture the work items in the correct sequence.

Second, since reverse planning processes are necessity based, no unnecessary intermediate inputs and no unnecessary activities find their way into the logistical network of the project. Thus, not only are the resulting project plans more complete. They are also devoid of unnecessary effort.

Finally, reverse planning processes automatically capture all the interactions among the members of a project team, and they exclude the countless micro-steps that are better managed directly by the team members and not by the project managers.

The Robust Project Planning is no exception. It is, in fact, an extremely simple and highly effective process with which a diligent project manager consistently can achieve accuracy relative to logistics. The process requires only that the project manager acquire the answers to five simple questions repeatedly, beginning with each of the tangible deliverables identified by the management team.

When using the Robust Project Planning process, it is useful to avoid the simultaneous use of software. While doing the difficult and important work of thinking, you and the members of your team need a view of the entire logistical network at once. You need the big picture view of the logic of your plan. This is simply not possible with a computer. A computer screen limits your view to a postage-stamp-sized segment of your plan, making it difficult for you and your team members to follow the logic of your network and, more importantly, making it difficult for you and your team members to spot the mistakes.

To really understand this unfortunate limitation created by computer screens, do the following exercise. Open any large map and plan an itinerary from one point on the map to five or six consecutive destinations. But, rather than allowing yourself to see the entire map in one eyeful, restrict your view of the map, by looking through the cardboard tube at the center of a roll of paper towels. You’ll understand very quickly the degree to which your team members will become frustrated by the highly limited view of the logistical network that a computer screen (or digital projector) provides for them.

A far more effective approach is to use Post-It notes while doing the hard work of thinking with your team members. With Post-It notes and large sheets of flipchart paper, you and your team can tackle a fairly large effort easily, all the while retaining the ability to see the big picture. At each step of the process, capture their answers to your five questions (see below) on white or yellow Post-It notes. Descriptions of required inputs (a final deliverable is an input to the customer) go on white Post-It notes. Task descriptions go on yellow Post-It notes.

By building the logistical network manually with Post-It notes, rather than moving directly to your software tool, you also avoid the annoyances, delays, and frustrations created by any idiosyncrasies of your software tool. These often impede the thinking process of your team. Certainly, the final version of your logistical network will end up in software. But the data entry should be nothing more than the final step, prior to the project becoming active.

Finally, prepare your conference room for the planning session. The walls of the room should be bare, rather than being cluttered with plaques or artwork. You’ll need them bare, so that your sheets of flipchart paper can be displayed and moved easily. Arrange for refreshments and snacks to be available throughout the planning process, so that team members find contributing to the planning process a pleasant and rewarding experience. And be absolutely certain that the first form of accuracy, accuracy relative to deliverables, has been achieved.

Once your preparations are complete.... [to be continued soon]

[5] 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.

They are wrong for two reasons. First, today it is quite possible to schedule invention. All that’s required is expertise in TRIZ, the Theory for the Resolution of Inventive Problems. A detailed discussion of TRIZ is beyond the scope of this small book. But I encourage you strongly to educate yourselves about this subject. Read first "And Suddenly the Inventor Appeared" by Genrich Altshuller.

Second, our inability to predict the future in no way justifies the conclusion that all planning is a waste of time. Indeed, we cannot know the future. For example, we may expect to proceed in a specific direction, with the design of a product. But, depending on the outcome of initial evaluations of competing technologies, the direction of our development effort may change, and we cannot know at the start of a project how the evaluations will turn out.

Does this mean that we should do no planning at all? Of course not! Planning a project is not unlike planning a long road trip. Initially we may decide to take a specific interstate highway, to reach our destination. But road construction and random accidents can easily cause us to make unanticipated changes. We are still far better off if we start our trip with a plan than if we start our trip with no plan at all, because the lack of any plan brings with it numerous additional problems that we might otherwise anticipate and avoid.

The same is true of projects. We cannot know the outcome of initial evaluations of key technologies, which often occur some months after the start of a project, and we may have to do some re-planning, once we gain important new knowledge. But, by planning the project to the best of our ability before we start it, we can avoid numerous additional problems that otherwise would surely create unnecessary delays and greater variation in both duration and budget.

“I know my job. I don’ t need to plan my work.” You’ll hear this one too, from many quarters. Again, this sort of thinking is shortsighted and simply wrong. We don’t create project plans so that we can micromanage the work of individual contributors (although those individuals often would benefit from scrutinizing their own work processes). The people whom we select as members of our project teams are already experts at their jobs, and we don’t need to manage the details of their work. But we do need to understand the interactions among the members of the project team. We do need to identify, monitor, and manage all the significant exchanges of inputs and outputs among the developers who contribute to our projects. This is the real purpose of a project plan. Therefore, all those who expect to contribute to the successful completion of a project must also contribute to the successful creation of that project’s plan. Their refusal to help build the plan is nothing less than the deliberate sabotage of the company’s speed to market.

“I’m not sure that we can afford to spend a week per project, just to create project plans.” Difficult to believe though it may be, these were the words spoken to me by the director of a product development organization. This sort of thinking, particularly among executives, is nothing short of complete stupidity. The value of effective project plans is stated most clearly by the next figure. Study it carefully.

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 chapter, contrast the results of this simplistic approach with the results of the Robust Project Planning(tm) process.

[4] 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 models requires that the models of our projects exhibit four forms of accuracy. These are:

1) Accuracy relative to deliverables.
2) Accuracy relative to logistics.
3) Accuracy relative to duration.
4) Accuracy relative to budget.

The four degrees of accuracy are hierarchical. Accuracy relative to deliverables is required before accuracy relative to logistics can be achieved. Accuracy relative to logistics lets us identify the required activities and the interactions among the various resources. It is necessary for accuracy relative to duration. The latter, in turn, is needed for accuracy relative to budget.

Therefore, the overall accuracy of a project’s model begins with the 1st form of accuracy, accuracy relative to deliverables. The tangible deliverables expected of a project must be defined clearly and completely, before the model of the project can be created.

Accuracy relative to deliverables is the responsibility of the customers of a project. The customers of any project include the customers of the enterprise and the leadership of the business, which represents the shareholders. As project managers, you bear a fiduciary responsibility. You are responsible for the overall accuracy of the model that you create, on behalf of the leadership team of your enterprise. Consequently, you must resist pressures to begin constructing a model of any project that lacks an agreed-upon list of tangible deliverables. In keeping with the iterative approach to product development, you cannot expect the list of tangible deliverables to be all-encompassing. But you must insist that expectations be well understood and well-defined for the limited project that you are about to undertake. In fact, you have a right to require that expectations be well-defined for any project that you are asked to undertake. This is accuracy relative to deliverables.

Accuracy relative to deliverables does not appear to be a difficult thing to achieve at this time. It is missing in many cases only because no attempt is made to achieve it. Once individuals are aware of the need to achieve accuracy relative to deliverables, they are usually quite capable of doing so. Therefore, I do not address accuracy relative to deliverables further.

Next on the hierarchy of accuracy there is accuracy relative to logistics. Accuracy relative to logistics is a product of the specific planning process that you use. Unfortunately, we do not study project planning in college. Consequently, very few people today possess an effective project planning process. The resulting project models lack accuracy relative to logistics to a substantial degree.

Today, most people who contribute to the construction of project models use a forward-going, workflow description approach to logistical planning. This is most unfortunate, for two reasons. First, the resulting logistical plan ends up with far too much detail, which severely limits the usefulness of the project’s model. Second, much of the work that is required for the successful completion of the project at hand is never included in the logistical plan. This happens because the conventional approach to logistical planning is not necessity based.

The alternative to this ineffective form of logistical planning is the Robust Project Planning Process, discussed in a subsequent chapter. Robust Project Planning yields logistical plans that are consistently complete and simultaneously devoid of unnecessary activities. Please study the corresponding segment of this book carefully, and practice the Robust Project Planning Process at every opportunity. If you use it consistently, it will serve you well for a lifetime.

After we achieve accuracy relative to logistics, we face the task of achieving accuracy relative to duration, with our project models. Here, virtually every project manager fails today, for the following reasons:

1) Due to damaging management practices, individual developers are justifiably unwilling to provide estimates of the process time of their tasks.

2) Due to widespread multitasking, individual developers today are entirely incapable of estimating the process time of their tasks.

3) Due to their lack of understanding of variation, project managers today are entirely incapable of taking into account the many effects of variation, on project duration.

4) Due to their completely lack of understanding of variation, executives and managers today strive to use project models not as predictive tools but as prescriptive tools, in a misguided effort to improve the performance of their teams.

Any one of these factors is enough to prevent you from building project models that exhibit accuracy relative to duration. It is very likely that in the future you will face all these factors, as do today’s project managers, for whom accuracy relative to duration is an unimaginable nirvana.

Although in this book I discuss the Robust Project 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 today, as does that of resource managers and executives.

Finally, we have accuracy relative to the budget. This is at the top of the hierarchy of accuracies. It relies upon all the other forms of accuracy. Thus, it is compromised to the greatest degree.

Accuracy relative to the budget is compromised further by the widespread misapplication of the Earned Value Measurement System, particularly among defense contractors. The section on accuracy relative to the budget addresses the Earned Value Measurement System, highlighting the changes that are needed to make the Earned Value Measurement System useful rather than counterproductive.

[3] 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 project plans and project 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 persists as well. 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.

[2] Introduction

During the 4th quarter of 2001 the leadership team of Confluence, a software development company in Pittsburgh, undertook four simple but extraordinarily powerful changes to the management process of the company.

* First, the leadership team adopted an enterprise-wide prioritization and scheduling policy for all the projects of the company.

* Second, the leadership team enacted a weekly meeting between a high-level executive and all the resource managers of the company, during which the near-term deployment of the company’s development resources was determined (that meeting continues at this writing).

* Third, the leadership team required the use of a more effective project-planning process for all new development projects.

* Fourth, the leadership team acknowledged the existence of variation in task duration and in project duration, by requiring the project plans of the enterprise to account for such variation in their designs.

The effectiveness of these changes is illustrated by the control chart of the duration of the projects of Confluence, for the two years before the management changes and for two years after the management changes. Average project duration was reduced from 140 business days per project to a mere 46 days per project. The rate of project completion increased from six projects per year to more than eleven projects per year. And throughout the entire period, Confluence did not hire a single additional developer.

Of the four changes that created such a massive improvement in the logistical performance of Confluence, the first two can be implemented exclusively by the leadership of a company (these will be discussed in a later work that I intend to leave for the two of you). No project manager possesses the authority with which to make the first two changes happen. But the latter two changes (the use of a more effective planning process and the development of project plans that capture and minimize the effects of variation) were merely enabled by the leadership of the company. These latter two changes are entirely within the span of authority of any willing project manager, and they are the heart of Robust Project Design. They will be within your span of authority during the early portions of your careers, when you are most likely to contribute to project plans or perhaps even to manage entire projects. I base the rest of this work on the assumption that at some time early in your careers one or both of you will be asked to fill the roles of project managers.

However, I must also caution you. Although your use of Robust Project Design will yield a measurable benefit, you cannot ever hope to achieve for your employer all that Confluence achieved, unless the leadership of your company deploys the same enterprise-wide multi-project scheduling policy and the weekly meetings. Still, your use of Robust Project Design can bring a non trivial improvement in performance, and it may even alert the leadership of your company that it is possible to nearly double the company’s throughput of projects without hiring a single additional developer, with just some minor policy changes. Your use of Robust Project Design also will provide you with useful, predictive models of your projects, rather than the highly misleading models that your counterparts will be creating.

[1] Robust Project Design

Project modeling as it should be.

Foreword

Our models of real projects are the tools that shape management decisions. Robust Project Design is the practice of creating models, of real projects, which yield unbiased estimates of project-duration, with minimum uncertainty in those estimates. Once available, the resulting models enable us to monitor the health of the corresponding projects and to make steadily improving predictions regarding the remaining duration, from the present to future events of interest.