“We ought to start a mentor program,” said one of the four Jim’s reporting to me several years ago.

“Great idea,” I replied. “One question: what’s a mentor program?”

A mentor program, Jim explained, recognizes the expert-in-the-next-cubicle, providing support, prestige (or at least respect), and a role in influencing how IS deals with LAN and desktop technology and support.

“I like it,” I told him. “You’re in charge.”

At this juncture all four Jim’s (and the rest of the room too, except for the other Bob who sat sketching the meeting notes) explained that this would prevent the proposal of any more good ideas. Suggesting doesn’t automatically mean volunteering.

Eventually we found two volunteers and started the program. We won a national award for it, too. And here’s the greatest part: I got some of the credit, when all I did was pop for lunch, books, and a few trinkets. Total budget variance: 0.0113%. Non-money.

Last week’s column started a series on the interaction between IS and the end-user community. As you may remember, the column discussed three insights that form the backdrop for these interactions: (1) Visibility = Dissatisfaction; (2) You need to provide stealth end-user support; and (3) IS isn’t the expert when it comes to personal computers.

Mentor programs build on all three of these insights at the operational level. By improving “next-cube” support, fewer problems reach any manager’s radar screen. If you’re really persuasive, get your mentors to buddy-up with new users, so neophytes have someone to say, “I don’t remember what they said about this,” to without feeling embarrassed.

Mentors require a small but real support effort on the part of IS, but reduce the total time expended by IS analysts supporting end-users greatly. Let’s look at how to organize a program like this.

1. Find a compatible and enthusiastic pair of individuals to head this up. Two is a great number of people for a program like this. Two people bounce ideas off each other where one just mutters. Two load-balance where one burns out or lets the program slide. Two keep each other’s enthusiasm going.

2. Qualifications: you need party planners and social directors, not techies. Business happens over lunch and participation is voluntary. Your mentors gotta wanna. That means planning lunches that are entertaining as well as useful. (Yeah I know: making work fun isn’t in fashion this year, but I’ve never had much fashion sense.)

3. Monthly Lunch Programs: have contests with prizes, (give the group a list of obscure features and see which one knows the most) drawings for door prizes, and guest speakers (every vendor in town will drool over the chance to talk to a group like this). Ask mentors to submit “Tip ‘o the Month” ideas for your company to include in its employee newsletter, and give a special prize each month to the mentor supplying the tip.

4. Giveaways: give every mentor aftermarket books on your applications – the ones for sophisticated users, not beginners. Also give them a plaque, clock, t-shirt, sweatshirt … something that both identifies them as a mentor and that they’ll like.

5. Influence: involve mentors in product decisions, configuration defaults, training-course content … everything that directly affects the end-user community. Give them access to a test server housing new software releases as soon as each new release appears on the market. Invite them to stress-test the new releases and give them prizes for major bugs.

This isn’t a strategic program – heck, it isn’t even tactical. It just helps everyone out with their day-to-day grind, at very low cost. You may not be a hero for putting together a mentor program. The mentors will be the heroes if anyone is, and that’s as it should be.

But you’ll have done your good deed for the day.

This, of course, is an election year, so we’re subjected to the usual array of ridiculous, mutually contradictory promises, none of which will last beyond the inaugural ball. They must think we’re smoking something, and probably think we inhale, too.

Since this is an election year, you’ll also be subjected to commentators and columnists of all persuasions shamelessly exploiting the subject in their ongoing, desperate attempts to create “hooks” to draw you into the main subject.

So why should I be any exception?

Bill Clinton and Bob Dole aren’t the only ones to make promises in their jobs, of course. (And you thought connecting this lead to an IS management topic would be a stretch.) Haven’t you, in a tight spot, ever made a promise in a meeting, only to go back to your office wondering how you’re ever going to deliver on it?

This week we begin a series on interaction between IS and the end-user community. Let’s set the stage with some basic insights:

Insight #1: Visibility = Dissatisfaction

When the quality movement picked up steam we all heard about delighting, rather than just satisfying customers. Most of us in IS shook our heads sadly, knowing the futility of this goal (along with the unfortunate “internal customer” concept that goes with it). The problem? “Quality” lumps lots of completely dissimilar issues into a single amoeba-like lump. We can mitotically divide this lump into two smaller chunks by recognizing that some forms of quality are only recognized by their absence, while others really do delight customers.

Genuine Corinthian leather delights a certain group of automotive customers. We can call this kind of quality “positive quality” (PQ, for those of you who, James Martin-like, enjoy acronyms). We can focus ingenuity, creativity, and all those other right-brain attributes on generating PQ-enhancing ideas.

Telephone dial tone doesn’t generate customer delight. Absence of dial tone, though, generates quite a bit of high-decibel-level conversation. We’ll call this kind of quality, where you’re only visible when things go wrong, negative quality (NQ). A lot of what we do falls into the NQ category.

Insight #2: The Need for Stealth End-User Satisfaction

IS interacts with the end-user community at all levels. Executives want you to focus on big strategic projects. Middle managers want you to build enhancements to their core information systems. Secretaries need help recovering their trashed memos. These requirements compete for resources, of course, and while the executives may agree to some tradeoffs in principle, those agreements vanish like vacation money when exposed to the sunny disposition of a secretary with a damaged document. (Rule #37 of organizational behavior: executives are terrified of secretarial dissatisfaction.)

If you expend visible effort supporting day-to-day end-user computer use, executives and middle managers will wonder who’s taking care of their strategic initiatives and production system enhancements. If you don’t take care of the day-to-day sturm unt drang, they’ll wonder … aloud … if you’re competent to handle the big issues when you can’t even take care of their secretaries.

So you need stealth efforts for optimal NQ.

Insight #3: IS isn’t the expert when it comes to personal computers.

Personal computers are more than a way to reach the company’s business systems. They’re more than a universal information access utility. They’re more than a general-purpose tool for improving effectiveness.

For some employees, they’re a hobby.

A friend of mine earned a PhD from his hobby, which happened to be creating a stochastic model of international banking. (He showed it to a friend who happened to run a graduate program in industrial engineering over lunch one day, and had his PhD a week later.)

Some people put a lot of effort into their hobbies. They read a lot, experiment a lot, think a lot. Within their self-imposed boundaries, they know more than you do. Disparage their expertise at your peril.

These insights represent the landscape. You have to build on it. Next week we’ll start to explore ways you can do so.