IS Projects: High Failure Rate

Introduction

‘To err is human; to really foul things up requires a computer’ – Anonymous.

Many statistics stand testimony to the issue of the high failure rate in IS projects. The Robbins-Gioia Survey (2001) points out that 51% of the projects are considered to be failures, and 46% of the respondents to their survey indicated that their company just did not know what they are doing in the IS project! However, the Robins-Gioia survey concluded that the success and the failure of the software project or an IS project was in the perception of the user rather than in the real performance of the project per se. A similar survey conducted by Conference Board (2001) in the same year also came to a similar result. They indicated that 34% were very satisfied with what they got from the project, while 58% were somewhat satisfied. 8% were unhappy with the results of the project. A recent KPMG survey indicates that the overshoot on the cost is up to 189% happens in most of the projects (Brenda Whittaker 1999). All this indicates weak project management and control and also a high possibility of failure for any of the IS projects taken up. Is this the true scenario?

Project Management Successes in IS

The Standish Group report (2004) indicates that the success rate of the IT projects has been improving over the 1994 – 2004 decade (The Standish Group International, Inc, 2004). Overall success rates have gone up with a better understanding of the projects and project management. This is reflected in every one of the activities connected with project management. The high degree of failure rates in the early days of the IT projects have made the project managers put a thrust on the way these projects are managed, and more scientific project management has come to the fore.

There are many instructions and self-help guides for successful projects. But there is no magic that could be done. Success has been and continues to be hard work and carefully planned work. One of the most successful projects in the UK is the Clearing House Automated Payment System (CHAPS) (RAEBCS Apr 2004) or the Banks Automated Clearing Service (BACS). This exists in most countries. A number of software projects made for the payments industry and for the banking sector have been large and successful. Similarly, a number of large insurance projects have also been successful for insurance companies. Airline reservations work across the world and have been ranked among the top-notch successful projects.

A project is termed successful when it meets the targets that it is destined to meet. During the commencement of the project, specific requirements should have been laid out, and the working of the software at the end of the project and the reports and results it is supposed to produce should also be fixed (Lancaster University Management School Aug 2005). And if the project meets these requirements, then the project is said to be successful. Most of the surveys look at a project as successful only if the project is completed on time, within the specified budget or planned budget, and produces all the expected features and facilities originally designed or planned. When these are met, the project is considered as successful.

Major reasons for the success of an IS project are (Uma Sekharan,2003):

1. The end-users were involved in the project right from the word go. On many occasions, the project had clear deliverables written down. The performance indexes were fixed, and the project team knew from where they are moving to what. Everyone in the project, including the end-users, was aware of the target for the project. Every key performance index that the project is going to improve is identified and measured (Eric Kimberling 2006). And the targeted improvement in the KPI is also to be noted.
2. The project had the clear backing of the management since the management knew what is going to be the gain from the project.
3. The team is well constituted, and everyone knew their job and what is expected out of them.
4. All the stakeholders in the project knew the outcome, and therefore, the expectations were highly realistic.

Project Management Failures in IS

Since the IS project management is more of a visualization work rather than something that can be seen as in the case of brick and mortar construction or in any other engineering fields (IT-Cortex 2007). That is possibly the reason why IS projects fail more than the rest of the engineering projects. In the normal course of work, most of the IS projects are conceived and passed on to the project manager (McConnell 1998). And in the execution of the job, a number of assumptions are made, which in turn could lead to a number of issues connected with the project resulting in a failure of the project.

Most of the failures of the IS projects happen because of the following reasons (Alf Pedersen 2004):

1. Complete requirements were not collected from the users. This arises when users are not involved in the project from the very beginning of the project. This also meant that the users continued to do the thinking process, and no firm commitment on the requirements was ever made. This is the major issue in most of the failures resulting in changing specifications all through the project and incomplete assessment of the scope of work resulting in cost and time overrun.
2. Lack of resources was also found to be a major problem in many of the projects. Resources are not allocated as and when required, or too much control on the resources was taken up. This resulted in the large-scale failure of the project (Karlsen et al. 2006).
3. The senior management commitment is essential for the entire project to go through. However, if the commitment wavers at points of criticality, then the failure of the project is possible.
4. Planning is generally found to be a major casualty when the world of project management starts. Most of the project management tools become redundant over a period of time, and the scheduled work or the tool that was supposed to have been used would have lost its significance or been neglected.
5. Sometimes the project scope is not in line with the business plan of the company and might have become outdated or not relevant for the company at the current point in time.

Analysis

The success or the failure rate of the projects at this point in time is tilted more towards failures. There are more failures obviously from what could be seen from the numerous surveys conducted. However, it should be noted that the lack of project management knowledge and information is the key reason for failure rates in IS projects (Randy Ott, Apr 2002). With more understanding of the project management techniques needed, the number of failures would keep coming down (Thomas Meloche 2006). Our analysis of the situation for failure or success of a project provides us with the following information.

1. Planning is a very critical activity. Every job is to be planned. The work breakdown structure should ensure that every person and every user is involved in the project and his or her ideas and concepts are taken into consideration. Only then a greater performance level can be achieved and result in project success.
2. Documentation has to be done meticulously. This has different connotations during the execution of the project. When the project changes hand or when part of the project is outsourced, a detailed instruction set is required to ensure that the project goes on without any hitch. Secondly, maintaining a project after its completion is critical since over 80% of the time of the project is really spent in the maintenance mode during the product’s life cycle.
3. Every person in the team should have their own responsibilities clearly marked out. One, they should know their job. Two, they should also know what is expected out of them. Only then, the job can be done comfortably and successfully.
4. Project managers should ensure that every milestone is marked, the schedules are clearly updated, and the project is on time every time at every turn in the project. They should also have a clear plan to manage changes that are going to get ushered into the company when the project is implemented.

If these four points are enabled, then the project could easily move towards success. These would essentially boil down to i) Relationship management ii) change management iii) shared vision of the company and that of the project iv) management support and project management v) training of manpower to deliver the best – HR management vi) industrial and interdepartmental communication or in other words business process engineering (Ed Yourdon Aug 2000). All these together make the project management success or a failure.

Conclusion

The above discussion indicates the success and the failure of a project is dependent only on the way the project management is done and not on the IS projects themselves. It is in the effectiveness of the project management team and the manager (Sheila Wilson 1998). The plan and the specifications that were worked out would decide on the success of the project. It is, therefore, important not to generalize that the IS projects are prone to failure; instead, there should be a constant effort to improve the performance of the project management team and, therefore, bettering the overall results realized. This would ensure that the project is completed successfully within the budget and within the timeline, meeting all the requirements that make up the project.

References

1. “2004 Third Quarter Research Report” The Standish Group International Inc.
2. Alf Pedersen, (2004) “Project Management failures: Why projects fail?” Web.
3. Brenda Whittaker, KPMG (1999). “What went wrong? Unsuccessful information technology projects” Information Management and Computer Society, Vol 7, Issue 1, pp 23 – 30.
4. Ed Yourdon (2000) “Success in e-Projects” ComputerWorld.
5. Eric Kimberling (2006) “7 Critical success Factors to make your ERP or IT project Successful”.
6. IT-Cortex (2007) “Failure Rate”.
7. Karlsen JT, Andersen J, Birkely LS, Odegard E (2006) “An empirical study of critical success factors in IT Projects” International Journal of Management and Enterprise Development, Vol 3, No 4, pp 297 – 311.
8. Lancaster University Management School (2005) “Case Study of Successful Complex IT Projects” The British Computer Society.
9. McConnell, Steve (1998). Software Project Survival Guide. Redmond, Washington: Microsoft Press.
10. RAEBCS (2004) “The Challenges of Complex IT Projects” Royal Academy of Engineering and British Computer Society.
11. Robbins Gioia Survey Inc. Web.
12. Randy Ott, (Apr 2002) “Insuring the Success of your Projects” Infotec Conference, Proc. Of. Capstone Consulting.
13. Sheila Wilson (1998) “Failed IT Projects (The Human Factor)” University of Maryland – Bowie State University.
14. The Conference Board Survey (2001).
15. Thomas Meloche (2006) “The Rational Unified Process”.
16. Uma Sekaran (2003) “Research Methods for Business: A skill building approach” John Wiley & Sons. London.