When it was announced, the Sydney opera house had a target completion year of 1963, and a budget of $7 million.

Exactly a decade later (1973), and ~$100 million over budget (14x the original estimate!), the Sydney Opera house opened its doors.

Humans are predictably terrible at estimating timelines. We're optimistic, we disregard our past experiences, and we consistently fail to grasp the intricacies of the tasks we need to accomplish.

This phenomenon has a name –– the planning fallacy.

The reach of the planning fallacy goes well beyond construction projects. It affects the projects we do at work, how we are evaluated, and ultimately whether we successfully accomplish our goals.

The predictability of the planning fallacy is its biggest weakness. It's root causes are well-understood, and by taking a structured approach to timeline planning, you can overcome the planning fallacy.

Why does the planning fallacy happen?

The Planning Fallacy was originally proposed by famed behavioral economics Daniel Kahnmenan and Amos Tversky in 1979, and has been closely studied ever since. Researchers have coalesced on a consistent set of findings.

🌏 Humans think broadly

A simple task like cleaning the kitchen is comprised of multiple smaller tasks: washing the pots and pans, unloading and filling the dishwasher, cleaning the stove, taking out the trash — the list goes on. If you simply think about the one large task, it's easy to assume it will be easy to tackle. Once you enumerate exactly what that task entails, you begin to see how it would take longer than you expect.

🔀 Humans are bad at managing dependencies

Determining the interdependency of complex projects does not come naturally to us. We gravitate to what is easiest for us, not to what will unblock or accelerate the larger project.

🌟 Humans are optimistic

Humans love the happy path. To help us complete the task at hand, we think about the desired end state. The natural consequence of this optimism is two-fold: we think tasks will be easier than they actually are, and we don't plan for failure.

Given that projects contain a great deal of complexity and uncertainty, involve multiple people, and carry a large cost in the case of failure, it's completely understandable that we struggle with estimating how long they will take.

Luckily, there's a way to conquer the planning fallacy.

How to come up with a timeline that conquers the planning fallacy

Once we truly understand what leads to the Planning Fallacy, we can take steps to avoid those root-causes in our planning process.

Below are the steps you can take to ensure your timeline is realistic, and doesn't become a victim of our flawed intuition.

Get granular

As we've discussed, a seemingly simple task can be comprised of several harder-than-expected subtasks.

The smaller the task, the easier it is to estimate.

When determining a project timeline, break up the initiative to its smallest constituent elements, and estimate those instead. Once you have all of them, add them together to get the larger timeline.

• Start broad. What are the biggest separable parts of of the project.
• Within each of those, identify the user-specific interactions. In other words, put yourself in the shoes of a user to determine what they're seeing that you need to build.
• Within each user-story, break down exactly what needs to be done to deliver the experience. In the end, these should ideally be tasks that will be assigned to specific individuals.

Once you have enumerated the subtasks that comprise the entire project, estimate how long each of those subtasks will take.

Then just add them up, and you have the overall number of days a hypothetical individual would take to complete the project.

Determine your time budget

Once you have the amount of time your project will take, it's time to figure out how much time you actually have with your current level of staffing.

To determine your time budget, the first step is identifying who is working on the project, and how much time he/she has allocated to it specifically.

In an ideal world, he/she is working on the project 8 hours a day, 5 days a week. But between onboarding new employees, vacation time, holidays, and other time out of the office, the realistic time budget looks much different than the real time budget.

Once you have your time budget, you can determine who should work on which specific tasks.

But before you can do that, you need to determine the order of the tasks you need to accomplish.

Demystify dependencies

Understanding how the tasks that comprise your project are dependent on each other is a prerequisite to determining the order in which you'll complete those tasks, and therefore who is working on them.

To determine the order of the tasks that you'll need to accomplish, go through the entire list and identify which tasks need to be completed to start work on the other tasks. Go task-by-task and identify if it depends on another task or is a dependency on another task.

Once you understand those relationships, make a graph to determine if there are any choke-points or risky tasks. Once you understand these relationships, you can determine how to tackle them in sequence with the staffing you have available.

HINT: A good tool to graph dependencies of tasks is DiagremmeR, which can be run in R.

Plan with failure in mind

As we've discussed, humans are optimistic, and would prefer to visualize the happy path. Unfortunately, the happy path is often the path less trodden, so it's incumbent upon you to plan with failure in mind.

In your time budget, account for lost time

Few people spend their entire work week on whatever project they are working on. Between ramp-up, vacation time, bugs, and holidays, most engineers are working at less than 75% capacity on a given project. Explicitly account for this lost time in your timeline to provide a more realistic estimate.

Add testing to the project plan

In a perfect world, everything we build would behave as expected.

Unfortunately, we don't live in a perfect world. Building a resilient infrastructure to identify and resolve bugs is a costly but worthwhile investment, and ensures that your product offers a good user experience.

As part of your project, carve out specific time for your developers to write the tests that will ensure your project behaves as you'd expect.

Want to spend less time writing these tests?

Try walrus.ai – an API that lets you write integration tests in plain english, with one line of code. Your team can spend more time writing the code that your customers will see, and less time working on tests. Want to learn more? Get your first test results in five minutes.

Putting it all together

Humans are bad at creating timelines, but at least we're predictably bad. By adopting a process that addresses the root-causes of the Planning Fallacy, we can begin to estimate projects with more accuracy.

In the end, creating a better timeline comes down to a few simple steps:

1. Identify the tasks that comprise your project to the granularity of what an individual would work on in a given day, and estimate how long each of those tasks will take. Be prepared for the unhappy path, and add tasks like writing integration tests into the plan.
2. Determine the budget of time you have available per person who is working on your project
3. Outline the dependencies of the tasks that comprise your project to determine the order you need to complete them
4. Based on the availability in your time budget, identify who should work on each task

Than you just have to follow the plan.

Planning for failure, but want to move fast?

Spend less time writing tests to ensure your product works as expected.

Walrus.ai lets you write integration tests in plain english, in one line of code.

Try it for free, and get your test results within 5 minutes.