"It'll be done next week…"

I have a friend who works at Bain who once told me she always tells new analysts to estimate how long their tasks will take to get done, then, to multiply it by 3 and let her know.

Her secret, she says, is that she then goes ahead and multiplies it again by 2 for her own peace of mind.

You heard it right – she needs a SIXFOLD adjustment to the initial estimate of how long a task will take in order to feel confident it'll actually be done by then.

And if you look at other jobs that also have pre-determined deadlines, like home remodelings and large infrastructure projects, you'll see that these "multipliers" aren't far off.

The official name for this phenomenon is the "Planning Fallacy", one of the many cognitive biases we humans have.

And it's something we all face.

Fellow reader Florian, for example, has shared a tip on how to deal with this:

And here's a funny one I found on Twitter (framed towards programmers):

EVERYONE has this problem.

If you're a manager, you need reliable estimations to plan the work effectively and give good estimations to the leadership team.

If you're the one doing the work, you need to give an estimation to your manager and it better be accurate, or you're seen as unreliable.

I've once heard of a project that even had some time allocated to estimate how much time would be spent on estimating the time to do tasks.

Crazy stuff out there.

So, how do you navigate this madness?

I have a few thoughts…

Time management is expectation management

The first thing to realize is why these estimates are needed in the first place.

In one word: expectations.

Maybe the leadership needs an estimate of how much will the project cost, and so they need an estimate of how much time will each task take.

Maybe they need to coordinate everyone's work, so the issue isn't cost, but sequencing.

Maybe your boss is just anxious. Or worried you'll spend way too much time because you're not that experienced yet.

The way you give an estimate on how much time a task will take heavily depends on the type of expectation of the asking party.

You don't need to give just a number.

You can give two numbers. Or a range. Or a number with a conditional.

Some examples:

• The main concern is cost: "It will likely take 3 days, but at most it'll take 5 days" (now they can add the appropriate margin to the project).

• The main concern is project management / sequencing: "It will take between 2 and 3 weeks, but I can prioritize this part of the deliverable that's what's needed for the next team to start working on it".

• The main concern is anxiety: "I think it'll take a month, but we can schedule a 30-minute checkpoint every Friday to recalculate this and make sure it's going in the right direction"

Using multiples in a smart way

This all assumes you have some numbers to give in the first place, though.

So, how do you get there?

Tracking and multiples.

Tracking means literally time tracking how long you take to do certain common tasks.

"Multiples” means the range, the margin of error.

For instance, I know exactly how long I take on average to write a newsletter. But I also know the longest it took me to write a newsletter.

In my schedule, I always assume the latter, even though it rarely happens.

So, my tip here is this:

For recurring tasks, take note of how long they take (even if it's for a week or a month). Also, take note of the variance of that number. If a task usually takes an hour, but sometimes takes 3 hours, you need both numbers.

In fact, the 3-hour number is more important than the 1-hour number, because people love it when you're early and hate it when you're late.

How to avoid "the trainwreck"

The "trainwreck" happens when people trust your promises, and your promises fail.

The WHOLE PROJECT gets delayed because you didn't hit your deadline.

Or your boss has to explain in a C-Level meeting why they don't have the data they promised to bring.

When estimating the time to do tasks, "the trainwreck" should be top of mind. It's the one thing you want to avoid.

And the root cause of the trainwreck is quite simple:

A false sense of certainty.

Projects almost always have some leeway. C-level teams are more understanding than we imagine them to be.

And if you're inexperienced, chances are that your boss knows that and has their own "multiple" on your estimates, like my Bainee friend does (though I wouldn't count on that).

Sometimes we, trying to show our best, give a tight, optimistic timeline to show we can do things fast. Then when things go wrong, we pull all-nighters to deliver on time and be reliable.

But that's the recipe for the trainwreck because there's no margin for error if the all-nighter doesn't work.

And it often doesn't.

There are two things you can do to avoid the "trainwreck".

The first is this: whenever you're giving a time estimate for an important thing, give them a "certainty index" along with it.

This avoids the false sense of certainty because, even though you gave a number, you also told them how reliable that estimate is.

The second thing is to give them a heads-up if you might be late. With enough time for them to readjust things that depend on your task.

There's usually some leeway, but things need some time to be adjusted and communicated.

Most people understand when things don't go as planned.

But most people don't understand why you didn't let them know earlier.

Keep working smarter.