Why "Urgent" Work Is Often Slower Work
Switching between tasks carries a measurable performance cost, even when the switch is planned and expected. Research on task-switching has found productivity losses in the range of 20 to 40 percent when people frequently divide attention across multiple tasks, compared to completing the same work with sustained focus. This cost shows up twice: once during execution, when a task worked in fragments takes longer in elapsed time than the same task worked start-to-finish, and once before work even begins, when people who expect to be multitasking build that expectation directly into their duration estimates — quietly inflating "how long this will take" well beyond the focused effort actually required, in a way that never shows up as a visible schedule slip.
What Multitasking Actually Costs
"Multitasking," in a project context, almost never means doing two things at the literal same instant. It means switching attention between tasks — working on one thing, getting pulled onto something else, and coming back later. Cognitive psychology research on this pattern goes back to task-switching experiments by Robert Rogers and Stephen Monsell in the 1990s, which found that people are measurably slower on a task immediately after switching to it than when repeating a task they were already doing — even when the switch is fully predictable and rehearsed in advance. Later research, including work by David Meyer, Joshua Rubinstein, and colleagues, extended this finding and estimated productivity losses from frequent task-switching in the range of 20 to 40 percent, with more complex tasks generally carrying a heavier switching cost than simple, routine ones.
This cost isn't a matter of willpower or discipline. It reflects real mental overhead: re-establishing context, recalling where a task was left off, and reloading the specific rules or state relevant to it. That overhead is paid every time a switch happens, regardless of how skilled or experienced the person is.
Why This Doesn't Show Up in Most Project Schedules
Most scheduling approaches estimate a task's duration as a fixed number — a certain number of hours or days of work — independent of how that time will actually be allocated during execution. A task estimated at three days of work is treated as taking three days whether it's worked continuously or spread across three weeks in scattered fragments between other commitments.
In practice, these are not the same three days. A task worked in fragments accumulates re-entry overhead every time it's picked back up, and it's also exposed to a longer window during which new interruptions, priority shifts, or dependency changes can further delay it. The three days of actual effort might be accurate, but the elapsed calendar time to complete the task can be substantially longer — and that gap is largely invisible to a schedule that only tracked estimated effort, not how that effort would actually be delivered.
Why "Everything Is Urgent" Makes This Worse, Not Better
When many initiatives compete for the same people, a common organizational response is to mark most of them high priority — the reasoning being that important work shouldn't wait. The effect is often the opposite of what's intended. If everything is labeled urgent, a person facing multiple urgent demands has no clear basis for choosing what to work on first, and ends up dividing attention across several things at once, each one accumulating the switching cost described above.
The result is a system where a large amount of work is technically progressing simultaneously, but the total throughput — how much work actually gets finished, project by project — is lower than it would be if people worked fewer things at a time, in a clear sequence. This is easy to miss from a distance, because activity and utilization can look high even as completion rates stay low. People are visibly busy; the work is not visibly moving.
The Cost Multitasking Adds Before Work Even Starts
Everything above describes what happens to a task once work is underway: switching costs accumulate, and elapsed time stretches beyond the effort actually required. There's a second, earlier effect that's easy to miss because it never shows up as a visible delay — it's baked into the estimate itself, before the task is ever scheduled.
When someone is asked how long a task will take, in an environment where multitasking is the normal way work gets done, they don't answer with how long the task would take under sustained focus. They answer with how long it will actually take them, given that they already know they'll be interrupted, pulled onto other priorities, and asked to context-switch throughout. A task that would take two focused days routinely gets estimated at a week or more — not because the person is padding dishonestly, but because they've learned, correctly, that a two-day estimate assumes a condition (uninterrupted focus) that doesn't exist in their actual working environment.
This is a different mechanism than the elapsed-time stretching described above, and it's arguably more consequential, because it never appears as a schedule slip. A task estimated at a week that takes a week looks like accurate planning. Nothing about it signals that the real, focused work inside that week might have been two days, with the other three absorbed entirely by anticipated — not even actual — multitasking. The inflation is invisible precisely because it succeeds at predicting the very dysfunction it's compensating for.
The result compounds at the organizational level. If most duration estimates across most projects already have this anticipated-multitasking buffer built in, the organization's baseline sense of "how long things take" is calibrated to a chronically multitasking environment, not to how quickly the work could actually move. Reducing multitasking later doesn't just recover the execution-time cost described earlier — it also exposes how much slower the organization believed itself to be than it actually was, which can be disorienting in its own right: work starts finishing faster than historical estimates would have predicted, and the gap is the accumulated cost of this anticipatory inflation, not a sudden improvement in skill or effort.
This is closely related to what critical chain project management calls a task's focus duration — an aggressive estimate of how long work takes with full attention and no interruption, deliberately kept separate from any padding for multitasking or interruption. See Critical Path vs. Critical Chain for how this concept fits into buffer sizing more broadly.
An Alternative: Sequencing Instead of Dividing Attention
An alternative to distributing partial attention across many "urgent" tasks is to establish a clear priority order and ask people to work their highest-priority task until it's finished or ready to hand off, before moving to the next one — rather than progressing several tasks partway at the same time. This approach is sometimes described using a relay race as an analogy: a runner carries the baton as fast as possible and hands it off cleanly, rather than trying to run two legs of the race at once. ProChain summarizes this concept as “prioritize, focus, finish.”
This requires the organization to actually establish and communicate a real priority order, rather than treating most work as equally urgent — which is a harder organizational commitment than it sounds, since it means explicitly deciding some legitimate, valuable work will wait. The alternative, however, is the switching cost described above being paid by default, across every task simultaneously in motion, in exchange for the feeling that nothing is being neglected.
Common Questions
- Does multitasking actually slow down project delivery?
- Yes, in most cases. Task-switching carries a measurable performance cost — commonly estimated at 20 to 40 percent lost productivity when people frequently divide attention across tasks — and this cost is rarely reflected in project schedules that treat a task's duration as fixed regardless of how continuously it's worked.
- Why does a task estimated at three days sometimes take three weeks to actually finish?
- The three days likely refers to actual hands-on effort, not elapsed calendar time. If that effort is spread across many short sessions interrupted by other priorities, each resumption carries a re-entry cost, and the task is also exposed to a longer window in which new interruptions or delays can occur — both of which extend elapsed time well beyond the effort estimate.
- Does the expectation of multitasking affect duration estimates even before work starts?
- Yes, often significantly. In environments where multitasking is normal, people tend to estimate task durations based on how long the work will actually take them — including anticipated interruptions and context-switching — rather than how long it would take under sustained focus. This inflates estimates in a way that never appears as a schedule slip, since the padded estimate is met, which makes the underlying cost of multitasking easy to miss even when it's substantial.
- If everything on a team's plate is labeled urgent, what typically happens?
- People facing several simultaneous "urgent" demands generally end up dividing attention across them rather than completing any one quickly, which increases total switching cost and tends to reduce overall throughput, even though individual people appear busy and engaged throughout.
- What's a practical alternative to constant task-switching on a project team?
- Establishing a clear, single priority order for each person's work, and having them complete or hand off their top-priority task before starting the next one, avoids much of the switching cost that comes from partial progress on several tasks at once. This requires genuinely prioritizing some work over other work, rather than treating most tasks as equally urgent. Using a planning and execution tool designed for complex, dynamic environments, like Fusion Online, can help provide useful prioritization guidance based on a current picture of each task’s criticality.
The Short Answer
Multitasking has a real, measurable cost that shows up in two places most project schedules don't account for: it stretches elapsed time during execution, and it inflates duration estimates before the work even starts, once people learn to anticipate it. Labeling most work "urgent" tends to increase multitasking and switching costs rather than accelerate delivery. Establishing a genuine priority order, and working tasks to completion before switching, avoids much of this cost — at the price of explicitly accepting that some legitimate work will have to wait its turn, and possibly discovering that the organization's real potential for speed and productivity was substantially higher than its historical estimates suggested. This principle is one of the core mechanisms behind critical chain project management — see Critical Path vs. Critical Chain for how it fits into the broader scheduling approach, and Resource Contention Across Multiple Projects for the related problem of shared people being split across simultaneous work.
