After coaching Lean Six Sigma for the last 12 years, it is still surprising to see how many projects get cancelled because they are not considered “valid.” Practitioners and managers must remember that this methodology is designed for making process improvements. If leadership cannot identify a broken process, more work by the project sponsor is required.

One reason projects are canceled is a sponsor or other leaders’ inability to see the process at all. In these cases, when a practitioner suggests a project to improve a particular process, the leader might say, “that is not a process.” But typically what this means is that there is no standardized process, even though the work is still being performed. This is especially true in transactional processes, where people seem to be given more freedom than in manufacturing, with the premise that “as long as the work gets done” there is no issue.

In this type of scenario, practitioners may benefit from conducting a shorter form of process improvement project called DMC, i.e., Define, Measure and Control. DMC projects can be good approaches under the following conditions:

  1. The process has excessive variation – many times caused by people executing the process in different ways.
  2. There is no standard process.
  3. There are no measures of the process, only a perception that there is a problem.

For each of these conditions, the DMC project output will be a process with a standardized set of instructions and metrics. These advances can be used to help leadership confirm whether an improvement project is necessary.

While it is no replacement for DMAIC, experience has shown that just putting metrics on a process does, in fact, yield some improvement.

Define Phase

There is little difference between a DMC Define phase and a classic DMAIC Define phase. Familiar elements such as the charter, SIPOC (suppliers, inputs, process, outputs, customers) chart and voice of the customer (VOC) are just as critical here, as well as the project communication plan and stakeholder analysis. The major deviation comes in the Measure phase.

Case Study – Part 1: Define
An insurance company was attempting to improve the process and accuracy for the application of its payments. The insurer believed that many of the payments received monthly were not being applied in a timely fashion. There was no data to understand whether this was, in fact, the case.A DMAIC effort was chartered and the people responsible for carrying out the process (14 in total) were gathered together. Their comments about the need for the project are summarized here:

  • “We complete all processes within the month.”
  • “We do not have enough people, and we are working a lot of overtime to meet the requirements.”
  • “The process would work better if everybody did it consistently.”
  • “The real problem comes when we cannot match the payments to a policy.”

Based on the comments above, the company decided to map, standardize and measure the process before pursuing a full DMAIC; hence a DMC project.

In Define, the team completed the charter, a SIPOC, and VOC analysis where they defined the key requirements:

  1. Complete all processing within the 30-day billing cycle.
  2. Resolve all problems within the 30-day billing cycle.
  3. Reduce the staff assigned to this process.

These requirements translated into the company’s outcome metrics for this process.

Measure Phase

Typically in the Measure phase, the goal is to baseline the existing process by mapping it and measuring it, and then comparing the output to the customer requirements. With DMC projects, there is no such information.

The first step is to map the process. Here, a select group of people who actually do the process are brought into a conference room with a large number of sticky notes so they can map what is actually happening in the process. Remember: The team is not concerned with “what management thinks is happening” or “what should be happening.” Their main interest is what is actually happening. This is often the first roadblock.

Most likely, each person in the room has not only a different opinion of how the measurement should be made, but also an opinion about why his or her way is the best. The job of the facilitator is to document all of these variations of the process and rationalize which way truly is best later.

The next challenge is to get all the workers to understand why standardizing processes are critical to consistent performance. The key reasons for standardization are:

  • To reduce variation among individuals or groups (and so make the process output more predictable)
  • Provide knowledge to operators and managers now on the job
  • To provide a basis for training new people
  • To provide a trail for tracing problems
  • To provide a means to capture and retain knowledge
  • To give direction in the case of unusual directions

A “parking lot” issue must be defined for each of the cases where there is some variation in how the process is done. We will get to these later.

The next step in the Measure phase is to go back to the VOC information from Define and establish what the output metrics are for the process; in other words, how do we know we are meeting the customer’s expectations?

The team must now eliminate all the variations of the process and agree via consensus that one way is better then all others. Known as process standardization, this activity should lead to a decision based on how the method impacts the output of the process or the critical-to-quality commponents of the process.

This is a task that often dredges up a lot of emotion because each member may feel some ownership about the process. Again, if the facilitator keeps returning the conversation to the question about which one method is better for the customer and which one is better for the business, agreements can usually be reached.

Finally, it is time to document and deploy the new standardized process. It is imperative that a complete future state process map be generated. Using the process map, be sure to perform a process failure modes effect analysis (FMEA) as a risk mitigation tool to determine if something was missed in the design.

As the process map is finalized and deployed, it is time to start collecting data around some of the x’s in the process, which could possibly impact the output.

Case Study – Part 2: Measure
The first step once Define was completed was to map the process and define the key metrics specified in Define that drive the output. Mapping the process became an eye-opening experience for everyone involved in the project.The high-level view of the process is as follows:

The interesting facts and data discovered during this process were:

  1. About 7 percent of the payments received had problems matching to the policies
  2. Virtually 100 percent of these problems were resolved within the billing cycle
  3. The process map took up 42 8.5 x 11-inch pages, consuming all 14 team members full time.

Based on this information, the team completed the following:

  1. They rationalized the investigation part of the map and found many different ways of doing the tasks. For example, one potential outcome of the investigation was discovery of an erroneous payment, which necessitated a refund. The team found five different ways to refund the money. As a result, they conducted a value-added analysis of the map and were able to simplify and reduce the steps, thereby enabling the reduction and reassignment of six of the resources.
  2. They established a procedure to track the reasons for the payment not matching the policy. This data would enable future reduction of this problem.
  3. They established a system to track cycle time and labor dollars/transactions through the entire process to ensure continued improvement for overall effectiveness and efficiency.

Control Phase

This final phase is about seeing how the process is really performing. It may be that once the process is standardized, all major concerns disappear. Another result may be that the team takes a “wait and see” approach and runs the new standardized process while collecting data around the metrics to determine whether a problem does exist. In the latter case, if the team still has some concerns with this process, a full DMAIC project can be launched.

Case Study – Part 3: Control
With the metrics defined and the tracking mechanisms in place, the process was deemed “under control.” The process owner was instructed about how to review the process and outcome metrics on a frequent basis (30 minutes per week), and to determine if any course of action was required.After about six weeks, the people doing the investigation process did find some additional inefficiencies and proposed further changes, which were accepted. This allowed for the redeployment of one additional resource to other opportunities.

The insurance company’s problem of not being able to match payment with policies continued, however, and a full DMAIC project was launched to address this issue. Although a full DMAIC analysis was needed, pursuit of an initial DMC project did benefit the organization by providing a reduction in the cost of the process (i.e. reassignment of staff) and presenting data to address the issue of the matching of payment to policies.

About the Author