3 People-Centric Signs of IT Failure

Updated: July 13, 2010

Most project managers view success strictly as a function of time and budget, and evaluate progress accordingly. Although measures of success related to time and cost are fundamental, they can be misleading if not considered with other indicators of project value.

These three warning signs relate to communication, value, and communication rather than simple measures of cost and time.

1. Process is more important than results

Every effective project team follows a defined process for completing projects. A coherent, systematic approach is essential to coordinate the project team and drive the project successfully from start to completion.

In some organizations, however, rigid adherence to process and methodology seems more important than achieving results. These companies suffer from a dysfunctional culture in which in which individuals use process, which may come from a strong command and control hierarchy, as an excuse for failing to achieve meaningful results.

Defining success in terms of milestones reached rather than results achieved is a sure sign that something is wrong. In extreme cases, a project team may claim success even though stakeholders see little or no benefit when the project is complete.

Solution: Focus on results! Process is important, but outcomes matter most; therefore, examine project results independently from the process used to achieve them. If you really want to know the truth about a project, ask the beneficiaries rather than the project team. Process should never become a substitute for achievement.

2. Poor communication drives a wedge between IT and the business

Successful projects always provide benefit, or value, to a specified group of stakeholders. The more precisely you can identify stakeholders, the greater chance of delivering results they will find to be of value.

In some companies, a culture of blame, arrogance, or division militates against IT engaging in active dialog and collaboration with business stakeholders. In such environments, IT views the business as a group of clueless users, while business stakeholders look down on IT as semi-illiterate functionaries. Of course, I am exaggerating, but you get the point: poor communication, and even antagonism, between IT and the business is common.

I asked Vishal Sikka, SAP's Chief Technology Officer, about alignment between IT and business:

Lines of business know the what and IT knows the how. Companies in which this "what / how" distinction is broken tend to have difficulties. You have to empower the lines of business and the IT guys….trusting the IT guys know the how and lines of business can articulate the what….The business [should] tell IT the nature of the problem to solve; IT [should] then bring in tools and platforms to [address them].

You [develop] strategic IT by bringing the line of business and the IT guys together to the table [with] mutual respect and empowerment.

Solution: There is no substitute for establishing regular and substantive communication between IT and business stakeholders. If either side is reluctant to engage in meaningful dialog, regardless of the reasons, then the project is at risk. When this happens, elevate the situation to the project sponsor and establish regular dialog between these groups. IT projects are a team exercise and all sides sink or swim together.

3. Business case is unclear or ambiguous

Perhaps it's not surprising that ambiguity is common on failed projects. Any corporate initiative involving multiple departments is subject to the "law of exclusionary results," which says that each group is motivated to achieve its own goals irrespective of what's best for the project as a whole.

This creates situations in which the project business case is muddled and confused, watered down by conflicting demands made by factions that cannot agree on a common purpose. When a project business case consists of mutually exclusive components created by groups unwilling to collaborate, then failure is virtually assured.

There's little point in continuing a project that is ultimately doomed to fail. "Zombie projects," as I have called them, deserve to be put out of their misery quickly and decisively:

These monstrosities stick around because they're a hassle to fix and no one is willing to muster the effort or courage needed to do the final deed.

Solution: Ambiguous or diffuse project ownership creates unclear outcomes and goals. If this describes your project, two reasonable choices exist: find a way to get key stakeholders on the same page or else kill the project.

Killing a project midstream is a dramatic solution that most organizations only undertake under duress. Nonetheless, if the business case is seriously flawed, then the project is likely a waste of time and money. In such cases, wisdom may demand that it's best to cut the losses short.