Why Do Technology Projects Fail? Is Failure a Feature or a Bug? — Opening Statement
CUTTER BUSINESS TECHNOLOGY JOURNAL VOL. 34, NO. 8
The Scope of the Failure Problem
Technology projects continue to fail at an astounding rate, and the number and cost of these failures are stunning. According to those who study enterprise resource planning (ERP), big data, and innovation projects, the majority of these projects fail, and sometimes spectacularly.1 There’s an entire industry devoted to studying why these projects collapse and how the number of failures can be reduced. But since failure persists, the advice is either wrong, ignored, or not focused enough on the real causes: poor talent, weak executive support, and resistant corporate cultures.
There are tons of studies about why everything fails.2 Are these findings helpful? Evidently not, since — as everyone likes to say these days — failure is a feature, not a bug. The massive ERP business, for example — likely US $75 billion by 2030 — routinely experiences failure, and sometimes famously.3 CRM projects backfire at nearly the same rate.4 Big data analytics projects also fail at an alarming rate.5 And digital transformation is unsuccessful 70% of the time.6
Failure data is everywhere:
In 2012, the US Air Force invested seven years and a billion dollars on a failed systems integration project, which resulted in a program with such limited potential that further investment would have wasted another billion dollars.7
In 2016, Southwest Airlines had to cancel 2,300 flights and delay 7,000 more when a router failed. Later that year, Delta and United were impacted by similar outages.8
In 2018, international travelers arriving in the US around the New Year's holiday period were forced to stand in long lines for two hours after the US Customs & Border Patrol computer system failed. Though this was an improvement from the year before, when a four-hour outage affected more than 13,000 passengers.9
Why Projects Fail
So why do so many technology projects fail? Figure 1 presents a root-cause analysis developed exclusively from ERP, big data, and innovation failures literature and shows six baskets of problems: definition, scope, management, talent, support, and culture. Project definition, scope, and management problems are almost self-explanatory; talent, support, and culture problems are less so. The same failures research suggests that definition, scope, and management problems can be “solved” with some professional discipline. The literature also shows that not only are talent, support, and culture problems the most difficult to solve, they’re also the ones avoided the most, which explains why so many projects fail and will likely continue to fail.
Certainly, project-definition problems are well known. Weak business cases consisting of ill-defined project objectives and vague performance metrics have plagued us for years. “Scope creep” is ubiquitous and usually rooted in poor requirements management, specification, and validation. Definition, scope, and management problems are “normal”; they are the ones we always talk about when projects fail. Research suggests that these kinds of problems can actually be solved to some extent with professional discipline, so long as there’s a strong, persistent willingness to practice the discipline — which there usually isn’t.
While there are well-developed playbooks for defining technology projects, reducing scope creep, and managing projects “better,” there’s also a stack of playbooks available for acquiring and managing talent, improving project support, and even tweaking corporate cultures, which are the real problems. But these playbooks are ineffective because they only offer conventional solutions, such as better training, clearer governance, organizational awareness, and improved leadership sensitivity, along with other solutions that have proven ineffective for decades. The root problem is that conventional solutions seldom, if ever, address the real problems around talent, support, and corporate culture.
Are We Doomed?
Failure research segments problems into “really tough” and “impossibly tough” categories. It tells us that many problems can be traced to leaders and the teams that enable their decisions and also reveals that a lack of objectivity is the greatest predictor of project failure. At the end of the day, successful technology projects depend on the willingness to make extremely hard decisions about people, processes, and cultures.
Are we doomed? One of the best ways to avoid technology project death is to stop thinking so ambitiously about technology projects. We should think twice about doing “big” enterprise projects at all. Big projects are far more likely to fail than small ones. Skilled CIOs and CTOs should understand that a huge part of their job is managing expectations downward. A smarter but tougher approach is to set expectations as low as possible while still generating project excitement. Given the failure rates when it comes to big technology project management, everyone should learn to dance in slow, small steps, not large ones. Resist the tango for the waltz.
Another way to avoid failure is to recommit to the discipline necessary to deal with the conventional problems. Sure, we could give up on conventional solutions to the same old problems, or we could look for more creative ways to solve some of these problems — as we do in this issue of Cutter Business Technology Journal (CBTJ).
In This Issue
This issue of CBTJ is devoted to failure. The contributors, God bless them, refuse to give up, refuse to accept the notion that failure is a feature. Cutter Consortium Fellow Robert Charette starts us off by looking at failure through an incredibly intriguing lens: what if failure is “the desired outcome of an IT project development and that success is inadvertent.” What? He then proceeds to define failure in a fascinating new way, asking if failure is defined as:
… keeping an IT development project alive as long as possible, or even better, until it achieves operational status, but with so many flaws that copious amounts of money are allocated to make it usable. A much less desirable failure in the latter case is that no amount of money is perceived to be enough, and the operational system is terminated. If the project is reliable, delivered on time, and on budget, well, that would be considered an unintended mistake.
He then proceeds to set the “conditions” necessary for the pursuit of failure, as it’s been defined. Hype, or as he calls it, “puffery,” needs to exist among vendors and the recipients of their pitches. Next, the vendors proceed under an agreement that failure along the way will still be financially rewarded. Then, current users accept laboring under the existing system’s functionality. Many of them are more than OK with this since many oppose change of any kind simply because they’re afraid, lazy, or worse. Finally, we need the internal champions of the project to stay with the company and continue to hype it because they have professional vested interests in doing so. Charette sums it up simply: “Are there other missing ingredients? Certainly, but these are sufficient to nearly guarantee a profitable IT project failure every time.” He then goes on to test — and largely confirm — his “cynical theory.”
There’s no question that technology projects fail all the time, and that failure has many beneficiaries. Is this just the nature of the beast? An inherent problem with the technology, technology projects, and “management”? I fear that Charette, as usual, is right on the money. Yes, it’s likely that failure is a feature, not a bug.
Ralph Menzano takes us directly into the C-suite for the second article through a series of discussions he had with CIOs and other executives about why so many damn technology projects fail. His article probes some of the causes of failure often ignored by the research community. As a former CEO and CIO, Menzano can relate to the reasons, which include a long list of essentially strategic management challenges. Some of the most diagnostic include:
Fully examined ROI calculations and project justifications
Co-ownership with IT and business unit(s)
Technology applied to business issues
Being in step with industry
Organizational and personal courage
Now we’re getting somewhere! Here’s just one of many important takeaways from his analysis: “Waiting for a big bang, splashy, go-live date hardly ever works. Incremental deliverables, though far less exciting, almost always work.” The discussions of organizational patience and personal courage are especially insightful — and revealing. Indeed, Menzano shares a personal experience about receiving death threats while implementing an inventory control system. (Read the article to learn how this ends.) His report is a must-read for anyone connected with technology projects. It’s cold water in the face. I’ve read it three times.
Anjali Kaushik follows Menzano’s sobering analysis by attempting to unfold the mystery of failed technology projects. Her examination drops into the trenches and also addresses the first three causes in Figure 1. But Kaushik’s analysis is anything but conventional. She begins by looking at the necessity and meaning of process redesign — and shares some excellent advice:
If you have changed your processes, make sure to revise the performance metrics to align with the new ones. The information systems should also align to the process, and the performance metrics should be based upon them.
She then turns to some old favorites, like scope creep, where she suggests a highly disciplined approach to scope, project, and vendor management. She identifies stakeholder management as a major failure variable, which is an excellent focus. Small prototypes can lead to larger-scaled products — MVPs— but not always. So be careful here, she warns.
Kaushik’s advice to match technology projects to complementary assets and capabilities is especially helpful. “People, processes, governance structures, culture, policies, and top management leadership are equally important aspects,” she says. Kaushik notes that the above occurs within the context of change management, governance, and resource allocation, and she ends the piece with advice about how to avoid failure:
[A project] … is not just about IT infrastructure or writing the code or designing the database. It is about gaining consensus across divergent stakeholders — and much more than that. A successful implementation requires the right strategic vision and matching it with a series of actions chosen for their potential to fulfill that vision.
Perhaps the strongest aspect of the article are the real cases discussed. When I first read the piece, I was impressed with how the observations and advice are all anchored in reality, and in the trenches.
Next, Sridhar Deenadayalan stays in the trenches to offer a playbook in the form of five keys to a successful technology project. The strength of this article lies in its two-step approach to failure management. Problems are identified, then followed by specific actions, or “keys to success,” to address them. At the beginning of a project, he writes, defining the problem and stressing the business value can help identify a solution. He offers these keys to success for this stage:
“Translate the business problem statement in technology terms at the very beginning.”
“Identify the right sponsor based on the translated business problem statement. This should include a C-level person who can influence and serve as an active advocate throughout the project lifecycle.”
It’s impossible to argue with this guidance, which is followed by advice about skills and competencies assessments, planning realities, implementation, and operationalization. Here are some real gems:
“Tech project assessment needs to evaluate an additional dimension beyond technical skills: a willingness on the part of employees to participate and contribute.… People with the required technical skills but a mindset inclined to protest change can be dangerous.”
“Devise a plan to retain key resources before embarking on major projects that are dependent on specific skills.”
“Develop a rollback strategy that allocates appropriate time to a possible implementation failure, as rollbacks sometimes can take more time than the new implementation.”
“Ensure the sponsor continues to remain active and voices the value of the change generated by the project to all the impacted groups — or even the entire organization.”
Finally, Shasheela Devi Karuppiah, Ezuria Nadzri, and Govindan Marthandan conclude the issue, focusing on the role that communication plays in technology project management. They suggest that many conventional problems as well as some more strategic ones can be reduced, if not solved, by developing a communication plan that spans the entire project lifecycle, beginning with the stakeholder communication strategy. Smartly, they focus on not just content of communication but on form as well. They distinguish between “standardized” versus “customized” content, which is tailored to the intended recipients. Communication methods ranging from formal to informal are identified, with the suggestion that reports and briefings should be supplemented by a variety of informal communications:
A push method is suitable to disseminate intended information to stakeholders via emails, reports, memos, or press conference. A pull method usually provides information to stakeholders at their own discretion via wikis, blogs, or software that supports collaborative working.
The standard formula N(N-1)/2 is used by project practitioners to determine the communication channels required. The N represents the number of team members whereby an increase in team members requires extra channels and efforts for communication and to ensure everyone is kept informed.
The authors then turn to velocity, the speed of communication that prioritizes stakeholder groups to ensure that the right information gets to the right place at the right time. And frequency? It’s easy to bury stakeholders and participants in data. We do it all the time. But is it too much or not enough? Too many meetings or too few? Too many PowerPoints or not enough? Frequency calculations should be made to determine the right balance.
Interpersonal communication has a challenging but necessary role in technology projects. Karuppiah et al. explore how these exchanges of ideas, information, and experience can create different types of project conflict. These conflicts can be managed, but they require healthy degrees of emotional intelligence, solid diversity acknowledgement, conflict management, and the ability to objectively accept new ideas. Yes, this is about personality, which is always a major communications variable. As they suggest:
… developing a communication plan requires critical consideration of multiple aspects: human, financial, technological, and procedural.… Customization is the key to ensure a successful communication management plan that will result in project success.
The usefulness of this article lies in its specificity about communication plans, which can be developed around all kinds of technology projects. Chances are we haven’t thought nearly enough about all the dimensions of a successful communication plan — though we should.
This issue of CBTJ addresses the tactical, operational, strategic, and human reasons that allow technology projects to fail. It offers some new thinking, tells some great stories, and at the end of the day suggests that we’re not forever doomed. But to avoid failure we must rethink and recommit to solutions that can help reduce its frequency. Of course, I am not suggesting we can ever eliminate failure — that’s impossible for reasons we’d need 10 issues of CBTJ to explore. But reduction is good. Like I said, resist the tango for the waltz. Enjoy the issue.
1Forrest, Conner. “The 20 Biggest Tech Disasters of All Time.” TechRepublic, 14 October 2016.
2See, for example: Florentine, Sharon. “More Than Half of IT Projects Still Failing.” CIO, 11 May 2016; Lee, Jeanne. “9 VERY Scary ERP and ERP System Implementation Statistics.” ERP VAR, 31 October 2014; “Chaos Report: 2015.” The Standish Group International, Inc., 2015; and Liebowitz, Jay. “IT Project Failures: What Management Can Learn.” IT Professional, Vol. 17, No. 6, November-December 2015.
3Fruhlinger, Josh, Thomas Wailgum, and Peter Sayer. “16 Famous ERP Disasters, Dustups, and Disappointments.” CIO, 20 March 2020.
4Guethoff, Anne. “Why 70% of All CRM Projects Fail … And How Yours Will Not Be One of Them.” LinkedIn, 4 May 2020.
5See, for example: Henrion, Max. “Why Most Big Data Analytics Projects Fail.” ORMS Today, 4 December 2019; McShea, Chris, Dan Oakley, and Chris Mazzei. “How CEOs Can Keep Their Analytics Programs from Being a Waste of Time.” Harvard Business Review, 21 July 2016; McShea, Chris, Dan Oakley, and Chris Mazzei. “The Reason So Many Analytics Efforts Fall Short.” Harvard Business Review, 29 August 2016; and Remington, Steve. “How to Avoid Analytics Failures: 10 Factors for Analytical Success from Research and Practice.” Minerra, 25 November 2018.
6Saldanha, Tony. Why Digital Transformations Fail: The Surprising Disciplines of How to Take Off and Stay Ahead. Berrett-Koehler Publishers, 2019.
7Charette, Robert N. “US Air Force Blows $1 Billion on Failed ERP Project.” IEEE Spectrum, 15 November 2012.
8Forrest (see 1).
9Charette, Robert N. “2018’s IT Failures Already Have a Familiar Look.” IEEE Spectrum, 9 January 2018.