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.