Having initiated a discussion during my last post about the frequency of enterprise IT project failures, it’s time to address two other parameters of this issue. I’ll start by looking at the annual cost of these failures and conclude today with an introduction to their primary point of origin.
So, how much do IT project failures actually cost the US each year. Well, it depends upon who you listen to—estimation methods and results vary.
If you look at the more conservative estimates, it’s probably safe to say that in the US alone, the hard dollar costs (out of pocket money wasted) of IT project failures runs about $500 Billon per year.
Per ZDNet, that number is comprised of $100 Billion in annual write-offs of abandoned efforts plus $400 Billion in rework on all the systems that limped into production but never did what they needed to do—so they have to be continually patched throughout their service life.
Robert Charette’s article, Why Software Fails – We waste billions of dollars each year on entirely preventable mistakes, in the Institute of Electrical and Electronics Engineers (“IEEE”) Spectrum magazine, noted that “…studies have shown that software specialists spend about 40 to 50 percent of their time on avoidable rework rather than on… work that’s done right the first time. Once a piece of software makes it into the field, the cost of fixing an error can be 100 times as high as it would have been during the development stage.”
Even issues missed earlier but caught pre-release (or go-live) carry a hefty price tag. Research has consistently shown that for every $1 “saved” up front by not taking the time to fully understand what the business is trying to do (note, we’re not talking about business requirements, we’re talking about the company’s mission—what it is that the organization is trying to accomplish) we will eventually spend $36 to $50 to fix what could (should) have been caught earlier.
We tend to overlook two things. First, there are no shortcuts. If you want a system that works the way you need it to work, you have to take the time (and spend the money) to do it right. It just happens to be far less expensive to do it right the first time than to redo it later.
Second, a botched software project is a thief that keeps on stealing throughout the life of the system. All in, at half a Trillion dollars per annum, that thief is stealing about two-and-a-half-percent (2.5%) of US GDP annually. This is money that would have gone straight to the bottom line as net income.
As I’ve done before—and will do again—I shall attempt to put this information into context. For every $100 Million in revenue that an average business generates, $2.5 Million is being wasted! By anyone’s reckoning, we’re talking about real money.
Now, let’s turn to the final parameter and look at why these projects fail.
Once again, across IT industry experts there’s near universal agreement. The vast majority of enterprise IT project failures are attributed to a lack of communication and a clarity thereof. Research by the Project Management Institute indicates that 74%, three out of four IT project failures are a direct result of communication failures.
These communication failures take two forms. The first arises when key executives and process owners simply do not show up and engage with the project team. They’re too busy, indifferent or otherwise preoccupied. The second occurs when those people do show up, but for one reason or another they don’t share everything that they know with the tech team who needs to know it.
As I said, these are normally described as communication failures, but that’s somewhat misleading. A communication failure implies that there is a problem in the way people talk to each other. In any given project, that may or may not be the case.
In the context of IT project failures the problem is not the way the business and tech teams talk with each other. The problem is what they do not say that needs to be said. We are leaving a silent void—a giant hole—where the specification of our system’s foundation needs to be. As a result, the people working on IT projects don’t understand what needs to be done, why it needs to happen and who needs to do it.
This silence is a little recognized, but pervasive problem throughout the business world. Gallup—with decades of organizational research and more empirical data on workplace communications than anyone on the planet—has consistently found that this problem extends far beyond IT, stating “…half of all US (and EU) employees don’t know what’s expected of them at work…(they) don’t know what their boss wants.”
There’s a rather obvious, but equally critical point to note about this silence. You can’t execute a business plan, if you don’t know what the plan is! If 19 out of 20 large IT projects fail—remember, 14 to 15 of those 19 failures are directly attributable to a lack of communication about the right things—and half of all workers don’t know what they’re supposed to be doing, then someone, somewhere, somehow is dropping the ball—on a massive scale—when it comes to communicating the basic information that’s essential for successful execution.
So, the $375 Billion question ($500 Billion in total loss multiplied by the 74% attributable to the communications void) is, why is this happening and how can we fix it? I’ll begin to wade into that discussion in my next post.
