Return of the Guru

More on Failed IT Projects: Readers Sound Off

Ara Trembly
Insurance Experts' Forum, June 23, 2011

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 ( is the founder of Ara Trembly, The Tech Consultant, and a longtime observer of technology in insurance and financial services.

Readers are encouraged to respond to Ara using the “Add Your Comments” box below. He can also be reached at

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 do not necessarily reflect those of Insurance Networking News.

Comments (2)

I like this idea, but I wonder just how well we can prepare someone--tell them what to expect--when a project extends out over years. It seems to me your solution would be more valuable as a function of the length of the project, e.g., shorter timespans would correlate with greater success.

Posted by: Ara T | June 26, 2011 9:10 PM

Report this Comment

Hi Ara,
A topic that is both facinating and frustrating.
In a previous life I specialized in salvaging these rogue IT projects, and every single time the core issue turned out to be that nobody knew exactly what was expected of them and others. The net result was, unsurprisingly, a lot of activity withouth much progress to show for it. The customer was never especially difficult, IT was never really unresponsive, nobody was really incompetent and certainly no one was hoping for the project (and themselves) to fail. And every time, as soon as we were able to establish clear understandings of roles and responsibilities, what ever issues remained with the tools or process were quickly resolved, turning a non-performing group of individuals into a team of true heroes.
Francis Dion

Posted by: Francis D | June 24, 2011 2:07 PM

Report this Comment

Add Your Comments...

Already Registered?

If you have already registered to Insurance Networking News, please use the form below to login. When completed you will immeditely be directed to post a comment.

Forgot your password?

Not Registered?

You must be registered to post a comment. Click here to register.

Blog Archive

The Other Auto Insurance Telematics Shoe Drops

Progressive's decision to charge Snapshot drivers more if their driving data indicates higher risk has started the industry down a road of data-driven adverse selection.

Core Transformation – Configuring in the Rain

The whole point of core transformation is that changes at the micro level can be used as a stimulus for changes at the macro level.

6 Ways to Develop a Productive IT-Business Dialog

Relationship management 101 for keeping IT and business on the same page.

Unified Digital Strategy: Succeeding in the Digital Revolution

A unified digital strategy recognizes that all business strategies and technologies touch the customer in some way and that a one-size-fits-all channel model is obsolete.

Agile and Continuous Delivery in a Regulated Environment

Just because a development team is doing continuous delivery or packaging releases into two-week sprints doesn’t mean that code is being moved to production.

Dealing with the COBOL Brain Drain

Documentation on aging systems often is akin to tribal knowledge, and the potential for things to go bump in the night increases as these environments face generational transition.