Last week’s column introduced a new process design technique — the Six Stupid methodology. Six Stupid is based on the well known phenomenon that a group of people is dumber than its stupidest member.

In contrast to Six Sigma, which reduces variance to six standard deviations from the mean, Six Stupid designs processes based on what one person can put on one PowerPoint slide and persuade the other five team members will work really, really well.

One correspondent, reading the column, suggested I trademark the name, reserve www.sixstupid.com, and charge big bucks for seminars. Hey, if you’re willing to pay …

Another, more serious-minded than the first, pointed out that in both of the situations I described (a furniture order that could only be routed from Shipping to Restocking by way of my Manhattan apartment, and an air travel experience that nearly forced me to fly from New York to Florida by way of a blizzard zone), the companies had out-of-control processes.

True enough. My guess, though, is that they were out of control by design, in that nobody ever thought to build controls into them. And in the absence of good process controls, the only control left is the process itself — following the steps, which guarantees frequent horrible outcomes.

Business processes have six possible goals — perhaps “points of optimization” would be a better way to say it. They are: Reducing overhead costs, reducing unit costs, improving throughput, decreasing cycle time, adding excellence (the ability to adapt to unexpected circumstances, add nifty product features and otherwise do cool stuff), and increasing quality (reducing the number of out-of-specification outputs).

A good process control is nothing more than one of these goals, expressed as a number instead of a sentence. Putting process controls in place lets every participant know which goals to pay attention to, and, as a consequence, that it’s the goals, not the steps, that matter most.

Six Stupid process designers don’t start by establishing the process goals. Instead, everyone on the design team operates from a different set of assumptions about what they’re trying to achieve. But that isn’t important, because all will agree their goal is to “do what makes sense.” That’s clear, isn’t it?

And so the design team toils away, eventually agreeing to a series of steps everyone is supposed to follow. Proud of their efforts they publish the flow chart and disband, leaving it to whoever supervises the workgroup to implement it. And since the process has no stated goal, the supervisor has little choice. The team’s instructions: Follow the steps, regardless of the consequences.

That’s how bureaucracy happens. What’s particularly sad is that when most of us deal with a bureaucracy, we blame the bureaucrats. But it isn’t their fault. They’ve been given clear instructions — just follow the steps, fill out the forms, dot the i’s and cross the t’s.

Compare this to a process that follows a more rational methodology than Six Stupid. The first step is to define inputs and outputs (and perhaps resources and constraints as well). The next is to decide on the goals. After that, the designers will ask the musical question, “How will anyone know if we’re heading in the right direction?”

That’s where metrics come from, or are supposed to come from at least. If the top process priority is throughput, the process will include information outputs that allow the process manager to measure it. If the second priority is unit cost, cost information will come out of the process as well.

Much more important than the metrics themselves is how they allow everyone to deal with the process when it’s in production. Compare the production employees in two rival companies.

Those in the first learn how the process works and the details of their individual responsibilities. Those in the second get more training. They’re told what the company is trying to achieve. “We’re trying to maximize throughput and minimize errors while keeping costs to an acceptable level.”

Even more important, they’re encouraged to think: “If something comes up where the process doesn’t fit the situation, figure out what will take care of things, do it, and then let your supervisor know about it.”

Which contrasts the difference between Six Stupid and intelligent forms of process design. Assemble six stupid people and they’ll figure they’re the only ones smart enough to figure out solutions. Put six smart people together and they’ll reach a very different conclusion. They’ll figure they can’t possibly be smart enough to anticipate everything that might happen.

They’ll also figure that when whatever it is does happen, grown adults can probably figure out reasonable ways to handle the situation … if they’re encouraged to do so.