Removing Barriers to Productivity: #3 Categorizing Barriers

To date we’ve discussed the concept of a productivity barrier removal process. Central to this is to establish how long work should take under good operating conditions. The logic is that when work is measured, and it takes longer than expected, poor operating conditions were occurring. Time was lost because of problems. Prior to implementation the process, we need to develop how the lost time data, found during live follow up, will be used.

Structured Data Supports Pareto Charting

Hard experience taught us that data structure needs to be defined before you start implementation rather than after. As a new consultant and supervisory coach, I spent many hours sorting through data where information hadn’t been initially categorized. Needless to say, it’s extraordinarily time consuming and you don’t need to repeat the pain. The addition of some simple codes, similar to manufacturing engineering’s failure codes, saves a lot of time getting to your Pareto chart.

The insert, Figure 1, left, shows what’s worked well in maintenance environments for oil pipelines, processing plants and compressor stations. When a job is done, actual time is compared to expected time. If the difference is greater than some predefined percentage, say 25 percent, then documentation is required about what happened during the job. The documentation includes job number, date of occurrence, cause of the deviation or problem, extra time required and corrective action taken. And every occurrence is assigned a barrier code that characterizes the cause of the deviation and extra time required.

Don’t Overdo It

Define your codes working with a cross-functional team including maintenance, operations and engineering. The big watch out here is don’t try to make an all-inclusive, Mona Lisa, list of barriers. Less is more going into implementation.

The cross-functional team’s purpose is to assure all affected parties are involved, understand what is happening, the intent, and provide input. Hard experience taught us that very zealous, and well intentioned, teams can generate 50 codes trying to describe ALL POSSIBLE barriers they can remember. But that creates an intimidating and cumbersome tool at implementation. Better to have four or five rather than fifty. You can always adjust based on what you find during piloting or early implementation.

Use of an “Other” category will help keep the initial list manageable. The may be understandable resistance around using such a broad code. The watch out is well advised lest you wind up back where I was as a brand new implementer: a huge list that has to be sorted! It should be explained at the start of the team’s design session how to manage the “Other” category in the codes. Following is an example of what cross-functional teams developed to manage the categories on an ongoing basis.

Define Process Management to Keep It All Evergreen

“Other” is a catch all and will get out of hand unless it is carefully monitored. In the best practice model, “Other” should be the smallest category in the Pareto chart. Certainly if it becomes the largest category, it has to be fixed, examined in detail.

First assure that the codes have been used correctly. There may be some retraining or changes to the training required. Second, if the codes have been applied correctly, define new barrier codes. Likewise for any barrier code that consistently report zero occurrences. Is there a training problem or should these unused codes be eliminated? This becomes part of the ongoing management of the barrier removal process.