Why Did Your IT Project Fail?

Why do investments in technology often fail to achieve promised results?

Most employees at nearly any size company have seen an IT-related project launched, with less-than-spectacular results. Of course, some organizations are better at it than others, but most are still struggling with their technology initiatives, even after years of improvements in the implementations of IT systems.

An extensive analysis uncovers that the root causes of underachieving tech investments aren’t overly apparently; in fact, you have to look hard to find them…because while it’s easy to focus on symptoms, it’s harder to identify the true causes. Here are the top four:

#1: Conflicts of interest 

The IT department wants to be an equal part of the organization, even though most tech divisions are really cost centers (they cost money, and don’t generate revenue). IT is responsible, for instance, for setting the architectural standards for their projects, and then designing, building and certifying these standards. In the construction industry, for example, it’s clear which departments design, which ones build, and which ones own the result.

Of course, this means that decisions are titled toward the builder’s priorities – to ensure that systems are working, on-time and on budget. Quality is not at the top of the list of priorities.

For a project that is running behind schedule and overbudget, workarounds can be found to get the project back on track – but typically, what we now have is another project! And the cycle repeats.

#2: Control – or Lack Thereof

The common denominator with these causes is that there’s a stakeholder that needs technology for some specific reason – either to capitalize on an opportunity, or to solve a problem. It’s the responsibility of the IT department to either build or acquire the solution.

As a result, the business unit wants to know it is getting what it signed up for, and it will require oversight of the progress and risks. Time and cost are the likely metrics.

But the business unit only receives the illusion of control; when there are countless decisions being made every day by the technology team that can undermine the ultimate outcome of the project, the end result is often left to chance (at least from the business unit’s point of view).

It’s similar to using an app to get a rideshare: you think you’ve determined that a car will drive you somewhere when you want it…but what happens if the driver is late, or the car is out of gas, or if it’s dirty? What if you don’t have room for your luggage? You don’t control the details, which ultimately might matter just as much as arriving at your destination.

#3: Don’t manage assets, manage expenses

With all of the money spent on technology, you could be forgiven if you expected that the end results of the projects would be considered as assets, but this isn’t always the case.  More often than not, the technology has no inherent value, and there’s typically ongoing work required to realize ongoing benefits.

It’s similar to the hotel business, in which an empty room on any given night returns zero value to the hotel. Hotel managers will get creative to fill their rooms, but organizations won’t always get overly creative to use technology just to maximize its value, and few organizations ever attempt to make the cost realization worth it after the money is spent.

#4: Build it and forget it

All projects are temporary, and people move on after projects are completed. At some point, a new project begins, and it might depend on integration with previous digital assets. Starting a dependent project can be like uncovering an ancient city – secrets often abound, and project-derailing unknowns are likely to emerge.

And past documentation doesn’t always help; ideally, it serves future projects, but it’s an often overlooked (and poorly-completed) task, as it only matters to future stakeholders, not current ones.

Of course, documentation is critical if a new compliance or regulatory requirement arises, and the teams that are responsible will require this knowledge to be successful. Without it, jobs are made that much harder, and there’s nothing worse than having to recreate documentation (that, again, will only be needed for future stakeholders). It’s a vicious cycle.

I’ve found that an IT division that is project-oriented will typically embody these shortcomings repeatedly, and they will no doubt affect future projects repeatedly.

What Can Your Company Do?

By themselves, each cause has a significant impact; together, their impact can be monumental.

Here’s how you can tackle these issues:

– Find value, don’t find funding. Showing business results requires a fundamental understanding of the bsuiness needs, and an understanding of what needs to be managed moving forward. Find the value before you get any project approved.

Treat digital systems as assets. Your IT projects should be viewed much as the hotel in the above example. Figure out ways to maximize the value to the company on an ongoing basis before the project starts and gets the go-ahead.

Remove any conflicts of interest. Uncouple the roles of those who establish design standards, those who are responsible for quality compliance, and those that manage the project. They can’t be the same people, or even report to the same people.

Look at your IT in a different way. The only true way to ensure that your IT is working for you is to find a trusted partner and outsource your IT. You need an organization (like Infracore!) that is constantly incentivized to work in your company’s best interest – if only for their own best interests.

No one starts an IT project with the intent to fail. But decisions are constantly made that lead to failed projects and often-wasted outcomes. Hopefully these points will help you view your IT differently for your next big project.

Leave a Reply

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

Prove your humanity: 1   +   2   =