Time for a logic puzzle: How are the following two pairs of statements the same, and how are they different?

First pair: IT has to be business-driven. We have to stop buying technology for technology’s sake.

Second pair: A stitch in time saves nine. An ounce of prevention is worth a pound of cure.

Got the answer? Here’s mine:

They’re the same in that both pairs are trite. They’re different in that the second pair provides good, if cliched, advice, where the first pair are like bad baloney — there’s not enough real meat in ’em.

I have yet to find an IT organization that buys technology for its own sake. I have run into quite a few whose leaders and staff had insufficient business acumen and poorly developed bunk detectors, falling for stories about the amazing business improvements to be had from one technology or another. But that’s different. Bad judgment isn’t the same thing as purchasing toys.

As for IT being driven by the business, it’s one of those half-truths that’s more dangerous than ignorance. It’s also a “truth” that’s contradicted by another truism — that IT should be proactive, not reactive. Would someone care to explain how IT can be both proactive and externally driven?

The optimal solution is more complicated, as optimal solutions usually are. Let’s start with this: In the absence of technological change, business practices stabilize and eventually stagnate. Look at every new business model that’s appeared over the past fifty years or so. You’ll have a hard time finding any that weren’t enabled by new or improved technologies, often information technologies. Whether the new business model was “big-box” retailing, direct marketing, the shift from grocers to supermarkets, or the broad trend toward product diversification, all appeared after some technological innovation made possible what was previously impractical.

An obvious example was the Internet. Imagine you were the CIO of a major travel agency in the early 1990s. Because you understood IT is supposed to be business-driven, you waited patiently (and in vain) for someone to ask you to put the company’s services on-line.

Bad call.

A less-well-known example: During the early days of computer telephony integration (CTI), a survey showed that telecommunications managers were the least-likely CTI advocates in most companies. How depressing: The individuals most likely to run across a business opportunity saw it as just another headache instead, and Somebody Else’s Problem.

One of the standard tools of strategic planning is SWOT analysis, for strengths, weaknesses, opportunities and threats. (It’s spelled backward, by the way: The analysis should start with threats and opportunities, reserving weaknesses and strengths for later.) When the business looks for threats and opportunities — for external trends with the potential to change your industry — where are you? In your office, waiting for the telephone to ring, or in the thick of the discussion?

Now about those strengths and weaknesses. Most of these will focus on internal businesses processes. Unless the process owners are simply incompetent, chances are good your internal processes are as good as they’re likely to get without the addition of some new, enabling information technologies, which you’re supposed to know more about than any business leader.

So what’s your role, whether you spell it SWOT or TOWS? You could wait at your desk, secure that your responsibility is to be driven by the business. If that’s your decision, when the most important threats and opportunities are the result of technological change, I have just one question:

If not you, then whom?

Pessimists, we’re told, look at a glass containing 50% air and 50% water and see it as half empty. Optimists, in contrast, see it as half full. Engineers, of course, understand the glass is twice as big as it needs to be.

Which explains a major source of friction in IT-related projects: Different umwelts.

Umwelt is a century-old concept introduced to ethology, the study of animal behavior, by Jakob von Uexkull. It’s the recognition that every animal exists in a unique perceptual universe that’s closed to human beings other than through inference: Much of a bee’s world is ultraviolet; a dog’s nose does a lot of what we use our eyes to accomplish. Then there are the electric fish I used to study, which perceive their world through a sense we lack entirely.

Oversimplifying just a bit, IT project teams consist of (at least) one professional optimist, one certified pessimist, and a collection of engineering types. They have to collectively commit to a plan and stick to it, but their umwelts differ.

The optimist is the business sponsor. Corporate executives are supposed to be optimists — they’re supposed to see possibilities as certainties … as real, and motivate everyone around them to envision them as real, too.

It’s hard to be chronically optimistic if your mental habit is exploring the complexities that make even seemingly simple projects difficult. This is one reason it’s very hard for many business executives to understand why IT projects cost so much. “It’s a simple process!” you’re likely to hear a business executive complain. “Why do you IT people have to make it so expletive complicated?”

Engineers — the core staff of your average project — are, for the most part, realists. They understand that the “simple process” really consists of the simple process itself, which takes care of maybe 80% of the situations the project is supposed to address; the most common exception to the process, which takes care of 80% of the rest; and another 327 exceptions, some of which the business really needs to deal with, and the rest of which nobody has had the time to combine with any of the other exceptions to simplify things.

The project manager is, of course, the pessimist. Project managers have to be pessimists, because there’s a short phrase that describes optimistic project managers perfectly: “Chronically over budget.”

Project managers have to be pessimists, because they’re the ones who are held accountable when unanticipated problems, like a key developer being hired away by a competitor, occur. These things happen in every project, of course, so good project managers anticipate them.

Project managers have to be even more pessimistic, because in addition to being held accountable for these anticipated unanticipated problems, they’re also the ones held accountable when harder-to-predict unanticipated problems arise, such as a serious bug in the development toolkit. So the best project managers make allowances for unanticipated unanticipated problems in their plans, too.

Project managers and business sponsors are supposed to meet weekly to review progress and discuss issues that arise as the project progresses. Many of these meetings are entirely dysfunctional. The project manager, who is working from a perfectly reasonable plan, collides with the business sponsor’s entirely predictable expectations. It’s an umwelt thing. The solution is to get the umwelts to converge, which is a matter of creating a corporate culture conducive to good project management.

Project managers can’t succeed unless they work in a project-management-friendly corporate culture. But project managers have projects to manage — they’re too busy to have to influence the corporate culture. That’s where you, as the head of IT, have a role to play. It’s your job. That’s why they pay you the big bucks.

There are three major elements that must be present in a project-management-friendly culture:

  • Appreciation that the overhead added to projects by use of good project management disciplines is worth the effort
  • Understanding of the complexities of software development
  • Recognition by both project managers and business sponsors of each other’s umwelt. Which is to say, they don’t need to understand each other instinctively, but do need to understand that a different umwelt isn’t wrong. It’s just different.

Project managers need strong business sponsors just as much as business sponsors need strong project managers. It’s up to you to make sure the enterprise has an ample supply of both.