PTM-RSKM-T01项目风险计划与跟踪表.xlsVIP

风险分类与检查项 风险跟踪裂变 封面 effort.ta size.ta ID 状态 类别 描述 识别时间 数值 时间 人员 内容 负责人 执行情况 触发条件 可能造成的危害 商业风险 风险类型 检查项 政府或者其他机构对本项目的开发有限制吗？ 有不可预测的市场动荡吗？ 有不利于我方的官司要打吗？ 本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？ 竞争对手有不正当的竞争行为吗？ 是否在开发很少有人真正需要却自以为很好的产品？ 是否在开发可能亏本的产品？ 客户 客户是否反反复复地改动需求？ 客户指定的需求和交付期限在客观上可行吗？ 客户对产品的健壮性、可靠性、性能等质量因素有非常过分的要求吗？ 客户的合作态度友善吗？ 与客户签的合同公正吗？双方互利吗？ 客户的信誉好吗？例如按客户的需求开发了产品，但是客户可能不购买。 子承包商 与子承包商、供应商签订的合同公正吗？双方互利吗？ 子承包商、供应商的信誉好吗？ 子承包商、供应商有可能倒闭吗？ 子承包商、供应商能及时交付质量合格的产品（或部件）吗？ 子承包商、供应商有能力做好售后服务吗？ 管理风险 项目计划 人力资源（开发人员、管理人员）够用吗？合格吗？ 项目所需的软件、硬件能按时到位吗？ 项目的经费够用吗？ 进度安排是否过于紧张？有合理的缓冲时间吗？ 进度表中是否遗忘了一些重要的（必要的）任务？ 进度安排是否考虑了关键路径？ 是否可能出现某一项工作延误导致其他一连串的工作也被延误？ 任务分配是否合理？（即把任务分配给合适的项目成员，充分发挥其才能） 是否为了节省钱，不采用（购买）成熟的软件模块，一切从零做起？ … 项目团队 项目成员团结吗？是否存在矛盾？ 是否绝大部分的项目成员对工作认真负责？ 绝大部分的项目成员有工作热情吗？ 团队之中有“害群之马”吗？ 技术开发队伍中有临时工吗？ 本项目开发过程中是否会有核心人员辞职、调动？ 是否能保证“人员流动基本不会影响工作的连续性”？ 项目经理是否忙于行政事务而无暇顾及项目的开发工作？ 本项目是否得到上级领导的重视？ 上级领导是否随时会抽调本项目的资源用于其他“高优先级”的项目？ 上级领导是否过多地介入本项目的事务并且瞎指挥？ 行政部门的办事效率是否比较底，以至于拖项目的后腿？ 行政部门是否经常干一些无益于生产力的事情，以至于骚扰本项目？ 机构是否能全面、公正地考核员工的工作业绩？ 机构是否有较好的奖励和惩罚措施？ 本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？ 技术风险 需求开发人员懂得如何获取用户需求吗？效率高吗？ 需求开发人员懂得项目所涉及的具体业务吗？能否理解用户的需求？ 需求文档能够正确地、完备地表达用户需求吗？ 需求开发人员能否与客户对有争议的需求达成共识？ 需求开发人员能否获得客户对需求文档的承诺？以保证客户不随便变更需求？ 待开发的产品是否要与未曾证实的软硬件相连接？ 对开发人员而言，本项目的技术难度高吗？ 开发人员是否已经掌握了本项目的关键技术？ 如果某项技术尚未实践过，开发人员能否在预定时间内掌握？ 开发小组是否采用比较有效的分析、设计、编程、测试工具？ 分析与设计工作是否过于简单、草率，从而让程序员边做边改？ 开发小组采用统一的编程规范吗？ 开发人员对测试工作重视吗？能保证测试的客观性吗？ 项目有独立的测试人员吗？懂得如何进行高效率地测试吗？ 是否对所有重要的工作成果进行了同行评审（正式评审或快速检查）？ 开发人员懂得版本控制、变更控制吗？能够按照配置管理规范执行吗？ 开发人员重视质量吗？是否会在进度延误时降低质量要求？ 项目风险检查表 政治 法律 市场 上级领导 行政部门 合作部门 综合技术 开发能力 包括设计 编程、测试等 需求开发 需求管理 客户的需求是否含糊不清？ 对项目的规模、难度估计是否比较正确？ 开发人员是否有开发相似产品的经验？ 项目风险计划与跟踪表 文件修订履历： 版本号 日期 编写 审核 批准 摘要 模板修订履历： V1.0 初版发行 V1.1 风险跟踪列表添加追踪情况一列 V1.2 添加工作列表风险管理策略 避免/减缓计划 风险计划与跟踪表 预计发生时间 发生概率 影响 程度 优先级 应对计划 等级 Issue 需求 用户对于外网建设需求仍不明确，可能对设计、开发产生影响 造成设计、开发产生延期 张三 1、给用户提供类似的实现样例，引导客户。 2、准备将此问题与用户的上级做简要沟通。 李四 与用户沟通2次 当设计里程碑完成时 1、将此问题提交与用户开会确定此问题不影响项目验收，以会议纪要形式记录。 用户确认此问题作为遗留问题，不影响项目验收。 Active 团队 某人离职，对项目开发的影响 造成开发阶段延期 1、提醒部门经理，是否可以解决某人离职问题。 与部门经