第九章 软件项目风险管理

软件项目中的风险

不断变换的需求
低劣的计划和估算
不可信赖的承包人
欠缺的管理经验
人员问题
技术失败
政策的变化
……

本章内容要点

风险管理概述
风险规划
风险识别
风险评估
风险应对
风险监控
软件项目风险管理案例分析

第一节 风险管理概述

• 风险是遭受损失的一种可能性。

• 这个定义包含两层含义：

第一，风险会造成损失。如产品质量的降低，费用的增加或进度的推迟等。
第二，风险的发生是一种不确定性随机现象，可用概率表示其发生的可能程度。

• 风险发生的概率越高，造成的损失越大，就越是高风险，否则就是中等风险或低风险。

风险的属性

• 一般来说，风险具有以下属性：

风险事件
风险发生的原因
风险发生的概率
风险的影响
风险发生的频率
与其它风险相比较的重要程度
风险防范策略和应对策略
风险责任人

风险分类

常用的风险分类方法包括：
按风险的后果划分：纯粹风险、投机风险；
按风险的来源划分：技术风险、行为风险、经济风险、组织风险；
按风险是否可管理划分：可管理风险、不可管理风险；
按风险影响范围划分：局部风险、总体风险；
按风险的可预测性划分：已知风险、可预测风险、不可预测风险；
按风险后果的承担者划分：项目业主风险、承包方风险、投资方风险、设计单位风险、监理单位风险、担保方风险、政府风险等。

• 人们在大量的软件项目实践中，还总结出了以下最常见的、对项目目标影响最大的软件项目风险类别：

• 1.需求风险：软件项目在初期确定的需求往往都是模糊的、不确定的，而且随着项目的进展，需求还可能不断变化，这些问题如果没有得到及时的解决，就会对项目的成功造成巨大的潜在威胁。常见的与需求相关的风险有：需求不够明确、不准确；缺少有效的需求变更管理措施；用户对产品的需求无限制地膨胀；用户不能经常性地参加需求分析和阶段性评审；用户与项目团队之间没有建立直接、快速的通信渠道。等等。

• 2.过程和标准方面的风险。规范的软件过程和软件工程标准是取得软件项目成功的重要保障。常见的有关过程和标准的风险有：组织没有建立适用于本组织的软件过程规范或标准；没有管理机制保证项目团队按照软件工程标准来工作；流程的重组和标准的改变使开发人员不适应，甚至有抵触情绪；没有采用配置管理来跟踪和控制软件工程中的各种变更，等等。

• 3.组织和人员管理风险。IT行业的人员流动性大，个性较强，难于管理。一旦项目组织和人员发生变动，往往会关系到整个项目的成败。组织和人员管理方面的常见风险有：采用了不符合项目特征的组织结构和管理模式；人员离职或因特殊原因而不能参加项目工作；人员之间的沟通和协调产生障碍；人员之间产生冲突；因绩效评估、奖惩等方面的不当措施而挫伤员工的工作积极性；将项目的一部分外包给其他开发商，但与承包商之间缺乏良好的合作和沟通，等等。

• 4.技术风险。软件项目所涉及的技术往往十分复杂，同时由于软件技术飞速发展，在项目中经常需要适当采用一些新技术，以更好地实现项目的目标。因此软件项目中经常隐含着技术风险，例如：团队对项目中的技术和工具缺少充分理解；缺少应用领域的经验和背景知识；采用了错误的技术和方法；需要对技术进行更新，但对新技术不熟悉；所采用的新技术不够成熟，等等。

风险的基本性质

• 客观性：首先表现在风险的存在是不以人的意志为转移的。不管风险主体是否意识到风险的存在，在一定条件下风险都可能变为现实。其次，风险的客观性还表现在它无时不有、无所不在，它潜在于各种活动之中。

• 不确定性：风险何时何地有可能变为现实是不能确定的。由于人们对客观世界的认识受到各种条件的限制，不可能准确预测风险的发生。

• 不利性：风险一旦发生，就会给风险主体带来挫折、失败和损失，对风险主体不利。

• 可变性：在一定条件下风险可以转化，风险可以转化为非风险，非风险的事件也可转化为风险事件。

• 相对性：对于相同的风险，不同的风险主体的承受能力不同，不同的组织和个人往往对风险有着不同的容忍限度。

• 风险和利益的对称性：风险和利益总是同时存在的，风险是利益的代价，利益是风险的报酬。

风险管理

• 风险管理是指项目管理组织对项目可能遇到的风险进行规划、识别、估计、评价、应对、监控的动态过程，是以科学的管理方法实现最大安全保障的实践活动的总称。

• 风险管理用来处理项目中的各种不确定性。风险管理策略可以分为4个层次：

危机管理：风险已经造成麻烦后才着手处理。
风险缓解：事先制定好风险发生后的补救措施，但不制定任何防范措施。
着力预防：将风险防范作为项目的一部分加以规划和执行。
消灭根源：识别和消灭可能产生风险的根源。

• 应采取主动的风险管理策略，即着力预防和消灭根源的管理策略。这一策略在项目计划阶段就启动了：识别出潜在的风险、评估它们出现的概率和潜在的影响、按照重要性进行排序，然后制定一个计划来管理风险。

• 风险管理应贯穿于项目始终，在项目早期要识别出风险并确定有效的应对措施，在随后的项目执行过程中，还要持续地关注和反复评估风险。

• 软件项目风险管理包括风险规划、风险识别、风险评估、风险应对和风险监控5个活动。

（1）风险规划：对风险管理进行系统规划和顶层设计，制定项目风险管理计划。
（2）风险识别：识别出项目中的风险，并对其进行描述和分类。
（3）风险评估：采用定性或定量的方法对风险发生的概率和产生的影响进行分析和评估。
（4）风险应对：确定应对风险的方案和措施。
（5）风险监控：在整个项目生命周期中跟踪已识别的风险，监测残余风险、识别新风险、实施风险应对方案并对其有效性进行评估。

第二节 风险规划

• 风险规划（Risk Planning）就是制定项目风险管理的一整套计划，主要包括定义项目组及其成员风险管理的行动方案和方式，选择适合的风险管理方法，确定风险判断的依据，指定风险管理的角色和职责，概括风险识别和评估的结果并制定相应的风险应对策略等。

• 风险规划的结果就是正式的“风险管理计划”（Risk Management Plan，RMP）。

风险规划的依据

（1）项目计划中所包含或涉及的有关内容，如项目目标、项目规模、项目利益相关者情况、项目复杂程度、所需资源、项目进度、约束条件及假设前提等。
（2）项目组织及个人的风险管理经验及实践。
（3）决策者、责任方及授权情况。
（4）项目干系人对项目风险的敏感程度及可承受能力。
（5）可获取的数据及管理系统情况：丰富的数据和运行良好的计算机辅助管理系统，将有助于风险识别、评估、定量化及对应策略的制定。

风险管理计划

• 风险管理计划是针对整个项目生命周期而制定的如何组织和进行风险识别、风险评估、风险应对、风险监控的计划。风险管理计划一般应该包括以下内容：

（1）方法：确定风险管理使用的方法、工具和数据资源，这些内容可随项目阶段及风险评估情况做适当的调整。
（2）角色与职责划分：明确项目中进行风险管理活动的角色定位、任务分工和相关责任人。
（3）风险承受程度：即风险承受限度标准。不同的项目团队对于风险所持的态度也不相同，这将影响其对风险认知的准确性，也将影响其应对风险的方式。应当为项目制定适合的风险承受标准，对风险的态度也应当明确地表述出来。
（4）项目风险管理时间与频率：界定项目生命周期中实施风险管理活动的各个阶段，以及风险管理过程的评价、控制和变更的次数或频率等，并把风险管理活动纳入到软件项目进度计划中去。
（5）预算：风险管理活动必然要发生一些成本，占用一些资源，因此应对风险管理进行成本预算。
（6）风险类别：风险类别清单可以保证对项目进行风险识别的系统性和一致性，并能保证识别的效率和质量，还可以为其它的风险管理活动提供一个统一的框架。
（7）基准：明确定义由谁在何时以何种方式采取风险应对行动。
（8）汇报形式：规定风险管理各过程中应汇报和沟通的内容、范围、渠道及方式、格式等。
（9）跟踪和数据记录：确定如何以文档的方式记录项目进行过程中的风险和风险管理活动。
（10）风险概率和影响的定性等级：为了按照统一的标准管理项目中的风险，需要定义风险发生概率与影响程度的定性等级。
（11）项目的主要风险及其特性：识别出的项目的主要风险及其特性描述，包括风险事件、发生概率、影响、原因、应对措施等。这一部分内容也可写在一份单独的“风险规避计划”中。

第三节 风险识别

风险识别的输入包括风险管理计划、项目计划、WBS、历史项目数据、项目约束和假设、公司目标等。

• 风险识别通常至少需要确定风险的三个相互关联的要素：

第一，风险来源，如进度、成本、技术、人员等；
第二，风险事件，即给项目带来消极影响的事件；
第三，风险征兆，即风险事件的外在表现，如苗头和前兆等。

风险识别方法

核对表法
德尔菲方法
头脑风暴法
SWOT分析法
其他方法

核对表法

• 在风险检查表中列出项目中常见的风险的检查条目。

• 项目相关人员通过核对风险检查表，判断哪些风险会出现在项目中。

• 可根据项目经验对风险检查表进行修订和补充。

• 该方法可以使管理者集中识别常见类型的风险。
  

有研究表明：IT项目常常存在一些共同的风险。
如：人员缺乏、不现实的人员和成本估计、晚期需求变化、外购构件缺陷等。
1. 基于关键域的检查表
2. 基于三层结构的检查表
3. 基于生存期的检查表

1.基于关键域的检查表

• 风险检查表中的风险条目属于以下几个关键域：项目规模、商业影响、项目范围、客户特性、过程定义、技术要求、开发环境、人员数目及其经验。其中每一关键域都包含很多风险检查条目。项目管理者将主要精力放在这些关键域方面来关注风险，通过对每个关键域中的风险检查条目的回答，可以识别项目可能存在的风险。

基于关键域的检查表（举例）

• 项目规模风险检查表：

对于估算出的产品规模的信任程度如何？
产品规模与以前产品的规模的平均值的偏差百分比是多少？
产品创建或使用的数据库大小如何？
产品的用户数有多少？
产品的需求改变有多少？交付之前有多少？交付之后有多少？
复用的软件有多少？

2. 基于三层结构的检查表

• 用类（class）、元素（Element）、属性（Attribute）三个层次描述风险列表。

• 每个类下包含若干元素，每个元素下又包含若干属性。

• 通过属性值来识别、评估风险。

三层结构的风险检查表

Product Engineering

• Requirements

Stability
Completeness
Clarity
Validity
Feasibility
Precedent
Scale

• Design

Functionality
Difficulty
Interfaces
Performance
Testability
Hardware Constraints
Non Developmental software

• Code and Unit test

Feasibility
Testing
Coding/Implementation

• Integration and Test

Environment
Product
System

• Engineering Specialties

Maintainability
Reliability
Safety
Security
Human Factors
Specification

Development Environment

• Development process

Formality
Suitability
Process Control
Familiarity
Product control

• Development System

Capacity
Suitability
Usability
Familiarity
Reliability
System Support
Deliverability

• Management Process

Planning
Project Organization
Management Experience
Program Interfaces

• Management Methods

Monitoring
Personnel Management
Quality Assurance
Configuration Management

• Work Environment

Quality Attitude
Cooperation
Communication
Morale

Program Constraints

• Resources

Schedule
Staff
Budget
Facilities

• Contract

Type of Contract
Restriction
Dependence

• Program Interfaces

Customer
Associate Contractors
Subcontractors
Prime Contractor
Corporate Management
Vendors
Politics

3. 基于生存期的检查表

• 初始阶段

项目范围不明确
用户参与少或与用户沟通少，。。。。。

• 设计阶段

项目队伍缺乏经验
漏项，。。。。。。

• 实施阶段

程序员开发能力差
项目范围改变，。。。。

• 收尾阶段

质量差
客户不满意，。。。。。

• 使用检查表法进行风险识别的优点是快速而简单，可以用来对照项目的实际情况，逐项排查，从而帮助识别风险。但由于每个项目都有其特殊性，检查表法很难做到全面周到。

• 在软件项目的收尾过程中，应通过总结项目经验，对风险核对表进行检查和改进。

德尔菲（Delphi）方法

• 德尔菲方法又称专家调查法，本质上是一种匿名反馈的函询法。它起源于20世纪40年代末，最初由美国兰德公司应用于技术预测。

• 把需要做风险识别的软件项目的情况分别匿名征求若干专家的意见，然后把这些意见进行综合、归纳和统计，再匿名反馈给各位专家，再次征求意见，再集中，再反馈，直至各专家的意见趋向一致，作为最后的结论。

• 要使用好该方法需要注意它的三个主要特点：

（1）德尔菲法中征求意见是匿名进行的，这有助于排除若干非技术性的干扰因素。
（2）德尔菲法要反复进行多轮的咨询、反馈，这有助于逐步去伪存真，得到稳定的结果。
（3）工作小组要对每轮的专家咨询结果进行统计、归纳，这样可以综合不同专家的意见，不断求精，最后形成统一的结论。

头脑风暴法

• 头脑风暴（Brain Storm）法简单来说就是团队的全体成员自由地提出自己的主张和想法，它是解决问题时常用的一种方法。

• 头脑风暴法可以充分发挥集体智慧，保证群体决策的创造性，提高决策质量。

• 利用头脑风暴法识别项目风险时，要将项目主要参与人员代表召集到一起，然后他们利用自己对项目不同部分的认识，识别项目可能出现的问题。一个有益的做法是询问不同人员所担心的内容。

头脑风暴法的具体做法

• 参加会议的人员轮流发言，无条件接纳任何意见，不加以评论。

• 由一个记录人员记录提出的每一条意见，并写在白板上，可被所有参会人员看到。

• 在轮流发言过程中，任何一个成员都可以先不发表意见而跳过。

• 这一过程循环进行，直到所有人员都没有新的意见或限定时间到。

头脑风暴法的特点

• 应用头脑风暴法时要遵循的重要原则是：不进行讨论，没有任何判断性评论。对各种意见、观点的评判要放到事后进行，否则会影响会议的自由气氛。要认真对待任何一种意见，而不管其是否正确。

• 头脑风暴法的优点是善于发挥相关专家和分析人员的创造性思维，可对项目风险进行全面的识别。

SWOT分析法

• SWOT是英文的Strength（优势）、Weakness（劣势）、Opportunity（机遇）和Threat（挑战）的简写。

• SWOT分析法的基准点是对企业内部环境之优劣势的分析，在了解企业自身特点的基础之上，判明企业外部的机会和威胁，然后对环境做出准确的判断，做出合理决策。

SWOT分析法的道斯矩阵表

SWOT分析的步骤

• 列出项目的优势和劣势，可能的外部机会与威胁，填入道斯矩阵表的Ⅰ、Ⅱ、Ⅲ、Ⅳ区；

• 将内部优势与外部机会相组合，形成SO策略，制定抓住机会、发挥优势的战略，填入道斯矩阵表的Ⅴ区；

• 将内部劣势与外部机会相组合，形成WO策略，制定利用机会克服弱点的战略，填入道斯矩阵表的Ⅵ区；

• 将内部优势与外部威胁相组合，形成ST策略，制定利用优势减少威胁战略，填入道斯矩阵表Ⅶ区；

• 将内部劣势与外部挑战相组合，形成WT策略，制定弥补缺点、规避威胁的战略，填入道斯矩阵表的Ⅷ区。
  

• 由于SWOT分析法明确了项目的优势和劣势，以及机会和威胁，因此可以多角度地、合理地分析识别项目的风险。

其他风险识别方法

• 文档评审：对软件项目的计划、方案等文档和每个项目阶段的工作过程及其成果进行评审，可识别出项目的许多风险。

• 挣值分析：将计划的工作与已完成的工作进行比较，确定项目是否符合计划的费用和进度要求，如果偏差较大，则需要进一步进行项目的风险识别、评估和量化。

• 环境分析：对项目的环境（包括客户、竞争者、合作者、政府管理者等）进行分析，从而识别出项目风险，并重点考虑它们相互联系的特征和稳定性。

• 情景分析：通过有关数据和图表等，对项目未来的某个状态或某种情况进行详细的描绘和分析，从而识别引起项目风险的关键因素及风险的影响程度。它注重说明某些事件引发风险的条件和因素，并且还要说明当某些因素发生变化时，又会出现什么样的风险，会产生什么样的后果。

• 面谈：与软件项目的团队成员、有经验的项目干系人、有关专家和有类似项目经验的人进行有关风险的面谈，将有助于识别那些在常规方法中未被识别的风险。

第四节 风险评估

• 风险评估就是对风险发生概率的估计和评价，项目风险后果严重程度的估计和评价，项目风险影响范围的分析和评价，以及对于项目风险发生时间的估计和评价。

• 定性评估是确定风险发生的概率和发生后产生的影响程度，并按照风险的潜在危险性大小对其进行优先级排序；定量评估是针对那些对项目有潜在重大影响而排序在前的风险进行量化分析，从而为风险应对和项目管理决策提供依据。

风险概率和影响程度评估

• 风险概率和影响程度评估是根据软件项目风险管理计划中定义的标准，评估项目中每一个风险发生的可能性和它对项目目标（时间、成本、质量等）所造成的影响。

• 在软件项目风险管理计划中应该为风险发生的概率和影响程度制定一个统一的分级标准。

风险概率评估

风险影响程度评估

风险概率和影响程度评估方式

• 可以组织包括软件项目团队成员、项目干系人和项目外部的专业人士等在内的人员，采用召开会议或进行访谈等方式，对风险发生概率和影响程度进行分析。

• 每项风险的发生概率和影响程度值可由每个人定性地估计，然后汇总平均，得到一个有代表性的值。

风险值及风险排序

• 可采用下式为每个风险计算出一个“风险值”。

  风险值 = 风险发生概率×风险影响程度

• 风险值代表了风险的危险程度，可根据风险值的大小对风险进行排序，风险值较大的排在前面。

• 风险排序可为风险应对措施提供指导，排在前面的高风险需要重点关注，并采取积极的应对策略，而排在后面的低风险，只需将之放入待观察风险清单，不需要采取任何积极的管理措施。

决策树分析

• 决策树是一种形象化的图形分析方法，它把项目所有可供选择的方案、方案之间的关系、方案的后果及发生的概率用树状的图形表示出来，为决策者提供选择最佳方案的依据。

决策树的结构

—— 决策节点。从它引出的分支叫方案分支，分支数量与方案数相同。决策节点表明从它引出的方案要进行分析和决策，在分支上要注明方案的名称。
—— 状态节点。从它引出的分支叫状态分支或概率分支，分支数量等于状态数量，在每一分支上注明状态名称及其出现的概率。
△—— 结果节点。将不同方案在各种状态下所取得的结果标注在结果节点的右端。

期望损益值

• 每一个分支都采用期望损益值（Expected Monetary Value, EMV）作为其度量指标。决策者可根据各分支的期望损益值中最大者（如求最小，则为最小者）作为选择的依据。期望损益值等于损益值与事件发生的概率的乘积，即：

    EMV=损益值×发生概率

• 例如：某行动方案成功的概率是50%，收益是10 万，则EMV=10*50%=5万。    

决策树分析示例

• 某软件公司有一款办公软件，现在需要决定是否研发该办公软件的新版本。据分析测算，如果市场需求量大，只销售老版本的软件可获利50万元，开发出新版本软件并销售可获利100万元。如果市场需求量小，只销售老版本软件仍可获利20万元，开发和销售新版本软件将亏损10万元（以上损益值均指一年的情况）。另据市场分析可知，市场需求量大的概率为0.8，需求量小的概率为0.2。试分析和确定是否应该研发该办公软件的新版本。

• 第一步：绘制出决策树。

• 第二步，计算各节点的期望损益值，计算顺序是从右向左进行。

    -节点2：100×0.8+(-10)×0.2=78（万元）
    -节点3：50×0.8+20×0.2=44（万元）
    -决策点1的期望损益值为：max{78, 44}=78（万元）

• 第三步，剪枝。决策点的剪枝从左向右进行，因为决策点的期望损益值为78万元，是“研发新版本”这一方案的期望损益值，因此剪掉“不研发新版本”这一分支，保留“研发新版本”这一分支。因此根据年度获利最多这一评价准则，合理的决策是开发新版本办公软件。

模拟分析法

• 模拟分析法是运用概率论及数理统计的方法来预测和研究各种不确定因素对软件项目的影响，分析系统的预期行为和绩效的一种定量分析方法。大多数模拟都以某种形式的蒙特卡洛分析为基础。

• 蒙特卡洛模拟法是一种最经常使用的模拟分析方法，它是随机地从每个不确定因素中抽取样本，对整个软件项目进行一次计算，重复进行很多次，模拟各式各样的不确定性组合，获得各种组合下的很多个结果。通过统计和处理这些结果数据，找出项目变化的规律。

风险评估结果

第五节 风险应对

• 风险应对就是针对风险分析的结果，制定风险应对策略和处置办法的过程，其目标是应对、减少、以至于消灭风险事件。

• 风险应对的主要策略：

回避风险
转移风险
减小风险
接受风险
风险预留

回避风险

• 回避风险是指当项目风险发生的可能性太大，不利后果也很严重，又无其他策略可用时，主动放弃或改变会导致风险的行动方案。

• 回避风险包括主动预防风险和完全放弃两种。

• 通过分析找出发生风险的根源，通过消除这些根源来避免相应风险的发生，这就是通过主动预防来回避风险。

• 回避风险的另一种策略是完全放弃可能导致风险的方案。是最彻底的风险回避方法，可把风险发生的概率降为零，但也是一种消极的应对手段，在放弃的同时也可能会失去发展的机遇。

• 注意事项：

必须要对风险有充分的认识，对威胁出现的可能性和后果的严重性有足够的把握。
另外，采取回避策略，最好在行动方案尚未实施时，若放弃或改变正在执行的方案，一般都要付出较高的代价。

转移风险

• 转移风险又叫合伙分担风险，其目的是借用合同或协议，在风险事故一旦发生时将损失的全部或一部分转移到项目以外的有能力承受或控制风险的个人或组织。

• 这种策略要遵循两个原则：第一，必须让承担风险者得到相应的回报；第二，对于各具体风险，谁最有能力管理则让谁分担。

• 当项目的资源有限、不能实行减轻和预防策略，或风险发生频率不高、但潜在损失或损害很大时可采用此策略。

转移风险主要有四种方式：出售、外包、开脱责任合同、保险与担保。

• 出售：通过买卖契约将风险转移给其他组织。这种方法在出售项目所有权的同时也就把与之有关的风险转移给了其他组织。

• 外包：向本项目组织之外分包产品的开发，从而把风险转移出去。

• 开脱责任合同：在合同中列入开脱责任条款，要求甲方（客户）在风险事故发生时，不令乙方（项目承担者）承担责任。

• 保险与担保：保险是转移风险最常用的一种方法。项目承担者只要向保险公司交纳一定数额的保险费，当风险事故发生时就能获得保险公司的补偿，从而将风险转移给保险公司。所谓担保，指为他人的债务、违约或失误负间接责任的一种承诺。在项目管理上是指银行、保险公司或其他非银行机构为项目风险负间接责任的一种承诺。

减小风险

• 在风险发生之前采取一些措施降低风险发生的可能性或减少风险可能造成的损失。

• 例如，为了防止人员流失，提高人员待遇，改善工作环境；为防止程序或数据丢失而进行备份等。

• 减轻风险策略的有效性与风险的可预测性密切相关。对于那些发生概率高，后果也可预测的风险，项目管理者可以在很大程度上加以控制，可以动用项目现有资源降低风险的严重性后果和风险发生的概率。而对于那些发生概率和后果很难预测的风险，项目管理者很难控制，对于这类风险，必须进行深入细致的调查研究，降低其不确定性。

接受风险

• 项目团队有意识地选择由自己来承担风险后果。

• 当项目团队认为自己可以承担风险发生后造成的损失，或采取其它风险应对方案的成本超过风险发生后所造成的损失时，可采取接受风险的策略。

• 主动接受：在风险识别、分析阶段已对风险有了充分准备，当风险发生时马上执行应急计划。

• 被动接受：风险发生时再去应对。在风险事件造成的损失数额不大，不对软件项目的整体目标造成较大影响时，项目团队将风险的损失当做软件项目的一种成本来对待。

风险预留

• 风险预留是指事先为项目风险预留一部分后备资源，一旦风险发生，就启动这些资源以应对风险。

• 风险预留一般应用在大型项目中。

• 项目的风险预留主要有风险成本预留、风险进度预留和技术后备措施三种。

风险成本预留

• 预留的风险成本是在项目经费预算中事先准备的一笔资金，用于补偿差错、疏漏及其它不确定性对项目费用估计精确性的影响。

• 风险成本预留在项目预算中要单独列出，不能分散到具体费用项目下，否则项目管理组很容易失去对支出的控制。

• 项目团队在进行风险成本预留时要根据风险评估的结果来进行，不可盲目地在各个具体费用中预留成本。

• 风险成本预留又可分为实施应急费和经济应急费两类。实施应急费用于补偿估价和实施过程中的不确定性，经济应急费用于应付通货膨胀、价格或汇率等的波动。

风险进度预留

• 风险进度预留就是在关键路径上设置一段时差或机动时间。当项目进行过程中出现了一些不利事件引起进度拖延时，项目管理者可以用这些机动时间或者时间差去补偿进度的延迟，从而在总体上保证项目的整体进度。

• 可以通过压缩关键路径上活动的持续时间或者改变活动之间的关系来预留项目的进度，比如赶工法、快速跟进法等。

技术后备措施

• 技术后备措施专门用于应对项目的技术风险，它是预留的一段时间或一笔资金。只有当技术风险发生，并需要采取补救行动时，才动用这段时间或这笔资金。

风险应对示例

• 人员的频繁流动是一项风险，基于过去的历史和管理经验，人员频繁流动可能性的估计值为70%，会造成开发时间增加15%，总成本增加12%。对于这一风险，项目经理采取了以下风险应对策略：

• 与现有人员讨论人员流动的原因。

• 项目启动时，做好会出现人员流动的准备，采取一些技术以确保人员的一旦离开后，项目仍然能继续。

• 建立良好的项目组织和通信渠道，以使大家能够了解每个有关的开发活动的信息。

• 指定文档标准并建立相应的机制，以保证文档能够及时建立。

• 对所有工作组织细致的评审，使大多数人能够按计划进度完成自己的工作。

风险分析表

第六节 风险监控

实施和跟踪风险管理计划
确保风险策略正在合理使用
监视剩余的风险和识别新的风险
收集可用于将来的风险分析信息

风险监控

• 风险监控包括对风险发生的监控和对风险管理的监控。

• 对风险发生的监控是对已识别的风险源进行监督和控制，以便及早发现风险事件的征兆，从而将风险事件消灭在萌芽中或采取紧急应急措施以尽量减小损失；

• 对风险管理的监控是在项目实施中监督人们认真执行风险管理的组织措施和技术措施，以消除风险发生的人为诱因。

风险预警

• 风险预警，是指对于项目管理过程中有可能出现的风险，采用超前或预先防范的管理方式，一旦有发生风险的征兆，就及时发现并发出预警信号，以便采取矫正行动，从而最大限度地控制不利后果的发生。

• 风险监控的一个良好开端和有效措施是建立一个预警系统，及时觉察计划的偏离。

• 例如，计划进度与实际进度之间的区别就是系统会探测到的一个偏差，可作为进度风险的预警。

• 另一个关于进度计划的预警是活动浮动时间（详见第4章）的减少，项目中浮动越少，风险产生影响的可能性就越大，因此活动的浮动时间越少，活动就越应该被关注。

• 预算与实际支出之间的差别是成本风险监控的预警。

• 通过风险预警，可从“救火式”风险监控向“消防式”风险监控发展，从注重风险应对向风险事前控制发展。

风险监控方法

• 常用的风险监控方法包括阶段性评审与过程审查、风险再评估、挣值分析、技术绩效衡量。

阶段性评审与过程审查

• 阶段性评审与过程审查是通过评审活动来评估、确认前一个阶段的工作及其交付物，评价软件过程的有效性，并提出补充修正措施，调整下一阶段工作的内容和方法。

• 阶段评审和过程审查可以让风险的征兆尽早被发现，从而可以尽早地预防和应对。

• 阶段评审和过程审查可以有效地检验工作方法和工作成果，并通过一步步地确认和修正中间过程的结果来保证项目过程的工作质量和最终交付物的质量，从而大幅度地降低了软件项目的风险。

风险再评估

• 风险监控过程通常要使用本章前面介绍的方法对已经评估的风险进行重新评估，检查其优先次序、发生概率、影响范围和程度等是否发生了变化，如果发生了变化，要考虑怎样调整其应对措施。

• 应该安排定期进行项目风险再评估，每次重新评估的内容和详细程度可根据软件项目的具体情况而定。

挣值分析

• 挣值分析不仅可以用于风险识别，也可用于风险监控，因为挣值分析的结果反映了软件项目在当前检查点上的进度和成本等指标与项目计划的差距。

• 如果存在偏差，则可以对原因和影响进行分析，这有助于对进度和成本风险进行监控。

技术绩效衡量

• 该方法将项目执行期间的技术成果与项目计划中预期的技术成果进行比较，如果出现偏差，则可能会导致风险发生。

• 例如在某里程碑处未实现计划规定的功能，有可能意味着项目范围的实现存在着风险。

风险管理案例分析

• 案例描述

          江西某行业业务运营支撑网络管理工程是全国性重点工程，受到该公司领导层的高度重视，委派业务支撑部部门经理为项目总监，张工为项目经理。
           在编制早期计划书时，市场部李工不断提出新的需求，而张工“来者不拒”，不停地更改项目计划。
           在工程的机房设备平面设计中，张工组织人员自行设计，将大部分机架式的小型机集中摆放在一片较小区域内。
           本期工程正式完全割接上线前，旧系统仍然需保持运行。保证系统稳定运行是项目团队的第一要务，在系统割接期间，确保7天×24小时的业务连续平稳运行。

• 问题：该工程中有哪些风险？应采取怎样的应对策略？

• 分析

       频繁的需求变更必然会影响信息工程项目的三大目标（进度、成本、质量）。因此引导客户需求对项目经理来说就非常关键，引导得好，项目的开发就会比较顺利，相反，就会给项目带来很多负面影响。
       在该项目中，项目经理张工对市场部李工不断提出的新需求采取了“来者不拒”的态度，这是不恰当的，因为这会使项目计划不断变动，导致项目范围无法确定，工期和成本不可控制，
       团队成员工作目标也不明确，因此出现了非常严重的需求风险。
       为了应对这一风险，张工应该与李工积极地沟通和谈判，使他明白工程的重要意义，并承诺工程不是交钥匙项目，可为系统升级和扩容留有扩展接口，将来新的需求能够通过后续工程逐步实现，从而使需求趋于稳定。
       在工程的机房设备平面设计中，将大部分机架式的小型机集中摆放在一片较小区域内，从表面上看，提高了机房平面空间的使用率，但是由于未充分考虑到设备散热因素，容易造成该区域
       机器过热而宕机。因此团队的机房设计技术经验不足给项目带来了系统运行不稳定的风险。
       可采取风险转移策略来应对这一风险。张工可聘请具有通信设计资质的专家来负责机房设备平面设计，从机房空调、电源、布线、承重、消防等各个方面进行详细的勘察和设计，从而保证设备运行的可靠性，实现工程设计风险的良性转移。
       在系统割接期间，新旧系统要顺利交接，这给系统业务的7天×24小时连续平稳运行带来了风险，
       因此项目组必须制定详尽可行的系统割接方案、新旧系统并运行方案和故障应急处理方案。

• 《软件缺陷管理和度量系统》项目风险管理

本章小结

1.理解风险和风险管理的概念，了解风险分类。
2.风险规划：了解风险规划的依据，理解风险管理计划的作用，了解其内容。
3.风险识别：理解检查表法、德尔菲方法，了解头脑风暴法、SWOT分析法和其他方法。
4.风险评估：掌握风险概率和影响程度的定性评估方法和决策树分析法，了解模拟分析法。
5.风险应对：理解回避风险、转移风险、减小风险、接受风险、风险预留的指导思想。
6.风险监控：理解风险预警、阶段性评审与过程审查的作用，了解风险再评估、挣值分析、技术绩效衡量在风险监控中的作用。