You can reduce the cost of delay by managing your projects: have shorter projects, use release criteria, or select a lifecycle that manages the risk.
But sometimes, you don’t have short projects. So projects get backed up, and your managers ask you to work on several things at once. This is the multitasking problem. 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.
Imagine you have two projects. Each of them should take a week. (Hey, they’re short projects.) You can deliver one at the end of the first week and one at the end of the second week.
But 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.
This is a huge cost of delay due to multitasking. How do you calculate this?
I’ve always explained, “I don’t know how to estimate the time lost due to context switching 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. Even calculating using relative estimation is hopeless. The amount of time we spend working on a project might be accurate. It’s the wait time that’s killing us.”
What I’ve done before is take a two- or four-week window and ask people to write down their predictions of how much time they thought some task would take. Then, as they work, I ask them to write down how much time they actually spend on each task.
It saps the morale of the people doing the work because they quickly realize how often they go back to the same thing, making zero progress, trying to realize where they are.
The managers will be astonished by how little time the technical staff spend on real work and how much time they 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 cost of delay due to multitasking is real. It’s invisible to most people, especially management. It’s not just the cost of time lost due to context switching; it’s the fact that nothing gets out of your organization until the end of the second week or later.
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 on time. Can you use this as an argument for your managers to end the multitasking?
