在项目管理过程当中, 如何通过监控项目干系人的行为来多维度评估干系人的风险？
金融行业会有反洗黑钱的部门，这些部门专门针对不同的客户身份和行为进行反洗黑钱的监控和汇报。而了解你的客户(Know your clients) 和客户尽职审查(Clients Due Diligence)，在很多金融机构都有广泛的应用。
比如你想要去银行开户的时候，银行会通过各种手段去了解你的个人信息，你的房产，收入来源，信用记录，月度平均资金量，甚至负面新闻等等。只有你提交了这些信息，银行才会让你开户并且通过系统算法给你风险评级和打分，将你分类为高，中，低三类风险客户。
这一部分是为了了解你的客户/客户尽职审查。当你真正开始进行存款，转帐，投资之类的交易的时候，银行就会持续性的监控你帐户里面发生的所有交易，一旦有可疑交易，系统就会自动触发警报并且通知反洗黑钱部门的员工去调查这笔交易并且采取相应的风控措施。
今天这个主题，就是受到客户尽职审查和交易监控的启发。
在项目的一开始，我们需要识别干系人，制作干系人的权利/利益矩阵，然后根据干系人的权利/利益给干系人分类，最后制定控制干系人的策略。
银行的客户尽职审查其实就等同于我们项目管理中的识别干系人的过程。而交易监控就是项目干系人的行为监控。
在项目管理中，我们经常谈到风险管理，比如范围蔓延，成本超支，进度延误，通常都是从事件角度来谈论风险管理。却较少听到针对干系人角度来讨论风险。
本质上，项目中所有事件都是人触发的，就好像我们在银行的交易一样，本质上银行不是在监控交易，是在监控我们人的行为。
虽然项目经理没有技术能力和资源去像银行那样，通过大数据，各种算法来精密的进行风险评级和交易监控。但我们可以尝试将干系人进行风险分类，构建一个大概的干系人轮廓。然后根据一定量的数值将每个干系人的风险行为进行综合的全面评估和量化打分，从而可以预先对我们项目经理可以产生一种预警机制。
如果我们能够及时针对人产生的风险进行干预，那么我们是不是距离项目的成功迈出很大的一步了呢？
接下来我会以一个银行的软件开发项目代入，来展示给大家看我是怎么做的。
假设我是一个弱矩阵的项目经理。刚刚接手了一个战略性的大型项目，干系人特别多，已经识别完毕干系人。
为什么是弱矩阵？因为弱矩阵项目经理对于人的管控要求更高。
PMP里面把干系人按照权利/利益矩阵分类。很多项目经理都知道这个矩阵，但是这个项目那么多人，在实际情况中，具体我们是从什么角度把这些人代入这个矩阵呢？
第一个就是高权力高利益。大家想一想什么样的干系人符合高权力，高利益？除了客户方发起人以外，只要是管理层的就一定是高权力。那高利益呢？只要是这个项目的1线干系人的管理层就都是高利益。
因为如果这个战略性项目做的好，老板们得到的利益自然是比我们这些冲锋陷阵的员工多很多的。所以这一层面，可以是项目经理管理层，产品经理管理层，测试部门管理层，甚至是客户方发起人的老板。
总结：高权力高利益的人通常是1线干系人管理层。他们不但是高权力，高利益，而且是高风险干系人。PMP里面有说到，这一类人项目经理就必须重点关注。
第二个是高权力低利益。我称其为18线干系人管理层。而这一层通常也是老板和管理层，只不过他们是非关键干系人的管理层，非关键关系人管理层就是项目当中一些临时性，支持性的干系人。
假设项目经理在项目进行中，对于某个政策不够了解，于是就临时找到一个制定流程的部门请教。再比如对于一些相互有接口的系统，开发团队需要去向其他部门请教关于这个接口的问题。
而这些支持性部门的管理层其实相对来说，他们或许在其他的项目中有着直接的利益，但在我的项目中，其实是没有什么利益的。我把这一范畴的干系人归类为中风险干系人，那为什么不把他们分为低风险干系人？因为他们好歹也是管理层啊，要是有什么意外情况，或者他们哪天吃错药了，给我们制造点波澜，对项目，对项目经理而言也是影响蛮大的。
总结：PMP里面有说到，高权力低利益的人人项目经理就必须令其满意，言下之意就是不满意，后果很严重。
第三，是低权利高利益。很不幸，项目经理就落在这一个范畴，不止是我们，所有一线干系人，也就是所谓的基层都属于这一个范畴。
项目中各个部门中你的首要对接人，一起共事的那个人就是属于这一层。
为什么我们属于高利益呢？难道就像我之前说的项目成功实施之后，管理层可以拿到很多利益那样吗？当然没那么好的事，这里的高利益意思就是我们是关键干系人，我们这些人是和项目成功失败紧密相连的，成也是我们，败也是我们，不得有任何闪失。并且，我们也都是高风险人物。
最后一个就是低权利低利益。跟高权力低利益遥相呼应，临时给我们提供支持，帮助，而不直接参与我们项目的干系人。也许这些人在其他项目里面是1线，但我的项目里就是18线干系人。很明显，这个范畴的人是低风险干系人。
以上，就是真实项目中把干系人分成了高，中，低三个风险级别的示例。
我们项目经理在管理项目的过程当中，最让我们心烦意乱，头疼的就是干系人表现出的各种各样的负面的不利于项目推进的行为。
大家回忆一下，是不是很多时候，我们心里经常会吐嘈↓↓
“A怎么总是在开会的时候迟到早退，一点纪律性也没有。”
等等等等，反正项目中人越多，诸如此类的负面行为就越多，让我们这些项目经理开始怀疑人生。
对于这样的问题，没有经验的项目经理就开始一团乱了，反正就是感觉心累，真的推不动了。
而有点经验的项目经理呢，虽然不至于手忙脚乱，但也只是凭经验去兵来将挡，水来土掩，最多就是记住这类有“前科”的人，心里留个神而已。
假设是一个比较小的项目，就那么几个人，然后里面有一个人经常迟到，另一个人经常延误交付，其他人都表现的很正常，那我们项目经理完全有时间去一对一想解决方案。
但是如果这是个巨大的项目，里面有一大堆的干系人在同一阶段表现出不同的负面行为，比如，干系人1经常迟到早退，干系人2喜欢推诿责任，干系人3喜欢延误，干系人4经常联络不到，干系人5……
在这种情况下，就算是有经验的项目经理工作效率也可能会降低，因为他们的大把时间可能都要花在跟这系人斡旋上了。
在我曾经做过的银行项目中，我通常会以以下几个主要指标来给干系人做风险评分，每个指标赋予权重，最后相乘。
初步风险层级 – 一开始我把所有干系人分为高，中，低三个风险级别
行为模式- 通过你在项目进行当中的体验和感觉，把干系人的行为模式记录下来。这是一个动态的过程。行为模式没有办法量化，但是以我的经验，每个不同的干系人都会有反复出现，符合个人性格特征的行为出现。我们可以针对一个干系人列出1-3条主要行为模式。
行为模式频率 – 分成高，中，低，如果某个干系人连续3次，或3次以上展现同一种，或者类似的负面行为。则视为高频率行为模式。
影响阶段 – 这个指标很重要。在软件开发的项目中，干系人处在不同的项目阶段，对于项目的影响是不同的。如果一个人的职责是贯穿整个项目的，那么他的负面行为对项目造成的杀伤力比那些只出现在某个阶段的人要大得多。反之，即使某个人有不少负面的行为，但是他只出现在项目很前期的阶段，那么他可能不能被视为是个高风险人物。
员工级别 – 初级员工更容易犯错和不专业，所以风险权重就比中级，和高级员工更高，
管理层？– 如果一个干系人是高权力高影响力的管理层员工，那么他的风险权重会比普通员工高。
一线干系人- 如果一个干系人是和项目紧密相连的一线干系人，那么风险权重会更高。
前端系统干系人- 这是一个IT软件开发的指标，比如银行的系统是分为前端和后端的。前端即网银，手机银行，ATM，柜面之类直接和客户接触的高风险系统，因为一旦这些系统出了问题，会直接影响到客户存钱，取钱，转账。所以如果这个干系人是一个前端系统的开发，那么他的风险权重要比后端的开发人员高很多。
总风险评分 - 如果调整这些风险指标，就会发现不同的搭配，对应的风险权重也会变化，最终算出一个评分。评分越高，这个干系人就越值得被关注和监控。
当然，其实根据不同的项目，还有一大堆次要指标，在这里我就不复杂化了。所以上面只是我给大家提供的一个简单的参考。
显然，即使干系人存在某项负面行为模式，但不代表他的风险评分会很高，需要结合其他指标来综合考量。
而这些指标都不是固定的，干系人在项目中的无论行为，还是各种指标，都不是一成不变的，比如，一个高风险的干系人，过一段时间就不一定是高风险了。一个干系人最近负面行为模式高发，但是到了之后很长一段时间就变低或不存在了。这些都是需要我们动态的监控和调整的。每个不同的项目经理都可以根据各自的行业和项目环境来自行剪裁或者增加，赋值权重。
在项目开始前，项目经理可以把这个风险评分工具纳入到风险管理计划当中，预先就制定好初始的应对方案。
1.将一大批不同类型，不同职权，不同利益影响的干系人分为高，中，低三个初始风险类别，这样做就直接将干系人的风险类别化。
2.动态监控，方便项目经理直接调整或者代入各种指标和参数。引入各类风险指标，定义风险权重，多维度综合计算干系人的风险评分，直观的用数字显示。
3.直观的显示项目经理应当干预干系人的优先级。避免项目经理用单一因素去衡量和干预干系人的负面行为。节省项目经理的时间，提高工作效率。
也许有人会问，风险评分有什么意义呢？只是一个数字而已。一个数字是没有意义，但是一旦干系人多了，项目经理一眼就可以看到哪些人是高危人物，哪些人应该被及时监控和制定措施管理。这样可视化的评分，也可以让项目经理迅速知道在某个阶段，应该投入多少精力和时间放在哪些人身上。
所以，我认为，项目干系人的风险评分的思维，对于项目经理，尤其是新人项目经理，是能提供相对更全面的评判干系人风险的工具的。
优培东方送你一张干系人管理策略：
干系人管理策略
项目名称： 准备日期：
第1页/共1页
首页>
粤公安备案 44010602008731号