风险跟踪列表

项目经理项目启动日期缓解计划或应急计划预计完成时间1SP积分管理模块的导入功能的需求不明确技术风险SP积分管理2异变模块的工作安排未确定，人员未确定组织风险异变模块3数据挖掘模块的功能不明确，数据库与各模块之间的接口只完成了一半技术风险数据库4数据库与数据分析之间的接口定义比较模糊，数据库设计存在一定的难度技术风险数据库5营销支撑模块的数据分析流程还未确定技术风险数据分析6营销支撑模块模板开发技术风险营销支撑7营销数据未提供，表字段不完整，数据分析存在一定的困难技术风险数据分析8SP积分管理的架构重新调整了，需要重新开发，与原进度有所延迟技术风险SP积分管理概率：使用百分比值指定风险发生的概率。影响：使用1到10之间的值指定如果风险成为现实，所带来的负面影响的严重性。成本：指定如果风险成为现实，将对成本产生的影响。类别：指定风险类型。市场风险、技术风险、组织风险说明：指定风险的特征。当对同一个风险有多个应对策略时，应详细说明每个应对措施的适用时机工件标识：工件版号：0.5实际缓解和规避情况实际完成日期跟踪状态填表说明：跟踪状态的内容有七种：已提交、已开放、规避中、已规避、已触发、已补救、已发生。风险项及触发条件简要描述■新产品□升级版□过渡版□补丁版序号风险跟踪列表产品名称及版本号项目类型应对与缓解和规避策略与措施责任人所属模块风险类型缓解计划：指定缓解风险的计划。触发说明：指定触发类型。应急计划：指定在风险发生时可以执行的计划。触发：指定触发应急计划的条件。是评估项目发现风险提交风险已提交确定应对和缓解策略已开放实施缓解策略规避中是否需实施缓解策略已规避是否规避成功不实施缓解策略，等待事件驱动触发条件是否满足已触发是否补救成功满足成功已补救已发生失败已补救▲进度安排制定得是否合理？▲WBS的分析是否足够细，以便对进度做较贴切的安排？▲对交付日期的要求是否严格？▲是否可以为了满足严格进度安排而对产品功能进行让步放行？▲计划是否为过程管理预留时间？▲对产品的需求是否和涉众认同一致？▲需求是否有优先级排列？▲对需求的变化是否建立了相应的管理机制并实施？▲对需求的变化是否做相应的分析？▲需求是否稳定并达到了充分的共识？▲规模的估计方法是否正确掌握和使用？▲项目规模是固定不变还是在不断扩展或变更？▲项目开发规模或范围预估是否正确？▲系统是否依赖于新的或未经试验的产品、服务或技术？是否依赖于新的或未被证明的硬件、软件或技术？▲对于与其他系统（包括企业以外的系统）的接口是否存在外部依赖性？▲该项目是否依赖于其他（平行的）开发项目？▲所采用技术是否已经过使用？▲使用的组件是否被成功的重复使用？重复使用的组件是否合理？▲数据量是否合理？当前可用的系统框架是否能够保存这些数据？▲是否有特殊或苛刻的技术需求（如要求项目团队处理他们不熟悉的问题）？▲是否存在极不灵活的可用性和安全性需求（如“系统必须永远不出现故障”）？▲系统的用户是否对正在开发的系统类型没有经验？▲应用程序的大小或复杂性是否导致了风险的增加？▲成功是否依赖于开发工具（设计工具、编译器等）和实施技术（操作系统、数据库、进程间通信机制等）的成功集成。是否有替代计划，可以在没有这些技术的情况下交付项目？▲是否获得必要的人员（测试人员、QA、SCM人员）？▲项目人员是否具备合适的技能和经验以及接受过相应培训？▲项目人员是否会有突然接受其他任务的可能性？▲他们对项目成功是否有信心和决心？▲完成项目所需的资金能否到位？▲是否有预算限制？▲项目的成本预算是否准确？▲是否有预留风险管理等资金？▲用户的配合程度，是否导致项目难以进行？▲用户环境以及外界环境变更是否将使软件中断或中止？人员资金用户风险考虑因素列表进度风险规模风险外部依赖风险技术风险