Discussion on:

Six types of IT project failure

http://thedailywtf.com/Articles/What_Could_Possibly_Be_Worse_Than_Failure_0x3f_.aspx

on why the rush to completion is often accretes failures.
Rings pretty true as well, like the author I hope I'm at least making new mistakes.

I see this in a lot of development and "enhancement projects"

A solution looking for a problem as my previous supervisor used to say! Basically it is the development organization with no governance.

I would add blind trust in technology and the esoteric arrogance of developers. Also, inability to address conflict due to over-dependence in teams, which leads to a "groupthink" mentality.

Another one that I have experienced personally is when the [purchased] technology solution doesn't deliver the results the vendor promised. This is especially true when you're an early adopter, and you don't have much, if any, other customer feedback to draw from, or your environment is different from most others.

A couple more things that can cause failures include:
1. TOO MANY FINGERS IN THE POT. The project leader needs to understand all aspects of the project and manage the inputs to the project.
2. MANAGEMENT APPROVAL. Top down approval is needed for a project to be a success. If you go with bottom up, you end up with staff members controlling the project direction and it gets completely out of hand.

Failure by Politics:

When the fix is in, the best solutions be damned. More often than is noted, conflicts power and control vectors are an important cause of a project going nowhere. It sure feels like failure to the consultant while red herrings are reported.

The worst situation I was involved with was the old syndrome known as "the moving target." One meeting would enumerate and clarify project goals, and though I'd return to my desk with a clear idea of how my module was supposed to perform, that definition would invariably and profoundly change at the next status meeting. My protests were met with charges that I didn't take notes or took them erroneously, and that nothing had changed. I soon learned to keep my mouth shut and just make the changes, but this was the norm, not the exception.

That project of course failed, and unsurprisingly the company did as well, but I was long gone by then. After several incidents like that, I accepted the next decent contract offer.

These failures are all valid but differences exist if the project is company-defined staffed by company IT, vs. packaged solution staffed by solution vendor/contracted implementor vs. custom software consulting firm. But there are two other types of failure not listed that are common to all. First is Customer Expectations Failure, the failure of the acquiring stakeholders to to adopt reasonable expectations despite the information received from implementators (many times the messenger gets unfair blame)
Second is Expectations Setting Failure, where the third-party vendore,contractor, consultant over-promises or ineptly allows the customer to buy into an exaggerated or accelerated vision of what is doable within the proposed timeline. Uusally this happens when there is a lot of pressure to win at the proposal stage. Then, of course, the development partner cannot reel that big fish back into line during the execution phase.

The ultimate cause of project failure is simple: failure to spend adequate time in the beginning planning the project. If you don't take the time to define the project 100%, determine the high-level risks, document the requirements at a high level, complete a Work Breakdown Structure, and create a viable schedule with realistic durations IN THE BEGINNING OF THE PROJECT, then the project is doomed no matter what!

All project fail from a "technical" problem (typically it requires more resources to solve that financially foreseen or acceptable). All technical problems are benign unless there is a political answer given to a technical problem (see Tchernobil - technical failure due to political pressures).
For e.g.:
- The customer politically decide to not deliver the whole technical information in order to obtain a lower price offer (asking for a turnkey application but avoids to specify that they need also the computers)
- The manager decide not to provide the predicted number of persons or the proper competences to the project because they are needed on another project, politically more important
- We won't say or want to know that the things are going wrong, because we don't want troubles or because it is not politically correct to embarrass some important person that may be wrong
- And so on ...
In order to make a successful project:
- Technical issues must have technical solutions.
- Financial issues must have financial solutions.
- Political issues must have political solutions.
In real life it is impossible to totally avoid them mixing.