Five reasons IT projects go wrong

AccountingWEB members recently debated the root causes of government IT disasters and pointed the finger as some fundamental flaws in project specification and management.

But private companies aren't immune from IT disasters - and often for the same reasons.

Continued...

» Register now

The full article is available to registered AccountingWEB members only. To read the rest of this article you’ll need to login or register.

Registration is FREE and allows you to view all content, ask questions, comment and much more.

Comments

Training AND Selling

grahamatgward | | Permalink

Nicholas Fraser rightly says application systems must be "sold" to their users and business managers - and good training, which is well inegrated with the business's and workforce's needs (not quite identical!) should do a lot of the ground work for that.

The real reason this is such a major mistake is that all too often training is a token exercise, seen as a cost to be minimised or avoided by senior managers who have been given a hard sell.

There are too many low quality managers - whether "seagulls" (particularly prevalent in the public sector these days) or bean-counters, take your pick - but the best way for an IT professional to avoid a project failure is to avoid organisations with too many of these duds on the business side.

I recognise and agree all of the other reasons for failure, and would suggest one more - although this may be more of a public sector weakness - pre-committment to completely unrealistic deadlines.

Not Training - Selling

nickyf | | Permalink

I agree with most of the points made but the reality is that people misunderstand what the objective is. Training is teaching a skill. In IT that is usually very easy - especially as the software becomes more intuitive and standard in approach.

What is needed is selling of the solution to the users - demonstrating clearly the value of the change to the user personally and to the company/organisation as a whole. This may just seem semantics but it is not. Using a new system of whatever type requires committment and that only comes with clearly focused selling of why the change should be implemented.

If that sales process does not work/persuade then management committment in forms of discipline are required to enforce the change.

Nicholas Fraser
MD
Sales & Marketing Mentors

PS and long term provider of IT solutions to large and small retailers

IBM taught me

nickyf | | Permalink

Further to my note and Graham Ward's good points. I learnt from the best - IBM. They had a process called a Project Definition Workshop (PDW) which was an excellent vehicle to getting top management committment to a project.

My first experience of this was delivering a solution to Iceland in 1989 - the Iceland management team were so enthusiastic about the process they used to commission senior project managers from IBM to run them for all sorts of key projects - IT or otherwise