| 11.5 规划风险应对 | ||
| 11.5.1.1 项目管理计划 | 11.5.2.1 专家判断 | 11.5.3.1 变更请求 |
| 11.5.1.2 项目文件 | 11.5.2.2 数据收集 | 11.5.3.2 项目管理计划更新 |
| 11.5.1.3 事业环境因素 | 11.5.2.3 人际关系与团队技能 | 11.5.3.3 项目文件更新 |
| 11.5.1.4 组织过程资产 | 11.5.2.4 威胁应对策略 | |
| 11.5.2.5 机会应对策略 | ||
| 11.5.2.6 应急应对策略 | ||
| 11.5.2.7 整体项目风险应对策略 | ||
| 11.5.2.8 数据分析 | ||
| 11.5.2.9 决策 |
规划风险应对是为处理整体项目风险敞口，以及应对单个项目风险，而制定可选方案、选择应对策略并商定应对行动的过程。本过程的主要作用是，制定应对整体项目风险和单个项目风险的适当方法；本过程还将分配资源，并根据需要将相关活动添加进项目文件和项目管理计划。
要为实施商定的风险应对策略，包括主要策略和备用策略（若必要），制定具体的应对行动。如果选定的策略并不完全有效，或者发生了已接受的风险，就需要制定应急计划（或弹回计划）。同时，也需要识别次生风险。次生风险是实施风险应对措施而直接导致的风险。往往需要为风险分配时间或成本应急储备，并可能需要说明动用应急储备的条件。
一、 输入
1. 项目管理计划：
a) 资源管理计划：有助于确定该如何协调用于风险应对的资源和其他项目资源。
b) 风险管理计划：本过程会用到其中的风险管理角色和职责，以及风险临界值。
c) 成本基准：包含了拟用于风险应对的应急资金的信息。
2. 项目文件
a) 经验教训登记册：
b) 项目进度计划：可用于确定如何同时规划商定的风险应对活动和其他项目活动。
c) 项目团队派工单：列明了可用于风险应对的人力资源。
d) 资源日历：确定了潜在的资源何时可用于风险应对。
e) 风险登记册：包含了已识别并排序的、需要应对的单个项目风险的详细信息。列出了每项风险的指定风险责任人，还可能包含在早期的项目风险管理过程中识别的初步风险应对措施。
f) 风险报告：报告中的项目整体风险敞口的当前级别，会影响选择适当的风险应对策略。
g) 相关方登记册：列出了风险应对的潜在责任人。
二、 工具
1. 专家判断：
2. 数据收集：单个项目风险和整体项目风险的应对措施可以在与风险责任人的结构化或半结构化的访谈中制定。
3. 人际关系与团队技能：开展引导，能够提高单个项目风险和整体项目风险应对策略制定的有效性。
4. 威胁应对策略：
a) 上报：如果项目团队或项目发起人认为某威胁不在项目范围内，或提议的应对措施超出了项目经理的权限，就应该采用上报策略。注：因为威胁不在本项目内，所以才可以上报给相关级别的管理人员，后续项目团队不跟踪。
b) 规避：是指项目团队采取行动来消除威胁，或保护项目免受威胁的影响。可能涉及变更项目管理计划的某些方面，或改变会受负面影响的目标，以便于彻底消除威胁，将它的发生概率降低到零。规避措施可能包括消除威胁的原因、延长进度计划、改变项目策略，或缩小范围。注：规避也可以翻译成回避，通常是通过改变计划来完全消除威胁。
c) 转移：涉及到将应对威胁的责任转移给第三方，让第三方管理风险并承担威胁发生的影响。采用转移策略，通常需要向承担威胁的一方支付风险转移费用。包括（但不限于）购买保险、使用履约保函、使用担保书、使用保证书等。注：一般转移针对财务风险最有效，而非财务类的风险使用外包更多起到的是减轻的效果。通常在题目中明确说明属于财务风险或并没有明确说明影响什么，一般选择转移。
d) 减轻：是指采取措施来降低威胁发生的概率和（或）影响。减轻措施包括采用较简单的流程，进行更多次测试，或者选用更可靠的卖方。如果无法降低概率，也许可以从决定风险严重性的因素入手，来减轻风险发生的影响。例如，在一个系统中加入冗余部件，可以减轻原始部件故障所造成的影响。注：减轻通常包括降低威胁发生的概率或减轻风险造成的影响。
e) 接受：是指承认威胁的存在，但不主动采取措施。接受策略又分为主动或被动方式。最常见的主动接受策略是建立应急储备，包括预留时间、资金或资源以应对出现的威胁；被动接受策略则不会主动采取行动，而只是定期对威胁进行审查，确保其并未发生重大改变。注：接受包括主动和被动两种，其中主动接受是预留应急储备，简单说就是留钱留时间当风险真的发生再使用储备来解决风险；而被动接受就是什么都不做，就是生挺。
5. 机会应对策略：
a) 上报：如果项目团队或项目发起人认为某机会不在项目范围内，或提议的应对措施超出了项目经理的权限，就应该取用上报策略。注：与威胁中的上报策略基本一致。
b) 开拓：如果组织想确保把握住高优先级的机会，就可以选择开拓策略。此策略将特定机会的出现概率提高到 100%，确保其肯定出现，从而获得与其相关的收益。开拓措施可能包括：把组织中最有能力的资源分配给项目来缩短完工时间，或采用全新技术或技术升级来节约项目成本并缩短项目持续时间。注：开拓通常会提及增加最优资源，强调确保机会发生。
c) 分享：涉及到将应对机会的责任转移给第三方，使其享有机会所带来的部分收益。采用风险分享策略，通常需要向承担机会应对责任的一方支付风险费用。分享措施包括建立合伙关系、合作团队、特殊公司或合资企业来分享机会。注：分享通常强调受益方较多，一起面对共同受益。
d) 提高：用于提高机会出现的概率和（或）影响。通过关注其原因，可以提高机会出现的概率；如果无法提高概率，也许可以针对决定其潜在收益规模的因素来提高机会发生的影响。机会提高措施包括为早日完成活动而增加资源。注：提高与开拓比较相近，区别仅限于提高只强调增加资源，不见得是最优所以只能提升机会发生的概率但是达不到100%。
e) 接受：是指承认机会的存在，但不主动采取措施。接受策略又分为主动或被动方式。最常见的主动接受策略是建立应急储备，包括预留时间、资金或资源，以便在机会出现时加以利用；被动接受策略则不会主动采取行动，而只是定期对机会进行审查，确保其并未发生重大改变。注：与威胁的接受策略基本一致。
6. 应急应对策略：可以设计一些仅在特定事件发生时才采用的应对措施，通常称为应急计划或弹回计划。
7. 整体项目风险应对策略
a) 规避：如果整体项目风险有严重的负面影响，并已超出商定的项目风险临界值，就可以采用规避策略。此策略涉及采取集中行动，弱化不确定性对项目整体的负面影响，并将项目拉回到临界值以内。
b) 开拓：如果整体项目风险有显著的正面影响，并已超出商定的项目风险临界值，就可以采用开拓策略。此策略涉及采取集中行动，去获得不确定性对整体项目的正面影响。
c) 转移或分享：如果整体项目风险的级别很高，组织无法有效加以应对，就可能需要让第三方代表组织对风险进行管理。若整体项目风险是负面的，就需要采取转移策略，这可能涉及支付风险费用；如果整体项目风险高度正面，则由多方分享，以获得相关收益。
d) 减轻或提高：本策略涉及变更整体项目风险的级别，以优化实现项目目标的可能性。减轻策略适用于负面的整体项目风险，而提高策略则适用于正面的整体项目风险。
e) 接受：即使整体项目风险已超出商定的临界值，如果无法针对整体项目风险采取主动的应对策略，组织可能选择继续按当前的定义推动项目进展。
8. 数据分析：
a) 备选方案分析：对备选风险应对方案的特征和要求进行简单比较，进而确定哪个应对方案最为适用。
b) 成本收益分析：如果能够把单个项目风险的影响进行货币量化，那么就可以通过成本收益分析来确定备选风险应对策略的成本有效性。
9. 决策：多标准决策分析，列入考虑范围的风险应对策略可能是一种或多种。决策技术有助于对多种风险应对策略进行优先级排序。
三、 输出：
1. 变更请求：规划风险应对后，可能会就成本基准和进度基准，或项目管理计划的其他组件提出变更请求，应该通过实施整体变更控制过程对变更请求进行审查和处理。
2. 项目管理计划更新：
3. 项目文件更新
a) 风险登记册：需要更新风险登记册，记录选择和商定的风险应对措施。风险登记册的更新可能包括（但不限于）：商定的应对策略；实施所选应对策略所需要的具体行动；风险发生的出发条件、征兆和预警信号；实施所选应对策略所需要的预算和进度活动；应急计划，以及启动该计划所需的风险触发条件；弹回计划，供风险发生且主要应对措施不足以应对时使用；在采取预定应对措施之后仍然存在的参与风险，以及被有意接受的风险；由实施风险应对措施而直接导致的次生风险。注：规划风险应对过程输出的风险登记册的内容需要掌握。
b) 风险报告：更新风险报告，记录针对当前整体项目风险敞口和高优先级风险的经商定的应对措施，以及实施这些措施之后的预期变化。
作者：ZLena
链接：https://www.jianshu.com/p/ea2f45859e37
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
以下是笔者总结出来的IT项目的常见风险及应对措施，供大家参考。
|
风险名称 |
风险类别 |
应对措施 |
|
技术方案不可行 |
技术风险 |
设计时考虑备用方案 |
|
人力资源不足 |
资源风险 |
合理安排工作、激励和技能培训 |
|
人员离职 |
资源风险 |
做好团队建设工作、从技能上备份人才 |
|
需求变更 |
需求风险 |
尽量细化需求描述，建立需求变更流程并严格执行 |
|
用户不配合 |
管理风险 |
事先签订合作协议，明晰双方责任和义务，记录过程证据 |
|
验收困难 |
管理风险 |
事先达成验收共识，不折不扣地按计划执行，多和关键人员汇报及沟通 |
|
工期较紧张 |
进度风险 |
采用迭代开发的模式，分期提交 |
|
高层支持不足 |
管理风险 |
多和领导沟通、经常向领导汇报工作情况 |
|
系统性能达不到要求 |
技术风险 |
提前设计和搭建出系统的基础架构并进行性能测试，确保架构符合性能指标后再进行后续工作 |
|
工具不到位 |
管理风险 |
在项目的启动阶段就落实好各项工具的来源和可能的替代工具 |
|
供应商工作质量不达标 |
管理风险 |
指定专人全程监控供应商活动、让供应商采用经认可的开发流程、督促供应商及时提交和汇报工作成果、及时审计供应商的工作成果 |