Who needs process, anyway?

Over the last couple weeks I've written about different ways that process-development can go wrong: either by piling too many procedures atop each other, or by imposing ungainly external constraints. But who really cares? Wouldn't it be easier to do without formal processes altogether? Think of all the trouble we'd save!

Do we really need processes? Of course it depends. It doesn't take much of a process to play Tag with your kids at the park (so long as you all understand the rules of Tag). But you absolutely need a clear process in order to bake a cake. Let's break down the difference. When do you need a defined process?

We can start with baking a cake. You need a process there because there are fundamental dependencies between the steps. For example, you have to mix the ingredients together into a batter before you put in all in the oven: if you try to bake the ingredients separately—the milk, the eggs, the flour, and the baking powder—you'll get a mess that can't be mixed together afterwards. Then again, you have to let the cake cool before putting on the frosting, or the frosting is likely to melt and smear. So any activity whose steps involve internal dependencies is implicitly a process, and should be understood as such.

Process-definition is also useful when you have an explicit list of requirements that have to be met, because when you specify a mandatory sequence of steps you can check that each requirement in turn is addressed somewhere. The procedures that I described as examples in my two most recent posts—the permitting procedure to build along the California coast, and the jury service reimbursement procedure—are both examples of this type of process. In both cases, there are legal requirements that have to be met. And so the government* defined explicit procedures to follow, to ensure that no requirement is missed.

You need processes when working with machines, for several reasons. Most basically, machines require uniform inputs in order to work correctly, and they deliver uniform outputs. In fact, you can almost say that a machine is a process—nothing else—worked out in steel and wire. But for that reason, the human activities around the machine—feeding it, tending it, and the like—have to be deterministic, and therefore procedural. Beyond that, working with machines means watching for safety issues and performing regular maintenance. Each of these tasks has its own list of requirements. And we have already seen that the best way to meet a list of requirements is to define a procedure. So in addition to operational processes around machines, we have to define safety processes and maintenance processes as well. 

One critical use-case is often overlooked: you need processes when several functions have to work together. (This is also called the division of labor.**) This is because each role is focused on its own work: Engineering is designing new widgets; Production is building them; Logistics is shipping them; Sales is selling them. For the most part, everybody understand his own work but has only the foggiest clue what anyone else is really doing. And yet everyone depends on the work of everyone else. So as soon as a work package has to be handed off from one person to the next, there are only two choices: either the two workers stop everything to discuss the hand-off in detail, or else each work package is proceduralized so that the hand-offs are always the same. Obviously the first approach is impossible, because it would bring all work to a halt. But that means the introduction of defined processes is necessary to support the division of labor. 

Let me mention two other use-cases briefly. Defining a process is helpful when training someone to do a job. As I have remarked before, there have been any number of times I've taken over a job from someone else who "just knew" how to do it, and the first thing I always do is to write a checklist (even if only for myself). And finally, defining a system of interlocking business processes is a useful tool for understanding the scope of your business as a whole—for example, if you are preparing an improvement initiative.

Is there anything that process can't do? Of course. Process can't make you smarter. It can't make you creative. And it can't make you successful. Processes are necessary in all the use-cases I've just described, to avoid the confusions and failures that would be inevitable without them. But by themselves, processes are never sufficient.

Steve Jobs talks about this in a brief clip available on YouTube. (This clip is extracted from a longer interview that you can find here.)

__________

* In both of these examples, this was the State of California. 

** See Adam Smith, An Inquiry into the Nature and Causes of the Wealth of Nations (1776, 1784, etc.), Book 1, chapter 1.