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.