Several readers said thanks.

In response to my miniseries on identity theft, in which the second column partially contradicted the first, these kind souls appreciated my having raised the overall level of awareness on this issue.

Maybe I did. But communication is defined as the delivery of information, information is defined as that which reduces uncertainty, and whatever impact the previous two columns had, I’m pretty sure they didn’t reduce your level of uncertainty.

I’ve never been a big fan of the “raising people’s consciousness” school of communication, even back in the ’60s when it was fashionable. It’s probably why those who deliver interpretive dance or read poetry in public hearings about major issues annoy me (especially when they’re on the same side of the issue I am) — the only uncertainty they reduce is whether they’re worth paying attention to or not.

I’m also not a big fan of most of the training I’ve seen come out of IT projects, and for the same reason: No, not that it’s excruciatingly embarrassing, but because it also doesn’t reduce anyone’s uncertainty very much.

It’s like this: A project team finishes a big software deployment — maybe a production scheduling module, sales force automation system, or order-entry application. What happens just before it goes into production? We train the users, of course.

So far, so good. But too often, that’s as good as it gets. Because what the project team trains the end users in is how to operate the software. And while the focus is more appropriate than teaching them how to, say, prepare a soufflé, it’s a good deal less useful. After all, when you’ve finished training them how to prepare a soufflé they’ll at least know how to cook something delicious — a reduction in their uncertainty about something. But when you train them in how to operate the software, their uncertainty about how they should go about performing their employment responsibilities will have increased.

The goal of software training really shouldn’t be negative information delivery.

It might seem to be too subtle to matter, but it isn’t: There’s a world of difference between training end-users in how to operate the new software and training them in how to do their jobs with the new software. In the former case you show them what happens when they click various menu choices, radio buttons, and combo boxes. In the latter you explain the new business process, how it’s different from what they’re accustomed to, and how they’re supposed to perform the role or roles they play in it. For those process steps that make use of the new software, you show them how to use it to accomplish those steps.

The project did include a redesign of one or more business processes, didn’t it? That should be the whole point. There are exceptions, of course — conversions from hopelessly obsolete applications, operating system upgrades, a new version of the e-mail client or office suite, But even with these, training that focuses on how to accomplish tasks is more effective than training that explains how to operate the technology.

The project team built the software. Of course everyone wants to show end-users how cool it all is. It’s an easy trap to fall into — a subset of the most seductive, yet ineffective form of communication there is: Starting with what-I-want-to-say instead of what-they-ought-to-know. What-I-want-to-say is all about me, and when it’s all about me, only one member of the audience is interested … me.

Despite this criticism, IT training certainly could be worse. For example, I’ve never seen it delivered in the form of poetry or interpretive dance, although on a related subject I was once nearly guilty of performing Tech Weenies in the Sky — a paean to computer telephony integration that finished with: It’s wired with fiber optics and it almost seems to glow/Though outside it’s Minnesota with a harsh and driving snow/Yes the nights here in the Northland are a bitter freezing cold/But with computers hooked to telephones/You’ll never go on hold/Yippie yi Ohhhhh!/Yippie yi Yaaaaay!/Tech weenies in the sky.

Mercifully, the performance never took place. And no — even if you invite me to keynote an event and then beg, it still never will. I’m not saying there’s no number big enough to get me to do it. I’m just saying you don’t have it.

And Warren Buffet isn’t about to ask.

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.