Comments on: Why do IT projects fail?-3

By: robert stewart

robert stewart — Mon, 14 Jul 2008 15:55:20 +0000

There are several reasons for project failure. The most obvious and sometimes overlooked reason is that the project does not follow the first rule of engineering, the KISS rule or Keep It Simple Stupid, of course this is normally taken care of in the discovery aspect of the project, but you would be suprised in the number of projects that get started without the proper discovery in place. I have also seen projects fail because there is no one person who takes ownership of the project. With no Owner, MGR of the project there is no one accountable to see if things are getting done and if they are correct. I work in an IT dept. for a company with 16 remote locations across the United States with over 500 Active
Directory Users, our IT staff totals 10 and 5 of these are in house programmers. Our programmers are constantly putting out fires instead of working toward the future, the reason they are putting fires out all the time is the initial discovery and scope were not completed correctly. The best course I ever took was a class at our local community college and it was Systems Analyis and Design. It pretty much covers everything that has been said in this post.

By: kevinbeaver

kevinbeaver — Mon, 14 Jul 2008 14:36:01 +0000

Most IT projects fail – like most human communications fail – because of unset expectations. Not getting *all* the key players on the same page by properly communicating what’s going to take place and who is to do what. It really can be distilled down to that.

By: jaideepkhanduja

jaideepkhanduja — Fri, 11 Jul 2008 10:15:38 +0000

Project fails only when they are allowed to fail…

By: tatworth

tatworth — Tue, 25 Oct 2005 08:22:30 +0000

For me, the definitive answer regarding programming is in “The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition (Paperback) by Frederick P. Brooks ” ISBN: 0201835959.

Whilst written some years ago, all of his comments (and all but one of his predictions) remain true today. (The only exception is that more powerful PC have allowed a working intellisense.)

By: carlosdl

carlosdl — Mon, 17 Oct 2005 14:52:50 +0000

dbrazeau1024 asked for examples…
We developed a few years ago, a project for inventories control, in response to a requirement from the Administrative Manager.
He requested that it was not allowed to make certain transactions, if the user had not made certain procedures in the system; which sounded logical, but, to save time, a thorough study was not made of how this would affect other areas, one of which had such amount of operations, that it had been impossible for them to fulfill that requirement.
When the solution was presented, the affected area rejected it, with reason, and was necessary to make great modifications so that the system could work.
What was the main reason of the fault?
the request was good, and would allow a better control, but it was not operationally feasible. The feasibility study had not been made.

Thanks,

By: carlosdl

carlosdl — Mon, 17 Oct 2005 14:09:19 +0000

Talking about software projects, I think that analysis is the most important phase of the lifecycle, and the resources (time and people) assigned to it are frequently insufficient, or in some cases this phase is omitted. Note that analysis does not only include the requirements and the process analysis, but the technical, economic and operational feasibility. A bad analysis may result in project “failure”.
Estimation (time, costs, resources) and planning are basic steps as well, and the plan must be flexible and it must consider all the possible problems that can arise, and the concrete solutions for each one of them. Project management is vital for success.
This takes time, but reduces (not avoid) the failure risk.

Regards,

By: dpwoody

dpwoody — Mon, 17 Oct 2005 13:23:40 +0000

An IT project fails because :-
The scope was wrong
or the budget was wrong
or the timescale was wrong
or the resources were inadequate
or the infrastructure was inadequate
or the solution was wrong
or the testing was wrong
or the implementation was wrong
or the training was wrong
or the users weren’t involved
or the users manager wasn’t involved

An IT project succeeds because :-
The scope was right
and the budget was right
and the timescale was right
and the resources were adequate
and the infrastructure was adequate
and the solution was perfect
and the testing was perfect
and the implementation was perfect
and the training was perfect
and the users were fully involved
and the users manager was fully involved

It’s a wonder that any IT project succeeds!

By: w860098

w860098 — Mon, 17 Oct 2005 12:17:30 +0000

Surely one of the fundamental problems with IT projects is that one basic stage has probably been omitted (because top management is afraid of the possible consequences).
The initial stage of any big project should be to undertake a complete process analysis exercise, i.e. look at and document all of the current business processes (in all the affected departments), and then analyse them – in most cases it should be possible to rationalise those and dramatically reduce the complexity of the desired solution. It is only AFTER that stage has been performed that consideration should be given as to what form of IT application(s) will best suit the new revised business processes.
Of course the big implication of this approach is that there will be changes in the activities of various staff members. Ideally this needs early management involvement to ‘sell’ this new approach to the staff, i.e. the need to justify why such changes will actually be advantageous to the organisation and hence to the (majority of) staff.

But, hey, that could be awkward for managers to deal with, so let’s skip that stage all together !!

By: gfriedrich

gfriedrich — Mon, 17 Oct 2005 09:50:50 +0000

IT Projects failo because they’re treated as though they were pure IT projects. Almost all IT projects require change. That requires people to understand, value and accept them. Just training on how to be a good “user” isn’t enough.
“Ready, willing and able” starts with “wanting to”. The history of most past IT projects doesn’t help, so you start with an orgaization’s hope “that this too shall pass” leaving you behind before you start.
No one trusts the “value statements” anymore based on past promises made and not kept. “What’s in it for me?” becomes the predominant test question and it better be godd and more credible this time than last.
The single best strategy to succeed is to start with the informal leaders in the organization and getting them to help you plan how the new system could be implemented best, listneing to them and keeping them convinced throughout the project that this is really best for them and their constituents. Sound easy? it isn’t! That’s why IT continues to try to ignore the reality of what an IT project really is- People changing!

By: worrab

worrab — Mon, 17 Oct 2005 06:29:29 +0000

Would I be correct that you’re questioning why IT projects fail more often than other more concrete projects? Here are some of my favourites:

1) The project is running over budget so someone high up in the organisation decides to bring it back to budget by reducing the scope. Trouble is, they don’t know/haven’t read? the reasons for the bit they draw a line through,

2) Government ministers love HUGE projects. The bigger the better – there’s soo much prestige attached to spending billions of dollars on systems that will integrated everything and do anything that anyone wants. So lets call in a gazillion consultants (who on occasion seem to be worse than useless) and make this thing zing. Trouble is that the big bang simply doesn’t happen because the huge system fails to take account of the everyday (small) needs of average users.

3) Scope creep. Sigh. If I had a dollar for every time somebody thought that this project would be an ideal opportunity for doing that (often unrelated) function…

The top and bottom of it is, I believe, more subtle though. When I build a wall, I drop the foundation in according to the design. If the design is right then the foundation is right…and if the foundation is right the wall will stand up and if the wall stands up…

With IT I have never (never, never, ever, ever) discovered an organisation that is willing to spend the time to design a piece of software thoroughly. If such an organisation did exist, then I believe it will be producing software that is years out-of-date. It’s the very speed of IT development that means that IT professionals have to be fleet of foot and constantly implementing newer (and sometimes better) ideas. And it’s the same speed of development that makes IT projects significantly higher risk than other more concrete implementations.