Part 2 – Apparent Causes
In this second part of our series on why public sector IT projects fail we’re going to discuss who or what commonly gets blamed for failure. In our unfortunately all too many postmortems of failed IT projects here’s what we typically find people saying:
Technology
Technology failed us. ”We didn’t have the right tools, We needed different software/hardware/network/programming language and we would have been ok.” The assumption here is there is some magic technology bullet that would have pushed us over the threshold of success. It’s possible but highly unlikely in our experience.
Methodology
Our methodology failed us ”We used ABC (insert CASE, SCRUM, Agile, Waterfall, Information Engineering – we’re old enough to have seen them all) system development and XYZ method of project management. If only we had used 123 project management and 456 system development methodology we would have been okay.” Similar to technology the idea is that there was some magic technique that if followed would have guaranteed success. This is usually a specious claim as most projects follow little or no real methodological discipline. Even if followed to the letter a methodology won’t save a project that’s destined to fail.
Staff
The staff failed us. “ We used contract staff instead of state staff. If only we had used our own staff we would have been okay” or “our staff just don’t have what it takes to do a big project like this.” Most developers are, in our experience and with good hiring practices, very competent. Same holds for program staff. Though there are occasions when a slick salesman provides bad resources these are usually weeded out quickly by competent management.
Vendor/Consultant
The vendor/consultant failed us. “They said they could build a rocket ship but it turns out they couldn’t”. OK Vendor’s do over commit. They are in business to make money and will often promise more than they can deliver. Was this the cause of a projects failure? Possible but unlikely, the root of the problem was in place well before the consultant was hired.
Senior Leadership/Politics
Our own leadership sabotaged us. “They never supported this project from the beginning!” or “The political winds were blowing against the project so they case us adrift.” In our post mortems we’ve simply never found this the case.
The Project Manager
The project manager didn’t understand technology. ”The manager really didn’t get the consequence of the decisions s/he was making, if only someone technical was in charge!” or “S/he micro-managed us the whole time!” Our reviews of failed projects have revealed many a PM who wasn’t a good project manager – but we’ve yet to see a project fail because the manager wasn’t technical enough or spent too much time with the project.
Oddly enough we rarely hear “our Quality Assurance vendor (QA) failed us.” QA has failed on these projects. However, their contribution to failure is rarely recognized, after all it was QA that pointed out the failure in the first place. However, as a buyer of Quality Assurance services you need to ask where was the QA vendor BEFORE failure began, why didn’t they recognize the seed of the problem before it sprouted?…but that’s a topic for a different time.
You’ve probably guessed by now we don’t believe any of these are the root cause of project failure. At best they might be contributory. No matter what they are certainly a diversion from finding the real cause and instituting practices that will save the next project.
Next we’ll give you a few ideas about what the real cause of failure might be.
This is the second in a multi-part series of posts analyzing the causes of failures in public sector IT projects and proposing some pragmatic solutions.