Why IT Projects Fail

I learnt how to better manage IT projects, and you can too.

Unfortunately I learnt this the hard way through an incredibly stressful project which I never wanted to experience again.

To help you avoid what I had to go through, it’s right and proper to first start with an absolutely clear idea the reasons why IT projects commonly fail.

In this article, I will use my personal experience of this incredibly stressful project as case study to illustrate why projects commonly go wrong and fail. I will also generalise my personal case study and show you how to apply the concepts more broadly across all IT projects.


Early on in my PM career, I landed a project beyond my capabilities without knowing it. It was to become one of those “nightmare projects”.

A year in having worked night and day, I had nothing more to give.

When the project was finally delivered I had some time reflect on the experience and what had gone wrong.

What surprised me the most was the project continued to go south whist I continued to manage it according to the book. Working “harder” didn’t make any difference. I had fallen into a bear trap without even knowing it.

I will now explain more about what I was doing and why it wasn’t working.

Project Initiation

As a newly hired PM dedicated to this project, I found an incumbent supplier and an end of life system in place.

Diligently I set about speaking to all the different stakeholders, understanding budget approval processes, and drafting the project documentation to get things started. Of importance was the Project Initiation Document (or PID) which this organisation used as a lightweight business case for some of the “smaller” capital projects.

The Wikipedia entry describes the Project Initiation Document as “one of the most significant artifacts in project management, which provides the foundation for the business project”, and as such I set about drafting a really detailed one given the complexity of replacing a business critical system.

Critical to getting the PID approved was (amongst other things) an accurate picture of the current and future states of the system to be replaced as well as the project structure to do so. In my logical engineering mind, the important aspects of the PID looked something like:

The actual PID which was written by myself and approved by stakeholders is outlined below (to give you some idea of the level of detail that went into the project planning):

Click here for a larger view

I’ve deliberately kept the PID image poor quality to obfuscate the project details and preserve confidentiality, whilst still being able to give you an idea of the detailed design and planning undertaken [nb. not an indicator of project success as it turned out]

Project Management 101

Risk management followed a typically standard process, namely:

  1. A pre-project risk identification workshop (source)

And then a regular process of:

  1. Identifying new risks
  2. Assessing each risk (threat / opportunity)
  3. Planning risk responses
  4. Implementing risk responses
  5. Reviewing risk responses

As per standard programme / project management, every 2 – 3 weeks the stakeholders got together in a steering committee meeting to review progress and make any decisions required of them.

Given all the detailed project management being performed, the question I came to ask myself over and over was…

How is it possible for the nightmare project to continue going south whilst I am following standard processes?

What project management actually felt like

I apologise slightly for including a summary of standard project management above, but I wanted to ensure we were all broadly starting on the same page.

But for those of you who skipped over it, felt you knew it by heart, or simply didn’t have the interest or time to go back through Project 101 principles, I decided to summarise what it actually felt like at the time as the Project Manager in charge (and often held to account):

Running through the RAID log in a steering committee meeting often felt like cleaning up the lounge room so it’s nice to be in ahead of watching the latest binge worthy Netflix series [1]
Meanwhile whilst watching Netflix, minor tremors were occurring from time to time under the delicately balanced house. I couldn’t exactly put my finger on what these meant, even if I had a deep-seated feeling that “something” was wrong [2]
And on one occasion, unfortunately the very worst-case event actually occurred, threatening the very survival of the project [3]

Not all risks and issues are as visible as a fallen house

My RAID log didn’t have an entry for “house falling down as a result of an earthquake”.

That’s because not all risks and issues are as visible as a fallen house. And also because as a new PM in an unfamiliar organisation, I could only identify and control so much of the total risk myself.

The project remained unaware of the very real environmental threats it had around it, and/or remained unwilling to discuss the reality of the situation. In this specific example, the real problems (which remained largely hidden and unmanaged) were the following:

Click here for a larger view

There are very many other examples of environmental threats to a project. Think of the effects of low morale and staff turnover for example, lurking in the shadows and not always openly acknowledged. But eating away at the productivity of a project team none-the-less.

The point is this. I was doing all the right PRINCE2 stuff but the nightmare project was still going wrong. I was effectively cleaning the lounge room whilst not “clocking” what the tremors happening around me actually meant.

How to stop IT projects failing

I have described that IT projects commonly go wrong because of the environmental threats in and around the project.

These threats are in addition to the more typical delivery risks and issues the PM deals with on a daily basis. And that environmental threats can remain hidden and actively at work, even when the PM is doing all the right things.

We started to introduce the idea that environmental threats are “things” which surround and influence the workings of the project (or temporary organisation of the project). To make this concept more visible to the PM and all parties involved in the project, you can imagine it as follows:

Click here for a larger view

Five reasons projects fail
Hans Læssøe, founder of AKTUS and former risk manager at The Lego Group, has written an excellent article titled “Five reasons projects fail – and what risk managers need do about them” (cached article, original source) which supports the idea that project risks are not adequately identified, saying:

The identification tends to be based on tunnel vision, not considering the “business system” of whatever the project addresses.

What should I do about my IT project?

Question: Given my project is surrounded by these threats, and perhaps as the PM I’ve had the nagging feeling that something is not working, what can I do about it?

Answer: Systematically uncover the surrounding environmental threats, along with project risks and issues, that might be bearing down on your project. And assess the disturbance caused by each of these one by one.

The good news is our free Risk Assessment Tool will do this uncovering for you. The tool takes into account many different types of threats and looks across the several different “tiers” of these, namely:

Click here for a larger view

The tool has 45 questions which results in a total of 145 recommendations covering what to consider doing to better understand (and mitigate if necessary) each identified possible threat.

The questions are grouped into Categories and have been carefully chosen to broadly cover all the “tiers” in the previous diagram, as follows:

CategoryContribution to
Overall Risk Model
Programme Management14%
Delivery Management12%
Deployment and Post “go-live”11%
Reputational Risk11%
Stakeholder Management11%
Industry & Business Landscape9%
Procurement & Supplier Management8%
Technical Challenges6%
People Management5%
Business Readiness3%
External Dependencies / 3rd Parties2%
Operational Requirements2%
Requirements Management2%
Project Ways of Working1%
Quality Assurance1%
Organisational Culture1%
Grand Total100%

At what point should I consider threats?

There are two logical points in the life cycle of a typical project at which to properly consider and account for environmental threats and project risks, namely:

1. Initial Project Design (preferred)
This is a term not commonly found in project management literature, however it refers to the outline project planning performed upfront (often in the Business Case or PID stages) when considering how the delivery of the new system or business change will be performed.

For example, default assumptions such as “we will tender for a single supplier to deliver the whole thing” may only leave your project vulnerable when it starts to hit the Project // Operating Environment boundary if that mode of delivery doesn’t suit the culture of the organisation it is in .

Great care and consideration need to be given to the different possible ways that the project could be delivered, along with what each option may mean when it comes to interactions with the Operating Environment around it.

Detailed consideration in the initial project design stage should offer the best possible chance of success.

2. Mid-Flight Assessment and Correction
Sometimes the problems a project is experiencing are such that it makes sense to reorganise things a bit before continuing.

This is not necessarily a “bad” approach or to be seen as a negative because those who have been involved in the project are now advanced in their own thinking and experience of it, along with the Operating Environment they find themselves working in.

Project staff should now be ideally placed to tailor a new project structure closer to the characteristics of the actual operating environment and the nature of the change being implemented.

(nb. a mid-flight assessment and correction is not uncommon as we’ve done several of them)

“That is not a Risk”

Occasionally I hear the remark, “that [question] is not a project risk” after they have used the Risk Assessment Tool

And they are often right, at least in terms of what a traditional project risk is generally understood to be.

That’s because the question is oriented towards uncovering a broad area of concern or a risk factor, which when present, is understood to bring with it a heightened cause for concern.

Some of the questions, when answered Yes as applicable, will mean that further analysis is required to better understand what is actually going on. One or more actual project risks (or issues) may then come out of this analysis.

The recommendations given should prompt you with how to get started with the further analysis required.

Example: A project with multiple suppliers

A project which relies upon multiple suppliers to work together and deliver their respective components on time and in good working fashion is no joke.

When using the Risk Assessment Tool and answering Yes to the following question which represents this project situation,

Are multiple suppliers involved in delivering the project?

You will be presented with the following 4 specific recommendations about what to do next in this regard:

  1. Review supplier contracts and ensure contractual responsibilities are clear
  2. Review supplier contracts and ensure contractual KPIs are defined and supplier performance is regularly reviewed
  3. Ensure a periodic re-competition of supplier contracts is advertised and conducted on the open market
  4. Ensure incumbent suppliers are encouraged to bid for re-tendering of contracts to encourage their good performance in the lead up to the re-tendering

Each one of these recommendations leads to some further analysis to ascertain exactly whether the multiple supplier project situation is also resulting in additional project risks (or issues) to be present.

Thanks for reading this far. Now…

Complete a risk assessment if you haven’t done so already, or

Go and update your risk assessment if you stopped at the first 15 questions

Risk Assessment Tool for IT Projects

Images used above and appropriately referenced were sourced from the below locations:

  1. https://maidsailors.com/blog/simple-and-easy-home-cleaning-tips-that-you-need-to-know/
  2. https://www.thesmitsteam.com/blog/famous-neutra-stilt-house-vaults-onto-the-market-for-1-55m/
  3. https://www.iwnsvg.com/2014/09/21/owner-of-house-that-collapsed-complained-about-shaking-2-months-earlier/

Frank Ray

Frank Ray & Associates is a software engineering consultancy that builds high quality software for businesses.

We develop new applications, automate manual processes, integrate vendor packages, replace Excel workarounds, fix unreliable applications, retire end of life software and remove dependence on poor value suppliers.

Get in touch if you need our help