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.