What is it about IT projects that dooms them to failure about two-thirds of the time, according to experts? This was the question I sought to answer when I put together a panel discussion on the topic at this year’s IASA Educational Conference and Business Show in Nashville.
Apparently quite a few others were interested in this topic as well, with registrations for this session outpacing all others in the same time slot. I called together some of the most knowledgeable consultants and insurance IT executives for this session. I also asked some savvy vendors what they thought. As you might expect, they came up with a lot of answers.
First, let’s consider an amazing fact. When I first started writing in the technology space in the 1980s, IT projects were deemed to have failed about 60 to 70 percent of the time. Now, almost 30 years later, they still fail at the same rate! Haven’t we learned anything over that time? Hasn’t our technology improved to the point where we fail less? Haven’t we found methodologies that will meaningfully impact the failure rate? The answer, sadly, is no.
My panel bravely took on this challenge and came up with a number of potential reasons for failure, most of which make a lot of sense. The culprits included poor communication, poor business/IT alignment, shifting priorities over the lifetime of a project, poor understanding of the business purposes of the project, and poor understanding of the capabilities of IT to deliver on what the business wants. Many of these involve the relationship between business and IT personnel, and certainly the history of business vs. IT in many organizations looks more like the Hatfields vs. the McCoys than anything else.
Yet relationship problems are usually fixable. Not that I’m suggesting that all business and IT executives get together for a group hug, but initiatives like agile methodology do provide for cooperative thinking and doing between the two groups. Indeed, some of my IASA panelists thought agile might offer some hope for improvement over previous methods, but in terms of project success, I have yet to see the evidence. Others tried to parse the term “failure,” noting that putting time and budget constraints on IT projects might not be completely fair.
Well, it might not be fair, but it is reality.
One interesting suggestion came from a vendor. “It’s the customers,” he insisted, noting that organizations tend to change personnel, change direction and just change their minds over the course of a project that could take anywhere from six months to five years to complete. I don’t know that I buy this completely, but I have to agree that this certainly is a powerful reason why projects don’t turn out the way they were first envisioned. Added to this, let’s also consider that over the course of years, technology itself is continuing to evolve and improve, so that the changes planned in year one may be much less relevant in year four.
I’m tempted to say that the reason many projects fail is that they’re just too long. Then again, we don’t want to rush things when we’re pouring millions into a key systems replacement or upgrade. In the end, probably the best course is to engage in smaller projects that take less time and that allow for a great deal of modification after they are complete. The better prepared we are for change, the less likely we will deem our projects as failures.
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
