Most common reasons why projects fail

Post date: Nov 30, 2013 5:04:35 PM

1. Lack of clear requirements - As always, we need just a system tomorrow which does everything we need. We don't even know what those things are, but it needs to fulfill those. Leads to scope creep.

2. Incompetent team - They don't have any kind of clue how hard the project is going to be. usually this is directly linked to the first factor. Because if customers team would be competent, 1st step wouldn't fail.

3. Management did not commit to the project - That happens all the time, 'someone' will take care of these things at 'sometime', but there's no clear resources allocated to the project. As guessed, it will lead to failure because someone is doing something, some day. Or maybe not? Leads to project resource starvation.

4. Service / software provider didn't give enough consultation to the customer - Well, that's true. Some customers simply say that they do have competent team and they don't want to pay for consultation. As far as I have seen, this has always lead to failure. As well as it leads to the situation where provider only acts on clear actionable requests, which are hard to make if you don't pay for consultation, you don't know what you need and your team is totally incompetent. This is not exactly the same as lack of management commitment, but usually leads to similar kind of end result.

5. Lack of change management - Yes, that's true. But what change management we're talking about, initial requirements can't change, if there are no initial requirements other than that it needs to work. So actual requirements and endless changes to those will follow.

6. Lack of end user / client personnel training - Same thing applies here than to 4th step. Customer doesn't want to pay for such services, they just assume that everything is provided and users somehow magically can use the system. But that's a fail. After all training clueless people who don't know what they need, is going to be quite much waste of time. So there should be plenty of resources reserved for this. Based on previous steps, this also means that some of the things that should have been initial requirements, start popping up at this point. - What, it doesn't do X, but we assumed ...

7. Failure to communicate - Of course there will be failure. It's really hard to find language which is understood by both sides, because failure of 2nd and 4th step. Things keep revolving around because nobody understands what they really need, because they don't even know it by them selves.

8. Stakeholder is not part of project core team / management. This usually leads to situation, where customer wants to get all kind of it would be nice to have stuff. Which usually leads to the situation, that if step 1. is done properly (rare), the cost of project will be after all so high that the stakeholder will cancel it before it really starts. Simply put, people planning the project goals and requirements, aren't the people paying for it. This also is one of the main reasons why public sector projects are often so silly. I don't want to do this task monthly, which would take me 5 minutes. But I don't really care if automating this task will cost more than my year salary.

9. Of course all of these steps combined to lead situation where estimations are inaccurate and there's huge project risk to both parties. - I have said simply no, to many projects, where all of this is evident from the very first meeting.

10. Fixing the wrong problem - This is so evident even in smaller software projects. There's problem X and it's fixed in a way that fixes just the X but doesn't fix the underlying reason for it. Utilizing the five Whys would help a lot.

11. Excess complexity - Customer wants system which is so complex it vastly exceeds their organizations capability to manage things. This is mainly linked to 2nd step. During the design, people struggle to understand what's required, complexity grows enormously. After everything is barely working, project is declared a success and complete. It doesn't take a long, until customer has huge problems with the system. They don't understand how it works and they don't have nearly necessary skills and competence to find out what's wrong with it. This usually starts different kind of project technological dept growth. Where people 'find a way to get it done', even if it's not how it was originally designed to work and this leads to further problems. After a while, project is mostly discarded and only parts of it will be used which seem to somehow keep working. This process can be accelerated by key personnel changes, where silent knowledge how things should be done is lost. - Just KISS, use very basic system which just delivers what you need, don't create a nuclear plant to heat up your sauna. It will be hideously complex and expensive thing to maintain operational.