First of all, I absolutely agree with Bob’s points. I had a few additional thoughts:
+ A very basic reason for project failure is that it does not follow any formal project methodology, which, sadly, is true in too many organizations. Not folling project metholdogies will allow just about anyting to derail any project. It is harder to get a project derailed if a formal methodlogy is used.
+ A slightly different take on Bob’s 1st bullet is projects will get derailed if the requirements are not fully vetted and understood by all parties, and, most importantly, have senior management buy-in.
+ My last poiint is that many projects get derailed becuase there is no project change management in place, which allows scope creep.
That’s my two cents….Ken
I’m a little puzzled – I answered this the other day, and nothing ever showed up – which is why (I’m guessing) that you reposted. If you didn’t repost, then perhaps someone at TechTarget reposted for you. Puzzling either way.
Anyway – here’s a copy of my original reply.
Perhaps I should stand aside while the floodgates open…
Be prepared for many, many responses to this. Personally, I’m looking forward to collecting some more war stories from other folks. Meanwhile, I’ll offer some high-level generalizations, each of which cover much ground below. You’ll notice that there’s room for a lot of overlap – but I call them as I see them.
1) Projects in which the expectations and objectives were never clearly laid out.
2) Closely overlapping 1, 3, and 6 are those which caused “turf wars” within a given organization.
3) Projects which were meant to solve a particular problem, but in which the technical details were either forced on the project team by management (You will buy Brand X, Product Y), or in which vital interactive portions were never researched, but merely assumed to “work out”. I personally believe that the Denver Airport automated baggage handling system was one of these.
4) Projects which were someone’s pet, never wanted, needed or valued by anyone else.
5) Projects which got underway, but then suffered a large change in staff (technical and managerial) which devalued the need or relative priority. Major reorganizations tend to do this as a side effect.
6) Projects where it was politically dangerous (Think CLM=Career Limiting Move) to point out ANY shortcomings to ANYONE because upper management had a vested role or position. In many ways very similar to 3) above, but the key difference being someone’s ego being in the way. This is not the same as 4). Pet projects which are unneeded or unwanted simply languish because no one ever spends time on them except the owner.
7) Projects which threatened some other portion of an organization. Basically they were sabotaged. This is similar to # 2 above, but in the case of #2 participants killed it. In this case, an “outsider” killed it.
8) Projects which died due to simple incompetence on the part of technical and/or managerial staff. This one is last for a reason – I believe it’s the least common of all the others.
Now, let’s all sit back and watch the horror stories roll in.
IT Projects fail because of many reasons, few of them could be:
Wrong selection of product
Wrong people driving it
Wrong implementation partner
No or very low top management involvement
IT project taken as IT project and not management project
I have found that when IT projects fail, the reasons are similar to when a theater performance fails. Both a theatre troupe and a programming group have a number of similarities:
1. Often have a widely different back ground from others in the group.
2. Are very creative
3. Tend to be better read, and more confident in their subject knowledge
4. Usually have a bit more ego than average.
5. Are usually very individualistic.
6. Are more devoted to their “art” than to any one project or show.
7. They tend to get personally involved with their “part” and criticism of ones work is taken personally.
The main failure (IMHO) comes when the entire cast fails to buy into the unified image as set forth by the director. There are often differences of how various parts of the final product should be achieved, and what they should look like when they are done. You will have visionaries who will severely underestimate how long a certain task will take, or how much it will cost. You will have those who are so bolted into one mind set that they will frustrate the creative efforts of others. I have only worked on a few software development projects, and even those mainly as hardware and network support. One place had a sign that hung on the wall in on of the development “cube farms” I liked it:
Direct and to the point