1、前言

我们常说PLM项目的实施是一个复杂的系统过程。之所以这么说，一方面因为对实施PLM的企业来说，PLM系统的贯彻执行涉及很多横向和纵向的部门，覆盖多个业务流程，会对相关员工的日常工作产生巨大影响，具有一定的推广难度；另一方面因为对供应商来说，系统实施周期较长，投入的人力多，需要有专人从整体上把握进度和控制质量，确保项目按期完成，使公司的专业服务进入良性循环。在这样一个过程中，项目经理扮演着一个非常重要的沟通和协调角色。

项目管理非常重视计划、执行和控制，但是要让项目的计划、执行和控制得以顺利进行，沟通和协调是不容忽视的一个重要方面。本文拟从供应商项目经理的角度出发，谈谈沟通与协调对于项目实施的重要性，以及如何通过良好的沟通与协调，给不同的项目阶段营造积极、热情的工作氛围。

2、启动阶段（startup stage）

启动阶段的主要目的是正式确认项目的存在，客户和供应商双方的领导层承诺为项目的开展提供资源，并授予各自的项目经理使用资源的权利。在这一阶段，pm应该着重做好的事情包括：

2.1、通过kick－off会议正式启动项目

kick-off会议参与者通常很多，包括双方的领导层、项目经理、项目组成员和业务部门代表等。客户领导发言宣布项目启动，强调项目对于实现企业业务目标的积极意义，任命客户方的项目经理；供应商领导强调对项目的重视程度，承诺为项目的实施提供一切必要的支持，宣布供应商方的项目经理。在kick-off 会议上，项目经理通常还不是主角，但会被要求向大家简单地做个自我介绍。 kick－off会议通常不要很长，1个小时左右即可，虽然没有太多的具体内容，但是它标志着项目的正式启动，其形式意义不容忽视。

2.2、界定项目范围和总体进度

这两点不但是必要的，而且是非常重要的。

现实中有很多项目进展到后期无法正常收尾。双方对项目范围的理解不一致是导致PLM项目无法正常收尾的一个重要原因。为什么会这样呢？在向客户投标的过程中，供应商需要编写并宣讲自己的方案建议书；在这个过程中，由于各种原因，供应商通常会较多地强调方案的完整性和鲁棒性，有时大篇幅介绍系统的标准功能。而事实上这些功能点未必将来都会在项目中实施，具体范围还要受项目进度、客户预算等因素的综合制约。最终的范围应以双方拟定的作为合同附件之一的工作说明书（sow, statement of work）为基础。这一点往往被客户所忽视，作为供应商项目经理必须在项目启动后立即与客户项目经理沟通，结合sow，将项目的具体范围进一步明确，澄清容易造成误解的描述。将哪些内容要实施，哪些内容不包括在本期项目中等信息明确的表述清楚，并以文字形式写到《项目工作手册》中。需要注意的是，这样做目的是使项目范围对双方来说都很清晰而且便于操作和衡量，而不是为了刻意缩减项目范围。已经在sow中明确表述的内容不能减少，因为这是合同的一部分。就项目范围与客户进行讨论和确认是对项目经理沟通能力的重要考验，这个问题处理的越晚，对项目的损害越大。

关于项目的进度安排，通常在启动阶段还很难细化到每一天做什么；但项目经理必须就其中的一些重大里程碑点与客户达成一致意见，如项目四个阶段（启动、计划、执行和移交）各自的起始和结束日期等等。由于启动阶段结束后项目将进入计划阶段，因此为了指导后续工作，在启动阶段的项目进度计划中，应对计划阶段的工作进行细致的安排，如什么时候开展访谈调研？什么时候完成初步设计？什么时候完成详细设计？如何评审等等。对于执行和移交阶段的工作安排，其时间节点可以先粗分，等到信息足够充分时再对其进行细化和更新。为了强化全体项目组成员对于项目进度的意识，建议每次项目组例会时都以相同的格式、用图示化的方法再次强调项目的进展状态，如图1所示。

2.3、确定工作场所和沟通模式

为了增进沟通，pm最好能够通过协商请客户提供一个专用的项目办公室，用于项目组日常的工作和讨论。项目组的沟通方式也应该以文字的形式记录到《项目工作手册》中。如每周举行一次非正式项目例会，每月举行一次总结会，每个阶段（启动、计划、执行、移交）结束时召开一次正式的项目组会议等等。

值得重视的是，启动阶段需确定项目相关文档的存放和管理办法。为了保证数据源的唯一性和访问的方便性，我们可以建议客户在其内部网上放一个有权限控制的共享文件夹，在该文件夹下针对不同的文档分类建立相应的子目录。项目开展期间，pm将各种正式文档（如项目工作手册、项目计划、设计方案、会议纪要、讨论决定等等）交给客户的信息员，通过他/她将资料放到共享文件夹中相应的子目录下供项目组成员访问，如图2所示。

2.4、启动阶段总结会

作为启动阶段的总结和承接计划阶段的开始，启动总结会是非常必要的。双方项目经理，项目组核心成员都应被通知参加这一总结会。在总结会上pm回顾启动阶段的各项工作，将双方在启动阶段进一步明确的项目范围、总体进度计划、工作场所和工作方式、项目文档管理办法等信息非常准确地传递给会议参加者。特别地，pm还应介绍项目最终的验收程序和标准，并力争获得客户的同意和认可。我们往往对这一点有所畏惧或感到为难，一方面怕客户怪我们太迫不及待，项目刚刚启动就想着验收；另一方面，觉得系统设计还没开始，不知最后是什么样子，难以衡量什么样的情况表示项目可以验收。其实不然，项目是强烈地以目标为导向的，对供应商来说按时完成项目验收很重要，对客户来说，也只有项目验收了项目组的工作才能得到认可，项目成果才能得到进一步推广。从这个意义上来说，按时验收项目是双方的共同目标，需要共同努力才能实现，而明确验收程序有利于这个目标的实现。而且，这里谈的只是验收程序和总体标准（如按时提交指定的各项交付物，通过测试场景是否满足来验证系统的功能是否满足等等），并不涉及具体功能要到什么程度。事实上，具体功能的定义是在计划阶段才进行的。

从启动阶段总结会开始，pm开始融入角色并且全面的安排和协调项目的各项工作。

3、计划阶段（planning）

“计划阶段”更确切地应该被翻译成“规划阶段”，它是对PLM项目进行规划、初步设计、详细设计的阶段，这个阶段的主要产出物是《系统设计》文档。由于后续执行阶段的工作将以《系统设计》为依据，《系统设计》文档的不足或者错误往往会导致返工和延误，从而给项目造成较大的风险。因此pm应该协调各方力量，把握好这一阶段工作的质量。具体来说：

3.1、组织和协调好需求访谈

访谈的目的是为了更好地了解客户的业务流程，更好地在既定的范围框架下了解客户的具体需求，从而为系统设计奠定基础。好的访谈应注意三个环节：制定访谈计划、提高访谈质量和适当地回访。

在访谈之前pm需根据项目范围，结合客户的组织结构与客户一起制定一个详细的访谈计划。该计划在得到客户项目经理的认可之后，由客户通知各相关单位的人员参加。建议在访谈前召开一次访谈者通气会，会上pm详细说明访谈的目的和过程，需要做什么准备等等，这样可以避免在访谈过程中被访者不知所措。另外，pm可以通过这个会议宣布访谈计划，让与会者确认自己的时间与访谈计划安排是否有冲突，从而及早发现问题，及时调整解决。

为了高效利用有限的访谈时间，可以采取以下几个措施：

（a）访谈前通过通气会向每个人就访谈目的、方式进行沟通，这样在每一段访谈开始前就无需重复；

（b）建议被访者在参与访谈时携带一些本部门常用的文档模板和文件样本，以及与其它部门之间沟通时常用的文档模板和文件样本，这样做可以大大节省需求调研时间；

（c）请被访者先简要介绍一下所在岗位的日常工作流程，并请他们描述工作中需要PLM系统进行改善和提高的方面；然后实施顾问结合项目的范围，有针对性的进行补充询问；

（d）访谈结束前，简要总结所收集的信息，请求被访者核实，感谢他们为访谈付出的时间和进行的准备。

我们必须尊重每一位受访者的时间，每次访谈都应该尽可能按时开始，准时结束。在两个访谈之间应该安排半小时左右的间隙。这个间隙既可以用于实施顾问简短的休息，也可以用于整理上一段访谈的内容，或者用作适当延长某些特别的访谈段落。但有时情况复杂，即使用完这半小时的缓冲，还是无法收集和了解所有信息。这时为了不影响与已经等候在一旁的其他人的访谈，pm还是应该非常果断地结束访谈。结束访谈前pm应该向被访者说明必须结束访谈的原因，并且商定一个对他进行单独回访的时间，以保证信息完整。

3.2对需求进行整合和筛选

pm以及实施顾问需对调研得到的信息进行汇总、分析、筛选和整合，形成需求调研报告。整合后的调研报告至少包括以下几个方面的内容：

（a）被访谈人员的需求信息汇总；

（b）结合项目范围分析哪些与本期项目相关，哪些不在本期项目范围内；

（c）对于与本期项目范围吻合的需求，其优先性如何？ 哪几点是至关重要因而需要重点考虑和关注的？调研报告完成后，pm应召集一次项目组会议，邀请接受访谈的人员一起参加，宣讲调研报告的主要内容，与客户就以上(a)(b)(c)三点取得共识。

需要注意的是：PLM项目中不同的部门、不同的人从各自不同的角度出发，总会有这样、那样不同的需求，有些需求甚至是互相矛盾的。pm必须从总体上沟通和协调这些需求，使得他们和项目的整体目标保持一致，这样才能使项目在既定的进度和预算下完成，盲目地承诺和扩大需求是对项目致命的损害！

3.3、《系统设计》评审和修改

这里想强调的是：项目计划中必须给《系统设计》文档的评审和修改留有足够的时间，因为从《系统设计》初稿完成到该文档评审定稿还有很多工作要做。第一稿通常是供应商根据需求调研报告，结合从客户那里收集来的其它文档和表格等资料而完成的。《系统设计》是面向后续开发的一份文档，它从各个方面定义了未来系统的数据模型：如文档、零部件的分类和属性定义，审批流程定义，角色及数据访问权限定义，与其它系统或者cad应用程序的接口定义等等。初稿出来后，客户需要时间组织相关的业务人员进行讨论和确认，然后给供应商提供修改反馈意见。由于涉及各个部门、各个方面，这一反馈和修改过程通常需多次反复才能完成。pm至少应该预留一到两周的时间来完成这一活动，形成经过评审的最终定稿。

3.4、定义项目业务场景

与《系统设计》不同，业务场景是从客户的日常业务操作角度出发，对未来系统的一种描述方式，因而更容易用作与客户进行沟通。图4为业务场景的一个示例。如果pm能够在规划阶段与客户一起工作，定义出这些业务场景并得到客户认可的话，则项目能够成功完成的可能性将大大增加。测试场景给供应商指出了明确的努力方向，同时也为客户对未来系统提供了更好的理解。

3.5、调整和完善项目计划

各项工作的展开和《系统设计》文档的完成，后续的各项工作（特别是“执行阶段”的工作）变得更加清晰，这时pm需要根据这些信息在“规划阶段”结束前对项目计划进行调整和更新，并在获得客户认可后重新发布修订后的项目计划，用以指导后续的工作。在这个过程中，有几点值得注意：

(a) 对原项目计划中比较粗的活动的下一级进行细化，落实到人，具体到天；

(b)不要触动和修改大的里程碑时间点。这是项目计划修改的前提，基于这一前提进行的修改很容易得到客户的理解和支持，而对大的里程碑时间点的修改需要经过特定的更改流程，除非万不得以pm应尽量避免这种情况的出现；

(c) 项目计划中既要包含面向项目管理的活动，也要充分体现面向最终交付产品的活动。PLM项目有很多相似性，因而有时我们倾向于使用以前某个项目的项目计划作为模板，在此基础上进行修改。这一做法无可厚非，但一定要结合本项目的范围和特点，将本项目特有的一些工作（如xxx cad接口设计与配置，零件族pfm规划与定义等等）加入到项目计划中去，否则项目计划很容易留于形式，不具有可操作性。