In Cost of Delay: Not Shipping on Time, Part 1, I introduced you to the notion of cost of delay. I said you could reduce the cost of delay by managing your projects: have shorter projects, using release criteria, or selecting a lifecycle that manages the risk.
Sometimes, you don’t have short projects, so projects get backed up, and your managers ask you to work on several things at once. Or, the managers can’t decide which project is #1. Somehow, you end up doing several things “at once.” This is the multitasking problem, and this is the cost of delay in this part.
You know me, I hate multitasking. The costs are significant. But those are just the costs of multitasking on the work you are doing now. That has nothing to do with the cost of delay to your projects.
In Manage It!, I have this nice picture of what happens when you try to multitask between two projects.
 |
| Two Tasks or Projects |
Imagine you have two projects. Each of them should take a week. Hey, they’re short projects. I’m trying to illustrate a point.
You can deliver one of them at the end of the first week. You can deliver the second one at the end of the second week.
But, imagine you have to multitask between them. Instead of being able to deliver anything at the end of the first week, you can’t deliver anything at all until the second week. And, depending on how much context switching you do, you might not be able to deliver anything until sometime during the third week. The blue boxes show the time lost due to context switching.
 |
| Effect of Multitasking Delay to Delivery |
This is a huge cost of delay due to multitasking.
How do you calculate this?
“Big” is not quantitative enough for some people. This is where using some of the tools from the people who do this for a living might be good.
I’ve always drawn a picture like this and explained, “I don’t know how to estimate the time in the blue boxes. The blue boxes are the delay times. I can’t estimate them, because everyone else is delayed by multitasking on their projects, too. Sometimes, it takes me an entire day to get an answer to a question that should only take me an hour to get an answer. All I know is that “ideal” time is irrelevant to actual time. And even calculating using relative estimation is hopeless. That’s because we are multitasking. All of our estimations are out the window because we are multitasking.
“The amount of time we spend working on a project might be accurate. It’s the wait time that’s killing us. I don’t know how to estimate that.”
What I’ve done before is take a two- or four-week window, and ask people to write down their predictions of what they thought some task would take. Then, I ask them to write down, as they spend their time on each task, how much time they actually spend on each task. Now you can compare the prediction to reality.
Remember that all of the context switching and wait time is the time you need to remove from the maximum sales revenue, had you released the product.
This is very difficult to do. It saps the morale of the people doing the work. They quickly realize how often they go back to the same thing, over and over and over again, making zero progress, trying to realize where they are. Do not do this for more than a four-week window. If you must do this, label this an experiment to obtain data. Explain you are trying to obtain actual work time, context switching time, and wait time. Let people label the time as they will.
The managers will be astonished by how little time the technical staff spend on real work. They will be amazed by how much time the technical staff spend on context switching and wait time. This is why managers think technical staff are bad at estimation. Who can be good at estimation when they are multitasking?
The problem is this: the cost of delay due to multitasking is real. It’s invisible to most people, especially management. It’s not just the cost of the blue boxes in the picture above. It’s the fact that nothing gets out of your organization until the end of Week 2 or later. Remember the back of the napkin in Part 1? Even if you use that calculation, you can see you are losing revenue left and right due to multitasking.
Remind the managers: Remember that all of the context switching and wait time is the time you need to remove from the maximum sales revenue, had you released any of the products.
Can you use this as an argument for your managers to end the multitasking and manage the project portfolio?
Cost of delay due to multitasking is real. What would you need to know to calculate it in your organization?
To take a devil’s advocate approach, if you only do one task at a time, there will be points within the task where you are waiting on others (or for something to complete). Having multiple tasks in your bucket, you could take this down time to switch to another task and come back to it when it is ready. I agree that forcing multitasking can cause delays, but sometimes avoiding multitasking can lead to delay too.
Kazar, my approach to agile is closer to lean. If you are waiting on others to finish something, I suggest you help that other person, or at least ask if you can help them get that thing to done.
The goal is to move the story or feature to done, not to optimize any person’s work. If you look at optimizing for the *team*, you might think of multitasking differently.