5 Reasons IT Projects Fail

While mistakes are inevitable, nothing shakes the foundation of an IT department faster or causes executive confidence to wane quicker than a major project failure. There are numerous reasons why IT projects fail, from inadequate preparation to stretching the boundaries beyond what staffing resources can absorb.

Every environment is different and no two situations are identical, however there are overall patterns that tend to emerge when projects fall short of desired results. Here are five of the more common reasons why IT projects fail and some suggestions on how IT professionals can avoid these pitfalls.

1. Putting technology before business need
"Cool" is not enough. It is easy to be swayed by what is new and exciting. But it's important to remember that great business outcomes come at minimal cost. This means that the "why" and "what" have to be fully understood before proceeding with the "how."

2. Starting too soon
IT has a tendency to jump in and get started on projects before fully understanding the scope. This comes from pride in past success, as well as assuming that technology can overcome any difficulty. Not only is this a high-cost approach, it also dismisses the upfront hard work of getting business requirements and understanding where the 80/20 line should fall (with 80% of needs met, the 20% "nice-to-haves" may cost you the project).

There is no substitute for planning based on a thorough understanding of the project. My advice: Don't start fishing until you decide what you are trying to catch.

3. Never-ending scope
What starts off as doable can slip into a morass of add-on requests that are a prelude to tomorrow's legacy system. Requirements should be constantly brought back to the "why" of doing a project. The core of the project should take priority far above the flotsam and jetsam of extras. Otherwise you are guaranteed to miss deadlines, pay more, and endure complexity with features that seldom get used.

4. Not stopping when a project goes bad
It takes courage to put the brakes on a project after it has started, but sometimes it's the wiser course of action. Sometimes the wrong technology is picked, maybe the price of the software has increased or there has been a change in requirements. Any of these can lead to a cost-prohibitive project or one that contains more complexity than it's worth.

There is an old saying that discretion is the better part of valor; truer words have never been spoken when it comes to IT. Remember, every milestone reached needs clarity and positive proof points. It is far easier to throw good money on a bad project than to stop throwing money, but you need to pull the plug at times.

5. Unexamined ROIs and miscalculated lifetimes
Many projects have ROI calculations as a "check-box" item. especially when project costs are believed to be low or the results are believed to be spectacularly good. You must constantly be on the lookout for the slippery slope for when "free" solutions can turn into major costs.

Similarly, many projects are not thought through as to when they will approach end-of-life, and what their upkeep will cost until then. Thus, many IT projects never fully pass on to the business, but are a constant generator of requests for IT to tweak the system. Many dashboards and reports fall into this category. I was told from early on in my career that nothing in life is free -- words to live by in IT.

Heading up an IT project takes a lot of foresight, planning, conviction to stay the course, and courage to alter your course when necessary. Networked environments are complicated places and there are often no easy answers. By acknowledging that mistakes are likely to happen, you can better prepare to deal with issues when they do arise. Hopefully being aware of these five common pitfalls will help you to better navigate your next project.