iSixSigma

An Affinity for Scope

Mike was a newly hired Black Belt (BB) at a roofing shingle manufacturing plant who was going through Six Sigma training. Tim, the general manager of the plant where Mike worked, brought Mike into his office and explained that Mike’s Master Black Belt was on the speaker phone. The Master Black Belt, Robert, shared with Mike the details of what would be his first project. “Tim and I have been talking and – congratulations, Mike! – here is your first project: Reduce Tray Jams. It is the second highest cause of downtime at your plant,” exclaimed Robert.

Tim explained to Mike that tray jamming in the plant’s autocatcher was a big problem that needed to be solved. The autocatcher was a mechanical bundling device notorious for having jams in the tray that stacks and consolidates individual shingles into bundles ready for packaging. Tim further explained that in his role as general manager of the plant, he would support Mike as the Champion of this project.

The Magnitude of the Project

Mike was excited about having his first project and immediately shared his news with the plant’s employees. Many of the operators patted Mike on the back and commented, “Well, if you reduce tray jams, you’ll make quite the name for yourself.” Others chided, “You poor soul,” and “Who did you upset to get stuck with that?” And then a wave of stories came of “Remember when so-and-so took on a tray jam project? It’s still a problem!” A heavy weight overtook Mike as he began to realize the gravity of the situation.

One operator encouraged Mike, saying, “We’ll help you in any way we can. We hate autocatcher tray jams.” These jams result in the operators having to manually clear the jams – often bringing the production line to a halt. How was Mike going to finish his first project in the standard six to nine months when it seemed this problem was so resistant to being solved?

Scope, Time and Resources

Mike reflected on the importance of establishing the scope of a project during the Define phase of any DMAIC (Define, Measure, Analyze, Improve, Control) project. As he went over his training notes, he came across a triple constraint diagram (Figure 1) showing the relationship among scope, time and resources on a project. The diagram displays how these three components are interconnected like an equilateral triangle. If scope increases, then time and resources must increase as well, and vice versa.

Figure 1: Triple Constraint Diagram

Figure 1: Triple Constraint Diagram

As with any project leader, Mike needed to find the right combination of scope, time and resources. For Mike specifically, time was of the essence because there was pressure for a new Black Belt to complete his first project in the expected six to nine months. If Mike did not have the project rightly scoped and resourced, the project’s cycle time would inevitably drift beyond that time frame. The project’s scope needed to reasonably match what he could accomplish with his allotted time. With scope and time defined, Mike would be able to communicate to his Champion what resources he would need.

Starting with the Right Tool

Mike remembered his Six Sigma instructor telling him to trust the tools and to trust the methodology. Mike wondered, “What tool do I need to kick this project off?” Mike recalled that his instructor taught that when you want to dig into the root cause of a specific problem the Ishikawa fishbone diagram is a tool of choice. He also remembered his instructor sharing a warning in the form of a joke, “Now some of you are going to run out there and do a fishbone and discover that what you have is not a fish, but an entire whale! In this situation, you should have used an affinity diagram.” Affinity diagrams!

Handpicked Content:   Get the Bugs Out: VOC Analysis and Scenario Planning

Mike began refreshing his memory on the tool. Affinity diagrams are a scoping tool that can be used to break down large-scale, complex problems into smaller, more manageable pieces. Mike recalled that when he visited the plant floor and asked individual operators what they thought caused the tray jams, the operators would often respond, “Everything! Everything causes tray jams!” Mike began to realize that the tray jam problem potentially had a broad base of root causes; he did not need the scalpel of a fishbone diagram, but rather a tool to help him identify the many potential root causes – an affinity diagram.

Brainstorming for Root Causes

Mike gathered a cross-functional team comprised of two engineers, three maintenance technicians and two operators for a brainstorming session. He explained the ground rules and then at the top of a dry erase board, he wrote the undesirable effect: autocatcher tray jams. Mike asked the team to tell him anything and everything that they thought caused tray jams.

At first, the team overwhelmed him with ideas all at once. He thanked them for their enthusiasm, but he had to refocus them on the ground rules of only talking one at a time. This gave Mike time to write down each suggested cause on a sticky note and attach it randomly to the board. He explained that after the brainstorming session the team would organize the sticky notes and (with luck) begin to see the problem with more clarity.

The operators enjoyed sharing their ideas. Mike noted there was a degree of venting by the operators with each suggestion. He also noticed that their insights initially revolved around ambient temperature, humidity and raw materials. Mike ensured that the maintenance technicians were not being left out. Their insights had to do with settings and the setup of the machine itself. The operators took offense at this since it revealed a degree of tampering on their part with the process. Mike settled the group and reminded everyone that they were one team and that the problem plagued the entire plant. He reaffirmed that there would be no finger pointing, just honest root cause analysis, and that it was the process that needed fixing.

The engineers began to chime in with potential solutions, rather than root causes, which started all kinds of excitement and side conversations. Mike had to stop the meeting and refocus everyone’s attention again. “Team, we are not ready to jump to solutions. We have to break down the problem first. Einstein said that if I have an hour to solve a problem, then I want to take 50 minutes understanding the problem and 10 minutes solving it.” He then assigned one of the engineers to be the enforcer of his “no-solutions” rule. After the flow of ideas diminished and the team’s eyes began to glaze over, Mike stepped back and reflected on what they had accomplished thus far (Figure 2).

Figure 2: A Sample of the Potential Root Causes for Autocatcher Tray Jams

Figure 2: A Sample of the Potential Root Causes for Autocatcher Tray Jams

Creating the Affinity Diagram

Mike was impressed by the number of potential root causes that he saw on the board. It looked like there were more than 100 ideas after about 40 minutes of brainstorming. With a quick review of the potential root causes, he noticed that many of them came from different raw materials and different locations in the manufacturing process; this reinforced the idea that “everything” caused tray jams.

Handpicked Content:   Using Critical Path Analysis to Prioritize Projects

Steps to Create Affinity Diagrams

The steps for creating an affinity diagram are:

  1. Have a cross-functional team
  2. Cover the ground rules:
    1. Only one person talks at a time.
    2. Do not discuss solutions; the problem must be understood first.
    3. All potential root causes are welcome – there are no bad ideas.
    4. Blame the process, not the person.
  3. Write the undesired effect at the top of the white board (or whatever you are using to collect the ideas and ensure the team members can see them) to focus the brainstorming. It is also helpful to have a macro-level process map posted.
  4. As they are identified, write each potential root cause on a sticky note and put it on the board. Repeat until done.
  5. After the brainstorming session is complete, it is time to affinitize. Arrange the sticky notes into common categories.

Mike explained the next step to the team. “Okay team, now we have to move all of these sticky notes around into similar categories. If you see any matches, call them out.” He asked for a couple of volunteers to help him move the notes around. An engineer started the process by commenting, “It seems like some of these root causes are upstream away from the autocatchers, and the others are related to the shingle machine that the autocatcher is a part of.” Everyone liked that idea as a first step, so Mike wrote “upstream” and “shingle machine” at the top of the board. His volunteers began to shuffle the ideas to their appropriate categories. Members of the team that were in their seats chimed in to help direct Mike and his volunteers as to which category to place each sticky note under.

Once that task was accomplished, Mike asked the team to help him to delve deeper into the relationships among the ideas. The notes were further divided into subgroups underneath the upstream and shingle machine categories (Figure 3). Mike was pleased at what the team had accomplished. The hour of time he had set aside for the meeting was drawing to a close; he thanked the team members for their participation and involvement. Clyde, an operator, asked, “But how are we going to fix all of that?” Byron, a newly hired engineer and enforcer of the no-solutions rule, interjected, “It’s too soon to talk about solutions! We have to understand the problem first!”

Figure 3: Affinity Diagram for Root Causes of Autocatcher Tray Jams

Figure 3: Affinity Diagram for Root Causes of Autocatcher Tray Jams

Scoping the Project

When Mike ended the meeting, the operators and maintenance technicians filed out to attend their shift-change meeting, but the two engineers stayed behind. James, a senior engineer with more than 20 years of experience with the company, stated, “That’s too much for one project. It will take you years to do all of that.”

Mike reflected, “You’re right! Who says this has to be one project? It could be several. What should this first project be about?” Mike, James and Byron began to discuss what was a reasonable scope for Mike’s project – and what would not be included. Mike said that he would suggest to Tim, his Champion and plant’s general manager, that root causes outside his scope be addressed as new projects by Green Belts who could work with Mike. “Tim will like that idea,” Byron said. “He struggles to find projects for his Green Belts, and he loves the idea of teamwork in his plant.”

Handpicked Content:   Lessons from Crusoe on Project Resource Allocation

Sharing Root Causes and Gathering Resources

Mike had been holding weekly Champion meetings with Tim to update Tim on the project’s progress and results and to make requests for resources. Thomas, the production line manager and process owner for this project, joined them at their next meeting. Mike brought his affinity diagram, now with four scoped projects identified (Figure 4), to explain how his brainstorming team had identified several different areas in which the root causes of the tray jams problem existed. Mike explained that the scope of the problem was too large for one project; he proposed that the scope of his project be limited to the inspection belts, delivery and the autocatcher itself.

Figure 4: Four Scoped Projects

Figure 4: Four Scoped Projects

At the same time, the plant could start two new Green Belt projects that would focus on increasing the life of the cutterhead and improving the changeover process that is laden with variation and waste. Tim asked, “Thomas, you used to be a Black Belt who worked on tray jams. What do you think about this approach?” Thomas replied, “Interesting. We break down this massive problem into smaller projects. Tim, we always need good projects for our Green Belts and our Green Belts always need help from a Black Belt. They usually end up coming to me all the time for help. In this case, we can approach this as a team with Mike taking the lead on it. We may actually get some momentum against this problem for a change.”

Mike jumped in, “Momentum is right. Otherwise, it’s going to take years for one project to tackle all of this.” Tim interrupted, “And you don’t have years to finish your first project. That would be a bad reflection on both of us and this plant.” Thomas then asked, “But, what about the cooling section? I remember everyone telling me how much the cooling section causes tray jams, but that is a hard one to prove because there is so much noise in the process.”

Mike answered, “I have it listed as a future Black Belt project. I was hoping to get through more of my training and see what these other projects can accomplish first before I tackle that one.” Thomas then agreed, “That makes sense. I bet your project and these other two Green Belt projects can clear the noise out of the process to the point where we could start seeing clearer signals from the effect of sheet temperature on tray jams.”

Defining Scope Is Critical

Mike’s story shows a critical approach to defining scope that many Green Belts and Black Belts neglect during Define. Project cycle time and success hinge upon an upfront understanding of the problem and of what a Belt is trying to accomplish. Mike was able to balance his scope, time and resources by using an affinity diagram. Using the affinity diagram in the Define phase enabled Mike to:

  1. Understand how broad a problem the project was trying to solve.
  2. Define the project’s scope into a manageable chunk that could be addressed within the allotted time and resources.
  3. Break down a large, complex problem into several smaller, manageable subsets. Once he established the scope of his project, Mike was able to separate the different problem areas into GB projects that would work alongside his BB project. He was also able to identify future projects that he could tackle after initial successes had reduced the noise in the current process.

Comments 11

  1. Chris Seider

    I really enjoyed this article.

    I actually agree that scoping is very difficult but had a few thoughts. If tray jamming is the biggest problem for the plant, why would resources be a problem? Second, I actually think this article shows an excellent example of a BB keeping focus and not letting side project detract from the original goal. However, I worry this BB will be limited in investigating causes. Often it’s upstream issues that are the root cause of tray jams that need to be solved. I would suggest the use of a pareto for the reasons for tray jams to focus the team instead of saying it’s not my project if it’s found that an upstream reason explains the problem.

    0
  2. Thomas Salaway

    Great article John! A good demonstration.

    I do have one question, in this article Mike needs to limit the scope of his project. One way that he does it is by giving the cutter project to a couple of GB, which was a very effective way to limit scope but keep management happy. Do you have any other methods of limiting scope if you are being pushed to accomplish a project that is too large for the time or resource constraints?

    0
  3. Phylis Stromile

    I Loved this article it help me remember some things i have learned in six sigma. Thank you for sharing

    0
  4. Kicab Castaneda-Mendez

    I like the point of not jumping to solutions: you’re in Define and solutions occur in Improve. It’s also better not to jump to root causes (as the team did): you’re in Define and root causes occur in Measure and Analyze.

    Both can be avoided when scoping by recognizing three ways to scope a project.
    1. Select fewer measures to improve. The team did this by choosing frequency of autocatcher tray jams. Also, when identifying several other projects, other measures were used.
    2. Select fewer demographic choices. By demographics I mean factors such as customers, products, regions, lines, and so on. The team apparently did this by choosing only one product, one region, one line rather than more than one of each. (It’s not clear whether there are more, but if there had been, choosing only one of each narrows the scope.)
    3. Select fewer process steps. It seems the team may have gotten to this but it took longer than necessary. Since it was trying to improve a process, nothing helps more than mapping the process. All three upstream steps and four shingle machine steps could have been listed in a few minutes without jumping to root causes and solutions. Then project could be scoped by just including the autocatcher or autocatcher and delivery, and so on.

    Note that the actual scope has 19 factors. That will involve a large study (design of experiment) or highly fractionated study.

    Since presumably each previous step influences the next step, the team could have also started as far upstream as possible to ensure that each previous step’s output meets the necessary requirements for the next step to do its job with quality. For example, if the cause of jams is due to the cutter, the team will study 19 factors and not find a solution.

    0
  5. Jean-Marc M. Agnero

    It is a great article which guides me as a new Green Belt who just finished his Six Sigma courses.

    0
  6. Rohit Priyadarshi

    Liked the narrative style of the article. Apart from scoping of a project,the article also brings out effectively the basics of project initiation, brainstorming sessions. Even i feel like other readers here to employ process mapping,SIPOC and pareto analysis alongwith affinity diagram to scope out BB project and child GB projects.For holistic investigation, i would have scoped upstream processes ( Raw materials, coater & cooling) alongwith extreme downstream ( Delivery & autocatcher) under BB project and rest under individual GB projects.
    Nevertheless, curious to know the project outcome if it`s started bearing fruits.

    0
  7. Royce C. Boatright

    Really good article on affinity diagrams. One thing I stress at the begining of every project is to look for existing data. If the jams were a consistent and ongoing problem that had been looked at before, there’s probably some data sitting around which could help scope the project. Questions like; are some production runs more susceptible to jaming than others, is one crew seeing more jams than others, are we tracking the why behind each time it jams so we can pareto that out?

    Just my two cents. I always ask of my SMEs; do you have data, if so can I have it. Then I ask myself; can I trust the data or do I need to get my own. Even limited amounts of data can be a big help in scoping a project.

    0
  8. Andy Rogish

    Great article for
    – drawing a distinction between affinity and fishbone diagrams by considering the purpose of the tool
    – narrative story style gives insight into scenario thinking
    – drawing together the worlds of Quality/Six Sigma and Project Management, by using affinity as a scoping tool.
    Kudos! and thank you.

    0
  9. Charlie Tindill

    Great story John thanks, I’m going to use this on an exercise next week. Much appreciated

    0

Leave a Reply