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?

It’s scandal time!

Your intrepid reporter has uncovered an outrage of major proportions: Not one of the major ERP suites … not SAP, not PeopleSoft, nor Oracle … scales effectively. It’s true!

Oh, they scale up just fine. I’m sure there’s some level of organizational size and scale where they break, but I don’t know what it is. Here’s what I do know, though: They don’t scale down very well.

Imagine you run a 45 employee company, and one of the above-mentioned vendors offered to give you their software for nothing. (Why? Maybe it’s a charitable non-profit whose cause they like. Don’t worry about it.) Both the cost of the license and the cost of annual maintenance and upgrades are covered. Not only that, but they’ll handle all of the installation, customization and integration.

Should you accept?

Probably not. I suppose it’s possible that with enough customization you could trick one of these packages into handling your operation, but what would be the point? Major ERP suites are built on a set of assumptions, largely hidden, regarding how a company operates. They assume, for example, you have an accounts payable department, with people who spend much of each day receiving invoices, matching them up with purchase orders, and routing them for approval to pay. They don’t assume you have Jill, who deals with maybe a dozen invoices a week in her spare time, getting approval to pay by yelling to the guy who lives three cubicles down, “Hey, Jack, did you ever get that toner cartridge I ordered for you?”

The scaling-down question has received little attention in IT, and it isn’t limited to software packages. Most of what we consider to be professional ways of implementing IT … the software, tools, and especially the methodologies … are designed for big. When your needs are small, they don’t scale.

Modern methodologies do recognize the fallacy of big projects. The idea of “chunking” big efforts into a collection of separate six-month projects executed by small, focused teams has entered the mainstream. You, however, have a four-person IT department which you lead when you aren’t busy helping the CFO figure out how to build a pivot table in Excel that links to an Access database. For you, an eight-person six-month project is far from small. It’s equivalent to the entire work output of your department for a year.

The heads of IT who run operations this size (they rarely call themselves CIOs) read about “industry best practices” and chuckle, knowing that using them would bankrupt their employer. “Best?” Not in a small company. When a large development effort is Ralph working with Jill to activate electronic bill pay in QuickBooks, it’s a sure bet Ralph shouldn’t first spend a month or two writing use cases. As for Ralph’s test plan: He’ll have Jill make a one-dollar payment to the company. If it arrives within a week, everything is working.

It’s been more than twenty years since IT discovered the importance of good process. And good process is vital in large companies. The reason it’s vital explains why scaling down is so hard. It’s the result of the formulas for two different kinds of line.

The first is the combinatorial formula: n(n-1)/2. It describes the number of relationships between employees, which translates to the cost of doing business through relationships. If you have few employees, you don’t need much in the way of process. Work gets done with little organizational friction because everyone knows everyone. With a lot of employees, though, everyone doesn’t know everyone, and the cost of doing business this way skyrockets.

When you rely on processes, in contrast, you apply a different formula: a*n + b. That’s the formula for a straight line, and what it means is that processes impose overhead, but scale well. It’s great when you have a lot of employees. The overhead becomes irrelevant compared to the ability to grow without costs going through the ceiling.

But if you run a small operation, be cautious about adopting them.

They weren’t, after all, designed to scale.