项目干系人分析的“四步法”

摘要:
项目管理的首要任务就是全面识别出项目干系人及其角色!项目干系人结构图为项目经理描绘了甲方项目干系人的全景,为进一步对干系人进行分析,为更好地把握项目管理打下了一个很好的基础。作为项目干系人分析的第三步,就是需要分析出本项目干系人对项目的不同立场。按照项目的前进方向,可以得出如图三所示的项目干系人支持度分析图。

作者:卢毅

摘 要:通过结合具体实际案例分析,本文提出了一套项目干系人分析的思路、步骤和方法:首先要形成一切项目管理活动首先着眼于项目干系人的思维模式、无遗漏地识别出项目干系人,然后从干系人的重要性和支持度两个维度进行分析,最后提炼出了干系人分析坐标格这一分析工具,并得出干系人全景视图供所有项目管理活动应用。

关键词目干系人、干系人分析、干系人分析坐格、干系人全景视图

0入案例

某市财政局局长在参加了一次信息化专题研讨会以后,开始反思本单位的信息化问题:自己对局里的信息化一直很重视,每次开会都将信息化挂在嘴边,每年信息化预算和实际投入都非常大,财政局里各部门也都积极加入到了信息化建设中来。局里对信息化人才队伍也非常重视,三年前就成立了信息中心并负责信息化的工作。但目前信息化的结果却不尽如人意,各部门都分别立项建立了本部门的信息系统。财政局的收支两条主业务流程在多个独立的系统里却无法顺畅地实现,分散的信息不利于掌握全局。局长决定由某位排名较靠后的副局长负责信息化整合工作。这位副局长分析了整个项目情况后,先从某部门提拔了一位“不怕死”且有足够能力的人做信息中心副主任,由他负责信息化的具体推进工作。然后通过招投标选择了一家信息化建设合作伙伴,来完成内部信息系统整合这个艰巨的项目。假如你就是这个项目的乙方项目经理,你将如何开展工作?

1无漏地识别目干系人

很多人如果有机会做这个项目的乙方项目经理,很可能接手这个项目后,马上就会着手开展一系列工作:项目启动、编制计划,然后按照项目计划执行,中间做些项目控制工作,最后就等着项目收尾和收款了。其实,中国的项目一般都特别复杂,每个项目都会涉及很多的项目干系人,每个干系人又会顾及项目对自己产生的不同程度利害影响。因此,必须从只关心做事转移到非常关注项目干系人。项目管理的首要任务就是全面识别出项目干系人及其角色!项目一开始绝对不是忙着启动和编制计划,一切项目管理活动首先着眼于干系人!只有从项目干系人识别开始分析,才有可能将项目做成功。

作为项目干系人分析的第一步,需要先仔细识别出本项目的全部干系人。项目经理需要对项目干系人有一个全面的了解,在心中有一张完整的项目干系人结构图,以后无论是启动、计划还是执行、问题处理和收尾,都需要系统全局地思考问题,切忌头痛医头、脚痛医脚。

在项目干系人识别中,对甲方项目干系人的识别和分析更是重中之重,在本文中将重点集中在对甲方干系人做重点分析。通过对上面案例分析,可以画出一张甲方项目干系人结构图,如图一所示。

图一:甲方项目干系人结构图

在识别出项目干系人之后,还需要分析干系人之间的关系和历史渊源,如果不做这进一步的分析,会在项目过程中遇到不小的麻烦。比如在上述案例中,信息中心主任就是局长三年前提拔起来的,而且和局长的关系非常不错,只是业务能力有些不足而矣。信息中心主任很担心这个整合项目一旦由信息中心副主任做成功了,对自己今后会有很大的影响,从心理上就希望项目做不好,从行动上也倚仗局长处处对项目设置障碍。有几个部门领导对系统整合也不太支持,认为不仅剥夺了自己本部门系统的建设权,而且以后业务运作都处在领导监控之下,自然就不怎么好好配合项目了。

通过以上对干系人的识别和初步分析,我们可以看出,如果不能对项目干系人进行无遗漏地识别,仅仅关注项目具体事情和计划,项目出了问题可能都不清楚问题出在哪里了。项目干系人结构图为项目经理描绘了甲方项目干系人的全景,为进一步对干系人进行分析,为更好地把握项目管理打下了一个很好的基础。

2按重要性干系人行分析

在全部识别出了项目干系人及其角色之后,经验丰富的项目经理马上就会想到他们的重要性是不一样的,他们在项目的不同阶段对项目目标达成的影响程度是有很大差别的。按照一般项目的干系人分类方法,项目的甲方干系人主要有如下几类:出资人、决策者、辅助决策者、采购者、业务负责人、业务人员、技术负责人、技术人员、使用者等,他们的不同身份会因甲方组织的情况不同和项目的不同,将对项目产生不同程度的影响,这就需要具体情况具体分析了。

作为项目干系人分析的第二步,就是需要分析出本项目干系人的重要程度。在上面提到的案例中,只要细加分析,不难理出项目干系人的重要程度,具体分析结果可以参看图二所示。不同的人可能会得出不同的顺序,最后管理的重点也就不同了,这就更说明这一步分析的重要性。

图二:甲方项目干系人重要性排序图

通过上面的分析,我们可以看到甲方项目干系人在本项目中的不同重要程度。对比较重要的干系人,我们要对他们的全部需求做比较详细的分析,以便能更好地获得他们的支持。比如本案例中最重要的局长,说出来的需求是将信息系统整合好;没说出来的需求是最好不要否定他三年前提拔的信息中心主任,否则有领导决策错误之嫌;另外就是局长也有一些无意识的需求,如果我们能分析出来,并能以可接受的代价替局长考虑更周全,那就会让局长感动,项目也就好做多了。副局长和信息中心副主任说出来的需求也是将信息系统整合成功,但他们未说出来的需求就有些不同了。副局长未说出来的需求是希望很快能出政绩,为自己排名靠前争取更大的机会,为以后接任局长提供更大的胜算。信息中心副主任由于刚刚提拔上来,未说出来的需求自然是新官上任的第一把火要做好,这为在信息中心站稳非常重要,他自己也会全力协助推进项目的,他的“不怕死”的性格特点将会起到很大的作用。而其他人员如各部门人员和信息中心技术人员就不必花同样的力气去分析了,因为项目经理的时间和精力毕竟有限,需要重点处理好与重要干系人的关系,让他们满意甚至感动,这对项目成功将增加很多几率。

此外,还需要注意的就是有些干系人虽然不那么重要,对推进项目也起不到什么实质性的作用,但项目经理也不能忽略他们的一些需求。他们一旦对项目起反作用,利用在一些重要干系人身边并影响他们对项目的判断,后果也同样严重。所以,项目经理在分析重要项目干系人的同时,一定也不要忽略了一些不怎么重要的干系人可能的影响。(卢毅北京商略达项目管理研究中心 北京 100085)

3按支持度干系人行分析

项目干系人除了重要性不同之外,在中国现实的项目管理环境下分析,各干系人对项目的立场也有显著的不同。实际上,经验丰富的项目经理,在拿到项目的时候,都会主动与销售人员进行详细沟通,一定要先搞清楚项目干系人对本项目的支持情况。通过上面重要性的分析,我们能分辨出很重要的人,但他们是支持还是反对本项目的立场将决定他们对项目产生积极或消极的影响,这说明我们还需要对干系人的支持度进行分析。

作为项目干系人分析的第三步,就是需要分析出本项目干系人对项目的不同立场。不同的立场,最终将体现在对项目的支持度上不同。就一般项目而言,按支持度依次递减的顺序,干系人主要类别有:首倡者、内部支持者、较积极者、参与者、无所谓者、不积极者、反对者。按照项目的前进方向,可以得出如图三所示的项目干系人支持度分析图。
图三:甲方项目干系人支持度分析图

以上面的案例为例来分析,完全支持项目的就有三位,分别是作为首倡者的局长和作为内部支持者的副局长和信息中心副主任。与项目目标不一致的主要是信息中心主任,不积极的人就是有些部门的领导,因为他们在信息系统整合的过程中会受到一定程度的影响,他们不会积极参与项目中来。其他一些干系人大多是中间力量,是可以争取获得支持的对象。

在项目管理实战中,需要我们能够建立项目管理的统一战线,即为了实现项目管理目标需要争取到干系人中大部分人的支持,尤其是中间力量的支持。比较现实的做法是充分借助你的首倡者和内部支持者、积极寻求中间力量的支持、让不支持者至少不要反对!当然,这还需要“不怕死”的信息中心副主任来大力协助推动才有可能真正做到。

另外要非常重视的一点就是,干系人的支持度并不是一成不变的!有时候项目的内部支持者可能会因为各种原因在项目进行中逐渐演变成项目的反对者,也有些项目关系人前期是反对者,到后面却逐渐对项目进行支持。随着项目的推移,情况在不断变化,各干系人的支持度也必将发生变化。因此,项目经理需要动态调整项目干系人支持度分析图,及时分析并修正各干系人的支持度,以便灵活应对项目的各种新变化。

4目干系人分析坐

在上述项目干系人分析的前三个步骤里,依次做到了无遗漏地识别出全部项目干系人、对干系人的重要性进行分析和对干系人的支持度进行分析。这些分析都是从一个维度对干系人进行了分析,对我们提高项目管理水平非常有价值,为成功地进行项目管理打下了很好的基础。但前三步的分析结果往往不是孤立的,一般都交织在一起,所以还有必要在前三步的基础上对项目关系人进行整合分析,形成对干系人的完整分析。

作为项目干系人分析的第四步,就是需要将全部项目干系人放到项目干系人分析坐标格里的合适位置。项目干系人分析坐标格是作者根据项目管理实战体会总结出的一个项目管理干系人综合分析的简单实用分析工具,具体如图四所示。项目干系人分析坐标格的纵轴是项目干系人对项目的重要性,分为高、中、低三个等级,具体分析思路在第二步里有详细说明。项目干系人分析坐标格的横轴是项目干系人对项目的支持度,分为支持、中间立场、不支持三个等级,具体分析思路在第三步里有详细说明。由这两个维度就组成了如图四所示的九个分区:A1、A2、A3、B1、B2、B3、C1、C2、C3。
图四:项目干系人分析坐标格

相信读者到这里,已经可以自己将本案例里在第一步里分析出的每个干系人放到项目干系人分析坐标格里的对应位置,在这里就不详细说明了,请读者自己完成。下面以本案例的验收和收款为例,来说明一下项目干系人分析坐标格的应用方法。按惯例,验收和收款的审批步骤是:信息中心副主任(位于坐标格A2,提出报告)—→信息中心主任(位于坐标格C1,第一次审批)—→副局长(位于坐标格A1,第二次审批)—→局长(位于坐标格B1,最后审批并同意付款)—→副局长(位于坐标格A1,第二次签批付款)—→信息中心主任(位于坐标格C1,第三次签批付款)—→信息中心副主任(位于坐标格A2,办理付款)。通过项目干系人分析坐标格的提示,本案例显然曲折地经过了长达一年多的项目实施,但按正常的流程,虽有信息中心副主任和副局长的支持,但乙方很难顺利验收和收款。原因就是信息中心主任的验收报告审批和签批付款两个环节过不了,项目干系人分析坐标格显示信息中心主任位于坐标格C1,立场是不支持的,事实也证明惯例流程确实行不通!

项目干系人分析坐标格的好处就在于可以提醒我们哪些环节会有问题,哪些环节会对我们有利。本案例最后顺利验收和收款的可行步骤是去掉了惯例中的前两个环节,设法绕过了第二步这个障碍和克服了第六步障碍,步骤变为有非常重要的副局长直接发起,即副局长(位于坐标格A1,直接审批)—→局长(位于坐标格B1,最后审批并同意付款)—→副局长(位于坐标格A1,第二次签批付款)—→信息中心主任(位于坐标格C1,没有办法只得签批付款)—→信息中心副主任(位于坐标格A2,办理付款)。

也许有人对以上分析的干系人坐标格有不同意见,其实没有关系。如果你分析每个干系人的坐标格不同,那么相应的处理方法也就不同了。笔者最后借助干系人坐标格这一工具,用上述流程成功验收和收款了,就用事实证明是可行的方法之一,也许还会有其它更好方法需要我们研究。
5 结论
经过以上四个步骤对项目干系人顺序地分析以后,我们可以将案例中的每一个项目干系人对应在项目干系人分析坐标格里的对应位置,这样就形成了一张完整的项目干系人全景视图。这张完整的项目干系人全景视图,在项目的每个阶段里、在解决每个项目具体问题时、在项目沟通管理和风险管理等方面都能发挥重要作用!这些还需要另外专门具体详细分析和灵活应用,不是本文讨论的重点。

本文的重点在于提出了一套项目干系人分析的完整思路、步骤和方法,用来帮助大家提高对项目干系人的分析和管理水平、提高项目管理的境界。项目干系人全景视图可以应用于所有项目管理活动,相信对正确分析项目干系人有很大的帮助。当然对项目干系人分析的目的是为了更好地做好项目干系人管理,以便在复杂多边的环境里能顺利地达成项目管理目标。至于如何恰当地应用好项目干系人全景视图,笔者以后还将专门撰文阐述。(卢毅北京商略达项目管理研究中心 北京 100085)

(本文发表于《项目管理技术》杂志2006年11月,作者联系方式:luyi@tsinghua.org.cn)

免责声明:文章转载自《项目干系人分析的“四步法”》仅用于学习参考。如对内容有疑问,请及时联系本站处理。

上篇Verilog中的标点position fixed 居中下篇

宿迁高防,2C2G15M,22元/月;香港BGP,2C5G5M,25元/月 雨云优惠码:MjYwNzM=

相关文章

TOGAF架构内容框架之架构制品(上)

TOGAF架构内容框架之架构制品(上)4. 架构制品(Architectural Artifacts)       架构制品是针对某个系统或解决方案的模型描述,与架构交付物和构建块相比,架构制品既不是架构开发方法过程各阶段的合约性产物,亦不是企业中客观存在的各种可重用解决方案,而是针对包括这些构建块在内的企业客观现实的描述,并以解答不同干系人的关注点为其最...

PMBOK概要(九大知识体系与五个具体阶段)

 早期的项目管理主要关注的是成本、进度(时间),后来又扩展到质量。最近十几年间,项目管理逐渐发展成为一个涵盖9大知识体系、5个具体阶段的单独的学科分支。9大知识体系包括:    集成管理 在项目分析中,项目管理人员必须把各种能力综合起来并加以协调利用。    范围管理 定义项目的边界,着眼于“大画面”的事物。例如项目的生命周期、工作分工结构的开发、管理流...

外包软件项目管理要抓住关键点

外包是发包方和接包方互相信任、高度协作的共同行为。为了顺利实施外包,对于发包方,要求企业具有一定的技术水平、项目管理水平、人力资源和沟通控制能力。对于接包方,要求企业具有一定的成本、质量控制能力,具有国际市场开拓能力(包括业务能力、交流能力、接包渠道和商业信誉等)。为了是外包服务形成产业化,还要求形成良好的政策环境和市场环境等。 下面以软件项目外包为例,从...

数据库软考易混淆知识之信息化基础、项目管理

一、进度安排常用图 1、Gant图:用水平条状图描述,以日历为基准描述项目任务,可以清楚的表述任务的持续时间和任务之间的并行,但不能清楚的描述各个任务之间的依赖关系 2、PERT图:是一种网络模型,描述一个项目任务之间的关系,可以明确表达任务之间的依赖关系,即哪些任务完成后才能开始另一些任务,以及如期完成整个工程的关键路径,但是不能很好的表示出各个任务之间...

持续测试 | 测试流程提效:在 CODING 中实践迭代内的持续测试

本文作者:程胜聪 - CODING 产品经理 持续测试带来的变革 持续测试(或者敏捷测试)要求测试作为基础活动贯穿于软件交付的整个过程中。相比起在 DevOps 时代陷入困境的传统测试模式,持续测试首要改变的是“测试后置“的状况,强调测试前置,通过尽早定义测试、测试与开发并行、在过程中保持紧密协作,从而实现快速反馈业务风险的目的。持续测试的实践变革是关于人...

软件项目开发流程以及人员职责

实行软件工程项目管理: ▲ 项目经理(负责人):项目经理(负责人)对整个项目负完全责任,是指导、控制、管理和规范某个软件和软/硬件系统建设的人,项目经理(负责人)是最终对客户负责的人。 ▲ 软件项目经理(负责人):软件项目经理(负责人)对一个项目的所有软件活动负完全责任,控制一个项目的所有软件资源,按照软件约定与项目经理(负责人)打交道。 ▲ 软件工程组:...