You plan and plan and plan and plan and yet… nothing goes according to plan.

Maybe you and your team are operating under these 4 cognitive biases:

A cognitive bias is a mistake in reasoning, evaluating, remembering, or other cognitive process, often occurring as a result of holding onto one’s preferences and beliefs regardless of contrary information. >>www.chegg.com

 

1. Bias: Dunning–Kruger effect – The tendency for unskilled individuals to overestimate their own ability and the tendency for experts to underestimate their own ability. >> org

Possible symptoms:

• When less experienced team members provide unrealistically optimistic estimates, not taking into account other work commitments (e.g., meetings, emails, normal interruptions and interactions).
• When very experienced team members provide unrealistically pessimistic estimates based on previous experiences of things going wrong, unexpected events, lack of clarity and people changing their minds.
• When evaluating bid proposals one company either under- or over -quotes the rest, significantly.
• Team members who are already working at or over capacity volunteer to do more.
• Experienced team members who seem to be highly skilled maintain that they are not capable of the task.

Potential remedies:

• Estimate in groups. Many Agile methods recommend techniques such as T-shirt estimating or Planning Poker that is done in groups so that team members (with varying experience and expertise) can talk through assumptions and come to a consensus on the size of effort.
• Use estimating points. More Agile techniques recommend using ‘estimating points’ instead of jumping straight to time and cost estimates. Providing estimates in time and costs (early on) can be humiliating later on if they are then incorrect. Experiences like this can be off-putting and end up reinforcing pessimistic estimates on future efforts.
• Provide estimates in ranges. Ranges show best case scenario to worst case scenario to counteract the different expectations.
• Identify the underlying assumptions. Ask those companies under- or over- quoting what assumptions they are making about the work.

 

2. Bias: Planning fallacy (optimism bias) – The tendency to underestimate task-completion times >>Wikipedia.org

Possible symptoms:

• Projects are consistently running over time.
• Re-estimates are just as inaccurate as the original estimates.

Potential remedies:

• See ‘planning in groups’ above. The knowledge transfer amongst team members is immeasurable and invaluable. The learning that occurs across the team helps each member to hone their own estimating expertise.
• Use stages / sprints / timeboxes. Break projects into small chunks and do one chunk at a time. The team can hone their ability to estimate on smaller pieces of work. If/when things take longer (or if using Agile if/when scope is dropped), lessons can be learned for estimating the next chunk.
• Really and honestly put the time and effort into retrospectives and lessons learned. I’m serious. As a team, really and truly review what went well (so that can be repeated) and what didn’t go so well (so that can be improved). Instead of repeating the same misestimating efforts again and again, learn. This should be the whole team’s responsibility.
• Keep track. This will aid in the retrospectives of what went well and what didn’t. If you’re not keeping track of what was estimated compared to what actually happened, then there’s no way to tell how you did (a little off, some what off, really far off!). Review regularly. Look for patterns (interruptions, distractions, clutter) that cause the discrepancies between planned and actual.

 

3. Bias: Normalcy bias – The refusal to plan for, or react to, a disaster which has never happened before. >>Wikipedia.org

Possible symptoms:

• Risk management is only given ‘lip service’. Risk meetings are not regularly scheduled nor well attended.
• Risks are not considered in planning sessions. Planning sessions revolve around estimates, known dependencies and assigning tasks. There is no agenda item for identifying (or even reviewing) risks.
• Estimates are always presented as exact figures. There is no contingency or discussion of assumptions built into estimates.
• Requirements are estimated based on their expected acceptance criteria.

Potential remedies:

• Add Risk identification activities to planning session agendas. Tools to add to the planning sessions could include brainstorming exercises, discussions with stakeholders inside and outside of the organisation about previous disasters, advice from a Disaster-Recovery expert, plan alternative contingencies, and identify early warning indicators to monitor going forward.
• Get multiple stakeholders involved. Hold specific risk reviews of draft plans with diverse groups of stakeholders before signing off a plan. Getting multiple view points on plans will help overcome this bias, as each new person who sees the plan can bring their experiences and interpretations of what might go wrong.
• Define unhappy path tests. Defining requirements in terms of what would happen if the unexpected happened (the building floods, the server goes down halfway through a transaction, hackers accessed the main database). Thinking of weird or unusual situations and how the product would have to act and react helps the team think confront the fact that ‘things’ happen, unexpected things happen and they have to be dealt with.

 

4. Bias: Anchoring bias – The tendency to rely too heavily, or “anchor”, on one trait or piece of information when making decisions (usually the first piece of information acquired on that subject) >>Wikipedia.org

Possible symptoms:

• Stakeholders keep throwing your original (early days) estimate at you as if it were a fact, not a ‘best judgement in time’ and arguments ensue.
• Stakeholders refuse to let go of old estimates when new information is presented.

Potential remedies:

• Recognise the bias. Unfortunately, this bias is strong! Even experts fall under this bias, so there’s not a lot of hope for the rest of us. The best bet is to recognise it. Call it out. Let people know that they might (probably will) fall under it. Make it a thing. Now when stakeholders are complaining that timings have changed or cost estimates have risen, everyone can reflect that they might be more upset because of the bias than the actual time or cost differences.
• Provide estimates using ranges. Seeing or hearing the whole range of best case to worst case is now the ‘first piece’ of information that is being shared. Based on the estimating funnel, the earliest estimates are speculative in nature and therefore cannot be accurate. So instead of presenting actual figures, provide a wide range that narrows over time, as more and more is known about the project.
• Use multiple sources. There is some evidence that comparisons help combat the anchoring bias. Similar to ranges, multiple numbers are presented simultaneously and thus they can all be considered the ‘first piece’ of information. Multiple sources of information (similar to a comparison website) might help take the anchoring edge off.

What cognitive biases do you and your team face when planning? What are you doing about them?