REBUILDING CAPABILITY IN HEALTHCARE (2015)
2. Structuring Change: Program Infrastructure
In the previous chapter we saw how many of the existing change paradigms contrive to undermine an organization’s ability to improve performance. It’s probably useful, therefore (to set some context), to describe what change practices we are actually seeking. In no particular order, change should be:
• Transparent and “contained”: Change occurs in known, visible “chunks” or “packets,” such as programs/initiatives (multiple related projects), projects, and events. For simplicity of writing, here we’ll use the term project in the generic sense to represent any or all of these. These projects are clearly defined and scoped; they don’t overlap, counteract, or clash with each other and are singly resourced in that no two groups are working on essentially the identical problem and could potentially or likely overwrite one another’s efforts; and there is no fragmentation of effort.
Change occurs within the projects down a predetermined path, such as a set of milestones or a specified roadmap, and so progress is obvious and visible (easy to track) and clearly understandable to all. These change projects also have a clear beginning and very specifically a clear ending. We’ll discuss this in more detail in what follows (regarding the difference between continuous improvement and breakthrough change), but here, from a transparency perspective, we’ll need to know when the planned change effort will be over, freeing up valuable resources to move on to other things.
• Aligned: Change projects are created and driven directly from the strategy and/or market needs, rather than commissioned independently of these things and aligned/linked afterward. The premise here is that the projects are born from the strategy (for instance) rather than being thought up separately and then connected back to the strategy after the event, to try to ensure that they are meaningful.
We don’t want the projects that are “most aligned” with strategy (of the projects we happen to have identified to this point); we want projects that are the strategic projects and are aligned because they came from the strategy.
Project alignment allows us to gain resource alignment. Project alignment alone isn’t sufficient (we’ll need other considerations), but it is a necessary component.
• Balanced and meaningful: Change isn’t limited in focus to a single business indicator; it targets all relevant business “pillars,” bringing improvement to operations, quality, and finance where applicable. Quality isn’t sacrificed for the sake of finance or vice versa.
The goals that are set are challenging and worthwhile, targeting significant results and associated financial attribution where appropriate.
• Made in light of the appropriate context: Solutions are based on a clear understanding of the Voice of the Customer (VOC) and relevant data. There isn’t a reliance on existing solutions-in-mind, and the teams have the latitude to create a composite solution on what effectively is a blank sheet of paper, rather than having to just benchmark and copy. They are free to explore the full “solution space” before selecting or constructing the final chosen solution.
• Appropriately scoped and focused: Change isn’t locally focused, ignoring the broader context, but rather considers the end-to-end process, its flow, and overarching functionality.
• Lasting and sustainable: Project Teams identify and tackle root causes, with a strong emphasis on robust implementation and control. Implemented solutions are subsequently owned by the staff. Performance management methods align the measures placed on frontline staff with business scorecard goals, and the focus thereafter is on consistency and sustainability versus reinvention and change.
These elements are not likely to come together and occur by chance; they require active management and leadership by key individuals with the right skills, methods, and tools. Thus it’s clear we’ll also need the following:
• Appropriate methods and tools within projects: Efficient and effective tools are clearly sequenced to support the path of critical thinking from problem to solution. Tools are objective and data driven, ensuring that change is made in context as previously described, reducing the risk of missed opportunities or ineffective changes.
Change is fundamental in nature as opposed to simply a patch or Band-Aid, and considerations are made for process, systems, and people (in both roles and competencies).
• Appropriate methods and tools across projects (at a program level): Projects are managed within a broader framework that helps leaders prioritize, adjust timing and resources, track, report, and respond to make needed course corrections. The tools used are effective and pragmatic and ensure that the portfolio of projects is well managed.
• Professional leaders and change agents to lead and conduct change: All personnel working within the framework understand their roles and are competent to undertake them, whether they are managing the portfolio, championing individual projects, leading a project, are members of a Project Team, or are a part of the workforce as recipients of changes.
Project Leaders, as critical change agents, are considered as professionals, are full time, and are highly trained and qualified, working through team members and key stakeholders to realize improved business performance.
In a book on rebuilding capability, the key focus must be on successfully identifying, aligning, resourcing, and managing change. We mentioned previously some of the needed tactics of managing change, but let’s also examine what we mean by change itself.
Change predominantly falls into two main categories:
• Needed improvement on key business metrics. For example, shortfalls in quality, financial, and service indicators require us to use targeted change activities to remedy those gaps in order to be successful in the marketplace. In simple terms, it is the change of making something better.
• (Major) strategic infrastructure change required to build or rebuild our organization to take a new required form for future success. Again, in simple terms, this means the type of change when we do different things. Instead of measuring progress using metrics, strategic progress is typically measured on achieving milestones. A common example might be the structuring and transformation from a traditional clinical practice to an Accountable Care Organization (ACO).
We need to add to this the third, often overlooked, category of “no change”:
• Performance sustainability and consistency. Not all change is good, as described in Chapter 1. This third category is the ability to maintain a stable performing status quo when the first two types of change aren’t required.
Paradoxically, when we think of change, it’s also critical to understand its counterpart: when it is appropriate and how not to change.
In this way we are considering three key facets of change, as shown in Figure 2.1, the balance among strategic change, performance improvement, and operational sustainability. An organization that manages this balance successfully has the ability to execute its strategy.1 If it mismanages the balance, difficulties arise:
1. Whether the chosen strategy itself is the right one to be successful long-term in the marketplace is an entirely different issue and not one we’ll attempt to address here.
• Way too commonly there is too much focus on performance improvement of a plethora of metrics across the house, with the notion of having to be the best at everything. This is the single largest underlying cause of many of the problems described in Chapter 1; resources are sapped away across the organization and few remain and are available to bring about broad-stroke change. Also, the continual drive to improve results in a constant churn of change, completely undermining sustainability and in fact degrading the very performance we’re trying to improve.
• If too much focus is placed on strategic change at the expense of the other two categories, it’s likely we’ll fail to get the basics right and lose valuable market share while we undergo our broad overarching change.
• Last, if our focus is too much on consistency, we’ll have a good foundation for change, but we’re failing to bring about the changes required to compete in the market or transform the organization.
Figure 2.1 The three key facets of change
In their book Blue Ocean Strategy, Kim and Mauborgne2 use the wonderful analogy of describing traditional businesses swimming in a red ocean (the bloody waters of competition) and the strategic desire to swim from those waters into the clearer, uncontested waters of a blue ocean and not having to compete. This is a profoundly different way of thinking about things. Rather than trying to win the game you’re playing (against the odds), try to find a different game to play that no one or few are playing and hence dramatically improve your odds of success. Most healthcare organizations focus intently on life in the red ocean and how best to compete while dreaming of yesteryear, when they didn’t have to, and when they might again be in a bluer ocean.
2. W. Chan Kim and Renée Mauborgne, Blue Ocean Strategy: How to Create Uncontested Market Space and Make the Competition Irrelevant (Harvard Business Review Press, 2015).
Our three facets of change fit the red/blue ocean analogy well:
• Strategic change is equivalent to setting the blue ocean destination, mapping the course, and managing the change of the journey (tracking progress on our milestones).
• Performance improvement focuses on maintaining that necessary competitive edge to allow us to compete in the red ocean, to outpace the rest as we swim (tracking progress on key metrics).
• Last, our operational sustainability focus ensures our organizational health and well-being, our basic ability to perform every time—simply to be able to swim to survive.
Lean Sigma as described here, where organizations most often start out, fits perfectly in the category of performance improvement. As outlined in the Control Phase descriptions (later), it also brings or relies on key elements of process management as part of the sustainability of the newly implemented process.
Also over time, Lean Sigma Project Leaders become highly skilled project and program managers, grow quickly into the role of strategic project managers, and become an integral part of how the organization executes its strategy.
Lean Sigma: The Program
To this point we’ve been purposely maintaining a generic (methodology-agnostic) perspective to ensure clarity of the underlying problems and the necessary components of the solution. Not surprisingly in a book with Lean Sigma in the title, the focus will be on the Lean Sigma approaches, but truly for the magnitude of the undertaking we have been discussing, there really isn’t a lot of choice. It’s worth making mention of another potential option often considered, namely, a Lean Transformation. This avenue is in practice a tougher one to take in healthcare, with less likelihood of success, despite at first glance seeming to be easier. Lean Transformation relies on mass change at a grassroots (frontline) level (versus the more strategic targeted change of Lean Sigma) and does work extremely well in many industries. It does, however, rely heavily on the ability of the in situ management system to sustain any change implemented. The management systems used extensively across most of healthcare are just not able to support such an endeavor. The leaders with the few strong successes in healthcare, such as at Virginia Mason Health System, even draw visitors’ attention to their systems, but many overlook the true power of what is really in place and mistakenly focus instead on how the change events are led and by whom.
Thus, from here on the focus will be specific to one proven solution to the problems, namely, the deployment of a Lean Sigma program.
Now in the prior sentence, note the very specific wording: deployment, Lean Sigma, program.
• Deployment: This takes leadership to bring to an organization. In healthcare, Lean Sigma is often seen to be just a tool set or a very tactical, low-level activity, which immediately destines it to failure. Here we will consider the critical deployment elements to bring to bear on what is for most a very different way of thinking about change.
• Lean Sigma: The approaches described utilize multiple methods: Lean, Six Sigma, but also project management, change management, VOC, concept design and development, and process performance management among others. There is no place in the heat of battle for the purist view of a theorist. Methods and tools are selected and advanced based on their effectiveness and efficiency. This stuff works, but if something better comes along, it is a robust enough framework to embrace additional or replacement tools and techniques.
• Program: Lean Sigma isn’t a set of tools, a roadmap, and a few projects. Instead, through a focused organizational infrastructure it is a business initiative or an underpinning to the way we do business or at least go about changing our business.
This isn’t something that executive leaders delegate, because it’s a cornerstone of leadership itself. It’s the means to execute strategy; it’s a means to meet market performance requirements and the means to manage sustainable performance.
It’s not about the knowledge of some tools or data or analytics; it’s a fundamentally different way of thinking, and as such for many organizations it becomes a compulsory leadership competency.
To reiterate, leaders should absolutely not delegate this. It is a key component of leadership itself.
At a program level a certain amount of infrastructure is critical for success. Many leaders new to Lean Sigma are misled into believing that all that is needed is a Project Leader trained in basic Lean Sigma tools and some projects to be successful.3 Unfortunately, especially for those concerned, this is quite far from reality.
3. Most of the miscreant misleaders are from organizations that sell Lean Sigma training classes and for the most part have never seen a Lean Sigma program as such, or at least a successful one.
Figure 2.2 shows the basic organizational infrastructure required for a Lean Sigma program. The infrastructure can be thought of in two sections: the program level and the project level. Our focus in this chapter will primarily be at the program level, and our focus in the next chapter will be at the project level.
Figure 2.2 Lean Sigma program organization structure
The Steering Group
At the core of the program-level infrastructure is the Steering Group, Team, Council, or Committee (all synonymous) that governs the program, sets its direction, selects projects and Project Leaders (known as Black Belts [BBs] and Green Belts [GBs]), and manages the overarching deployment, timelines, resourcing, and course correction. The Steering Group meets monthly after the first few months, but more frequently (biweekly or even weekly) as a program commences.
The Steering Team is typically made up of the following:
• Executive Champion for the program: One of the Executive Team, a C-level individual or vice president (VP), typically sits as the Chair of the Steering Group. The Executive Champion ensures that the Lean Sigma program is aligned with the business strategy and reports out on Lean Sigma matters to the Executive Team.
• Other key executives: The focus of the program may vary over time, and depending on this focus the relevant members of the Steering Group may evolve but almost certainly will include the executives (C-level or VP) over medical and clinical operations as well as finance and support function operations (diagnostics, pharmacy, materials, etc.).
• Director of Lean Sigma: In the early stages of a deployment, the Executive Champion likely takes this role, but once the program is stable and has enough impetus, it’s a good idea to appoint a full-time person to the role. The Director takes on the more tactical aspects of the program and the day-to-day management of the personnel involved.
• Finance representation: Although the CFO may be a member of the Steering Group, it’s important to have the involvement of a financial analyst in the program. This person is charged with ensuring that financial returns from the projects are identified, real, and tracked appropriately.
• Human resource representation: So many of the decisions of the Steering Group and the outcomes of the program and individual projects impact the roles of the workforce that having an HR role on the Steering Group is critical. As the program is deployed, emphasis is put on the newly created roles of Project Leaders. Considerations such as reward and recognition, career path planning, and personnel performance management are required, even before the staff members can transition into the roles.
• Key change leaders: Other improvement/change leaders, such as medical quality and clinical quality directors or the equivalent, ensure a common understanding of project prioritization and resourcing and ensure that change is conducted efficiently across the organization. The primary goal here is to reduce the clashing of disparate change groups described in Chapter 1.
Having such a steering body can seem like a tough addition to executives’ already heavy workloads. As mentioned earlier, part of the justification here comes back to the simple realization that governing change is a key part of leadership and hence has to have time invested in it. Additionally, executives often query whether this should be an additional entity: “Why can’t we just use an existing meeting to do this work?” The reasoning here is multifold:
1. The Steering Group isn’t a meeting; it’s an organizational body with organizational responsibilities. It is part of a flow of accountability that a simple meeting could not possibly achieve.
2. Most organizational leadership structures aren’t agile or responsive enough to deal with the rapid changes and decision making required to launch and initially manage a Lean Sigma program.
3. Over time it is important to fold the Steering Group back into the existing leadership mechanisms. Most executives understand this, but to a one they realize, having managed change through a Steering Group, that the existing leadership mechanisms themselves are in need of updating and they gain a significant bolstering from the rigor and discipline learned from leading a program through the Steering Group.
Lean Sigma programs are thus most successful when initially launched as a freestanding infrastructure in parallel to the main organizational leadership structures. After typically two or three years or so, once the leadership and workforce understand what it means to have such capability in-house and the program has enough momentum and credibility, most leadership teams elect to consolidate the program infrastructure. This is done most often into the strategy planning and execution infrastructure.
In simple terms we light a small ember of a program on one side, nurture it to a good-size flame, and consolidate only when the risk of it being extinguished has passed.
Setting the Program Direction
Most programs fail to make headway in the early stages primarily due to a lack of clear understanding of why we’re doing this in the first place. A key first discussion of the Executive Team, even prior to the Steering Group being formed, is on the purpose and vision for the program, at a minimum answering these questions:
• What are we doing?
• Why are we doing it?
• What are the desired outcomes?
• What are the types of business problems that we expect to solve with this?
• How will this fit with other initiatives?
If the value of the program isn’t discussed and agreed to up front, confusion will quickly arise, focus will be lost, and the program will begin down a slippery slope as other priorities appear on the executive’s desk, as they certainly will. Once these questions have been answered, it’s a good idea to use the responses as messaging in the initial communications to leaders, managers, and the workforce.
Every program purpose is likely different, but given that the primary value that Lean Sigma can immediately bring is improved performance, there is a useful common set of messages that could be incorporated here. In terms of the program purpose, we should be able to link directly back to the purpose of the organization. Consider the following:
In simple terms, any hospital or health system has two primary purposes:
1. To provide the best patient care today (short-term performance and consistency)
2. To provide the best patient care tomorrow (long-term growth and sustainability)
The term best is vague enough to include all aspects of the care experience such as quality, clinical outcomes, service, convenience, and so on, and the term patient care is vague enough to include all types of care from wellness to episodic and across the spectrum of acuity.
Most in healthcare readily understand the former, but the latter, even though understood at the executive level, is crucial and is often underemphasized in the context of the here-and-now further down in the organization, and in many cases it is rejected entirely. To satisfy this longer-term thinking, there needs to be an additional financial focus to support future care operations, along with a strategic consideration of long-term direction and identity of the organization. This matches well with the three facets of change described earlier (namely, strategic, performance improvement, and consistency/sustainability) and the notional strategic change journey toward a bluer ocean.
At the launch of most programs, the focus probably won’t be the strategic infrastructure changes but more likely will be the competitive performance elements required to survive and ideally thrive in the market—that is, the ability to compete in the red ocean. This ability to compete is certainly not limited to quality performance, which is sometimes how leaders think of Lean Sigma—“just another quality initiative; something to delegate to the quality folks while the leaders can get on with the important aspects of running the business.”
Thus, Lean Sigma efforts should be driven and prioritized against a balanced set of business goals, including patient-centered, operational, and financial goals. These are generally framed around major metrics such as those shown in Table 2.1.
Table 2.1 Major Metrics by Which a Lean Sigma Program Might Be Focused4, 5
4. Note the purposeful omission of measures of employee engagement or satisfaction. Again, this will be discussed in the metrics section of this chapter.
5. Relates to clinical outcomes, not process compliance metrics. This requires a further discussion and will be broached in the metrics section of this chapter.
Only recently, with the advent of healthcare reform, has the notion of a truly balanced view including financial metrics become possible with healthcare leadership; however, as the majority of U.S. hospitals are not-for-profit, emphasizing the financial aspects of healthcare provision is still disturbing to many in the front lines. The famous adage “No margin, no mission” is apt here, but why is this so important? Without profit and the subsequent cash amassed, a hospital cannot afford to invest in new technologies, facilities, staff, expansion, marketing, and other assets. A business that isn’t growing is dying (costs will eventually catch up and place the organization in financial hardship), or the competition will slowly capture more of the market share, which amounts to the same thing.6 Also, given the huge changes required to function in the transformed landscape, the vast majority of organizations are undergoing massive restructuring, consolidation, or rebuilding, which again requires significant investment on their part.
6. An example of this in a hospital radiology unit is described in Chapter 4.
Thus the relevant metrics as shown in Table 2.1 are business metrics, not just clinical or quality metrics. Lean Sigma is a business initiative, not a quality initiative. So, being a little flippant, simply put, all a hospital or health system has to do is grow, while at the same time maintaining customer satisfaction and profitability, thus ensuring adequate cash reserves. Easy to say, obviously not so easy to do.
At this point, traditional performance improvement and Lean Sigma are already beginning to diverge. The traditional focus is typically on improving the clinical performance and quality, whereas Lean Sigma takes a more business-rounded view. Throughout the whole Lean Sigma approach, there is no distinction between quality and operations improvement. Quality improvement is achieved through operations improvement, because obviously the quality of care is created in operations. This brings a significant unification to all performance improvement in the organization, rather than having improvement being made by disparate, sometimes competing groups as described in Chapter 1.
The Fit with Existing Initiatives
Another key consideration is the fit with other existing initiatives. This aspect is obviously highly dependent on exactly what those other initiatives are, but the most common question to answer is whether Lean Sigma is part of a broader performance excellence initiative, is one of many parallel initiatives, or is the umbrella program under which other initiatives fall, as depicted in Figure 2.3.
Figure 2.3 Lean Sigma’s fit with other performance excellence initiatives
The answer here depends on many factors such as what the executive would like to achieve from the program, the strength of brand of the existing initiatives, and other factors. Some organizations go to great lengths to describe just how things fit together. One example of the no-umbrella approach is how a medium-size hospital initially positioned its Lean Sigma projects and program.
At the time (around 2005), the program was embryonic and there was little organizational understanding of what could be achieved through it. Like the majority of their counterparts at the time, the hospital leadership was very much focused on swimming in the red ocean, trying to compete to win. The multilayer diagram in Figure 2.4, affectionately dubbed the “wedding cake” due to its look, shows how they linked multiple active programs (including Lean Sigma) back to strategy.
Figure 2.4 Example of how Lean Sigma is aligned to strategy9
9. Adapted from and used with kind permission from Columbus Regional Health.
They had purposely chosen a strategic goal of “be the best at everything we do,” a lofty goal, but it really helped to drive performance improvement in the organization. To make claim to being the best, there had to be measures involved; otherwise, how would they know they were the best? These were provided from various external sources such as Magnet7 and Fortune, as well as internal benchmarks such as physician satisfaction, as shown in the second layer in the figure.
7. The Magnet Recognition Program, operated by the American Nurses Credentialing Center, recognizes healthcare organizations that provide excellence in nursing.
An interesting and correctly placed inclusion in the external benchmarking group was Baldrige.8 Quite often healthcare professionals mistakenly think that Baldrige is an improvement methodology, with statements such as “Should we do Lean Sigma or Baldrige?” Baldrige does not in fact provide the means to improve but does, however, provide a means of judging current systems performance and an objective way of identifying opportunities for improvement that can be tackled using improvement methodologies such as Lean Sigma, or strengthening of an organization’s management systems.
8. The Malcolm Baldrige National Quality Award recognizes U.S. organizations in the business, healthcare, education, and nonprofit sectors for performance excellence.
The “Methods” row shows how the hospital leaders positioned the different kinds of performance improvement, including Lean Sigma, parallel to one another, which helped staff understand how these facets might work together.
Incidentally, since 2005 things have changed substantially once Lean Sigma found a footing in the organization. The hospital became a benchmark organization for Lean Sigma deployment and results. Most recently (2013 to the present) the Lean Sigma department has been transformed into the Office of Strategy Deployment (OSD), ensuring that all change is structured and aligned to strategy, resourced appropriately, and tracked and managed to success.
Shaping Projects
Before we can discuss where opportunities arise, it’s important to understand what projects (as our means to take advantage of those opportunities) are and how to think about them. Once we understand the shape of projects, only then can we develop them and launch and manage them.
The means to close performance gaps includes a rounded portfolio of methods to make change. Not all projects require a full-blown Lean Sigma project approach, so once project opportunities are identified, a suitably experienced group of individuals (typically a subset of the Steering Group augmented with a Master Black Belt [MBB]10) decide on the likely approach required. There are a number of possible project options:
10. More on roles later in this chapter.
• Just do it: The change needed is known and is a quick and easy fix to the process. No data collection is required, and there are no significant organizational barriers to making the change. There is a clear, obvious, and unanimously agreed-upon solution that just needs to be implemented, and the implementation itself requires no significant project management. The change is effectively a “no-brainer.” Unfortunately, many projects are mistakenly placed in this category. Everyone thinks the solution is straightforward, but the reality is that there isn’t alignment in thinking. The best “just do its” are to remove or stop a current activity or effectively more of a “just don’t do it.”
• Kaizen (also known as accelerated change event or breakthrough event): The process needs to be streamlined to reduce complexity or improve flow. The problem doesn’t require rocket science (or extensive data analysis); it just needs the right people in the room with a simple set of (Lean) tools and some good facilitation. These are typically three- to five-day events and are often aimed at capacity or throughput in areas with excess demand versus available capacity, such as computed tomography (CT) or cath lab.
• Regular (engineering) project: The solution is known and understood. The implementation takes time and resources, and thus a disciplined project management format is used to ensure success, for example, building a new emergency department (ED). Note that these projects often could be supported by Lean or Lean Sigma activity such as ensuring that the new ED design supports the right workflow.
• Lean Sigma project: The solution is not known and when discovered may take resources and time to implement. The problem is not one of simply reducing complexity; some data collection and analysis will be necessary. Lean Sigma projects will be explored in detail inChapter 4.
• Standardization project: The process doesn’t require major change; however, many of the staff conducting the process do it in different ways. The problem is thus one of setting a standard process and having all of the staff follow it. Standardization projects will be discussed in Chapter 4.
• Process design: The process itself isn’t defined or may not exist at all, or the current process technology may not be capable of the performance levels needed. A whole new process is required.
• Service development: The organization would like to develop a service (or product line) to move into a new market. A project is undertaken to understand the strategic intent, understand the market, and target customer needs and shape a new service accordingly. Once developed, such projects often spawn multiple Lean Sigma projects or Kaizens to improve performance or increase capacity in adjacent processes to better support the new service.
• IT/IS project: The organization has identified a new or replacement information system need, and a project is undertaken to understand the process requirements (and thus the system requirements), develop the system or identify and tailor it, and then implement it. In more mature Lean Sigma organizations it is required that a Lean Sigma process improvement project be undertaken prior to any IT/IS work, to ensure that the Voice of the Customer (VOC) and Voice of the Business (VOB) are deeply understood, but also to determine if the new system is needed at all.
• Programs: In some cases such as in the ED or in surgery there are many related projects that should be dealt with as a set of projects rather than individually. Creating a “world-class OR” or “world-class ED” program as an umbrella initiative to provide oversight for multiple related projects ensures the correct integration of projects and a reduction in total resource effort.
Focus on Process
We saw in the previous chapter that the traditional improvement approach often involves multiple uncoordinated teams to tackle symptoms as if they were unrelated. Here the approach is very different.
Lean Sigma is a process improvement methodology, not a practice, symptom, function, or activity improvement methodology. This is a key distinction in framing projects, and it is one that newcomers frequently get wrong during project identification, scoping, and selection.
Practice relates to what needs to have been achieved during a time period and why. For example, if a patient arrives at the ED with chest pain or a heart attack, practice describes the “what” (patient receives a fibrinolytic drug within 30 minutes of arrival) and the “why” (to open the clogged artery and minimize heart damage). The process relates to how the practice is achieved, when, and by whom, in this case by the ED nurse during triage from the storage cabinet to the left.
A process is a sequence of activities with a definite beginning and end, including defined deliverables. Also, a “something” travels through the sequence (referred to as an “entity”), typical examples being an order, patient, or bill. Resources are used to accomplish the activities along the way. If there is no obvious, single process identified or if the process doesn’t have a start, an end, deliverables, or an entity, it probably isn’t a process and you would struggle to apply Lean Sigma to it.
Figure 2.5 shows an extended version of Figure 1.1’s description of processes and systems to include the roles (analogous to the seats people can sit in through the process), the competencies required to sit in those seats, the people having those competencies who sit in the seats, and the knowledge base that supports this. Lean Sigma projects focus on the process aspects of this picture but by necessity have to work through the connection to systems, the roles involved, competencies, people (typically staff), and the supporting knowledge base.
Figure 2.5 The relationship between processes, systems, roles, people, and competencies
Breakthrough Change
One of the most common mistakes made with respect to change in healthcare relates to the notion of continuous improvement. As described in Chapter 1, continuous improvement has become synonymous with everyone being encouraged to make incremental change all of the time, in an effort to gain a continuously improving performance like that shown on the left in Figure 2.6 (see page 36). An initial endeavor to improve performance from a low level can yield improvements, but a logical disconnect arises when leaders and staff believe that continuing to change will bring yet better performance, when in reality it is much more likely to get worse.
Figure 2.6 Continuous improvement (left) versus breakthrough change (right)
This flawed thinking has given rise to continuous churn in organizations with processes not stabilized or controlled and has in fact led to reduced performance. Lean Sigma can be thought of as continuous improvement, but referring not to change at the process level (staff continuously tweaking the process), but rather at the organizational level as a whole. Breakthrough change is made process by process and as a result the organization continually improves.
Lean Sigma from a single-process perspective is a breakthrough change approach, as depicted on the right in Figure 2.6. A change Team is launched based on a business need. The Team works to understand baseline performance (no immediate change is made). The Team then determines the context of why the process performance is the way it is (and still no change is brought about). Next, the Team designs and develops the new process, along with a robust implementation plan. Only then is change made—not just a minor (hit and hope) tweak, but instead a significant change in the context of understanding what is really driving process performance: a breakthrough change. Once that change is made, focus is placed on locking down the process, so no subsequent change is allowed and the elevated performance is sustained.
The word breakthrough is obviously a little vague, so in an effort to clarify, Table 2.2 shows real examples of performance change made using Lean Sigma.
Table 2.2 Examples of Breakthrough Change in Healthcare Processes
Project Tiers
How projects are structured, the approach, the resourcing needed, and the quickness of return all depend on the complexity and magnitude of the process(es) being targeted. The complexity of projects can be categorized into three levels or tiers, with Tier 1 being the least complex and Tier 3 the most (see Figure 2.7 on page 38).
Figure 2.7 Project tiers
Tier 1: Projects
Tier 1 projects are those where the process is usually geographically well defined and relatively small in scope. The process can be tackled independently of other processes, with no domino or cascade effect whereby this process issue could not be resolved until other (adjacent) process issues are tackled. The project can be stand-alone. Tier 1 projects are often great training projects, good in the early stages of a Lean Sigma deployment.
The shape of the Tier 1 project may be different based on the type of process problem, whether it be flow related or perhaps an accuracy issue.
If the problem is flow related with a need to accelerate the process, Lean methods are likely the appropriate approach and a Kaizen event an appropriate vehicle.
As an example, a hospital may wish to improve the capacity of its diagnostic imaging department. A Kaizen event might address the velocity of patients through the process and deliver significant results in increased volume, revenue, and patient satisfaction.
Some projects target an improvement in accuracy (or the reliability/robustness of a process), which includes examples such as reduction in incidents of catheter-acquired urinary tract infection (CAUTI), or perhaps a reduction in billing errors in a particular department.
In this case, the problem is not simply one of streamlining or removing complexity. Lean Sigma, over a purely Lean approach, would be more appropriate, with its attention to reducing defects and minimizing variation alongside streamlining the process.
Tier 2: Programs
In contrast to Tier 1 projects, Tier 2 work is more aptly referred to as a program, in that multiple, smaller projects fall under a program umbrella. Tier 2 programs typically address a series of linked processes, often across several departments or functions, but in which there is a single primary flow.
The key characteristic of Tier 2 projects is that the bigger problem can be decomposed into subproblems and projects that are appropriate to tackle and be resolved independently of one another. In other words, they are a group of Tier 1 projects falling under a common umbrella.
A clinical example of a Tier 2 program might be a surgery process, from patient registration to discharge home or to a medical-surgical unit. This represents a relatively straightforward, sequential, linked process, at least from the patient’s perspective. Other clinical examples might include the pharmacy process for medication delivery.
A nonclinical Tier 2 project might be the billing process. Successful completion of billing requires the coordination of many distinct processes across an overarching function. Charge capture is related to the billing process but could become its own Tier 2 project.
A useful approach to tackling Tier 2 projects is to begin with a Discovery event. Here, the overarching process is broken apart into its individual, discrete processes, performance metrics are captured, and projects are appropriately sequenced. Once the discrete subprojects are determined in the Discovery event, leadership collaborates to make decisions about sequencing and methodology for the ensuing program of projects. Some processes may be amenable to single Kaizen events, as in Tier 1. Other processes, however, may be more appropriately addressed by Lean Sigma projects.
Tier 2 programs also often include a VOC element. For example, for a Tier 2 surgery program, the team might interview surgeons and anesthesiologists to understand their experience with the existing processes, determine their key quality indicators, establish a baseline of their level of satisfaction with performance, and identify subsequent opportunities for improvement. These opportunities may form other projects under the program umbrella or serve to strengthen the process knowledge for existing program projects.
Tier 2 projects often call for their own Steering Committee made up of function leaders and process owners. The Steering Committee provides the guidance, support, and clout necessary for success.
A useful approach is to resource a Tier 2 program with a Black Belt as the program lead and multiple Green Belts to run the subprojects under the program umbrella.
Tier 3: Complex Programs
Tier 3 describes large, complex programs within an organization made up of highly interrelated subproblems and processes that cannot be resolved independently of one another. There is a nominal umbrella, but the projects under the umbrella are so interwoven they have to be tackled as a single whole.
An example of a Tier 3 program is one that addresses patient placement and staffing. Such a program addresses multiple functions across the organization and cannot be fully decomposed into subproblems/projects that are resolved independently of one another, in this case:
• Patients categorized by need
• Room type and care requirement
• Patient placement process
• Staff assignment process
• Staffing models
• Patient demand by patient category type
• Skills matrix
Tier 3 programs require significant coordination and management across disciplines and usually follow an organizational redesign and transformation roadmap, not just a simple DMAIC11 approach. They are not something to be tackled by novice change agents, and it is strongly recommended to use either an internal Master Black Belt or an external consultant equivalent.
11. See Chapter 3 for a more detailed understanding of DMAIC.
Identifying Opportunities
Now that we have a little more grounding in what projects represent and how to think about change, let’s turn our attention to identifying opportunities. Our goal is to keep at all times an inventory of meaningful project opportunities in what is commonly referred to as the project hopper.
The sources of the projects aren’t of utmost relevance, since all the projects will be prioritized against a common set of business criteria. The focus is on maintaining a meaningful set of potential projects at all times. It is worth noting that the hopper of potential projects is a source of great value to organizations. In fact, many CFOs, particularly outside healthcare, share the hopper contents and value with stock market analysts as a means of demonstrating their leadership direction and organizational potential and thus suitability as an organization for further investment (and subsequently to drive higher stock prices).
The organizational strategy should always provide a source of strong opportunities to populate the hopper. From the discussion earlier, note that there isn’t a one-to-one relationship of opportunity to project; for example, a single opportunity might represent a Tier 2 program with multiple projects involved. So work is conducted to decompose or deconstruct opportunities into their constituent project parts before they are placed in the hopper and prioritized. This is quite a skilled endeavor, and it is recommended that an experienced hand be involved throughout. It’s also useful to reiterate that opportunities should focus on process, represent a breakthrough change, and be as far as possible cast in a solution-free form going into the hopper.
Strategy isn’t the only source of good projects. Shortfalls in performance in the metrics provide ample projects to fill any organization’s hopper. Many of these performance shortfall opportunities are known already, but it is also useful to purposefully work to “mine” for these kinds of opportunities. This can be done in a number of ways, such as brainstorming in operational leadership team meetings, but a more rigorous route is through the development of an organization-level “Core Process Map.”
The basic premise here is that any hospital or health system, despite having many hundreds of processes, is made up of a relatively small number of core, or mission-critical, processes, which form the fundamental building blocks or foundation. Consider them as the engine room of the organization. Each has an associated start, end, and known deliverables and performance metrics. These processes can be laid out in a high-level block diagram, our Core Process Map, an example of which is shown in Figure 2.8.
Figure 2.8 Core Process Map example
Creation of the Core Process Map requires considerable thought. These are not the typical functions of the business, which obviously aren’t processes as such. An example here is the core process of medication delivery. Multiple functions are involved in this process from physician groups to pharmacy to nursing. The idea is to form actionable “chunks of process” to guide toward performance shortfalls.
For each process, measuring current performance (across the key process metrics) against benchmark or market requirements makes the gaps in performance apparent. These processes are now the opportunities—this is subtle, but very important; the focus is not on the metrics (which are symptoms) but on the processes that contain the causes for the metrics being at their current level. If the process does not change, the metric cannot change for any length of time.
Another source of projects that also links in nicely here is the organization’s financial statements. The profit and loss (P&L) statement, or income statement, can help identify projects to grow revenue and reduce costs. The balance sheet can identify projects to free up cash. Examples of financially driven projects might include the following:
• Revenue growth: Increasing volume of patients, reducing “left without being seen” (LWBS), reducing cancellations, capturing lost charges, reducing contractual allowances
• Cost reduction: Reducing materials usage and obsolescence, reducing staffing costs (including overtime, on-call, and agency costs), reducing returned meal trays, reducing bad debt
• Cash enhancement: Decreasing A/R days, decreasing “discharged, not final billed” (DNFB) days, reducing materials inventory
By focusing directly on financials, the organization can create the means to deliver its strategy per Figure 2.1.
One final source of projects to fill the hopper is suggestions from hospital stakeholders (staff, physicians, etc.), rounding, and external sources such as consultants. These “bottom up” suggestions, as they are known, augment the “top down” projects developed from gaps in performance as related to the strategy. There is often an overreliance on this source. In reality, most frontline staff don’t see enough of the end-to-end overarching context of business processes, and so these suggestions are likely too tactical or low-level. That isn’t to say that all projects identified by this means aren’t valid, but rather just be prepared to sift through a great many suggestions to find a few nuggets.
Characterizing Projects (Preliminary Project Chartering)
Once projects have been identified, in theory the next obvious steps are to prioritize them and launch the most favorable ones. In practice, some work is required to clean up and characterize or clarify each project to enable the prioritization to be performed. Without this work, prioritization often is long and arduous.
Typically this step is conducted by the Program Director and one or more MBBs and involves putting a little more thought into the project focus. Some organizations prematurely hand projects to the Project Leader to put in this level of detail; however, this work should be done at a program level, well in advance of a Belt ever being assigned. In its simplest form, to characterize the project we’ll need to know three things:
• A basic problem statement
• Project metrics and goals
• A likely Champion
This can be considered to be a preliminary Project Charter (a simple document to ensure that all the key players are on the same page regarding the project).
The problem statement should identify what particular problem this project is focused on solving. It will at least include what customers are being affected and what issue is affecting them, what is the impact on the customers, and when the problem occurs—in short, from a business perspective, why we should do this.
The approximate scope of the project is also considered, perhaps not in a precise way but more as a carving of larger endeavors into more manageable project pieces. This undertaking is known as decomposition or deconstruction.
The majority of projects are there to move a key business metric or metrics. Conventional approaches tend to use indicators such as
• Patient satisfaction
• Physician satisfaction
• Employee satisfaction
It is difficult to base improvement on metrics such as patient and physician satisfaction, because they are lagging indicators of the performance of the process. They are also impacted by a vast array of causes in the process and thus are very hard to isolate.
Employee satisfaction also warrants some discussion. Taken to the absurd, if I were trying to improve employee satisfaction, the perfect process environment for staff would be plenty of breaks, big-screen TVs, and Starbucks coffee for everyone. Clearly this is inappropriate. Conventional thinking leads us to believe that happy workers are productive workers. In fact, the reality is just the reverse from a cause-and-effect standpoint. The truer statement is “Productive workers are happy workers.” Thus, a focus on the productivity of meaningful, value-added work is a key driver of employee satisfaction. If the process is streamlined and the work is clearly valued, workers are generally happier.
Another common metric approach is the use of percentiles relative to (similar) benchmarked organizations. They are useful for communication if we are doing well relative to others, but in practice they are poor guides. Even if we improve to the 99th percentile, so what? Is that good enough from a business perspective? Percentiles don’t tell us in raw terms how much we need to improve or have the granularity we need from a metric. For example, when considering incidents of ventilator-associated pneumonia (VAP), zero incidents equate to the 99th percentile, and one incident might put you below the 50th percentile. Percentiles are also tough because they are moving targets—our raw performance can remain the same, but our percentile score can change as the performance of others in our benchmark group changes. For the most part they aren’t specific enough and they’re not actionable—it’s important to get to the metrics behind the metrics.
Another ubiquitous approach is the use of compliance metrics, whereby the organization measures staff compliance or adherence to doing a particular process step or practice. These are typically used in lieu of process metrics. While this approach has worked well in many instances, such as VAP, it often overengineers the process (adds steps without improving performance).
Mostly the issue relates to the fact that even if there is compliance with an approach to 100%, so what? It’s useful at this point to refer to a key foundation of Lean Sigma. Many process performance indicators measure outcomes of a process—let’s call these our “big Y” measures. These Y measures are actually driven by many factors in the process—let’s call these Xs. What we realize is that our Ys are just functions of the many Xs in the process, or in other words, they are just symptoms. All of these Xs probably impact the Y to some degree, but only a handful of Xs really make a big difference. The trick is to find the critical X or Xs and focus on those.12
12. A wonderful example of this is described in the admission assessment case study in Chapter 4, where the simple X of whether the nurse hands off his/her phone to a colleague drives more than half of the process duration.
Compliance often relates to a single X, which is just one of many and does not necessarily make a big impact on the performance measure Y; it isn’t a critical X. A great example of this is the drive to comply with certain basic approaches such as AIDET13 (Acknowledge, Introduce, Duration, Explanation, and Thank) to improve patient satisfaction. AIDET likely does have value in many cases, but the project is better framed in the light of the real reason for poor patient satisfaction, which could relate to many more overriding operational factors such as length of stay, number of stops in the process, capacity, accuracy, and so on. The tendency to keep revisiting the same X again and again to try to move the satisfaction measure will continue to be fruitless.
13. AIDET is a registered trademark of The Studer Group, LLC.
The obvious impertinent question here is why measuring whether someone actually did his or her job is a performance measure at all.
Thus, metrics used in developing and scoping Lean Sigma projects
• Relate to the performance of a single process (not an amalgamation of many processes)
• Are raw numbers, not percentiles
• Relate to the Ys for the process, not potential Xs (outcomes versus compliance)
Some examples include
• Lead time (e.g., the time it takes for a patient to progress the length of the process, such as a length of stay)
• Left without being seen
• Cycle time (e.g., the time between patients as they pass a certain point in the process, such as patient in to next patient in)
• Throughput (e.g., the number of patients processed per hour)
• Accuracy (e.g., percentage of orders processed correctly)
• Work content (e.g., hands-on time spent by a nurse per patient)
Setting Goals
Accompanying the metrics are the associated goals. Goal setting is a key difference in Lean Sigma, and if it is done right, it can dramatically impact program results.
Consider a common scenario, an emergency department with too long a length of stay (LOS). The current average is approximately 5 hours. The ED leadership have worked for some time to reduce the average and are now at the point of considering a Lean Sigma project to reduce the time further.
Traditional goal setting takes into consideration the struggle to this point and would seek to reduce the LOS by a reasonable amount, say, 30 minutes, the assumption being that if the team did manage a 30-minute reduction, perhaps they could work harder to squeeze a bit more reduction.
In reality it never seems to work this way. We try to make everyone aware of the problem and hope they’ll work harder and make the difference. In reality we won’t have fundamentally changed anything.
Let’s take the analogy of a diet. I’ve been trying to lose 5 pounds for some time now. I do well for a week, or sometimes two, but then I always seem to slip back. Trying to lose 5 pounds is very tough. A few years ago my physician informed me of an elevated cholesterol problem. He advised me that I needed to change and change quickly. I looked at what I ate and just cut out all of the foods with high cholesterol content. I exercised a little more frequently, not much but something I could maintain. In short, I changed my lifestyle. I dropped my cholesterol from 285 to 135 (obviously a big relief), but also as a by-product I shed about 40 pounds in three months. It was actually much easier to do.
The same principle applies to Lean Sigma goal setting. Aim low and you’ll probably not achieve it, achieve it and not value it, or struggle to maintain it. Aim for some loftier goal and there’s a higher chance of achieving it and you’re much more likely to maintain it. Another aspect of setting that high goal relates to staff and team engagement. The better goals are actually ones that induce responses like “That’s not going to happen” or “You’re nuts.” If people don’t know how to achieve a goal, they are much more likely to engage when we say we have the roadmap that will do it, and also they are less likely to independently attempt to achieve it themselves.
So how do we identify that lofty goal without being unrealistic? The approach taken is through the use of a concept known as entitlement. Entitlement is the best a process could ever be—perfection. For some metrics this is fairly straightforward:
• Yield: 100%
• Accuracy: 100%
• Scrap: 0%
• Defects: 0
• Errors: 0
• Cost of poor quality: $0
For other measures, it’s a little trickier; for example, a round of golf has an entitlement of 18 (one shot per hole), not par as many people guess. For a process metric such as capacity, one approach might be that if we’re running at 100% of capacity, the process is up all the time (zero downtime), going as fast as it has ever gone, and no time is spent doing rework.
Once we’ve identified the entitlement for the metric, we do not set that as the project goal. It would be wholly inappropriate to ask a Project Team to deliver perfection. Instead, the recommended approach is to set the goal at 50% of the way between the current performance and entitlement. For example, if current registration accuracy is 92%, the goal would be 96% (halfway between 92% and 100%). We often might also see a stretch goal of three-quarters of the way. In our registration example this would equate to 98% accuracy.
Prioritizing Action
As we know from any other project work, in pretty much every organization there just aren’t enough change resources to form teams for all projects, and it is important not to stretch resources too thinly. It is much better to tackle a few projects and complete them quickly and efficiently than to tackle large numbers of projects in unison and have them drag out over months. Some prioritization is needed.
Thus, once the opportunity processes have preliminary charters, they are placed in the project hopper and prioritized. This is done by rating the projects in the context of the major business metrics as shown in Figure 2.9, or even just on a simple urgency/benefit grid. Once the opportunities are prioritized, the top (more strategically important) projects focused on key process opportunities are obvious. Consideration of additional factors, such as cost, risk, and resource requirements, can help you fine-tune the selection. Projects are then chosen, teams are allocated, and projects commence.
Figure 2.9 Project prioritization matrix
Program and Project Roles
At this point, let’s assume we have selected a project and the approach will be to improve the target process, so we will need resources to launch the project to achieve this. Each Lean Sigma project has a
• Project Champion(s)
• Process Owner(s)
• Project Leader known as a Black Belt or Green Belt
• Team
The Project Champion is the sponsor for the project. The Champion should in essence be a customer14 of the project and be senior enough in the organization to own the resources involved in the project and to remove barriers as the project progresses. Sometimes the Champion is the Process Owner (see below), but often not. There may be more than one Champion if the process crosses multiple functional boundaries. For example, for a medications delivery project, the Champions would perhaps be the director of nursing or preferably the chief nursing officer over the nursing units, along with the vice president over the pharmacy. If the project scope were to include physician activity, the chief medical officer would be a third Champion.
14. If the project is successful, the numbers by which the Champion is appraised will improve and therefore the Champion is aptly engaged.
Clearly these are very senior people in a hospital, but this is the level of support needed (especially in the early stages of a Lean Sigma program) to drive results. If this level of individuals is not interested in the project, the project probably isn’t strategically important to the organization and the organization would be better served by selecting a different project to tackle.
The Project Champion meets early with the nominated Project Leader to define the project using a Project Charter. Project Leaders are known as Belts in Lean Sigma and typically fall into three categories:
• Master Black Belts: These are full-time resources who may undertake project work for perhaps half their time but are generally focused on mentoring other Belts through their projects, training new Belts, and leading awareness sessions for the hospital staff or helping manage the Lean Sigma program. Master Black Belts earn their stripes as Black Belts for at least two successful projects and then are trained with an additional three or more weeks of training in leadership, technical, and teaching skills.
• Black Belts: These are typically full-time resources whose primary focus is project work. Black Belts are trained for four weeks in the roadmap and tools described in Chapter 4. Black Belts can lead projects autonomously, and they quickly become skilled change agents. The projects undertaken can involve processes crossing multiple departments and be very complex in nature, both technically and organizationally.
• Green Belts: These are part-time Project Leaders. Due to the part-time nature of the role, the ongoing project learning cycles they have are less and so it’s trickier for them to follow up on complex business issues and also to maintain a deeper skill base on the more complex Lean Sigma tools. For these reasons, they are restricted to fixing smaller pieces of a target process, or they are focused on smaller, simpler processes, perhaps within a single hospital function rather than across multiple functions. They thus have a lesser tool set (which still allows them to streamline processes and identify root causes of issues and resolve them). Training lasts for two weeks.
Both Master Black Belts and Black Belts (given that they have a full-time role) would report to a Program Director (typically a member of the Executive Team). In the early stages this role is played by a vice president or chief operating officer or similar.
Some organizations opt for a number of other Belt colors to represent other levels of experience such as awareness or the participation of an individual on a Lean Sigma team. Here we’ll stick to the three main categories.
The Process Owners for the target process are the functional leaders for the areas that are crossed by the process. For the medications delivery process mentioned earlier, the Process Owners might be a care unit nursing supervisor and the pharmacy director.
The Team, as determined by the Project Champion, Process Owner, and Belt, is composed of key representatives from the functions involved in the process. The most apt Team members are those folks who “live and breathe” the process every day. They should be respected by their peers, since once the solution is constructed, there should be confidence among those not participating that their needs have been represented. The Team should be somewhere between three and seven members plus the Belt. Any more than this will make the Team unwieldy. Having a large Team isn’t really a showstopper, but if necessary the Team can be whittled down by using multifunction resources—perhaps people who have experience in more than one discipline. The Team may also be augmented by ad hoc members, brought in to participate in certain tool applications or to validate process understanding. Teams contain all the right resources (at least in an ad hoc form), including operations, compliance, and clinical quality if appropriate. Note that the Project Champion and Process Owners are for the most part not included in the Team to ensure that Team innovation and objectivity aren’t stifled by any sense of having to “say the right thing in front of the boss.”
Lean Sigma differs from many typical project approaches in that the work is done in the Team meetings rather than between meetings, and any full Team interaction is focused mainly on progress reporting and planning the next actions. Hence, once the Team is formed, members meet for at least half a day, or preferably a whole day, per week, led and facilitated by the Belt. This is clearly a significant commitment and is often seen as a formidable request in novice Lean Sigma organizations. Remember, though, that the projects that might normally be under way in a fragmented form have been consolidated into a few well-managed, contained undertakings. Whole-day sessions generally make it easier to plan and backfill for staff involved.
There is sometimes a tendency to “shortchange” Teams by placing only available resources versus the right resources, or just allowing a Team member to participate when or if available. Having the right Team members is absolutely critical. Team members also need to be consistent for the duration of the project and not swapped in and out. The project work is a sequence of learning, so having a continuity of players is critical. Team members need to be freed up completely by backfilling or offloading their other activities or commitments. If the project is strategically important, it needs to be resourced accordingly. If resources aren’t available, the Executive Group needs to take an interest in what other activities are under way and determine if any projects can be furloughed or consolidated.
In addition to the project roles, there are some key program-level roles. These include the Steering Group roles mentioned earlier (executives, program leader or director, financial analyst, HR, etc.) but also communication and education coordination.
For each role described, a key aspect of Lean Sigma is the competency required to conduct the role. Consider each role as a seat to sit in. Anyone sitting in the seat has identified accountabilities (goals and activities) and the associated competencies (and level thereof) to achieve those goals. Competency isn’t considered just from the perspective of having it or not, but also by the degree or level of skill. Many in the organization may just need an awareness of or be oriented in a skill; some will need a higher level of skill to participate; some will need to be skilled in order to lead; some need to be skilled enough to teach; and at the highest level a few might be skilled enough to change the method itself.
Training, some of it quite substantial, is thus a key part of any Lean Sigma deployment to ensure that new competencies are ingrained. Chapter 5 deals more with the details of how this is planned and undertaken.
Program Tracking, Reporting, and Ongoing Management
Managing the program on an ongoing basis involves managing across the portfolio of individual projects, and hence tracking and communicating (reporting) project status and results are an integral part of any Lean Sigma program. Lean Sigma projects follow a phased and gated roadmap, so it’s possible to know the status of any and all projects at any time. Champions and Belts are required to report this status, typically on a monthly basis, to the Steering Group. Champions and the Steering Group manage the resource across the portfolio accordingly to remove roadblocks and ensure that projects progress in a timely fashion.
Financial tracking of implemented projects ensures that results are realized but also sustained in the months after each project closes.
Ongoing communication of project and program status and results to key stakeholders (leaders, staff, the Board of Trustees, etc.) ensures that the program continues to receive the attention it needs and to bear fruit. Such communication includes simple monthly statements and newsletters, CEO briefings, leadership updates, operational huddles, and annual reports.
Summary
In simple terms, Lean Sigma as a program installs the key infrastructure elements that ensure that change is conducted and managed, meeting the criteria described in the first pages of this chapter—namely, that change is
• Transparent and contained
• Aligned with the business purpose and direction
• Balanced and meaningful
At the program level these elements ensure that projects are managed within a broader framework that helps leaders prioritize, adjust timing and resources, track, report, and respond to make needed course corrections.
At the project level, we’ll see in Chapter 3 how Lean Sigma ensures that change is
• Made in light of appropriate context
• Appropriately scoped and focused
• Lasting and sustainable