Strategy and Tactics – Page 133 – IS Survivor Publishing

A simple sourcing strategy?

There are simple sourcing strategies. There are effective sourcing strategies. But there are no simple, effective sourcing strategies.

This, at least, was the perspective offered by yours truly at Outsourcing Strategies 2004 the week before last. It is, it appears, the minority perspective. The popularity of the Core/Context Theory — “Keep what’s core to your business and outsource the rest” — appears to be undiminished by the complete lack of any evidence to support it.

Complete lack of evidence?

Yes. In fact, that’s being gentle about it. In the past few years, two research teams reported the results of extensive research on what characteristics and practices lead to enduring business performance. The better-known, reported in Jim Collins’ Good to Great, found seven features common to outstanding corporations: A “Level 5” leader — one focused on building a great organization, not on personal recognition (I’m oversimplifying: there’s a lot more to Level 5 leadership than this); a strong, focused, coherent leadership team; a willingness to face the “brutal facts of their current reality”; clear focus around an organizing business goal (the “hedgehog principle”); creation of a “culture of discipline” (as opposed to achieving disciplined execution through close supervision); the use of technology as an accelerator; and reliance on the “flywheel” effect (building momentum for success on ongoing, continual, accelerating change, not on one-time transformational breakthroughs).

The second research effort was called the Evergreen Project. Described by William Joyce, Nitin Nohria, and Bruce Roberson in What Really Works, the project found eight factors — four primary, four secondary — that separated winners from the pack. While the factors aren’t exactly the same as those articulated in Good to Great, it appears the differences are more a matter of how each research team chose to define its categories than major disagreements as to what’s important. Having a clearly stated, focused strategy as stated in What Really Works isn’t very different from the hedgehog principle. Two other primary characteristics, flawless operational execution and a performance-oriented culture, together look a lot like instituting a culture of discipline and using technology as an accelerator.

The two studies don’t line up perfectly, which isn’t all that surprising. The Evergreen Project found that a flat, flexible organization was important to success. Collins was silent on this subject. And Evergreen’s list of secondary factors — retain and attract exceptional talent, creating industry-transforming innovations, growing through mergers and partnerships, and keeping leaders and directors committed to the business — have less overlap with Collins’ findings.

How to account for the discrepancies? When two study teams look at the same pile of raw data, there’s no particular reason to expect them to abstract the same generalities. The process of doing so isn’t purely analytical (Collins is direct on this point, describing lots of discussions and downright arguments over what a bunch of specifics might mean.) And since both pieces of research are correlative rather than experimental, this kind of disagreement is to be expected.

One point is clear: Keep the core and outsource the rest is nowhere to be found among either study’s recommended practices. Sounds to me like keeping the core and outsourcing the rest isn’t correlated with enduring business success.

(Keeping a wary eye on the ROI of individual projects or applying any other purely financial perspective on running a company is similarly absent, by the way, as is focusing on the maximization of shareholder value, two very popular points of emphasis among the current crop of business pundits … but that’s another column for another time.)

Adherence to the core/context theory isn’t among the factors driving outstanding business performance. It’s unsurprising when you look at how most large-scale outsourcing contracts are constructed. Much of their payoff comes from nothing more than the playing of financial games — a transfer of capital assets that front-end loads the benefits and back-end loads the costs. Gee, maybe that has something to do with why client satisfaction frequently runs out of steam just a few years into the average outsourcing relationship.

So why would a business theory that’s unsupported by the evidence retain such popularity?

Simple, easy-to-understand explanations are comforting — much more comforting than notions like the need for focus, disciplined execution and persistence. And given a choice between a comforting explanation and one that actually works, many people prefer comfort.

That’s one of the brutal facts of our current reality.

The TCP/IP of business process design

According to the Theory of Else, IT’s job is done when the software runs. It’s up to others in the business to make sure useful business results follow.

As last week’s column explained, the Theory of Else is a good way to make sure IT gets the blame when projects fail to deliver their expected value. The alternative, the Theory of Everything Else, is what will see you through to success: IT has to take on whatever tasks nobody else in the company is willing to do — not because it’s IT’s responsibility, not because it’s “the right thing to do,” but for the simple and unavoidable reason that your other alternatives are worse.

One of the most frequent items in the everything else list is the redesign of one or more business processes. And while it might seem counterintuitive, IT is a logical home for the discipline of business process redesign, for two very different reasons.

The first is that since IT is involved in every business change — something that isn’t true for any individual business division — placing the discipline inside IT means its practitioners will have the opportunity to practice their craft more than once, letting them deepen and perfect their skills (the same, by the way, is true of project management).

That’s the organizational logic. There’s also the knowledge of the process design discipline that already exists inside IT. No, I’m not talking about your business analysts, although some of them might have built some abilities along these lines. It’s your network engineers who really understand the subject, because everything you ever needed to know about business process design is already built into TCP/IP.

What TCP/IP does is break a message into chunks, send them into an intrinsically unreliable network built out of a collection of store-and-forward queues, to a defined destination where they’re reassembled into the original message. Ignore the break-a-message-into-chunks bit and what’s left?

A pretty good representation of most business processes, that’s what. Business processes consist of work queues. A piece of work is pushed onto a queue where it waits its turn. When its turn arrives, the queue manager does whatever is required, then forwards its completed to the next queue, where it’s worked on in its turn.

That isn’t very different from the routers that make up a TCP/IP network, although the routers don’t do much to each packet other than check it for errors and then either forward or discard it.

Any given link or router can lose a packet, which is to say, the network is intrinsically unreliable. That’s the IP part. The responsibility of the TCP part is to detect when that happens and correct the problem.

In a work process, work can get lost moving from queue to queue, too. A well-designed business process includes error checks to make sure work doesn’t get lost, assuming that from time to time something will go wrong along the way. Same thing.

Network engineers understand they have to deal with two different measures of speed: Latency and bandwidth, which is to say the end-to-end transmission delay for a single packet, and the total amount of information the network can handle in a given period of time.

Business process designers need to consider both cycle time and throughput — same ideas, different words.

To improve network latency and end-to-end bandwidth, network engineers find and speed up bottlenecks. Speeding up a part of the network that isn’t a bottleneck achieves nothing — installing faster routers is pointless if the ones you have already outpace the speed of the connection that links them. Business process designers also need to look for process bottlenecks instead of just speeding up whatever process step is most easily accelerated.

Network engineers are accustomed to the concept of a management console — a display that lets them know, at a glance, the health of the network. Manageability is built into the design of every router to make network management possible.

How many business process designers have the same understanding? Yes, it’s easier to manage a router than an employee. It still isn’t all that hard to build manageability into the queues that make up a business process, and construct a dashboard so the process manager can tell, at a glance, the health of the process.

Can a network engineer really succeed as a business process engineer?

Beats me. It sure would be fun to facilitate the design sessions, though, don’t you think?