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?

Management and leadership are, as has been mentioned once or twice, different. Precisely how they differ is a matter of some controversy, and quite a lot of ink has been spilled arguing what exactly distinguishes the two.

There has been somewhat less discussion of which is the more important, possibly because the answer is so obvious.

It is obvious, isn’t it? Just listen to the two words. Leadership sounds downright inspirational, forward-looking, and important. Management, in contrast, conveys overtones of control, drudgery, and hard, tedious work.

Hmmm. Maybe it isn’t so obvious after all. If we use the Edison Ratio as our metric (1% inspiration : 99% perspiration), perhaps management is the more important of the two. After all, inspiring the troops to battle on for glory and mother country doesn’t do much good if you haven’t first taken the elementary precautions of arming, training, and briefing them.

From a personal perspective the distinction matters only in how you decide to allocate your time. To be effective, you have to be proficient at both — to inspire people to follow your lead, and to make sure they do the job well and deliver results. It’s a reality as true for a chief executive officer as for a first-time supervisor.

Organizationally, the sequence is more clear: Manage first, then lead.

Which is to say, before anyone will take IT seriously as an equal partner, fully engaged in the development of business strategies and tactics, it first has to deliver stable, high-performance systems and networks; it has to complete projects on-time, within the planned budget, and with the original list of deliverables intact; and those deliverables have to help the business change and improve as intended.

Oh, and the Help Desk has to be helpful. Don’t ever underestimate the importance of the Help Desk. It’s impact on IT’s image would be hard to overstate. The Help Desk is the WD-40 of IT, lubricating its relationship with the rest of the business. It’s where the battle for business users’ hearts and minds is won, one resolved problem at a time.

Those stable networks don’t win anyone’s hearts and minds. They do, however, lose them. They’re critical to IT’s success, but only in the way showing up for work is critical to an employee’s career. It isn’t something you get credit for. It’s expected.

Which leaves projects as the battleground for IT’s credibility in the enterprise. IT project completion rates were poor during our industry’s Jurassic period, when file-oriented batch mainframe dinosaurs roamed the enterprise; they continued to be poor after the introduction of database management systems and on-line programming techniques moved us into our Cretaceous period; and they still hadn’t improved as additional waves of technology propelled us through geologic time to the Pleistocene era of object-oriented programming.

IT organizations have finally started to figure it out: Better project completion rates come from better project managers, not better technology. Project completion rates are trending up at last, and that’s a good thing. The only problem is, they’re trending up just in time to be not enough.

Project completion rates are about delivering software to the business that adheres to specifications. Which was enough when IT figured its proper role was to be a supplier and the enterprise was its customer.

The world has changed again, though, and as an industry we’ve caught up just enough to be a step behind the times. Because while we’re finally completing IT projects, the business is figuring out that there is no such thing as an IT project.

We need to take the next step and take it quickly: We and our partners in the business need to stop completing projects and start excelling at change.

Because in the end, taking control of business change is the only goal that matters.