Train WreckYou would have probably read about the Queensland Department of Health payroll project, which ended in a debacle with costs estimated at $1.2 billion. In the US, the Expeditionary Combat Support System project was cancelled after the US Air Force spent $1 billion on its development.
The sad fact is that these failures are not isolated instances, but rather, only the most visible examples.  The failure of IT projects is very common. Per industry norms, less than 50% of IT projects finish on time and on budget.
Discussions with experienced CIOs, consultants and project managers show there are many reasons for the failures of IT projects. If you step back from the individual causes, some common themes emerge. Some are obvious, but others are not well recognised.

Fuzzy Goals

Many large projects fail, because they don’t have a clear idea of what they are trying to do. There is no clear problem definition or clarity about the project requirements. The full scope of the project is not understood. One Executive has an objective, but as the project moves forward new people, such as other executives, risk managers, and architects are introduced who add their ideas of what would be best for project implementation. The net result is unclear goals, expanding project scope, and poor project design, which lead to unending debates and sliding timelines.


Over OptimismSalesmen and internal project champions both want their proposal to succeed. However, in their wish to make the ‘sell’, they often underestimate the costs and over emphasise the benefits. While preparing  business cases, there is a tendency to maximise benefits and cut costs to meet the right return on investment (ROI) At times, the under-estimation is not intentional, but a result of the CIO having a poor understanding of the current situation and requirements. The CIO does not consider, or budget for, the effort to move from installing a system to actually achieving the benefits (new products, customers, new capability).
Over optimism then results in unrealistic schedules. There often is an unjustified faith in technology (product, vendor, or internal capability). Solution complexity is not evaluated. As a result, project risks are not well understood or controlled.


ComplexityMajor IT projects have a high degree of complexity due to new technology, the myriad of interfaces with other systems, data conversion. and due to project team having to compete for resources with other projects. Many times the legacy processes have to be replicated or supported in the new system, which adds to the complexity.
What project managers (PMs) and executives do not understand is that the project risks and effort involved in the project increase exponentially as complexity increases. Systems and processes become brittle as people try to cater for this complexity in a tight timeframe and with workarounds. The complexity eventually overwhelms the PMs, and the projects go out of control.

Weak Ownership

Large projects often have multiple executives, each with slightly different agendas as stakeholders. The executives have different expectations of the project’s benefits and options, which are at times incompatible. None of the executives fully support the project, and many projects lack an effective sponsor who is accountable for the project goals, and benefits, and can arbitrate conflicting demands. Weak sponsorship also indicates weak accountability across the project. When dates slip, tasks are not completed or roadblocks emerge, and no one is held accountable to do their job, which results in the project becoming unmanageable. Weak ownership usually results in weak project control resulting in an increased chance of the project failing.


People accept that lack of governance is a reason for the failure of a project. However, most large projects have the exact opposite problem; there is too much bureaucracy. For example, in one IT project, 80% of budgeted costs were non-productive costs or red tape. In another organisation, a 3 day change request needed justification papers, and the approval of the executive steering committee, which costed more than 10 days of effort. In large organisations, stakeholders such as risk managers, compliance staff, process experts, and architects all have their own governance demands, which greatly increases the demands on the project staff.

Over-engineered Project Management

It appears that Project Management has succumbed to the modern fetish for valuing form over substance. Simply put, there is a greater focus on how we carry out the project, than on the activities, which produce the product. Below is a quote from a CIO on this over engineering:

In the past, we spent time working out how to solve a problem. We explored different avenues of approach, different ways of meeting a target. We focused on the customer’s needs and expectations. We focussed on what was to be delivered.

Nowadays, it seems that the focus is more on planning how you are to do it, coupled with a determination to adopt methodologies and standards. The result is that we spend more time planning the method and approach to the project and not working on the technical requirements of the solution and how we can deliver it. The body of documentation has greatly increased. Now we have plan, plus risk analyses, process flows, summary timelines, and all sorts of forms showing who did what, with and to whom, and when.

That gives rise to a more formally documented meetings, implying a new breed of project administrators who manage the documentation and schedule the meetings, adding to the project overhead, both in time and cost.  A second result is that the poor people at the coal face have, in addition to actually doing the work, a welter of forms to complete.

Wrong Project Manager

The major success reason for projects – large or small – is the Project Manager (PM).  Having certification as a PM is one thing, but having the ability and know-how is another. The PM has to know how to balance the needs of the project with the needs of good governance. The PM has to use the right method, apply it at the right time and in the amounts that are really needed. A PM must have knowledge of the subject of the project. This knowledge not only helps the PM drive the right solution, but also helps them to effectively communicate this solution to the business and the sponsor The notion that a qualified PM can manage any sort and size of project is twaddle.

Failure to Recognise a Troubled Project

Projects never go from being well-managed, on-budget, and on-schedule to outright failure overnight. There is always a transition period during which time the project is “troubled”. If you can cut through the noise to see the real issues, you have a window of opportunity in which the project can potentially be rescued. It is likely that this is the last chance to save the project. Since people involved in a project generally want it to succeed, they unintentionally start ignoring or dismissing the warning signs.

Using external reviewers to detect these early signs and help the sponsor take decisive action can often help rescue a troubled project.


Think Big, but Act Small

As shown in this article, large IT projects fail for a variety of reasons. There is insufficient space in this article to go into the details of mitigating these failures, but one last fact is worth mentioning here.

Standish group research indicates that smaller projects (agile or waterfall) have a higher success rate (76%) than larger projects (10%). Research suggests that delivering product in small doses produces positive results. So you can think big, but you need to act small by making every big project a group of small projects.

You may also be interested in Barriers to Transformation.

Written by: Hemant Kogekar

Share →

3 Responses to Real Reasons why IT Projects Fail

  1. Sanjay Sarode says:

    How does the ‘Fuzzy Goals’ reason for project failures contrast with Agile delivery methodology, where requirements normally keep evolving?

  2. hkogekar says:

    I am not an agile expert. But i understand that each stage of agile has clear goals. In fact agile methodology breaks the project in to many small projects which reduces many of the risks in the waterfall methodology.

  3. Goals are not the same thing as requirements. Projects easily and often can have clear goals but inadequately-defined REAL business requirements deliverable _whats_ that provide value when met by a product/system/software _how_. What most people call ‘requirements’ are actually requirements of the presumed product, and thus actually are a form of high-level design, which frequently turns out to lead to creep when wrong because the REAL business requirements it is intended to satisfy have not been defined adequately. For more, see my book, Discovering REAL Business Requirements for Software Project Success and articles at