Multitasking is Conflict Avoidance


There's a great quote over at The pernicious thinking behind multi-tasking.

Note the admission that required multi-tasking is an implicit means to avoid conflicts around setting priorities.

I've been doing a bunch of multitasking talks this year (and suggesting ways for people to say no), and have written about it in Successful Project Management. (I did rename the section that originally said, “Multitasking is the root of all evil.”) When I talk about it, and tell people it makes no sense, at least part of the time they say “Ooh.” Too many people have no idea what the cost of multitasking is.

But the conflict avoidance part is because management, especially senior management is unwilling to make the hard decisions about what's most important to do. That's unacceptable. Managers are the only people who can make these most strategic decisions.

Multitasking guarantees your project will be late. If managers don't make the decisions, project staff will. And it won't be the way the managers want it.

Labels: multitasking, project management, Successful Project Management

9 thoughts on “Multitasking is Conflict Avoidance”

  1. Just because a tool is being used badly, even by the majority of people, is not sufficient reason to condemn the tool. This sounds like a classic case of misuse.
    Sticking with the computer analogy, multitasking is a way to use CPU cycles that would otherwise be wasted due to a block on an external resource. Similarly there are plenty of legitimate impediments to project progress at the individual level and having something else to do is just plain efficient; twiddling of thumbs waiting for resource availability is not.
    Granted that we need to pace ourselves and not bounce from one task to the next, making little progress on any of them — there’s another computer term for that: “thrashing”. A well-functioning system tunes these into proper proportion, it doesn’t dismiss multi-tasking as a bad idea.

  2. I have been working with several clients where multitasking had taken on a new level. I did a brief exercise with several teams to show them the harm. The exercise is the Confetti Factory and it takes about a half hour. It helps people understand the time wasting and it lead one client to change an established policy. People need work to do, but they need an orderly process to get more of it done in a set time.

  3. I think there are two questiona to ask :
    1) what is a reasonable number of project for a given group to be working on at the same time”.
    2) How much time can you safely allocate a resource to any project (slack)?
    To me, if a resource is only needed 50% of the time on a given project, they shouldn’t be necessarily idle the other 2.5 days of the week.
    I think what happens is that after priorities are nominally set (and I am absolutely in the middle of this right now), other “priorities” intrude. so, for example, “Rich” is assigned to my project 2 days a week and 3 days a week to John’s project. This is fine. Then, it turns out that Rich is .5 days on me, .5 days on John and 4 days on three other things that “came up”.
    As for question 2, we need to acknowledge that we can’t fill every whole. Is it reasonable to budget people at more than 80% time for anything? How much slack do we need in the system?

  4. For those of you who have commented above, I suggest you study the teachings of Eli Goldratt, notably “The Goal” and the Theory of Constraints. Is it the mission of the organization to get projects completed as rapidly and efficiently as possible or to fully utilize every hour of every staff member? The big problem with assigning a person who is only needed 50% of the time on one project to a second (or third or fourth) project is that you can’t know exactly when you will need this 50% involvement and what other tasks or personnel may be dependent on the efforts of that person. For those of us who have seen this dynamic in action, there is no question about the deleterious effects of multi-tasking. Having fill-in work for idle time is not the same thing.
    I would love to receive a detailed description of the Confetti Factory exercise from Chris Frame.

  5. If you do 2 tasks of 40 hours work simultaneously, you need 2 weeks to finish.
    If you do them sequencially, one task finishes after 1 week and the other after 2 weeks.
    So, by ignoring priorities, all work will be as late as the lowest priority. Indeed, multitasking is not an economic choice.

  6. I get a kick out of this multi-tasking thing…People use the word to connote highly talented…in the meantime most women say they are good at it and men aren’t…I have yet to see a mult-tasker accomplish great things…Usually people who excel at the highest level of greatness are very focused individuals

  7. Multitasking is cetainly killing efficiency… But in our world it is more and more difficult to avoid it. Personal organization methods like GTD allow to limit multitasking impact at individual level by improving focus and reducing switching costs: the tasks are split in elementary actions that are focused on, one at a time, when context allows.
    I develop this idea in “GTD vs multitasking”
    Happy GTD and stay away from multitasking!

  8. We are all missing a critical factor in this discussion. Task dependency. That’s the key factor here. How do you think assembly lines in manufacturing manage the operators’ time effectively? Through multitasking? No. Each person does the same task without any dependency on any other resource except the output of the previous person. His own work is totally independent and well defined. In such a scenario, imagine that he (say) screws one nut in one door (of a car), then switches to another screw in a second door and back to door number one. All doors would end up getting delayed. So, Schophuizen’s hypothesis holds valid in this scenario. Finish the first door, let the next person start his work on it. Now, think of a scenario where the work is novel (software development is a typical case). A developer might need to wait for inputs on a query response from analyst or business user. They might take 2 days to respond, his work is stuck and is totally dependent on external inputs. In such a scenario, he’d be much better of writing the unit test script (say) for his next module. So, multitasking, like all other ideas needs to be applied with common sense. Whether finishing TaskA completely in first week makes more sense, or doing both TaskA and TaskB parallely (for whatever reason) does not impact the final end date of 2 weeks, and does not stop any other operator’s work, then it’s immaterial. Let the poor operator choose what he wishes to do when!

    1. Amit, We can let people decide what to work on next. That’s fine. That’s letting the software developer or the software tester make the strategic decisions about the project portfolio. That person decides which project is #1. If that fits for your organization, that’s fine.

      That’s what happens when everyone multitasks. The rate of project throughput goes way down. You feel as if you walk through mud. That’s why I wrote Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects.

      Everyone’s life is better when you have a ranked backlog, and the team understands what to do together. They don’t have to work in an agile way, although I certainly lean that way. They can work in a coordinated, collaborated way. I explained how you can use any lifecycle you want in Manage It! Your Guide to Modern Pragmatic Project Management. (I referred to that book as Successful Project Management in the post.)

      You are right when you say that software development is novel work. My question is this: Why does a developer have to wait two days for a response to a query? Is that because the team is geographically distributed? There are ways to manage the project so people are better coordinated and respond faster. Is that because people are multitasking? That is not helping the project get to done. That’s nuts.

      Which project is #1? Decide that. Then, let’s work on that project. Don’t work on projects that don’t matter.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: