Psychological biases, their effect on project management and how to avoid them

A thousand and eight years ago, before I got into project management, I was interested in psychology.  The two are – needless to say – inextricably linked as well.  It very rarely comes as a surprise to people that I went from a degree in psychology to a career in project management!  But I love it when the two disciplines overlap.  In this article, I’m exploring some of the psychological biases and fallacies that we all fall prey to because, well – we’re human!  Importantly, I’ll also take a look at what can be done to avoid them.  First up is a classic…

The Sunk Cost Fallacy

Perhaps the most famous of all the biases I’ll discuss is the sunk cost fallacy.  This is the tendency to stick to a course of action due to the amount already invested in it, rather than taking the more sensible decision to stop.  In projects, I find this is particularly insidious at – believe it or not – the business case stage.  The business case ought to be one of the key tools in killing off the sunk cost fallacy, but I’ve genuinely worked in places where, if you have written a business case it will typically get approved, simply because someone has taken the time and effort to write a business case.  It must surely therefore be a project worth doing, goes the (il)logic.

But it can happen at all stages of a project and is to be resisted!  There will be no medals for getting a project over the line that no longer provides any kind of a return or will not get the uptake originally estimated.

How to avoid it in projects: invest in robust project governance.  Most project management training reminds us that we should be checking that the business case still stacks at every stage gate, but how many of us actually do?  And if the business case does get checked, how often will a project get stopped if the case no longer exists.  Project governance exists precisely as a check on things like the sunk cost fallacy, so make sure yours is robust.  You could even (whisper it) celebrate projects that have the good sense to stop before good money is thrown after bad.  They’re such a rarity.

Plan Continuation Bias

This is similar in nature to the sunk cost fallacy (and often occurs in tandem) as it is an inclination to continue a course of action rather than change.  Tom Connor on Medium provides a nice explanation along with several famous examples of Plan Continuation bias.

Plan continuation bias is the act of continuing to follow an established plan despite changing conditions and increasing evidence that an alternative course of action would be better.  Another version of this bias is the ‘doubling down’ phenomenon described in Matthew Syed’s excellent Black Box Thinking, where, presented with evidence that contradicts someone’s belief, rather than reappraising, they will actually ‘double-down’ in their support for that belief.  Matthew Syed movingly highlights just how dangerous this phenomenon can be in a medical context and points to creating an environment where people are not only comfortable, but encouraged to challenge decisions being made.  To see an example of this in the real world, this idea is now embodied in Martha’s Rule in UK healthcare.

How to avoid it in projects: healthy risk management and reporting.  Having a healthy risk management environment where people feel comfortable to report risks, no matter how seemingly inconsequential, will allow for a realistic consideration of the threats and how best to mitigate them (up to and including contingency planning).

The Planning Fallacy

The planning fallacy comes to us from two giants in the world of psychology: Daniel Kahneman and Amos Tversky.  It describes how we tend to be overly optimistic about timescales (something familiar to anyone who has worked in projects, even briefly).  In fact, the planning fallacy definition has been extended to include optimism not just in relation to timescales, but also to cost estimates and benefit realisation (alongside an underestimation of risk).  This leads to “not only time overruns, but also cost overruns and benefit shortfalls.”

It often feels like a simple truism that projects will be delivered late and cost more than they were supposed to, while delivering less benefit than intended.  But this is plainly not supposed to be the case!  Indeed, this is WHY WE HAVE PROJECT MANAGEMENT as a discipline.  And yet, it is often project teams who are most susceptible to this fallacy.

How to avoid it in projects: challenge, challenge, challenge.  As a project manager do not be afraid to challenge the estimates that you receive from your team.  But – and here’s the really important part – challenge whether enough time or money has been estimated.  Given the obvious pressures from stakeholders to deliver faster and cheaper, most project managers will happily challenge estimates of time and cost downward and be so pleased when they receive a lower estimate that they accept it.  We must learn to buck this trend and challenge estimates upwards – not outrageously so; just to the point of realism.

See also: Wishful thinking and Hofstadter’s Law (below).

Honourable mention: Hofstadter’s Law

This is related to the planning fallacy and comes from another great in the world of psychology: Douglas Hofstadter.  Hofstadter’s Law dictates that: “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”  I really love the humorously self-referential nature of this law, but more than that, I love how true to life it is.

Brooks’s Law

This law was originally coined by Fred Brooks in The Mythical Man-Month, sometimes referred to as the Bible of software project management, though I think this idea applies more widely than just software projects.  Brooks’s law states that “Adding manpower to a late software project makes it later.”  For many, this is a counter-intuitive claim; when something is running late, the temptation is to throw more people at it in order to get it over the line.  Indeed, it is often seen as a central tenet of project management that by increasing resources it is possible to reduce delivery time.

And this is true for work that can be easily and effectively compartmentalised (such as building a modular structure).  But for more complex solutions you may be inadvertently extending the timelines by adding more people.  This is because new resources will take time to come up to speed and be productive.  Where specialist knowledge is required on a project, simply throwing another body at the problem, won’t help.

How to avoid it in projects: when things are running late, take a moment to consider whether adding more people is actually the best solution.  Better yet, ask the team whether additional support would actually be helpful or a hindrance.  The people working on the problem are usually the best placed to tell you the solution.

Action bias

As someone who is naturally given to pausing and wanting as much data as possible before making a decision, I find this bias particularly interesting.  Action bias is the tendency to favour action over inaction, even when doing nothing would be a much better strategy.  It is also reflected in the age-old aphorism “Act in haste, repent at leisure.”  As humans we seem to approve more of people who take action in certain situations over those who do not act, but might instead pause to reflect and consider the best form of action.  This particularly comes to the fore in the domain of project issues management.  When the proverbial hits the fan (or as a colleague of mine once put it for a massive issue “The dung-heap has hit the windmill”) the overwhelming temptation can be do act – often on impulse, often without due thought to the consequences.  The overriding consideration is simply to act.

The best project (and indeed crisis) managers, when faced with issues will also act, but their response will be measured and practiced.  They will take time to consider their action, but only as much time as is needed to satisfy themselves that action is the right course.

How to avoid it in projects: the antidote to action bias can be summed up in the quote usually attributed to Sylvia Boorstein: “Don’t just do something. Sit there.”  Assess the issue quickly and be as realistic as possible about its impact.  Be careful not to overstate the impact.  The human tendency to catastrophize in stressful situations must be overcome here.  Finally, have an issues management strategy from the outset of your project and implement it.  Decide who you will need to pull into each type of issue you might encounter; the point at which escalation will be necessary and what your escalation paths will be.  This will save you valuable time in the moment and hasten your path to action – if that’s what is necessary!  Above all – take a breath.  Issues are rarely as bad as they appear at first blush.  Allow yourself the time to make the right decision, not just any decision.

 

What would you add to the list?  And how have you seen these play out in your projects?  Let me know in the comments.

To receive these blogs, project management tips and video tutorials straight to your inbox click here to sign up to our newsletter.

Image by Elisa from Pixabay