#### A series of 5-minute posts on applying principles of flow to knowledge work

If I asked you to tell me how many minutes it takes you to get to work, what would you say?

The number you thought of is probably an average. Sometimes it takes less, sometimes more, but most days it’s clustered around the middle. Let’s say it’s 30 minutes:

But this graph isn’t quite right. Because the bell curve is not actually symmetrical on both sides, is it?

There’s a chance your commute could be shorter, but not *much *shorter. There’s a bottom limit to the absolute shortest time it could take you to get to work. Let’s say 15 minutes:

And the right side is not so simple either. There is an increasingly smaller chance that your commute could take a *long *time, with no upper limit. It’s conceivable that you could get sick, get in a traffic accident, have an emergency at home, or there could be a natural disaster. It could take you hours to get to work.

What this leaves us with is a *right-skewed* graph:

There is a 10% chance that it will take 60 minutes to get to work, a 5% chance that it will take 90 minutes, and a 0.1% chance it will take 120 minutes.

Notice that, when we include that long tail on the right, the *real* average is not at the peak of the curve, but a little to the right: 45 minutes, not 30 minutes. We don’t usually take into account traffic accidents and natural disasters when planning our commute, but statistically they do have an effect.

Now what if I asked you to pick a typical task from your to do list, and to estimate how long it would take to complete? Let’s say you estimate that it will take 2 hours.

Then I ask you how confident you are in your estimate, in terms of the probability of completion within that time. In other words, what do you think is the chance that it will actually be completed within 2 hours?

Most people will intuitively give it 50% confidence — they think they’re equally likely to need more than 2 hours, as to finish within 2 hours. As in the commute example, they assume that their own estimate is an **average**:

But it’s almost certain that your estimate is actually closer to 90–95% confidence. How do I know? Because only a lunatic would set an expectation for themselves that they have a 50% chance of failing:

In estimating commute times, we can blame all sorts of external factors for being late, so our estimate is more objective. But at work, our objectivity gets skewed by the potential consequences of failure.

So what’s the problem? Workers set expectations they think they have a high chance of meeting. Isn’t that called “being responsible”?

On an individual level, yes. But think about the implications at the system level. On a distribution with such a long tail to the right, any estimate with 95% confidence is typically 2–3 times longer than the true average (at 50% confidence):

Which means that every time we give an estimate at 95% confidence, we are adding 100–200% in padding to the time actually needed. A project full of tasks with 100–200% padding adds up to a project with a dramatically longer lead time than truly required.

This is problematic not only because long projects are costlier and riskier, but because the financial penalty for delaying a project almost always dwarfs everything else. By “protecting” each and every little task with massive padding, we expose and endanger the project as a whole. This is exactly what we saw in manufacturing: optimizing the efficiency of individual parts lessens the effectiveness of the whole.

Absolutely no one, of course, will admit that they do this. They’ll say that they add, at most, 5% or 10% to their estimates, “just in case.” The incentives for this behavior are so deeply ingrained in the structure of the workplace, we don’t even see them.

Consider that not only are we penalized for taking longer than our estimates, we are not rewarded for finishing early. Finishing ahead of schedule just invites pressure from managers to cut the estimate for next time. More subtly, what’s the point of finishing ahead of schedule when we know the person we hand off our work to won’t be ready anyway? We can always find something to polish, optimize, or (over)engineer.

What we are left with is constant pressure to add padding to estimates (to make sure we hit them), and no counter-pressure that would reward faster execution. And this happens at every level: each manager adds their *own* padding to the combined estimates of their subordinates, to make sure *they* aren’t in danger of overshooting, and so on all the way up the ladder.

By the time it gets to the top, the total estimated time to completion for a project is so radically inflated that the executives issue drastic, across-the-board cuts of 10%, 20%, 30% or more. But the people at the bottom of the pyramid have been around the block a few times: they *knew* this would happen, so they already added *even more* padding in the first place to compensate for it.

Estimates in this environment become a self-fulfilling prophecy, always growing and never shrinking, discouraging anyone from taking advantage of opportunities for acceleration, even when they appear.

Now here’s the paradox: you would think conservative assumptions in estimation would lead to on-time delivery. That adding so much padding, despite the drawbacks, would at least result in not overshooting the project delivery date. But what if it was that conservatism itself that *produced* the delays? What if the *more* padding you added to ensure on-time delivery, the *later* the project was likely to be?

We’ve begun to enter the strange world of **Critical Chain Project Management (CCPM)**, the application of the Theory of Constraints to project work. We’ll explore the pillars and implications of CCPM over the next few posts in the series.

**Follow us for the latest updates and insights around productivity and Building a Second Brain on Twitter, Facebook, Instagram, LinkedIn, and YouTube. And if you're ready to start building your Second Brain, get the book and learn the proven method to organize your digital life and unlock your creative potential.**

- POSTED IN: Flow, Project management