The Risk That Needed a Trigger, Not a Mood

Filed by: D.B. Trench

Field line: A risk without a trigger is a warning label on a locked door.

The risk had been in the register for six weeks.

Environment readiness may impact test execution.

Probability: medium.

Impact: high.

Mitigation: ongoing monitoring.

Ongoing monitoring is where risks go to develop patience.

Every week, the update sounded the same. Infrastructure was progressing. Security was engaged. Access was being worked through. Nobody was panicking, which was unfortunate because a small amount of panic would have been more honest than the calm drift we were calling management.

The test cycle needed the environment ready by Monday.

On Thursday, the infrastructure lead said final validation was still in progress.

On Thursday at 12:17, I asked whether testers could log in and execute the first three scripts.

They could not.

That was the trigger. Or it should have been.

The old risk entry did not know what to do with that fact. It only knew how to be monitored.

So the risk was rewritten:

Trigger: if named testers cannot log in and execute smoke scripts by Thursday 3:00 p.m., test start moves and launch readiness must be reforecast. Action owner: PM and infrastructure lead. Decision owner: sponsor.

At 3:00, the testers still could not log in.

The trigger had fired.

Nothing moved.

That is the part risk-management templates do not like to admit. A trigger creates clarity. It does not automatically create courage.

Security wanted one more overnight fix. Infrastructure said the issue was close. The sponsor asked whether we could “hold the test start for now” and reassess in the morning.

So we held the date for another day and lost the morning pretending the trigger had not already done its job.

By Friday afternoon, access worked for two testers and failed for three. Test execution started in fragments. Defect triage opened before baseline smoke testing had completed. The schedule did not explode. It sagged.

Sagging is worse because people keep calling it manageable.

The Friday update said:

Environment trigger met Thursday 3:00 p.m. Test start proceeded partially on Friday with access limitations. Launch readiness confidence reduced due to delayed and incomplete test start. Sponsor decision required Monday on date movement, scope reduction, or accepted residual risk.

That sentence arrived too late to save the first two days.

It arrived in time to stop the team from calling the delay a surprise.

The useful question is not “Are we monitoring this?”

The useful question is: what observable event means we stop monitoring and change the plan?

Missed date. Failed access. No named resource. Defect count above threshold. Approval not received. Test pass rate below target.

Pick the line before the line picks you.

For the next risk that is being “monitored” because no one wants to name the moment of action:

---

Trigger discipline: Use this when the risk register says “monitoring” but nobody knows what event forces action.

Observable trigger: “If [specific condition] occurs by [date/time]...”

Required decision: “...then [owner] must decide [action/escalation/contingency].”

Hard truth: A trigger creates clarity. It does not automatically create courage.

Field channel: Get The Dispatch — weekly field reports for PMs managing the work beneath the official update.