An alarming study by Flyvbjerg and Budzier published in the Harvard Business Review has made everyone stand-up and take notice. The coherent advice being that IT projects are much more riskier than we think.
The study showed that amongst the 1400+ projects surveyed, on an average 27% were over budget. 16% of the projects could easily be categorized as Black Swans. They had a cost overrun of over 200% and were late by almost 70%. These were the projects which could cause stunning failures and bring down companies.
Boris Gloger mentioned that the results were frightening.
These results are significant. But even more frightening are the conclusions of the authors of Harvard Business Review article. They write: If you want to avoid the slow death caused by IT projects you must be prepared not only to spend 400% more than planned on the project, but to reap only 25% of the expected benefits. If you keep this in mind you can possibly prevent a company from being killed by an IT project.
Paul Glen mentioned that one would expect the distribution of project overruns to look like a bell curve, but surprisingly that is not the case. A disproportionate number of projects were huge failures which had the potential to destroy complete organizations.
Ed added that it was amazing to notice that in the last 15 years the industry had not got any better at delivering large IT projects. One of the possible reasons for the results to look the way they look could be that the study pointed to a lot of projects where re-platforming was involved.
My theory is that it is these very large re-platforming projects that are frequently the issue. They touch so many systems, so many discrete business units involved across the globe, and the desire to do customization so they become impossible to upgrade.
Ed mentioned a similar re-platforming project which was successful as it had all the ingredients of a good Agile project.
An example from the article of a successful project by the Emirates bank in 2006, shows a successful way to run a large complex project. The lessons learned from this successful project were to:
1. Stick to schedule
2. Resist changes to the projects scope
3. Break the project into discrete modules
4. Assemble the right team
5. Prevent turnover among team members
6. Frame the initiative as a business endeavor, not a technical one
7. Focus on a single target – readiness to go live, measuring every activity against it.
Boris added that another reason for such disappointing numbers could be that we are addressing wrong people.
But maybe we are addressing the wrong people , like Ken Schwaber says in his new, soon to be published book. Possibly IT customers, software development, and product development need to simply not accept any more that IT departments, QA departments and process people can not create finished, tangible and measurable results every two weeks.
Mary-Ann Massad mentioned that a good governance model could have saved the day for many organizations. According to Mary-Ann,
Real governance means leadership. Real governance means courage-the courage to tell the truth even when it will not be well-received. Too many "well"-run organizations operate under a culture of fear and "group-think". This is why IT projects or any projects for that matter, have the ability to bring an organization to its knees. We have to work on building organizational cultures that welcome honesty, diverse opinions, and integrative thinking.
Thus, one could dive deeper to analyze the shortcomings and learn from them, however the numbers do suggest a serious re-think in the way projects are executed.
