You finally put the fix in place. The meeting's over, the code's shipped, the new process is live. So now you're done, right?
Not even close Small thing, real impact..
Here's the thing — most people treat "implement the plan" like it's the finish line. It isn't. Still, if you've ever wondered which problem solving step comes after implementing the plan, you're already ahead of the pack. Because that next step is the one everybody skips, and it's usually why the same problem shows up again three months later.
What Is the Step After Implementing the Plan
The step that comes after implementing the plan is evaluating the results — sometimes called monitoring, reviewing, or checking the outcome. In plain language: you look at what actually happened after you did the thing, and you compare it to what you said would happen Simple, but easy to overlook..
That's it. That's the step. But "that's it" makes it sound small, and it isn't.
When we talk about structured problem solving — whether it's the PDCA cycle (Plan-Do-Check-Act), the DMAIC framework from Six Sigma, or just a sane approach to fixing something at work — implementation is never the last move. Consider this: you plan, you do, and then you have to check. The check is the step after implementing the plan Turns out it matters..
Easier said than done, but still worth knowing.
Why It Goes by Different Names
Depending on where you learned problem solving, you'll hear different words for the same idea:
- PDCA calls it "Check"
- DMAIC calls it "Control" or "Measure" (depending on how you frame the loop)
- Old-school business manuals say "Review and Evaluate"
- Teachers sometimes call it "Reflect"
Same muscle. Different gym class.
What Evaluating Actually Means
It doesn't mean "hope nothing breaks." It means you go back to the goal you set in the planning phase and ask: did this actually move the number? Did the customer complaint rate drop? Did the bug stop reproducing? Did the team stop missing deadlines?
If you didn't set a measurable goal before implementing, evaluating gets fuzzy. That's a problem we'll get to later.
Why It Matters / Why People Care
Look, skipping the evaluation step is how organizations waste years. They "solve" a problem, declare victory, and never check if the fix held. Then the issue quietly returns, but now it's more expensive because everyone thinks it was already fixed.
Why does this matter? Because most people skip it.
In practice, the implementation feels like the hard part. You fought for budget, you convinced the team, you shipped the change. Your brain wants a dopamine hit and a closed ticket. But the real test of a solution is whether it works in the wild, not whether it works in the meeting where you announced it That's the part that actually makes a difference. Turns out it matters..
I know it sounds simple — but it's easy to miss. A friend of mine in ops once redesigned an onboarding flow. Sign-ups looked better for two weeks. They moved on. Six weeks later, churn was worse than before, because the new flow attracted the wrong users. In practice, they never built a check-in at week six. That's the cost of stopping after implementation.
And here's what most people miss: evaluation isn't just about the problem you fixed. Which means it tells you if your planning was any good. If the fix worked, your diagnosis was probably right. If it didn't, you learned something about the real cause — which is gold for next time.
How It Works (or How to Do It)
The evaluation step isn't magic. It's a loop you run on purpose. Here's how to actually do it without turning it into bureaucracy Simple, but easy to overlook..
Step 1: Go Back to Your Original Success Criteria
Before you implemented, you should have said something like "we'll know this worked if support tickets drop 20%." If you didn't write that down, do it now, retroactively, based on what you intended. You can't evaluate against a target you never set.
The short version is: no criteria, no real evaluation. Just vibes.
Step 2: Pick a Time Window
Don't check the day after. Don't check six months later either. Which means choose a window that matches the problem. A UI change? Give it two weeks of traffic. In practice, a hiring process? Look at 90 days of new-hire performance. The point is to let the system breathe before you judge it Most people skip this — try not to. Took long enough..
Step 3: Collect the Actual Data
Use the same source you would've trusted during planning. Here's the thing — if you said "tickets," pull the ticket report. If you said "cycle time," pull the pipeline. Don't eyeball the Slack channel and call it research. Real talk, anecdotal "it feels better" is how bad fixes survive.
Step 4: Compare Expected vs. Actual
Lay them side by side. A small win might mean the plan was partially right. Expected: 20% drop. Worth adding: actual: 4% drop. Now you have a gap. That gap is information, not failure. A miss means either the plan was wrong or the implementation drifted.
Step 5: Look for Side Effects
At its core, the part most guides get wrong. A fix can hit the target and still break something else. In practice, the onboarding example above is classic: hit the signup goal, wrecked the retention goal. And when you evaluate, scan adjacent metrics. Revenue per user, error rates, team hours, customer sentiment. The problem solving step after implementing the plan is also where you catch the collateral damage Practical, not theoretical..
Step 6: Decide the Next Move
Evaluation feeds the next loop. Still, if it worked, you standardize it (that's the "Act" in PDCA). If it didn't, you revisit the plan with new info. Either way, the step after implementing the plan is not "close the doc." It's "decide what the data is telling us to do.
Common Mistakes / What Most People Get Wrong
Honestly, this is the part most guides get wrong because they treat evaluation like a checkbox. Here's where it actually falls apart:
Declaring success too early. Two good days is not a trend. If your window is too short, you're evaluating noise.
Measuring the wrong thing. People count activity, not outcome. "We trained 100 employees" is not the same as "errors went down." The step after implementing the plan demands outcome measurement.
No baseline. If you didn't record what things looked like before, you can't prove change. "It's better now" isn't data.
Confirmation bias. You wanted the fix to work, so you read the numbers softly. A 3% dip becomes "early signs of improvement." Worth knowing: get someone who wasn't attached to the plan to look at the numbers Easy to understand, harder to ignore..
Skipping it entirely. The classic. Implement, announce, move to the next fire. Then wonder why the old fire restarts.
Confusing implementation completeness with solution validity. Just because the plan was executed doesn't mean the problem is gone. Those are different facts.
Practical Tips / What Actually Works
Forget the heavy frameworks if they scare your team off. Here's what actually works in real life:
- Put the review date on the calendar before you implement. If it's not scheduled, it won't happen. I've done this for years and it's the only reason I ever evaluate.
- Write the success criteria in one sentence. "We'll know it worked if ___ drops/rises by ___ in ___ days." That sentence is your evaluation anchor.
- Use a simple before/after table. Two columns. Old number, new number. You don't need a dashboard to start.
- Ask the frontline. The people using the fix know in week one what you'll see in month two. They'll tell you the side effects if you ask.
- Kill failed fixes fast. If the data says it didn't work, don't defend it. The step after implementing the plan is about truth, not pride.
- Document the lesson, not just the result. "Fix X failed because root cause was Y" is more valuable than "Fix X failed." That's how you get better at problem solving overall.
And look — don't overdo it. A broken printer cable? Not every tiny fix needs a 90-day review with a steering committee. Implement and move on. Match the weight of the evaluation to the weight of the problem. A revenue-leaking checkout flow?
When the Data Says "Neither Win Nor Loss"
Sometimes the numbers don't give you a clean verdict. A 2% improvement on a metric that needed 15% isn't a partial win — it's a signal that you treated a symptom and missed the disease. That said, in these gray zones, the step after implementing the plan becomes a decision about depth: do you iterate on the same fix, or do you reopen the root-cause question you thought you'd closed? They say "kind of," and that's its own trap. Plus, most teams pick iteration because it feels like progress. The disciplined ones go back to the drawing board, because they understand that a weak signal is still a signal about their diagnosis, not just their execution.
The Cultural Piece Nobody Mentions
Evaluation only works if your environment allows a fix to fail out loud. If you lead the team, your job isn't to demand accountability after the fact; it's to make "the fix didn't work and here's why" a career-safe sentence before you ever start. That's why in teams where every metric review is a performance autopsy, people quietly stop recording the bad numbers. Now, the step after implementing the plan then becomes theater — a presentation of survivable truths. That single shift turns evaluation from a threat into a tool Small thing, real impact..
Conclusion
The step after implementing the plan is where most solutions quietly die or quietly succeed — and the difference is almost never the quality of the fix itself. But schedule it, simplify it, and let the data tell you what to do next — even when what it tells you is that you were wrong. That's not failure. It's whether anyone bothered to look, with honest eyes and a recorded baseline, at what changed. Evaluation isn't bureaucracy. It's the moment you stop hoping and start knowing. That's the loop working.
