项目管理阅读材料

项目管理与实施方法专题课程

项目管理阅读材料

项目管理历史简介

想象一下：你公司的一个重要客户委托你完成一项复杂的全球性市场研究，

以作为全球拓展战略的基础。或者你将负责一项产品的开发，该产品将会决定你

们公司是否有上市的能力。或者你负责处理你们公司与另外一家公司的合并。在

进一步想象一下，在上述这些情景中，你接受的预算很紧，进度安排很精确。这

样，你就参与了项目一并且，是项目管理。你必须得根据进度表和预算来完成交

付物，通常情况下，进度安排得是非常紧，预算也是固定的。

因为项目管理的重点是特定的结果（交付物）、时间和（进度表），资源（资

金，人员等），故有一系列的技术和过程来帮助人们有效地管理这些方面。本模

块将向各位介绍这些技术和过程。

项目管理的起源

弗雷德里克3></a>.泰勒（1856-1915）是第一个科学地研究”工作”的人，

并且也是第一个考虑流程设计的人。直到二十世纪五十年代初期，许多项目管理

方法才汇集成一套一系统：这样极为复杂的努力主要是因为美画国防部为了开发

北极星导弹。包括享利・甘特为管理军队的后勤而创建的甘特图在内，这些方法

对如何管理专家进行工作的交接、如何管理进度表等方面所牵涉到的错综复杂的

事物而方刺至关重要的。可喜爱覆毫不夸张地说，处于这些努力的中心位置的是

项目的“作战室”，赫然陈列着巨大的计划评审（PERT）图。

紧随着军队步伐的是汽车行业和电影行业，以及私营的和公用的工程组织.所

有的行业和组织都需要创造独一无二的结果,他们发现项目管理技术帮助跨职能

的团队定义/管理和执行那些为了达到这些目标而需进行的工作.早期采取项目

管理的实践者除了运用诸如直方图和网络图这类的技术外,还运用了项目生命周

期的概念，并在生成更为复杂的工作任务分析表（工作任务分析表:work

breakdownstructure）时，吸收了这种概念。工作任务分析表综合确定了为了达到

某个目标而需完成的单项任务。

最近，随着新的项目管理方法（如：如何创建跨职能的进度表、管理共享的

资源、调节项目组合）涌现，个人电脑的广泛使用以及项目管理软件工具的复杂

程度和有效性的增加，解决不同项目问题的方法论的有效性也随之增强。

项目的日益重要性

然而我们所考查的不仅仅是项目管理有效性的改善。其他的力量结合在一起

也使得对这些方法的使用猛增。管理和降低产品周期的竞争压力在剧增，正如很

多市场的全球化也在增加，人们日益认识到项目是组织和战略目标和不同职能部

门完成的战术性实工作之间的关键纽带。因此，象计算机制造业、咨询服务业、

医药行业、复印业和自然管理业这些不同的行业都积极地实施项目管理。这些行

业以及其他的知业将项目管理作为一种创建未来的方式，因为可以更好地理争顾

客的需求和满足需求的解决方案。另外，项目管理对公司底线利润也有很强的影

响。

一项国际研究发现“当公司对开发前期的重视程度增加后，新产品商业化取

得成功的可预见性的比例可增加2倍。”当开发前期活动增加（主要是指项目定

义和规划），产品成功的几率也会增加。一引起区分成功和失败的关键因素有：

“赢家在开发前期活动上所花费的资源是输家的两倍以上”

71%的新产品开发受到耽搁，是由于对顾客需求的定义和理解不足。

改变产品的需求比其他任何原因更易造成产品开发中更多的延误。

项目管理也会影响底线利润，因为它有助于跨部职能团队更聪明地工作。项

目管理抛开公司的组织结构，提供了有效的基础设施来定义，计划和管理项目工

作，使用权得团队更好地利用成员的个人优势。在专业化的职能环境下或者是高

度矩阵型的环境下，项目管理尤其有用，因为它根据明确定义的项目合作和贡献

业务活动来进行专业分配，并阐明了模糊不清的角色和职责。因此，正如某个作

者所评论的，“团队成员获益于为项目规划/任务的估计和识别提高机会（如本应

多花或者少花些时间的业务活动）而编制的总结数据。数据为小组的开发流程提

供了量化的理解，并且也提供了监控流程的一种方法。很多团队成员将他们认为

应花费的时间的领域进行比较，受到了许多启辿。"（Wiergers,1994）。

同样，“成功的公司已掌握了将人的意愿力与组织融合在一起的艺术。但组

织生命力的关键是他们一流的选择、指导并完成开发项目的能力，这些开发项目

是企业复兴和变更的基石。那些可以持续重复这种过程的公司如同发现了制造商

的永动机。"（Bowen,Clark,Holloway&Wheelwright,1994,P14）.

另外再举…个例子说这方面的影响。集成项目系统进行了两项研究（未公

布），一名计算机制造商通过为重复的项目创建了一个项目计划的模板，在项目

管理中获得了500%的投资回报率。另外一家公司在早期开掉了一个有问题的项

目，估计的投资回报率达900%。实施项目管理而带来的投资回报率看起来是很

重要的。

项目管理过程综述

项目管理是一门正式和管理学科，运用系统的、可重复的以及规模可变化的

过程来计划项目和执行项目。我们可以这样定义项目：

在特定的起始时间和结束时间内、用特定的资源分配，产生确定的结果的一

套独特的业务活动。

因为项目受到其结果、时间和资嫄的限制，我们通常需要在这三个因素（或

者项目“因素”）之间作出权衡。因此，项目管理是每个参数产生大量的、系统

的数据的这第一个过程，以保证在参数之间作出权衡的决定更有效。因此，项目

管理过程是一系列的步骤，通常由“项目管理过程模型”来表示。

我们在哈佛商学院使用的项目管理的模型见图-1。模型由三套总体活动组成

（项目定义和组织，项目规划以及项目的追踪和管理）。每套总体活动又由一系

列用于定义/计划和管理项目的步聚组成。

项目的定义和组织

一个项目的成功通常取决于其目标和清晰性以及团队成员从事项目活动的

协调性。我们因此可以假设，为了有效地完成项目，我们需要知道目标、需要知

道为了完成目标而作为一个团队来工作的人员以及了解他们将会台何工作。但是

设立该假设是有很多原因的。

虽然所有的行业都同意在项目开始前定义项目的目标和组织是至关重要

的，但很多项目的失败就在于所界定的项目期望结果存在问题，并且对需完成项

目的组织和步骤也了解也了解不足。因此失败的项目的比例是令人瞠目的。人们

令人沮丧，频繁地完成的是“错误”的项目，最好地情况表现为结果不尽人意，

最差的情况则是完全地浪费了时间和资源。在大多数项目环境中，分工不明，会

议无成效、沟通不畅和人际冲突司空见惯。因此，即使花较短的时间来明确地定

义和组织项目也能带来很好的效益。关键的步骤有：确立项目组织，定义项目参

数，计划项目框架以及汇集项目定认文档。这些步骤定义了项目的“谁”、“什么”、

“如何”。在接下来的儿节里，我们将更详细地论述这一点。

项目规划

项目的主要冲突来源在于项目应在“什么时候”完成和缩短该时间所牵涉的

风险之一•间的紧张关系。项目组以外的管理者总是一直对该项目的进度要求非常

苛严，但项目组成员则会意识到这样做的困难。针对这一矛盾的解决方法是制定

可信的项目计划。

可信的项目计划是基于可靠的，系统的过程之上，高层管理者可以了解和信

任进度表。并就项目的权衡作出更好的管理决策。因此，由于既拥有一个可信的

进度表又有风险管理计划，与客户紧密合作的咨询公司在得知其可能会错过公司

一个关键的日期时，能够系统地缩小其企业再造范围。该录活性不仅对于某一工

作很重要，还挽救了公司与客户之间的关系。

相反地，根据猜测、自上而下的压力或者没有考虑风险而制订的不可信的以

及无法预测的进度表，会造成财务上的灾难。在某一家公司，一项未精密考虑的

进度表使得一项新产品在未成熟时就宣布了。因此，造成老产品的购买在新产品

推出之前18个月就枯竭了。结果是什么？公司在宣布新产品之前的市场份额是

第一的，然后却持续10个季度的亏损，市场份额降为第三位。

系统的规划过程给决策制订者提供了具体的数据，使得高层管理人员的决策

制订的更加有效。项目规划中的关键步骤包括：编制工作任务分析表，编制进度

表，分析资源以及编制风险管理计划。这些步骤帮助项目经理和项目给确定为了

完成项目的目标而需完成的任务、每项任务需要花费的时间，任务的最优顺序，

项目会进行多长，资源将如何影响进度表，以及项目牵涉到哪些主要风险。因此,

项目组的所有成员不仅仅知道他们自己所从事的项目方面的工作，也知道他们的

小组同伴们的任务和进度。在接下来的几节里，我们将更详细地论述这一点。

项目的跟踪和管理

“根据计划管理”看起来是个非常简单的概念。但是，大多数情况下，一旦

做完了计划（如果作了计划），项目管理通常就会停止了，因为“完成工作”的

推动力占了主导。项目本身的动力占了主导。团队成员觉得于管理无形的过程式

相比，更容易完成产生有形结果的具体任务。但是，不对项目进行跟踪，项目经

理和团队本身会失去收集关键项目数据并即时采取关系到成功的举措的机会。这

种情况通常的结果是降低了团队控制项目的能力，因此间接地削弱了他们的权威

和地位。相反，通常被项目管理人士认为是“额外工作”的项目跟踪和管理，实

际上给项目管理人员和团队成员提供了更多的控制，因此提高了权威和地位，从

而增涨了士气。

另外，一旦有了可信的计划，项目组不仅有了提供效率的工具，团队成员也

有了与原先的期望相比，系统地跟踪和管理他们所从事的工作的方式——因此

更会提高项目的效率。这样，我们就有可能非常精确地知道在某个项目中，哪些

工作已经完成了，为了完成目标仍需完成哪些计划的工作，以及需要采取哪些行

动来应对项目工作的自然动态，并且是不需要发生多少烦琐的间接费用就可以完

成的。这些方面之所以成为可能是由于过程的跟踪和管理给项目经理和团队提供

了高度具体的数据，因此能够在项目工作中高度集中地、间断地干预。

项目跟踪和管理的主要步骤有：状态搜集和结束项目。这些步骤使得项目经

理将重点放在必要时调整项目工作所需的信息上，并使主要参与人员了解过程，

利用从一个项目学习到知识来改善下一个项目的业绩。这些步骤将在接下来的几

节里详细论述。

关键流程点

图1中的过程模型虽然是按线性陈述的，但应循环地来考虑：即应反复多次

并自多检测。比如说，在“编制进度表”这一步骤完成的进度超过了在“参数定

义”阶段的目标进度。同样，”编制进度表”步骤中的任务顺序明细通常突出了

一些省略的任务，造成重新回到步骤“编制工作任务分析表”。过程模型自然地

检查计划，并提倡进一步完善，造成其可靠性和可信性也相应地增加。

我们现在来完整地描述模型中的每一节，分析一下其特性和活动。

项目规划和管理

项目的定义和组织

确定项目组织

对于任何一个项目而言，知道谁将做些什么事是非常关键的。确定项目组织

这…步骤的目的就是保证清楚地了解所有的角色和职责，对项目组的所有成员加

以确认并使之忠于项目工作。尤其是，该步骤保证确立了领导者（项目经理），

并明确他或者她的权威和职责。

确定项目组织的关键问题

谁是项目经理？

项目经理的职责是什么？

在哪些领域项目经理有决策权？

是否就项目经理的职责和权威达成一致意见？是否已记录下来并且发放给

了项目组?

项目组成员有谁？

每名项目组成员的专长是什么？

是否已认同了所有为项目工作的人？

项目组的职责是什么？

项目组的花名册是否已完成？

谁为该项目组筹集资金？向谁汇报？

确定项目经理传统上是大多数项目的第一步。最佳的项目经理应具备下列条

件：

优秀的激励者和领导者，指导并教授项目组的其他成员。

“全局导向的”

有效的沟通者。

优秀的组织者

以目标为导向的。

懂得项目管理的步骤，并且坚定地使用项目管理的步骤。

有效的项目经理不一定是技术上的专家：事实上，如果技术上的专家主要

涉及的是项目的内容而忽视了对项目管理过程的管理，专业性经常有可能成为项

目管理成功的一个阻碍。有效的项目管理发动团队来实施项目的内容。

尤为突出的是，项目经理负责保证图1中所示的项目管理过程得到有效的执

行。因此，项目经理：

保证项目组成员理解项目管理并进行实践。

保证所有的项目组成员理解并接受他们的职责。

集中项目组资源用于计划的制订和实施。

对计划用出及时的调整。

维护项目文件。

仲裁并解决冲突。

向项目组成员和其他人汇报项目的状态。

记录问题的日志。

项目经理的任命应该以书面的形式正式宣布，并完整地描述其承担的角

色和职责。比如说，高层管理人员在宣布时应表明：如果团队成员之间有争端，

项目经理是否有权做出决定，或者宣布“破裂来寻求其他权威人士的帮助。

例：一家财富500强公司的电视机生产设备分部的一个“关键任务

(missioncritical)”项目出了差错，可能会错过需要的市场机会。公司的高层管

理人员已经告诉过部门管理人员：如果项目不能在某一特定的日期前完成，分部

将被关闭，并且所有人员的都被解雇。

对项目所做的分析表明团队由项目“主解”构成（即：代表诸多不同职

能的人员，如营销/工程和制造等），但却没有一个项目经理。每个项目主角向不

同的职能部经理汇报，每名经理对项目的优先权和期限望的结果都有不同的观

点。项目主角非常难以就目标、解决问题/确定进度达成一致的意见，并且也很

难作到在管理上不插手不同职能部门。项目完全是一团混乱，没有一个人负责。

一旦高层管理人员意识到问题所在，分部的副总裁正式地任命了一名威信高

的管理者作为项目经理，并且明确地给予了这名经理解决差异的权力。项目经理

积极地告知所有的重要人员任何冲突是不可接受的，然后举行了一次为期两天的

计划方面的讲习班。在讲习班上，经理和团队明确修正了项目的目标，修订了项

目的进度表并达成了i致的意见，制订并批准了争论管理过程。通过力推项目管

理，经理和团队比最后期限提前完成了项目。

同时，我们还应清楚地确认项目组，并配以明确的角色和职责。这样可以保

证所有的工作都由某人“所有”，多余的工作最少，并且减少了角色的冲突。为

项目工作的所有的人都应该包括项目组中，当然，有些人要完成的工作会比其它

人多许多。项目组的主要职责包括：

了解项目管理的过程和工具。

帮助创建项目计划。

致力于项目的成功。

汇报项目的进展、风险、争论和问题。

针对项目的变化作出有效的调整。

每个项目都应完成项目给花名册（图2）。这个强有力的工具确定了团队的

成员和他们的角色以及职责。同时也是保存项目组后勤方面信息的一种方便和有

效的方法。通常情况是，当首次完成项目组花名册时，团队会非常吃惊地发现：

项目涉及到那么多不同的人员和角色，人员之间的冗余那么大以及有那么多关键

的职责被忽略了。完成花名册迫使成员更全面地定义他们的团队。每个项目都应

有花名册。

图2--项目组花名册

姓名和职位

角色

组织

电话和传真

电子邮件地址

地址/邮箱

例：一•个大型的复杂软件开发项目的项目经理对于他所面对的工作量感

到无所适从。他经常奔忙于会议之间以及与不同小组交流。然而，他仍然不断地

被指责为没有与关键人员和关键部门沟通。对他所处的情景进行的分析表明他不

清楚究竟有谁在参与该项目。

因此，他作为一份项目给的花名册，发现他在处理64个不同的部门、

200多名人员，实际上，他一直在努力用“原始的力量”来管理项目，很少地制

定项目组的职责。一旦完成了项目组的花名册，他就能够让项目有更多的结构，

能够明确界定由12个人组成的核心团队，来代表其它的职能部门和员工。团队

的有效性提高，并且项迅速地产生了巨大的、及时的重新调整。

确定项目组织的关键行动

以书面形式任命项目经理。

书面描述项目经理的角色、权力和职责。

确认项目组角色和职责。

创建并公布项目给花名册。

1.2定义项目参数

也许任何一个项目计划的最重要的因素是知道项目的目标和交付物。项目参

数定义这一步骤的意图是保证完成的是“正确”的项目。所谓“正确”的项目是

指按期望的结果或者范围、进度、和花费的资源来规定的。这些数据记载在项目

目标书(ProjectObjectiveStatement:POS)和主要交付物中,包括强有力”是/

否”的过程。

这些数据的第一关是确定项目的目标。但是，具有在完整的详细计划(包括

风险管理计划)完成以后，才能最终确定这些目标，因为详细的计划就目标可行

性方面提供了大量信息。

定义参数时的主要问题

项目范围是什么？

项目什么时候完成？

给项目分配什么资源?

是否有一份清晰的、简明的、字数少于25的项目目标书？

项目的主要交付物或者后果是什么？是否很好地定义了主要的交付物？

每个主要交付物是否都有书面的是/否清单？

主要的交付物是否设定了目标完成的时间？

项目目标书（POS）描述了项目应完成什么，应在什么时候完成以及需要花

费多少来完成。这些方面分别被称为项目的范围、进度和资源。所有的POS都

应有这三个参数。

POS中范围这一部分描述的是预期结果的精髓。因此，美国国家航空及太空

总署的月球火箭发射项目的范围是：“将一个人送到月球上，并让他安全返回。”

如果其中某一部分被省略，比台有关安全返回这一部分，项目可以达到规定的结

果：将一个人放到月球上，但项目却很难被认为是成功的。有效的范围陈述必须

捕捉到成功结果的精髓。

POS中进度这部分应抓住项目的完成时间（记住，在完整的进度表编制好之

前，这仅仅是一个目标）。因此，月球火箭发射项目的POS中进度部分是：“在

十年之前”。虽然这引起了人们的想象，但作为进度目标，却有点过于模糊。”在

十年之前”可意味着提前一年，提前进6个月或者在十年的最后一天。同样，象

“在职998年二季度之前”这类的进度目标也许对某些人意味着第二季度的开

始，有些人认为是季度末。作为POS中的进度，应是项目的一个确切的日期，

如“1998年6月30日前”。

POS的资源部分描述了项目的资源配置，可以用某笔金额（如“成本为了百

万美元”）、人月数或者相当于全日专职数（如“使用32个人月数）来表示，或

者综合这些表示法。比如，月球火箭发射项目的资源部分，1961年是5.31亿美

元，十年期间是70-90亿美元.保证所使用的尺度在相关环境中被普启蒙接受是非

常重要的.当心用这类的语言”用现存的资源”.该句话假设这些资源可供该项目

使用，但实际上可能不是那样.同时，这样的陈述为以后作权衡性的决策无法提供

有用的信息.POS中的资源部分应该反映项目所需资源的目标总量.

除了这三个参数（范围，进度，资源）以外，一份好的POS还包括儿项其

他重要性：

单词数不超过25（该限制迫使POS精确）

使用普通的语言，避免行话和首字母缩合词。

清楚，简洁。

理想的POS应是一种愿景，形成了挑战和一定程度的兴奋。

再以月球火箭发射为例，一个好的、完整的POS应是这样的：

将一个人放到月球上，并让他在1969年12月31日前安全返回，预算为9

亿美元。

这个POS清楚、简洁并且很有效。

例：在一家大型医疗产品公司，负责一个关键项目的高层经理让项目组

精心制订一份POS来保证他们对目标达成共识。项目组首先写了一65个单词的

目标书，其中包括多个日期和儿种资源变更。经过很大的努力，小组将POS缩

减为25个单词，并拿给高层经理看。

她惊呆了。小组把项目弄错了！刚开始的65个单词中至少隐藏着三个

可能的项目。项目组重点放在了错误的项目上。高层经理和项目组迅速地重新调

整其重点，项目很早就完成，并月认为是非常成功的。高层经理估计通过使用

POS她的部门节省了40个人的团队三个月的工作，或者按每个人工满负荷工作

一天是750美元计算，每月节省了180万美元。一份好的POS能够直接影响底

线利润。

主要交付特是提炼完善了POS中对范围的定义。主要交付物是管理人员注

意力焦点所在的主要项目的后果或者结果。比如说，并购项目的主要交付物可以

是财务分析的第一稿：医学项目的主要交付物是临床实验：或者营的调研项目的

最终交付物是市场战略的定义。这些交付物通常是判断项目成功的基础。

因为主要交付物是作为一种让管理人员将注意力集中在关键项目结果上的

一种工具，有关这些交付物应该是什么以及多长时间应交付这些方面具体的指导

方针很少。基本的“经验之谈”是：项目经理和团队应提前决定他们致力于哪些

关键的有形结果。比如说，在创建复杂的新产品线的项目中，车间的“第一关”

设计也许是一个好的主要交付物。但是，如果生产线很简单，完整的设计也许是

一个更好的主要交付物。团队应该选择那些方便他们规划和管理项目的结果。

既然主要交付物对于项目的成功那第重要，那就有必要系统地保证很好地定

义并且明确主要交付物。定义主要交付物的一种简单，但却是非常有力的方法是

是/否方法。

考虑这么一个常见情景。你打开了电视机，收到了图象却没有声音。你随之

调大音量。如果你仍然无法收到声音，你就可能换频道。如果你收到了声音，你

则了解边界状况的某些信息，既然在第二个频道你收到了声音，问题不是电视机;

问题是发送。想似地，是/否的过程通过明确地定义边界状况阐明了交付物。与

更正式的规范过程相比或者与完全无规范相比，是/否过程是一种异常有效地定

义主要交付物的方法。

使用是/否过程时，项目组列出所有的包括在项目中的事项（是）或者所有

的被项目排除在外的事项（否）（通常是在活动挂图上，有一栏为是，一栏为否）。

通过快速的头脑风暴法产生出上述清单。“是项”是指当你思考“该交付物是什

么时？”闯入你脑海的所有事项。比如，交付物是一份咨询报告，则“是项”清

单中可能包括诸如篇幅（是5页）、装订（是螺旋装订）、内容（有关营销和财务

的两节）以及其他帮助阐明期望结果的任何项目。

“否项”是指有些人认为将某些项目包含在交付物里是合理的、但却不应该

包括的项目。因此，在咨询报告的例子里，“否项”可能是这样的：不包括正式

的演讲，或者不进行某些统计分析。“否项”限制了主要交付物，因此更好地定

义了项目的工作。

是/否清单显示出一些造成管理上挑战的•致模式。典型的模式是，“是项”

清单很长，令人立即意识到得从该清单上去除某些项目才能保证羡慕是可行的。

另一种情况是，总有些“否项”清单上的某些项目让一名或者多名项目组成员受

至U困扰。他们强烈地指出该项目非常重要，不应该排除在外。将一些项目在“是

项”和“否项”之间移动正是管理权衡的精髓，因为每一次变动都会同时改变项

目的重点或者扩大了项目、触犯某些人或者令某些人激动，并最终直接影响进度

和资源上的需求。是/否过程给项目组、项目经理和高层管理人员提供了一种制

订非连续决策的工具。

例：一家财富500强公司的人力资源部开始进行一个主要的流程再造项目。

人力资源部的团队召开了为期两天的研讨班，用是/否方法来确认和定义再造工

程的主要交付物。主要交付物包括：

分析公司当前的所有关键流程。

重新定义这些流程。

一份正式的实施计划。

一份独立的人员配备计划。

当团队谈到第一个主要交付物（分析公司当前的所有流程）的是/否（见

下表）时，他们迅速地发现高层管理人员真的是同时指公司“所有的”流程。

是

否

产品开发

定单的履行

营销

顾客服务

战略计划

计算机模拟

“是项”清单中需处理的流程非常的广泛，而“否项”却非常的少。因

此，他们广泛地讨论怎样才是可能的，最终决定优先将“定单的履行”作为项目

的首要重点。他们还修改了主要交付物来反映以定单的履行为重点。“是项”清

单按某种方式定义了“所有的”含义，导致了项目范围上的决定更加有效。

定义项目参数的关键行动

书写项目任务书。

列出主要交付物。

对每个主要交付物都创建一份是/否清单。

计划项目框架

许多项目的项目组成员通常都会抱怨两件事情：一是会议太多，二是很难制

订决策。这两者都表明操作程序定义得不好。相反，有效定义了操作程序的项目

通常效率很高、人员士气也更高——人们常将它们描述为“运转良好”。计划项

目框架这一步骤的目的是定义项目组应该如何操作。对该问题达成一致意见对项

目的成功有直接的影响。

计划项目框架的关键问题

项目组是否明确指出什么时候开会？在什么地方开会？哪些人会参加？将

讨论哪些问题？

是否已确立出席准则？

是否已确立参与标准？

项目组是否定期地记录所有的问题？

是否定期地更新并且回顾问题日志？

项目组将如何解决意见上的分歧或者冲突？

对未解决的问题是否有自动升级的路径？

谁负责并且维护项目文件？

文件的存储地点是什么？

项目组如何沟通（电子邮件、电话等）？

这些已达成一致意见的事宜是否已经书面记录并且存储在项目文件中？

虽然有多种可能的操作程序，有些方面对于大多数项目而言是尤其重要的。

包括：

会议以及会议管理。

问题管理（包括“自动升级”）

项目文件的维护和储存。

沟通过程。

对于大多数项目组而言，会议既是主要的沟通方式又是一利工作。不

幸的是，会议也是很多人存在的祸根。规定会议的某些简单的方面，可以使会议

更有实效。比如，去顶一个标准的项目开会时间、会议议程和参会政策是非常有

价值的。同时，在会议中积极地并且有意识地管理问题，将问题记录到日志中，

但当时尽量不去解决，以及解决决策制订的程序（例：制订决策需全体同意、或

多数投票、或项目经理独自决定），都是影响项目成功的重要因素。

正式的问题管理也是相似的影响。在问题日志中系统地记录所有的问题

会简化问题的决策制订，因为记录这一过程就使得重点在问题本身。通常问题日

志是由项目经理提议并维护的。它是用来确认那些不能立即解决的问题。提出一

名该问题的“责任人（所有者）”以及需解决问题的日期。项目组所有的成员都

可以接触该日志，并且在状况会议上回顾以保证所有的人都能了解。

另外，这么一个给问题分派“责任人”、指定解决的时间、记录解决问

题的过程造成了压力来以他人可以接受的方式快速地终止问题。如果对于尚未解

决的问题有自动升级的路径，这一点尤其正确。自动升级路线是在项目刚开始时

就由项目组规定的，它确定了什么时候未决问题可以升级，并且升级给谁来解决。

将未决问题升级给当权人士去解决，会激励人们解决他们的分歧。项目

组成员经常不愿意解决某个问题，因为与他们所在的职能职责的潜在的冲突。他

们也许不愿意冒险出错，或者担心某件事情真的是高层经理的职责。

图3——问题/行动项跟踪表格

问题跟踪表

事情

日期

提出者

描述及影响

所有者

到期日

状态或者解决

若采取更标准方式操作的话，姓名局组应该指定一个人在某一特定场所

来维护项目文件。项目文件是所有项目文档的贮藏室，对解决在项目工作的白热

阶段形成的争端，是非常有用的。可以将项目文件保存在活页夹中或者作为在线

文件来保存，但对所有权、存放地点和取用等必须正式指定。

所有的项目都产生了大量的交流。前瞻性地确定项目组成员如何彼此沟通、

使用什么类型的媒介以及沟通的频率都会很好地节约时间。因此，有些项目组同

意使用电子邮件来交流对时间不敏感的正式的状况报告和留言，而使用声音邮件

来满足短期的需要。其他的项目组从以下方面来讨论该问题：谁应该将什么信息

传递给高层经理，频率如何等。每个项目组都应该确定自己的沟通战略。

例：一家有14家公司的集团的某一个项目组处于困境之中。因为该项目组

综合了所有公司的人员，每个公司都有自己的决策制定方法，可以很快地提出项

目上的问题，但解决起来却很慢。项目组成员真的不知道如何相互交流，很多项

目上的问题将会升级到首席运营长官的参谋人员那，但部门的需要总是优先考

虑。

面对这些解决问题上的困难，项目组制订了正式的问题管理过程，其中包括

跟踪问题未决的时间，以及自动升级过程，如果一个问题在提出两周后仍然未解

决的话，自动升级过程将运转。该升级的第一步是项目经理，第二步是首席运营

官。两个琐碎的问题儿乎很迅速地就升级到了首席运营官那儿一他明确地表明他

希望在升级以前项目组更加合作地解决问题。

不久，解决问题的时间急剧地下降。由于该过程以及其他的管理过程，该项

目原本以为会延误三个月的，实际上却提前6周完成了。有效的框架过程能很好

地提高项目工作的速度，改善项目组的工作。

计划项目框架的关键行动

同意并撰写会议管理程序。

积极地管理问题，包括利用正式的问题日志。

制订项目文件的负责人和地点。

确定并撰写交流沟通战略。

1.4汇集项目定义文挡

一旦组织好了项目、确定了参数并且确定了框架，这些步骤的信息将一起综

合成项目定义文档（PDD）。项目定义文档称为定义和组织信息的手册，在整

个项目期间，作为促进理解和帮助制订决策的参考工具。项目定义文档的例子见

附录。

项目计划

2.1编制工作任务分析表

导致项目延迟的最主要的原因是那些偶然遗忘或者忽视的工作。为了使

项目计划更可靠，一份项目计划书中必须说明达到目标所需要完成的所有任务，

而不仅仅是其中的一部分O工作任务分析表的主要目标是系统化地识别项目所需

要的所有工作。反过来，明确识别所有任务能使人们负责所分派的工作，这些“责

任人”能定义完成特定任务的各项标准。

工作任务分析表是对完成某一部分目标所需要的所有工作的层次化分解

（见图4）0要产生各个层次，我们可以从最大的项目工作集开始，即从最大组

成部分或第1层开始，将其逐步分解成更小的任务；也可以从最小的任务出发,

通过头脑风暴法，组合成更大的集合。这两种方法分别被称为自上而下和自下而

上。两种方法都能很好地工作。项目组决定哪种方法更合适。

图4-一个软件应用驱动程序项目的工作任务分析表

如何定义任务识别的层次？这里有一些共同的规则。''最底层次的”任务（即

处于每个分支最底层的任务）必须是：

对于一般性的项目，该任务需要花费大约2天至2周的时间（对于学生项目

则要花费1小时至半天）。

只有一个责任人。

一种有效的编制工作任务分析表的方法是将整个项目组成员集合在一起，向

每个人发一张报事巾，然后向他们提出如下问题：”为了完成交付物需要做哪些

工作？”，当项目的主要组成部分和任务识别出来之后，把它们写在报事贴上，

不同的分组贴在墙上。这个过程能进行生动活泼的决策，最终，整个项目组成员

对达成目标所需要的工作都有一个更加深入的理解。

“那是谁的工作？”是项目经理最常问的一个问题。没有责任人的任务是无

法完成的。项目给必须有一个正式的过程，（由整个项目组或者由项目经理）来

指派任务责任人。指派任务责任人不仅能消除项目中存在的混淆因素，明显减少

以后可能出现的一引起相互指责和推委的现象。而且，指派任务责任人还能增强

责任感，因此有时会遭到反对。

一旦任务被识别出来，就要对每一个最底层的任务指派一个单一的任务责任

人。因此任务责任人要完成任务，他们必须是最有资格执行这项任务的人。任务

责任人要定义项目输出结果、负责执行任和汇报工作进展情况，这些者是十分关

键的。将现任人的名字记录在报事贴上，在项目开发过程中，将这一信息始终与

任务保存在一起。

2.2编制进度表

大多数项目的核心问题是“它什么时候完成？”编制进度表这一步骤的

目的是通过一个系统化方法来建立项目进度表。因为采用系统化方法编制的进度

表更可靠、也更具有预见性。它们阐述了与达成项目目标所需要的任务、顺序和

时间相关的、具体的战术决策，能进一步进有效的项目管理。

进度表的编制主要依赖于两个要素：任务之间的逻辑关系（被称之为依赖关

系）以及每项任务的时间估计。将这两类数据组合到一个时间表中，就形成了实

际项目进度表。

逻辑关系（比如计划评审图、，网络图、依赖关系和逻辑图）是项目所包括

的工作顺序或者流程。它们通常在“依赖关系图”（图5）中显示。一个说明逻

辑关系的经典案例是在穿鞋之前要穿袜子。这里存在一个逻辑过程：穿鞋之前穿

袜子。（当然，要在穿袜子之前穿鞋，这也是可行的，但这会公共场合下带来尴

尬，因此袜子露在了鞋子外面，这种改变逻辑关系的风险是一项关键的折衷性决

策，本文稍后会加以说明）。对最底层的任务进行排序是编制项目进度表的关键

的步骤。此外，任务排序工作还经常能发现一引起被遗忘的工作，从而会使人们

回到工作任务分析表步骤。

虽然在任务之间存在着多种逻辑关系，一些比较有用的、普遍的关系是：

终点到起点。

起点到起点。

滞后的起点到起点。

依赖关系

任务A

前导后续

任务B

任务A

任务B

终点到起点（FS）起点到起点（SS）

任务A

任务B

滞后SS

最通用和最容易使用的逻辑关系是“终点到起点（FS）”关系。在FS关系中，

只有当后续任务（任务A）安然无恙成之后才能开始后续任任务（任务B）。例

如，学生必须在接受课程指导之后才能做作业，在接受指导（前导任务）和开始

做作业（后续任务）之间存在着终点到起点的关系。在一项任务结束之前，另…

项任务不能开始。FS关系是非常线性的关系，因此容易管理。当然，并不是所

有的工作都是纯线性的，因此在对于工作流建模时,还需要考虑其他的逻辑关系。

比较难使用的一种逻辑关系是“起点到起点（SS）”关系。它主要用来对那

些可拆藉并联行处理、但在活动的起点之间存在关系的一件作进行建模。搭S-S

关系中，一项工作不能从一个任务开始，而必须等到另一个任务开始之后才能开

始。当然，一旦工作开始，则两项任务可以同时进行。例如，在一些合并和收购

项目中，一份主要收购目标的清单已经形成草案但没有最终定稿，但是，一旦某

一些名单已经进入了清单之上，那么对这些收购目标的财务分析工作就可以开始

了。在这里，财务分析工作（后续任务）的开始要依赖于列入清单（前导任务）

的开始而不是结束。但一旦两项任务都开始了，只要资源允许，它们就可以同步

进行。因此，进度表显示了这引起任务之间的S-S的关系。

S-S关系的一个变异类型是"滞后的S-S关系”。滞后是任务之间的延迟，这

里是指任务起点之间的滞后（也存在其他类型的延迟，但不经常使用）。例如，

在开发新型计算机时，软件开发与硬件开发之间通常就存在这种"滞后的S-S关

系”；软件小组在开始工作时至少需要硬件的设计说明，但一旦它们存在，它就

可以和硬件开发i起同步进行。因此，“延迟”是对任务之间滞后进行建模。

尽管"滞后的S-S关系”具有允许并行工作和滞后的优点，它同样也存在着

缺点，即后续任务何时开始是比较模糊的。因此，较好的做法通常是将”滞后的

S-S关系”转化成FS关系，将较大的并行任务分解成可以建立FS关系的较小任

务。

编制一份依赖关系图（图6）的实际过程是要显示出逻辑关系，使项目组成

员移动写有工作任务分析表最底层任务的报事贴，直到将它们按一定的顺序连接

起来。在项目组就是最终流程达成一致之前，预计要移动多次。

图6-计划评审图（“PERT”图）

草案

“PERT”图

软件驱动程序项目

项目经理：JimRemick

初度进度表

编制人：K.Hansen第一页

评审日期：V14/9x

里程碑的概念与逻辑关系的概念紧密相关。里程碑是指一个时间点，它

通常用来表示出项目中的重大事件，并且使管理人员对它予以重视。因此，”完

成引导测试”是许多制造型公司普遍的里程碑，”完成报告初稿”则是许多咨询

公司的里程碑。里程碑之所以重要是因为它们通常表明了许多依赖关系的顶点。

里程碑有许多不同的类型，包括：

项目的开始和结束。

主要交付物的完工。

正式的评审。

关键事件，比如讲座或者商业演示。

对项目环境以外的组织的依赖关系或者交付物。

尽管研究（和经验）表明项目中出现最多的问题是“遗漏某些任务”，但对

任务时间长度的估计通常也是项目中的关键点和争论最激烈的地方。因此，进行

有效的任务估计的最佳程序是：

完成工作任务分析表。

快速估计最底层次任务的大致持续时间。

持续时间不同于“工作“或者”进度表”，它是完成任务所需要的工作周期

（小时、天、周等）的数量。一份好的工作任务分析表通常会给出关于任务长度

足够的初步的持续时间的信，在项目进度的这一阶段对持续时间所作出的“快速

和粗略”估计能够满足大多数项目的需要。任务责任人必须马上在该任务的报事

贴上写下任务所需时间的最佳估计。

现在我们手已经有了依赖关系图以及快速估计的任务，就可以开始建立一份

可靠的进度表了。进度表几乎是前面的项目计划过程产生的微不足道的最终产

品。即，如果很好地定义了工作任务分析表、很仔细地构造依赖关系图，我们是

非常容易建议一份可靠的进度表的。当然，如果这些前期步骤中任何一个被忽略,

进度表的可靠性和可预见性将大幅度降低。

编制进度表时要将时间长度估计和依赖关系图填加到一份日历或者时间表

上。最通常的方法是建立甘特图（图7）。甘特图按时间显示任务。它之所以流

行是因为它容易使用，而且直观清晰、容易阅读和理解。甘特图可以手要编制，

在时间表上按预计的时间和顺序画出所有任务，用直线表示其依赖关系。甘特图

也可以使用项目关系软件包来完成。

图7-甘特图

草案

甘特图

软件驱动程序项目

项目经理:JimRemick

工作任务分析表

任务名称

1月

2月

3月

4月

5月

6月

7月

1

1.1

项目计划

项目开始

1.2

1.3

确定项目目标

规划项目框架

1.4

1.5

编制工作任务分析表、进度表和资源计划

审核并批准项目计划

1.6

2

计划完成（里程碑）

编制规格说明书和设计报告

2.1

2.2

编制外部规格说明书

编制内部规格说明书

2.3

2.4

编制财务分析报告

编制内部规格说明书

2.5

3

设计完成（里程碑）

开发及测试驱动程序

3.1

3.2

开发驱动程序

确定BETA测试地点

3.3

3.4

编制质量计划

发送程序之前的质量检验

3.5

3.6

发送程序进行BETA测试

进行BETA测试

3.7

3.8

根据测试结果修改程序

开发完成（里程碑）

4

4.1

商业发布的准备

编制技术支持计划

4.2

编制最终财务分析报告

初步进度表

汇总推迟的进度

关键任务里程碑

非关键任务

编制人：k.Hansen第1页

评审日期：1/1的x

尽管甘特图本身是被广泛接受的工具，但作为一个系统化计划过程的结

果，一份超过了预期进度的表总是不能被很好的接受。对于采用系统方法构造的

进度表。人们通常的反应是“这术长了”（也被称为”进度表的震惊”）。但是，

因为该进度表是经过慎重考虑才松造出来的，对预计的完成日期的反对意见不

久就会消失，从而集中支持一些权衡决策。

2.3.资源分析

“如果我有更多的资源！”失败的项目经理总是这样喊着。尽管拥有额外的

资源，资源问题总是存在的。仅仅只是增加更多的资源是很难提高项目绩效的。

相反，项目经理要更系统地分析他们的资源需求。资源分析步骤的目的是向项目

经理提供更多的关于实际状况的信息，使之能对三个参数进行更有效的决策。

典型的项目决策是在三个参数之间进行权衡：项目范围、项目进度以及

项目可用资源。有效的资源管理基于一种有效的资源分析方法，是项目成功的关

键要求。

尽管存在着许多用于分析和管理资源的工具，但对于较小的项目而言，

它们大多数都是不太划算。许多非正式和分析方法也能起到同样的作用，其成本

要明显低得多。

在甘特图上加上所指派的任务责任人，就构成非正式资源分析的基础。

项目经理和项目组成员浏览甘特图，找到任务分派模式，例如:

同一个人是大多数任务的责任人。

同一个人是许多并行任务的责任人。

某些人是极少数任务的责任人。

许多任务以并行方式堆在一起。

某些任务没有责任人。

既然可以存在许多不同的模式，在诠释这些模式时就没有一种通用的指南。

但是，每一种模式都自然而然地提出一个问题，即项目组必须进行管理。资源运

用模式将和项目范围、项目进度等数据一起用于权衡决策。

资源分析的关键行动

•分析甘特图，得到资源运用模式

2.4.优化权衡

实施项目管理的主要理由是为决策产生更好的数据。这些数据通常代表着不

同的选择，需要一次困难的决策。在好的项目管理中，为了得到最佳的整体结果,

儿乎总是需要舍弃一些期望的东西。权衡优化步骤的目的是使决策过程正式化和

合法化。

权衡优化的关键问题：

•是否在POS限度以内？

•你是否能缩小项目范围？

•你是否能改变项目任务的执行顺序？

•你是否能重新分配或获取更多的资源？

•是否存在着更好更灵活的工作方式来达到同样的结果？

有效优化的关键是检查整个项目计划，并且开发出创造性的方式使项目计划

更有效。事实上与计划有关的任何事情都可能被改变，但这些变化必须以系统化

的方式完成、并且所有项目参与者都知道这些变化。一些比较常见的变化是：

•将项目从“是”项列表中移到''否”项列表中。

•取消一个或多个主要交付物。

•开发出不同的执行任务的工作方式。

•改变依赖关系。

•改变资源。

•接受新的参数。

也许我们显然无法简单地描述优化过程。该过程既包括了明智的分析和合理

的判断。从这个角度来讲，优化实际上是项目管理的精髓，因为它意味着真的要

作出困难的决策。

例：一个项目要开发一种新型的、具有特殊用途的并行处理计算机，它们将

计算机包含8个微处理器列为“是”项。尽管这是一个非常强大的设计方案，但

也需要技术革新和开发。这是一个伟大的设想，但风险极大。项目组编制了项目

计划，不久就发现项目在一年之内会失去市场机会。

项目组成员尝试了许多不同的“假设分析”策略来优化项目计划，包括将某

些工作以并行方式处理、加入新的人员。不幸的是，所有这些策略都不能满足进

度的需求，而且它们的代价都非常大。

经过慎重的争论之后，他们重新检查了关于8个处理器的需求。如果将数量

降低到2人处理器，他们认为这种计算机可以按时完成，2个处理器尽管不如理

想的数量多，但也足够在细分市场中建立他们的地位。他们做出了一项困难决策,

减少项目的范围，从而能抓住市场机遇。

权衡优化的的关键行动：

•分析整个项目计划。

•建立一些“假设分析”。

•作出权衡决策。

2.5.编制风险管理计划

所有项目都存在风险，这确实是一个真理，然而令人惊讶的是，项目人员忽

略了风险。编制风险管理计划步骤的目的是使项目组注意到项目风险并对其进行

管理。

编制风险管理计划的关键问题:

•项目的风险是否已经明确？

•是否定义了它们的优先顺序？

•是否采取了行动来降低这些风险发生的可能性？

•当风险发生了，是否存在应急计划？

•你将如何知道风险是否发生？

•谁负责管理项目风险？

如果在项目开始时询问项目组成员，事实上每个人都能够描述出项目成功的

关键风险。同样，在失败的项目中，人们儿乎总是说失败的原因其实事先就已经

知道了，但没有采取相应的措施加以防范。人们往往知道存在项目风险但很少主

动地去管理它们。

这种自相矛盾的现象是由许多原因造成的：

•人们不相信风险会发生在他们身上。

•没有时间去考虑和管理风险。

•人们过于自信，认为风险发生时他们也可以克服。

•人们不喜欢管理风险。

因此，风险管理方案必须同时与上述原因中所隐含的乐观主义和管理风险能

用的时间相一致。在此我们提出这样的方案，它包括两个组成部分：

•风险评估。

•风险管理。

在风险评估时，项目组要花费一些时间进行脑力激荡，列出项目中可能存在

的所有风险，然后非正式地选择对项目威胁最大的两至三项风险，并编制出管理

这些风险的计划。

风险管理计划应当提出降低风险发生可能性的措施（预防措施）以及风险发

生时要采取的措施（应急措施）。预防性措施可能会在项目计划中加入更多的任

务。应急性措施需要一个触发标准，以通知项目组何时需要启动风险计划。例如,

对项目最终完成日期10%的偏移将启动一项应急计划来减少项目范围。具体的偏

移量就是应急计划的触发标志。

通常，风险管理计划要简略地记录在项目文件中。在许多情况下，项目组会

指派某个成员来负责监控项目的触发标准并通知项目组需要启动应急计划。

例：某家公司承担了一个项目，为整个校园系统铺设光纤，使计算机能够安

装在所有的教室和办公室里。项目必须在开学之前完成。

该项目需要大量的光纤。风险评估表明从主要供应商得到光纤存在巨大的风

险，因为所需要的光纤数量非常大，而且供应商正在处理一个非常棘手的劳资纠

纷问题。项目经理和项目组采取了如下预防性措施：

•拜访供应商，确定其生产能力的正式状况。

•储存额外的光纤（在合理的额外费用下）。

•建立和其他供应商的关系，包括下一些小的订单。

•储备一些“应急”资金，以备可能出现的、超出正常价格的采购。

不幸的是，在学校即将开学之前，供应商不能交付所有需要的光纤。项目经

理启动了应急计划，使用应急资金从其他供应商处采购光纤。尽管公司损失了一

些毛利，但损失是很小的，而且项目在学校开学之前完工。风险管理计划直接推

动了项目的成功。

编制风险管理计划的关键行动：

•确定所有项目风险并确定其优先顺序。

•编制风险管理计划，包括预防性措施和应急计划。

指派专人管理项目风险。

3.项目跟踪和管理

3.1搜集状态

3.2计划和采取相应的措施

一旦项目启动，保证其不偏离轨道甚至是比第一次制订项目计划更艰难

的挑战。跟踪和管理步骤的目的是让项目是让项目经理和项目组把注意力重点放

在那些提供项目进展最优信息的领域。好的信息又反过来会帮助项目经理和项目

组面对所有项目中发生的动态的变化，相应地作出更好的决策。

搜集状态的关键问题

•正式的“搜集状态”的频率是多少？

•如何进行？

•需监控什么信息？

•要作什么决策?

•要采取什么措施?

•如何沟通这些决策和措施?

好的规划真正带来的收益是项目极好的“实时”管理。实际上，有效的

跟踪让项目组的重点和精力如此集中，项目组经常会觉得热情高涨，会检查项目

的进展和作出及时的决定。同时，并不是所有的人都喜欢项目跟踪。对于他们而

言，跟踪意味着严格的责任、过多的繁文缗节，以及得分配更多的时间做项目工

作以外的事情。对于这些人来说，跟踪是件讨厌的事，应该尽可能地少做或者应

该完全忽视。

使这两种看起来相对立的观点协调一致并不难。如果跟踪体系足够简

单，只需花很少的时间维护，但体系却非常有力，可以给项目经理和项目组提供

制订有效的决策所需要的所有数据，则项目跟踪可以高效并且甚至令人愉快。如

此简单的体系必须将重点放在那些影响决策的数据上。令人吃惊的是，这样的话

并不会产生很多数据。

一套好的跟踪体系仅对三个有限的主题搜集状态信息——进度状态、未决

问题和风险。

进度状态包括：

•按进度应在该期开始的任务是否已经启动？

•如果没有启动，能做些什么才能让它们启动?

•按进度应在该期结束的任务是否已经完工?

•如果没有完工，能做些什么才能让它们完工?

未决问题包括:

•所有未决问题的状态如何?

•能采取什么措施来解决它们？

•是否有些新的未决问题?

风险包括:

•风险状况如何？

•是否有新的风险?

这三个方面阐明有效管理项目所需的所有项目信息。收集这些数据是容易

的。可以利用声音邮件、电子邮件或者会议来搜集这些数据（虽然最好是在会议

前就搜集信.息，通过会议来界定问题和指派行动）。通常，项目状态信息是每周

搜集，虽然在一些短期或者尤其重要的项目里可以更频繁地搜集状态信息，或者

在一些较长期的项目里减少频率。

虽然还有些更复杂和更全面的跟踪体系，但该体系通常是以满足大多数的需

要。

显然，一旦搜集了状态信息，项目组就必须调整计划并且采取相应的措施。

这里的决策与优化步骤里的决策完全相似。通常项目组可以：

•将项目在“是项”清单和“否项”清单之间移动。

•去除一个或者多个主要交付物。

•制订不同的方法来完成任务工作。

•改变依存的关系。

•改变资源。

•接受新的参数。

再次，项目管理的精髓在于根据大量的项目数据制订艰难的决策。这些决策

发生在整个项目的生命周期内。

例A：一个咨询公司的项目组受委托为一个准备推出新产品线的客户做一次

全世界范围的市场研究。接受委托时，一