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 helps people untangle complex technology, processes, relationships and governance. He is a guest blogger on Econsultancy.
No hay comentarios:
Publicar un comentario