Why do companies’ IT projects fail?

All too often, investments in technology fail to deliver the promised results. What causes these failures in a company’s IT projects, and what can organizations do to change it? Here are four identifiable causes and what organizations can do about them.

Do you remember that IT project your company launched that turned out to be a failure? The answer, of course, is yes: there are probably few organizations that have not been affected by some mishap, or worse, a disaster, in an IT (Information Technology) project.

How is this possible? Why, despite decades of implementing IT systems, do organizations still encounter issues with their technology projects? My colleague, R.M. Bastien, and I have studied hundreds of such projects and discovered that the root causes of technology investment failures or underperformance were rarely where executives thought to look.

The problem: they focused on the symptoms, not the true causes.

What are these true causes? Here are four that we have identified and what organizations can do about them.

One of the hidden causes is an investment process that begins when someone – typically an executive or budget holder – needs technology to solve a problem or seize an opportunity. Then, the IT department builds or acquires the technological solution, as all technology-related requests go through this single department.

The consequence is that, on one hand, there is the “customer” (the business unit), and on the other hand, the “provider” (the IT department). The customer wants to ensure they get what they paid for, so they will demand some project progress oversight and visibility of any risks. To do this, they may create a committee and establish appropriate information parameters, typically time and cost.

Unfortunately, all of this only gives them the illusion of control. What happens in the project, where hundreds of decisions can be made weekly, is likely invisible to the project sponsor. And those decisions can undermine the project’s final outcome.

As an analogy, think of calling an Uber and following the car as it travels to pick you up. This gives you the feeling of controlling the transaction. But it’s an illusion. Yes, the driver arrives on time, but the car is out of fuel, dirty, the driver seems intoxicated, and it has a small trunk that won’t fit all your luggage.

The IT department wants to be seen as a business partner, working closely with colleagues throughout the organization. Despite this commendable goal, IT units are mostly designated as cost centers, while the business unit is a profit center.

This means that the business unit’s priorities are not necessarily the same as those of the IT department.

The most apparent conflict lies in the practice of IT being responsible for setting the architectural standards for building systems and then designing, building, and certifying that digital systems conform to these standards. In other fields, such as construction, there is a clear demarcation between those who design, those who build what is designed, and those who own – and benefit from – the outcome.

In practice, this means that decisions systematically lean towards the builder’s priorities:

• Systems working on time and within budget.
• System quality.

The value it brings to the company is a distant priority

Imagine a project running behind schedule and exceeding the budget. It’s not uncommon. Solutions can be found to get back on track. The project team has solved a problem, the schedule or budget has not been compromised, and the business unit is unaware. The solution becomes another project’s problem in the future.

When the project is completed, the business unit will never be aware that a shortcut was taken; the digital asset will function, and there will be celebrations all around. However, this decision could compromise the performance of the application that has been built It may not be immediate, but when transaction volume increases, perhaps within a few months or even years, it may manifest in response times and dissatisfied users.

Think of it as a contractor building a house who decides to save some money and not use industry-standard plumbing pipes. With this solution, the shower will still work, as will the washing machine. And, most importantly for the contractor, the client will be happy with the new house. However, problems will arise if the client wants to replace the washing machine, install a dishwasher, or perhaps build an extension.

A project, by definition, is a temporary endeavor Therefore, when a technology project is completed and functional, it’s done. People move on to new projects or new companies. The past is forgotten.

At some point in the future, a new project is launched that relies on the integration with digital assets created by many projects over the years. But when new project team members start working, it’s a bit like an archaeological dig, not knowing what they will find until they begin. As the project progresses, unknowns are likely to arise that can derail it.

The most glaring example of IT amnesia is documentation that describes what has been built. Gathering it serves only future projects, while consuming precious time and money in the present, so it is often neglected.

However, this documentation will be crucial if something needs to be modified, perhaps due to a new compliance or regulatory requirement or a new business need. The teams responsible for carrying it out will need all this knowledge if they want to undertake this task Without that documentation, their work will be difficult, and they will have to recreate it. nd often, they can’t, at least not as well as they would like.

What we observe is that a project-focused IT department systematically creates these deficiencies that will impact future projects. Ironically, focusing on a project’s success leads to its failure in the future.

Considering the substantial amount spent on technology, one would expect these digital systems to be treated as assets and managed as such. . In other words, one would expect digital assets to be managed like power plants, cargo ships, or any other investment of that magnitude.

But that’s not the case.

The reality is that technology doesn’t have inherent value; the mere deployment of technology on time and within budget doesn’t automatically translate into any business value. It requires a lot of effort from the business unit to realize the expected benefits. While IT closely monitors the construction and maintenance costs of the asset, few organizations actively manage the realization of benefits from using this asset.

Compare this to airlines. Airlines know that if planes don’t fly, they don’t generate revenue, so they seek to maximize their time in the sky, transporting passengers. In contrast, most organizations do not actively manage to ensure that the expected benefits of technology are obtained. Technology arrives and “works.” But does it increase value for the company? That question is rarely asked.

Individually, these hidden causes have a significant impact. Collectively, their impact can be devastating for achieving the intended business outcomes.

• Seek value, not funding. The model for this drives much of the behavior we see in organizations. An entire project is funded, and the IT team starts working on it. Adopting a more phased funding approach, where complete funding for an investment is not guaranteed but contingent on demonstrating progress, reduces risk. However, it also means that the continuation of a project is determined by evaluating the usefulness of what has been delivered at a given moment and demonstrating results.

However, to demonstrate business-related results, it’s necessary to have a deep understanding of the business, which can be hindered by the division between the IT department and the rest of the organization. So, organizations need to find ways to bridge the gap between IT and “the business.” More on this in a moment.

• Own and manage digital systems as productive assets. Just as a plane parked on the runway doesn’t generate revenue, the value of technological assets must be actively managed. . What helps is having clear ownership of the digital asset. Our suggestion is that it should belong to the one who pays for it. . After all, they will be the ones reaping the benefits and, therefore, should be responsible for ensuring that they are achieved.

The CEO of one of the studied companies has made it very clear to those seeking IT funding that he is likely to call them back before the investment committee, many years after a project has ended, to demonstrate that the benefits they listed in the business case for the investment have been realized

Like all assets, there comes a point when the asset ceases to be an asset and becomes a liability and a hindrance for the organization to achieve its strategic ambitions It never ceases to amaze us how companies continue to use applications that are never used.

Eliminate conflicts of interest. To achieve this, there are three types of functions that should be dissociated:

1. Those who set the design standards for digital assets from those who build and maintain them.
2. • Those who check the quality compliance of what is created from those who create it.
3. • Those who manage projects from those who use the project’s creation.

Doing IT differently

The genesis of the problem that most organizations have with digital technologies is how they are currently organized to adopt them; they are designed to manage IT rather than generate value from it As I’ve written before, the answer is to get rid of the single IT department.

That doesn’t mean getting rid of IT. It means integrating IT into all departments, so that those creating digital assets genuinely collaborate with those who will derive value from those assets.

No executive intends for their organization’s IT to fail or underperform.

However, the decisions they make unfortunately lead to failed projects, negative outcomes, and wasted investments. These executives, though in influential positions, simply do not know what it takes to succeed with technology in today’s digital world. Essentially, they don’t know what they don’t know. They are working from a fundamentally flawed cognitive map, leading to erroneous decision-making. Unless this is remedied, your organization will continue to achieve poor results from IT investments.

Publicado originalmente el 16 de October de 2023, modificado 22 de February de 2024