Thirteen years ago I wrote a paper entitled “Top 10 Reasons Why Systems Projects Fail”. This has been my most requested paper. It was used at Harvard which eventually led to my company building the budget and finance system for the government of Ethiopia. I have been asked about it many times over the years by dozens or professionals, graduate students and academics.
I recently was asked by a Polish project management organization for permission to reprint it in their magazine. I thought this would be a good opportunity to go back to the topic and revisit it.
I am surprised at how well the paper has held up. IT projects are still failing in very similar ways to the ways in which they failed a decade ago. However, I do think that the article deserves updating for two reasons. First, after another decade in the business, I have been exposed to more (and larger) projects. Second, the world has changed since I wrote the article. When I wrote the paper, web architecture was rapidly evolving but had not taken over yet.
Unchanged IT project failure rates
The most important point here is that we fail projects just as often as we did a decade ago. So, in spite of all of the advances, we still fail most of our projects. Nothing has changed in that regard.
What has changed is the way that we spin our failures. First, more projects are now COTS projects, so customers are forced to spend millions (or tens of millions) of dollars up front. Once an investment of that size has been made, it is very difficult to walk away. It is even harder to admit failure. Imagine that you are a manager (or even worse an elected official) and you have wasted tens of millions of dollars with little to show for it. It looks far less bad to help the vendor blame it on the fact that “the business changed”, “we rethought the scope”, or “we ran into unforeseeable difficulties”, than it is to admit wasting that much money.
Because the Java EE environment and the culture of reduced reliance on the database make for a much longer development time and a much higher cost, I am routinely seeing projects that I would have happily bid at a few million dollars for a 1-year effort a decade ago, that are now multi-year projects with budgets more than 10 times what I would see as reasonable. In addition, barely functioning prototypes are often being delivered a year or more into the project.
Is a project (that we could have built in under a year for 2 million dollars a decade ago using client/server technology) that is delivered on time and under budget (when the budget is $30M and takes 5 years to complete) a success? It was certainly a success for the consulting company and the COTS vendor.
Complex Architecture
Back in the old client/server days, a single developer could design the database, build the screens and reports, deploy the system to a 3.5 inch floppy, and deploy it on the client machine in under half an hour.
Modern JavaEE architectures are notorious for having more moving parts than an expensive sports car. They are hard to build, harder to maintain, and each and every Java EE project is built differently from every other project. Therefore, once the development team is gone, no one knows how it was built.
Once the system is finished, there is a very high probability that it will appear to work until it is stress tested or put into production where it fails instantly.
Software Integration
More layers of bureaucracy in a project is usually a bad thing. This happens most often in large projects (and almost always on large government contracts). If the prime contractor does no technical work, but only coordinates the efforts of the subordinant parts of the project, then the project is probably doomed.
Service oriented fantasies notwithstanding, software does not integrate itself without help. Someone working on the project needs to take the lead architectural role. That person actually has to be in charge of all of the technological aspects of the project.
A project without an architect who is truly in charge is like a boat without a captain. It goes without saying that this architect must actually know how build a system.
Leave a Reply