Why do information systems fail?

[Prestwich_Blue]

All sorts of reasons. Usually though it's down to a few old chestnuts.

1) The users don't really know what they want.
2) They know what they want but it's virtually impossible to deliver it using the software.
3) They want something pretty standard but instead of using the strenghts of the software and adapting their business processes, they want to re-write the software so it does things the way they've always done it.
3) People want stuff delivered too quickly and/or on the cheap. Therefore corners get cut & quality suffers.
4) The biggest reason, in my experience, is that they don't plan properly. A large information system implementation is like any other big engineering project. For one of those you would need a proof of concept (i.e. proof that it could be done and how), a high level blueprint based on standard and agreed design criteria, lower level component plans that were consistent with the overall blueprint.

It's like building a plane. You need an overall blueprint and then all the components and sub-assemblies can be built in different places but as part of an integrated plan. You wouldn't let one company build the wings and say "Just do it however suits you best" because then the chances are they wouldn't meet the requirements.

 

[Bluemoon115]

All sorts of reasons. Usually though it's down to a few old chestnuts.

1) The users don't really know what they want.
2) They know what they want but it's virtually impossible to deliver it using the software.
3) They want something pretty standard but instead of using the strenghts of the software and adapting their business processes, they want to re-write the software so it does things the way they've always done it.
3) People want stuff delivered too quickly and/or on the cheap. Therefore corners get cut & quality suffers.
4) The biggest reason, in my experience, is that they don't plan properly. A large information system implementation is like any other big engineering project. For one of those you would need a proof of concept (i.e. proof that it could be done and how), a high level blueprint based on standard and agreed design criteria, lower level component plans that were consistent with the overall blueprint.

It's like building a plane. You need an overall blueprint and then all the components and sub-assemblies can be built in different places but as part of an integrated plan. You wouldn't let one company build the wings and say "Just do it however suits you best" because then the chances are they wouldn't meet the requirements.

Cheers, that should give me plenty to write about.

Out of interest, are you a Systems Analyst?

 

[Prestwich_Blue]

All sorts of reasons. Usually though it's down to a few old chestnuts.

1) The users don't really know what they want.
2) They know what they want but it's virtually impossible to deliver it using the software.
3) They want something pretty standard but instead of using the strenghts of the software and adapting their business processes, they want to re-write the software so it does things the way they've always done it.
3) People want stuff delivered too quickly and/or on the cheap. Therefore corners get cut & quality suffers.
4) The biggest reason, in my experience, is that they don't plan properly. A large information system implementation is like any other big engineering project. For one of those you would need a proof of concept (i.e. proof that it could be done and how), a high level blueprint based on standard and agreed design criteria, lower level component plans that were consistent with the overall blueprint.

It's like building a plane. You need an overall blueprint and then all the components and sub-assemblies can be built in different places but as part of an integrated plan. You wouldn't let one company build the wings and say "Just do it however suits you best" because then the chances are they wouldn't meet the requirements.

Cheers, that should give me plenty to write about.

Out of interest, are you a Systems Analyst?

Quaint term rarely used anymore but essentially yes. But I'm not writing your bloody assignment!!!!!!

Generally college IT syllabuses are years out of date. I did some marking for the systems paper of one of the accountancy bodies and it was about 20 years behind the real world.

Another couple for you are insufficient processing capacity, making them slow and unreliable and poor testing and training.

 

[Bluemoon115]

All sorts of reasons. Usually though it's down to a few old chestnuts.

1) The users don't really know what they want.
2) They know what they want but it's virtually impossible to deliver it using the software.
3) They want something pretty standard but instead of using the strenghts of the software and adapting their business processes, they want to re-write the software so it does things the way they've always done it.
3) People want stuff delivered too quickly and/or on the cheap. Therefore corners get cut & quality suffers.
4) The biggest reason, in my experience, is that they don't plan properly. A large information system implementation is like any other big engineering project. For one of those you would need a proof of concept (i.e. proof that it could be done and how), a high level blueprint based on standard and agreed design criteria, lower level component plans that were consistent with the overall blueprint.

It's like building a plane. You need an overall blueprint and then all the components and sub-assemblies can be built in different places but as part of an integrated plan. You wouldn't let one company build the wings and say "Just do it however suits you best" because then the chances are they wouldn't meet the requirements.

Cheers, that should give me plenty to write about.

Out of interest, are you a Systems Analyst?

Quaint term rarely used anymore but essentially yes. But I'm not writing your bloody assignment!!!!!!

Generally college IT syllabuses are years out of date. I did some marking for the systems paper of one of the accountancy bodies and it was about 20 years behind the real world.

Another couple for you are insufficient processing capacity, making them slow and unreliable and poor testing and training.

Not asking you to write it for me, but something I'm looking into that sort of area, and just wondering whether it would be worth going into (is there much work out there), or if I should follow a different path.

 

[Prestwich_Blue]

All sorts of reasons. Usually though it's down to a few old chestnuts.

1) The users don't really know what they want.
2) They know what they want but it's virtually impossible to deliver it using the software.
3) They want something pretty standard but instead of using the strenghts of the software and adapting their business processes, they want to re-write the software so it does things the way they've always done it.
3) People want stuff delivered too quickly and/or on the cheap. Therefore corners get cut & quality suffers.
4) The biggest reason, in my experience, is that they don't plan properly. A large information system implementation is like any other big engineering project. For one of those you would need a proof of concept (i.e. proof that it could be done and how), a high level blueprint based on standard and agreed design criteria, lower level component plans that were consistent with the overall blueprint.

It's like building a plane. You need an overall blueprint and then all the components and sub-assemblies can be built in different places but as part of an integrated plan. You wouldn't let one company build the wings and say "Just do it however suits you best" because then the chances are they wouldn't meet the requirements.

Cheers, that should give me plenty to write about.

Out of interest, are you a Systems Analyst?

Quaint term rarely used anymore but essentially yes. But I'm not writing your bloody assignment!!!!!!

Generally college IT syllabuses are years out of date. I did some marking for the systems paper of one of the accountancy bodies and it was about 20 years behind the real world.

Another couple for you are insufficient processing capacity, making them slow and unreliable and poor testing and training.

Not asking you to write it for me, but something I'm looking into that sort of area, and just wondering whether it would be worth going into (is there much work out there), or if I should follow a different path.

It's certainly worth going into but you'll meet the old Catch 22 of companies usually wanting someone with experience. Best bet is probably the public sector/NHS at the moment as the private sector is a bit dead for obvious reasons. They also tend to be more relaxed about taking on inexperienced people. Once you're in the skills are generally transferable.

The problem is these days that there are relatively few in-house IT departments at big companies. A lot of stuff is outsourced to third parties and a lot of development work goes on in India. So the likes of Accenture, EDS, CSC, Capita are the places to get into if you can. However, plenty of companies have in-house "Change Management" departments, where business analysis lives.

 

[Bluemoon115]

It's certainly worth going into but you'll meet the old Catch 22 of companies usually wanting someone with experience. Best bet is probably the public sector/NHS at the moment as the private sector is a bit dead for obvious reasons. They also tend to be more relaxed about taking on inexperienced people. Once you're in the skills are generally transferable.

The problem is these days that there are relatively few in-house IT departments at big companies. A lot of stuff is outsourced to third parties and a lot of development work goes on in India. So the likes of Accenture, EDS, CSC, Capita are the places to get into if you can. However, plenty of companies have in-house "Change Management" departments, where business analysis lives.

Cheers pal. All you get from careers advice is "So your studing ICT? Why not be an ICT teacher/turor or lecturer?"
My mate goes in..."So your studying business, why not be a business lecturer?"

So yeh, I'll take all the advice I can get, cheers for the help pal.