IT Project failure

Over the years, many studies have been done, looking at the success rates for IT projects. All of the traditional issues are always raised, and they often are categorized as some of the following, as it was on this Blog "12 early warning signs of IT failure". The list includes:

1. Lack of top management support
2. Weak project manager
3. No stakeholder involvement and/or participation
4. Weak commitment of project team
5. Team members lack requisite knowledge and/or skills
6. Subject matter experts are over-scheduled
7. Lack of documented requirements and/or success criteria
8. No change control process (change management)
9. Ineffective schedule planning and/or management
10. Communication breakdown among stakeholders
11. Resources assigned to a higher priority project
12. No business case for the project

While these may all be valid, there is one underlying issue that is not mentioned. One of the first things that I was taught in problem solving ( a basic introduction to any computer course is "root cause analysis"). Root cause analysis says that you shouldn't look at the first level of causes to understand why something is happenning, but look a few levels down to the underlying causes of these causes. This is also a standard quality management practice.

When we look at some of the above-mentioned causes, we find:

• Lack of top management support
• No stakeholder involvement and/or participation
• Weak commitment of project team
• Subject matter experts are over-scheduled
• Lack of documented requirements and/or success criteria
• Communication breakdown among stakeholders
• Resources assigned to a higher priority project
• No business case for the project

All of these related to the fact that this was not something of value to the business. If top management and the business units don't want it, these things will happen. So why do projects get started, and why is time and money spent on them?

Projects get started for good business reasons, but quickly get into "project mode". They cease being a business need and become an IT project. The project team starts talking about implementing software instead of upgrading business performance. Time stretches out as we build a sophisticated system to provide all options that might be requested at some time in the future (it never comes). Let's get back to basics and focus on the business outcomes that the business needs. By focusing on those business outcomes, that should deliver benefits to the business, we will not only have more successful projects, they will deliver the value and keep the interest of top management and the stakeholders.