Multiprojecting: The Illusion of Progress

[article]
Summary:

Think working on five projects at once will make great results appear like magic? Don't be so sure. The price your team pays by switching from one project to another could make your productivity disappear. Johanna Rothman reveals the smoke and mirrors behind the illusion of multiprojecting.

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?

Pay No Attention to That Team Behind the Curtain
The short answer is that putting the same people on two high-priority projects only creates the illusion of progress. 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 when he was working on one project he was needed on the other project. 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 had not cleared any obstacles for either of the project teams.

The testers couldn't help the projects make progress either. One of the testers 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 each other 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.

Watch Your Time Disappear
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 is wasted by multiprojecting, consider this: The relationship between number of tasks and wasted time is directly related. As the number of tasks increase so do the number of wasted hours. For example, as Gerald Weinberg indicated in his book Quality Software Management: Systems Thinking, a person who works on two tasks spends only about 40% of her time on each task, wasting 20% of her time. With more concurrent tasks, it's even worse: A person involved with four tasks spends only 10% of her time on each task, wasting 60% of this person's time! Clearly, multiprojecting is not a technique for finishing projects quickly.

User Comments

1 comment
Joe DeMeyer's picture
Joe DeMeyer

Hello Tim and thanks for your response!

Good example! Two processes disconnected by elapsed time, or by data transformation (your data is changed by the next system, which changes it again, and so forth) would certainly qualify. I would enjoy the challenge of creating data paths to help determine if an evaluation is possible, or just as a thought experiment to generate ideas for testing.

October 14, 2013 - 7:42pm

About the author

Johanna Rothman's picture Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:

  • Manage Your Job Search
  • Hiring Geeks That Fit
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management
  • Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03