Chapter 13

Successful Implementation of Lean

This chapter discusses some of the logistical and organizational considerations that must be negotiated for a Lean program to be successful, where the term program is intended to mean an effort within a company where many Lean projects are undertaken over a sustained period. Questions that must be considered in designing a Lean program include: How many Lean projects should be pursued simultaneously, which Lean projects should be pursued, how should management support Lean projects, how should Lean project teams be staffed, how should Lean projects be planned, and what are common roadblocks that are encountered in Lean programs? These questions are addressed in this chapter.

Employee Involvement and Lean Team Personnel

Lean projects are best done in teams for many reasons. First, constructing and improving the value stream map requires knowledge of all steps of a process. The scope of Lean projects is usually large enough that no one person is familiar with all the process steps, thus multiple people are required to develop a comprehensive understanding of the entire process. Moreover, buy-in to process improvement solutions is required for successful implementation, and involvement on the team fosters that buy-in. In addition, besides people who are directly responsible for the operations in a process’s steps, personnel from relevant support departments should be involved because their involvement during the project should encourage, first, buy-in and, second, support during the ensuing implementation phase. Finally, it is often a good idea to involve people from outside the process. Intuitively, people from similar processes in the same organization can share best practices across the organization. In fact, including people from outside the process with no knowledge of the process to be improved can be a good, albeit unintuitive, idea. How so? People’s familiarity with a process can cause them to be too wedded to the current process, which promotes continuing to do it the way they have been doing it. Team participants that are not so close to the process have a greater capability to think of ideas that are out of the box and groundbreaking.

Involving personnel from the entire process, from support functions (e.g., information technology, engineering, maintenance, human resources, etc.), from other similar processes, and from other plants has a benefit for highly siloed operations that is, perhaps, unexpected. While communication and coordination within departments may be fairly effective in many companies and organizations, coordination across departments is more difficult. Companies, especially those that operate within departmental silos, can expect opportunities for organizational development from Lean projects. In particular, having people on a Lean team from all departments involved in a process helps to break down barriers and animosity between departments that naturally build up over time among insular departments. People from different departments who work together on a Lean project sometimes develop personal relationships that dispel the negative notions held about other departments and make it more likely that those people will be able to work together in the future more effectively. Besides reducing interorganizational tensions, this benefit is particularly significant because processes naturally cut across departments and involve support groups. For processes to be executed well, all departments need to be focused on the processes in which they are involved rather than their department’s self interests.

Who should be on Lean teams? Many arguments point to involving workers on the lowest level of the organization who actually execute the process. First, any organization’s hierarchy is likely to be a pyramid, with fewer higher level managers and many more workers on the lowest level. If Lean projects involve only managers, then the vast majority of an organization’s human resources will not be leveraged in the Lean efforts. Making as much improvement as quickly as possible, therefore, requires involving lower level personnel. In addition, the old saying “Nobody knows a process like the person who stands within five feet of the machine all day” is true and implies that you should include workers if you really want the team to understand the process, which is a prerequisite for finding the greatest possible number of the best improvement opportunities. Further, employees who have not been involved in the process, or who have had representatives involved in the improvement process, are less likely to support the changes. Therefore, even if it was not a good idea otherwise, involving floor-level workers is essential to finding good improvements and getting them implemented. This is not to say that technical workers and managers should not be involved on a team. This can also be a good opportunity to build bridges across the levels of the organization.

One true story that illustrates the importance of involving workers from all aspects of the process and, especially, involving lower level employees is as follows: A manufacturing company had an active and successful Lean program. One project that they pursued was a 5S project where one of the end results was an improved process layout within a work cell. Five days were allotted for the kaizen project to implement 5S. The team was justifiably proud of itself because it required only 3 days to clean, reorganize, and improve the flow in the work cell, which was approximately 40 feet by 80 feet. The new equipment layout reduced travel time and lead time of the process significantly and lent itself to ready identification of problems in the process because the entire process could be viewed from one vantage point. On the fourth day, the team returned to the work area to celebrate their early completion of the project. Much to their dismay, the entire work area had been rearranged back into the original configuration. What had happened? The second shift contract employees had not been invited to participate on the Lean team with the first shift permanent employees. When the second shift workers arrived to work on Wednesday night, they found an unfamiliar process layout, which they truly might not have understood. Possibly because they did not know how to operate the process under the new design, or perhaps in defiance for not being involved in the change, they took the time to put the process back into the layout with which they were familiar. Although frustrating, this experience was one that stuck with the team members, many of whom were likely to be more inclusive in subsequent projects.

The Project Charter

A document called a project charter is typically used by companies to define, propose, and plan Lean projects. This document might also be used to determine which projects a company will support in the short term. Another benefit of project charters is that filling them out forces a team to think through a project at a level of detail that increases its probability of achieving their goals and making a substantial contribution to an organization’s improved business performance. Figure 45 shows a blank charter template and typical information required in a charter.1 The charter’s header section indicates key contacts and broad information about the project. The indication here of the product or service affected gives top management an idea of whether this project addresses the most important aspects of its business. A champion is a person who is at a relatively high level in the organization and whose business area will be addressed by the project. The identity of the champion indicates to top-level management that this project is supported by the champion, who is vouching for the importance of the project to the operations under his or her jurisdiction. The business unit indicated on the form would likely, therefore, be the champion’s business unit. The team leader is responsible for managing the project if it should be approved. A team leader with a proven track record might enhance the chances that management would support that project. That said, new team leaders should be developed on an ongoing basis. The project facilitator is a person with expertise in Lean. He or she provides guidance for the team regarding which Lean tools should be applied in a project, as well as how these tools should be applied. This person is also likely to facilitate constructive conversation in team meetings.

Lean Project Charter

Figure 45. Lean project charter template.

The body of the document gives the details about the project in terms of nine elements. In order to describe these elements more concretely, we will give examples of how they might be specified for the five processes shown in Table 12. Some of these processes have been described elsewhere in this book, so the reader who has progressed linearly through the book will find these processes to be familiar. For those who have used this book as a reference, the chapters that relate to these processes will be cited. In the context of manufacturing, we will consider the job shop setting used in the chapter on work cells (chapter 11) and, in particular, a product family manufactured in that job shop, which is a group of parts that require common processing. In the realm of sales and marketing, we will consider the process that a company uses to respond to a request for quotation (RFQ), such as was discussed in chapters 2, 5, and 12. In administration, we will consider the process that creates invoices that are submitted to customers for payment, as was discussed in chapter 2. In a service industry, we will consider baggage handling at an airport, which is an allied process to the Jetway management process that was briefly discussed in chapter 1. In health care, we will consider the process of delivering medications to patients in a hospital. For an in-depth consideration of such a process, Harvard Business School Publishing has published an excellent case, which is titled Deaconess-Glover (A).2

The process element of the project charter describes the process within the business unit identified in the header section that will be addressed. The process names that are specified in the second column of Table 12 might be appropriate responses for this element on the project charter form, except that we would want to be more specific in the manufacturing example. For our illustration, let us consider a manufacturing process for mePads, which are a relatively small and thin handheld computing devices consisting of an internal circuit board, a screen, and a case. The current layout of the mePad factory is similar to the job shop layout described in chapter 11 with three production departments: circuit board assembly, final assembly, and packaging. MePads are produced in batches, 1,000 to a batch. Circuit boards for 1,000 units are assembled and stacked on a pallet before being transported to final assembly. After those 1,000 circuit boards are assembled together with screens and cases into a finished unit, they are, again, loaded on a pallet of 1,000 units, and then transported to the packaging department. The packaging department puts the finished units in boxes, along with manuals, and then puts them into racks in the warehouse. With this backdrop, the process name that might be entered on the project charter is “mePad production process.”

Table 12. Process Examples

The project description element describes the problem that will be solved by the project. In the case of our five projects, this element might be stated as shown in Table 13.

If the process description is well stated, then it should be relatively easy to identify the metrics that are listed as part of the objectives element on the project charter. In fact, the project descriptions in Table 13 are so clear in our case that we can easily identify the appropriate metrics that should be targeted with the projects, as made explicit in Table 14. If the metrics are not so clear from the process description, then perhaps the description can be improved. Lead time is clearly a metric that if approved would help resolve the issues identified in the process description for the first four projects. In fact, the mePad manufacturing process description implies two lead times: overall process lead time and time from when customers place orders to when the orders are shipped (see Table 14). The focus of Lean is lead time reduction, and so it is clear that the Lean methodology is an appropriate avenue to resolve the issues identified in these four projects. Furthermore, the other non-lead-time metrics listed for the first four projects involve quality improvements, which also tend to occur with Lean projects. Management should be looking for this congruence between a project’s goals and the Lean methodology when it approves Lean projects.

The congruence between Lean and project goals is not so apparent in the case of the health care project. The metrics that fall out of the process description for that project (see Table 14), increased frequency of medication delivery and reduction in prescription changes, a measure of efficiency and a measure of wasted labor hours, may not be so clearly related to Lean, at least to the novice. Hopefully, management has some knowledge of Lean or asks the right questions of the project participants to realize that increased frequency of fulfillment is synonymous with reduced batch sizes and reduced setup times. Furthermore, the lead time of the fulfillment process must be reduced so that fulfillment can be performed more frequently. In addition, if the lead time of the fulfillment process is reduced, then it could be delayed until closer to when the medications were needed. Postponing the selection of medications in that way allows a greater percentage of the doctors’ revised prescriptions to be taken into account, and thus the percentage of prescriptions that needed to be replaced would be reduced, as would the associated waste of throwing medications away and the additional labor hours required for rework. Finally, Lean usually uncovers opportunities for improving efficiency. Thus, although not as apparent from the process description, Lean is an appropriate tool for this health care project mainly because reducing lead time is required to improve the metrics for this project. Because reducing lead time is so important to this project, it could also be listed as one of the project metrics.

Table 13. Project Charter Project Description

Besides lead time to respond to an RFQ, another metric was added to the sales and marketing project—namely, the average number of errors on an RFQ. Although not explicitly mentioned in the project description, this might be an important metric to include because we do not want to decrease lead time if we are going to sacrifice accuracy. Additionally, fewer errors should support the stated goal of a higher win rate, and including this metric puts a focus on a facet of performance on which we can expect Lean to deliver. This metric also reminds us to look for quality improvements as we analyze the process. Similarly, in the administrative process, reducing errors is important because invoices with errors will result in the customers having extra time to submit their payments, which would result in a longer lead time to be paid (as the terms of payment are typically extended when invoices are in error).

Table 14. Project Charter Process Metrics

In the baggage-handling process, reducing the lead time from plane to terminal will reduce the number of bags that do not make close connections and, furthermore, allow closer connections, which increases the number of feasible flight combinations and perhaps customer satisfaction due to a greater selection of feasible combinations of flight legs. Again, a measure of quality (percentage of bags misrouted) is important in this process because it is not sufficient for bags to be placed on any plane: They need to be on the correct plane in order for them to arrive with customers at the final destination. Including this quality metric, again, heightens team members’ attention to potential causes of misrouted bags. Including the average cost paid for special delivery of late bags is perhaps redundant with the percentage of bags misrouted. However, using metrics that are measured in dollars is often effective in convincing people that the process is worthy of the resources that would be dedicated to it in a Lean project.

Because Lean can often result in process lead times being reduced by 90% or more, managers who advise Lean teams and who approve projects often look for teams to target lead time reductions, and improvements in other metrics, by 50% or more. The idea is to have the Lean teams realize that significant improvements are possible and to strive for them.

The next element in the project charter is process scope, which defines the size of the process that the project will address. In Lean projects it is best to think of defining process scope by listing the first step and the last step of the process that will be addressed. The scope of a project must be carefully selected for the project (a) to be feasible in a reasonable amount of time and (b) to yield a significantly improved process. If the scope is too small (i.e., too few process steps), then there are fewer opportunities for improvement and a greater probability that any suggested changes will conflict with other process steps not considered within the project scope. A small scope also reduces the advantages discussed previously of having a project that crosses departmental boundaries. Examples of how the scopes for our five projects might be stated are shown in Table 15.

Table 15. Project Charter Process Scope

One scope that is illustrative is the baggage-handling process. One might argue that this project is about what the baggage handlers do to get bags off the plane and how they interact with the baggage-handling system. One might further argue that what the pilots and ground control do to get the plane to the gate sooner or later is beyond the control of the baggage handlers. Defining a larger scope, however, has advantages in this case. If it is not deemed important for the plane to get to the gate as soon as possible, this is time lost that makes it more difficult for the bags to get to their next destination. Including the steps required to get the plane to the gate would motivate taking a closer look at these preliminary steps, which do matter to the ultimate goal of this project. Also, including people outside the realm of the baggage handlers would expose more problems and opportunities for improvement. Having a wider scope and more interdepartmental interaction also has advantages as mentioned previously in terms of organizational development. One could even argue that the scope of the baggage-handling project should be expanded beyond what is listed in Table 15. Transferring baggage is not complete until the bags make it onto their next flight or arrive at the baggage carousel. Hence, a greater number of process steps could, and possibly should, be included, such as the sorting process itself and moving the bags to the outgoing planes.

Similarly, the scope of the RFQ process could have begun when work begins on an RFQ response. However, defining the scope as it is in Table 15 makes it clear that the clock starts ticking when an RFQ is announced, and it is important to detect RFQ opportunities as soon as possible to start work on the responses as soon as possible. In other words, we have enlarged the process scope from what it might have otherwise been.

The next element, business case, is a short statement of why a project is important to the organization. Although this may be apparent from the metrics and problem statement, this may still be a reasonable element to require of project teams. This is an opportunity to express how a project relates to the organization’s strategy and top-level metrics. For example, Table 16 lists how this element might be completed in the case of the five projects we are considering.

Table 16. Project Charter Business Case

The sixth element, benefit to internal and external customers, specifies the customers who will benefit from the project and how they will benefit. External customers are people, companies, and institutions outside the company or organization undertaking the project. Sometimes external customers are considered people outside the facility undertaking the project but still within the same company. Internal customers are people and departments within the organization undertaking the project. Table 17 shows possible responses for this element for the five projects.

The seventh and eighth elements of the project charter, team members and schedule, simply list the team members (and their departments) and the proposed schedule for the project. Management who critique this proposal might check that the team is sufficiently interdepartmental and involves all relevant parties. The schedule should be reviewed to ensure it is not so short as to be unfeasible and not too long as to lose focus. Finally, the ninth element, support required, lists the support functions, departments, and resources that are required to successfully complete the project. Management might check here to see if any department or resources are listed that are not represented on the project team. If a critical resource is not represented on the team, then perhaps expanding the team should be considered for the reasons previously discussed. Support might include departments such as maintenance, engineering, information technology, human resources, and so forth.

Table 17. Project Charter Internal and External Customer Benefits

The project charter in Figure 45 should be considered to be malleable. The data fields and terminology used can and should be adapted to a particular organization’s needs. For example, different organizations might have different titles for those involved in their Lean effort or have different roles altogether.

Kaizen Events

Process improvements can be made more quickly if a concerted effort can be dedicated to improvement projects. Allowing team members 2–5 days away from their day-to-day jobs allows focused effort on a project that might otherwise take months, if it could ever be accomplished at all. These focused events are often called kaizen events. Of course, this places a burden on a company or organization who must either find replacement personnel or have somehow worked ahead to relieve the burden of day-to-day deliverables. In manufacturing operations, production areas must be shut down when a kaizen event focuses on rearranging production flow through a work area. Alternately, these projects can be pursued in periods of slack demand or activity.

Some examples of activities addressed during kaizen events are the following:

1. Constructing a value stream map
2. Reducing changeover time
3. Improving work area design
4. Implementing 5S
5. Designing a kanban replenishment system

Notice that the first item on the list can be distinguished from the remaining items on the list in that it involves the highest level tool within Lean, which is the value stream map, whereas the other topics are lower level tools in a sense that will be made clear shortly.

The creation of a value stream map results in an understanding of the current state of the process, as well as its deficiencies. Thus the result of value stream mapping is the identification of waste and its causes, and a typical deliverable from a value stream mapping kaizen event is a list of places in the process where waste exists and the Lean tools that can be applied to reduce those sources of waste. That list would typically be prioritized in terms of which sources of waste have the greatest impact on lead time and the other metrics for the project. Alternately, opportunities for improvement might also be prioritized, putting those with the biggest bang for the buck at the top of the list—that is, priority would go to projects that returned the greatest improvement in metrics for the effort expended. The remaining four types of kaizen events listed would address the wastes that were identified in a value stream mapping kaizen event. Thus we call the value stream map a top-level Lean tool and the tools used in the other kaizen events lower level tools because their use follows from the creation of the value stream map.

Selecting the Right Projects

Companies with an active Lean program must decide which of the proposed projects will be supported because it is often the case that there are more candidate projects than can be sponsored by the company at any one time. Any company can support only a limited number of projects at one time because of the resources required to pursue them. Actually, even if the number of candidate projects is fewer than the number that can be supported, then the information in this chapter should still be used to make sure that all those candidate projects are important and the team has done adequate investigation and planning to make the success of the project likely.

The project charter contains information that can be used to make the judgment about which projects should be supported. Of course, if any project is not immediately supported, it can either be put in the queue for later implementation or, if the project charter is not yet satisfactory, the team can be directed to further develop their project proposal. In general, these criteria can be used to select the best project prospects:

1. Importance of the process to the overall organization
2. Importance of the project goals and metrics to the business
3. Magnitude of improvement possible
4. Feasibility and resource requirements of the project
5. How well the project has been planned and whether Lean is the appropriate improvement methodology

Of course, there may not be candidate projects that score highly in all these categories, and in that case, trade-offs among the criteria must be made. Feasibility of a project might have many connotations, but could be the following:

1. Will the parties involved cooperate?
2. Is data available for the project?
3. Are the required Lean tools the simplest ones to use or the most difficult and time-consuming?
4. Can a Lean expert see that this project is likely to end in successful improvements to the process?

One exception might be made to the criteria in the case of a company that is just embarking on a Lean program. In that case, early success is important to convince people in the organization that Lean is viable and to help train people in Lean. In that case, some companies early on in their Lean program focus on the feasibility of the project and whether it is likely to improve a process, regardless of how much it may improve. One aspect of projects to focus on here is which and how many Lean tools are likely to be required for a project, whether they are the simplest of the Lean tools, and whether the team members have already been trained in those tools.

Organizational Structure to Support Lean

This section describes a hierarchy of roles that medium-sized to large firms employ to support their Lean efforts, as displayed in Table 18. A successful company need not copy this managerial format exactly. However, even though all the positions described here might not be needed, the roles served by each might need to be served by someone. In smaller companies it may be appropriate to have fewer positions filled with people who play multiple roles.

If a company pursues too many projects at one time, it risks not meeting day-to-day deliverables because workers and managers on project teams are often relieved of day-to-day responsibilities to do their Lean project (see the description of kaizen events earlier in this chapter). In the interest of allocating the scarce human resources to pursue Lean projects, the steering committee is responsible for selecting which candidate projects offer the greatest potential improvement and the greatest probability that the potential improvements will be attained. The remaining roles of champion, project leader, and project facilitator were described earlier in this chapter when project charters were discussed.

Table 18. Roles in Lean

Roadblocks

Getting Out of Firefighting Mode

The typical mode of operation for many companies and organizations is manifest in the need to respond to a plethora of crises on a daily basis. (Does this describe where you work?) This is particularly true for organizations that have not yet defined their processes, standardized them, and used Lean to improve them. For these organizations, it is difficult to divert resources from the continual firefighting and crisis management to do a Lean project. This is possibly the biggest hurdle in getting started with Lean. Controlled, stable processes are needed to make people available to thoughtfully improve processes with Lean, but how does an organization attain process stability when it cannot ignore daily crises? Getting started is thus a difficult task, and the early going may be slow because it is difficult to dedicate resources to Lean.

Coping With Improved Worker Efficiency

Lean focuses on reducing lead time, and as we have discussed, many other metrics improve concurrently, one of which is worker efficiency. In other words, fewer worker hours are required after a Lean project to produce the same output. This creates another issue that often arises as Lean projects begin. If an organization’s business volume remains constant, then a company will have extra workers due to Lean. Several alternatives for dealing with this situation exist, including (a) increasing business volume to absorb the workers, (b) reducing the workforce level through attrition, and (c) laying off the excess workers. Of these three approaches, the best alternative is the first, where workers do not lose their jobs and management improves the company’s bottom line. Increasing business volume is not always easy to do, however, particularly in economic downturns. In that case, a company might resort to one of the other two alternatives. It might be obvious that the third option is rife with issues. We have argued that Lean is most effective when the lowest level of workers are involved in Lean projects. What happens when a team of workers completes a successful project and then the workforce is rewarded with layoffs? The answer to that rhetorical question is that you have most likely ended your Lean program and eliminated any sort of effort to improve processes. Even the second option can be met with cynicism from the workforce. For example, in the 1980s and 1990s GM formed a jobs bank by negotiation with the United Auto Workers, whereby workers whose jobs had been reduced due to efficiency improvements would be guaranteed a job. Redundant workers were removed from the work floor and put on other make-work projects until attrition opened up a spot for them back on the production floor. Conceived as an innovative solution to the second option, the jobs bank was not effective in gaining widespread worker support for productivity improvements due to the organizational climate and the relationship between the union and management. Thus the second alternative was difficult for GM to implement.

Telling the Truth About Performance

A necessary situation for Lean to be successful is that an organization must be able to admit that its operations are not as good as they could be. In other words, an organization must be honest in calculating and reporting its metrics. This practice may be difficult for some organizations, and there are a number of possible root causes for this. One root cause is when workers and management are penalized whenever metrics do not match up with expectations or mistakes are found. If workers are yelled at, chastised, disciplined, or otherwise penalized for mistakes, then a manager should not expect their metrics to reflect reality. Workers and supervision will find ways to avoid delivering bad news by doing things like taking quality measurements after inspection and repair or, where latitude exists, defining a metric in the most favorable way possible. In organizations like this, the picture communicated to management grows increasingly rosy as it percolates to the top of the organization. Management, consequently, is pleased with the metrics reported while the bottom line performance of the company (such as profit) languishes. Conversely, Lean only succeeds when all errors, inefficiencies, and shortcomings can be acknowledged. If you do not know you have a problem, then you will not be able to fix it. In order for an organization to be honest with itself and measure its performance accurately, the culture must be one where shortcomings can be safely reported and not immediately penalized. It is important to remember Deming’s philosophy that 85% of errors are due not to lazy workers but to faulty processes, which are predominantly management’s responsibility. If one subscribes to this philosophy, then workers should not immediately be blamed for mistakes, but rather the mistakes should be taken as indications of a less-than-perfect process. Furthermore, the most stringent metrics—that is, those that reveal the greatest number of improvement possibilities—will result in the greatest improvement and should be used. So rather than glossing over errors and inefficiencies, an organization should want to reveal as many issues as possible.