Why only a third of IT projects succeed

The latest and rather sobering industry statistics about IT projects show that 18% fail completely, 39% of them succeed, and 43% are only partially successful because they’re  either late, over budget, not completed to the agreed specifications, or a mixture of the three.

Interestingly, size does matter in these situations. Small IT projects (less than $1m) have a 76% success rate, with only 4% failure; whereas large IT projects (over $10m) have only a 10% success rate, with a massive 38% failure rate.

Why projects fail

In our experience, there are three main reasons for this:

1.The first is lack of management buy-in. If the key stakeholders aren’t fully engaged, they will not provide the impetus needed to make the project succeed. For example, if we are updating an accountancy package, we will need input from the accountancy team who will be using it. Unfortunately when it comes to testing the package on a parallel system which isn’t live, we are often told there isn’t enough time. If we don’t have the backing of management to make this happen, so we can make the necessary changes before it’s rolled out across the company, adequate testing simply doesn’t happen.

2.The second reason is that the client has unrealistic expectations of what the new system can do because they have given us insufficient information about what they need. In order to manage expectations and make sure we provide exactly what our clients need, we put a lot of effort into communication in the initial stages. Before we begin the work, we will always summarise (in plain English!) in our Statement of Work what we understand the desired outcome will be, and will clearly state how we will deliver it. We will also manage the client’s expectation about how the system will be tested and we agree with them the acceptance criteria. Typically, this exercise will take us between 5 and 10 hours’ work, but it is well worth it as it gives both parties a clear understanding of what we need to do in order to complete the project successfully.

3.The most common factor that delays projects is scope creep – where new criteria keep being added to the project as it progresses. In the past, we have tried to absorb these extra features as and when they occur, but experience has taught us that allowing scope creep to divert a project will inevitably end in the project’s failure in terms of time and budget.
If you allow scope creep to derail your project, it can delay it for so long that the technology becomes redundant before it’s ever had a chance to be used. The most disastrous and possibly most expensive example of this is the NHS’s computerised patient record system, which was abandoned in 2011 after years of scope creep at a loss of nearly £13 billion.

Eliminating scope creep

By using our own interpretation of a Prince2 framework, effectively keeping the best parts on control and planning whilst eliminating the burdensome administrative elements, combined with detailed requirement capturing we ensure that we can properly scope a project, communicate the outcomes to the client and control each stage to allow us to stay on track. Where requirements change during the lifecycle of a project, which inevitably does happen from time to time, we will work with the client stakeholders to determine if the changes can simply be included as an out-of-scope phase, whether a follow-on project needs to be initiated, allowing the original project to complete against the original requirements, or whether the project needs to be abandoned and a new project initiated. In this way we can mitigate the risks from scope creep at the same time as accommodating new requirements.

If you are planning a new IT project, contact us to make an appointment with one of our experienced experts.