The Project Fallacy

A Cousin to the Planning Fallacy

It is no secret that we are all bad at estimating. We are too optimistic about our timelines and our own capabilities. Every home project I’ve ever done has fallen victim to the planning fallacy.

You’ve likely seen this play out in your own life, both personally and professionally. Dates change, timelines extend, projects take longer.

This is all part of the planning fallacy: We consistently underestimate the time it will take to complete something.

I’ve been noticing an adjacent phenomenon, particularly in my professional work with companies that have a particular focus on project and program management. I’m tentatively calling this the “project fallacy.”

Project Fallacy

The project fallacy is the idea that we can effectively and sufficiently plan an unknown project such that we will not need to make any adjustments once we’ve begun.

For many of you, this may seem absurd on its face. There is no way to plan sufficiently such that you account for every contingency. And you’d be right. There isn’t any way to plan for every possibility. Almost everyone would agree on this.

Most planners (whether project managers, executives, or others) would say that we don’t need to plan for every contingency or possibility, but we just need to plan well enough to have a good understanding and then be able to handle issues as they come up.

But our attitudes toward changes are often very different, both as companies and as individuals.

The problem is this gray area in the middle. What is well enough? What is an acceptable level of planning? What is an acceptable number of issues or changes?

Product Development

Let me step back for a moment here.

I work primarily in software development, as many of the readers of this newsletter are likely aware (and are probably familiar with). Many of you may be in a similar field, especially given the topics we cover here.

The general software development process involves:

• product discovery (understanding problems)

• product exploration (testing solutions)

• product development (planning and developing the product)

• product delivery (going to market)

We have many variations of this process, but they all revolve around the same idea of creating and launching software products.

The planning phase typically comes when we are ready to develop a product (we’re done testing ideas and ready to develop something). I’m sure many people will be happy to jump into the comments here about the ideal process of tiny steps and testing each hypothesis. I agree with all of that, but at most companies you’ll be lucky if you get to do proper discovery and exploration. This is especially true at companies with a strong project management focus (which is most companies). You’ll be expected to get to the planning phase as quickly as possible.

Project Planning

Regarding project planning, as I’ve worked through many products, projects, and feature releases, I’ve seen this handled in a variety of ways. Some companies have a high tolerance for changes. They are flexible enough to handle adjustments, big or small, to work being done by their teams. Other companies have very little tolerance for changes. Any change to timelines seems to cause massive amounts of trauma to individuals, entities, and divisions.

Your organization may be on either of this continuum, or somewhere in the middle.

Regardless of the general attitude, there seem to always be stakeholders who have a mentality that better planning before could have prevented changes after work began.

I’ve encountered this attitude at every company. It comes in the form of questions like:

• “Was this not part of the initial requirements?”

• “Did we not flag that as a dependency?”

• “We originally had XX as our date, but now it is changing. Why?”

• “Why do we see additional scope creep?”