Issues arrive in five categories: Process, knowledge and skills, attitudes and behaviors (that is, culture), technology, and organizational structure. The fix doesn’t have to be the same as the cause, however. For example, you can fix a process problem with training to increase skills and knowledge.

Finding suitable solutions to problems while showing good judgment and a sense of perspective is an important characteristic of leadership. I just heard an excellent example … of the exact opposite.

The situation: IS, in the final stages of cleaning up after a computer virus, announced its plan for preventing future ones. Its “solution”: Eliminate floppy drives. My correspondents work in the marketing department. Floppy diskettes are their sole medium for exchanging data between the PCs they use themselves and the Macintoshes favored by their outside contractors, so they raised objections.

IS responded by offering to leave one PC intact, but with a locking device attached to its floppy drive. The user of this PC is to interrupt her work, unlock the drive, manually scan the diskette, transfer files, and re-lock the drive whenever someone needs to read a floppy. To satisfy the rest of the company, IS also plans to set up a central scan station it will administer and operate.

“We are not trying to make life difficult for you,” wrote the person responsible for this policy. It’s a true statement, too. “Trying” means expending effort, and as is usually the case, making life difficult is effortless. It’s making life easy that takes thought and work.

Three features of this case make it especially sad. The first is that whether the issue is virus-prevention, security, or data corruption, the first reaction of many in IS is to erect barriers that interfere with end-users’ ability to do their work. Getting rid of floppy drives in response to a virus attack is a predictable, baby-with-bath water response to the problem, equivalent to eliminating keyboards because someone sent out a letter containing erroneous information.

The second feature of this case, and an especially unfortunate one, is that the steps outlined by IS, while draconian, don’t solve the problem. The vast majority of viruses these days are macro viruses arriving through documents attached to incoming e-mail. Eliminating floppy diskettes is a lot like nailing the windows shut while leaving the front door unlocked – you get neither security nor fresh air.

And of course, there’s the third, most obvious flaw in IS’s strategy: Through the simple expedient of installing a reputable virus-scanner on every workstation, the enterprise could receive real protection from virus attacks.

Why did IS ignore this obvious choice? In the absence of hard evidence, we can only guess. One likely culprit is the budgeting process. IS would have to pay for the virus scanning software and the labor needed to install it (although in most cases virus scanners can be installed painlessly across the network). Floppy disk elimination moves most of the costs and all of the inconvenience to the rest of the business. So once again budgeting, a process that exists to promote good planning and fiscal accountability, instead has its customary effect of creating incentives to make wrong decisions.

No process is perfect – not budgeting, not inventory management, not salary administration – nothing. When you blame your own bad decisions on a process you’re making an excuse, much like a customer service representative who tells you, over and over again, “I can’t do that for you because it would violate our policy.”

Issues may stem from process problems, deficient skills, bad habits or attitudes, poor technology, or organizational barriers. In this case, a virus attack, the problem was technological – the susceptibility of modern PCs to virus attacks. IS (if our guesses are accurate) allowed the budgeting process to divert it from the optimal response of installing a companywide virus scanner, an easy technological fix.

Instead, it responded to one process problem by creating another one. Why?

The problem is one of culture, the attitudes and behaviors of an IS leadership that chooses to erect barriers to effectiveness throughout the company because it isn’t ept enough to find a creative solution to its budget limitations.

There are two kinds of people in the world, according to a tired joke: Those who divide the world into two kinds of people and those who don’t. I’m one of those who do. I divide the world into engineers and everyone else.

Being an engineer isn’t a matter of training or expertise, or at least not the way I use the term. Engineers look at every problem as a puzzle they can solve, so long as they’re smart, systematic, and ingenious enough and look at it from the right angle.

The rest of the world looks at problems as, well, as problems. Things that make their lives worse. Obstacles. Barriers. Something you call an engineer to take care of for you.

Engineers have a hard time working with non-engineers because of how much time and emotional energy the non-engineers expend bemoaning their fate and how hard it all is. Non-engineers have an even harder time working with engineers because the engineers display so little empathy.

There’s room in the world for both. For the non-engineers, I figure we should reserve the Aleutian Islands.

Correspondence from an IS Survivalist brought this to mind. Following my suggestions on how IS can improve its relationship with the rest of the business, this scarred veteran described a situation that’s all too common: End-users who are all too willing to complain, but who aren’t willing figure out what they really need.

How do we deal with them, Mr. Know-it-all Consultant?

Some problems require more extreme solutions than others. When asked how to fix the acoustics at Northrup Auditorium, for example, the great conductor Eugene Ormandy had a one-word answer: “Dynamite.” Recalcitrant end-users also call for extreme solutions, although not as extreme as Ormandy’s. Here are some possibilities:

Extreme Technique #1: Make sure you aren’t the problem. Because it’s so easy to blame the users, ask a couple of the best analysts you know to review the situation with you. See if they can offer any suggestions or point out flaws in your technique.

Extreme Technique #2: Ping pong. In every meeting tell the complainers, “Here’s what I need from you. As soon as I get it, I’ll build it into the prototype.” Every time they hit the ball back to you, put it back on their side of the table again. Use prototyping tools so you can do your part at great speed. Every time they’re late send a reminder on e-mail, copying your boss and the project’s sponsor.

Extreme Technique #3: Assign a leader. According to legend (most of which he apparently authored himself) Wyatt Earp once faced down a mob by appointing a leader, pointing a gun at him and saying, “Get these people out of here.”

Look the biggest trouble-maker in the eye and say, “It’s clear not everyone wants the same thing in this system. Fred, you seem to have strong opinions about it so I’d like you to be my point of contact.” Then, ask Fred, every step of the way, “If I build it this way will it be what you need?”

Not only will Fred will have a hard time complaining, he’ll be on the receiving end of everyone else’s complaints – after all, you built it to his specifications and he was supposed to coordinate with everyone else.

Extreme Technique #4: Escalate. There comes a time when the CIO has to explain the facts of life to his counterpart in the end-user organization. “For us to build the system you need, we need someone from your organization to take responsibility for its design, and we need you to sponsor the project so there’s someone with enough authority to resolve issues and priorities. Otherwise, we’ll just have to guess, and there’s no way we can get it right that way.”

And then there’s the last and most extreme technique: Look the complainers dead in the eye and speak the following words: “You have two choices: You can complain, or you can design. Pick one.”