项目管理包含了许多内容，它是对项目管理专业知识的一个总结，正如法律、医药和会计等其它专业一样，这一知识体系也有赖于那些实践者和学者们对它加以应用和提高。整个项目管理知识体系不仅包括那些已经被求证过的理论知识和已经被广 泛加以应用的传统经验，而且还容纳了新的理论知识以及还没有被充分应用的先进经验。
第一章 绪论
第二章 项目管理环境
第三章 项目管理程序
第四章 项目综合管理
第五章 项目范围界定管理
第六章 项目时间管理
第七章 项目成本管理
第八章 项目质量管理
第九章 项目人力资源管理
第十章 项目沟通管理
第十一章 项目风险管理
第十二章 项目采购管理
第一章 绪论
　　项目管理知识体系包含了许多内容，它是对项目管理专业知识的一个总结，正如法律、医药和会计等其它专业一样，这一知识体系也有赖于那些实践者和学者们对它加以应用和提高。整个项目管理知识体系不仅包括那些已经被求证过的理论知识和已经被广泛加以应用的传统经验，而且还容纳了新的理论知识以及还没有被充分应用的先进经验。

　1．1本文的目的
　　本文最根本的目的是要向大家介绍已经被普遍认可、接受的项目管理知识体系的基本内容。"普遍认可"意味着在此所介绍的理论和实践经验在大多数时候对于大多数项目来讲都是适用的，这意味着大家对于这些理认和实践的价值用途已达成了广泛的一致。但是，"普遍认可"并不是说这些理论和实践经验可以或者应该适用于所有的项目。什么是对项目适用的，这应该由项目管理工作组做出决定。

　　作者也希望为大家探讨项目管理提供一本专业（术语）的通字典，项目管理是一个相对年轻的专业，因此在各种项目的实际运作中有大量相同类似的工作，但所使用的术语却很少相同。

　　本文为任何对项目管理感兴趣的人提供了一个基本的参考，主要适用于：（当然也不局限于此）　
　　 项目经理和项目组的其他人员
　　 项目的客户和其他项目涉外人员
　　 项目经理的主管
　　 有下属参与项目工作的部门经理
　　 进行项目管理和相关课程教学工作的教育工作者
　　 项目管理及相关领域的顾问和专家
　　 对项目管理人员进行培训的培训师
　　由于本文在内容上还不够深刻和广泛，因此仅为大家提供了一个基本的参考。附录E所讨论的是对项目管理应用的扩展，附录F给出了有关项目管理上的进一步的信息采源。

　　本文也被项目管理研究院采纳，作为其学科专业发展计划的常用教材，包括：
　　 项目管理专业人员资格认证
　　 项目管理教育等级认证
1．2什么是项目
　　需要组织来实施完成的工作。所谓工作通常既包括具体的操作又包括项目本身，虽然，这两者有时候是相重叠的。但具体操作与项目有许多共同特征，比如：
　　 需要由人来完成。
　　 受到有限资源的限制。
　　 需要计划、执行、控制。

　　具体操作与项目最根本的不同在于具体操作是具有连续性和重复性的，而项目则是有时限性和唯一性的。我们因此可以根据这一显著特征对项目作这样的定义--项目是一项为了创造某一唯一的产品或服务的时限性工作。所谓时限性是指每一个项目都具有明确的开端和明确的结束；所谓唯一是指该项产品或服务与同类产品或服务相比在某些方面具有显著的不同。

　　各种层次的组织都可以承担项目工作。这些组织也许只有一个人，也许包含成千上万的人；也许只需要不到100个小时就能完成项目，也许会需要上千万小时。项目有时只涉及一个组织的某一部分，有时则可能需要跨越好几个组织。通常，项目是执行组织商业战略的关键。以下的活动都是一个项目：
　　 开发一项新的产品或服务
　　 改变一个组织的结构、人员配置或组织类型
　　 开发一种全新的或是经修正过的信息系统
　　 修建一座大楼或一项设施
　　 开展一次政治性的活动
　　 完成一项新的商业手续或程序
　1．2．1时限性
　　时限性指每个项目都有明确的开端和结束。当项目的目标都已经达到时，该项目就结束了，或是当我们已经知道，已经可以确定项目的目标不可能达到时，该项目就会被中止了。时限性并不意味着持续的时间短，许多项目会持续好几年。但是，无论如何，一个项目持续的时间是确定的，项目是不具备连续性的。

　　另外，由项目所创造的产品或服务通常是不受项目的时限性影响的，大多数项目的实施是为了创造一个具有延续性的成果。例如，一个竖立民族英雄纪念碑的项目就能够影响好几个世纪。

　　许多工作在某种意义上说都是有时限性的。因为它们都会在某一点上结束。比如，一个自动化工厂的装配工作会有暂停的时候，这个工厂本身也会有停工的时候，项目与此有根本性的不同，因为项目是在既定目标达到后就结束了，而非项目型的工作会不断的有新的工作目标，需要不断地工作下去。
项目的这种时限性特征也会在其它方面体现出来：
　　 机遇或市场行情通常是暂时的--大多数项目都需要在限定的时间框架内创造产品或服务。
　　 项目工作组，作为一个团队，很少会在项目结束以后继续存在--大多数项目都是由一个工作组来实施完成的，而成立这个工作组的唯一目的也就是完成这个项目，当项目完成以后，这个团体就会被解散，成员也会再被分配到其它的工作当中去。

　1．2．2产品或服务的唯一性
　　项目所涉及的某些内容是以前没有被做过的，也就是说这些内容是唯一的。既使一项产品或服务属于某一大类别，它仍然可以被认为是唯一的。比方说，我们修建了成千上万的写字楼，但是每一座独立的建筑都是唯一的--它们分属于不同的业主，作了不同的设计，处于不同的位置，由不同的承包商承建等等。具有重复的要素并不能够改变其整体根本的唯一性，例如：
　　 一个新开发商业航线的项目可能需要提供大量的模型。
　　 一个推广新药的项目可能需要大量药剂用于临床试验。
　　 一个房地产开发项目包括成百上千的独立单元。
　　
　　每个项目的产品都是唯一的，产品或服务的显著特征必定是逐步形成的。在项目的早期阶段，这些显著特征会被大致地作出界定，当项目工作组对产品有了更充分、更全面的认识以后，就会更为明确和细致地确定这些特征。

　　应该将产品特征的逐步形成与项目范围正确的界定加以仔细地协调，特别是当项目是根据合同实施的情况下，对这一点要更加注意。当作出正确的界定以后，项目的范围--需要做的工作--既使当产品的特征是逐步形成的，范围也应该保持不变。关于产品界定与项目范围界定两者的关系，我们将在绪论到第5章中进一步地加以讨论。

　　以下两个不同应用领域中的案例解释了产品特征的逐步形成过程。

　　案例1，一家化学加工工厂往往首先要开始的程序是对工艺流程性质、特点的定义，这些性质、特点将用做设计主要加工环节。这种信息资料是工程设计图的基础，而工程设计图需要明确工厂布局细节、工艺流程以及辅助设备的机械特征。通过所有这些可以使我们完善工程设计草图，这个工程设计草图可以进一步被绘制成与实物等大的建筑工程图。在建造过程中，根据需要在被许可的范围内进行解释和改造。那么，对于以上性质特点的进一步完善要根据以施工现场变化而变化的图纸来得出。在测试和运转中，性质、特点的更进一步完善常常是以最后的操作调试来完成的。

　　案例2 一个生物制药的研究项目最初被称之为"XYZ临床试验"，因为此时的试验次数和每次试验的规模都未确定。随着项目的开始进行，对于这些就有了更为明确的描述："一阶段试验三次，二阶段试验四次，三阶段试验四次，四阶段试验两次。"为了逐步地确定产品的特性，接下来的工作将全力集中于确定第一阶段试验方案上--对多少病人进行试验，需要多少药量剂，用药的频率应该是多少。在项目的最后，第三阶段试验的内容就可以根据前两阶段收集和整理出来的信息加以明确。
1.3什么是项目管理
　　项目管理就是为了满足甚至超越项目涉及人员对项目的需求和期望而将理论知识、技能、工具和技巧应用到项目的活动中去。要想满足或超过项目涉及人员的需求和期望，我们是需要在下面这些相互间有冲突的要求中寻求平衡：
　　 范围、时间、成本和质量
　　 有不同需求和期望的项目涉及人员
　　 明确表示出来的要求（需求）和未明确表达的要求（期望）

　　"项目管理"有时被描述为对连续性操作进行管理的组织方法。这种方法，更准确地应该被称为"由项目实施的管理"，这是将连续性操作的许多方面作为项目来对待，以便对其可以采用项目管理的方法。虽然，对于一个通过项目实施管理的组织而言，对项目管理的认识显然是非常重要的，但是如何由项目实施管理这不在本文讨论的范围之内。

　　我们可以用许多方式把关于项目管理的理论知识组织起来。在本文中，我们把它分为两大部分，十二章加以阐述。

　1.3.1项目管理的框架

　　第1部分，项目管理框架，为理解项目管理提供一个基本的结构。
　　　第1章　绪论，对关键术语作出定义并给出全文的梗概。
　　　第2章　项目管理环境，描述项目实施的环境。项目管理工作组必须了解和认识项目所处的背景、环境--对项目日常活动的管理只是取得成功必要而不充分的条件。
　　　第3章　项目管理过程，概括地叙述了各项目管理程序通常会产生相互作用、认识和理解这些相互作用，对于理解本文4-12章的内容是非常必要的。

　　第2部分，项目管理知识体系主体，根据项目管理的构成程序，讲解项目管理的理论和实践知识。这些程序在下文中被划分为九个部分，如图1-1表示。
　　　第4章　项目综合管理，阐述了如何确保对项目的不同构成要素进行正确的协调。它包括了项目开发计划，项目执行计划，全程变化控制。
　　　第5章　项目范围界定管理，阐述了为了确保成功地完成项目所有需要做的工作，也是仅仅被要求做的工作。这一章包括了项目的启动，范围界定计划书，细分子项目、范围核实和范围变化控制。
　　　第6章　项目时间管理，阐述确保按时完成项目的工作程序。它包括活动定义、活动排序、活动的时间估计、进度编制和进度控制。
　　　第7章　项目成本管理，阐述了如何在法定预算内完成项目，包括资源规划，成本计划、成本预算和成本控制。
　　　第8章　项目质量管理，阐述了如何确保项目达到既定的要求。包括质量规划，质量保证和质量控制。
　　　第9章　项目人力资源管理，阐述了如何确保最大限度地调动项目涉及人员的积极性，包括组织规划，人员组织、团队建设。
　　　第10章　项目沟通管理，阐述了及时并且准确得到、收集、传送、存储及利用项目信息资源，它包括沟通计划、信息传送、实施情况报告及行政总结。
图1-1项目管理知识体系主体和项目管理过程图

　　　第11章　项目风险管理，阐述项目风险的确定，分析及对策。包括风险识别，风险量化、风险对策研究和风险对策实施控制。
　　　第12章　项目采购管理，阐述如何从执行组织外获取物资和服务。包括采购计划、征集申请书计划、征集申请书、货源选择、合同管理和行政收尾。

　1.4与其它管理方式的联系
　　项目管理中许多知识都是独一无二的，或者说几乎是独一无二的（如，关键线路分析和工作分层结构）。然而项目管理知识体系与其它管理方式的确有相同之处，如图1-2表示。

　　全局管理包括了企业运作的计划、组织、人事安排、实施和过程控制。全局管理还包括诸如计算机程式设计、法律、统计、可行性研究、后勤学及人事管理。项目管理知识体系与全局管理在许多领域是互相交迭的，如组织行为、财务预算、计划方式等不一一列举了。在第二章第4节对全局管理有着更详细的讨论。

　　"应用领域"是一系列拥有共同要素的项目的统称。这种共同要素虽然重要但却不一定为所有项目所必需或在所有项目中呈现出来。应用领域常需用以下术语来定义：
　　 技术因素，如软件开发、制药技术或工程建筑。
　　 管理因素，如管理层构建或新产品开发决策。
　　 工业集团，如汽车工业、化学工业和金融服务业等。

　　附E对项目管理的应用领域作了更为详细的探讨。
图表1-2 项目管理与其它管理学科的关系

注:该图仅为对象的关系示意图
重叠部分未按比例制作

　1.5相关的工作
　　还有几种与项目相关的工作，这里阐述如下：
　　方案：方案是一系列以相互协调方式管理并获得利润的项目的集合，将集合内的项目进行分别管理是得不到我们所说“方案”的。许多方案还包括正在运行的要素。举例如下：
　　 XYZ飞机方案即包括设计和开发飞机的项目，还包括正在进行的生产制造以及对飞机的支持维护。
　　 许多电子企业都有经理，他们既负责每一独立产品的市场投放，又要负责众多产品市场投放的总体协调。
　　方案可能会包括一系列重复的或周而复始的工作，如：
　　 公用事业往往会提到每年一度的市政建设方案，而这个规律性强，持续性强的方案包含了许多项目。
　　 许多非盈利组织都有一个筹款方案，它是一项为了寻求经济支持而进行的持续性工作，常常涉及一系列诸如发展会员或拍卖会这类无关连的许多项目。
　　 出版发行一种报纸或杂志也是一种方案--它们的定期性本身就是一种持续性的工作，但每一期却是独立的项目。

　　在某些应用领域，方案管理与项目管理被视为同义词，而在另一些领域，项目管理被看作是方案管理的子集，在不多的情况下，方案管理被认为是项目管理的子集。这种丰富多变的内涵使任何关于方案管理与项目管理的讨论都必须首先对二者的定义有清晰、固定的共识。

　　子项目：项目常常可以被分解为更易管理的单元或子项目，而子项目常常可以由外部企业承包或项目执行组织中的其它职能单位完成，以下是一些子项目的举例：
　　 一个单个的项目阶段（项目片断的描述见章节2.1）
　　 在建筑项目中的水泵安装或电路铺设。
　　 一个软件开发项目中的程序自动测试。
　　 一个药物研究开发项目中提供临床检验用药的批量生产。

　　然而，从实施者的角度来看，子项目常常被视做一种服务而非产品，而且这种服务是独一无二的。因此子项目也被认为是项目，并作为项目来进行管理。

　2．1项目的阶段和项目的生命周期
　　因为项目都是些具有唯一性的工作，因此它们包含一定程度的不确定性，组织在实施项目时通常会将每个项目分解为几个项目阶段，以便更好的管理和控制，并且将执行组织正进行的工程与整个项目更好的连接起来。总的来看，项目的各个阶段构成项目的整个生命周期。

　2．1．1项目阶段的特征
　　每个项目阶段都以一个或一个以上的工作成果的完成为标志，这种工作成果有形的，可鉴定的。如一份可行性研究报告、一份详尽的设计图或一个工作模型。这些中间过程，以至项目的各阶段都是总体逻辑顺序安排的一部分，制定这种逻辑顺序是为了确保我们能够正确的界定项目的产品。

　　一个项目阶段的结束通常以对关键的工作成果和项目实施情况的回顾为标志，作这样的回顾有两个目的：1)决定该项目是否进入下一个阶段；2)尽可能以较小的代价查明和纠正错误。这些阶段末的回顾常被称之为阶段出口，进阶之门或是关键点。

　　每个项目阶段通常都规定了一系列工作任务，设定这些工作任务使得管理控制能达到既定的水平。大多数这些工作任务都与主要的阶段工作成果有关，这些阶段通常也根据这些工作任务来命名：识别需求、设计、构建、测试、启动、运转，以及其它恬当的名称。在第2章第1节的第3个总是中我们将讨论几种具有代表性的项目生命周期。

　2．1．2项目生命周期的特征
　　项目生命周期确定了项目的开端和结束。例如，当一个组织看到了一次机遇，它通常会做一次可行性研究，以便决定是否应该就此设立一个项目。对项目生命周期的设定会明确这次可行性研究是否应该作为项目的第一个阶段，还是作为一个独立的项目。

　　项目生命周期的设定也决定了在项目结束时应该包括或不包括哪些过渡措施。通过这种方式，我们可以利用项目生命周期设定来将项目和执行组织的连续性操作链接起来。

　　大多数项目生命周期确定的阶段的前后顺序通常会涉及到一些技术转移或转让的，比如设计要求、操作安排、生产设计。在下阶段工作开始前，通常需要验收现阶段的工作成果。但是，有时候后继阶段也会在它的前一阶段工作成果通过验收之前就开始了。当然要在由此所引起的风险是在可接受的范围之内时才可以这样做。这种阶段的重叠在实践中常常被叫"快速跟进"。
项目生命周期通常可以确定：
　　 每个阶段所需做的技术性工作（如：确定建筑师的工作是不是设计阶段的一部分，或者是执行阶段的一部分）。
　　 每个阶段所涉及的人（如：实时工程在识别需求和设计中需要涉及实际操作人员）。
对于项目生命周期的说明可以是非常概括的，也可以非常详细。高度详细的说明可能会包含大量的表、图和清单，以便于确定项目生命周期的结构，并确保其稳定性。这种详细说明的方法常常被叫做项目管理方法学。
　　
　　大多数项目生命周期的说明具有以下共同的特点：
　　 对成本和工作人员的需求最初比较少，在向后发展过程中需要越来越多，当项目要结束时又会剧烈的减少。我们可以从图2-1中看到这一变化。
图2-1生命周期的一般样板


　　 在项目开始时，成功的概率是最低的，而风险和不确定性是最高的。随着项目逐步地向前发展，成功的可能性也越来越高。
　　 在项目起始阶段，项目涉及人员的能力对项目产品的最终特征和最终成本的影响力是最大的，随着项目的进行，这种影响力逐渐削弱了。这主要是由于随着项目的逐步发展，投入的成本在不断增加，而出现的错误也不断得以纠正。

　　我们要注意区分项目的生命周期和产品的生命周期，比如，一个已经完成的项目将一种新型的台式电脑投放到市场，而这只是产品生命周期的一个阶段而已。

　　尽管许多项目生命周期由于包含类似的工作任务而具有类似的阶段名称，但很少含有完全相同的情况，大多数项目被划分为四个至五个阶段，但也有一些全被划分为九个甚至更多的阶段。甚至在同一应用领域中项目阶段的划分都可能会明显不同--某个组织的软件开发的生命周期中也许只有一个设计阶段，而另一个组织则可能会将基本功能设计与细节设计划分为两个不同的阶段。

　　项目的子项目可能也会有清晰的生命周期。比如，一家建筑公司承担了一项设计一幢新型写字楼的工作，最初，建筑公司参与了业主描述阶段的工作，在业主的实施阶段建筑公司又协助其进行建筑施工。建筑公司所承担的设计项目从构思到定稿、实施直到结束也有其自己的生命周期，建筑公司甚至可以将对写字楼的设计和对建筑施工的协助视为两个独立的项目，每个项目都具有自己的阶段划分。

　2．1．3项目生命周期划分的典型方法
　　我们选择以下项目生命周期的划分方法来解释应用中所采用的方法是有所不同的。这里所给出的案例是具有代表性的，但它们既不是推荐的方法，也不是首选的方法。在每一个案例中，阶段的名称和阶段的主要工作成果是由作者自己确定的。

　　防御设备的添加。美国国防部1993年2月修订的第5000.2指令明确了一系列添加防御设备的里程牌事件和阶段划分，如图2-2所示。
　　 导弹需求的确定--以"方案的研究许可"为结束标志。
　　 方案探讨和界定--以"方案的演示许可"为结束标志。
　　 演示和确定效力--以"开发许"为结束标志。
　　 设计和生产开发--以"生产许可"为结束标志。
　　 管理与生产开发--与连续性运作和支持重合。
　　建筑。莫里斯（Morris）在图2-3中分析了一个建筑项目的生命周期。
　　 可行性--项目陈述，可行性研究和策略规划及许可在该阶段不需要得出对项目取舍的决定。
　　 规划和设计--基础设计、成本和进度、合同条款和详细设计。在该阶段末要将主要的合同分包出去。

图2-3 建筑项目生命周期代表性划分，由莫里斯(Morris)提供

　　 实施--制造、运输、辅助机件、安装、测试。在该阶段来完成全部安装工作。
　　 启用和运转--最后测试和维修。在该阶段末全面运行该项设施。
　　制药。墨菲在图2-4中解释了在美国开发一种新药品的项目生命周期。
　　 发现和甄别--包括基础研究和应用研究，确定可以用作预临床试验的药物。
　　 临床前研制--包括为了确定药物安全性和有效性所作的实验和动物试验及其准备工作，并填写新药调查申请表。
　　 整理注册--包括Ⅰ、Ⅱ、Ⅲ阶段的临床试验和其准备工作，填写新药申请表。
　　 后续工作--包括了由于食品药物管理局对新药申请进行复查所要求做的额外工作。

　　软件开发。莫切<Mvench>在图2-5中描绘了一个软件开发的螺旋型模型，在此模型中有四个循环和四个象限。
　　 构思求证周期--包括商业需求、确定构思求证的目标，进行概念性的系统设计、设计和构造构思、求证，制定可行性测试计划，进行风险分析以及制作与下一周期连接的接口
图2-4 制药项目的代表性生命周期,由墨菲提供

　　 第一个编制周期--明确系统要求，明确第一期编制的目标，进行逻辑顺序设计，设计和完成第一期编制、制作系统测试计划，完善第一期编制以及制作与下一周期连接的接口。
　　 第二个编制周期--明确子系统要求，明确第二期编制的目标，进行具体内容设计、第二期编制，制作系统测试计划，完善第二期编制以及作与下一周期连接的接口。
　　 最后一个编制周期--满足单元要求，进行最后的设计。完成最后一期编制，执行单元，子系统，系统以及可行性测试。
2.2项目涉及人员
　　项目涉及人员是指那些积极参与该项目工作的个体和组织，或者是那些由于项目的实施或项目的成功其利益会受到正面或反面影响的个体和组织。项目管理工作组必须识别哪些个体和组织是项目的涉及人员，确定他们的需求和期望，然后设法满足和影响这些需求、期望以确保项目能够成功。对项目涉及人员的识别通常是非常困难的。比如，一个设计新产品的项目可能会影响一个装配线上的工人将来的就业，那么他是不是项目涉及人员呢？
　　每个项目的主要涉及人员有：
　　 项目经理--负责管理项目的个人。
　　 顾客--使用项目产品的个人或组织。对一个项目而言，可能会有多个层次顾客户。比如，一种新药的顾客包括了开出药方的医生、使用该药的病人以及为其承保的保险商。
　　 执行组织--指雇员直接从事该项目工作的企业。
　　 发起者--在执行组织中为该项目提供现金或其它财政支持的个人或团体。
除此之外，还有许多不同称谓，不同类别的项目涉及人员--项目内部的和项目外部的，项目所有人和投资者，供应商和承包商，工作组成员及其家属，政府机构、媒介、个体公民、临时的或固定的疏通组织，乃至于整个社会，通过对项目涉及人员命名和分组，我们可以确认哪些个人和组织将自己视为项目涉及人员。当一家工程设计公司为其正在设计的二个工厂提了资金帮助时，作为项目涉及者，这家公司的职能就有相互重合的地方。
图2-5具有代表性的软件开发生命周期，由莫切提供

　　想要完全满足项目涉及人员的期望可能是非常困难的，因为众多项目涉及人员的期望可能有所不同，有时甚至可能会相互冲突，比如：
　　 一个部门的主管可能希望新的管理信息系统运行成本低，系统的建筑师却更注重技术的完善，而项目承包商更感兴趣的可能是如何获得尽可能大的利益。
　　 在一家电子产品公司中，主管开发的副总裁以产品的设计工艺来判定产品的成功与否，主管生产的副总裁则以一流的生产操作判定新产品的成功与否，为主管市场的副总裁则更多的考虑的是产品新特征的数量，以此来定义产品的成功与否。
　　 一个房地产开发项目的业主关心的是要按时完工，地方政府则希望尽量得到更多的税收，环境保护组织要求尽可能减少对环境的负面影响，而附近的居民也许希望将该项目另迁别处。
总的来说，要解决项目涉及人员目标的分歧还是要以顾客的期望为准。但是，这并不是意味着我们可以忽略其他项目涉及人员的要求与期望。

　　对于项目管理而言，寻求一种适当的方式解决这些冲突是一项重大的挑战。
2.3组织对项目产生的影响
　　组织通常比项目本身更为庞大--公司、政府机构、卫生医疗机构、跨国集团、专业团体及其它。项目通常只是组织的一部分，有时甚至当一个项目本身就是一个组织（合资合作）时，项目仍然会受到设立该项目的一个或多个组织的影响，下面的这一部分内容阐述了这些比项目更大的组织结构中可能会对项目产生影响的关键因素。

　2.3.1组织系统
　　以项目为基础的组织是通过项目来实现运作的，这些组织可以分为两个大类：
　　 通过为其它组织承担项目来获取收入的组织--建筑设计公司、工程设计公司、咨询机构、建筑施工单位、政府分包商等。
　　 通过项目实施管理的组织（见第1章第3节）
这些组织都偏向于建立一个便于项目管理的管理系统。比如：专门设计了能对多个项目同时进行核算、跟踪、汇报的财务系统。

　　不以项目为基础的组织--生产企业、金融服务公司等--很少会设计出能够高效满足项目需求的管理系统，缺乏这种以项目为导向的系统常常会使项目管理的难度加大。某些情况下，不以项目为基础的组织会设立一些部门或其它的子单位，这些部门和子单位可以象那些以项目为基础的单位一样，采用相应的管理系统进行动作。

　　项目工作组应该非常准确地知道组织系统是怎样影响项目的。比如，如果部门经理们会因为能调动员工按时完成项目而受到组织的嘉奖，那么项目管理工作组就需要监督参与项目工作的员工要高效工作。

　2.3.2组织的文化与风格
　　多数的组织都已经形成了自己独特的，可描述的组织文化。这种文化在许多方面有所反映。比如在组织的价值观、行为准则、信仰、期望上；在组织的政策、程序上；在对上下级关系的观点上以及其它方面上，组织文化常常会对项目产生直接的影响。比如：
　　 在一个开拓型的组织中，工作组所提出的非常规性的或高风险性的建议更容易被采纳。
　　 在一个等级制度严格的组织中，一个高度民主的项目经理可能容易遇到麻烦，而在一个很民主的组织中，一个注重等级的项目经理同样也会受到挑战。

2.3.2组织结构
　　执行组织的结构会对取得项目资项源的可能性有所限制，组织的结构类型从职能型到项目型跨度很大，在这两者之间，还有好几种矩阵型，在图2-6解释了几种主要的企业组织结构中与项目相关的关键特征。"项目组织"将在第9章第1节的"管理规划"中进行讨论。

　　图2-7所表示的是传统的职能型组织，这种组织具有明确的等级划分，每一个雇员都有一个明确的上级。员工高度地依各人专长进行组合，比如生产、市场、工程、会计。而工程又可能进一步细分机械和电气。职能型组织也有项目，但各部门对项目的研究范围被局限于部门的职能界限内：一个职能型组织中，工程部的工作是独立于生产部，市场部之外的。比如，当一个纯粹的职能型组织准备开发一项新产品时，设计阶段会被称为"设计项目"，仅仅由工程部人员来完成，如果一旦涉及到生产方面的问题，这些问题将会被逐级地汇报到部门主管处，再由他向生产部主管咨询，然后通知工程部主管，再由工程部主管解决问题的方法逐级向下传递到项目负责人。
图2-6组织结构对项目的影响

图2-7职能型组织

图2-8项目型组织


　　与职能型相对应的另一极端是项目型组织。如图2-8所示。在一个项目型组织中，工作成员是经过搭配的。项目工作会运用到大部分的组织资源，而项目经理也有高度独立性，享有高度的权力。项目型组织中也会设立一些组织单位，这些单位也称作部门，但是这些工作组不仅要直接向某一项目经理汇报工作，还要为各个不同的项目提供服务。

　　图2-9到2-11表示的是矩阵型的组织，这种组织是职能型和项目型的混合体，既具有职能型组织的特征又具项目型组织的特征。弱矩阵型保持了较多的职能型组织特征，项目负责人扮演的是协调者、协助者的角色，还算不上是一个项目经理。同样也是矩阵型，强矩阵型则具备较多的项目型组织的特征--有专职的收力很大的项目经理，有专职的项目行政管理人员。

　　更为现代化的组织则不同的程度地包括以上各种组织类型的结构特点，如图2-12所示。比如，一个基本上是职能型的组织设立了专门的项目工作组去完成一个重要的项目，这个工作组具有项目型组织中项目组的许多特征：有独立于职能部门的专职项目工作人员；有自己的一套工作程序；可以在组织常规的标准、正式报告架构之外进行运作。

图2-9弱矩阵型组织

图2-10平衡型矩阵组织

图2-11 强矩阵型组织

图2-12 复合型组织

（黑色方块表示职员参与项目活动） 项目协调
2.4全局管理的关键方法
　　全局管理涵盖面非常广泛，全局管理要处理一个连续运转企业在管理中方方面面的问题，它包括：
　　 财务和会计，推销和市场、研究和开发、生产和分配。
　　 战略性计划、战术性计划、操作性计划。
　　 组织结构、组织行为、人事管理、补助方式、利益分配、晋升方式。
　　 通过鼓励、授权、监督、团队建设、冲突管理及其它技巧处理好工作关系。
　　 通过个人时间管理，压力管理和其它方法实现个人管理。

　　全局管理方法为项目管理奠定了基础，对项目经理而言是必须了解和掌握的，在任何一个项目中都可能要求运用一定的全局管理方法。本节要阐述的是那些很可能会对大数项目产生影响的全局管理方法。在本文的其它章节不会对此再作阐述了。

　　也有许多全局管理的方法仅仅与某一类项目或某一些应用领域有关系。比如，工作成员的人身安全在所有建筑都是至关重要的，而在大多软件开发项目中就没有那么重要了。

　2.4.1指导
　　科特（KOLER）区分了指导和管理，并且强调这两者对项目而言都是不可或缺的：缺少两者中的任何一个都很能会产生不良的结果，他指出管理从根本上而言关注的是"稳定地得到项目涉及人员所期望的主要成果"，而指导涉及的则是：
　　 确定方向--规划出对未来的构想及发展战略以便能实现这一构想。
　　 明确表达--实现这一构想需要很多人的协助，那么就有必要通过语言或行动让所有这些人明白这一构想。
　　 激发和鼓励--激励大家去努力克服在变革过程中可能会遇到的政策上的、官僚主义的，资源上的种种障碍。

　　在一个项目中，尤其是在一个大的项目中，项目经理通常也被期望成为项目的指导者。但是，并非只有项目经理可以对项目进行指导，项目中众多不同的个体在各个不同的时间都有可能对项目进行指导。项目的各个层次上都需要有指导（项目指导、技术指导、团队指导）。

　2.4.2交流
　　交流涉及信息的传递，信息发出者要确保信息是清晰明确，不含糊的，而且是完整的，这样才能有利于信息接收者准确接收，信息接收者则要确保接收的完整性，并且要正确地加以理解。交流是多元化的：
　　 书面的和口头的，听和说。
　　 内部的（项目的）和外部的（与顾客、媒介、公众等）。
　　 正式的（报告、摘要等）和非正式的（备忘录、非正式会谈等）
　　 纵向的（组织上下级）和横向的（与同级同事）。

　　全局管理的交流方法与项目交流管理（见第10章）有一定联系，但并不完全相同，交流本身是一门更为广博的学问，包含了丰富的知识，并不仅仅体现在项目中，如：
　　 发出者-接收者模式--反馈回路、沟通障碍等。
　　 媒介选择--何时采用书面形式、有时采用口头形式、有时采用非正式的书面备忘形式，何时采用正式的书面报告形式等。
　　 书写风格--主动语态、被动语态、名子结构、用词选择等。
　　 表达方法--形体语言、辅助的形象化设计等。
　　 达标管理技巧--日程安排、冲突处理等。
　　项目交流管理就是将这些广义的概念运用到具体的项目需求中去，比如，决定在何时以何种形式向谁怎样汇报项目的实施情况。

　2.4.3协商
　　协商是指与他人交换意见以便得出结论或达成共识，为了达成共识可能需要进行直接的协商或者通过一些辅助手段进行协商，调解和仲裁就是协商的两种辅助手段。

　　项目在许多层次、许多观点上会有多次的协商，在一种典型项目的进行过程中，项目工作人员需要就以下全部或部分内容进行协商：
　　 范围、成本和进度目标
　　 范围、成本或进度的变动
　　 合同条款
　　 任务分配
　　 资源

　2.4.4解决问题
　　解决问题包括明确问题和制定解决方案两方面的组合。它所关注的是那些已经出现的问题。（与风险管理相反，风险管理涉及的是潜在的问题）

　　明确问题要求将原因和现象进行区分，问题可能出自于内部（一个主要成员被分配到别的项目上去了），也可能来源于外部（开始工作所需得到的许可延迟了）。问题可能出在技术上（对产品设计的最佳方案有不同的观点），也可能出在管理上（一个职能部门没有按计划完成工作）或是出在内部内员（个性或办事风格有冲突）

　　制定解决方案包括分析总是以便寻求可行的解决办法，以及从中作出选择。我们可以制定解决方案，我们也以从顾客、工作组或是某一部门主管那儿寻求解决方案，一旦明确了解决方案，就必须实行，解决方案是具有时间性的，--如果解决方案制定得太早或太晚，那么既使是正确的解决方案也不一定是最好的解决方案。

　2.4.5向组织施加影响
　　向组织施加影响是一种"成事"的能力，这要求要了解所有项目涉及组织的正式及非正式的结构--执行组织、顾客、承包商和多的其它组织。向组织施加影响也需要了解运用势力和政治策略的一些技巧。

　　在这里指的是要从积极的角度运用势力和政治策略，彼弗（PTEFFER）是这样定义势力的"一种潜在的能力，可以影响行为，改变事情的发展，可以克服阻力，还可以让人们去做他们本不愿做的事情"，艾克（Eccles）也这样定义了政治"政治是要让一群可能有完全不同的利益的人产共同参与的行动，政治就是创造性的利用冲突和无序"。当然，它也有消极的一面，试图协调各种利益冲突的努力有可能导致权力之争以及组织游戏，这时会使得他们自己毫无工作效率。
2.5社会经济学的影响
　　和全局管理一样，"社会经济学的影响"包括一系列广泛的论题。项目管理工作组必须了解社会经济的现状和发展趋势，可能会对他们的项目产生重要的影响：社会经济中一个很小的变化在经过一段时滞以后都有可能会造成项目的重大变化，我们在许多潜在的社会经济影响中选择介绍几类经常影响项目的因素。

　2.5.1标准和规定
　　国际标准认证组织区别了标准和规定：
　　 一项标准是"一份经认证组织认证过的文本，它为产品、（生产）过程或服务预定了规则、指导或特征，这些标准具有通用性，可以反复使用。是否采纳标准是不具强制性的，从有压液体的热稳定性到计算机磁盘的尺寸，各种东西都有大量在用的标准。"
　　 一项规定是"一份对产品，过程或服务特征的计划文件，包括了适当的行政条例，要按规定行事，这是具有强制性"。建筑尺码就是一种规定的例子。
由于标准和规定有很多相互交迭之处，因此我们在讨论这两者时必须加以注意，比如：
　　 标准作为一种指导，说明了优先的方法和后继的方法，当它被广泛采纳时就成为了一种事实上的规定（如，对大多建筑项目进度安排使用了关键线路法）。
　　 标准和规定不同层次都具有强制性（如：通过政府机构要求强制执行，通过执行组织的管理强制执行，或者通过项目管理工作组强制执行）。

　　对许多项目而言，对有关标准和规定（无论是如何定义的）的充分了解会在项目结果中体现出来，也有一些情况下，这种影响是看不见的或是不确定的，这必须在项目风险管理中加意注意。

　2.5.2国际化
　　由于越来越多的组织从事的工作跨越了国界，因此越来越多的项目也是跨越国界的。除了对项目范围、成本、时间和质量的传统考虑外，项目工作组也必须考虑时区不同的影响、国家和民族的节日，为了面谈所需的旅行需要，电话会谈的服务工作及易变的政治分歧。

　2.5.3文化影响
　　文化是"大众行为模式、艺术、信仰、风俗习惯及其它人类工作和思想成果的总称"，每个项目都是在一种或多种文化形式的背景下运行的，文化影响的领域包括政治、经济、人口统计、教育、道德、种族、家教以及习题、信仰和态度，这一切影响着个人及组织相互作用的方式。

　　由于存在这种内在的相互作用所以需要我们对各种项目目标进行权衡--在一个工作区域加强工作力度就可能需要减少在另一个工作区域的工作力度，成功的项目管理要求能有效的控制这些内在的相互作用。
为了帮助大家理解项目管理的综合性，以及强调这种综合的重要性，本文就项目程序的构成及其它们的相互作用作了阐述，本章把项目管理分解为许多相互连接的程序，为大家理解4-12章有关程序的理论提供了必要的基础，本章的内容包括：

　　　3.1项目程序
　　项目由一个一个的程序组成，一个程序是"为实现某一个结果的一系列行动"，项目的程序是由人来完成的并且大致可以分为两类：
　　 项目管理程序注重对项目工作进行描述和组织。项目管理的程序在大多数时候对多数项目都是适用的，本章对此只作了简要的阐述，我们将在4-12章中再作进一步讨论。
　　 产品导向型程序注重对项目产品进行具体说明并进行制造。产品导向型程序常常是通过项目生命周期来进行定义（见第2章第1节），并且在不同的应用领域会有所不同（见附录F）。
项目管理程序和产品导向型程序在整个项目中会相互迭用、相互作用。比如，如果缺乏对如何制造产品的基本了解，我们就无法确定项目的范围。
3.2程序块
　　项目管理程序可以被分为五块，每块有一个或多个程序组成：
　　 起始程序块--确定一个项目或一个阶段可以开始了，并要求着手实行。
　　 计划程序块--进行计划并且保持一份可操作的进度安排，确保实现项目的既定商业目标。
　　 执行程序块--协调人力和其它资源，执行计划。
　　 控制程序块--通过监督和检测过程确保项目达到目标，必要时采取一些修正措施。
　　 结束程序块--取得项目或阶段的正式认可并且有序地结束该项目或阶段。

　　程序块通过各程序块的结果进行连接--个程序块的结果或输出是另一个程序块的输入。在核心程序块间，程序块反复进行连接--计划在开始时为执行提供了一份书面的项目计划，随后又给项目计划提供一份更新的书面文件，以示项目的进程。图3-1表示了这种联系，另外，项目管理程序块不是相互分立的、一次性的事件；在整个项目的每一个阶段它们都会不同程度的相互交迭，图3-2表示了程序块是如何交迭的，在一个阶段内这种交迭会怎样变化。

　　项目管理程序 最后，程序块的相互作用也会跨越阶段；一个阶段的结束作为下一个阶段开始的输入。比如，结束一个设计阶段要求顾客接受认可设计文稿。类似的，设计文稿为实施阶段提供了产品说明。这种内部作用如图3-3所示。

　　在每一个阶段开始时重复起始程序确保项目不会偏离既定的商业要求，也帮助确保当商业要求已不存在或项目已不可能满足这种要求时中止这一项目。在第5章第1节"起始"部分会进一步详细讨论商业要求。

　　尽管图3-3表示的是分立的阶段和分立的程序块，但在实际项目中它们可能会有相互交迭。比如，计划程序不仅为成功地完成项目提供了本阶段所需做的工作的细节，并且可能为下一个阶段所需做的工作提供前期的说明。这种项目计划的推进式细节说明常常被称为"滚动计划"。
3.3程序的相互影响
　　在每一个程序块中，各个程序通过它们的输入、输出进行连接。如果将注意力集中于这些连接上，我们可以这样描述程序：
　　 输入--书面文件或书面表述的工作，下达开始工作的指令。
　　 工具和技巧--运用各种输入得到输出。
　　 输出--书面文件或书面表述的工作，它们是每个程序结束后得出的结果。

　　在下文我们列出了对于大多数应用领域中的大多数项目都普遍适用的项目管理程序，在4-12章我们会详细讲解。程序名后括弧中的数字指明了在哪一章节会作进一步阐述。在这里阐述的程序内部的相互作用同样也是对大多数应用领域的大多数项目适用的。在第3章第4节我们讨论按顾客要求确定有关程序说明和相互作用的问题。

　　3.3.1起始程序块
　　图3-4表示了在这一程序块中单个的一个程序。
　　 起始（5.1）--指示组织开始项目下一个阶段的工作。

　　3.3.2计划程序块
　　计划对于一个项目是非常重要的，因为项目涉及许多以前从末做过的工作，因此在这一部分有相对较多的程序。但是，程序的数量并不代表计划是项目管理中最主要的部分--计划的工作量应与项目的范围和还有信息的实用性相匹配。
　　
　　图3-5表示了项目计划程序块中程序的相互关系（这是图3-1中椭圆形"计划程序块"的扩充）。这些程序是在计划完成之前反复运作的程序标题。比如，如果开始设定的完成日期是不能被接受的，那么项目资源、成本，或者甚至是范围都可能需要重新制定。另外，计划并不是一门精确的科学--两个不同的工作组可能会为同一个项目制定出区别很大的计划。

　　核心程序 一些计划程序间有很明确的关联性，这使得它们在多数项目中需要按相同的次序来实施，比如，在对活动进行进度安排和成本核算前首先需要对活动本身进行界定。这些核心计划程序可能会在一个项目的任何一个阶段，被反复实施好几次。核心计划程序包括：
　　 范围计划(5.2)--制定一份书面的范围表述，作为将来需要作项目决定时的基础。
　　 范围界定(5.2)--将主要的项目工作步骤细分为更小、更易管理的构成单元。
　　 活动定义(6.1)--确认具体的活动，这些活动的实施对于完成项目各阶段的工作成果是必须的。
　　 活动顺序安排(6.2)--明确并用书面形式表述活动内部的关联性。
　　 活动持续时间估计--估计为完成各个活动所需的工作时间。
　　 进度安排(6.4)--分析活动顺序、活动持续时间和资源需求，制定项目进度。
　　 资源规划(7.1)--确定实施项目活动所需的资源（人力、装备、原料）及相应的数量。
　　 成本估计(7.2)--估计实施项目活动所需的资源成本。
　　 成本预算(7.3)--将总体成本估计分配到各项工作上。
　　 项目计划研究(4.1)--将其它计划程序的结果纳入到一份稳定、连贯的文件中。

　　辅助程序 在其它的项目计划程序中的内部相互关系比核心过程更有赖于项目的性质。比如，有一些项目几乎没有或没有可识别的风险，一直到大部分的计划已经被实施且工作组认识到成本和进度安排受到了严重的挑战时才出现很大的风险，尽管在项目计划期间，这些辅助程序断断续续地按需要被实施，但它们不是可以自由选择的。辅助程序包括：
　　 质量规划(8.1)--明确哪一些质量标准是与本项目相关的，决定怎样去满足这些标准。
　　 管理规划(9.1)--确定、记录并分配项目职责和报告关系。
　　 人员组织(9.2)--组织项目工作所需的人力资源。
　　 沟通规划(10.1)--识别项目涉及人员所需的信息和沟通需求。谁需要什么信息、何时需要、以及怎样传递给他们。
　　 风险认别(11.1)--识别可能会影响项目的风险，并且说明每种风险的特征。
　　 风险量化(11.2)--进行风险评估，并且分析风险间的相互作用，确定一系列可能的项目结果。
　　 风险对策研究(11.3)--确定进行机会选择和危险应对的步骤。
　　 采购计划(12.1)--确定购买什么，何 购买。
　　 征集申请书计划(12.2)--以书面形式表述产品需求和识别潜在的来源。

　　3.3.3执行程序块
　　和第3章第2节的第2部分中的计划程序块一样，执行程序程块也包括核心程序和辅助程序。图3-6表示了下列程序是如何相互作用的：
　　 项目计划的执行(4.2)--通过实施计划内的活动来执行计划。
　　 范围核实(5.4)--项目范围的正式验收。
　　 质量保证(8.2)--有规律的对所有项目工作进行评估，确保项目达到相关的质量标准。
　　 团队建设(9.3)--开发个人及团队的工作技能，以便提高实施项目工作的水平。
　　 信息传递(10.2)--定期向项目涉及人员传递他们所需的信息。
　　 征集申请书(12.3)--求征适当的报价。
　　 货源选择(12.4)--从潜在的卖方中进行选择。
　　 合同管理(12.5)--处理与卖方的关系。

　　3.3.4控制程序块
　　必需有规律的评测项目工作，以便知道实施情况与计划间存在的差异。各工作区域中存在的差异都被纳入控制程序块中，一旦发现出现了重大差异(如对项目目标构成威胁的差异)就需要重新正确实施计划程序，对计划加以调整。比如，一项活动延误了，就需要根据所延误的时间，或根据对成本预算及进度安排权衡并调整目前的人员规划。控制也包括对可能发生的问题预先采取防范措施。控制程序块同样也包括核心程序和辅助程序，图3-7表示以下程序的相互作用：
　　 全程变化控制(4.3)--协调整个项目中出现的变化。
　　 范围变化控制(5.5)--控制对项目范围的改变。
　　 进程控制(6.5)--控制对项目进程的改变。
　　 成本控制(7.4)--控制对成本预算的改变。
　　 质量控制(8.3)--监测具体项目结果，判断它们是否达到了相关的质量标准，确定消除导致不满意实施状况的成因的方法。
　　 实施情况报告(10.3)--收集和发送实施情况的信息，包括情形报告、进程检测及预测。
　　 风险对策实施控制(11.4)--在项目进行中对风险进行应变。
.3.5结束程序块

图3-8表示了以下程序的相互作用：
　　 行政收尾(10.4)--产出、收集、发放阶段或项目正式结束的信息。
　　 合同收尾(12.6)--合同完成，及对赊销的清偿。
3.4按顾客需求制定项目程序
　　在第3章中确定的程序及图示的内部相互关系满足了总体可行性检测的需要--它们在大多数时候对大多数项目适用，但是并不是所有项目都需要有这些所有的程序，也并不是所有的内部相互关系都适用所有的项目。比如：
　　 一个大量使用分包商的组织会在项目计划程序中，对每一次采购程序都加以明确的说明。
　　 缺少某一个程序并不意味着这个程序不应该被实施。项目管理工作组应该确认并且管理所有确保项目成功的程序。
　　 依赖于某种独一无二的资源的项目(商业软件开发)可能会在范围界定之前先确定工作人员及职责，因为所能获得的人才决定了所能进行的工作。
　　 有些程序输出可能预先确定控制的因素。如管理需要确定一个目标完成期限，而不是任由进程计划决定。
　　 较大型项目相对需要更多细节。如风险识别就需要分别对风险成本、计划风险、技术风险以及质量风险等进行细致分析。
　　 对干一些子项目和小项目来说，则不需付出太多努力在已经被限定于项目水平上的程序（如：谈判小组的成员就可以忽略谈判小组组长所承担的风险）或提供不重要功能的程序（如四人的项目就不必制定正规沟通计划了）。

　　当需要变化时，则变化应清晰界定，仔细权衡和极积应对。

　　 这章的核心是分析用于项目综合管理过程的程序、工具和技术。例如：当为了一个临时性的计划进行的成本估算或各种人员调整带来的风险被基本确认后，项目综合管理方可进入实施状态。然而，为了能成功地完成一个项目，综合管理也会同其他领域发生一定数量的联系。例如：　
　　 项目的具体工作必须要同项目执行组织正在进行的具体操作结合起来。
　　 产品范围和项目范围必须结合起来（产品范围和项目范围是不同的，这些内容的介绍在第5章）。
　　 项目工作必须与不同特殊功能的子项目相结合（象工程设计项目中的工民建、电力工程和机械图
纸一样）。

　　　4.1项目计划的开发
　　项目计划的开发
　　项目计划的开发是用其他计划程序的输出，创建一个内容充实、结构紧凑的文件，使它能够引导项目计划的实施和控制。这个过程几乎经常重复几次。

　　 例如：最初的草案可能包括一般性的方法并没有时间期限，而最终计划则要反映具体的方法和有明确的时间期限。这个项目计划用于：
　　 引导项目的实施。
　　 编制项目规划的设想。
　　 记录项目计划讨论好的有关任选事宜。
　　 促进项目参与者之间的沟通。
　　 确定主要的管理问题如内容、范围和时间等。
　　 为进一步提高测量和控制项目的水平提供一个标准。

　　 4.1.1对项目计划开发的投入
　　 1． 其他规划的输出。其他项目规划程序在3.3中概括，这些项目规划程序的所有输出是开发这项计划的输入。其他规划的输出包括两个基本文件，即工作分析结构和辅助说明。许多项目也要求应用专门领域的输入（例如：许多建筑项目要求有资金流程预测）。

　　 2． 历史资料。可行性的历史资料（比如；估算记录、过去项目执行情况记录）在其他项目规划程序的制定中已经考虑到了。在项目计划的开发期间，这些资料也有参考价值，它能帮助人们证实假设的真实性和评价任意一个在项目进程中，已得到确认的资料。

　　 3． 组织管理政策。所有的组织包括项目管理组织在内，可能都有正式的或非正式的政策，在计划时必须考虑到它们的影响。要考虑的组织管理政策通常包括以下内容，但并不局限于此：
　　 质量管理--通过审计，继续改进目标。
　　 人事管理--雇佣和解雇标准，雇员执行任务的情况分析。
　　 财务监控--时间报告、要求的经费和支出情况分析、会计帐目和标准合同条款。

　　 4． 制约因素。制约因素是限制项目管理团队运行的因素。例如：预先确定预算被认为是影响项目团队对范围、职员人数和日程表选择的极其重要的因素。当一个项目按照合同执行时，合同条款通常是受合同制约的。

　　 5． 假设。为了项目规划目标的准确性，考虑到的假设因素必须有科学性、真实性和肯定性。例如，如果一个项目不能确定关键人物的到场日期，那么，项目团队可以假设一个具体的开始时间。假设通常保含着一定程度的风险。

　　 4.1.2为项目计划开发所采用的工具和技术
　　 1． 项目规划方法。在项目计划开发期间，项目规划方法是用于引导项目团队工作的一种结构分析方法。它可能是越来越简单的标准形式和图纸（不是信件就是电文，正式的或非正式的形式）或者是越来越复杂的一系列模型（比如：蒙特洛的风险分析一表）。多数项目规划方法都将项目管理的软件这种"刚性"手段和易召集的会议这种"柔性"手段结合在一起使用。

　　 2． 参与者的技能和知识。每个参与者所拥有的技能和知识，在项目计划开发中都能得到充分的利用。项目团队必须营造一个让参与者发挥自己才干的适当环境（看第9章第3节，团队建设）。谁奉献？他们奉献些什么？什么时候改变。例如：
　　 对于按照大量的合同进行运作的建筑项目来说，专业成本工程师对制定有利的项目目标，在目标准备阶段的合同金额决定时起着主要作用。
　　 对一个已事先确定了人员结构的项目来说，每个参加者为制定满意的成本和进度目标，通过回顾期限和理智的估算都能做出有益的贡献。

　　 3． 项目管理信息系统（PMIS）。项目管理信息系统是由用于归纳、综合和传播其他项目管理程序输出的工具和技术组成。它用于提供从项目开始到项目最终完成，包括人工系统和自动系统的所有信息。

　　 4.1.3项目计划开发的成果
1． 项目计划，项目计划是正式被批准的用于管理和控制项目实施的文件。它的作用在沟通管理计划中作了界定（比如：执行组织的管理，可能不要求提供详情，而承包商则要求每个问题要提供全部细节）。在一些应用领域，综合项目计划是归在这个文件中的。

　　 应该搞清楚项目计划和项目执行情况测量基准是有明显区别的。项目计划是一个文件或文件的汇集，当得到有关项目的进一步的信息后，它会被改动。项目绩效测量基准代表了一种管理控制，这个管理控制通常只会周期性地变化，而且通常只要对通过的范围变化作出相应的反应。

　　 有许多方法可以用于组织和表示项目计划，但是它的共同特征包括在以下几方面（这些项目工作在其他章节阐述的更多一些）：
　　 项目证书。
　　 项目管理方法或战略的阐述（在其他章节对个人管理计划进行了总述）。
　　 范围阐述，包括工作细目和项目目标。
　　 工作分析结构（WBS），是把项目工作分解到控制系统可以操作的程度。
　　 成本估算、进度计划的开始日期和责任分配，一直分解到WBS的控制系统可以操作的水平。
　　 为进程和成本制定的绩效测量标准。
　　 对项目每个阶段的具有里程碑意义的事件和目标日期的记载。
　　 关键的或必需的人员。
　　 主要风险，包括制约因素和假设以及每个阶段的对应计划。
　　 辅助的管理计划，包括范围管理计划和进度管理计划等。
　　 已经公布的和悬而未决的决定。

　　 根据各项目的需要，其他项目规划的输出应该包含在这正式计划中。例如：为一个大的工程作的项目计划通常包括一个组织管理图表。

　　 2． 辅助说明。为项目计划所做的辅助说明包括：
　　 没有包括在这个项目计划中的其他规划程序的输出。
　　 在项目计划开发期间产生的附加信息和文件（比如：制约因素和假设如果事先没考虑到）。
　　 技术性文件、要求、特征和设计等方面的文件。
　　 有关标准文件。

　　 应该根据需要对这些材料进行组织，使它们在项目计划实施期间更易于利用。

　　 　4.2项目计划的实施
　　 项目计划执行是实施这个项目计划的主要过程--项目的巨额预算在这个执行过程中被花掉。在这个过程 ，项目经理和项目管理团队必须协调和指导项目中存在各种技术和组织问题。这是项目的应用领域最有影响的项目程序。因为项目产品是在这个过程中产生的。

　　 4.2.1对项目计划实施的输入
　　 1． 项目计划。项目计划在（1.1.3.1中阐述了）。具体项目的管理计划（范围管理计划、风险管理计划和采购管理计划等）和绩效测量基准是对项目计划实施的主要投入。

　　 2． 辅助说明。辅助说明在4.1.3.2中阐述了。

　　 3． 组织管理政策。组织管理政策在4.1.1.3中阐述。所有包括组织管理政策都在项目中有正式的和非正式的两种，它们会影响项目计划的实施。

　　 4． 纠正措施。纠正行为所做的是把未来项目的执行，按照人们的预期纳入与项目计划要求相一致的轨道进行运转。纠正措施是各种控制程序的一个输出--在这里作为一种输入完成反馈环，这个反馈环是为确保项目管理的有效性。

　　 4.2.2项目计划实施的工具和技术
　　 1. 普通管理技能。普通管理技能如领导艺术、信息交流和协商组织等，都对项目计划的实施产生实质性的影响。普通管理技能在第2章第4节中阐述。

　　 2. 生产技能和知识。项目团队必须适当地增加一系列有关项目生产的技能与知识的学习。这些必要的技能被作为项目规划（尤其是在7.1中的资源规划阐述的）的一部分得以确认，并通过人员的组织过程来获取、体现。

　　 3. 工作分配系统。工作分配系统是为确保批准的项目工作能按时、按序地完成而建立的正式程序。基本的方式通常是以书面委托的形式开始进行工作活动或启动工作包。
一个工作分配系统的设计，应该权衡实施控制收入与成本之间的关系。例如：在一些比较小的项目上，言语分配就足够了。

　　 4. 形势评论会。形势评论会是把握有关项目信息交流的常规会议。在许多项目中，形势分析会以各种不定期的和不同级别的形式召开（比如：项目管理团队可有周会并通过周会或月会的形式与客户沟通）。

　　 5. 项目管理信息系统。项目管理信息系统在4.1.2.3中阐述。

　　 6. 组织管理程序。项目的所有组织管理程序包括了运用在项目实施过程中的正式的和非正式的程序。

　　 4.2.3项目计划实施的结果
　　 1． 工作成果。工作成果是为完成项目工作而进行的具体活动结果。工作成果资料--工作细目的划分、工作已经完成或没有完成，满足质量标准的程度怎样，已经发生的成本或将要发生的成本是什么等等--这些资料都被收集起来，作为项目计划实施的一部分，并将其编入执行报告的程序中（看第10章，第3节对执行报告有更细的讨论）。

　　 2． 改变要求。改变项目要求（比如：扩大或修改项目合同范围，修改成本或进行估算等等）通常是在项目工作实施时得到确认。

　　 　4.3全程变化控制
　　 全程变化控制是关于(a)影响造成项目变化的因素，并尽量使这些因素向有利的方向发展；(b)判断项目变化范围是否已经发生；(c)一旦范围变化已经发生，就要采取实际的处理措施。全程变化控制要求：
　　 保持绩效测量标准的一致性--所有被通过的变化应该能够反映在这个项目计划中，但是，只有项目范围界定的改变会影响绩效测量标准.
　　 要确保产品范围的变化要在已确定了的工作范围中反映出来(产品范围和工作范围是不同的,有关这些内容的介绍在第5章)。
　　 协调变化过程的理论体系用图表4-2来阐明。例如,一个工作进程表的改变,通常会影响成本、风险、质量和人员调整。
图４
　　 4.3.1对全程变化控制的输入
　　 1． 项目计划。项目计划为变化控制提供基本的参考（看4.1.3.1）.

　　 2． 执行报告。执行报告（在第10章第3节阐述）提供的资料是项目执行中的一些情况。执行报告也能提醒项目团队公布项目未来可能出现的问题。

　　 3． 改变要求。改变要求有多种形式--口头的或书的、直接的或间接的、内在的或外在的原因及合法的代理或任选的。

　　 4.3.2为全程变化控制投入的工具和技术
　　 1. 变化控制系统。变化控制系统是正式汇集资料，创建文件程序，创建的这个文件程序必须是经权威项目文件认可了发展阶段的文件。它包括书面工作、跟踪系统和必要的权威部门认可了的变化级别。
在多数场合，项目执行组织将有一个变化控制系统，它能够通过项目，用"好象是什么"的形式被采纳。然而，如果没有一个合适的控制系统可以利用，则项目团队就需要开发一个这种系统，作为这个项目的一部分。

　　 许多变化控制系统都包括一个变化控制委员会（CCB），负责批准或抵制变化要求。控制委员会的权力和责任应该得到仔细地界定，并且要取得主要参与者的同意。在一些大的复杂的项目中，可能会有很多控制委员会，他们负有不同的职责。

　　 变化控制系统也应该包括这样一些程序，这些程序是在没有预先审议情况下通过的处理改变的程序。例如：象紧急紧急情况的处理结果。典型的例子是，一个控制系统将允许对一些确定的变化类别实行"自动放行处理"许可。这些变化必须也能被记录并让人们获得，以便在项目后期不要引发一些问题。

　　 2.结构管理。结构管理是编制一些文件程序，用于对技术和行政政策管理进行指导和监督：
　　 项目或系统的界定、文件功能和物理特征。
　　 对于任何会改变的特征的变化进行控制。
　　 记录和报告这些变化并作必要的分析。
　　 审计这个项目和系统的工作，检验它们是否符合要求。

　　 在许多应用领域，结构管理是变化控制系统的一个分支，用它是为确保项目产品说明的正确性和完整性。然而，在一些应用领域，结构管理这个词是用来描述一些精确的变化控制系统的。

　　 3. 绩效检测。绩效检测技术比如能帮助人们判断纠正措施是否符合计划的要求。

　　 4. 附加计划。项目很难按照计划的要求精确地运转。预期的变化可能要求新或修改成本估算、修改活动顺序，分析对风险的任意对策或对项目计划进行其他评判。

　　 5. 项目管理信息系统。项目管理信息系统在4.1.2.3中阐述。
　　 4.3.3从全程变化控制中的输出
　　 1. 项目计划的更新。项目计划的更新是对项目计划内容进行修改或辅助说明（在4.1.3.1和4.1.3.2中有反映）。根据需要适当地通知项目的参与者。

　　 2. 纠正措施。纠正措施在4.2.1.4中阐述。
　　
　　 3. 经验总结。我们应该把各种变化的原因，纠正行为背后的理由和经验总结的其他类型编制成文件，以作为历史资料的一部分，为执行组织完成这个项目和其他项目报务。

　　 本章的核心是阐述用于管理项目的程序、工具和技术。用于管理项目产品范围变化的程序、工具和技术，在不同应用领域中会有所不同，通常它们被认为是项目生命周期的一部分（项目的生命周期在2.1中阐述）。

　　 一般情况下，一个项目是由一个单个产品组成的，但是，这个产品可能包括几个子要素，每个子要素都彼此分离，但是在产品活动范围中又相互依存。例如：一个新的电话系统，通常包括四个子要素--硬件、软件、试运行和完成。
　　产品范围的完成情况是参照客户的要求来衡量的，而项目范围的完成情况则是参照计划来检验的。这两个范围管理模型间必须要有较好的统一性，以确保项目的具体工作成果，能按特定的产品要求准时交付。
　　　5.1启动阶段

　　启动阶段是正式认可一个新项目的存在，或者是对一个已经存的项目让其继续进行下一阶段工作的过程（看2.1，对项目阶段有详细的阐述）。在一些组织中，一个项目计划的正式启动，是在必要的学习、初步的计划和其他相当于划分项目开始阶段的工作完成后才进行的。有些项目形式，如特殊的内部服务项目和新产品开发项目，它们的启动不是很正规，要受到所做的工作数量的制约，目的是为项目正式启动时，职员能牢固地掌握这些工作方法。项目通常是由于以下的需要而被核准的
　　 市场需求（比如：一家石油公司核准一个建立新炼油厂的项目，是对长期的汽油发展战略作出
的反应）。
　　 商业需求（比如：一个旅游公司为了增加收入核准的项目是开辟一条新的旅游线路，以增加它
们的收入）。
　　 客户的需求（比如：一家电力公司核准一个建一家新的发电厂的项目，为新的工业园服务）。
　　 工艺的进步（比如：电力公司核准一个引进音像设备的项目，是为了发展影视娱乐业）。
　　 法律要求（比如：涂料生产厂家核准的项目是，建立一个处理有毒物品的生产线）。

　　 这些动因也可能被称为是问题、机遇或商家的要求。无论叫什么，其核心的问题是管理部门通常要做出怎样对应的决策出来。

　　5.1.1对启动阶段的投入
　　1． 产品说明。产品说明应该能阐明项目工作完成后，所生产出的产品或服务的特征。产品说明通常在项目工作的早期阐述少，而在项目的后期阐述的多，因为产品的特征是逐步显现出来的。

　　 产品说明也应该记载已生产出的产品或服务同商家的需要或别的影响因素间的关系，它会对项目产生积极的影响（看上面的清单）。尽管产品说明的形式和内容是多种多样的，但是，它应能对以后的项目规划提供详细的、充分的资料。

　　 许多项目都包括一个按购买者的合同进行工作的销售组织。在这种情况下，最初的产品说明通常是由购买方提供的。如果买者的工作本身就是制定项目的，则买者的产品说明就是对自己工作的一种陈述，这些将在12.1.3.2里阐述。

　　 2． 战略计划。所有的项目组织都应该提供项目执行组织的战略目标--在项目决策的选择中，执行组织的战略计划应该作为一个考虑的因素。

　　 3． 项目选择标准。项目选择标准通常是通过项目产品界定的，它涉及到管理可能包含的全部范围（如：财政收入、市场份额和公众的观念等）。

　　 4． 历史资料。历史资料包括以前项目选择决策的结果和以前项目执行的结果，在可获得的范围内对它们加以考虑。在项目启动阶段，就包含了对项目下一阶段工作的认可时，有关前阶段结果的信息通常是非常重要的。
　　5.1.2为启动阶段投入的工具和技术
　　1． 项目选择方法。项目选择方法通常是下列两种模型之一：
　　 利润测量方法--比较研究法、评分模型、利润贡献或经济模型。
　　 制约最优化方法--数学模型、用线性的、非线性的、动态的、完整的及混合目标项目规则系统。

　　 这些方法通常被作为决策模型来考虑。决策模型既包括常规技术（决策树、核心选择和其他），也包括特殊技术（历史进程分析、逻辑结构分析及其他）。在一个成熟模型中，对项目选择标准的应用通常被作为一个分离独立的阶段。

　　 2． 专家评审。专家评审通常是要对这个项目的投入进行评估。象这种专家评价，可以通过一个组织或拥有特殊知识和受了专门培训的个人来进行，可以通过许多途径获得。包括：
　　 这个执行组织中的其他单位
　　 顾问
　　 专家和技术联合会
　　 工业集团
　　5.1.3启动后的成果

　　 1． 项目证书。项目证书是正式认可项目存在的一个文件。它对其他文件既有直接作用，也有参考作用。
　　 既定的商业目标。
　　 产品说明书。

　　项目证书应该通过管理者对项目及项目所需的条件进行客观的分析后颁发，它提供给项目经理运用、组织生产资源，进行生产活动的权力。

　　当一个项目按照合同执行时，合同条款通常象项目证书一样，为销售者服务。

　　 2． 指定/委派的项目经理。通常，项目经理应该尽可能在项目的早期进行指定和委派是比较合适的。项目经理应该在项目计划实施开始之前被委派（这些理论的阐述在4.2中），更应该在许多项目规划完成之前就委派好（项目的规划过程在3.3.2中阐述）。

　　 3． 制约因素。制约因素是限制项目管理团队进行运作的要素。例如：事先确定预算是制约项目团队的操作范围、职员调配和进步计划的一个很重要的因素。
当一个项目按照合同执行时，合同条款通常是受合同制约的。

　　 4． 假设因素。为了规划目标的准确性，考虑到的假设因素必须具有科学性、真实性和确定性。例如：如果关键人物的到场日期不能落实，那么项目团队就应该设置一个具体的开始时间。假设通常包含有一定程序的风险。在此它们可能被确认或它们可能是一个风险界定的输出（在11.1进行论述）。

　　　5.2 范围规划
　　范围规划是创立书面文件，阐述项目范围为未来项目提供基础条件的过程，特别是包括了用以确定项目或阶段是否成功完成的标准。例如：一个工程公司签订的合同是设计一个石油处理工厂，就要求在设计具体目标时，要界定好具体的工作范围。范围阐述形式的基础是通过确认项目目标和主要项目的子项目，使项目团队与项目客户之间达成一个协议。

　　 如果范围阐述的所有要素已经具备（如：主要项目的子项目能够反映项目目标，项目证书能证明项目目标），那么，这个过程就仅剩实质性的制定书面文件的工作了。

　　5.2.1对范围规划的输入
　　 1. 产品说明。产品说明在5.1.1.1中讨论。

　　 2. 项目证书。项目证书在5.1.3.1中阐述了。

　　 3. 制约因素。制约因素在5.1.3.3中作了阐述。

　　 4. 假设条件。假设的描述在5.1.3.4中。
　　5.2.2为范围规划投入的工具和技术
　　1. 产品分析。产品分析意味着开发一个更好、更明确的项目产品。它包括这样一些技术，如：系统工程、价值工程、价值分析、功效分析和质量功能展示等。

　　 2. 利润/成本分析。利润/成本分析意味着估算各种项目选择的有形成本和元形成本（支出）与利润（收益）。然后用投资收益率或投资偿还期限等经济方法，评估这些经确认的选择方案相对优势，用任选的鉴定方式估算投入--产出情况的合意程度。

　　 3. 可供选择的签订方式。可供选择的鉴定方式是个包容性较大的词，描述的是完成一个项目用任何一种技术，就能产生一个不同的方案。这里常用的是一般性的各种管理技术，许多管理技术有一个共同特征："头脑风暴"和"迂回思维方式"。

　　 4. 专家评审。专家评审在5.1.2.2中阐述。
　　5.2.3 从范围规划中的产出
　　1. 范围阐述。范围阐述是为制定未来项目决策，进一步明确或开发一个参与者之间能达成共识的项目范围提供一个纪实基础。作为项目的过程，阐述的这个范围可能需要修改或精确些，从而很好地反映项目范围的变化。这个范围阐述可以直接进行分析，也可以通过参考其他文件来得出：
　　 项目调整--商家的既定目标。项目调整要为估算未来的得失提供基础。
　　 项目产品--产品说明的简要概况（产品说明在5.1.1.1中讨论）。
　　 工作细目成果--列一个子产品级别概括表，完整的、满意的这些子产品标志着项目工作的完
成。例如：为一个软件开发项目设置的主要子项目可能包括工作所需的电脑代码、工作手册和专门的导师。当这些子产品都知道了，排除应该是确定了，任何不明显的排除都包含在这个排除中了。
　　 项目目标--考虑到项目的成功性，质量标准必须要满足项目的要求，项目目标至少要包括成本、进度表和质量检测。项目目标应该有标志（如：成本）、单位（如美元、英磅）和绝对的或相对的价值（如：少于150万美元等）。不可量化的目标（如："客户的满意程度"）要承担很高的风险。

　　在一些应用领域，项目工作细目被称为项目的目标，而全部的项目目标被称作是评价项目成功的关键。

　　2. 辅助说明。为项目范围阐述作辅助说明，应该是根据需要记录和编组一些文件，并通过其他项目管理程序，把它变成易被利用的东西。辅助说明总是包括所有已认定的假设文件和制约因素。附加说明的数量在不同的领域中会有所不同。

　　 3. 范围管理计划。范围管理计划是描述项目范围如何进行管理，项目范围怎样变化才能与项目要求相一致等问题的。它也应该包括一个对项目范围预期的稳定而进行的评估（比如：怎样变化、变化频率如何及变化了多少）。范围管理计划也应该包括对变化范围怎样确定，变化应归为哪一类（这特别困难--而且也因此绝对必要--当产品特征还在逐步形成中时，依然是逐步显视的）等问题的清楚描述。

　　 根据具体项目工作的需要，一项范围管理计划可以是正式的或非正式的、很详细的或粗略的。项目管理计划是全部项目计划（在4.1.3.1中阐述）的分支要素。

　　　5.3范围界定
　　范围界定包括分解这个主要工作细目的子项目（象在范围阐述中界定的那样），使它变成更小、更易管理、操作的东西。目的是为了：
　　 提高估算成本、时间和资源的准确性。
　　 为绩效测量和控制确定一个基准线。
　　 使工作变得更易操作的，责任分工更加明确。

　　 正确的范围界定是项目成功的关键。"当它是一个很差劲的范围界定时，由于不可避免的变化会使最终项目成本可能会很高，因为这些不可避免的变化会破坏项目节奏，导致重复工作、增加项目运行的时间、降低生产功效和工作人员的士气"。

　　5.3.1对范围界定的输入
　　 1． 范围阐述。范围阐述在5.2.3.1中。

　　 2． 制约因素。制约因素的阐述在5.1.3.3中。当一个项目按照合同执行时，由合同条款定义的制约因素，在范围定义中通常是重要的考虑因素。

　　3． 假设条件。假设条件的阐述在5.1.3.4中。

　　 4． 其他规划输出。程序的输出在其他章节。考虑到可能对当前项目范围界定的影响，应该对其他规划的输出进行回顾。
　　5． 历史资料。在项目范围界定期间，应该考虑以前项目计划的有关历史资料。对于以前的项目来说，资料中的有关错误或省略的东西应该有特殊的用途。
　　5.3.2为界定范围投入的工具和技术
　　1. 工作分析结构样板。一个工作分析结构（WBSs，在5.3.3.1中阐述了）从以前的项目到新项目都能用，虽然每个项目是唯一的，但是，WBS经常能被"重复使用"，多数项目间在某种程序上是具有相似性的。例如：从每个阶段看，许多项目中给出的组织形式都有相同或相似的生命周期和因此而形成的相同或相似的工作细目要求。

　　 许多应用领域都有标准或半标准的WBSs，它能当作样板用。例如：美国国防部，有界定标准的WBSs为防御材料项目服务。图表5-2中展示出的样板是这些样板中的其中一个样板的一部分。

　　 2. 分解。分解意味着分割主要工作细目，使它们变成更小、更易操作的要素，至到工作细目被明确详细的界定，以有助于未来项目的具体活动（规划、评估、控制和选择）的开展。分解包含着以下主要阶段：

　　（1）确认项目的主要要素。通常，项目的主要要素是这个项目的工作细目和项目管理。然而，在一定时期内,这个主要要素总是根据项目的实际管理而定义的。例如：
　　 项目生命周期的阶段可以当作第一层次的划分，把第一层次中的项目细目在第二阶段继续进
行划分。
　　 组织管理政策在WBSs的每个分支中可能都不一样，用图表5-4来说明。

　　 （2）决定是否能对开发到这种详细层次的每个要素进行充分的成本和期限估算。这里"充分的"意味着能够改变项目运行过程--工作细目的分解如果在很久的将来才能完成的话，那么这种分解也就没了确定性。对于每一个要素，如果是充分、详细的论述，就有四个阶段，否则，是三个阶段--这意味着不同的要素有不同的分解层次。

　　这仅仅是WBS的图表说明形式。它不能代表任何专门项目的全部项目范围，也不意味着组建一个WBS是项目这种形式的唯一方法。

　　 （3）确认项目的组成要素。子项目的组成要素应该用有形的、可证实结果来描述，目的是为了绩效易检测。当我们知道了主要构成要素后，这些因素就应该用项目工作怎样开度，在实际中怎样完成形式来定义。有形的、可证实的结果既包括服务，也包括产品（比如：情形报告能够用图形来描述；对于一个工业项目，组成要素可能包括几个独立单位及对它们的综合）。

　　 （4）核实分解的正确性：
　　 为完成具体工作分解，划分更低层次的细目是否必要和充分？如果没必要，这个组成要素就必须重新修正（增加项目、削减项目或修改项目）。
　　 每个项目都要有明确的、完整的定义吗？如否果不是，这种描述需修正或扩充。
　　 是否每个项目都要有适当的日程表、预算能分配给特殊的组织单位（如：部门、团队或个人）？谁能担负起满意地完成这个项目的任务？如果没有，修正是必要的，为的是提供一个充分的管理控制。

　　 5.3.3从范围界定中的输出
　　1． 工作分析结构。一个工作分析结构是项目要素的一个子项目定位组，是对项目总范围的组织和界定：如果这个工作不是WBS系统内的，那么，这就是项目范围以外的工作。作为范围阐述，这个WBS通常是用来开发或巩固一个达成共识的项目范围。项目的划分每降低一个层次阐述，就要增加一个项目要素的详细描述。在5.3.2.2中阐述了为开发一个WBS的许多共同方法。一个WBS的正式代表形式是象图表5-2、5-3和5-4这种图表形式。当然，WBS不应该与表述方法混淆起来。在图表中绘制一个非结构式的活动清单并没有做成一个WBS。

　　这仅仅是WBS的图表形式。它不能代表任何专门项目的全部项目范围，也不意味着组建一个WBS是项目这种形式的唯一方法。

　　在WBS中的每一个具体项目工作通常都指定唯一的代码，这些代码被看作是与会计代码相同的。WBS的最低层次通常是指工作包。这些工作包可能在以后再分解，把它作为活动的定义。在6．1中阐述。

　　具体工作要素的阐述通常收集在WBS这个字典中。一个典型的项目分析字典，既包括了对工作包的阐述，也包括了对其他规划资料如进度表的日期、成本预算和员工分配等问题的阐述。

　　WBS不应该与其他表示项目信息的"分析结构"混淆。在一些应用领域，通常会用到的其他一些结构包括：
　　 契约性的WBS（CWBS），它是用于界定销售者提供给购买者的产品报告级别的。通常CWBS包括的内容要比WBS的少，它用于卖方管理买方的工作环境中。
　　 组织分析结构（OBS），它是用以展示工作要素已经分配给了具体的组织单位。
　　 资源分析结构（RBS），每一个RBS都是与OBS不同的，通常用于给个人分配工作要素的时候。
　　 材料清单（BOM），它代表了一种级别概念，表示了制成（或装配）一个工业产品所需的工具箱、零件和零部件。
　　 项目分析结构（PBS），它与WBS是基本相同的。PBS更广泛地应用在因WBS不能妥善表达BOM内容的领域中。

　　　5. 4范围核定
　　范围核定是通过参与者（倡议者、委托人和顾客等）的行为正式确定项目范围的过程。它要求回顾生产工作和生产成果，以保证所有 项目都能准确地、满意地完成。如果这个项目已提前终止，这个范围核实过程也应该证实并应以书面文件的形式把它的完成情况记录下来。范围核实与前面讲的质量控制是不同的，范围核定是有关工作结果的验收问题，而质量控制是有关工作结果正确性的问题。

　　 5.4.1对范围核定的投入
　　1． 工作成果。工作成果--项目阶段性的交付物已经完成或部分完成，已经发生的或将要发生的成本是什么等--它是项目施实的输出（在4.2中讨论）。

　　2． 生产文件。描述项目产品的生产文件，必须对项目的回顾有帮助作用。通过应用领域用生产文件描述这些文件(计划、特征、技术性文件和图纸等)的变化情况。

　　5.4.2为范围核实投入的工具和技术
　　1. 检验。检验包括用象测量、测验和考试等这样一系列活动去判断承担的工作任务是否符合计划的要求。检验有各种称呼：评价、产品评价、审查和走过场等；在应用领域，这些不同的词有它自己的使用范围和特定的含义。

　　 5.4.3范围核实的输出
　　1． 正式验收。验收文件是当事人或投资者已经认可了这个项目产品或某个阶段的文件，他们必须为完成这项工作准备条件，做出努力。象这种验收可能是有条件的，尤其是在一个阶段末的时候。

　　　5.5范围变化控制
　　范围变化控制是关于(a)影响造成项目变化的因素，并尽量使这些因素向有利的方面发展，（b）判断项目变化范围是否已经发生，（c）一旦范围变化已经发生，就要采取实际的处理措施。范围变化控制必需与其他控制管理程序（时间控制、成本控制、质量控制及其他控制在4.3中阐述）结合在一起用。

　　5.5.1对范围变化控制的输入
　　1．分析结构。WBS在5.3.3.1中进行了阐述，它确定了项目的范围基准线。

　　 2. 执行报告。执行报告在10.3.3.1中阐述。执行质量报告是提供一个项目范围执行情况，如中间产品已经完成或没有完成的资料。执行报告也能提醒项目团队公布未来可能发生的情况。

　　3. 改变要求。改变要求可以采取很多形式--口头的或书面的、直接的或间接的、从内部或外部开始及法定的（合法的）批准的或任选的。改变的可能是要求扩大项目范围或缩小范围。许多要求的改变都是这样一些情况导致的：
　　 一个外在事件发生了（如：政府的法规发生了变化）。
　　 产品范围的界定有错误或疏漏（比如：程控交换系统设计的失败，是因为它的覆盖面不够大）。
　　 项目范围的界定有错误或疏漏（比如：用材料清单代替了工作分析结构）
　　 产值增加的变化（比如：通过采用先进的技术，改变项目的发展环境，可降低成本，当环境还是
原来的情况时，降低成本是不可能的）。

　　 4．范围管理计划。范围管理计划在5.2.3.3中阐述。

　　5.5.2为范围变化控制准备的工具和技术
　　1. 范围变化控制系统。一个范围变化控制系统定义为这样一些程序，即通过它能改变项目范围。它包括工作面、跟踪系统和权威部门允许变化所需的认可标准。范围变化控制系统应该与综合管理中讲的全程变化控制系统（在4.3中论述）结合在一起用，尤其要与适合于控制产品范围的系统结合在一起。当项目按照合同执行时，范围变化控制体系必须按所有相关的合同规定执行。

　　 2. 绩效测量。绩效测量技术在10.3.2中阐述，绩效测量技术能帮助人们评估所发生的任何重大变化。如果变化发生后要求有纠正措施，那么，范围变化控制的一个重要部分是分析导致变化的原因是什么，并做出对应的处理决定。

　　 3. 附加规划。很少有项目能按合同的要求精确地运转。预期的范围变化可能要求对WBS进行修改或对其他的任选方法进行分析。
　　5.2.3范围变化控制的输出
　　1． 范围变化。范围变化是对已被认可的WBS所确认的项目范围的任何修改。范围变化经常要求对成本、时间、质量和其他项目目标进行判定。通过规划程序反s馈的范围变化情况，技术信息和规划文件，要根据需要进行更新，并适当地通知参与者。

　　 2． 纠正措施。纠正措施所做的事是把未来项目按照人们的预期，纳入项目计划所要求的轨道进行运作。

　　 3． 经验总结。我们应该把各种变化的原因，纠正行为选择的背后理由，以及从范围变化控制中得出的其他形式的经验教训，当作文件记录下来，目的是把这些资料变成历史记录的一部分，为项目执行组织执行这个项目和其他项目提供参考。

　　 以上过程彼此相互影响，同时也与外界的过程交互影响。根据实际情况，每一过程由专人或数人或一组人加以完成。在项目各阶段，每个过程通常至少出现一次。
虽然上述过程是分开叙述具有明确的分界。实际上它们也许是重迭和相互影响的。过程间相互影响在第3章详细讨论。

　　 有些项目，特别是一些小项目，活动排序、活动时间估计和进度安排这些过程紧密相连可视为一个过程。（例如，当这些过程可由一个人在较短时间内完成时）这里还是把这四个过程作为不同过程，因为每一过程所用工具和方法是不同的。
当前，在项目管理领域里，活动（ACTIVIFIES）和作业（TASKS）的关系的用法并不统一。
　　 在许多应用领域里，活动视由作业组成，这种用法最常见。
　　 在其它，作业视由活动组成。

这里重要的不是使用词的名称，而是要做的工作是否被描述清楚以及被工作人员所理解。
图6-1项目时间管理框

　　　 6.1定义活动
　　 定义活动是一过程，它涉及确认和描述一些特定的活动，完成了这些活动意味着完成了WBS结构中的项目细目和子细目。通过定义活动这一过程可使项目标体现出来。

　　 6.1.1定义活动过程的输入
　　 1、 工作分层结构图。工作分层结构图是定义活动过程的主要输入（见节5.3.3.1关于WBS的详尽讨论）。

　　 2、 范围的叙述：在定义项目活动时，包含在范围陈述中的项目的必要性和项目目标必须加以考虑（见节5.2.3.1关于项目范围描述的详细讨论）。

　　 3、 历史的资料：在定义项目活动过程中，要考虑历史的资料（以往类似的项目包含哪些活动）。

　　 4、 约束因素：约束因素将限制项目管理小组的选择。

　　 5、 假设因素：要考虑这些假设因素的真实性、确定性，假设通常包含一定的风险，假设是对风险确认的结果（见节11.1）。

　　 6.1.2定义活动的工具和方法
　　 1. 分解 分解是把项目的组成要素加以细分为可管理的更小的部分，以便更好管理和控制。分解在节5.3.2.2已详尽讨论，但这里讲的分解和定义范围中讲的分解之间的主要区别是：这里分解的结果是活动而不是项目细目（有形的东西）。在有一些应用领域，WBS和活动目录是同时编制的。

　　 2. 参考样板：先前项目的活动目录（见节6.1.3.1）或活动目录的一部分常可作为新项目活动目录的参考样板。当前工程的WBS结构中的要素目录可作为今后其它类似WBS结构要素的参考样板。

　　 6.1.3定义活动过程的输出
　　 1. 活动目录 活动目录必须包括项目中所要执行的所有活动（无一遗漏）活动目录可视为WBS的一个细化。这个活动目录应是完备的，它不包含任何不在项目范围里的活动。活动目录应包括活动的具体描述，以确保项目团队成员能理解工作应如何做。

　　 2. 细节说明 有关活动目录的细节说明应表达清楚，以方便今后其它项目管理过程的利用。细节说明应包括对所有假设和限制条件的说明。细节的内容由应用领域不同而不同。

　　 3. WBS结构的修改 在利用WBS去确定哪些活动是必须的过程中，项目团队也必然能确认哪些项目细目被遗漏了或者意识到：项目细目的描述需要修改或应更清楚。任何这样的修改必须在WBS相关文件（例如，成本估计）中反映出来，以上修改通常在项目涉及新的或未被验证的技术时发生。
　　 　6.2活动的排序
　　 活动排序过程包括确认且偏制活动间的相关性。活动必须被正确地加以排序以便今后制订实现的可行的进度计划。排序可由计算机执行（利用计算机软件）或用手工排序。对于小型项目手工排序很方便，对大型项目的早期（此时项目细节了解甚少）用手工排序也是方便的，手工编制和计算机排序应结合使用。

　　 6.2.1活动排序过程的输入
　　 1. 活动目录 活动目录见节6.1.3.1

　　 2. 产品描述 产品的描述见节5.1.1.1，不同的产品特征常明显地影响活动的排序（例，建设中某工厂的平面布局，一个软件项目子系统的接口）同时，对产品的描述要加以核对、审查以确保活动排序的正确性。

　　 3. 内在的相关性：内在相关性是指所做工作中各活动间固有的依赖性，内在相关性通常由客观条件限制造成的（例如，在一个建设项目在地基完成前先进行大楼的建设是不可能的。一个电子项目只有在原型完成后才能对它进行测试。）

　　 4. 指定性的相关性：指定性是指由项目管理团队所规定、确定的相关性，应小心使用这种相关性并充分加以陈述。因为承认并使用这样的相关性进行排序会限制以后进度计划的选择。这种相关性通常发生在以下一些情况。
　　 在一个特定应用领域有一个"最好的做法"
　　 有些时候，即使有几种可接受的排序，但因某种原因一个特定的活动排序关系被偏爱

　　指定性相关也可称偏好相关或软相关。

　　 5. 与外部相关性：外部相关性是指本项目活动与外部活动间的相关性。例如，一个软件项目的测试活动依赖于外部硬件的运到，或建设项目施工之前应先听取人们对环保的意见。

　　 6. 约束：在节6.1.1.4描述。

　　 7. 假设：在节6.1.1.5描述。

　　 6.2.2活动排序的工具和方法

　　 1. 前驱图法（PDM）这是编制项目网络图的一种方法，利用节点代表活动而用节点间箭头表示活动的相关性（见节6.2.3.1）图6.2表示一个用PDM法编制的简单网络图，这种方法也叫活动在节点法（AON）是大多数项目管理软件包所采用的方法。PDM法可用手算也可用计算机实现。

　　 有四种相关的前驱关系：
　　 结束→开始：某活动必须结束，然后另一活动才能开始。
　　 结束→结束：某活动结束前，另一活动必须结束。
　　 开始→开始：某活动必须在另一活动开始前开始。
　　 开始→结束：某活动结束前另一活动必须开始。

　　 在PDM法，结束→开始是最常见逻辑关系，开始→结束关系极少使用。（也许只有职业进度计划工程师使用）对管理软件，如果用开始→开始、结束→结束或开始→结束关系会产生混乱的结果，因为很多管理软件编制时并没有对这三种类型的相关性加以考虑。

　　 2. 箭头图方法（ADM）这是项目网络图的另一种方法，箭线表示活动，用节点连结箭线以示相关性。（见节6.2.3.1）图6-3表示用ADM法做的一个简单项目网络图。这种技巧也叫箭线代表活动（AOA），虽比PDM法较少使用，但在某些应用领域仍是一种可供选择的技巧。ADM仅利用结束→开始关系以及用虚工作线表示活动间逻辑关系。ADM法可手编也可在计算机上实现。
图6-3用箭头图画的网络逻辑图
　　 3. 条件图方法：如图表审评技术（GERT）和系统动力学，这些模型允许非前后排序活动的存在，诸如一个环。（例子是某试验须重复多次）或条件分技（例，一旦检查中发现错误，设计就要修改）而PDM法和ADM法均不允许和条件分技的出现。

　　 4. 网络参考样板：用各种标准网络可用来加速项网络图的编制。网络的一部分叫子网络，当一项目包含几个相同或几乎相同内容时，子网络特别有用。（如一个高层写字楼的地板；一个新药品研究项目的临床试验；或一个软件工程的程序模块）
　　 6.2.3活动排序过程的结果
　　 1. 项目网络图：一个项目网络图是项目所有活动以及它们之间逻辑关系（相关性）的一个图解表示。图6-2，6-3表示同一项目网络图的二种不同画法。网络图可手工编制也可用计算机实现。网络图应伴有一个简洁说明以描述基本排序方法。但对不平常排序应充分地加以叙述。

　　 项目网络图经常不正确的被称为PERT图。（计划评审技术）实际上PRET图是一类特殊类型的项目网络图，今日这种图很少应用了。

　　 2. 修改后的活动目录 前面已述：活动定义的过程可对WBS做修改，以几乎同样的方法，编制网络图也同样出现这样的情况（例，一个活动必须进一步分划或重新定义以画出正确的逻辑关系）。

　　 6.3活动时间估计过程
　　 活动时间估计指预计完成各活动所需时间长短，在项目团队中熟悉该活动特性的个人和小组可对活动所需时间作出估计。

　　 估计完成某活动所需时间长短要考虑该活动"持续"所需时间。例如，混凝土养护需要4天时间，即需要2--4天工作日，到底是几天取决于（A）活动的开始日期是星期几？（B）周未是否算工作日？
绝大多数的计算机排序软件会自动处理这类问题。整个项目所需时间也是运用这些工具和方法加以估计的，它是作为制订项目进度计划的一个结果。（见节6.4）

图片六
　　　1.活动目录 1.专家判断 1.活动时间估计
　　　2.约束 2.类推估计 2.估计的基础
　　　3.假设 3.仿真 3.活动目录修改
　　　4.资源需求
　　　5.资源库质量
　　　6.历史资料

　　6.3.1活动所需时间估计的输入
　　1. 活动目录 见节6.1.3.1

　　 2. 约束 见节6.1.1.4

　　 3. 假设 见节6.1.1.5

　　 4. 资源需求 见节7.1.3.1
　　 大多数活动所需时间由相关资源多少所决定。例如，二人一起工作完成某设计活动只需一半的时间（相对一个人单独工作所需时间）。然每日只能用半天进行工作的人通常至少需要二倍的时间完成某活动（相对一个人能整天工作的所需时间）

　　 5. 资源质量 大多数活动所需时间与人和材料的能力（质量）有关，例如，对同一活动，设有两个人均全日能进行工作，一个高级技工所需时间少于低级技工所需时间。

　　 6. 历史资料 有关各类活动所需时间的历史资料是有用的，这些资料来源来自于以下情况：
　　 项目档案--与这个项目有关的一个或几个组织也许保留有先前项目结果的记录，而这些纪录非常详细可帮助时间估计。在许多应用领域，个别小组成员也许也保留这些记录。
　　 商业用的时间估计数据库--过去的一些数据往往是有价值的，当活动所需时间不能由实际工作内容推算时这些数据库特别有用（例如混凝土多少时间干、一个政府机构对某种类型申请的批复需多时间）。
　　 项目团队知识--项目团队的个别成员也许记得先前活动的实际或估计数。虽然这种重新回忆的方法也许有用，但比起记录的档案文件可靠性低得多。

　　 6.3.2活动所需时间估计的工具和方法
　　 1. 专家判断 专家判断见节5.1.2.2。估计所需时间经常是困难的，因为许多因素会影响所需时间（例如，资源质量的高低，劳动生产率的不同）只要可能，专家会依靠过去资料信息进行判断。如果找不到合适专家，估计结果往往是不可靠和具有较大风险（见第11章，项目风险管理）。

　　 2. 类推估计 类推估计意味利用一个先前类似活动的实际时间作为估计未来活动时间的基础，在以下情况下这种方法常用于估计项目活动所需时间：即只有很有限关于项目的资料和信息。（例如在早期）类推分析是专家判断的一种形式（见节6.3.2.1）以下情况下类推估计是可靠的（A）先前活动和当前活动是本质上类似而不仅仅是表面的相似。（B）专家有所需专长。

　　 3. 仿真 仿真是用不同的假设来计算相应的时间，最常见的是蒙特·卡罗方法。在这种方法中，假设了各活动所用时间的概率分布以用来计算整个项目完成所需时间的概率分布（见节11.2.2.3进度仿真）

　　 6.3.3活动所需时间估计的结果
　　 1. 各活动所需时间的估计 活动所需时间估计是关于完成一活动需多少时间的数量估计。
活动所需时间估计值用某一范围表示：例如
　　 2周±2天，表示该活动至少需8天和不超过12天。
　　 超过3周的概率为15%，表示以85%概率活动将用3周或更短时间。
第11章项目风险管理包含了关于估计不确定性的详细讨论。

　　 2. 估计的基础 在制订进度时所用的假设必须被确认合理可信。

　　 3. 活动目录修改 活动目录修改见章6.2.3.2。

　　 　6.4进度编制
　　 进度编制要决定项目活动的开始和结束日期，若开始和结束日期是不现实的，项目不可能按计划完成。进度编制、时间估计、成本估计等过程交织在一起，这些过程反复多次，最后才能确定项目进度。 输入 工具和方法 输出

　　 6.4.1时间进度编制的输入
　　 1. 项目网络图 见节6.2.3.1

2. 活动所需时间估计 见节6.3.3.1

　　 3. 资源需求 见节6.3.1.4

　　 4. 资源库描述：对进度编制而言，有关什么资源，在什么时候，以何种方法可供利用是必须知道的。例如，安排共享的资源也许是特别困难的一件事，因为这些资源的可利用性是高度可变的。
在资源库描述中，对各资源的详细程度的要求是变化的。例如，一个咨询项目最初的进度计划编制时，仅

　　 须知道，在某一段时间内有两个咨询人员可供利用，然而在同一项目的最终进度编制时，必须确定使用那一位特定的咨询人员。

　　 5. 日历表 项目日历表和资源工程日历表确定了可用于工作的日期。项目日历表对所有资源有影响（例如，一些项目仅在法定的工作时间内进行，而有的项目可一日三班安排工作）各资源日历表对特定的资源有影响（例如，项目团队的成员可能正在放假接受培训；某一劳动合同可能限定工人一周的工作天数）。

　　 6. 约束 约束见节6.1.1.4。有三类约束在编制进度计划时必须加以考虑。
　　 强制性日期：某些工作细目应项目支助者（或项目顾客或其它外界因素）的要求必须在某一特定日期完成。（例如，某技术项目的市场窗口；某董事会要求在某日期前完成一个环保项目。）
　　 关键事件或里程碑事件，项目支助者，项目顾客或其它项目相关人提出在某一特定日期前完成某些工作细目，一旦定下来，这些日期就很难被更改了。

　　 7. 假设 见节6.1.1.5。

　　 8. 超前与滞后 为了精确说明活动间相互关系，需对超前和滞后有一说明（例如，在订购一台设备和使用之间有二个星期间隔）。
　　 6.4.2进度编制的工具和方法
　　 1.数学分析 数学分析包括理论上计算所有活动各自的最早和最迟开始与结束日期，但计算时并没有考虑资源限制。这样算出的日期并不是实际进度，而是表示所需的时间长短，考虑活动的资源限制和其它约束条件，把活动安排在上述时间区间内，最常用的数学方法有：
　　 关键路线法（CPM）--借助网络图和各活动所需时间（估计值），计算每一活动的最早或最迟开始和结束时间。CPM法的关键是计算总时差，这样可决定哪一活动有最小时间弹性。CPM算法也在其它类型的数学分析中得到应用。
　　 GERT（图表审评技术）--对网络结构和活动估计作概率处理（即某些活动可不执行，某些仅部分执行，某些可不只一次执行）。
　　 PERT（计划评审技术）--利用项目的网络图和各活动所需时间的估计值（通过加权平均得到的）去计算项目总时间。PERT不同于CPM的主要点在于PERT利用期望值而不是最可能的活动所需时间估计（在CPM法中用的）。PERT法如今很少应用，然类似PETR的估计方法常在CPM法中应用。

　　 2.时间压缩法 时间压缩是一种数学分析的方法。在不改变项目范围前提下（例如，满足规定的日期或满足其它计划目标），该方法寻找缩短项目计划的途径。时间压缩包括如下：
　　 应急法--权衡成本和进度间的得失关系，以决定如何用最小增量成本以达到最大量的时间压缩。应急法并不总是产生一个可行的方案且常常导致成本的增加。
　　 平行作业法--平行地做活动，这些活动通常要按前后顺序进行（例如，在设计完成前，就开始在软件项目上写出程序；或在25%的工程点被达到前，就可开始建一个炼油厂的地基）。平地作业常导致返工和增加风险。

　　 3.仿真 见节6.3.2.3。

　　 4. 资源调整尝试法 数学分析法通常产生一个初始进度计划，而实施这个计划需要的资源可能比实际拥有的更多。或要求所用资源有大幅度变化(这给管理带来困难)。尝试法（如首先把稀有资源分配到关键路线）可在资源有约束条件下制定一个进度计划。用资源调整尝试法计算出的项目完成时间一般比初始进度长。用计算机优化软件编制进度计划时尝试法叫建立在资源约束基础上的方法。
资源有约束的进度编制是资源调整的一个特例，前者涉及的仅是可利用资源在数量上限制。

　　 5. 项目管理软件 项目管理软件被广泛地使用以帮助项目进度的编制。这些软件可自动进行数学计算和资源调整，可迅速地对许多方案加以考虑和选择。用这些软件，还可打印显示出计划编制的结果。

有许多其它方法可用以显示日期信息,上图中显示了各活动的开始和结束日期
图6-6 条形(甘特)图

在条形图上有许多其他方法可用以显示项目信息
　　 6.4.3进度编制的结果
　　 1. 项目进度 项目进度至少要包括每一具体活动的计划开始日期和期望完成日期（注：求出的进度计划仍是初步的，一直到资源分配被确定是可行的，资源分配可行性的确认应在项目计划编制完成前做好。见节4.1）

图6-7 里程碑图

有许多其他方法在一里程碑图上显示项目信息
图6-8 有时间尺度的网络图

　　 在有时间尺度的网络图上有许多其它可接受的表示项目信息的方法一个。
项目进度可用简略形式或详细形式表示，虽然可用表格形式表示进度，但更常以图的形式来表示，具体有以下几种：
　　 有日期信息的项目网络图（见图6-5）。这些图能显示出项目间前后次序的逻辑关系，同时也显示了项目的关键路线与相应的活动。（见节6.2.3.1以了解更多关于项目网络图的内容）。
　　 条型图 也称甘特图（见图6-6）该图显示了活动开始和结束日期，也显示了期望活动时间，但图中显示不出相关性。条型图容易读，通常用于直观显示上。
　　 重大事件图（见图6-7）它类似于条型图，可出主要的工作细目的开始和完成时间。
　　 有时间尺度的的项目网络图（见图6-8）它是项目网络图和条型图的一种混合图。这种网络图显示了项目的前后逻辑关系、活动所需时间和进度方面信息。

　　 2. 详细说明 项目进度的详细说明要包括对所有假设和限制的文字叙述。其它的说明因应用领域而异。例如：
　　 对一建筑项目，其它的说明也许包括资源的直方图，现金流量的预测，订货与交货计划。
　　 对一电子工程其它的说明也许只包括资源的直方图。
详细说明中提供的资料信息通常包括（但不是局限于）：
　　 不同时间阶段对资源的需求，经常以资源直方图形式表现。
　　 替代的进度计划（在最好情况下或最坏情况下，资源可调整或不可调整情况下，有或无规定日期情况下）。
　　 计划进度余地或进度风险估计（见节11.3.3）

　　 3. 进度管理计划 一个进度管理计划是指对进度的改变应如何加以管理。根据实际需要，进度管理计划可做得非常详细也可粗框架，可用正规形式也可以非正规形式表示。它是整个项目计划的一部分。

　　 4. 资源需求的修改 资源调整和活动目录的修改可能对资源的初始估计产生很大的影响。

　　 　6.5进度控制
　　 进度控制是指（a）改变某些因素使进度朝有利方向改变，（b）确定原有的进度已经发生改变，（c）当实际进度发生改变时要加以控制，进度计划控制必须和其它控制过程结合(见节4.3总体改变控制)。
　

　　 6.5.1进度控制的输入
　　 1. 项目进度表 项目进度表见6.4.3.1，被认可的项目进度表（又称基准进度）是项目总计划的一部分（见节4.1.3.1）。它提供了度量和报告进度执行情况的基础。

　　 2. 执行情况报告 执行情况报告（见节10.3.3.1）提供进度进展方面的信息。如哪一活动如期完成了，哪能一活动未如期完成。报告中也可提醒项目团队值得注意的问题。

　　 3. 改变的要求 要求改变进度的形式有多种--口头或书面，直接或间接，由外部或内部因素导致的，强制性的或有多种选择的。这些具体的改变要求的结果可能是加快进度也许是进度的延长。

　　 4. 进度管理计划 进度管理计划见节6.4.3.3。
　　 6.5.2进度控制的工具和方法
　　 1. 进度改变控制系统 可改变进度的控制系统指一些特定过程，通过这些过程可改变项目进度。该系统包括书面工作，追踪系统以及允许的进度偏差。进度改变控制应和控制系统的总改变结合起来（见节4.3）。

　　 2. 执行情况测定 如节10.3.2描述的执行情况测定方法可用来评估实际与计划时间进度间差异的大小。控制进度的一个重要部分是决定进度的偏差是否需要纠正的措施。例如，在一个非关键活动的一个较大时间延误也许只对项目产生较小的影响，而在关键活动的较小延误也许就需要马上采取纠正措施。

　　 3. 另外的计划 极少的项目精确地依计划进度行事。可预料到的改变需要重新对活动所需时间做估计，重新修改活动排序，或对多种进度计划作出分析。

　　 4. 项目管理软件 项目管理软件见6.4.2.5，项目管理软件能把计划日期和实际日期加以对比，并能预测进度改变所造成的影响。该软件是进度控制的一个有用工具。
　　 6.5.3进度控制的结果
　　 1. 进度的更新 进度更新指根据进行执行情况对计划进行调整。如有必要，必须把计划更新结果通知有关方面。进度更新有时需要对项目的其它计划进行调整。在有些情况，进度延迟十分严重以致需要提出新的基准进度，给下面的工作提供现实的数据。

　　 2. 纠正措施 指采取纠正措施使进度与项目计划一致。在时间管理领域中，纠正措施是指加速活动以确保活动能按时完成或尽可能减少延迟时间。

　　 3. 教训与经验 进度产生差异的原因，采取纠正措施的理由以及其它方面的经验教训应被记录下来，成为执行组织在本项目和今后其它项目的历史数据与资料。