When IT projects fail, who gets the blame? IT, of course. But with failure rates for projects often over 50%, the truth is, there's an awful lot of blame to go around. I had a refreshing talk with Lewis Cardin, senior analyst at Forrester Research, about why IT projects fail, and he has a different point of view.
Over time, IT has become a "demand management" organisation that is asked to add its kind of creativity to the products and services the business requires. The business may seek to capitalise on an investment opportunity, or it may demand a specific project of IT, with a specified start and end date, and particular deliverables in mind. Historically, the PMO (program management office) has been the mechanism within IT that takes the project and, working with IT project managers, makes sure there is "excellence", as Cardin puts it, in project delivery in terms of scheduling, costs and requirements. Of course, when you have a number of competing opportunities, the PMO is also responsible for prioritising projects. It has to know which project comes first, which delivers the most value, and so on. And it is on IT to figure out how to optimise the people and financial resources across active projects. Usually, the PMO does all this with oversight from a governance or steering committee. That steering committee needs to be there in some form to make investment decisions based on business case scenarios, for example. After a project gets the nod on investment, the committee must assess its priority and decide how funding will be approved. All of these things enable IT to go ahead and do the work once the steering committee consents. As the project continues, the PMO works with the programme manager to build the project plans and sort out the interdependencies and details of financing, so everyone understands what is needed. Then it is the job of the PMO to make sure milestones and deliverables have been met before it goes to the next round. You might call this part risk management.
After reviewing all of the key components of managing a project I had only one question for Cardin. "Lewis, you make it sound as if, with all of this oversight and planning, a project can't fail and that every project is going to be a roaring success. Yet over 50% of projects fail. How do you explain that?" I asked. Cardin laughed. "What I discovered," he told me, "is that when you peel back the onion the project isn't failing." According to Cardin, when projects are labelled a failure, if you look a bit deeper, there is usually somebody in the business that said, "If we can change this requirement or add this requirement, we would improve the value proposition of the project." The business case is re-run, and everyone decides it should be done. Of course, project expenditures increase, budget increases, and the schedule takes longer. "But people only remember that the first part where it was going to take X number of dollars and X number of months," Cardin says. What they conveniently forget to consider it that the changes made to the project actually improved on the original plans. If IT is to blame, it is because it has not convinced stakeholders that changes actually make the project better.
When a project truly goes down in flames, rather than simply blame IT, we should look also at the governance process, says Cardin. "What causes some projects to fail is the non-responsiveness of the steering committee," he adds. Often, IT can't proceed with a project until it gets in front of the steering committee, whose approval is needed to inject the next round of funding. If IT doesn't get to the committee for two and a half weeks, everything is stalled. "The project isn't failing; it is governance that is failing," says Cardin. Perhaps it is a bit optimistic, but Cardin says every project should be a roaring success if you plan well, are fully resourced, the project manager is good at execution, and you have made decisions when they are supposed to be made. "If all those things are in place, you will never have a project fail", he says.