MITIGATIONS FOR THE PLANNING FALLACY

Steve Loving, PMP, Scrum Master [email protected] [email protected] www.stanford.edu/~loving Goals for this talk

• Be able to define the Planning Fallacy • Recognize the planning fallacy in your projects • Learn some mitigations that you can use • Get some resources to learn more Bibliography and Disclaimer

• The bibliography is on page 9 of the paper, it is the most important page of the whole paper and the foundation of the talk. Here are some highlights: • Thinking, Fast and Slow. By , 2011 • Exploring the “Planning Fallacy”; Why People Underestimate Their Task Completion Times. By Roger Buehler, Dale Griffin and Michael Ross, 1994. • Identifying and Managing Project Risk: Essential Tools for Failure-Proofing Your Project, Second Edition. By Tom Kendrick, 2009. • The Signal and the Noise: Why So Many Predictions Fail – but Some Don’t. By Nate Silver, 2012.

• This paper/talk is my interpretation of the concepts of the planning fallacy, and my conclusions based on my own, often limited, understanding. Please try these ideas, but, most importantly, consult the original books and articles for additional information. I apologize for any errors in judgments, faulty linkages or unsubstantiated conclusions.

What is the Planning Fallacy?

• The Planning Fallacy is a set of cognitive biases present across all levels of expertise and all subject matters • Planners/PMs/Project teams are exhibiting the Planning Fallacy when they: – use an internal, idealized scenario about the future of the project, (this can also be the case when a team is using a proprietary model) – ignore past information – show false optimism , sometimes exacerbated by high motivational states. What is the Planning Fallacy?

• Anchors influence the Planning Fallacy – numbers introduced early in planning, even spurious numbers, influence estimates/planning • Closely linked to the PF, seen in novices and experts alike, are limits in cognition whenever probabilistic thinking is involved – this becomes an issue when project teams must deal with likelihood of risk events (see Kendricks’ book) DIMENSIONS OF PLANNING FALLACY

PLANS X X PAST X X X X OPTIMISM X X X X X MOTIVATION X X X ANCHOR X X X MODELS X X X X X X

PROBABILITY X X X X

.Class

-

Mitigation Premortem Reference Likely Most Development Algorithm Bayes ModelExplicit Techniques Structured Decomposition Scrum TheoryOf Constraints • Proposed by Gary Klein Mitigation - • The project team is asked to imagine Premortem themselves at the project end date, or at the service rollout date. They are told to imagine that the project has gone awry; it is late, incomplete, of poor quality, over DIMENSIONS OF PLANNING budget, and/or perceived by the clients as a FALLACY failure. PLANS PAST X • What were all the possible pitfalls in this OPTIMISM X MOTIVATION X imaginary project failure? ANCHOR MODELS • The premortem takes positions “outside” of

PROBABILITY the project for a unique view.

• This is mitigation for the .

• The premortem can mitigate the propensity Premortem Mitigation to discount or ignore past experiences

• The Reference Class is an idea championed Mitigation – by Bent Flyvbjerg in his work on Reference Class . • The Reference Class institutionalizes an outside view. DIMENSIONS OF PLANNING • The Reference Class is a database of FALLACY PLANS X projects. A project team can compare their PAST X OPTIMISM project to projects in the database. MOTIVATION ANCHOR X • The use of this tool forces a team to pause MODELS and reconsider lessons from the past PROBABILITY

• It can help the team to gauge the validity of

- the internal planning assumptions

• This approach can help to correct false

Reference Reference .Class Mitigation anchors.

Mitigation-Most Likely • Another idea from Flyvbjerg Development • What is the impact to the overall project of deleting just the high risk components? • In this approach, the larger project is DIMENSIONS OF PLANNING decompose a project with risk in mind. FALLACY • Look at parts of the project that have PLANS PAST the highest probability of , OPTIMISM X MOTIVATION X schedule overrun, or negative ANCHOR environmental MODELS X PROBABILITY X • This technique forces a team to look at

alternative models for the project

• Remembering Kendrick’s risk formula,

MLD’s focus implies the team is using

Most Likely Likely Most Development Mitigation probability to determine risk; this approach may strengthen probabilistic thinking. • MLD is also a way to address optimism and motivational bias.

• Project teams can use the Bayesian algorithm Mitigation – to adjust their judgment of the probability of Bayes’ Algorithm success of their planning efforts. • Bayes’ methods are mitigations for planning fallacy where there is a heavy reliance on an internal scenario, use of probabilistic thinking, DIMENSIONS and a lack of consideration of past lessons. OF PLANNING FALLACY • Planning parameters that have been impacted PLANS X by the anchoring phenomena can also be PAST X OPTIMISM corrected via the Bayes’ algorithm MOTIVATION X ANCHOR • The algorithm is best used iteratively MODELS X PROBABILITY X throughout the life of the project

• Interpretation of results is not always easy –

may need an exceptional team and sponsor to

follow the ups and downs of the math and the

Bayes Bayes Algorithm Mitigation predictions • See Nate Silver’s book for a more in depth explanation and good “cookbook” • The process of changing a model from Mitigation – intrinsic to explicit will improve planning Explicit Models • The best examples of extrinsic models are computer and simulation models • Variables, dependencies, and assumptions DIMENSIONS can be identified during extrinsic model OF PLANNING FALLACY building PLANS PAST • The explicit models can moderate the OPTIMISM MOTIVATION influence of the outside view of a project in ANCHOR the planning phases MODELS X

PROBABILITY • This mitigation might be a difficult one for

many project teams – Simulation packages tend to be specialized to particular fields,

and general purpose packages require

Mitigation ModelExplicit special expertise Mitigation – • Structured techniques are cookbook Structured processes that are reliant on data and Techniques detail. • They are consistent process, repeated multiple times throughout estimation DIMENSIONS phases OF PLANNING FALLACY • PMI Practice Standard for Earned Value PLANS PAST X Management is an excellent source for OPTIMISM X structured techniques MOTIVATION ANCHOR X • “Estimates without associated risk MODELS

PROBABILITY assessments are worthless.”

• Use the Central Limit Theorem (CLT) – seek many estimates on small chunks of work, let

average help with final numbers

Mitigation Structured Techniques • Activity Based Costing (ABC) – iterative model where costs can be spread across organizations (see paper) Mitigation - • Project managers have access to a wealth of Decomposition/ information on project decomposition WBS practice in the PMI Practice Standard for Work Breakdown Structure. • Every step of creating a WBS forces more details, and may illuminate faulty models DIMENSIONS OF PLANNING • Quoting Tom Kendircks: FALLACY PLANS “Whenever it is confusing or difficult to PAST OPTIMISM decompose project work into smaller, more MOTIVATION manageable pieces, there is scope risk. If any ANCHOR MODELS X part of the project resists breakdown using these PROBABILITY ideas, that portion of the project is not well

understood, and it is inherently risky.”

• WBS remains one of the strongest tools for

any project team; it addresses many issues

Decomposition WBS Mitigation in project governance. • Stories and tasks are ranked and scored by Mitigation -- the Scrum team using story points. Scrum • Story points are internally consistent and allow the Scrum team to communicate with certainty about the probability of meeting goals. DIMENSIONS • Story point awarding is a consensus based OF PLANNING FALLACY process PLANS PAST • Most Scrums operate with quality control OPTIMISM X MOTIVATION built into the development and release ANCHOR cycle, so estimations are automatically MODELS X PROBABILITY X iterative.

• Iterative estimation can be a remedy for the

pitfalls of ignoring the past, implicit models,

and poor estimations based on an inside

Mitigation Scrum view.

Mitigation – • The Theory of Constraints (TOC) is the work Theory of of Eliahu Goldratt (see his 1997 book, Constraints Critical Chain) • TOC and Critical Path use real time mitigation for projects via buffer management. DIMENSIONS OF PLANNING • Estimation becomes more team oriented. FALLACY PLANS Data are fresh, problems are solved quickly. PAST OPTIMISM X • The team has influence on the probability MOTIVATION ANCHOR X of meeting estimation. MODELS X PROBABILITY X • These TOC and Critical Path based methods

of estimation mitigate the optimism bias.

• The Critical Path buffer method allows the

project team to identify problems with

TheoryOf Constraints Mitigation faulty estimations as they happen, remedying false anchors.

Mitigations for the Planning Fallacy Conclusions • Humans exhibit the planning fallacy and there are mitigations. • No single mitigation is likely to be the ideal solution for a project team struggling with estimation. • However, there is at least one advantage both to thinking about the problems of estimations and considering the solutions; the team looks outside of themselves. • A team that slows down to improve estimating, takes an outside view of the project, and considers other variables and priorities, may see some improvement in estimates. • Perhaps a team will try these methods and say: “We have increased confidence in our estimations. Our team is using these mitigations, and we are experiencing an increase in the accuracy of project estimation and our project planning.”

Questions

Steve Loving, PMP, Scrum Master [email protected] [email protected] www.stanford.edu/~loving 415 860 4670