前言
鄙人是来自IT行业，商务出身，做过PM和公司管理层。因集成商身份，我参与过大大小小的项目有数十个，深感项目管理之魅力与价值之大。我希望通过加深学习项目管理方面知识、技能，成为更高价值的复合型IT人才。
在认真研读了项目经理及产品经理类的一些经典书籍后（大多偏向实践类），有一些粗浅的体会与心得想要记录下来，一方面是巩固、梳理自己的知识体系，另一方面也是借此投石问路、抛砖引玉，希望能得到看到此文的同行一些精彩见解。
此文鄙人将着重从自身的经验、见识出发，讲述两个方面内容，分别是：一、瀑布式项目管理的全流程最佳实践；二、技术以外的问题用商务来解决。
一、项目管理最佳实践
1.1瀑布式管理常见知识要点
项目管理有5大过程组、9大知识域，共计42个管理过程，基本完全涵盖了我们项目管理过程的方方面面。
5大过程组按照逻辑顺序分别是：启动、规划、执行、监控和收尾。其中规划和执行是相互交织的，规划逻辑在前，执行逻辑在后。但是执行过程会因为实际情况而不断地修正规划，所以它们首尾相连。而监控恰恰就是规划与执行这两个过程联系、转化的纽带。下图展示了管理过程组的关系：
9大知识域是由《项目管理知识体系指南》一书中总结，分别是范围（S）、时间（T）、质量（Q）、成本（C）、沟通（C）、采购（P）、风险（R）、人力资源（H）、整合（I），都是项目经理需要实际掌握的知识点，在项目中会频繁地遇到。具体如下图：
把5个过程组和9个知识域理解为横纵坐标的话，就会得到一个项目管理过程的框架矩阵，如下表：
这42个过程是前人总结的“招式”，是概念性的说明，可以帮助项目经理和准项目经理归纳总结实践的经验，形成知识的体系。
1.2我理解的最佳实践
站在前人的肩膀上，我们能看得更高、更远、更清晰。在实际的项目中，尤其复杂的项目，PM往往会手忙脚乱不知千头万绪从何开始。即便对照着上表的管理框架矩阵，或许也还是会觉得很难做到贴近实战指导。自己如果整理一套PM最佳实践，可以套用在常规IT项目上就可做到胸中有丘壑。让自己知道从进驻项目组的第一天起就知道应该做什么，用什么工具做，做到什么程度才算合格。
我自己对IT项目瀑布式管理过程整理了一份思维导图，主要参考《IT项目经理成长手记》一书，以及自己全程参与的各类项目经验总结而来。把42个过程杂糅进5大过程组，依据时间逻辑顺序递进，具体如下：
1.2.1启动过程组
PM的项目管理生命周期从进驻项目组开始算起，即启动期。
这个时间段特指项目刚刚完成合同签约或即将签约，项目组进驻的初始阶段。这个时候需要PM做的事情主要有4件，都是围绕着“规矩”进行。无规矩不成方圆，项目启动阶段不要忙着开工，而是先把规矩立下，不然很容易越忙越乱。
好的开始是成功的一半，这4件大事分别是：管理计划、工作思路、启动会和培训。
1、管理计划是把项目组的权责利、信息传递和交付等要求做了规定；
2、工作思路是为下一个阶段“规划”做铺垫，把项目和产品范围、工作量、资源配置做一个粗略的评估。另外也要和开发经理或者架构师，商议好开发团队之后的开发模板、样例，统一度量衡。还有一个最重要的事就是初期拜访一下客户，把相关的客户领导能见的都见，不论职级大小，一方面是拜山头，另一方也是提前与相关客户沟通PM的准备工作是否符合客户的预期。
3、启动会就相当于互联网公司产品流程召开的Kick off，是一个重要的里程碑。启动会的目的有几点，包括确定里程碑、提振士气、明确整个项目的工作方向、方式和方法，再有就是获得客户与公司高层领导的表态支持。启动会的会议纪要就是里程碑的交付物，形成双方落到纸上的第一份成果。
4、启动会后马上开展项目组内的全员培训，把通过的各项文档材料在组内传达、学习、落实。
1.2.2规划过程组
启动的过程顺利完成后，PM马上开始着手规划过程组的工作，详见图1-6。
这个时期重点考虑的是范围、进度、资源和预算。这4项内容的敲定是层层递进、逐步推导的过程，顺序对了则事半功倍。
1、范围指的是完成《范围说明书》，并估算工期和理清依赖关系。这3件事凑在一起是有道理的，因为范围说明书中重点包含了WBS，WBS+依赖关系可得活动清单，而活动清单+工期可得网络图（后面会用到）。另外，《范围说明书》并不是单纯项目组内自己看的，最重要的价值是拿出来和客户商议并得到认可，可以单独做确认，也可以与之后的《需求规格说明书》一起做确认。这个步骤怎么强调都不过分，许多项目后期失败都是因为需求范围界定不明，客户与项目组之间扯皮延误了工期、耗费了人力物力反而通不过验收，两败俱伤。
2、明确了范围后，就可以根据项目总工期要求去制作进度计划。其中涉及两张图：网络图和甘特图。网络图的初稿一定是很容易理想化的，我们需要通过计算来验证是否合理，通过判断“关键路径”的TS是否小于0即可得知。一般可通过优化依赖关系、预估工期和风险余量来得到网络图v2.0版本，接着便可以推导出进度计划表（即甘特图）。
3、有了进度计划表v1.0（甘特图），PM就清楚每一项任务在何时开展与结束。对照着甘特图，PM与架构师、开发经理、测试经理等各小组负责人共同敲定每项任务需要的人手，资源配置表v1.0就呼之欲出了。再进一步，把每个岗位职级分类统计就得到分类资源配置表v1.0。根据分类资源配置表，PM还可以反过来验证网络图是否最优，优化后可得网络图v3.0、进度计划表v2.0、资源配置表v2.0、分类配置表v2.0。
4、最后是明确预算，作为项目实施的基线。根据分类配置表可得人力成本，再加上合同涉及的各项支出可得总成本预算（即成本预算表）。
5、另外补充说明，PM需要时刻把握项目的即时状态，还需要做好挣值分析（在“监控过程组”需要用到）。挣值分析的数据来源于PV（计划价值）、AC（实际成本）、EV（挣值价值），AC和EV都可以在进度计划表敲定后（即至少是v2.0版本），每周的中层计划、底层计划报告里得到真实数据。有了这些数据后，就可以实时生成SPI（进度绩效指标）与CPI（成本绩效指标）动态监控进度绩效与成本绩效。
6、中层计划指的是项目组以周为单位，以小组为执行团体把进度任务分解。最好在每周五下午召开，PM和各个小组负责人必须参与，进行回顾分析并分配新任务。各小组独立完成周报，汇总至PM处形成整体周报。
7、底层计划是中层计划的再细化，在每一个小组内独立进行，PM不干涉。以天为时间单位，任务责任落实到个人。每个工作日的早上第一件事就是召开晨会（我个人偏向采用敏捷的站立晨会，15分钟即可），晨会内容在白板上清晰体现、定时更新、简单明了。
1.2.3执行过程组
规划相当于地图和作战计划，拿着地图和作战计划的PM知道该如何指挥团队去执行任务。整个执行阶段遵照瀑布流程，从需求（调研）、设计、开发、测试层层递进。
1、需求阶段明确的产出物是《需求分析报告》（附上我个人做的一个项目简单示例，链接点此处）与《需求概要说明书》，前者是后者的输入，后者是前者的输出，由PM牵头团队集体完成。在一些项目上会省略分析报告，直接编写说明书。不论是否省略，前期在规划过程组中编制的《范围说明书》应该作为组成部分。最后形成的《需求规格说明书》一定要组织正式的需求评审会议，客户方、我方甚至第三方专家共同出席，正式通过确认后才能进入设计阶段。我见过有些项目失败的原因就在此，要么是没有得到客户确认验收不通过，要么是召开得太迟而延误了大量工期和人力物力。
2、设计阶段的里程碑式交付物包括《概要设计说明书》《详细设计说明书》，主要由开发经理或设计团队牵头负责。可以在项目组内部组织评审，但也要足够重视和正式，把开发的风险降低。
3、开发和测试阶段一般都由开发经理、测试经理带领各自团队开展，PM这个时候主要关注SPI、CPI的管理和重点难点问题的解决上。细节部分不用置身其中，精力要放在对内协调资源支援开发团队和测试团队，对外及时与客户通气交流。
4、另外测试部分工作在监控过程组展开说明，PM配合质量经理完成监控。
1.2.4监控过程组
监控过程组在规划、执行的过程中始终进行，直到项目验收通过并移交。监控关注的对象其实就是风险、质量、进度和成本。换句话讲，其实就是风险在S（范围）T（时间）Q（质量）C（成本）这4个要素间的扰动。
1.2.4.1风险的监控管理
项目都会存在风险，而且绝对不止一个。所以风险的管理步骤是：识别、分析、计划和监控。
1、首先PM在风险发生前就应当识别风险的种类，提前预判。风险的来源一般有技术、管理、组织和外部。技术风险一般指采用技术难度过高，超出项目组能力。管理风险则是指项目管理原则使用不当，计划草率或者资源调度不合理等等。组织风险一般指内部对目标没打成一致，客户不重视等。外部风险值不可预测的一些政策变化、外部环境变化等等；
2、风险分析分三个维度来看——可能性、影响及时间距离。可能性和影响都是定性地判断，可以根据中公司或组织的《可能性等级表》《影响等级表》将定性分析转化为定量等级，对应《风险等级表》得出定量结果。时间距离指的是距离风险发生预计时间，需要每隔一段时间重新判断一次风险。
3、风险计划一般有四种办法——规避、转移、弱化、接受。通常的做法是PM根据之前分析得到的风险等级，来对应采纳这四种办法。致命风险必须要尽全力规避、转移，中等以上风险可以弱化，小微风险随机应变接受即可。
4、风险监控就是监视风险的状态，检查风险的计划是否有效，以及持续监控新风险关注旧风险。
1.2.4.2质量的监控管理
质量的监控一般指质量控制、质量保证两种途径，质量控制指的是控制项目的结果按照预期，质量保证指的是确保质量相关活动合乎标准、制度。
所以质量控制就包括测试、缺陷跟踪、配置管理。这部分的管理需要专人，即质量经理。如果团队配置不够健全，也尽量在质量这块安排专员，因为缺陷跟踪、配置管理都需要花费大量的精力和时间。PM从旁辅助，配合质量经理。
1、测试是执行过程组的一部分，除了单元测试是交给开发人员来做，其余的由测试团队负责。在测试的后期如系统测试、性能测试期间，往往因为临近验收所以时间紧任务重，测试、开发人员和客户甚至会“捉对厮杀”。这样的看似节省时间，改bug速度快，但很容易自乱阵脚把测试工作搞成一盘散沙。质量经理和PM要盯紧缺陷跟踪过程，这一步骤尽量不要省略；
2、缺陷跟踪是贯穿在整个监控过程组的，从缺陷发现开始直到缺陷确定结果（无论是完成更正还是延迟处理都是结果）。缺陷源于发现活动，如各类评审、测试和审计。跟踪的过程依据《缺陷跟踪记录表》，其间涉及项目组多个角色，包括缺陷发现者、协调者、分配者和修改者。最后质量经理要把所有缺陷记录做整理、分析，已改进缺陷修正的效率、准确度；
3、配置管理是持续性工作，不能简单理解成项目文档的处理，务必要专人在专门的服务器用专门的软件做配置管理。从项目启动时就有准备工作，执行阶段有日常工作，最后到项目收尾阶段还有结束工作。最好具体由质量经理来指导专人处理，涉及较多的工具操作。
质量保证则一般包含评审、审计和变更控制。
1、评审在执行阶段会发生，需求评审、设计评审都很正式，因为前期越严格后期问题就越少。代码和TC评审以专人走查的方式进行即可，尽量安排经验丰富成员；
2、审计多为大型IT公司职能部门组织牵头，包括对预算、进度以及各项流程进行审计；
3、变更控制要着重强调的是它的原则性，即它的目的是为了让项目可控，而不是为了阻挠项目变更。有时会在项目上遇到客户或者我方自己人不理解，变更的过程为什么这么复杂或者艰难，那是因为如果变更可以随意进行的那么项目会非常容易脱离既定的规划，导致项目4要素失控。
1.2.3收尾过程组
这一个过程组相对来说比较简单，但也是建立在前面几个过程的扎实推进基础上才行。总体有：试运行、培训、验收和移交。ToB的IT项目试运行一般多为3个月居多，期间可以准备好培训的文档材料并完成对客户相关人员的培训工作。验收一般分为初验和终验，初验通过后试运行，接着没问题的话终验。最后是进行移交工作，这个在质量监控时配置管理的工作价值就凸显出来了。把配置管理的结束工作做好，即可顺利完成移交。
二、巧用商务资源
2.1商务资源有哪些
项目管理事无巨细，PM都要操心，所以有时难免会陷入其中。又因为项目经理很多都是技术出身，习惯了用技术性思维考虑问题。这种思维模式有优势也有劣势，优势就是能够更清晰地理解技术性难点，给予团队技术上的关键指引。劣势就是项目管理过程更多的难题其实是在于技术以外，再用技术性思维难免捉襟见肘。
在本文的这一章节中，鄙人将以亲身经历或见闻来分享一下项目经理遇到的难题如果巧用商务资源的话，许多都将迎刃而解。商务在新华字典里的解释是：商业上的事务。在我们接触的项目中一般特指运用企业级、事业部级资源的相关活动，都属于商务范畴。所以按我理解，当我们说到项目上的商务资源，应该包括这些类别：销售资源、采购资源、事业部资源、公司资源以及友商资源。
这种分类方式是我根据实践总结的，并不一定科学，但实用好记。根据资源的协调者来定义，比如销售资源就是指公司的销售经理、KA等能协调的资源。所有这些资源都是通过各种手段，来达到“搞定”项目、“摆平”问题的目的。
2.2技术以外的问题
PM在项目管理的实操过程中，有一些常见的棘手问题：包括需求范围界定、需求变更、外部风险、组织风险、项目监理。这是我认为大部分To B项目都多多少少会碰到的问题大类，而且往往都会让项目经理抓耳挠腮、头疼不已但又一筹莫展。在我以前集成商销售生涯中，这些问题我都碰到过，接下来一节我对应讲讲如何用商务资源解决。
2.3四两拨千斤
2.3.1需求范围界定
需求范围界定常见问题有：
1、项目已经接近尾声了，客户提出意见说我们做的不是他们想要的，怎么办？
2、PM知道要界定范围，但是客户不配合，不是很想参与确定范围怎么办？
3、客户参与了需求范围界定，但是我们与客户意见分歧很大，不肯签字怎么办？
2.3.1.1问题1
第一，项目经理首先要明确客户为什么这么提，提出的依据是什么？如果根据合同、招标文件、需求规格说明书等都能显示，我们的项目建设内容不符合要求的话，那么这个问题就出在自身，请赶快补救。
如果补救起来时间不足，或者远远超出成本改怎么办？这个时候要请出销售资源、事业部资源帮忙。一方面让销售向客户说情，宽限时间or降低标准，另一方面向部门领导甚至更高级别领导请罪求更多的资源支持。事后挨板子是免不了的，前期项目管理不到位酿成项目损失，PM要负第一责任。
第二，如果客户提出的并没有依据，也应该第一时间向客户了解清楚为什么有此异议，而不是冷漠拒绝。搞清楚原因，再恰当应对，可以提升PM在客户心中的地位。
比方说以前我的某个口岸的项目，其中一个用户单位是游艇协会，提出了合同要求之外的需求，我们合同之内的反而不是他们需要的。这个时候项目组当然可以简单地拒绝，因为需求说明书已经写明了。但是PM当时并没有这么做，而是了解清楚原来问题是出在前期调研不仔细，把需求弄错了。PM和我提前分析了更改这个需求不会影响验收的功能项，增加的一点工作量可以承受。
从商务角度我当时建议在验收时增加这一份用户体验报告，所以我们决定给他们更换这个需求，于是我们向业主单位汇报提出了这点并得到认可。最后反而因为我们的这个举动，在后期验收时游艇协会给了相当大的超预期支持。
2.3.1.2问题2
了解清楚为什么客户不愿意配合，或许是因为不想承担责任，或许是因为PM找错了客户对接人，或许是因为客户不想看到分歧等等。初来乍到的PM很难做到熟悉客户内部的真实情况，及时向销售或者了解客户状况的前辈打听信息。有了预判后，再和客户1对1的了解想法，印证真实原因再对症下药。
我以前经手的某个项目上，PM及团队都比较不擅长沟通，客户对接人当时出于某些政治原因，并不过多过问。所以项目的需求范围界定做得很模糊，项目组东拼西凑做了需求分析，但一直闭门造车没有申请需求评审，直到半年后才被客户高层发现与预期严重不符被叫停。我当时作为商务被调去救火，公司的相关领导也多次出面沟通，与项目组通力合作重新界定了需求范围才挽回项目损失。
需求范围的界定从来都不是PM自己一个人的战斗，所以请积极地拉上销售一起推进，许多模糊需求客户不肯退让，但可能会卖客户经理或者部门领导的面子而放松许多。技术上、实施上的大改动，可能只需要商务上的一点小变动就能消除。
2.3.1.3问题3
首先明确一个共识，有分歧并不可怕，所以不要回避分歧。让客户直接签字，都会容易有畏惧心理。PM要收集好客户情报，最好请销售一起帮忙找出分歧的原因所在。把大家都认可的部分先敲定下来签字，剩下分歧严重的单独讨论。一般分歧都是来自于合同的模糊地带，可能是双方故意留下的，也有可能是单方面设下的，或者大家都没想到。如果是双方故意留下的，那么请销售资源帮忙解决，会很容易与客户达成共识。
需求分歧的部分往往对应着不同的客户干系人，所以比较好的方式是先与客户私下沟通，大量的沟通会打好基础。分歧一定要有个结果，就算不能形成共识也要留下努力促成和谐共识的痕迹，客户也会看在眼中多出一份体谅。
分歧可能是零和游戏，也有可能是双赢或者双输。这又是仁者见仁智者见智的另一个话题了，此处不展开。
2.3.2需求变更
2.3.2.1问题1
需求变更的常见问题是项目做到一半，客户突然提出要增加需求，怎么办？
我的建议是搞清几个问题再做决定：什么样的需求？为什么要增加？符不符合我们的利益？用什么样的资源能最优解？还是拿实例来说明：
某一次，我的一个项目上客户提出要临时增加某批GPS终端设备的通信功能，我们作为项目的集成商会增加开发工作量（导致项目超期的巨大工作量）和预算。PM在分析了新增需求的依据后发现这是个绕不开的问题，是设计标里预留的坑。所以他第一时间找了销售资源，也就是我来帮忙处理这个棘手问题。根据监控过程组的风险计划知识我们都知道，既然这个风险没办法规避，就只能采用转移、弱化或者接受的方式。
在这个问题上，我们找出了问题的源头——GPS设备供货商。于是通过销售资源、采购资源、事业部资源共同向友商施加影响，成功地将问题物归原主转移了出去。由供货商负责解决新增的开发，我方采购SIM卡和一年的流量费，最后只用几千元就成功地解决了一个很大的风险。
2.3.3外部风险
外部风险的常见问题有：
1、接口方不愿意提供接口详细设计文档，只给一些简陋的需求文档和接口标准，里面甚至还有描述很多是错的，怎么办？
2、XX出台了XX新政策和标准，系统要增加新需求怎么办？
3、项目早期调研时有疏漏，没考虑到未来要和XX单位对接。现在要对接，XX单位不配合怎么办？
2.3.3.1问题1
我们可以请客户方出马帮忙协调，但是切记不要找错人，并不是每一位客户都有能力和面子协调竞争对手的。找准客户干系人，对接口方施加影响是最简单的办法。
当接口方与我们形成竞争关系时，就会自然地抵触。所以另一种方式是把竞争对手变成合作方，通过销售资源、事业部资源或者采购资源与接口方谈判，找合作的切入点，把1个项目上的冲突转变成N个项目上的合作。
2.3.3.2问题2
碰到这样的政策性新增需求，有几种方案可以选择。第一是协调客户增加预算，把功能补上；第二种把新需求延迟到下一期项目建设，取决于政策要求的上线时间与验收时间是否符合；第三种是做需求替换，把新需求替换掉老需求，已经建好的部分可能会浪费了。这种牺牲是无奈的，但可以争取换来一些客户的资源倾斜。此时拉上销售，运作得好的话可以为事业部甚至公司带来一些超预期的资源回报。
2.3.3.3问题3
与新的单位对接接口，一般有两种解决思路：不花钱与花钱。不花钱的方法需要客户方支持，帮忙协调新单位接口。
花钱的办法我举个真实案例，以前经手的某项目就碰到要和B单位对接接口，客户方A单位在项目规划中也没有预料到，所以对接时相当被动。B单位并不买客户方A单位的账，但又必须要对接，否则验收不了。而B单位又是政府单位，我们想花钱购买接口都做不到。于是我方动用了许多商务资源，包括事业部领导、销售都花了大精力协调，找到了B单位的某个服务商C单位，以购买服务的方式解决了接口对接的问题。
2.3.4组织风险
组织风险的常见问题有：客户单位即将面临组织调整，客户开始响应缓慢，项目推进不利怎么办？
面对这种客户组织机构调整的情况，要以不变应万变。不论上层建筑如何更替，项目总是要完成的，尤其政府、事业单位的项目是受到监管的，不能耽误。所以在组织架构调整完毕之前，PM应当把项目进度推进到下一个里程碑节点前，做好各项汇报材料准备。一旦组织调整完毕，PM先非正式汇报，让新到任领导心里有数增加认可。随后立刻协调公司领导、事业部领导做里程碑汇报，一举突破项目进展的瓶颈。
2.3.5项目监理的常见问题有：
1、项目监理总是找我们问题，一到评审上就挑我们毛病，许多问题都通不过怎么办？
2、监理总是和客户联合起来给我们施压，要求我们多做很多东西怎么办？
2.3.5.1问题1+2
项目监理的角色是项目的监督者，是平衡的第三方。我见过许多承建单位会对监理带有抗拒和排斥的心理，这首先是不对的。监理并不是天然地站在承建方对立面，我们可以与他们通过共同利益联系在一起。项目的验收通过就是共同利益，所以评审上挑刺，要么是确实做得太差，要么就是没有提前通气。
PM可以独自与监理构建良好的合作关系，搞不定时可以试试销售资源或者事业部资源。监理如果时常施压要求做很多东西，PM就要反思一下是不是在关系处理上有不到位的地方，得罪了对方。我曾经见过不少PM与监理势如水火的关系，其实都是非常不应该的。
2.4横看成岭侧成峰
2.1-2.3章节我写的比较多都是实际操作层面的内容（受限于篇幅和时间精力也只能粗略举例），但项目管理中遇到的问题往往千人千面，单纯模仿套路可能效果并不一定最好。在这一节，我分享一些作为一名成绩尚可的前大客户经理的客户管理心得，偏重于道的层面（虽然我本人也还没完全达到这个层次）
在To B项目中，客户管理私以为是在项目管理过程中占据了50%以上甚至更多的重要性。客户管理是一种技能，就像PM对项目管理42个过程的掌握一样都是有迹可循的。做好了客户管理，面对同样一个问题时PM会感受到“横看成岭侧成峰”的境界。
我发现Top sales与PM对待同一个问题的解决思路有显著的差异。不得不承认，这种差异很多时候决定了结果的巨大差异。Sales man也会有不好的思维方式，我们取其精华去其糟粕。
一、首先是心态。项目组成员看待客户往往会有生疏感，对待高级别一些的客户领导还会有紧张感、距离感。这都是人之常情，但也使得PM天然地不愿意与客户中高层领导接触。于是乎，我们不难发现很多项目上的通病就是，客户中高层对项目组的实施进展不了解，对成果认可度普遍偏低。人们总是会对自己陌生的事务，天然地抵触或戒备。
所以PM要做好心理建设，不要只把自己局限在一个小项目里，认为自己只能和某科长、某工程师打交道，只和他们平级。要把自己当做anyone，上得庙堂下得草堂。
建立了这种心态后，项目中遇到问题时就不会第一反应是畏难、躲避或者掩盖问题。很多问题一开始都是小问题，但是项目经理不及时反馈沟通，不喜欢与客户交流寻求支持或者探讨解决方案。PM许多都是一肩挑问题的敢担当之人，但喜欢闭门造车，问题反而容易越弄越大。
二、接着是日常关系的处理。心态平和了后，我们对待客户、监理以及友商要像对待朋友般温暖和自然。不要单纯把关系等价成上下级，或者监督与被监督，甲方与乙方。日常关系的处理是必要的，一说到搞关系很多人会排斥和抵触。
当然我们对PM处理关系的能力要求不会这么苛刻，但适当的“会来事”还是必要的。休息时间没事就和客户聊聊家常，偶尔约客户干系人喝茶吃饭谈谈心，节假日及时送上祝福等等。私以为在To B项目中，PM应该把60%以上的时间用在对外联络、沟通上，剩下的时间才是与项目组成员协作。但很多项目中，PM甚至会把80%的用在自己团队内部，我认为是不提倡的。
三、最后是技术以外的知识储备。我以前在集成商时做KA时，对KA的一个要求是“通才”。在项目实施期间，PM也应该是一个通才。尤其集成商的项目，涉及的信息系统往往很多样化，PM会有机会接触到销售、售前、合同谈判、采购、招聘、团队建设、售后等等多项事宜。所以PM首先要对自己公司内部的各项流程了如指掌，才能在客户现场有底气和信心拍胸脯。
其次PM对于身处行业的前沿知识、新闻热点最好要熟悉，对于客户单位的行业消息、政策新闻、绩效考核等等也要储备知识。这既是我们PM与客户交流的谈资，也是对客户行动的预判，能帮助我们提前规避风险、保障顺利交付。
参考文献
【1】潘东，韩秋泉.IT项目经理成长手记【M】. 北京：机械工业出版社，2013.
【2】王如龙，邓子云，罗铁青.IT项目管理——从理论上到实践【M】.北京：清华大学出版社，2008.
【3】美国项目管理协会.项目管理知识体系指南【M】.第4版.王勇，张斌，译. 北京：电子工业出版社，2009.
【4】哈罗德·柯兹纳.项目管理最佳实践方法【M】.第2版.宋笛帆，黄诗雨，译. 北京：电子工业出版社，2011.