Chapter 7

Project Management for a Lean Project Using DMAIC

DMAIC really made its appearance in the manufacturing environment representing a merger of sorts between Six Sigma at Motorola and Lean at Toyota. Today, the combination of the two merged into one approach commonly referred to as Lean Six Sigma. DMAIC capitalizes on this merger to enable projects to improve process performance for the customer.

7.1 Basics of DMAIC and Project Management

DMAIC consists of six stages:

D in DMAIC stands for define, which involves determining the problem or issue to address, building a business case and plan, as well as establishing an infrastructure for a project; the goals are to determine clearly what the customer wants, and preparing to manage and lead the project.

M stands for measure, which entails determining in greater detail the requirements: mapping the current process, collecting data, identifying critical inputs and outputs affecting the quality of the output, and pinpointing variations to performance. The goal is to generate a baseline for use in deriving improvements to address in a later phase.

A stands for analyze, which entails delving into data and process details to ascertain the cause or causes of problems and the degree of relationship between inputs to a process and the corresponding outputs; the goals are to acquire a greater understanding of the existing process and to determine the one or more root causes contributing to the problem or issue to address.

I stands for improve and involves identifying recommendations for improvement, selecting the most appropriate solution for reducing variation, and optimizing the process in question; the goals are to formulate a solution that solves the problem or issue the customer needs addressed.

C stands for control, and it entails ensuring that the newly revised process performs as expected and, if not, exercise contingencies if the process falls outside an expected range of variation; the goal is to apply ways to monitor process performance and to address any variation in the revised process.

Leading and all the project management processes apply to a Lean project using DMAIC. See Figure 7.1. They all apply to the entire project and within each stage. At the overall project level the processes have a broad perspective. For example, a charter and high-level plans contain content at a summary or strategic perspective. At the stage level, the processes may amplify in greater detail the applicable content at the overall project level or, if necessary, be modified for the particular context in which a stage finds itself.

7.2 Goal

The ultimate goal of DMAIC is essentially the same as if applying the PDCA cycle: to satisfy the customer. The way to achieve that goal is to resolve a problem or issue to satisfy or delight a customer by removing waste that will increase efficiency, enhance effectiveness, and improve overall organizational performance on a continual, sustainable basis.

To achieve this goal, project management (PM) plays an instrumental role. The very same PM processes are just as relevant for DMAIC projects. Generally, projects using DMAIC, as opposed to PDCA, require a more in-depth application of the PM process because of the complexity and breadth of these projects. Regardless, however, the goals remain the same for DMAIC projects as they do for those using PDCA.

7.3 Benefits

Using DMAIC offers several benefits.

Emphasizes the quantitative over the qualitative. DMAIC places great stress on using numbers, rather than qualitative factors to understand a current process. This does not mean that the quantitative approach is more important than the qualitative. It simply means that the stress is on coming up with numerical data to understand what contributes to the problem or issue and how well the revised process will meet customer requirements. In other words, facts and data are absolutely critical for applying DMAIC. Largely, DMAIC requires subscribing to the old adage that what is measurable gets attention. This emphasis on the quantitative also serves as a more effective way to test assumptions and offset biases that interfere with coming up with meaningful recommendations. Facts and data can rarely be challenged other than in the way they were collected and interpreted.

Requires considerable rigor in the approach. For projects using DMAIC, the opportunity to skip over phases has a direct impact on the quality of the output of a project. If any phase is skipped, then the results in subsequent phases become quite apparent. The deliverables for the previous phase depend on the quality and existence of those from its predecessor, because the results calculated from one phase are used to compare with those of subsequent phases. For example, the calculated results about an existing process are compared to the ones from the improved process to ascertain if the latter actually resulted in changes increasing customer satisfaction. This rigor must occur, both on the technical and PM levels. Generally, the degree of PM also requires greater rigor in application. This greater application of PM processes not only occurs for the overall project but also for managing within each phase. Project managers are responsible for managing the work and leading the team to accomplish the goals and objectives identified in the project charter. They must coordinate with a large number and variety of stakeholders.

Stresses the importance of pinpointing the root cause. One of the significant efforts using DMAIC is to determine the critical elements causing the outputs of a process. Not all inputs in a process are equal when it comes to producing results. To make meaningful recommendations that result in effective change requires knowing the critical drivers, making the necessary changes to them, and coming up with expected results, that is, ones satisfying the customer. The goal here is to identify one or more meaningful improvements in a process rather than applying a Band-Aid that temporarily ameliorates the problem or issue. To a large extent, DMAIC reflects the scientific method whereby a hypothesis is formulated, a test is conducted, and the results studied to ascertain if expectations have been met. The fundamental difference is that, under DMAIC, one is conducting two tests: one for the baseline process to establish a standard and the other for a revised process to ascertain the effectiveness of a change. Then, if effective, the revised process is implemented and monitored. By addressing the root cause, therefore, change becomes meaningful and lasting unless significant variation occurs once again due to changing circumstances.

Places great value on definition. This definition comes at two levels. The first level is on defining the scope. From a project standpoint and from a Lean perspective, knowing the scope enables not only building a useful plan, it also enables focusing on efforts to collect data, identifying areas to study, and formulating meaningful recommendations. Too broad a scope causes waste in terms of applying resources and energies; too narrow a focus and the result may not provide any meaningful value to a customer. Defining the scope allows for meaningful technical analysis as well as applying PM effectively. The other level is operationalizing terms, such as speedy delivery or increasing customer satisfaction. All terminology requires sufficient tangible definitions that lend themselves to collecting data and conducting tests. By operationalizing, or defining, terms people can then better identify the “vital few” inputs and the resulting outputs rather than rely on assumptions that people view a term the same way. When testing occurs, it becomes easier to ascertain what inputs contribute to specific outputs and ascertain whether an improvement has met key performance expectations.

Puts the customer at the forefront. One of the great contributions of Lean is that improvement efforts focus on one strategic entity, namely the customer. The needs and wants of the customer become the reason for a process; anything in the process that fails to add value (short of some restrictions) to the customer is non-value-added. DMAIC requires that the needs and wants of the customer be the focus of a project. This focus on the needs and wants includes their identification, prioritization, and contribution to a process. The Lean project, applying the concept known as the voice of the customer (VOC), puts the customer at the forefront. VOC requires making every effort to understand the satisfiers and delighters of the customer; any shortcomings bothering them; their expectations surrounding quality, cost, and schedule; and then verifying and validating requirements. The customer is at the center of attention for a Lean project using DMAIC throughout the entire life cycle of the project. For example, it enables better scoping as well as generating a meaningful problem or opportunity statement. These requirements can then be applied to the product or service being delivered to ascertain which features or functions to improve, based upon the expectations of the customer.

Derives the solution, not imposes it. On many projects, the solution is dictated from higher-level management or by another organization. For Lean projects applying DMAIC, the opposite occurs. A solution arises based upon previous work performed in earlier phases. Understanding the current situation, knowing the needs of the customer, collecting data about the status quo, analyzing the information, developing solutions and selecting one, and testing it prior to implementation offer many additional benefits. There is greater buy-in and justification for a change, there is a solution that has been proven to work, and there is the solution that addresses one or more causes of a problem or issue. In other words, this approach helps to avoid an old saying, “Forcing a square peg in a round hole.” If a solution arises that is a poor fit, it may in the long run create greater problems than what it was meant to address and will, more than likely, affect customer satisfaction.

Verifies and validates results. The power of measurement that DMAIC requires helps to determine whether technical standards and customer requirements have been met. Verification in this context is determining whether specific technical requirements have been met; validation is whether customer requirements have been met. In some circumstances, both may be in alignment with each other. In other circumstances, they may not. With meaningful measures using reliable data, verification and validation are possible with little or no threat of bias affecting perception. Without good measures and reliable data, verification and validation become a subjective assessment by key stakeholders. As with a camera, the information generated from the data using carefully designed metrics never lies. All too often, when metrics and data are missing or tarnished in some way, validation and assessment often reflect the opinion of certain stakeholders who, by virtue of their power or position, may necessarily not represent reality. Well-designed metrics can help offset this situation.

Combines data reliability and process efficiency. The use of the DMAIC life cycle depends on data. These data must be reliable, meaning free from inaccuracies, bias, duplication, and other threats to their validity. Process efficiency is how well a process executes its purpose with little or no waste. Data allow us to make that determination and also to formulate recommendations, such as reduced cycle time, that will satisfy the customer. In other words, data are used to assess how efficiently a process is working. The data, too, work hand in hand with effectiveness, meaning that the process achieves the goals and objectives of the customer. It becomes clear that data are akin to the blood cells that circulate through the body, analogous to a process. If the blood, or in this case, data, are tainted, they act like a poison, making it difficult to verify and validate behavior or performance. Therefore, it is imperative to understand the symbiotic relationship that binds data and process together when evaluating the latter’s efficiency and effectiveness.

Asks the right questions before coming up with the right answer. This one is related to the other benefit: derive the solution, not impose it. One of the cardinal rules of problem resolution, in addition to listening, that is often violated is a failure to ask the right question or questions before developing a solution. Too often, just the opposite occurs; people come up with a solution before really understanding what the problem or issue is. The 1980s and 1990s philosophy of shoot first and aim later generated disasters in information technology; some organizations received technological solutions that failed to solve their problems or issues. DMAIC requires going into a serious review of the current process, identifying the real cause or causes, developing recommendations that will address problems or issues, and finally monitoring the effectiveness of the chosen recommendation. The chain that flows from the right questions down to the right answer has a direct link.

Monitors process performance. In theory, projects, by their very nature, deliver the product or service to the customer and end. The product or service moves, for example, into “sustaining and operations” as is often the case with information technology. Lean projects, using DMAIC, usually at least address the delivery of a product or service by providing metrics to assess first the effectiveness and efficiency of the revised process, and then to make any changes before deployment. Most of the metrics deal with detecting the degree of variance that occurs during the execution of a revised process. The point is DMAIC, particularly in the control phase, emphasizes monitoring performance once the product or service has been delivered. This monitoring enables keeping tabs on how well improvements are meeting the customer’s expectations. Of course, the key to successful monitoring is collecting reliable facts and data to generate useful information.

Identifies what is and is not critical. The DMAIC cycle stresses the importance of identifying the critical elements of a process to make meaningful process changes. Special emphasis is on identifying the most important drivers for the outputs produced by a system. This identification is based upon collecting data and testing. Armed with those data and information, improvements can be made by altering the inputs and then comparing the results from the baseline and the revised process. There are three fundamental critical areas that are considered on a Lean project using DMAIC. Critical-to-quality (CTQ) consists of those requirements that relate to important functional outputs, critical-to-schedule (CTS) relates to timely delivery requirements, and critical-to-cost (CTC) relates to financial requirements. Knowing these and other critical requirements helps to determine what measures to establish to conduct a comparison between the baseline process and the revised one. Remember, one size does not fit all using DMAIC; the key is to use data collection and calculations to improve what are deemed important in a process.

Uses proven tools. This one applies whether using the PDCA cycle or DMAIC life cycle. However, it is especially emphasized when using DMAIC. Extensive data collection and information generation necessitate using a wide array of statistical methods and tools. In each stage of DMAIC, these methods and tools play a vital role for understanding, analyzing, and revising the baseline process to determine, validate, and verify the exact cause of a problem or issue and to then display that information in one or more ways, such as in a Pareto chart or trend chart. The same applies when coming up with a recommendation, making changes, and then verifying and validating results to ensure effectiveness in satisfying the customer’s needs.

7.4 Challenges

Despite all the above benefits, DMAIC presents several challenges to project managers. Some of these challenges also apply to the PDCA cycle. The only difference is they are often more acute in the DMAIC life cycle.

Obtaining data and information. This challenge is very difficult to surmount in some organizations where data and information are power. In these organizations, provisioning data and information can become a bargaining chip in negotiating for goals and objectives to achieve on a project. It can also be quite challenging when a downturn in the economy occurs and people begin to lose their jobs. Under such circumstances, protection and preservation become prevalent values. Much more than projects using the PDCA cycle, projects using DMAIC need hard data to perform statistical calculations to create a baseline of the current process, analyze the results, identify improvements, and determine their effectiveness. Data and information, therefore, are the lifeblood of these Lean projects. Any major restriction of access to data and information can affect change. This challenge can become augmented when proprietary data and information require sharing among not only employees but also contractors and consultants. To deal with this challenge, project managers need to know the organization’s policies and procedures on accessing and sharing information. They may also need to solicit support from high-level management to grant their team this access. It is not uncommon on such projects to have team members sign a nondisclosure agreement before accessing and sharing of information can occur. As mentioned earlier, one of the keys to a successful Lean project is to entrust stakeholders with the data and information to help them succeed.

Narrowing down what is critical. There are two parts to this one. The first one deals with scoping. Scoping the process related to a problem or issue pinpoints the goals and objectives covered on a project and allows for developing meaningful tangible recommendations. The other part is using the scope to determine what the priorities for the project are. The term “vital few” is often used to describe those elements within a process deemed important to affect outputs. The idea is that by modifying the important inputs, improvements are identified and tested for anticipated results. These inputs can relate, for example, to cost, requirements, and time. With the scope narrowed, determining critical elements becomes less ambiguous, more recognizable, and tangible. Project managers have some important tools and techniques, of course, to manage this challenge. These tools and techniques include a project charter, a statement of work, and a work breakdown structure, as well as developing and implementing change management disciplines. They can also develop a table or matrix to reflect priorities assigned to requirements.

Overcoming resistance to change. With any change usually comes resistance. Some people will resist any improvement that does not further their interests. An improvement may be viewed as a threat, for example, to their position, power, or esteem. Sometimes this resistance is easy to foretell; sometimes it is not, because the resistance may not be obvious. Instead, it often manifests itself in subtle ways, such as political resistance, or through overt behavior, such as terminating support for a project just before completing one of the DMAIC stages. Project managers have several ways to address resistance to change. They can perform a stakeholder analysis, which will help them determine who has an interest, pro or con, in the outcome of their projects. They can form a core team of individuals consisting of representatives from various disciplines and organizations involved with the process. They can invite representatives from the different stakeholders to participate in performing the actual work. They can keep everyone informed according to the contents of a communication plan. They can continually communicate and coordinate with an executive steering committee for review of major activities and deliverables.

Defining the problem or issue. It is an axiom in systems analysis that 50% or more of solving a problem or issue is to know exactly what it is. In many cultures, especially those in the West, the emphasis is on coming up with a solution first; in the East, it is coming up with the question before determining the problem or issue. The latter makes good sense but the temptation is to go for the former. The only problem with determining the solution before really understanding or defining the problem or issue is that it may be the wrong solution and may actually worsen the problem or issue later. To a large extent, the reason for coming up with a solution first is that, in a world of fast delivery, not much time is available to define exactly the problem or issue. The result is often patchwork that never really addresses the problem or issue. Lean, especially when applying DMAIC, delays formulating a solution by first emphasizing the need to define a problem or issue. However, even using DMAIC is no guarantee, because immense pressure is placed on stakeholders to push the Lean project along as quickly as possible to focus on productivity and, ironically, reduce overhead costs (which is the purpose of Lean in the first place). Project managers must be assertive when dealing with this challenge. They need to insist that people follow all the stages of DMAIC and do so in a way that does not subvert the purpose of one of its stages. Project managers also have the ability to meet with their sponsor, steering committee, or customer to obtain agreement on what the exact problem or issue is and then to ensure that it is documented and signed off in the project charter, statement of work, or both. Any expansion of the problem or issue can also go before a change board for review and determination of whether any request or proposed action goes beyond the original definition of the problem or issue.

Abandoning biases and unfounded assumptions. On any project, biases and assumptions will exist and are often assumed as fact until proven otherwise. Even in the face of data and alternative facts, however, some people still adhere to biases and assumptions. Some people find it very difficult to shed their biases and assumptions due to their own paradigm, or view of how the world works. In fact, these biases and assumptions can be so strong that they can enable a person to foolishly ignore contrary facts and data; this phenomenon can occur on individual or group levels. Such rigid adherence to biases and assumptions can cause stakeholders to overlook viable recommendations to improve a process, or can result in adopting a recommendation that results in a greater problem. Project managers have at their disposal many ways to address this problem. They can bring on board outside stakeholders, such as consultants, to challenge biases and assumptions, adopt techniques such as brainstorming and the Delphi technique, perform benchmarking, review lessons learned of projects of a similar nature, conduct lessons learned, and occasionally change the membership of their team to offset the psychological and sociological pressures to conform.

Finding qualified and knowledgeable people. When the economy is bad, this challenge is usually not a problem. When the economy gets better and expands, it becomes a significant problem. Improving a process in a technological environment often involves many people with unique skill sets and backgrounds, both at a strategic and operational level. On Lean projects employing DMAIC, these people require certain unique skill sets. For example, these projects require some people to be Master Black Belts or Black Belts whereas others are known as Green Belts. Master Black Belts are people who have considerable experience in Lean Six Sigma and often support one or more Lean projects. Black Belts provide full-time support to a project and have some of the many skills and background of the Master Black Belt. The Green Belts are people who provide part-time support to a Lean project in the form of a specific expertise. Master Black Belts and Black Belts are project managers, the former being more of a coach or consultant. Both are knowledgeable in Lean Six Sigma and PM. One other group of people yet to be mentioned is the champions. These are usually senior people in an organization who embrace and further the mindset of Lean and ensure that the relevant tools and techniques are employed on projects. Champions are usually members of an oversight team, such as a steering committee, at different levels of an organization. One of their principal roles is to ensure that all Lean projects are successful by providing the necessary guidance and support. To increase the probability for success, project managers need to ensure that they, and the other stakeholders, have this top-level support. The support may be tangible, such as financial backing for the project, or intangible, such as providing the political muscle to overcome resistance. Project managers have the project charter, tool gates (also referred to as check points or gate reviews), and approval of deliverables. Above all, project managers, in this case Master Black Belts and Black Belts, need champions to provide them with Green Belt support.

Giving people sufficient time to support the project. This one is significant in organizations having a matrix structure, meaning people come from a functional organization and support multiple projects. The matrix structure offers several advantages, including making people with rare skills available and flexible in assignments; however, it can also be very difficult on people, such as working extensive overtime, having conflicting priorities, and supporting, although not formally, multiple superiors as well as projects. For Black Belt project managers this situation is not as acute because they support, in theory, only one project. For people who serve in a Green Belt role, they can find themselves stretched thin in terms of the support provided to more than one Lean project. If not managed correctly, the gains of working in a matrix environment can be offset by the negative consequences. Project managers of Lean projects using DMAIC can find that the matrix environment can extend their schedules, cost more, and deteriorate the quality of output. Nevertheless, project managers have several tools and techniques to offset this challenge. They can ask the steering committee and the sponsor to set priorities among projects that may have been done already if portfolio management has been implemented. They can perform leveling and smoothing to ensure that resources reflect resource constraints. They can appeal to a change board or steering committee to reduce the scope. They can outsource some work. They can negotiate with functional managers and other project managers to determine the availability of people to support the project.

Transferring to operations. Once the Lean project using DMAIC comes up with a recommendation and implements it, a time period will exist that still requires the people to adjust to a revised process. Even when a revised process makes sense, many people have a difficult time changing their perspectives and their ways of doing business. Because a Lean project does not necessarily involve all the stakeholders affected by a change, especially in large organizations, this adjustment period will take some time and will be difficult. Project managers of Lean projects using DMAIC, of course, have some control over this during the control stage and can help smooth the transition through training, producing procedures, and establishing metrics to populate a dashboard. Project managers can also keep the affected people of a process apprised of the progress to date by distributing information as defined in the communications plan. Finally, they can incorporate the training of people in the schedule prior to deploying the revised process on a full scale.

Inculcating accountability. Process improvement, especially for processes that span multiple organizations, can involve a large number of stakeholders. Some stakeholders have a greater impact than others. The challenge is to determine which stakeholders have a more significant role and to ensure that they produce according to expectations. It is not uncommon for people, especially in large organizations, to attend project meetings simply out of interest and sit on the sidelines and then take credit if the results are successful. Project managers need to ensure that such people are identified, do not interfere on their projects, and avoid incurring needless costs. They can handle this challenge in several ways. They can perform a stakeholder analysis to ascertain which ones have a salient interest in the project; identify roles, responsibilities, and authorities; assign people to specific activities; and publish a communications plan that restricts who attends specific meetings and receives specific information. Nothing can impede performance more than having people involved who have no accountability in a project’s outcome.

Resolving differences. Lean projects, because of their often cross-functional nature, may involve many different people. They involve people at all levels of an organization, from the strategic to the operational. They involve people from different disciplines. They even involve people with different psychological profiles, for example, thinking styles. Projects using the DMAIC life cycle especially use a diverse group of people. Naturally, this situation lays the groundwork for conflict. Conflicts can be positive, and often are, but they can also be negative. If not handled appropriately, conflicts can hurt the overall performance of the projects. In the middle of all conflicts is one person who must bridge the gap: the project manager. This person is really the only one who interacts with everyone to a certain degree and this provides him or her with the opportunity to see all perspectives. If handled correctly, conflict can become the springboard for moving a project forward. If handled poorly, it can stop a project dead, and, under certain circumstances, the project manager receives the blame. Project managers have several tools and techniques to help them deal with conflict. They can always appeal to the steering committee or project sponsor to deal with the conflict, but that is often perceived as being weak and ineffective. They can take the initiative by taking other courses of action, including having a well-written statement of work and requirements document, having people participate in developing the work breakdown structure and schedule that will cause conflict to come out in the open early on, establishing rules for meetings that include agreed-upon approaches to resolve conflict, and performing a risk assessment early on to raise potential areas where conflict can result if a risk is realized.

Following the stages. Lean projects using DMAIC require discipline when adhering to its stages and in their sequence. As with most projects, a tendency exists to cut corners, especially if a project starts to fall behind schedule, exceeds cost estimates, or people feel like they are no longer enjoying the experience for a multitude of reasons. Under such circumstances, it is not uncommon for people to pursue the line of least resistance by short-changing DMAIC activities. The consequences are that the recommendation implemented does not satisfactorily address the problem or issue, which ultimately fails to satisfy the customer. Project managers can manage this challenge by placing a work breakdown structure under configuration management and requiring any changes to go through change control. They can incorporate gate reviews or tollgates in the schedule. They can require peer reviews of output produced by key stakeholders to ensure that the right statistical method or tool is being used. They can also cross-check all output of each stage to ensure consistency with what was produced in a previous stage.

Lacking understanding and knowledge about DMAIC. Not everyone on a project will have a Black Belt or even have experience with Lean or Six Sigma. If fact, chances are that most of the people will lack knowledge and understanding of the topics. Chances will also exist that some stakeholders will think they are experts on these subjects even without any experience or substantive understanding or knowledge. Under such conditions, miscommunication and misunderstandings can be prevalent, resulting in negative conflict that can further result in an impasse in moving a project forward. Project managers have several options to address this challenge. For example, they can have all stakeholders attend an introductory seminar or workshop on Lean Six Sigma or one focused on DMAIC. They can send only certain members of the team who, in turn, train the other stakeholders; this approach is often referred to as cascade training. They can provide alternative resources of information such as online training sites. They can have the Master Black Belt provide the necessary training at the worksite. The key is to have training that is relevant to the stakeholders so they can participate meaningfully on a project. The training may provide a general overview, for instance, for part-time stakeholders, or it could cover specific statistical techniques.

Selecting the right candidate projects. Just about every process or operation within an organization can benefit from using DMAIC. However, there is only a finite amount of resources, from time to energy, that can be devoted to Lean. An organization still has to carry out its current mission, goals, and objectives. It is important, therefore, to select the right project or projects to improve a process using DMAIC. If the project is the first Lean project and a candidate to use DMAIC, the process being improved should not be overly complex nor should it be too simple. The process should have enough impact on the bottom line so people can see and appreciate the difference between the old and new way of doing business. It should have enough complexity to cause people to stretch and certainly give them enough time to increase their understanding and knowledge of Lean and the process to revise. As in any project selection, the goal is to choose a project that can demonstrate value to the customer while simultaneously allowing people to master new knowledge and skills. Building upon one successful project after another is the quickest way to encourage additional Lean projects in the future, each with increasing scope and complexity. Project managers usually receive projects after an executive committee, such as a steering committee, reviews and approves a list of projects. They can also review the lessons learned of previous projects of a similar nature, to see if any potential projects can evolve from that information.

Focusing on the short term. It is hoped that using DMAIC will help overcome this challenge. DMAIC requires identifying the source of a problem or issue by rigorously identifying and examining facts and data. If the team and other key stakeholders truly want to address the root cause or causes, they must not only proceed sequentially from one stage to another but also execute each one diligently. In today’s environment, the pressure is to move with velocity, that is, speed and direction. Some of the work required to perform a Lean project using DMAIC takes considerable time and effort. Not surprisingly, some people may succumb to this pressure and gloss over some necessary work. The consequence is that a team may be recommending a fix rather than a lasting change. Project managers must encourage key stakeholders to take and maintain a strategic view of their projects. They should continuously remind all stakeholders of the vision, goals, and objectives of their projects that are, one hopes, captured in the project charter and statements of work; they can do that by displaying the vision, goals, and objectives at the beginning of each meeting, such as status review meetings, at kaizen workshops, or any other team meeting, for that matter. They should develop the work breakdown structures predicated on the information in a project charter, statement of work, and the requirements documentation. They can then use the elements in the work breakdown structure to build plans that ensure work is not glossed over simply to succumb to pressure to just “get it done.” Yielding to such pressure only breeds mediocre results, at best, and may actually lead to greater customer dissatisfaction.

Creating a sense of urgency. This challenge may seem like a contradiction from focusing on the short term. However, this one deals with a different context. The concern here is that some stakeholders may view a Lean project using the DMAIC as an additional workload to address, if time permits. This perception can have dire consequences for a Lean project. For one, people will tend to view the project as having a lower priority than other responsibilities and, therefore, fail to give it their attention; people in operations or production often subscribe to this view. It then becomes a considerable challenge for the project manager to coordinate activities or to set up necessary meetings at a time that accommodates the needs of the project and those of individual stakeholders. Consequently, the flow time of the project tends to expand farther than necessary, and the project manager faces a serious obstacle in keeping people motivated and engaged. Fortunately, project managers have some ways to deal with this problem: they can emphasize the need to meet specific milestones as determined by executive leadership. They can have participants perform many planning activities that affect them, such as determining the percentage of their time working on an activity or the number of time units to work on, or the start and finish dates for each one. By encouraging participation in planning, project managers can increase the likelihood that stakeholders will get a greater sense of ownership and commitment to complete their responsibilities. As plans come to completion, project managers can give as much visibility as possible to progress, to include the names of persons responsible to complete upcoming activities. The intranet places considerable power in the hands of project managers in this regard. Another technique to create a sense of urgency is presenting only the current start and finish dates and not the two sets of early and late dates and positive total float. If people know that they have time to slide an activity they will likely do so up to the time available for its completion. Project managers can also shorten the calendar time between status collection and review sessions. Finally, they can, as a last resort, conduct daily stand-up sessions. During these sessions, each stakeholder with current and immediately forthcoming responsibilities on the team briefly discusses for one or two minutes what he accomplished the previous day and what he expects to do during the current day. He may mention any problems experienced but the session is not the time and place to problem solve.

Achieving simplicity. One of the biggest ironies of Lean projects using DMAIC is that the pursuit of eliminating waste through simplification can result in people making things way too complex. Many stakeholders start finding themselves getting tangled up in the details, sometimes forgetting that the whole purpose is to remove complexity in a process. For instance, some stakeholders find it very difficult to think at a higher strategic level because they treat all details as equal. Some individuals start to squabble over those details and more time is spent trying to formulate a compromise than coming up with a simplified solution. Or some people get so involved in the calculations that precision becomes more important than looking for patterns of behavior in a process. The key, of course, is having a strategic perspective in alignment with the collection of details in a way that produces a simplified recommendation. At some point, more charts, calculations, and data oftentimes reach a threshold and their value diminishes and only adds confusion. Project managers have several options at their disposal to deal with this circumstance. They can conduct peer reviews of the work done by colleagues. They can, with input from the team, set standards for deliverables. They can limit the time available to complete certain activities. They can select team members who, when combined, reflect many different mental models, thereby offsetting the tendency of groupthink or people with a certain mental model commandeering the project.

Defining terminology. In a multidisciplinary environment, such as a manufacturing one, jargon can become commonplace. For example, one group of people thinks a term means something when another interprets it differently. In the beginning of a Lean project using DMAIC, people start using terminology, such as a customer and satisfaction (or customer satisfaction), thinking that everyone has the same meaning or connotation for the terms. As the project progresses, it soon becomes apparent that some people have a different interpretation of just what these terms mean. This situation can result in considerable rework as the project progresses from one stage to another, all because of misinterpreting terminology. It can also result in negative conflict among stakeholders, thanks in large part to miscommunication and misinterpretation. It is very important, therefore, for project managers to operationalize, or define, terminology on these projects up front to minimize problems. One of the most important deliverables for such projects is to produce a common glossary that people can reference during analysis and formulating recommendations.

Obtaining customer feedback. Another irony of Lean projects in general and ones using DMAIC is the tendency to lose focus on the customer. Some people become enamored more with the tools and techniques of Lean Six Sigma, for example, forgetting about focusing on the interests of the customer. Unless the customer participates in each of the stages of DMAIC, this tendency begins to manifest itself more and more. This lack of customer focus can cause a loss of feedback. Of course, both could share responsibilities in this circumstance. The customer can contribute to this failure by sending liaisons to the project who really don’t understand its needs. It may also not provide the time or data needed to perform a meaningful analysis or to formulate value-added recommendations. The fault, in other words, can be the result of the behavior by the project team or the customer. Project managers can surmount this problem by preparing a communications plan that encourages customer input and feedback. They can also engage customers in the planning of the project by assigning activities in the schedule. They can hold periodic meetings with the customer to obtain feedback; they can have customers attend status review meetings.

Ensuring visibility of performance. Some stakeholders like to operate “under the radar.” In other words, they do not want any visibility of the work performed unless, of course, it has a very positive outcome. Not surprisingly, some stakeholders, therefore, are very reticent and hesitant in providing any status or communicating what they’ve done on a Lean project. They may not want visibility for many reasons. They may just prefer to work in the background. They may fear reprisal for not performing according to expectations. They may not want to associate themselves with the project directly in any way. They may not agree with participating on a project but have been told to do so. Whatever the reason, some stakeholders want to keep visibility to a minimum. The consequences are many, including an inability to collect and evaluate status for members of a project and other stakeholders, such as the project sponsor and steering committee. Project managers, when dealing with stakeholders who eschew visibility, must be assertive in the relationships. They have various ways to deal with this challenge. They can set up standards to report status, create a dashboard that lists stakeholders not cooperating in this regard, have reluctant stakeholders participate directly at status review meetings, and, ultimately, raise the issue to the project sponsor or the steering committee. Some negative approaches include sending out an email that lists the stakeholders who have provided status and who have not, taking advantage of peer pressure. They can also contact the superior of the stakeholder not providing status. The key is project managers asserting themselves in collecting information that they need to assess performance and to provide the necessary visibility to key stakeholders.

7.5 Case Study

Phoenix Plane Parts Aerospace, Inc., known as P3A, is a major supplier of airplane components to the airline manufacturer Starlight Aerospace, Inc. (SA) in Denver, Colorado. P3A specializes in assembling components for different business jets produced by SA. It is becoming a leader in assembling airplane components made of composite material, provided by its Tier 1 suppliers. P3A has three sole suppliers for myriad composite parts and then assembles them into larger components for shipment to different aerospace manufacturers, the primary one being SA. P3A has approximately 7,000 employees and generates revenues close to $12 billion a year.

The growth of P3A has been phenomenal over the last two years, thanks in large part to its lucrative contract with SA to provide a fully assembled empennage for its series of business jet models. P3A has tried to maintain a small shop, craftsman perspective, but its success in this regard has made it very difficult to adapt to this growth. Its current processes to assemble components have been costly in terms of money, reputation, and its relationships with both suppliers and its primary customer, SA. Despite dramatic growth in revenues, the operating costs have skyrocketed so high that the profit margin has been declining each year. Labor problems have also increased, thanks in part to management seeking to reduce costs using layoffs and pursuing greater offshoring opportunities. Stockholders, especially institutional investors, are also upset and placing pressure to increase stock performance and dividend payouts.

Not surprisingly, P3A has many problems, the least of which include

• Excess inventory buffers and work-in-progress (WIP)
• Excessive scrap quantities and costs
• Excessive transportation time and costs
• Extended lead times
• High defect rates
• High warranty costs
• Incomplete or inaccurate specifications to suppliers
• Inefficient flow processes
• Lack of visibility of performance metrics
• Large batch runs
• Late deliveries from suppliers
• Late deliveries to SA
• Long setup times
• Lost or misplaced parts
• Lost or misplaced tools
• Low employee morale
• Machine equipment breakdown
• Nonstandard information systems
• Part shortages
• Pilferage of parts
• Poor quality
• Reliance on inspection
• Safety and health issues and costs
• Strained management–worker relations
• Undocumented processes and procedures

Based upon the long list of problems and the impact on the company and its longevity, the president and chief executive officer (CEO) and the other members of the board of directors (BoD) decided that something had to reverse this situation or the company could dissolve in five to ten years, closing the factory gates for good. The BoD agreed to establish a steering committee that would guide and oversee a program to implement Lean principles adopting the DMAIC cycle throughout the factory.

The steering committee comprised senior vice presidents and directors from each of the following functions and support services:

• Engineering and mechanics
• Facilities
• Human resources
• Information services
• Legal
• Material management
• Procurement
• Production planning and control
• Publications
• Quality assurance and control
• Representative union leadership for engineers and machinists
• Safety
• Sales and marketing
• Shop maintenance
• Supplier management
• Tooling
• Training and development

Several of the vice presidents and directors have multiple functional responsibilities, thereby limiting the number of stakeholders to a manageable level of 10 people. The vice president of engineering, David Letrino, was appointed to lead the steering committee. After several weeks of painstaking work, the steering committee developed a five-year plan to adopt Lean throughout the factory as a way to do business. Five major projects were identified to enable this transition to occur. Major start and stop milestone dates were identified for each project. The first project the committee selected was for the final assembly of the empennage for SA Model X38, a medium-range business jet popular throughout Latin and South America. The committee titled the project “Lean Empennage Advancement Project” (LEAP).

LEAP was to serve as a pilot to ascertain the challenges, issues, problems, and lessons learned that would lay the basis for managing the other four projects.

The steering committee selected Rob Jacobsen, senior project manager from engineering, to lead LEAP. Having previous experience leading Lean projects with other companies and being a certified Black Belt, he became the prime candidate for this pilot. His previous experience as an aerospace engineer in the empennage section of a factory with still another company also added to his becoming a prime choice.

Cindy McMartin, vice president of quality assurance and control, was selected as the project sponsor. She was to serve as the champion for LEAP, having experience in leading change management initiatives as they relate to manufacturing processes.

The empennage assembly team, or EAT as it is affectionately called, is responsible for assembling the major components of the tail of an aircraft to enable stability in flight. It includes the horizontal stabilizer, rudder, and vertical stabilizer. Each of the components is assembled separately in what are called subassemblies and then assembled together, called final assembly, as an integrated component by EAT. The empennage is then shipped to an SA manufacturing facility in Colorado.

The first order of business for Rob was to meet Cindy to become more knowledgeable about the work performed by the steering committee. During the meeting, he was presented with information needed to begin his own planning for LEAP:

• Five-year strategic plan for the Lean initiative
• Expectations and budget for the pilot project
• Business case
• Core team member assignments
• Program charter

The core team consisted of members from the first shift line responsible for assembling the empennage prior to shipment to SA. The core team consisted of a team lead, applicable manufacturing and industrial engineers, machinists, assemblers, composite specialists, quality control inspectors, drivers, and riveters. These people support LEAP on a part-time basis and are the considered equivalent to Green Belts. On an ad hoc basis, selected individuals serving as liaisons from finance, publications, information technology, sales and marketing, procurement, materials, and supplier management also participated on the project on an ad hoc basis or scheduled basis.

The company had two empennage assembly lines, consisting of two shifts. The assembly lines were located in the middle of the factory and the subassemblies for the empennage were then transported by vehicle to the final assembly area. Each line had its own set of equipment and supplies; these included but were not limited to cranes, lifts, stands, carts, tooling, toolkits, cargo loaders, tugs, functional and electrical test equipment, scaffolding, and seal and paint booths.

Despite efforts to control the flow of parts for the empennage through scheduling, the inventory buffers at selected points near the final assembly area were getting increasingly stacked with parts on a “just-in-case” basis because suppliers often delivered late to the subassembly areas and the parts sometime fell short of quality standards. The time requirements to deliver a completed empennage assembly did not allow for flexibility of rework. The standard practice was to inspect parts coming in from suppliers, conduct a quality inspection on relatively short notice, and, if the product failed, it was hoped the buffer had the necessary part. Unfortunately, on many occasions the quality of some parts, even in the buffer inventories, did not meet the standards because, during transport to the subassembly or to the final assembly area for the empennage, they were damaged.

Rob then elected to arrange for the first of many team meetings with his core team. The first order of business was to review the output of the steering committee and his discussions with Cindy. This information provided the context for LEAP as well as guidance for managing and leading the project in the future.

Working as a team, they developed a project charter that aligned with the one for the overall program. All core team members participated in updating the draft that he had presented to Cindy for feedback. She had some minor changes before the steering committee members were to review the charter. A draft of the charter was then circulated among steering committee members, all granting their approval. Then, Rob presented the charter one more time to the core team members for final feedback. No one on the team requested any changes. Cindy and Rob signed the charter, and she submitted it to the steering committee for final signatures.

Rob then convened the team to begin developing an overall strategy to manage the project. He explained that LEAP had some unknowns inasmuch as this was the first Lean project for the company. He suggested, and the team consented, that with the exception of the first stage of the DMAIC milestone dates were set for each stage; as each preceding stage got closer to completion, the succeeding one would then be planned in detail. Hence, the define stage was planned in detail within the flow time allowed by the start and stop milestones identified in the charter. As the define stage approached the completion milestone, the measure stage of DMAIC was planned in detail. This approach was adopted because LEAP was the first Lean project and the magnitude and complexity of the work effort was unknown. The approach gave the team some flexibility to adjust its plans accordingly. The concept applied is known as rolling wave, whereby as more information is known, the more in depth the planning can be for the next phase or stage.

In addition, the team elected to include gates at the end of each stage. This approach would preclude erroneously moving LEAP into the next stage with a serious oversight or need to perform rework.

The core team then met in subsequent sessions to perform the organizing and planning PM processes for the project. Rob realized from previous experience that detailed planning done unilaterally rarely worked. The people who had to perform the work would likely not follow the plans too seriously unless they had a sense of ownership and commitment and the best way to achieve both was to have them participate in the development of the deliverables for each PM process for LEAP. For example, the core team provided input on establishing the infrastructure (e.g., organization chart, procedures, etc.), work breakdown structure, time and cost estimates (where possible at this point in time), risk assessment, network diagram, schedule, and so on. The entire package, at a summary level, was presented to Cindy who, in turn, with Rob presented the output at the next steering committee meeting. The steering committee recommended some minor changes and then granted its approval contingent upon those changes being made. All changes were made.

Rob then worked with other functional managers on the floor, for example, electrical engineering, and the administrative functions, for example, finance, to procure their support for the project, specifically for acquiring part-time team members to perform relevant activities in the schedule.

Then, Rob determined that a kickoff meeting for LEAP, with Cindy attending, was necessary. After some minor input to the work done to date, the kickoff meeting was held. The meeting included all core and part-time members. The chairman of the committee, David Letrino, spoke briefly, followed by Cindy. Rob then presented a high-level overview on the project’s background followed by a more extensive overview of the project infrastructure and plans. He also covered the next steps after giving everyone the opportunity to express comments, concerns, and insights. A scribe recorded all feedback during the session. If Rob, Cindy, or David could not answer a question or clarify something the request for feedback was recorded on an easel sheet titled a parking lot and one of the three promised (and did) get back to the pertinent person or persons requesting a response.

After the kickoff meeting, Rob, along with the core team, agreed to continue a two-day kaizen workshop that would compile and evaluate data and information related to the current process at the empennage assembly line.

Rob had a telephone conversation with the team leader of the empennage team who happened to note that no one from the customer or the suppliers was participating in LEAP. Rob was dumbfounded that such an oversight was not caught earlier by him or his core team, let alone the project sponsor or the steering committee. He knew that the team had to look at the entire supply chain for manufacturing, assembling, and delivering the empennage. He quickly made contact with some people responsible for interacting with both suppliers and the customer and was assured of their participation either through a P3A company liaison or representatives from suppliers and the customer. They, too, would attend the kaizen workshop and future ones and would be added to the project plans, where applicable.

Before the first kaizen workshop, Rob made every effort to ensure that rudimentary training on Lean was available, to include classroom and online training. The goal was not to make people experts on Lean or DMAIC but to have a common basic understanding and knowledge about the subject as well as being capable of communicating intelligently with each other, thereby reducing the opportunity for miscommunicating, poor coordination, and negative conflict.

He also conducted extensive preparations before the kaizen workshop. He collected relevant data and information as well as formulated a strategy for collecting the voice of the customer to acquire and clarify requirements that involved observations, interviews, documentation research, and data collection.

Cindy suggested that it would be a good idea to visit one of the suppliers’ factories and the customer prior to the kaizen workshop. The purposes would be to become more familiar with their way of doing business and also to learn more about their needs and requirements. David agreed with her; and Rob, along with some other core team members, went to the suppliers’ and customer’s locations. He felt that this was a good way to start capturing the VOC in a document discussing their observations, insights, comments, and the like for use during and after the kaizen workshop.

The kaizen workshop lasted two days at an offsite location during a slow period in production. The project team covered many topics that were listed in the agenda prior to the meeting and sent along with a reminder for people to come prepared with the requisite data and information. At the session, the team started off with a review of the vision, goals, and objectives of the program and the LEAP project; they developed a high-level current value stream of the empennage assembly process; applied data and information to the value stream; reviewed the schedule for the define stage; presented observations, insights, and comments as well as entertained questions about the gemba at the suppliers’ and customer’s locations; presented results from the VOC efforts prior to the workshop; and conducted a lessons learned session for the workshop.

After the workshop, Rob and a select number of core team members prepared a presentation on the results of the define stage. This presentation was for the steering committee and was reviewed by the project sponsor and the chairman of the committee before presenting it to the steering committee. The reason for this approach was to identify and prepare for any shortcomings, problems, objections, or concerns that could cause some complication during the session. Two days prior to the steering committee meeting, Rob sent the final draft to the steering committee members. During the meeting, the committee members expressed their approval for the work done by LEAP. They also used the session to conduct a gate review and granted approval to proceed to the measure stage.

Prior to the session with the steering committee, Rob collected status against the schedule baseline. He collected this status and held weekly status review sessions with the core team and others who attended the meetings. Occasionally, he took corrective action to ensure that the current schedule and costs aligned with each prior to the next status review session. At the status meetings, he always started off reviewing the vision, goals, and objectives of the project as well as the risk assessment, critical issues, minutes from the previous meeting, and any concerns expressed by the stakeholders between meetings. At the end of each meeting, he would conduct a round robin to solicit feedback, thoughts, insights, comments, questions, and so on from attendees and also reviewed the upcoming weekly activities for the project, commonly referred to as the one-week look-ahead. He made a special effort to keep the meeting within its allotted timeframe and rarely, if ever, deviated from the agenda.

All material for the project, to include status review data and documentation, was stored on a server that allowed all team members to access data and information generated by the project. For stakeholders with restricted access, such as suppliers and contractors, nonproprietary files were stored on an intranet site using collaborative software.

Toward the end of the define stage, the core team began planning in detail for the measure stage. By the time the steering committee met to review the output of the define stage, the team had a game plan already built. A subsequent meeting was held after the team conducted a lessons learned for the define stage. The project sponsor and the chairman of the steering committee reviewed the plan for the measure stage and then both Cindy and Rob presented it to the steering committee, which granted its approval to proceed.

Rob then conducted a kickoff meeting for the measure stage for the project. Attendees at the session included core team members and other selected stakeholders. Although important, this kickoff meeting mainly covered the work for the measure stage.

The purpose of the measure stage is to amplify the collection of data and information about the current process that was compiled and received in the define stage. Special effort was made to drill down into the current process and collect or verify additional data and information. The team, for instance, identified and collected more data and information about the satisfiers and delighters of the customer, to use Kano jargon. It also expanded on the current value stream to ascertain areas performing well that satisfied the customer and those that provided potential opportunities for improvement. This information was then used to determine the critical inputs to the process as well as the requirements, also known as the critical-to-quality requirements.

Also important to the success of this stage was having all the team members understand the terminology used on the project. Although important for the define stage, it becomes even more so for this one and the succeeding stages. Rob collaborated, therefore, with core team members and others to develop a common glossary of terms. He also collaborated with the team to achieve consensus over a set of statistical tools and techniques to use for collecting, displaying, and eventually analyzing results (which occurs in the analyze stage).

During this stage, it became apparent that the milestone date for completion would have to slide two weeks. The complexity and effort to measure the performance of the current process was taking longer than expected. This situation meant the milestone date specified in the charter would have to change, which required formal approval. Rob first convened with the core team to explore options before formally submitting a request to Cindy for initial review and final approval by a change board that consisted of her and selected stakeholders, some of whom were on the steering committee. The options were clear: either reduce the scope or change the schedule. Rob and the team favored changing the schedule after performing an impact analysis based upon assessing the impact on cost, schedule, and quality. Cindy agreed and had Rob submit a formal request to the change board, which approved it after performing its own evaluation of the impact on future projects and the overall Lean initiative for the company.

Rob then made adjustments to the schedule after consulting with team members who performed activities affected by the changes. He also continued the same approach on managing and leading this stage as he did for the define one. He collected status data and information, held weekly review meetings, revisited the risk assessment, and ensured ongoing communication occurred among stakeholders according to the communications management plan.

Toward the end of this stage, he prepared, with input from the team, a report on the findings and any emergent recommendations for improvement as well as conducted a lessons learned session with relevant stakeholders.

One of the unique features that he performed on the project was encouraging the use of peer reviews among team members as they went about collecting and compiling data and generating information. These peer reviews helped to check the quality of work of individuals to ascertain if the right statistical measures, techniques, or charts were used and to ensure all standards in the project procedures were followed. Rob, with the consensus of the core team, saw this approach as a way to improve quality of the output throughout this stage and, therefore, minimize the amount of rework at the end of the stage. In other words, quality was built into the process, not waiting for inspection to determine if rework was necessary.

After passing the gate review for the measure stage, the team reviewed the data and information along with the current value stream map to determine the critical inputs to the process, identified the most important causes for the problems and issues in the define stage, and conducted additional data collection and analysis to substantiate existing findings.

Throughout the phase, Rob kept the team focused on the vision, goals, and objectives for the project, the critical-to-quality requirements, and had the team follow the schedule. He also ensured that all PM tools and techniques adopted in the define and measure stages were applied according to the consensus of the team. Again, as this stage came to a conclusion, the team planned out the next stage, conducted a lessons learned, and produced a report on the results. And, once again, the project team received approval from the steering committee to move forward to the next stage, improve.

The improve stage was the most exciting part of the DMAIC for the team. It required using the output of the measure and analyze stages and coming up with potential solutions to reduce waste in the empennage process. After several brainstorming sessions, the team came up with a list of recommendations that addressed 80% of the problems and issues that were high priorities as identified by the VOC. The team’s recommendations were reflected in a future state value stream map along with expected standards of performance and accompanying metrics to detect significant variation when those recommendations were to be implemented. The recommendations were identified by priority using the prioritized list of problems, issues, and concerns from the VOC along with the associated corresponding benefits. Often these recommendations involved improvements that eliminated waste usually in one or more of these four areas: people, data, systems, and procedures.

Additionally, the team decided that first it would conduct a test of the future state on a much smaller scale before implementing the changes in the future value stream map. This pilot served as a way to determine the effectiveness of the recommendations shown in the future state value stream. The team decided to apply the recommendations to the vertical stabilizer subassembly process. This pilot was to help determine if the recommendations did improve performance and also to see if any unexpected problems might arise or if anything might be overlooked in the future value stream map.

The pilot proved to be a success. Some minor problems did occur but overall ended up as improvements, such as reducing inventories, improving setup times, speeding up cycle time, and decreasing the number of defective parts arriving at the assembly line. One of the significant recommendations embraced the concept of just-in-time delivery of some parts for the horizontal stabilizer. These parts mainly came from a supplier on the west coast of the United States. The supplier, having a representative on the team, had served as an effective stakeholder in communicating to his company the need to embrace JIT manufacturing and working closely with P3A. The production of these parts at the supplier’s location was now in tandem with the takt time of the manufacturing line of P3A which, in turn, was getting in sync with P3A’s customer, SA. The team also conducted a risk assessment to anticipate any of the problems that could arise during the pilot and, if they did occur, and some did, apply the appropriate response to ascertain its effectiveness. The risk assessment approach used was failure modes and effects analysis (FMEA).

The pilot proved successful with some minor glitches. Substantial improvements were realized in the subassembly process of the horizontal stabilizer. Rob conducted a lessons learned with the team and other stakeholders in the process. He also got with the team and prepared a detailed plan to manage and lead the control stage, the last one in the DMAIC cycle. He also produced a report on the results of the pilot that was presented to the project sponsor and the steering committee. After a review of the cost, schedule, and quality performance for the improve stage and the report, the steering committee granted its approval to proceed to the next and final stage, control.

The purpose of the control stage is to implement the improved process on a much grander scale, in this case the empennage assembly. Because two assembly lines existed, Rob with the consent of the project sponsor and the steering committee decided to implement the improved process on one of the assembly lines before doing so with the other. This strategy offered several advantages. It would minimize the complexity of transitioning the two large assembly lines at the same time. It would allow time to work out the bugs in the revised process and take whatever corrective action necessary. It would enable P3A to deliver to SA an empennage and not involve a total shutdown of the delivery of the product to the customer if a showstopper occurred. It would provide for a smoother transition for the other empennage assembly line based upon the lessons learned from the first assembly line.

The plans for the control stage had three major deliverables. The first one was the preparation deliverable. This deliverable entailed developing all the procedures and training needed to ensure a smooth transition from the current process to the new one as described in the future value stream map. Another deliverable was the measures and metrics to monitor the effectiveness of the future process and to ascertain if, and when, corrective action was necessary. The third deliverable was to verify whether the vision, goals, and objectives, as well as the expectations and requirements of the customer, had been met either through an audit or a postimplementation review, or both.

A final report was delivered to the steering committee, which reviewed the vision, goals, and objectives of the project. The report also presented a balanced view of the successes and failures during the project, most of which were extracted from the lessons learned compiled at the end of each stage. A review of the overall cost, schedule, and quality performance was also conducted and recorded in the report. The customer, SA, sent a letter to the president and CEO of P3A congratulating the team for reducing the reject rate and improving the cycle time, making a big difference on SA’s own reject rate and cycle time delivering airplanes to its customers, not to mention a substantial decline in late delivery penalties.

Rob closed all open contracts before officially closing the project. He also compiled and archived the information for the project. Finally, he planned for individual and team awards for stakeholders on the project.

7.6 Project Management Works with DMAIC, Too

As with using the PDCA cycle, PM plays an instrumental role in the success of a Lean project applying DMAIC. Imagine the complexity of managing a project like LEAP without any PM. The probability of failure would be greater than that of success. With a PM, however, the probability of success exceeds that of failure if for no other reason in that it provides velocity, that is, speed and direction toward a vision. Just the complexity alone compels a large or even a small organization to use PM. As with using the PDCA cycle, the degree or extent of PM applied depends on the scale and complexity of a project. The project manager, along with the feedback of key stakeholders, makes that determination. The LEAP example demonstrates the power of buy-in when determining how much PM is enough on projects so that stakeholders have a sense of ownership and commitment in their project. In other words, PM for a Lean project is more than numbers, schedules, and methods. It is more about people working together for a common outcome.

7.7 Getting Started Checklist