I’ll just say it. Most “project professionals” do not understand risk. They understand the idea of risk. They understand the templates. They understand the workshop exercises.
They do not understand what makes risk actually matter.
And here’s the truth that’s going to irritate a few people: A Risk is not your problem. An Issue is your problem. And a Risk becomes an Issue when a Trigger event occurs.
Too many teams obsess over identifying risks. Very few teams obsess over identifying triggers. That’s the difference between paperwork and leadership.
Welcome to Risk 101 by Professor Kinder….
A Risk is a potential future event that may impact your objectives. It has: a probability, an impact, and a timeframe. It lives in the future.
An Issue is a current problem that is impacting your objectives. It has: a root cause, a present effect, a required action. It lives in the now.
The bridge between the two? The Trigger.
The trigger is the signal that the risk has moved from “maybe” to “it’s happening.”
And yet… Most risk registers I review have: 47 risks, 0 defined triggers, 0 assigned trigger monitoring owners, 0 documented trigger thresholds.
But they do have beautiful color coding. So there’s that…
Let me be blunt. A lot of risk management is theater. Big workshops. Sticky notes. Monte Carlo simulations. Heat maps.
Then what?
The risk register goes into SharePoint. No one looks at it again until the quarterly review. Then everyone is shocked when a “known risk” turns into a five-alarm fire.
It wasn’t “unknown.” It was unmanaged. Because no one defined the trigger.
Here are some examples.
A Vendor Delay. Risk: Key vendor may miss the delivery milestone.
Probability: Medium Impact: High
Great. That’s cute. Now answer this: What specifically will signal that this risk is materializing? Is it 3 days late? Is it 10% schedule slippage? Is it a failure to submit documentation? Is it a missed intermediate checkpoint?
If you haven’t defined that… You don’t have a risk strategy. You have a hope strategy.
Trigger Examples: Vendor fails to deliver 30% design package by the March 15 milestone.
Now we’re talking. Because when March 15 hits and nothing shows up? It’s no longer a risk. It’s an issue. And now your contingency plan should be executed immediately.
Budget Overrun Risk: Project may exceed budget due to scope creep.
Everyone nods sagely. Now define the trigger. Is it: Two unapproved change requests? Cost variance exceeding 5%? Earned Value CPI (Cost Performance Index) below 0.92? A single executive-directed enhancement?
Without the trigger, you won’t act until you’re already bleeding.
Trigger Example: CPI drops below 0.90 for two consecutive reporting cycles.
Now your team knows exactly when to escalate. That’s leadership.
Resource Burnout Risk: Key team members may burn out due to sustained overtime.
Good risk. Now what’s the trigger? More than 50 hours/week for three consecutive weeks? PTO requests denied twice? Error rate increases by 20%? Engagement survey dips below baseline?
If you don’t define it, you’ll only notice burnout when the resignation letter hits your inbox.
And then you’ll say: “We knew this was a risk.”
No. You documented it. You didn’t manage it.
Here’s why most project professionals miss triggers:
They’re Task Managers, Not Constraint Managers: Early-career PMs manage tasks. Maturing PMs manage constraints. High-level leaders manage value.
Risk is about constraints. Triggers are about constraint thresholds.
If you don’t understand the constraint architecture of your project, you cannot define meaningful triggers.
Fear of Accountability: Defining triggers forces accountability.
If you write: “Trigger = CPI < 0.90” Then someone has to: Monitor CPI Report CPI Act when CPI drops. It removes wiggle room.
Many PMs prefer ambiguity. It gives them narrative control later.
Misunderstanding Probability: Probability is not the point. Probability is interesting. Triggers are operational.
You can debate whether something is 30% or 40% likely all day long. But when the trigger occurs? Debate is over.
Over-Engineering the Analysis: Some “project professionals” would rather: Run 10,000 Monte Carlo simulations, create a 3D risk heat map, produce a 22-slide risk dashboard… Than answer a simple question: “What observable event tells us this risk has arrived?”
That’s ego, not execution.
If you want to stop playing risk theater, here’s your framework. For every risk, you must define: the Risk Statement, the Root Cause, the Impact, the Trigger, the Response Plan, the Owner, the Monitoring Cadence.
If any of those are missing? You have documentation. Not management.
Let’s get tactical. A good trigger is: Observable. It must be measurable or visible.
Bad: “Team morale declines.” Good: “Engagement score drops below 70%.”
Time-Bound: It must have a timeframe.
Bad: “Schedule slips.” Good: “Critical path milestone slips by more than 5 business days.”
Binary: It must clearly happen or not happen.
Bad triggers create arguments. Good triggers create action.
Linked to Contingency: If the trigger occurs, something must happen. Immediately. Not “we’ll discuss.” If the trigger fires and nothing changes? You just proved you weren’t serious.
Let’s hammer this home. Risk → Trigger Event → Issue. That’s the sequence.
Many PMs skip the middle. Then they’re shocked when a risk becomes an issue “suddenly.” There is no sudden. There is ignored.
Executives don’t care about your 70-line risk register. They care about: What could hurt us? How will we know it’s happening? What will we do about it?
Notice what’s in the middle: “How will we know?” Hint: That’s the trigger.
If you can’t articulate that clearly in one sentence, you are not controlling your project. You are reacting to it.
Here’s where seasoned leaders separate themselves. Trigger thresholds should reflect risk appetite. High-risk tolerance organization? Triggers may allow wider variance. Low-risk tolerance environment (healthcare, aviation, defense)? Triggers should be tight and early-warning oriented.
The trigger is not random. It reflects the organization’s tolerance for deviation.
If you don’t align triggers to risk appetite? You’ll either overreact or underreact. Both are expensive.
Another pet peeve. Teams call everything a “risk.” If it has already happened? It’s not a risk. It’s an issue. Stop softening language. Words mean things. When your production server crashes, that is not a “realized risk.” It is an issue requiring root cause analysis.
Words matter and language drives action.
Want a practical habit? Every week ask: Did any triggers fire? Are we approaching any thresholds? Has the probability shifted because of new information? Are contingency plans still viable?
This takes 10–15 minutes if you’ve built it correctly. If it takes an hour? You overcomplicated it.
In military operational environments, we don’t debate risk philosophically.
We define: Indicators, Warnings, Decision points.
Those are triggers. If X happens, we maneuver. If Y occurs, we escalate. If Z fires, we abort.
No one says: “Well, that was identified as a risk.” They say: “Execute the contingency.”
Projects should operate the same way. Calm. Predefined. Disciplined.
When triggers are undefined escalation is delayed. Stakeholders are blindsided. Contingencies are late. Budgets are overrun. Schedules are unrecoverable. Teams burn out.
And the post-mortem always includes this line: “We knew that was a risk.”
That’s not wisdom. That’s indictment.
Real project leaders: Define risk clearly. Define triggers precisely. Monitor triggers consistently. Act decisively.
They don’t hide behind documentation. They use it as a weapon.
Open your current risk register. Pick your top five risks. For each one, answer: What exact event signals this risk is materializing? Who is watching for that signal? How often are they watching? What action occurs immediately when it fires?
If you can’t answer those? You’re not managing risk. You’re archiving it.
Risk identification is easy. Trigger definition requires thinking. Issue management requires leadership. Stop spending crazy amounts of time brainstorming hypothetical doom.
Start defining the observable events that turn potential into problem. Because once the trigger fires… The clock starts.
And at that moment, no one cares how pretty your heat map looked. They care whether you were ready.
