{{ searchResult.published_at | date:'d MMMM yyyy' }}

Loading ...
Loading ...

Enter a search term such as “mobile analytics” or browse our content using the filters above.

No_results

That’s not only a poor Scrabble score but we also couldn’t find any results matching “”.
Check your spelling or try broadening your search.

Logo_distressed

Sorry about this, there is a problem with our search at the moment.
Please try again later.

Problems rarely kill projects. What kills them is failure to recognise and address problems.

A colleague said recently that online projects fail for three main reasons – poor governance, weak communication or problematic technology, and in roughly equal proportions.

I’m not sure I agree about the proportions, but the categories feel useful.

For a start, each has its own distinctive failure modes.

Governance failures

Failures with governance, for example, stem from a failure to decide. Perhaps the accountability for a decision is unclear, or maybe the decision-maker refuses to step up to the mark. 

This then creates uncertainty. People wait about, or act on the basis of unconfirmed assumptions, so we get delays and divergent actions. 

At worst, poor governance creates a vacuum that gets filled by confusion and politicking.

Communication failures

Communication failures, on the other hand, generally stem from a failure to listen. People think they’ve communicated, but never check that the message has been received. 

Or they focus on what they want to tell people, with little thought for what people want to tell them. So they starve themselves of information. Eventually everyone’s understanding of the project diverges and it begins to lose forward momentum.

Technology failures

And finally, technology failures result from a failure of understanding. We underestimate the complexity of the problem we’re trying to solve, or overestimate the capability of our teams and tools to solve it. 

So we end up trying to do stuff that just isn’t feasible within the constraints of our tools, skills, deadlines and budgets.

These failures are all common enough. They’re also all recoverable. Once we see the problem, we can make the decision, gather the necessary feedback, train the team or adjust the tools and plans. 

What really kills projects is failure to identify such problems and fix them. This brings me to the underlying reason for most project failures.

Projects fail because they lose touch with reality.

Rather than dealing with the problem, they proceed as if it doesn’t exist. Sometimes they don’t even see the problem: everyone gets so locked into their own assumptions that they miss the reality completely. 

Or perhaps someone does see the problem, but they’re afraid to mention it. Or they’re not heard when they do mention it. And so the problem compounds and eventually the project fails.

And why are project teams so good at avoiding reality? 

Here are five common reasons, all grounded in basic human psychology:

Anchoring

We interpret what we see in light of the ideas already in our heads. This affects estimation. If I ask “Can you do this by Friday?” your perception of the size of the task will be very different to if I ask “How many months will it take to do this?” 

And project planning has a diabolical effect – if you spend days developing a plan, then it gets very embedded in your mind. So you’ll be very prone to interpret reality as if it still fits the plan, no matter how far off course we’ve got.

Confirmation bias

We tend to gather information with a view to confirming our ideas, rather than disproving them. So as a project team will focus on the metrics and indicators that “prove” it’s on track, paying less attention to the ones that show how lost it really is.

Repetition bias

The more often we hear something, the more likely we are to believe it. This is the basis of most propaganda (and advertising). 

Every time we report our status as “green”, we get a little more locked into the idea that all is well, regardless of how it’s really going.

Pain avoidance

We all like to avoid pain. And telling people our project is off course can bring a lot of pain – embarrassment at admitting “failure” to our peers and superiors, fear of consequences such as lost bonuses or even lost jobs, the consequences themselves. 

So it’s very easy to avoid the pain and tell ourselves that all is well. Sadly, often we’re deferring the pain rather than avoiding it.

Overconfidence

Most people think that they are above average drivers and have above average intelligence. That’s a statistical nonsense. But it’s one reason why we’re more likely to underestimate than overestimate. 

And it’s a core reason for teams believing that they will make up any delays by the next milestone.  The reality is that projects, once they're behind, almost never make up the delays.

And how do we avoid these biases?

Awareness of them helps. We can temper their effect if we’re aware of the way they act.  ut what we really need to do is find people who aren’t so locked into the original assumptions.

People who aren’t anchored on the plan, and hence don’t have any bias towards confirming it, can be better placed to see where we’ve drifted off course.

That’s why I think projects benefit from independent reviews. People with an outside perspective can bring us back into touch with reality, while we’ve still got time to fix things.

Image credit: Griffithchris via Flickr

Graham Oakes

Published 19 April, 2012 by Graham Oakes

Graham Oakes helps people untangle complex technology, processes, relationships and governance. He is contributor to Econsultancy.

43 more posts from this author

Comments (3)

Avatar-blank-50x50

Carolyn Clarke

As usual, Graham has hit it on the head. I've now survived 5 major enterprise-level redevelopments of intranets and websites, and no amount of planning, gantt charting etc can solve the mind-set problems that the project team bring to the project.

I found some of the good ways to mitigate all the failings he has named is: (1) to have a clear, simple achievable goal, e.g. not 'a new intranet' but 'an intranet that delivers the best possible user experience', (2) to use personas, so that compromises aren't made to solve the problem by reducing the quality of user experience for the personas, or removing some of their requirements, (3) to avoid using your Comms team and speak for yourselves to the company.

about 4 years ago

Panos Ladas

Panos Ladas, Digital Marketing Manager at Piece of Cake

Loved it!!!! Great article Graham!!! Well done, really loved it :D

about 4 years ago

Avatar-blank-50x50

Uladzislau Shauchenka, Entrepreneur at Ulikeapps

Take a look at Why Projects Fail http://whyprojectsfailbook.com. It's a 113 pages book featuring project management case studies, analyze of failed projects, suggestions and recommendations.

almost 3 years ago

Comment
No-profile-pic
Save or Cancel
Daily_pulse_signup_wide

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Daily Pulse newsletter. Each weekday, you ll receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.