Who's accountable for IT failure? (part two)

Who's accountable for IT failure? (part two)

Summary: This two-part series presents a structure for understanding why IT projects fail, in a way that goes far beyond project management alone.


This two-part series presents a structure for understanding why IT projects fail, in a way that goes far beyond project management alone. Part one elaborates the problem while part two discusses the need for greater accountability on the part of senior management.




While executives cannot anticipate every risk, current standards of accountability are clearly too low. The incidence of failed IT projects, leading to dramatic examples of waste, remains high and there is little cause to assume this situation will change soon.

Author and Suffolk University ethics professor, Lydia Segal, sees the result as "economic abuse" on the part of company executives. "Disregard for successful outcomes is the unintended, if frequent, consequence." she says. "We expect senior management to be financial stewards on all matters of material importance, including large IT projects."

And those who assess corporate risk agree. One of the UK's top authorities on managing risk, David Hancock, also refuses to excuse failures, saying, "Executives who do not protect this value are negligent in their duties. Failing IT projects can rapidly erode shareholder value and company reputation."

As evidence, look at these examples, which do not even scratch the surface of IT failure stories:

  • In March 2012, United Airlines changed a variety of ticketing and web systems as part of a merger with Continental. Problems arising from the upgrade caused prominent sourcing blog, SpendMatters to comment on the impact to United's best customers: "across the globe, frequent flyer chaos, even for top-tier flyers, has ensued as a result."
  • The National Health Service (NHS) IT failure, a massive project, has ongoing ramifications for system integrator CSC, which is currently negotiating with the UK government. Earlier in 2012, the company was forced to write off almost $1.5 billion resulting from its participation in the ill-fated National Programme for IT (NPfIT)
  • In 2010, publicly traded wood retailer Lumber Liquidators announced a 45 percent drop in earnings, due to "reduced productivity" associated with its ERP deployment.
  • In the UK, in 2010, system integrator EDS was forced to pay £318 million ($460.3 million) to British Sky Broadcasting (BSkyB) to settle another CRM failure case
  • In 2008, clothing giant Levi Strauss reported a 98 percent drop in net income due to problems with its SAP implementation.
  • Also in 2008, retailer J. Crew reported weak earnings due to problems deploying a new CRM system and website
  • In 2007, Arizona State University had to bring in armed guards on payroll days, due to problems with an Oracle system. One can only imagine the reputation damage to the university when the Wall Street Journal published that story.


IT failures are a byproduct of poor management practice and can be prevented. Organizations committed to change and improvement should consider these points carefully:

Make your CIO an equal partner in the business - if he or she doesn't measure up, then find a replacement. Many sophisticated CIOs seek a "seat at the table," hoping to forge a genuine partnership with business peers. However, not all CIOs possess the experience and understanding needed to discuss business issues at that level. For the good of all concerned, senior executives should invite the CIO to participate in strategic discussions while demanding that IT play a user- and business-centric role.

Enlist the Board behind your effort to improve. The size and scope of many IT initiatives requires approval from the Board of Directors. Too often, the Board is so far removed from IT projects that members do not fully understand the risks and practical realities of complex project execution. Enlist the CEO to champion IT change at the Board level - do so by considering the aggregate IT budget and making the strategic relevance of IT to the business as a whole. The more the Board is seen actively sponsoring the change, the greater the acceptance of the change among the employees.

Take control of change management, the silent killer of IT projects. Despite lip service to the contrary, most organizations treat change management as a relatively low-priority activity. As a result, change budgets are low and companies do not invest adequately in engaging employees at early stages of change or properly training them to perform new processes.

Define success and failure metrics; track progress over time. Many IT departments track key performance indicators such as system uptime and user logins. However, these technical measures do little to address the underlying reasons for IT failure. Instead, develop metrics related to user satisfaction, collaboration between business and IT, and senior management support for IT delivery.

Acknowledge failure when it happens; sweeping a mess under the carpet won't fix it. Transparency can be painful at first, but it also encourages trust and enhances long-term credibility.

CIOs should take personal control to assess and track the buy-in of employees to ensure they:

  • Are aware of the need for change
  • Possess the desire to change
  • Understand what they must do to make the change
  • Possess the necessary new skills to enable them to handle the changed way of doing things
  • Reinforce the change over time


Responsibility and accountability for IT project success or failure lies with senior management - transferring blame to project managers or third parties is ultimately a misguided effort that will not solve this massive problem. It is time for the business community to expose IT project failures as an important source of economic waste and take steps to fix the problem.

Topic: CXO

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • The problem is management and over engineering

    Being a software developer for 30+ years (everything from punch cards to web/ajax), I've been around. Most failures are unnecessary and caused directly by poor management. IT management is some of the worst in the world, overridden with over-engineering and "management process of the month" attempts at finding "the silver bullet" to development. There IS NO silver bullet. The key to success is to hire people that know the difference between the real world and the text book model, and keep the BS away from them. Good managers (I've seen a couple) know how to do this. It's not forced "Agile" or "Scrum" or "Extreme" or "Pyramid" or any other worthless management "savior" techniques, it's common sense. Unfortunately there isn't enough of that to go around.
    • Yes, management is responsible, but are almost never punished.

      Any failed project I have seen has been blamed on everyone and anyone but the manager responsible for the failure, and they are the ones who are punished. This will never, ever change. Scapegoats are always available, so they just have to pick one. That is what they do, and all they know. Of course, if the project is a success, they get all the credit and glory, and those responsible for it would be lucky to get so much as a thank you.
      • The business process reengineering goat

        You need a goat like this on every project.

        Business Process Reengineering methods advise the following:

        1. Reduce the number of steps in a process
        2. Reduce the number of people involved in the process
        3. Make this group of people responsible for the whole process.

        Normally lots of people run around trying to find who is to blame. The BPR goat makes this process more efficient:

        1. Just one step in the process, you know who to blame - the goat.
        2. There is only one entity to blame - the goat.
        3. The goat and the goat alone is to blame and is responsible for the whole blame process.

        I bought my plastic BPR goat for 4.50 Euros from a toy shop, it's on my desk. You can get similar goats from Accenture, PwC or Deloittes but they usually start at around 250,000 Euros.

        Great article by the way Michael, keep up the good work.
    • ...

      I second your points...

      However if common sense was common, everyone would have it. :)
    • Silver bullets

      Some projects are like playing Russian roulette with a silver bullet in every chamber.

      I agree with what you say, but added to common sense, discipline, persistence and realistic expections are important too. Good methods are important but silver bullet thinking leads people into believing that if they just follow some method then success is inevitable. Project success requires flexible thinking.

      The sunk cost syndrome is also a problem. When a lot of money has been sunk in a project almost no one is prepared to say that stopping the project would be the best thing to do.

      As WC Fields put it "if at first you don't succeed, try again, then give up, there's no sense in being a damn fool about it".
  • Who's accountable for IT failure?

    Man. age. ment.
  • Failure is a dirty word

    Management is ultimately responsible for most of these failed projects... and who polices management? Management usually lacks the necessary understanding of IT project risks to give IT projects the attention they require. It's common for IT personnel who raise this issue, citing the large IT project failure rate, to be dismissed as overly negative... and contrarily management remains overly confident.

    One thing we can do to reverse this trend is to collect details of successful projects and document what was done right. Success and failure rates are often linked to certain software and companies. You want to ensure that the best software rises to the surface... along with the best companies. Another step would be to ensure management does not load software with so much customisation that implementation becomes problematic. Many of these user requirements are made without consideration of the limitations of technology or cost.

    Vendors consistently over promise... which is an understandable danger if the alternative is to lose the contract.

    Management often also contributes to the problem by failing to utilise existing software and demanding totally new systems (unnecessarily increasing the risk of failure).

    Programmers/designers increase list of failure by using inappropriate software ie. whatever software they are familiar with... rather than the most appropriate software.

    It's particularly surprising how few companies get sued for IT system failures... which suggests that there is a problem with the contracts being signed or the oversights of these contracts are lacking. These are very much management issues.

    Management is also often inexperienced in managing major litigation... or unwilling to manage the process. Very few companies seem to manage the process of litigation successfully. We can learn a lot from those who do.
  • When is a failure not a failure ...

    "Lies, damn lies and statistics!" Samuel Clements,1895 (mis)quoting Disraeli

    Everyone seems to want to point to IT as a major failure when it comes to project management. But much of the failure can be attributed to not understanding risk and variance. This lack of understanding by both business and IT is a major root cause of expectations not being met.

    I can't begin to count the number of organizations that set project success at 10% of budget. And then go ahead and set the budget when the workload variance is 50-100% and the team has not yet been determined (a 500% range of variation).

    Unfortunately, managers used to working with consistant, repeating processes have a great deal of difficulty when being forced to accept the silliness of estimating the length of the piece of string in my kitchen drawer. And as a result they tend to have an unrealistic expectation of my ability to estimate and then produce that length.

    Glen Ford, PMP
    • You really should spell his name right

      Mark Twain's real name was Samuel Langhorne Clemens.
      John L. Ries
  • IT Emergencies

    The real problem is not just how IT manages projects, since most business projects have a technology component. While you could literally design a page or wizard in a day and get it built and deployed in days this usually takes months. Once the project gets started group dynamics take over that are hard to overcome. Groups that argue, point fingers, bully, etc. will take longer to get things done. Unfortunately, there are few barriers to this kind of bad behavior in 2012 business culture - "everybody knows you have to ..." blah blah blah. The next time I hear someone on a project actually push for a Harvard Business Review best practice I'll give you $100 - it ain't going to happen.