REBUILDING CAPABILITY IN HEALTHCARE (2015)
3. Lean Sigma Roadmap: The Anatomy of a Project
Chapter 2 described how to structure and manage change across projects at a program level. This chapter focuses on managing change within a project, specifically a Lean Sigma change project. At the end of the chapter, also briefly described are two other commonly used types of Lean Sigma project approaches, namely, standardization projects and accelerated change or Kaizen events.
First we turn to a Lean Sigma project, describing the way it is structured along with the thinking and approaches it relies upon.
Lean Sigma Project Roadmap
There are a multitude of incarnations of Lean Sigma, but for the purposes here it is best to consider it as the tight integration of two methodologies: Six Sigma and Lean. Both are business improvement methodologies, more specifically business process improvement methodologies.1Their end goals are similar—better process performance—but they focus on different aspects of a process:
1. This may run contrary to popular belief that Lean Sigma is a quality initiative.
• Six Sigma is a systematic methodology to home in on the key factors (known as Xs) that drive variation in the performance of a process (the measures of this are known as Ys), set them at the best levels, and hold them there, thus ensuring a significantly increased performance level for all time. Six Sigma is an excellent method to drive much higher reliability in a process by increasing accuracy and decreasing defects.
• Lean is more of a collection of methodologies to reduce the complexity in a process and streamline it by identifying and eliminating sources of waste in the process, waste that causes a lack of flow. Lean is an excellent approach to increase capacity and throughput of processes, to help processes “move” better.
Another helpful way of viewing the difference is that Lean looks at what we shouldn’t be doing and aims to remove it; Six Sigma looks at what we should be doing and aims to get it right the first time and every time, for all time.
The most common misconception at this point is that Lean, Six Sigma, and the integration of the two are simply toolkits. This is just not true. Admittedly there are tools involved, but viewing them as just toolkits is similar to defining a sports car as a collection of pieces of metal, plastic, and rubber. The identical materials might be put together completely differently and form something entirely different. The value is in how they are put together, but also in the “essence” of the sports car. The car is much more than the sum of its component parts.
In this vein, Lean Sigma is actually a way of thinking. It’s a sequence of thought through a project that allows a team to progress from problem to implemented solution. Tools are used at every step along the way to answer the questions at hand, but it’s the sequence of questioning (the flow of critical thinking) that is the backbone of the method. It is by this means that change is managed throughout the project.
This is a profound concept that many never even recognize, but for a leader planning to bring Lean Sigma successfully to an organization, understanding it is key.
On many occasions I’ve heard leaders say that they want to train everyone in the organization in the tools, so “they can pick them up and use them in their daily work.” Ideally at this point in the book, you’ll have realized that this statement really isn’t advisable. Lean Sigma is a way of thinking and managing change. Just giving the raw tools to staff members would be at least inefficient, but more likely even detrimental to the organization. Uncontained, unfocused change made without the backbone of critical thinking and big-picture context can only lead to reduced performance and frustration of staff.
As we left off in Chapter 2, the project had been identified and the preliminary Project Charter drafted. The project Champion was identified, along with a Project Leader or Belt to facilitate the project. Next, a team of process experts is identified, staff who live and breathe the process every day. The Team follows a disciplined roadmap of five phases: Define, Measure, Analyze, Improve, and Control, often known by the acronym DMAIC. The roadmap is supported at every step by the use of multiple data-driven tools to systematically understand the true problem at hand, determine the reasons for the exhibited performance shortfalls, develop an appropriate solution, and implement it.
Briefly, for each phase:
• Define: Is this the right project? Is this the right project now?
• Measure: How is the process performed? How well is the process performed?
• Analyze: Why is the process performing this way?
• Improve: What should the new process be to perform the right way? The newly performing process is in place.
• Control: The performance is at the level it needs to be. The performance is stable and guaranteed.
The roadmap is structured into three layers:
• Major phases
• Subphases or steps (the goals or the “what”)
• Tools (the “how” to achieve the “what”)
A high-level representation of the Lean Sigma roadmap containing just the major phases and steps is shown in Figure 3.1.
Figure 3.1 High-level Lean Sigma roadmap2
2. Source: © Haelan Group 2012.
Each of the major phases is divided into two to four steps. Each of these steps is not described by the tools that constitute it, but rather by the intended goals that the tools help achieve. Lean Sigma is really about linkage of tools to achieve goals, not using tools individually. The strength of the approach is in the sequencing of tools and the critical thinking based on goals.
The best level at which a leader should think of and interact with a Lean Sigma project is at the major phase and step level, as shown in Figure 3.1, rather than getting drawn down into the tools themselves too much. This leader interaction typically takes the form of “Which phase are you in?” and “What’s between you and the end of the phase?” The discussion should be centered around the primary goals.
With this layered structure in place, the roadmap is goal driven, depicts the critical thinking sequence involved, and is completely generic as it relates to process performance improvement. The tools vary project by project, but these goals are consistent for all process improvement projects. The Lean and Six Sigma tools (and any others interchangeably for that matter) can be selected to meet the goals of any step.
The full roadmap with all three levels is shown in Figure 3.2.
Figure 3.2 Detailed Lean Sigma roadmap3
3. Source: © Haelan Group 2012.
As proven across a diverse range of companies, the roadmap is equally at home in service, manufacturing industries of all types, and healthcare, including sharp-end hospital and clinic processes, even though at first glance some tools may lean toward only one of these. For example, despite being considered most at home in manufacturing, the best pull systems I’ve seen were to control replenishment in office supplies. Similarly, workstation design applies equally to a triage nurse and an assembly worker.
The Belt progresses through the 16 steps in the overarching DMAIC roadmap, at each step utilizing the appropriate tools to meet the step goals. In this manner, the critical thinking involved in being a truly successful Belt is baked into the roadmap and guides each step along the way.
A good Belt always maintains the focus on the underlying principle of “I’ll apply the minimum practical sequence of tools to understand enough about my process to robustly make dramatic improvement for once and for all in my process.”
In the following sections we walk through each phase in more detail.
Define
During Define, the primary objectives are to understand whether this is the right project and the best project to do right now. If not, it is either reshaped appropriately, postponed until it becomes a higher priority, or canceled completely. The Team is mobilized and spends time reviewing and making necessary updates to the preliminary Project Charter to ensure that everyone is on the same page as to what this project will address, its scope, benefits, who will be involved or affected, and what business value it will generate. Tools are used that begin to explore the process, its customers, their requirements, and the associated primary performance metrics. By the end of Define, the Champion, Process Owner, Belt, and Team are all on the same page with respect to the scope of the project, exactly what it will achieve (the problem it will resolve), and the business metrics by which success will be determined. The steps and supporting tools for Define are shown in Figure 3.3.
Figure 3.3 Define Phase roadmap
Initiate the Project
Prior to the project commencing, the Belt, Champion, and Process Owner meet to formally hand over the project to the Belt to lead.
Lean Sigma is not a gladiator sport. The Belt is not there to deliver the project on his or her own. The Belt is a facilitator of the Team. Initiate the Project is when the Team first meets and the project is truly up and running.
The Belt is purposely selected to not be from the process area in question, primarily so that he or she has no preconceived ideas. However, the Belt does need enough of a basic understanding of the process layout, flow, and local process jargon to be an effective project facilitator. With this in mind, the Belt “shadows” in the area prior to the first Team meeting.
At the commencement of the first Team meeting, the Champion and Process Owners kick things off by introducing the Team to how Lean Sigma fits into the organizational strategy (or reminding them). They then explain to the Team the purpose, value, and initial scope of this particular project by walking the Team through the Project Charter. Once this is complete, the Champion and Process Owner are not part of the Project Team but check in regularly (at the end of Team meetings, for example) for “calibration.”
Define the Process
Although the prioritization process described earlier drove selection of a particular project, without more detailed insight into the process and its business impact the Team may not focus on the important elements. It is therefore important to have a well-defined scope for the project and that the true purpose of the process be understood. To define the process, the Team uses very simple mapping tools to determine the beginning and endpoints of the process to investigate them in detail and ensure the right scope.
Determine the Customer Requirements
To determine the deliverables for the process, the Team could just accept the conventional thinking of what the process generates. Experience shows, however, that the purpose of most processes is misunderstood, and in fact large pieces of processes often exist to deliver things that aren’t truly needed by the customers of the process. Often the true customers aren’t identified or consulted on what is needed from the process. So, during the Define Phase, the Team uses a series of tools to identify the customer, gather the Voice of the Customer (VOC), and distill it into a usable form.
For the majority of projects this involves a series of carefully planned interviews to capture insight into the customers’ worlds and their interaction with the process. The output is in the form of a Customer Requirements Tree, as shown in Figure 3.4.
Figure 3.4 Example Customer Requirements Tree
It is worth mentioning that up until this step, projects for the most part follow the same path or tools sequence. This step, however, exhibits the first real divergence of tools by project. For example, if a project really has only a single, internal customer, the approach for capturing the VOC might be as simple as inviting the customer to a Team meeting and having an open-ended conversation about the needs and purpose of the process. If, however, there are multiple customers (or external customers), it is highly recommended that the Team spend much more time, effort, and tools focused on whom to ask what and how.
A common mistake made during this step is to consider staff as customers. Staff will be taken into consideration later in the roadmap, but positioning them as customers at this point can skew the real purpose of the process and even prevent unneeded steps from being designed out.
Another key mistake is confusing what is wanted with what is needed—improving a process based on what customers say they want, which often is very much solution oriented and thus very diverse, as opposed to the fundamental underlying needs across customers, which are typically a lot more consistent. Henry Ford said that if he had only listened to what people said they wanted, he would have made faster horses. He understood that the real need was for better transportation.
Determine the Project Goals
From the VOC, the subset of major metrics that the project will target is determined and a baseline is taken, typically from historical data. This baseline is rudimentary at this time (later in the Measure Phase a more robust baseline is taken)—effectively at this stage it’s just a rough-cut baseline to determine if there really is potential in the process (remembering the Define goal “Is this the right project?”).
The metrics are very much business based and are typically split between effectiveness metrics (those that are customer related, such as quality or service level to customers) and efficiency metrics (those that are business related, such as cost per unit of service).
With the project metrics identified, it’s a matter of determining the target or goal value for each metric. To accomplish this, the approach taken is that used in initially chartering the project as described in Chapter 2, using the concept of entitlement (perfection for that particular metric). The target is thus set at (for example) halfway between current performance and entitlement.
As a critical juncture in the project, any mistake here can cause serious ramifications later for the Project Team. The most common mistakes in scoping projects are the following:
1. Boiling the ocean (too large a scope): The circumvention for this is tricky to explain in an introductory text such as this, given the multitude of complicating factors. In simple terms, if you find yourself in a position of chartering a project across multiple processes (a Tier 2 or Tier 3 program), the project is too large and needs to be broken into pieces.
2. Having too many metrics: This is somewhat akin to “boiling the ocean.” If attempts are made to tackle too many metrics in the process, the project may effectively be trying to address the whole golden triangle (cost, quality, and timeliness) all in one go. The same is true if the project targets changes in practice, process, and systems all at the same time. Both of these are possible but require an experienced hand and a carefully designed approach.
3. Micro-focused projects: A very common mistake, especially in the early stages of a Lean Sigma deployment, is for leaders to scope a project too small, often with the thought that doing so will help a Team get through the project more quickly and with a higher chance of success. The opposite can in fact happen. Because the project is very small, the business value is low and thus the Project Team meetings often get postponed due to other (now higher) priorities.
4. Having a solution in mind: This is likely the highest-risk mistake that is made. Typically a senior leader has a pet solution in mind, and the assumption (similar to the micro-focused project) is that the Team will be accelerated if the focus is just to install the solution.
The business problem has root cause(s) driving most of the variation in performance. An all-too-common scenario is that the chosen solution does not address the critical root cause(s) and now there is a difficult situation. The Project Team is unnecessarily limited to examining those Xs circumscribed by the solution. The leader often blames the Team for poor execution, when the reality is probably that they did the best they could under the circumstances but the chosen solution just didn’t impact critical Xs. If the solution did happen to make a big difference, the Team sometimes gets reduced credit because it was not their answer.
Either way, as a Team or a Belt, if you’re being handed a solution to implement, you might have a struggle ahead of you.
Once the right metrics and target values are determined, the Charter is updated and the project passes through a formal gate meeting, with the Belt, Champion, and Process Owner present, to review and sign off on the Define Phase. Define Phase signoff indicates that all parties are comfortable with moving forward and this project is worth applying valued resources. There is a clear opportunity and the Team can continue on to the Measure Phase.
Measure
During the Measure Phase the Team works to understand the current state of the process through the use of mapping tools. Focus is placed on ensuring the reliability of the primary performance metrics and then a more robust baseline is established. Once a baseline is determined, if any quick hits have been identified, the Team can go ahead and implement them. The steps and supporting tools for Measure are shown in Figure 3.5.
Figure 3.5 Measure Phase roadmap
Understand the Process
Here the focus is to use simple and yet surprisingly elucidating mapping tools to understand the basic structure of the process and begin to understand its shortcomings. The mapping tools used vary depending on the problem at hand. If the project is about increasing accuracy or reducing defects, the maps help identify all the potential Xs in the process. If the problem is more about streamlining and reducing complexity, the maps are more about detailing all of the individual process steps and delays.
Once the mapping is complete, the Team has a much deeper understanding of the current process, remembering that one of the questions to be answered in Measure is “How is the process performed?”
Develop and Evaluate Measurement Systems
Measurement at this stage is aimed at the primary performance metrics for the process—just how good we are right now, before any changes are made to things such as cycle times and lead times. The prior mapping activities help determine exactly what to measure and where in the process, but before any data can be collected, work is undertaken to ensure that the metrics used are reliable. This means that they are clearly defined, repeatable (if I measure it more than once, I agree with myself), and reproducible (if two or more of us measure it, we agree with one another). This simple concept is remarkably powerful in identifying problems with how we measure performance of processes. It’s very common to see lengths of stay not spanning the entire process from when patients walk in the door to when they truly leave the facility. Often we focus on a subset of the full process and hence limit our thinking and subsequently our results, or the data isn’t captured or transcribed correctly. In most hospitals and health systems there is an abundance of data but very little reliable information. Disturbingly, when a request for data is made, it’s common to hear the answer “Sure, what do you want it to tell you?” In the objective world of Lean Sigma, where data drives decisions, this obviously isn’t ideal.
Measure Current Process Performance
Once the measurement systems are proven to be valid and reliable, a carefully planned data collection is conducted for the primary metrics in the Charter. The purpose of taking the baseline is multifold:
• The process might actually be better performing than anticipated, and perhaps it’s better to focus the project somewhere else—perhaps rescope the project or kill it entirely. Remember, “Is this the right project?” We need to make the best use of our valuable resources.
• The business cannot claim success for improving a process if it’s not clear how good or bad the process was to begin with.
• More importantly (and this is certainly not traditional thinking), if a baseline is taken and improvement is made, the change in performance is truly understood. Once the project is complete, operators within the process are much less likely to try to “dink” with a process to improve it further if they understand just what a significant improvement has been made.4 This represents one of the best control tools in Lean Sigma—processes tend to stay fixed because stakeholders in the process genuinely understand that the performance is better than anyone could achieve by additional tweaking. More importantly, this breaks the cyclical thinking attached to process improvement. Changes are made once and for all, and no one will mess with the process beyond this point unless some external factor or change drives us to do so.
4. Remember that most “dinking” leads to a degradation in performance.
During the Define and Measure phases often a lot of “low-hanging fruit” in the process becomes apparent. There is always a temptation to address these early in the project, but until a solid baseline is known, it’s better to leave them for the three bulleted reasons just given.
Once a baseline measure has been taken, the Belt meets with representation from finance to formalize how the project will be measured financially. At a program level work will have been done in general to determine how key business measures (e.g., increased volume, reduced inventory, etc.) should be translated into dollars. At this point in the roadmap the financial translation is formalized for this specific project.
Financial analysts are also extremely helpful in identifying other potential value in the project.
After the financial review, the Belt, Champion, and Process Owner(s) meet to sign off on the final scope, baseline, and goal of the project.
Implement Quick Hits
Once a baseline has been determined, some quick hits can be implemented and quite often dramatic improvements can be made in a structured way.
Interpretation of what constitutes a quick hit varies considerably. Here it is defined as something that requires no analytics, has full consensus, requires few to no resources to implement, and can be rolled out very quickly.
By this definition, quick hits include only changes that are blindingly obvious. If there is any debate about the validity of a quick hit, it is no longer deemed as such. If a large number of resources are involved in the process, for example, in nursing, there is really no such thing as a quick hit. By the time the education plan has been developed for the quick hit and all the resources have been trained, many weeks may have passed and the project has likely progressed well into the Improve Phase.
A great example of a quick hit that I often share with new Project Leaders was in a returns process in an electronics business in San Diego, California. Customer service representatives (CSRs) would answer the phone and take details from customers regarding the return. They would fill in the paperwork and dutifully take a copy to the warehouse because “the warehouse needed it.” The warehouse staff would likewise dutifully file the copy because “the CSR needed it filed.” In reality all of this paperwork filling out, transporting, and filing was a total waste of time and money, and the simple quick hit was to just stop doing it. No analytics or investment was required, and it was a simple implementation.
Analyze
Analyze is designed to provide the context for the improvements to be designed in the Improve Phase, not as is sometimes believed to prove that an initial solution idea was correct. The Team uses data-driven tools (some statistical, some flow related) to understand the key sources of variation and waste in the process.
Analyze is the only phase where there is some separation of the methods of Lean and Six Sigma.
For projects specifically targeting the accuracy and robustness of a process, Analyze utilizes a sequence of tools involving initially Team insight and subsequently data collection and analysis to systematically home in on the critical Xs driving that accuracy. Later in Improve, focused change on these key Xs will significantly reduce defects in the process, thus making it more robust. The whole approach for accuracy and reliability projects is thus like a funnel, as shown in Figure 3.6.
Figure 3.6 Funnel approach to identifying critical Xs
For flow/capacity-related projects, Analyze tools aim to identify the key sources of waste (hindrance to flow and reduction in capacity).
The steps and supporting tools for Analyze are shown in Figure 3.7.
Figure 3.7 Analyze Phase roadmap
Use Team Knowledge to Identify Causes
For projects targeting accuracy and robustness, the Team will have identified all the process Xs (possible factors affecting performance) during the mapping in the Measure Phase.
In this step, the Team uses slightly more subjective tools to narrow down the Xs to a more manageable number before the later, more intense data-driven tools are applied. A first rough cut is applied using a tool called a Cause and Effects (C&E) Matrix5 to drop the Xs by approximately three-quarters. Then, a second, more detailed tool called a Failure Modes and Effects Analysis (FMEA)6 is used to focus on the highest-risk Xs to reduce down to a final set of 10 to 15 primary Xs prior to applying the data-driven tools.
5. See Wedgwood, Lean Sigma: A Practitioner’s Guide, pp. 153–57.
6. See Wedgwood, Lean Sigma: A Practitioner’s Guide, pp. 325–29.
Analyze Data to Identify Causes
Data and data analyses are critical to Lean Sigma. Continuing with our accuracy/reliability-type problems, the Team uses an overarching data capture, planning, and analysis method called a multi-vari study, which involves more stringent statistical tools to objectively narrow down the Xs to the final few.
Data is captured for the remaining 10 to 15 Xs from the prior step and then analyzed graphically to identify any patterns or relationships, which are captured as potential hypotheses. For example, from Figure 3.8 we might identify the following potential hypotheses:
• Length of stay varies by ED physician.
• Variation in triage time is higher on the night shift.
• Wait time for a room varies by day of the week.
• Wait time is more variable on Saturdays, Tuesdays, and Thursdays.
• Length of stay in the ED is longer on the night shift than on the day shift.
Figure 3.8 Graphical analysis of Xs during a multi-vari study
Statistical analyses are then conducted on each of these potential hypotheses to identify which relationships are significant (real) and those for which the graphical hypotheses could have been exhibited purely by chance.7 From the analytical results practical conclusions or implications are drawn as to the critical Xs and how they affect the performance of the process.
7. For a more detailed description of hypothesis testing, see Wedgwood, Lean Sigma: A Practitioner’s Guide, pp. 300–305.
Understand Demand, Flow, Capacity, and Value
For those projects and processes that are focused on capacity, throughput, flow, and timeliness (as opposed to accuracy and reliability), this step utilizes tools to understand the related issues and sources of waste or complexity hindering the ability of the process to meet performance requirements. The tools used are fairly disparate, but collectively they show the fundamental issues with the dynamics of the process.
Improve
The purpose of Improve is to develop and implement the solution. Improve is the time when the solution(s) are finally constructed. Changes made in Lean Sigma are based on the data and understanding gained by this point in the project. The approach isn’t to first decide on a solution, then commence a project to prove that it’s the best solution and implement it.
Conceptual solutions are constructed based on the context of what has been learned from Define, Measure, and Analyze. Once a final concept is determined, the Team produces a detailed design and pilots the process to ensure its success. The steps and supporting tools for Improve are shown in Figure 3.9.
Figure 3.9 Improve Phase roadmap
In the early days of Six Sigma in other (manufacturing) industries, solutions tended to relate to a simple change to an X in the process. Also in those other industries, the process had likely been designed at one time by a process engineer and hence was reasonably “clean.” In healthcare, processes are rarely engineered from the beginning. More typically, they have evolved over time and are for the most part pretty messy. In other industries, there is also a predominance of physical plant and equipment, whereas in healthcare, as in most other service industries, the predominant process “equipment” is human.
What these two factors mean in practice is that change in healthcare processes needs first, to include cleaning the whole process pretty much as a matter of course, and second, to involve the trickier scenario of changing people. When implementing change in this kind of environment, it’s worth noting the three key requirements for an individual to be motivated to change:
1. I know why I’m being asked to change.
2. I know what is expected of me in the new process.
3. I feel safe doing it.
The Belt and Team will handle item 2 in developing the new process, constructing an implementation and education plan, but it is critical that leaders, including Champions and Process Owners, own items 1 and 3. From the outset of the project, leaders should be open about the business need for the project and associated process and role changes. They should also encourage the staff in feeling comfortable about their ability to perform their duties in light of any changes and be clear that staff will be supported throughout the transition.
Develop the Concept
Lean Sigma is a highly innovative approach at this point in the roadmap. Rather than implementing a preconceived solution that tackles perhaps a small part of the process, the Team invariably considers the whole process from its fundamentals. Based on the context gained from the first three phases, innovation tools are used to generate a multitude of potential solutions, and these are tested against the process requirements. Components of the best solutions are hybridized together to form the new concept.
Once a new concept has been developed, there is an important project gate, at which point the key stakeholders sign off on the chosen solution. One common mistake made at this gate is that the leaders try to “cherry-pick” components that they like from the solution and deselect elements they don’t like. This can be extremely detrimental for a couple of reasons:
1. Most solutions tend to be a holistic answer to the problem, and hence deselecting certain elements can unravel the solution to the point of being ineffective.
2. Deconstructing the solution conveys a message to the Team that their solution isn’t trusted, which the Team can translate into “The leaders don’t trust us. If they were just going to implement their answer, why did we go through all of this?”
As a leader it’s important to remember that the best solution is the one that gets implemented and actually sticks. Remember that from the leadership position you don’t often get the best view of how the work is done and how it might be done better.
A key activity once the concept is developed is to simulate the process and then to attempt to break it. The Team tries to identify scenarios that will cause the process to fail, with the intent of making it yet more robust. A useful tool here is to conduct a prospective risk analysis of the new process. The Team looks at new steps introduced into the process and brainstorms what might go wrong, how bad it would be, and how it can be mitigated. This will help the Team anticipate potential failures as they simulate the new process. Once the Team has tried this, they should engage key stakeholders, including Champions and Process Owners, to attempt the same.
Develop the Detailed Design
Once the concept has been agreed upon and signed off, it’s only now worthwhile to spend Team time putting together the details of the process, the standard work, and the implementation plan.
The Team progresses systematically to
1. Add clarity to the process steps (definition, order, balance, pace, work sequence, flow)
2. Identify simple triggers to ensure uninterrupted flow of the process
3. Determine roles and accountability through the process to ensure clear ownership and balance of work content
4. Create Standard Work Instructions showing both the overarching flow of the process, but also fine detailed steps where needed
5. Lay out the workplace to support the process flow and the work conducted there
6. Ensure that competency is clearly defined for each role and thus create linkage to orientation and ongoing education
Once the process detail is created, the Team works to create a detailed implementation, communication, and education plan to be able to confidently deploy the new solution.
Pilot/Ramp Up the New Process
In many circumstances it’s useful to pilot the new process prior to undertaking full-scale implementation. This is usually most relevant when the process is to be rolled out across multiple units or locations.
The term pilot has certain connotations, and here again is a difference in Lean Sigma from traditional approaches. Typically, piloting implies a test of a solution to see if it “fits.” Once the pilot is complete, a decision might be made as to whether or not to commit to the solution. This approach can create problems with buy-in. “If we just wait this out and don’t commit to it, we’ll be back to our old approach in no time.”
Here, piloting refers to the period during which the process is fine-tuned in situ. The new process is fully committed to before the pilot; the pilot just optimizes the solution. By taking this approach, the staff has to engage with the new process, because this is the only handholding they will get. “This new process is here to stay, so I need to understand it as soon as I can.”
Control
Once the new streamlined process is in place, the critical control elements are added to ensure that the process and hence its performance never revert to their original state. Once the Control Plan, as it is known, is in place, a second measure is conducted on the primary process performance metrics to ensure that the gains are real. Any gains are validated by the finance group. The steps and supporting tools for Control are shown in Figure 3.10.
Figure 3.10 Control Phase roadmap
Finalize the Control System
The Control Phase is a major difference between traditional approaches and Lean Sigma. The Control Plan is the complete package of physical changes, tools, documentation, measures, roles, and responsibilities that define the process in its new form.
The Control Plan in effect relies on, or can be considered to be part of, what is known as (process) performance management. The Control Plan Summary document captures the key decision points in the process where performance is managed. For example, consider a practical situation that targeted a registration process.8 A key performance criterion for such a process is that patients get through the process in a timely manner. Patients wait ahead of a bank of four registration booths. At most times of day only two booths out of the four are needed to handle the volume of patient demand. However, at certain unpredictable times, spikes in demand occur and cause backlog at the two open booths, thus causing all new patients entering the process to wait for an unacceptable duration. To manage performance of the process, if patients wait for more than 10 minutes, phone registrars working adjacent to the booths are alerted and shift position temporarily, opening another booth to work down the backlog. Once it is cleared, they return to their original duties.
8. Discussed in more detail in Case 6 in Chapter 4.
This localized performance management is reinforced by the manager but isn’t overseen by anyone but the registrars themselves. The key metric of patient wait time is part of their daily scorecard, which they passionately drive.
Verify Long-Term Performance
Once the Control Plan is in place, a second measure is conducted on the primary process performance metrics, and statistics are used to ensure that the gains are real (a statistically significant difference from the process performance before the project to after it). The gains are then validated by the finance group and entered into the program tracking documents.
The Lean Sigma Roadmap: Why It Works
At first glance the roadmap should seem just commonsense and straightforward, but it has a number of perhaps not-so-obvious built-in strengths, including at least
• Integral change management techniques
• Flexibility of approach to different problem types
• Focus on customer need
• The right metrics to reduce complexity
• Goals set in a meaningful way
• Decisions based on the right data, not subjectivity
• Changes made in context
• Breakthrough change, not incremental improvement
• Changes locked in to assure that gains are maintained forever
Integral Change Management Techniques
The people aspects of change are notoriously difficult to navigate and have spawned a plethora of techniques and approaches to ensure that change is implemented successfully and sustained. The Lean Sigma roadmap has multiple techniques built into it in a meaningful order, not limited to the following:
• There are mechanisms to ensure that throughout the project all parties are on the same page with respect to the project scope, purpose, measures, and solution.
• Key stakeholders (staff, managers, physicians, customers, etc.) are managed from problem to implemented solution.
• Solutions are based on data and the context of understanding gained along the way.
• A full complement of the right people closest to the process solve the problem.
• Composite solutions are developed, engaging all parties involved.
• Solutions are openly reviewed for critique and honing.
• Goal-driven project management methods underpin the roadmap.
• A systematic roadmap ensures that all parties know what’s happening now, what’s next, and why.
• Goals are set based on entitlement, to engage and drive thinking.
• Projects are resourced to a meaningful degree.
• Recipients of change understand the need for change, the newly developed solution, how they got there, their role in the solution, and what’s expected of them.
Flexibility of Approach to Different Problem Types
Different business problems, depending on complexity and inherent difficulty of resolution, require different levels of rigor. The split-level roadmap with the higher-level goals (Initiate the Project, Define the Process, etc.), underpinned by flexible use of many available tools, allows latitude to tackle simple problems quickly and efficiently, while allowing higher degrees of rigor for more complex problems that require it. The roadmap is flexible so that it can be executed in a single event or spread across many shorter meetings, affording choice about how to manage resources within a project and across the program.
Focus on Customer Need
To determine the deliverables for the process, the Team could just accept the conventional thinking of what the process generates. Experience shows, however, that most processes are misunderstood, and in fact large pieces of processes often exist to deliver things that aren’t truly needed by the customers of the process. Moreover, the true customers aren’t often identified or consulted on what is needed from the process. The Team assumes it knows what the customer needs. Most often, it does not. The roadmap includes a series of tools to identify the customers, gather the VOC, distill it into a usable form, determine the major metrics and goals for the process, and derive a solution that meets these goals.
The Right Metrics to Reduce Complexity
The approach used doesn’t tackle a single metric and try to improve it. Agreed, there may be one key metric related to the process that is giving the greatest pain, but it’s important to consider all of the key metrics related to the process. The reason for this is best illustrated by using an example such as the case study on Medication Delivery in Chapter 4. Typically, projects related to this problem focus on just the accuracy of this particular process and not the timeliness of delivery. By focusing just on accuracy, the solution invariably involves adding some extra policing steps to the process—that is, we add more work to make things right. We patch the process. Each time someone examines the process, additional patches are added and the process complexity increases. As the complexity increases, so too does the risk of error (since it is more difficult to do the process), which is completely contrary to the objective. The better approach is to strip the process down to its fundamental pieces, remove all the complexity, and really focus on the essence of the process. A great tenet here is that if a step is designed out, that step can no longer be done wrong.
Our seemingly advanced systems have added much unneeded complexity, and our solutions often are driving in entirely the wrong direction, to add yet more complexity.
By considering all the key process metrics in the project and thus including the metric of timeliness of delivery in the objectives of the project, the focus is on doing things more quickly. To achieve this, the best approach is to remove unnecessary work from the process and streamline it. Simpler, streamlined processes tend to be much easier to do and are more consistently applied and thus more reliable.
Goals Set in a Meaningful Way
If goals are set based on entitlement, they are completely achievable from a Lean Sigma standpoint but are much greater than what could be achieved by other means. The stretch nature of the goal engages the Team and moves them well beyond the realm of just making minor tweaks. Once the project is complete, such magnitude of change is less prone to be overwritten by future tweaking and is thus more likely to be sustained.
Decisions Based on the Right Data, Not Subjectivity
In most healthcare organizations there is an abundance of data but very little information. Lean Sigma seeks to base decisions and changes on reliable data, thus removing subjectivity. “We’re making a particular change because that’s what the data shows us.”
Changes Made in Context
Changes made in Lean Sigma are based on the learning and understanding gained prior to the Improve Phase. The approach isn’t to first decide on a solution, then commence a project to prove that’s the best solution and implement it. Instead, based on the context gained from the first three phases, innovation tools are used to combine smaller components of solutions to form the new concept. The Team then forms the detailed design of the process around the agreed-upon concept.
Breakthrough Change, Not Incremental Improvement
As described in Chapter 1, the more traditional performance improvement methods used in healthcare rely on the notion of continuous improvement and thus drive continuous change in processes, hence causing a constant churn and inevitably leading to degraded performance.
Lean Sigma, with its breakthrough change approach, not only drives bigger change over a shorter time frame but also, because staff are not required to subsequently continuously improve the process, ensures that gains are more likely to be sustained.
Changes Locked In to Assure That Gains Are Maintained Forever
Changes made using traditional performance improvement methods typically fail to sustain, due to the many reasons described in Chapter 1.
However, once changes have been effected in Lean Sigma, the strong emphasis on control methods in the latter stages of the roadmap, including Standard Work Instructions and the Control Plan, ensure that subsequent performance is managed and maintained.
Standardization Projects
For many processes the issue is that staff all do the process somewhat differently. Substantial change isn’t necessarily required. The need is more to define what the standard process should be (say what we do), and then have everyone follow it, every time (do what we say).
The recommended approach is shown in Figure 3.11. The approach has two main threads: one related to defining the standard process, the second to following it.
Figure 3.11 Flow of standardization projects
To define the process, a short standardization event is used. Prior to the event, preparation work is done to ensure that the event goes off smoothly, and once the event is complete, there is usually some degree of follow-on implementation and education.
The roadmap used is a cut-down version of the full DMAIC change roadmap adapted specifically for standardization. Rather than incorporating an Improve Phase, because no significant change is being made, a replacement Standardization Phase is used, thus creating the new DMASC roadmap. The major steps in the roadmap are very similar to those of DMAIC, and the tools used represent a small subset of the DMAIC tools portfolio. The full three-layer roadmap is shown in Figure 3.12.
Figure 3.12 Standardization roadmap
To complete the full roadmap in the shortened time frame, a few corners are cut as follows:
• Determine Customer Requirements becomes Review Customer Requirements. No extensive VOC work is conducted. The Team reviews the purpose of the process, as it is currently understood.
• Develop & Evaluate Measurement Systems is removed. If the process capability is initially unknown (the process performance isn’t measured), the Team continues regardless. During the Control Phase appropriate measures are put into place, so subsequent performance is tracked.
• Analyze Data to Identify Causes is removed. Detailed statistics are avoided. The purpose of DMASC is not to identify the root cause of low performance and then change; it is simply to standardize to what should be an already understood process, so the detail of this step is not needed.
• Develop the Concept is substantially lessened, since the complexity of evolving a wholly new process is avoided.
• Implementation typically is much smoother and less intensive, since the standard process by definition is relatively well understood.
Based on this fairly extensive list of omissions, many might question the point of such an endeavor. What is striking is the magnitude of change in the performance based on the approach. In a recent rollout across 42 major hospital processes, approximately one-third had not had performance measured before, so no insight could be gained into the magnitude of the improvement. However, the remaining two-thirds all saw an expected reduction in variability in performance. What was surprising was that about half of those processes also saw a significant shift in the mean of the process (defects reduced, cycle times reduced, etc.), and many showed hard-dollar savings.
Kaizen (Accelerated Change) Events
Accelerated change events, often known as Kaizen events, are frequently used within a Lean Sigma program. It is possible to conduct such an event outside of a program, but the focus here is on leading within a Lean Sigma environment, so we’ll not consider that possibility further.
A (Lean Sigma) Kaizen event is a means for effecting change very quickly, in a matter of days versus weeks, but for a very specific problem set. Let’s reiterate that last statement: for a very specific problem set. This approach is applicable for projects that
• Don’t require extensive analytics and data capture
• Aren’t focused on accuracy or defects
• Instead focus on streamlining, improving flow, or removing complexity and thus increasing capacity or throughput or reducing cycle time and length of time through the process (e.g., length of stay)
The work is achieved through use of a team-based event, typically of four or five days, depending on the complexity of the process. The roadmap is shown in Figure 3.13.
Figure 3.13 Lean Sigma Kaizen roadmap
To ensure that the event is efficient and effective, some prework is needed on the part of the event leader, Champion, and Process Owner. The event is chartered in the same manner as a Lean Sigma project. The event leader shadows in the area to gain an understanding of the process, language, and so on. Relevant data is captured and analyzed offline, typically related to demand, capacity, lead times (e.g., length of stay), and cycle times. A baseline is established, plus an understanding gained for the primary process delays and losses in capacity.
The daily event activity follows the Figure 3.13 roadmap steps approximately as follows:
• Day 1: Current state
• Understand the process
• Understand demand, flow, capacity, and value
• Day 2: Develop the future state
• Develop the concept and sign off
• Develop the detailed design
• Days 3–5: Implement and stabilize the new process
The work across days 3 to 5 can vary, depending on the magnitude of the rollout. If the change is localized to a small department, or is across a small number of staff, the process can be implemented on day 3, stabilized, and a Control Plan developed. If, however, the number of staff involved in the process is too large to effect change successfully during the event without a high degree of risk, the Team makes all the possible (smaller) changes they can and then focuses the remainder of the time planning the rollout and go-live for a time beyond the event itself. This allows a certain degree of flexibility and ensures that the Team can drive as much change as possible in a short time frame, without either stalling out or attempting anything too far-reaching or risky without the appropriate planning and diligence.
A well-run Kaizen looks remarkably easy to facilitate, but in fact the approach requires a very high degree of skill and experience in the facilitator. These types of events can yield remarkable results very quickly but if not well planned and led can fizzle out just as easily.
Building Post-Event activity into the roadmap ensures that the control system is finalized, implementation is complete, and performance is verified.
As with any shortened approach, the biggest pitfalls are
1. Trying to apply the method to problems outside of the list of applicability
2. Assuming that because we can accelerate things to 4 to 5 days, we must be able to squeeze them further to (say) 2 to 3 days
Summary
Lean Sigma provides three different roadmaps, each one applicable to a variety of problem scenarios encountered.
The most generic of these, the DMAIC roadmap, is applicable across the majority of improvement projects that involve changing the process. For a subset of these projects, namely, those limited to changes focused on flow and streamlining, the simpler, accelerated Kaizen roadmap is useful. For projects where significant change is not required and the problem relates more to the fact that different staff members involved in the various steps of the process perform the process steps differently, the DMASC process standardization roadmap is very effective.
Each roadmap is simple, flexible, and goal-driven. All have critical thinking embedded within them, to aid in navigation from problem to solution.