项目风险及规避
发布时间:2020-06-22 02:18:34
发布时间:2020-06-22 02:18:34
广东海洋大学学生实验报告书(学生用表)
实验名称 | 项目规划 | 课程名称 | 软件工程 | 成绩 | |||
学院(系) | 软件学院 | 专业 | 软件工程 | 班级 | |||
学生姓名 | 学号 | 实验地点 | 实验时间 | 2016-4-28 第3大节 | |||
对于本项目的可能采取的风险管理方法主要有以下几种类别:
◆ 专家评判干法:经验估计法、Delphi法、清单法与当量分析
◆ 问卷法:调查与统计分析方法
◆ 简单风险结构描述与分析工具:决策树分析法、层次分析法、风险矩阵法
◆ 复杂风险结构描述与评估工具:影响图、Petri网、网络分析技术
◆ 可靠性分析法:故障模式及影响分析、概率风险评估
◆ 人工智能方法:贝叶斯网络、粗糙集理论、模糊集理论、人工神经网络、专家系统
◆ 成本评估模型与工具:构造型成本模型、蒙特卡洛模拟、成本效益分析
风险管理周期与频率:
风险管理预算:
预备风险资金15000元,用于削减项目成本、进度、范围、质量和资源等方面的风险。
通过讨论确定了七个主要的风险,下面是风险清单:
◆ 项目缺乏企业高层的支持和积极参与
◆ 项目进程过程中企业经历重组或管理层变动
◆ 项目所需的业务流程的变化与组织文化不相匹配
◆ 由于企业战略的变化,项目所需资源被转移
◆ 项目没有明确的商业价值,而是出于某些政治上的原因
◆ 项目计划没有征求所有相关方的同意
◆ 项目实施对组织结构具有较大影响
◆ 项目实施对业务流程具有较大影响
◆ 错误的系统需求
◆ 系统范围或需求频繁变动
◆ 不清晰或误解的需求
◆ 由于对该应用领域较陌生并且缺乏相关知识,用户和开发人员对系统需求不能很好定义
◆ 用户与开发人员一技术为中心,而忽视了商业需求
◆ 相关人员对系统需求定义存在冲突
◆ 用户对系统功能和需求缺乏了解
◆ 没有定义,项目的成功标准
◆ 难以界定系统的输入和输出
◆ 系统需求分析不充分,有遗漏
◆ 缺乏用户的合作和责任
◆ 用户提出不切实际的期望
◆ 用户过度依赖咨询顾问,忽略了自身的重要作用
◆ 用户抵触变化
◆ 用户对项目持否定态度
◆ 缺乏足够的用户参与
◆ 用户与开发人员之间存在分歧或冲突
◆ 用户部门之间存在冲突
◆ 用户没有按排足够用于系统维护阶段的预算
◆ 项目采用的是以前未曾实用过的新技术
◆ 缺乏有效的开发方法
◆ 项目需求与已有的其他系统进行较多的集成
◆ 技术相当复杂
◆ 使用不成熟的技术
◆ 项目开发团队成员缺乏责任感
◆ 项目团队成员在性格、态度、观念方面存在冲突
◆ 项目团队成员变动频繁和严重短缺
◆ 团队成员不熟悉自己的任务
◆ 开发人员缺乏项目所需的技能
◆ 开发人员没有经过充分培训
◆ 没有清晰地设立项目里程碑
◆ 缺乏有效的项目管理方法
◆ 项目计划制订得很糟糕
◆ 项目所需资金和资源估计不足
◆ 项目干系人之间缺乏有效的沟通
◆ 项目所需时间和进度估计不足
◆ 对项目进展状况监控不够
◆ 没有实行有效的变化管理
◆ 对相关方(如开发商和顾问)的角色和责任没有进行明确和合理的规定
◆ 风险管理很糟糕
◆ 选择了错误的系统开发方法
◆ 对顾问、开发商及合同方缺乏控制
市场发生变化以至于项目不能获得预期的商业价值
竞争者着手开发类似系统或采取其他难以防范的行动
合作伙伴、客户、供应商和商业团体做出对项目产生影响的不利举动
市场上新的替代产品、服务或技术出现使系统变得过时
项目相关方没有提供很好的服务和帮助
项目依赖过多的供应商,缺乏供应商之间的合作,软件包不兼容很难进行集成
类别 | 潜在风险事件 | 风险发生概率的定性等级 | 风险后果影响的定性等级 | 综合风险指数 |
组织风险 | 项目缺乏企业高层的支持和积极参与 | 高 | 灾难性的 | 1 |
项目进程过程中企业经历重组或管理层变动 | 中 | 轻度 | 7 | |
项目所需的业务流程的变化与组织文化不相匹配 | 低 | 严重 | 7 | |
由于企业战略的变化,项目所需资源被转移 | 低 | 严重 | 7 | |
项目没有明确的商业价值,而是出于某些政治上的原因 | 低 | 轻度 | 10 | |
项目计划没有征求所有相关方的同意 | 中 | 轻度 | 9 | |
项目实施对组织结构具有较大影响 | 高 | 灾难性的 | 1 | |
项目实施对业务流程具有较大影响 | 高 | 严重 | 2 | |
需求风险 | 错误的系统需求 | 高 | 灾难性的 | 1 |
系统范围或需求频繁变动 | 极高 | 轻度 | 8 | |
不清晰或误解的需求 | 中 | 轻度 | 8 | |
由于对该应用领域较陌生并且缺乏相关知识,用户和开发人员对系统需求不能很好定义 | 低 | 严重 | 6 | |
用户与开发人员一技术为中心,而忽视了商业需求 | 低 | 轻度 | 9 | |
相关人员对系统需求定义存在冲突 | 高 | 轻度 | 8 | |
用户对系统功能和需求缺乏了解 | 低 | 轻微 | 11 | |
没有定义,项目的成功标准 | 低 | 轻微 | 11 | |
难以界定系统的输入和输出 | 中 | 轻度 | 8 | |
系统需求分析不充分,有遗漏 | 高 | 轻度 | 7 | |
用户风险 | 缺乏用户的合作和责任 | 中 | 轻度 | 8 |
用户提出不切实际的期望 | 低 | 严重 | 6 | |
用户过度依赖咨询顾问,忽略了自身的重要作用 | 中 | 轻微 | 9 | |
用户抵触变化 | 低 | 轻微 | 11 | |
用户对项目持否定态度 | 中 | 严重 | 5 | |
缺乏足够的用户参与 | 高 | 严重 | 3 | |
用户与开发人员之间存在分歧或冲突 | 中 | 轻度 | 8 | |
用户部门之间存在冲突 | 中 | 轻微 | 9 | |
用户没有按排足够用于系统维护阶段的预算 | 高 | 轻度 | 7 | |
技术风险 | 项目采用的是以前未曾实用过的新技术 | 中 | 轻度 | 8 |
缺乏有效的开发方法 | 高 | 灾难性的 | 2 | |
项目需求与已有的其他系统进行较多的集成 | 中 | 轻度 | 7 | |
技术相当复杂 | 中 | 严重 | 5 | |
使用不成熟的技术 | 低 | 轻微 | 11 | |
团队风险 | 项目开发团队成员缺乏责任感 | 中 | 轻度 | 8 |
项目团队成员在性格、态度、观念方面存在冲突 | 中 | 严重 | 5 | |
项目团队成员变动频繁和严重短缺 | 低 | 严重 | 6 | |
团队成员不熟悉自己的任务 | 低 | 严重 | 6 | |
开发人员缺乏项目所需的技能 | 中 | 严重 | 5 | |
开发人员没有经过充分培训 | 低 | 轻度 | 11 | |
计划和控制风险 | 没有清晰地设立项目里程碑 | 中 | 严重 | 5 |
缺乏有效的项目管理方法 | 高 | 灾难性的 | 1 | |
项目计划制订得很糟糕 | 中 | 严重 | 5 | |
项目所需资金和资源估计不足 | 低 | 严重 | 6 | |
项目干系人之间缺乏有效的沟通 | 中 | 轻度 | 8 | |
项目所需时间和进度估计不足 | 中 | 严重 | 5 | |
对项目进展状况监控不够 | 中 | 轻微 | 10 | |
没有实行有效的变化管理 | 低 | 轻度 | 10 | |
对相关方(如开发商和顾问)的角色和责任没有进行明确和合理的规定 | 低 | 轻度 | 11 | |
风险管理很糟糕 | 中 | 轻度 | 8 | |
选择了错误的系统开发方法 | 中 | 严重 | 5 | |
对顾问、开发商及合同方缺乏控制 | 低 | 严重 | 6 | |
市场和竞争风险 | 市场发生变化以至于项目不能获得预期的商业价值 | 高 | 严重 | 4 |
竞争者着手开发类似系统或采取其他难以防范的行动 | 中 | 严重 | 5 | |
合作伙伴、客户、供应商和商业团体做出对项目产生影响的不利举动 | 低 | 轻度 | 11 | |
市场上新的替代产品、服务或技术出现使系统变得过时 | 中 | 严重 | 5 | |
项目相关方没有提供很好的服务和帮助 | 低 | 轻度 | 11 | |
项目依赖过多的供应商,缺乏供应商之间的合作,软件包不兼容很难进行集成 | 中 | 严重 | 5 | |
(1~3为不能接受的风险,4~6为不希望有的风险,7~9为可控制的风险,10~12为可以接受的风险)
一致认同的风险 | 应对策略 |
项目缺乏企业高层的支持和积极参与 | a. 企业高层领导应该花更多时间参加项目的开发和实施工作 b. 项目经理应该建立标准和机制来评价企业高层领导对项目的参与 c. 项目经理应该对企业高层领导参与项目而实施奖励 d. 项目经理应该对鼓励用户对项目提供更加积极的评价,从而促使企业高层领导对项目有更多的责任感 e. 企业高层领导应该作为用户参与到项目中来 f. 企业高层领导应该为项目提供合适的和充足的资源和资金 g. 企业高层领导应该参加项目的审核会议 |
项目实施对业务流程具有较大影响 | h. 项目经理应该鼓励开发人员和用户一起工作,这样开发人员对企业的业务流程就有更好的理解 i. 项目经理应该邀请企业高层领导和用户为开发团队提供业务方面的培训 j. 项目经理应该为用户提供更多的培训,让他们对信息系统,以及系统对业务流程的影响有一个更好的了解 k. 项目经理和企业高层领导应该更加明确实施过程中各方的作用和责任 |
项目实施对组织结构具有较大影响 | l. 企业高层领导应该制定相应的规定和条例来推进企业实施信息系统的工作 m. 项目经理和企业高层领导应该和其他项目干系人经常进行有效的沟通 |
错误的系统需求 | n. 项目经理应该选用其他一些开发方法,如原型法 o. 项目经理应该分阶段交付任务 |
缺乏足够的用户参与 | p. 项目经理和企业高层领导应该考虑把开发人员和用户“栓在一起” q. 项目经理应该和用户建立信任和良好的关系 r. 项目经理应该运用一些非正式控制方法来补充正式控制机制 |
缺乏有效的项目管理方法 | s. 项目经理应该多使用项目管理工具 t. 企业高层领导应该按时检查项目是否按照计划完成 u. 项目经理应该分阶段交付项目 |
缺乏有效的开发方法 | v. 项目经理应该将项目细分以便于管理 w. 项目经理应该选用其他的开发方法,比如原型法 |
对风险监控主要用基于战略的监控方式并确定风险阀值。一旦战略目标和风险变量超过了预定的范围,即超出了风险阀值,就说明该战略目标没有得到很好的执行,需要控制影响各战略目标的风险,并制定相应的风险应对执行方案。风险阀值的计算公式如下:
T(阀值)=N(额定指标值)X W(权重)
风险监控流程如下: