Bob, the VP, told Sam, the project manager, "I have three high-priority projects. I trust you. I want you to run them all." Sam's flattered, but queasy: He knows that if he tries to run these three high-priority projects at the same time, he'll fail.
No matter how efficient you think you are, multitasking comes with a high cost. Because we're people, we don't swap out the content of our brains as easily as a computer does, and we definitely don't swap in the old state when we're ready to return to the original task.
Slip-Sliding Away
Gerald Weinberg, in Quality Software Management, Vol. 1, Systems Thinking (Dorset House, 1992), estimates the context-switching cost among three tasks to be 40 percent. That means that 40 percent of your available work time is spent on non-task activities. The rest of the time is split among the three projects. So, if you thought that in a 45-hour week, you could spend 15 hours on each of three tasks, don't kid yourself. You're really spending eight hours on project A; eight hours on project B; eight hours on project C; and 24 hours context-switching, figuring out where you were and what you have to do next. The time spent on each project works out to about half of what you expected.
Actually, if you're spending six hours equally on projects A, B and C, you're quite lucky. Usually, multitasking shortchanges at least one of the three projects, and you're lucky if you have 40 possible work-hours in a week. In some organizations, people have about 20 hours available for project work. The rest of their time is spent in meetings, answering e-mail or voice mail, or discussing some other urgent problem.
In his acclaimed examination of efficiency—and lack thereof—Slack (Broadway Books, 2001), Tom DeMarco talks about "immersion time." When we multitask on software projects, we need time to familiarize ourselves with where we were the last time we worked on this project. To this, DeMarco adds the notion of team-binding time. When you're working on a project with your team, everyone's focused on the same goal. If you move away from that project, you've lost the enhanced productivity that team binding provides. In part, agile techniques are so productive because the people on those projects stay bound to their teams, focused on only one task at a time. Because they're immersed, they require no extra time to refocus their efforts.
DeMarco claims the task-switching cost is the sum of moving to a new task (putting other stuff away, getting out what you need, organizing papers and files); the rework or fixing required because you stopped what you were doing before; the immersion time; and the loss of team binding, with an additional soupon of frustration. All of those costs occur each time you move from project to project.
Time-Log Test
If you can't believe that the overhead of switching tasks is winnowing away so much of your vital essence, here's a way to check. On the left side of a piece of paper, write down the entire list of projects you think you're working on during the week. Draw a line down the middle. On the right side, log the time spent working on one project. If you work on a project you didn't originally consider, that's OK—just add it to the left side of the paper, then log the time spent. At the end of the week, evaluate your totals. When I've done this, I've seen these two patterns:
- Choose a priority by default and work on that. Many of us choose which project to work on, no matter how many projects are actually assigned to us.
- Attempt to work a little on everything.
Now, assess your accomplishments. Were you able to finish anything? Did you finish less than you expected? Or did you flail around aimlessly, making no significant progress on anything?
When you've chosen a priority, you'll find that you spend much less time on the other projects. And, if you examine the time spent and compare that to the time planned, your original task time estimate in the left column is probably pretty close to the time you actually spent on that project as noted in the right column, although the total elapsed calendar time is much longer, because you've spent at least some time on other tasks.
When you attempt to work a little on everything, you'll find that you spend less time than you thought on anything. Yes, it's possible to make some progress on everything, but it's so minimal that you end up feeling as if you're working harder, but getting farther behind.
If you're a manager, planning other people's work, rank all the projects you have in your project portfolio. Which ones do you absolutely need to accomplish this week? Number the projects, with only one #1 priority; then, have everyone work on that project. You can re-rank your projects as early as the following week, but if you don't give your staff a chance to finish something, the pernicious effects of multitasking eat away at your time and efficiency, with higher defect levels and a protracted schedule.
If you're a technical contributor, ask your manager this question: "If you had to choose just one thing for me to work on and complete, what would that one thing be?" If your manager has trouble with this idea, ask her to pretend you're a new, but experienced hire who just started today. What would she start you on? That would be the highest-priority work this week. (Some of you may be wondering why a company would assign a neophyte to a mission-critical project. In this economy, managers are hiring as late as possible, so when the new hire arrives, the work is mission-critical.) Although you can change your project rankings, the longer you can keep the projects at the same relative ranking, the more progress your project teams can make. However, even if you can organize the work for just one week at a time, the team can still make progress, albeit less dramatic.
The bottom line? People don't context-switch easily. It's far easier and more productive to continue working on the same project, at the same level, for as long as possible. It costs valuable time and brainpower to switch to another project or activity. To obtain the highest productivity from your staff, rank your projects and make sure your team members know what they need to do-and when.
Whatever happened with poor, unsettled Sam? He asked Bob to rank the projects: "If you could have one project first, which one would it be?" He also asked about the risk of not releasing the projects: "What are the consequences if any of these projects are late?"
Bob explained the relative importance of each project, clarifying the risk to the company of releasing any of the projects late. Sam chose to manage two of the projects and helped Bob understand why another project manager was needed for the third. Bob's happy, because his two time-critical projects will be finished on time, and Sam's happy because he can manage the top-priority project, and in his spare time deal with the least important project. And he doesn't have that queasy feeling anymore.
Johanna Rothman is a consultant in high-technology product development. Contact her at [email protected] or visit http://www.jrothman.com
