The Longer It Takes, The Longer-Longer It Takes

Uri -

Here’s two intuitions I have:

  • Almost-everything takes longer than I think it will
  • Longer things take disproportionately longer than I think they will

By which I mean: if something I think will take one week actually takes two weeks, a similar project that I think will take two weeks will actually take eight weeks.

How do you explain that?

I think many of my projects take longer than planned not because the work itself takes longer than I think it will, but because of long stretches of time where I do nothing at all -- something comes up, weeks go by, and suddenly I realise I’ve made no progress at all on that-thing-I-was-working-on. Even if I correctly estimated the number of work-days it would take to finish a given task, I wrongly estimated how long it would take in calendar-days me to get around to those work-days.

You can actually get a result like this from a model where the break-probability and break-lengths are completely unrelated to how long you’ve been working so far. E.g. suppose we assume that once I’m working on something, I’ll do five days of work on it before taking a break of a random length of 1-5 days:

  • A project that takes 5 work-days will be finished after 5 days
  • A project that takes 10 work-days will be finished after (on average) 13 days

And note:

  • A project that takes 11 work-days will be finished after (on average) 17 days

Scoping down a project can have disproportionate impact -- obviously these numbers have been chosen conveniently to show a certain effect, but they show how slightly cutting down the scope of a project can cause it to be finished disproportionately sooner, just by stopping it from spilling over across breaks.

In reality, I think there are two factors that make the situation much starker.

First, I think the length of breaks I end up taking is proportional to the amount of time I’ve spent on the project so far: I have sometimes taken year-long breaks in the middle of multi-year projects.

Suppose that again I work in 5-day increments after which I take a break, but the break is now a random length between 1-n, where n is the number of days elapsed so far. Now...

  • A project that takes 5 work-days will be finished after 5 days
  • A project that takes 10 work-days will be finished after 13 days on average
  • A project that takes 11 work-days will be finished after 21 days on average
  • A project that takes 16 work-days will be finished after 39 days on average

Already we have a much starker effect.

Second, in practice, I think delays kick in with higher likelihood the longer a project goes on. So it's not the case that I work five days, take a break, work five days, take a break – breaks hit stochastically along the course of the whole project, and the longer a project has been going, the more likely it is on any given day that I'll start aa break.

This compounds with the length-of-break effect, of course: the longer a project has been going, the more likely I am to break and the longer the break is likely to be.

At this point, it would be really great if I created a proper model, maybe with one of those widgets that let you play with the paramaters and see how different assumptions affect the outcome. But if I tried to do that, I would probably never get round to finishing this post. The moral of this model is, basically, to scope down projects as much as you can, because the version that's 1/3rd as good as the one you intended might well take 1/8th of the time.