Operations consulting · Why fixes fail
The Fix That Didn't Fix It: why fixes fail when the explanation was never tested
You approved the fix. Eleven weeks later, the same milestone is red. Before you fund another answer, test the explanation behind the last one.
By Jim Wilde, Emergent Skills · October 4, 2026
The second status meeting after the fix
The fix went in eleven weeks ago. Two new coordinators, a reconfigured approval workflow, and a half-day training session for the intake team. The budget was approved after a post-mortem pointed to handoffs.
Now it is Tuesday, the status deck is up, and the same milestone is red. The new explanation is already forming: the coordinators need more time.
That is the expensive part of a recurring problem. You did not just lose time. You paid to remove the problem, waited for the result, and ended up back at the same decision.
Every fix is a bet on an explanation
When a project stalls or a result comes in short, plausible explanations appear quickly. The process is broken. Two people left. The tool is wrong. Priorities changed. The team needs more capacity. The vendor is late.
Any of those could be right. The danger is obvious: you can spend money fixing the wrong problem.
Some answers are easier to buy than others. Headcount has a requisition. Software has a vendor. Training has a calendar slot. "We do not know yet" is harder to turn into an approval request.
But an easy-to-buy fix can still be the wrong fix. Add coordinators when completed work is sitting in one approval queue, and you may add people without moving the decision. Redesign the workflow when necessary work was never identified or assigned, and the new route can leave the same gap untouched.
Before you fund the fix, find the right problem. Make the case for the proposed fix against what actually happened.
Why an internal review can settle on the first plausible answer
An internal review is the obvious first move, and it may be all you need. A project manager, PMO lead, operations manager, or analyst already knows the organization and may be able to reconstruct what happened.
The review gets weaker when one or more of four constraints are present:
- Time. The reviewer is also responsible for current delivery, so the investigation has to compete with the work it is examining.
- Reach. The problem crosses teams, but the reviewer has easy access to only part of the route.
- Records that stop short. Jira, Workfront, ServiceNow, Planview, or another system can show what was entered. Work that was never defined, assigned, or recorded may require other evidence.
- Independence. The reviewer may have helped design the plan or own part of the result. That does not make the review wrong, but it can make competing explanations harder to test.
None of this means the internal team cannot do the job. It means these are the weak spots you need to watch.
What testing an explanation actually takes
You do not need a bigger post-mortem. You need enough evidence to challenge the story that has started to take hold.
Start with the result, not the fix
What was supposed to happen, what actually happened, by when, and what is still worth protecting? And ask the uncomfortable question: does this result still matter enough to keep spending money on it?
Run the Initial Investigation Checks
Is the outcome still valid? Is it genuinely a chosen priority? Are capability, information, authority, and funding available? Is an external dependency controlling progress? These checks can point to a simpler explanation before you redesign anything.
For a broader look at these checks, read why projects fail and what to check first.
Check the necessary work and ownership
List the work the business result required and establish who owned each part. "Operations owns it" is not the same as knowing who owned the work. If nobody can establish ownership, that is something to investigate, not something to fill in by assumption.
Trace the work path
Reconstruct where the work waited, queued, reopened, looped, hit an approval, crossed a handoff, or came back for rework. Nine days in one approval queue is a different operating problem from nine days spread across several necessary steps.
Check the conditions around execution
Everybody is busy. That proves nothing. The question is whether interruptions and competing priorities are actually showing up in mistakes, rework, reversals, or missed handoffs.
Try to disprove the leading explanation
A staffing explanation should have evidence that lack of available capacity matters at the steps in question. If the record instead shows completed work waiting on decisions, headcount becomes less supported as the first fix. Ask what would prove your favorite explanation wrong.
A capable internal team can do this. Pay an outsider only if they add something the internal team cannot reasonably provide: dedicated time, reach across teams, facilitation, or a separate reconstruction of what happened.
"Do not fund this yet" can be a useful finding
A useful investigation does not have to end with a new intervention. Sometimes the proposed fix does not yet have enough support to justify the money.
Do not fund this yet. Here is the evidence that is missing, the decision that has to be made, or the bounded test that would change the answer.
There is nothing magical about a 14-day test. If a test is warranted, its length should follow the work. And sometimes no test is needed. The next move is a management decision, a missing piece of evidence, another specialist, or stopping the work.
Cross-functional problems add another complication. A finding from one team can be challenged as partial or territorial. An outside finding is not automatically neutral, but a conclusion tied to dates, decisions, records, and stated uncertainty gives the people involved something concrete to inspect.
What the wrong fix costs
The cost of a fix that does not solve the problem rarely sits on one line. It can show up as repeated review, extra coordination, elapsed delay, management attention, another intervention, or value that remains held back.
One external benchmark is useful as context, but only if it stays in bounds. PMI's 2024 Pulse of the Profession reported average budget loss of 25.7% on failed projects in its 2023 global survey. On a $1 million project budget, 25.7% is $257,000. That is a benchmark for failed projects, not an estimate for a late or partly delivered project and not evidence about your case.
Your number needs cleaner categories. Do not turn every consequence into one giant dollar number. Extra labor is one thing. Delay is another. Opportunity value may be another, if you can support it. And the next proposed fix has a cost of its own. Keep them separate and do not double-count them.
Money already spent explains why the situation matters. Money you are about to spend is the decision in front of you.
Before you fund the next one
If the same result is still red after the fix, do not start by asking what to try next. Ask: What evidence says we have the right problem? And what would prove us wrong?
If your PMO or operations team can answer that with the records open, use them. If they cannot get the time, access, or cross-functional room needed to test the explanations, a bounded outside investigation may be worth the fee.
Emergent Skills' Stalled Priority Snapshot investigates one important result and the next decision around it. It checks necessary work and ownership, traces the work path, assesses conditions around execution where relevant, and keeps other explanations open.
The fee is $1,500 fixed. The session is 90 minutes with up to three participants. Written input from six to eight contributors is optional and agreed before booking. You receive the written readout within 24 hours of the session, plus a 15-minute walkthrough and follow-up after an agreed test or evidence review. No further engagement is required.
The readout says what the evidence supports, what remains uncertain, the costs that can be established, and the next step we recommend. If the right answer is "do not fund the fix yet," that is a valid result.
The next fix should have to earn the money.
Start with one result that still matters. Test the explanation before you fund another answer.
