Quality
and the Planning Fallacy: When Your Organization Consistently
Underestimates How Long Quality Improvements Will Take — and the
Timeline Everyone Agreed On Became the Corner Your Team Cut to Meet
It
There is a particular kind of meeting that happens in every
manufacturing organization. You know the one. The plant manager stands
at the front of the room, clicks to a slide labeled “Quality Improvement
Roadmap,” and lays out an ambitious plan. FMEA rollout: six weeks. SPC
implementation: three months. Full IATF 16949 certification: eight
months. The room nods. The timeline is aggressive but achievable.
Everyone has seen similar plans before. The consultant who prepared it
has impressive slides. The board has already approved the budget.
Eighteen months later, the FMEA is half complete, SPC is running on
two out of fourteen lines, and the certification audit has been
rescheduled twice. The plant manager is now a different person. The
consultant has moved on to another client. And the quality team is
working weekends trying to close a gap that was never supposed to
exist.
This is not a story about incompetence. This is a story about one of
the most well-documented, most predictable, and most ignored cognitive
biases in organizational life. It is called the planning fallacy, and if
you work in quality, it is almost certainly costing you more than any
defect ever will.
What the Planning Fallacy
Actually Is
The planning fallacy was first identified by psychologists Daniel
Kahneman and Amos Tversky in 1979. In its simplest form, it describes
the tendency to underestimate the time, cost, and risks of future
actions while overestimating their benefits. This is not optimism,
although it feels like optimism. This is a systematic cognitive error
that operates below conscious awareness and persists even when people
have direct experience with similar tasks failing to meet their own
estimates.
Kahneman, who won the Nobel Prize for this line of work, described it
with characteristic precision. When people plan, they adopt what he
called the “inside view.” They focus on the specific details of their
plan, the uniqueness of their situation, and their own competence. They
do not look at the base rate — the statistical record of how long
similar projects actually take in the real world. They construct a
best-case scenario and then treat it as a realistic one.
The result is not slightly optimistic estimates. The result is
estimates that are systematically, consistently, and dramatically wrong.
Studies across industries show that large capital projects take, on
average, 30 to 50 percent longer than their initial estimates. Software
projects are even worse. And quality improvement projects in
manufacturing — a domain I have watched closely for over two decades —
are among the most predictable victims of this bias.
Why Quality
Projects Are Especially Vulnerable
Quality improvement projects are uniquely susceptible to the planning
fallacy for several reinforcing reasons.
First, quality work is inherently cross-functional. An FMEA is not a
document. It is a negotiation between design engineering, manufacturing
engineering, production, quality, and often procurement. Getting five
departments into the same room at the same time, with the right people,
with the right information, is not a logistical detail. It is the
project. And it is never accounted for in the timeline.
Second, quality work surfaces unexpected problems. This is literally
its purpose. When you begin a serious FMEA on a process that has been
running for years, you discover failure modes that no one anticipated.
Each one requires investigation, data collection, discussion, and
consensus. The timeline assumes none of this will happen. It always
does.
Third, quality projects compete with production. The production
manager who agrees to allocate two hours per week for quality training
will, when a customer order is late, reallocate those hours to the line.
This is not sabotage. It is rational prioritization from their
perspective. But it extends every quality timeline by exactly the amount
of time that was “temporarily” borrowed.
Fourth, quality improvements depend on cultural change, and cultural
change does not respect Gantt charts. You can train someone on SPC in a
day. You can install the software in a week. You cannot make an operator
who has spent fifteen years relying on experience and intuition start
trusting a control chart instead of his gut in any timeframe you can put
on a project plan. The plan accounts for the training. It never accounts
for the adoption.
The Anatomy of a
Biased Quality Timeline
Let me walk you through a real pattern I have seen play out dozens of
times across automotive, aerospace, and pharmaceutical manufacturing.
The names change. The numbers change. The structure never does.
A company decides to implement a new quality management system. The
project manager, who is competent and well-meaning, creates a work
breakdown structure. Gap analysis: four weeks. Documentation
development: eight weeks. Training: four weeks. Internal audit: two
weeks. Corrective actions from the audit: three weeks. Certification
audit: one week. Total: twenty-two weeks. Five and a half months.
What actually happens:
The gap analysis takes six weeks instead of four because the team
discovers that three legacy processes were never documented and two key
people are on vacation. The documentation phase takes fourteen weeks
because every procedure requires three rounds of review and the legal
department insists on seeing the supplier quality manual. Training takes
eight weeks because production will only release people in groups of
four and the first training session revealed that the materials were
written for engineers, not operators. The internal audit finds
forty-seven nonconformances instead of the expected fifteen. The
corrective action phase takes twelve weeks. The certification audit is
rescheduled once because the registrar has no availability and a second
time because the company is not ready.
Total elapsed time: fourteen months. Not five and a half.
The interesting thing is not that the estimate was wrong. The
interesting thing is that everyone involved in creating the estimate had
lived through a nearly identical experience before. The project manager
had overseen a similar implementation at a previous company that took
thirteen months. The quality director had been through certification
three times in her career. None of them had ever seen a
five-and-a-half-month implementation. And yet, when the estimate was
prepared, no one raised a hand.
This is the planning fallacy in its purest form. Direct, relevant
experience does not protect you from it. The inside view — the seductive
narrative of this project, this team, this time — overrides the outside
view every time.
The Cascade of Consequences
The planning fallacy does not merely produce late projects. In
quality, it produces something much worse: it produces corners being
cut.
When a project falls behind schedule, the organization faces a
choice. Extend the timeline, which means re-approving budgets,
explaining delays to leadership, and admitting that the plan was wrong.
Or compress the remaining work into the original timeline, which means
skipping steps, reducing rigor, and accepting compromises.
In my experience, organizations almost always choose the second
option. This is not because they are reckless. It is because the social
and political cost of admitting a planning failure is perceived as
higher than the quality cost of rushing. And so the FMEA gets completed
in a workshop instead of being done properly across weeks. The training
gets condensed from four sessions to two. The internal audit samples
twenty transactions instead of fifty. The corrective actions get
“verified” by email instead of by re-audit.
Each individual compromise feels reasonable in the moment. But each
one embeds risk into the quality system that the organization will carry
for years. The planning fallacy does not just make you late. It makes
you late in a way that permanently reduces the quality of the quality
system itself.
The Reference
Class Forecast: A Tool That Works
There is an antidote to the planning fallacy, and it is beautifully
simple, though organizationally uncomfortable. Kahneman called it the
reference class forecast, and it works like this.
Instead of building a timeline from the bottom up by estimating
individual tasks, you start by asking a different question: How long
have similar projects actually taken in comparable organizations? Not
how long they were planned to take. How long they actually took.
If you are planning an FMEA rollout and you can find data from ten
similar implementations, and the average elapsed time was nine months
with a range of six to fourteen, then your estimate should start at nine
months. You do not get to plan for four months just because you believe
your team is exceptional. You might be exceptional. Statistically, you
probably are not.
The reference class forecast works because it forces the outside
view. It replaces hope with data. It replaces narrative with statistics.
And it produces estimates that, while still imperfect, are dramatically
more accurate than the ones produced by traditional planning.
The reason organizations resist this approach is telling. It produces
timelines that leadership does not want to hear. It produces budgets
that strain credibility. And it requires admitting that your
organization is, in most respects, statistically typical. The planning
fallacy persists not because we lack the tools to correct it, but
because the correction is unflattering.
Practical Strategies
for Quality Leaders
Beyond the reference class forecast, there are several practical
approaches that I have seen work in manufacturing environments.
Build explicit buffers for cross-functional
coordination. Every quality project timeline should include
specific allocations for scheduling conflicts, key-person
unavailability, and departmental prioritization disputes. A rule of
thumb: if your plan requires coordination across three or more
departments, add 40 percent to the timeline. This is not pessimism. This
is empiricism.
Separate technical duration from calendar duration.
An FMEA workshop technically takes two days. On the calendar, getting
the right people in the room, getting the preliminary data prepared, and
scheduling the follow-up actions takes six to eight weeks. Quality plans
almost always estimate in technical duration and then track against
calendar duration. This mismatch alone accounts for a significant
portion of schedule overruns.
Plan for the problems the project will discover.
Every quality improvement project surfaces issues that were not visible
before the project began. A useful practice is to build a specific
“discovery and remediation” phase into the plan. This is not
contingency. This is an honest acknowledgment that the purpose of
quality work is to find things that were hidden, and that finding hidden
things takes time.
Use phased milestones instead of single endpoints.
Instead of planning for “FMEA complete by Q3,” break the project into
phases with explicit go/no-go decisions at each stage. This creates
natural points where the timeline can be recalibrated without the
political cost of a wholesale revision. It also creates accountability
that is harder to defer.
Track estimation accuracy over time. Start recording
the ratio of planned to actual duration for quality projects. After six
or eight projects, you will have a calibration factor that is specific
to your organization. If your projects consistently take 2.3 times
longer than planned, then your future estimates should be multiplied by
2.3. This is not sophisticated. But it works.
The Deeper Lesson
The planning fallacy is ultimately a symptom of a deeper issue in how
organizations think about quality. Quality work is treated as a project
to be completed rather than a capability to be built. This framing
creates the expectation that quality improvements should have defined
endpoints and predictable timelines, when in reality, the most
meaningful quality transformations are ongoing processes that never
truly finish.
The organization that plans its FMEA rollout as a twelve-week project
is setting itself up for failure. The organization that plans its FMEA
program as an ongoing discipline with initial implementation milestones
understands something fundamental: quality is not something you
implement and check off. It is something you build, layer by layer, at a
pace that respects the complexity of what you are changing.
The planning fallacy tells us that we will always underestimate how
long this takes. The corrective action is not to estimate better. The
corrective action is to stop pretending that complex organizational
change can be scheduled like a maintenance task.
The Bottom Line
Every quality professional has seen it. The ambitious timeline. The
confident project plan. The gradual realization that reality has no
intention of conforming to the Gantt chart. The compromises made to
salvage the schedule. The quality system that launched incomplete and
stayed incomplete because the organization moved on to the next
initiative.
The planning fallacy is not a personal failing. It is a cognitive
bias as fundamental as depth perception. You cannot eliminate it through
willpower or good intentions. You can only counteract it through
structure: reference class forecasting, explicit buffers, phased
milestones, and a willingness to let data override narrative.
The next time someone presents you with a quality improvement
timeline, ask the only question that matters: How long did the last
three similar projects actually take? If the answer is different from
what is on the slide, the slide is wrong. And the most important thing
you can do for your quality system is to say so before the project
starts, not after it fails.
Peter Stasko is a Quality Architect with 25+ years of experience
transforming organizations across automotive, aerospace, and
pharmaceutical industries.
