Why IT Projects Fail


Before you ask, yep, I’m an IT guy, and a highly technical one at that. So why am I talking about failure of IT projects? Because it’s absolutely critical to understand. For me, knowing the key signs of an IT project that’s doomed and destined for failure means that I can prevent projects that I am assigned to from meeting the same fate.

For you, the business executive I’m working for, this means realizing the ROI, solving the IT pain point, or, from the most general perspective, reaching the success factors laid out in the project. Here are the top three things I look for in an IT project that tell me something’s wrong. Oh, and I have a solution for it at the very end…


1 Unreasonable Expectations

In today’s business landscape, technology seems to be this elusive creature. It is simultaneously capable of granting your business near mythical powers to achieve amazing things, and/or causing your organization to completely crash and burn if one thing goes wrong.

Take email, for example. Not even 10 years ago, communication was so much more limited. People were using email, sure, but they didn’t have a smartphone that gave them 24×7 access to it. At best, you could expect an answer some time during business hours. And even 10 years before that, the phone was the quickest method. If you left a voicemail, you’d be lucky to hear back within 24 hours.

Flash forward to the here and now. Not only do we have constant and instant access, if you leave me a voicemail, I’ll get it as an email and I can respond right then and there, no matter my location. Employees and business owners expect the same “magic” when it comes to most other technology-related components. Whether it’s their servers, switches, hard drives you name it…we demand instant and constant access.

The same thing holds true for projects. With the commoditization of IT, technology that would have been a dream a couple of years ago is now affordable for even small businesses. However, there are still plenty of cases when I see a company that has sky high expectations for a much more grounded price. Nine times out of ten, when I see unrealistic expectations, it’s a business owner believing that a project can be accomplished for much less than is realistic and again, 90 percent of the time it’s simply not possible. Something will have to give, whether it’s the quality, the expertise or the completion of the project.

Reasons for IT project failures, People and IT project failure, I.T. project goals, successful, riskIt’s critical to view your business IT expenses as investments rather than costs. If you are making an IT purchase and trying to cut costs (rather than save money), take some time to examine your project. Often, it’s critical to lay the foundation properly now. With the way innovation works, there are always bigger, better and more “magical” things coming down the pipe. You don’t want to have a shaky foundation that can’t support your business’ future needs.


Even worse, you don’t want to get halfway through a project and find out that a huge piece was missing and discover that the price for the project will now double. It’s much better to have a realistic picture from the start, along with financial justification for that cost.


2 Shifting Goals

Almost as important as a realistic view on expectations, is to have goals set in stone for your project. From the initial planning phase, you must map out some measurables. On the first level, this will help the engineers determine the best course of action as they work to solve your business challenge. On a second tier, this will enable you to determine success at the end of the project.

There’s no way to decide if a project is financially justifiable or whether you achieved the ROI you were expecting if you did not have concrete, objective goals from the onset.

Of course, there will be occasions when you need to change goals. One of the top reasons for this would be setting out on a project with unreasonable expectations. However, before you change anything at all, sit down and take a deep dive into the project. Truly root out the problems and troubleshoot for their causes. It’s vital to determine what is going wrong and why before you change any goals or desirable outcomes, otherwise, you might not achieve anything.

3 Irrational Deadlines

I suppose this could fall in with the first point, but I think deadlines deserve a discussion on its own. Similar to cost, there is going to be an amount of time required to complete a project. Again, it’s critical to determine what is reasonable and what’s not.

This does not refer solely to the time it will take to complete the project, although that is likely the most important component here. A deadline could also be the different individual stages of a project, some of which might require downtime or some other hardship for your business.

Planning ahead for this – similar to a business continuity plan – can mean that this won’t affect or frustrate employees. But the ultimate key is ensuring deadlines are met.

Like the goals pointer (see how all of this ties together nicely?), it’s critical to examine why deadlines are not being met. Preferably, you would be able to do this before the deadline is missed and correct the course of action to ensure it doesn’t happen again. Often one missed deadline leads to another.


4 The solution

As promised, here’s how to avoid this from happen within your organization. Please note it’s not a quick fix.

The key to all of this is planning. If you have the internal expertise start by gathering your team. Then collaborate with them so you can ensure they fully understand your intention for the project. All of these details will enable you to create realistic expectations for cost and time. From this, you can also determine the measurables – what are your goals and how will you judge whether this project was successful.


If you don’t have internal IT resources to call on, start by bringing in external experts. Ensure they take the time to get to know your business and your pain point. Try to find one who has worked with organizations similar to yours (particularly your industry and size) and see if they have seen similar issues and if they have been able to successfully solve these problems in the past.

At NetGain Technologies, we would call this period of exploration an Architectural Design. When a client has a serious business challenge that we can solve, there are a lot of other variables within their environment that are challenging to account for…unless we have an architectural design. This is a planning period when our engineers go to the drawing board and determine exactly what needs to be done, step-by-step, to solve a client’s business challenge based on the communication they had with the internal staff. It is a separate project that provides a written, detailed plan of action for the timely and successful completion of a project. It takes the worry out of the actual project – including the assumptions and risk.

IT is one of the greatest frontiers in innovation today. We have to be ready to put our minds to great use and develop the tools that solve business challenges and provide newer, better ways to do things. This comes with risk, but the innovating still must be done. As I said, an architectural design, or any intense period of planning, will enable the engineers to take the time, innovate, and find the best solution to custom-solve the problem, removing much of the fear and consequence from project failure because they are completing the project hypothetically first.

Once your technical resources – whether internal or external – know exactly what is necessary, and you’ve done the proper planning to establish reasonable expectations, solid goals and rational deadlines, you’re ready to begin the project with confidence.


Photo Credit: WernerKappler & Bb. Art

Related Posts