摘要

风险管理是 Microsoft? 解决方案框架(MSF)的核心原则之一。MSF 认为，变化和随之产生的不确定性是 IT 生命周期与生俱来的方面。MSF 风险管理原则提倡使用一种主动的方法来处理这种不确定性，连续地评估风险，并在生命周期中使用它们来影响最终决策。这一原则瞄准成功的、持续的风险管理，通过使用五步过程来描述原则、概念以及指导，这五步分别是：风险识别、风险分析、意外事故和应对策略计划、控制风险状态以及从结果中汲取经验。

本页内容

	介绍
	风险基础
	基本原则
	关键概念
	风险管理计划
	风险管理过程
	识别风险
	风险分析与分级
	风险计划和调度
	风险跟踪和报告
	风险控制
	风险学习
	项目生命周期中的集成风险管理
	企业中的风险管理
	管理项目的公文包
	概要

介绍

和 MSF 过程模型一样，Microsoft 解决方案框架 (MSF) 也定义了一个过程，其目的在于持续地识别和评估项目中的风险，区分风险等级，并执行策略，从而提前处理项目生命周期中的风险。¹

本白皮书介绍了 MSF 风险管理原则的基本概念，描述了其原则、概念、指导以及通向成功 IT 项目风险管理的六步过程。阅读完本文档后，有 MSF 使用经验的项目团队应该能够为 IT 项目实现前摄的风险管理过程，而 IT 项目风险管理方面的新手也应该能够了解其基本概念、术语以及在 IT 项目生命周期中参与 MSF 风险管理所需的原则。

在将软件工程协会(SEI)知名的连续风险管理过程模型应用到项目中 ² 的同时，³ MSF 风险管理原则尝试通过 Microsoft 的扩展产品开发经验，以及源于 Microsoft 顾问服务 (MCS) 及合作伙伴的软件开发和部署经验来解释这一模型。MSF 风险管理原则将以项目为中心的风险管理过程进一步扩展，在知识资产恢复过程中结合企业 IT 策略，并将项目生命周期中的所有阶段紧密集成。

在 MSF 中，风险管理是用来提前识别、分析和定位项目风险，从而在其造成损害或损失前将其消灭的进程。

MSF 风险管理原则具有以下几点定义特性：

返回页首

风险基础

项目管理的基本要素之一是控制项目内在的风险。风险始于围绕着项目决策和结果的不确定性。大多数个人将风险的概念和项目中潜在的价值、控制、功能、质量或完成时间的损失联系在一起。然而，项目结果也同样会导致机会最大化增长的失败，而决策作为结果先导，它的非确定性也应该被包含于风险的要素中。在 MSF 中，项目风险被广泛地定义为：任何可能对项目结果产生积极或消极影响的事件或条件。这个范围更宽的投机风险 概念被利用于金融业，投机风险中的不确定性决议可能和潜在收益以及损失相关联，这和纯粹风险 的概念恰恰相反，纯粹风险被利用于保险业，它的不确定性仅仅和潜在的损失相关联。⁴

风险和故障有所不同，因为风险指的是未来的消结果或损失的潜在可能。然而，故障则是当前已经存在于项目中的条件或状态。如果没有被有效地定位，风险可能会转化为故障。在 MSF 中，风险管理是提前识别、分析和定位项目风险的过程。风险管理的目标是让项目风险带来的积极影响（机会）最大化，同时让消极影响（损失）最小化。对于风险的有效策略的理解和管理能一定程度上保证风险和机会间的有效平衡。

信息技术 (IT) 项目拥有创造有效风险管理基础的特征。竞争的商业压力、调整变化以及技术标准发展有时会促使 IT 项目团队在项目中期改变计划和方向。变化的用户需求、新兴的工具和技术、进化的安全威胁以及职工岗位变化都会导致额外的压力。Jim McCarthy 提供的文章说明了这个问题：

“事实上，即使在最成功的软件项目的每一个阶段，都有大量的有用要素是未知的。”（Dynamics of Software Development，1995年，99页）。⁵

返回页首

基本原则

MSF 风险管理原则基于风险必须被提前解决这一理念；它是正式和系统过程的一部分，将风险管理作为积极的工作。此原则构建于作为 MSF 核心的基本原则、概念和做法的基础上。有效的项目风险管理是 MSF 基本原则的关键所在。⁶ 不过，以下原则对 MSF 风险管理原则也是尤为重要的。

保持灵活 — 预测变化

变化是项目团队面临的主要不确定性之一。风险管理工作不应该被限制在项目生命周期的单一阶段。项目团队经常在项目的开始就投入很大的精力来应用风险管理原则，可是随着项目完成所要求的紧密的进度表压力，项目团队也许做不到持续地努力。活跃这个原则，要求项目团队在整个项目生命周期的每个阶段都持续地评估并提前管理风险，原因是项目各方面的连续性变化也意味着风险的持续性变化。前摄方法让项目团队可以接受变化，并防止其向分裂性的，消极的影响发展。

鼓励公开交流

MSF 针对讨论风险提出了一个公开方法，既在团队内使用，又在团队外部使用。所有的团队成员都应该参与风险识别和分析。团队领导和管理人员应该支持和鼓励非过失文化的发展，从而发扬这一行为。对于项目风险公开、诚实的讨论可以带来更多对项目状态的正确评价，而执行管理人员和投资人更富有远见的决策会使整个团队受益。

学习经验

MSF 认为，在学习中保持对持续改进的关注将带来更大的成功。从某一个项目中获得的知识可以减少围绕着决策的不确定性。MSF 强调通过利用项目和风险管理过程一体化来实现组织或企业级项目结果学习的重要性。在鼓励所有团队成员公开通讯的过程中，对从项目结果中获得经验的直接关注也鼓励团队级的学习（互相学习）。

共同的责任，清楚的义务

在 MSF 中，没有人可以“独享”风险管理。项目团队中的每一个成员都有责任积极地参与风险管理进程。在项目进度表及计划中，团队成员个人都被赋予了明确的项目风险定位的责任。积极性可能贯穿于项目及风险管理过程周期的每一个阶段。它包含了个人专家意见或责任范围内的风险识别，并进一步扩展到包含风险分析、风险计划以及在项目推进过程中执行风险控制任务。在 MSF 组队模型中，项目管理角色群的项目管理功能领域对在风险管理工作中组织项目团队负有最终责任，并确保风险管理工作融入该项目的标准项目管理过程。⁷

返回页首

关键概念

在本章节，我们讨论风险和风险管理的重要概念，这是理解 MSF 风险管理原则的核心内容。

风险天然存在于所有项目或过程中

尽管因项目的不同，风险的多少也各异，但没有一个项目是不包含风险的。项目发起后，组织可以在支持组织目标的过程中实现价值目标。在项目及其环境的周围，往往围绕着很多不确定性因素，而它们将影响到目标的实现。MSF 实施者通过始终紧记风险无处不在的规律，寻求持续在风险和机会中做出正确平衡决议的方法，而不会过于关注如何将风险小消化。

主动的风险管理是最有效的

通过关注以下要素，MSF 采用一种主动的方法来识别、分析和定位风险：

有效的管理绝对不只是通过单纯地处理故障来实现的。项目团队应该致力于提前识别风险，并发展策略和计划来管理这些风险。计划应该包含如何在故障发生时解决它们。预见潜在的故障、提前做出有效的计划可以缩短危机出现后的反应时间，并限制甚至扭转故障发生时带来的危害。

前摄风险管理的定义特性是风险缓解和风险影响缓解。缓解工作可能发生在特定风险目标级别，并瞄准其潜在的直接原因，也可能通过改变根本原因级别（或是改变因果链）来实现。缓解方法在初期是最好的措施，因为这时项目团队还可以及时改变项目结果。

根本原因的识别和修正对企业有着很高的价值，因为修正方法可以带来比个体项目范围更深远的积极影响。例如，在开发或部署项目的过程中，编码标准或机器命名惯例的缺乏可能明显地导致不利的结果，并因此成为增加项目风险的源头。不过，创建标准和指导方针能在企业里对整个项目起到积极的影响，前提是这些标准和指导方针在整个企业里执行。

积极地看待风险识别

有效的风险管理和项目团队对正面临着的风险的正确和全面的理解密不可分。当挑战和潜在损失的数量变得明显时，开发团队可能会对风险管理工作失去信心。一些团队成员甚至会认为识别风险事实上就是寻找破坏项目成功的原因。MSF 则刚刚相反，它认为正是风险识别过程让项目团队可以通过公开化，更高效地管理风险，从而让成功的前景更加明朗。公开、归档的风险探讨将团队成员完全解放出来，通过提供任务、责任和预防工作计划的直接改良，让他们能够更加专注于工作，并纠正错误的方法。

项目团队（尤其是团队领导）应该积极地看待风险识别，从而保证提供关于眼前风险尽可能多的信息。对风险消极的理解可能让团队成员不愿意做风险沟通。项目团队应该营造这样一个环境：员工在识别风险的过程中不需要害怕，只需要诚实地表达尝试性或是有争议的观点。消极的风险环境的例子比比皆是。例如，在某些环境下，报告新的风险被视为捣乱，而反击风险则定位到人而不是风险本身。在这样的环境下，人们通常谨慎地进行风险沟通，然后开始选择性地表达他们准备分享的风险信息，从而避免和团队成员的对质。如果项目团队积极地对待提出风险的团队成员，那么就能创造一个积极的风险管理环境，这样便能更成功地识别和定位风险，而在消极风险环境下工作的团队则刚刚相反。

为了实现项目收益最大化的目标，项目团队必须乐于接受风险。这要求项目团队将风险和不确定性视为创造正面机会的途径，从而通向成功。

持续评估

很多信息技术专家错误地将风险管理理解为必要但却令人厌烦的任务，他们认为风险管理应该发生在项目的开始或是引入新过程的时候。

项目和操作环境中的持续变化要求项目团队有规律地对已知风险的情况进行重新评估，从而修正计划以防止这些风险带来的故障，或者对这些故障做出响应。项目团队同样应该坚持不懈地寻找新的项目风险。应该将风险管理工作集成到整体项目生命周期中，从而适当地修正风险控制计划和工作，而不需要创建一个单独的报告和跟踪基础设施。

保持公开交流

尽管风险通常为一些团队成员所知，但这些信息常常缺乏充分的交流。虽然组织层次中由上至下的信息交流通常十分简单，但是由下至上的信息传递却是相当困难的。无论人们处在哪个层次，都希望了解更低层次的风险，却害怕向上传递信息。有限的风险信息流对项目风险都会是有力的促进，因为它能用甚至更少的信息促进决策。在分级的组织中，管理人员需要鼓励公开交流，并确保每个人都正确地理解风险和风险计划。

先说明，后管理

风险管理面向不确定性影响决策制定工作。标准的风险声明适当地列出了一些不确定性，并鼓励风险的不同解释。清楚的声明可以在以下方面帮助项目团队获益：

MSF 提倡在风险管理计划中注意细节信息，从而最小化风险计划中的执行错误，这些错误可能导致预防工作失效，也可能干扰恢复及纠正工作。

不要简单地根据风险的数量判断情况

尽管团队成员和主要投资人总能认识到风险项目是消极的，但避免简单地根据风险的数量判断项目或操作过程也是尤为重要的。毕竟，风险只是可能发生的事物，而并不是实际的损失或不理想的结果。MSF 风险管理过程提倡使用结构化的风险识别和分析过程来为决策者提供现存的风险信息，以及这些风险的重要性。

返回页首

风险管理计划

在 MSF 过程模型的预想和计划阶段，项目团队应该对如何实现风险管理过程进行开发并归档。在计划中应该回答的问题包括：

风险管理工作不应该被孤立于标准项目计划和调度工作之外，风险管理任务应该被视为 团队成员完成项目的补充。因为风险由始至终普遍存在于所有项目的所有阶段，所以应该分配和调度资源，以积极地管理风险。在 MSF 过程模型的预想和计划阶段产生风险管理计划。⁸ 而在工作分级结构中，记录这些计划的计划书应该记录分配给特定团队成员的定义工作项目。这些工作项目应该出现在项目计划和主项目进度表中。

返回页首

风险管理过程

MSF 风险管理过程概述

MSF 风险管理原则提倡前摄的风险管理、持续的风险评估以及项目或操作生命周期的决策集成。风险应该被持续地评估、监控和积极地管理，直到被解决或是转化为可以处理的故障为止。图1中描述的MSF 风险管理原则定义了项目团队管理现有风险、计划、执行风险管理策略以及为企业获取知识过程中的六个逻辑阶段。

图1：MSF 风险管理过程

MSF 风险管理过程的六个阶段是：

风险识别让个体可以发现风险，进而使项目团队意识到潜在的故障。作为风险管理过程的输入，风险识别应该尽可能早的执行，并在项目的生命周期中频繁地重复。

风险分析将风险识别过程中发现的特定项目风险估计量或数据转化为一种可被项目团队用来确定优先决策的形式。风险排序让项目团队可以负责项目资源从而对最重要的风险进行管理。

风险计划提取风险分析中获得的信息并用其明确表达策略、计划和工作。风险调度可以确保计划被认可并融入标准的日常项目管理进程和基础设施中，从而确保风险管理作为团队日常工作的一部分执行。风险调度明确地利用项目计划与风险计划关联。

风险跟踪监控特定风险的状况以及它们各自工作计划中的进展情况。风险跟踪也包含监控变化风险的概率、影响、暴露程度以及其他因素，这些变化可能改变优先级或风险计划、项目特性、资源或是进度表。风险跟踪从风险等级的角度定义风险管理过程在项目中的可见度，这与标准业务项目管理过程任务完备化的角度恰恰相反。 风险报告确保团队、发起人和投资人明白项目风险的状态并管理它们的计划。

风险控制是执行风险工作计划和相关现状报告的过程。风险控制也包含项目变化控制请求的初始化，而风险状况或风险计划的更改可能导致项目特性、资源或进度表的更改。

风险学习使知识和相应项目案例及工具正式化，并在团队和企业内部以可再度使用的形式提取知识。

注意，这些阶段属于逻辑阶段，对于任何给定的风险，您都并不需要严格地遵循这些阶段。项目团队将经常在识别-分析-计划三步中循环往返，而仅仅周期性地进入学习这一阶段来为企业捕获知识。

从这个图表中得出的“所有项目风险都会固定地经过这些阶段”的结论是错误的。相反地，MSF 风险管理原则鼓励每个项目在 MSF 过程模型的项目计划阶段定义风险管理过程将于何时，以何种方式发起，以及各阶段间的转化将在怎么样的环境下发生。

返回页首

识别风险

介绍

风险识别是 MSF 风险管理过程的最初阶段。项目团队必须准确地识别并明白地定义风险，从而达到统一并继续进行分析和计划。在风险识别阶段期间，应该有意识地扩展团队焦点。应该将注意力放在学习活动上，并寻找项目知识和环境间的缺口，这些会给项目带来反面影响或限制它的成功。图2以图形化的方式地描述了风险识别阶段的输入、输出以及行动。

图2：风险识别

目标

风险识别阶段的目标是为项目团队创建一个他们面临的风险清单。这个清单应该是全面的，覆盖项目的所有方面。

输入

风险识别阶段的输入包含一般可用的知识以及相应商业、技术、组织和环境领域中的特定项目风险。其他的考虑事项还包括团队的经验、当前的风险组织方法（以策略、指导、模板等形式存在）以及在那时已知的项目信息，包括历史和当前状态。项目团队可能选择利用其他输入（项目团队考虑的任何与风险识别相关的要素都应该被考虑）。在项目的开始，利用团队自由讨论、推动会议甚至是正式会议来收集项目团队信息及项目投资人对风险和机会的理解是尤为重要的。行业分级方案（例如 SEI Software 的风险分类法）、⁹ 项目检查表、¹⁰ 早前项目综合报告和其他发布的行业资源及指导都能帮助项目团队更好地识别相关项目风险。

风险识别工作

在风险识别的过程中，项目团队创建明确的声明或风险清单，清晰地说明他们面临的风险。在项目的开始阶段，组织正式或自由讨论来识别新状况相关的风险是相当容易的。不幸的是，很多组织将此看作一次性的工作，在项目或操作的生命周期中再也不对其进行重复。MSF 风险管理原则强调，应该在整个项目实施过程中周期性地进行风险识别。风险识别可能是进度表驱动（例如每日、每周、每月）、重要事件驱动（和项目计划中既定的重要事件相联系）或是事件触发（受商业、技术、组织或环境设置中的重大影响事件驱动）的。应该依据每个项目团队确定的间隔和范围不时地进行风险识别工作。例如，一个团队在大型开发项目中可能会在关键的重要事件阶段完成一次整体风险识别会议，而在过渡时期的重要事件阶段则会另外选择个体特色团队甚至是个体程序员来重复识别工作。

在项目的风险识别阶段，团队成员和投资人之间的交流十分重要，因为这是提出设想和分歧观点的有效手段。基于这个原因，MSF 风险管理原则提倡在风险识别过程中尽可能广泛的兴趣、技能和背景。

风险识别也包含团队发起的研究和主题专家，从而在项目领域范围内学到更多风险相关的知识。

结构化的方法

MSF 提倡尽可能地使用结构化的风险管理方法。对于软件开发和部署项目，在风险识别阶段进行风险分级是提供一致、可再生、可测量方法的正确途径。风险识别提供标准风险术语的基本原则，这在报告和跟踪中是必需的，对创建和维护企业或行业风险知识库也是至关重要的。在风险识别阶段，风险分级清单通过提供现成的，来自早前类似项目或行业经验的风险观点，使项目团队对于项目的思维更加全面。风险声明表述是 MSF 中用于评估特定项目的主要技术，也可以用来指导特定风险计划的排序和展开。

风险分级

风险分级，或风险分类，有时也被称为风险分类法，为项目团队的多个目标服务。在风险识别期间，它们可以用来刺激项目中不同领域的风险思维。在自由讨论期间，风险分级也能通过提供方便的同类风险分组方法，大量减少风险工作的复杂性。风险分级还能为项目团队提供公共术语，用来在项目中监控和报告风险状况。最后，风险分级对建立行业和企业风险知识库也是至关重要的，因为它们提供索引新条目和搜索以及检索现有工作的基本原则。下面的表格描述了项目风险中的高级资源分级。

对于常规软件开发项目中的风险，有很多种分类或分级方法。著名的也是常用的软件开发项目风险分级方法包含 Barry Boehm，¹¹ Caper Jones，¹² 以及 SEI Software 风险分类法。¹³

从更多细节覆盖有限项目领域的风险领域同样是可用的。进度表风险是项目团队的通常领域，通过进度表周围的风险识别来协助软件开发项目团队的全面、详细的清单已经由 Steve McConnell 编译出来。¹⁴

不同类型的项目（基础设置或内置的应用程序部署）、在特定技术领域执行的项目（例如安全、嵌入式系统、安全边界、EDI）、垂直行业（医疗、制造业等等）或是特定产品项目可能会将知名的项目风险带入这个领域。在信息安全领域中，风险涉及到信息盗窃、丢失或腐败，而有准备的行为或事故往往指的是威胁。¹⁵,¹⁶ 这些领域的项目将收益于对可选风险（威胁）的分级或对知名的通用风险分级的扩展，在风险识别阶段保证项目团队思维的深度。

其他项目风险信息的资源包括项目风险数据库，例如软件工程信息仓库（SEIR）¹⁷ 或是企业内部的风险知识库。

风险声明

风险声明是一种自然语言表达，它表述了真实、实际存在的项目事件或属性状态和潜在、没有实现的项目事件或属性间的因果关系。风险声明的第一部分被称为条件，它提供了现有项目属性或事件状态的描述，项目团队认为这可能有原因地导致项目损失或收益缩减。而风险声明的第二部分则是另一种自然语言声明，称为结果 。结果阐述了不期望出现的项目属性或事件状态。这两种声明被“因此”或是“结果”这样的连词关联起来，暗示着不确定的（换句话说，不是100%的）但又存在因果关系的关系。图 3 用图表的方法对其进行了描述。

图 3：风险声明

风险声明中的两部数字化过程能够更好地在风险识别阶段的前期联结风险结果和可见的（以及可潜在管理的）风险条件 。在风险识别阶段仅仅关注风险条件需要团队备份风险条件，从而保证风险管理进程的后期阶段，当他们开发管理策略的时候能够再次使用。

注意，风险声明并不是“如果-那么”格式的声明，而是搜索可能却没有实现的结果的事实声明。在分析和计划阶段，使用假定的“如果-那么”声明可能对权衡方案和使用决策树明确地叙述计划有所帮助。然而，在风险识别阶段，目标是识别尽可能多的风险，因此应该将“如果-那么”推迟到计划阶段。在项目初期应该有丰富的风险声明，描述团队缺乏的知识，例如“我们目前还不明白某事，因此……”。

在明确叙述风险声明的时候，项目团队应该既考虑到潜在的原因和没有实现的不期望的结果，又考虑到结果的本身。风险声明包含了项目中的现有事件（条件）状态，也包含了可能发生的事件（结果）状态。作为彻底的风险分析的一部分，团队成员应该寻找项目风险声明中条件的相似性和自然分类，并通过每个条件的因果链寻找共同的潜在原因。¹⁸根据风险声明中“条件-结果”组合的因果链，检查组织和项目外部环境的影响，从而获取与特定项目条件相关联的整体损失或机会损失的更大增值，也是相当重要的。¹⁹

在风险识别期间，很少有团队为同一条件识别多个结果。有时，在项目的某一领域定义的风险结果可能会成为另一个结果的风险条件。项目团队应该记录这些条件，从而在风险分析和计划过程中做出适当的决策。取决于风险之间的关系，结束一个风险可能会结束一组相互依赖的风险，并改变项目中的整体风险状况。在风险识别阶段的前期记录这些关系，能提供大量有用的信息，用于指导风险计划，这些风险计划是灵活的、全面的，并能通过定位根本或前导原因来高效利用可用项目资源。在识别阶段捕获这样的附加信息的益处，应该与后来的分析和分级过程中的快速移动，以及计划阶段中对依存关系和根本原因的再审查相平衡。

输出

风险识别工作中的最小化输出是一份清晰、明确、得到一致肯定的风险声明，作为 风险清单记录下来。如果风险条件-结果方法像SEI ²⁰、NASA²¹以及较早版本的 MSF²²中描述的那样使用²³，那么输出的将是一个风险声明的集合，用来明确地描述项目中被识别的风险。而这个表格形式的清单将成为风险管理过程下一个阶段，也就是分析阶段的主要输入。在风险识别阶段常常还生成其他的大量有用信息，包括根本原因和影响的识别、受影响的团体以及所有者等等。

MSF 风险管理原则建议项目团队创建表格式的风险声明记录、根本原因以及影响信息。在定义良好的分类法存在的情况下，在使用项目风险信息来构建或利用企业风险知识库时，用于对风险分级的额外信息可能也是相当有用的。其他有用信息可能记录在风险清单中，以定义风险的上下文 ，从而帮助其他团队成员、外部评论家或投资人更好的理解团队意图^24，25，26。在风险识别阶段，项目团队可能选择记录的风险上下文信息包含以下几点：

表格式的风险清单（包含或不包含条件、根本原因、影响或上下文信息）将成为后面的风险管理过程阶段的主导风险清单。下面的示例表格描述了主导风险列表的形式。

返回页首

风险分析与分级

介绍

风险分析与分级是 MSF 风险管理过程的第二个阶段。风险分析包括将风险数据转换为能更好地帮助决策的形式。风险分级则确保团队成员能够定位首要的项目风险。

在此阶段，项目团队检查风险识别阶段提供的风险项目清单，并根据行为对它们进行分级，记录主导风险清单中的次序。

通过主导风险清单，项目团队可以列出“最大风险”，这对特定策略的计划与执行工作很有帮助。项目团队还可以识别哪些风险具有很低的优先级，可以从清单中去除。当项目接近完成和项目环境发生变化的时候，应该重复风险识别和风险分析的过程并将改变记入主导风险清单。新的风险可能出现，而老的风险可能不再拥有很高的优先级，它们可能从清单里去除或“无效”。图4描述了这个阶段的输入和输出。.

图 4：风险分析与分级

目标

风险分析阶段的主要目标是对风险清单中的项目进行分级，并确定哪些风险保证资源的承诺。

输入

在风险分析阶段，项目团队将利用它们自身的经验以及从其他相关资源中提取的信息，这些信息与风险识别期间产生的声明相关。将未处理的风险声明转化为分级的主导风险列表需要一些相关信息，这些信息的来源可能是组织的风险策略和指导方针、行业风险数据库、模拟试验、分析模型、商业单位经理以及其他领域的专家。

风险分析工作

有很多定性和定量的技术能帮助项目团队完成风险清单的分级。其中一种易用的风险分析技术是：对两种普遍承认的风险、概率或影响组件进行集体表决。将表决的结果相加就能计算出一个专门的度量值，被称为风险暴光量。

风险概率

风险概率指的是我们在风险声明中的风险结果部分提到的事态实际发生的可能性。 使用风险概率的数值对风险分级有着十分重要的意义。风险概率必须大于 0，否则风险就不可能造成威胁。以此类推，风险概率也必须小于 100%，否则风险就是确定的事情了—换句话说，它就是一个已知的故障了。尽管行业或企业风险数据库基于大量项目的实例，可能对提供已知概率估计值有用，但对于个体来说，估算和应用概率是相当困难的。不过，大部分项目团队可以描述他们以往的经验，产生行业报告，并提供自然语言术语来映射数字概率范围。这可能和将“低-中-高”映射为不连续的概率数值（17%，50%，84%）一样简单，也可能和映射不同的自然语言术语一样复杂，例如“不一定高”、“不可能”、“很可能”、“几乎肯定”等，这些术语描述了概率中的不确定性。下面的示范表格列出了一个三段概率分级的例子。紧随其后的示范表格则列出了一个七段概率分级的例子。

注意，用来计算的概率值等于概率范围的中间值。有了这些映射表格的帮助，项目团队可以通过将概率范围或自然语言表达映射为数字分数，从而将概率定量。在使用数字分数描述风险的时候，对于所有风险使用同样的数字分数标准是非常必要的。

无论项目团队使用何种技术来对不确定性定量，都需要开发一种方法来为风险概率获得单一值，表述每个风险的大众观点。

风险影响

风险影响是对负面影响严重性、损失量或是项目中风险的潜在机会成本的估量。它应该是对风险声明中定义的风险结果的直接度量。它可以通过财政术语测量，也可以通过主观量度测量。如果所有的任务影响都可以通过财政术语表达，那么项目团队就可以使用财政值来量化损失数量或机会成本，这样做的好处是商业发起人对此非常熟悉。财政影响可能是操作和支持过程中的长期成本、市场份额的损失、额外工作的短期成本或是机会成本。

在其他情况下，像 1 至 5 或 1 至 10 这样的主观范围则更适合测量风险影响。在主导风险清单中的所有风险使用相同的单位进行测量的时候，简单的分级技术都可以胜任。创建转换表格与特定单位（如金钱或时间）相关联，并形成数值是非常有用的，这些值可以和分析过程中的其他主观单位相比较，如下表所示。这种方法提供一种高可适应性的度量，用于比较企业层面多个项目间的不同风险。这种特别的映射是一种对数变换，得分基本和 log₁₀($loss)-1相同。“高”值代表严重的损失；“中”值表示部分损失或效率减少；而“低”值则标志着较小的或微不足道的损失。

当金钱损失无法简单计算时，项目团队可以选择开发一种备选的影响评分机制，获得适当的项目领域。Hall (1998)提供了一个示例，²⁷如下表所示。

用于估算影响的评分系统应该体现出团队和组织的价值观和策略。$10,000 的金钱损失对于某些团队或组织是可以容忍的，但对于另一个组织就不一定了。使用被人工分配高值的灾难影响将保证即使是低概率的风险也会上升到风险清单的顶端并逗留。

风险暴光量

风险暴光量测量风险的全面威胁，将表示实际损失可能性的信息和表示潜在损失数量的信息组合为一个单独的数字估计值。接下来，项目团队可以根据风险暴光量的大小来对风险分级。通过对风险概率和影响的叠加，风险暴光量以最简单的定量风险分析形式进行计算。

当分数被用于概率和影响定量的时候，往往很方便创建矩阵，这个矩阵考虑可能的分数组合，并将它们和低风险、中等风险和高风险范畴对应起来。对于使用三级概率评分（1 代表低，3 代表高），可能的结果以表格的形式表达出来，每个单元代表风险暴光量的一个可能值。在这样的安排中，将风险分级为低、中还是高取决于它们对角线的位置。

低暴光量 = 1 或 2 中等暴光量 = 3 或 4 高暴光量 = 6 或 9

表格形式的优势在于它让风险等级可以包含于发起人或投资人的状况报告中，使用颜色（红色代表右上角的高风险区域，绿色代表左下角的低风险区域，而黄色则代表沿着对角线的中等风险区域）和易于理解、定义明确的术语（高风险比高“暴光量”好理解得多）。

其他定量技术

因为风险分析的目标是对风险清单上的风险进行分级，并针对风险控制来驱动决策，所以应该注意：每个项目团队都应该选择适合自己项目、团队、投资人以及风险管理基础设施（工具和过程）的分级方法。一些项目从有利的多属性技术中获益，团队希望在分级过程中考虑所需时间线、潜在机会收益的数量或是概率估量的可靠性。下面提供了一个有利的分级矩阵的示例表格，它不仅考虑概率和影响，还考虑实现高效控制所需的时间窗口和成本，分级数值通过以下公式计算：

分级数值 = 0.5（概率 x 影响）– 0.2（需求时间）+ 0.3（控制成本 x 有效的概率控制）。

这种方法让项目团队可以考虑风险暴光量、进度表危险程度（风险控制或缓解计划必须何时完成），并将计划的成本和功效并入决策过程。这个常规的方法让项目团队可以按照设置的项目贡献对风险分级，并提供从损失（影响）的角度和机会（正面收益）的角度评估风险的基础 。

选择正确的风险分析方法或方法组合依赖于在风险分析的花费或是错误分级选择（对于投资人来说）间作出正确的决策。应该保证风险分析，从而支持驱动决策的分级，而且不应该为分析而分析。定量或半定量风险分级方法的结果应该在商业目标、机会以及声音管理做法的上下文中进行评估，而不应该被认为是自身的决策自动化形式。

输出

风险分析为项目团队提供一个风险分级清单，引导团队进行风险计划工作。在 MSF 风险管理原则中，它被称为主导风险清单。详细的风险信息，包括项目条件、上下文、根本原因以及分级（概率、影响、暴光量）中使用的度量，常常以风险声明的形式对每个风险进行记录。

主导风险清单

MSF 风险管理原则将风险清单定义为主导风险清单。主导风险清单以表格形式存在，识别引发风险的项目条件、潜在的负面影响（结果）以及用于分级的凭据或信息，例如概率、影响和暴光量。当主导风险清单由分级标准等级（高到低）分类时，就可以在计划过程中提供分级的基础。下面的示范表格是一个主导风险清单，它使用两个要素（概率和影响）。

低影响 = 1，中等影响 = 2，高影响 = 3

暴光量 = 概率 x 影响

主导风险清单在个体项目清单细节的层次编辑所有风险评估信息。它是一个活动的文档，记录正在进行的风险管理过程的基本要素，在整个项目分析、计划和监控的周期都应该保持更新。

主导风险清单是支持积极的或前摄的风险管理的基本文档。它通过为下面的工作提供基本要素来实现团队决策：

下面的表格包含了主导风险清单中维护的项目清单。应该细致地将用于计算风险带来的暴光量的方法归档到风险管理计划中，并保证计算过程能够正确地提取团队权衡利弊过程中的意图。

其他分析方法

某些团队可能会选择其他的分析级别来阐明他们对项目风险的理解。其他可以被项目团队用来阐明项目风险的技术将在标准项目管理和风险管理教科书中讨论^28,29。决策树分析、因果关系分析、帕列托分析、模拟仿真以及灵敏度分析这样的技术被用来向风险管理提供更丰富的定量理解。使用这些工具的决策应该基于价值，引入驱动分级和计划阶段说明来抵消资源成本。

风险声明表格

在分析每个个体项目风险时，或是对某一特定风险相关的活动进行风险计划时 ，从文档查看风险信息是十分方便的，这个文档被称为风险声明表格。

风险声明表格包含了识别和评估阶段中主导风险清单里的字段，可能还加入了团队在风险管理过程中所需的额外信息。当接下来的行为通过单独团队或是特定个体分配给风险时，将其作为主导风险清单里的单独文档看待有时是非常简单的。

团队在开发风险声明表格时应该考虑的信息如下表所示：

最大风险列表

风险分析为每个单独的风险衡量威胁，从而帮助项目团队确定哪个风险更有价值，而管理风险是会减损其他工作的时间和经历的。因此对于项目团队来说，选择绝对重要的风险并管理它们就尤为重要。

一种简单而高效的风险监控技术是使用最大风险列表来列出最关键的风险项目。最大风险列表对所有的投资人都是可见的，也可以被包含在重要报告文档中，例如计划/范围文档、项目计划和项目现状报告。

代表性地，项目团队将确定有限的、必须被管理的关键风险（在大多数项目中，个数往往小于10），并分配项目资源来定位它们。即使项目团队最后希望管理超出最大风险范围的风险 ，先将最大的风险集中到一个小的数值，然后在首要风险得到控制之后处理其他风险的方法常常也是相当高效的。

在风险分级过后，项目团队应该关注风险管理策略以及如何把风险行动计划融入整体计划当中。

解除风险

风险可以被解除或是被归类为非活动的，这样项目团队就可以集中精力管理活动的风险。将风险归类为非活动的，就意味着团队已经将它确定为不需要浪费精力去跟踪的项目。解除风险的决策发生在风险分析的过程中。

某些风险被解除的原因是它们的概率已经达到或是接近 0，它们已经成为非常不可能实现的条件。还有一些风险被解除的原因是他们的影响已经低于阀值，不值得再为其规划缓解或可能性策略；注意，即使风险的暴光量很低，但影响高于阀值，解除它们都是很不明智的，除非项目团队可以确定在任何可预知的环境下，概率（包括暴光量）都将持续保持低值。还应该注意，解除风险和排除风险是不同的，被解除的风险还可能在一定条件下重新出现，项目团队会将这一风险重新归类为活动的，并对其进行风险管理工作。

返回页首

风险计划和调度

介绍

风险计划和调度是风险管理过程中的第三个阶段。由项目团队执行的计划工作将分类风险清单转化为行动计划。计划包含为最大风险展开的详细策略和行动、风险行为分级以及综合风险管理计划的创建。调度包括在风险行为计划中必需实现的任务与项目进度表的集成，这是通过将它们分配给个体，并积极地跟踪它们的状态来实现的。图5对这一阶段进行了描述。

图 5：风险计划和调度

在风险分析过程中确定的最大风险补充了主导风险清单。有时，在计划过程中，让被分配风险行为项目的团队成员将主导风险清单中的这些部分引入单独的风险行为表格，是相当方便的。

目标

风险计划和调度阶段的主要目标是开发详细的计划，用于控制在风险分析阶段确定的最大风险，并将它们和标准项目管理过程集成，从而确保它们的完整性。

输入

MSF 风险管理原则提倡：风险计划应该与标准项目计划过程和基础设施紧密集成。风险计划的输入不仅仅包含主导风险清单、最大风险清单、风险管理知识库中的信息，还包含风险计划和进度表。

计划工作

在为减少风险暴光量而开发计划的过程中，应该做到以下几点：

降低风险有以下几种方法：

在风险行为计划的过程中，项目团队应该在明确叙述风险行为计划时考虑以下六种备选方案。

调查

很多项目风险与不完全信息周围的不确定性有关。知识缺乏引发的风险一般可以通过在行动前对更多的领域知识学习来高效地解决。例如，项目团队可以选择进行市场调查或用户群行为分析来了解更多关于用户基线技能以及完成项目计划前使用特定技术的想法。如果团队决定进行调查，那么风险计划应该包含适当的调查建议，包括有待证实的假定、有待回答的问题、职工安置以及任何所需的试验设备。

接受

一些风险是这样的，它不能简单地通过有效的预防性或调整措施来解决，但是项目团队可以选择简单地接受风险，从而认识机会。接受和“什么都不做”策略是不一样的，计划中应该包含归档的基本原理，说明团队为什么选择接受风险而不是开发缓解或意外事故计划。在项目生命周期中持续监控这样的风险应当非常谨慎，注意变化发生的可能性、影响或是执行风险相关的预防或意外事件方法。这些正在进行的监控或监视行动应该包含适当的资源和整体项目管理过程的跟踪度量值。

避免

有时风险可能非常容易通过改变项目范围来控制，来一并消除风险。风险计划应该包含变化基本原理的归档，项目计划则应该更新，并开始所有必需的计划更改或是范围变化过程。

迁移。

有时可以将风险迁移，这样它便能被另一个项目外部的实体所管理。可以迁移风险的情况如下所示：

风险迁移不意味着风险消除。一般而言，风险迁移会产生一些仍然需要前摄管理的风险，不过可以将风险降低到一个可以接受的等级。例如，利用外部顾问可以将技术风险转移到团队外部，但可能将一些风险引入项目管理和预算领域。

缓解

风险缓解计划包含了提前预防风险以及将影响或结果降低到可接受等级的行动或工作。风险缓解与风险避免不同，因为缓解关注预防和风险最小化，而风险避免则改变风险范围，从而移除可能带来无法接受风险的活动。

风险缓解的主要目标是减少风险发生的概率。例如使用冗余网络连接到 Internet，通过排除单点失效，可以减少访问失败的概率。

不是所有的项目风险都具有合理并划算的缓解策略。在缓解策略不可用的情况下，考虑一种高效应急计划作为替代，是非常基本的工作。

意外事故

风险应急计划创建一个或更多让步计划，从而避免不利的事件出现。意外事故计划对于所有风险都是必需的，包括已经拥有缓解计划的风险。它们定位了在风险发生时应该采取的措施，并关注结果和如何将影响最小化。为了更加高效，项目团队应该预先做出意外事故计划。项目团队常常可以基于可能遇到的影响/风险类型，为意外事故计划建立触发值。

有两种意外事故触发器：

对于项目团队来说，尽早与适当的管理人员在意外事故触发器和它们的值上达成一致非常重要，这样在执行紧急事件计划时就不会有预算或资源延迟。

调度工作

对于通常的项目调度工作，风险管理调度和控制工作和 MSF 推荐的标准方法没有什么区别。³⁰ 项目团队应该理解：风险控制工作是项目的一部分，而不是建立在主动基础上的附加工作，这是相当重要的。所有的风险工作都应该在项目调度和状态报告过程中计算。

输出

风险行动计划的输出应该包含特定的风险行动计划，实现前面讨论过的六种方法的其中一种。实现这些计划的任务应该与标准项目计划和进度表集成。它包含了资源调整、进度表和特性设置，让一套风险行动项目指定将由团队成员完成的个体任务。主导风险清单应该更新，以反映包含于缓解和意外事件计划中包含的额外信息。将风险管理计划总结为单独的文档是非常重要的 。

风险行动项目

风险行动项目记录在项目团队的标准项目行为跟踪系统里，因此应该将它们与其他任何行动等同看待。

和所有适当的归档行动一样，它们也应该与完成时限及人员分配相关联，因此不应该混淆谁该对其完成负责。

风险行动表格

项目团队应该为最大风险清单中的每个风险发展附加计划信息，从而记录缓解和意外事故计划、触发器和详细行动。在开发风险行动表格或文档时，团队应该考虑的信息如下：

更新的项目进度表和项目计划

风险相关的计划文档应该与整体项目计划文档以及被计划产生的新任务更新的主导项目进度表集成。

返回页首

风险跟踪和报告

风险跟踪是 MSF 风险管理过程中的第四个阶段。风险跟踪是高效实现行动计划的基本要素。它确保分配的任务能够实现预防性方法，并且意外事故计划在项目资源约束下可以及时完成。在风险跟踪阶段，项目团队的首要工作是监控风险度量值和触发事件，从而保证计划中的风险行动正常工作。跟踪是风险行动计划中的监控功能。图 6 对风险跟踪进行了描述。

图 6：风险跟踪和报告

目标

风险跟踪阶段的目标是监控风险行动计划的状态（意外事故和缓解计划完成的进度），从而监控已经和意外事故计划触发器相关联的项目度量值，并通知项目团队意外事故触发器已经启动，意外事故计划也要开始执行了。

输入

风险跟踪阶段的主要输入包括：

取决于项目团队跟踪的特定项目度量值，其他信息资源（例如项目跟踪数据库、源代码仓库或登记系统，甚至人力资源管理系统）也可以为项目团队提供跟踪数据。

跟踪工作

在风险跟踪阶段，项目团队将缓解计划中的行动作为团队整体工作的一部分来执行。项目团队通过触发值提取这些风险相关的动作项目和相关变化，并用它们为每个风险创建特定风险状态报告。

可能被分配触发度量值，并持续跟踪的项目度量值包括：

风险状态报告

风险报告应该在两个层面启动。对于项目团队自身，规则的风险状态报告应该为每个风险考虑四种可能的风险管理情况：

在给项目投资人的外部报告里，项目团队应该报告最大风险，并总结风险管理工作状态。报告早前的项目分级和每个风险进入最大风险清单的次数也是非常有用的。当项目团队开始采取行动来管理风险的时候，项目的总暴光量应该开始接近可接受的等级。

输出

风险状态报告的目的是交流风险状态变化，并报告缓解计划的进度。风险状态报告中的有用信息包括：

主管或投资人风险状态报告的目标是交流项目中的综合风险状态。报告中包含的重要信息包括：

这个报告通常包含于标准项目状态报告中。

返回页首

风险控制

风险控制是 MSF 风险管理过程中的第五个阶段。在这个阶段，项目团队对意外事故计划相关的活动进行实际操作，因为触发器已经被触发了。图7对这个阶段进行了描述。

图7：风险控制

纠正工作的发起基于风险跟踪阶段获得的信息。MSF 风险管理原则依赖现有的标准项目管理过程以及基础设施，如下所示：

从意外事故执行中获得的结果或教训将被并入意外事故计划状态和结果报告，这样，信息将成为项目和企业风险知识库的一部分。在故障发生的时候或意外事故计划被用来确定风险控制计划或策略功效的时候，尽可能多地捕获故障相关的信息是相当重要的。

目标

风险控制阶段的目标是成功执行项目团队为最大风险创建的意外事故计划。

输入

风险控制阶段的输入是风险行动表格，它详细列出了将被项目团队成员完成的工作以及记录项目度量值的风险状态报告。.

控制工作

风险控制工作应该利用标准项目管理过程来初始化、监控并评估计划进度。虽然风险计划的特定细节因不同的项目而异，但是还是应该使用任务状态报告的一般过程。保持持续的风险识别，从而发现可能出现或因意外事故执行而扩大的二次风险是非常重要的。

输出

风险控制阶段的输出是标准项目状态报告，它记录意外事故计划完成的进度。对于项目团队来说，将意外事故计划中学到的特定内容（例如，什么在工作，什么不能工作）总结成意外事故计划输出总结的形式是非常重要的。在拥有正式的更改控制过程的项目中，风险状态的变化应该也能导致更改控制请求的产生。

返回页首

风险学习

介绍

风险学习是 MSF 风险管理过程中的第六个，也是最后一个阶段。它将战略的、企业或是组织的观点加到风险管理活动中。这个阶段常常指风险作用，强调通过性能提升和团队、项目或组织层面的成熟获得的价值，还强调风险管理过程的改进。风险学习应该是 MSF 风险管理过程中持续的工作，可以在任何时间开始。它关注三个主要的目标：

风险审查会议提供风险学习的讨论。它们应该记录在正规原理中，和其他 MSF 审查工作一样，它们从提前计划、清晰的预先日程、所有参与者的分享以及“无过失”环境中的自由、诚实交流中获益。图8对风险学习阶段进行描述。

图8：风险学习

从风险学习中提取知识

风险分类定义是确保从前经验适用于将来风险评估工作的强大手段。通常使用风险分类来记录的风险学习中的两个主要方面是：

管理风险学习

使用风险管理技术的组织常常发现：它们需要创建一种结构化的方法来管理项目风险。成功推动这一需求的条件包括：

特定上下文的风险分类

风险识别可以通过特定重复的项目上下文风险分类工作来完备化。例如，一个项目实施组织可以对不同类型的项目进行分类。随着在项目上下文中获得更多的经验，可以进一步明确风险并成功地与缓解策略联系起来。

风险知识库

风险知识库是一种正式或非正式的机制，项目组织通过风险知识库捕获知识，来帮助将来的风险管理。如果没有某些知识库，项目组织可能很难采取前摄的方法来管理风险。风险知识库和风险管理数据库不同，风险管理数据库是用来在项目过程中存储和跟踪个体风险项目、计划和状态的。

发展风险知识管理的成熟度

风险知识库是风险管理持续发展的关键驱动力。

在不成熟的情况下，项目和过程团队的知识库没有特定的形式。每个团队都必须在每次进行风险管理的时候从零开始。在这样的环境下，风险管理方法通常是起反作用的，但是可能会转向下一个阶段，也就是积极的风险管理。然而，团队不能前摄管理风险。

下一级的成熟度包括一个非正式的知识库，通过更多富有经验的组织成员获得固有的知识。这通常是通过实现风险板来实现的，富有经验的从业者可以通过风险板审查每个团队的工作。这种方法鼓励积极的风险管理，可能在策略的引入中实现有限的前摄管理。前摄风险管理策略的一个例子是“所有超过20天的项目都需要在正式开展前进行风险审查。”

正式知识库的第一个级别提供更多结构化的方法来进行风险识别。MSF 风险管理原则提倡使用风险分类来实现这一目标。通过对经验正式的捕获和索引，项目组织可以更多地前摄管理风险，因为风险的潜在的原因已经被确定了。

最后，成熟的组织不仅记录可能导致风险的指示器，还记录被用来管理风险和它们的成功比率的策略。有了这种形式的知识库，风险过程识别和计划阶段就可以基于许多团队间共享的经验，组织可以开始优化它们的风险管理成本，收回项目投资。

在风险知识库的执行中，经验告诉我们：

风险管理不应该成为一个自动化过程，这样会消除团队思考风险的需要。即使在重复的条件下，商业环境、客户期望、团队技能和技术也始终在变化。因此，项目团队必须为特定项目情况评估适当的风险管理策略。

返回页首

项目生命周期中的集成风险管理

MSF 风险管理过程与整体项目生命周期紧密集成。风险评估可以在预想中开始，跟着项目团队和投资人开始设置约束。对于每个加入项目的约束和假定，额外的风险都可能形成。项目团队应该尽可能早的在项目中进行识别工作。在风险分析和计划阶段，所需的风险缓解和意外事故计划应该直接建入项目进度表和整体计划中。风险计划的进度应该由标准项目管理过程进行监控。

尽管风险管理过程通常由预定的初始风险识别和分析会议开始，但之后的风险计划、跟踪和控制阶段将对主导风险清单上的不同风险采取不同措施。在 MSF 风险管理原则中，持续风险管理假定：项目团队 “总是”同时地进行风险识别和跟踪阶段。他们将在触发事件、风险进度表和计划启动后参加风险控制工作。然而，在整个项目生命周期中，新的风险会不断出现，这就需要开始额外分析和计划会议。不需要用任何特定生命周期事件来同步风险管理阶段。一些项目团队将在主要事件发生时开始风险识别和分析，以方便项目状态的再评估。同时总结风险中的知识是非常方便的。

一般而言，风险识别和风险跟踪是长期持续的工作。项目团队成员应该坚持不懈地在项目中寻找风险，并处理它们，持续地跟踪特定风险计划的进度。对风险的分析、再分析以及对风险管理行动计划的更改工作可能是断断续续的，有时是提前计划（或许围绕着重大事件），还有时是不按时间表的项目事件导致（在跟踪和控制阶段发现的其他风险）的。学习大都发生在重大事件和项目的结束期。

随着阶段的变化，风险的种类也会改变。在项目早期，商业、范围、需求和风险相关的规划占主导地位。随着时间的进展，执行过程中的技术风险变得更加突出，接着又转化为操作风险。在项目生命周期的主要阶段，利用风险检查表或审查风险分类清单来指导风险识别工作是非常有用的。

返回页首

企业中的风险管理

为了实现风险管理工作回报的最大化，对于一个企业来说，保持风险管理的企业观点是非常重要的。

创建风险管理文化

尽管很少有项目实施组织反对在项目中进行风险管理，但很多组织发现完全采用前摄风险管理过程相关的原则非常困难。它们常常在每个项目的开始进行风险评估，却不能在项目进行时维护过程。

这通常有两个原因：

这些信任的根本原因一般是管理人员本身并没有意识到在项目中实施风险管理的重要性。结果他们很难在项目预算中计划足够的风险管理时间（和其他风险管理活动）。在预算面临压力的时候，他们会首先抛弃风险管理工作。

因此，确保所有的投资人认识到风险管理重要性，从而建立有注意风险管理成长的文化，是非常重要的。在把风险管理作为一致原则建立过程中，下面的阶段非常有效：

返回页首

管理项目的公文包

项目实施组织可以通过引入一个过程来管理项目中公文包的风险而受益。通常有以下好处：

应该注意：公文包风险审查补充了被每个项目团队实施的风险评估。审查团队没有识别风险所需的项目知识，也没有可用的时间来进行风险缓解工作。然而，它可以进行风险分析和计划工作。

因为审查团队通常包含更多经验丰富的管理人员，所有它的成员常常可以利用经验向面临重大风险的项目团队提出建议，帮助项目团队对风险分级。它们也可以向团队推荐他们曾经遇到过的、能够高效使用的缓解和意外事故策略。

下面是被应用到公文包风险管理的成功做法：

返回页首

概要

MSF 风险管理原则提倡对软件开发和部署项目使用前摄的、结果化的风险管理。MSF 风险管理过程包含六个逻辑阶段（识别、分析、计划、跟踪、控制和学习），在整个项目生命周期中，项目团队都应该不断地重复这个循环。学习阶段用于交流从企业级风险管理资源中学到和反馈的项目风险知识，并在企业风险知识库记录。

本文档中包含的信息代表 Microsoft 公司在发布时对所讨论问题的最新观点。由于 Microsoft 必须适应不断变化的市场情况，因此，这些信息并非 Microsoft 方面所作的承诺，Microsoft 也不能保证出版日之后提供的任何信息都完全正确。

这份白皮书仅用于提供信息。对于本文档中的信息，Microsoft 不作任何明示、暗示或法律的保证。

用户有责任遵从所有适用的版权法。除了版权法所赋予的权利以外，未经 Microsoft 公司明确书面许可，不得擅自将本文档的任何部分进行复制、存储在或输入可检索系统，或以任何形式或方式（电子、机械、影印、录制或其他方式）进行传播，或用作其他目的。

Microsoft 对本文档中的主题持有专利权、专利申请权、商标权、版权或其他相关的知识产权。Microsoft 只提供在任何书面许可协议中明确规定的权利，而不授予您本文档的上述专利权、商标权、版权或其他知识产权。

© 2002 Microsoft 公司版权所有。

Microsoft 是 Microsoft Corporation 在美国和/或其他国家/地区的注册商标或商标。

此处提到的真实的公司和产品名称是其各自所有者的商标。

编号： 602-i401a

¹MSF Process Model v. 3.0, 2002

²Audrey J. Dorofee, Julie A. Walker, Christopher J Alberts et al, Continuous Risk Management Guidebook (Carnegie-Mellon University, 1996).

³ Ronald P. Higuera, "Team Risk Management: A New Model for Customer-Supplier Relationships", SEI Technical Report CMU/ SEI-94-SR-5, (Pittsburgh, PA: Software Engineering Institute—Carnegie Mellon University), 1994.

⁴ Encarta 2002, Article "Insurance. II. Reasons for Insurance".

⁵ Jim McCarthy, Dynamics of Software Development (Redmond, Washington: Microsoft Press, 1995), page 99.

⁶ 这八个原则是：1. 预测变化-保持灵活。 2. 在工作中分享观点。 3. 在生命周期中关注商业价值。 4. 在质量上投资。 5. 从所有的经验中学习—好的和坏的。 6. 鼓励公开交流。 7. 清楚的义务，共同的责任。 8. 赋予团队权力。

⁷ MSF Team Model 3.0 Whitepaper.

⁸ 查看 MSF 3.0 Process Model Whitepaper 以进行更深入的讨论，它在http://www.microsoft.com/china/technet/itsolutions/techguide/msf/可用。

⁹ Ronald P. Higuera and Yacov Y. Haimes, "Software Risk Management", SEI Technical Report CMU/SEI-96-TR-012 ESC-96-012 (Pittsburgh, PA: Software Engineering Institute—Carnegie Mellon University, 1996).

¹⁰ 例如， Steve McConnell, Software Project Survival Guide, (Redmond, WA: Microsoft Press), 1998.

¹¹ Barry W. Boehm, Software Risk Management, (New York, NY: IEEE Press), 1989.

¹² Capers Jones, Assessment and Control of Software Risks. (Englewood, NJ: Prentice-Hall, 1994). ISBN 0-13-741406-4

¹³ Ronald P. Higuera and Yacov Y. Haimes, "Software Risk Management", SEI Technical Report, 1996.

¹⁴ Steve McConnell, Rapid Development, (Redmond, Microsoft Press), 1996, pp 87-91.

¹⁵ Thomas R. Peltier, Information Security Risk Analysis, (Boca Raton: Auerbach Publications, 2001).

¹⁶ Donald L Pipkin, Information Security: Protecting the Global Enterprise, (Newark, NJ: Prentice Hall, 2000).

¹⁷http://seir.sei.cmu.edu/

¹⁸ 一种有效的根本原因识别的自由讨论技术叫做“五个为什么”。在这个方法中，项目团队应该提出关于风险条件的“为什么”，提供答案，并重复“为什么？因为……”循环至少五次。

¹⁹ 这可以通过不同的“五个为什么” 技术来完成，项目团队应该重复“为什么？因为……”循环至少五次。

²⁰ Audrey J Dorofee, Julie A Walker, Christopher J Alberts, et al., Continuous Risk Management Guidebook. (Pittsburgh, PA: Carnegie Mellon University, 1996).

²¹ Linda H Rosenberg , Theodore Hammer , Albert Gallo, Continuous Risk Management at NASA, 1999 (http://satc.gsfc.nasa.gov/support/ASM_FEB99/crm_at_nasa.html)

²²MSF Risk Management Process Whitepaper, 2001.

²³Principles of Application Development- Course 593 and Course 1517.

²⁴ Rosenberg LH, et al., 1999.

²⁵ Elaine Hall, Managing Risk. Methods for Software Systems Development, SEI Series in Software Engineering, (Reading, MA: Addison-Wesley, 1998), Ch. 4, "Identify Risk".

²⁶ Dorfee AJ, et al, 1996.

²⁷ Elaine Hall, Managing Risk, p. 101.

²⁸ Project Management Institute, A Guide to the Project Management Body of Knowledge 2000 Edition, (Newtown Square, PA: Project Management Institute, Inc. 2000), Chapter 11.

²⁹ Elaine Hall, Managing Risk.

³⁰ 查看MSF 3.0 Project Management Discipline，位于 http://www.microsoft.com/china/technet/itsolutions/techguide/msf/。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号