koya979 - Fotolia

IT is not always to blame for a failed tech project

IT projects failing to be delivered is a problem we have all grown used to but as Billy MacInnes discovers the reasons things go wrong are not always obvious

I am indebted to IEEE Spectrum for an interesting series on notable failed technology projects over the last 10 years, which can be found here.

The data is skewed because so many of the failures in the public domain are government projects as private sector messes tend to be kept quiet, but there are still some interesting lessons to be gleaned.

Firstly, IT project failures and operational issues are occurring more frequently and the consequences are worse than they were before. This isn’t surprising because IT has become far more pervasive over the past decade. IT outages also affect far more people than they used to.

Secondly, IT systems are getting more complex and larger, “which means not only are they increasing difficult and costly to develop, but they’re also harder to maintain”.

The author of the series, Robert Charette argues that it’s not usually the technology’s fault. The graveyard of failed projects is “a testament to unrealistic and unarticulated project goals, badly defined system requirements, unbounded project complexity, poorly designed human interfaces, sloppy development practices, poor project management, vicious stakeholder politics, and unbridled commercial pressures, to name but a few”.

That’s quite a litany of failings, but there’s more.

Charette argues human decisions are at the root of nearly any problem, including sloppy code, insufficient testing, poorly understood dependencies and incorrect assumptions. But people are very quick to shift the blame away from themselves, he adds: “When we read about (and report on) failures, the language we use tends to assign blame to inanimate technology that can’t defend itself or get fired.”

While I agree with him to a certain extent – technology really is only as good as we allow it to be – I think Charette overlooks a wider issue. And it’s one that has existed since the serpent promised Eve that when she ate the fruit of the tree of knowledge she would “be like God”. In other words, claims are made on behalf of the technology and its capabilities at the start of a project which are close to unattainable and highly unrealistic.

Again, it’s not the technology’s fault. It’s the people creating and marketing that technology who are frequently culpable. And yet, they’re often the ones that emerge reasonably unscathed from the wreckage. It’s not unusual for those companies to be awarded more IT contracts by the same governments.

There’s a famous quote from Samuel Beckett that goes: “Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.” The history of IT project failures would suggest that far too many organisations and technology providers have taken that advice to heart a little too enthusiastically.

Read more on Managed IT Services

Join the conversation

2 comments

Send me notifications when other members comment.

Please create a username to comment.

In addition to the claims that are made about the technology, there’s also, quite often, a failure to communicate the complexity of implementing a project, which can lead to the perception that the project is failing or has failed. I was once asked to assist with a post mortem on a project to implement a new resource scheduling application that the users were claiming as a failed project. During the course of the interviews, one of the key users stated that he didn’t understand what took so long - all we needed to do was run down to the store, buy the software, and install it on a computer, right? In speaking with the PM, he told me that he just assumed that everyone knew what was involved in the process.
Cancel
"Charette argues human decisions are at the root of nearly any problem,
including sloppy code, insufficient testing, poorly understood
dependencies and incorrect assumptions."

That (again) reminds me of Gerald Weinberg.
"The Second Law of Consulting:
No matter how it looks at first, it's always a people problem."
The Secrets of Consulting

"One way for managers to avoid mentioning that they have a problem is to label the problem a "technical problem." Technical problems aren't really supposed to be a manager's responsibility. Besides, in a high technology business, it wouldn't be possible
to keep all the expertise you need on the payroll.
Even when it's "really" a technical problem, it can always be traced back to management action or inaction. Even so, the experienced consultant will resist pointing out that it was management who hired all the technical people and is responsible for their
development. At the same time, the consultant will look for the people who should have prevented this problem, or dealt with it when it arose."

Cancel

-ADS BY GOOGLE

ComputerWeekly.com

SearchITChannel

Close