The Planning Fallacy in Shop Projects
Why this matters
Moving the shop, switching software, building a website, upfitting a new truck, hiring an office manager: none of these are jobs you bid, so nobody checks your estimate against an invoice. They run long anyway, nearly every time, and the cost is rarely the extra weeks themselves. It is where the extra weeks land. A software cutover planned for six weeks that actually takes fourteen does not just finish late; it finishes in the first heat wave, with the office learning a new dispatch board while the phone rings off the hook. This card is about seeing that coming before you pick a start date.
This is a different problem from estimating a customer job. That sibling covers the optimism in a tech's or an owner's hours on billable work, where the shop has a feedback loop. Internal projects have none, which is why they are worse. See related: How to Avoid Optimism Bias in Your Own Estimates.
What the planning fallacy is
The planning fallacy is the tendency to predict that your own project will go about as well as your plan for it, even when you know that most similar projects, including your own past ones, ran over. Daniel Kahneman and Amos Tversky named it in 1979. The finding that makes it stick is that knowing the history does not fix it. In a well-known study by Roger Buehler, Dale Griffin and Michael Ross in 1994, students predicting when they would finish a thesis were asked for a best case, a realistic case, and a worst case. On average they finished later than their own worst case.
The mechanism is that a plan is built from the steps you can see. You picture the work going in order, each piece taking about as long as it should. What you cannot picture, because it has not happened yet, are the interruptions, the waiting, and the step nobody listed. Kahneman calls the plan-from-the-steps approach the inside view. The correction is the outside view: ignore the details of this project for a moment and ask how long projects like it have actually taken.
Why shop projects run long in particular
General project research applies, but small shops add four things of their own:
- The project is done in the gaps. An owner or office manager runs it between service calls. Every emergency, every sick tech, every busy Monday preempts it. A plan that says "two days to clean up the customer list" means two days of uninterrupted work, which the owner does not have in any given week.
- Outsiders set the pace. The landlord's contractor, the utility hookup, the software vendor's onboarding calendar, the sign permit. None of them are on your plan's timeline, and each one has a queue.
- The data is worse than you think. Every software switch discovers duplicate customers, equipment with no model numbers, and price books that exist only in someone's head. Cleaning it is real work that appears in no vendor timeline.
- Running two systems is a phase, not a moment. The plan shows a cutover date. Reality has weeks of running the old system for open jobs and the new one for new ones, with the office reconciling between them.
What does not fix it
The instinctive fixes are the ones that fail, and it is worth knowing why so you stop reaching for them.
Padding each step. Adding 20 percent to every line in your plan buffers the risks you already thought of. The overrun mostly comes from the steps that are not on the list at all, so a padded plan of the wrong steps is still short.
Thinking harder about this project. More detail can help a little, mainly by surfacing steps you had skipped, but the deeper you go into this project's specifics, the more it feels unique and the less you weigh the record of similar projects. The detail makes the estimate feel more certain without making it more accurate.
Taking the vendor's timeline. A software vendor's "most customers are live in four weeks" is an inside view from a party that is rewarded for a short one and measures "live" as the day you can log in, not the day the office stops calling for help. Use it as one data point, then ask the vendor what share of shops your size actually hit it.
A hard deadline. A deadline does not shrink the work. It moves the cut to whatever is easiest to skip, which in a software switch is usually training and data cleanup, and both come back as months of slow, error-prone office work.
Worked example: switching field-service software
A six-tech HVAC shop is replacing its scheduling and invoicing system. The owner's plan, built step by step with the vendor:
| Step | Planned |
|---|---|
| Export and clean customer data | 1 week |
| Set up price book and job types | 1 week |
| Vendor onboarding sessions | 2 weeks |
| Train office and techs | 1 week |
| Cutover and run in parallel | 1 week |
| Total | 6 weeks |
He plans to start February 1 and be done by mid-March, comfortably ahead of the spring rush that starts in late April.
Building the outside view from his own record. The shop's office manager has been there eight years, so she and the owner list every internal project of similar size they can remember, with what was planned and what it actually took:
| Past project | Planned | Actual | Ratio |
|---|---|---|---|
| Website rebuild | 8 weeks | 20 weeks | 2.50 |
| Move to the current building | 4 weeks | 7 weeks | 1.75 |
| Switch accounting software | 3 weeks | 7 weeks | 2.33 |
| Two-truck upfit rollout | 2 weeks | 3 weeks | 1.50 |
| Hire an office manager | 4 weeks | 9 weeks | 2.25 |
Sorted, the ratios run 1.50, 1.75, 2.25, 2.33, 2.50. The middle value, the median, is 2.25, and every past project ran over; the best one took half again as long as planned.
Applying it. 6 weeks x 2.25 = 13.5 weeks as the central estimate. The range from the record is 6 x 1.5 = 9 weeks at best, 6 x 2.5 = 15 weeks at worst. The closest match in the list, the accounting switch, ran 2.33, which would be 14 weeks.
Why the median and not the average. The average of the five ratios is 2.07, pulled down by the truck upfit, the one project that was mostly hands-on work the shop controls, with no outside party and no data to clean. The median is less sensitive to one unusual project, and the projects most like this one (accounting software, website) sit at or above it. Either way, the outside view says roughly twice the plan.
What it changes. Start February 1 and the central estimate lands in the first week of May, 13.5 weeks later. That is a week or two into the spring rush, with the office mid-cutover. The plan was fine; the start date was not.
The owner moved the start to the first of the previous October, after the cooling season and before heating peaked, kept the same six-week step plan as the working schedule, and told the office the realistic finish was early January. It finished in the second week of January, about 14 weeks in. Data cleanup took three weeks instead of one, because about a fifth of the customer records had no equipment attached. The vendor's onboarding sessions slipped two weeks over the holidays.
What changes the answer
The outside view is only as good as the reference class, the set of past projects you compare against.
- A thin record. Five projects is a small set, and one odd one moves the average a lot. Add other owners' experience: ask three shops your size who made the same switch how long it actually took them, start to "the office stopped asking the old system." Their ratios belong in the list. See related: Forecasting a New Service Line From a Reference Class, for building a reference class when you have little of your own, and Base Rates: The Number You Should Start From.
- A project unlike the others. If this one has no outside party and no data migration, like the truck upfit, the low end of the range is the honest estimate. If it has more outside dependencies than anything in the list (a building purchase, a lender, a zoning change), expect it to run past the top of the range, and say so rather than using a ratio that does not fit.
- A fixed outside date. A lease that ends, or a vendor sunsetting your old software, means the end date is not yours to choose. Then the outside view tells you when you must start, working backwards: an immovable date in early June with a 2.25 ratio on a six-week plan means starting in late February, not the first of May.
How to check you used it
Three habits make the correction stick past one project:
- Write down the inside-view estimate before you build the outside view. If you skip this, the outside number quietly becomes the new plan and you lose the record of how far off you were.
- Record the actual, the day the project is really done. Not the day of cutover; the day the old system or old building stopped generating work. Add the ratio to the list.
- Put the start date, not just the end date, against the season. The outside view's main job in a seasonal trade is to tell you which month to start. If your decision did not change the start date or the scope, check whether you actually used the number or just noted it.
The list of past projects with their ratios is the most useful planning document a small shop owns, and almost none have one. Keeping it in the same place you log big decisions makes it easy to find next time. See related: Keeping a Decision Journal.
References
- Kahneman, D. and Tversky, A., "Intuitive Prediction: Biases and Corrective Procedures," 1979 (origin of the planning fallacy)
- Buehler, R., Griffin, D. and Ross, M., "Exploring the 'Planning Fallacy': Why People Underestimate Their Task Completion Times," Journal of Personality and Social Psychology, 1994
- Flyvbjerg, B., work on reference class forecasting for major projects (the formal version of the outside view)
- See related: How to Avoid Optimism Bias in Your Own Estimates; Forecasting a New Service Line From a Reference Class; Base Rates: The Number You Should Start From