Some of the complaints commonly levied against continuous improvement deployments is that they focus on the wrong issues, and that projects take too long or require too much investment (time, training and financial) in order to achieve meaningful results. Unfortunately, these complaints are often justified – not because of some fault in the Lean Six Sigma (LSS) process itself but because leadership fails to properly plan and manage deployments. Selection of projects, selection of LSS practitioners, sequencing of projects and the linkage of all these activities to the company’s operating model and overall mission and goals is a vital factor in the long-term success of any continuous improvement initiative. Effective continuous improvement does not happen spontaneously; it requires careful planning and management. This is especially critical when the continuous improvement deployment is driven in a decentralized manner rather than by a strong corporate edict.

Success Comes From Planning

Most well-run companies spend a significant proportion of management time in planning. Budgets, production, new products and other important elements of the business plan are well thought through and tracked. Unfortunately, many of these same companies do not apply this same discipline to their continuous improvement activities. Green Belts (GBs) and Black Belts (BBs) are trained to employ the plan-do-check-act (PDCA) cycle, but the organization then pushes the Belts to do projects that are not well planned. Change is undertaken without a clear understanding of how these projects fit into the long-term business plan. The result is reactive problem solving that may not have a lasting and significant impact on the long-term health of the organization. Effective management of continuous improvement, however, is primarily driven by good planning. Failing to integrate continuous improvement into the overall business planning cycle is a leading cause of failed deployments.

Why LSS Failure Exists

There are many reasons why organizations do not fully integrate their improvement programs into the business planning cycle. Sometimes it is a confidence problem – when the program is new, leadership may not believe it will deliver the promised results. Sometimes it is a trust issue – if the program is being run by an outside consultant, leadership may be hesitant to share strategic plans. Most often, however, it is an oversight – LSS is not considered a core part of the operation and, thus, is not fully integrated into the plan.

Regardless of the reason, failing to incorporate improvement initiatives into the plans used to run the business results in dysfunctional behavior. These dysfunctions sometimes look like solid management of the LSS program. Most, in fact, are good components of a proper portfolio plan, but since the program is incomplete the components tend to drive the wrong behavior. The distinction is whether the components are proactive and long-lived within the organization.

For example, many companies charge one functional area (such as finance or operations) with accountability for LSS projects. This is important from a validation perspective. Unfortunately, when continuous improvement is responsible to only one function, the needs of that function tend to dominate and drive all project selection. For example, when finance is accountable for all LSS projects, priority is given to projects that result in cost reduction even when this is not the most important issue on the strategic plan. Likewise, when the leadership of the continuous improvement program is responsible for project selection, projects tend to be aligned to GB and BB training.

Narrowly governed programs generally have a one-year to five-year lifespan within the organization and are then supplanted by other programs focused on the needs of the functional areas not driving the LSS agenda. Programs aligned with the strategic plan and governed by a scorecard approach in which the needs of all functional areas are represented tend to be sustainable in the long term and create business impact. To do this, however, the organization must actively plan the execution of LSS, not just run projects.

Avoid Failure

What follows is a simple process and set of proven tools that have been used in several industries to help senior leadership teams to:

• Effectively manage their Lean Six Sigma deployments,
• Ensure that these programs remain on target,
• Ensure that the programs deliver meaningful results to the business,
• Guarantee that the program serves all the key stakeholders, and
• Focus the LSS deployment on driving delivery of strategic goals.

Six Steps for LSS Program Success

1. Establish a set of goals and objectives for the business to achieve. Most companies do this as part of their employee performance and business planning cycles. These same goals must be the goals of the LSS program. When the LSS program pursues goals not directly related to how the business runs (particularly if its employees are incentivized toward these other goals), the program becomes an add-on activity. Relegating LSS to an additional activity within the employees’ responsibilities ensures that continuous improvement will always be a lower priority than the “real” goals for which they are paid. The role of LSS should be to ensure delivery of those real goals; additional goals serve only to distract the team from the strategic agenda. [Tools for this step include: employee goals and weighting, annual business plan, strategic business plan, and mission statements.]

2. Identify the needs of the business and core competencies. When looking at the goals of a company, there are some goals that will be easily achieved, and for which the activities required to achieve them are well-known, while there are other goals for which the path to success is less clear. By focusing the LSS activities on the business goals that are at risk, efforts are aligned to the areas where the greatest effects will be felt. Furthermore, since LSS is helping key leaders meet difficult goals, buy-in for the continuous improvement program is generated. The goals of the business are the LSS goals. When the business goals are met, the organization is propelled forward and creates value. [Tools for this step include: quality function deployment (QFD), failure mode and effects analysis (FMEA), key process indicator (KPI) scorecards, and system capability scorecards.]

3. Make plans to close that gap. This is, of course, where most organizations want to start. Without the baseline data that shows where and to what extent the LSS projects will improve the real needs of the business, however, the process is likely to create an arbitrary list of project that may or may not support long-term goals. It is vital that these steps be undertaken only after the real needs of the business are understood.

• Brainstorm project ideas. Once the areas for LSS teams to focus on have been identified, it is time to identify projects. Do not start this until specific areas of focus have been identified, how those areas of focus relate to the overall strategy is understood, and they can be related to specific KPI that the business needs to improve. Be sure that a brainstorming team is fully representative of the functional need of the business. [Tools for this substep include: Ishagawa diagrams and the Theory of Inventive Problem Solving (TRIZ).]
• Evaluate and prioritize the ideas. Once there is a list of potential projects, it is time to decide which ones are viable and in what order those projects should be undertaken. Develop a list of business specific questions (see “Prioritization Questions” sidebar) to help sort the high impact projects from the less viable ones. [Tools for this substep include: strengths, weaknesses, opportunities, threats (SWOT) analysis, Pugh matrix and prioritization questions.]

4. Match team members to projects with problems they have an interest in solving. Many organizations assign their LSS leaders to projects regardless of those leaders’ backgrounds, education and experience. This model works okay if the company also dedicates those LSS resources (i.e., GBs and BBs) full time to improvement projects, but this is not reality for most GBs. Most GBs undertake improvement projects in addition to other responsibilities. Failure to keep this arrangement in mind when assigning teams frequently means people will choose their “day jobs” over project work resulting in project delays. In an ideal case, GBs who work in non-LSS functions should be assigned to projects that directly affect that non-LSS function. This minimizes the conflict of interest between project work and day jobs. [Tools for this step include: skills matrix, organizational charts and training of new LSS practitioners.]

5. Plan project execution. It is a mistake to identify projects and just hand them off to project teams. The success of an effective project portfolio rests on creating a steady, predictable stream of results. To achieve this, projects must be actively sequenced, resourced and managed. Nothing should be left to chance.

• Choose the right tools and approaches. There are many continuous improvement methodologies; each is tailored to a specific type of problem. While it is possible to solve most problems with any continuous improvement methodology, it is not efficient. Choose the method that best fits the problem and the resources at hand. [Tool for this substep: continuous improvement process selection matrix.]
• Establish realistic timelines. DMAIC projects typically require about 200 to 300 hours of work to deliver results. Similarly, there is a specific amount of effort required for Kaizen (10 to 120 hours) and DFSS projects (about 350 hours). While shortcuts can be taken, it is important to plan for the actual time the team will require to execute the project rather than arbitrary calendar goals. While a team of five full-time BBs can complete a project in one week (assuming all the data is available), part-time GBs with demanding day jobs will require more time. Add to that holidays, weekends, urgent business issues and a learning curve for GBs new to LSS, and 20 weeks is likely to be the time it takes highly motivated GBs to complete their projects. [Tools for this substep include: Gantt charts and project performance standards.]
• Use multigenerational plans where appropriate. Sometimes it is desirable to undertake a massive change in stages. This allows several advantages such as reduced risk, the opportunity to include anticipated new technologies and an ability to realize the benefits of early-stage improvements while pursing the larger goal. Project Champions and advisors should guide teams into this approach when appropriate rather than allow them to become stymied by attempting big changes that require a long time to achieve. [Tools for this substep include: multigenerational planning chart and Hoshin Kanri.]

6. Execute the plan. This is the point where all the work in planning pays off. If planning has been done properly, then this stage is simply managing to the plan and dealing with any deviations. The key to success is to make the work visible.

• Provide teams with the resources, including time, needed to be successful. Once teams have developed project plans and these plans have been approved by leadership, it is critical that both the team and leadership follow the plan. In order for the teams to remain on track to deliver their project on time and on scope, leadership must ensure that time and resources are available as planned.
• Visibly track and report progress. Unless something is being measured, it is unlikely to happen. A portfolio manager should visibly track the execution of projects. This means all teams must report progress at scheduled intervals (not just at mileposts in their projects) and all projects completing a phase should get a rigorous review. [Tools for this substep include: weekly timeline and status updates, and master project plan.]

• Employ tollgate reviews. LSS projects are composed of a series of discrete deliverables that are ordered so that the deliverables that have the highest impact on project risk are first and the highest cost deliverables are delayed. The purpose of tollgate reviews is to ensure that the risk of project failure falls before resources are committed. This means that all the important tasks are verified as done, done correctly and done in the right order. To this end, every project must be reviewed by a Master Black Belt (MBB) and project Champion at the end of each phase. Projects should not proceed to subsequent phases until approval is granted but both the MBB and Champion. [Tools for this substep include: tollgate reports and process performance standards.]
• Validate results. Promising results and delivering them are different things. It is often a conflict for the teams executing the change to also certify that the benefits have been achieved. Most companies are good at validating financial outcomes (e.g., cost reductions, revenue, ROI, etc.), but what about the other benefits? Operational and soft benefits should be independently confirmed by the functional leadership that is held accountable for those outcomes. For this reason, it is important for the entire leadership team to participate in project outcome reviews. [Tools for this substep include: benefit audits and performance scorecards.]

Summary

When all this is done correctly (see “Critical Outputs from Good LSS Portfolio Planning” sidebar), there will be a clear vision of how a company’s continuous improvement efforts will drive success and project teams will have a clear path forward.