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

[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?!

[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

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

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

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!]