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

作者： techrepublic.com.com
Thursday, May 20 2004 9:55 AM 如果一个项目的复杂程度没有达到令人难以置信的地步，那么不妨采用一下关键途径分析（Critical Path Analysis），它提供的是一种几乎完全非技术性的项目管理方法。


对于一个项目的最终成功来说，于项目的时间安排是怎么强调是都不为过份的。来自Standish Group的"噪声报告（Chaos Report）"和来自KPMG Canada的一项名为“不成功的信息技术项目问题在哪儿？”的调查均认为：项目时间安排的不合理是造成项目失败的主要原因之一。

现在市场上有很多功能强大的工具可以帮助管理人员对所有类型、所有规模的项目进行管理，Microsoft Project就是其中的一种。应用这些工具可以对资源进行分配，完成报告的制作，并且对各项任务进行时间规划。但是，由传统的水平线和里程标所构成的标准的Gantt图表并不是对项目中所有任务进行表示和分析的唯一途径。Critical Path Analysis（CPA）是项目经理们可以应用的另外一种有价值的工具。

连点成线
要完成CPA，不需要应用价格昂贵的项目管理软件，只需要借助一支铅笔和一张纸就够了。当一个项目处于格式化的阶段，基本的任务都已经确定的时候，这种方法就尤其有效了。如图A所示，每项任务在得到确定之后都可以用一条直线来表示，在直线的两端各画上一个圆点，分别代表任务的起点和终点以及预计所需的完成时间。

图A：


与Gantt图表相同，图A中的直线起于左端而终于右端，所以有些人喜欢在右端标上一个向右的箭头，如图B所显示的那样。

图B：


数据库应用实例
下面就让我们以一个简单的数据库应用项目为例，来对CPA进行说明。

如下所示是一个简化了的任务清单和预计的完成时间：


必要准备：1天

设计数据库：3天

创建数据库：7天

创建观察点：2天

创建存储程序：2天

设计类别：2天

业务规则编码：4天

CRUD操作编码：5天

错误日志编码：2天

设计GUI：7天

创建菜单：3天

建立应用导航：3天

创建数据输入窗口：4天

建立用户注册：2天

创建报告：4天

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

图C：


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

图D：


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

图E：


图F：


图G：


图H：


图I：


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

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


必要准备：1天

设计数据库：3天

创建数据库：7天

创建观察点：2天

设计类别：2天

CRUD操作编码：5天

设计GUI：7天

创建数据输入窗口：4天

创建报告：4天
完成以上各项任务，所需要的最短时间共计为35天。

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

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

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


CRUD操作编码：5天

设计GUI：7天

创建数据输入窗口：4天
总计时间为16天。

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

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

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

【 发表评论 0条 】