All Posts in Strategy and Tactics

|In: Leadership|Last Updated:

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.

Comments

|In: Industry Commentary|Last Updated:

If you’re a fan of the future, it’s time to write a letter.

K. A. Boriskin, a long-time correspondent, reports that there is a movement among science fiction readers to get the USPS to issue a stamp commemorating Isaac Asimov. Click here for details. Mr. Boriskin adds, “Unfortunately we’re dealing with the Postal Service here, so there’s no email address available, only snail mail.”

My 37 cents worth? Ask for the big three: Isaac Asimov, Robert Heinlein, and John W. Campbell, who together transformed the field. Send the letter to: Citizens’ Stamp Advisory Committee, C/O Stamp Development, 475 L’Enfant Plaza, SW, Room 5670, Washington, D. C., 20260-2437. And don’t complain that the USPS requires a letter. It is, after all, in the snail mail business — why would it encourage you to use its competition?

No, don’t answer that …

Speaking of the future, the future of IT (the organization, not the stuff) is that it will go away. That, at least, is the gist of a recent Gartner exercise in futurism, as reported and critiqued here last week. The quick version: Because tools for configuring and reconfiguring workflows are becoming user-friendly enough to transition to business units, IT will become unnecessary. The here-on-this-planet version: So what? Business units don’t reconfigure workflows very often, because have you ever tried to change a business process? If you have, you know it’s hard to do no matter how good the information technology.

The hard fact is that designing a good process is an engineering task, not just a matter of dragging connectors in Visio. The harder fact is that once you do, you have to actually get employees to do their work differently. And the hardest fact of all is that once you do that, you have to fix all the gaps in your process design, because no process designer has ever anticipated everything that can happen once actual work starts flowing through.

You just don’t want to go through this all that often.

But while Gartner-bashing might be fun (and “might be” is a pale description of the joyful reality), it isn’t fair to criticize without offering an alternative. Luckily, I am (to quote Asimov) “a keen-eyed peerer into the future,” and so, I will.

What’s the organizational future of information technology?

From a business planning perspective, anything beyond three years or so is little more than science fiction without the science. Within that window there are no obviously transformational technologies or trends that suggest a need for radical change. For most businesses:

  • IT operations will continue to be semi-automated. Systems management tools continue to improve; systems complexity continues to increase; the likelihood of true “lights out” operation is still far away. Savvy CIOs already know their job is to shift budget out of operations, but only as much as they can without harming the quality of service they provide.
  • IT’s bread-and-butter work will still be application maintenance and enhancement (small non-discretionary and discretionary changes, respectively). Today’s rules won’t change: Organize talent into teams that know the major applications inside-out and sideways; batch changes into scheduled releases; and make sure you’re very, very good at integration and regression testing.
  • Most companies will continue to organize their technical architecture around one or a very small number of enterprise applications — usually an ERP suite. Integration will be hub-and-spoke with those applications. If it isn’t already, make it so. And integration will continue to be more about data than about business logic: The former is a necessity, the latter is a convenience. ERP suites will continue to simplify the process of integrating peripheral applications into their architecture. That’s great news — but not the stuff of organizational change.

In the next three years, IT will transform in one very important respect: Its role in the business. At the risk of flogging even further a horse that’s already been tortured in this space, IT, in most companies, will stop trying to be a supplier to its internal customers, and will start being a partner and collaborator in the achievement of business change.

The change will hit business analysts the hardest. Much of what they know today will become irrelevant. Much of what they don’t know will become essential. More than anything else, they will have to become experts in the disciplines of process design, and in designing large-scale change programs that translate strategic intent into achievable action.

Are they ready for this? Ask them. They’ll probably tell you, “We’re doing that already.” If they do, it’s possible they’re right. It’s more likely that they don’t know what they don’t know.

Yet.

Comments