项目管理新方法—关键途径分析

必须有始有终
在列出了上面所示的清单之后，接下来要做的就是排列各项任务的完成顺序。在我们所举的这个简单的例子当中，在数据库设计完成之前，是无法进行数据库的创建的，但是一旦数据库创建完成，其他的一些任务，比如观察点和存储程序的创建，就可以同步进行了。如图C所示，当一项任务的开始要依赖于另外一项任务的完成时，代表该项任务的直线的起点就应该设在另外一项任务的终点。

当多项任务同步开始进行时，代表这些任务的直线就可以变成从同一个起点开始，到同一个终点结束的曲线，如图D所示。这里就没有必要一定要用直线来表示了。

应用这种方法，我们现在就可以建立一个包含了所有任务的图表。如果你手头现在有一张比较大的纸，你就可以做一个比较大的图表，从左向右依次表示各项任务。你还可以做一系列比较小的图表，就像我在图E、F、G、H、I中为大家演示的一样。

确定关键途径
接下来要做的就是对已经做好的图表进行检查，按照从点到点的方法把最长的途径连接起来。这就是我们所说的关键途径：要完成所有必须完成的任务可能花费的最短时间。

在我们举例的这个数据库应用项目当中，关键途径是：

完成以上各项任务，所需要的最短时间共计为35天。

要在我们制作出的图表上确定出关键途径，最简单的方法就是使用着重色。着重表示那些需要单独完成的任务和那些可以同步进行的任务当中耗时最长的任务。大家现在已经知道，各项任务必须要绝对按时完成（或者更快）。在关键途径上的任何一项时间推迟都会造成其他依赖于它的任务完成时间的推迟，进而造成整个项目完成时间的推迟。在关键途径上的项目应该交给那些你最可以信任的、最可靠的人来完成。那些需要时间较短的平行项目相对来说条件比较宽松，可以交给那些经验不太丰富的员工去完成。在这些相对较为宽松的项目完成之后，富余出来的资源可以被应用到那些关键途径上的任务中去，更好的完成这些任务。

调整变化
在项目的进行过程当中，你可能会找到一些途径，对任务进行调整变化，或是为了保证项目的按期完成而把一些任务从关键途径上转移。你可能还会找到一些途径来缩短整个项目的工期。在我们上面所举的这个例子当中，如果我们决定在进行CRUD操作编码、业务规则编码和错误日志编码之前进行类别设计并不重要，那么这四项任务就可以同步进行，这样一来，完成关键途径上的各项任务所需要的时间就缩短了两天。终端用户的培训也可以更早的开始——比如说可以在GUI的设计完成之后——但是这项任务的预计完成时间本来就已经很宽松了，所以改变它的起始时间并没有多大的意义，不会在整体上节省项目时间。

如果在开始制表的过程当中你忘记了某项要完成的任务，可以在制表过程完成之后将这项任务加进去。比如说，在上面所举的数据库应用项目的例子当中，我们忘了DLL编码这项需要五天时间来完成的任务。把这项任务需要依赖的前一个项目的终点当作这个项目的起点——在我们所举的例子当中，前一项任务就是类别设计。把要依赖这项任务的下一项任务的起点当作这项任务的终点——在我们所举的这个例子当中，下一项任务就是终端用户培训。在添加完这项任务之后，重新对两点之间的关键途径进行审查，看看新添加的项目是否会对两点之间的项目时间产生影响。现在，两点之间的关键途径上的任务包括：

总计时间为16天。

由于完成两点之间的关键途径上的各项任务一共需要16天的时间，远远超出了完成新添加的任务所需要的五天时间，要完成这项新任务的时间条件就非常宽松了，因此，新任务的添加不会给整体的项目时间带来影响。如果完成新添加的任务所需要的时间要比完成原来的关键途径上的任务所需要的时间长，那么新添加的任务也就成为了新的关键途径上的任务了，整个项目的预计完成时间也要相应的延长了。

利弊分析
尽管从理论上来说，应用我们所介绍的这种简单的方法进行时间规划的任务的数量是没有限制的，但是，当可以同步完成的任务的数量很多时，情况可能就会比较混乱。与此同时，一些大的调整变化，比如说同时添加多项新任务，可能会使图表的重新制作成为必须。

尽管如此，从另外一个方面来看，CPA仍然不失为一种对项目进行时间规划和追踪的快捷方式。特别是在一些小型项目上，它的应用就尤其具有吸引力。因为那些专业化的项目管理软件对于小型项目来说不是大材小用了，就是根本没有什么用处。