Why do IT projects fail? 4 ways to avoid another IT disaster
The media is full of stories of IT projects gone wrong, with plenty of case studies. However, the reputational damage usually falls on the company implementing the new IT. End customers will not pause to dig in to the reasons behind their bad service, moving quickly to competitors instead, as suppliers and vendors rarely make the news in the same way. It is therefore increasingly important for you to get it right when rolling out new IT, as traditional business-led projects make way for technology-led solutions, with a more complex vendor environment and more significant technical challenges.
What can you do to avoid your project going wrong in the first place, and becoming the next IT failure headline?
Our breadth of delivery experience in Infrastructure and Application delivery, ERP implementation, and IT transformations has shown that IT projects often run nearly 50% over budget. Worse, many projects start already doomed to fail, with 78% of respondents to a study by Geneca reported that the “Business is usually or always out of sync with project requirements”, with 75% of project participants lacking confidence that their projects will succeed. [Footnote 1].
So why do they fail, and what are the most common pitfalls you should avoid?
Robust Change Management
You have probably accepted scope creep as a fact of life, and it is a key factor in project failure, with project costs ballooning and timelines slipping. You should plan for scope creep early, before even requirements gathering, to be able to clearly state what will and will not be in scope for delivery. By managing scope and change effectively, stakeholders won’t have unrealistic expectations, and you can be much more rigorous as a gate-keeper for new requests coming in. Make sure to also define and engage a dedicated change control board of both business and technical leaders, who have the authority to approve any new scope requests. Done rigorously, you can communicate extra costs transparently, and any impact to timelines can be prioritised accordingly.
Breaking up your project scope in to manageable sections will allow you to have more frequent checkpoints to validate with your stakeholders that you are delivering the right solution. Not all projects fit a true Agile model of weekly or fortnightly deployments, but did you consider an Agile approach on your last project? An Agile mind-set can be a powerful one, keeping your teams motivated & focussed on short-term goals, and allows you to introduce checkpoints more naturally to verify progress. Consider re-scoping the project or re-prioritising requirements to allow for minimal viable products (MVPs) or proof of concepts (POCs) to be delivered. With this approach, you will bring a spirit of continuous improvement to your team, and help them deliver higher quality output at the end.
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 considerations – though it is often possible to 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 neglect this until after go-live. Underperforming 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 ultimately 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 an opportunity to add input to improve usability of features, something that is often impossible to think through during the initial requirement gathering phases.
Finally, ensure that your project stakeholders are engaged at every stage. Stakeholders should not be restricted to senior project sponsors either – technical support and end user teams will be just as vital to project acceptance, and their sign-off should be a part of every project. Are you confident you’ve identified all of yours? This may include public users, tech support, operational support, leads of dependent projects, vendors (eg in case of application customisations), as well as the traditional project steering board. Your stakeholders must give full sign off on requirements; frequent demos and checkpoints with them throughout the development phase will also help maintain their enthusiasm for the end goal.
A Gartner survey in 2012 [Footnote 2] showed that nearly 50% of all IT projects failed because they were either too late to be useful, or did not deliver the functionality that was requested. Accept that a project’s 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. Splitting your project in to smaller sections will make your delivery more modular, easily allowing you to de-prioritise planned work in favour of new, more critical scope. You can then increase stakeholder engagement by prototyping functionality with demos, ensuring your project remains on track in delivering what it needed to. Ensure frequent feedback loops exist, and plan for them, to keep continuously improving your delivery and keep users interested in your product. And finally, test everything robustly to demonstrate that your project is fit for purpose, and can be used immediately by the business on go-live day.
For more information on how DMW could help you succeed with your project, and to learn more about the key building blocks distilled from our 25 years of successful delivery, please Contact Us or click on the following link “The DMW Approach”.