The Misery of IT Projects. Why IT Projects Fail

Table of Contents

Table of Contents

List of Figures

Acknowledgements

Abstract

1 Introduction

2 IT Project
2.1 Definition
2.2 Characteristics
2.3 Environment

3 Project Management
3.1 History
3.2 Definition
3.3 Tasks
3.4 Project Management Triangle

4 Failure Statistics
4.1 The Chaos Report 1994
4.2 The Chaos Report 1998
4.3 The Chaos Report 1994 - 2004

5 Causes of Project Failure
5.1 Incomplete Requirements
5.2 Lack of User Involvement
5.3 Lack of Resources
5.4 Unrealistic Expectations
5.5 Lack of Executive Support
5.6 Changing Requirements and Specifications
5.7 Lack of Planning
5.8 No Longer Needed
5.9 Lack of IT Management

6 Case Study: FBI's Trilogy Project
6.1 Chronicles
6.2 Reasons
6.3 Conclusion

7 Keys to Project Success
7.1 User Involvement
7.2 Executive Management Support
7.3 Experienced Project Manager
7.4 Clear Business Objectives
7.5 Minimised Scope
7.6 Clear Requirements
7.7 Standard Software Infrastructure
7.8 Formal Methodology
7.9 Reliable Estimates
7.10 Skilled Staff

8 Case Study: Irish Local Government’s Financial Management System
8.1 Chronicles
8.2 Conclusion

9 The Successful IT Project Process
9.1 Initiating
9.2 Planning
9.3 Executing
9.4 Controlling
9.5 Closing

10 Conclusion

11 Bibliography

12 Appendix
12.1 Questionnaire
12.2 Questionnaire Answers
12.3 Glossary

List of Figures

Figure 1: Environment of Projects [10]

Figure 2: Project Management Processes [18]

Figure 3: Tasks of Project Management [10]

Figure 4: Project Management Triangle [24]

Figure 5: U.S. Companies’ Project Costs 1994 [30]

Figure 6: Project Success Rate 1994 [30]

Figure 7: Project Success by Company Size 1994 [30]

Figure 8: Project Success Rates 1994 – 1998 [31]

Figure 9: Comparison of Success Rates and Project Costs 1994/1998 [31]

Figure 10: Project Success Rates 1994 – 2004 [27]

Figure 11: Average Cost Overruns1994 – 2004 [27]

Figure 12: Average Time Overruns 1994 – 2004 [27]

Figure 13: FBI’s Failures Overview [34]

Figure 14: Irish Local Government’s Success Keys Overview [17]

Figure 15: Relation of Project Processes [21]

Acknowledgements

I would like to thank the following people who have been kind enough to help me during the course of my dissertation. I would like to especially thank Andrew Wright for his guidance, Martin McCourt for his advice and my family and friends for their support.

Abstract

This dissertation studies possible reasons for information technology (IT) project failure or success.

In general, projects have a defined goal with clear boundaries and defined resources. They are limited in time, highly complex and run by a specific organisation. In particular, software projects are characterised by complexity, simple modifications, abstraction, technology changes, incomplete requirements and undefined practices. In addition, the environment plays an important role. The key players consist of: senior management, project sponsor, project manager, project team and users. To successfully run projects, a formal methodology is fundamental. Project management involves initiating, planning, executing, controlling and closing.

The Standish Group has proved that IT project failure is common. The Chaos Report publishes facts on failure every two years. In 2004, 18% of projects in the U.S. failed, 53% were challenged and 29% were successful. The reasons for project failure are related to incomplete requirements, lack of user involvement, lack of resources, unrealistic expectations, lack of executive support, changing requirements and specifications, lack of planning and lack of IT management. These factors were also crucial for the failure of the FBI’s Trilogy project. This project consisted of upgrading the FBI’s hardware and software, their communications network and five most important investigative applications. The Trilogy project was 15 months over schedule, $201.3 million over budget and has never been finished.

Other success factors however include user involvement, executive management support, experienced project manager, clear business objectives, minimised scope, clear requirements, standard software infrastructure, formal methodology, reliable estimates and skilled staff. For the successful implementation of Mentec’s AGRESSO Financial Management System in Irish Local Government these issues were extremely relevant. The new system could be distributed to 72 local authorities on plan and within budget.

This dissertation theorises a successful IT project process. Whereas formalised project management practices cannot guarantee an effective project, they only provide for better opportunities to reach the goal.

1 Introduction

"We know why projects fail, we know how to prevent their failure – so why do they still fail?" (Martin Cobb, Treasury Board of Canada Secretariat, 1996) [29]

Today business environments are characterised by complexity and acceleration. IT has played an important role and is one of the most current influential technologies. There are innumerable IT applications, which support and enhance services in business. Companies in sectors such as science, engineering and manufacturing make considerable use of IT. The result is not only in the improvement of productivity, efficiency and effectiveness. It would be difficult to imagine today’s world of work without computers, communications and software. Considering those capabilities of IT, it is disappointing when companies have difficulties with IT projects. In spite of the progress of project management over the past years, IT projects often fail.

The purpose of this report is to investigate the most frequent reasons of IT project failure. Different factors must be taken into account including the human factor, which determines the project’s result. In addition, key issues for successful IT projects are outlined. My research consisted of surveys, case studies, literature as well as information sources such as the Internet and press articles.

The outcome of this paper should provide the reader with an informed view of the pitfalls and success keys for IT projects. Furthermore, this thesis aims to provide theoretic knowledge of successful IT project processes.

The dissertation opens with an examination and description of an IT project with its key characteristics and environment. I will outline the ways, in which IT projects, with specific focus on software projects are unique.

In addition, it is important to contextualise project management. Chapter 3 Project Management explores this topic. It contains a brief history on the progress of project management. Moreover, I define the term and its content and clarify the tasks and responsibilities of project managers. The chapter concludes with factors that determine successful project management.

Statistics are a further relevant issue. Surveys on project failure over the past years of the noted Standish Group are consulted and explained. It is interesting to recognise the progress of project failure. Although the failure rates sunk over the last ten years, it is alarming how many IT projects still fail.

With the aid of a case study the report points out the key reasons of project failure. I examine the failed IT project Virtual Case File of the Federal Bureau of Investigation. It ran 15 months over time, $170 million over budget and never finished.

After showing the negative aspects of IT projects the paper recommends aspects for project success including vital players and main factors. The case study concerning the implementation of the AGRESSO Financial Management System in Irish Local Government is consulted.

Chapter 9 The Successful IT Project Process describes the process of running a successful IT project. It serves as a model.

The report closes with the detailed conclusion, which has been derived from the analysis of the subject matter with the aid of the case studies regarding the FBI’s Virtual Case File and the Irish Local Government’s Financial Management System.

Note: For the sake of reader accessibility, the pronoun ‘he’ is used to refer to both for male and female people in this dissertation.

2 IT Project

2.1 Definition

"A project is any task which has a definable beginning and a definable end and requires the expenditure of one or more resources in each of the separate but interrelated and independent activities which must be completed to achieve the objectives for which the task was instituted." (Robert L. Martino, 1964) [38]

The following aspects define a typical IT project [10], [13]:

Defined Goal

Before you begin a project, a goal must be clearly defined. A project cannot exist without a concrete target. Therefore, it is useless to realise a project. If the objective is defined you also have to classify the tasks to fulfil it.

Time Limitation

A project is temporary. That means it has a clear beginning and ending. It can take just one week or continue for a lengthy time period. According to a defined duration, a project is not a permanent task and is neither an ongoing operation.

Clear Boundaries to Other Projects/Operations

There must be transparent boundaries to other projects and the day-to-day operations. If not, discrepancies will occur.

High Complexity

A project is a new venture that has individuality. It creates a unique product or service. It is not solely a repetition of previous operations. A project is always connected to uncertain endings and risks.

Specific Organisation

As a project has a defined goal it is also necessary to identify a specific organisation. It is extremely important to nominate a responsible person, or project manager who competently communicates with management. Moreover, a project team must also be named.

Defined Resources

On establishing project definition, you also define project resources. Accordingly, you classify the budget, duration, needed personnel and equipment.

2.2 Characteristics

IT projects (especially software projects) differ fundamentally to other projects. The building trade is one example. The following section is based on [10] and [28] that describe key characteristics, making software projects unique. From these characteristics, it is easier to understand that IT projects are challenging tasks.

Complexity

“Computer programs are the most intricate, delicately balanced, and finely interwoven of all the products of human industry to date. They are machines with far more moving parts than any engine: the parts don't wear out, but they interact and rub up against one another in ways the programmers themselves cannot predict.“ (James Gleik, 1992) [28]

Even a small application can consist of hundreds of line codes. However, the number of lines do not express much complexity. If you determine how software is written, you can better hypothesise what is meant by the term ‘complexity’. Software consists of instructions, which execute the functionality of a program. Examples of these include: save, load and modify data. The data storage does not play any part. This further explains why IT projects are complex. Computer environments can be widespread, which contain a huge number of personal computers, servers and printers connected via networks using different protocols and applications.

Abstraction

Software is immaterial. You cannot physically touch it. It consists of codes, which executed, allows requested behaviour to take place. Codes can only be executed and results can be seen if a definite functionality is implemented. Therefore, software is difficult to measure and assess. The progress of software projects is difficult to recognise. Consequently, it is neither easy to visualise software. You cannot draw blueprints, which are used for building houses. Even if the structure of software is drawn, it is difficult to understand because the structure does not state anything about the functionality.

Modification

Once a house is built, then it is built. To modify it, considerable effort must be expended. In contrast, the term ‘software’ is self-explanatory soft. That means software can be changed at any time. Only a piece of code must be modified. This is necessary because a source code is not usually programmed perfectly in the beginning. Programming is an iterative process. If errors occur it is easy to remove them.

Technology Changes

Many years ago the operating system was command-oriented. Users were satisfied when they created a spreadsheet on their personal computer. Today we edit photos and videos on our high-tech machines. In addition, we are connected via the Internet to the whole world. The rapid change of hardware and software reveals the developers new opportunities. They must also be aware of the quick changes and the impact on the software, which shall be built during a project. The software, the product or service, which is delivered today, can be out-dated tomorrow.

Incomplete Requirements

As described above, software is difficult to measure and assess because of its abstraction. That leads to incomplete requirements. Users understand business processes and developers are responsible for the implementation in source code. Requirement changes occur due to the fact that users do not get the possibility to assess unfinished software. The first time users encounter new software, product or service, they recognise whether their needs were met. Therefore, it is highly challenging to define necessary requirements.

Undefined Practices

Before software can be implemented there are a lot of considerations, which have to be taken into account. Thus, the programming language, the required technology, the architecture and the procedure model must be chosen. Subsequently, it is difficult to make the right decision. There is an immense choice that must be appropriately selected for the project and the environment. The latter is a weighty problem because there is not any comprehensive knowledge relating to, for example, which programming language or procedure model best fits. As mentioned above, technology and programming languages changes rapidly. Therefore, most of the available technologies are not mature enough to be chosen as the best ones.

2.3 Environment

Abbildung in dieser Leseprobe nicht enthalten

Figure 1: Environment of Projects [10]

Figure 1 [10] shows three parties involved in running a project: senior management respectively project sponsor, project manager including the project team and user/ customer.

The senior management is the highest authority and sponsor of a project. Furthermore, senior management supports the project team to ensure that the requirements are met. In order that a project is fulfilled according to expectations, senior management draws up guidelines. These include standards, rules and regulations, which have to be taken into consideration by the project manager. Moreover, the senior management targets project goals so that the project manager is familiar with the demands of the user/customer. That is only possible due to the fact that the users request their needs from senior management. The senior management in return promises to deliver the desired requirements.

The project manager and his team are responsible for implementing the requirements. He plays among others the roles as planner, coordinator and controller. The project manager acts as an intermediary between senior management and project team. The guidelines and goals, which the project manager receives, are forwarded to the project team for execution. Over the entire project progress users and project team interact. The project team delivers the intermediate product on a regular basis. The users request both new and changed requirements. It evolves as a cycle until the product fully meets the requirements. The project team informs constantly the project manager concerning the actual status of the project. That takes place for instance, at weekly meetings and/or with the aid of reports. The project manager in turn forwards the actual figures to the senior management.

3 Project Management

3.1 History

Project management has been around for millenniums – examples are found in the Egyptian pyramids (25th century BC) and the Temple of Salomon (10th century BC). In those days it was necessary to manage and coordinate funding, work and materials to complete these gigantic projects.

The Industrial Revolution during the 19th century saw the needs of business and industry become more complex. Consequently, large-scale, widespread projects such as the construction of the transcontinental railroad were set up. Business leaders were faced with decision-making, managing budget and material and organising the labour of thousands of workers.

In the early 1900s Frederick Taylor started his research on work. In steel mills he analysed that the work had to be split into elementary parts such as lifting and moving parts to improve the productivity of workers. Henry Gantt, Taylor’s associate, created charts with task bars and milestone markers to describe the order and duration of operations in process. He analysed the tasks to construct Navy ships during the First World War. Since then, Gantt charts are powerful managerial tools still in use today.

In the 1950s project management was established as practiced today. The U.S. military started to work with a project management program called PERT (Program Evaluation and Review Technique). Designed by Willard Fazar, PERT charts refer to a critical path methodology that help mangers to control massive projects with complicated tasks and logistics. Today, all U.S. Navy projects make use of PERT. [22], [26]

3.2 Definition

“Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements.” (Project Management Institute, 2000) [23]

According to the Project Management Institute project management is divided into five phases [23]:

Initiating

Initiating a project is the process after the decision is made to run a project. At first, the project manager interviews the different stakeholders such as project sponsor and end users. It is important to identify the needs of the different groups and people. After that project requirements must be defined. The project objectives (time, cost, functionality) are established when the goal is clear and the project team is defined. Afterwards the project chart, which formalises the whole project, should be prepared.

Planning

After the project is formalised, the planning phase starts. Everything, that is broadly defined in the project chart, is broken down into detail. The widespread scope is divided into small parts. Time and costs are clear calculated. Required resources as goods and services must be clarified. Risk strategies should be established and quality assurance should be classified. The identification of responsibilities and authority is also part of the planning. It must be clearly defined who is responsible for what. During this phase it is also important to plan the communication with project stakeholders. At the end of the planning the project plan should be completed with the above points taken into consideration.

Executing

During the execution the project plan is put into practice. The project manager searches appropriate contractors to conclude agreements. In addition, he procures required resources for instance, hardware and software. Work results are created. Changes are identified and performed. The team performance is rated, guided and if necessary improved. Communication takes place, for example, by weekly meetings with stakeholders where information regarding results and changes are exchanged with the aid of periodic reports such as status reports.

Controlling

The controlling process involves the control of the execution phase outputs. The project must be monitored and measured continuously so that changes from the plan can be recognised and countermeasures can be taken. Possible modifications create variances to the project scope, schedule and budget. The changes are documented. Controlling also includes testing of quality and functionality.

Closing

The project closure consists of commissioning, handover and evaluation. The finished product or service is delivered to the stakeholders. All documents as specifications and manuals are handed over. Additionally, needed trainings are identified and developed. In conclusion, the completed project is evaluated for use in planning projects for the future.

Abbildung in dieser Leseprobe nicht enthalten

Figure 2: Project Management Processes [18]

Figure 2 [18] illustrates the project management processes defined by the Project Management Institute.

3.3 Tasks

Abbildung in dieser Leseprobe nicht enthalten

Figure 3: Tasks of Project Management [10]

In all projects the project management has its responsibilities and tasks. They are crucial for the success of a project. The different tasks are shown in Figure 3 [10], which consist of the following:

Setting Goals

During the project initiation, after the stakeholder needs are known, it is essential to set goals. If you have not any goals there is nowhere to go. The goals must be set clearly, without opposition, realistically and coherently. Everybody, who is involved in the project, must know and understand the goals. Only then is it possible to pull together to reach the goals and fulfil the project successfully.

Deciding

In projects there are a lot of decisions to be taken. It must be decided if the desired project is to run or not. This determination is not the only one. During the whole project the project management has the task to decide. For example, the following questions have to be answered:

- What has to be done if problems occur?
- What changes are beneficial if modifications are necessary?
- Should a project be cancelled if it is out of control?

It is important to reach a decision in an early stage and in a comprehensible way.

Delegating

As mentioned above during a project process there are different roles. It is significant that boundaries are set between senior management, project management and project team. The role of the project management is to delegate. The project manager knows because of time and task schedules what when has to be done. His job is to delegate the tasks to the different team members. It should be clear that no one person does everything.

Coordinating

With the aid of different established schedules it is easy to coordinate tasks and align the responsibility to team members. Thus, team members have to know their responsibilities and tasks.

Organising

The organising task is the definition of the order of events and the responsibilities. The project manager has to organise the approach to fulfil defined functions. This part is also known as operational structure. There is the organisational structure, which defines the responsibilities among other things. The organisation of meetings is another task of the project manager.

Controlling

According to the description above controlling contains the control of the execution phase outputs. The project manager must monitor the project continuously in order that changes from the plan can be recognised and countermeasures can be taken early on. Possible modifications affect the project scope, schedule and budget.

Motivating

Motivation is a central aspect of a successful project. If all involved people are motivated, it is easier to accomplish common objectives. Thereby the project manager motivates. In almost every project there are moments when the project team loses drive. In such circumstances, the project manager has to use his skills to animate the team to work to reach the goals.

Communicating

Communication is the exchange of information. It is necessary that projects are transparent. Therefore, the project manager’s task is reporting. He is responsible for the communication between management, project team and user respectively customer. The exchange of necessary information in a compact and clear form is helpful.

3.4 Project Management Triangle

Such as described a characteristic of projects is the limit of resources as time, cost and scope (also quality). The combination of the three elements is called the project management triangle and is illustrated in Figure 4 [24]. The definitions of the elements are the following [19], [20]:

- Time

Time is the deadline, by which the product or service must be delivered.

- Scope/Quality

You have to distinguish between two forms of scope: product scope and project scope. The product scope specifies the quality, features and function of the outcome. In contrast, the project scope describes the work required to deliver the product or service with the proposed product scope.

- Cost

Costs include everything needed to accomplish the project: people, equipment, materials and all kinds of events and issues, which require money.

Abbildung in dieser Leseprobe nicht enthalten

Figure 4: Project Management Triangle [24]

Time, quality and cost exist in interdependency. If you concentrate on one element you affect the others, which translates to:

- Increased time means reduced scope and increased cost.
- Reduced cost means increased time and reduced scope.
- Increased scope means increased time and increased cost.

The key to the balance of the three elements depends on excellent project management.

4 Failure Statistics

4.1 The Chaos Report 1994

The following facts and figures are based on The Chaos Report by The Standish Group [30]. This report is a study of IT project failure, which is published every two years. The Standish Group is the information technology leader in project and value performance and is focused on failure to help companies succeed.

In 1994 the respondents to The Standish Group survey were IT executive managers. The sample includes large, medium and small U.S. companies from various industry segments such as banking, securities, manufacturing, retail, wholesale, insurance, services and local, state and federal organisations. The total sample size was 365 respondents and 8,380 applications. The results are based on research surveys and several personal interviews.

The Standish Group classifies projects into three groups:

- Successful

The project is completed on time and on budget, with all features and functions as initially specified.

- Challenged

The project is completed and operational but over budget, over the time estimate and offers fewer features and functions than originally specified.

- Failed

The project is cancelled at some point during the development cycle.

U.S. companies spend more than $250 million for IT projects each year. In 1994 the average cost of a project for a large company was $2.3 million, for a medium company $1.3 million and for a small one $430,000. See Figure 5.

Abbildung in dieser Leseprobe nicht enthalten

Figure 5: U.S. Companies’ Project Costs 1994 [30]

General report key findings in Figure 6 state:

Abbildung in dieser Leseprobe nicht enthalten

- 16% of all investigated projects have been successful.
- 53% have been delivered but over budget, over time and with less features and functions.
- 31% have been cancelled before completion.

Figure 6: Project Success Rate 1994 [30]

In addition, The Standish Group distinguished the results into large, medium and small companies. The classification is described next:

- A large company is classified as any company with revenues greater than $500 million per year.
- A medium company has a yearly revenue that ranges between $200 million to $500 million.
- A small company is defined as having $100 million to $200 million in revenue per year.

Only 9% of all projects were successful in large companies, in comparison to 16% in medium and 28% in small ones. The highest rate of challenged projects (61.5%) was investigated for large companies, compared to 47% and 50% for medium respectively small companies. 22% of all projects failed in small companies, 37% in medium companies and 29.5% in large ones. Figure 7 shows the results.

Abbildung in dieser Leseprobe nicht enthalten

Figure 7: Project Success by Company Size 1994 [30]

Restarts

The major reason for cost and time overruns is restarts. As the survey demonstrates, The Standish Group investigated that 94 of 100 projects were restarted – some of them several times.

Cost Overruns

The average cost overrun of challenged and failed projects for large companies was 178%, 182% for medium companies and 214% for small ones. The average cost overrun of all surveyed companies was 189%.

Time Overruns

The results of challenged and failed projects included the following statistics. The overall average time overrun was 222% compared to the planned time, which was broken down into 230% for large companies, 202% for medium companies and 239% for small ones.

Content Deficiencies

On average only 61% of the originally defined functions and features were available on challenged projects. Large companies delivered only 42% of the planned functions and features, medium companies 65% and small companies 74%.

According to The Standish Group U.S. companies spent $81 billion for cancelled software projects. They also paid extra $59 billion for completed software projects, which have exceeded the schedule. In addition, they lost opportunity cost at a rough estimate of trillions of dollars.

4.1 The Chaos Report 1998

The following section compares the results of The Chaos Report of the year 1998 [31] with those of 1994.

In comparison to the survey from 1994 the project success increased. In the past only 16% of software development projects have been successful whereas in 1998 26% have been completed on time, on budget and with all features and functions as initially specified. See Figure 8.

Abbildung in dieser Leseprobe nicht enthalten

Figure 8: Project Success Rates 1994 – 1998 [31]

Compared to the report in 1994 large companies mostly improved. Four years ago the success rate was only 9%, it rose to 24%. Furthermore, large companies decreased their project cost from $2.3 million to $1.2 million per project. The success rates of medium and small companies also rose from 16% to 28% from 28% to 32% respectively. This meant that medium companies could reduce their average project cost by $200,000. Nonetheless, the cost of small companies increased by the same amount. Figure 9 illustrates the results.

Abbildung in dieser Leseprobe nicht enthalten

Figure 9: Comparison of Success Rates and Project Costs 1994/1998 [31]

The cost spent on failed projects decreased from $81 billion in 1995 to $75 billion. The cost overruns were reduced from $59 billion to $22 billion in 1998.

4.2 The Chaos Report 1994 - 2004

Over the past twelve years, The Standish Group researched with the aid of focussing groups, in-depth surveys and executive interviews. In the course of these 50,000 IT projects have been studied on project performance in the United States. The following figures show the trend of IT projects from 1994 to 2004.

The overview in Figure 10 indicates that project success rates have consistently increased up to 34% in the year 2002. In comparison to 1994, there was more than a 100% improvement. Standish Chairman Jim Johnson were asked to explain the causes: “The primary reason is the projects have gotten a lot smaller. Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward.” [11]

Furthermore, project failures have decreased up to 15%. Therefore, the failure rate halved compared to the value in 1994. Johnson’s comment: “People have become much more savvy in project management. When we first started the research, project management was a sort of black art. People have spent time trying to get it right and that has also been a major step forward.” [11]

Abbildung in dieser Leseprobe nicht enthalten

Figure 10: Project Success Rates 1994 – 2004 [27]

If you take a look at the statistics, regarding average cost overruns in Figure 11 the improvement from 1994’s 189% to 2002’s 43% is significant. In addition, there has been a great leap forward from 1994’s 189% to 1998’s 69%. The Standish Group’s Chairman gives reasons: “The improvements were the result of our research. On the other hand, we did see in many of our focus groups and workshops after our initial published report that user involvement was up, executive support was greater, and people were clearer on their business objectives.” Another reason “is the Internet. Now with Internet-style development, projects are much smaller, simpler, faster to implement, and easier to manage.” [12]

[...]