The Documented Process Trap

"I can't do this work well without a way of working..."


"If only we had a document describing how people should work they'd be much better...."


"It's very difficult to do this without a documented process..."

Any of these sound familiar? The third one might be true, but that says more about the person (or the conditioning they've been exposed to) than the process. It can be easy to get conditioned into this way of thinking.

Trap?
This is the belief that something can't be done unless it's documented. But where does this belief come from?

Beware, it's a trap.

It's a self-fulfilling trap. The more you hear it, the more some people tend to believe it, then it disables them so that they can't operate unless they have a documented process in front of them.

It can even become contagious.

Once you have a document (sometimes called a process description or way of working) telling you how to do things or what to do in what order, you start thinking about other aspects of your work that needs a document describing it...

Beware of this trap.

Note, sometimes process critical steps need ordering and documenting - this trap is not saying anything documented is bad, it's a warning about approaching new or original problems.

A logical extension of this is that test ideas, sometimes called test cases, are described in advance - so that we know what to do. Sound familiar?

Bad to document test ideas?
No. Awareness of this trap is stating that it is dangerous to pre-determine all steps to a solution before the solution is known. It can be very useful to write down a set of ideas in advance, but don't let the problem solving approach stop there - before you know if you're on the right track.


What about decisions or criteria for decisions? Should they be documented in advance so that you don't make mistakes?

Why document things in advance?
As aide-memoire, as checklists, or as decision tools? All of these are fine when used in the right spirit - as a help, but not necessarily definitive. Unfortunately, the move to something being definitive can be quite short. From aide to "standard" to "standard practice", or even "best practice". This is connected to the way we create norms, and then the dreaded cognitive ease (which we're all susceptible to).

Kahneman, ref [1], states that norms are built by repetition - when we see something "work", we start to think of it as "how it works". This is complicated by something called cognitive ease - once we start to "see how it works" it can become a natural default as it is much more difficult to think each time, "is that really how it works?".


Hypothesis
I proposed a hypothesis recently:

Many people naturally approach new problems in a heuristic manner, but due to repetition or familiarity this becomes a "standard" and the heuristic approach is lost or forgotten.

When we look at new or original problems we often don't know how to tackle them - we might take out our "toolkit" of approaches and try out some different ideas, we might think down different solutions depending on time, customer needs and available tools and people. We evaluate the results of some of those ideas, and either change or continue. There is rarely a pre-defined way to approach a problem.

Polya, ref [2], warns not to mix up heuristic reasoning with rigorous proof.


Awareness
Awareness of a trap won't avoid anyone falling into it. However, it is the first step in progressing away from unconscious incompetence, ref [3].

The next time you are presented with a new or original problem, ask yourself "am I thinking originally about this" or am I following a "standard" (or accepted practice) and should I question that.


References
[1] Thinking, Fast and Slow (Kahneman, 2011, FSG)
[2] How to Solve It: A New Aspect of Mathematical Method (Polya, 2004, Princeton University Press)
[3] Wikipedia: http://en.wikipedia.org/wiki/Four_stages_of_competence