“I’m sorry, sir, but that’s against our policy.”

There’s something about that phrase that sets my teeth on edge. Maybe it’s being called “sir” — yet another sign of my advancing age. But I don’t think so.

Policies exist to make sure everyone (or every situation that falls into a defined category) is treated the same. But as a customer, or as an employee, I don’t necessarily want to be treated the same.

I want to be treated fairly, yes. But that’s different.

Speaking of treating people fairly, in last week’s column differentiating policies and procedures I neglected to credit IS Survivalist Harry Kriz for the suggestion. Thanks, Harry.

Sadly, I can’t give attribution to the friend and colleague who provided the following anecdote from the Disney organization (by all accounts, including his, a well-run company) which underscores the limitations to documented procedures:

“When Oriental Land Company and Mitsui Railroad entered into the agreement with the Walt Disney Company to build Tokyo Disneyland in the early 1980’s, they required a full set of Standard Operating Procedure manuals for the running of the Park. While Disney was, and remains, more disciplined than most companies in its documentation, this requirement still employed 43 writers for a year.

“As a result, the Japanese management team had a full instruction manual for a Disneyland Park. Many would argue that Tokyo Disneyland is the best run Disney park in the world. But the manual-bound mentality had a drawback. One day, not long after opening the juice stand in the middle of Fantasyland ran out of paper cups. The SOP only had procedures for ordering paper cups for the next day, not during the middle of the day, so the manager closed the stand. (The normal, but undocumented, procedure employed by Disneyland managers for years to solve this problem was to borrow some cups from a neighboring Fantasyland restaurant).”

The moral of this story: If you do try to document procedures for every situation, or even if you don’t, add one more at the end: “If none of these procedures fit, improvise.”

And then, to wrap up this topic, my UK-based Perot Systems colleague Dan Heany offers this:

“Your latest article reminded me of the policy manual we had when I was an officer in the [London] Metropolitan Police. It comprised TWO, 6 inch ring binders and contained policies to cover all the foul ups that had happened since the force was founded in 1829!

“One that particularly stuck in my mind was the policy on ‘How to stop a runaway horse’ (clearly a very important topic in 1829). It started with the paragraph: ‘1. In order to stop a runaway horse, firstly, run in the same direction as the horse …’

“This always raised a question for me about the constable who caused that paragraph to be written — did he run away or did he run into the horse do you suppose?”

Which leads to one more piece of advice: In addition to asking yourself, every time you write a policy or procedure, “Do we really need to standardize this?” do yourself one more favor: Include a sunset date. Especially in this age of cheap storage, it’s way too easy to just let policies accumulate. And if you do your employees may figure you’re just horsing around.

My daughter Erin just caught her first fish.

Regular readers may recall that her dad spent years studying fish. Mine emitted electric impulses and lived in Africa. To catch them we dammed small streams, then shoveled the water through nets.

Erin caught hers with a salmon egg on a hook. It’s an entirely different experience. After we de-hooked the fish and returned it to the lake, I felt like we owed it an apology.

I might owe Managing in Manhattan an apology, too.

If you don’t recall, Manhattan wanted sample policies to use as a starting point for his own. In response, I suggested he avoid creating policies whenever possible.

In retrospect, I’m not sure if Manhattan wanted policies or procedures. Despite their linkage in the phrase “policies and procedures,” they’re entirely different concepts.

What’s the difference? The short version: Procedures are good, policies are bad.

The longer version: Policies define what behavior is and isn’t allowed. They exist to replace the good judgment of individuals with the better judgment of the institution. Static documents, they’re immune to context and nuance. As a result, they’re useful only for circumstances where context and nuance aren’t important. Reserve them for black-and-white situations.

For everything else, communicate principles. Doing so allows employees to be adults and managers to use discretion. Sure you’ll have difficulties in the gray areas, but that’s the nature of grayness.

Policies replace good judgment with inflexible edicts. Procedures, on the other hand, replace improvisation with step-by-step instructions. There are plenty of situations where step-by-step instructions are pretty helpful.

Consider the lowly tape backup. When you first install a new tape backup system, you need to do a fair amount of configuring and testing to make sure all data is recoverable. If you aren’t using an automated tape handling system, you also need to be able to locate and identify tapes when you need them.

If your operators follow your written procedure (not always a safe assumption) you ensure the utility of your backup system. If they don’t, it doesn’t matter how much you spent on the technology — it’s worthless.

“Procedure” is just another word for “process”. Well-defined, tested processes are important tools that help your employees succeed. Here are a few more tips:

1. Only write procedures for recurring situations or emergencies you can anticipate: You don’t need procedures for everything. For one-time occurrences or unanticipated exceptions, have this written procedure: “Use your best judgment and improvise.”

2. Keep them simple: State purpose, scope, and authorization, so each procedure is applied only in the right circumstances and by the right people. The rest is a numbered list of steps.

3. Don’t confuse procedures with tutorials: A procedure isn’t an instruction manual. And if you need an instruction manual you also need employee training. Provide it.

4. Test, adjust, test, adjust, and test again: Process designs are never right the first time, so don’t try: Get close tinker, and make sure each procedure works.

5. Make sure you can find the right one: Use your intranet. Burn some CD-ROMs for when the intranet is down. Keep hard-copy too.

Finally, keep them refreshed. Retire those that are irrelevant and reinvent any that are obsolete, because you need to periodically reinvent the wheel. If we didn’t, we’d all look like Fred Flintstone, driving cars that roll on logs.