Yesterday, My Plugin Nearly Broke and It Taught Me Something About Risk Management
Yesterday morning, I was sipping my coffee, feeling pretty good about the progress on our new WordPress plugin for A/B sales page testing.
Everything was going smoothly — until my developer pinged me:
“Hey Dejan… we’ve got a problem. The tracking script isn’t recording time-on-page correctly.”
Now, for those of you who’ve ever built software, you know this is not the kind of message you want before lunch. Especially when you’re just weeks away from launch.
The good news?
I didn’t panic.
Why?
Because I had a contingency plan ready.
Why I’m Writing This?
I’m also writing this because one of my students from my Risk Management in Scrum course asked me a question that reminded me of this exact situation.
Demar said:
“I’m not understanding why the response to the question — saying that a contingency plan outlines proactive measures vs a fallback plan being activated when the initial response fails — is the wrong answer. It sounds like a valid response to me. Some clarification would be helpful.”
And honestly, I get it. On the surface, it does sound correct.
But the truth is, that answer — while not entirely wrong — is incomplete. An incomplete understanding of risk management can be dangerous.
So, let me use what happened yesterday to explain the real difference in a way that sticks.
What I Did First – My Contingency Plan
Before we even started building the plugin, I had identified a few high-risk areas. Tracking accuracy was one of them.
So, part of my contingency plan was:
- Have a backup tracking method using a different script.
- Test that method on a staging site to confirm it works.
- Switch to the backup script within 30 minutes if the primary fails.
That’s exactly what we did.
We swapped scripts, tested, and… everything was back on track.
But Then… Things Got Worse
By late afternoon, a second message popped up from the dev team:
“The backup script works, but it’s slowing down page load times, and our analytics are showing a 20% drop in conversions on the test pages.”
Uh-oh. This was new territory. The contingency plan handled the first risk — the data tracking problem — but it introduced a new risk we hadn’t anticipated: slow load times hurting conversions.
That’s when we had to pull out our fallback plan.
Fallback Plan to the Rescue
The fallback plan was simple but powerful:
- Stop the A/B tests temporarily.
- Roll back to the stable version of the plugin from two weeks ago.
- Resume testing only after the performance issue was resolved.
It wasn’t as elegant as the contingency plan — and it definitely slowed our momentum — but it kept us from losing more conversion data and upsetting beta testers.
So, What’s the Real Difference?
Here’s the easy way to remember it:
| Aspect | Contingency Plan | Fallback Plan |
|---|---|---|
| Purpose | Handle a known, identified risk if it happens | Handle the situation when the contingency fails or isn’t enough |
| Timing | Proactive — you prepare it in advance and trigger it when the risk occurs or seems likely | Reactive — you trigger it after the contingency doesn’t solve the problem |
| Focus | Minimize or avoid the impact of the risk | Keep the project alive when things have gone beyond the contingency |
Think of it like this:
- Contingency = Your Seatbelt → You use it when you expect bumps or possible crashes.
- Fallback = Your Airbag → You only see it deploy when the seatbelt wasn’t enough.
Why the “Proactive vs Reactive” Answer Is Incomplete
Demar’s version — “contingency is proactive, fallback is reactive” — is part of the truth, but it leaves out two critical points:
Trigger Points Matter
- A contingency plan isn’t just “any proactive measure.” It’s a specific, pre-planned set of steps for a known risk with a high likelihood or impact.
- A fallback plan isn’t just “what happens when the first thing fails.” It’s also pre-planned — but it only kicks in when the contingency either fails or can’t fully solve the problem.
Both Are Prepared in Advance
- Many people think of fallback plans as being improvised on the spot. They shouldn’t be. Good risk management means you already know what your fallback will be before you ever need it.
So yes, proactive vs reactive is correct at a high level, but without the details of when they’re used and how they’re connected, the answer can be misleading.
Final Takeaway
Whether you’re building a WordPress plugin, running a Scrum project, or managing a construction site, always have both:
- A Contingency Plan to handle the likely risks you can foresee.
- A Fallback Plan to keep the project alive if your contingency doesn’t cut it.
Because in real life, just like yesterday with my plugin, the risk you prepare for might not be the only one you face.
