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.
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.
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.
What follows is a simple process and set of proven tools that have been used in several industries to help senior leadership teams to:
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.
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.
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.
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.