Removing Barriers to Productivity: The Concept

Work Measurement Work measurement, the science of relating work to time, is a broad field. There are numerous techniques for measuring including time studies, predetermined motion time systems (PMTS), and several types of estimating methods. And there is a myriad ways to use work measurement.

Researching the reasons for measuring work reveals a myriad of applications. The list below summarizes what we found: • For industrial engineers and lean and continuous improvement practitioners: - Comparing work methods and developing best practices - Determining standard time for various operations and implementing Takt time - Balancing production lines - Establishing wage incentive schemes • For operations managers - Determining production capacity - Planning workforce requirements - Operations scheduling - Evaluating labor performance • For construction and services managers - Determining price or cost of a product or output involving human labor

However, there is one application not widely discussed. That is a structured and ongoing surveillance of the production process for operating problems that cause delays or rework in the flow. We could not find this application covered at all in recent internet searches. However, it is possible that we just did not use the right search words.

This is not a program conducted and led by continuous improvement specialists or manufacturing/industrial engineers. It is similar to reliability engineers’ use of failure codes. Other than that, this is a purely operations-driven (production and maintenance) exercise.

This program is an ongoing problem identification and solving process that is complimentary to the review of key performance indicators (KPIs). Specifically, it is a process underlying the KPI that compares expected time to actual time, most commonly called “performance” or “performance to estimate.”

How It Works Work progress is checked at regular intervals during work execution. The intervals might be hourly for high speed production lines, at the end of shift for plant turnarounds or weekly for design engineering. Progress is compared to an expectation of progress based on “good operating” conditions. Where actual progress is different from expected progress by a predefined percentage (that can vary from ten to twenty five percent depending on how you design your process). When that percentage is exceeded, action is required.

The logic is that since the expectation (volume or time to complete) is based on good conditions, the only reason there is a difference is that some problem or “barrier” is getting in the way. So the first action required is identify and fix the problem if it is still occurring. Act first, then write. Stabilize the situation.

The next action is to document what just occurred, while memories are still good. Identify what happened, its cause, the lost time (and other impacts), date and job/process identification. Then categorize the incident by assigning a pre-defined problem code. In a maintenance environment, these codes can include searching for material, special tools not available, waiting for equipment availability.

Each coded incident is entered in a data based. Regular, periodic Pareto charts are generated based on the problem codes. The Pareto charts can be based on frequency of code or total lost time of code, or both. The reports are generated with the weekly publication of Key Performance Indicators and become part of the KPI reviews.

During that review process, management can pick out the top codes for further examination. The objective is to eliminate recurring problems permanently. Top codes are assigned to problem solving teams for investigation and recommendations.

The problem solving team investigates each incident, interviewing individuals involved, soliciting their input. The problem solving team frequently develops a second Pareto chart for their assigned problem code where they are finding different root causes.

The categories in the second Pareto chart, the root causes, become the targets for focused problem solving. New participants can be brought into the original team or new teams can be formed if each of the of the root causes needs a different skill set to resolve.

Progress of all the teams is tracked and reported back to the KPI reviews. The teams work the solutions through implementation and tasting for resolution.

An Example: This means that historical data is typically not usable. Historical data will include the operating problems we are trying to highlight. An example comes from the electric utility industry.

Construction Units (CU) were used to estimate how much time equipment installation would require. These construction units were developed using an average of time required by the last six installations of that type of equipment. That logic is good for establishing budgets and developing annual plans. It does not help us here. It is not the number with which the construction crews should be managed during execution.

We found that some of the equipment had been manufactured outside contractual specifications. Field crews, hurrying to meet schedule dates, would modify the equipment in the field but, in the same rush, not inform engineering or procurement of the variance.

That field modification time was built into the CU and institutionalized in the field as SOP! The work measurement process proposed here uncovered that situation. We reduced construction costs by holding the manufacturer to the contractual specifications.

The next steps in the setup are developing the time requirements (“standards,” or “reasonable expectations”) and the problem codes. After that, we define process and roles during work execution and implementation. We will cover each of these steps in subsequent blogs.