Why Project Fail

Projects fail, at an alarmingly high rate, and there is a never-ending debate as to why they do. There is a list of core reasons touted as to why they fail and recent debate in LinkedIn seems to be focused on whether these are causes or symptoms. I think this is the wrong question.

If a project fails because of poor planning, is that a cause (“it’s a bad plan”) or a symptom (“it’s a bad plan because the project manager is inexperienced”)? Cause or symptom, the net effect is still the same: a project fails.

As a veteran project manager, I had spent a number of years rescuing failing projects and I would agree that the touted list of core failures does indeed contain quite common reasons for project failure. The reality is however, that the answer is rarely found by ticking off a checklist. Project failures are complex subjects and need to be approached accordingly. When reporting on a failing project, I prefer the term “findings” instead of causes or symptoms. Nice and neutral: neither negative or positive: no accusations. The real value is in asking the question ‘why?’. WHY is it a bad plan? WHY did it not deliver? WHY was so much spent for so little return?

There is no one reason why projects fail, but if I was pinned to suggest just one, I would say ‘people’! There are already many very good methodologies and processes out there that will help a project succeed and, all else being equal, will achieve the objective. But there’s the rub. Things are never equal. The over optimistic project sponsor who believes you can get a lot for very little; the over zealous project manager who lacks the experience to understand where the pitfalls lie; the constant tug-of-war on resources to also attend to their day job; and on and on. In short, people deciding to do things without understanding the consequences. And the higher the position of that person in a hierarchy, the greater the propensity for catastrophic consequences.

You can’t always mitigate the impact of forceful personalities. I remember a colleague telling me that, in the early days of his career, when trying to convey the problems to a sponsor, he started a sentence with “the reality is …”, when the sponsor interjected with “reality is not an option”. It may have been hyperbole on the sponsor’s part or just downright stupidity, but the problem was clear. It can sometimes be quite hard, especially for inexperienced or junior project managers, to manage upwards successfully. Fixing a failing project is rarely a matter of plugging a hole in a leaky dam. There are items which “cause” a project to fail, but they are also quite often “symptoms” of a bigger underlying problem.

Since I gave one key word for failure, perhaps here is one for success: ‘systemic’! Getting everyone involved in recognising that a project is an integrated system and EVERYTHING is related. Knowing that you cannot change something without having an impact on everything else. So, while the junior project manager may not be able to grandstand the project sponsor, perhaps being able to demonstrate the cause and effect of a decision may go some way towards mitigating the issue. Identifying and demonstrating this systemic relationship is where a good methodology shines.

However, I am not so naive as to suggest that simply applying a methodology would solve all problems. Quite the opposite. Instead, I suggest that recognising the volatile conundrum of people in our projects will bring us closer to seeing where the potential pitfalls are, as will adopting a more pliant approach that conciliates the variable that is people. As they say, every project is unique, so our approach needs to be equally so.