Why IT Projects Fail
Although IT projects may be difficult to scope, budget and schedule, he adds that organisations frequently miss the most important question: ‘Are we on track to deliver the business benefits?’ “If we don’t have baseline measures in IT, it means when there’s a scope change we can’t tell whether it’s meeting objectives,” Roberts notes. “People create a business case to justify the project, but oftentimes it’s an estimate that cannot be subsequently audited to say ‘did we deliver this?'”
Cahill says that intangibility and scoping difficulty is often overused as an excuse for why IT projects fail. He points to the relative immaturity of the industry—”construction has been around for thousands of years; IT is a relatively new industry”—but adds that even this is an excuse because IT projects have both fixed and unfixed elements just like other projects.
Essentially he agrees with Roberts: the problem is the lack of recognition that an IT project needs to realise benefits for the organisation. “The organisation may not have any formal or informal notion around benefits realisation, but projects can still start with what it wants to achieve,” explains Cahill. “Not having this, projects lose their way, not even realising that they’ve lost their way because they’ve never had anything to follow. And this becomes more fundamental than scope.”
When a project is bereft of its true objectives, it is then difficult to engage stakeholders and garner buy-in from executive management. Cattaneo nominates lack of management commitment and involvement as one possible cause of failure. “The project may well be forced upon the organisation and may not fit the current business agenda. By asking the right questions and building an understanding of whether management clearly sees business value from the project’s outputs, ‘true’ commitment can be better gauged,” he says.
Involving the right stakeholders at the beginning of the project and communicating with them will also help to formalise the requirements, which in turn informs the scope and the business benefits to be realised, Cattaneo adds.
A complex issue
Delivering a project on shifting ground is yet another challenge for IT projects. IT is one of the few sectors where the speed of change in technology and business requirements has such a profound effect on an unfinished project. “Both business strategies and IT capabilities seem to be subject of ever decreasing lifecycles,” notes Cattaneo. “Many projects start, and halfway through execution, the environment changes, for example, new business requirements emerge, or new technologies supersede older ones.”
Cahill calls this complexity, and includes the effect of the organisation’s other projects in the mix. “IT project managers need to be cognisant of other projects likely to impact from a technical perspective or from a shared resource, or political, or stakeholder management perspective,” he says.
Roberts agrees: “IT projects rarely exist in isolation, they have to fit with other things where you might have to tie information into some other application that may already exist.”
He concludes that, fundamentally, IT projects fail because they do not articulate the changes that will occur in the business and therefore fail to prepare an organisation for delivery. “It’s rare that in implementing a project that the technology does not work,” he states. “Invariably the failure comes from a lack of a definition of the way the new business process will work or the fact that the people have not been trained to work in a different way. It’s a change management thing.”
Good projects for a change
Catherine Smithson, managing director of change management firm Being Human, agrees that IT project managers rarely encounter technical problems and have more trouble engaging people. To prevent failure on this count, she says project managers need to first identify how much of an IT project is actually a change project.
“Understand the degree to which an IT project is going to cause people to change the way they do their work,” she says. “It might be a change in terms of the systems that they use, or it might be a change in business processes. Do an impact assessment; look at the change from their perspective. If there is a change—either a little bit or a lot—you are managing a change, not just delivering an IT project.”
Fortunately, Smithson sees IT project managers, particularly in Australia and New Zealand, leading the way when it comes to recognising the change aspects of a project. “A lot of organisations have realised that they don’t just need to manage the technical part of the change, they actually need to manage the people side,” she says.
However, there are still organisations out there that deliver the IT component of a project, only to find “that perhaps people aren’t ready for change, they don’t understand the need for change, they’re not on board with the change and they’re very reluctant to adopt the change”.
The key to success is full stakeholder acceptance, which “delivers people ready willing and able,” says Smithson. This approach may require more planning time upfront, but the projects tend to move faster and encounter fewer problems: “They finish on time and on budget and people are responsive.”
