IT vs. Business: Who Should You Blame When Projects Fail?

As I was researching this story, not many sources stepped forward to dispel those stereotypes. Emails from business executives liberally sprinkled in terms like “propeller-heads,” “introverts” and “Asperger’s.”

IT, meanwhile, didn’t hesitate to point out that the typical business executive is tech-illiterate and so irresponsible when it comes to data security that, as one person said off the record, “If I were I hacker, I’d target executives before the elderly. There’s more money to be made, and they’re as easy, if not easier, to dupe.”

With attitudes like these, no wonder business is eager to ship IT operations to India and that IT is busy trying to make technology seem like such a black art that business executives will avoid them at all costs lest they actually have to talk to them about something.

Okay. Fine. So they don’t like one another, but who’s to blame already?

This isn’t the most satisfying answer in the world, but you probably guessed it going in: there’s plenty of blame to go around.

“These conversations [to assign blame] are counter-productive, [and they] deter participants from giving unbridled feedback. It’s a little difficult giving honest feedback when your head lies on the chopping block,” said Larry Pritchard, managing partner, Pritchard Enterprise Solutions, a technology consulting firm.

Meanwhile, business efficiency coach Laura Rose argues that the person to blame is the person searching for someone to blame. “The act of ‘finger-pointing’ is the breakdown. Individuals are no longer working as a team to contribute collectively to the shared vision or goal. Finger-pointing is actually a great tool to indicate something is amiss.”

The trick, then, is to stop worrying about blame (easier said than done), figuring out how to move past it (ditto), and, eventually, learning how to redefine business processes so that when technology projects start to fail in the future, your organization will know how to get them back on track (like pulling teeth).

Knowing who is responsible for what

According to William Hartman, managing director, Brand Velocity, a firm that specializes in “project acceleration,” problems with technology projects are almost never technology problems ... they are invariably business ones. Hartman has been on both sides of the business-IT divide, previously serving as CIO for Coca-Cola Enterprises and as CEO of Ernst & Young’s Global Client Consulting practice for the Americas, Europe, Asia, and Latin America.

Hartman notes that ultimately it is up to business leaders to accept responsibility for technology projects and not abdicate responsibility simply because they don’t understand technology. “Business leaders can delegate authority, but they should never abdicate it. That’s an important distinction.”

On most large important projects there should be five key constituencies working towards a shared goal: 1) the executive team, 2) the specialized project team, 3) IT and system administrators, 4) the specific technology team (usually a vendor from outside the organization, such as a VAR or ISV), and 5) the board of directors (on very large projects).

It is critical that every constituency has a well-defined role and that they are held accountable for certain project goals and benchmarks. If anyone’s role is nebulous and if no one can be held accountable for things like missed deadlines or cost overruns, you’d better go back to the drawing board.

“It’s common for a project to be authorized and then just put on a shelf,” Hartman said. “Business isn’t held accountable for the realization of goals going forward and IT isn’t responsible for ensuring that the new technology is actually used and has a direct impact on the bottom line.”

8 Warning signs

Clear roles and responsibilities are just a start, though.

Often, failed projects would have a better chance at success if team members knew earlier in the process that the project was straying off course. With corporate culture these days placing so much emphasis on “being a team player” and exhibiting outright hostility towards dissenters and whistle-blowers, people often hesitate to express their concerns because they fear being regarded as negative. That perceived negative attitude can affect performance reviews, raises and promotions.

The eight warning signs of failing projects include:

1. Excessive overtime, which is an indicator of poor project planning.
2. No one on the business team "owns" the technology project.
3. No one on the IT side understands larger business goals and how the technology serves them.
4. The project lacks a translator (often just a tech-savvy, business-aware project manager or business analyst) who can translate the language of business for IT and vice versa.
5. There are no plans for measuring successful progress along the way and no contingency planning for when conditions (external or internal) change and threaten the success of the project.
6. IT and business goals are never written down and aligned.
7. No on one the project can articulate what a successful outcome means to both the business and IT.
8. Poor (or no) change management. Successful technology projects, by definition, bring change, yet most organizations erroneously believe that post-project life will be business as usual.

Another perceptual problem is people tend to be optimistic at the beginning stages of things. “At the beginning of projects, there’s a shared delusion where no one is willing to realize that things can go wrong. Early on, people tend to be optimistic, even bordering on euphoric,” said Michael Krigsman, CEO of Asuret, Inc., a technology consulting firm.

“Of course, in any reasonably successful organization there will be professionals on board who should know better. They know firsthand that projects can and do go sideways, yet amnesia sets in,” he said.

Working against these delusions is incredibly hard and that a project often must start failing before people are willing to realize that failure is a possible outcome. For consultants like Krigsman, they benefit from the fact that it often requires a set of outside eyes to see a project for what it is.

Group psychology is tricky and incredibly hard to counter. However, there are much easier symptoms to spot that warn of sick projects. “Overtime is a big one,” said Todd Williams, president of eCameron, Inc., which specializes in project auditing and recovery. "The first thing I do when I’m brought in is cancel all overtime. Companies where overtime is common are ones where good planning is scarce."

Williams next audits projects and looks for policies that pretty much guarantee failure. For instance, he has worked with companies where policies dictate that in-house employees must staff projects. Never mind that the employees may not have the requisite skills to lead the project to successful completion.

“You have a choice,” Williams said. “If you want to keep staffing projects in-house, you’d better hire some experts or devote the time and money necessary to train your employees so that they become experts.”

Policies like these aren’t arbitrary. Often, they’re instituted in down times like the current recession. They are cost-cutting measures. You can’t hire new people; you can’t bring in outside contractors, yet the stable of projects you had lined up before the economy tanked must still be completed. Too often, cost-cutting policies are so removed from business realities that they end up costing far more than they intended to save in the first place.

Policies like that pretty much guarantee failure, no matter whom you put on the project team.

As they say in various twelve-step programs, acknowledging that you have a problem is the critical first step. Awareness is important, but it’ll only get you so far.

Based in Santa Monica, California, Jeff Vance is the founder of www.sandstormmedia.net, a copywriting and content marketing firm. He regularly contributes stories about emerging technologies to this publication and many others. If you have ideas for future stories, contact him at jeff@sandstormmedia.net or visit.