发起阶段

项目对发起条件具有敏感性。如果大家缺乏对结果清晰、一致的认识，项目必将以失败告终。

作为项目领导者，最主要的工作之一就是让所有人统一思想，从项目伊始就澄清各自的预期。也就是说，这个任务并不轻松；如果没做好，就会给项目带来大的风险。

项目和方案花的时间越长，项目周期越短。所以，在项目早期投入精力是非常划算的。

要想定义明确的项目目标，有很多操作要点。

首先就是目标不应该过高。基于愿望的目标必然会破产，甚至可能导致团队功能失调，并滋生消极的组织文化。当目标能够达成，并且指向未来、又富有挑战性的时候，就是最有效的。

要用具体的语言，清楚地说明要达成的标准。项目目标应该是可以被量化的，而不是模糊的。应该有一组明确的数据，作为测量项目是否达成目标的依据。目标的可测量性，应该从数量、质量、成本、时间、客户满意度这 5 个方面来描述。

相关人员应该参与到项目目标的设置过程里，确保拟定的项目目标能在组织和团队之间达成一致。项目目标要与组织目标达成一致，更要考虑达成目标所需要的条件。

项目目标要有时间限制。

作为项目经理，一定要能清楚把握领导对这个项目的期望，把双方领导对项目的要求分类列条，然后全部写出来。

在收集需求的时候，要分辨客户的需求。客户愿意付钱的，就是他真正需要的；否则就不是。少关注客户说什么，多关注客户的行为。

作为项目经理，要时刻铭记项目是一个业务过程。遇到问题后，不仅仅要解决问题本身，还要解决问题所在的环境。

切记不要有鸵鸟心态，也就是明知道客户有某种需要，却不加以明确，结果只会使问题更趋向于复杂、更难处理。如果确实有问题存在，而且躲不掉，假如争吵不可避免，那么早吵也比晚吵要好。

不管用什么方法，在项目开始之前，主要的项目相关人员必须对项目目标和需求达成一致。原则是：对事要硬，对人要软。

最后，要了解每个人的预期。具体要回答这么几个问题：

这个项目会对谁产生影响？
谁会决定项目的成功？他们的预期是什么？
项目的限制是什么？
怎样让大家对项目结果达成共识？

为了每次都能回答以上问题，需要遵循以下步骤：

确定所有相关利益方。
确定主要相关利益方。
对主要相关利益方进行有效访谈。

所谓相关利益方，就是指积极参与到项目中，会因为项目产生正面或负面影响的人或组织。

在确定所有相关利益方的阶段，越努力去了解与项目相关的人，犯错的概率就越小。每个项目绝对不只有一个相关利益方，这就导致预期往往是多元的，甚至冲突的。

主要利益方是指任何一个决定项目成功或失败的人。这个人对项目给予的输入越多，项目成功的胜算就越大。

在确定主要相关利益方的时候，可以根据决策权限、需求关系、能量这 5 个维度来判断谁是相关利益方：

决策：指做出控制或影响项目决策、项目预算的决策。
权限：指有权威对项目进行批准。一定要把每个人都算进清单里。
需求：指直接从项目中受益或受到影响，从而需要了解项目所有进展。
关系：指与解决困难或取得成功所需要的人、资金或资源相关。
能量：指能够给予正能量或负能量，从而影响项目成败。

其中，前三个维度是最重要的。从前三个维度进行识别的时候，一定要把每个人都算进清单里，不要出现遗漏，导致盲区产生。

从关系维度识别到的人，如果有可能，最好让他们从头到尾参与到项目里。对于从能量维度识别到的人，忽视他们并不能解决问题，所以必须刻意地对他们进行引导。

在对主要相关利益方进行访谈的时候，要彻底访谈，仔细倾听。原则是尽早获得全部信息，前期得到的信息越多，后期遇到的不确定性就越小。

要先听后说，仔细聆听，不要打断对方。之后要敢于提问，直到对预期有了完全清晰的认识。

访谈的时候，只要稍作准备就可以，能给他们留下可靠的印象。在和对方预约见面的时候，要说明访谈的目的以及自己的预期，最重要的是要提到访谈给他们带来的意义。而且要提前准备几个关键问题，以便必要时引导谈话方向。

访谈时可以使用的第一个工具，是主要利益相关方访谈表。表中有这么几个字段：

项目目的：描述为什么做这个项目，要能够回答“这个项目将对部门和公司的目标产生什么影响”这个问题。
描述：尽可能清楚地回答项目怎么做、做什么、什么时候做的问题，要包含所有细节。
预期结果：写明什么结果才算项目成功。
排除项：填上不属于项目考虑范畴的内容。
沟通需求：询问利益相关方希望的沟通方式和内容需求。
审批条件：填上谁需要对项目进行审批。
局限：填上项目的限制条件。可能的局限区域包括范围（需要提供的产品、服务和结果的总量）、质量（项目特点满足需求的程度）、资源（满足要求所需的人力、设备、服务或供给）、预算（项目批准的预算）、风险（某个不确定事件或条件一旦发生，将会对项目的结果产生影响）、时间（产品、服务和结果需要提交的截止日期）。

访谈可以使用的第二个工具是提问漏斗。具体操作步骤是：先了解大方向和背景，然后对个别信息进行深入探讨，最后验证是否真正了解了被采访者的想法，从而确保一切都清晰明了。

在整个过程中，不要太关注问题本身，要仔细倾听，好好消化理解。如果没有听到想要的答案，或者回答不够具体，就再问一次。只要时刻铭记最终目的，就能够准备出正确的问题，得到想要的答案。

访谈可以使用的第三个工具是一对一访谈。一对一访谈的优点是能够了解对方真实的想法。访谈对象愿意开口交流，吐露他们对项目的真实预期。缺点是会缺乏讨论带来的协同，而且会占用比较多的时间。

访谈可以使用的四个工具是团体访谈。

首先，要将尽可能多的利益相关方聚在一个会议室里，或者通过电话会议进行。同时设定严格的时间表，承诺会在规定时间内结束会议。

然后，设立会议规则，最主要的是不能打断其他人讲话。正式开始时，给每个人几分钟时间回答访谈者的问题。期间不要就提出的问题展开讨论，只有当需要澄清和确认时再提问，然后感谢发言者。

在认真记录每个人的发言之后，会议结束后要感谢所有参与者。如果他们还有更多建议，可以接下来邀请他们进行一对一访谈。会议之后还要分发会议纪要。

团体访谈的优点是能够比单独访谈更快地获得更多信息。如果方法得当，信息质量比单独访谈更高。缺点是难度比较大，因为每个人都想发言时，时间往往很难把控，最终只会变成浪费时间。

在了解了每个人的预期之后，需要描述项目范围。所谓项目范围，也就是所有利益相关方同意的明确预期。

项目范围有两个作用：

让所有主要利益相关方对项目的成功有一个清晰的共识。
为将来的项目决策，以及确认和发展利益相关方对项目范围的共识，提供一个书面依据。随着项目发展，在经过其同意的前提下，可以对其进行修改完善，以反映项目范围的变化。

必须在之前和主要利益相关方的访谈里，特别是排除项和局限等方面做好铺垫，才能让所有主要利益相关方对项目有一个共同且明确的共识。

组建团队的时候，要小心“旁观者行为”，避免责任分散。团队成员能不能全力以赴，取决于成员被要求承担什么样的责任。如果管理者没有为团队成员规定明确的责任，很多成员都会产生“即使我不做，也有人做”的想法，从而导致团队合作中出现相互推诿的现象，最终导致团队绩效远不如单个成员工作绩效的累加值。

要避免责任分散，需要达到三个标准：

任务落实：每项任务必须有且只能有一个人对其负责。如果一项工作必须由多人负责，则应该对这个任务进一步分解落实。
人员落实：必须确保将每个具体工作责任落实到具体个人，而不是一个组织、一个部门、一个小组。不能让任何一个人对项目只享有权利而不承担义务。
组织落实：确保在项目组织和实施中，人员、流程、使用管理、平台、技术、工具之间能够达成协调一致，并建立相应的激励措施等。

具体实操时，可以使用责任分配矩阵来明确每个人的责任。责任分配矩阵的填写步骤如下：

首先，水平方向上填写好各个活动的代码和描述；垂直方向上写清团队内各个成员的名字。
针对每一个活动，填写项目责任程度，分为四个等级：负责（实际上执行具体任务）、批准（承担最终责任和问责，必须确保任务得到妥善完成）、咨询（向负责这项工作的人或团队提供必要的信息和建议，帮助他们做出决策）、知悉（虽然不直接参与任务执行，但需要被持续告知进展和结果，以确保了解情况，可以根据项目进展进行相应的规划和决策）。
填写好之后，需要对责任分配进行讨论和审批。
讨论并确定好责任分配矩阵之后，必须把责任分配矩阵传达到项目中的相关人员，至少组织内部人员要被传达到。

填写过程中需要注意：

每项活动尤其只能有一个负责的人。如果不能对某项职务划分责任，则这个活动需要进一步细分。
如果项目管理团队成员在其栏内没有负责的人，那么他不是项目管理团队的真正成员，可能是扩大范围的团队成员。
活动责任的承担涉及对时间安排、成本、风险等方面的保证，所以所有人必须落实在项目管理团队的范围内。而且责任不仅是技术性责任，也包括管理责任。
如果项目管理团队之外的人负责一项活动，那么项目经理必须承担这项工作的管理责任，还要承担这部分工作与其他工作的接口协调责任。

责任分配完成之后，项目经理还需要确保团队的工作优先级和客户的需求一致，并且确保将团队的工作适当地展示给管理层。在团队内部，要让技术负责人为不懂技术的人员解除技术问题，同时让开发团队也了解一些必要的非技术问题。

组建好团队之后，就要建立项目团队与组织的契约。一定要警惕先干起来的诱惑，在干起来之前要先达成共识。

对于一个项目相关人员都集中在同一地点，并且经过充分互动交流的小型项目来说，编写一个简单的项目任务书就可以了。对于大型或更为复杂的项目，特别是涉及多个组织的项目来说，必须要有一个更为健全的项目任务书。

项目的每个参与者可以定期查阅项目任务书，以确保大家目标一致。

编制项目任务书的流程可以分为三步：

起草项目任务书：由项目经理召集联席会议来起草项目任务书。目的是对需求达成早期概念层次的共识，并对需求做出回应。参会人员有客户代表、项目发起人、项目经理，以及已经确定的关键项目成员。
检查和讨论项目任务书：邀请那些没有参与制定项目任务书的相关人员来检查和讨论，直到所有关键人表示认可。以项目任务书为起点，项目计划团队在开始制定项目计划时，应该进一步讨论项目任务书的细节，从而更好地理解项目范围。并且应该把这种理解用正式文件做出公告并归档。
提交管理层批准：将项目任务书提交给管理层批准。批准过程中包含的主要参与者有高级管理层、客户、职能部门经理、项目经理、项目团队核心成员。

项目任务书一般包含的主要内容有以下几个：

可测量的项目目标和相关的成功标准。
项目的总体要求。
概括性的项目描述。
项目的主要风险。
总体里程碑进度计划。
总体预算。
项目审批要求。
委派的项目经理及其职责和职权。
发起人和其他批准项目任务书人员的姓名和职权。

项目任务书是非常重要、具有约束力的文件，相当于这个项目的宪法。项目任务书的发布就标志着项目的正式启动。

项目任务书应该由高级管理层编制，或授权项目经理代为编制，但必须由高级管理层签字，以表明高级管理层为项目提供支持的态度。

项目任务书必须指定一位项目经理，并明确其责任和权利。项目任务书应该分发给与项目有关的部门和人员，因为项目任务书将授权项目经理在项目活动中使用组织资源。

为了便于阅读和理解，项目任务书里尽量不要出现晦涩的技术术语。对于超出项目经理职权范围以外的问题，项目任务书必须明确处理问题和升级问题的机制，并且让相关人员知悉。

项目任务书要对项目的可交付成果进行概括性的描述，以便团队成员了解所做的工作是什么。项目目标主要指项目的绩效目标。

在范围说明里，要特别指出项目不能提供的东西，尤其是可能被误以为已经包括在项目范围内的东西。

项目任务书应该清晰定义项目的关键里程碑，通过对关键节点的检查，确保项目取得令人满意的进展。

而且，项目任务书不是一成不变的。如果发生重大变更，使得原项目任务书不再可行，就应该签发新的任务书。对于外部项目，应该先有合同，再有项目任务书。

项目开始之后，还需要确定团队的工作风格。项目团队的工作节奏和氛围，都与这个阶段的风格关系密切。

作为产品经理，也可以通知大家项目已经开始，大家应该慢慢找到工作状态，尽量营造项目的工作氛围。

项目经理还要明确工作规则。提前制定好可预见问题的处理规则，当事人在面对实际问题的时候，配合程度将大大提高。实际操作时。先说出对方实际中会遇到的情况，尤其是那些不愉快的情况。同时说出他们在遇到这些不愉快的情况时，可能要做出的心理反应，从而改变对方内心的固有程序。

要树立的规则：

沟通方式、频率、内容以及格式。
项目管理者的权利，即项目奖惩权利、人事调度权利和项目方案的决定权利等。
甲方责任、需求提供、调研配合和业务指导等。
变更处理的流程、文档、权利等。
团队合作模式、风格、出勤、考核标准、考核标准、争议解决等。
项目开发方各个部门的义务及责任。

可以适用以上规则的制度，包括但不限于项目例会制度、绩效考核制度、汇报制度、文档流程、变更管理制度。

项目经理明确规则和制度的时候，要顶住压力，不必过多解释。

项目经理要详细审视待实施项目的特点，查找已完工的类似项目，再查阅已完工类似项目的历史资料。记录中，已完工的类似项目历时 X 天，最后给出 X 天的时间估计。

有三个不容忽视的问题：

已完工的类似项目和待实施项目的相似程度有多大？
已完工的类似项目真的用时 X 天吗？
会不会有人为自己或项目安全注入水分？

在完成上述所有工作之后，就可以召开项目启动会，为发起阶段进行收尾。

启动会是为项目而开，属于组织行为。项目是组织战略的实现手段，所以获得支持是项目启动会的关键。

整个项目启动会侧重对已确定事项的说明，求同存异，但主旨是面向未来，通过启动会议了解人们对项目的期望。

项目启动会需要传达的重要信息或需要达成的目的有以下几个：

客户企业领导对项目的重视和支持。
向所有接触到项目的员工介绍双方项目团队成员和工作制度，树立项目组成员的执行权威。
让客户企业项目组明确认识到双方高管对项目的支持期望以及考核压力。
对前期选型工作的认同。
让客户企业各部门意识到自己未来工作中需要抽出精力配合，甚至暗示此项目部分内容将成为所有相关部门的考核标准，以确保项目能够顺利进行。

对于项目经理而言，还有一些私人目的：

依据商务人员的情报，重新分析企业的组织结构模型，弄清楚各个企业人员之间的微妙关系，确定自己的盟友、合伙人，以及需要沟通、说服、争取的对象。然后结合企业组织特点，小心而有效地建立自己专业人士的形象。
想尽一切办法和企业项目关键人物建立私人友情，成为一种合作搭档关系，而不能简单停留在一般工作配合的层面。

当然，召开时机应该根据项目情况灵活选择。作为一种号召大家大面积快速参与项目的宣传和推动手段，不见得要在启动的时候开，也不见得只开一次。

在这么几种情况下，可以考虑暂时不召开：

无法化解各方矛盾。
客户已经经过了充分磨合。
企业具备良好的实施经验和管理规范。
项目偏工具化、产品化。简单的项目把形式搞得过于复杂，只会增加双方项目组的组织沟通和时间成本。
我方公司弱势，并且签下了过度承诺的合同。这种过度承诺的项目，从实施角度来看风险很大，很可能在项目启动之后很长一段时间内，我方公司都很难拿出合适的产品到现场实施。
项目金额很小。有的企业虽然签订了一个复杂的合同，但投入的费用其实不对等，供应商出于种种原因还是签订了合同。此时指望供应商提供强大的后续支持不太现实。

在正式召开前，先召开筹备会，明确启动大会召开的准备事宜和细节。再分头准备、分头安排准备，不能立即进入启动大会的准备。

前期要和客户企业高层领导充分沟通，了解领导的设想，并让高层意识到项目的难度，以及让领导清晰认识到如何支持项目，为今后项目的实施取得支持，并建立定期回馈管道。

召开筹备会的期间，也可以为项目团队成员打造真正成为一个团队的磨合过程。对项目经理评估团队能力和管理复杂程度非常重要，一定要充分利用这个机会。

在启动大会过程中，发起人组织的高层管理者代表要作为会议的主持人。整个时间不宜太长，普通项目以 30 分钟到 1 小时为宜，大型项目可以适当调整。大会的时间必须协调高管的行程安排，并确保相关领导和高管的及时参与。特别重要的项目应确保双方高管能参与，务必避免相关领导没请到的情况出现。

发起人组织的高层管理者代表、项目经理、职能经理、涉及部门的分管领导、业务骨干和其他关键人员必须参加，且接到正式会议通知，并按重要会议的标准进行纪律考核。

落实项目责任、预警项目风险、确定成功标准、营造项目氛围，是会议内容的重要性排序。

会议召开期间，要根据不同情况设计发言：

如果项目团队组建非常顺利，项目管理制度非常完善，就要重点宣讲各个部门如何依据项目管理制度进行工作配合。
如果企业项目还没有进入状态，团队组建还不顺利，就要重点介绍我方公司的实施方法，让企业知道在什么阶段需要配合做什么工作，哪些工作由我方公司团队在现场做，哪些工作不在现场做。让大家对整个工作套路有所认识，并强调成立专门实施团队的重要性。
如果企业对太虚的东西没有兴趣，而且对企业情况有比较深入的了解，就要重点介绍在其他企业实施过程中的一些经验，以及预期可以在这个企业取得的效益，引发大家对项目参与的兴趣。

整个会议里尽量避免讨论需要较长时间沟通的业务问题，可以简单介绍项目的技术概况、架构组成等。

发起人组织高层管理者代表来讲项目目标和要求，并介绍项目组织构成。重点对各职能经理介绍项目分工，得到各职能经理、项目经理以及关键人员对项目的承诺，并形成书面确认。

讲规则的时候，要重点强调变更程序、协调和问题升级程序。一定要把项目的组织结构，也就是每个人的责任，以及假设、约束等说清楚。还要说明项目中需要注意的方面及关键因素。

组织协调方面，让发起人讲。越是不支持的人，越是要面对，尽量争取他们的承诺。如果要发布一些文件，文件下发程序要正式。

会议结束后，要切记落实会后 1～2 周的工作安排。项目团队一定要利用这个时间安排一些需要大家全力配合的工作，争取高管直接支持和驱动。