Every once in a while, a blog posting seems to touch a nerve with readers, and that has certainly been the case with my recent article on why so many IT projects fail, and in particular why the failure rate has remained in the 60-70% range for more than 25 years.
Readers definitely had strong opinions and they expressed them in emails to me, as well as postings to the blog. The responses to this piece fell into several categories: suggested reasons for failure; who is to blame for failure, and suggested solutions to eliminate failure. The blame responses were predictable, with IT blaming business and vice versa; an old story, I’m afraid.
One responder, a vendor, asserted that the problem was “complete ignorance of information as something that exists. There are many who pontificate on its uses but none who focus on its dimensions and component parts.” I’m assuming that this means that we don’t appreciate the value and form of information, thus we plan projects that don’t sufficiently leverage that information to achieve the project objectives. I suppose this is possible, but I wonder whether it can be generalized to the entire population of projects. I would suggest that some may appreciate and be aware of the forms and value of information while others do not. Still, I’m not sure if this is a universal problem.
Another suggested reason for continued failure was that projects are becoming increasingly complicated, especially because of all the interdependencies and interconnections required in modern enterprises. This makes a lot of sense to me, but if it is a major cause of project failure, then I would think we would see an increase in such failures as the complexity of projects grows. Instead, we see the same old failure rate. Of course, it’s possible that some other factors have improved performance while the complexity is negatively affecting it, but I have no real way of teasing that out.
The same responder also points to what he believes is our failure to “deal with the basics of issue resolution, risk mitigation, stakeholder expectations, etc.” This is the relational reason that others have put forward as well, but again, relational issues are fixable, so if they still are a problem, we have to ask why enterprises are not making use of issue resolution sources (such as might be found in Human Resources) to help these projects succeed. I think this may be part of the answer, but not the whole enchilada.
Yet another responder suggests that “exaggerated customer expectations, tentative and ever changing decisions, fragmented suppliers each doing a piece of the job, and lack of accountability and non-availability of recourses (Software licenses generally start with all denials of any fitness for purpose)” are combining to make projects extremely ponderous and difficult. I think this reader may have hit on something here. The problem is not that one or two factors are combining to cause project failure; the real problem is that so much that is inimical to computing projects can go wrong, and as Murphy’s Law would have us believe, will go wrong.
As I mentioned, a few vendors talked about products they believe will reduce the IT project failure rate. With all due respect to these vendors, however, any solution that does not reduce the number of things that can go wrong will probably not have significant success. Still, we live in hope, and I’ll be looking at such products as information becomes available. As always, please feel free to add your thoughts.
Ara C. Trembly (
Readers are encouraged to respond to Ara using the “Add Your Comments” box below. He can also be reached at ara@aratremblytechnology.com.
This blog was exclusively written for Insurance Networking News. It may not be reposted or reused without permission from Insurance Networking News.
The opinions of bloggers on
