Root Cause Analysis Series: Change Analysis for problems that started after a change

What Change Analysis is and where it came from

Change Analysis was developed by Charles Kepner and Benjamin Tregoe in the 1960s as part of the Kepner-Tregoe approach to structured decision making and problem analysis. It was later adopted by the US Department of Energy for incident investigation work. The core discipline is the same in both contexts. Force a side-by-side comparison of before and after instead of jumping to whatever cause the team suspects first.

The technique gets the most use when an organization is adapting quickly. A full move to permanent remote work that broke a working training program. A CRM migration that quietly changed how sales reps log activity. A platform engineering team that swapped a build tool and watched deploy times drift. The pattern is always the same. Something used to work, then a change happened, then the outcome dropped.

The comparison spans five variables that matter, including the people involved, the systems running underneath, the tools being used, the surrounding environment, and the steps in the process. It works either as a structured table or as a set of open questions per variable.

How Change Analysis works (with an example)

Step 1: Define the problem

Problem: After moving employee training to remote, the program no longer drives engagement or measurable learning outcomes.

Step 2: Identify the change event

Event: training moved from on-site sessions with a regular instructor and a live classroom to remote sessions delivered through Google Meet or Zoom, paired with a Learning Management System (LMS).

Step 3: Compare key variables, before and after

Instructor: before, classes were taught by a mix of internal instructors and guest speakers who knew the audience. After, the instructor is usually a guest speaker dropping in through video, with no relationship to the room.

Method: the format shifted from live back-and-forth and in-room Q&A to one-way video and slides. Learners became passive by default.

Tools: classrooms, whiteboards, and workshop kits were replaced by video conferencing, LMS, polls, and quiz tools. These tools can produce interaction, but only when the session is designed for them. Out of the box, they default to broadcast mode.

Engagement: learners went from active participation to cameras-off, microphones-muted, passive viewing. The instructor lost the signal that tells them whether anyone is following.

Feedback: real-time correction in the room was replaced by post-session surveys. Problems surface late, after the class is over.

Step 4: Identify the likely causes

Three likely causes stand out. There is no deliberate design for interaction on remote tools. Cameras-off behavior removed the social pressure that drove participation. And the LMS is optimized for content delivery, not real-time interaction.

Step 5: Summarize root causes and fixes

Problem: Low participation and weak interaction on video.

Fix: redesign sessions to use breakout rooms, ice breakers, and polls in the first ten minutes, so participation is a structural feature.

Problem: Passive learning with no internal motivation.

Fix: add lightweight gamification, like session badges and a running score.

Problem: Feedback arrives too late.

Fix: add mid-session pulse surveys and a live Q&A block.

Common pitfalls

Change Analysis is one of the cleanest frameworks in the RCA series, but a few pitfalls show up often enough to call out.

The first pitfall is waiting too long to run it. The before state fades fast. Six months after a change, the team can no longer reconstruct what life was like beforehand without filling gaps from memory, which tends to confirm whatever theory is already in the room. Run Change Analysis as soon as a problem starts trending in the wrong direction.

The second pitfall is comparing only the variables the team is comfortable with. Engineers tend to compare tools and process. Operations leads tend to compare people and environment. Most failures involve indirect causes that sit in the variables nobody on the analysis team owns. Forcing the comparison across all five (people, systems, tools, environment, process) is what catches the indirect effects.

The third pitfall is jumping from comparison to fix without sitting with the data. When the team rushes to the first plausible cause, the fix usually patches a symptom and leaves the real shift in place. One extra round of looking at the comparison catches the cases where two variables shifted together.

The fourth pitfall is treating coincidence as a change point. If the outcome dropped right after a deploy, but the deploy was minor and the metric is noisy, the analysis can be a wild-goose chase. Confirming that the change is plausibly large enough to cause the shift saves wasted cycles.

The fifth pitfall is comparing too vague a unit. "The team before" vs "the team after" is too loose. "The average sales rep's daily activity in week 4 before migration" vs "the same role in week 4 after migration" is specific enough to drive a real finding.

Compared to other tools in the RCA Series

Inside the broader Root Cause Analysis Series, Change Analysis has a clear lane. Problem Analysis sits at the front as the 4-axis gateway that classifies a problem before any technique is chosen. Fact-Based Thinking separates fact from assumption before analysis begins.

Against the other techniques, the picks are straightforward. The 5 Whys fits when the cause is unknown and the team needs to drill down one chain at a time. Fishbone Diagram fits when the problem is complex and probably has several parallel causes. Barrier Analysis fits when communication and process exist but the result still falls short, and the team needs to know which control broke. FMEA evaluates risks proactively before a project starts. Fault-Tree Analysis uses AND and OR gates to map combinations of factors. Parent Analysis asks what foundation should exist but never has. Management Oversight focuses on gaps in executive decisions.

Change Analysis is the right call when there is a clearly identifiable before and after, and the team wants a systematic comparison to surface the shifted variable. It pairs well with the 5 Whys. Use Change Analysis to find the shifted variable, then run the 5 Whys on that variable to find the deeper reason it shifted.

When NOT to use Change Analysis

Change Analysis is not the right tool when there is no clear change point. Slow drift problems that worsen across 18 to 24 months without a specific event do not give the technique anything to compare against. For those problems, Fishbone Diagram is better at surfacing parallel causes, and Parent Analysis is better at exposing structural gaps.

It is also a poor fit when the problem is that something should exist but never has. There is no before state to compare, so the framework cannot run. Parent Analysis is the correct start in that case.

When multiple changes land at the same time, Change Analysis can return ambiguous results. If the org restructured, a tool was swapped, and a new process rolled out within the same month, isolating the shifted variable becomes guesswork. Separate the changes into testable units first, or use Fault-Tree Analysis to map combinations.

Use case for digital product teams

Digital product teams reach for Change Analysis at several natural moments. After a release where Conversion Rate drops 15 percent, the team compares the funnel before and after across UI layout, copy, performance, tracking, and user cohort. The structure forces the team to look beyond the obvious change (a UI refactor) and consider whether a tracking change accidentally broke event capture.

A second case is a spike in Customer Support tickets right after a Payment Gateway swap. Comparing each step of the checkout flow before and after exposes the exact step where users now stumble. For an agency like SUFFIX, Change Analysis after a Hand-off helps separate problems that come from changed Spec from problems that come from differences between the client's environment and staging.