The Primary Cause of Failed IT Projects

I agree!!!!!

When they decide how the things "must" works, even when this doesn't answer the end user needs, produces really bad results.

Also, some/most of the times they decide to change the scope of the project during the project without asking for impacts. Or they decide to change the team members.

Or didn't listen the importance of a roadmap

Or another common mistake:

when the team says "we need to do an indepth analysis to identify the detailed needs and real functionalities, we also have to identify how to test, how to resell it, how to support it, who will be the team members... so creating a product" and the answer is "why? your proof of concept works, just develop it!"

I also seen this: develop like in a big team, like its a huge project, like you have an unlimited budget. (so create huge doc, setup dev, QA, stage & prod env., involve 10 persons etc...)  But you only have 1 server and just between 1000$ and 2000$ for your project! oups... something doesn't works here.

I have tons of examples on what to not do... And you resume this clearly: a manager must never take technical / functional / design / project plan decisions.

So you are right, in my life too, managers are the main reason of the failures and frustrations.

Completely Agreed.

Getting an idea of the technical design is okay to gain confidence into the design decision, as many managers grow from a technical background than an organic management background. But dominating technical design as per one's own taste just coz one is in manager's shoes, it a suicidal decision for the project.

One should leave the design on the technical expert, and if the management lack confidence, they can arrange a technical evaluation/audit of the design by an external technical team.

Worse yet (IMO), letting project managers make technical decisions!

I fully agree!

Only some rare projects start with a kick-off meeting or at least a conf call with all relevant teams. In my option that's one main reason why projects fail. Because nobody has all necessary informations...

Yes, certainly one of the principal reasons. Good post, and way to raise awareness.

And when you try to right them from wandering off in the wrong direction, they will probably ignore you. Hence my reason for pursuing Project Management Certification from PMI.org to be able to do the PM work myself legitimately, or to be able to speak the PM's language when the risk of project failure it high.

In my experience, it's not so much managers making technical decisions as much as it is managers making decisions with technical ramifications without consulting the technical people with enough time and detail to come up with a sane answer that is respected. Which I guess is the same thing, technical decision by proxy.

Well, those are the worst, but more common is setting deadlines and scope creep's lack of effect on said deadlines. If I say the project will take four weeks, you give me three, then requirements change that adds another week, and one assumption made at the beginning proves false which adds another week, why hasn't the date changed? I swear people are scared of telling a client that a date has been pushed back.

I totally agree with you...

Yes the above explanation is totally rite...managers should do only management works not the technical works...also they should leave the design to designer/architecture....

I have to agree with the stated resolution.  I also agree with Andrew's statement regarding managers making technical decisions wihout consulting techies.

I have been on some projects that went extremely smoothly . . . although those seem to be more and more rare these days.  Lately, I have been finding that I am more commonly on projects that involve someone making decisions regarding how long tasks will take without having any knowledge of what those tasks entail.  Then, when it becomes patently obvious to the least casual observer that the "deadline" is going to be missed, the project manager trades 5 new features for one more week of time.  The net result is rather like borrowing money to pay the interest on a loan without ever paying on the principle . . . the faster the Project Manager negotiates time, the behinder the project gets. ;-)

Managers who involve their technical staff (and then make an allowance for the fact that techies are usually a bit overly optomistic ;-) generally seem to bring in projects without the project becoming a Death March.  However, a very key factor is not only keeping the client/end user in the loop and appraised of progress and problems but also having the intestinal fortitude to stand up to a client/end user who is making unreasonable demands regarding deadlines.

Actually I tend to find the problem isn't that they try and make "technical" decisions so much as political ones.

Things such as stating the manpower and time-scales up front before consultation, overcommitting to projects and deadlines and then choosing to block any negative news in progress reporting to their superiors.

Occasionally certain managers try to get involved in a lower level of detail than necessary and cause the problems you highlight but they are outnumbered by those who simply never bother to delve low enough.

Which type they are is almost entirely correlative with their background, often the delvers used to be technical in some field or another but are horribly out of date.  They normally have kept abreast of the latest fashionable and good sounding ideas but have no grasp on whether such ideas are applicable or feasible.