Project Management, as Taught by Eli Goldratt · Lesson 5 of 7

Bad multitasking, and how to stop it

Switching between projects doesn't waste much work time; it destroys lead time. Goldratt's three-project simulation, the story of an aircraft repair depot where engineers held fifty open problems each, and the counter-intuitive cure: start later to finish sooner.

22 min · Not completed yet

What bad multitasking really costs

A person has three tasks, one for each of three projects. The plan: do task a, then b, then c. In execution, under pressure from three project managers, they switch: a bit of a, then some of b, then some of c, back to a…

The real damage is not the set-up time lost in each switch. The actual time worked on each task stays about the same; the lead time of each task increases dramatically. Every project now waits for all three tasks to be finished.

Bad multitasking: interrupting work in a way that doesn’t help any project finish earlier.

And it feeds back into estimates:

Leo: “How long until you can deliver?”

Engineer (thinking): “If I could stay focused on this without interruptions, two weeks. But multitasking is the norm here…”

Engineer (aloud): “Two months, minimum.”

Three projects at once

Goldratt’s simulator ran three projects sharing the same resources. Each one, on its own, was the 140-day project from the last lesson. The conditions were optimal: nobody was interrupted more than once a week, and switching cost no set-up.

Days to complete 10% chance 50% chance 90% chance
A single project, alone 130 150 180
Each of three projects, run together about 315 about 370 about 430

You have already promised the first client 140 days. Two more projects arrive. What completion dates can you honestly commit to?

  • 140 days each
  • About 200 days each, since the work is shared out evenly between the three
  • Hardly any reliable date: each project now takes over twice as long

In a multi-project environment it is very hard to give reliable commitments. We often promise one project before accepting the next, and then can’t renegotiate the first.

What to change, concluded. The core problem is our mode of operation: trying to finish every task on time. There is plenty of safety in projects, but it is masked and wasted. So any solution must make sure that:

  1. Estimates don’t turn into commitments: much less safety is wasted, and gains and delays can compensate each other.
  2. Bad multitasking drops drastically.

The aircraft repair depot

Goldratt told the story of an air force depot that maintained fighter aircraft. In aircraft repair, quality is mandatory, and everything is done by the book. When a problem arises that the book doesn’t cover, experienced engineers must write the procedure and personally supervise each step until the fix is implemented and tested. That engineering department was the bottleneck. Each engineer had more than 50 open problems, and the average time to close one was over four months.

The cycle that created it:

  1. There is a constant stream of new problems.
  2. The same day a problem is found, it is assigned to an engineer.
  3. Each engineer has several open problems.
  4. The other resources needed to fix a problem aren’t immediately available.
  5. Bad multitasking occurs.
  6. The time to close a problem increases.
  7. More problems are open at once, so more and more bad multitasking.

The undesirable effect intensifies its own cause and becomes more and more extreme, until it limited the number of aircraft the depot could work on. To break a vicious cycle, you must contradict a common convention, even if it seems counter-intuitive. Here the convention was: assigning a problem sooner means solving it sooner.

The new policy limited each engineer to 3 open problems; the rest waited, unassigned, in a bank. What happened?

  • The bank of unassigned problems grew forever, since engineers could no longer take new work
  • Multitasking almost vanished, problems closed faster, and the bank shrank
  • Engineers became idle

With little multitasking, the rate at which problems were closed rose dramatically. The time from discovery to closure fell and kept falling, and the bank stabilised where new problems arrived as fast as old ones were closed.

The general convention behind it: the sooner you start a project, the sooner you finish it. Picture a crowd of projects trying to get through one door at once. Let them through one at a time, and all of them get out faster. If you want to finish earlier, you have to start later.

Staggering

The way to stop bad multitasking is to stagger the release of projects. Dictating priorities alone isn’t enough; the informal system is too strong. But over-staggering may leave resources under-used. So where should the staggering point be? Ask: where are projects most likely to get stuck longest? Where are they most likely to cause bad multitasking? Where is it most important to exploit the resource? All three point to the most loaded resource.

  1. Identify the most loaded resource type.
  2. Schedule that resource’s work, considering its limited capacity. This is the drum.
  3. Plan all the projects according to the drum’s schedule.

Two warnings. Don’t release more work, even if resources are idle. And there will still be some residual contentions for other resources: resolving them is a waste of time, since Murphy will put them right back. Don’t optimise within the noise.

Days to complete (three projects) 10% chance 50% chance 90% chance
Project 1, staggered 130 155 195
Project 2, staggered 255 302 360
Project 3, staggered 305 370 425
Each project, before staggering about 315 about 370 about 430

The first project now finishes almost as if it were alone, the second much earlier than before, and the third no later. The way forward is not to fight the remaining contentions, but to tackle the mechanisms that waste safety even in a single project.

Check your understanding

Answer all five. Get four right to complete the lesson.

1. The main damage of bad multitasking is…

  • Set-up time
  • Lower quality from people working under constant pressure
  • A large increase in the lead time of every task
  • Higher wages

Work time hardly changes; lead time balloons.

2. At the depot, the convention that had to be contradicted was…

  • Assigning a problem sooner means solving it sooner
  • Quality is mandatory
  • Engineers must supervise every fix themselves
  • Problems must be recorded

A cap of 3 open problems broke the cycle.

3. Projects should be staggered according to…

  • Their due dates only
  • The client’s importance and the size of each contract
  • Project size
  • The schedule of the most loaded resource: the drum

Then plan all projects around it.

4. Residual contentions between other resources should be…

  • Resolved in detail
  • Left alone: don’t optimise within the noise
  • Escalated
  • Solved with overtime

Murphy will put them back.

5. Any solution must ensure estimates don’t become commitments and…

  • Resources are always busy with project work
  • Budgets are cut
  • Bad multitasking drops drastically
  • Projects start sooner

The two requirements from the analysis.