规划阶段

在接手一个新项目的时候，首先要尽可能多从各个方面了解项目情况。对项目把握越到位，可以提前遇见的问题就越多，也可以想办法提前申请或预约资源加以解决。

在项目的最初阶段，根据各方面的情况，经过平稳后，可以得出一个项目大致目标，并获得其他人的认可。

做整体项目计划之前，先大致计算一下自己手上的资源：

时间：往往很多项目要求在几乎不可能的时间范围里完成，在做项目风险控制计划的时候，要充分考虑。
人员：根据项目预算和以往经验，大致计算未来项目小组有多少种角色；每个角色目前公司是否有人，是否能完全归这个角色项目使用；是否需要另外招聘或者借用一些人员。
开发任务准备：项目所需关键功能如果还不具备，就要尽早和开发部门预定，争取提前纳入版本开发计划，并定期跟踪，确保没有被挤出版本开发任务单。

做业务调研时，可以分为如下几个工作周期：

调研准备阶段：确认调研计划，准备调研背景资料。
现场调研阶段：根据计划完成各项调研工作，取得客户认同。
调研后续工作落实阶段。

初次调研最好先了解客户企业基本情况和客户项目组成员情况，由此建立对客户企业的初步认识，对项目有个初步判断。

然后再了解企业组织结构和岗位设计，由此确定访谈对象。按照业务口逐个了解业务流。

了解业务流的时候，要关心业务可以划分为哪些阶段，每个阶段应该相互独立、彼此穷尽。每个业务阶段要问清楚业务目的、输入数据、输出数据、过程步骤、每个步骤的负责人、什么时候开始、什么时候结束等。

如果有商务合同和技术协议，在调研之前一定要先认真阅读。同时还要阅读前期技术方案和各类备忘录，确保后期工作质量一致性。并且要和项目前期的我方人员进行充分沟通，熟悉我方已实施的相似项目情况，启发思路。

还要熟悉相关产品的最新功能及发展方向，了解产品的发展方向、现有和近期可实现的功能。客户那边要了解客户企业所属行业的行业特点、竞争态势、产品研发等特点。

正式调研之前要准备同客户交流时的产品原型、业务原型或演示文稿。有必要的时候主动收敛客户的思路，引导项目边界。还要准备企业业务调研问卷，按客户的当前情况或背景、客户可能面临的问题或挑战、问题可能带来的后果或影响、解决问题或满足需求可能带来的好处或成果这个模式来设计问题。

同时还要事先和客户沟通，编制业务调研计划，得到客户的确认。还要准备业务调研流程培训材料，让客户知道我方的调研方法和思路。

现场调研的时候，还要把常用行业案例及标准配置数据带到现场。客户很难提供明确需求的时候，用我方在别的企业的成功样例启发和引导。除此之外，还有我方各种流程管理文件。遇到一些客户提出麻烦或不合理的要求的时候，用公司流程去拒绝。最好的话还能带上公司的小礼品。

业务调研时有很多常见误区：

调研计划不够细致：

好的计划应该可操作、可执行，能让客户看明白。调研计划一定要细化到每天上、下午分别调研哪个部门、需要怎样资历的人员配合、需要配合多长时间、将了解哪些方面的业务问题、需要准备哪些相关数据等。

在项目里要有随时调研的意识，一旦发现新的事实与历史调研结论不符，要马上重新完成调研结论，并进行相关调整。每次调研都应该有成本概念，只要达到使下个阶段工作可以顺利启动的目标，调研就可以结束。

确认调研计划后，没有主动要求见客户企业负责的领导，而是立即进入调研状态：和企业领导见面时，首先要汇报计划，请他再次确认，并请他协调资源安排人员配合。可以要求领导配置一个专门的联络人，由他进行联络工作。可能的话，也要求其全程参与调研。

如果时间允许，在汇报计划的同时，也可以向企业领导汇报自己的调研工作方法，请其提出意见，做相应的客户化调整。企业领导可能提出一些要求，可以根据实际情况确定是否进行。

调研之前，最好利用和高管见面的机会，约定项目中后续汇报工作的机制。和企业领导汇报工作时，原则上一定要言简意赅，不要表现自己，低调切入。

调研过程中要收集足够事实，通过汇报机会逐步让领导加深对项目经理的印象，使其认可自己思路的合理性和创新点。

没有预约时间，也没想好调研开场白：进入具体调研业务之前，要和客户企业调研协调人确定今天的调研计划和资源到位情况。如果今天计划安排的配合资源不到位，要主动给企业调研协调人几个替代性调整方案，由其负责落实到位后，才能放心开展调研。

和被调研客户提前预约调研时间。出晨时，首先要自我介绍，表达自己是想通过调研为其业务设计好手段的合作者，有时候还包括极其简短的公司介绍。然后了解被调研者的背景，对其配合调研表示感谢，顺便奉承一下。最后对调研总体内容和时间做一个说明，让其配合时做到心中有数，乐于协助。

调研的时候，调研者不断地问问题：

向客户了解整个业务过程，在具体业务过程中顺便了解自己想重点关心的问题。调研方式应该站在客户的角度了解业务，先有一个对业务的总体认识，再了解细节，也就会更深入、更细致。

要充分让客户讲话，让客户有兴趣、有心情把自己知道的事情完整、有序地讲出来。一个单元业务问题问完后，要立即主动复述客户所讲的业务和过程，让客户确认调研人员已经理解其所说的内容。

可以在快结束会谈的时候，再提出一个相对敏感的问题，顺便多了解更多信息。调研结束后，一定不要忘记感谢客户的帮助。如果最后有时间，还可以请客户审核调研记录，修正自己理解上的一些错误。

调研时有选择地问问题：

越是有公司产品明显不能解决的问题，越要调研清楚，搞清楚来龙去脉，为公司今后的产品发展提供完整的需求建议。

立即就问题提供解决方案：

解决方案一定要在内部达成一致后，才能提供给客户。

调研过程中，不要过多花费精力介绍自己的产品，而是做一个好的发问者和聆听者。用耳朵去听，用心去想，用大脑去分析客户的信息，发现有价值的内容。

不注意收集异常的事实，挖掘背后的需求：

调研不是简单了解企业业务流程，而是要找到业务流程中的问题。

如果听到一件和流程不符合的事情，或者和管理预期不符合的事情，要高度重视，一层一层了解下去，直到把事情分析得很透彻，并出现问题的解决思路。

有价值的问题往往隐藏在意外事故之中。调研过程中要随时分析现有流程存在的问题，而且一定要找到事例证明问题存在，并事后分析可能存在的改进点。

关键业务只询问了个别人意见：

一些业务在整个调研工作中占据重要分量，而且涉及多个业务部门。这个时候，调研一定要把业务涉及的不同部门的意见都听到，也要把不同人对同一业务的描述进行对比分析。不能因为调研内容很饱满，或者时间紧张，就只做单点调研。

关键业务一定要从其他人那里不断得到验证。在问其他人的时候，可以用主动复述业务的方式，请他们重点指出不对的地方，加快调研进度。

每天调研工作时间太长：

每天有效调研的时间一般尽量不要超过 4 个小时；对每个个体的一次访问时间也尽量不要超过 2 个小时。

把要调研的问题结构化。针对一类问题，将一组相关问题形成一个开放性或封闭性的问题引导区。

尽量不要自己一个人调研，而是应该两个人一起调研。最好两个调研者中有一个是企业项目组的成员。

调研完成后，要及时把调研内容转化成文字，而且要转化成结构化的文字。一旦发现一些自己感觉清楚、但实际并不清楚的内容，可以把这些内容整理成第二天的问题，进一步确认，把调研逐步推向深入。

最终要把这些文字回馈给公司相关同事，让他们立即提供回馈意见，以便调整调研进程。

只重视正式沟通，不重视非正式沟通：

非正式沟通适合问一些相对敏感，或者自己有看法但没把握的问题。在此过程中得到的信息，往往是企业的真实运行信息，和正式调研得到的信息可以互相印证。调研者可以和客户企业中的一些人建立友好关系，为今后工作奠定良好基础。

一次调研就企图锁定需求：

项目团队绝不可以因为大规模调研完成了，就对此后的调研随意进行，不留记录，不进行确认。

预先锁定需求的假设前提是：客户不经过系统实践的过程，就能预先精确地提出所有的系统需求。某些简单的项目或产品，或者具有极高技术水平的客户，还是可以的。但一般情况下，客户只对其目标和需求有模糊、笼统的认识，许多细节都不清楚。

调研的时候一定要保持一个理念：问题不在于要求客户不变更需求，而在于找到一种方法，让客户认同项目能发挥作用。当有新的需求时，通过项目建立的信任关系，重新形成新的业务。

不重视收集企业表单报表：

要根据报表了解每张表格的作用、填写内容、移交给哪个单位或部门；了解每个单据表格每项填写内容的来源、填写格式规范、数据约束要求、自动计算公式、原始数据收集来源，以及提交给哪个部门做何应用等。

所有表格最好收集一份空白表格，再收集一份带典型数据的单据和报表。如果客户数据涉密，就手工填写一份类似真实的单据，并记录下单据的更新频次、来源、去向、收集时间、收集人、被收集人以及电话。

将一份份零散的纸质单据之间的业务联系和数据联系画成流程图。

没有开业务分析会：

调研者应该在调研计划中主动安排或创造一次汇报机会，专门陈述自己对企业业务和要解决的关键问题的认识。

汇报时间不一定要很长，只要让客户企业领导真切感受到我方调研工作的成效、对事实把握的可靠程度、对客户企业业务了解的深入程度、对问题分析的细致程度，以及在该领域的专业程度即可。

项目经理不宜采用过高的姿态进入业务分析会。越是企业信任项目经理的个人魅力时，越要注意这个问题。面对客户企业存在的问题，即使要说，也应该采用一种委婉的方式表达。具体而言：指出可进步的地方，而不是落后的地方；指出不可控的地方，而不是失控的地方；指出实现不方便的地方，而不是无业务管理覆盖的地方。

在进行业务调研的时候，要撰写业务调研日志。

调研日志的基本要求是：工作过程清晰化、调研内容结构化、不明内容有后续计划。除了上述基本要求，调研日志上还要看出本日调研了哪些部门、走访了哪些人、用了多长时间、获取了哪些业务信息。

调研内容不能是流水账记录，必须将被调研者的话组织成一个个合理的单元。这些单元可以独立反映某个业务层面的情况，然后整体上构成业务调研报告的一部分。

不同的信息结构化方法可能不太一样：有的适合用表格，有的适合用文字段落，有的适合绘制图形。而且还要说明，今天调研中还有哪些问题需要进一步明确。

调研结束之后，必须尽快整理出业务调研报告。业务调研报告的主体内容可以在业务分析会上取得客户确认。应该结合我方公司产品和业务特点，形成一个比较统一的汇报目录模板。内容有三大部分：

业务基本情况介绍：这部分要结构化，不要散乱。将相关性强的一组基本情况设计成表格填写。
企业业务流程图和数据流程图：这部分要求按照调研先后顺序组织，与业务流顺序尽量一致。
项目关键价值点：这个部分必须符合结构化层次，不要将很大的价值和很小的价值并列排放。应该将最大的价值独立作为一层，然后将小价值分别归类到不同大价值下，形成一个价值支撑体系。这个支撑体系也是解决方案的实现思路。

完成了业务调研之后，就要编制项目解决方案。

首先，不要把实施当作售前。售前方案以宣传我方公司综合实力为主，内容务虚，重在介绍一些理念和管理思路；以我方公司功能和实施经验为主，结合客户企业一些特色加以发挥。一些概念要么在实施阶段找到落脚点，要么在实施阶段把这些天上的东西用地面的目标取代。

对产品更多是从功能列表角度来陈列或解释不同应用要用到哪些功能。实施方案以描述企业业务流程实现方法为主，内容务实，通过业务线来串联；在详细业务调研基础之上，以企业业务为核心，结合企业流程详细展开功能实现的操作主要细节。要明确提出一些定量的目标，一切要清清楚楚，不能说不出所以然。

对项目价值点要能结合部门、岗位和业务，并描述不同业务环节的不同岗位责任人能从系统中得到哪些效益，进而支持客户企业的何种价值点。必须能够将功能真正串结成业务操作，让客户能看懂一个业务在系统支持下，从原始输入到最终输出的全部流程，而不能含糊其辞。

写方案的时候，方案的目的性一定要强。解决方案在很多项目上应该是项目验收的法定标准。一个明确的企业业务流程和管理思路解决方案，是项目经理向项目团队成员传递实施经验和配置思路的一种工具。

解决方案有四个常见问题：

套路化：解决方案必须有个性化内容，不能全部复制模板，包括方案图片也不应该抄袭标准模板的图片，而应该用客户的实际数据来做说明。
价值点加功能手册式的假大空方案：要让客户看到实现哪些业务流程、在过程中改善了哪些环节、工作是如何改善的、要如何实施，最终操作模式是怎样的。所有这些构思要能指导实施顾问进行项目配置，通过配置好的产品验证解决方案的可操作性。
对项目目标关注过少，没有清晰的项目目标：目标也没有分阶段划分，就会导致项目目标没有保障措施。
和售前方案缺乏一致性：也就是文档排版质量和售前文档显著下滑。文档一些关键提法和售前没有保持一致，就容易引起客户的误会。

编制解决方案的最佳时机是在业务调研阶段，此时大量鲜活的情报应该快速纳入解决方案的思路中。项目经理应该在每天整理调研日志和调研记录的时候，快速形成解决方案的思路。

编制解决方案的最佳地点是在客户现场。有任何问题，项目经理都要快速和客户沟通，群策群力解决问题；除非碰到一些新的棘手问题，才需要回总部沟通。

要想让客户得到认同，最佳方式是项目经理在编制阶段就让客户参与进来，而不是单纯让客户变成解决方案的审核者。

编制解决方案时，项目经理一定要要求自己把一个完整的业务流，从原始输入到最终输出，按真实流程全部覆盖到。特别是在客户不具备对解决方案审核能力的情况下，不能贪图快，用模板快速改造一个解决方案给客户。

解决方案编写一定要用心、用脑、用时间来做。一旦做清楚了，项目经理应该感觉整个项目的很多细节连成一体，这才是方案质量到位的感觉。

如果一个项目经理感觉解决方案写不下去，就要赶紧补充业务调研或者内部讨论，找到解决对策，再去构思解决方案。

在编制阶段，项目经理要反复根据内容和思路与客户提前沟通，让客户明白我方公司的业务组织思想和产品功能关系，逐步建立客户对解决方案的判断能力。客户参与得越多，对解决方案的理解就越到位，提出有价值的建议就越多，解决方案达成一致概率就越高。

不怕解决方案讨论反复进行，这个阶段反复越多，后期实施效率越高。一定要组织现场会议反复讲解，与业务骨干达成一致。越是关键问题，越不要回避或者模糊化。要谈清楚管理思路和实现方案。解决方案做的越细致，后续变更就越少，整个项目受控的可能性就越大。

项目经理不要只通过纸质方式交流，一定要采取面对面详细讲解、反复讲解的方式。而且不仅要对客户讲，首先要在项目组内部就解决方案思路达成高度一致，确定可行之后再来说服客户。

在讲解决方案的时候，应该准备符合企业实际情况的原型系统，让主要业务客户亲自感受，操作后给出对整个方案的合理评价。必要的时候可以先就解决方案中部分成熟内容达成一致，先行实施，防止出现因为部分业务不能达成一致而导致整个项目停滞不前的风险。

在完成了业务调研和解决方案制定之后，就开始做项目计划。

计划可以提供一个基本框架和方向，即使在不断变化的条件下也能组织思路和资源，预见和应对可能的变化。正因为计划没有变化快，才更需要做计划。

项目经理作为团队领导者，不应该直接管人管事，而应该管计划。团队成员不应该按照领导者的指示做事，而应该按照计划做事。项目也不应该被领导者管着，而应该被计划管着。

计划是花费最少、影响最大的工作。用较多的时间为一次工作做计划，做这项工作所用的总时间就会减少。

项目开始之前，必须回答这么几个问题：

必须做什么？
谁来做什么？
存在什么不确定性？
必须做得有多好？
应该怎么做？
什么时候必须完成？
哪些工作需要外包？

同样，项目经理也应该对计划制定过程本身进行计划，而且计划的执行者也应该参与制定计划。

计划制定的第一规则是随时准备重新做计划。换句话说，就是需要进行风险分析，预测最可能发生的障碍。在此基础上制定备用计划，在原计划不起作用时启用这个备用计划。

在做计划的时候，无论做什么都要定义目的，从目的定义入手，制定问题陈述。而且要重点关注项目的工作分解结构，实现分阶段编制计划。

计划一旦制定出来，就应该送交相关人员签字。相关人员签字，表示他承诺并认同了自己需要完成的工作范围，并接受技术规范等。

在项目计划审查会议上签署计划，比通过邮件方式签署效果要好很多。同时，为了保证计划的执行效果，应该鼓励人们在审查会议上指出计划中的漏洞，而不要等到问题产生以后再来解决。

项目经理应该只要求对项目负责任的人进行签署，不负责任的名字不应该出现在签署栏。

项目计划制定完成后，需要对项目计划的有效性进行检查：

是否满足合同中的需求？
是否已经计划项目建议书/项目任务书里规定的活动？
是否已经有项目任务书和项目启动会议纪要？
计划中是否明确了重大里程碑？
重大里程碑设置得合理吗？它们和回款时间对应吗？
是否明确了所有的假设和限制条件？
是否明确了成本、进度、质量目标？
项目计划满足合同规定的进度吗？
是否定义了重新修订计划的准则？
有费用计划吗？是否将费用分配到了每个重大里程碑上？
明确了交付成果的评审方式吗？
明确了公司质量管理体系对项目的检查点吗？
资源计划中，明确了资源的要求、资源占用的起止时间吗？
有沟通计划吗？是否明确了沟通周期和提交物？
有内部培训计划吗？是否明确了培训需求、培训时间、培训方式？
有对客户的培训吗？是否明确了培训内容、培训完成标准和培训完成时间？
有度量计划吗？是否明确了度量项、度量周期、度量数据报告方式？
有 QA 计划吗，明确了 QA 活动内容、时间和依据的标准吗，明确了 QA 报告的形式和提交周期吗？
有配置管理计划吗？明确了配置管理工具、配置项、配置基准和备份策略吗？
有风险管理计划吗？是否明确了风险等级和风险应对措施？
客户手册的编写是否在计划中得到了体现？

计划要体现出对项目实施工作的策划。实施计划不能成为实际工作的流水账，必须有明确的里程碑。

在目标定义清楚的情况下，项目经理要充分考虑达到项目目标可以经由的策略，评估哪种策略在现实实践中最合理，并就这个策略与客户充分沟通，将项目总目标划分为各个里程碑目标。

设定里程碑时，很容易出现两个问题：

把行动当作目标。
把完成重要关键事件和里程碑的具体含义等同。

整个项目实施计划要依据解决方案确定目标。确定目标时，要能够在计划中清晰体现：多长时间、整个项目团队要完成哪些工作。

计划要保持一致性。实施计划中，把好的售前内容也统一纳入，最终做到授权方案和实施阶段的真实计划保持基本一致。

项目经理的工作就是想尽一切办法避免项目延期，而不是为项目进度制造种种合法的延期理由。不管错误是谁造成的，项目经理都要保证进度如期完成。

如果因为考虑不周和不可抗拒的因素导致项目出现计划延期，应该想办法在下一阶段加以弥补，使局部延期不至于形成整体延期。

项目经理应该非常熟悉自己所在公司的产品平均质量和平均交付周期。如果公司开发延期成为一种习惯，就必须考虑在这个边界条件下如何完成项目。

计划不要过于理想化，不要按照合同规定进度编制计划，要尊重规律和自己的能力，按照实际工作边界和资源来编制计划。

计划是大家对后续工作安排和分工的一种共识。所以一定要先在公司内部工作里，征求客户经理以及其他配合人员的意见。一些重点项目甚至要征求公司管理层意见。

要随时考虑有没有让客户参与进来。项目经理要敢于让客户参与项目，知道安排怎样的工作给客户做。如果可能的话，项目经理还是应该请客户一起编制工作计划。

计划是约束双方用一切办法保证最终里程碑目标按时间节点达成的工具。所以计划在执行之前，一定要让客户理解、同意并落实准备工作。

要在沟通中制定计划，最有效的方式就是面对面沟通，其次是打电话，最后才是邮件确认。

一个项目的实施计划还需要细分成各个阶段的子计划，每个阶段的子计划还要逐次分解为不同活动的现场和非现场工作计划。

每次现场阶段的工作计划应该可以看出隶属哪个里程碑阶段，以及完成后对里程碑起到怎样的促进作用。

最终的现场实施计划应该是团队每个成员在充分理解项目经理的全局计划之后，自觉依据全局计划推导和编制出来的结果，并经过项目经理和客户的认可。

制定好计划之后，就要设计风险管理策略。

对于项目经理而言，不重视风险就是最大的风险。一定要在每个项目启动阶段就投入全身心思考，发动所有人讨论，从最悲观局面设想计划风险，然后逐步考虑风险控制策略，最终完成整个项目。

有些明明存在但暂时不会显露的风险，可以选择不告诉客户，但私下里一定要提前着手解决。

风险有三个要素：

风险事件本身。
发生的概率。
产生的影响。

按属性分类，可以分为已知风险和未知风险。

分析风险需要的数据有 3 个：

风险事件发生的概率。
风险真的发生后，可能产生的后果范围与影响。
每个结果的可能性。

风险评估的公式是，实际风险 = 影响 × 可能性。

处理风险的可用选项通常有四种：

将风险转移给第三方。
了解风险，在风险发生时给予解决。
降低风险发生的可能性或影响。
尽力将风险解决。

一旦确定了风险的应对策略，就要将其编写成风险管理规划，这样便于向主要相关利益方及团队成员传达信息。要基于对相关利益方的尊重和负责，对高分风险项和盘托出。如果风险失败的概率很大，要告知相关利益方，并向团队解释风险管理规划。

设定风险管理策略之后，就要设计沟通计划。沟通计划包括确定利益相关方的信息和沟通需求，也就是要回答四个问题：谁需要什么？什么时候需要？怎么将信息提供给他们？由谁提供？

项目经理绝不能假定别人喜欢的沟通途径，必须使用一套可靠的沟通系统。首先要考虑多少人希望收到信息，以及怎么做才能抓住别人的注意力。

沟通计划有五大要素：

内容或沟通类型。
发起者。
接收者。
方式或渠道。
时间或频率。

在设计项目沟通规划之后，要与项目团队和核心利益相关方分享，并在这些人的日历中加入沟通提醒，同时也要确保自己按规划执行。

设计沟通计划之后，就要设计项目日程表。

日程表应该是可视的、持续更新的，同时要对项目成员开放。要包含完成项目所需的全部关键任务和里程碑。可用形式有项目进度网络图、甘特图、里程碑图。

整个流程分为六大部分：

制定 WBS。
根据依存关系为工作排序。
确定项目团队。
估算每项工作的时长。
确定关键路径。
设计项目预算。

首先是制定 WBS：隐性工作显性化，显性工作结构化，结构工作标准化，是提高组织效率的必由之路。所以必须通过 WBS 分解告诉大家，项目总目标是可行的，可以通过一个又一个小目标的实现走向最终胜利。无论是总目标还是阶段目标，应该让每个项目成员感觉这是一个不会做不到、也不会太轻松完成的目标。

在 WBS 中，每个阶段的工作目标应该用文字精确表述，让每个人对每个阶段工作的目的有明确、无歧义的共同认识。

WBS 所有计划都是双方团队成员共同讨论确认后的结果。常见的 WBS 类型可以按分解方式来区分，而分解方式可以按组成、功能用途、生命周期、地域或组织这四个维度来分解。无论选择哪一种方式，都必须考虑 WBS 的用途和表示方式。

WBS 里的里程碑事件应该是项目进入一个阶段后不能倒退的标志，由项目经理来设计里程碑。

一个错误的里程碑划分方法，是把一些项目中发生的大事件当作里程碑。WBS 是以可交付成果为导向的分解，而不是以活动为导向的分解。必须确保项目的里程碑一旦达到，项目就无法退回到里程碑之前的状态。

WBS 分解粒度要和项目成员能力、项目成员的能动性相匹配。一般而言，WBS 中计划分解得越细致，具体工作就越简单，可胜任项目工作的人越多，完成把握越大。

在复杂项目里，不可预期的因素太多，要求项目经理能把握每个项目组成员的特点，了解项目突破的关键瓶颈和障碍，以此编制出大小合适的任务包，分配给不同的项目组成员。

如果是自上而下，也就是从 WBS 的顶部开始分解可交付成果，执行步骤是：

确认项目将要交付的最终产品、服务或成果。
定义为完成每个第一层级组件所需要的主要交付成果。
把每一个主要可交付成果分解至恰当的详细程度。
评估核实 WBS，直到被批准。

如果是自下而上，也就是从底层的工作包开始，向 WBS 顶层汇总项目工作，执行步骤是：

确认 WBS 中的全部工作包。
有逻辑地把相关工作包归并到一起。
把可交付成果汇集到更高一个层级，也就是母层。
重新分析工作，确保所在分支的所有工作都包含在 WBS 中。
重复开展汇集和分析工作，直到把所有组件都汇集到第一层级，并且 WBS 中包含了 100% 的工作。
评估和核实 WBS，直到被批准。

最底层组件一定是交付什么，也就是具体的交付成果。

在 WBS 中，每个工作包都应该有自己的名称。名称应该是名词、形容词加名词，或名词加动词这三种组合，而不应该是一个单纯的动词。

WBS 的展示方法分为两种：

树形层次结构：更适合向高层管理者汇报工作和沟通。
阶梯缩进表格：更适合项目团队成员自己使用。

一个好的 WBS 应该既不重复，也无遗漏。通过确认 WBS 下层的组成部分是完成上层相应可交付成果的必要且充分的工作，来核实分解的正确性。最底层工作包应该分解到信息透明的层次，以此可以估算工作包的工作量，以及完成工作包所需的时间、成本和验收标准。

一般情况下，单个工作包的完成时间不应该超过 80 个小时，也就是以任务分配的第 10 个工作日为期限，分配的任务总的来说不应该超过两周。单个工作包应该只分配给一个责任人，以避免推诿扯皮。

要在未来才完成的可交付成果或子项目，当前可能无法分解。项目管理团队通常要等到这些可交付成果或子项目的信息足够明确后，才能制定出 WBS 中的相应细节。那么，对于近期的任务应该进行更为详细的规划；对于较远期的任务，规划可以相对粗略，涵盖的细节比较少，强调的是总体方向和战略目标。

而且，不同可交付成果要能被分解到不同的层次。过细的分解会造成管理努力的无效浪费、资源使用效率低下以及工作时效率降低。应该由项目经理来决定 WBS 的结构和细节水平。最后，每一个下级组件有且只有一个上级组件。

综上所述，考察 WBS 质量的标准有以下几点：

以可交付成果为导向。
包含所有的可交付成果，包括项目管理。
涵盖了 100% 的项目工作。
每个下层组件都包含上层组件 100% 的工作。
每个工作包的名字都是用名词、形容词加名词或名词加动词这三种组合来命名的。
以层次结构图或者阶梯缩进的表格展示给各相关人员。
负责具体工作的执行者参与了 WBS 的创建。
征求了相关专家的意见。
得到了相关人员认可或批准。
建立了 WBS 词典。
随着项目工作的渐渐明细而更新。
随着项目工作的变更而更新。

所谓依存关系，也就是一项工作依赖于另一项工作。总共有三种类型：

结束开始：必须完成前一项工作，才能开始下一项。
同时开始：一项工作的开始，就意味着另一项工作的开始。
同时结束：有些工作要在其他工作结束后才能结束。

确定项目团队时，总原则是用目标来决定团队。一个项目必须有多人参与，不要让一个人长期做一个项目。而且一个项目不允许只有一个实施顾问长期维系，必须想办法协调至少两个人参与。

估算每项工作时长的总原则是：工作不能等同于时长。工作即完成一件事所需要的时间，决定了项目的预算；时长即在现实生活中完成一件事，并同时做完其他杂事总共需要的时间，决定了项目的时间规划。

对 WBS 中每个工作包，请最熟悉该工作包的人基于历史数据进行估算。有三个不容忽视的问题：

WBS 分解正确吗？
各工作包估算准确吗？是否加入了水分？
会不会有人为了保证自己或项目安全而注入水分？

如果截止时间设计得不合理，可能会导致整个项目失败。千万小心，不要把任务排得太紧，以至于没有任何灵活或回旋的空间，至少要提供一个喘息的时间。

在任何情况下，如果已知在规定时间内不可能完成任务，就不要轻易做出承诺。如果真的遇到时间紧急的情况，就要让领导对优先项进行排序。

可以使用 PERT 公式来决定每项工作的时间：预计时间 =（乐观时间 + 最可能时间 × 4 + 悲观时间）÷ 6。乐观时间即工作完成所需的最短时间，悲观时间即完成工作可能需要的最长时间。

关键路径即项目从开始到结束所需要的最长路径，以及在不导致项目延期的前提下，每项工作开始和结束的最早及最晚时间。关键路径上的工作，其开始和结束时间的决定没有任何灵活可言。如果关键路径上遗漏了某项工作，那么将面临极高的失败风险，并导致费用超支以及项目节点延后。

确定关键路径时，要将最好的资源分配给关键路径工作。要时刻关注关键路径和其他较为灵活的工作，以便在关键路径工作遇到麻烦时，尽快将资源调配给关键路径项。

想避免关键路径中出现瓶颈，可以把关键路径工作分配给最值得信任、最有才华、最可靠、最负责的成员。而且要保证不止一个人能够完成关键路径工作。在项目日程和预算允许的条件下，应该训练团队成员完成不止一件工作。还可以通过小型确认会来保证项目按规划进行，最好可以发动客户企业力量参与。

通常使用甘特图来寻找关键路径。制定步骤分为三个步骤：

明确项目活动的各个属性。包括：活动代号（即一个简短且唯一的活动名称或标志）、活动持续时间（即活动从开始到完成的时间长度）、最早开始时间（即某项活动能够开始的最早时间，只决定于项目计划，只要计划条件满足就可以开始的时间）、最早完成时间（即某项活动能够完成的最早时间，计算公式为最早开始时间 + 活动持续时间）、最迟完成时间（即为了使项目在要求完工时间内完成，某项活动必须完成的最迟时间）、最迟开始时间（即为了使项目在要求完工时间内完成，某项活动必须开始的最迟时间，计算公式为最迟完成时间 - 活动持续时间）、浮动时间（即最早完成时间和最迟完成时间之间的差值，计算公式为最迟完成时间 - 最早完成时间）。
按照各活动间的紧前关系，绘制进度网络图，并确定关键路径。这里可以采用顺推和逆推的方法。顺推，即依次计算各个活动的最早开始时间、最早完成时间。当某个活动有多个紧前活动时，当前活动的最早开始时间取所有紧前活动中最早完成时间的最大值；逆推，即通过依次计算各活动最迟完成时间、最迟开始时间，来反向推断。当某个活动有多个紧后活动时，当前活动的最迟完成时间取所有紧后活动中最迟开始时间的最小值。
压缩关键路径，主要措施有三种：并行（把正常情况下按串行展开的工作改成同时展开）、加班（必须让关键路径上的人加班，一定安排费用增加最少的人加班，以完成对应工作）、增加投入资源。

在确定关键路径之后，可以把关键路径分配给最得力的人选，绝对不能分给新手或能力较差的人，否则会大大增加风险。

设计项目预算时，可以把费用分类为外部费用、内部费用，以及内外部费用总和 10% 的杂费。

外部费用是需要从公司外购买的所有资源，包括外部供应商的所有账单。

内部费用包括每个核心项目成员及项目外人员需要花费的时间，需要用每个人的工作时间乘以该员工相应的小时费用。

算管理的时候，要将项目总预算分摊到项目各项工作中，并为每一项工作建立成本预算。

另外一种方式是，项目组为每一阶段建立预算基准。把预算成本分配到各阶段具体工作中，并根据组成该阶段的各活动进度，按月列支。

资源要先集中，再分散。投入资源来缩短瓶颈阶段，方便改变业务的管理模式。

实施双方要在重点实施阶段重点投入资源，让客户在实施关键突破阶段投入的时间减少到最低，进一步降低客户投入成本和风险。

如果项目投入人力资源也无法解决任何问题，项目经理千万不要因为客户抱怨就轻易派人去现场。要先把压力扛下来，争取资源解决客户关注的问题后，再派人过去。

除非去现场让客户发泄一下，做情绪疏通工作，否则宁可得罪客户，也不到现场做无意义的工作。