IT项目干系人管理模型研究

1 背景

IT项目从最初的招投标过程一直到项目的验收结项，都会遇到这样或者那样的负面风险因素，其最终表现为项目的结果不尽如人意。有的是项目工期延误，影响了客户的正常业务；也有的是成本严重超支，超出了客户的预算；或者是质量低下，不能符合客户的应用要求。造成项目负面结果的诸多因素中，人员利益因素是其中的一个重要因素。

在许多失败的IT项目实施过程中，都会注意到与人员利益相关的现象：

组织决定启动项目，而个别部门站在自己的角度，认为新项目会“冲击”部门利益，使得部门的重要性降低、权力减少、工作过于透明等，因而对于项目的实施不配合，对项目中涉及本部门的工作消极推诿，甚或出现对项目“唱反调”等极端情形。

个别人员认为项目上线后将会对自己的利益和工作造成负面影响，因而对于项目不热心、不支持。散布项目的消极言论，在组织中夸大项目的负面影响。

项目实施过程中施工方更多考虑的是工期，而对于项目的质量缺乏足够的重视，他们关心的重点是项目什么时候结束、什么时候发放项目奖金，至于项目的质量，只要在项目验收时不出问题就行，以后的事情再说吧，现在管不了那么多
项目的各个参与方都站在自己的角度考虑问题，争取自己的利益最大化，但往往对于项目的整体利益造成负面影响。

上述的各种原因正是造成许多IT项目失败的“罪魁祸首”。在IT项目执行的过程中会遇到技术方面、业务方面的困难，但是如果参与项目的人员根本没有发自内心的积极性将项目做好、甚至阻挠项目的顺利进展，来自人员利益所造成的困难则往往造成更致命的后果。

对于成功的IT项目都具有一个共同的基本特征，那就是在项目执行的全过程中整个项目团队高度团结，开发商、客户与供应商关系融洽、彼此谅解，人员在项目执行的过程中相互帮助，充分体现了“人和”的特点。反观那些人员不团结、相互不信任、甚或勾心斗角的IT项目，一路跌跌撞撞、恶性冲突不断，即使能够勉强验收过关，后续的项目维护工作也一定麻烦不断。如果人员没有发自内心的积极性将项目做好，再好的管理方法、制度、流程也无济于事。那些严格的管理体系充其量只能确保项目的结果不至于太糟。对于杰出的IT项目结果，“人和”无疑是一个必要条件。IT项目“人和”的基础又是利益一致，为了识别项目干系人的利益是否一致，所以有必要对IT项目中涉及的各种干系人的利益进行分析并加以有效引导。

为了促进IT项目的顺利实施，本文对IT项目所涉及的各种干系人进行综合分析，并提出分析干系人的定性与定量管理模型，分别是力场分析模型与加权分析模型。IT组织在实施IT项目的过程中可以参考该模型，分析不同类型的项目干系人利益所在，对项目中可能出现的各种利益冲突加以防范和引导，从而做到未雨绸缪、防患于未然。

2 力场分析模型

IT项目干系人管理对IT项目的成败有着重要的意义，但在实际IT项目的操作过程中往往不能引起足够的重视。在绝大多数IT项目中并没有建立干系人管理的系统的方法和流程，项目经理往往凭籍个人经验对干系人进行自发式地管理，因而可能遗漏重要的项目干系人，更不用说对项目干系人的利益进行积极分析和主动管理了。

2.1 IT项目干系人类型分析

为了对IT项目干系人进行分析，首先对IT项目中通常会涉及到的干系人类型进行分析 ，不同类型干系人的特点及其关注重点如表一所示。

表一：IT项目干系人类型列表

IT项目干系人类型列表

2.2 IT项目干系人分析力场图表示及解释

力场分析法(Force Field Analysis)由美国社会心理学家库尔特•卢因(Kurt Lewin)所首先提出[4][5]。他对群体动力学以及行动研究法做出了杰出贡献，但卢因最著名之处还是他的力场分析法以及力场分析图。力场分析方法可用于分析某一事件活动所涉及的各种干系人利益并分析他们之间的相互影响。IT项目通常是一个涉及到复杂干系人的系统活动，所以可以使用力场分析方法分析IT项目的干系人利益所在以及他们之间的相互影响机制。

本文假定IT项目有自身的项目利益取向，然后采用力场分析方法分析每一类干系人的项目利益与项目自身利益的一致程度。IT项目利益取向可借助图一说明，即项目按照预定的计划达到设定的目标，包括范围目标（功能的数量）、时间目标（工期）、成本目标以及质量目标。

图一：项目管理三角形

在实际IT项目进展的过程中，是否所有干系人的利益都与IT项目的自身利益完全重合呢？或者即使干系人的利益应该与项目利益完全重合，但是因为他们自己没有认识到这一点（例如甲方信息中心），应该与项目利益一致的干系人却表现出相反的行为？所以首先对IT项目干系人利益与项目利益的重合程度进行分析，如图二所示。

图二：IT项目干系人与项目利益力场图

图二列举了上节所列出的十三类干系人可能的利益方向，他们的利益方向基本决定了他们对IT项目的态度。

甲方发起人 甲方发起人的利益应该与项目利益完全一致，否则他没有必要发起这样的项目。但在实际的IT项目管理中会遇到发起人变更的情形，这样可能会对项目的连续性造成负面的影响。所以组织对项目的发起尽可能地表现为组织行为，而非个人行为，例如发起人可能作为个人，但是他作为某个委员会（例如项目委员会或业务委员会）的代表，而不是仅仅作为个人。

甲方高层 甲方的高层通常是可以与发起人保持一致的，但正如图中的虚拟箭头所示，他们有可能会偏离项目的利益方向，例如没有对项目给予充分的人力或财力方面的支持。一种可取的方式就是将甲方的高层有意识地作为该项目的高层管理人员，让他们在项目中也承担相应的管理职责。

甲方关键业务部门 在实施IT项目之前，甲方项目的发起人和高层就要确保关键业务部门对项目采取积极支持的态度。有许多组织在实施IT项目之前并没有进行充分的IT项目业务影响分析，忽略了关键业务部门利益，因而有可能导致关键业务部门在项目实施中采取完全抵触的态度，而此时如果发起人和高层采用强行压制的方式改变现有业务流程，则会激化矛盾，造成不必要的负面结果。所以项目启动之前就应该尽量取得关键业务部门的支持。

甲方一般业务部门 一般业务部门通常没有关键业务部门对项目的作用表现得那么突出，他们通常会受到业务部门的影响。但是因为他们的业务不是关键业务，因而受到的影响或冲击也相对较弱，所以很多情形下，在项目执行的过程中争取他们对于项目的支持要更为容易。甲方信息中心 信息中心是一类比较特殊的部门。首先它们都是组织内的成本中心，所以相对其它业务部门来讲，他们的位置不会太高，对其他部门协调的能力有限；其次他们的重点是IT系统的运营维护，从IT支持的角度促进组织业务的健康发展。所以甲方信息中心的部门利益应该是与IT项目的利益是高度重合的，项目的投入使用只会使得信息中心在组织内的作用越来越重要。

甲方项目经理

乙方高层 乙方高层通常与项目的利益也应该是完全一致的，因为乙方组织都希望与甲方建立长期的合作关系，假如甲方对乙方的工作非常不满，下次与乙方合作的可能则会变得非常渺茫。所以乙方高层与甲方的发起人一样，希望项目利益得到最大程度的满足。

乙方项目经理 乙方项目经理与项目组成员在IT项目的执行过程中非常重要，因为正是由他们决定了IT项目的最终结果，工期、成本、质量和范围。但是他们的表现如何呢？这与IT行业的特点有关。IT行业的应用虽然也非常重要，例如金融、证券、政府、教育等行业，它关注到许多国计民生的应用；而反观其他的传统行业，建筑行业、航空航天、水利行业等，这些行业不但关乎国计民生，而且一旦有问题，都是人命关天的问题。

所以相对来讲，IT项目的质量后果显得不是那么可怕 。所以项目经理很多情形下对项目的质量不是那么重视，勉强通过验收就可以了。但是对于组织来说，可能需要在项目上线后投入更多的人力物力来解决前期遗漏的质量问题。所以乙方组织在项目执行的过程中确保对项目的质量进行监督。

乙方项目组成员 与项目经理类似，在许多IT项目中项目组成员对于自己所完成的工作质量并非十分重视。一方面由于IT项目的重要性所决定，另一方面也是由于在IT项目中往往不具备严格的质量责任追溯机制。所以除了加强监督机制还应该有对应的责任机制来确保人员有足够的质量意识。

乙方项目监管部门 乙方的项目监管部门通常受乙方高层委托，及时发现和报告项目中存在的问题与风险。项目监管部门的利益与项目利益完全重合，但在实际工作过程中往往会出现监管人员的业务能力或技术能力不足 ，以至于不能及时发现项目中存在的问题。没有技术背景或业务背景的人员担任监管职责，可能只是对项目的信息进行汇总再报告给管理层，其发挥的作用比较有限。

分包商 在很多情形下IT项目中会涉及到分包商。如果没有严格的约束条款，分包商可能会倾向于自己的利益最大化，例如为了节省成本而缩减项目范围或降低质量。所以对于分包商应该采取过程中控制的方式，参与到分包商的项目管理过程中，预防项目执行过程中出现问题与风险，而不是单纯地采用项目验收的方式检查分包商的工作成果。

供应商 供应商的配合情况对于IT项目的结果也有着重要的影响。设备能否及时到货？功能规格是否满足？能否提供持续稳定的后续服务与支持？因为通产供应商都是大型的IT设备供应商，所以对他们的管理要基于严格的商务条款以及包含详细规定的服务级别协议（Service Level Agreement） 。

监理 IT行业中的项目采用建立机制的并不多见，但是IT项目监理是大势所趋。IT项目监理遇到的最大问题就是没有“全才”。IT项目的行业知识与技术路线纷繁复杂，要掌握所有的知识几乎是不可能的。所以监理给甲方的报告并不一定能够反映真实的状况，极端的情形表现为监理为了体现自己的工作成绩，提一大堆无关项目痛痒的流程管理问题，而有可能忽略项目真正的业务与技术风险。所以甲方在选择监理人员一定要重视监理自身的业务能力与技术能力。

2.3 IT项目干系人相互作用分析

分析了不同干系人的利益取向以及如何使得他们的利益取向与IT项目本身利益趋同，接下来分析干系人之间如何通过有效的渠道相互作用促使IT项目的利益最大化，如图三所示。

图三：IT项目干系人相互作用图

首先说明图三的表示方法，方框中的内容为每类干系人的名称。考虑到有些干系人比较相似，并且为了分析方便，将甲方发起人与甲方高层合并、甲方关键业务部门与一般业务部门合并、甲方IT部门与甲方项目经理合并、乙方项目经理与乙方项目组成员合并。带箭头的虚线表示一般IT项目中干系人的相互沟通与报告渠道，称其为项目干系人作用渠道，带箭头的实线则强调应该重点关注的干系人作用渠道。作用渠道的名称首字母表示作用类型， A表示乙方内部作用渠道、B表示甲方内部作用渠道、C表示甲乙之间的作用渠道、D则表示需要重点加强的作用渠道；第二个字母则表示编排顺序。

一般在IT项目中干系人的作用渠道主要体现为虚线箭头所描述的内容。典型地，乙方项目经理在与甲方IT部门交互的过程中经常处于被动的位置，只是根据甲方IT部门的要求或命令行事。但是根据上文的项目干系人力场分析，他们的基本利益取向应该是一致的，这就说明乙方项目经理在于甲方IT部门交互的过程中更应该采取主动的方式，以达到共赢的目的。

在实际的项目过程中，当乙方项目经理接受来自甲方IT部门的指令——例如需求的增加、验收延期等不利于项目组的情形（见图三的CB路径），他有可能将这些棘手的问题报告给自己的管理层（见图三的AA路径），而管理层则与甲方的高层进行沟通（见图三的CA路径）争取对乙方有利的条件，由甲方的高层再协调甲方的业务部门（见图三的BA路径）和IT部门（见图三的BB路径）。这种处理模式的问题弊端有二：第一是效率比较低下，响应时间缓慢；第二在于乙方高层要说服甲方高层采取有利于乙方措施时面临较大的挑战，可能意味着额外的成本。

如果乙方的项目经理在项目操作过程中与甲方IT部门能保持更为积极主动的态度（强化图三中的DA路径），那么由甲方IT部门驱动自己的管理层（见图三的DB路径）则可能有效得多。从基本态度的角度分析，相对于乙方管理层建议甲方管理层当然更容易接受自己IT部门的建议。而这种处理方式也可以使得乙方组织在项目中处理更为主动有利的位置。所以这种处理方式要求乙方的项目经理在项目启动之初就应该与甲方的IT部门分析共同利益，建立融洽和谐的关系。

从乙方组织内部来讲，则应强化组织对项目的监督管理作用。图二的分析表明项目经理、项目组成员、分包商和供应商都有可能采取与项目利益不完全一致的工作方式，所以需要强化组织的监督作用。许多组织已经建立类似的组织（见图三的AB路径与AC路径），但是需要强调的是同时也要加强对供应商（见图三的DD路径）和分包商（见分包商的DE路径）的监督机制。需要说明的是乙方组织的监督管理可以有不同的实现方式。第一种是建立内部项目监理机制，组织在项目中派驻项目监理对项目的工作进行监督指导；第二种则由管理层定期对项目进行巡视检查，从组织的角度及时发现项目中存在的问题；第三种则是委托甲方的IT中心对项目组所作的日常工作予以确认，保证项目经理报告的工作结果的真实性。

此外，在越来越多的项目中甲方倾向引入第三方建立机制对乙方的项目执行进行监督（见图三的CD路径）。因为IT项目的特殊性，监理所报告的问题未必可能都客观真实。所以甲方IT部门要强化对监理的监督机制（见图三的DC路径），并将其与来自项目经理的信息（见图三的DA路径相比较）以确保信息的真实性和完整性。

借助于力场分析模型，项目经理可以在实际工作中更多地从人员利益的角度去考虑问题以及采取有针对性措施，确保IT项目能够最大限度符合项目干系人的利益。

3加权分析模型

通过立场分析模型可以对干系人分析进行重点分析，判断不同类型干系人利益与项目利益的重合程度，并且给出重点需要加强的干系人管理路径。为了便于在实际项目管理过程中进行操作，本节给出IT项目干系人分析的加权模型，根据加权分析模型可以动态地判断各类型干系人的利益变化情况以及项目干系人总体利益的变化情况。

3.1 加权模型的前提与假设

加权分析模型考虑每类项目干系人可能的利益取向及其影响程度，例如甲方管理层与甲方IT部门的出发点与项目利益完全重合，但因为其在组织中的不同位置、个人魅力、以及责任心等因素影响，他们最终表现出来对项目的影响程度可能会有较大的差别。所以加权模型考虑利益人的取向之外还考虑影响程度。上一节的力场分析模型已经详细分析了每类干系人的利益取向，此处对干系人的影响程度再进行分析。

根据权力模型[1][2][3]，人们对他人或事情的影响程度主要取决于如下五个方面的因素：

1. 正式权力 组织赋予个人的权利，通常在组织中有明确的职位与其相对应，例如企业中的总经理在生产运营的过程中拥有最终的决定权，他还具有对组织中其他管理人员的任免权限，而他具备这样的权利与他的个人美德、工作能力并不直接相关，因为他是企业的总经理，所以他具备这样的权力。

2. 奖惩权 可以对其他人进行有效奖励和惩罚的权力。经理可以奖励或惩罚那些他认为满意或不满意的员工，奖惩权通常与正式权力相关联，奖惩权也是正式权力的表现形式。

3. 专家权 某人对某事比其他拥有更大的影响程度，不是由于他的职位，而是因为他比组织里其他人拥有更多的知识和经验。因为他比其他人更了解组织的某种业务或技术，所以大家更倾向于接受他的意见。当然，最终表现有可能仍然是领导拍板（正式权力），但实际的决策提出人是专家。

4. 个人魅力 在组织里影响他人的另一个重要因素是个人魅力，个人魅力可以表现为感召力、对其他人的关心、待人接物的彬彬有礼、甚至是性别差异等方面。个人魅力很大程度会增强或削弱其他权力类型的影响程度。

5. 相关权 通俗的说法为关系，因为与管理层、关键决策者等人员拥有不同的联系，例如血缘关系、姻亲关系、同学关系、老乡关系等，因而对人或事情拥有一定的影响程度。

除了上述的这五个方面之外，还有一个重要的因素会影响到干系人的影响程度，所以第六个方面为责任心。责任心是人员在工作中表现出的一种态度，利益取向并不完全能够和责任心重合。有些人在从事各种工作（包括发自内心喜欢的工作）时总会表现出漫不经心的态度，而另外有些人则对所有的工作都会表现出一丝不苟、兢兢业业的态度。所以在确定干系人对IT的影响程度方面，引入上述六个方面的因素，分别是正式权力、奖惩权、专家权、个人魅力、相关权和责任心。

对于每类干系人考虑两方面的因素，利益取向和影响程度，并将其乘积作为每类干系人对项目的影响力。利益取向，用B表示，每类干系人的利益取向则用Bi表示。为了表征方便，设定其取值范围为[-10，10]。-10代表与项目的利益完全相反， 10则代表与项目的利益完全一致，0则代表与项目的利益无关，介于-10与10表示利益取向的变化情况。例如利益取向为6，则代表基本重合；而-3则表示对项目略有不满。影响程度的设定责要取决于六个因子的和，每个因子的依次用A（正式权力）、H（奖惩权）、E（专家权）、C（个人魅力）、R（相关权）、O（责任心）表示。设定每个因子的取值范围为[0，5]之间，所以影响程度D的取值范围为[0，30]之间。对于每类引子的取值可以参考如下的标准[IFPUG CPM 4.2.1]

0 没有任何表现
1 偶尔会有所表现（≤10%）
2 有时会表现出来（≤30%）
3 经常会表现出来（≤50%）
4 频繁表现出来（≤70%）
5 总是表现出来（>70%）

为了理解上的方便，对每类干系人的影响力进行百分化。设干系人的影响力为P,则某一干系人的影响力为Pi，其中，角标i代表不同的干系人。对应地，Pi=Bi*Di。其中，
D, i=（Ai+Hi+Ei+Ci+Ri+Oi）

所以Pi的取值范围介于[-300，300]之间，将每类干系人的影响力都除以3，则修正后的取值范围介于[-100，100]之间，更容易得到理解。

3.2 加权模型的使用以及结果分析

根据上述加权模型的假设，可以根据下面的表格对IT项目执行过程中的干系人影响力进行动态分析与跟踪。表二是在项目中的某一时间点所作的分析（例如每周、每月或每个里程碑），重点分析每类干系人在当前阶段的影响力；表三则强调对于干系人的整体影响力进行持续跟踪，跟踪干系人影响力在项目执行过程中的变化情况并采取对应的措施。

表二：IT项目干系人影响力分析表

表三：IT项目干系人类型列表

表三以每周作为干系人影响力的跟踪周期，每周的数据来自于表二中汇总的各项平均数据。所以表二是对每类干系人影响力的详细分析，而表三则是基于表二的基础之上对干系人整体影响力的跟踪。

基于表二对干系人影响力的分析重点集中在干系人影响力的差异分析，例如观察不同类型干系人的利益重合程度，如图四所示；或者不同类型干系人的影响力大小排序图，如图五所示。

图四：干系人利益重和度

图五：干系人影响力排序图

如要对干系人的影响力进行跟踪，则可以参照表三所提供的数据。例如对影响力在不同时期的变化趋势进行跟踪，如图六所示。

图六：干系人影响力变化趋势图

4 结论

基于本文对IT项目干系人管理模型的分析，表明对项目干系人的有效管理对于IT项目的成败有着至关重要的影响。对于IT项目管理来讲，除了要有意识地加强项目管理制度、方法与流程方面的管理，更要着眼于项目的“人和”管理。只有最大限度的发掘和调动项目干系人的积极性，才能确保IT项目最终达成满意的绩效目标。

本文依次从定性模型和定量模型两个角度探讨了如何对IT项目干系人进行分析和管理，在实际工作中可以使用其中的单一模型，例如在项目中只采用力场分析模型区分不同干系人的利益取向，或者采用加权分析的方法以量化的方式分析、跟踪干系人的变化状况。当然，以可以结合两种模型一起使用。

需要说明的是，本文所提出的加权模型是基于作者自身的经验，并不具备唯一性。在使用和借鉴模型的过程中，可以对其进行裁减或者仅将其作为参考模型。

文章来源：项目管理者联盟