One reason is culture. Organisations discourage ‘negativity’. They penalise anyone who doesn’t present an optimistic face. This closes off a lot of discussion.
Big projects also make it hard. People struggle to see how widespread problems are. Is it just me, or are other people bogged down too? Without the wider picture, it’s easy to believe that my problems stem from personal inadequacies rather than project-level failings.
But I think it’s more than that. There’s something deep within the way we think about projects that inhibits us from identifying and calling out incipient failures. There’s a problem in the way we define success.
We play mind games with ‘success’. We define it in multiple, contradictory ways. This then makes it almost impossible to recognise failure. (A good thing if you’re trying to avoid blame; a bad thing if you’re trying to avoid failure).
For example, most projects I see have about five different definitions of success:
The ideal. The grand vision of what the project will ultimately achieve. We paint this to create good feelings about the impact we will have. We quickly realise the vision is unachievable: an ideal rather than a target. But we still talk about it as if it’s real.
The specification. The subset of the ideal that we’re contracted to deliver. This is defined after painstaking analysis, many rounds of negotiation, much compromise. It may be couched in legalistic documents or as an informal “backlog” of post-it notes; either way, it embeds the target the project was set up to aim for.
Personal goals. The subset of the ideal that each individual team member would like to achieve. It reflects people’s desire to do a little better than their last project. It’s what they want to do to see progress in their career and personal development.
The optimal. The subset of the ideal that delivers most “bang for the buck”. This is what the project’s customer most values. If they get all of it, they’ll be happy. We learn more about it as the project proceeds and we gain information on what’s feasible, what works in user testing, etc. Thus it isn’t defined within the initial specification.
The achievable. The subset of the optimal that can be delivered in the desired timeframe. Ideally, the project would deliver this as quickly as possible, then use it as a platform to deliver the rest of the optimal system in subsequent releases.
Good project managers and sponsors focus on identifying (4) and (5), and hence on steering the project to deliver it. This is their implicit definition of success, even though the official definition may be quite different.
However, even as they focus on the achievable, they keep talking about the ideal. Part of this is habit, part of it is legal, part of it is a desire to keep people aiming as high as possible.
Other people on the project also recognise that (1) isn’t achievable. They probably realise pretty quickly that (2) and (3) are going to be compromised too. However, they have no clear picture of (4) and (5) (no-one’s talking about them), so they’re left with an overall sense of failure.
It’s difficult to talk about this sense of failure. Culture gets in the way. Even if you overcome culture, you start to talk at cross-purposes with project leadership. You’re talking about failure against a baseline of the ideal, but project leadership have abandoned that in order to focus on the achievable.
Talk this way too much, and you’re seen as overly negative. So people learn not to raise their concerns.
And if people don’t raise their concerns, project leadership gets cut off from information. They have no way to recognise when problems grow and start to threaten even the achievable. The project risks drifting into catastrophic failure.
How do we break this cycle?
At one level, it’s simple – start talking explicitly about the achievable rather than the ideal. Accept that scope will change as we learn more. Talk always about real objectives so that people can more easily identify when they’re at risk.
At a deeper level, this is really hard. We play these mind games with ourselves all the time, simultaneously dreaming about the ideal outcome while scrabbling to find a path to the achievable.
Bringing in a Devil’s Advocate or Court Jester can help break our mindset, but only if we’re truly prepared to listen to them. Nonetheless, it’s worth trying.
Of course, the best prescription is: don’t do big projects. Any IT project above maybe £5-10 million (or a lot less in many organisations) is at serious risk from the outset. Break stuff down into smaller chunks and we can get our heads around the likely outcomes with fewer mind games.