“When I am right, no one remembers. When I am wrong, no one forgets,” Doug Harvey, a professional baseball umpire, once lamented.

In IT we face a similar dilemma: Our responsibility is the delivery of working software that adheres to the specifications. When we do, and the specifications are appropriate, and the business makes use of the software to its fullest capabilities, and everything improves the way it was supposed to, the rest of the business takes it for granted. Or even worse, it grudgingly acknowledges that for once IT did something right, making it clear we shouldn’t feel too good about this victory.

There is no such thing as an IT project. It’s always about business change. When the business change isn’t successful, we both know what happens next: No matter what really went wrong, IT will get the blame. Why? Because it’s always safe to blame IT. We’re convenient scapegoats for everything that can (and usually does) go wrong in a project.

And there’s nothing we can do about it. Our job, after all, is done when the software works according to the specifications. Everything else that has to happen is someone else’s responsibility.

Right?

Right … if, that is, you practice the Theory of Else.

The Theory of Else, whose practitioners hold the word “they” in high esteem, asserts that it’s better to determine who else should have done something different than it is to determine what you can do to ensure success.

In many IT organizations, the Theory of Else is ingrained in the culture: “The software met the specifications. It isn’t my fault that the specifications were wrong.” “The software can do what the business needs it to do. It isn’t our fault that the business failed to use it the way we designed it.”

Heck, some IT organizations missed most of the new economy, figuring it was someone else’s job to figure out that e-commerce was important. IT’s job? To build software that met the specifications once they did.

If you can get away with the Theory of Else, more power to you. There’s no particular nobility in doing somebody else’s job for them, and there’s a lot of safety in building software that works just fine only nobody in the business ever puts it to the test.

More than likely, though, the Theory of Else will work for everyone else in the business, leaving you holding the bag. In their eyes, these are all IT projects, so if they don’t deliver the expected returns, it must be IT’s fault.

Which means IT has to practice a different theory — the Theory of Everything Else. The Theory of Everything Else leads to this IT mission statement: “We do whatever needs to get done that nobody else chooses to do.”

It might not be elegant. It falls a few parsecs short of being diplomatic. But it has two useful consequences.

The first is that it’s a turf intrusion. If, for example, nobody develops a communications plan, the most likely result is that employees will resist the planned change strenuously, causing it to fail or at least disrupting its success. So instead, imagine you practice the Theory of Everything Else and develop a communications plan for the affected employees.

“Who do you think you are! That’s a job for Internal Communications, not IT!” or so you’ll most likely hear from the head of Internal Communications, who thereby volunteers for the job.

Likewise business process redesign: “Who do you think you are! That’s our responsibility,” you can imagine the Chief Operating Officer exclaiming. Which, of course, it is, again letting you off the hook specifically because you carefully put yourself on the hook.

You’ll undoubtedly step on some toes by practicing the Theory of Everything Else. Which brings us to the second benefit: While you might step on their toes (yes, there is a pun there, but only if you insist), which might cause some resentment, that’s far better than the alternative.

Which is, of course, being on the wrong side of their Theory of Else.

In response to the various keep-your-mouth-shut stratagems presented in recent columns came this inquiry: “Is there no room in the type of discussion you outlined to share our ideas with others, and simply ask for feedback? Can’t strong leaders ask for and actually accept contrary positions, or are we so governed by fear of retribution that we would be fools to offer a contrary idea, in which case, “strong leader” becomes an oxymoron?”

Of course, strong leaders can ask for feedback and listen to contrary positions without inflicting consequences. When they do, some people just might offer those opinions. Others offer whatever opinion they think the leader wants to hear. A third group … the wisest in many circumstances … remain quiet, figuring that once a strong leader offers an opinion, his or her mind is sufficiently made up that the risk of offering an alternative point of view vastly outweighs any possible benefit.

Strong leaders offer their ideas and honestly solicit honest feedback, hoping to hear something useful. Stronger leaders hold their own ideas in reserve, and improve the odds of hearing useful feedback by doing so.

Listening is hard, especially when you have strongly held opinions. Organizational listening is harder. Listen to an individual and you have two difficulties to overcome: keeping your own mouth shut and understanding the other person’s meaning. Try to listen to the organization and you’re faced with a choice of problematic channels, none well-suited to telling you what you desperately need to know, which is What’s Going On Out There?

One of the most difficult issues in organizational listening is the Proximity Trap. It’s the almost unavoidable tendency to listen more to those who have the most access to you.

Whether it’s because you like them, or simply because they sit nearby, you converse with some people more than others.

This can lead to minor distortions, or it can cripple your ability to make decisions based on an accurate understanding of What’s Going On Out There. In particular, in many organizations access and knowledge are inversely related: People in the field know what’s really going on, but they have the hardest time reaching you.

Military thinkers have been aware of this issue, the staff vs field problem, for centuries. Sometimes they solve it, sometimes they’re quite happy with it (in peacetime it’s far more comforting to hear what you want to believe than what’s really happening) but any good military officer is familiar with the topic.

Military leaders have an almost formulaic understanding of the need to reserve time and attention for understanding What’s Going On Out There. It’s part of their job: C3I (command, control, communication and intelligence).

Business leaders as a group pay less attention to such matters for some reason. Far from reserving time specifically for organizational listening, many consider it to be something done in their spare time, when they aren’t needed for more important or urgent matters. So when they can relax they hold employee lunches, “skip meetings,” or practice their open door policies by actually being inside their doors.

We run our businesses lean and mean these days, which means staffing is thin throughout most companies. Thin staffing turns situations that would otherwise have been minor inconveniences into major crises for the simple reason that there’s nobody available to deal with them.

Come a crisis and leaders cut out inessential and time-intensive activities. Frequently, this means they stop listening to anyone other than the people with easy access.

Which is exactly the wrong thing to do: It’s in difficult times that leaders need the best information the most urgently, such as what’s going on in the field.

But finding out takes time and they have no time, so instead they have to trust their gut and those around them who have no better idea of What’s Going On Out There than they do.

What, you thought decisions from headquarters are dopey because they come from stupid people?

Well, sometimes. More often, it’s because they fell into the Proximity Trap, so they’re worse than stupid.

They’re ignorant.