I’ve developed a sixth sense for failed enterprise software deployments. Yes, it’s an odd superpower to have — I’d much prefer the ability to stop bullets in mid-air or to leap tall buildings — but it’s one that served me well when I was a consultant.

In previous jobs, I’d be the technical expert brought in to help at to crucial moments in the enterprise sales cycle: pre-sales and post-sales. These are the points immediately before and after the handshakes and the signing of the check. These are the moments when all eyes in an organization are focused on the new, shiny software and hardware. These are the make-or-break moments for a technology vendor.

But these moments of heightened attention don’t usually make or break a large-scale IT implementation. Those happen long before or long after the vendor has disappeared from the scene. Really, my job was to spot any additional opportunities during the pre-sales period — or to help identify ways we could stand apart from the competition. Or it was to clean up after the sales guy had deposited his commission.

But although I’m fluent in geek and can cut code with the best of them, the source of my super power rests in political science 101.

Yes, that’s right. I was a liberal arts major.

Soft science and hard facts

If you want to understand a physical system, it helps to understand the forces that affect it. If you want to understand a human system, you need to understand the groups at work.

There are four groups at work in any large enterprise software project. There’s the software vendor, the organization that bought the software, and the consultants that implement the software.

Whoops. I said four, didn’t I? That’s because within the organization there’s actually two main groups involved: those who use the software and those who provision the software.

The secret to sniffing out a rotten enterprise software implementation is recognizing these groups and identifying how well their interests are aligned. In successful implementations, all the key players have complimentary goals and objectives. In failed implementations, these groups are working at cross-purposes, if not actively trying to sabotage each other.

Sabotage is a harsh word, isn’t it? But what else would you call:

• A collaboration system that senior management burdens with so many security restrictions that it leaves departments more isolated than before?
• A consultant that buys cheaper, less capable software so that they bill extra hours for configuring, integrating and upgrading it?
• Employees that resent the influence consultants have with their bosses, and do their best to mislead and dis-inform them?
• Vendors that deliberately “leave out” key features so that their consulant partners have services to sell?

Even in cases where everyone agrees to the broad objectives and goals of a project, the competing interests of groups and individuals can slow or block an implementation. The old political science adage for this is “where you stand is where you sit”. Some examples:

• The IT group must justify their budgets for hardware and software, but they don’t have to worry about training costs. When evaluating a system, they’ll pick things that are cheap and easy to support, even if they’re hard to understand and use.
• Knowing roughly what a customer’s budget entails, consultants will favor cheap software so that they can have a large slice of the budget devoted to services.
• Software vendors will construct their products so that they demonstrate well, but will skimp on features that ease long-term maintenance.
• Line of business managers, happy that they finally get some slice of the capital budget, will splash out on the most comprehensive and most expensive tools they find, because who knows when they’ll get another opportunity to upgrade?

And if all that sounds dysfunctional, you should see what happens to the projects!

It’s not about the technology

Yes, technology is hard. Breaking old habits is difficult. Not everyone enjoys learning new stuff. But these things can be addressed with planning and communication.

But changing the way people work — changing the way that a company does business — that’s a wicked problem.

To address a wicked problem, you need more than fancy tools. You need leadership. You need pioneers. And you need a mission.

Because without those things, these competing groups — and the interests that drive them — will pull your project apart.

Related posts

1. Paul Graham on Enterprise 2.0
2. The Second Biggest Mistake of Enterprise 2.0
3. Why Enterprise 2.0 Will Fail