Comment:     by Kay Duchesne 2/17/2005 Johanna, thanks for tackling a subject I deal with daily. As a Quality Engineer in a large company, I spend my time juggling 4 to 5 projects a week. The transition time is not instantaneous. One of the solutions I've come up with is to use my calendar to register necessary meetings, and plan for them in advance. I also notify all of my projects at the beginning of the month what they will be evaluated on this month. So far, so good. I've managed to keep my sanity so far, there is a lot of stress.
	Comment:     by Robert Kohlenberger 2/16/2005 This idea that "People do not multitask easily because of the context-switching cost." is not universally true for all types of activities. It is only true for big-context activities, such as software or test design, not for small-context activities like short order cook. But it is clearly a problem for our line of work. The unfortunate thing is that this article doesn't speak to managers. Although this context-switching cost has been well documented (see for example "The Limits of Multitasking" by Klaus Manhart, Scientific American Mind, Jan. 2005), managers may say, "it's time to stop using 'interruptions' as...Read On
	Comment:     by Jacob Halperin 3/31/2004 Though it's not 100% Multi-Projecting... , We have found out that a certain level of features multi-tasking testing works very well, if we split 2 week tasks into 30%-40%-30% parts and interleave between 2-4 tasks of this type. Though it definitely add additional stress, it allows us to surface 1st level of bugs quickly on 3 different issues, while instead of waiting for the 1st feature bugs to be fixed, we switch to the next 2, and normally when we return to 1st one for a deeper 40% session, the core bugs are already fixed. It also gives us a better knowledge of the version status, as instead of having a single feature fully covered while...Read On Author's Response: 4/5/2004     Jacob, if the tasks are sufficiently related so that the context switching between tasks is minimal, then maybe this will work. I know that even when I think I'm productive, if I have multiple tasks, I will choose which one to finish rather than attempting to work on them all. For testing, I seem to have been in a different environment than you. I didn't want to know a little bit about a lot of features, I wanted to fully test (for whatever value of fully we were using) a particular feature or module before going on to the less risky areas. As long as you're assessing risk and prioritizing the work, you'll at least be making good decisions about the work. And you can always change your mind.
	Comment:     by James Ward 3/29/2004 Johanna, I admire you for taking on a difficult subject. I have taken over a department where multi-tasking was the rule, and abruptly ended that practice, with extemely positive results - for both our staff and our customers. I also stress the evils of multi-tasking when training project managers and preach this message to both managers and staff whenver I get the chance. I believe that the strongest argument against multi-tasking is time-to-market. Even if time was not lost in context switching, two one month projects would still take two months if done simultaneously. If done serially, the organization gets the benefit of the results...Read On Author's Response: 4/5/2004     James, thank you. I agree with you that placating is a huge problem. The IT organization wants to do everything the business asks, but just agreeing is no recipe for finishing the work. Congruence in discussing the issues is crucial. Thank you for pointing that out.
	Comment:     by Michael Goetchius 3/27/2004 Context-switching cost. Thank you for naming my demon. Author's Response: 3/27/2004     Michael, my pleasure.
	Comment:     by Sergiu Frishling 3/27/2004 Johanna, I agree that there is a problem. It is a management one. As far as I understand, if we have several development and tester teams working on several projects at once, then, the work progress will be less or no productive at all. More, each team has its own schedule and work organizer. That’s a typical case of wrong planning, no milestone based and no managed company. If that’s the case, you have to change the CIO and not to search what’s wrong with the teams or with individual people. There is no problem working on several projects at once. You only need a good planning, a very disciplinary teams which have commitment to follow the...Read On Author's Response: 3/27/2004     Sergiu, multiptojecting is a case of not managing the project portfolio, you're right. Sometimes changing the CIO is appropriate, sometimes the problem is not limited to just one manager. Your experience of having the same people work on multiple projects seems to be different from mine. With your idea of weak interrelations, I agree, the projects have more chance for success. However, I have not seen this work for longer than 6 months as a time. I don't know if working on multiple projects prevents your staff from becoming sufficiently expert so that the developers would welcome your defect reports. I have certainly seen many organizations where the testers ran from project to project (or worked on multiple projects at the same time), not developing significant solution-space product domain expertise, and the developers were unimpressed with their defect reports.
	Comment:     by Matthew Heusser 3/24/2004 Gene Fellner wrote that: "But in my experience the root of this problem is the fact that most IT managers (indeed most American managers period) simply distrust the advice of 'experts.' Even something which has been proven invariably true many times in many ways by many experts in many studies is generally shrugged off as 'more ivory tower academic nonsense.'" -- I have had a similiar reaction. I think a big part of that is the implication that a new idea must be either good or bad. If it's bad, it can easily be dismissed. If it's good, that brings up the humiliating question "...Then why aren't you doing it?" People want to avoid that...Read On Author's Response: 3/24/2004     Matthew, people work in ways they think are successful. I attempted to write this so that people could recognize their situations, and allow them to choose whether to continue they way they are working, or consider changing. No one listens to "experts" or anyone else who tells people they are wrong, and by implication, stupid. I assume that people do things because they think it works for them. If I'm successful as a writer, my readers will consider whether the situation applies to them, and if they can see a way to follow my advice. I firmly believe people do the best they know how. If they don't know any other way, they continue working in the way they work now. My job is to suggest alternatives in a way that allows people to consider them. My readers (and my clients) are smart people. They will make decisions that fit for them. None of the ideas are all good or all bad; they are just ideas. I have an advantage over other people because I've seen lots of other organizations and have seen how they deal with their problems (such as this one, multiprojecting). BTW, people mistrust experts because too often those "experts" have a vested interest in something they are suggesting to these people.
	Comment:     by Ajay Pandey 3/23/2004 The article is interesting. I fully agree that the productivity can diminish if the entire test group divides their time in 2 projects. But if we use either the Lead or the seniormost Test engineer we can salvage the damage. Further the chances of productivity decraesing are less if both the projects are of the same domain and more or less revolve around the same functionalities. Project Managers need not spend their entire time in their projects as they can manage with the status provided by their leads. Once again from preventing this scenarios from leading to hobson choice, Budget, people and timeframes needs to be considered. Author's Response: 3/24/2004     Ajay, you can certainly use the technical leads to leverage the work of others. But what if the technical leads are working on three projects? The more similar the projects, the easier the context switching is, I agree. And I agree with you, that evaluating the risks of multiprojecting or not is necessary.
	Comment:     by Tek Wallah 3/23/2004 It’s a funny thing: Many people react as though they’ve been accused of stupidity when it’s pointed out that the quality (and usually quantity) of work declines when you multitask. I wonder why that is. The phenomenon is common to all human beings. Author's Response: 3/24/2004     Tek, I think people become defensive when they realize they (and their staff) cannot do it all -- not all at the same time. They want to, and they can't. I don't know why.
	Comment:     by Harriet Canfield 3/23/2004 While your column makes sense, it is not completely realistic. I certainly try to limit the number of concurrent projects my testers and I work on, but it does not make business sense to leave people idle waiting on system corrections while they can begin working on another project. It is really up to the manager to know how well each individual on their team can multi-task and assign work accordingly. I know some who actually get bored and are less productive if they only have one project to work on. As both a manager and a mother, I know that if I limited myself to just one "project" at a time I would miss out on many opportunities to...Read On Author's Response: 3/24/2004     Harriet, I have had better results when I assigned testers to one product, and had them use a variety of techniques to explore the product. If they finish earlier than we anticipated and we know enough about the product, great. If we don't know, we spend more time. I have found that using a variety of techniques to explore a product more deeply to be more limiting to me. Clearly, my mileage varies from yours :-)
	Comment:     by Wayne Allen 3/23/2004 Jim Highsmith has also pointed out that projects that are worked on serially get done faster than those worked on in parallel (Queuing Theory). Certainly what you are saying is accurate, but like others have asked, how do we get those with scheduling authority to believe it? The response I seem to get frequently is that the manager is trying to mitigate the risk of one project failing by scheduling 3 projects simultaneously. Another scenario is that multiple projects are scheduled because it is assumed that there will be work stoppages on individual projects and we certainly don't want our employees sitting around twiddling their thumbs! Author's Response: 3/24/2004     Wayne, if the people who schedule the work understand anything about Theory of Constraints or Lean or Agile, they would understand why simultaneous scheduling doesn't work. What managers don't understand (and what Tom DeMarco talked about in "Slack") is that not everyone needs to be 100% allocated 100% of the time. The more often people have slack, the more work gets done. If there are work stoppages on projects, it's because the people scheduling haven't thought about the dynamics of the interdependencies (not a particularly easy thing to think about, and unique to each organization). The first thing to do is explain the cost in money and time to multiproject.
	Comment:     by Gene Fellner 3/23/2004 You've made some good points very persuasively. But in my experience the root of this problem is the fact that most IT managers (indeed most American managers period) simply distrust the advice of "experts." Even something which has been proven invariably true many times in many ways by many experts in many studies is generally shrugged off as "more ivory tower academic nonsense." (E.g., no one accepts the fact that keeping knowledge workers on duty for more than 40 hours per week increases the defect rate so badly that it more than cancels out any increase in productivity.) For the most part, WE believe you. Some of us even already knew...Read On Author's Response: 3/24/2004     Gene, I wish you would ask easier questions :-) What you're really asking about is the ability of managers to change. For people to change, they need to see a reason for the change. Until they understand it costs them more (in time and money) to multiproject, they won't change. The costs have to be crystal clear to the managers. (I'm trying to develop a project portfolio tool that effectively does this, but I am not successful yet.)
	Comment:     by Darryl Hurmi 3/23/2004 Joanna I agree with the basic premise of your article and I believe that trying to do the same tasks for two projects at the same time is a problem for everyone. There is more to it then that, the context switching cost varies by individual I have work with some people that could not switch between projects and others that switched very quickly between several projects. Another issue is how similar is the work that is being done on the different projects, if the projects are at the same point in there development and the work is the same context switching becomes harder. If the projects are at different stages of development switching...Read On Author's Response: 3/24/2004     Darryl, I agree people are different. In my experience, people who attempt to work on debugging on one project and design on another cannot. They shortchange one of the project. So, my experience is different from yours. I once tried to do design on two projects, and it was an unmitigated disaster -- until I stopped working on one project. If you have a person who is a scarce resource, then yes, that person may multiproject or multitask, and the company needs to realize the cost to the projects and the cost to the person.
	Comment:     by Udhay Kumar Ramamurthy 3/23/2004 Hi! I feel that some people would like to do MultiProjecting and show their Heroism - but still they are successful in doing those. What are your comments on those. Please dont say as Exceptions since - they keep doing that consistently. Thanks. With warm regards, Udhay. Author's Response: 3/24/2004     Udhay, some people, some times, are somewhat successful when they multiproject. They look like heroes, especially to management. More often, they slough off work to other people, or create more problems than they fix. The problem is the delay between the problem creation and the problem detection. When you're faced with people who act like heroes and multiproject, look at the eventual total cost. If you calculate the cost to develop, test, and support, you will find the overall cost to be higher (and take longer) than for people who do not multiproject.
	Comment:     by Smriti Metikurke 3/23/2004 Johanna Thanks for the good write up. This is a good article to be shared across teams. I'm forwarding this column to my entire team & let me wait for the response of each person. - Smriti Metikurke Author's Response: 3/24/2004     Smriti, I hope you decide to share the results (if you feel you can).
	Comment:     by Anne Turner 3/22/2004 Thanks for that. I keep telling my managers that multiprojecting is not working for us; it's obvious it isn't, yet they still do it because they think there is no other way to get the work done. I am going to forward this column to them in the hope that they might believe it if they see it in print. Author's Response: 3/22/2004     Anne, good luck. I hope you let me know what happens.
	Comment:     by Gerold Keefer 3/22/2004 excellent idea to point to the common multi-tasking non-sense experienced in the lean and mean corporate world. while project support work might be fed to several projects in parallel, actual development and testing work should not. here are the reasons i came across: 1. (as pointed out) context switches take time. 2. (as pointed out) multi-tasking creates almost always bottlenecks whereby individual delays are exported into all projects and individual gains are lost. 3. necessary, regular communication is inhibited or becomes at least more difficult. 4. defects get injected as people work on similar but not identical tasks (what was it...Read On Author's Response: 3/22/2004     Gerold, my rule of thumb for sharing people among projects or tasks is to ask how complex the task is. The more complex the task, the less sharing is reasonable. People make mistakes with complex tasks (such as development and testing) and the more mistakes they make, the longer the tasks (or projects) take.
	Comment:     by Frank Patrick 3/22/2004 "Multi-Projecting" is not so much the culprit as "multi-tasking." Project delays and context-switching losses come primarily from bouncing back and forth between half-finished tasks without handing off anything that anyone else on the project can work on. It's all right to contribute to multiple projects as long as you don't try to work on multiple tasks from them at the same time -- as long as you pick up your inputs, work on your task until it is done, and hand off your outputs as soon as it is done. Then, move on to the next priority task in your inbox, whether it's from the same project or another. If you're working in a multi-project...Read On Author's Response: 3/22/2004     Frank, it is up to project management to prioritize, and some PMs don't realize the cost of multi-tasking or multi-projecting.
	Comment:     by Bernard Homes 3/22/2004 Johanna, thank you for a nice article. I am currently working on 5 different projects simultaneously and while I doubt that my efficiency is at peak level when changing project, I am confident that my total efficiency is at a high enough level (ie higher that 75%) on each of the projects. The context I work in is as follows : I'm in charge of quality support and independent V&V, and most of my work is dependent on inputs from other teammembers. I have set my own priorities, based on the deadlines for each projects, and it seem to work OK (ie nobody complaints and no delay is created). One thing I would suggest, to those who have to work...Read On Author's Response: 3/22/2004     Bernard, what you're doing is possible (although not the best use of your time) if your deadlines are not tight. And yes, if you allocate days or significant portions of days, you make more progress.
	Comment:     by Sanal Menon 3/22/2004 Column makes good sense. I too agree that working on multiple projects brings down the productivity of an individual. But am also curious to know about the ratio by which the productivity comes down. As per this column, a person working in 2 projects are only 40% productive on each project and one working on 4 projects is only 10% productive. Isn't is a bit unrealistic, having considered only the context-switching time. The productivity loss may also be due to the fact that he does not get enough time to meet the dead lines of both the projects. Let's say that a tester is working on 4 different projects, having similar deadlines. The...Read On Author's Response: 3/22/2004     Sanal, I'm not sure I can differentiate between the lack of available time and context switching time without more information. I've worked in organizations where some people attempted to work on all projects, leading to high context-switching time. And, other people chose to work on only one project at a time, leading to non-availability time.

Back to Top