The Problem With Procedures
Published January 20, 2012 | 
It’s not that I’m against procedures. No, in fact, I’m a big fan. I started my professional career in 1980 as a technical writer, so in some ways procedures have helped make me what I am today. :-) The problem is that we often expect them to do too much. We expect procedures to be “enough”. We mistakenly believe we can break down the elements of our complex world into parts and pieces and neatly assemble them into step-by-step instructions.
And we can’t. Although there are places where procedures and checklists make sense (Recent studies speak to how checklists help hospital personnel, pilots and others in critical roles reduce errors and perform more effectively), we must also be aware of the limitations of procedures. The reality is that much of what those pilots, doctors, and nurses deal with on a day-to-day basis cannot be proceduralized.
One of the primary problems with procedures is they assume you can know and realistically cover every eventuality. In the late 1980s I worked with expert systems and decision support teams. My job was to work with the SMEs and capture the rolodex of if/then configurations. “If this happens under these conditions, do this…”
Although I loved the work, I could see the flaw back then – that we could never really cover all the bases, that we would constantly be “chasing our tails” so to speak. Which I think explains in part why those technologies were never very successful.
Procedures often lack context. They assume that things can be done the same way in every situation. For those of us who recognized the importance of context and attempted to include it, we ran into two problems – an unwieldy confusing mess of a document, and continually needing to add new contextual elements.
Another major problem with procedures is they quickly get out-of-date. And once they are out-of-date they are beyond worthless and into the realm of dangerous. Greg Jamieson and Chris Miller (Exploring the Culture of Procedures,2000) studied four petrochemical refineries in the US and Canada to see how they managed their procedures. In none of the four cases did the workers ever completely trust the procedural guides and checklists because they never knew how updated the guides were.
What did they do instead? The learned workarounds. They used their experience to adapt, just as we would expect in complex domains. And it is exactly here, in this state of adaptation that we should focus our energy (but I’ll save that for another post).
Staying with the problems of procedures for now, perhaps the biggest problem with procedures is that they can lull people into a passive mindset of just following the steps and not really thinking about what they’re doing. They stop trying to understand the situation or look for different ways to solve the problem. In a complex environment, this mindlessness is exactly the opposite of what you want. You want people to be continually mindful and aware, proactively anticipatory. You want them to look for clues and signals, and continually develop richer mental models.
Procedures do a lot of good things. They help ensure consistency, help beginners learn the ropes, help more seasoned professionals remember the essential steps. They are an important and necessary element of our cognitive support toolbox. But they are only one tool in the toolbox. We’ll talk next time about some of the other tools.
The Knowledge Funnel
Published June 16, 2011 | 
A helpful way to think about knowledge in an organization is using the metaphor of a funnel. At the highest level, you have a wide variety of disparate ideas, concepts and tacit knowledge that have not yet been made explicit. There is a lot of good intelligence and know-how in this collection, but it isn’t very useful to anyone other than those who hold the knowledge in their heads.
With some expert help (say by someone on the Knowledge CATS team), you draw out this tacit knowledge and make sense of it. You package it into models or heuristics and in so doing you move it from tacit to explicit and now other people can use it. At the Models & Heuristics stage, the knowledge or know-how is in guideline form. In other words it is principles and rules-of-thumb that the expert uses to make decisions quickly and efficiently. Typically cues or signals are also included at this stage, so it’s not just the heuristic or rule-of-thumb, but it’s also knowledge about when to use it.
The bottom of the funnel is Systems and Procedures. This is where knowledge is distilled into uber explicit procedures. Step 1, do this, Step 2 to this. The ultimate path from this point forward is from procedures to systemization or into code.
There is increased usability and cost savings as knowledge moves down the funnel. But there are also risks. Once you capture in depth knowledge and put it into procedures, you now have to keep up those procedures. Models and heursitics don’t require regular updates, but procedures do, because so many of the variables (equipment, people involved, contexts, etc.) change frequently.
Secondly, once proceduralized or systematized, the know-how can be easily copied. As my friend Adrian Davis says – once systemitized, it can be commoditized! Which means it no longer offers you any sort of competitive advantage.
Bottom line – not all knowledge should be pushed down into the Systems & Procedures part of the funnel. We’ll go into how to determine which should and when you should stop at Heuristics in a subsequent post.
