project-risk-register

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Project Risk Register

项目风险登记册（Project Risk Register）

Purpose

目的

Proactively identify, assess, prioritize, and monitor project risks to reduce likelihood of surprises, enable informed decision-making, and ensure stakeholders understand uncertainty. Transform vague concerns ("this might not work") into actionable risk management (probability×impact scores, named owners, specific mitigations, measurable triggers).

主动识别、评估、排序和监控项目风险，以降低意外情况发生的可能性，助力明智决策，并确保相关方了解不确定性。将模糊的担忧（如“这可能行不通”）转化为可落地的风险管理措施（包括概率×影响评分、指定负责人、具体缓解方案、可衡量的触发条件）。

When to Use

适用场景

Use this skill when:

Project kickoff: Establishing risk baseline before significant work begins
High uncertainty: New technology, unfamiliar domain, complex dependencies, regulatory constraints
Stakeholder pressure: Execs/board want visibility into "what could go wrong"
Critical path concerns: Delays, dependencies, or single points of failure threaten timeline
Gate reviews: Quarterly check-ins, milestone reviews, go/no-go decisions require risk assessment
Incident response: Major issue occurred, need to identify related risks to prevent recurrence
Portfolio management: Comparing risk profiles across multiple projects for resource allocation
Change requests: Scope/timeline/budget changes require risk re-assessment

Common triggers:

"What are the biggest risks to this project?"
"What could cause us to miss the deadline?"
"How confident are we in this estimate/plan?"
"What's our backup plan if X fails?"
"What dependencies could block us?"

在以下场景使用本技能：

项目启动阶段：在大量工作开始前建立风险基线
高不确定性场景：涉及新技术、陌生领域、复杂依赖关系、监管约束
相关方施压：高管/董事会希望了解“可能会出什么问题”
关键路径担忧：延迟、依赖关系或单点故障威胁项目 timeline
阶段评审：季度检查、里程碑评审、立项/终止决策需要风险评估
事件响应：发生重大问题后，需要识别相关风险以防止再次发生
项目组合管理：比较多个项目的风险状况以分配资源
变更请求：范围/时间/预算变更需要重新评估风险

常见触发词：

“这个项目最大的风险是什么？”
“什么会导致我们错过截止日期？”
“我们对这个估算/计划有多有信心？”
“如果X失败了，我们的备用计划是什么？”
“哪些依赖关系可能会阻碍我们？”

What Is It?

什么是Project Risk Register？

Project Risk Register is a living document tracking all identified risks with:

Risk identification: What could go wrong (threat) or go better than expected (opportunity)
Risk assessment: Probability (how likely?) × Impact (how bad/good if it happens?) = Risk Score
Risk prioritization: Focus on high-score risks (red/high) first, monitor medium (yellow), accept low (green)
Risk ownership: Named individual responsible for monitoring and mitigation
Risk response: Mitigation (reduce probability), contingency (reduce impact if occurs), acceptance (do nothing)
Risk triggers: Early warning indicators that risk is materializing (time to activate contingency)
Risk monitoring: Regular updates (status changes, new risks, retired risks)

Risk Matrix (5×5 Probability×Impact):

Impact →     1         2         3         4         5
Prob ↓    Minimal   Minor   Moderate  Major   Severe

5 High   │ Medium │ Medium │  High  │  High  │ Critical│
         │   5    │   10   │   15   │   20   │   25    │
4        │  Low   │ Medium │ Medium │  High  │  High   │
         │   4    │    8   │   12   │   16   │   20    │
3 Medium │  Low   │  Low   │ Medium │ Medium │  High   │
         │   3    │    6   │    9   │   12   │   15    │
2        │  Low   │  Low   │  Low   │ Medium │ Medium  │
         │   2    │    4   │    6   │    8   │   10    │
1 Low    │  Low   │  Low   │  Low   │  Low   │ Medium  │
         │   1    │    2   │    3   │    4   │    5    │

Risk Thresholds:

Critical (≥20): Escalate to exec, immediate mitigation required
High (12-19): Active management, weekly review, documented mitigation
Medium (6-11): Monitor closely, monthly review, contingency plan
Low (1-5): Accept or minimal mitigation, quarterly review

Example: Software Migration Project

Risk ID	Risk	Prob	Impact	Score	Owner	Mitigation	Contingency
R-001	Third-party API deprecated mid-project	3	4	12 (Medium)	Eng Lead	Contact vendor for deprecation timeline	Build abstraction layer for quick swap
R-002	Key engineer leaves during critical phase	2	5	10 (Medium)	EM	Knowledge sharing, pair programming	Contract backup engineer
R-003	Data migration takes 3× longer than estimated	4	4	16 (High)	Data Lead	Pilot migration on 10% data first	Extend timeline, reduce scope

Project Risk Register是一份动态文档，用于跟踪所有已识别的风险，包含以下要素：

风险识别：可能出现的问题（威胁）或超出预期的有利情况（机会）
风险评估：概率（发生的可能性？）×影响（发生后影响程度？）=风险评分
风险排序：优先处理高评分风险（红色/高优先级），监控中等风险（黄色），接受低风险（绿色）
风险负责人：指定负责监控和缓解风险的个人
风险应对：缓解（降低发生概率）、应急（降低发生后的影响）、接受（不采取行动）
风险触发条件：风险即将发生的早期预警指标（此时需启动应急方案）
风险监控：定期更新（状态变更、新增风险、已关闭风险）

风险矩阵（5×5 概率×影响）：

Impact →     1         2         3         4         5
Prob ↓    Minimal   Minor   Moderate  Major   Severe

5 High   │ Medium │ Medium │  High  │  High  │ Critical│
         │   5    │   10   │   15   │   20   │   25    │
4        │  Low   │ Medium │ Medium │  High  │  High   │
         │   4    │    8   │   12   │   16   │   20    │
3 Medium │  Low   │  Low   │ Medium │ Medium │  High   │
         │   3    │    6   │    9   │   12   │   15    │
2        │  Low   │  Low   │  Low   │ Medium │ Medium  │
         │   2    │    4   │    6   │    8   │   10    │
1 Low    │  Low   │  Low   │  Low   │  Low   │ Medium  │
         │   1    │    2   │    3   │    4   │    5    │

风险阈值：

Critical（≥20）：上报给高管，需立即采取缓解措施
High（12-19）：主动管理，每周评审，记录缓解方案
Medium（6-11）：密切监控，每月评审，制定应急计划
Low（1-5）：接受或采取最小缓解措施，每季度评审

示例：软件迁移项目

风险ID	风险描述	概率	影响	评分	负责人	缓解方案	应急方案
R-001	第三方API在项目中期被弃用	3	4	12（Medium）	工程主管	联系供应商获取弃用时间表	构建抽象层以便快速替换
R-002	核心工程师在关键阶段离职	2	5	10（Medium）	工程经理	知识共享、结对编程	签约备用工程师
R-003	数据迁移耗时比估算长3倍	4	4	16（High）	数据主管	先对10%的数据进行试点迁移	延长时间线，缩减范围

Workflow

工作流程

Copy this checklist and track your progress:

Risk Register Progress:
- [ ] Step 1: Identify risks across categories
- [ ] Step 2: Assess probability and impact
- [ ] Step 3: Calculate risk scores and prioritize
- [ ] Step 4: Assign owners and define responses
- [ ] Step 5: Monitor and update regularly

Step 1: Identify risks across categories

Brainstorm what could go wrong using structured categories (technical, schedule, resource, external, scope). See Common Patterns for category checklists. Use resources/template.md for register structure.

Step 2: Assess probability and impact

Score each risk on probability (1-5: rare to almost certain) and impact (1-5: minimal to severe). Involve subject matter experts for accuracy. See Risk Scoring Framework for definitions.

Step 3: Calculate risk scores and prioritize

Multiply Probability × Impact for each risk. Plot on risk matrix (5×5 grid) to visualize risk profile. Focus mitigation on Critical/High risks first. See resources/methodology.md for advanced techniques like Monte Carlo simulation.

Step 4: Assign owners and define responses

For each High/Critical risk, assign named owner (not "team"), define mitigation (reduce probability), contingency (reduce impact), and triggers (when to activate contingency). See resources/template.md for response planning structure.

Step 5: Monitor and update regularly

Review risk register weekly (active projects) or monthly (longer projects). Update probabilities/impacts as context changes, add new risks, retire closed risks, track mitigation progress. See Guardrails for monitoring cadence.

复制以下 checklist 跟踪进度：

Risk Register Progress:
- [ ] Step 1: Identify risks across categories
- [ ] Step 2: Assess probability and impact
- [ ] Step 3: Calculate risk scores and prioritize
- [ ] Step 4: Assign owners and define responses
- [ ] Step 5: Monitor and update regularly

步骤1：跨类别识别风险

使用结构化类别（技术、进度、资源、外部、范围）进行头脑风暴，找出可能出现的问题。参考常见模式中的类别清单。使用resources/template.md中的登记册结构。

步骤2：评估概率和影响

为每个风险的概率（1-5：罕见至几乎确定）和影响（1-5：极小至严重）评分。邀请主题专家参与以确保准确性。参考风险评分框架中的定义。

步骤3：计算风险评分并排序

将每个风险的概率乘以影响得到风险评分。在风险矩阵（5×5网格）上标记位置，可视化风险状况。优先缓解Critical/High风险。参考resources/methodology.md中的高级技术，如蒙特卡洛模拟。

步骤4：分配负责人并定义应对方案

对于每个High/Critical风险，指定具体负责人（不能是“团队”），定义缓解方案（降低发生概率）、应急方案（降低影响）和触发条件（何时启动应急方案）。参考resources/template.md中的应对计划结构。

步骤5：定期监控和更新

每周（活跃项目）或每月（长期项目）评审风险登记册。随着环境变化更新概率/影响，添加新风险，关闭已解决的风险，跟踪缓解进度。参考注意事项中的监控频率。

Common Patterns

常见模式

Risk categories (use for brainstorming):

Technical risks: Technology failure, integration issues, performance problems, security vulnerabilities, technical debt, complexity underestimated
Schedule risks: Dependencies delayed, estimation errors, scope creep, resource unavailability, critical path blocked
Resource risks: Key person leaves, skill gaps, budget overrun, vendor/contractor issues, equipment unavailable
External risks: Regulatory changes, market shifts, competitor actions, economic downturn, natural disasters, vendor bankruptcy
Scope risks: Unclear requirements, changing priorities, stakeholder disagreement, gold-plating, mission creep
Organizational risks: Lack of executive support, competing priorities, insufficient funding, organizational change, political conflicts

By project type:

Software projects: Third-party API changes, dependency vulnerabilities, cloud provider outages, data migration issues, browser compatibility, scaling problems, security breaches
Construction projects: Weather delays, material shortages, permit issues, labor strikes, soil conditions, cost overruns, safety incidents
Product launches: Manufacturing delays, supply chain disruption, competitor launch, pricing miscalculation, market demand lower than expected, quality issues
Organizational change: Employee resistance, communication breakdown, training inadequate, budget cuts, leadership turnover, cultural misalignment

By risk response type:

Mitigate (reduce probability): Training, prototyping, process improvements, redundancy, quality checks, early testing
Contingency (reduce impact if occurs): Backup plans, insurance, reserves (time/budget), alternative suppliers, rollback procedures
Accept (do nothing): Low-score risks not worth mitigation cost, residual risks after mitigation
Transfer (shift to others): Insurance, outsourcing, contracts (penalty clauses), warranties

Typical risk profile evolution:

Project start: Many medium risks (uncertainty high), few critical (pre-mitigation)
Mid-project: Critical risks mitigated to medium/low, new risks emerge (dependencies, integration)
Near completion: Low risks dominate (most issues resolved), few high (last-minute surprises)
Red flag: Risk score increasing over time (mitigation not working, new issues emerging faster than resolution)

风险类别（用于头脑风暴）：

技术风险：技术故障、集成问题、性能问题、安全漏洞、技术债务、复杂度被低估
进度风险：依赖关系延迟、估算错误、范围蔓延、资源不可用、关键路径受阻
资源风险：核心人员离职、技能缺口、预算超支、供应商/承包商问题、设备不可用
外部风险：监管变化、市场转变、竞争对手行动、经济衰退、自然灾害、供应商破产
范围风险：需求不明确、优先级变更、相关方意见不一致、镀金需求、任务蔓延
组织风险：缺乏高管支持、优先级冲突、资金不足、组织变革、政治冲突

按项目类型划分：

软件项目：第三方API变更、依赖漏洞、云服务商 outage、数据迁移问题、浏览器兼容性、扩展问题、安全漏洞
建筑项目：天气延迟、材料短缺、许可问题、劳工罢工、土壤条件、成本超支、安全事故
产品发布：制造延迟、供应链中断、竞争对手发布、定价错误、市场需求低于预期、质量问题
组织变革：员工抵制、沟通中断、培训不足、预算削减、领导层变动、文化不匹配

按风险应对类型划分：

缓解（降低发生概率）：培训、原型设计、流程改进、冗余、质量检查、早期测试
应急（降低发生后的影响）：备用计划、保险、储备（时间/预算）、替代供应商、回滚流程
接受（不采取行动）：低评分风险，缓解成本过高；缓解后残留的风险
转移（转移给他人）：保险、外包、合同（惩罚条款）、保修

典型风险状况演变：

项目启动阶段：大量中等风险（不确定性高），少量Critical风险（缓解前）
项目中期：Critical风险已缓解为中等/低风险，新风险出现（依赖关系、集成）
项目接近完成：低风险占主导（大多数问题已解决），少量高风险（最后一分钟的意外）
危险信号：风险评分随时间上升（缓解措施无效，新问题出现速度快于解决速度）

Risk Scoring Framework

风险评分框架

Probability Scale (1-5):

5 - Almost Certain (>80%): Expected to occur, historical data confirms, no mitigation in place
4 - Likely (60-80%): Probably will occur, similar projects had this issue, weak mitigation
3 - Possible (40-60%): May or may not occur, depends on circumstances, some mitigation in place
2 - Unlikely (20-40%): Probably won't occur, mitigation in place, low historical precedent
1 - Rare (<20%): Very unlikely, strong mitigation, no historical precedent

Impact Scale (1-5) - adjust dimensions for project context:

For Schedule Impact:

5 - Severe: >20% delay (e.g., 3-month project delayed 3+ weeks), miss critical deadline, cascading delays
4 - Major: 10-20% delay, miss milestone, affects dependent projects
3 - Moderate: 5-10% delay, timeline buffer consumed, no external impact
2 - Minor: <5% delay, absorbed within sprint/phase, minor schedule pressure
1 - Minimal: <1% delay or no delay, negligible schedule impact

For Budget Impact:

5 - Severe: >20% budget overrun, requires new funding approval, project viability threatened
4 - Major: 10-20% overrun, contingency exhausted, scope cuts required
3 - Moderate: 5-10% overrun, contingency partially used, no scope cuts
2 - Minor: <5% overrun, absorbed within budget flexibility
1 - Minimal: <1% overrun or no budget impact

For Scope/Quality Impact:

5 - Severe: Core functionality lost, customer-facing quality issue, regulatory violation
4 - Major: Important feature cut, significant quality degradation, customer complaints
3 - Moderate: Nice-to-have feature cut, minor quality issue, internal workarounds needed
2 - Minor: Edge case feature cut, cosmetic quality issue
1 - Minimal: No scope or quality impact

Composite Impact (when multiple dimensions affected):

Use maximum of any single dimension (pessimistic, conservative)
OR use weighted average: Schedule 40%, Budget 30%, Scope/Quality 30%

Example Scoring:

Risk: "Key engineer leaves mid-project"

Probability: 2 (Unlikely - 20% based on tenure, satisfaction, retention rate)
Impact Schedule: 4 (Major - 3-week delay to onboard replacement, knowledge transfer)
Impact Budget: 2 (Minor - recruiter fees, some overtime)
Impact Scope: 3 (Moderate - may cut advanced features)
Composite Impact: 4 (take maximum: schedule impact is worst)
Risk Score: 2 × 4 = 8 (Medium)

概率量表（1-5）：

5 - 几乎确定（>80%）：预计会发生，历史数据证实，未采取缓解措施
4 - 可能（60-80%）：很可能发生，类似项目曾出现此问题，缓解措施薄弱
3 - 可能（40-60%）：可能发生也可能不发生，取决于环境，已采取部分缓解措施
2 - 不太可能（20-40%）：很可能不会发生，已采取缓解措施，历史先例少
1 - 罕见（<20%）：极不可能发生，缓解措施完善，无历史先例

影响量表（1-5）- 根据项目环境调整维度：

进度影响：

5 - 严重：延迟>20%（如3个月项目延迟3周以上），错过关键截止日期，引发连锁延迟
4 - 重大：延迟10-20%，错过里程碑，影响依赖项目
3 - 中等：延迟5-10%，消耗时间缓冲，无外部影响
2 - 轻微：延迟<5%，在迭代/阶段内吸收，轻微进度压力
1 - 极小：延迟<1%或无延迟，对进度可忽略不计

预算影响：

5 - 严重：预算超支>20%，需要新的资金审批，项目可行性受威胁
4 - 重大：超支10-20%，应急储备耗尽，需要缩减范围
3 - 中等：超支5-10%，应急储备部分使用，无需缩减范围
2 - 轻微：超支<5%，在预算灵活性范围内吸收
1 - 极小：超支<1%或无预算影响

范围/质量影响：

5 - 严重：核心功能丢失，面向客户的质量问题，违反法规
4 - 重大：重要功能被削减，质量显著下降，客户投诉
3 - 中等：非核心功能被削减，轻微质量问题，需要内部 workaround
2 - 轻微：边缘功能被削减，外观质量问题
1 - 极小：无范围或质量影响

综合影响（当多个维度受影响时）：

使用单个维度的最大值（悲观、保守）
或使用加权平均值：进度40%，预算30%，范围/质量30%

评分示例：

风险：“核心工程师在项目中期离职”

概率：2（不太可能 - 根据任期、满意度、留存率为20%）
进度影响：4（重大 - 入职替代人员和知识转移需要3周延迟）
预算影响：2（轻微 - 招聘费用、少量加班）
范围影响：3（中等 - 可能削减高级功能）
综合影响：4（取最大值：进度影响最严重）
风险评分：2 × 4 = 8（Medium）

Guardrails

注意事项

Ensure quality:

Identify risks proactively, not reactively: Run risk workshops before problems occur
- ✓ Brainstorm risks at project kickoff, use checklists (technical, schedule, resource, etc.)
- ❌ Add risks only after incidents occur (reactive)
Be specific, not vague: "Integration fails" is vague, "Vendor API rate limits block migration" is specific
- ✓ "Third-party payment gateway rejects 10% of transactions due to fraud rules"
- ❌ "Payment issues"
Separate probability and impact: Don't conflate "bad if it happens" with "likely to happen"
- ✓ Asteroid hits office: Prob=1 (rare), Impact=5 (severe), Score=5 (low priority)
- ❌ Conflating: "This is really bad so it must be high priority" (ignoring low probability)
Assign named owners, not teams: "Engineering team" is not accountable, "Sarah (Tech Lead)" is
- ✓ Owner: Sarah (Tech Lead), responsible for monitoring and activating contingency
- ❌ Owner: Engineering Team (diffused responsibility)
Define mitigation AND contingency: Mitigation reduces probability, contingency handles if it occurs anyway
- ✓ Mitigation: Prototype integration early (reduce prob). Contingency: Build abstraction layer for quick swap (reduce impact)
- ❌ Only mitigation, no backup plan
Update regularly: Stale risk register is worse than none (false confidence)
- ✓ Weekly review for active projects (High/Critical risks), monthly for longer projects
- ❌ Create register at kickoff, never update (probabilities/impacts change as project progresses)
Retire closed risks: Don't let register grow indefinitely, archive mitigated/irrelevant risks
- ✓ Mark risk "Closed" with resolution date, move to archive section
- ❌ Keep all risks forever (signal-to-noise ratio degrades)
Escalate critical risks immediately: Don't wait for weekly meeting if Critical risk emerges
- ✓ Prob=5 Impact=5 Score=25 → Escalate to exec same day, emergency mitigation
- ❌ Wait for scheduled review (risk could materialize)

确保质量：

主动识别风险，而非被动应对：在问题发生前举办风险研讨会
- ✓ 在项目启动时进行风险头脑风暴，使用清单（技术、进度、资源等）
- ❌ 仅在事件发生后添加风险（被动）
具体明确，而非模糊笼统：“集成失败”过于模糊，“供应商API速率限制阻碍迁移”则具体明确
- ✓ “第三方支付网关因欺诈规则拒绝10%的交易”
- ❌ “支付问题”
区分概率和影响：不要将“发生后后果严重”与“发生可能性高”混为一谈
- ✓ 小行星撞击办公室：概率=1（罕见），影响=5（严重），评分=5（低优先级）
- ❌ 混淆：“这后果很严重，所以必须优先处理”（忽略低概率）
指定具体负责人，而非团队：“工程团队”没有明确问责，“Sarah（技术主管）”则明确
- ✓ 负责人：Sarah（技术主管），负责监控和启动应急方案
- ❌ 负责人：工程团队（责任分散）
同时定义缓解和应急方案：缓解方案降低发生概率，应急方案处理已发生的情况
- ✓ 缓解：提前进行集成原型设计（降低概率）。应急：构建抽象层以便快速替换（降低影响）
- ❌ 仅制定缓解方案，无备用计划
定期更新：过时的风险登记册比没有更糟（虚假信心）
- ✓ 每周评审活跃项目，每月评审长期项目
- ❌ 仅在项目启动时创建，从不更新（概率/影响随项目进展变化）
关闭已解决的风险：不要让登记册无限增长，归档已缓解/不相关的风险
- ✓ 标记风险为“已关闭”并记录解决日期，移至归档部分
- ❌ 永久保留所有风险（信噪比降低）
立即上报Critical风险：如果出现Critical风险，不要等到每周会议
- ✓ 概率=5 影响=5 评分=25 → 当天上报高管，启动紧急缓解措施
- ❌ 等待预定评审（风险可能已发生）

Quick Reference

快速参考

Resources:

Quick start: resources/template.md - Risk register template with scoring table, response planning, monitoring log
Advanced techniques: resources/methodology.md - Monte Carlo simulation, decision trees, sensitivity analysis, risk aggregation, earned value management
Quality check: resources/evaluators/rubric_project_risk_register.json - Evaluation criteria

Success criteria:

✓ Identified 15-30 risks across all categories (technical, schedule, resource, external, scope, org)
✓ All High/Critical risks (score ≥12) have named owners, mitigation plans, and contingencies
✓ Risk scores differentiated (not all scored 6-9; use full 1-25 range)
✓ Mitigation and contingency plans are specific and actionable (not "monitor closely")
✓ Triggers defined for when to activate contingencies (quantifiable thresholds)
✓ Register updated regularly (weekly for active projects, monthly for longer projects)
✓ Risk profile matches project phase (high uncertainty at start, decreasing over time)

Common mistakes:

❌ Too few risks identified (<10) → incomplete risk picture, false confidence
❌ All risks scored medium (6-9) → not differentiated, unclear prioritization
❌ Vague risks ("things might not work") → not actionable
❌ No risk owners assigned → diffused accountability, mitigation doesn't happen
❌ Mitigation without contingency → no backup plan if mitigation fails
❌ Created once, never updated → stale data, risks evolve
❌ Only negative risks (threats) → missing opportunities (positive risks)
❌ Risk register separate from project plan → not integrated into workflow

When to use alternatives:

Pre-mortem: When project hasn't started, want to imagine failure scenarios (complements risk register)
FMEA (Failure Mode Effects Analysis): Manufacturing/engineering projects needing detailed failure analysis
Monte Carlo simulation: When need probabilistic timeline/budget forecasting (use methodology.md)
Decision tree: When risks involve sequential decisions with branch points
Scenario planning: When risks are strategic/long-term (market shifts, competitor actions)

资源：

快速入门：resources/template.md - 包含评分表、应对计划、监控日志的风险登记册模板
高级技术：resources/methodology.md - 蒙特卡洛模拟、决策树、敏感性分析、风险聚合、挣值管理
质量检查：resources/evaluators/rubric_project_risk_register.json - 评估标准

成功标准：

✓ 识别15-30个跨类别的风险
✓ 所有High/Critical风险（评分≥12）都有指定负责人、缓解计划和应急方案
✓ 风险评分有区分（并非全部为6-9分；使用1-25的完整范围）
✓ 缓解和应急方案具体可落地（而非“密切监控”）
✓ 定义了启动应急方案的触发条件（可量化阈值）
✓ 定期更新登记册（活跃项目每周，长期项目每月）
✓ 风险状况与项目阶段匹配（启动时不确定性高，随时间降低）

常见错误：

❌ 识别的风险过少（<10个）→ 风险画像不完整，虚假信心
❌ 所有风险均为中等评分（6-9）→ 无区分度，优先级不明确
❌ 风险描述模糊（“可能行不通”）→ 无法落地
❌ 未指定风险负责人→ 责任分散，缓解措施无法落实
❌ 仅制定缓解方案，无应急计划→ 缓解失败时无备用方案
❌ 创建后从不更新→ 数据过时，风险不断演变
❌ 仅识别负面风险（威胁）→ 遗漏机会（正面风险）
❌ 风险登记册与项目计划分离→ 未集成到工作流程中

何时使用替代方法：

事前验尸：项目尚未启动时，想象失败场景（补充风险登记册）
FMEA（失效模式与影响分析）：需要详细失效分析的制造/工程项目
蒙特卡洛模拟：需要概率性进度/预算预测时（参考methodology.md）
决策树：风险涉及顺序决策和分支点时
情景规划：风险为战略/长期（市场转变、竞争对手行动）时