©2015 Mark Henderson
I recently worked with a client to develop a large number of detailed task procedures. It was a great relationship and in the course of the contract, we developed about 400 procedures (initial release plus revisions) over a vast array of equipment and planned work activities. This was done largely in response to the client’s top management direction, that work would be performed using procedures and that people would be trained in their use.
I would love to report that I truly believe the client will follow through and use those three or four hundred clear, concise, and valid procedures we delivered, and will realize the long-term benefits that come with enforcing discipline into any process. Casting no disparagement toward this client, I suspect that this story won’t enjoy this happy ending. This is because my observations lead me to believe that ingrained in their culture is a—to paraphrase that comedic movie western line—We don’t need no stinkin’ procedures notion that seemed imbued in the organizational belief system, despite what the top brass declared.
So, what happens when nobody uses what starts out as good procedures? In a nutshell, they “go bad”: Configurations and nomenclatures change, processes change, “stuff” changes; but, the procedures never get changed. So, the people doing the work who already think procedures are useless sure aren’t going to use procedures that are obsolete!
So, what motivates an organization to change? And not only change, but change the organization’s belief system? It’s a tough question, and there are dozens of books written by experts on changing an organization’s culture, so I’m not going to portend to be an expert or try to answer that question. However, a former colleague with whom I had teamed on a Super Fund remediation project some years back opined that the only way some organizations change is when someone gets killed or when someone goes to jail. It sounds harsh, I know, but he was simply saying that changing an organization’s cultural belief system is difficult—so difficult that it rarely happens unless there’s an avoidable catastrophe that overcomes the inertia of years of entrenched mindset.
On the success side of the coin, I did a project for a heavy manufacturing firm not long ago. Even before I wrote the first procedure, they helped plan the format to allow them to re-purpose the content into training materials; they also planned the process for revision in order to ensure the procedures would be kept up-to-date. But, more importantly, they positioned each procedure on the floor with the technicians executing that work, making access easy. Then they trained every employee on every procedure, and they enforced the usage of these same procedures as condition of employment. These guys were serious about operating the old ISO adage: Document what you do, and DO what you document.
During a follow-on contract to develop lock-out/tag-out procedures at that same facility, I witnessed firsthand the way this company walked the walk as well as they talked the talk: Whenever they wanted to improve a sub-process, they accounted in their planning for the changes required to their released procedures. I walked away from this client knowing that the clear, concise, and valid procedures I delivered initially would not only be used, but would be kept clear, concise, and valid (or at least the valid part) long after I was gone. This enterprise got it: They realized that to keep their processes in control, they needed people executing their work the same way across shifts, day in and day out. To do that, they needed to document the processes the way they should be performed, and then update the procedures to reflect process improvements. This would keep their processes in control, and keep them on the road to continuous improvement.
In conclusion, I think it’s fair to say that to bring a process in control, the process must be documented and the documents must be used in process execution. So, when organizations invest in documenting processes with clear, concise, and valid procedures, it seems shortsighted or even foolish not train their folks on their application and use (to steal a page from a former client’s top brass edict), as well as to enforce their usage when performing those work processes. It seems similarly foolish not to update these procedures as things or even the processes change (such as continuous improvement). Or, to say it another way, to allow good procedures to go bad!