text: When is a process a process? – Keller Technology Corporation
  Blog & News When is a process a process?
  The importance of not over-documenting or encumbering employees in the name of Quality.
  With a growing drive for "quality systems" there is a lot of talk about 'process' in industry today. Ongoing discussions about how to define, optimize and document processes happen in every office and around every coffee machine. Accompanying these discussions is a near inevitability that many of these topics will quickly escalate from friendly chat to departmental clash. It begins innocently enough with best intentions when someone launches a conversation by suggesting a review of a process.
  In short order, the conversation turns to the brass-tacks of documenting steps for the benefit of training and consistency. Then comes the moment of frustration when a complicated process step turns into a point of contention because someone believes it should be considered its own process or perhaps because there are too many options, inputs or other complicating factors. Discussion ensues and tensions rise as the complexity of the issue grows.
  From here the conversations can sour quickly from frustration; devolving into questions like "Where does this all stop?" or "How far do we go with our documentation?". Cooler heads usually prevail, and before anything regrettable is said, the discussion is tabled for another time. Sadly, this pattern leads to a dark cloud hanging over the idea of process reviews and if left unchecked will create a culture of stagnation and stop critical progress dead in its' tracks.
  Though the dissenting questions can be dangerous, they are also very valid and ultimately some of the most important to real progress in process improvement. How deep should processes be defined? How far do you go with documentation? How do you not paint your workers into a corner with regimented documentation when the map doesn't match the land? Everyone has a different perspective on these and in truth the answer to what is or isn't a process will universally come down to the same thing every time "it depends".
  Lets' take a moment to explore exactly what "it" depends on, and how we can use these questions to resolve issues instead of instigating conflict.
  A safe place to begin looking at defining a process is by asking "can this be done correctly and consistently by a reasonably competent professional without reading instructions?". In other words, can a person be expected to hold the full details of the job at hand in their head without reminders, cheat sheets, notes or prompting? If the answer is 'yes', then it is a task, not a process.
  Changing a vehicle's oil is a process, however pouring new oil into the engine isn't a sub-process that requires detailed step-by-step instruction, it's a task that any reasonably trained individual can properly complete without reminders or aids (we hope). The documentation can read "add oil" without going into the details of opening the container. A process-documents' job is to identify the tasks, but that doesn't mean the step-by-step instructions need to be spelled out for every single motion or activity. Avoid over-documenting tasks; it can save a lot of dickering over granular details, cuts back micromanagement, documentation and reduce a lot of process audit liabilities.
  Another great method for identifying a process is counting steps.
  There is some debate to be had here, and it will always be relative to considerations of risk; a process will have no less than ten steps and no more than twenty-five. The professional hair-splitters of the world will of course be quick to step forward and point out that any 'step' can be broken down into more steps. While this is technically true, the considered assumption of a "reasonably trained professional" helps to settle the issue. In the task mentioned above, "pour fresh oil into the engine" more than suffices, and a reasonable professional doesn't need to be told to remove a cap, tilt the bottle, etc. Keep processes documentation short, a process with more than twenty-five or so steps can begin to feel unwieldy or intimidating and will likely prove difficult to train new staff on.
  Most process improvement conversations begin with a discussion about a subject that is well over the twenty-five steps rule, don't let this deter you! Break the discussion up into bite-sized pieces. Begin with broad strokes and work your way down, if you keep in mind the above guidelines you will find natural breaks in workflows that will allow a team to identify processes that meet the criteria of being complex enough to warrant documentation and simple enough to complete without a full manual. When these sweet-spots emerge, let them guide the documentation.
  Process reviews will begin to move more smoothly with these simple tools, and the documentation will evolve naturally to lean and effective instructions that not only represent the work being done but become valuable points of reference to your front-line staff.
  Keller Technology provides our customers with quality performance, value, schedule adherence, and technical compliance.