上回说到项目经理授权后的第一步动作，将需求转化为了具体的任务。但是光有任务还远远不够。对于任务还需要有一个大致的估算，这是在具体活动出现前的估算。明确任务层级的关键路径。通过任务估算和关键路径，可以获得项目里程碑。

所以第二步动作是在任务的基础上制定粗略的计划。当前我们手头上有以下信息：

1. 项目章程

2. 大而粗的项目时间节点

3. 干系人列表

4. 工作分解结构 （WBS）

5. 工作分解结构词典

6. 项目范围说明书

7. 需求管理计划

8. 需求跟踪矩阵

而做完第二步还将得到基于WBS的工时估算，项目的关键路径以及项目里程碑。大致的流程如下：

《一》工时估算

这步的输入是工作分解结构，而输出是基于工作分解结构的工时估算。

对于一个项目来说，工时估算一般会有三次，

第一次发生在投标之前，需要估算项目成本。

第二次发生在项目启动会议之前，主要用于制定项目里程碑。

第三次会在启动会议之后，用于制定项目计划。

区别在于详细程度逐次递增。第一次是非常粗略的估算，可能是基于历史数据，也有可能是拍脑门得出的结果。第二次是在任务明确的基础上的估算，精度会上升很多。第三次是基于活动的估算，此时的估算是项目计划的基础，需要非常精确，一般推荐三点估算方式进行。如果今后遇到项目需求变更，也需要使用三点估算进行估算。

现在回到基于工作分解结构的估算上来，对于此时的估算，多数使用的是基于历史经验，历史数据的类比。如果做房屋装修，对于项目经理来说，基本明白粉刷墙壁，铺设地板，排布电线水管等等工作大致需要的时间。这些都是从历史经验上类比而来。

也许你会说那不是很不精确吗？的确，在这个阶段的估算并非十分精确，也没有必要。原因在于：

1. 此时的项目需求也是比较粗略的，具体需求细节并未确定。

2. 项目资源并没有明确，也就是说，在什么阶段需要什么样的资源，资源的个数都么有最终确定。

项目管理三角形中两项要素都存在变数。自然此时的估算带有大的误差是可以理解的。

那么这样一个不精确的估算的意义是什么呢？

在于被否定，被更新，逼近真实的情况。

这就好比定位一样，当要找一个人的时候，起先定位到他在中国，那就不会去美国找。而随着时间的推移，发现他在中国上海，那就不会去南京找。最后发现他在中国上海的外滩，那就不会去外滩找。

估算也一样，随着需求的明确和深入，对于估算的也随之越来越准确。即使之后的估算推翻了之前的，这种情况经常会有，但是至少因为之前的估算，任务得以继续，不会举步不前。

于是在完成估算之后，对于每一个任务都有一个完成工时的估算。

《二》明确关键路径

同样的，工作分解结构中把任务进行了系统的罗列，基于他，可以产生项目关键路径。

对于任务，可以分为两种，一种和其他任务没有关联，相对独立。另一种需要以完成其他任务为条件。对于第一种任务，只需要安排人做完成即可。而对于第二种任务，就需要根据其前置条件，制定任务拓扑图。

在这个阶段，需要将工作分解结构中所有任务，都放置到拓扑图上去。如果两个任务有关联，需要标明之间关系。比方说粉刷墙壁的任务需要在水泥干后才能开始，那么在这两个任务上就需要有带方向的箭头标明先后关系。

下图为关键路径拓扑图的一个例子：

方块内为任务，以及需要的工时，连线标明任务的关系。

当把所有任务都罗列到拓扑图中去之后，需要计算每条线路的时间，而时间最长的那条代表项目完成的最短时间，即项目的关键路径。

值得注意的是，随着项目的变化，需求的变化，资源的变化，关键路径是会发生变化的。这需要项目经理时刻对于项目有个整体的把握，尤其在关键路径上。

关键路径的变化代表着工期的变化。并不是所有任务的延期都会造成项目交付的延期。但是关键路径上任务的延期，必然造成交付的延期。

《三》确定项目里程碑

当经过工时估算和关键路径确认之后，我们得到了每个任务的工时以及任务和任务之间的关系。同时在工作分解结构中，对于任务有了阶段层级的归类。这在账户编码中可以体现见下图：

在1.x这个层级1.1.1与1.1.2必然都属于需求评估阶段，而 1.1.1和1.2.1，必然不属于同一阶段，因为评估和开发不会混在一起。

所以根据不同的账户编码，可以将任务归类，而归类的粒度可以根据账户编码得以控制。

于是在关键路径拓扑图中，可以加上账户编码。从中根据需要的粒度，提炼出各个阶段所需要的时间。

拿软件开发举个例子，对于一个完整的项目，会有如下的工作分解结构：

这里不妨做一个资源的假设，即我有一个BA做需求文档，有一个资源做页面设计，一个资源做数据库设计以及一个资源做服务层设计，相应的，设计人员兼顾开发。有一个测试，以及一个资源专门负责部署。

对应的关键路径拓扑图：（下图的关键路径看出来了吗？是 1.1.1 -> 1.4.1->1.4.2->1.4.3->1.5.2 哦）

于是得到了以下结论：

需求分析： 5天

设计： 2 天

开发： 2天

测试： 15天

部署：1天

结合最开始的大而粗的项目时间节点，获取客户要求的交付日期，倒推各阶段的开始结束时间。如客户要求11月30日交付。那么可以得到如下结论：

部署： 开始时间 11月30号，结束时间 11月30号

测试时间：开始时间 11月9号，结束时间 11月29号

开发时间：开始时间 11月13号，结束时间 11月15号

设计时间：开始时间11月9号，结束时间 11月10号

需求分析时间：开始时间11月2号，结束时间11月8号

从而得到了各个里程碑时间。

最后，还需要和当前客观情况进行对比。问问自己，可行吗？显然如果今天是11月13日，这个计划是不可行的。按照当前资源来说，需要在 11月2号开始需求分析。实际上是13号。于是在不更改交付日期的前提下，需要增加资源。

大致方案如下，增加为2个BA，缩短需求分析的时间为3天。开发人员不变，测试人员增加为2人。于是对应的拓扑图发生了变化，关键路径也发生了变化（1.1.1->1.2.1->1.3.1->1.4.2->1.4.3->1.5.2)

于是再次根据交付时间倒退里程碑得到如下：

部署： 开始时间 11月30号，结束时间 11月30号

测试时间：开始时间 11月20号，结束时间 11月29号

开发时间：开始时间 11月21号，结束时间 11月22号

设计时间：开始时间11月17号，结束时间 11月20号

需求分析时间：开始时间11月14号，结束时间11月16号

这个计划按照当前是11月13号的情况下，是可行的了。于是我们得到了项目的里程碑。