项目风险与规避

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

9风险分析及规避措施广东海洋大学学生实验报告

书(学生用表)

9.1产品风险管理计划

对于本项目的可能采取的风险管理方法主要有以下几种类别:

◆专家评判干法:经验估计法、Delphi 法、清单法与当量分析

◆问卷法:调查与统计分析方法

◆简单风险结构描述与分析工具:决策树分析法、层次分析法、风险矩阵法◆复杂风险结构描述与评估工具:影响图、Petri 网、网络分析技术

◆可靠性分析法:故障模式及影响分析、概率风险评估

◆人工智能方法:贝叶斯网络、粗糙集理论、模糊集理论、人工神经网络、

专家系统

◆成本评估模型与工具:构造型成本模型、蒙特卡洛模拟、成本效益分析风险管理周期与频率:

风险管理周期与频率.bpm

风险管理预算:

预备风险资金 15000 元,用于削减项目成本、进度、范围、质量和资源等方面的风险。

9.2风险识别

通过讨论确定了七个主要的风险,下面是风险清单:

9.2.1组织风险

◆项目缺乏企业高层的支持和积极参与

◆项目进程过程中企业经历重组或管理层变动

◆项目所需的业务流程的变化与组织文化不相匹配

◆由于企业战略的变化,项目所需资源被转移

◆项目没有明确的商业价值,而是出于某些政治上的原因

◆项目计划没有征求所有相关方的同意

◆项目实施对组织结构具有较大影响

◆项目实施对业务流程具有较大影响

9.2.2需求风险

◆错误的系统需求

◆系统范围或需求频繁变动

◆不清晰或误解的需求

◆由于对该应用领域较陌生并且缺乏相关知识,用户和开发人员对系统需求

不能很好定义

◆用户与开发人员一技术为中心,而忽视了商业需求

◆相关人员对系统需求定义存在冲突

◆用户对系统功能和需求缺乏了解

◆没有定义,项目的成功标准

◆难以界定系统的输入和输出

◆系统需求分析不充分,有遗漏

9.2.3用户风险

◆缺乏用户的合作和责任

◆用户提出不切实际的期望

◆用户过度依赖咨询顾问,忽略了自身的重要作用◆用户抵触变化

◆用户对项目持否定态度

◆缺乏足够的用户参与

◆用户与开发人员之间存在分歧或冲突

◆用户部门之间存在冲突

◆用户没有按排足够用于系统维护阶段的预算

9.2.4技术风险

◆项目采用的是以前未曾实用过的新技术

◆缺乏有效的开发方法

◆项目需求与已有的其他系统进行较多的集成

◆技术相当复杂

◆使用不成熟的技术

9.2.5团队风险

◆项目开发团队成员缺乏责任感

◆项目团队成员在性格、态度、观念方面存在冲突◆项目团队成员变动频繁和严重短缺

◆团队成员不熟悉自己的任务

◆开发人员缺乏项目所需的技能

◆开发人员没有经过充分培训

9.2.6计划和控制风险

◆没有清晰地设立项目里程碑

◆缺乏有效的项目管理方法

◆项目计划制订得很糟糕

◆项目所需资金和资源估计不足

◆项目干系人之间缺乏有效的沟通

◆项目所需时间和进度估计不足

◆对项目进展状况监控不够

◆没有实行有效的变化管理

◆对相关方(如开发商和顾问)的角色和责任没有进行明确和合理的规定◆风险管理很糟糕

◆选择了错误的系统开发方法

◆对顾问、开发商及合同方缺乏控制

9.2.7市场和竞争风险

市场发生变化以至于项目不能获得预期的商业价值

竞争者着手开发类似系统或采取其他难以防范的行动

合作伙伴、客户、供应商和商业团体做出对项目产生影响的不利举动

市场上新的替代产品、服务或技术出现使系统变得过时

项目相关方没有提供很好的服务和帮助

项目依赖过多的供应商,缺乏供应商之间的合作,软件包不兼容很难进行集成

9.3风险定性分

析(包括定性分

析与定量分析)

集成

(1~3 为不能接受的风险,4~6 为不希望有的风险,7~9 为可控制的风险,10~12 为可以接受的风险)

9.4风险应Array

对计划

法w.项目经理应该选用其他的开发方法,比如原

型法

9.5风险监控

对风险监控主要用基于战略的监控方式并确定风险阀值。一旦战略目标和风险变量超过了预定的范围,即超出了风险阀值,就说明该战略目标没有得到很好的执行,需要控制影响各战略目标的风险,并制定相应的风险应对执行方案。风险阀值的计算公式如下:

T(阀值)=N(额定指标值)X W(权重)

风险监控流程如下:

风险监控.oom

相关文档
最新文档