All Posts in Organizational Design

|In: Leadership|Last Updated:

Worthington, Minn., claims to be turkey capital of the United States. Worthington has competition, though. Example: In his autobiography, Dennis Green, head coach of the Minnesota Vikings, described his plan to sue the team’s owners if they refused to sell him a 30 percent share of the company.

Since a) privately held companies have no legal obligation to sell themselves to head coaches; b) writing an autobiography when you’re as unaccomplished as he is reveals an ego as big as Green’s waistline; and c) when you play hardball politics you’re best off doing it covertly; Minneapolis gets to include Green in its turkey production total. And at 285 pounds, he compensates for a large fraction of Worthington’s turkey production all by himself.

While you’re in the mood for turkey, here’s another turkey story for you from a reader I’ll call Stan, who worked for “a major US corporation.” The words are mostly his — I’m lightly paraphrasing from his description.

Once upon a time, Stan was a front-line manager responsible for keeping a large number of PCs up and running in five locations. Stan instituted a preventive maintenance program, and logged the results to help him spot trends — information that came in mighty handy on several occasions.

Then his management instituted a new trouble calls process. Instead of end-users’ calling Stan’s department directly, they were directed to call the front desk, which in turn called the help desk at corporate headquarters, which then opened a trouble report and paged Stan’s department, alerting them to a problem occurring probably no more than a several dozen paces away from their office.

Stan’s analysts would then log onto the corporate mainframe, find the trouble report, assign it to themselves, change its status to open, and then fix the problem. Afterward they retrieved the trouble report, closed it, and reported their time (including the “administrivia,” which was usually more time than it took to fix the problem), and what they did to fix it.

One thing you get from an advanced help desk system is statistics. Lots of ’em. And so Stan got some feedback on the success of his preventive maintenance program: Of all the offices, his had the smallest volume of trouble calls.

You know where this is going. Stan’s managers were devotees of the if-you-can’t-measure-you-can’t-manage school of process supervision, but not graduates of the be-careful-what-you-measure-because-that’s-what-you’ll-get college of advanced techniques. They measured productivity by number of trouble calls responded to, and therefore Stan’s office was the least “productive.” Management could not justify paying three salaries for such an “unproductive” office and gave Stan 30 days’ notice. Stan predicts that when the trouble call volume increases for this office (as it inevitably will), management will be able to point to its statistics to show how cutting one salary raised productivity.

OK, let’s be serious for a minute. Stan’s management made two basic conceptual errors. First, it designed its new process around management reporting, not staff effectiveness. Management reporting became the goal of the system, not a desirable byproduct. Problem management systems must always improve convenience for end-users and be unobtrusive and helpful for technicians, or they’ll fail.

Far worse, though, Stan’s management confused internal process management measures with external, business results measures. “Trouble calls responded to” merely measures a departmental sub-process, not a business result. The business result is measured by end-user up-time, however it’s accomplished.

Stan’s management, obsessed by numbers, had no interest in the business result. (No, I won’t name the company. If I did, companies that might do some soul-searching wouldn’t bother.)

Oh well. At least we won’t suffer from a turkey shortage this Thanksgiving.

Comments

|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