Watch the webinar here:
Check out the slides:
The word transformation gets used so loosely in continuous improvement work that it has almost lost its meaning. Organizations announce transformations the way they once announced initiatives. The transformation usually consists of a Lean tools rollout, a few high-profile rapid improvement events, and some new dashboards. Five years in, the organization has changed some, but the deeper work of building the infrastructure that connects strategy to operations and operations to daily improvement remains undone.
Roger Chen's session is a corrective. Drawing on more than thirty years of experience -- starting at General Electric as a Six Sigma Master Black Belt and senior Lean value stream manager, then leading performance improvement at Martin Memorial Health System, Lee Health, and now as Executive Director of Lean Transformation at Indiana University Health -- Roger lays out a framework for understanding transformation as a continuum rather than as a destination. The continuum runs from the foundational work of standardizing processes through improvement, spread, and ultimately to innovation. Each stage requires different capabilities, different tools, and a different relationship between Lean methodology and project management discipline.
What makes the session particularly useful is Roger's insistence that process improvement and project management are complementary disciplines that most organizations treat as separate. Process improvement people often haven't been trained in classical project management. Project managers often haven't been trained in Lean. The work of transformation requires both, deliberately combined, applied at the right scope and scale for the situation. Without both, organizations either run projects that don't produce real improvement or run improvement work that fails to sustain.
Roger Chen serves as Executive Director of Lean Transformation at Indiana University Health, a multi-hospital health system serving Indiana. He has more than thirty years of experience in improvement and leadership roles, including extensive work at General Electric where he reached the level of Six Sigma Master Black Belt and Senior Lean Value Stream Manager. After GE, he led performance improvement and transformation work at Martin Memorial Health System and Lee Health before joining IU Health approximately two months before this session. He is a certified Six Sigma Black Belt and Master Black Belt with a unique background bridging classical quality frameworks (including ISO 9001:2000 certification work and Joint Commission compliance) and Lean enterprise thinking. He holds a B.S. in Electronics from DeVry Institute of Technology and an International MBA from Nova Southeastern University. He has been invited to speak to healthcare institutions in the United States and Latin America on integrating Lean thinking and leadership development.
The session is hosted by Mark Graban, then VP of Improvement and Innovation Services at KaiNexus and the author of Lean Hospitals, Healthcare Kaizen, Measures of Success, and The Mistakes That Make Us.
The most useful single move in Roger's framework is the reframing of transformation itself. Most organizations treat transformation as an event or a state -- something you launch, work on for some period of time, and eventually arrive at. Roger's framing treats transformation as a continuum of distinct stages, each with its own prerequisites and its own work.
The stages, in sequence:
Standardize. Establish reliable, documented standard work for the processes the organization runs. Without standardization, there is no baseline to improve from and no way to detect whether improvement has actually occurred.
Improve. Apply Lean and process improvement methods to the standardized processes to make them better -- faster, less wasteful, higher quality.
Spread. Move the improvements from where they were developed to other parts of the organization that could benefit. Most organizations are better at creating improvements than at spreading them.
Innovate. Build on the foundation of standardized, improved, spread practices to develop genuinely new ways of working that the organization couldn't have conceived of before.
Roger is direct that most organizations get this sequence wrong. The classic Lean training emphasizes improvement -- value stream mapping events, kaizen events, rapid improvement workshops. Organizations launch immediately into the improvement work without first developing the standardization that makes improvement measurable, or the spread infrastructure that makes improvement scalable.
His Zen-influenced framing: maybe we should shift our focus and go backwards down the path. Understand the environment for standardizing process. Build the processes for spreading process. Recognize that improvement work matters, but that it's only one stage of the continuum. And recognize that innovation -- the stage every organization wants to claim it has reached -- depends on the foundation work of standardize, improve, spread. Innovation grows from soil that has been tilled. The tilling is the prerequisite.
This framing matters operationally because it tells organizations where to invest their attention. An organization that is genuinely at the standardization stage shouldn't be running kaizen events on processes that have no documented standard. An organization that is improving well but failing to spread improvements should be investing in spread infrastructure, not in more improvement events. An organization that has the foundation built well can credibly pursue innovation. The diagnostic of which stage you're actually in determines what the next investment should be.
Once the transformation continuum is named, Roger moves into the structural framework that connects strategic intent to daily work. The taxonomy he uses moves from the highest level down to the most specific:
Portfolio (strategic plan / pillars). The organization's overall set of strategic priorities, often organized into pillar areas. For IU Health, the priorities Roger names are improving healthy outcomes, improvement and innovation that supports margin, first-year turnover, and stewardship of significant construction activity.
Strategic initiatives. The major thrusts within each portfolio area that the organization is actively pursuing.
Programs. The longer-term efforts that allocate significant capital and people resources, often spanning multiple years. Programs are the operating unit of strategic deployment.
Projects. The defined-scope, defined-timeline efforts that produce specific outcomes within programs. Each project has a start date, an end date, a defined deliverable, and an owner.
Tactics (major projects or system value streams). The actual work happening on the ground, which can map to value streams or to specific major project workstreams.
Roger's specific qualification matters: he isn't trying to follow PMI's Project Management Body of Knowledge convention rigidly, and the taxonomy he uses has variations across organizations. The specific names matter less than the principle, which is that strategic work has layers, and the layers have to be deliberately connected. A project that isn't tied to a program isn't tied to anything strategic. A program that isn't tied to a portfolio area is loose. The chain from portfolio down to tactics is what makes strategy deployment real rather than aspirational.
One observation Roger pulls out specifically: programs are where some organizations get confused. Programs tend to be the longest-running and largest-scope units of work, often spanning years, often consuming significant capital and people resources. The electronic medical record rollout in many health systems is a program -- it spawns dozens of projects, runs for years, and has its own internal portfolio of work. The same is true of construction programs, regulatory programs (the CMS five-star rating work or hospital-acquired conditions reduction), and major operational transformations. Understanding programs as a distinct level between strategic initiatives and projects is part of what makes the taxonomy useful.
Most Lean practitioners are deeply familiar with PDCA (or PDSA -- plan, do, study, adjust). Roger introduces a modification that puts two additional phases in front of the traditional Plan step:
Plan Scope. Define the project resource mix the organization is willing to commit. Identify stakeholders, milestone reviews, dependencies, and support function involvement (IT, HR, legal). Assess the cultural acceptance of the type of change being considered. This phase prepares for the change management and training work that follows.
Plan Scale. Define the intended impact -- the outcome to be achieved, the number of people who will be affected, the magnitude of the benefit (quality improvement, cost reduction, customer experience, staff experience).
Plan (traditional). Design the countermeasures to be implemented.
Do, Check, Adjust (traditional). Run the experiment, evaluate the results, adjust accordingly.
The expansion matters because most organizations skip directly to the traditional Plan phase without doing the scoping and scaling work first. The result: improvements that lack the resources to succeed, that scale incorrectly when they do succeed, or that fail to translate into the broader organizational change they were intended to produce.
Roger's point about the scope phase is particularly sharp for rapid improvement events. A rapid improvement workshop is, as he frames it, a very complex project on a highly compressed timeline. Because the timeline is compressed, the project management fundamentals become more important, not less. There is no slack to recover from poor scoping. The work that should have been done in a deliberate scoping phase gets compressed into the days before the event, and any gaps in stakeholder analysis, dependency mapping, or resource planning show up as friction during the workshop itself.
For complex environments like healthcare -- with clinical dependencies, license requirements, and longer cycle times for tests of change -- the standard one-week rapid improvement event may not be the right format at all. Roger suggests that some work is better structured as a series of sprints with defined cycles and reporting periods, rather than compressed into a single workshop week. The format follows from the scoping. The scoping has to come first.
The single sentence worth pulling out of Roger's session: a rapid improvement workshop is simply a very complex project on a highly compressed timeline.
The framing changes how practitioners think about rapid improvement events. Most Lean training treats RIEs as their own category of work, with their own methodology and their own success patterns. The framing is useful but incomplete. RIEs are also projects -- with stakeholders, dependencies, deliverables, and risks -- and the discipline of project management applies to them more, not less, because the timeline compression eliminates the ability to recover from project slip.
The implication: process improvement practitioners running RIEs need solid project management skills. Pre-workshop scoping needs to be rigorous. Stakeholder analysis needs to be complete before the workshop starts. Support function dependencies need to be identified and aligned. The change management and communication plan needs to be developed before the workshop, not improvised after it.
The other implication: project management practitioners running large projects need solid Lean and process improvement thinking. Without it, the projects produce technical outputs that fail to translate into actual operational improvement. The integration isn't optional. Both disciplines are necessary, and neither is sufficient.
A statistic Roger references is worth pausing on. When he first started learning project management, the commonly cited figure was that more than 90% of projects either missed their deadline, went over budget, or failed to deliver on scope. His current sense is that the number has gotten worse, not better -- probably more than 95% now.
The numbers are imprecise (no rigorous source for the exact figure), but the directional point is correct and supported by multiple Project Management Institute studies and similar industry research over the years. The underlying issue is that most projects fail at one of the three constraints (time, cost, scope) even when they technically deliver something. The work of project management is largely the work of bringing more projects closer to on-time, on-budget, on-scope delivery -- which is itself a form of improvement work.
The implication for Lean practitioners: the project management failure rate is also the rapid improvement event failure rate, in a sense. RIEs that go over their planned scope, that miss their planned outcomes, or that fail to sustain are subject to the same dynamics that make most projects fail. The disciplines that improve project success rates -- rigorous scoping, stakeholder alignment, milestone reviews, change management -- improve RIE success rates too. The fact that an RIE has a compressed timeline doesn't exempt it from these disciplines. It makes them more important.
The intersection Roger highlights repeatedly is the relationship between process improvement professionals and project management professionals. Both disciplines are necessary for transformation. Neither is sufficient on its own. And they're often held by different people in different functions, with different training, different vocabulary, and different stakeholder relationships.
The classic patterns Roger names:
Process improvement professionals (Lean facilitators, Six Sigma Black Belts) are deep in the technical tools of improvement -- value stream mapping, root cause analysis, A3 thinking, statistical process control. They may not have been trained in classical project management -- scope definition, stakeholder analysis, dependency mapping, change management. When they run into resistance, they often diagnose it as cultural or political when it's actually a project management gap.
Project management professionals are deep in the technical tools of project management -- Gantt charts, milestone reviews, resource allocation, risk management. They may not have been trained in process improvement methods. They run projects that deliver technical outputs that fail to translate into operational improvement. They wonder why the dashboard they built doesn't get used.
Roger's diagnosis: both are necessary, neither is sufficient. The work of transformation requires the combination. Some of this happens through training -- exposing process improvement practitioners to classical project management discipline, and exposing project managers to Lean thinking. Some of it happens through deliberate team composition -- pairing PI practitioners with PM practitioners on significant initiatives. Some of it happens through organizational design -- structuring the Transformation Office so that both disciplines are represented and integrated.
For IU Health specifically, the Transformation Office Roger describes has three programs that hold this integration deliberately:
A Quality Resource Center that supports anyone in the organization doing quality and process improvement work, providing technical consultation and connection to specialist resources.
System Initiative Deployment that handles the strategy-to-operations work, applying both process improvement and project management discipline to the work of executing strategic initiatives.
A Training Institute that develops both the internal process improvement team and the broader leadership population, in partnership with the IU Health Leadership Academy.
The three programs together form what Roger calls the engine for transformation. The integration of process improvement with project management with leadership development is the operating model.
One of the most useful contributions in the live Q&A comes from Jessie, a physical therapist on Roger's IU Health team. She offers a healthcare-specific nuance that's worth surfacing because it's easy to miss when applying Lean frameworks built for manufacturing.
Her observation: healthcare can't have standard work for everything because every patient is unique. A physical therapist never has a textbook patient. Clinicians constantly use clinical judgment to determine what each individual patient needs. The work isn't really about making every clinical interaction standard -- it's about developing the processes around the interaction so that the parts that should be standard are reliable, while preserving the clinical judgment that has to remain flexible.
The reframe is important. Standardization in healthcare isn't about making clinical care identical. It's about making the supporting processes reliable enough that clinicians can focus their judgment where it matters. Medication administration processes should be standard. The clinical decision about which medication to administer remains clinical. Patient identification processes should be standard. The clinical assessment of the patient's condition remains clinical. The distinction matters because Lean transformations that try to standardize too far in healthcare hit resistance from clinicians who experience the standardization as an attack on their professional judgment. The transformations that succeed are the ones that standardize the right things and leave the rest to clinical expertise.
Roger's transition from manufacturing to healthcare gives him a useful perspective on this. He notes early in the session that comparing healthcare to manufacturing is unfair -- it's not a compare-and-contrast situation. Healthcare is its own thing, with its own complexity, its own constraints, and its own appropriate applications of Lean methodology. The frameworks transfer, but they have to be adapted with respect for what makes healthcare different.
Roger's closing image is the Ouroboros -- the ancient symbol of a snake eating its own tail, representing infinite cycles. He uses it to represent the connectivity between the levels of work he's been describing.
An idea, captured in a continuous improvement system, can be the equivalent of a task -- something a single person does by a specific date. Or it can grow into an opportunity for improvement (an OI in KaiNexus terminology), with a short-term project timeline (30-90 days), discretionary manager resources, and specific outcomes. Or it can tie into a program with more substantial capital and people resources, often running for multiple years. Or it can become significant enough to be recognized as a strategic initiative, allocated against the organization's portfolio of strategic priorities.
The infinite connectivity matters because it inverts the usual assumption about how transformation works. Most organizations think of strategy as something that flows downward -- senior leaders set direction, the direction translates into initiatives, initiatives translate into programs, programs translate into projects, projects translate into tasks. The Ouroboros says the flow goes both directions. Frontline ideas can become strategic initiatives if the connection infrastructure exists. Strategic priorities can become daily tasks if the deployment infrastructure exists. The relationships between the levels are continuous and bidirectional.
The implication for the platform infrastructure: organizations need systems that can capture work at any level (an individual idea, a task, an OI, a project, a program, an initiative) and connect it to the appropriate level above and below. A continuous improvement platform that only handles ideas at the frontline isn't enough. A strategy deployment platform that only handles initiatives at the top isn't enough. The connection infrastructure is what makes the Ouroboros operate as a working system rather than as a metaphor.
The connection between Roger's framework and KaiNexus is unusually direct because the platform was designed around the principle of connecting work at multiple levels.
The dashboard structure Roger describes -- with strategic focus areas at the top, program panels below them, and projects within programs -- maps directly onto how the platform organizes work. Strategic initiatives can be set up as dashboards. Programs can be set up as the next level of organization beneath them. Projects and OIs live within programs. The hierarchy that Roger's taxonomy describes can be operationalized in the platform structure.
The bidirectional connectivity -- ideas growing into projects, projects rolling up into programs, programs aligning with strategic initiatives -- depends on infrastructure that handles each level and links them. The platform handles this through its program-and-project structure. An idea captured by a frontline worker can be developed into an OI, can be assigned to a project, can be associated with a program, and can be visible at the strategic initiative level. The growth path doesn't require manual translation between systems.
The strategy deployment work Roger describes -- particularly the hoshin kanri-style cascading of priorities from executive level down to operational tactics -- is what the platform's strategy execution features are designed to support. The X-matrix that maps strategic priorities to programs to projects to KPIs can live in the platform, with the actual work tracked against the strategic intent.
The spread infrastructure Roger emphasizes -- making best practices visible across the organization so they can be replicated -- is a core function of the platform. When an improvement is completed in one facility or department, the documentation lives in a system that other facilities can find. The spread isn't dependent on someone remembering to share it.
The standardization work that Roger places at the foundation of the transformation continuum benefits from the platform's standard work and process documentation features. Standards can be documented, versioned, and made accessible. Updates to standards can be tracked.
None of this substitutes for the disciplines Roger describes. The taxonomy, the expanded PDCA, the integration of process improvement and project management -- these are organizational practices that no platform can perform on its own. The platform provides the infrastructure on which the practices operate. The practices are what produces the transformation.
Roger Chen serves as Executive Director of Lean Transformation at Indiana University Health. He is an organization transformation and change management coach with extensive experience in quality improvement, operations management, and leadership development. He graduated with a B.S. in Electronics from DeVry Institute of Technology in 1986 and earned his International MBA from Nova Southeastern University in 1999. As a certified Six Sigma Black Belt and Master Black Belt, he brings an unusual understanding of the transition from classical quality frameworks to Lean enterprise thinking. He has led ISO 9001:2000 certification work, Joint Commission compliance work, and technology team development, and has been invited to speak to healthcare institutions in the United States and Latin America on integrating Lean thinking and leadership development. He spent significant earlier years at General Electric, reaching the level of Six Sigma Master Black Belt and Senior Lean Value Stream Manager, before transitioning to healthcare. Prior to IU Health, he led performance improvement and transformation work at Martin Memorial Health System and Lee Health.
What is the transformation continuum?
A framework for understanding transformation as a sequence of stages rather than as a single program or destination. The stages are standardize, improve, spread, and innovate. Each stage has prerequisites in the stages before it. Organizations that try to skip directly to improvement without first standardizing tend to produce gains that don't sustain. Organizations that try to claim they're innovating without having spread the improvements they've made tend to be doing one-off heroic work rather than systematic innovation. The continuum framing tells organizations where to invest their attention based on what stage they're actually at.
Why does rapid improvement event work require strong project management?
Because a rapid improvement workshop is fundamentally a very complex project compressed into a short timeline. The compression eliminates the ability to recover from project slip. Any gaps in pre-workshop scoping, stakeholder analysis, or dependency mapping show up as friction during the workshop itself. The disciplines of classical project management -- defining scope clearly, identifying stakeholders, mapping dependencies, planning for change management -- become more important under timeline compression, not less. RIEs that fail usually fail because the project management work that should have happened before the workshop got skipped.
What's the difference between scope and scale in Roger's expanded PDCA?
Scope is the project resource mix the organization is willing to commit to the work -- the people, the budget, the time, the support function involvement, the cultural readiness. Scale is the intended impact of the work -- how many people will be affected, what magnitude of outcome is being targeted, how broadly the change will operate. Most teams skip both phases and go directly to the traditional Plan step, which produces improvements that lack the resources to succeed or that scale incorrectly when they do. Adding scope and scale as explicit pre-planning steps catches these gaps before they cause downstream failure.
Why is it important to distinguish projects from programs from strategic initiatives?
Because they call for different management approaches. A project has a defined start, end, and deliverable. A program is a longer-term coordinated set of related projects, often consuming significant capital and people resources over years. A strategic initiative is a major thrust within the organization's portfolio of strategic priorities. The terms get used interchangeably in many organizations, which produces management confusion. Different work requires different governance, different resource allocation, different decision-making rights. Naming the level explicitly helps the organization apply the right discipline to the right work.
Why is the relationship between process improvement and project management so important?
Because they're complementary disciplines that most organizations treat as separate. Process improvement practitioners often haven't been trained in classical project management. Project managers often haven't been trained in Lean thinking. Successful transformation requires both, deliberately combined. The gap between the two disciplines shows up as projects that produce technical outputs without producing real operational improvement, or as improvement work that fails to scope and scale properly. The integration isn't optional. Both are necessary, and neither is sufficient.
How does this framework apply in healthcare specifically?
Healthcare adds important nuances. The clinical work has irreducible variation -- every patient is unique, clinical judgment can't be standardized out of the process, and clinicians push back hard against transformations that try to standardize their professional judgment. The right framing is that standardization in healthcare is about the supporting processes around clinical work, not about the clinical work itself. Medication administration processes should be standard. The clinical decision about which medication remains clinical. The framework works in healthcare; the application has to respect what makes healthcare different from manufacturing.
What is the Ouroboros metaphor Roger uses, and what does it tell us about strategy deployment?
The Ouroboros is the ancient symbol of a snake eating its own tail. Roger uses it to represent the connectivity between levels of work -- ideas can become tasks, tasks can become opportunities for improvement, OIs can become projects, projects can roll up into programs, programs can align with strategic initiatives, and the relationships flow in both directions. Most strategy deployment thinking imagines the flow as one-way (top down). The Ouroboros says the flow is bidirectional. Frontline ideas can become strategic initiatives if the infrastructure exists. Strategic priorities can become daily work if the deployment infrastructure exists. The platform infrastructure that supports both directions is what makes the bidirectional flow operational.
How does Roger's IU Health Transformation Office structure the work?
Through three integrated programs. A Quality Resource Center supports anyone in the organization doing quality and process improvement work, providing technical consultation and connecting practitioners to specialist resources. System Initiative Deployment handles the strategy-to-operations work, applying both process improvement and project management discipline to the execution of strategic initiatives. A Training Institute develops both the internal process improvement team and the broader leadership population, in partnership with the IU Health Leadership Academy. The three programs together form what Roger calls the engine for transformation.
.svg)
Copyright © 2026
Privacy Policy