I came across a WSJ article a couple of weeks ago that’s haunted me since I read it. It was a piece about the shift in company attitudes from “grow at all costs” to “we’ve got to get operationally efficient.” The authors report that the primary driver behind this shift—which came as no surprise—is the end of the era of free money.
Many, myself included, have bemoaned the inefficiencies that arise when the cost of capital is zero and companies are rewarded for fiscally irresponsible behavior. That said, the purpose of this piece isn’t to rant about corporate excess. It’s just to say that I applaud the shift. It’s long overdue. I’m glad the WSJ is talking about it.
The article went on to explain that technology is now being pitched—as it has been in the past—as the path to operational efficiency. As a lifelong IT guy, I agree with this idea too. There’s no question that technology can make an enormous difference in the operational efficiency of a business. We at Bridging Business & IT did a podcast a year ago on Nestles’ digital transformation that was a wonderful illustration of how a company can use software to dramatically increase productivity, cut costs, and take their business to a new level. But, as we examined in that podcast, those gains came only after Nestle failed miserably, went back to basics and did the heavy lifting that was necessary to fully understand what they needed to do. (If you’re interested, you can listen to that podcast here.)
So, while I agree with what the article said, I have a problem with what it didn’t say. Something big was missing that needs to be addressed. There’s a hidden irony to tech enablement that’s universally acknowledged in private but rarely discussed in public. It’s the dirty, not-so-little secret of IT departments and IT Project Management Offices. Projects that attempt to leverage technology to accelerate business performance fail at an appalling rate and waste a fortune.
In January, 2021 the Consortium for Information and Software Quality (“CISQ”) released The Cost of Poor Software Quality in the US: A 2020 Report. You can download it here. Around the same time the Standish Group issued their 2020 Chaos Report which looked at IT projects in 50,000 companies. McKinsey & Company, Oxford University, Gartner, Infotech, the Institute of Electrical and Electronics Engineers (“IEEE”), and others have studied this topic at length. Here’s what they’ve found.
If you’re running an IT project that costs over a million dollars (and it’s remarkably easy to cross that threshold), the odds of a total failure, complete write-off are one in three. The odds the project runs way over budget, behind schedule, or under-delivers are one in two. The odds of it going so badly it threatens to bankrupt your business are one in six. Taken together, you have better odds playing Russian Roulette with five out of six bullets in the revolver than successfully undertaking a large enterprise IT project. Let that sink in for a second.
Those are the odds, now let’s talk costs. The smoking craters waste $260 Billion a year. Those projects that eventually limp into production but never do what they’re supposed to do so they have to be continually remediated over their service lives waste another $1.56 Trillion. In total this is $1.8 TRILLION per annum in the US alone–roughly 8% of US GDP.
According to the IEEE the reason these numbers are so big is because roughly half of all IT staff time is spent fixing things that should have been done right the first time. The costs to fix a problem after the fact can be 100 times more than it would have been to do it right up front. So the next time someone says, “We’ll fix it later” you can share this nugget and explain why such rationale is fiscal idiocy.
Now let’s turn to the cause of these failures. If you look at the research into why IT projects fail, about 75% of all failures are attributable to one thing–regardless of whether the governance model is waterfall, agile, or anything in between. Businesspeople never fully communicate to the tech team what it is that the new system needs to do and why it needs to do it. There’s a silent void where business requirements need to be. That void is comprised of three things. It’s all the things the business forgets to tell the tech team. It’s all the questions the tech team forgets to ask. And it’s all the assumptions they both forget to confirm. Three out of four times a technology enabled business project fails, the problem isn’t technology. The problem is all the things the people associated with that project forget to say.
Over the last three years I’ve dug into the research on this topic, conducted hundreds of interviews with industry analysts, academics, and practitioners, and given scores of presentations to groups like IEEE, PMI, SIM, AITP, the CIO Forum, and IIBA to share what I’ve found. To date I’ve presented to a few thousand people. And much to my surprise, not once, has anyone pushed back on the information I’ve shared above or expressed any dissenting view–even when I started asking them to tell me I was wrong. You see, I didn’t want to believe this problem could really be this bad or that its cause could be such a readily avoidable oversight.
Following one such request a little over a year ago, one CIO from the New York area explained to me, in a rather colorful way, why nobody disagreed with what I was saying. He started like this. “It’s like if we went back to Manhattan in 1890.” Not having a clue what he was talking about, I asked him to deal me another card. What did he mean? He continued, “Well look, if you could go back to a street corner in New York in 1890 and walk up to some guy and say, ‘Hey, there’s horseshit all over the streets.’ The guy would look at you like you were nuts. He’d say, ‘Of course there’s horseshit all over the streets. We use 20,000 horses in this town every day to move people and goods around. Horses shit, that’s what they do. There’s nothing you can do about it.’ That’s the same reason nobody is pushing back on you. We’re all wading through the horseshit you describe every day. There’s nothing we can do about it.” After everybody stopped laughing, all I could say was, “Point taken!”
Although I have come to agree with my horseshit-storytelling-friend and accept the reality of our collective predicament, I disagree with him on one point. I think we can do something about it. I believe there is a relatively simple solution to this “forgetting” that will go a very long way towards solving 3/4ths of our IT project failures. It is decidedly low-tech and un-sexy. It is positively ancient, and it’s extremely inexpensive—which is why many IT consultants will never tell you about it. They would rather charge you 100X to fix the mistakes later. This solution also hides in plain sight. Unfortunately, most people never see it because they lack the breadth and depth of experience to spot the patterns that reveal the solution. There is at least one advantage to having worked in the business technology sector for 40 years.
In the coming weeks I intend to explain this solution in a series of articles. However, before I do I want to explain why this “forgetting” is happening and call out the myths and misconceptions that perpetuate it. I’m doing this because I find that it’s only after we understand what’s going on and why it’s happening that we’re able to truly understand how to fix it. I hope you’ll stay with me throughout this series. And I hope you’ll share your stories and experiences with me along the way. I’ll be back next week.
If you want to look ahead to see where this is heading in the next several weeks, check out this presentation I gave in December to PMI’s Global Summit in Las Vegas. Or download our whitepaper.
