Do you know why the plans we make often tend to fail? đź‘€
How many times have you promised someone, “You’ll have the report by Saturday.” And when Friday comes, you’re sitting on your work desk with a pile of papers all around you, not knowing where it all went wrong.
Welcome to the world of the planning fallacy where architects underestimate how long a renovation will take to complete, writers underestimate the time they’ll take to complete a novel and you underestimate the time you’ll need to complete that report.
But what exactly is this fallacy about?
It’s a tendency where we underestimate the time that is required to complete a task even when we know that similar tasks have taken longer in the past.
Wait! It gets worse. Even when we know we’re likely to underestimate deadlines, we still go ahead and do just that.
Ughh!! I know.
Here are three solutions to this though-
- If you think you’re going to complete something on Friday, add a buffer to it. Tell your client you’ll submit the report by Saturday. If you get it done by Friday, yay, brownie points for early submission. But be careful when you do this, because Parkinson's law is a real problem too (which is one of the main reasons why I recently added the features of time boxing and setting deadlines inside Brutask)
- Break down your projects and estimate how long each part will take. This makes your timelines more accurate.
- Always, and I mean, always, measure the time you spend working on each task. Use this data to make accurate predictions.
Love,
Siddhita ❤️
These are great tips. I worked with a guy who was an amazing estimator. He could produce timelines for multi-year software engineering projects that were surprisingly accurate. If you read any literature in software engineering estimation, you'd know that this is basically considered to be impossible.
The secret to his success went one step beyond these recommendations, and he tracked why schedules shifted. During the course of a project, he tracked typical burndown-style task metrics - estimated task time, actual task time, hours remaining, etc. But he also tracked what changes were made to the schedule after it was first introduced: extra unplanned work, tasks that were removed, anything that really made the schedule change. At our weekly planning meetings, he'd look at why schedules were moving and address those problems. This gave him an insight into trends that he could proactively correct, like "Hey, we're adding way too much work after we start working, which means we're not thinking enough at the start."