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

2007-03-28 13:58

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

关键词：项目干系人、干系人分析、干系人分析坐标格、干系人全景视图 导入案例

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

1. 无遗漏地识别出项目干系人

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

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

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

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

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

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

2. 按重要性对干系人进行分析

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

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

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

这对项目成功将增加很多几率。

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

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. 结论

经过以上四个步骤对项目干系人顺序地分析以后，我们可以将案例中的每一个项

目干系人对应在项目干系人分析坐标格里的对应位置，这样就形成了一张完整的项目干系人全景视图。这张完整的项目干系人全景视图，在项目的每个阶段里、在解决每个项目具体问题时、在项目沟通管理和风险管理等方面都能发挥重要作用！这些还需要另外专门具体详细分析和灵活应用，不是本文讨论的重点。 本文的重点在于提出了一套项目干系人分析的完整思路、步骤和方法，用来帮助大家提高对项目干系人的分析和管理水平、提高项目管理的境界。项目干系人全景视图可以应用于所有项目管理活动，相信对正确分析项目干系人有很大的帮助。当然对项目干系人分析的目的是为了更好地做好项目干系人管理，以便在复杂多边的环境里能顺利地达成项目管理目标。至于如何恰当地应用好项目干系人全景视图，笔者以后还将专门撰文阐述

项目干系人之需求调研分析中的项目干系人概念

2007-03-28 13:49

摘要：根据调查，属于需求分析和软件设计的错误和缺陷约占软件错误的64%，而属于程序代码的错误仅占36%。因软件错误的积累与放大效应，造成整个软件业项目拖延的情况高达20%到60%。这些数据表明搞好需求调研分析及软件设计是提高软件质量的基础。以下是一些通过全面了解所有项目干系人的需求改进需求调研分析效果的体会。

关键字：项目干系人、需求、调研

在需求调研分析阶段，项目组对客户的整体组织结构、有关人员及其关系、工作职责等没有足够了解以致于无法得到完整需求或最终经权威用户代表确认的需求。由于项目经理和需求分析员的工作问题，客户参与程度部不高，客户方相关责任人不明确或对范围和需求责任心不强，提出的需求具有随意性，项目前期对需求的确认不够积极；或者是多个用户代表各说各话、昨是今非但同时又希望软件尽早交付；项目后期需求变化随意，造成项目范围的蔓延，进度的拖延，成本的扩大。

造成上述现象的原因是系统分析人员没有全面了解所有项目干系人的需求，并按照重要性优先级进行权衡取舍。全面的需求来自所有项目干系人。项目干系人STAKEHOLDER也有的翻译成利益关系⒗叵等恕⒗娓上等恕⒗婀蚕碚摺⑸嬷冢绱说鹊龋此锌赡苁艿较钅拷峁卮笥跋斓娜恕Ｏ钅扛上等思纯赡苁窍钅康氖芤嬲撸彩窍钅康姆缦粘械Ｕ撸踔劣锌赡苁窍钅康氖芎φ摺Ｏ钅扛上等说男枨蟀魅返暮鸵模部梢苑治狽EED、WANT、WISH等不同层次。

不同的干系人其愿望和追求的目标往往相差甚远，因此对项目干系人的愿望进行平衡可能是相当困难的事情。例如政府部门准备建设的不少对群众办公的信息系统，上层管理机关往往希望能够采集尽可能多的信息项以便对数据进行多种多样的统计分析，同时为了对信息进行有效控制而增加一些审批流程；基层对外办公的窗口则因为办公速度的压力希望减少信息项的输入量；甚至有些不良的基

层客户由于害怕建立透明度高的信息系统会影响他们的工作考核成绩而消极地应付，即所谓反需求；而客户的客户（办事群众）则希望相关政府机构能够简化工作流程，加快办事速度；一些客户相关的管理机构或组织也会制定一些有关的标准规范；作为项目干系人的公司领导层也可能会提出一些技术上、接口上、环境上的需求；甚至项目组本身因为技术、资源、进度等原因，需要对一些功能进行优先级排序和取舍。虽然不是所有人的需求都是可以满足的，特别是消极的反需求是不能接受的，但他们的需求都是应当考虑全面并进行平衡的。

软件开发项目的目的就是实现项目干系人的需求和愿望。如果对项目所有干系人没有进行足够的沟通和影响，使其尽可能地参与项目，则可能因为项目开始时项目范围和一些具体需求不够完整清晰，也可能因为某个项目干系人后期因为认识的变化而提出新的需求，造成工期的延长，成本的增加，甚至项目的完全失败。因此，应当从项目的启动开始，需求分析员及其项目成员就要分清项目干系人包含哪些人和组织，通过沟通协调对他们施加影响，驱动他们对项目的支持，调查并明确他们的需求和愿望，减小其对项目的阻力，以确保项目获得成功。以下是一些有效的措施：

1、尽快熟悉项目干系人全貌

有些项目在做需求调查时，由于受进度要求等客观因素影响，需求分析员与建设单位的技术部门交流较多，向业务管理部门和实际使用者调查不够深入，造成软件试用后不得不再对需求做较大调整，"从头再来"的部分比例很高，大大超过进度要求时间。因此，熟悉项目干系人全貌是进行需求调查的第一步，也是需求调查的基础。在定制开发项目的项目干系人中，最重要的是建设单位中的人事组织、业务关系。最好是能够用组织结构图画出相关单位的组织结构；用责任矩阵确定各部分的调研对象；建立调研对象通讯录以保证调研及分析期间及时的沟通。与此同时要注意项目干系人的主次关系，以便在他们之间的需求出现矛盾时能够进行合理的取舍。

熟悉建设单位内部相关部门的业务划分及它们之间的相互关系,为功能分析准备了必要的资料, 同时可以熟悉用户方的各类人员，并及时进行广泛、有效的沟通与交流。特别要与客户方业务与技术的规划者和实际使用者进行深入探讨，收集必要的原始资料，保证需求调查的完整性、正确性。

建设单位只是项目干系人中的一部分（当然是主要的部分），为了更好地了解项目干系人全貌，还应当在建设单位组织结构图基础上全体项目干系人结构图，以便更好更全面地进行需求调研分析。

2、详细描述各项业务，以利于让所有客户确认

尽可能全面详细地调查并且描述原有系统和用户希望将来系统具有的各项业务的流程，并将这些业务流程文档化后与客户进行讨论，对描述错误或不准确不精确的进行修改，最终让客户进行确认。从近年来开发的软件看，对业务处理过程了解的完整性和准确性非常重要。虽然对数据来说都是SIDUT（查增删改传），但具体业务都是分为若干步骤，每个步骤都有其业务名称，同一步骤可能对多个

数据集进行不同操作，需要调查了解清楚才能设计出适合各流程业务节点用户业务特点和习惯的软件，使开发出来的软件更受欢迎。当然在进行软件概要设计时，要尽量排除业务流程的制约，即把流程中的各项业务结点工作作为独立的对象，充分考虑他们与其他各种业务对象的接口，在流程之间通过业务对象的相互调用实现其业务流程，这样，在业务流程发生有限的变化时，就能够比较方便地修改系统程序而实现新的需求。

对于各项业务的调查可以通过对以下资料的收集整理分析，这些资料来自各种各样的项目干系人：遵循的标准、组织发放的工作手册、作业流程、有关业务的上级通知、有关业务的办事指南、办理业务时需要填写的登记表、各种相关的统计报表及通过其他途径收集的类似系统的介绍、技术资料等等。

3、可视化需求调研，引导各种客户挖掘他们的需求

有的客户因为自己缺乏计算机知识，无法提出完整准确、隐含的或潜在的需求。但若这些需求不能满足将导致用户的不满。因此需求调研分析人员应善于想用户所想，不但要确定明确的需求，还要善于用启发的方式与用户探讨隐含的或潜在的需求，并结合各种调研分析技术挖掘超出客户期望的令人兴奋的需求。这就要求需求调研分析员要尽快完整地熟悉相关业务，从而能够站在用户的立场看待软件需求，想用户所想，做好业务与计算机之间的桥梁。利用可视化需求调研的方法可以很好地启发用户深入挖掘潜在的需求。可视化需求调研就是使用图表等工具来启发引导用户清楚地叙述需求，并且使需求更加全面完善。

对于高层领导，可以提供系统总体框架图；对于业务管理人员，可以用业务流程图来描述新旧系统的业务流程；对于客户中的技术人员，可以用数据流图、实体关系图或UML中的各种图形对系统进行各种角度的描述；而对于业务管理人员、客户中的技术人员、以及各层次各流程中的用户，画出用户界面图来进行需求挖掘，是个比较有效的沟通方式。

这里特别说明一下用户界面的重要性。用户界面的设计按理来说是软件设计的责任，当然客户自己对界面有特别提出要求的除外。但是，如果把它提前到需求调研时（紧接着原有系统调研分析和系统模型完成之后）与客户进行讨论，则可以大大改善需求调研的效果。因此不少需求分析的著作把用户界面说成是“设计层”的需求之一。因为这时客户对于将来的系统还没有一个形象上的概念，或者有一个模糊的预想的概念需要表述、验证、明晰化、完善化。以笔者的经验，画出用户界面草图与客户进行讨论，可以大大激发他们提供更为准确全面的需求。原来收集资料，描述业务，说明系统模型到了山穷水尽的时候，这种方法可以达到柳暗花明又一村的效果。在《微软项目：求生法则》的第8章“需求开发”中，从头到尾都是围绕着“使用者接口”（USER INTERFACE也可以翻译成“用户界面”）进行讨论，如“建立简单的使用者接口雏形”、“不断修订使用者接口雏型，直到使用者对软件感到兴趣盎然为止”、“完全扩展使用者接口”，同时还要“区分一份非使用者接口需求文件”，等等。因此，所谓需求就是“当你按下各种相关按钮（或输入各种相关命令）时系统做什么”，所谓设计就是“当你按下各种相关

按钮（或输入各种相关命令）时系统怎么做”。虽然在英语中“接口”与“界面”实际是同一个单词，但“接口”的含义似乎比“界面”来得广泛，如功能之间的接口、与其他软件的接口、与其他硬件的接口等等。需求的最终目的实际上是完整准确地描述系统需要的各种接口或“界面”，及它们的相互关系或与外部环境的关系，如界面中的某个按钮按下去时，可能产生新的界面、新的按钮、或者调用其他软件硬件完成某些功能。自顶向下，把这些界面及涉及到的数据描述清楚，就是一份不错的需求。

4、与其他项目小组成员共同协作、持续完善系统需求

需求文档完成之后，并不是万事大吉，把它扔给后面的设计人员就了事了。作为项目干系人之内的项目组其他成员，对需求的有效性也起到某种程度的验证作用。虽然软件项目的生命周期按照各种开发模型有不同阶段的划分，但每个阶段的结束不是简单地把阶段工作成果塞给下一阶段的成员就可以了。特别是高科技的软件开发项目，上一阶段的工作成果往往要通过多次的沟通才能更为清晰地被下一阶段成员接受，其有效性、合理性也要被下一阶段的工作所检验，通过检验有时也有必要对上一阶段的工作结果进行相应的调整，需求更是如此。因此，无论是同一阶段不同人员之间，或是不同阶段人员之间都应根据需要相互协作，相互配合，共同完成软件开发任务