1 Symptoms: What Problems can be Observed? What Consequences Result from these Problems?

The failure of IT projects has been subject to discussions for decades. For example, magazines report on historical failures of IT projects in the U.S. (Zeitler 2008), consulting firms analyze the failure of large-scale IT projects (Richter et al. 2008), and also science provides detailed studies about failures in selected major IT projects in Germany (Mertens 2009).

Often, the so-called CHAOS report is used as a starting point for such analyses: according to this report, currently 24% of IT projects fail, 44% are considered to be challenged, and only 32% are successful (Eveleens and Verhoef 2010). From the perspective of business and information systems engineering (BISE), however, it is necessary to critically question the findings of the CHAOS report. The definition of “success” either remains unclear, or – if carried out – only the successful completion of the project’s implementation is assessed. However, it is not examined whether the project also helps to achieve the company’s objectives. This debate is not new. Already in 1998, Peter Mertens presented 15 theses in which he ultimately claimed that these analyses should focus on the overall objective of increasing corporate value, and derived what should actually be the proper goals of BISE. And yet there is still no single, accepted definition of when an IT project is to be considered a success. Against this background, the prudent scientist would do well to be careful with such general quantitative studies.

Although the way of measuring success is controversial, it can be observed that still many large-scale IT projects face enormous problems or even fail. The direct and indirect effects are often dramatic and sometimes even threaten the existence of companies, as the following examples illustrate:

  • In the first half of 2004, the supermarket chain Sainsbury’s had to record a profit decline of 88% compared to the previous year, after they failed to launch a new IT system. The new supply chain management system had proved inadequate so that the company had to let employees carry out processes instead of automating them. A total of 791 million U.S. dollars had to be charged off; Sainsbury’s decline to the third place in the British market has been blamed in large parts on the failure of the project.

  • Toll Collect’s approach to establish a new system for track-based toll collection in Germany failed with great publicity effect with the termination letter from the Federal Transport Minister, stating that the offer is technically, legally, and economically unacceptable. This was preceded by months of quarrels due to numerous failures and ever-new delays. The system went live in early 2005 with a total delay of 16 months and limited functionality. On July, 29th 2005 the federal government therefore brought an action against the toll consortium and raised claims of 5.1 billion Euros. The dispute lasts until today.

  • One of the largest IT projects in Europe with an estimated cost of up to 5.4 billion Euros, extensive requirements regarding data volume and protection is the introduction of the electronic health card in Germany. It was originally intended to replace the health insurance card on January 1st 2006 and now is several years behind schedule. The resulting loss of confidence of the public towards politics is enormous. Hence, the Chaos Computer Club summarized a study by Booz-Allen-Hamilton with the following words (translated): “In the best tradition of state-run large-scale software projects, another extremely expensive prestige project is consciously being approached here, the benefits of which are in no reasonable proportion to the risks and foreseeable problems. A first look at the data points to a massive explosion of costs through the introduction of the health card and to another technological disaster.”

Such large-scale IT projects are likely to cause problems in future as well. Both, the increase in IT penetration of virtually all areas of life and their increasing interconnectedness, can be expected to increase the level of IT investments and the size of IT projects. This would also, unless countermeasures are taken, involve a higher number of failing projects, including – as mentioned above – huge tangible and intangible damage. Without a thorough performance analysis, large-scale projects therefore continue to fail. Here, BISE as an interdisciplinary field of research is required to contribute to more success. In a first step, the following questions must be answered:

2 Diagnosis: What are the Reasons? What Typical Challenges have to be Considered for Large-Scale IT Projects?

If a project failure is imminent, often consulting firms quickly provide help with “frameworks” and “checklists” and try to at least partly save the project in cooperation with the project management. They tend to focus heavily on a project-internal point of view and neglect aspects, such as dependencies on other projects and the role of the project in the company. The ultimate failure rate of IT projects is not surprising despite ad hoc measures to save the project. As already mentioned and as many interviews with practitioners show, the reason for the failure of IT projects is a lack of alignment between corporate and project objectives, as reflected in unclear and differing expectations and ambitions of all stakeholders involved in a project. Thus, the core cause is a poor goal orientation, i.e. a non- or poorly coordinated objectives system of the whole company is the “root of all evil” in many cases. Of course, this does not only apply to projects, but very often the consequences are very clear here. One may therefore conclude that with such different objectives many projects already fail even before they start. In summary, the main reason is that questions like “Does the project support the overall business objective?” and “Are all stakeholders aware of this objective?” are neither posed nor answered adequately.

All other complex factors that are denounced as reasons just arise from or reinforce this core problem and can be roughly divided into the four categories of technology, organization, human factor, and environmental changes (which may include, e.g., political influences or competition effects):

  • Technology: Instead of proven and reliable technologies new, non-mature instruments are used. The individual objectives of technology-loving IT decision-makers are given priority over the company’s main objective of increasing corporate value based on return and risk considerations.

  • Organization: Companies do not adequately succeed in “breaking down” the – admittedly abstract – corporate objectives to individual projects. In consequence, a complete preservation of the objectives is not always possible. However, this should be tried in the best possible way; otherwise it would be pure coincidence if a project achieved this. In particular, dependencies between individual projects should be taken into account and the organization as a whole should operate towards the business objectives.

  • Human factor: This factor needs to be considered from the management down to the staff level since the rational, perfect acting person does not exist in reality. Hence, errors inevitably occur – no matter on which company level – which are even intensified by a non-consideration of “soft factors” and a non-recognition of the imperfection at the planning stage. For example, the duration of large-scale IT projects often corresponds in a worrying way to the trend of shorter retention periods of the top management. The mixture of corporate and individual objectives, which is unpleasant from a business perspective, is almost as “human”. After all, who wants to be involved in a major IT project if it is to be expected that – given a successful conclusion – the successor will gain the laurels?

  • Environment: A balancing act between “adapt” (in terms of adaptation) and “adopt” (in terms of replacement) – also this decision must be motivated by the objective system and justified accordingly. Several major projects are motivated by an “adopt” approach: A legacy IT landscape is to be replaced by modern standard software. Objectives, such as independence of the individual – aging – critical knowledge carriers, improved process automation, and future reliability are often cited here. Therefore, the standard should be used as far as possible – an approach that is frequently and increasingly carelessly questioned in the course of the project – which may result in the fact that you end up back in the old “adapt” world, i.e. “tailoring” the (originally designed as easier to maintain) IT system. Attributing this entirely to inadequate requirements and change management does not reach far enough since – as mentioned above – the project objectives have to be aligned with the business objectives first. Only then can meaningful prioritization and thus sustainable requirements and change management take place.

The previously mentioned reasons can a priori also be found in small IT projects. However, these succeed – according to relevant studies – far more often than large projects. What is the reason for this? In small projects, the problems of poorly coordinated objectives do not become evident or appear less strongly. From a “worm’s-eye view”, there are fewer conflicts than in a complex, global world! The result often is that a supposedly “successful” small project does not contribute to an increase in corporate value, but to the wrongly set standards of success of decentralized decision-makers.

Comparing large-scale IT projects with smaller IT projects, one first thinks of the typical factors of time, cost, and functionality:

  • Time: Large projects typically require a long time of preceding actions and have a longer implementation period. Thus – e.g., due to external conditions – often changes in requirements result over time.

  • Costs: Major projects lead to higher costs and are due to their significance more often questioned than smaller, less expensive projects.

  • Functionality: Major projects have a greater impact on existing processes and technologies. They therefore concern a larger group of people (users or project team members with their different objectives) and have more points of contact with the environment.

On closer examination, these factors are not the actual causes, but merely the specification and consequences of the fundamental problem of lacking goal orientation, which – regardless of the size of an IT project – may even increase with the company’s size and type. Thus, there are escalation paths in the private sector (in the form of hierarchy levels) and usually a final decision-maker exists. However, the bigger a company is, the more complex decision-making processes become and the longer it takes until a decision is made. Thus, with conflicting objectives of different stakeholders a project escalation and enforcement of the corporate objective is generally more difficult in larger companies.

While in the private sector the decision-making body or a possibility of taking drastic measures at least exists in principle, this is usually not true for public administration, especially in the case of large projects. Here, we can observe that projects fail as a result of the divergence of objectives of the stakeholders involved. One example is the already mentioned introduction of the electronic health card, where – among others – conflicts between the government, doctors, hospitals, pharmacies, private and compulsory insurance companies and data privacy contribute to a deadlock and thus to a severe delay.

The reasons for the failure of IT projects can rarely be attributed to a single cause. Thus, a scientific, thorough investigation is not trivial. That may be one reason for the prevalence of so-called best practices in place of concrete scientific evidence. Precisely at this point it may be beneficial for BISE to set a major priority on failure research, which has also significantly advanced other disciplines such as medicine and engineering.

3 Therapy: What Kind of Approaches Should and Can BISE Contribute?

From the previous diagnosis we can now derive the overall approach: From a management perspective, it has to be ensured that there is a single objectives system which is transferred to the individual departments or projects. From the perspective of individual IT projects, the alignment of the project’s objectives (including project organization, used technologies, …) to the company’s objectives system is the top priority. This requires the transfer of the objectives system to all stakeholders involved in the project. The actual project success and thus also the long-term sustainable business success depends on the alignment with the company’s objectives. The concrete implementation for achieving improvements is more difficult. Therefore, we now suggest some solutions – without any claim to completeness:

  • Management and governance structures that are currently not sufficiently effective have to be improved for the project implementation phase. In doing so, the image of IT, IT awareness, and IT decision-making competence are strengthened at the level of corporate management. Only if IT investments are managed with more expertise at the border between business administration and technology, we can successfully use financial means in a more reasonable way in the private and the economic sector.

  • It is equally important to better consider the human factor. If small IT projects, which are not crucial for the long-term business success, delay or fail (in part), this is a setback for the particular department, but is manageable from a business perspective. Thus, errors by employees in these projects are more easily manageable. A successful staff development includes providing enough leeway for error, i.e. creating a productive learning and development environment. In large IT projects, which are critical for the company’s continued existence, such “experiments” with the human factor are not appropriate. Similarly, surgeons do not attempt “open heart” surgery on their first day of training, but are gradually introduced to responsible positions. This approach has yet to find its way into large-scale IT projects to a greater extent.

  • In addition, there are direct starting points in typical project situations in order to increase the chances of success. On the one hand, often large and complex lists instead of the proper project management software and methods are used. Studies show that about 94% of all so-called Excel lists or approximately 1% of all the formulas are incorrect (Powell et al. 2009). For example, using network techniques – in contrast to the usually rigidly implemented Excel lists – might help to consider dependencies and interactions automatically in case of short-term changes, such as schedule delays. Likewise, network techniques may also be extended by stochastic elements (e.g., PERT approach) to reduce risks significantly. Thus, the error rate of schedule changes that become necessary in the short term can be reduced. Here, it is required both to more critically question why this condition still holds and to make use of pragmatic, practical methods.

As so often, failures not only involve negative implications, but can also have positive effects if the opportunities to learn from mistakes are seized. Despite all the proposed solutions and recommendations it is expected that also future projects will be “out of budget” and/or “out of time” or even fail. Here, a well-conducted cause analysis often relentlessly reveals points lacking the necessary goal orientation. Thus, the failure may contribute to the fact that these companies will hopefully realize this huge deficit and learn for future projects and many other still more important decisions.

Nevertheless, concerning large-scale projects it is particularly important and correct that BISE intensifies its involvement in failure research. Especially due to its inherent strengths, such as interdisciplinarity, methodological pluralism, design and engineering tradition, innovation strength, and practicality, the field has great potential to contribute to society in this important area. The relevant question is: What needs to be done in general and from the perspective of BISE in particular in order to both promote existing measures to improve the success rate of large-scale IT projects and to take its own role within the project management and strengthen it sustainably?

In practice, BISE can contribute to sustainable business success and competitiveness by supporting companies in the alignment with a consistent objectives system. As a result of its intermediary role between business administration and computer science, the competence of BISE is more sought-after and required in order to close the still existing and mission-critical gap at the border between IT and business departments within IT projects (with procedural and organizational challenges).

BISE should also become aware of its responsibility towards society to a greater extent. By contributing to the successful implementation of large-scale projects it may prevent a loss of jobs and a further waste of taxpayers’ money.

In the (academic) training of its junior experts, BISE should contribute to the successful management of large-scale IT projects by increasing the recognition of its solutions, tools, methods, etc. Hence, the research and training needs for large-scale IT projects represent a key area of action for BISE. Scientific knowledge (e.g., concerning industrialization of IT, methodologically sound architectural design) for such huge projects is still hardly available and is even less implemented in practice. A good example is provided by Mertens (2009) who derived suggestions for practice from a scientific point of view. Therefore, the BISE discipline should think about how its findings “can actually improve the world” to a greater extent. Ultimately, the research performance will also become visible and evident in the real world. Only then will BISE successfully continue its mission to shape and improve our environment.