Inevitably, both the types of projects you select and the methods you use will evolve as your skills in and understanding of Lean Six Sigma increase. The main reasons why some projects aren’t addressed until after you and your organization have gained experience with Lean Six Sigma are:
Notice that these issues encompass not only the need for technical expertise, but situations where teams also need well-developed people- and project-management skills. In such situations, the challenges and risks are elevated. Failing to solve a long-standing problem could disillusion staff and be a setback to your initiative, just as asking teams to apply methods they don’t understand can create frustration. And you wouldn’t want to involve external customers or suppliers on a poorly run project, even if the solutions didn’t require any particular expertise.
This chapter looks at case studies from our contributors that are more suitable for second-wave projects—that is, after the organization has some experience under its belt—either because of the need for more sophisticated tools or because they involve cross-functional and/or customer collaboration.
A Quick Guide to the Cases…
Case #6: Gaining control over process complexity [a service Kaizen project]
Case #7: Collaborating with internal customers
Case #8: Improving response time on signature services
Case #9: Cleaning up your workspace (a 5S+1 project)
Case #10: Knowing what’s here (and where It Is)
Case #11: Changing professional practice
Case #12: Developing supplier relationships through Lean Six Sigma
In February 2002, Bank One held a strategy meeting where key operational managers talked about and prioritized improvement specific opportunities. The issue of “overnight courier packs” used in their Wholesale Lockbox operations rose to the top of the list. This involves corporate-to-corporate payments that customers would overnight to Bank One and want processed ASAP the day the payments arrive.
As described at the beginning of Chapter 5, what started out as a modest service comprising a few deposits each day soon exploded into a high volume, highly complex operation with a lot of “exception processing” (where staff would need to follow non-standard procedures because of varying customer needs). Besides the obvious cost associated with excessive complexity, Bank One was also losing a revenue opportunity—the competition charged for similar services, but Bank One didn’t feel comfortable doing so until they could guarantee a specific service level. As one of the largest Wholesale Lockbox providers nationwide, the lost opportunity was estimated at millions of dollars per year to be had if the process was improved.
An initial improvement event in this area had generated some improvements, but the changes recommended to achieve a quantum improvement in service were deemed to risky, so a second event was launched to reexamine the process. The project was launched using the NEO’s group standard improvement event (Kaizen) format:
Day 1: Training and Define. Team members receive baseline training in Lean and Six Sigma concepts, such as the 7 types of wastes.
Day 2: Measure and Analyze. Team members physically walk through the process, following the path that an item of work would follow. They collect data on cycle time, queues, travel distance, and so on to complete the value stream map.
Day 3: Improvement testing. Generating ideas for process improvements continues with an impact/effort analysis to focus in on areas contributing the most to waste. The team then brainstorms solutions for the high-impact areas, and reorganizes the value-stream map to reflect appropriate changes via “should” (future state) mapping (how they’d like the process to operate).
Day 4: Improvement simulation. Participants gather data to evaluate the selected improvements, document proposed changes to the procedures, and simulate the process with these new procedures (as much as is feasible).
Day 5: Evaluate and report out. The team reviews results with the sponsors and celebrates the results.
A portion of the value stream map developed by this team is shown in Figure 13.1.
Figure 13.1: Lockbox Value Stream Map Data
This chart shows the data collected by the Lockbox team to quantify various forms of non-value-add (NVA) time in their process.
The team generated several dozen process improvement ideas they thought would have the biggest impact on turnaround time for the least investment. In general, they covered areas such as:
Team members; Sohail Khan, Stacey Hartman, Yolanda Johnson, Mike Gallagher, Keith Guarneri, Tammie Jones, Karyl Miller, Dannie Paz, David Medina, Karen Mieszala
Support: Doug Hartsema (executive sponsor), Mike Hendershott (project sponsor), Jim Kaminski
Together, these ideas allowed for a 35% improvement in cycle time, and a reliable turnaround within the promised service level of 4-hour turnaround. That means the company can now feel confident in generating a revenue stream (see Table 13.1, below, and Figure 13.2, next page).
Figure 13.2: Total Cycle Time (Before/after)
This frequency plot shows the results before and after process changes. The lower, dotted “before” curve reflects an average cycle time of over 2.5 hours. The “after” curve shows a 30% gain in cycle time.
Type of gain
To charge a fee that reflects the added value that customers receive from this service
Reduce Operator Processing Time
Reduce Total Cycle Time
At one point, the procurement operations at the Lockheed Martin facility we’ve visited many times in this book discovered there was a very low first-pass yield on certain types of purchasing requests—meaning few requests made it all the way through the process without being stopped because of some defect (such as missing or incorrect information). The buyers could not solve this problem themselves because many of the problems originated with the internal customers (the people making the requests).
In many ways, this project could be considered “first wave” in that it used basic Lean Six Sigma tools and principles—developing work standards, mapping the process, and so on. But to use these tools effectively, the buyer team had to work effectively across organizational boundaries, carefully avoiding any appearance that they were simply trying to blame others for problems. Working across boundaries takes both credibility (so people outside your work area will be willing to support and/or participate on the project) and a degree of comfort with the tools. That’s why significant cross-functional projects are often more suitable as later projects.
Improving cycle time is a strategic goal for any service function. Here, a cross-functional team, which included a customer representative, was assigned to investigate situations or factors that contributed to significant delays. In this case, they realized that 2% of purchase requests (over 1600 annually, or a 3.38 sigma level) were “rejected back” to the requester because of defects (missing, incorrect information, etc.). These rejects extended the lead time from a mode of 11 days with an average of 37 days—more than tripling the cycle time. That meant on any given workday, there were at least three irate customers and helpless buyers on the phones expediting an order impacted by these rejects.
The first issues the team encountered should sound familiar by now: they discovered there was no consistency in how request rejects were handled, no data available on just how many rejects there were, no documentation on how the process should work, a lot of differences in defining what a “reject” was, and so on. The team manually collected data for two months just to establish baselines. In fact, the majority of its work (75%) was spent developing standard work definitions and data collection procedures.
Team members: Tony Ceneviva, Dave Anderson, Luis Escalante, Catherine Jeffries, Ken Mortimer, Rich Schneider, Zakiya Slayton, Ron Varnum, Myles Burke (BB)
Support: Dan Grant, Martha Derry, Gary Harrer, Rolf Eklund, Lou Diapollo, Ken Klobus
Once they had clear definitions of reject types, the team took a natural first step, analyzing the data on the reasons why a request would get rejected. The results are depicted on the Pareto chart shown in Figure 13.3.
Figure 13.3: Pareto Chart of Reject Reasons
Pareto charts give a team a focus and set the goals for the remaining DMAIC steps. Here, five causes drove 80% of the rejects.
The team also performed an impact/effort assessment for each of these reject reasons (how much effort would it take to solve that problem; what kind of impact would it have if they could). The results are shown in Figure 13.4. As you can see, most of the issues that scored highest on the Pareto would also require a lot of effort to address.
Figure 13.4: Impact/Effort Analysis for Reject Causes
This matrix was used to identify causes that had both a high impact on the observed problem (rejected purchase requests), and the amount of effort needed to fix them. Drawing and Part obsolescence scored “high” on both scales, so you’ll see them in the upper right corner (they were the top two in frequency and also in effort to correct).
Other data analysis included looking at what factors contributed to the length of time a rejected request would sit “in queue” before being addressed.
The key ideas the team implemented were to…
As a result of the many actions:
Every business has signature services, the ones that are most visible and therefore have the biggest effect on how customers view you. In the city of Fort Wayne, one of the most visible departments is Street, responsible for everything from leaf collection to paving streets (they even have their own asphalt plant). Here’s one of their case studies:
Anyone who’s driven on streets in the northern states knows that the continuous freeze-thaw cycles wreak havoc on pavement. And the problems are made worse if the city Street department is too busy to do preventive maintenance. Pothole repair is therefore a highly visible city service, and a failure to provide timely response has significant impact on citizen satisfaction and on the number and cost of claims filed against the city. Historically, it has also been the cause of huge overtime expenses that provide another drain on city services.
Employees of the Fort Wayne Street department knew that street repair and maintenance had suffered in recent years. The result was a large and growing number of complaints. Under new leadership, the department began a two-pronged initiative to get the problem under control:
There was one more reason for putting effort in developing the pothole repair system. “We have a heavy concentration of street department workers in the leaf season and the snow-removal season,” explains Mayor Graham Richard. “If we didn’t have other work for them to do at other times, we’d have tremendous dips and valleys in employment.”
Support team members: Brad Baumgartner, Jill Morgan, Brooks Beatty
Bob Kennedy (Black Belt)
Ted Rhinehart (Champion)
The first question most teams want to answer is “just how bad is the problem.” Figure 13.5 shows a dotplot of response times once a complaint was received. The average response time was well over 20 hours, with many trailing off much longer.
Figure 13.5: Quantifying the Problem
On this chart, each dot represents the amount of time it took to complete one repair. The plot shows a typical pattern seen whenever time is being measured: there is more than just one peak, and the points trail out on the long end. Patterns like this are seen when there are some types of jobs that go quickly (the small peak toward the left), a majority of work that has almost a normal distribution, and a few jobs that, for whatever reason, take a long time to complete.
The team also mapped out the process then brainstormed ideas about possible causes of problems. The team discovered that there was a lot of inefficiency in the repair process. For example, if a crew had a repair on the northeast and one on the southwest, they’d go to the northeast and then to southwest and do nothing in between. Furthermore, standing orders were to repair only the potholes for which they had repair orders—so a team could drive over a pothole in one block on their way to fix one in the next block, and not do anything about it. (Actually, most processes have some version of this problem.)
In discussing problems with the process, the team decided to focus on:
The process changes made by the team improved communication about where the problems were and made better use of the crews’ time. The key changes were:
Each truck is now equipped with communication equipment so crews can be updated immediately of any changes in their work orders.
Defining a defect as any repair not completed within 24 hours, the original Sigma level was 1.2, which quickly went up to 3 Sigma. (In fact, that continues to rise: by December 2002, the average pothole repair time was less than 9 hours, with 100% of all reported pot holes repaired in less than 24 hours—meaning their defects have held at zero for a number of months). With lead time reduced so dramatically (see Figure 13.6), there essentially is no WIP to clog up the process. Perhaps the most important result is that positive citizen response has inspired the crews, and increased their job performance, job satisfaction, and self-image.
Figure 13.6: Improvements from the Pothole Repair Project
This time plot shows a dramatic (and sustained) drop in repair time soon after the project was launched in September 2001. Currently, 98% of the repair orders are addressed within 24 hours.
Disorganization and clutter in a workspace are big contributors to wasted time in service functions, and, if allowed to exist in public areas, will give customers a poor first impression. The way out of that clutter and dis-organization is a Lean technique known as the 5S’s, introduced in Chapter 11 (see p. 301–302). The five steps are:
…and some add a 6th S —>Safety
The buyers at the Lockheed Martin procurement center decided to put the 5S+1 method to the test. Here’s what happened…
Team: Jennifer Sharpe, Judy Liang, George Sholtis, Natalie Stewart, Glenn Harden, Nicole Plair
Resources: Manny Zulueta (Champion), Ranga Srinivas (coach), Myles Burke (BB)
During a value stream mapping event, it became obvious just how much variation there was among the buyers in how they performed the same job. The data showed the more productive buyers were also those who were the most organized in folder management, files, and general workspace usage. The team therefore launched an initiative called “Visual Workplace” with a very simple goal: To reach the point that when anyone was away from their desk, someone else could easily fill-in temporarily without spending all their time searching for the right files, information, or status. The scope of the effort was defined as follows:
The team studied other companies then held weekly meetings to develop a plan for achieving a clean, organized workspace. For each “S,” they talked about what it meant in their situation, and talked about how they would achieve that goal. For example, the first S is Sort, getting rid of unneeded work (usually paper files or other documentation) from the area, and keeping only what’s truly needed. To achieve this goal, the team follows the Red Tag process:
In the next step, Straighten—based on the simple phrase “a place for everything and everything in its place”—any extraneous paperwork, furniture, etc., is eliminated. The team continued this way through all of the S’s, developing guidelines for desk organization that would make it possible for anyone to easily find information in someone else’s workspace, etc.
This same process works for both physical and computer workspaces; in the latter case, people delete old files, archive files that should be kept for business reasons but are no longer active, and so on.
The team estimated it cost about $100 per person on average to complete this project, which included purchasing of standard supplies to make the work organization possible (In/Out boxes, hanging file baskets, file dividers, etc.). The time investment per person included a 1-hour introduction to 5S+1 process, plus 6 hours on average to complete all the sorting, straightening, shining, and so on (see Figure 13.7 for examples of improvements). The results are priceless in productivity and attitude.
Figure 13.7: Before and After Workspaces
Team member Judy Liang shows her office before the 5S+1 project (top). One action taken by the team was to post charts that help them track daily work (bottom).
“I was at a customer’s facility in Florida and received a panic call from my boss about a hot placement that needed to occur that morning. With my workplace organized it was simple to walk my coworker through the status to exactly describe where the files were for her to place the order.“
—Natalie Stewart; MAC-MAR Buyer, Visual Workplace team leader.
Most programs at Lockheed Martin rely on Government Furnished Property (GFP), equipment or materials that are owned by the U.S. government and furnished to Lockheed Martin. Knowing exactly when this equipment arrives and getting it to the proper location at the needed time has been challenging in the past. An earlier initiative failed to produce the desired results, so a team at the Naval Electronics Surveillance Systems–Moorestown, NJ, location (NESS-SS) was commissioned to take on the effort.
There are two very powerful reasons why Lockheed Martin wanted to gain better control over the GFP it receives:
Team members: Edna Winans, Glenn Carlson, Steven Ezzyk, Jeffrey Lewis, Edward Maisel, Robert Ogbin, William Quail, Robert Wolfe, Paul Zurcher, Richard Winans, Joanne Smith, Kevin Fast (BB)
Support resource: Lara Cribb
Naval / Customer representatives: Charles Deitch, Kenneth Hornback
The project goal was straightforward: getting the GFP equipment to show up in the right place at the right time. High level goals of the project were to:
In this project, team membership would be an important determinant of success. Rather than limit the team to like-minded individuals, the Black Belt pushed for a significant cross-functional team, ending up with 15 people representing diverse functions inside NE&SS-SS and 2 customer representatives. This positioned the team to define and understand the process many times better than if they had limited themselves to one or two functional groups.
After some discussion the team defined the boundaries of its project from when the GFP was received at the warehouse until it was delivered to its final destination. The box was drawn here to ensure that the project was not too large and to ensure that the tasks remained within the team’s sphere of influence.
Once the boundaries were clear, the team developed a flowchart then started measuring the performance of the process. Fortunately, a wealth of data was at their fingertips: by the nature of the process, documentation is well maintained and data mining was relatively straightforward. In addition, the team conducted a survey to understand how well participants and stakeholders understood the GFP processes. The data exposed numerous defects in the process:
“Not only didn’t people know what they were doing wrong, they did not know what they were doing right.”
—Glenn Carlson, GFP Lead
Because of these problems, GFP tracking and delivery occurred seamlessly only 10% of the time (a low first-pass yield). The other 90% of the time, some data was missing or incorrect: orders without problems had a cycle time of 2 days on average; orders with problems could take 2 days to 2 weeks. What the team discovered:
It was obvious that NE&SS-SS employees needed to be trained, and convincing the stakeholders of the need was easy. What was most exciting, however, was the active participation the customer (= the Navy) assumed in order to train those in government. Other improvements included:
“No one was doing anything wrong. The Navy ordered a Gateway computer, Gateway shipped a Gateway computer. And our defined requirement was for a ‘simulator’—which was a Gateway computer.”
—Glenn Carlson, GFP Lead
“We considered starting at the beginning of time—when an engineer thought that he might just need some sort of GFP. However, as we considered all of the variables—all of the different development engineers, many scenarios, vendors of all types, GFP of all types— it was clear that such a scope would be too large and too complex. Keeping the project manageable is a key to success.”
—Kevin Fast, GFP Project Black Belt, Lockheed Martin
As in Chapter 12, we were unable to present all of the cases our contributors have shared with us. We have compiled the cases described in this chapter and others at our website (www.georgegroup.com). Here’s a quick peek at two of the additional cases you’ll find there.
Once we’re trained on a given way to perform any work, be it a simple task or heart surgery, it’s human nature to continue doing the work that way (as long as we think it’s working). One example of this phenomenon comes from Stanford Hospital and Clinics. For several years, staff had been aware that different cardiac physicians prescribed different pre-discharge procedures for their patients. But the issue of asking physicians to change their practice was deemed so politically charged that the topic sat on the back burner… until the cardiac surgery team decided to confront the issue head on. As it turned out, one set of pre-discharge practices was more expensive than another, with no perceivable advantage to patients. A standard practice was then adopted by all the physicians in the group.
The solution to this problem turned out to be relatively simple, but the key lesson is that the outcome may not have been so positive had the issue been tackled at the very beginning of Stanford’s quality initiatives. Rather, over several years of being on and around improvement teams, the physicians (and everyone else at Stanford) started developing an “improvement mentality” that made them more open to critically examining their own practices.
The basic philosophy that drives MAC-MAR’s service is that their customers deserve to buy the best products made from the best suppliers in the world. “And if the best suppliers in the world are not our current suppliers… then we must make them the best!” They use a formal four-phase, fourteen-step engagement process with a goal of having the suppliers be self-sufficient in their Lean Six Sigma journey and to bring these suppliers into design efforts early on (and they’ll have the opportunity to become a sole source supplier for their product). They make it a win-win engagement by telling suppliers, “We are after your waste, not your margins.”
But the challenge here was that most of MAC-MAR’s suppliers fall closer to the “mom & pop” end of the spectrum than to “worldwide conglomerate”—that is, they are small operations without a lot of flexibility in staffing or spending. The last census showed 75% are facilities of less than 250 people. Small suppliers have fewer managers to deploy strategic plans or drastically reorganize work to cut costs while improving outputs. There are few green fields, a lot of heritage, and many single sole sources. They are always asked to reduce cost without always having corresponding reductions in their own costs—and thus eventually they hit a price wall.
To decide which of their thousands of suppliers to work with, the procurement staff rated each supplier according to…
This evaluation was balanced against decisions concerning how much Lockheed Martin could afford to do ($s and personnel) to help suppliers improve. The result of this analysis was a list of 200 suppliers that Lockheed Martin’s MAC-MAR and specific programs wanted to work with, and an understanding of WHY for each one—e.g., to reduce lead times, improve delivery, improve new product introductions, improve risk management, reduce cost, and so on. Over the past few years, they have used this information to help them structure and launch dozens of supplier development projects, which ranged from holding Kaizen improvement events (centered around value stream mapping) at the suppliers’ locations, to holding supplier symposiums, to deploying Lockheed Martin experts full- or part-time to work with the suppliers.
There is no substitute for conducting a rational project selection process, such as that described in Chapter 4. But the final list of candidate projects should also be filtered against the likelihood that your organization can complete the project successfully. There are no hard and fast rules about what kinds of projects an organization should work on first, or second, or not at all. But, in general, the kinds of cases in this chapter work better once an organization has some experience because they…
These types of projects can be attacked by novice teams, if they have expert coaching by Black Belts or Master Black Belts who have both excellent people skills and technical skills.
This is an excerpt of the first House of Quality the Caterpillar team developed as part of the credit card project. This house relates customer (or “Process Partner”) statements of needs (left column) to critical requirements (top columns). The individual scores for each requirement are multiplied by the importance (far right), then summed at the bottom to get a Priority rating.
Part I - Using Lean Six Sigma for Strategic Advantage in Service
Part II - Deploying Lean Six Sigma in Service Organizations
Part III - Improving Services