Why do IT projects fail and how can you ensure yours doesn't?

The media is full of stories of IT projects gone wrong, like the £300m TSB IT migration failure or BA’s £150m IT Disaster Recovery failure. So it is vital for you to get it right when rolling out new IT, as traditional business-led projects make way for technology-led solutions and the scope and impact for IT failure increases.

Read next: Disrupt the digital challengers with a 'transformation mindset'

But what can you do to avoid your project failing in the first place, and becoming the next IT failure headline? Our experience in IT transformations has shown that projects often run nearly 50% over budget. Worse still, many projects start already doomed to fail. 78% of respondents to a study by Geneca said that “ [the] business is usually or always out of sync with project requirements,” while 75% of project members lack confidence that their projects will succeed.

Why is this, and what are the most common traps you should avoid? Robust Change Management

You may have accepted scope creep as a fact of life. It is common in project failure, as costs rise and timelines slip. Plan for scope creep early, before even requirements gathering, so that you can clearly state what will and will not be in scope.

If you manage scope and change effectively, stakeholders won’t have unrealistic expectations, and you can be stricter as a gate-keeper for new requests. Make sure you define and engage a dedicated change control board of both business and technical leaders, who have the authority to approve any new scope requests. You can then communicate extra costs clearly, and prioritise any impact to timelines. Agile Development

If you break up your project scope in to manageable sections, you can have more frequent checkpoints to check your solution with your stakeholders. Not all projects fit a true Agile model of weekly or fortnightly deployments, but did you consider Agile on your last project?

An Agile mind-set can be powerful, to keep your teams motivated and focussed on short-term goals. You can then introduce checkpoints more naturally to confirm progress. Consider re-scoping the project or re-prioritising requirements to allow you to deliver minimal viable products (MVPs) or proof of concepts (POCs). Then, you will bring a spirit of continuous improvement to your team, and help them deliver higher quality output at the end. Testing

Have you ever cut a test phase short, because you were “nearly there” or a go-live date was looming and you ran out of time? No project can succeed without strict testing, and you should allow enough time for integration, performance, and user acceptance testing – though you can often combine several phases together.

Plan to set strict testing pass criteria early on, to define what a “functional pass” looks like. Often, this will be very different to a technical pass, as it has to deliver a business process, not just a stable code base. Performance testing is equally important to demonstrate the viability of the solution under normal use, so do not forget this until after go-live. Poor solutions will destroy stakeholder engagement, or worse, hamstring funding and support for future phases.

Finally, have you asked your end users? They must be engaged and happy with the solution as they are the first adopters, and need to be just as happy as senior stakeholders. This is where MVP and POC delivery becomes so important. End users have a chance to add input to improve usability of features, which is often impossible to think through during initial phases. Stakeholder Engagement 

Finally, ensure that your stakeholders are engaged at every stage. They should not be restricted to senior project sponsors either – technical support and end user teams are just as crucial to success, and their sign-off should be a part of every project. Are you sure you’ve identified all of yours? This may include public users, tech support, operational support, leads of dependent projects, vendors (e.g. in case of application customisations), as well as the project steering board. They must fully sign off requirements and frequent demos and checkpoints throughout the development phase will also help them remain enthusiastic for the end goal. In a nutshell

A recent Gartner survey showed that IT projects keep failing due to complexity and poor governance. As a result, they were either too late to be useful, or did not deliver the requested functionality.

• Accept that scope is likely to change, and have a strong process in place to manage and plan for this change, and you will be ready to anticipate this;

• Split your project into smaller sections to make your delivery more modular. This will allow you to de-prioritise planned work in favour of new, more critical scope;

• Increase stakeholder engagement by prototyping functionality with demos, ensuring your project remains on track;

• Plan for frequent feedback loops, to keep improving your delivery and keep users interested in your product;

• Test everything thoroughly to show that your project is fit for purpose, and can be used straight away by the business on go-live day.