First Wave Service Projects

Overview

There’s a dynamic tension set up whenever a company embarks on a Lean Six Sigma initiative. Naturally, it wants to target resources at significant problems, where improvements will have a noticeable effect on quality, speed, and cost. Yet it’s likely the majority of people recruited to make these improvements will be new to Lean Six Sigma: newly minted Black Belts, novice team members, untrained frontline staff. So a company needs to balance its focus on important issues versus not putting people into situations that just set them up for failure.

Fortunately, the opportunities for manageable, meaningful projects abound in the early stages of Lean Six Sigma, especially in organizations with no active program on improvement. You can make significant gains in lead time, quality, and cost reduction relatively quickly by…

• Having frontline staff collaborate on developing complexity value stream maps. Collaboration is key because it’s through discussion that people realize there are differences in how they each think the process works. It’s this realization that opens the doors for identifying and documenting best practices.
• Developing data collection systems (especially for value stream mapping), which is generally absent from service processes.

In addition, you’ll want to use experienced Lean Six Sigma resources (Master Black Belts, Black Belts) to provide coaching on tools and methods.

Below is a selection of five case studies from our contributing organizations that illustrate how some of the basic tools and principles of Lean Six Sigma work in real life. These projects were all conducted by novice teams under the guidance of a trained Black Belt (or someone with equivalent skills).

None of these particular projects were done with novice Black Belts as part of their training, though such projects will occur in your own organization.

One last note: It is unlikely that the majority of the readers of this book will work in a procurement center, or a city government, a bank, or hospital. But as you’ll see, the basic principles of Lean Six Sigma hold true for all processes, no matter what the environment.

Quick Reference Guide for the Cases

Case #1: Understanding the process

Case #2: Blaming the visible part of the process

Case #3: Turning a customer hassle into a delighter

Case #4: Getting rid of backlog

Case #5: It’s not just WIP piling up

Case #1 Understanding the process

Kevin Fast, a Lean Sigma Black Belt and Manager of Quality Initiatives for Lifetime Support at Lockheed Martin in Moorestown, NJ, made an interesting observation: “You know,” he said, “after you do a few Six Sigma projects, you come to expect certain things. When a project team comes together to define their as-is process, inevitably someone will say, ‘You do that? I didn’t know you did that!’ Or ‘You do this? I do this, too.’ It’s just amazing how people who have worked on a process for a long, long time often don’t realize everything that goes on. And it’s because they don’t have the tools.”

Kevin was right: Though we may think we know all about the processes we use every day, chances are we’re wrong. When we start using Lean Six Sigma tools to document those processes, we all have moments of epiphany where we realize that what we’re doing differs from what others are doing. In many cases, there’s no flowchart, let alone a value stream map, that we can compare against our perceptions. And even if a process map does exist, chances are it documents only the value-add activities in a process not the other 50% or more of the activities that are non-value-add. A lack of process knowledge and documentation always means there is hidden non-value-add cost and waste that is ripe for elimination.

Why do this particular project?

As you may recall from Chapter 2, the Systems Integration MAC-MAR procurement operation at Lockheed Martin has a huge impact on overall costs and efficiency: more than 50% of the costs of their final products are determined by products and services that are purchased from outside the company.

But as in most service functions, until recently the purchasing process had never been studied in great detail. Process mapping is the first step toward developing the data for a value stream map and ultimately a complexity value stream map. The initial goal therefore was to document the current reality of the early stages of procurement, from when an internal customer submits a request to when a purchase order is generated and the order placed. The goal was to find out how the process actually worked, where the value was, and where opportunities existed for improvement.

Participants

Team: Melana Ackerman, Tim Bishop, Norma Borcherding, Allen Niven, Scott Richardson, Karen Zirkle

Internal consultant support: Tim Williams, Cathy Hayhurst, Rush Fozo

Management support: Chris Bobko, Lyle Myers, Elizabeth Petri

The Analysis

The initial steps for this project consisted of a lot of process mapping and data collection. They began with a basic flow analysis, but then continued to collect the data needed to generate a value stream map like that shown in Figure 12.1. This VSM shows the three different methods buyers used to obtain quotes from suppliers, which is typical in service processes.

Figure 12.1: Value Stream Map

This “5000-foot view” of the procurement value stream shows three key stages: purchase history review, request-for-quote generation (where price and delivery are confirmed with the supplier), and finalizing the form for entry into the purchasing system. It has three separate paths because different buyers did the work differently.

The data they gathered led to the creation of a time value map (TVM), shown in Figure 12.2. In this sample, only 14 minutes of a 4-day turnaround time was spent on value-added work—and this reflects higher-performing buyers working on simple requests. (The median turnaround time for all orders was 11 days.) Other insights included:

Figure 12.2: Time Value Map for the Purchasing Process

This time value map depicts how little time in a process is spent on value-added work compared to non-value-added delays. Here, only 14 minutes added value in the eyes of the customer.

• The TVM made it clear that even if the buyers doubled their productivity (completing twice as many orders a day), it would only shorten the total cycle time by 7 minutes over 4 days! Getting significantly faster wouldn’t happen by getting buyers to “work harder”—it would take eliminating non-value-add time in the support process that delayed prompt PO placement.
• Originally, there was only one measurement of lead time, and the clock started the moment someone entered a request into the system—but it could take days before it reached the buyer. That meant measures of buyers’ lead time looked much worse than they really were because they were penalized for time over which they had no control. Now, there are two distinct metrics: total cycle time and buyer cycle time. This better understanding of the metrics provided the data to start additional cross-functional teams to look at the whole process. (Measurement system errors are common in transactional processes mainly due to the lack of standard definitions.)
• 41% of the requests were for materials or items that cost less than $50; another 38% was for items under $500. Estimates showed that the cost to place about half of all orders was more than the cost of the order itself—meaning a disproportionate amount of resources was being spent on low-dollar items.
• There was often insufficient information submitted by the requesters, which meant the buyers couldn’t do their jobs and had to send the requests back for “rework” (pure non-value-add activity).
• Priority was often given to orders based on when the request was submitted, not when delivery was due because a key metric was not aligned with the true customer CTQs.

Solutions Results

One question that arose for this team was “why isn’t this a paperless system?” Having a method that eliminated paperwork would save a lot of time, especially on the small dollar-value requests (where it actually cost more to place the order than to purchase the goods). The team implemented numerous actions that revolved around training, new processes, best practice standardization, new computer functionality, daily status messaging, working with the customer, and so on. Here is a sample of just a few of their improvements:

1. A full-time position was created to focus on high volume/low dollar purchase orders, with an emphasis on expanding the use of master (blanket) purchase orders, electronic on-line catalogs, and purchasing via credit cards.
2. Adding a “material-request to purchase order” cycle time metric to the visual management boards allowed the group to track the daily pulse of work-in-process.
3. A second team developed a Buyer Training Aid pamphlet that had quick reference materials incorporating best practices.

What it took to make this work

• In any un-studied, un-documented process, you will always find easy improvements that lead to visible improvement—having people who work on a process talk about what they do inevitably leads to some quick hit improvements.
• A key element is observing the process in action. This project took three Black Belts and a core team of buyers three weeks (part-time) to capture the process details for the value stream map. (The Black Belts would sit with the buyers asking a lot of “dumb” questions, looking over their shoulders observing keystrokes, time on the phone, interruptions, etc. This only works if you have a good team with very people-friendly Black Belts.)
• The people who work on the process were integrally involved.
• This project, like many at Lockheed Martin, was conducted in a Kaizen mode—short, intensive sessions.

  “With shorter lead times, people are not interrupted in the middle of a task to handle another customer. People in service take it for granted that we will have to constantly change tasks mid-stream, moving on to a second task before the first is completed. While some flexibility is good, too many interruptions lead to inefficiency. This was observed daily in the VSM by sitting next to the buyers being in their shoes. The Black Belts saw that the buyers’ priorities would change two or three times within an hour.”

  —Myles Burke, Master Black Belt, Lockheed Martin

Case #2 Blaming the visible part of the process

It seems common in service functions for people from only one part of a process to receive most of the blame when something goes wrong. A delivery is late? Blame the delivery person. A hospital bill is wrong? Blame accounting. A maintenance person appears in the wrong location? Blame him or her. In all of these situations, there is some chance that the end-point person is at fault. But the vast majority of the time, factors from throughout the process are the root cause. Bank One ran into this exact situation early in one of their improvement efforts.

Why do this particular project?

In June of 2000, Bank One handled more than 210,000 transactions where an individual or corporate customer requested a paper photocopy of a cleared check. Though this check copy retrieval process wasn’t as visible as other bank services, the quality of the process was critical in determining the attitudes of those customers who used it.

Data from that month showed that 10% of those transactions resulted in a service failure—the customer didn’t get what they wanted, when they wanted it. And the rate rose as high as 25% on some days in July. So in any given month, the bank could create 10,000 or more unhappy customers. It was no wonder that staff were tired of dealing with angry customers calling to demand why their copy hadn’t appeared as promised, or complaining that the copy was unreadable.

The Analysis

The cross-functional team brought together to improve the photocopy retrieval process quickly identified three main failure modes:

• The customer didn’t get the check copy on time
• The customer couldn’t read the copy
• The bank had no copy of the check

They then mapped each step of the process and determined what could go wrong in that step that would contribute to the failure mode (which is the essence of Failure Modes and Effects Analysis). It turned out that nearly every step of the process had serious problems. Here are just three of the many problems they uncovered:

• Staff sometimes promised the wrong service level to customers. The bank had a standing policy of providing 3-day turnaround… but that was good only if the check was kept onsite. Checks over two years old were moved to off-site storage—and it could take two or three extra days to produce copies of those checks. The retail branches didn’t know about the two-year cut off, so they were unknowingly promising the wrong delivery dates.
• The request may have incomplete or wrong information. The staff trying to retrieve the checks often had difficulty identifying what it was they were supposed to copy because information was either missing from the request form or filled in incorrectly. (A Pareto chart revealed the most common types of problems, see Figure 12.3.)

Figure 12.3: Pareto chart of errors

This Pareto chart showed that the two biggest types of errors made in the check retrieval process were having an invalid sequence number and an invalid date.

Fixing those two types of errors first will eliminate the majority of errors.

• Vendor service quality had a big effect. Some check “copies” were actually images on microfiche film. The team tested a number of microfiche cartridges by exposing the film and returning them to the vendor, who would develop the images. They discovered that the vendor overexposed one out of every ten cartridges. So 10% of the time an image was unclear because of overexposed film—a problem that no one inside the bank could solve.

Solutions Results

The team instituted numerous changes throughout the process to deal with the problems they had identified. Some common themes in the solutions were:

• Mistake-proofing the process: Improving the software used to submit requests prevented clerical staff from entering incorrect information (e.g., not accepting alpha characters where numerals were required). It also allowed an instant message to pop up whenever the check date was more than two years old so staff would know not to promise a 3-day turnaround.
• Educating staff on the procedures. New procedures exist that allow staff to adjust the microfiche equipment to make the photocopies better, and there is better documentation on making clear photocopies. There is also a new set of standard error codes used to communicate between the retrieval staff and other users. Having everyone trained on the new codes eliminated miscommunications where clerical staff didn’t understand what information the retrieval staff needed.

Participants

Heather Presley (Green Belt)

Team: Elissa McGauley, Rick Kunkel, Michelle Kyrou, Jim Norris, Pat Fahey,

Support: Andrew Downs (Champion), Stacey Stumpf (Black Belt)

• Developing better tracking so they could tell where, when, and under what conditions service failures were most likely to occur. The process includes regular business reviews where management and staff evaluate performance data an react quickly when problems arise.
• Initiating preventive maintenance on key equipment. When the changes were first made, vendors were required to perform frequent tests of their equipment. The tests have gotten less frequent now that the process is stabilized.

Measurable Results

Soon after the team started implementing the new procedures, the error rates dropped substantially. Overall service failures were cut in half, from more than 15% to nearer 7%. Factors contributing to this drop were improvements in preventing the various types of service defects. Figure 12.4, for example, shows a drop in the number of requests the bank was unable to fulfill due to mistakes made in filling out the request forms.

Figure 12.4: Time Plot of Check Retrieval Errors

This time plot shows how many check retrieval requests the bank staff could not fill due to problems with how the initial request form was filled in. The data shows that the errors dropped steadily for months after the changes were made.

What it took to make this work

• Having an end-to-end perspective of the process. Bank One had tried to fix this problem in the past, but the efforts always focused just on the people who made the copies. This time, they included people from all parts of the process on the team: front office retail and commercial (the people who deal directly with customers); item processing (where the checks are originally converted into microfiche); and retrieval.
• Devoting sufficient resources to the problem. This project was not the first time the bank had attempted to improve this process. What was different this time was not only did they draw people together from all points in the process, end to end, but also devoting people to the team full-time for four to six weeks. (This kind of focus on an important project is possible only if you limit WIP—the number of “projects-in-process.”)
• Realistic expectations: While six sigma levels of quality are always the goal, Bank One has found that’s simply not practical in their environment—at least not in all cases yet. Here, cutting the failure rate from 15 to 7 percent was worthy of celebration. After that, other priorities popped to the top of the list (that is, they could make greater gains in productivity and customer satisfaction by working on other problems). Once improvements are made elsewhere, it may be that reducing this 7% failure rate will once again become a priority.

That said, it wasn’t the data that convinced the customer service staff at Bank One that this improvement stuff was okay. It was when they stopped getting phone calls from customers yelling at them.

Don’t forget the Intangibles

“Improving this process didn’t require the use of advanced statistical tools. Success came from having a cross-functional team examine the end-to-end process and identifying the gaps that caused breakdowns through the use of simpler tools such as cause-and-effect diagrams and Pareto charts.”

—Tim Williams, Ass’t Vice President, Bank One

Case #3 Turning a customer hassle into a delighter

As a customer yourself, how often have you decided NOT to do business with a company because it was simply too much of a hassle? Customer surveys reveal that people often make their decisions about where to take their business based on their total experience with a company, not just on price alone. Here’s an example from the city of Fort Wayne, Indiana, that demonstrates how much can be gained by removing hassles for your customers.

Why do this particular project?

Like many cities, Fort Wayne has suffered the loss of key employers throughout much of the 1980s and 1990s. Economic development efforts are therefore key to the city’s long-term plans. Sustaining and creating the tax revenue base was clearly one of the largest “ROIC” opportunities facing the city.

Through some initial benchmarking, the city’s Department of Economic Development discovered that the city was failing in a critical element of the building permit processes. While smaller cities nearby could turnaround site plan improvement applications in just 5 to 10 days, Fort Wayne was taking 50 to 60 days or even more. And it wasn’t just turnaround time that was a problem: potential applicants were expressing a desire to build/expand in other locations to avoid Fort Wayne due to the protracted and intimidating permit approval cycle. They were hearing comments like, “I’m not going to put myself through that hassle. The permit process takes too long, there’s too many restrictions, and I’m not going to go in there and be treated that way.”

Participants

Departmental team members: Rick Orr (Black Belt), Elenore Petroff, Sunnie Heddon, Harvey Meyer, Mike Burkart

Expert resources: Bill Simmons, Peter Hill, Bob Bowen, Gary Merriman

Support: Ted Rhinehart (Champion), Michele Hill (BB), Roger Hirt (BB)

Obviously, this negative attitude towards dealing with the city was having a serious impact on jobs and business opportunities.

The Analysis

A first step for this team was collecting the Voice of the Customer by conducting focus groups with representatives from other city departments affected by or involved in the permitting process, and with external customers (building contractors, engineers, and architects). Critical-to-quality factors turned out to be:

• Timely approval of permits and certificates of compliance
• Excellent service in face-to-face contact
• Timely and accurate reviews
• Quality of the communication between the city and the customer

To focus their efforts, the team created a process map (Fig 12.5) and then answered the question, “What process steps most significantly affect whether customers get what they want?”

Figure 12.5: Permitting process flowchart

They concluded that the following process elements were most critical:

• Reviews of the permit application documentation (“site packages”)
• Routing meetings and attendees (where it is decided which city departments have to get involved in the review)
• Tools and guidelines used during reviews
• Communication back to the customer after the city’s review

Their investigations revealed that the permit process was rife with non-value-added work and delays. For example, standard practice had been to send every application to every department, when in reality different types of permits needed reviews by only certain departments. As the process was originally structured, a lot of people ended up going through a lot of permits they didn’t have to review. Eliminating that overproduction was a huge reduction of WIP which, according to Little’s Law, will dramatically reduce Lead Time.

Solutions Results

After studying each of the target process elements, the team came up with a number of process measurements, changes, and enhancements:

• Using a punch list to make sure that the permit requests are complete before they are accepted from the customer
• Developing better tracking capability through use of new software (see Figure 12.6, below)
• Developing triaging criteria (such as assigning “red flags” to permit types that had historically proven challenging or complex) and developing alternative pathways for simpler permit applications
• Changing procedures to provide better collaboration and communication between city departments
• Collecting data regularly to better measure and monitor turnaround times

Figure 12.6: Permit Tracker [Screen Capture]

Results

The team tracked three different kinds of results: measurable improvements in lead time, cost avoidance, and anecdotal support.

1. Quantifiable results in lead time

The team saw dramatic improvements as soon as they began making changes (see Figure 12.7), and ultimately achieved even greater gains (see table below).

Figure 12.7: Before & After Results of the Permit Tracking Project

Before	After
None released <14 days	95% released in <10 days
Nearly 1/4 took 60 days or more	Only special causes exceed 41 days
72 requests in the cycle (WIP)	30 requests in the cycle (WIP)

2. Expenditures avoided:

The team Green Belt taught herself Access and did the programming—saving the city from spending $150,000 that had been budgeted for software purchases (funds that were freed up to provide additional services to citizens).

3. Anecdotal support

Feedback from customers has entirely changed in tenor from “I said I’d never build here” to “I never believed that the city could get this good.” The builder’s association was so excited about the gains that they invited the team Green Belt to give a presentation at an association meeting.

What it took to make this work

• Giving teams the green light to immediately fix obvious problems. As Roger Hirt says, “One of our philosophies with all of our Green Belts and Black Belts is that they shouldn’t wait until the end of the project before making changes. Don’t let it run on broken. We call it process hardening—get it done, put it in place, make it work, fix it.”
• Having a cross-functional team. Typical permits need to pass through a number of city departments before they are approved, so no single department could have hoped to improve cycle time without cooperation from all the departments involved.
• Using a process focus and data to build trust. Team members drawn from different city departments were able to set aside historical finger-pointing blame games by focusing on the process and using data to isolate problems.
• Direct contact with customers. Holding discussions with various customer groups (contractors, engineers, realtors) proved invaluable in providing direction and focus to the project, and in re-establishing trust between customers and the city.

Case #4 Getting rid of backlog

Why do this particular project?

For years, the problem of “curb cut restorations” was a real headache in the city of Fort Wayne. A curb cut is when a builder or contractor cuts away part of a curb and the adjoining frontage property in order to add a new driveway, create a handicap-accessible sidewalk ramp, and so on. In theory, the entire process from making the cut to complete restoration (pouring the concrete, re-seeding grass) is supposed to be done in 30 days. Then, also in theory, it would be inspected by the City and cleared off the books.

What happened in practice was twofold: (1) sometimes the restorations never got done, and (2) it could take as long as three years for the inspection to be done.

By early 2001, there was a backlog of over 2800 curb cut permits that were unresolved (= WIP), clogging the permit process.

The Analysis

Ideally, once an individual or company receives a permit, the process should flow through just three steps: the permittee makes the cut, the permittee restores the cut, and the city clears the permit. But along the way, as the team discovered, there was a lot of opportunity for errors.

Participants

Departmental team members: Rick Orr (Black Belt), Elenore Petroff, Sunnie Heddon, Harvey Meyer, Mike Burkart

Expert resources: Bill Simmons, Peter Hill, Bob Bowen, Gary Merriman

Support: Ted Rhinehart (Champion), Michele Hill (BB), Roger Hirt (BB)

For example, the original information was copied several times by hand before being put into a database. As you probably know, one way to minimize errors in paperwork/information systems is to minimize the number of times the information is touched. Also, there was often poor communication between city departments. When one department would confirm restorations (“clear the permit”), they threw the paperwork in a box without updating the central records. When a team member asked why the department had so many open permits, they responded “Oh, we got all those done.”

Overall, the team confirmed four main problems with the process:

• Cuts not being restored quickly enough
• Permits not being finalized quickly enough
• Customer satisfaction is too low
• Wasted dollars due to process inefficiencies

Solutions Results

The team performed a Failure Modes and Effects Analysis (FMEA) to identify the ways the process could fail that would contribute to the problems they had just confirmed. A portion of this analysis is shown in Figure 12.8.

Figure 12.8: FMEA table

By looking at ways in which the process could fail, the team discovered factors that led builders to unintentionally exceed the 30 day limit (such as when inexperienced permit holders subcontracted out the restoration work without informing the subcontractor of deadlines).

In response to their FMEA analysis, the team initiated the following changes:

• Regularly communicating expectations to applicants
• Better documentation of key information (e.g., recording anticipated completion dates on permits)
• Identifying locations where restoration was not required
• Instituting daily updates on particular types of restoration work
• Triggering inspections based on expected completion date rather than waiting for notification of completion to arrive at the office
• Working with customers so they would not request permits until the work was scheduled (originally, if a contractor or the power company was going to develop 40 sites, they’d get permits for all 40 at once even though work on the majority of those sites wouldn’t be started for weeks or months)
• Working closely with their largest customer (who always had numerous permits-in-process) to foster better awareness of its progress, delays, etc.

The team also immediately and easily reduced the current WIP by examining open permits and determining which were in fact still open and which were completed but the city had not been notified. This cleared a lot of the backlog.

Results

• Goal #1: Reduce WIP: The original level of 2,843 backlogged permits dropped to 342 within just a few months.
• Goal #2: Having all the permits cleared (the cuts restored and confirmed) within 45 days. The extra 15 days beyond the 30-day limit stated on the permit was to allow the grass to grow. The actual results can be seen in Figure 12.9 (where a “defect” is any permit not cleared in 45 days).

Figure 12.9: % defective, before and after

The data points here are percentages of defective curb restorations (those not cleared within 45 days). The upper line shows that originally often times less than 20% of curb restorations were cleared within the target time frame. Post-improvement (lower line), the situation is completely reversed:_80% of the curb cuts are restored within target, and only 20% do not make the deadline.

In addition, the database on completed and outstanding permits is now essentially defect-free (and more likely than before to remain that way).

What it took to make this work

• Looking at the process from the customers’ viewpoint. The team members realized they needed to understand the contractor’s process and its relationship to their process.
• Making changes in both their processes and their customers’ process. Achieving the faster lead time required modifications in both the contractors’ and Fort Wayne’s processes. The work with customers had to be conducted in a non-costly and non-threatening manner.
• Recognizing that a “one size fits all” process was inefficient and prone to delays and errors. They needed to develop alternative pathways depending on the substance of the permit.

A last bonus case

Due to space considerations, 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 just one of the additional cases you’ll find there.

Case #5 It s not just WIP piling up

When you’re in charge of Robbery cases in the City of Fort Wayne, the people you’re concerned about aren’t just “customers,” they’re crime victims. So when you see that the number of unresolved robbery cases is increasing faster than the number of resolved cases, you start to get concerned. At least Captain Art Norton, a 16-year veteran on the Fort Wayne police force, did. So he launched a project to see if the lead time for the disposition of Robbery cases could be brought down from 2 months to less than 30 days.

Captain Norton and a team of nine police officers and administrative staff mapped out the robbery case process, from assigning of the cases to five potential outcomes: an arrest is made, there is a warrant request, the complaint was unfounded, the case is closed because the likelihood of solving it is extremely low, or the arrested person is prosecuted for different crimes (“exceptional clearance”). The mapping exercise and subsequent data analysis revealed a number of procedural problems in the process, such as the lack of controls over staffing levels in the typing pool, no backup procedures in place if the Sergeant in charge of assigning a case is away, a lack of use of guidelines on determining solvability, and so on.

The team made a number of relatively simple changes:

• Establishing guidelines for minimum staffing levels in the typing pool. This eliminated delays in report preparation due to illness or vacation, etc., among typing pool staff.
• Training officers on new quality control guidelines. This eliminated delays due to the problems with the report forms.
• Assigning backup responsibility among section Sergeants so cases could always be assigned for investigation within 24 hours. This eliminated delays in assigning cases.
• Establishing a triaging procedure (see pp. 299–300) such that cases determined to have a low probability of being solved were diverted out of the mainstream case assignment. This eliminated WIP and cleared the pipeline so officers could spend their time on cases that were more likely to be solved.

Results: Average days to disposition was 58 days prior to this project, now it is 24 days. And even those that can’t be solved are being handled better: The new process for the “no solvability” cases includes upfront communication with robbery victims. Whereas in the past they’d be kept hanging for months at a time as their case languished in the pipeline, now they’re told that the likelihood of solving the case is slim and it will not be actively investigated. Having an earlier resolution to the case, even though the resolution does not include charging a criminal, has been a welcome change among the robbery victims.

Lessons We Can Learn

Here are some tips for running first wave projects:

• Have teams focus on projects within their work area, because that is where they will have the greatest amount of control, subject matter expertise, and support.
• It’s important to select projects that will mean a lot to the people involved. Ideally, the selection would be based on the Voice of the Customer and/or management’s key business needs.
• Be patient with process mapping and data collection; expect some confusion and mistakes the first time around.
• Try a few Lean things—get rid of WIP, visible waste, and hassles by improving flow, and everybody will be happy with and learn from early results.

If all you get is a value stream map and data out of the initial efforts, that’s quite a bit… and it won’t be “all”! In getting people to agree on flow as it is now and should be, you’ll eliminate waste. And even without any sophisticated analysis, you’ll be able to use the data to pinpoint areas where delays and complexity are greatest (“identify the Time Traps”). Often, just a few simple improvements will eliminate waste and delay… once the data on the value stream map has been compiled. So invest the time to get it right.