The Project Management Soap Box

Featured book: Robust Project Design(tm) - All the things that you were never taught about modeling projects.

Saturday, December 18, 2004

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

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