There is a thin line when it comes to success and failure of information systems. At least 50% of information systems fail and this figure could even be higher as people do not like admitting failure, so the attention to detail becomes crucial and the risks become grater. Some of the main reasons that seem to be recurring in IS failures are due to risk management, accountability, professionalism, formal training, research, good communications, leadership and ownership. For those who do not know a lot about IS system failures I will put it in a simpler form,a software engineer is similar to a civil engineer. Building a large information system is almost like constructing a 30-story office building. If a bunch of architects, electricians, plumbers, carpenters, tillers and contractors meet in a office room, talk for a few hours and then start building, the building will be unstable if it even gets built at all. “If building engineers built buildings with the same care as software engineers build systems, the first woodpecker that comes along would knock the building making it a failure as the build should stand after storms.
Three Keys to Successful IS Projects
Successful projects are like a tripod and have these factors in common:
1. Top management support
2. A sound methodology
3. Solid technical leadership by someone who has successfully completed a similar project
1. Almost all system success or failures have identified top management support as a critical to the success factor. The management personnel in any organisation that undertakes a systems project should be understand that the project will meet stumbling blocks along the way. They will need to be prepared to keep there composure as there will be setbacks or else the project is set for failure. From my simplified point earlier there is a massive difference between systems projects and office buildings. When a building is half built, there is something to see, but when a software project is half done, there is almost nothing to see. Managers need to know what they can expect to see and when. If they assume that the project will have 50% of the systems running when the budget is 50% spent, they will probably start thinking about giving up on the project that is progressing exactly on schedule.
2.Many systems are built with little thought. The team gets together and as enough information is collected, coding begins. This lack of attention to process can ruin a system. It is easy to see the result of a lack of attention to process after a system fails. Usually parts of the user requirements are ignored. Large amounts of code need to be rewritten, since it does not meet user requirements the first time around. The system is put into place with scarce testing. Without a well thought out process, there is little chance that a systems project will be successful. If the project does succeed, it only does so with substantial rewrites and cost overruns.
3. Like a building needs an architect, software systems needs a technical lead. The technical lead must have built similar systems down to the level of the specific business area for which the system is being built. To be successful, technical lead must be the one in control of the “architecture” of the project, most importantly the data model and application design. This level of control must be recognised and acknowledged by everyone involved with the project.