Every quality initiative begins with a plan. A Gantt chart. A budget.
A team. A kickoff meeting where someone projects a slide that says “12
weeks to full deployment” and everyone nods because the timeline looks
reasonable — the boxes fit neatly on the screen, the dependencies are
mapped, and the milestones feel achievable. The project sponsor signs
off. The steering committee approves. The calendar invitations go
out.
And then reality arrives.
Twelve weeks becomes sixteen. Sixteen becomes twenty-four. The budget
that was supposed to cover everything barely covers the first phase. The
team that was supposed to be fully dedicated is actually shared across
three other priorities. The software that was supposed to integrate
seamlessly doesn’t. The data that was supposed to be clean isn’t. The
operators who were supposed to embrace the new system resist it. And
slowly, predictably, inevitably, the project that was sold as a
transformation becomes a case study in frustration.
This is the Planning Fallacy at work in your quality organization,
and it is destroying your credibility, your budgets, and your ability to
improve.
What the Planning Fallacy
Actually Is
The Planning Fallacy is a cognitive bias first described by
psychologists Daniel Kahneman and Amos Tversky in 1979. In its simplest
form, it describes the tendency to underestimate the time, costs, and
risks of future actions while overestimating their benefits. It is not
optimism — optimism is a general disposition. The Planning Fallacy is
specific: it occurs when you have access to historical data showing that
similar projects have failed or overrun, and you ignore that data
entirely when planning the next one.
Kahneman later refined the concept by distinguishing between two
modes of thinking about the future. The “inside view” is the planner’s
natural perspective — you break the project into steps, estimate each
step, and add them up. The “outside view” is the statistical perspective
— you look at how long similar projects have actually taken, regardless
of their specific details. The Planning Fallacy is what happens when you
rely exclusively on the inside view and never consult the outside
view.
In manufacturing quality, this bias is everywhere. Every corrective
action plan underestimates the time to verify effectiveness. Every CAPA
underestimates the complexity of root cause investigation. Every
software implementation underestimates the integration work. Every
training program underestimates the time to achieve actual competence.
And every quality manager who has watched this happen proceeds to plan
the next initiative using the exact same method that failed the last
time.
The Anatomy of a
Quality Project Overrun
Consider a typical scenario: a mid-sized automotive parts
manufacturer decides to implement Statistical Process Control (SPC)
across its machining lines. The quality team plans the rollout in three
phases over six months. Phase one covers two pilot lines. Phase two
expands to ten lines. Phase three covers the remaining fifteen lines
plus integration with the ERP system.
Here is what the plan says:
- Month 1-2: Select software, install sensors,
configure dashboards, train pilot line operators. - Month 3-4: Analyze pilot results, refine control
limits, expand to ten lines, train additional operators. - Month 5-6: Full deployment, ERP integration,
management reporting, project closure.
Here is what actually happens:
Month 1: The software selection takes three weeks
longer than planned because the IT department has security concerns that
nobody anticipated. The sensor installation requires electrical work
that wasn’t in the budget. The pilot line operators attend training but
don’t understand why they need to react to control chart signals when
they’ve been running the same parts for years without any charts.
Month 2: The dashboards are configured, but the data
isn’t clean. Gage R&R studies reveal that two of the four
measurement systems on the pilot lines have unacceptable repeatability.
The data you were going to use to set control limits is unreliable. You
need to fix the measurement systems first. This was not in the plan.
Month 3: You’re still fixing measurement systems.
The operators on the pilot lines are recording data but not reacting to
out-of-control signals because “the supervisor said to keep running.”
The quality engineer assigned to the project gets pulled into a customer
audit for two weeks. The pilot data that you finally collect shows that
the process capability is worse than anyone expected, which means the
control limits need constant revision.
Month 4: You present pilot results to management.
They are underwhelmed. The scrap rate hasn’t improved because the pilot
lines weren’t the biggest contributors to scrap. The steering committee
asks why the project is behind schedule. You explain the measurement
system issues. They ask why you didn’t anticipate that. You don’t have a
good answer.
Month 5-6: The expansion to additional lines
proceeds, but each line has its own unique challenges — different
machines, different operators, different measurement methods. The ERP
integration requires a custom API that the vendor wants to charge extra
for. Training across all lines takes three months instead of one because
you can only pull operators off the line in small groups.
Month 9: The project is “complete,” except that the
management reporting module still doesn’t work properly, three lines are
using the system differently from the rest, and nobody has conducted a
formal effectiveness check. The quality manager declares victory and
moves on to the next initiative. Six months later, half the lines have
stopped entering data entirely.
This is not a hypothetical. This is the median outcome for quality
technology implementations in manufacturing. And the root cause is not
incompetence — it is the systematic failure to account for what Kahneman
calls the “distributional information” about how projects like this
actually unfold.
Why the Inside View Fails
in Quality
The inside view fails in quality projects for specific structural
reasons that most planners don’t account for:
First, quality work is embedded in production systems that
were not designed to accommodate it. You cannot shut down a
production line to implement a new quality system. Every change must be
made while the line is running, which means scheduling around
production, working in batches, and accepting interruptions. Planners
who have never had to install sensors on a running die-casting machine
consistently underestimate how disruptive this is.
Second, quality data depends on measurement systems that are
never as reliable as you assume. Every quality project that
involves data collection should budget time for Measurement System
Analysis (MSA) before the actual project work begins. Almost none do.
The result is that projects discover bad data after they’ve already
built dashboards, set control limits, and trained people on systems that
are measuring noise.
Third, quality improvements require behavioral change, and
behavioral change takes longer than any training schedule accounts
for. You can train operators to use a new system in a day. You
cannot change their habits, their incentives, their supervisors’
priorities, or the production culture that tells them to keep running
regardless of what the quality data says. The training plan says “two
days per shift.” The reality is “six months of coaching, reinforcement,
and correction.”
Fourth, quality projects interact with other systems in ways
that are invisible until they break. The SPC system needs data
from the ERP. The ERP needs data from the MES. The MES needs data from
the sensors. The sensors need calibration. The calibration schedule
conflicts with production. The production schedule changes because of a
customer order. And suddenly your “simple integration” is a multi-system
orchestration problem.
Fifth, quality projects compete for resources with production
emergencies that always take priority. The quality engineer
assigned to your project will be pulled into a customer complaint. The
maintenance technician who was going to install sensors will be diverted
to a machine breakdown. The IT resource who was going to configure the
server will be fighting a cybersecurity issue. Every one of these
diversions is predictable in aggregate — they happen in every project —
but unpredictable in specific timing, so planners treat them as
exceptions rather than the rule.
The Statistical Reality
Research on project planning consistently shows that the median
project overrun is 40-60% in time and 20-40% in budget. Large
infrastructure projects — the best-studied category — show overruns of
60-100% on average, with some categories (rail, IT, nuclear) routinely
exceeding 100%.
Quality projects in manufacturing are not as well studied, but
anecdotal evidence from quality consultants and practitioners suggests
similar patterns. A CAPA that was supposed to take 30 days takes 90. A
supplier audit program that was supposed to be implemented in a quarter
takes a year. An ISO 9001 transition that was supposed to be
straightforward reveals systemic gaps that require fundamental process
redesign.
The pattern is so consistent that it constitutes a distribution. If
you have implemented five quality initiatives and they all overran by
30-70%, the base rate for your next initiative is a 30-70% overrun. Yet
the next plan will predictably show a timeline that assumes everything
goes right the first time.
The Reference Class
Forecasting Solution
Kahneman’s recommended antidote to the Planning Fallacy is Reference
Class Forecasting — deliberately seeking the outside view before
constructing the inside view. In practice, this means:
Step 1: Identify the reference class. Before
planning your specific SPC implementation, look at other SPC
implementations in similar-sized manufacturers in your industry. How
long did they take? What was the budget overrun? What were the common
failure modes?
Step 2: Collect the distribution. Don’t look for the
best case — look for the median. If ten similar companies implemented
SPC and the median time was nine months with a range of six to eighteen,
your baseline expectation should be nine months, not the six months that
your inside view is telling you.
Step 3: Adjust for specifics. If your company has
particular advantages (strong leadership commitment, clean data,
experienced team), you might shade the estimate downward. If you have
particular disadvantages (high turnover, legacy equipment, minimal IT
support), shade it upward. But start from the distribution, not from
zero.
Step 4: Build the plan from the adjusted baseline.
The inside view still matters — you need to understand the specific
tasks, dependencies, and milestones. But it should be built on top of a
realistic time horizon, not an aspirational one.
In quality organizations, this approach is rare. Most quality plans
are built entirely from the inside view, with timelines that are driven
more by management expectations and budget cycles than by historical
evidence. The quality manager who says “based on similar
implementations, this will take nine months” is seen as pessimistic or
obstructive, while the one who says “we can do it in six” is seen as
ambitious and capable — right up until month eight, when the project is
still in phase two and everyone is asking what went wrong.
The Social Dynamics
of the Planning Fallacy
The Planning Fallacy is not just a cognitive bias — it is a social
phenomenon reinforced by organizational incentives.
The optimism premium. In most organizations, the
person who proposes a shorter timeline gets the project. The person who
proposes a realistic timeline is seen as lacking confidence or
capability. This creates a systematic bias toward underestimation,
because the selection process rewards optimism over accuracy.
The anchoring effect. Once a timeline is proposed
and approved, it becomes an anchor that shapes all subsequent planning.
Even when reality diverges from the plan, the original timeline remains
the “baseline” against which progress is measured. Every status report
shows variance against a plan that was never realistic, which creates a
narrative of failure that demoralizes the team and erodes management
trust.
The sunk cost escalation. When a quality project
falls behind schedule, the organization has already invested time,
money, and political capital. Rather than reassess and adjust the
timeline, the tendency is to push harder, add resources, and hope that
intensity will compensate for poor planning. This rarely works in
quality work, where the bottlenecks are usually systemic (measurement
reliability, behavioral change, system integration) rather than
effort-based.
The blame cycle. When the project finally delivers —
late, over budget, and with compromised scope — the post-mortem focuses
on what went wrong rather than why the plan was unrealistic. The quality
team is blamed for poor execution. The next project is planned using the
same methods that produced the failure. The cycle repeats.
Practical Countermeasures
Beyond Reference Class Forecasting, there are specific practices that
quality organizations can adopt to mitigate the Planning Fallacy:
Build MSA time into every data-dependent project. If
your project involves collecting or using quality data, budget two to
four weeks upfront for measurement system analysis. This is not optional
— it is the foundation that everything else rests on. Every hour spent
on MSA before the project saves ten hours of troubleshooting during
it.
Use three-point estimates instead of single-point.
For every task, estimate best case, most likely, and worst case. Use the
most likely as your planning figure, not the best case. This simple
shift — from “how long should this take?” to “how long will this
probably take?” — can dramatically improve forecast accuracy.
Plan for resource contention explicitly. Assume that
20-30% of allocated resources will be unavailable due to competing
priorities. This is not pessimism — it is the base rate for shared
resources in manufacturing environments. If you need one full-time
quality engineer, plan for 1.3.
Separate technical deployment from behavioral
adoption. Installing software takes weeks. Changing how people
work takes months. Plan these as separate phases with separate success
criteria. Do not declare victory when the software is installed —
declare victory when people are using it correctly without
supervision.
Conduct pre-mortems. Before the project begins,
gather the team and ask: “Imagine it is six months from now and this
project has failed. What went wrong?” The answers will reveal the risks
that your optimistic plan is ignoring. Build mitigation for those risks
into the plan from the start.
Track prediction accuracy. Keep a record of your
planned versus actual timelines and budgets for every quality
initiative. After five or six projects, you will have your own reference
class data — and it will almost certainly show that you are
systematically underestimating. Use this data to calibrate future
estimates.
The Deeper Implication
The Planning Fallacy in quality work is not just about missed
deadlines and blown budgets. It is about trust. Every quality project
that overruns erodes the organization’s confidence in the quality
function. Every timeline that proves unrealistic makes the next timeline
harder to sell. Every budget that explodes makes the next budget request
more likely to be cut.
Over time, this creates a vicious cycle: quality plans are
unrealistic, delivery falls short, trust erodes, resources are reduced,
plans become even more unrealistic because they’re built on insufficient
resources, delivery falls further short, and trust erodes further.
Breaking this cycle requires something that most quality
organizations lack: the courage to plan honestly. To say “this will take
nine months, not six” and accept that the short-term disappointment of a
longer timeline is far less damaging than the long-term credibility loss
of another failed commitment.
The factories that get quality right are not the ones with the most
ambitious plans. They are the ones with the most honest plans — plans
built on evidence, not aspiration; on distributions, not best cases; on
the outside view, not the comforting fiction that this time, everything
will go according to schedule.
It won’t. It never does. And the sooner you plan for that reality,
the sooner you’ll start delivering results that actually match your
promises.
Peter Stasko is a Quality Architect with over 25
years of experience in manufacturing quality management, process
optimization, and continuous improvement across automotive, aerospace,
and industrial manufacturing sectors. He specializes in helping
organizations bridge the gap between quality theory and production floor
reality.
