Project Risk Early Warning — 项目风险预警

Use when the user manages projects and wants to identify potential delays, resource bottlenecks, or risks before they materialize into actual problems.

NOT for: financial risk assessment, personal risk tolerance evaluation, security vulnerability scanning, or insurance risk calculation.

描述

为项目经理和团队负责人提供风险预警分析，根据进度数据、资源分配和历史模式，提前识别延期风险与资源瓶颈，从"后知后觉"变为"未雨绸缪"。

重要限制（请提前告知用户）

• 依赖用户输入的进度数据准确性，"garbage in garbage out"
• 不能替代项目管理经验判断，工具提供参考，决策需人工确认
• 无法预测外部不可控因素（如政策变化、天灾、关键人离职）
• 预警是概率性判断，非100%确定会发生

快速开始

我的项目计划完成60%但时间已过70%，帮我分析风险

团队有3个人同时被其他项目借调，帮我评估对进度的影响

这个项目有5个关键里程碑，帮我识别哪些最可能延期

帮我建立一个项目风险监控清单，我每周可以对照检查

能力

• 进度偏差分析：对比计划vs实际进度，量化偏差程度
• 资源瓶颈识别：发现过载的人员/设备/预算节点
• 依赖链风险：识别关键路径上的脆弱环节
• 历史模式匹配：基于常见项目延期模式给出预警
• 风险等级评估：按概率×影响给风险分级
• 应对方案建议：针对每个风险提供缓解/规避/转移策略

执行步骤（Step by Step）

Step 1：项目数据采集

1. 了解项目总体计划（起止时间、里程碑）
2. 获取当前进度状态（已完成/进行中/未开始的占比）
3. 识别关键资源和依赖关系
4. 了解已知的问题和障碍

Step 2：风险识别与评估

1. 计算进度偏差率（SPI指标）
2. 检查关键路径上各节点的健康度
3. 识别资源冲突和过载点
4. 匹配常见风险模式（范围蔓延、技术债、沟通断层）

Step 3：预警与方案输出

1. 按风险等级排序输出预警清单
2. 为每个风险提供触发条件和观察指标
3. 给出应对建议（缓解/规避/接受/转移）
4. 建议监控频率和升级机制

输出格式

## 项目风险预警报告

### 项目概况
- 项目名称：XX系统重构
- 计划周期：2024.01 - 2024.06（24周）
- 当前进度：第16周，计划完成67%，实际完成52%
- 进度偏差：⚠️ 落后15个百分点（SPI=0.78）

### 风险预警清单
| # | 风险描述 | 概率 | 影响 | 等级 | 触发信号 |
|---|----------|------|------|------|----------|
| 1 | 接口联调延期导致整体上线推迟 | 高 | 高 | 🔴严重 | 联调开始时间已推迟1周 |
| 2 | 前端开发人力不足 | 高 | 中 | 🟠较高 | 2人被借调，剩余1人 |
| 3 | 需求范围持续扩大 | 中 | 高 | 🟠较高 | 本月新增需求3个 |
| 4 | 测试环境不稳定 | 中 | 中 | 🟡中等 | 上周环境故障2次 |
| 5 | 第三方API对接不确定 | 低 | 高 | 🟡中等 | 对方未确认接口文档 |

### 应对建议

**🔴 风险1：接口联调延期**
- 缓解：提前准备Mock接口，前端不等后端
- 规避：协调后端团队优先完成关键接口
- 升级：若下周仍未开始联调，向PMO报告

**🟠 风险2：前端人力不足**
- 缓解：临时外包部分页面开发
- 规避：与借调方协商提前归还人员
- 接受：降低非核心页面的交付标准

### 建议监控节点
- 每周一检查：进度偏差率、新增需求数
- 每周三检查：资源到位情况、阻塞问题数
- 下一个里程碑：3月30日 接口联调开始 ← 关键观察点

输出原则

1. 风险描述必须具体，不能含糊（"可能延期"→"接口联调推迟导致上线延期2周"）
2. 每个风险必须有可观察的触发信号和量化指标
3. 应对方案分缓解/规避/转移/接受四类，不只说"注意"
4. 预警等级基于概率×影响的二维评估
5. 报告面向行动，每个风险必须有明确的下一步

错误处理

常见问题（FAQ）

Q：没有项目管理工具也能做风险预警吗？

A：可以。只要能描述当前状态和计划，就能做分析。甚至一张Excel进度表也足够。

Q：多久做一次风险评估合适？

A：关键阶段每周一次，平稳阶段每两周一次。里程碑前后加做一次快速检查。

Q：风险预警出来了但上级不重视怎么办？

A：用数据说话。量化延期的损失（如每延期一周=XX万成本），比主观判断更有说服力。

Q：怎么区分"风险"和"问题"？

A：风险是尚未发生的潜在威胁（需要监控），问题是已经发生的障碍（需要解决）。预警处理的是风险。

Q：小项目也需要风险预警吗？

A：周期超过1个月或涉及跨团队协作的项目都建议做。5分钟快速检查就能避免大坑。

Q：风险预警和项目复盘有什么区别？

A：预警是前瞻性的（项目进行中），复盘是回顾性的（项目结束后）。两者配合形成闭环。

最佳实践

1. 把风险预警变成周例会的固定议程（5分钟快速过一遍）
2. 建立风险台账，已关闭的风险保留作为未来项目参考
3. 对关键路径上的任务设定提前预警线（进度落后10%即触发）
4. 鼓励团队主动上报风险，而非等到出问题才暴露
5. 每个风险必须有明确的Owner，不能"大家注意一下"

不适用场景

常见误用：

• 只记录风险不采取行动（预警的目的是推动应对）
• 风险评估变成走形式（应基于真实数据分析）
• 把所有不确定性都列为风险（应聚焦高概率高影响的）

安全与隐私

• 用户的项目进度和团队信息仅用于本次分析
• 不存储项目的商业敏感数据和客户信息
• 建议用户在提供信息时使用项目代号而非全名
• 风险报告可能涉及人员能力评估，建议谨慎传播