Convincing Management That Context Switching Is a Bad Idea

© 2005 Johanna Rothman (This article previously published in Better Software.)

The last few times I’ve taught project management, I’ve explained that multi-project context switching wastes time. The project managers agree with me. But then they ask the question, “How do I explain this to my management? They refuse to believe me.”

Managers, especially senior managers, don’t believe context switching wastes time because all they do is context switch. Senior managers frequently have several projects in the air, most of them waiting for input from other people. But that’s not how technical projects work. Most of the time, technical people are not in wait states, but can continue to work productively on projects. Senior managers don’t understand or remember that the work technical people perform is substantively different from the work they perform.

So to reach managers and convince them that context switching is a bad idea, make sure you 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 accounts. 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 group of four other people(a total of five people), and each fix will take two calendar weeks to complete. That’s a cost of ten person-weeks for each fix, a total of 30 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.)

Figure 1

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

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, three people are calling your VP and leaving urgent voicemails, emails, or stopping by your VP’s office.

Stacy represents the Federal Reserve auditor. She says, “I really need that fix for the Fed, and I need it right away. Your guys are working on my fix, right?” Betty represents the branch managers. She’s left your VP several emails and voicemails, each saying “Another call from a branch manager. This problem is costing us a fortune in back-office support to create those accounts with those workarounds.” And Dan, the CFO, represents the Board when he says, “We need the data from the branches. And we need it before the end of the quarter, so we can get ready for the end-of-quarter financials.”

Your VP is under tremendous pressure to fix all of these 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 are 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.

Typically, I ask about consequences and 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 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, and asked, “Would you rather save this much money in back-office work or receive the branch reports?” Of course, Dan said both, and we explained he had a choice of one. If he didn’t make the choice, we would. He chose saving money in the back-office, a choice that surprised both my client and me.

I’ve been in situations where we really did need to have three things done at virtually the same time. In that case, we staffed each fix with its own project staff, and stopped working on new development work. Now we have three projects in priority order: fix the accounts, then the reports, and finally implement the data format changes.

Keep Management Apprised of Status

As you proceed with your projects, make sure you maintain progress on each project. Since you’re not context switching, it’s easier to do that, especially on smaller projects like fixes. Report your progress to management periodically, so they understand you are making progress.

Some of you may be saying, “Well, now I know how to do this for small projects. But I’m managing three big projects, all with the same thirty people. Each project is a year long. How the heck do I stop context switching on these projects?”

Extend the risk analysis for larger projects

First, perform risk analysis for all of the projects, developing a list of projects in relative priority. For larger projects, your management may not be able to or willing to define the relative priority for each project using the issues of regulation, loss of customers, loss of revenue, enhancement of revenue, or reducing operations costs. Two projects may appear quite similar. In that case, either consider how you prioritize projects (which may be out of your control) or consider changing how you develop projects (in your control).

Consider moving to iterations for projects that appear to have the same priority

One technique I’ve used is to move to month-long iterations when two projects are competing for the same people at the same time. Even after attempting risk analysis, if my management still can’t make a decision, I either assign half the people on one project and half to the other, or I select one project. Either way, everyone works on their assigned project for one month, and shows some visible progress. Then I ask management to look at the progress we’ve made. One technique to accomplish this is to implement by feature. If no one looks at the demo or our visible progress, I stop work on that project and move everyone to the other project. If management reviews our progress, I verify that this project is still the highest priority,and continue work. If I’ve staffed both projects with half the people, and management is happy about our progress, we continue with that staffing. Otherwise, if this is enough project work on this project for now, we move to the other project.

Context switching at a one-month boundary isn’t great, but it’s better than the alternatives. But in order for this to work, you need to show demo-able software. It doesn’t have to be release-able, but people outside your project have to be able to see your progress.

Stop the madness

Context switching is insanity, because it guarantees everything will be late. You don’t have to live with multi-project context switching. It requires an understanding of the differences in work between technical people and management. You may need to lead the risk analysis and ordering of projects. And when you’ve selected a project and started working,make sure you can show people your progress at reasonable time periods. It’s hard work to stop multi-project context switching. But the rewards are worth it.

Acknowledgements

I thank Dwayne Philips and Leo Hepis for their review.