AYE Conference » context switching

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.)

Week 1	Week 2	Week 3	Week 4	Week 5	Weeks 6
Start Fix 1	Finish Fix 1	Start Fix 2	Finish Fix 2	Start Fix 3	Finish Fix

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).

Week 1	Week 2	Week 3	Week 4	Week 5	Weeks 6	Week 7	Week 8
Start Fix 1	Start Fix 2	Start Fix 3	Work on Fix 1	Finish Fix 1, Work on Fix 2	Finish Fix 2	Work on Fix 3	Finish Fix 3

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.

convert this post to pdf.

This article was originally published on Stickyminds.com

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 only maintained their time organization 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 multi-projecting 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. Multi-projecting 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 multi-projecting, 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, Vol. 1: Systems Thinking, a person who works on two tasks only spends 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 spend only 10% of her time on each task, wasting 60% of this person’s time! Clearly, multi-projecting is not a technique for finishing projects quickly.

Nothing Up My Sleeve

So what could this CIO do to complete both high-priority projects in the desired timeframe?

In this case, the problem of two small, short-duration projects using the same staff with unplanned and unplannable interactions, the CIO could first decide which project is higher priority. The CIO could then assign the entire team to that project, and, using release criteria to make sure the minimum work is done on the first project, as people come off of that project, start them on the next one.

People do not multitask easily because of the context-switching cost. It is easier and more productive for people to continue working on the same project, at the same level, for as long as possible. It costs time and brainpower to switch to another project or to another activity. Rank your projects, and make sure people know what done means, so they only do the minimum necessary. Don’t fool yourself with an illusion of progress; make the progress real.

Acknowledgements:

I thank Elisabeth Hendrickson and Frank Patrick for their reviews of this column.