Cost of Delay Due to Multitasking, Part 2

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
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
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?

COD Series:

Jutta Eckstein and I gathered all of these posts into a book: Diving for Hidden Treasures: Uncovering the Cost of Delay in Your Project Portfolio.

12 Replies to “Cost of Delay Due to Multitasking, Part 2”

  1. One of the big challenges for companies that sell bespoke solutions is that their sales model relies on making promises to clients to close a sale. If they were to say to a potential client “your order is at the back of the queue and you must wait for projects A, B and C to complete before we start on yours” they would likely lose the sale. So they try to keep everyone happy and generally end up disappointing everyone, and also set up the development teams for failure by forcing them to multitask right off the bat. It’s madness but we keep doing it, probably because of the way the incentives are structured — Sales get bonuses for closing, project managers are rewarded the more projects they run concurrently, managers build power from having more staff to manage — and so around it goes.

  2. You also unwittingly made the case for using JavaScript as a backend language/framework. Because of the big bad context switch and loss of productivity. This means in order to be fully productive as a developer I should avoid any project that requires multiple languages (tools).

    If only real life were that simple. The fact is you are constantly switching between tools in one project more often than not. This could be as simple as swapping libraries out or as complex as replacing a whole framework or language. Each with its domain specific knowledge.

    When we ask a carpenter to build a house we don’t tell them “Try to only use nails because switching between nails and screws will slow you down.” That’s complete nonsense and as a manager you should understand that context switching can be accounted for by expecting less than 100% efficiency from your developers.

    They are humans not robots so treat them that way.

    1. Stephen, I agree with “Treat people as humans, not robots.” Absolutely. As to the specific tool? Everyone’s environment is different. If you have to switch between different tools, is that a different cost of delay for you? Is there a good reason for it? I have no idea. I don’t know why things are that way. I would ask the question, “Do they have to remain that way?” Is there a reason for them to do so?

      I ask out of ignorance. Maybe there is a darn good reason for the tools to remain that way. I have no idea. The (old) developer in me wonders if there is a way to build a command line script that wraps things up so you don’t have to switch things so often. But I have no idea.

      I do agree with on one thing: Expecting 100% efficiency from any one human is stupid. That’s optimizing at the lowest possible level in the organization. That is total nonsense. You (not you personally) never optimize at the lowest possible level. You optimize for throughput through the system. In this case, through the project. Optimizing for any one person’s efficiency (as if we knew how to measure that) is craziness.

  3. I agree, context switching has a huge impact. Therefore I find it difficult to read the first part of your article, but not the second. All those links to other pages in the first part is to me just noice.

    To all all of you good article writers: use good old fashioned footnotes for your external links, and let me concentrate on your article, it deserves the undisturbed attention.

    Thanks Johanna!

    1. Christer, oh, you made me laugh! I struggle to set the context, when I write and when I speak. I thought I was doing so at the front of this post. Oh well. I thought by having the posts open in new windows that might help. Double oh well 🙂

      Thank you for the feedback. Caution: you might not want to read the further posts in this series… I hope you do.

  4. Really? It *is* possible to multi-task effectively on software projects, but not all people are capable of doing it. In my experience only perhaps 10% are capable of it.

    Folks who can multi-task should reasonably expect to be paid better than those folks who cannot.

    1. Sue, Well, your experience is different from mine, but that’s what makes the world a wonderful place.

      How can you tell who can really multitask? I am asking from a place of curiosity. I really cannot tell. Every time I meet people who think they can, it turns out they have created problems down the line. This is why I am asking.

  5. Stephen I’m not sure you understand Johanna’s overall point. The way I read this post is not so much about the switching of tools a developer uses – that in an of itself is the nature of the business. A developer often needs multiple tools to fully implement a feature. And that’s not so much a switch of context because the developer is still thinking about either a very specific technical detail or the overall design of their solution. The context is unchanged, for the most part.

    Speaking as a former developer, and now a manager of developers, the real cost of context switching is introduced by project managers (mostly, but others as well) calling ad hoc meetings, doorway conversations, etc that pull developers away from what they’re doing to answer, most of the time, questions unrelated to the tasks their presently performing. The questions could be about projects that have been closed out, solutions deployed and in an operational or maintenance state, and the PM has questions about how something implemented in those solutions could apply to a future solution for another customer. That’s just one example. In essence, it’s the switch from the very tedious, logical methods of problem solving and solution implementation to, oftentimes, abstract questions about as-yet undefined requirements for projects to which the developers have had little to no exposure.

    If you add up these short distractions the impact is definitely noticeable. Now, I believe the information the PMs need from the devs is vital to their success, but I also believe the process by which this information flows could be better managed.

    Thanks, Johanna, for your insightful post.

  6. Kevin, the context switching to answer a question is real. Your example is from project managers, which is quite irritating. Agile attempts to manage that with standup meetings. When those meetings work, they are great. When they don’t work, they are horrible.

    Paul Graham has a classic essay about this: Maker’s Schedule.

    There are other interruptions, such as when people have questions. You see this a lot when people have their own little areas of expertise. If everyone is a generalizing specialist, it’s not so bad. There are fewer interruptions. But if everyone is an expert, you have more bottlenecks, and more questions. There are more interruptions and more multitasking.

    If PMs want data about project state, even in a waterfall project, they can create a kanban board. Kanban works for any project, regardless of lifecycle. That would allow them to not interrupt the developers/testers/writers/whomever. That would eliminate one source of meetings and therefore multitasking.

    Thanks for writing.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.