[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. †