We all do it, but it’s pricey: Context switching demands valuable time and energy. Ranking priorities can help you manage that melting clock.
Bob, the VP, told Sam, the PM, “I have three high-priority projects. I trust you. I want you to run those projects.” 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.
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. Here’s how you’re spending those 45 hours: 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.
Your actual time on each project works out to about half of what you expected.
Actually, if you’re spending six hours equally on projects A, B, C, you’re quite lucky. Most of the time, when we multitask, we shortchange 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 to them to do project work. The rest of the time, they’re 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 on their teams, focused on only one task at a time. These teams remain immersed, requiring no extra time to refocus their efforts.
DeMarco claims the task-switching cost is the sum of the mechanics of moving to a new task (putting other stuff away, getting out what you need, organizing the papers and files you need); plus any rework or fixing required because you stopped what you were doing before; plus the immersion time; plus the loss of team binding, with an additional soupcon of frustration from moving from project to project. All of those costs occur each time you move from project to project.
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. Write down the entire list of projects you think you’re working on during the week on the left side of a piece of paper. Draw a line down the middle. When you work on one project, log the time spent in the right column. If you’re working 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 say that you finished anything? Did you finish less than you expected to finish? 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 you can make some progress on everything, but the amount of progress is so small, you end up feeling as if you're working harder, 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 when a company would assign a neophyte to a mission-critical assignment. In this economy, hiring 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 do not 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. Rank your projects, and make sure your team members know what they need to do and when, to obtain the highest productivity from your staff.
Sam asked Bob to rank the projects, “If you could have one project first, which one would it be?” Sam also asked about the risk of not releasing the projects, “What are the consequences if we release any of these projects late?”
Bob explained his thinking and the relative importance of each project. And, Bob clarified 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 Bob needed one more project manager for the third project. Bob's happy, because his two time-critical projects are completing 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 Sam doesn't have that queasy feeling anymore.