Skip to Content
← Articles
Leadership & Management · 6 min read

The Dunning-Kruger Effect: How Overconfidence Can Ruin Your Organisation

What the research actually says, and why it wrecks ERP scope anyway.
The Dunning-Kruger Effect: How Overconfidence Can Ruin Your Organisation

The Dunning-Kruger effect is the best-known idea in business writing about overconfidence, and the most overstated. The original finding is narrower than the popular version, and a good deal of it is disputed. The underlying problem is real anyway: in an ERP project, the people most confident about how a process works are often the furthest from doing it.

This page covers what the research actually says, why the pattern shows up in system projects regardless, where it does real damage, and what to do about it.

What does the research actually say?

Less than the chart suggests.

Kruger and Dunning published in 1999, finding that people who scored poorly on a test tended to overestimate their performance, while high scorers slightly underestimated theirs. The popular version became a curve where incompetence produces soaring confidence, usually drawn with a peak labelled "Mount Stupid". That curve is not in the paper.

Since then a substantial critique has argued that much of the pattern is a statistical artifact. If you plot self-assessment against performance when both contain error, you get something resembling the effect from random data alone, through regression to the mean and autocorrelation. Researchers disagree about how much survives once that is accounted for.

Honest summary: people are not reliable judges of their own competence, and that is well supported. The specific claim that the least competent are the most confident is contested and often repeated with more certainty than it deserves.

Which is enough to be useful, because the practical pattern in a system project does not depend on the disputed part.

Why does this show up in ERP projects?

Because the people describing a process and the people performing it are usually different people.

Scoping workshops run with managers. A manager describes the process as designed: the approval path, the sequence, the exceptions they know about. They describe it confidently, because from where they sit it is simple. They are not wrong about the design. They are describing a version of the process that nobody has performed in two years.

The person doing the work knows the real one, including the workaround they invented when the designed version stopped fitting. They are often less confident describing it, because they are aware of the exceptions and the parts they are unsure about.

So confidence runs inversely to proximity, and the project gets built against the confident description. That is the effect that matters, and it needs no contested psychology to explain it.

Where does it do the damage?

Four places, in rough order of cost.

Scope. A process described as four steps turns out to have eleven. Each addition is small and reasonable and unpriced, and together they are the variation nobody chose. Covered at length in Why do most Odoo and ERP projects blow out?

Data. "Our customer list is clean" is one of the most confidently wrong statements in any project. It is almost never tested before migration is scoped.

Vendor selection. Both sides are susceptible. A buyer who has read about ERP for a month can feel ready to evaluate platforms. A vendor who has done forty builds can assume this one is the same shape.

Go-live readiness. Confidence peaks just before cutover, when everything has been built and nothing has been used in anger.

What actually helps?

Not humility as a value. Mechanisms that make the claim testable.

  • Talk to the people doing the work. Not a survey, and not a meeting with their manager present. The difference between the described process and the actual one is the project's main risk.
  • Ask for the artefact, not the description. "Show me the last ten orders" beats "describe your order process". The exceptions are visible in the records and invisible in the summary.
  • Test the confident claims first. If someone says the data is clean, extract it in week one. The extract settles it in an afternoon.
  • Stage the work. A build delivered in stages is a build where each estimate is checked against reality before the next one is made.
  • Write down what you assumed. An assumption on paper gets challenged. An assumption in someone's head becomes a variation.

How we think about it

Ooda Consulting is named after the OODA Loop, the decision cycle of observe, orient, decide and act. Odoo is the ERP platform we implement; the OODA Loop is the method we run the implementation with. The two are different things with similar names.

The orient step is the relevant one here. It is the point where you check whether your picture of the situation is still the right one, and it is the step most projects skip because the picture feels settled. Running it on a schedule is what stops a confident early description surviving all the way to go-live unchallenged.

How we work

Ooda Consulting is based in Sydney at Level 6/201 Kent St and works with SMEs across Australia and New Zealand. The Australian team scopes the work and supports it afterwards, with a dedicated senior developer doing the build.

See Odoo ERP Implementation for how a build is scoped and staged, or Clean Data, Clean Start for testing the claim that the data is fine.

Frequently asked questions

Is the Dunning-Kruger effect real?

Partly. That people judge their own competence poorly is well supported. The stronger popular claim, that the least competent are the most confident, is contested, with a substantial argument that much of the pattern is a statistical artifact of plotting self-assessment against performance. It is repeated with more certainty than the evidence carries.

How does overconfidence affect an ERP implementation?

It puts the build on the described process rather than the actual one. Managers describe the process as designed and do it confidently; the people performing it know the workarounds. The project is scoped from the confident description and the difference arrives as unpriced variations.

How do we avoid scoping against the wrong process?

Interview the people doing the work, not only their managers, and ask for artefacts rather than descriptions. "Show me the last ten orders" surfaces exceptions that "describe your order process" never will.

Our data is fine. Why does everyone say it is not?

Because it is the claim most often made and least often tested. Extract the customer and product lists in week one and look at them. The extract settles the question in an afternoon and changes the project plan if it is wrong.

What is the OODA Loop, and what does it have to do with Odoo?

The OODA Loop is a decision cycle, observe, orient, decide and act, and it is what Ooda Consulting is named after. Odoo is the ERP platform we implement. The orient step is where you check whether your picture of the situation is still right, which is the step overconfidence skips.

Can staged delivery help with this?

Yes, and it is the most practical defence. Each stage checks an estimate against reality before the next one is made, so a confident early assumption gets corrected in weeks rather than surviving to go-live.

Did you find this article helpful?
We’re happy to answer any of your questions.
Contact us