Changing Minds About Context Switching

The last few times I've taught project management, I've explained that multiproject context switching wastes time. The project managers agree with me. But then they ask, "How do I explain this to my management? They refuse to believe me."

To reach managers and convince them that context switching is a bad idea, be sure to speak their language. First, set the stage by explaining how technical work is different from management work. Next, help your manager determine the relative priority of each piece of work. Finally, block out the work, and keep your management apprised of the status.

Technical Work Is Different from Management Work
Here's one example I've used when explaining how technical work is different from management work. Assume you work for a bank and you have three post-release fixes to complete. One fix is for the branches, for a particular type of new account. One fix is to change the format of particular data you send to the Federal Reserve. And the last fix is in the reporting software that the branches use to report a variety of measures to headquarters.

You're the technical lead for a fiveperson group and each fix will take your group two calendar weeks to complete. That's a cost of ten person-weeks for each fix, a total of thirty person-weeks. Because the fixes are in unrelated systems, you can't batch any of them together. If you perform the work for each fix serially, at the end of six weeks, you'll have all three fixes ready. (See Figure 1.)

If you context switch, the best case is the first fix is finished at Week 5. The best case assumes that each person working on a fix spends the entire week working on a particular fix. Between each week, time is spent context switching to remember the state of the fix. In my experience, it's more likely that the first fix would not be ready until about week seven, the second fix at week nine, and the third fix at about week eleven—if not later. (See Figure 2.)

But that just represents the pressure on the technical staff. Don’t forget the pressure on senior management. In this example, in between their meetings, presentation development, document review, voice mail, and more meetings, representatives from the Federal Reserve, the branch managers, and company headquarters are calling your VP and leaving urgent messages.

Your VP is under tremendous pressure to fix everyone's problems at the same time. So, first explain how you work, and how working on one fix at a time will get one customer off your VP's back. Now, help your VP determine the relative priority of each fix.

Determine Relative Priority for Each Project
Each of these three fixes is critically important to the welfare of this organization. And, because there is a limited number of people, management will have to choose a relative priority for each fix. One question I like to ask about priority is, "What are the consequences to the organization if we select this project first?" Then I ask the same question as we review the project list.

risks in terms of regulatory issues, loss of customers, revenue, and ongoing operations costs. Your organization might rank these issues in a different order or modify this list. Then I ask about the data that says this project is urgent. When I worked with this client, we called Stacy, the Federal Reserve representative, and asked about the auditor’s needs for the data. Stacy was being proactive, but the real deadline was another quarter away. Next, we called Dan, the CFO, and asked,