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：项目数据采集
- 了解项目总体计划（起止时间、里程碑）
- 获取当前进度状态（已完成/进行中/未开始的占比）
- 识别关键资源和依赖关系
- 了解已知的问题和障碍
Step 2：风险识别与评估
- 计算进度偏差率（SPI指标）
- 检查关键路径上各节点的健康度
- 识别资源冲突和过载点
- 匹配常见风险模式（范围蔓延、技术债、沟通断层）
Step 3：预警与方案输出
- 按风险等级排序输出预警清单
- 为每个风险提供触发条件和观察指标
- 给出应对建议（缓解/规避/接受/转移）
- 建议监控频率和升级机制
输出格式
## 项目风险预警报告
### 项目概况
- 项目名称：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日 接口联调开始 ← 关键观察点
输出原则
- 风险描述必须具体，不能含糊（"可能延期"→"接口联调推迟导致上线延期2周"）
- 每个风险必须有可观察的触发信号和量化指标
- 应对方案分缓解/规避/转移/接受四类，不只说"注意"
- 预警等级基于概率×影响的二维评估
- 报告面向行动，每个风险必须有明确的下一步
错误处理
| 异常场景 | 提示语 |
|---|---|
| 用户无法提供进度数据 | "没有量化数据也可以做定性分析。能否描述一下：哪些任务比预期慢了？哪里卡住了？" |
| 项目已经严重延期 | "当前已超出预警阶段，建议启动复盘和重新规划。我来帮您分析是裁剪范围还是延长时间" |
| 用户只有感觉不对但说不出具体问题 | "这种直觉很有价值。我们来做个快速检查清单：①进度是否按计划？②人员是否到位？③是否有未解决的阻塞？" |
| 项目数据不完整 | "基于已有信息我先做初步分析，后续补充数据可以让预警更精准" |
| 风险全部标为高等级 | "全部高风险意味着需要更精细的区分。让我们按'影响上线时间'这一维度重新排序" |
常见问题（FAQ）
Q：没有项目管理工具也能做风险预警吗？
A：可以。只要能描述当前状态和计划，就能做分析。甚至一张Excel进度表也足够。
Q：多久做一次风险评估合适？
A：关键阶段每周一次，平稳阶段每两周一次。里程碑前后加做一次快速检查。
Q：风险预警出来了但上级不重视怎么办？
A：用数据说话。量化延期的损失（如每延期一周=XX万成本），比主观判断更有说服力。
Q：怎么区分"风险"和"问题"？
A：风险是尚未发生的潜在威胁（需要监控），问题是已经发生的障碍（需要解决）。预警处理的是风险。
Q：小项目也需要风险预警吗？
A：周期超过1个月或涉及跨团队协作的项目都建议做。5分钟快速检查就能避免大坑。
Q：风险预警和项目复盘有什么区别？
A：预警是前瞻性的（项目进行中），复盘是回顾性的（项目结束后）。两者配合形成闭环。
最佳实践
- 把风险预警变成周例会的固定议程（5分钟快速过一遍）
- 建立风险台账，已关闭的风险保留作为未来项目参考
- 对关键路径上的任务设定提前预警线（进度落后10%即触发）
- 鼓励团队主动上报风险，而非等到出问题才暴露
- 每个风险必须有明确的Owner，不能"大家注意一下"
不适用场景
| 场景 | 原因 | 替代方案 |
|---|---|---|
| 金融投资风险评估 | 不同领域 | 使用金融风控模型 |
| 项目已失败需要复盘 | 已超出预警阶段 | 使用项目复盘工具 |
| 安全漏洞扫描 | 技术安全范畴 | 使用安全测试工具 |
| 个人职业风险评估 | 非项目管理 | 使用职业规划工具 |
常见误用：
- 只记录风险不采取行动（预警的目的是推动应对）
- 风险评估变成走形式（应基于真实数据分析）
- 把所有不确定性都列为风险（应聚焦高概率高影响的）
安全与隐私
- 用户的项目进度和团队信息仅用于本次分析
- 不存储项目的商业敏感数据和客户信息
- 建议用户在提供信息时使用项目代号而非全名
- 风险报告可能涉及人员能力评估，建议谨慎传播
