Most bad business decisions are not made by careless people. They are made by capable people running a reasonable process that has a predictable flaw in it. Knowing the name of the flaw helps less than people expect. Changing the process so it cannot happen is what works.
This page lists the traps that show up most in system selection and ERP projects, grouped so they are usable, then covers why knowing about them is not enough and what to do instead.
Traps in how the problem gets framed
- Solving the stated problem. "We need better reporting" is usually a symptom. The problem is often that two systems disagree, and no report fixes that.
- Anchoring on the first number. The first quote, the first timeline or the first vendor estimate sets the range everything else is judged against, including when it was a guess.
- Treating the loudest requirement as the biggest. Volume of complaint is not a measure of cost.
- Scope by wishlist. Collecting requirements without ranking them produces a list nobody can price and everybody assumes is funded.
Traps in gathering information
- Asking managers how the work is done. They describe the process as designed. The people doing it know the version with the workarounds in it.
- Confirmation in vendor demos. You see what you went in expecting, because the demo was built to show it.
- Taking "our data is clean" on trust. It is the most common claim and the least often tested.
- Survivorship in reference calls. Vendors give you the clients who stayed. The ones who left are the interesting calls and you will not be offered them.
Traps in weighing options
- Sunk cost. Three years into a system that does not fit, the money already spent is not a reason to spend more. It feels like one.
- Feature counting. A longer feature list wins comparisons and loses implementations. What matters is the handful of things you do daily.
- Availability. The failure you heard about recently feels more likely than the one you have not.
- False precision. A scoring matrix with weighted decimals looks rigorous and is usually a judgement call wearing a lab coat.
Traps in estimating
- Planning fallacy. Every project is estimated as though nothing will go wrong, by people who know things go wrong.
- Ignoring the base rate. Your project is more like other projects than it feels. Ask what the last three took.
- Optimism about availability. The internal time a build needs is real work by people who already have jobs.
- Estimating the build and not the adoption. Go-live is the start of the expensive part.
Traps in deciding and committing
- Consensus mistaken for agreement. Silence in a meeting is not assent, and the objection will arrive as a variation later.
- Escalation of commitment. Once a decision is public, reversing it costs status, so it gets defended past the point of sense.
- Diffuse ownership. A decision that belongs to a committee belongs to nobody, and nothing surfaces it until it is late.
- Deciding once and never revisiting. A good decision made with the information available in month one is often a bad one by month six, and nothing makes anyone look again.
Why knowing the list is not enough
This is the part most articles about cognitive bias leave out.
The research on debiasing is not encouraging. Teaching people about a bias produces modest, often short-lived improvement, and it reliably produces a new problem: people become better at spotting the bias in other people's reasoning than in their own. A team that has read the list argues about which bias the other person is committing.
What does work is structural. Change the conditions so the trap cannot spring, rather than asking people to resist it:
- Write the estimate down before you hear theirs. Anchoring cannot operate on a number you already committed to.
- Ask for the artefact, not the description. "Show me the last ten orders" beats any amount of self-awareness about how managers describe process.
- Stage the commitment. Sunk cost and escalation both need a large irreversible decision to work on. Remove that and they have nothing to grip.
- Name one owner per decision. Diffuse ownership is a structural fault, not a character fault.
- Diarise the review. Revisiting is the only defence against a decision that was right once.
- Write down what you assumed. An assumption on paper gets challenged. In someone's head it becomes a variation.
Every one of those is a change to the process rather than to the person, which is why they survive a busy week.
How this connects to the OODA Loop
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 two are different things with similar names.
Most of the traps above sit in Orient, the step where you work out what the information means. It is also the step that gets skipped, because the picture feels settled once you have gathered the facts. Running the loop deliberately means orienting again when new information arrives, which is the structural version of staying open to being wrong.
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 The Dunning-Kruger Effect for the one trap that does most damage in scoping, or Odoo ERP Implementation for how staged delivery removes several of these structurally.
Frequently asked questions
Does training people about cognitive bias actually help?
Only modestly, and the effect tends to fade. It also has a side effect worth knowing about: people become better at spotting bias in others than in themselves. Structural changes to the decision process work better than asking people to think harder.
What is the single most expensive thinking trap in an ERP project?
Scoping from how managers describe the process rather than how it is performed. Everything downstream is built on that description, and the difference arrives later as unpriced variations.
How do you avoid anchoring on a vendor's first estimate?
Write down your own expected range before the conversation. Anchoring cannot operate on a number you have already committed to, and the gap between the two figures is itself informative.
Is a weighted scoring matrix a good way to choose software?
It is useful for structuring a discussion and misleading as an answer. The weights are judgements, so the decimal places give a judgement call the appearance of a calculation. Use it to surface disagreement, not to settle it.
How does staged delivery help with decision traps?
Sunk cost and escalation of commitment both need a large irreversible decision to work on. Committing to one stage at a time removes the thing they grip, and each review is a scheduled opportunity to change your mind cheaply.
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. Most of these traps sit in the orient step, where you decide what the information means.
