Psychologists Daniel Kahneman and Amos Tversky coined the term "planning fallacy" in 1979 to describe a specific, consistent human tendency: we underestimate the time, cost, and risk of a task, while overestimating its benefits, and we do this even when we have direct personal experience of being wrong about the exact same kind of task before. Kahneman later won the Nobel Prize in economics in part for this body of work.

The classic study illustrating it is almost funny. Psychology students were asked to estimate how long their senior thesis would take. The average guess was under 34 days. Only around 30% of them actually finished within their own predicted timeframe, despite having written papers before and knowing, going in, that they tend to run long. Knowing the pattern didn't stop them from repeating it.

The mechanism researchers point to is what's called the "inside view." When people plan, they focus on the specifics of the project in front of them, the exact steps, the specific team, the particular timeline, rather than on how similar projects have actually gone in the past. That inside view feels more rigorous, because it's detailed and specific to your situation. It's also exactly what produces the underestimate, because it quietly excludes all the ways things went wrong on comparable projects that weren't yours.

The documented fix is called the "outside view," deliberately setting the specifics of your project aside and asking instead: how did this category of project actually go, across everyone who's attempted it. That's a harder habit than it sounds, because the inside view always feels more relevant to your case. It rarely is.

This is what a genuine reference class looks like in practice, rather than an abstract idea. Based on GTconsult's own migration work, rough timelines by environment size: under 50 users and 500GB of data sits at around a couple of weeks. 50 to 300 users, 500GB to 5TB, runs 1 to 3 months. 300 or more users, 5TB or more, runs 3 to 6 months minimum, and that's before accounting for custom functionality, classic web parts, or on-premises workflows that need rebuilding into Power Automate.

None of those numbers come from guessing at your specific project. They come from having run enough migrations to know what actually tends to happen, which is exactly the outside view this whole piece is about.

The planning fallacy doesn't go away because you've heard of it, the psychology students knew they tended to run long and still underestimated. What actually helps is building the outside view into the plan deliberately, asking someone who's run this category of project many times what actually tends to happen, rather than reasoning from your own specific case alone. That's most of what a good delivery partner is actually for: not extra hands, a reference class of every time this has gone wrong before, applied to your project before it does.

The same pattern shows up well beyond SharePoint migrations. It's just as true of a Power Apps build, a Microsoft Fabric implementation, or an agentic AI rollout, teams plan from the specific project in front of them rather than from how similar projects in that category have actually gone. Our Copilot Readiness Checklist is built entirely from that outside view for Copilot and Microsoft 365 adoption specifically, and it's the same discipline we bring to Power Apps, Fabric, and agentic AI builds too.

Planning a migration and want the outside view before you start? Get in touch and we'll tell you what actually tends to happen.