Your CIO has two projects he wants finished in the next month. “We can share this project manager and that test team on both of these high-priority projects,” he declares confidently. “The projects are small enough that the teams should be able to make progress.” Two weeks later, the CIO realizes neither project is progressing the way he'd envisioned. What's going on?
Quantity does not equal quality
“Those who speak most of progress measure it by quantity and not by quality.” — George Santayana
The short answer is that putting the same people on two high-priority projects only creates the illusion of progress by focusing on quantity of projects being worked on, not projects completed. Here's what really happened.
The project manager worked mornings on Project 1 and afternoons on Project 2. Part of the test group also chose to work mornings and afternoons. But the other part of the test group used Monday and Tuesday for Project 1 and the rest of the week for Project 2 because of the way they needed to work with the developers. The first problem was that the project team, including the project manager and the testers, didn't work on the same project at the same time.
The project manager and the testers maintained their time organization only for the first week. After the first week, the project manager was an obstacle to both projects, because he was working on one project when he was needed on the other. Work from Project 1 piled up when he was on Project 2 and vice versa. By the start of the third week, the project manager hadn't cleared any obstacles for either of the project teams.
The testers couldn't help the projects make progress either. One tester who split his project work into mornings and afternoons discovered a problem that required test data from one of the Monday/Tuesday testers. It was bad enough that the testers had to wait on one another for information, but the developers had to wait for the testers, too. The developers would start to fix problems, then have to wait more than a week for the testers to verify them.
In this case, the multiprojecting caused people to be far less productive than if they'd been assigned to only one project at a time.
The Case of Disappearing Time
“Time is an illusion. Lunchtime doubly so.” — Douglas Adams
People pay a context-switching cost when they switch from one project to another. Even if they try to assign half of their time to one project and half to the other, they can't. People need time to stop thinking about one project and start thinking about the other — particularly the details of where they left off. Multiprojecting doesn't create more time in the day; it wastes time.
When people divide their time during the day, they switch context more often (at least once per day), paying the context-switching price more often. In the above example, the people who divided their time into mornings and afternoons paid a higher cost than the people who assigned different days for different projects did. The people who switched context only once a week paid the cost less often.
If you're not sure how much time you waste by multiprojecting, consider this: There's a direct relationship between number of tasks and wasted time. As the number of tasks increases so does the number of wasted hours. For example, as Gerald Weinberg indicated in his book Quality Software Management, Vol. 1: Systems Thinking (Dorset House, 1992), a person who works on two tasks spends only about 40% of his time on each task, wasting 20% of his time. With more concurrent tasks, it's even worse: a person involved with four tasks spends only 10% of his time on each task, wasting 60% of his time. Clearly, multiprojecting is not a technique for finishing projects quickly.
What's the Problem?
“The greatest challenge to any thinker is stating the problem in a way that will allow a solution.” — Bertrand Russell
So what could this CIO do to complete both high-priority projects in the desired time frame? In this case, the problem of two small, short projects using the same staff with unplanned and unplannable interactions, the CIO could first decide which project is a higher priority. The CIO could then assign the entire team to that project and use release criteria to make sure the minimum work is done on the first project. As people come off of that project, he could start them on the next one.
People don't multitask easily because of the context-switching cost. It's easier and more productive for people to continue working on the same project, at the same level, for as long as possible. It costs time and brainpower to switch to another project or to another activity. Rank your projects, and make sure people know what done means, so they do only the minimum necessary. Don't fool yourself with an illusion of progress; make the progress real.
Acknowledgments: I thank Elisabeth Hendrickson and Frank Patrick for their reviews of this column.
Originally published in Computerworld.