All Posts in Organizational Effectiveness

|In: Leadership|Last Updated:

Back when I was studying electric fish, I learned a bit (no pun intended) about information theory. The math isn’t too difficult and has wide and surprising applicability.

Information resolves uncertainty. If someone flips a coin, you’re uncertain as to how it landed. With a fair coin (one that lands on each 50% of the time) the information needed to resolve your uncertainty regarding the outcome is called a “bit” (short for “binary digit”).

Toss two coins. 50% of the time they deliver a heads/tails combination (one bit again); two heads and two tails each happen 25% of the time – two bits each, because those events are twice as unlikely. Which, I suppose, is why we call a quarter “two bits”.

The weighted average of all outcomes – the probability of each outcome times the bits in each outcome – is the average information content in the event. In our double coin-toss, it’s .25*2 bits + .5*1 bit + .25*2 bits = 1.5 bits, or more generally, -SUM(p(i)*log2p(i)), if you care.

Try this: take some function and rate every application used by the employees that accomplish it. 5 means it’s critical, 3 means it’s important, and 1 means it’s used somehow. Add the ratings together and make each application’s rating a proportion of the total (“p” in the formula). Compute the formula – call it “application complexity” (more complex environments need more information to describe them). Fewer, better-integrated applications will reduce the complexity – and improve the end-user environment.

In English, the information formula means the more obvious the statement, the less information it contains. That’s why “dog bites man” isn’t news (low information content) – while “man bites dog” is.

I’m afraid this column will have no information content for many readers, as it may seem pretty obvious. It wraps up our series on interacting with end-users, though, and the series would be incomplete without it, so I’m going to press on.

Most Information Systems organizations have some form of executive steering committee to make sure its priorities and initiatives stay in line with the company’s strategic objectives and critical success factors. If yours doesn’t, you should form one right away.

A surprising number of IS departments have no corresponding feedback channel to help with the nitty-gritty day-to-day crud. If you haven’t organized a PC users group or something along those lines, your life is much harder than it needs to be.

If you support PCs and networks in an organization of any size, your chance of understanding the concerns and priorities of the end-user community are pretty dismal. It’s a diverse group of individuals, with widely varying priorities, levels of expertise, work habits, and deadlines. This constituency has no organizational clout, no easy consensus, and a large ability to create demand for your services.

A solution that’s worked well for me is to create an internal advisory group. Call it a PC Users Group, Network Advisory Council, or make it a Mentor Group function. The specifics are less important than how you position it. Your goal is to make this staff-level group a surrogate for the whole end-user community. Its consensus defines a lot of your requirements, and you, of course, set its agenda and facilitate its meetings.

Keep this group in the loop regarding server upgrades, software changes, training schedules, standard workstation configurations, PC delivery schedules, and every other aspect of your operation. Make sure its members understand your constraints and what you’re doing about them. Publicize it, give it a strong, clear advisory role, and also make sure its members understand their role in getting the word out to their coworkers. It’s a great way to transform fragmented demands into coherent requirements.

Comments

|In: Organizational Effectiveness|Last Updated:

I just received my first flame. Getting real hate mail is pretty exciting.

Plenty of readers have disagreed with me before. One or two have even called me a socialist, or Marxist, or something like that. Even the most passionate e-mails, though, have identified the subject and point of dispute.

Not this one. The first two words of the message were, “You are …” The remaining nouns and verbs don’t belong in a business publication. The message, if you’re curious, described my alleged double-jointedness and unsavory dining habits.

InfoWorld‘s readers are my customers, and I’ve often pointed out that customers are always right.

So I was wrong. Sue me. Change “always” to “usually”. (Not only am I not double-jointed, I haven’t been able to touch my toes without bending my knees since 1961, nor do I eat non-traditional foodstuffs.)

People who provide service to real, paying customers sometimes take calls from people who are a bit testy. That’s part of the job … up to a point. Beyond that point, the caller is abusive and the customer service representative has no obligation to listen.

(For those of you who act this way, some questions: do you think service reps set policy? Do you think they designed the feature you don’t like or the created the defect you’re trying to work around? No? Then why are you yelling and swearing at them? Companies pay these people to solve product-related problems, not to accept the anger and frustration you’ve PKZIPped and sent down the telephone line.)

Your staff members, dealing not with customers but with fellow employees, have no obligation to take abuse either. They do have an obligation to help solve problems, even when the person needing help is less than warm and friendly. Continuing our series on dealing with end-users, this week we talk about one-on-one interactions. Here are some tips that have worked for me in the past. I’m writing them for telephone conversations; they work just as well face-to-face:

Tip #1: Defuse frustration: You won’t have a productive conversation until you get past it. Empathize, and redirect attention away from the emotional context to the actual problem. One good technique: ask for microscopic detail. “I’m sorry you’re having a problem. Let’s see if we can get it fixed. Tell me exactly what you see on the screen.”

Tip #2: Focus on the problem, not the request: A caller may insist on a site visit, even when one isn’t necessary. Neither argue nor obey – redirect attention. Try this: “I’ll need to make sure I understand exactly what’s going on so I can dispatch the right person. Let’s start with what you’re looking at on the screen.”

Tip #3: Gather information first, and don’t argue: The caller really is experiencing difficulty. Find out exactly what the user was trying to accomplish, and exactly how … and the symptoms they’re experiencing now. Remote control software helps a bunch in this situation. If you don’t have it, have the caller walk you through the steps he or she took. At each step, ask the caller if his/her screen shows what yours is showing.

Tip #4: Resolve the problem: You should have a good handle on what the user was trying to accomplish and how. It’s taken awhile, but now you get to apply your technical, as opposed to your interpersonal, skills.

Tip #5: Leave the caller smarter than when he or she called: Once the problem has been fixed, explain what’s happened and what you did in some detail. It takes another minute or two, but if you help that user avoid the next problem, you’ve helped yourself in the long run.

This is a column on management issues, of course, so I get to palm off the little details, like how to actually troubleshoot. That’s where Brian Livingston and Brett Glass get involved. Good luck, pals.

Comments