The IT industry has what might best be described as a fairly shabby record on project delivery.
Projects that do deliver the promised benefits are often late and/or over budget. Unfortunately many projects never make it to the finishing line or simply fail to deliver the benefits that they were predicated on in the first place. A high profile and very expensive example being the national NHS ‘Spine’ project which quietly slipped in to oblivion.
So why is this the case? Other indiustries such as construction manage to put buildings up that meet the architects brief, we dont generally see them abandoned or struggling to finish. The big software companies suffer from the same malaise, how many people would want to travel regularly on a plane powered by Microsoft Windows? – ‘the engines have suffered a fatal error and need to close’.
There are many approaches to project management with ‘Agile’ development processes gaining popularity over the historical ‘waterfall’ approach. For the purposes of this post I am taking a very generic view.
The Top Reasons for IT Project Failures
- Inadequate Specification. With all projects the devil is in the detail. If this is not pinned down, agreed, and signed off, the project is flying blind in terms of some of what it is trying to achieve. Its like trying to set a Sat Nav to go ‘somewhere’, if you are not specific you are unlikely to reach your destination.
- Requirements Change. This is common, especially in long term projects. The world moves on, the market changes, what you needed a year or two ago becomes inappropriate. A regular review of project objectives against business needs can prevent a project missing the mark. This of course needs balancing with the dreaded ‘scope creep’ whereby requirements change all the time and the project simply changes shape continuously rather than actually delivering anything.
- Insufficient Change Management. Very few projects make it to the finishing line without some kind of changes being needed. A structured change management process to review, manage, and allow/deny change requests is essential.
- Lack of Stakeholder Involvement. The project beneficiaries and sponsors tend to be the experts on what the project should be achieving, their representation is needed from project inception right through to testing and go live. Without this the day to day project team will be making decisions and trying to progress without necessarily understanding the nuances of what they are doing. The worst scenario is the IT team delivering what they think the business will need, this is often no more than guesswork as many IT staff do no understand the detail of the businesses they serve.
- Poor Estimates. One of the trickiest parts of any project is estimating both time and budget. A set of metrics from previous projects is useful, but in practice all projects are different and all bring their own challenges. A prudent project manager will break the project down in the smallest chanks they can and estimate each one individually, and then add 30% or 40% to the total to cater for surprises and unknowns. Even then the estimnates can be woefully wrong. Its is key to communicate with sponsors and stakeholders and articulate both concerns and variances, much better to discuss potential issues in advance rather than simply not deliver.
- Lack of Understanding of Risk. Many projects are run without all risks being identified or without mitigation measures being put in place. Assessment of likelihood and severity of risk is vital, on this basis alone some projects would never get kicked off. If these are unkknows proceed with extreme caution!
- Too Much Complexity. The bigger and more complicated the project the more likely that things will go wrong. People can only manage so much complexity, then things get dropped or misinterpreted. Also by definition overly complex projects take too long and suffer from the changing world syndrome where the produce a solution to a problem that no longer exists. Far better to find ways of running a number of iterations where the complexity is gradually added in.
- Wrong Project Team. This is another common problem, if the right people are not involved the outcome tends to be predictably bad. If the expert that is needed is tied up elsewhere find a backfill for them or delay the project, compromise on the team is a a killer.
There are many other reasons for failure, anything that could go wrong quite probably will. Key staff go sick, important suppliers fail to deliver, hardware fails, strange bugs in software cause delays, the list goes on.
However most problems can be avoided or resolved with concise regular communication between all parties, attention to detail, and a healthy dose of common sense. Then plan and track, and tackle issues head on – deferring difficult decisions inevitably makes things worse.