Browse

All Posts in Strategy and Tactics

|In: Industry Commentary|Last Updated:

Not all that many years ago, a friend of mine bought a router. When he brought it home to show his wife, she asked, skeptically if it was really worth a week’s lunch money. So to prove its value he’d spend hours in his workshop, using his new router to build nifty items like chairs, tables, and lamps. (Now, of course, the wife is as likely as the husband to bring home a router. Usually, it has Wi-Fi built into it. But I digress.)

Routers are versatile tools. But not so versatile that they solve every problem. To pry the lid off the paint can or hammer nails you’d be better off with other gadgets. It’s a lesson some CIOs need to learn: Having adopted global sourcing as a useful addition to their IT sourcing strategies, they’re now trying to use it for every job in IT.

The problem is, global sourcing vendors aren’t well suited to every job in IT, and in fact some modern trends are converging that should aim wise CIOs squarely at local resources. These trends are the accelerating trend toward making use of commercial software rather than in-house developed proprietary software, the trend toward componentized software architectures, the increasing use of adaptive methodologies such as eXtreme Programming (XP), and the growing awareness that the proper goal of IT isn’t successful software delivery — it’s to collaborate in the delivery of successful business change.

One at a time:

When you buy commercial software, the tasks that remain are to adapt it to your enterprise and vice versa. That means process redesign for the business, configuration and customization of the software, and systems integration work. Sending any of this work offshore is an unnatural act, as the work is highly interactive and heavily dependent on the details of the situation. It’s on-site work, heavy on telephone calls and light on heads-down coding.

With componentized architectures, developers connect software modules that provide generalized business services to support business processes (yes, I’m oversimplifying, but for the purposes of this discussion it should be close enough). While the coding to create components might be accomplished by a global sourcing vendor, the use of the components is, again, light on coding and high on interactivity. Offshore? What’s the point?

Which brings us to adaptive methodologies. Whether you prefer XP or some other flavor, adaptive methodologies all embrace the idea of high interactivity, to the point of having business users looking over programmers’ shoulders during development. You could, I suppose, use NetMeeting to allow end-users to look over the virtual shoulders of third-shift programmers in Bangalore. But then, with enough effort you can make soy paste taste vaguely like hamburger (or so I’m told). That doesn’t make it a good idea.

Adaptive methodologies don’t achieve IT nirvana, though, because they’re still focused on software delivery. And software delivery is yesterday’s news. It used to define success for IT. Now it’s the ante that lets you into the real game: Changing the business.

The traditional methodology used to redesign business functions, business process re-engineering (BPR), closely resembles traditional IT “waterfall” methodologies (those that separate analysis, design and coding into separate sequential phases). Business re-designers figure things out, then let IT know what they need. This isn’t very different from having business analysts figure things out and then hand specifications to developers. Global sourcing can succeed with traditional BPR, because sequential methodologies with strong separation of function is their strong suit.

The problem is one we’ve known for at least twenty-five years but still pretend doesn’t exist: With waterfall methodologies you have to be right the first time, and nobody is ever right the first time. Business redesign succeeds best when it gets the initial elements of a new process into production and then continually improves it until it hums.

There are two ways to continually improve a business process. One is to assume the available tools are fixed and immutable — the machinery, work space, and information technology is what it is, and the process works within those limitations. With this assumption there’s no work to send offshore.

The other assumption is that everything is up for grabs — process flow, work space, information technology, training, and even product design. With this assumption the last thing in the world a business should do is to send the IT part of continuous process improvement half a world away. The proper solution is, in fact, the exact opposite:

Move programmers out of IT and into the business area where they can participate in the work.

Comments

|In: Industry Commentary|Last Updated:

In 1950 the Union of Japanese Scientists and Engineers hired W. Edwards Deming to teach them how to manufacture high-quality goods. American industry, which dominated world trade at the time, ignored him.

Big mistake.

While Ford, Chrysler and American Motors searched for strategies to counteract General Motors’ dreaded tail fins, Toyota and Nissan (then Datsun) achieved the unthinkable. Through a combination of low prices and high quality, the product of lower labor costs and Deming’s Statistical Process Control (SPC), they grabbed marketshare and mindshare until the American automobile industry was in full retreat.

It still hasn’t fully recovered, nor has the rest of America’s manufacturing economy, although Japan Inc., has given way to a variety of Asian manufacturing powerhouses.

Substitute the Software Engineering Institute’s Capability Maturity Model (CMM) for Deming’s SPC, India’s lower cost of labor for Japan’s, and the software industry for manufacturing. The parallels are hard to ignore.

Many Americans, hearing phrases like global sourcing or offshore outsourcing, think the whole issue is one of American employers selling out high-quality U.S. workers for cheap foreign labor. And yes, Indian (and Russian, and Chinese, and so on) programmers do work for a lower hourly rate.

But that’s only half the story. The other half is that the global sourcing concerns, and in particular Indian companies, have bought into CMM and its process-driven approach to achieving high-quality code. Their American counterparts never pursued this strategy in spite of mounting evidence that it works, at least from the perspectives of programmer productivity and programming quality.

Which is to say, we got ourselves into this mess.

Again.

Whose fault is it? Put on a blindfold, spin in circles, and take the blindfold off again. Chances are you’re looking at one of the culprits. American management lacked the will to implement strong software quality processes, American programmers resisted the whole notion as it smacked of regimentation and suppression of creativity, and American executives couldn’t be bothered with such trivial matters when everyone knew America held an insurmountable advantage when it came to information technology.

There’s plenty of blame to go around, and not much point to assigning it. The reality is as simple as it is inescapable: For an increasing array of information technology tasks, offshore suppliers provide more value than on-shore suppliers or in-house staff.

What’s the solution? Predictably, some organizations are pursuing the require-longer-hours strategy that trades off cost for quality instead of improving both.

A more likely solution would be for all remaining American code factories, whether they be internal IT shops or software vendors, to institute crash CMM implementation programs.

It’s unlikely to do much good, though, and very likely to fail, for three reasons.

First, doing so would be a game of mirror chess, and mirror chess always loses. There’s little advantage to pursuing a strategy that keeps you a step behind your competitor.

And then, most adoptions would be half-hearted at best: The do-the-same-thing-the-same-way-every-time mentality required by SPC and CMM just don’t seem to be part of the American character. Our national success has had more to do with rule-breaking than rule-following, after all. A strategy that embraces our culture is far more likely to succeed than one calling for radically changing it.

The third reason to avoid this direction is that nobody has much of an incentive to invest in it. In a country that has decoupled its capital and labor economies, those investing capital are more than happy to send programming work offshore. The best-case outcome of a CMM program is insufficient: Parity in code production and quality, and a labor force that’s still seriously overpriced. Compared to partnering with an Indian company that can deliver high quality and low prices now, what’s the point?

If there’s hope for the American software industry, it’s in software design and delivery models for which CMM, or at least CMM as practiced by the global sourcing firms, is irrelevant.

For the most part, the global sourcing concerns employ methodologies that strongly separate business analysis, software design, and coding. The geographic distance between the business process owners and end-users who define the need and the programmers who fulfill it requires this.

Any American firm that wants to establish a competitive edge should pursue alternatives that minimize this segmentation of effort. While the ingredients of a solution have been floating around for some time, a mature version doesn’t yet exist. But that’s good news.

Because it plays to our most important strength: Knowing when and how to break the rules.

Comments