Mark Twain missed the big one.

As he pointed out, lies, damned lies and statistics can certainly give people the wrong impression. But if you really want to convince someone that up is down, they’re flimsy tools compared to the really big deceiver: Surveys.

I’m not talking about the well-understood practice of asking biased questions, like Burger King’s famous, “Would you prefer to eat a delicious hamburger, cooked from a quarter pound of fresh ground beef on an open flame, or a disgusting, greasy, fried, hockey-puck-like mess?” (I might have the exact phrasing wrong — I’m working from memory) that led to its not-very-effective “The Whopper beat the Big Mac” ad campaign some years back.

Sure, it’s a useful technique. It’s simply second-rate compared to one exemplified by a recent Gartner survey, reported in the January 14th issue of Processor magazine in an article titled, “The End of the IT Department as We Know It.”

The survey asked the popular question, “What’s your biggest frustration — something you’re supposed to accomplish but don’t, or something someone else is supposed to accomplish but doesn’t?”

The exact phrasing was a bit different. Gartner asked corporate executives to identify what gets in the way of strategic change in their companies, and IT failures beat out changing the culture. Since the culture changers are themselves and IT is someone else, the response is less than surprising.

Perception, of course, is reality, so you need to pay attention to this, especially since Gartner sells the perception to the executives with whom you work, also sells its solution, and, unlike you, has a paid sales force and PR machine. According to the article (and to be fair, it’s possible Gartner’s actual findings had fewer logical holes than the article that presented them) what’s going to happen is:

New technologies, that deliver pre-packaged workflows to businesses, and let businesspeople reconnect the process flows by manipulating visual tools and pushing a button (Ta-Da!!!) will fundamentally change the responsibilities of IT departments.

Since today most IT organizations spend the bulk of their budgets on operations and applications, something fundamental needs to change. Mix in outsourcing and the end of IT is at hand.

Oh, and the career solution for technical professionals? Get an MBA.

Let’s deconstruct this, shall we? First of all, suggesting that IT should spend most of its budget on something other than applications and operations is a bit like suggesting that Toyota should spend most of its budget on something other than designing and manufacturing cars. Applications are what people use to do their work. What, other than running the applications you have while enhancing them and delivering new ones, are you supposed to be doing? Raising chickens?

Second, workflow tools (just another class of application, by the way) don’t automate work. They automate the process of assigning work. Once the work arrives at employees’ desks, they still need business applications to help them do it.

Maybe the point is that businesses will start to view internal processes as commodities. Instead of figuring out how you want to run your business, you’ll just buy best-practice processes off-the-shelf, pre-automated and pre-integrated, with no work required from IT other than to install them and no work required from anyone else other than training the end-users.

Yeah, that’ll work. Your COO will buy Wal-Mart’s supply chain processes, Nordstrom’s customer relationship management, Amazon.com’s e-commerce, and Dell’s build-to-order. Voila! Like magic, out will come a lean, mean, fighting medical-devices, cosmetics, or maybe janitorial services machine.

There’s an old saying in the consulting business: It looks great on the PowerPoint.

So here’s some advice you might find a bit more practical regarding how to keep the joint running, from your old keep the joint runner:

Keep on spending most of your budget on operations and applications. Shift as much out of operations as you can every year — but only what you can shift through improved efficiency and not a penny more.

Spend as much as you can on applications — not just coding, of course, but all the associated disciplines that spell the difference between code that runs and successful business change.

And most important of all, pay attention to the “biggest frustration” that started this chunk of rant ‘n roll. Many IT organizations still haven’t mastered the fundamental discipline of managing projects to successful conclusion.

If you haven’t, perception really is reality, and while your IT department might not go away, you probably will. Soon.

And not under your own steam.

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.