You’ve triple-checked the work breakdown spreadsheet you spent the last three days creating for a new IT project. Every task is included, estimated down to the hour required for development, and every sprint should finish with all assignments completed. You’re confident the project will continue without a hitch, and there shouldn’t be any unforeseen issues. But ultimately, despite all the planning, you can’t finish the project within your set timeline.  

Welcome to the planning fallacy. 

What is the planning fallacy? 

The planning fallacy is the human tendency to underestimate the time needed to complete a project, even if similar projects took longer in the past. 

We, as people, are typically overly optimistic about our ability to finish work within a given timeframe. This normally occurs when judging our own tasks, though, not the tasks of others. The planning fallacy goes away when we review a project’s schedule without having any personal stake in its outcome. When self-assessment is removed, we’re more realistic about the resources needed. If we are considering our own ability to complete a task, that rational thinking gets skewed.   

What causes the planning fallacy? 

The planning fallacy is caused by the combination of tangible and intangible factors. The drivers behind this phenomenon appear consistently across industries, but to better illustrate the causes and effects, let’s use the IT industry as an example.  

Cognitive biases

Cognitive biases are a significant driver of underestimating the amount of work, time, and people needed to complete an IT project. To put it simply, people are too optimistic. Workers tend to set aspirational goals rather than achievable ones. 

The tricky part about cognitive bias is that it is difficult to recognize its presence within ourselves. It leaves the self-reporter genuinely thinking they can complete a project within their self-given timeframe. When the researchers who coined the phrase “planning fallacy” questioned subjects about the time it would take to complete a specific project, most respondents didn’t estimate enough time—only 30% of the subjects completed the project within their predicted schedule.

Underestimation of risks and unknowns

Related to optimism bias is an underestimation of risks and unknowns. It can be tricky to accurately account for variance and unforeseen obstacles, particularly within IT projects. For example, a developer might need to work with a new API integration. API integrations usually take this person 10 hours, so they assume this one will be the same. However, the integration becomes more complicated than initially expected, and 30 hours are needed. Underestimating the resources necessary to handle unplanned bumps in the road plays right into the planning fallacy. 

Organizational pressures

Additionally, organizational pressures can push workers into this planning pitfall. We want to seem like capable, reliable employees, particularly in competitive and high-pressure environments. Managers sometimes reward people with a “can-do” spirit, which can discourage teammates from voicing dissenting opinions. If counterarguments are not welcome, people on an IT team won’t feel like they can safely say a project might require more time or effort than planned. 

Project complexity

A final contributing factor is the complexity of projects. IT projects, in particular,  have many nuanced or specific requirements, which can be overwhelming for a team to include during discovery. Not accurately scoping for each client’s complicated, unique conditions will cause the best-laid plans to go awry. 

How can planning fallacy impact IT project scoping? 

Sprint planning, scheduling, and allocating resources for an IT project are determined by the specs from discovery sessions and scoping. The requirements documented at that stage impact all subsequent work through production and development. Getting trapped in the planning fallacy during project scoping can cause significant effects throughout the project lifecycle. These include: 

1. Delays and missed deadlines

A significant impact of the planning fallacy during project scoping is inaccurate scheduling. IT professionals budget too much work in too little time to accomplish it. As the sprints get underway and more tasks stay “in progress,” work bottlenecks. Scheduled tasks are delayed, and the whole project timeline gets pushed back. Beyond the apparent inconvenience with resource allocation, clients are forced to reschedule any PR, release dates, and marketing relying on the project launch. 

2. Budget overruns 

In managed IT work, clients agree to the cost of a project based on how long the project takes to complete. If the IT sales team underestimates the time needed (and therefore, the total price), either the client will need to agree to pay more money to finish the project—which they might not do—or the MSP will decide to eat the cost of the overage as it was their responsibility for inaccurately scoping the project. It’s a tense situation, and it rarely resolves without conflict. 

3. Client relationships worsen 

When clients are consistently told deadlines are missed and the project is over budget, they tend to get upset. Failing to meet agreed-upon expectations erodes trust between an IT professional and the client while creating a tense working atmosphere. 

4. Team morale lowers

No one likes a Sisyphean task—feeling like no matter what they do, they cannot complete their assigned tasks. If IT professionals are always expected to meet unrealistic deadlines, eventually, they’ll become disgruntled. Managers cannot motivate a team when everyone feels dismayed and unequipped for success. After repeated instances, team morale will lower, and the MSP company will have a bigger problem scaling with an overworked team. If scaling is impacted, the company will also struggle with its overall financial security

Examples of the planning fallacy in IT

To better illustrate how the planning fallacy can impact professional IT work and scoping, consider the following examples: 

Network security improvement

Example: An IT team estimates they can complete a network security upgrade for a medium-sized business in two weeks. During discovery, the IT team asks the business what outcome they’re looking for but doesn’t ask too many questions about existing protection and cybersecurity measures. 

The IT team creates an estimate of the best-case scenario as they are under pressure from upper management to complete more projects this quarter. The team assumes the existing hardware will be compatible with all new security software upgrades and there won’t be any unforeseen security issues. 

Outcome: During the upgrade, the team finds existing vulnerabilities to fix before the security upgrade can proceed, and they must replace some of the hardware to support the latest security protocols. This sets the team back by two weeks, adding an extra sprint to the project timeline and significantly increasing the project’s cost. 

Software development and implementation

Example: An MSP takes on a client request to implement a new Salesforce CRM system. The team knows that if they put an IT professional full-time on this work, they can complete it in four weeks. However, that same IT professional is working part-time on two other projects. 

Outcome: A bug arises in one of the part-time projects, forcing the IT engineer to spend two days solving the issue. Additionally, an update on the other part-time project takes slightly longer than planned. This results in setting the engineer a week behind schedule with the CRM implementation, even though that schedule was too tight from the outset. 

Infrastructure upgrade for remote work

Example: A small social media business allows its employees to work fully remote, so they contact an MSP to upgrade the company’s infrastructure to support the change. The MSP estimates it can have all systems ready for remote work within one more. 

Outcome: The MSP company completes the technical upgrade on time but underestimates the time it takes to train the social media company’s employees on the new tools and systems. The slow training prolongs the company’s period of reduced productivity, delaying the project’s true completion. 

Disaster recovery planning 

Example: An IT team conducts a discovery session with a new client, asking for a better comprehensive disaster recovery plan. After noting how robust a strategy the client wants, the team asks if the client has existing documentation on the IT infrastructure, to which the client answers “yes.” The IT team estimates two months for the work, assuming they will spend the first week learning the existing systems and documentation. 

Outcome: During the first week of discovery, it becomes apparent the systems were not as well documented as the IT team expected. The engineers discover undocumented legacy systems, outdated documentation, and a diverse tech environment. The team’s initial plan is undone as they scramble to reformulate a plan that better accounts for these unknowns. 

5 tips to avoid the planning fallacy

Though overcoming a cognitive bias can be tricky on its own, with proper procedures in place, you can implement guardrails to minimize the adverse effects of the planning fallacy. 

1. Track and review historical data effectively 

Record all data from past projects so they can be reviewed and leveraged in the future. Save the project estimate and track the actual development schedule. After a few repetitions, compare the initial and actual timelines and note the differences. Use the project completion time to inform future quotes for similar projects. 

2. Encourage a culture of honesty and constructive realism

Craft a working culture where employees can speak up and share any concerns about project timelines, even if they’re the sole voice advocating for a more extended deadline. Healthy argument and debate can lead to more diverse opinions when forming an estimate, improving the plan’s accuracy. Strive for positivity, but not to the point where it dampens realistic timeframes and makes employees afraid of seeming ‘too negative’ for mentioning potential obstacles. 

3. Ask an outsider to review the plan 

After creating an estimate, ask an engineer or sales team member who won’t work on the project to review the timeline. Though people are overly optimistic about completing their work, the unbiased opinion of an objective third party will often be more realistic and help create a more well-rounded schedule. 

4. Account for unknowns 

Budgeting for unforeseen obstacles can mitigate the variance of each new IT project. Adding planning buffers could include adding +20% of an estimate to the timeline to cover potential complexities, agreeing to a flexible payment range, or any number of possible solutions. The key is to budget for unknown bumps in the road proactively. 

5. Get detailed

A well-thought-out project increases the chances that you’ll note all the details. Considering each step deeply tends to curb underestimating work. It requires more time during scoping but can lead to more accurate quotes in the long run. One tactical solution is creating an implementation schedule and an estimate detailing when, where, by whom, and how the work will be completed. 

Using CPQs to avoid the planning fallacy

IT professionals have a secret weapon to help them avoid the planning fallacy of scoping new projects. A CPQ (configure, price, quote) software programmatically employs the above methods. 

CPQs remove human optimism from the equation while storing detailed analytics and data that can be reviewed in the future to hone the estimation and project planning stages expertly. Additionally, many CPQs offer detailed knowledge on how to price services. Whereas people need to skim through pricing spreadsheets to find all requirements and updated prices, a CPQ can populate that information with little input required. The detailed estimates created by the software allow the delivery team to plan better and allocate resources based on a practical and accurate timeline. 

If you want to lessen the impact of planning fallacies in your project scoping, contact us to see how ScopeStack’s CPQ software can benefit you.

You may also like: