Top 10 reasons why IT projects fail?

Information systems (IS), or information technology (IT), have been around for over 50 years. The goal of most IS or IT efforts has been to effect change and improvement in business processes and management information. People have been working at this for thousands of years. With all of this experience, we might think that IT work and projects would be very successful if completed on time and within budget.

Too bad. This is still not the case. In the 1980s people were writing that over half (50%) of IT efforts fail. Moreover, among those that are successfully completed, even fewer have resulted in change and improvement. Some recent surveys and one by the authors point to a percentage here of about 30-35% that resulted in tangible, measurable benefits. This is not very good. One disaster story in 2003 was that of a major Japanese bank that had undertaken a major IT project. It was a colossal failure - US$110 million was written off. No salvage. There appears to be little improvement. IT efforts fail often for the following reasons.

1. Issues are detected too late. Management and staff may not be aware of issues or be looking at the glass as “half full.” Here is a lesson learned. Always look at the work as “half empty” — you will achieve more success.

2. Issues are not managed well. Typically, issues are managed in an unsystematic, ad hoc manner. Moreover, different managers and leaders may deal with the same issues in different ways. Inconsistency leads to more problems.

3. Issues are not tracked using the same measurements of both IT in general and IT project management in particular.

4. Experience in resolving issues, doing work, and completing work is not used to improve the management of issues in the future.

5. People tend to make the same mistakes again and again with the same issues. This makes measurement, management, and estimation diffi cult at best and impossible at worse. There are also problems with the traditional system life cycle. Here are some of them.

6. When gathering requirements, it is assumed that users are supportive of the effort and change. This is often not the case. You need to get users to see the need for change.

7. Traditionally, you seek to involve a few senior users (called here king and queen bees). These people are often the ones who are most resistant to change.

8. After the requirements are gathered, users are asked to sign off and approve them. These approvals, as users have learned, are not legally enforceable. We have seen many cases in which users later state that they did not understand or that things have changed. Only with involvement can come commitment to the requirements.

9. Users are left alone, sometimes for months. They have seen no results. The requirements gathering could have generated new ideas, resulting in change of scope.

10. There is often a disconnect between the training and the implementation of the new system and the current business proces. How to get from A to B is not made clear. Many of the problems stem from a lack of understanding of users and business departments.

Summary from Risk Management for IT Projects - How to Deal with Over 150 Issues and Risks by Bennet P. Lientz