3.4 都是婆婆——认识项目干系人
在清理外部系统接口的时候，小M遇到了不小的麻烦。
部分老系统在新系统上线之后仍将被保留。但是，为了界面一致性，需要将保留功能的界面用新系统重新开发，方便用户操作和培训。
为了重写这些老系统的功能界面，需要原来的设计文档和接口资料。但是，负责老系统的厂商D与小M的公司存在着竞争关系，而且新系统上线之后厂商D的系统会被逐步取代，对工作自然不支持，因此以技术保密为借口拒绝提供设计文档，仅提供了最初的客户需求文档和接口标准。如果没有设计文档，就无法知道操作流程和页面栏位的控制关系，只能仿制页面的样子先做出来，再一遍一遍地去试验。这样的方式进度极其缓慢，几乎无法完成工作。
小M找到了G总寻求帮助，G总表示会出面协调。但等了几天没有进展，多次催问之后，G总表示因为D公司是竞争对手，所以没法帮忙了。
小M觉得项目中婆婆太多了！没想到还会碰到自己的竞争对手，这的确是件麻烦的事情。该怎么办呢？
3.4.1 项目的组织关系
项目的组织关系挺复杂的，其实小M一直都想整理一下，看看内/外部有哪些主要的角色，他们主要职责是什么。小M对照着项目中的具体部门和人员画了一张草图，将他们之间的汇报关系和沟通渠道标示了出来，如图3-7所示。
项目中主要人员和客户的人员组成，见灰色的部分。这些成员来自不同的部门。
这个项目的用户实际上是各个业务部门，他们直接提出项目的要求，并最终使用项目的成果实现业务目标。但在客户内部，这个项目由信息中心负责；为了便于管理，信息中心任命了甲方项目经理G总。
G总原来是信息中心主管开发的副主任，代表客户对项目整体进展和结果负责。他直接向信息中心主任汇报，项目中的重大事项甚至直接向总裁汇报。G总带领信息中心一部分开发人员共同参加了项目组，还负责领导多个部门的业务骨干。项目中的需求确认、验收测试、用户培训、系统实施等许多工作，都是由G总的团队承担的。
从公司角度来看，项目经理是小M，平时的汇报途径一是公司内事业部总经理S总，二是客户方G总和信息中心主任。S总与客户的信息中心主任关系比较好，一直保持着密切的沟通。
G总和信息中心主任向客户方的总裁汇报。这个项目就是总裁批准的，也是他一直在推动的。尽管总裁不关心项目的细节，但是经常直接过问项目的进展，并为项目组从各个部门协调资源。
S总向公司的CEO汇报，一般情况下如果想与客户方总裁沟通，需要通过公司的CEO。
项目组中的公司内部员工，有来自事业部的顾问和技术人员，还有是来自产品部门的支持人员。他们有自己的部门经理，但在项目执行过程中对小M负责，按要求完成任务后就可以离开项目。
除了这些角色，项目中还有很多合作厂商。一些合作厂商是客户直接的采购对象，另外一些是小M的采购对象和支持伙伴。因此，一部分伙伴通过公司联系，另一部分通过客户联系。
问题是，厂商D不属于项目的伙伴和供货方，而是信息中心的供货方。信息中心的另一位副主任负责与厂商D联系。
3.4.2 项目打破了组织的平静
如果说组织原来是一池平静的水，项目就好比一块石头，不仅会改变组织的结构和流程，而且重新分配了人员的利益和权力。自然有些人是受益者，有些人是“受害者”。
小M了解到，这个项目是一把手主抓的项目，是客户业务转型的重要举措，对客户来说意义重大。信息中心主任当着一把手的总裁立下了军令状，G总也是总裁点的将。
G总虽然面临着很大的压力，在新系统上线之后他的团队将承担运维和升级任务，客户内部都认为他是信息化的“明日之星”，因此其团队积极性很高。
而负责旧系统运维的人员，新系统上线后有些会逐步转到新系统运维团队中，而有些人到底今后怎么安排现在还不明确，负责与厂商D联系的那位副主任就是这种情况。
虽然他负责老系统的维护，但是新系统上线之后前途未卜，对于这个项目自然有一些抵触情绪。而厂商D本来就是竞争对手，更不可能支持这个项目，因此想推动他们帮助解决问题自然十分困难。
现在的情况比较清楚了，但矛盾和困难的事情是需要推动抵触项目的组织，为项目做事。
3.4.3 婆婆也能帮你
从组织关系上分析，要想解决问题必须通过信息中心主任。小M与G总商量，希望向信息中心汇报这件事情。厂商D在信息中心还有其他的业务，不会为了这样一点事情得罪信息中心的主任。另外，建议G总从信息中心调集一名懂原有系统开发的人员，如果真的拿不到文档，至少有人能说清楚是怎么回事。
G总同意这样的安排，并说自己的一个下属原来就是负责老系统维护的，也非常愿意进入这个项目。但他自己不太愿意出面进行汇报。一方面，负责老系统运维的那位副主任是自己的老上级，因为这个项目G总提升了，变成了他的平级；项目启动之后又从他那里调集了很多人，对他的工作造成不小的影响，本身就有点过意不去；如果继续从他那里要人，还要指责他负责联系的厂商D不支持项目，恐怕会影响两个人之间的个人关系。
小M完全能够理解G总，自己没有什么人际关系的负担，于是提出可以从项目角度直接反馈问题。但是自己直接找信息中心主任好像级别不够，有点犯憷。突然想到自己的上级S总与信息主任关系不错，也许他出面可以帮助解决问题。
小M向S总汇报了事情的原委，并希望得到支持。隔了一天，S总反馈已经与信息中心主任谈过了，会解决问题的。很快，信息中心主任就找到了小M和G总了解情况，并要求小M提交一份书面报告。
第三天，G总告诉小M，在信息中心主任主持的工作例会上，讨论了小M的报告，信息中心对此事形成了几点决议：
再次重申了项目的重要性，各个部门必须全力配合。
确定调集一名参加过原有系统开发的人员加入项目开发团队。
通过正式渠道通知厂商D，按照原来的合同要求应该提供设计文档；如果其不能履行合同义务，将中止与其任何合作。
烦恼了很久的事情，突然间就圆满解决了。小M自己也没有想到，S总出面可以发挥这么大的作用。
不仅如此，此事也改进了小M和G总的关系。以前两个人“各为其主”，因此冲突比较多。这次两人能够密切合作顺利地解决了问题，有点“英雄惜英雄”了。
3.4.4 经验与教训
项目中的干系人关系非常复杂，遇到困难的时候，冷静分析谁是项目的得益者，谁是项目的失利者，就可能发现解决问题的关键点。项目经理不用将“所有问题都自己扛”，可以巧妙利用非组织关系，可以设法获得高层支持，就有更多解决问题的钥匙了。
