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