Three Aspects of IT Project Failures

You need to define the root causes of IT project failure which can be broken down into Culture, Politics, Expertise, Policy and technology categories.

The high rate of IT project failure is one of the biggest headaches for CIOs and IT/project management. IT is also transforming from “build to last” to “design to change, “ because the speed of business changes is accelerating, and Agile has been emerged as mainstream IT philosophy and management discipline. To dig through the root causes, why do so many IT projects fail and how to manage IT project portfolio more effectively.

1. Ego of the sponsor

• "My project cannot fail." Sponsors often tend to do everything to avoid a failure - and the higher the sponsor the more difficult it becomes. Inflated egos are always a problem. Projects are started, but add very little value to the company and only serve to highlight the sponsor.You will never stop politicking totally but steps can be taken to limit them, by imposing penalties on anyone found playing politics for personal gain or to the detriment of projects. It needs a mind-set change.

• Diminishing leadership support as the project moves on: Some leadership show extreme degree of support at the inception of the project, perhaps more as a way of showcasing themselves or their teams. However, as the project progresses, their levels of motivation for the specific project may wane, hence reducing the huge impact of user advocacy combined with leadership support.

2. Loss avoidance

In terms of loss avoidance one has to take a reality stand and only undertake projects that are for the benefit (measurable) of the company and have a better than average chance of success. Most IT project fail to figure out what success looks like for the customer. They don’t measure success in the correct way. And most basically what the users are they trying to achieve with this project?

• The purpose of IT is not to drive the business; it’s to drive the value of the business.

“I.T. Projects” are business projects sponsored by business owners whose objective is to solve business (or consumer) problems.You can talk about requirements, project managers or bad code all you want; ultimately projects fail because of combinations of three factors: lack of enterprise knowledge, static or outdated IT capabilities, and dysfunctional communication structures across the enterprise.

• All projects are or should be for the benefit of the business so their title is irrelevant. Business project or IT project makes very little difference. The use of title of IT project simply identifies it is a Business project with IT Components. Scope creep is coming up time and time again and generally is a combination of cutting corners on analysis, specs, communications and management. Again TIME is the factor that is seeing all these procedures and processes being rushed because of the lack of available time. But you still need to have a comprehensive plan of action which covers all known tasks and then stick to it and adjust where necessary if changes occur.

• Project that runs long and doesn't take into consideration of industry dynamics: Here, the project undertaken may be huge and have a long gestation, resulting in a few problems: a) what was unique to the results of the project, is no longer true; other products/services fulfill the need at a much lower cost b) the longer the project is gestation, the greater the chance for scope creep and its resulting dangers c) Big gap in expectations and delivery - Project Managers have to pay enough attention to managing expectations

"The thought of accepting the large sure loss is too painful, and the hope of complete relief too enticing, to make the sensible decision that it is time to cut one's losses. This is where businesses that are losing ground to a superior technology [or track on a major project (the author)] waste their remaining assets in futile attempts to catch up or save the project." ("Thinking, Fast and Slow")

3. Ignoring the probabilities of failures

Commonly many people agree that 30% of IT project failure rate is a reasonable assumption. If that's the case, more often, the management do not accept this probability. Portfolios are usually not managed with the perspective that 30% are not successful. Usually management is saying something like "that doesn't apply for us because we have a great project manager, a great PMO manager or a great sponsor." And reality usually turns out differently.

From industry study, there are even about 70% of IT projects fail to achieve the customers’ expectation.  That is where analysis of Project Risk comes in. If the risk from the situations above can be quantified, then that can be weighed against the expected benefit - leading to some logical responses (such as Accept, Fall-back, Avoid etc.) to situations which being perceived as possible in IT projects.

Projects bring about change, big or small, in how business is conducted. If the project has not taken into consideration of the impact of the project, the methodologies to reduce change management stress, not created enough time or resources for training, not much has been done towards project advocacy (How will this project help you do your job better), and then, it has a higher degree of failure - the reason being low or no usage, resistance to change, loss of productivity.

IT Projects are so crucial to company success, so any company that does not take and treat IT success seriously will lose out in the competition stakes. You need to define the root causes of failure which can be broken down into Culture, Politics, Expertise, Policy and technology categories. And then well align the leadership, talent, process, analytics and governance discipline to improve IT management capability, effectiveness and agility.

Posted in: Lessons from Failures,Project Management