Computer Systems failure

Last Friday, I spent about an hour at a Government Department that shall remain nameless conducting a transaction which ordinarily should take a few minutes.

After the clerk who was assisting me found my record on the department’s computer database, she typed the information relating to my transaction into the system. She then opened a large book and wrote exactly the same information that she had just entered into the database in the neatly ruled book. She then wrote a receipt, again rewriting the information relating to my transaction. {{more}}

Ideally, the information relating to my transaction should only have been entered into the system once, then a receipt printed.

About a year and a half ago, the last time I visited that department, a similar thing happened. At the time, I assumed that a new computer system was being introduced, and as is standard procedure, the new system was being used simultaneously (in parallel) with the old manual system as a means of testing the new computer system to ensure that it had no glitches before discontinuing the manual system.

The period of testing during which systems run in parallel is usually clearly defined and is never for a very long time. Once it can be verified that the new system captures and correctly processes all the data it is required to, and there is a reliable back up system in place, the manual system is usually phased out.

I was therefore surprised to see the two systems still being run in parallel almost two years later. Most of the time, a decision is taken to computerize a manual system to increase efficiency and save money. In this case, it would seem that the opposite has been achieved.

Using both a manual and computerized system for an indefinite period is a drain on resources. If there is a deficiency in the computer system, and the decision makers do not have confidence in its ability to capture, process and safely store the department’s information then the computerized system should be shelved until the problem is fixed.

Failed computer systems are nothing new. As a matter of fact, studies show that forty percent of information technology application development projects are canceled before completion and thirty-three percent of the remaining projects are “challenged” by cost/time overruns or changes in scope. CIO Magazine estimates that failed and challenged projects cost U.S. companies and government agencies an estimated $145 billion per year.

For example, in 1993, the Oregon Department of Motor Vehicles (DMV) embarked on what was to be a 5-year, $50 million project to computerize its paper-based records. It was estimated that this project would allow the DMV to downsize its workforce by one-fifth and save $7.5 million annually. Two years later, the five-year project’s completion date crept to 2001, and the estimated budget ballooned to $123 million. Finally, in 1996 a prototype was rolled out, but according to published reports, “the system was fired up on a Monday, and by midweek the DMV test office had longer lines than ever backed up around the block. The new system was a total failure.” State officials killed the project soon after because of public outcry. The only downsizing the DMV saw was the officials who oversaw this project.

Information System Projects fail for many reasons. Some are doomed from the start because developers fail either to properly assess users’ needs or to accurately define the project’s scope or both. After the project starts, mid-course project changes can also lead to cost and time overruns. Other common causes of project failure include loss of backing of the people in authority, choosing the wrong infrastructure and lack of people with appropriate skills. Many times, the “computer experts” working with the project choose technology they are comfortable with but which may not be the best solution for that particular situation. If you don’t have the right skills for the project, hire them.

It is sometimes possible to turn around a failing project but we have to be able to recognize the symptoms of impending failure. One frequently overlooked symptom is missed deadlines, budgets and other deliverables. Once the project begins to miss agreed-upon milestones, watch out. Attention also needs to be paid to unresolved issues and miscommunication that develop regarding the project.

When the warning signs are recognized, the project team needs to go back to the drawing board and review the project’s budget, time line, scope and deliverables and see what adjustments need to be made. Sometimes the project team itself is the problem. Many IT projects fail because basic project management procedures are ignored.

Sometimes however, no matter what remedial action is taken, project failure is unavoidable. It is therefore necessary at the very beginning of a project for the project sponsors to set down the conditions under which the project would be shut down. That condition is usually when projected costs far exceed expected business benefits. The unfortunate thing is that in the majority of cases the possibility of failure is not considered until it is much too late.