I’ve been discussing Eli Goldratt’s third business novel, Critical Chain, which explores project management.
Goldratt’s primary point is that padding individual task estimates with safety just means that a lot of time gets wasted. All that safety should get pooled into a few strategically placed buffers.
But Goldratt makes a secondary point about multi-tasking — namely that it does terrible things to lead times.
Imagine that you have three tasks to get done — X, Y, and Z — and each takes 10 days to finish. Your lead time should be 10 days for each task.
If, on the other hand, you start each task, get it half done, then flit to another of the tasks, get it half done, then work on the remaining untouched task, and get it half done, before returning to the first and finishing it, then your lead time will double to 20 days for each task.
Now, Goldratt only hints at this in Critical Chain, but how bad is extra lead time? Does it matter? Well, yes and no. For any task not on the critical path, no, it shouldn’t matter, not as long as there’s enough slack. For any task on the critical path, yes, of course, it matters a great deal.
To play devil’s advocate for a moment though, when would it make sense to switch away from Task X to Task Y? Goldratt asserts that workers multi-task simply to keep busy — and I’m sure that’s often the case — but what happens when you can work on Task X, but Task Y is critical? You work on Task X until Task Y is ready for you, then you switch to Task Y, leaving Task X half done. What happens when Task Z, which is even more critical, is ready for you? You switch to it.
The problem comes when you switch back to Task X without finishing Z, then Y, because those were the more critical tasks; otherwise you never would have — or never should have — switched to them in the first place.
In such a case, starting a low-priority task early, to keep busy, might inflate lead time numbers, but it doesn’t hurt the project’s progress at all.
The key is always knowing which tasks are critical or threatening to become critical — to have buffer-driven task priorities. By looking at each path’s relative buffer burn rate — the percentage of the buffer penetrated versus the percentage of work completed on that path — we can immediately see which paths, and thus which tasks, deserve priority.