Trying to cut costs in a company by trimming the IT budget is like trying to cool a room by blowing cold air at the thermostat: The harder you try, the worse things will get. But since you’re reading the thermometer built into the thermostat, you’ll be sure you’re improving the situation.

I can almost hear the yeah-buts. “Yeah, but you can’t just write a blank check to IT.” “Yeah, but you have to hold the CIO and CTO accountable for IT spending.” “Yeah, but IT has to generate a measurable return on investment.”

Yeah, but we’ve replaced management by objectives and management by walking around with management by platitude.

Last week’s column inspected quicker/cheaper/better — the process triad — and found that the “quicker” consists of two independent measures, cycle time and throughput. If you don’t pay attention to both, process redesigns can do more harm than good.

This week’s column focuses on “cheaper,” which turns out to consist of three measures, not one. To make a process, or for that matter an organization less expensive to operate you can reduce fixed costs, variable costs, or total costs. The distinction between fixed-plus-variable cost reduction and simple cost-cutting is the difference between smart, well-considered business improvement and felonious stupidity.

I’d stop here, figuring it’s just too obvious to need further explanation, except that I’ve seen, and sometimes endured, quite a few IT cost-cutting exercises during my increasingly long tenure in this business, and every single one ignored this, the most basic concept in cost accounting. (For that matter, I recently corresponded with one of the industry’s most respected authorities on total cost of ownership (TCO), who waved it off as an irrelevancy. And people pay more for his opinion than they do for mine. There ain’t no justice, or even worse, perhaps there is.)

To understand why looking at costs from a fixed-plus-variable perspective is so important, look what happens when you don’t: You cut total costs, usually by laying off staff since labor is the most expensive line item in the IT budget. Layoffs reduce costs quickly and convincingly. Of course, they also reduce your ability to deliver working product, which in the case of IT means working software.

Simple-minded reductions of total costs, in other words, reduce delivered value. Almost without exception, this reduction in value exceeds the reduction in costs, which means cost-cutting leads to a net reduction in benefit. It’s the thermostat problem.

Separate fixed and variable costs and you get a very different result.

Fixed costs are your overhead — the cost of turning the lights on. Reducing overhead has no effect on your ability to deliver results.

Variable costs, also known as unit, incremental, or marginal costs, are what you spend to produce one more doohickey. Reduce variable costs and you don’t affect your ability to deliver results either. Reduce fixed and variable costs and you reduce expense while leaving value untouched. You increase benefit, where mindless cost-cutting reduced it.

The popular subject of offshoring illustrates this concept nicely. Why send programming work offshore? To reduce variable costs. Whatever your measure — cost per line of code, cost per function point, or cost per hour of programming effort, it’s lower in India and the Philippines than here.

Between networking costs, the infrastructure needed to coordinate activities on multiple continents, and the additional responsibilities associated with monitoring vendor performance and managing a multicultural, 12-hour-time-shifted business relationship, offshoring has higher fixed costs than using staff resources or on-shore systems integrators.

I was talking about fixed-plus-variable analysis with a client, recently — a former teacher of high school algebra. “It’s nothing more than the equation for a straight line,” I mentioned, “y = ax + b.”

“That’s all you need to say,” he responded. “I understand completely.”

Which means, I guess, that to understand the relationship between the cost of information technology and its benefits, you’re better off with a high school algebra teacher than a high-priced TCO consultant.

Quicker, cheaper, better — pick two.

It’s an old bit of business wisdom, providing a valuable caution about the consequences of process re-engineering. While there no doubt are circumstances in which you can improve all three, there are many more where the attempt is costly and the results are a shambles.

Some of the worst disasters I know of, though, appeared to be successes — achieved through the magic of bad metrics, coupled with the sad reality that plenty of self-appointed authorities in re-engineering have never once been anywhere near a class in real engineering. If they had they’d have known that none of these three process attributes can be characterized by a single measure.

Take quicker. Your average process engineer will walk in, reduce cycle time, and walk out, serenely confident that business improvement has taken place. No real engineer would do anything that boneheaded, but few real engineers redesign business processes for a living.

Real engineers understand that “quicker” consists of two entirely independent measures: cycle time (latency for you network folk) and throughput (aka bandwidth). Cycle time measures how long it takes to get from the start of a process to its finish line; throughput measures how much product emerges from the process in a given unit of time. They’re independent measures.

Don’t believe it? Imagine ten people sitting at a table. A metronome on the table ticks once every second, and on each tick everyone at the table hands a sheet of paper to the person on their right, except for the last person who places a sheet into an outbox.

Sensing opportunity, the company in which this table resides hires a consultant. His assignment: Make the process quicker, and if possible cut costs at the same time. And so he does. How? He cuts eight people out of the process, that’s how. The trade-off is that instead of only needing one second to handle each sheet of paper, each person at the table now needs four. He changes the metronome to tick once every four seconds, lays off eight employees, and starts things up.

The consultant points at the numbers with pride, and adds a case study to his website. Cycle time with the old process was ten seconds — the time required for a sheet of paper to move from one end of the table to the other. For the new process it’s only eight seconds — a respectable 20% reduction, with an 80% reduction in cost to go with it. It’s a triumph of process re-engineering.

Too bad the business has become a disaster area, but that’s what has happened. Why?

Look at throughput instead of cycle time and the answer is obvious. The old process pushed through 60 pieces of paper per minute — a new sheet entered the outbox every second. The new one? The metronome ticks once every four seconds, which means it processes only 15 pieces of paper per minute. That’s a 75% reduction in throughput.

The problem is fixable, of course. You can add three more processing lines to regain the lost throughput without affecting cycle time, and still have only eight people processing paper instead of ten. Not bad.

Only … now you need a dispatcher at the beginning of the process to allocate the paper among your processing lines, and a collator at the end to collect it from them. Not only have you lost your cost savings, but when you add the time needed for allocation and collation you lose the cycle time benefit as well.

Real-world business processes are, of course, more complex than a table full of people handing pieces of paper to each other. (Aren’t they?) Designing real-world processes that improve cycle time without harming throughput, or vice versa, is a tricky business.

That’s all very interesting, but what does that have to do with IT? We just deliver the software — what the business does with it isn’t our problem.

To answer a question with a question: When the whole thing blows up and you say, “Don’t look at us — the software works just fine,” do you really think that’s going to protect you?

Me neither.