Why IT Failures Are Not Held Accountable

Introduction

IT project failures are not uncommon in many companies. Despite repeated outcomes such as budget overruns, unmet expectations, and team burnout, these failures are rarely met with clear accountability. This article examines why IT failures are exceptionally exempt from accountability, framing the issue not as a problem of individual capability or attitude, but as a problem of management judgment and decision-making structures.

When Failure Occurs, “Who Decided?” Is Unclear

The primary reason IT failures are not held accountable is the inability to answer the following questions at the point of failure: “Who made this decision?”, “On what premise was it based?”, and “What was defined as success?”. Because these are not documented, failures are consistently explained away as “unforeseen,” “due to poor conditions,” or “technically challenging.” Before accountability can even be discussed, there is no clear place to assign responsibility.

IT Has Advanced Through “Execution Without Judgment”

In most areas of management, judgment precedes execution. Investments involve decisions, business exits involve resolutions, and organizational restructurings have accountable leaders. In contrast, IT has historically seen a pile-up of executions without judgment, driven by field requests, technical necessities, or constraints of legacy systems. As a result, even when failures occur, they are not examined as “errors in judgment.”

Delegation and Abdication Have Blurred Responsibility

The notion that “IT should be left to the experts” has significantly impacted the structure of accountability. Management does not assume judgment under the pretext of specialization, experts are expected to act as proxies for management decisions, and field teams operate within given constraints. In this state, failures are consistently treated as “someone’s lack of effort” or “bad luck,” and are never examined as failures of management judgment.

Failure is Treated as an Event, Not a Structure

IT failures tend to be discussed as events: schedule delays, cost overruns, or system outages. However, what should truly be questioned are structural issues: “Why was that premise set?”, “Why couldn’t a decision to stop be made?”, “Why wasn’t it designed holistically?”. Without delving into the structure, accountability cannot be established.

The Era When Not Holding Anyone Accountable Was Rational

There was a managerial rationale behind the lack of accountability for IT failures. Technology changed rapidly and unpredictably, making it difficult to explain cause and effect, and there was a fear that assigning blame would make no one willing to take on IT projects. Consequently, IT came to be treated as an area where “failure is to be expected.”

What Has Happened as a Result?

Within a structure devoid of accountability, the following phenomena have become entrenched:

• The same failures are repeated.
• Decision-making processes are not accumulated.
• Neither success nor failure can be replicated.

This is not a problem of the IT department or vendors; it is the result of management failing to assume judgment.

Holding Accountable Is Not About Blaming Someone

It is crucial to understand that accountability is not a personal attack. True accountability is the act of clarifying: “Which judgment was incorrect?”, “Which premise was wrong?”, and “What should be changed next?”. Without this, an organization cannot learn.

What Is Needed Next

To stop repeating IT failures, what is needed is neither shifting blame to the field teams nor adding new management rules. The first necessities are to “clearly identify who made the IT decisions” and to “verify decisions by linking them to their outcomes.” The next article will examine the moment when business strategy and IT strategy run in parallel, exploring how this structure of absent accountability has expanded.