70 change concepts: how to generate improvement hypotheses.

Change is not synonymous with improvement.

Organizations change constantly: they add approvals, automate activities, change targets, reorganize teams, create forms and replace suppliers. Yet the existence of a change does not demonstrate improvement. Improvement requires a defensible relationship between an intervention and a better system outcome.

This distinction sits at the center of the Model for Improvement, developed by Associates in Process Improvement and disseminated by the Institute for Healthcare Improvement (IHI). The model asks three questions: What are we trying to accomplish?, How will we know that a change is an improvement?, and What change can we make that will result in improvement?. Change concepts primarily support the third question by widening the space of possible interventions before a team jumps to the first available solution.

A change concept is not a ready-made solution. It is a lens for generating intervention hypotheses.

The reference material supplied to Struckel groups 70 concepts into nine families. The second edition of The Improvement Guide, as currently referenced by IHI, lists 72 concepts, showing that the taxonomy evolved over time. The principle remains: combine general change notions with local subject knowledge to create specific ideas that can be developed, tested and evaluated.

Concept, idea and test are different levels of reasoning.

The appendix used as a source makes an important methodological distinction. Concepts such as reduce intermediaries, perform tasks in parallel or use sampling are intentionally general. They should not be implemented literally. They must first be interpreted in the context of the process, customer, risk and constraint to be changed.

A rigorous sequence can be expressed as:

Change concept → contextualized idea → operational change → prediction → measure → PDSA test → decision.

Consider a commercial process in which proposals above a threshold go through four sequential approvals and take 52 hours on average. “Reduce system controls” does not mean removing governance indiscriminately. A specific idea could be to eliminate one redundant approval for low-risk proposals. The operational change could be a one-week test using authority rules based on margin, credit exposure and contractual exceptions. The prediction: reduce lead time from 52 to 30 hours without increasing rework, unauthorized discounts or bad debt.

Learning only exists after execution and comparison of prediction with results. If lead time falls but rework doubles, change occurred — improvement may not have.

Nine families organize the 70 change concepts.

The taxonomy is not a catalogue of independent tools. It groups directions of reasoning that can be combined. Managerially, it behaves as a structured hypothesis generator.

The families prevent an excessively operational view. Performance may be constrained by flow, but also by the work environment, customer interface, service design or variation. The list deliberately pushes teams beyond their usual solution repertoire.

The 70 change concepts — complete list.

The family-level synthesis is useful for orientation, but the practical value comes from reviewing the complete repertoire. Below are the 70 concepts from the reference material supplied to Struckel, preserving their numbering and nine-category structure. Each concept is a direction for generating hypotheses, not an implementation instruction: it should be translated into a context-specific idea, linked to a prediction and tested before scale-up.

How to use the list: do not try to “implement a concept” literally. Select one, translate it into a concrete change for the process, state the expected causal mechanism, record a prediction, define outcome and balancing measures, and test at a scale compatible with risk.

Apparent conflicts are a feature, not a flaw.

Some concepts intentionally point in opposite directions. The source highlights, for example, reduce feature choices versus mass customize; or reduce controls versus standardize. There is no logical contradiction when the analysis starts from context.

Reducing options may be economically sound when variety increases inventory, errors and cost without increasing perceived value. Customization may be better when segments have substantially different needs and are willing to pay for fit. Likewise, removing redundant approvals can shorten cycle time, while formalizing a critical process can reduce variation and risk.

This is a marker of management maturity: tools and concepts do not make decisions; they structure decisions. Teams must state the condition under which a direction is expected to produce a favorable effect. That condition is part of the hypothesis.

Directed and random selection create different kinds of learning.

The guide proposes complementary logics. Directed selection chooses a concept or family clearly related to the improvement aim and tends to produce useful ideas quickly. Random selection deliberately forces the group to consider an apparently unrelated concept and ask how it might apply.

Random selection is a divergence technique: it disrupts habitual associations and can produce alternatives that ordinary discussion would miss. It does not remove criticism. After generation, ideas still need to be assessed for causal plausibility, risk, cost, testability and measurement.

A robust workshop separates two moments: first diverge without judging, then converge with criteria. Mixing creation and criticism too early narrows variety and favors the solution defended by the highest-status person in the room.

Worked example: shorten proposal release time without increasing risk.

Assume a B2B company wants to reduce mean proposal approval time from 52 to 24 hours. Initial mapping reveals four approvals, manual data re-entry, a legal queue and high variation between salespeople.

• 2 — eliminate multiple data entry: integrate CRM and ERP so price, tax ID and terms are entered once.
• 14 — minimize handoffs: remove manual routing when predefined rules are met.
• 19 — perform tasks in parallel: run credit review and technical review simultaneously.
• 49 — increase specialist time: reserve Legal for non-standard clauses rather than standard contracts.
• 53 — develop operational definitions: define exactly what “high-risk proposal” means.
• 61 — use constraints: prevent discounts above authority from proceeding without justification and approval.

The team then chooses a small first PDSA: parallelize credit and technical review for ten proposals in one segment while preserving other controls. Prediction: remove eight hours from the cycle without changing rework rate. Measures include total time, time by step, rework, exceptions and user feedback.

Change concepts expand the solution space before testing. PDSA then prevents a good idea from being mistaken for a proven improvement.

Managing variation requires statistical thinking — especially to avoid making a stable process worse.

The variation family is technically important. It includes standardization, operational definitions, better forecasting and the recommendation to stop tampering: repeatedly adjusting a stable process because of the latest observed result.

Statistical process control recognizes that results vary even when the system has not fundamentally changed. Adjusting a machine, target or rule after every ordinary fluctuation can amplify variation. Before intervening, teams need to distinguish common-cause variation from signals compatible with special causes.

This also changes project measurement. Monthly averages alone rarely establish causality. Preserve the time order of data, use consistent operational definitions and study behavior over time. Measurement for improvement is different from measurement only for accountability.

Error prevention moves attention from the person to the person–system interaction.

Concepts 59–62 shift the discussion away from blaming “human error.” Reminders help but depend on attention. Differentiation reduces confusion among similar items. Constraints prevent incompatible actions. Formal cues make the correct action more apparent.

In modern human-factors terms, the question becomes: how can we make the correct action easier and the incorrect action harder? A form can validate range and format; a physical connector can fit only the correct way; a digital workflow can prevent progress without critical information.

Training remains important, but it should not indefinitely compensate for poor system design. When the same failure reappears across different people, systemic causes deserve priority.

The list becomes powerful when connected to a theory of change.

Mature use requires an explicit causal chain: if we do X, we expect Y, because we believe Z. X is the intervention, Y the observable result and Z the proposed mechanism.

This structure avoids two extremes: management fashion — “automation is improvement” — and analytical paralysis — “we cannot test until certainty is complete.” A PDSA works between the two: formulate enough theory to make a prediction, test at a scale compatible with risk, and use data to update knowledge.

Before implementing at scale, ask: what result should change, what measure will detect the effect, what unintended consequence might appear, and what evidence would make us abandon or adapt the idea?

References and methodological basis.

Langley, G. J.; Moen, R. D.; Nolan, K. M.; Nolan, T. W.; Norman, C. L.; Provost, L. P. The Improvement Guide: A Practical Approach to Enhancing Organizational Performance. 2nd ed., Jossey-Bass, 2009.

Institute for Healthcare Improvement. Model for Improvement: Selecting Changes. IHI describes change concepts as general approaches that can be combined with local knowledge to develop specific changes, then tested through PDSA.

Moen, R. D.; Norman, C. L. “Circling Back: Clearing up myths about the Deming cycle and seeing how it keeps evolving.” Quality Progress, 43(11), 2010.

Montgomery, D. C. Introduction to Statistical Quality Control. Wiley.

Editorial note: the document supplied to Struckel presents 70 concepts in nine categories. IHI's current page, referencing the second edition of The Improvement Guide, mentions 72. This article preserves the supplied 70-concept structure and makes the version difference explicit.