项目管理风险评估表

项目管理风险评估表工具指南一、适用情境本工具适用于各类项目在启动前、关键节点推进中或外部环境发生重大变化时，对项目潜在风险进行系统性识别、分析与评估的场景。具体包括：新项目立项阶段，全面预判项目全生命周期风险；项目执行过程中，当范围、资源、技术等要素发生调整时，重新评估风险变化；镑周期项目（如研发、基建、活动策划等）在阶段性里程碑前，聚焦核心风险领域；团队对风险认知存在分歧时，通过结构化工具统一评估标准，形成共识。二、操作流程详解步骤1：明确评估范围与目标输入：项目章程、范围说明书、相关方需求文档。操作：确定评估边界（如项目阶段、涉及模块、地域范围）；定义风险评估目标（如识别10类以上核心风险、明确高优先级风险应对策略）。输出：《风险评估范围说明书》，明确评估对象与预期成果。步骤2：组建风险评估团队输入：项目组织架构、相关方登记册。操作：团队成员需包含：项目负责人、技术负责人、业务代表*、风险专家（可外部聘请）；明确团队分工：如风险识别由业务代表主导，可能性与影响评估由技术专家负责，整体协调由项目负责人把控。输出：《风险评估团队成员名单及职责表》。步骤3：风险信息收集输入：历史项目风险数据、行业风险库、团队经验。操作：收集项目背景信息（如预算、周期、技术复杂度、团队经验）；梳理历史类似项目的风险案例（如“某研发项目因第三方接口延迟导致延期2周”）；识别项目独特风险（如“首次采用的新技术存在适配风险”“政策变动导致合规要求变化”）。输出：《风险信息清单》（含风险描述、触发条件、潜在根源）。步骤4：风险识别与分类工具：头脑风暴法、德尔菲法、检查表法。操作：通过头脑风暴会议，鼓励团队成员自由提出潜在风险，记录所有观点（避免早期评判）；使用检查表法对照行业通用风险库（如“IT项目常见风险：需求变更频繁、技术瓶颈、资源不足”），补充遗漏风险；将识别出的风险按类别分类（参考下表“风险分类”维度）。输出：《风险清单初稿》（含风险编号、风险描述、所属类别）。步骤5：风险分析与量化评估评估维度：可能性：采用1-5级评分（1=极低，几乎不可能发生；5=极高，很可能发生）；影响程度：采用1-5级评分（1=轻微影响，对项目目标无实质影响；5=灾难性影响，导致项目失败）。操作：团队成员对《风险清单初稿》中的每项风险独立打分（可能性与影响程度）；计算平均分（四舍五入取整），根据公式“风险值=可能性×影响程度”得出风险等级；划分风险优先级：高风险（风险值≥15）、中风险（8≤风险值＜15）、低风险（风险值＜8）。输出：《风险等级评估表》（含风险值、优先级排序）。步骤6：制定风险应对策略策略选择：规避：改变项目计划消除风险（如“放弃高风险技术方案，改用成熟技术”）；转移：将风险影响转移给第三方（如“为关键设备购买保险，将故障风险转移给保险公司”）；减轻：降低风险可能性或影响程度（如“增加技术预研，降低新技术失败概率”）；接受：不改变项目计划，仅准备应急资源（如“预留10%应急预算，应对minor延期”）。操作：针对高、中风险项，明确应对策略、具体措施、责任人和完成时间；低风险项需记录并定期监控，不立即投入资源应对。输出：《风险应对计划表》（含应对策略、措施、责任人、时间节点）。步骤7：风险监控与更新操作：定期召开风险评审会（建议每周/双周），跟踪已识别风险状态（如“风险是否发生、应对措施是否有效”）；监控风险触发条件（如“供应商交付延迟超过3天，触发供应链风险应对”）；新风险出现时，及时补充至《风险清单》，重复步骤5-6评估更新。输出：《风险监控日志》（含风险状态、应对效果、新风险记录）。三、风险评估表模板风险编号风险描述（含触发条件）风险类别可能性（1-5）影响程度（1-5）风险值优先级应对策略具体措施责任人完成时间状态（未发生/发生中/已关闭）R001需求文档频繁变更（单月变更次数≥3次）范围风险4312中风险减轻建立变更控制委员会，评估变更影响*需求经理2024-03-15未发生R002核心算法技术攻关失败（原型测试通过率＜60%）技术风险3515高风险规避聘请外部技术顾问，提前验证可行性*技术总监2024-04-01未发生R003关键供应商交付延迟（合同约定交付日延期≥7天）外部风险248中风险转移在合同中约定延迟违约金，同时备选2家供应商*采购经理2024-03-20未发生R004项目预算超支（累计超支率≥10%）财务风险3412中风险减轻每月审核预算执行情况，设置预警阈值*财务经理持续监控未发生四、关键提示动态评估原则：风险并非一成不变，需结合项目进展（如需求冻结、技术方案确定）定期更新评估结果，避免“一次评估、全程使用”。客观性要求：打分时避免主观臆断，可参考历史数据（如“过去6个月内需求变更平均发生2.5次/月”），而非仅凭个人经验判断。团队全员参与：鼓励一线成员（如开发、测试）参与风险识别，避免因层级差异遗漏隐性风险（如“测试环境资源不足导致测试延期”