Bad Multitasking

Antipattern: A recurring trap that causes harm — learn to recognize and escape it.

The project-management failure mode in which a scarce resource keeps switching among active tasks even though the switching does not help any project finish earlier.

Also known as: harmful multitasking, bad multi-tasking.

The name isn’t an argument against every interruption. The TOCICO Dictionary is careful on this point: multitasking can be good when switching to another task helps a project finish earlier. Bad multitasking is the opposite. It is the switch made to show local progress, satisfy several project managers, or keep every commitment nominally alive, while the critical chain waits.

Context

Critical Chain Project Management assumes project work happens in a finite-capacity system. The same engineer, test rig, architect, machinist, lab, supplier contact, or reviewer is often needed by more than one task. In a single project, this creates resource contention inside the schedule. In a multi-project environment, it creates competition across projects that all want the same scarce resource at once.

Traditional project management often treats this as a utilization problem: keep people loaded, ask them to make progress on every active project, and trust each project manager to defend their own dates. The result looks productive in local reports. Many tasks have started. Many resources are busy. Many projects can claim movement.

CCPM reads the same situation differently. A resource split across competing tasks isn’t adding capacity. Each switch costs setup time, attention, context, and priority clarity, so every task on the resource’s plate runs longer than its estimate. Budd and Cerveny’s TOC Handbook primer names forced multitasking as one of the pressures already loaded resources face in chaotic project systems. The Dictionary draws the operational boundary: if the switch doesn’t help a project finish earlier, it is bad multitasking.

Problem

Bad multitasking hides a system constraint behind local busyness. A project can have its critical chain identified, its project buffer sized, its feeding buffers placed, and its resource buffers scheduled, then still lose time because the people assigned to critical-chain work are not allowed to focus when the chain needs them.

The pull is strongest in multi-project settings. Not every project can be first priority, but every project manager can pressure a shared resource for visible progress. The shared resource responds by doing a little of everything. No one wants to admit that some projects should wait, so all projects start, all projects compete, and all projects slow down.

Trap

Bad multitasking usually enters through reasonable local behavior.

• A resource tries to keep every promise alive. The person switches tasks to avoid disappointing any one manager, even though each switch delays the real completion of all tasks.

• A project manager asks for visible progress instead of finished work. Starting a task lets the status report show movement; finishing the critical-chain task would help the system more.

• A resource manager optimizes utilization. Keeping every specialist fully loaded appears efficient, but it removes the slack needed to respond when the critical chain is ready.

• A portfolio starts too many projects. Each project looks defensible by itself. Together they create more active demand than the constraining resources can serve.

• The organization treats multitasking as virtue. The ability to juggle several tasks is praised even when the juggling is the reason none of the projects finish.

The distinguishing test is completion impact. If switching to another task unblocks the critical chain or the most threatened project, the switch may be good multitasking. If switching only lets another task show partial progress while no project finishes earlier, it is bad.

Consequences

Bad multitasking damages CCPM in five ways.

It lengthens task durations without changing their estimates. A task that would take two focused days can become a week of fragments. The schedule still carries the dedicated estimate, but the execution system no longer lets the resource work under dedicated conditions.

It consumes buffers for the wrong reason. Project and feeding buffers are meant to absorb task-time variation. Bad multitasking burns them because the resource was pulled away, not because the work itself contained more uncertainty than expected.

It defeats resource buffers. A resource buffer warns the resource that critical-chain work is approaching. That warning has value only if the surrounding organization lets the resource set down non-critical work. If every manager treats their own task as urgent, the alert becomes another ignored signal.

It corrupts priority. CCPM’s relay-runner work ethic asks a critical-chain resource to take the baton, run the task without interruption, and hand off immediately. Bad multitasking breaks the baton pass. The resource starts, stops, returns, restarts, and reports partial progress while the chain waits for finished output.

It spreads into a cascade. In a portfolio, one delayed handoff pushes another task later, which creates more pressure to show progress elsewhere, which causes more switching. At that point the failure mode is no longer one person’s overloaded week. It has become the Multi-Tasking Cascade, a policy constraint on the project system.

Correction

The correction isn’t “try harder to focus.” CCPM changes the policy frame around focus.

Start with the critical chain. Identify the chain after resource leveling, then make the chain’s current task the system priority. The resource assigned to that task works relay-runner style: start when ready, report remaining duration, finish, and hand off. Non-critical work yields when it would delay the chain.

Use resource buffers as real alerts, not decorative schedule objects. The alert tells the resource and the resource’s manager that critical-chain work is approaching. If the resource is still doing non-critical work when the alert fires, the decision is not local. The system is deciding whether to subordinate that work or let it delay the chain.

In a multi-project environment, stagger project releases against the drum or virtual drum. The Dictionary’s CCPM and staggering entries make this explicit: a new project should enter execution based on the availability of the resource, integration point, or policy that paces the portfolio. Starting every funded project at once increases bad multitasking and usually lowers project throughput.

Where multitasking is already severe, use a freeze mechanism. Temporarily stop lower-priority projects, paths, departments, or tasks so scarce resources can finish the active work already in flow. The point isn’t to abandon the frozen work. It is to restore flow on the work that can actually finish, then release more work as capacity becomes available.

Read the fever chart for evidence. If many tasks report partial progress while the project buffer keeps burning faster than the chain advances, the problem may not be one late task. It may be bad multitasking masking itself as effort.

Complements: Student Syndrome — Student Syndrome spends local safety before work starts; bad multitasking spends focused work time after the resource has already been pulled into too many commitments.

Corrupts: Critical Chain — Bad multitasking disperses critical-chain resources across competing work, delaying chain starts and making the project constraint wait.

Detected by: Fever Chart — A fever chart that worsens while many tasks report partial progress often reveals bad multitasking rather than one isolated late task.

Mitigated by: Resource Buffer — Resource buffers warn critical-chain resources early enough to set down non-critical work before the chain needs them.

Produces: Multi-Tasking Cascade — Repeated bad multitasking across shared resources can become a portfolio-wide cascade in which every project delays every other project.

Violates: Subordination — Bad multitasking lets local priorities outrank the critical chain, which is the opposite of subordination in a CCPM system.

Sources

• Cox, TOCICO Dictionary (2nd ed., 2012), entries “multitasking,” “critical chain project management (CCPM),” “staggering,” “freeze (defrost) mechanism,” “resource buffer,” “relay runner work ethic,” and “drum.” The Dictionary supplies the certification-grade boundary between good and bad multitasking and connects the correction to staggering, resource alerts, and project freezing.

• Goldratt, Critical Chain (1997), the originating treatment of CCPM. Introduces the project-management mechanism that strips task safety, protects the critical chain with buffers, and replaces fragmented task progress with relay-runner execution.

• Cox and Schleier, Theory of Constraints Handbook (2010), Ch. 3 (Budd and Cerveny, “A Critical Chain Project Management Primer”), the chapter-length operational specification. Describes forced multitasking in chaotic project systems, the six-step CCPM scheduling sequence, resource buffers as communication signals, and the multi-project problem of too many active projects competing for shared resources.

• Cox and Schleier, Theory of Constraints Handbook (2010), Ch. 2 (Walker, “The Problems with Project Management”), the systems diagnosis behind CCPM. Shows why finite shared resources and variation make PERT/CPM project control unstable in multi-project environments and why monitoring critical-chain resources matters.

• Newbold, Project Management in the Fast Lane (1998), the implementation-grade companion to Goldratt’s project-management work. Develops the multi-project CCPM discipline in which release pacing and priority by buffer status reduce bad multitasking at the portfolio level.