Read time: 7 minutes

Hey Subscriber First Name,

I once sat in a planning meeting where a senior sponsor opened with this: "We think this should be done in eighteen months." He said it casually, like he was reading the weather. But it wasn't based on analysis. It wasn't based on what similar programmes had taken. It was based on what he needed to tell the board.

The room full of engineers and planners then spent two hours building a schedule that, by pure coincidence, came out at around eighteen months. Every estimate bent slightly towards the number that was already in the room. Nobody lied. Nobody even noticed they were doing it. But by the end of the session, we had a plan that everyone quietly knew was fiction, built on an opening number that had nothing to do with reality.

The real answer, as it turned out, was closer to twenty-eight months.

I've seen this play out more times than I can count. A number lands early in the conversation, and everything that follows is pulled towards it like gravity. Kahneman called this anchoring. The first number you hear becomes the reference point, and even when you try to adjust away from it, you don't adjust far enough. It happens in every estimation workshop, every business case review, every conversation where someone says "we were hoping for" before the team has done any actual analysis.

But anchoring is only part of the problem. The bigger issue is something Kahneman spent years studying, and it explains why almost every project plan is too optimistic. He called it the planning fallacy.

Here's how it works. When you sit down to plan a project, your brain naturally focuses on the specifics. This project, this team, this scope, this timeline. You think about what needs to happen, how long each piece should take, what could go wrong. You build a detailed picture from the inside. And because you're focused on the detail, it feels thorough. It feels like you've thought it through.

The problem is that this inside view almost always produces an optimistic answer. Not because you're bad at planning, but because your brain is wired to focus on what's in front of it and ignore what's missing. Kahneman calls this "What You See Is All There Is." You build a confident story from the information available, and you never stop to ask what you might be leaving out. The unknown risks. The delays nobody can predict. The dependencies that only surface once work begins. Your plan accounts for what you can see, and the things that blow projects up are almost always the things you couldn't.

Kahneman tells a story about this from his own life. He was part of a team writing a new school curriculum. After a year of work, he asked everyone to estimate how long the full project would take. The group consensus was about two years. Then he asked one team member, who had seen similar curriculum projects before, how long those had actually taken. The answer was seven to ten years. And forty percent of them never finished at all. The team's detailed, inside-view estimate was off by a factor of five.

They carried on with the two-year plan anyway. And this is the part that really matters. Even after seeing the data, the group chose to ignore it. Not because they were stupid. Because the inside view feels personal and specific, and the outside view feels like someone else's problem. Your brain treats your own project as unique, even when the evidence says it isn't. Psychologists call this the optimism bias, and it's one of the most consistent findings in decision-making research. We genuinely believe we're the exception, every single time.

That story has stuck with me because I've been in that room. You probably have too. The moment where the data says one thing and the room agrees on something else, because the inside view feels more real than the base rate. But statistically, your project is almost certainly not different enough to overcome the pattern.

The fix is what Kahneman calls the outside view. Instead of asking "how long should this take based on our plan", you ask "how long did similar projects actually take?" Not your plan. Not your hopes. The actual outcomes of comparable work. That's your baseline. Everything else is adjustment from there. It often produces a number nobody wants to hear. But it's the number that's most likely to be right.

I've started doing this on every programme I run. Before we build the detailed schedule, I ask the team one question: what's the closest thing we've done to this before, and what actually happened? Not what the plan said. What actually happened. The gap between the two is usually where the truth lives.

It doesn't mean you throw your detailed plan away. It means you hold it next to the historical reality and take both seriously. When your inside view says twelve months and your outside view says eighteen, the answer is almost never twelve.

The best PMs I know aren't the ones with the most detailed Gantt charts. They're the ones who are honest about what they don't know, and who use what actually happened in the past to stress-test what they're promising for the future. That's how you build judgement over time. And judgement is how things actually get delivered.

MAKING IT HAPPEN: Your Weekly Strategy

Think about a project you're currently planning or estimating. Before you refine the schedule any further, ask yourself one question: what is the closest comparable project I've seen, and how long did it actually take from start to finish? Not the plan. The reality. Write that number down next to your current estimate. If there's a gap, don't ignore it. Take that gap to your next planning session and ask the team: what would need to be true for us to beat the historical pattern? If the room can't answer that clearly, you've just found the risk nobody was talking about. Name it, size it, and build it into your baseline.

THE AI CAN SEE THE PATTERN. BUT CAN IT READ THE ROOM?

Here's what's interesting. The technology to do this at scale already exists. AI-powered forecasting tools can now run Monte Carlo simulations across thousands of possible scenarios, pull historical data from similar projects, and give you a probability curve for your delivery date. Some platforms claim near-95% accuracy on task duration predictions when trained on enough historical data. Digital twins can simulate a project's outcomes before a single day of work begins.

This is genuinely useful. But it also creates a new trap.

I'm already seeing it in planning rooms. Someone pulls up the AI forecast, it says eighteen months with 70% confidence, and the room treats that as the answer. The conversation stops. Nobody asks what assumptions the model was trained on. Nobody asks whether the historical projects it's comparing to were genuinely similar, or just superficially tagged the same way. Nobody asks what the model can't see: the politics, the team dynamics, the client who changes their mind every quarter, the supplier who's about to lose half their workforce.

The tool is doing what Kahneman said we should do. It's looking at the outside view. It's pulling base rates from historical data. That's good. But it's doing it without judgement. It doesn't know which variables actually mattered on those past projects and which were noise. It doesn't know that your site team has three people leaving next month. It doesn't know that the approval process changed last year and now takes twice as long.

The skill isn't reading the output. The skill is knowing what the output can't tell you. Knowing its limitations. Knowing when to trust it and when to override it. Knowing when "the AI says eighteen months" actually means eighteen months, and when it means "eighteen months if everything goes the way it usually does, which on your project, it won't."

AI gives you the base rate. Judgement tells you how far your project deviates from it. You need both. And the PM who treats the AI output as the final answer is making the same mistake as the PM who ignores historical data entirely, just from the other direction.

A QUICK WORD

I want to give a shout out to Paul Simms, a project professional with over 37 years in project delivery. Paul has been a mentor to me behind the scenes since I started writing. He was one of the first people to believe in what I was doing, encourage me to keep going, and review my work to make sure I wasn't going off the rails. We share the same passion: helping others learn, grow, and build judgement.

I think we all need a Paul. Someone who's been in the rooms you haven't been in yet, seen the patterns you're encountering for the first time, and is willing to share what they've learned. This newsletter talks about looking at how similar projects actually played out in the past. The same applies to people. Someone who's seen dozens of similar projects across decades carries an outside view that no tool or framework can replace. Find that person. Learn from them. And when you've built enough of your own experience, be that person for someone else.

Thank you, Paul. For the time, the honesty, the encouragement, and for believing in this before it was anything. This newsletter and the community around it are better because of your contribution, and I wanted you to know that publicly.

CHEAT SHEETS

The free cheat sheet library is here. I'll keep adding to it. Save the link and grab whatever helps.

If this one landed, forward it to someone who's sitting in a planning meeting right now with a number they don't believe in. The best time to tell the truth about a timeline is before you commit to it.

bilaljamil.com | Newsletter archive | Hit reply and tell me about the biggest gap you've seen between a plan and reality. I read every one.

Take care and speak soon, 

Bilal