Why You Need to See the Smoke Before the Fire
Protecting your project is not all that different from protecting a national park. Park rangers construct watchtowers to keep an eye on the landscape, looking for signs of trouble. Where there is smoke, there is usually fire — and the earlier you spot the smoke, the more effectively you can respond before the fire becomes an inferno.
Risk triggers are the project equivalent of smoke signals. They are early warning indicators — observable conditions, events, or patterns — that signal a risk is about to materialise. Identifying and monitoring risk triggers enables you to shift from reactive crisis response to proactive, decisive risk management, responding to threats while they are still developing rather than after they have already impacted your project.
In the project knowledge base, risk triggers are defined as events that, when they occur, indicate the risk is no longer a risk but has materialised into a problem or issue requiring resolution. This transition — from risk to issue — is the critical moment that risk triggers are designed to detect.
Two Types of Risk Triggers
Type 1: Immediate Indicators
Immediate indicator triggers signal that a risk is happening right now in your project environment. They provide an instant signal that something has changed and action may be required.
Example: You have technical experts scheduled to join your project team at a future milestone. To ensure a smooth onboarding, you request them to start attending status meetings one month before their start date. The date arrives, you remind them of the commitment, and they do not attend the meeting.
This is an immediate indicator trigger. Their non-attendance signals that competing priorities may prevent their participation in your project — a risk you identified during planning is now showing the first concrete signs of materialising.
Defence context: On a combat system integration project, an immediate indicator trigger might be the late submission of a subcontractor's design data package ahead of a scheduled interface review. The late submission does not itself cause a project problem, but it signals that the subcontractor may be struggling with their design work — a risk trigger for the broader "subcontractor technical performance" risk.
Type 2: Forward Indicators
Forward indicator triggers are signals that something will happen at some point in the future. Unlike smoke — which indicates a fire is happening now — forward indicators are predictive signals based on observable patterns, trends, or external conditions.
Example: Tuna fishermen use water temperature at specific times of year as a forward indicator of future tuna population density. Based on temperature readings, they can project whether the upcoming season will be plentiful or poor, and plan their crew size, fuel reserves, and revenue expectations accordingly.
In project terms, forward indicators include trends in early test results that predict future quality problems, patterns in vendor communication responsiveness that predict future delivery delays, or economic indicators that predict future material cost escalation.
Defence context: On a vehicle manufacturing program, a forward indicator might be the supplier's quarterly order book report showing capacity allocation approaching 95%. While the supplier is currently meeting delivery commitments, the high capacity utilisation signals a future risk that surge demand from other customers could displace your project's production slots — a forward indicator that the "supply capacity constraint" risk may materialise in 6–9 months.
Common Sources of Risk Triggers
Risk triggers can manifest across every dimension of your project. Common trigger categories include:
People behaviour changes: Team members becoming disengaged, key stakeholders becoming unresponsive, vendors avoiding direct communication, sponsor meetings being repeatedly deferred. Schedule variances: Tasks slipping from planned dates, critical path activities consuming float faster than expected, milestone dependencies becoming tighter. Technical indicators: Defects appearing in early prototypes or design reviews, test results trending below specification thresholds, integration issues surfacing in preliminary builds. External signals: Regulatory announcements that may affect project requirements, geopolitical events affecting supply chains, market conditions affecting material costs, competitor actions affecting customer priorities. Financial indicators: Actual costs trending above earned value, vendor invoices exceeding agreed rates, contingency reserve consumption accelerating.
How to Identify and Leverage Risk Triggers
Step 1: Research Historical Triggers
Do not try to invent risk triggers from scratch. The most reliable sources include:
- Past risk logs from previous projects — what triggered risks that actually materialised?
- Post-implementation reviews and lessons learned — what early warning signs were identified in hindsight?
- Risk and issue logs from similar projects in your organisation or industry
These historical sources reveal patterns that are likely to recur on your project. A trigger that preceded a risk event on three previous programs is a strong candidate for monitoring on your current program.
Step 2: Empower Your Team to Monitor Triggers
You cannot be everywhere at once. Your project team members are the subject matter experts who live and breathe the technical, operational, and commercial details of the project every day. They are far better positioned to spot triggers in their domains than you are.
Communicate the identified risk triggers to your team clearly. Explain what each trigger looks like, why it matters, and what action should be taken if it is observed. Staff the watchtowers — assign specific team members to monitor specific triggers as part of their routine responsibilities.
Step 3: Pre-plan Your Response to Each Trigger
The purpose of risk triggers is to enable rapid and decisive response. When a trigger activates, you should not need to convene a meeting to figure out what to do. The response should be pre-planned, documented in your risk response plan, and ready for immediate execution.
For each trigger, your plan should specify:
- What the trigger looks like (observable conditions)
- Who is responsible for monitoring it
- What action is taken when it activates
- Who authorises the action
- What the escalation path is if the action requires senior approval
Step 4: Involve Stakeholders in the Trigger Process
Your sponsors and key stakeholders should be aware of the risk triggers you are monitoring and the actions you will take if they activate. This transparency serves two purposes: it demonstrates proactive management, and it ensures that when you need to execute a response rapidly, your stakeholders are not surprised by the action.
Defence Application: Risk Triggers on a Platform Integration Program
| Risk | Risk Trigger | Type | Monitoring Method | Pre-Planned Response |
|---|---|---|---|---|
| Key systems engineer reassigned to competing program | Engineer declines meeting invitations or misses two consecutive status meetings | Immediate | Weekly status meeting attendance tracking | Activate cross-trained backup engineer; escalate to functional manager within 48 hours |
| Supplier delivery delay on long-lead electronics | Supplier's monthly progress report shows schedule slippage of >5 days | Forward | Monthly supplier progress review | Activate alternate supply agreement; expedite shipping arrangements |
| Software integration defects exceed threshold | Defect count in Sprint 3 integration testing exceeds 15 critical defects | Immediate | Automated defect tracking dashboard | Halt integration; convene technical review board; allocate additional testing resources |
| Export control approval delayed | ITAR/EAR application processing time exceeds 60 days without status update | Forward | Fortnightly check with export control compliance team | Escalate to government relations; prepare design alternative using non-controlled components |
Common Pitfalls
Pitfall 1: Identifying triggers after the risk has materialised. A trigger identified in hindsight is a lesson learned, not a risk management tool. Triggers must be identified before the risk event to provide early warning value.
Pitfall 2: Defining triggers too vaguely. "Things might start going wrong" is not a trigger. A trigger must be specific, observable, and measurable — something that can be unambiguously detected by the monitoring team. Pitfall 3: Monitoring triggers without pre-planned responses. Spotting smoke without having a fire response plan means you detect the problem but waste critical time figuring out what to do. Pre-plan your response for every trigger. Pitfall 4: Centralising all trigger monitoring with the project manager. You cannot watch everything. Distribute trigger monitoring responsibilities to the team members best positioned to observe each trigger in their domain. Pitfall 5: Failing to update triggers as the project evolves. As the project progresses, some triggers become irrelevant (the risk window has passed) and new triggers emerge (new risks are identified). Review and update your trigger list at every risk assessment session.
Key Takeaways
- Risk triggers are early warning indicators that signal a risk is about to materialise — enabling proactive response before the full impact is felt.
- Triggers come in two types: immediate indicators (something is happening now) and forward indicators (something will happen in the future based on observable trends).
- Identify triggers through historical research — past risk logs, lessons learned, and similar project experience are the most reliable sources.
- Empower your team to monitor triggers in their domains — the project manager cannot be everywhere at once.
- Pre-plan your response for every trigger so that activation leads to immediate, decisive action rather than delayed deliberation.
- Involve sponsors and stakeholders in the trigger process to ensure transparency and enable rapid response execution.
- In defence and heavy engineering, triggers are tied to supplier performance metrics, technical test thresholds, resource availability milestones, and regulatory processing timelines.
Contingent Response Strategies
Contingent response strategies are a special category of response that bridges the gap between proactive planning and reactive execution. A contingent response is a pre-planned action that is only triggered when specific predefined conditions are met.
The key characteristics of contingent responses are:
Pre-planned: The response is designed and resourced in advance, not improvised in the heat of a crisis. Conditional: The response is only activated when a specific trigger event occurs — a leading indicator that the risk is about to materialise. Time-sensitive: There must be sufficient warning between the trigger event and the risk impact to allow the response to be implemented effectively.
How It Works: Outputs
Project Management Plan Updates
The risk management plan itself may need modification as response strategies are developed. Response strategies that involve scope changes, additional procurement, or schedule modifications will ripple into the schedule management plan, cost management plan, and procurement management plan.
Project Document Updates
The risk register is updated to include, for each prioritised risk:
- The selected response strategy
- Specific actions to implement the strategy
- The risk owner responsible for execution
- Trigger conditions for contingent responses
- Budget and timeline for response implementation
- Secondary risks introduced by the response strategy itself
- Residual risks remaining after the response is implemented
- Fallback plans if the primary response fails
Why Analysis Without Action Is Wasted Effort
A beautifully constructed risk register, a meticulously populated probability-impact matrix, and a professionally executed Monte Carlo simulation are all worthless if they do not lead to concrete, actionable response strategies that change the project's risk profile. The corresponding activity in the earlier process model — Plan Risk Responses — is where risk management transitions from analysis to action. It is the process of developing options and actions to enhance opportunities and reduce threats to project objectives.
Every response strategy must satisfy five criteria to be effective: it must be appropriate to the significance of the risk, cost-effective in meeting the challenge, realistic within the project context, agreed upon by all parties involved, and owned by a responsible person. A response that is theoretically elegant but practically unaffordable, or one that no individual is accountable for implementing, will fail when the risk materialises.
How It Works: Four Strategies for Threats
When a risk represents a threat — an uncertain event that would negatively impact project objectives if it occurred — the project team selects from four possible strategies:
1. Avoid — Eliminate the Risk Entirely
Avoidance involves taking action to reduce the probability of the risk and/or its impact to zero. This typically means changing the project plan to circumvent the risk entirely — altering scope, schedule, strategy, or approach to remove the source of uncertainty.
Avoidance is the most decisive strategy, but it is not always possible. Some risks are inherent to the project scope and cannot be eliminated without fundamentally changing what the project delivers.
2. Transfer — Shift the Liability
Transfer involves shifting the management burden and financial impact of a risk to a third party. It does not eliminate the risk — it simply ensures that if the risk materialises, someone else bears the consequences.
Common transfer mechanisms include:
| Mechanism | How It Works | Defence Context |
|---|---|---|
| Insurance | The insurance company assumes financial liability in exchange for a premium | Construction all-risk insurance covering physical damage during facility build |
| Fixed-Price Contracts | The contractor assumes cost overrun risk in exchange for a price premium | Fixed-price subcontract for hull fabrication — the subcontractor bears the cost risk of material price increases |
| Performance Bonds | A surety guarantees the contractor's performance; if the contractor fails, the surety pays | Performance bond on a critical subsystem supplier ensuring delivery of a qualified product |
| Warranties and Guarantees | The supplier assumes post-delivery risk of defects or failures | Extended warranty on a propulsion system covering defects discovered during the first 5,000 operating hours |
3. Mitigate — Reduce Probability and/or Impact
Mitigation involves taking early action to reduce the probability of the risk occurring, its impact if it does occur, or both. Mitigation does not eliminate the risk — it reduces it to an acceptable level.
| Mitigation Approach | What It Targets | Defence Manufacturing Example |
|---|---|---|
| Reduce probability | Makes the risk event less likely to occur | Conducting additional prototype testing before committing to a production design — reducing the probability of production-stage design rework |
| Reduce impact | Limits the damage if the risk event occurs | Pre-qualifying an alternative titanium supplier so that if the primary supplier fails, the schedule impact is weeks rather than months |
| Reduce both | Addresses probability and impact simultaneously | Implementing a comprehensive welding quality programme with enhanced NDE inspection — reducing both the probability of defects and the impact of any defects that occur (caught earlier, fixed cheaper) |
Mitigation is the most commonly applied strategy and the one that demands the most creativity and engineering judgment. The project manager must balance the cost of mitigation against the expected cost of the risk — a mitigation action that costs more than the expected value of the risk it addresses is not cost-effective.
4. Accept — Acknowledge and Prepare
Acceptance is the strategy chosen when the team decides to take no proactive action to address a risk, either because the risk is assessed as low-priority or because the cost of any other strategy would be disproportionate to the risk itself.
Acceptance comes in two forms:
Passive acceptance — the team simply acknowledges the risk and decides to deal with it if and when it occurs, without pre-planning a specific response. Active acceptance — the team establishes a contingency reserve (time, money, or resources) that will be deployed if the risk materialises. This is the more disciplined form of acceptance and is appropriate for risks that are well-understood but deemed too expensive or impractical to avoid, transfer, or mitigate.