All Posts in Strategy and Tactics

|In: Industry Commentary|Last Updated:

One of the most popular games in the world of business is “Blame the Consultant.” No matter what actually went wrong — bad leadership, poor project management or sloppy implementation — it’s easiest to blame the consultants.

The most recent example is New York Times analyst Paul Krugman, who, in a recent editorial blamed the Enron fiasco on its leaders’ preference for guru-driven theories over business realities. Enron was, after all, led by Jeff Skilling, a former McKinsey consultant, and McKinsey is notorious for only handling the inspiration slice of the genius pie chart. Doesn’t that prove the point?

Sorry, but no. Enron’s problems apparently stemmed from old-fashioned fraud: When you show the cash but hide the debt, as has been alleged in this sorry debacle, it’s easy to post good numbers.

Krugman is, however, right about one thing: Enron built its whole business on the popular core vs context theory. If you’re unfamiliar with the terms, core activities differentiate you from your competitors, while contextual activities do not. Core/context theorists contend that you should outsource everything that isn’t core. The theory is especially popular among outsourcing companies, because … well, that’s obvious, isn’t it?

The theory suffers from two flaws, one fatal, the other merely grievous. The fatal flaw is that it’s just plain wrong: Context activities can differentiate you. Oh, not in a good way — nobody chooses a vendor because its invoices are always accurate. But context activities sure do differentiate you when you bungle them. They drive customers into the arms of competitors. And since it’s harder to manage a vendor well than to lead employees (vendors are more adept at hiding problems, and more motivated to do so), it’s hard to understand how the core/context theory leads to business benefit, except when an outsourcer has economies of scale unavailable to you.

That’s the fatal flaw. The grievous one is more basic: This isn’t a theory, it’s a hypothesis. Dig deep and you’ll find that the theorists are relying almost entirely on two high-profile test cases: Nike and Enron, both of which leave the doing-something-useful-that-creates-real-value aspects of running a business to others. Nike markets very well; Enron traded very well, or so we all thought.

Now we’re down to a single test case, and that’s awfully limited evidence on which to bet your company.

Treat this theory with caution. Outsource very selectively and only when you can quantify clear financial benefit, when you can build strong mechanisms to manage the additional risk, and when you can construct a clear exit strategy in case the outsourcing arrangement sours.

That’s the best advice I can give you. If you ignore it … please don’t blame the consultant.

Comments

|In: Leadership|Last Updated:

Which is more important — skills or manners?

The right answer: Both. Because while mediocre employees will never create excellent results, everyone else will torpedo the work of a brilliant but obnoxious co-worker.

Likewise your IT organization. Excellence is important, but not until after the rest of the business invites you to participate. Relationships matter.

Nor is having a “good” relationship sufficient. You have to have the right kind of relationship — one you’ve designed. But how do you do that?

Last week I introduced a technique for starting the process of designing your relationship with the rest of the business, called either “scenario-based design” or “tales by the campfire,” depending on which stage of the consulting sales cycle I’m in. It replaces abstract generalities with illustrative anecdotes as a way for IT leaders to explain to each other what they’d like IT’s relationship with the business to look like.

Once your team has shared these anecdotes … and probed at them, because you need internal consensus on this … what happens next?

Extract a set of between five and seven relationship design principles. These are abstractions tested against each campfire tale to make sure they’re valid. For example, if one campfire story talks about mandatory adherence to IT standards, “they’re our customers” won’t survive as a design principle. Coercion isn’t something you do to a customer, after all. (Unless you’re an IT vendor, but let’s not go down that path.) Examples of relationship design principles: “There’s no such thing as an IT project, only business change projects, most of which have an IT dimension.” And: “To the rest of the company, IT appears to be a unified whole, in which every IT employee acts as an ‘ambassador’ for the department.”

What good are these design principles? They’re what you need for the next step — to figure out how IT has to change. That’s the payoff.

What really matters in all of this is that you have a structured process to help you figure out what new skills and knowledge your employees will need, how some key processes will have to change, and perhaps what new tools you’ll have to put into place so you can have the right relationship with the rest of the company.

See? Telling tales by the campfire can be pretty useful. You bring the marshmallows.

Comments