The PM Soap Box

[23] For Loryn, Another WayTo Look At the Problem

2005-02-19T16:41:00.000-05:00

Loryn, you've inspired me to action, if only for a brief interval.

ANOTHER WAY TO LOOK AT THE PROBLEM

Multitasking is the visible piece of the problem for product development organizations and for IT organizations. This is the widespread behavior that causes a huge amount of damage and, ironically, is actually encouraged by managers. But there's another way to look at the problem.

Imagine that you run a product development organization with a payroll of, say, $50 million, and you have n people on your payroll (managers as well as developers). Are your shareholders getting the most out of that $50 million annual payroll? If your organization is like the vast majority of product development organizations, the answer is a resounding "no!" ...why? ...because much of your organization's capacity to complete projects, for which you are paying $50 million every year, is being misdirected to create pips, projects in progress, which ultimately are terminated, killed, thrown away. Here's what's really happening to your very expensive product development organization.

First, your marketing people are launching projects faster than your developers can complete them. This wouldn't be all that bad, were it not for the fact that once each project is launced you and your senior people expect the project to demonstrate progress. The only way that this can happen is for your resource managers to shift capacity from the existing (earlier) projects to the new project.

What happens to those existing projects? Well, they slow down, of course. They slow down further with each new project that is thrown into the mix. Unfortunately, you don't see this taking place. The process takes too long for anyone to notice it. And no one notices that the number of pips is growing without bound.

Eventually, of course, you are forced to notice the pitifully slow rate at which projects are completed. Eventually, you just can't ignore the pain. What do you then? You call in some big consulting firm, for very big bucks, and you follow their advice. You kill at least half of your active projects. So, half of your pips go poof.

One result of having half of your pips go poof is that the capacity released by each poof is refocused on the remaining projects, and those remaining projects speed up for awhile. Why do I say only for awhile? I say this, because you never change the conditions that create the steady build-up of pips. Those conditions continue to exist, and they continue to create the everbuilding pile of pips. They create a virtual mountain of new pips.

Stop! Think about what's happening. Your organization is experiencing a series of transients. These transients have a very long time constant, of approximately two to three years. The expensive consulting firm tells you to kill half your projects, and you do so. This is the beginning of the transient. But the expensive consulting firm never permanently changes how you manage your enterprise. So once the transient begins, the number of active projects begins to grow again, steadily, over a course of two or three years. After that time, you feel so much pain that you call another big, expensive consulting firm. And they again tell you to kill half your projects. And so it goes, year after year. You and your managers create a mountain of pips, and approximately half of them go poof every few years.

Now, think about all the capacity (read that as millions of payroll dollars) that goes into all the projects that you kill every few years. All that capacity is wasted, discarded, thrown away, never to be retrieved. Worse! All that capacity could be used to bring products to market at twice your current rate. That's the real damage, all the business that you might do but never actually do, because you continually spend a huge portion of your payroll on pips that go poof, instead of investing that payroll on generating faster throughput, more completed projects, more sales, and much more shareholder value.

How much is the damage? Experience (my experience and that of a number of my clients) shows that product development organizations (and IT organizations) worldwide could complete projects at twice their current rate, if such a huge portion of their development capacity weren't being diverted to generate a pile of pips that ultimately go poof. Imagine the loss. Fully half of their payroll is being wasted right now.

Imagine the value that could be realized! With their current payrolls, product development enterprises worldwide could bring products to market at twice their current rate. It's mind boggling. The development payroll stays fixed, yet twice as many products reach the market each and every year, forevermore. Twice as many buying opportunities are created for customers each and every year, forevermore. Twice as many actual purchases take place each and every year, forevermore. Twice as much revenue is generated each and every year, forevermore. And it's all done without any increase in headcount, at least in development.

What's the answer? The answer is to apply rigorously, to the people-systems of business, the concepts, the principles, and the methods of engineering.

[22] What's The Problem, Really? (Conclusion, part 3)

2004-12-18T16:42:00.000-05:00

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

In the previous article it became evident that multitasking had zero effect on mean resource utilization and on mean flow time. These functions, it seems are entirely under the indirect control of the executive of an enterprise, who decides the rate at which projects are launched and by so doing indirectly sets the mean rate at which tasks arrive at all resources, even our at generic resource. So, what does multitasking do?

The answer is made clear by the next figure, which shows the mean process time of tasks as a function of the load ratio and the multitasking policy level. The white circles in that figure denote that multitasking is banned. The yellow circles denote a multitasking policy of two tasks simultaneously, presumably from two different projects. The gold circles denote a multitasking policy of four tasks simultaneously. The red circles denote a multitasking policy of ten tasks simultaneously at every opportunity.

It is evident that multitasking acts as a multiplier of the process time of tasks. This isn't so stunning a revelation. A human being is a finite capacity device. The duration of a task that receives only a fraction of the capacity of a resource is inversely proportional to the level of capacity that the task actually receives. But the figure does yield a surprise. Specifically, the magnitude of the multitasking multiplier is itself a function of the load ratio. At low values of the load ratio, multitasking has almost zero effect. As the load ratio approaches a value of 1, the magnitude of the multitasking effect approaches its maximum value. This means that the effect of multitasking is actually an interaction effect.

This interaction, between multitasking and the load ratio, provides the most astute executives and managers with a unique opportunity to limit the damaging effects of multitasking. Per the robust design strategy defined by Dr. Genichi Taguchi decades ago, an informed management team can minimize the damaging effects of multitasking and not compromise throughput simply by maintaining the organization's actual load ratio at approximately 70%.

The next figure shows, both, the flow time curve (dark blue squares) and the same process time curves of the previous figure. Recall. Flow time is a function exclusively of the load ratio. Therefore, so long as the load ratio is held constant, the resulting mean flow time is also a constant.

With that said, consider the case where the load ratio is held constant at 94%. The flow time data for our generic resource shows that when the load ratio is constant at 94%, the mean flow time is just shy of 500% of planned task duration. This is true regardless of the multitasking policy level.

The process time data in that same figure shows that as the multitasking policy level increases, the process time becomes an increasingly larger portion of the overall flow time. But the queue time becomes correspondingly smaller. In other words, multitasking is letting us exchange time in process for time in queue. The mean flow time is constant, no matter what the multitasking policy level happens to be. The process time and the queue time see-saw back and forth as the multitasking policy level changes. With zero multitasking, the process time is at a minimum, and the queue time is at its maximum. As the degree of multitasking increases, process time becomes longer, and queue time becomes correspondingly shorter. But the flow time is unchanged.

So, what is multitasking really doing? Multitasking is creating only the illusion of progress, for executives. Multitasking lets every resource manager look any executive straight in the eye and say with a straight face, "We're working on your project, Mr. executive. It's making progress." What's never said is the rest of that thought: "Your project is making progress at the pace of a sick, pregnant snail."

The executive, in turn, sleeps soundly at night, comforted by the knowledge that he is really getting his money's worth out of those expensive developers, scientists, and engineers. After all, the monthly report from the CFO shows that the mean utilization level of the development staff is well above 100%. He's getting free overtime. Surely his enterprise is operating at peak productivity. Isn't it?

No, the executive's enterprise is not operating at peak productivity. Quite the contrary is true. Multitasking was costing Confluence the equivalent revenue of five project per year. When the dilution of capacity across too many active projects and multitasking defined the management paradigm of Confluence, the company's development resources were completing only six projects per year, on average. After the implementation of enterprise project management, EPM, those same resources were able to complete an average of eleven projects per year. The revenue from the five additional projects is all gravy, so to speak, and it cost virtually nothing to generate it.

The real decision faced by today's executives is illustrated by the next figure. The triangles in that figure denote the mean resource utilization. The blue squares denote the mean flow time of tasks. Both, utilization and flow time, are functions exclusively of the load ratio, which is controlled entirely by the executives of every enterprise. The figure clearly shows that these two measurements are in total conflict with each other. Policies and measurements designed to maximize utilization do exactly that. But they maximize utilization at the expense of flow time and speed to market. More importantly, as the Confluence case history and numerous others show unequivocally, they maximize utilization to the great detriment of real productivity and shareholder value.

The luxury of keeping people busy is costing product development organizations and IT organizations most dearly.

So what is the real problem? Finally we can answer the question posed in the titles of this and the previous two articles. The real problem is that we continue to design organizations in such a way as to optimize the wrong measurement, resource utilization. The policies, measurements, and executive practices of our enterprises are all based upon the false premise that keeping everybody busy automatically results in maximum shareholder value. In truth, keeping everybody busy results in a great destruction of shareholder value. I can say with great confidence that today at least 50% of the development payroll of nearly every product development organization is being wasted. But this is only the directly measurable waste. Much more than this is squandered worldwide, in the form of opportunity, revenue, and profits that might have been seized but never are. The great irony of it all is that our very efforts to save a few dollars are costing us millions upon millions more in lost earnings.

Is there a way out of this quagmire? Indeed there is. Confluence and others have given us indisputable proof that a useful, powerful solution is available to us. We begin to construct that solution step by step in the coming articles, as we design an Enterprise Project Management (EPM) system for product development and IT organizations. Stay tuned. These are exciting times.

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

[21] What's The Problem, Really?! continued

2004-11-25T23:48:00.000-05:00

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

To understand why multitasking exists, it is necessary to look at a multiproject operation through the eyes of a single knowledge worker. From the perspective of a single worker, a multiproject organization looks like an amorphous entity that generates tasks at random, pushes them to the worker, and requires the worker to complete them all as soon as possible. The worker, in addition, is required to abide by a number of policies that are imposed by the management of the organization.

Two levels of management typically define the policy environment within which a knowledge worker must exist. These are the worker's immediate supervisor, also known as the resource manager, and the executive in charge of the greater organization. The resource manager, to whom the knowledge worker reports, determines the degree of multitasking that the worker is required to perform. The executive indirectly determines the rate at which the greater organization spawns urgent, project-related tasks for the worker to perform. The executive, in other words, indirectly determines the workload for which the knowledge worker is held responsible.

To understand the interaction between the knowledge worker and his immediate environment, we use the computer model illustrated in the next figure. The organization is represented by the cloud at the left of the illustration. It is the source of urgent, project-related tasks that are pushed to the worker's in-box.

The tasks generated by the organization are of various sizes. The distribution of task sizes is skewed to the left (long tail to the right). Further, the tasks are not generated in any predictable pattern. Rather, they are generated and pushed to the worker at random. The distribution of inter-arrival intervals used in this model is very nearly uniform, for reasons that are beyond the scope of this discussion.

Finally, our knowledge worker is represented by a third distribution. This one is skewed to the right (it has a long tail to the left). The random numbers generated from this distribution represent the hours of effective effort that the worker provides during each day of operation. The hours of effective effort are applied to the active tasks before the worker.

The mean of the worker output distribution is precisely eight hours, implying that the worker is capable of delivering eight hours of effective effort, but only on average. The minimum of the worker output distribution is zero, and the maximum is thirteen. A worker output of zero hours of effective effort for a particular day of operation implies that for that day the worker was absent or at least unproductive. The maximum value of thirteen implies that the worker had an unusually productive day.

Next, we have the policy variables. Two policy variables are important to our model. The first of these is controlled by the executive, and we refer to it as the executive's policy variable. The executive's policy variable has two settings. The first setting is usually stated as: "If we have idle resources, then we launch more projects." In other words, the executive's policy variable really controls resource utilization throughout the organization. Further, this particularly ubiquitous setting creates a push system within organizations.

The second setting of the executive's policy variable can be stated as: "We launch new projects only as fast as we can complete projects." This is the policy that ultimately creates a pull system within organizations.

The executive's policy variable is represented within our model by the load ratio (see the next figure). This is, in essence, the ratio of two flow rates: the flow rate of tasks coming to the resource and the flow rate of tasks that leave the resource after being completed. Within a real organization, the flow rate of tasks coming to any resource is proportional to the rate at which new projects are launched. Thus, by ordering projects to be launched faster, the executive in charge of a development organization or an IT organization is increasing the rate at which tasks arrive at all resources.

Further, the denominator of the load ratio is a constant, for a very practical reason. A person is a constant throughput device, on average. Therefore, by ordering projects to be launched at a faster pace, the executive is indirectly causing the load ratio of all resources to increase. In this model we control the load ratio directly, with the understanding that an increase in the load ratio corresponds to an increase in the rate at which a real organization launches new projects.

The other independent variable is the multitasking policy setting. This is controlled by the resource manager directly, who requires our generic developer to begin new tasks before his current task is completed. For the purposes of this discussion, the multitasking policy variable can be set to any integer value between 1 and 10, inclusive. A value of 1 indicates that multitasking is actually banned, since it specifies that the resource may work only one task at a time. The maximum number of tasks that any individual can work simultaneously varies from person to person, of course. And it is highly unlikely that anyone can work 10 tasks simultaneously. Thus, a multitasking policy setting of 10, which specifies that the resource must work a maximum of 10 tasks simultaneously at every possible opportunity, is used to model the case of nearly unlimited multitasking.

The model just described is used to determine the effects of the two policy variables on three measurements: mean resource utilization, mean task flow time, and mean task process time. These are defined as follows:

1) Mean resource utilization - the percentage of available work hours that are spent on project work. A 40-hour week corresponds to 100%.

2) Mean task flow time - this is defined as the average interval from task arrival to task completion. It is expressed as a percentage of planned task duration.

3) Mean task process time - this is defined as the average interval from task start to task completion. It is expressed as a percentage of planned task duration.

A fourth measurement, queue time, is implied by the flow time and process time measurements. Queue time is defined as the interval from task arrival to task start. Thus, it is the time that a task spends in the in-box of the resource, before the resource begins working it. It is evident that the sum of queue time and process time always equals flow time.

Now that we understand the model, we can begin using it.

It is vitally important to understand the interaction between the two levels of management, which this model helps to clarify. We begin by observing that most executives regularly receive reports from the financial arm of their enterprises, a.k.a. the CFO's organization. All too often, one of these reports includes a measurement of the mean utilization of the resources of the organization. Should such a report indicate a level of utilization that is measurably less than 100%, the executive in charge inevitably concludes that much of the expensive capacity made available by his painful payroll is unutilized by the organization's projects and therefore being wasted. A loaded question comes to mind now. How long does it take most executives to respond to such a measurement?

The response time rivals the time that it takes information to travel from the executive's eyeballs to his brain. The nature of that response depends on the economic outlook and on the expected demand for the company's products, particularly the products already in the development pipeline. If the economic outlook is bright, and if the anticipated demand for the products under development is high, then the executive nearly always responds to the low utilization report with a mandate to launch more projects. After all, it is only reasonable. The report indicates that many of those expensive developers don't have enough project work to do.

Unfortunately, the decision to launch more projects quite often fails to take into account the real reasons for the low utilization measurement. Frequently developers are required to undertake a number of activities that have nothing to do with the projects of the organization and, consequently, may not show up on the CFO's utilization measurement. Such activities include training, paperwork for any number of initiatives launched by corporate, sales presentations, bug fixes for products already on the market, and more. Still, the utilization measurement is low, and the executive usually responds by pushing more projects into the organization.

The increase in the rate at which new projects are launched inevitably creates a queue of tasks in the inbox of our generic resource, our any-resource. The queue would not exist, were it not for variation. But, variation does exist. Variation exists in the arrival rate of tasks, in the size of tasks, and in the rate at which the resource completes tasks. Variation is everywhere, and it is most significant. Therefore, once the release rate of new projects is increased, it doesn't take long for a very visible queue of unstarted tasks to form in the in-box of our resource and in the in-box of every other resource as well.

Once there exists a queue of tasks for the resource, the fun begins. At this point, I'd like you to pretend that you are the supervisor of our resource. You are the resource manager. Your expensive developer is working diligently on one single task, while three or four other tasks simply sit in his in-box, untouched. Might you feel somewhat uncomfortable with this situation? Indeed you might, if you were employed by any of the vast majority of product development organizations or IT organizations of today. The four tasks in the in-box indicate that there could be as many as four different executives stalking you, each of them expecting an explanation as to why his pet project has seen zero progress for some time.

What are your options as resource manager? Well, you could simply tell the executives to take a hike. But that would be a career-limiting move for you. Given your severe need for a paycheck, that's not likely to happen. A second option is for you to tell the resource to start the tasks that have been in his in-box for perhaps a few weeks. This is a much safer move for you, since the resource can do little to curtail your career. Indeed, if he is like most other developers, he wants to do his best to help out. He wants to be a team player. Therefore, the multitasking policy has just been increased from one task at a time to five tasks simultaneously, all in the name of increased productivity.

Now, here's a wakeup call for all of us. We've increased the multitasking policy, from no multitasking to multitasking with five tasks simultaneously (presumably from five different projects). Does this mean that the queue of tasks vanishes, that the in-box of our resource is cleared out?

Indeed, the in-box of our any-resource is cleared out. The queue of tasks does vanish. But it vanishes only for the briefest period. The conditions that created the queue of tasks in the first place continue to exist. The queue was created by the increase in the arrival rate of tasks, an increase that was itself caused by the executive, when he decided to launch new projects at a faster pace. That executive decision hasn't changed. Therefore, the excessively high arrival rate of tasks persists, variation also persists, and the queue of tasks begins to build anew in just a week or two.

Ironically, the decision to use multitasking widely has no impact on resource utilization. This is illustrated by the next figure, which shows the Capacity Utilization of our any-resource, as a function of the Load Ratio and of the multitasking policy level. Recall that the Load Ratio is defined as the ratio of the mean arrival rate of tasks to the mean process rate of tasks. The multitasking policy level is denoted by the colored triangles. White triangles denote that multitasking is banned (one project at a time only). Yellow triangles denote that the resource must multitask with a maximum of two tasks simultaneously, at every opportunity. Gold triangles denote a multitasking policy level of four tasks simultaneously. Red triangles denote a multitasking policy level of ten tasks simultaneously. The figure shows that all the curves are on top of each other, indicating that the multitasking parameter has no impact on resource utilization. Resource utilization is a function exclusively of the Load Ratio, which is controlled by the executive of the organization and not by the resource managers.

Nor does the decision to use multitasking widely have any impact on flow time. Recall. Flow time is defined as the interval from task arrival to task completion. This is illustrated by the next figure, which shows flow time as a function of the Load Ratio and of the multitasking policy level. Flow time is shown as a percentage of the mean planned duration of tasks. The white squares denote that multitasking is banned (one project at a time only). The yellow squares denote a multitasking policy level of two tasks simultaneously, presumably from two different projects. The gold squares denote a multitasking policy level of four tasks simultaneously. Yet again, all the curves are on top of each other, indicating that the multitasking parameter has absolutely no impact on flow time. Flow time is a function exclusively of the Load Ratio, which is controlled entirely by the executive of the organization and not by the resource managers.

So, multitasking has no effect on the utilization level of our resource, and it has no effect on the mean flow time of tasks. This begs the question, "What is multitasking doing for us, or perhaps to us?" The answer to this question will be the focus of the next article.

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

[20] What's The Problem, Really?!

2004-11-25T11:38:00.000-05:00

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

If you've read this blog up to this point, then you know that the models of projects, which are being created currently by managers who don't understand variation, fail to take into account variation. Thus, even if the models did exhibit accuracy relative to deliverables and accuracy relative to logistics (which they do not), the models cannot exhibit accuracy relative to duration. This unfortunate fact essentially dooms the respective project managers to failure. But the situation is actually worse than that, if you can believe it. It is much worse.

All the analysis that we discussed during the previous articles was based on two assumptions: (1) resources work each task at a full level of effort, and (2) each project enjoys a fully dedicated team of resources. These assumptions were valid during the early days of formal project management, when Kelly Johnson and his people busily were developing the U-2 and the SR-71 Blackbird, because at that time companies indeed had adopted the single-project model. Today, it is exceedingly difficult to find any company that continues to use the single-project model.

What changed? During the 1970's and 1980's, companies throughout the world began adopting matrix management. They all saw matrix management as a tool with which to increase the productivity of their product development operations. "Do more with less," was the cry of the day. Ironically, when they jumped onto the matrix management bandwagon they created conditions that yielded exactly the opposite of that which they sought to achieve. They all ended up doing much less with a good deal more.

This unfortunate outcome was probably impossible to predict. Even today, the mechanism by which matrix management destroys the real productivity of product development organizations and IT organizations is counterintuitive. The real problem, therefore, is hidden from view and shielded from the spotlights of scrutiny, analysis, and understanding. The solution to this devastating problem is counterintutive to an even greater degree and therefore shielded to that greater degree from the understanding of most managers and executives. We begin by undesrtanding the mechanism by which the productivity of organizations is destroyed, multitasking.

First, we need to define multitasking. Multitasking is a behavior exhibited by working resources, individuals. A multitasking developer contributes to several tasks simultaneously, without focus, without a full level of effort, and with much unnecessary switching from one open task to another. Multitasking is a tremendous source of variation in task duration, project duration, delays, and waste. Here is why.

Let's say that a particular developer has three open tasks and is driven to jump from task to task several times, before any of the three tasks is completed. Let's say, too, that each task is associated with a different project. Task A is part of project P1, task B is part of project P2, and task C is part of project P3. While the developer works task A, project P1 is making progress. But projects P2 and P3 are not. They are being delayed. If the developer puts down task A, rather than finishing task A and launching the work of a downstream resource in project P1, and shifts his focus to task B, then while he works task B projects P1 and P3 are being delayed. Every time that the developer leaves a task without finishing it, that task and the corresponding project are delayed.

Sometimes, the task switching is absolutely necessary. Shift happens, as the saying goes. Emergencies, problems, opportunities present themselves, and the people of our organizations must respond. But such responses do not constitute multitasking. They constitute the necessary, information-driven, real-time reprioritizations of the task queues of a few developers.

Such information-driven changes in the priorities of a few developers also create delays at times. But their number and their schedule impact are at most an order of magnitude smaller than the schedule impact created when most developers multitask most of the time. Further, the information-driven task switching is necessary. The task switching that constitutes multitasking is undesirable, unnecessary, and driven by factors that have nothing to do with creating shareholder value.

So, what causes the task switching that constitutes multitasking? To answer this question, and to understand the full impact of the damage to schedule performance and financial performance, we need to look closely at the interaction between a single developer and the organizational ecosystem created by the management team. We do this with a computer model of a single knowledge worker in a typical product development organization or IT organization.

[continued in the next article]

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

[19] Multitasking Is Costing Billions

2004-11-18T22:11:00.000-05:00

A note: This particular article is being republished. A number of readers helpe me with the contents of a newsletter, recently. The article is the first in the newsletter, and I wanted to share the latest version of it. The message is the same. Multitasking simply causes expensive capacity to be redirected to the creation of more and more work in process, at the expense of throughput. The real question is "Why is multitasking taking place at all?" We'll explore this in subsequent articles.

Perception

Multitasking, a work paradigm that is widely perceived as a productivity enhancer, is actually costing you millions of dollars every year. After eliminating multitasking from their multiproject operations, some companies are now saving those millions, by avoiding massive payroll increases.

Multitasking is a task-level paradigm. A multitasking developer has several tasks active simultaneously. The developer shifts his/her focus from task to task many times before completing any of them. Multitasking developers typically are perceived as being diligent, hard-working, valuable, and very busy, which they most certainly are.

Most managers perceive multitasking as a productivity-enhancing paradigm, since it allows them to start projects that otherwise would have to wait for developers to become available. Consequently, many managers actively encourage their developers to multitask. If your organization performs product development projects or IT projects, then multitasking is probably devastating your performance in these areas right now.

How can you tell if multitasking is widespread in your organization? To find out, just look at the ratio of the number of active projects to the number of developers. If this ratio is greater than about 0.3, then multitasking is probably running rampant throughout your enterprise. If the ratio is approaching 0.5, well, yikes!

Reality

So, why is multitasking such a big problem? The answer to this question is explored best in two steps. First, imagine that you’re a customer at a bank. As you wait in an unpleasantly long line, for your turn with the teller, you notice that the teller is doing something unusual. Rather than completing each customer’s transaction, the teller is beginning the transaction of the second customer and even that of the third customer. Then, she is task-switching, from one transaction to another, without completing any transaction. Before long, the teller has four or five open transactions, with none of them close to being completed. The teller is multitasking.

Would you expect to complete your banking any sooner, given the teller’s multitasking paradigm? Obviously not! In fact, you can probably expect to be delayed further, by the mistakes that the teller’s frequent context switching is sure to cause.

Of course, bank tellers don’t multitask. In such an environment, multitasking is obviously damaging. So, workers simply don’t do it. Nor would bank managers tolerate it for long, even if some workers decided to try it.

Working For WIP

Any bank teller who decides to multitask is making a big mistake. Such a teller is choosing to misdirect capacity, away from generating throughput (in the form of completed transactions) and toward creating more and more work in process, WIP.

Of course, bank tellers and knowledge workers aren’t quite the same things. But the mechanism that damages the throughput of product development organizations and IT organizations is identical. When your developers multitask, they are misdirecting their own far more expensive capacity, away from generating throughput (in the form of completed projects that make money) and toward creating more and more work in process, WIP. The effect of this misdirection of capacity is that the organization’s throughput of completed projects is dramatically reduced.

By how much is throughput reduced? One software development organization, Confluence, increased its throughput from 6 completed projects per year to 11 completed projects per year. It did so simply by eliminating multitasking, without hiring a single additional developer. Another organization increased its throughput of completed projects from 5 per year to 16, again without hiring a single additional developer.

How did these organizations make such improvements? They changed their management process. That’s right, their management process. They replaced their antiquated management policies and practices, which were forcing their developers to multitask, with management policies and practices that enabled resource teams to achieve and sustain maximum throughput.

Today, most organizations simply continue to suffer largely unrecognized financial losses, which multitasking is inflicting upon their businesses. A few have taken action. They’ve undertaken a change process that has nearly doubled the real productivity of their product development or IT operations. Inevitably, other organizations will follow. But for the shareholders of those other organizations, improvement will be none too soon. †

[18] Anatomy of a Robust Project Plan

2004-11-05T16:33:00.000-05:00

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 deliverables, …logistics, …duration, and …budget. These features are the result of discipline, your and that of your superiors.

This concludes the Robust Project Design content. As I stated clearly at the beginning, good project plans are absolutely necessary for successful operations, but they are in no way sufficient. Today, the widespread use of the matrix management model ensures that the single-project model is little more than a recipe for disappointment. For truly effective operations in product development today, we need a multiproject management approach. This will be the focus of the future writings.

[So that others also might subscribe to The Project Management Soap Box, please share the following link with friends and colleagues.Subscribe!]

[17] The Critical Chain Model

2004-11-04T08:57:00.000-05:00

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.

[So that others also might subscribe to The Project Management Soap Box, please share the following link with friends and colleagues.Subscribe!]

[16] Tolerance Design

2004-10-30T16:04:00.000-04:00

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.

[So that others also might subscribe to The Project Management Soap Box, please share the following link with friends and colleagues.Subscribe!]

[15] Diamond-Shaped Networks

2004-10-21T14:30:00.000-04:00

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.

[So that others also might subscribe to The Project Management Soap Box, please share the following link with friends and colleagues. Subscribe!

[14] Component Tolerances

2004-10-19T08:55:00.000-04:00

It is clear [Variation And The Parallel Structure] 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 (ALAP), taking into account the component tolerance. For reasons that are beyond the scope of this writing, the ALAP 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 chapter.

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

[13] Variation & The Parallel Structure

2004-10-17T16:29:00.000-04:00

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 chapters I’ll show you techniques for limiting the adverse effects of variation.

In the meantime, please do me a favor. No, two favors! First, let me know that you're reading this. Since I started this blog I've received almost no feedback, despite the number of subscribers. Second, please help me to recruit more subscribers. One day I hope to publish this as a book. Feedback from interested readers would be most useful. Thank you!

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

[12] Project Tolerance

2004-10-13T23:05:00.000-04:00

The mean duration of a sequence of tasks, often called the expected value of duration, is a valid and useful concept. However, the probability of observing exactly the mean of any distribution is exactly zero. Therefore, we must be careful not to interpret the mean in this deterministic manner. Instead, it is more useful to interpret the mean value merely as a positional parameter for the corresponding distribution, an anchor point about which we can expect considerable variation.

Further, the confidence level associated with the mean value of duration is rarely acceptable in business settings. That confidence level can be as low as 50%. A more useful confidence level might be, say, 95%. The duration that corresponds to the greater confidence level becomes the promised or committed duration. Therefore, we need a new concept, one that helps us bridge the difference between the mean value of duration and the committed duration. I call this the project tolerance.

The project tolerance is a necessary component of any project’s design. It indicates our estimate of the variation in duration, to which the project is exposed. Some refer to this design feature as the project buffer. However, the word buffer brings with it a number of unfortunate connotations, particularly among high-level managers and executives. To these busy people, the word buffer smacks of padding and sandbagging. Frequently their instantaneous response, upon hearing the term buffer, is to mandate that such buffers be removed immediately from the designs of their projects. The inevitable result is that yet another grand lie is fabricated, since the resulting committed duration corresponds to the mean value and brings with it unacceptably high risk.

The term tolerance, however, is a technical term. For example, mechanical engineers use the concept of dimensional tolerancing when specifying the dimensions for components and products. Indeed, even engineers who have embraced the practice of robust product design continue to use the concept of dimensional tolerancing. They do so in an environment where variation in component dimensions at times is imperceptibly small. In the world of projects, where the degree of variation that we encounter is three to four orders of magnitude greater than that encountered in product design, the concept of project tolerance makes even more sense. I would go so far as to say that the project tolerance is an indispensable design component of every robust project model.

With the model of a simple sequence of tasks we have addressed the subject of variation, at least to the extent that variation affects such sequences. We have even taken a first important step toward managing that variation, by defining the concept of project tolerance. However, no real project ever consists of a single sequence of tasks. Real projects always include multiple parallel sequences of tasks. With the next chapter we explore how variation and the parallel structure of project models interact. The strength of their interaction will surprise you.

[11] A Truer Representation

2004-10-11T22:54:00.000-04:00

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.

[10] Variation & Sequences of Tasks

2004-10-01T15:49:00.000-04:00

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.

[9] The Mean of a Sum

2004-09-30T19:42:00.000-04:00

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

2004-09-27T19:25:00.000-04:00

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.

2004-09-23T22:34:00.000-04:00

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)

2004-09-18T23:09:00.000-04:00

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

2004-09-16T16:43:00.000-04:00

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

2004-09-14T07:19:00.000-04:00

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

2004-09-12T13:55:00.000-04:00

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

2004-09-10T14:25:00.000-04:00

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

2004-09-10T14:03:00.000-04:00

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.