风险声明
风险声明是一种自然语言表达,它表述了真实、实际存在的项目事件或属性状态和潜在、没有实现的项目事件或属性间的因果关系。风险声明的第一部分被称为条件,它提供了现有项目属性或事件状态的描述,项目团队认为这可能有原因地导致项目损失或收益缩减。而风险声明的第二部分则是另一种自然语言声明,称为结果 。结果阐述了不期望出现的项目属性或事件状态。这两种声明被“因此”或是“结果”这样的连词关联起来,暗示着不确定的(换句话说,不是100%的)但又存在因果关系的关系。图 3 用图表的方法对其进行了描述。
图 3:风险声明
查看完整的图像。
风险声明中的两部数字化过程能够更好地在风险识别阶段的前期联结风险结果和可见的(以及可潜在管理的)风险条件 。在风险识别阶段仅仅关注风险条件需要团队备份风险条件,从而保证风险管理进程的后期阶段,当他们开发管理策略的时候能够再次使用。
注意,风险声明并不是“如果-那么”格式的声明,而是搜索可能却没有实现的结果的事实声明。在分析和计划阶段,使用假定的“如果-那么”声明可能对权衡方案和使用决策树明确地叙述计划有所帮助。然而,在风险识别阶段,目标是识别尽可能多的风险,因此应该将“如果-那么”推迟到计划阶段。在项目初期应该有丰富的风险声明,描述团队缺乏的知识,例如“我们目前还不明白某事,因此……”。
在明确叙述风险声明的时候,项目团队应该既考虑到潜在的原因和没有实现的不期望的结果,又考虑到结果的本身。风险声明包含了项目中的现有事件(条件)状态,也包含了可能发生的事件(结果)状态。作为彻底的风险分析的一部分,团队成员应该寻找项目风险声明中条件的相似性和自然分类,并通过每个条件的因果链寻找共同的潜在原因。18根据风险声明中“条件-结果”组合的因果链,检查组织和项目外部环境的影响,从而获取与特定项目条件相关联的整体损失或机会损失的更大增值,也是相当重要的。19
在风险识别期间,很少有团队为同一条件识别多个结果。有时,在项目的某一领域定义的风险结果可能会成为另一个结果的风险条件。项目团队应该记录这些条件,从而在风险分析和计划过程中做出适当的决策。取决于风险之间的关系,结束一个风险可能会结束一组相互依赖的风险,并改变项目中的整体风险状况。在风险识别阶段的前期记录这些关系,能提供大量有用的信息,用于指导风险计划,这些风险计划是灵活的、全面的,并能通过定位根本或前导原因来高效利用可用项目资源。在识别阶段捕获这样的附加信息的益处,应该与后来的分析和分级过程中的快速移动,以及计划阶段中对依存关系和根本原因的再审查相平衡。
输出
风险识别工作中的最小化输出是一份清晰、明确、得到一致肯定的风险声明,作为 风险清单记录下来。如果风险条件-结果方法像SEI 20、NASA21以及较早版本的 MSF22中描述的那样使用23,那么输出的将是一个风险声明的集合,用来明确地描述项目中被识别的风险。而这个表格形式的清单将成为风险管理过程下一个阶段,也就是分析阶段的主要输入。在风险识别阶段常常还生成其他的大量有用信息,包括根本原因和影响的识别、受影响的团体以及所有者等等。
MSF 风险管理原则建议项目团队创建表格式的风险声明记录、根本原因以及影响信息。在定义良好的分类法存在的情况下,在使用项目风险信息来构建或利用企业风险知识库时,用于对风险分级的额外信息可能也是相当有用的。其他有用信息可能记录在风险清单中,以定义风险的上下文 ,从而帮助其他团队成员、外部评论家或投资人更好的理解团队意图24,25,26。在风险识别阶段,项目团队可能选择记录的风险上下文信息包含以下几点:
• |
条件 |
• |
约束 |
• |
环境 |
• |
假定 |
• |
起作用的要素 |
• |
风险间的依存关系 |
• |
相关问题 |
• |
商业资产所有者 |
• |
团队关注点 |
表格式的风险清单(包含或不包含条件、根本原因、影响或上下文信息)将成为后面的风险管理过程阶段的主导风险清单。下面的示例表格描述了主导风险列表的形式。
根本原因 | 条件 | 结果 | 影响 |
职工安置不合理 |
开发和测试角色被混合 |
我们会遇到更多bug |
客户满意度减少 |
技术变革 |
我们的程序员遇到生疏的程序设计语言 |
开发时间将拉长 |
我们进入市场的时间更迟,将市场份额拱手让给竞争者 |
组织 |
开发团队被分隔在London和Los Angeles两地 |
团队内部的交流将更加困难 |
产品发布时间延迟,并产生更多的额外工作量 |