PM项目管理中的风险来源、识别与控制 | ||||||||||||||||
项目管理中的风险来源、识别与控制 摘要 由于项目的研制需要开发新的技术或使用许多已经过验证的技术和产品但产品生产数目一般较少这些技术和加工工艺不容易达到成熟或定型的程度。且大型项目的研制需要长时间大规模的组织、指挥协调工作以及漫长的研制周期等都会带来种种难以预见的不确定性因素。这些不确定因素的存在使得项目能否按照预定的计划——费用、进度和性能完成研制任务往往难以预料不可能做到研制完全成功存在着失败的风险。所以在项目研制的可行性分析和方案认证时加强方案风险分析是十分必要。 关键词项目风险分析 正文 有效地分配风险与减少风险对于基础设施项目融资的完成和推进建设与经营来说是十分重要的。只有当风险由最适于管理它的一方承担时才会有有效的风险分配。即便一些风险没有照此原则分担项目融资仍可进行但是成本--及最终的资费--就会高一些。项目方和债权人认为要承担更多的风险就会得到更多的回报。 1、风险分析的概念 风险的定义是对目前所采取的行动在未来没有达到预期结果失败的可能性。其大小可用失败的概率和失败的后果两个变量来标识。风险是损失发生的不确定性是对潜在的未来可能发生损害的一种度量如果它确实发生了。则它的发生会对项目产生有害的或者负面的影响。 风险分析有狭义和广义两种狭义的风险分析是指通过定量分析的方法给出完成任务所需的费用、进度、性能三个随机变量的可实现值的概率分布。而广义的风险分析则是一种识别和测算风险开发、选择和管理方案来解决这些风险的有组织的手段。它包括风险识别、风险评估和风险管理三方面的内容。本文中论及风险分析时都采用后一种定义。 风险发生过程 2、风险类型 2.1 风险的分类 1、项目中的风险 项目的风险无非体现在以下四个方面需求、技术、成本和进度。I项目开发中常见的风险有如下几类 1需求风险 ①需求已经成为项目基准但需求还在继续变化 ②需求定义欠佳而进一步的定义会扩展项目范畴 ③添加额外的需求 风险因素 风险事件 损失 实际与预算差异 风险结果 ④产品定义含混的部分比预期需要更多的时间 ⑤在做需求中客户参与不够 ⑥缺少有效的需求变化管理过程。 2计划编制风险 ①计划、资源和产品定义全凭客户或上层领导口头指令并且不完全一致 ②计划是优化的是最佳状态但计划不现实只能算是期望状态 ③计划基于使用特定的小组成员而那个特定的小组成员其实指望不上 ④产品规模代码行数、功能点、与前一产品规模的百分比比估计的要大 ⑤完成目标日期提前但没有相应地调整产品范围或可用资源 ⑥涉足不熟悉的产品领域花费在设计和实现上的时间比预期的要多。 3组织和管理风险 ① 仅由管理层或市场人员进行技术决策导致计划进度缓慢计划时间延长 ② 低效的项目组结构降低生产率 ③ 管理层审查 决策的周期比预期的时间长 ④ 预算削减打乱项目计划 ⑤ 管理层做出了打击项目组织积极性的决定 ⑥ 缺乏必要的规范导致工作失误与重复工作 ⑦ 非技术的第三方的工作预算批准、设备采购批准、法律方面的审查、安全保证等时间比预期的延长。 4人员风险 ① 作为先决条件的任务如培训及其他项目不能按时完成 ② 开发人员和管理层之间关系不佳导致决策缓慢影响全局 ③ 缺乏激励措施士气低下降低了生产能力 ④ 某些人员需要更多的时间适应还不熟悉的软件工具和环境 ⑤ 项目后期加入新的开发人员需进行培训并逐渐与现有成员沟通从而使现有成员的工作效率降低 ⑥ 由于项目组成员之间发生冲突导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作 ⑦ 不适应工作的成员没有调离项目组影响了项目组其他成员的积极性 ⑧ 没有找到项目急需的具有特定技能的人。 5开发环境风险 ① 设施未及时到位 ② 设施虽到位但不配套如没有电话、网线、办公用品等 ③ 设施拥挤、杂乱或者破损 ④ 开发工具未及时到位 ⑤ 开发工具不如期望的那样有效开发人员需要时间创建工作环境或者切换新的工具 ⑥ 新的开发工具的学习期比预期的长内容繁多。 6客户风险 ① 客户对于最后交付的产品不满意要求重新设计和重做 ② 客户的意见未被采纳造成产品最终无法满足用户要求因而必须重 做 ③ 客户对规划、原型和规格的审核 决策周期比预期的要长 ④ 客户没有或不能参与规划、原型和规格阶段的审核导致需求不稳定和产品生产周期的变更 ⑤ 客户答复的时间如回答或澄清与需求相关问题的时间比预期长 ⑥ 客户提供的组件质量欠佳导致额外的测试、设计和集成工作以及额外的客户关系管理工作。 7产品风险 ① 矫正质量低下的不可接受的产品需要比预期更多的测试、设计和实现工作 ② 开发额外的不需要的功能镀金延长了计划进度 ③ 严格要求与现有系统兼容需要进行比预期更多的测试、设计和实现工作 ④ 要求与其他系统或不受本项目组控制的系统相连导致无法预料的设计、实现和测试工作 ⑤在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题 ⑤ 开发一种全新的模块将比预期花费更长的时间 ⑥ 依赖正在开发中的技术将延长计划进度。 8设计和实现风险 ① 设计质量低下导致重复设计 ② 一些必要的功能无法使用现有的代码和库实现开发人员必须使用新 的库或者自行开发新的功能 ③代码和库质量低下导致需要进行额外的测试修正错误或重新制作 ③ 过高估计了增强型工具对计划进度的节省量 ④ 分别开发的模块无法有效集成需要重新设计或制作。 9过程风险 ① 大量的纸面工作导致进程比预期的慢 ② 前期的质量保证行为不真实导致后期的重复工作 ③ 太不正规缺乏对软件开发策略和标准的遵循导致沟通不足质量欠佳甚至需重新开发 ④ 过于正规教条地坚持软件开发策略和标准导致过多耗时于无用的工作 ⑤ 向管理层撰写进程报告占用开发人员的时间比预期的多 ⑥风险管理粗心导致未能发现重大的项目风险。 2.2 风险的基本性质 风险的客观性 风险的不确定性 风险的不利性 风险的可变性 风险的相对性 风险同利益的对称性 3 风险识别 风险识别是指确定哪些可能导致费用超支、进度推迟或性能降低的潜在问题并定性分析其后果。在这一步须作的工作是分析系统的技术薄弱环节及不确定性较大之处得出系统的风险源并将这些风险源组合成一格式文件供以后的分析参考。它属于定性分析的范围。风险评估是指对潜在问题可能导致的风险及其后果实行量化并确定其严重程度。这其中可能牵涉到多种模型的综合应用最后得到系统风险的综合印象。而风险管理则是指在风险识别及风险分析的基础上采取各种措施来减小风险及对风险实施监控。这也可以说是风险分析的最终目的。 风险识别过程 4 风险分析的方法 我们知道对于风险分析所作的工作大多局限于任务风险分析当中。这些方法对于考虑项目风险领域的分析方法也有一定意义风险分析方法可分为定性和定量两种定量的风险分析方法是在定性的基础上而实现的。下面我们对这两类风险分析方法作简要的论述。 输入 标识风险 评审风险 风险表 4.1、定性风险分析方法 定性风险分析的目的是界定风险源并初步判明风险的严重程度以给出系统风险的综合印象表1是一些定性风险分析方法的简介。易于看出初步危险分析是用于识别系统中可能存在的风险源而以下的几种方法则用于定性地量化各种风险源可能对系统造成的破坏从而判明系统风险大小。 4.2、定量风险分析方法 定量风险分析是在定性分析的逻辑基础上给出各个风险源的风险量化指标及其发生概率再通过一定的方法合成得到系统风险的量化值。它是基于定性风险分析基础上的数学处理过程。现发展较为成熟的方法有PRA概率风险评估DPRA动态风险概率评估及仿真通用软件VERT风险评审技术等。 PRA和DPRA都是在FTA分析基础上的量化在可靠性及运行系统风险分析领域内应用广泛。稍作改造我们便可将其运用到项目风险分析领域。其分析步骤如下1识别项目研制过程中的困难环节找出风险源2对各风险源考察其在项目研制中的地位及相互逻辑关系给出项目的风险源树3标识各风险源后果大小及风险概率4对风险源通过逻辑及数学方法进行组合最后得到系统风险的度量。如果是用DPRA进行评估则尚须考虑它们在时间上的关系。 另一种被广泛运用于风险评估的方法是VERT .VERT是国外在八十年代初期发展的一通用仿真软件它对项目研制构造过程网络将各种复杂的逻辑关系抽象为时间、费用、性能的三元组的变化。网络模型面向决策统筹处理时间、费用 、性能等风险关键性参数有效地解决多目标最优化问题具有较大的 实用价值。它的原理是通过丰富的节点逻辑功能控制一定的时间流、费用流和性能流流向相应的活动。每次仿真运行通过蒙特卡洛模拟这些参数 流在网络中按概率随机流向不同的部分经历不同的活动而产生不同的变化最后至某一终止状态。用户多次仿真后通过节点收集到的各参数了解系统情况以辅助决策。如果网络结构合理逻辑关系及数学关系正确且数据准确我们可以较好地模拟实际系统研K时间、费用及性能的分布从而知道系统研制的风险。 定量风险评估可以包括访谈、盈亏平衡分析、模拟、决策树分析、量化风险条目检查 等方法。 4.2.1 决策树分析 决策树分析是一种形象化的图表分析方法它提供项目所有可供选择的行动方案以及行动方案之间的关系、行动方案的后果以及发生的概率为项目经理提供选择最佳方案的依据。决策树分析采用损益期望值EMV作为决策树的一种计算值它是根据风险发生的概率计算出一种期望的损益。 例如 某行动方案成功的概率是50收益是10 EMV1050 4.2.2 方案分析 利用决策树风险分析技术来分析如下两种情况的以便决定你会选择哪种方案 方案随机投掷硬币两次如果两次投掷的结果都是硬币正面朝上你将获得元投掷的结果背面每朝上一次你需要付出.元。 方案随机投掷硬币两次你需要付出元如果两次投掷的结果都是硬币正面朝上你将获得元。 分析结果 很显然应该选择方案1. 4.3风险分析的原则 在风险分析时应该遵循一些分析原则。下面是进行风险分析的几个一般性原则 1风险分析是软件设计的一部分就像应力分析是传统软件设计实践的部分一样 2风险分 析是正式的、严谨的、定量化的 3风险分析的目的是为了支持决策应当把风险分析作为系统软件设计和研制过程的一部分而不应该过迟而无法做出主要的改变和资金的压力强迫在安全性和可靠性上妥协而这种妥协不能接受的情况下作为一种反省进行 4风险分析可以按各种等级的详细程度、彻底程度和精密程度来进行 5风险分析详细、彻底、精确程度与分析项目的重要性和环境潜在的破坏 程度大小相一 6在一个项目的早期概念阶段能够而且应该实施近似的风险分析随着设计的逐渐开展风险分析的精度和详细程度也随之提高。 5项目风险管理模型 针对项目中的风险管理问题不少专家、组织提出了自己的风险管理模型。主要的风险管理模型有Boehm模型CRM模型和SERIM模型。 5.1 Barry Boehm模型 模型REP UOL UO 其中RE表示风险或者风险所造成的影响PUO表示令人不满意的结果所发生的概率LUO表示糟糕的结果会产生的破坏性的程度。Boehm思想的核心是10大风险因素列表。针对每个风险因素都给出了一系列的风险管理策略。在实际操作时Boehm以10大风险列表为依据总结当前项目具体的风险因素评估后进行计划和实施在下一次定期召开的会议上再对这10大风险因素的解决情况进行总结产生新的10大风险因素表依此类推。 5.2 SEI的CRMContinuous Risk Management模型 SEI CRM模型的风险管理原则是不断地评估可能造成恶劣后果的因素决定最迫切需要处理的风险实现控制风险的策略评测并确保风险策略实施的有效性。CRM模型要求在项目生命期的所有阶段都关注风险识别和管理它将风险管理划分为五个步骤风险识别、分析、计划、跟踪、控制。 5.3 SERIMSoftware Engineering Risk Model模型 SERIM从技术和商业两个角度对软件风险管理进行剖析考虑的问题涉及开销、进度、 SERIM从技术和商业两个角度对软件风险管理进行剖析考虑的问题涉及开 销、进度术性能等。它还提供了一些指标和模型来估量和预测风险由于这些数据来源于大量的实际经验 因此具有很强的说服力 结束语 项目管理和其它的项目管理相比有相当的特殊性。首先软件是纯知识产品其开发进度和质量很难估计和度量生产效率也难以预测和保证。其次软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。我们尽量去定义明确不变的需求以便进行计划并高效管理但商业环境总是快速变化的甚至是无序的变化。所以软件企业在进行项目管理的过程中必须采用适合自己的风险 管理方法进行风险管理以确保项目在规定的预算和期限内完成项目。
|