Crash and burn: Why do large IT projects fail so often?

Large IT projects continue to fail, often with disastrous results for the organizations involved. The most recent example of this that came to my attention is the legal battle between Hertz and Accenture over delivery of a new mobile digital platform that would provide business processing and e-commerce capabilities to deliver better services to Hertz customers around the world. While the impact of this situation upon the two companies involved remains to be seen, a report issued by McKinsey Digital in 2012 said that “17 percent of IT projects go so bad that they can threaten the very existence of the company.”

Why does this kind of thing keep happening? Does the IT profession really not know how to deliver what they seem capable of doing? Or are the failures more related to other areas such as project management or corporate politics? I’ve often discussed these matters with my circle of contacts in the IT profession and also with the half-million strong community of subscribers of our popular weekly newsletter WServerNews, and I thought it might be helpful for those of you involved in delivering on mid- to large-scale IT projects to share what some of my colleagues think concerning this problem. So without further ado here are five reasons why large IT projects often fail, presented in no particular order and largely based on the personal experience of those involved. If you have any additional insights to add from your own personal experience with failed IT projects, feel free to add these using the comments feature at the bottom of this article.

it projects

Too big to fail? No — not big enough!

“Projects have to be large enough to actually achieve their goals,” says Anthony, a network engineer working for an institution of higher education. I had argued with him that perhaps large IT projects should be broken down into a series of smaller projects that are implemented independently not as milestones in a larger project but as standalone entities by themselves. Anthony responded by saying, “Breaking certain projects into smaller projects is often literally not possible. Deep infrastructure like authentication services (Kerberos, Active Directory, etc.) can easily require ‘flag days’ where the whole organization is required to do something at the same time, often with limited possibility for backing out.”

Knowing what customizations will be needed for the customer

Anthony also had some thoughts on the matter of customizing software systems for the specific needs of the customer. “For many projects, the actual intricate details are not in the base system, but how it is and must be customized for local use. SAP and other software is often not meant to be used in a raw state. Budgeting and accounting software often has legal compliance requirements outside of the actual software project. Discovering halfway through a project that major assumptions about how a system is used are invalid is a problem.” Clearly customization based on localization requirements is something that those involved in IT projects need to consider early on before any procurement or deployment takes place.

Know what the end product you’re supposed to deliver actually is

Sometimes the blame for the failure of IT projects falls squarely on the ones developing the system or code they promise to deliver. “The number one reason any project fails is a false sense of perspective,” says Craig, who runs an IT consultancy in Australia. “I recall in my Air Force days that each section thought it was the reason the Air Force existed. I even had one radio tech state that the only reason the Air Force had aircraft was so they could get radios in the air. He was joking, of course, but it stuck with me because it highlights priorities. Everyone thinks what they do is the most important thing. So, with IT projects (of any size), the focus is on delivering software that does what the design brief says, doesn’t crash and is easy to use. It started life as an improvement to a business process but that’s long forgotten by the time code is cut,” Craig says.

“Programmers see their code as the end product,” says Craig, “when in reality it’s the business process. Too often the business process has to change in order to meet the requirements of the computer systems. Sure, often it includes improvements, but just as often it needlessly makes more red tape.” When I asked Craig what he thought was the answer to this problem, he replied, “My solution? Have a plan with a constant path for improvement and clearly defined business processes. But everything happens in small, manageable chunks.”

Stay focused on the customer’s wants and needs, but not tooooo much

“Most large IT projects fail for a number of reasons,” says another colleague, named Tom. One reason can be not staying focused on the customer as you work through the project. “Lack of feedback from the targeted end users,” Tom says. “It simply amazes me how often the end user is kept out of the loop. The best code in the world is useless if no one wants to use it. Won’t necessarily make a project perfect, but it will get much closer faster if the end user is involved.”

Tom also suggests you should “create what the user needs, not necessarily what they tell you they need. I have listened to and read great specifications for project. And the programming staff takes off the build what they are told. But what is required and usually lacking is the ability to understand what is asked for and translate that into actual code. The ability to translate is so lacking in IT, and in reality most projects of any kind. There is this belief that projects can be mechanized. And in fact much of programming or development can be. But the creative ability to understand what is wanted, not just simply state a fact of what is wanted.” I agree with Tom in this regard that delivering IT isn’t merely a science; it’s also a creative activity — an art.

There’s actually no such thing as an IT project!

Finally, this interesting insight was shared with me by Dave who is a retired project manager who holds the project management professional (PMP) certification. “In my humble opinion, the moniker ‘IT project’ is part of the problem. It tends to put the blinders on focusing only on the IT solution without continuing to monitor impacts to the rest of the business. This tends to be more prevalent the larger the IT project.”

“Projects should be related to business strategy, Dave says. “Technology can, and many times is, part of the solution to a business problem. Projects normally referred to as IT projects should be called business projects with technology as part of the solution. This change of perspective tends to keep all stakeholders engaged. Additionally, focus is on the total solution, not just the technology portion (hardware/software).”

Hmm, interesting point. So maybe we should stop thinking of ourselves as IT professionals and just consider ourselves professionals. If we shift our thinking like this away from the tech side and more towards the business side, then maybe we’ll start to act more like professionals too — instead of typical IT nerds!

Featured image: Shutterstock

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top