hello world

Time is so ruthless. the last post is 4 years ago.
GFW is so powerful. My Chinese post has no reader.
But My English artical is so few.
Next I need write in English.

恢复更新！

虽然这里没人看。
但恢复更新了。
向强权要自由，哪怕付出金钱！

项目风险管理的常见问题和对策

引言
项目风险管理相对于企业全面风险管理，主要关注项目范围之内的风险，所关注风险相对比较具体，涉及总的影响范围较小，一般地采用定性分析方法。 在定性项目风险管理中，本文指出了五个方面的问题，并给出了对策。
1，用词问题
各大标准/最佳实践中也都有风险管理的内容，其中用词并不一致。在多个标准/最佳实践的导入中产生了由于用词理解不一致而发生的误解，在业界交流讨论时也多有不便。
风险，没有其它用词，但本身有二个不同含义：一种定义强调了风险表现为不确定性；而另一种定义则强调风险表现为损失的不确定性。这二个不同含义简直就是导致用词不一致的根源。现在大多数标准采用第一种定义，但停留在各级管理者头脑中的定义仍是第二种
风险管理，在有些地方又叫“危机管理”，不过一般对危机管理的理解与风险管理并不一样，危机管理更偏重于危机发生后的管理。
风险应对，在PMP中是指在风险识别以后到风险触发或关闭之间采取的促使风险向有利方面转化的方案和措施，在CMMI中相应的词是“风险缓解”，也有地方用“风险处置”，“风险处理”。 本文下文中使用“风险应对”。
风险应急应对，在PMP中“对某些特定事件，专门设计一些应对措施。对于有些风险，项目团队可以制定应急应对策略，即只有在某些预定条件发生时才能实施的应对计划。如果确信风险的发生会有充分的预警信号，就应该制定应急应对策略。应该对触发应急策略的事件进行定义和跟踪，如未实现阶段性里程碑，或获得供应商更高程度的重视。”，一般而言，这是指风险触发后或预计必定触发后的方案和措施。其它用词有“风险应变”，“风险应急”。
风险可能性，指风险发生的可能性，其它用词有“风险概率”。
风险影响，指风险发生的冲击，其它用词有“风险影响的程度”，“风险严重级别”。
危险性，其它用词有“风险值”。
接受风险，其它用词有“承受风险”，“保留风险”，“保持风险”。
避免风险，有“回避风险”，“规避风险”。
转移风险，有偏转风险
减轻风险，有“缓解风险”，“控制风险”，“降低风险”注意：与前文有冲突。
风险触发器，其它用词有“风险征兆”，“警示信号”。

对此问题，对策是在一定的组织范围内对风险用词给出定义，比如在风险管理规程中专门进行词汇定义。
2，认识问题
20世纪80年代，软件风险管理之父Boehm将风险管理的概念引入软件界。Boehm认为:软件风险管理这门学科的出现就是试图将影响项目成功的风险形式化为一组易用的原则和实践的集合，目标是在风险成为软件项目返工的主要因素并由此威胁到项目的成功运作前，识别、描述并消除这些风险项。
在CMMI过程域中，风险管理过程域是关联度最高的过程域之一。与风险管理明确相关的过程域目标有：
1，需求分析过程域的特定目标3：分析并确认需求
2，需求管理过程域的特定目标1：管理需求
3, 项目计划过程域的特定目标2：建立和维护开发项目计划
4, 项目监控过程域的SG 1：按照计划监控项目
5, 供应商管理过程域的SG 1：建立供应商协议
6，集成项目管理过程域的SG 1： 使用项目定义过程
7, 技术解决方案过程域的SG 1：选择产品组件解决方案
8, 决策分析及决议过程域的SG 1 ：评估备选方案
9, 产品集成过程域的SG 1： 准备产品集成
10, 组织过程焦点过程域的SG 2： 策划与执行过程改进
11, 组织培训过程域的SG 1：建立组织培训能力
等等不完全列举
在PMP中，风险管理是9大领域之一。

从以上大师的论述、CMMI的相关性、PMP中的篇幅，可以充分看到风险管理的重要性。

3，风险的表述问题
风险在表述时，用多个属性来综合说明风险的全部内容，常见的风险属性有：标题、说明、负责人、应对措施、时间要求、风险概率、风险影响度等等。
必备的属性有标题和说明（也有称为描述）
常见的一个突出问题是没有对风险的标题给出指导或要求，各项目识别的风险标题差异明显，如下面的例子：

• 存在工期延误的风险
• 过多的支持工作占用工作量可能导致工期延误
• 频繁的需求变更可能导致项目规模变大，成本超支，工期超期，人员士气低落而离职
• 频繁的需求变更、过多的故障现场支持还有人员意外离职都可能导致项目工期延误

类似第一个风险标题，没有说明风险来源，只说了后果，在实践中有如下不利之处：

1. 不能直观理解，仅从标题不难了解可能的困难。
2. 在风险的说明中，把多个风险来源写在一起，相应的应对措施也放在一起，不利于分别跟踪，可能导致只跟踪了部分诱发困素。
3. 风险难于高效地有效地跟踪到关闭，由于多种风险来源能够导致相同的后果，风险长期得不到关闭，会产生风险麻痹。

类似第二个风险标题，说明了一个风险来源及相应的一个后果，这样应对措施可以针对这个诱发困素，应变计划针对这个后果，可以高效且有效的跟踪风险直到关闭。

类似第三个风险标题，说明了一个风险来源及相应的多个后果，这样应对措施可以针对这个风险来源，由于是同一因素引发的后果，应变计划虽然要处理多个后果，但是相对应容易制订。在着重预防的风险应对中，能够清晰识别并管理应对措施，也是不错的做法。

类似第四个风险标题，说明子多个风险来源及相应的一个后果，这个写法的不利之处与第一种写法相似，相对好一点的地方是限定了风险来源的范围，但总得说来，也是不推荐的写法。

对此问题，对策是优先采用上述类似第二个风险的写法，可以采用上述类似第三个风险的写法。

4，风险的跟踪问题
常见的风险跟踪问题主要有二类：第一类是轻视风险管理；第二类是没有预先考虑风险发生的条件。

对于第一类问题，主要发现为风险不及时跟踪，过程中不主动识别，认识问题是主因。前期加强宣导、培训，在过程中保持关注，恰当地进行监督是这类问题的对策。

对于第二类问题，过程中的风险发展是一个渐变的过程，有些风险的渐变比较缓慢，因此在风险跟踪中比较容易错过采取措施的第一时间。所以预先考虑风险发生的条件是很有必要的，做法是设立风险触发器，风险触发器说明风险已经发生或者将必然发生。比如对于第3章中第2个例子，风险触发器可以是“当连续两周支持工作量比重超过了50%”，或者是“到X年X月X日，累计支持工作量比重超过40%”。风险触发器中设立日期期限是个推荐的做法，这样会较容易监控这个触发器。为争取第一时间，风险触发器设立时，应优先更注预警信号。比如对于第3章中第3个例子，触发器1设成这样“一期工程完工日期较计划延迟二周”，触发器2是这样“变更后的项目规模超过了原计划估模的130%”，比较一下就发现，触发器2是能更早地捕捉风险的发生，也就能更多地争取到时间和调整空间。

5，可操作性问题
风险识别之后的应对措施是保证风险向有利方面转化的关键过程。以下是应对措施的实例。
1, 加强交流，保持沟通

2, 密切注意里程碑工期偏差

3, 对新员工开展Java工作流方面的培训

以上应对措施的通病是不具备可操作性，可操作性有三个要素：人员、时间和任务，包括三个要素的应对措施一般来说都是可操作的。改定上述三个实例得下。

1, 张三每双周电话联络用户代表李四

2,项目经理每周进行里程碑工期偏差估计

3,王五在6月底之前在Java工作流方面来培训新员工

风险管理中的用词问题

风险管理的重要性无需再说明，在各个领域几乎都有风险管理。
各大标准/最佳实践中也都有风险管理的内容，其中用词并不一致。在多个标准/最佳实践的导入中产生了由于用词理解不一致而发生的误解，在业界交流讨论时也多有不便。

本文列举一些，来看看中文用什么词更合适。风险管理的国际标准据说就要出来了，国内的翻译恐怕仍将是众矢之的。

• 风险，没有其它用词，但本身有二个不同含义：一种定义强调了风险表现为不确定性；而另一种定义则强调风险表现为损失的不确定性。这二个不同含义简直就是导致用词不一致的根源。现在大多数标准采用第一种定义，但停留在各级管理者头脑中的定义仍是第二种。[建议用第一种定义]
• 风险管理，没有其它用词
• 风险识别，没有其它用词
• 风险分析，没有其它用词
• 风险应对，在PMP中是指在风险识别以后到风险触发或关闭之间采取的促使风险向有利方面转化的方案和措施，在CMMI中相应的词是“风险缓解”，也有地方用“风险处置”[建议用风险应对]
• 风险应急应对，在PMP中“对某些特定事件，专门设计一些应对措施。对于有些风险，项目团队可以制定应急应对策略，即只有在某些预定条件发生时才能实施的应对计划。如果确信风险的发生会有充分的预警信号，就应该制定应急应对策略。应该对触发应急策略的事件进行定义和跟踪，如未实现阶段性里程碑，或获得供应商更高程度的重视。”，其它用词有“风险应变”，“风险应急”，一般而言，这是指风险触发后或预计必定触发后的方案和措施[建议：风险应变]
• 风险可能性，指风险发生的可能性，其它用词有“风险概率”，[建议：风险概率]
• 风险影响，指风险发生的冲击，其它用词有“风险影响的程度”，“风险严重级别”[建议：风险影响度]
• 危险性，其它用词有“风险值”,[建议：风险值]
• 接受风险，其它用词有“承受风险”，“保留风险”,[建议：接受风险]
• 避免风险，有“回避风险”，“规避风险”,[建议：避免风险]
• 转移风险，似乎没有其它用词
• 减轻风险，有“缓解风险”，“控制风险”，注意：与前文有冲突，[建议：减轻风险]
  

导入标准的两层皮问题

在公司推进各项标准建设中，难免出现两层皮的问题。 表面上符合了各项标准，实质上是另外一套，没有符合标准。
典型的两层皮做法：
1,选择少数样本在一个小的时间范围内来满足标准，应付标准检查。
2,把标准的导入看成是短期项目，认证或评估结束后恢复旧样。
两层皮产生的原因
主要有:
1, 原有方式方法难于改变
2, 标准的某些强制要求过高，而且效率低下。比如ISO27001中的软件白名单、信息资产穷举、CMMI中的代码需求双向可追溯性等等。
两层皮的后果
两层皮的后果也是不利的，本来引来标准是要有正面收益的，两层皮之后，反而是负面收益，费了很多工夫搞标准，而实质上没有改进，看起来就是在繁忙的工作 之外还要搞标准费时费力。
导致两层皮的不当理解
不当理解1：“标准导入完全是正常工作之外的额外工作”。导入标准应当是工作本身的一部分，没有导入标准, 也是要总结经验教训，下一步改进的。标准一般是某个领域的最佳实践,是前人经验和智慧的集中.
不当理解2：“这部分是标准范围，那部分不是”。本身这句话没有错, 某个标准总有其适用范围, 问题在于随意的设定标准范围, 无视标准范围真正的维度, 在适用的范围内限制标准的应用, 并美其名日:消化吸收, 拿来主义, 或是结合自身实际情况。
以CMMI为例,CMMI是软件工程多年来实践的经验总结，其范围与软件工程这门学科的范围基本一致。诚然CMMI 是有不适合范围的，主要在于个人绩效考核方面，而不在于项目类型，不在于项目参与方过多，不在于工程部门是否参与，也不在于产品还是工程.
不当理解3：搞标准就是搞文档，文档齐了就可以。听说业界的ISO9001就是顾问公司给一批文档，换个抬头，就可以过ISO9001。早期CMM引入中国的时候留下了这个印象。现在研发部的需求文档已经不是强制要求，设计文档只需要5~6 页。“用最少的文档达到业务的需要”才是CMMI的要求。
不当理解4:"通过标准的认证或评估是要达到的目标", 对于独立核算的组织而言, 利润才是目标；对于不独立核算的组织，高绩效才是目标，CMMI及其它标准 是为了达成目标的方法、手段。在过程改进中，时时保持对绩效的关注，一切改进都是为了绩效或利润。当然有些标准更加关注长远利益。
如何避免两层皮现象
管理者代表对导入各类标准的战略目标应当有准确的认识，如果管理者代表以通过某标准为唯一目标，就是为了拿张证书，那么两层皮几乎必然出现。
标准导入层在导入标准时，应对牵记绩效利润优先，切身为标准执行层考虑问题，避免利用导入标准的授权来过分显示个人或小团体的权威。在标准导入与绩效利润冲突时，对上对下要有充分沟通，在上级的支持下可以设立一些检查惩罚措施。
在标准适用范围方面慎重考虑后，与上级达成一致共识，正式宣布。在这方面虽然可以征询执行层的意见，但不能为执行层左右。
培训标准执行层的意识是标准导入的重点。从实际看，标准导入后在技术上的难点都是可以克服的，有些改变是极其简单的（比如垃圾分类，U盘登记等），技术改变的困难往往是借口，真正困难在于意识。 大多数直观的认识是导入标准是额外工作、是负担。

诱因分析的常见方法

1, 鱼骨图法 也叫石川图
在QC活动发布中，这个方法被强制使用，常说的“人机料法环”给出了一个清淅的鱼骨框架。
2,五问法
3, 帕累托法
4, 麦肯锡 MECE

组合应用以上方法可以获得更好的效果。以下提出一个实践的步骤。
1,首先选一个鱼骨图的大框架，常见的有“人机料法环”，这在QC活动中有详尽说明，
还有从过程的几大方面“输入”，“输出”，“用什么”，“做什么”，“谁”，“如何校验”来考虑。 管理类问题从“人事时地物”来划分。
2,其次，按照选定的大框架来收集信息，以MECE（穷尽但不重迭）为原则来收集各方面的客观信息。
3, 在某些方面如果有分类统计的机会，应用帕累托方法，以数字来说明主要原因。如果有假设校验（一种数学统计分析方法）的机会，应用这个更为复杂的统计分析方法，参见6西格玛。在实际工作中，应用复杂数学分析的机会其实不多，如果一个问题可以应用数据分析，反而这个问题容易分析了。
4, 对认定的事实或主要原因进行五问法分析
5, 最后结论和对策从五问法中导出

如何高效地接待现场咨询

这里指的接待现场咨询是指作为甲方来接受咨询方的服务；而不是办一个现场咨询，接受公众的提问。
在不少咨询服务中，收费是按现场时间来计算的，因此提高现场咨询的效率是很有好处的。
最近几次现场咨询中,连续看到了多次效率不高的咨询接待。先来看看低效的咨询接待，罗列一下。
1，所有似乎相关的人员（总数>10)全部出席，准备的议程不足，中间不断有人提出新的话题。
2，请咨询师点评内部已经达成共识的文件，但只有1~3个人陪同，最后也没有其他/她人员共同参与。
3，没有准备，请咨询师按照咨询师的顺序进行，要相关人员出场时，相关人员不在。

首先，如果自身对情况和相关内容不熟悉，不能在内部识别问题的话，把时间和议程交给咨询师是个不错的做法，把咨询的主要诉求提前与咨询师沟通，请咨询师安排议程和所需人员，虽然这样做效率不是最高，但至少能保证咨询的有效。如果咨询师已经在内部作过调研，比较了解的话，也会主导一个高效的咨询，当然咨询师在内部的了解是要付出成本的，而且是不小的成本。

本文的重点是如何主动的接受咨询，对自身情况有所了解、可以识别部分问题的情况下，如何来组织高效的接受现场咨询。
Entry
1, 识别咨询需要，
典型咨询需要有：

• 内部无法达成共识的地方
• 内部执行中的困难
• 推进新事物的改进方案
• 有疑虑的改进方案

2, 识别出场人员，协调时间和场地，制订现场议程
特别建议在现场议程的最后安排一个相关人员的小结会，在咨询师在场的情况下，确认达成的共识。
3, 按约定提前把相关材料发送给咨询师，让咨询师有时间做好作业
Task
1，按准备的议程进行，现场伴同人员控制时间，邀请相关人员在需要的时候出场
2，小结现场咨询达成的共识
Verify
1, 准备的议程是否全部完成
Exit
1, 咨询纪要或联席会议纪要或记录达成共识的其它文档得到发布。