why do projects fail

[sbegum]

many IT project fail, can anyone share their experience of something IT related how its been successfulor unsuccessful.

 

Why do you think many IT projects fail?

[glennda]

The people behind them don't have time - or they change there mind in what they want to do

[jinnantonnixx]

No clear goals and feature creep.

 

"It would be nice if it did this as well..." just before release is not a good phrase to hear.

[elsiegee40]

I've been in IT for nearly 30 years. Projects invariably fail due to poor planning, i.e. Failure to plan thoroughly enough, failure to anticipate potential issues and/or failure to budget properly for time and cost.

 

If the planning is done properly and appropriate levels of finance, time and manpower with appropriate skills are included the project should succeed.

[theriver]

Gosh, this one could run and run ;-)

 

Er, off the top of my head:

 

Lack of engagement or representation from the user community

 

Disconnect between user requirements and system capability (see also: planning, above)

 

One that particularly annoys me is IT defending their turf instead of attempting to be useful to the organisation

 

Also - people attempting to introduce technology instead of finding the root of problems. Beware of the management type who tells you that you need to install Sharepoint to fix all the communication problems rather than start by trying to figure out what the communication problems are and then what processes and tools might be used to fix them. Related to this is attempting to introduce the wrong tool for the job (e.g. everyone's favourite database application, Excel).

[broc]

failure to engage with the end users & understand requirements... followed by scope creep

 

technology led solutions rather than requirements led...... e.g let's buy iPads & then decide how we might use them......

 

unrealistic timescales.... often working backwards from end date.......

 

no contingency

 

underfunding

 

lack of resource

[Meldrew]

In my opinion, the answer is usually BT. If they are involved, the project will likely fail.

[pete]

Lack of communication (or too much communication - hours of pointless meetings).

Disconnect between expectations and causality.

Not understanding the "Good, fast, cheap - pick two" statement (or variations thereof).

Poor planning for the future:

 

Or rather, this (and variations thereof):

 

[Earthling]

I've been in IT for nearly 30 years. Projects invariably fail due to poor planning, i.e. Failure to plan thoroughly enough, failure to anticipate potential issues and/or failure to budget properly for time and cost.

 

If the planning is done properly and appropriate levels of finance, time and manpower with appropriate skills are included the project should succeed.

 

+1 for planning.

[psydii]

It's often the interfaces. (well, sometimes it is incompetence as well)

 

Project Management->Customer (poor understanding of requirements, feature creep, mismanagement of expectation etc)

Project Management ->Operations (poor understanding of either role's needs by 'the other side')

Or the Ops team trying to be the ops team, the dev team and the PM team, as well as 'customer'. Without the boundaries it becomes harder to monitor the project.

In-fighting within the various teams. Personality clashes, and differing priorities of individual stakeholders.

 

In my experience PM's don't give a monkey's what happens after they have handed over a project, and therefore don't want to know about it. I have, though, found that those that do pay attention to what the customer is intending to do post handover often make better decisions during the little crisises that inevitable pop up during planing and implementation.

 

I've never seen money as an issue in a project - it's pretty simple(*) to make sure you have enough available before you start, and if you don't make sure that a very senior manager has signed off that they accecpt they haven't given you enough money. :-) If the case is made for the project and it has been accepted that it is required, then the necessary money has to be made available otherwise the project will fail. Make sure that some one more senior signs for it. Or don't do it

 

Then there is the the technology itself - sometimes it is the problem. Look at the problems and mistakes people made with Windows 2000, XP, Vista, 7 by trying to deploy at scale before SP2 was released, or early 'n' adopters.

But in general uncovering post sp1 bugs takes a scale deployment and live use - in an edu environment you are unlikely to have the budget to basically do it twice, so you trust the tech (after initial testing) and either continue to push ahead or work around problems, or fall back to your contingency plan. Either way not a success, though if you stay on pathways outlined in the project contingency planning, it isn't exactly a failure either. Look at SIMS.NET ten years ago (it took to 2007 before it wasn't the bain of everybody's lives), or Progresso today; I wouldn't want to have been the project initiator anywhere that was trying to bring them in, but today SIMS.net is the gold standard)

 

Finally there is Training - allocate enough and appropriate training for the various class of end user. Here a needs analysis is required first. Just guessing, or asking for self evaluation will lead to pain. I recently told someone who has self evaluated as 'average IT skills' to copy all her work from her USB to her Documents... response: 'How do I do that' She was on on our list of urgent problems to solve because in SMT's view "The unreliable IT (implicitly: that you put in) was letting her down".

 

(*)write down what you want to achieve, list the deliverables, list the steps required to realise each deliverable, look at the steps and draw up a check list of resources (manpower, time, space, equipment, training etc). Confirm cost of each. Give SMT the figure and say 'no contingency accounted for please allocate std % contingency to this project and don't quibble when we need it'. I'll be honest I'm pretty bad at the 'time' part of this. But then again this is actually a recipe for the Ops team to play at being the PM team, which I've already said can be a cause of the failure.

Edited September 28, 2012 by psydii