许多不同的专业为项目管理的理论和实践做出了贡献。 自史前时代以来，工程师和建筑师就一直在管理重大项目。 大约从 1960 年代开始，人们就开始努力将项目管理实践专业化，作为其自身的专业化。围绕这个问题有很多激烈的争论：项目管理是否应该像工程、会计和医学一样成为一种职业？ 这些机构有专业协会，证明谁可以合法允许使用职称，谁可以合法从事该行业。 他们还为行为不当的质量和纪律成员提供一定程度的保证。 另一个正在进行的辩论是：经验丰富的项目经理需要多少行业知识？一个项目经理从一个行业（例如 IT）过渡到另一个行业（例如酒店业）有多容易？

有两个对项目管理实践具有世界影响的主要组织：总部位于美国的项目管理协会 (PMI) 和总部位于瑞士的国际项目管理协会 (IPMA)。 本教科书采用更接近 PMI 方法的方法。 本章包含更多详细信息，以及有关项目管理办公室的部分。

项目管理知识领域介绍

项目启动与整合

项目的启动类似于新组织的启动。 项目负责人开发用于设计和执行项目的项目基础设施。 在项目的早期阶段或定义阶段，项目管理团队必须在项目的主要利益相关者（那些对项目有共同利益或利益的人）之间建立一致性。 项目经理将召开一次或多次启动会议或调整会议，将项目的各方召集在一起，并开始项目团队建设，为了在项目期间高效运作。

在项目启动期间，项目管理团队细化工作范围并制定初步进度表和概念预算。 项目团队根据项目概况制定项目执行计划。 制定和跟踪详细时间表的计划、采购计划以及建立预算和估算和跟踪成本的计划是在启动期间制定的。 信息技术、沟通和跟踪客户满意度的计划也都是在项目启动阶段制定的。

流程图、图表和责任矩阵是捕获与执行项目计划相关的工作流程的工具。项目程序手册的初稿捕捉了团队成员为项目带来的历史和直觉知识。 这些程序和工作流程的开发和审查有助于项目组织结构的开发。

了解到一切皆有可能，这是项目启动的一个激动人心时刻。 项目管理团队要花很多时间制定初始计划、为项目配备人员并与客户建立关系。 项目经理设定项目的基调，并为每个项目团队成员设定期望。 复杂项目的项目启动阶段可能会很混乱，在制定计划之前，项目经理成为信息和方向的来源。项目经理创造一个环境，鼓励团队成员充分参与项目，并鼓励采用创新方法来制定项目计划。

项目范围 Project Scope

项目范围是一个文档，它定义了项目的参数——定义系统并确定其行为的因素，在项目边界内完成了哪些工作，以及在项目边界外完成了哪些工作。工作范围（SOW）通常是一份书面文件，用于定义项目结束时将完成的工作——项目的可交付成果。项目范围定义了将做什么，项目执行计划定义了如何完成工作。

没有适用于所有项目的模板。有些项目有非常详细的工作范围，有些仅有简短的摘要文档。 范围的质量由项目经理和项目利益相关者发展和保持对项目将交付的产品或服务的共同理解的能力来衡量。项目范围的大小和细节与项目的复杂性概况有关。更复杂的项目通常需要更详细且全面的范围文件。

根据PMI，范围说明书应包括以下内容：

•   范围的描述 Description of the scope
•   产品验收标准 Product acceptance criteria
•   项目可交付成果 Project deliverables
•   排除项目 Project exclusions
•   项目约束 Project constraints
•   项目假设 Project assumptions

范围文件是各方达成协议的依据、清晰的项目范围文档对于管理项目变更也至关重要。 由于项目范围反映了项目将完成的工作，因此未捕获和记录的任何预期变化都会造成混淆。项目最常见的趋势之一是项目范围的增量扩展。这种趋势被称为“范围蔓延”。 范围蔓延会威胁到项目的成功，因为范围的小幅增加需要计划中没有的额外资源。增加项目范围是常有的事，因此需要对项目预算和进度进行调整以应对这些变化。 当这些变更未被识别或未被管理时，就会发生范围蔓延。 项目经理识别潜在变更的能力通常与范围文件的质量有关。

需要更改项目范围的事件确实会发生。 市场的变化可能需要改变产品设计或产品交付时间。 客户管理团队或客户财务状况的变化也可能导致项目范围发生变化。 项目进度、预算或产品质量的变化将对项目计划产生影响。 通常来说，项目变更发生的越晚，项目成本的增加就越大。 项目经理有责任为项目建立一个变更管理系统，以捕获项目范围的变更，并确保这些变更得到客户组织中适当管理层的授权。 项目经理还分析这些变更对成本和进度的影响，并调整项目计划以反映客户授权的变更。 范围的变化可能会导致成本的增加或减少。

项目进度和时间管理 Project Schedule and Time Management

项目成功的定义通常包括按时完成项目。制定和管理按时完成项目的项目进度表是项目经理的主要职责之一，按时完成项目需要制定切合实际的计划并对计划进行有效管理。在较简单的项目中，项目经理可能会领导项目计划的制定，并制定一个时间表来满足该计划。 在较大或更为复杂的项目中，专注于成本和进度计划和控制功能的项目控制团队将协助项目管理团队制定计划并根据计划跟踪进度。

为制定项目进度表，项目团队对项目范围、合同和其他有助于团队定义项目可交付成果的信息进行分析。 基于这些信息，项目团队制定了一个里程碑时间表。 里程碑时间表确定了项目生命周期中的关键日期，项目必须满足这些日期才能按时完成。 关键日期的确定通常是为了履行合同义务或确定的时间间隔，以反映项目的适当进展。 对于不太复杂的项目，里程碑时间表可能足以跟踪项目的进度。对于更复杂的项目，需要更详细的时间表。

为了制定更详细的时间表，项目团队首先制定了工作分解结构（WBS）——对按细节层次排列的任务的描述。 尽管项目范围是制定 WBS 的主要文件，但 WBS 合并了所有项目可交付成果并反映了阐明项目可交付成果的任何文件或信息。 从 WBS 中，制定了项目计划。 项目计划列出了完成 WBS 中确定的工作所需的活动。 WBS 越详细，为完成工作确定的活动就越多。

项目团队确定活动后，团队将根据活动完成的顺序对活动进行排序。 工作流程的一个结果是项目逻辑图。 逻辑图代表完成项目所需活动的逻辑顺序。 规划流程的下一步是估算完成每项活动或活动持续时间所需的时间。 有些活动必须按顺序进行，有些活动可以同时进行。 计划流程通过以有效和高效地使用项目资源并在最短时间内完成项目的方式安排活动来创建项目进度表。

在较大的项目中，会创建多个路径来表示从项目开始到结束的一系列活动。 完成项目的最长路径是关键路径。 如果关键路径花费的时间少于客户允许的完成项目的时间，则该项目的总浮动时间或项目松弛时间为正数。 如果客户的项目完成日期早于计算出的关键路径结束日期，则该项目有一个负数的总浮动时间。 理解和管理关键路径上的活动是一项重要的项目管理技能。

要成功管理项目，项目经理还必须知道如何加快进度以补偿延迟关键活动的意外事件。 压缩加速 (Compressing) ——紧急冲刺 (Crashing)——是用来描述缩短项目进度的技术的术语。 在项目生命周期中，经常会发生进度冲突，项目经理有责任减少这些冲突，同时保持项目质量和满足成本目标。

项目成本 Project Cost

项目成功的定义通常包括在预算范围内完成项目，这是制定和控制项目预算以实现项目目标的关键项目管理技能。尽管客户期望项目能够高效执行，但不同项目所面临的成本压力各不相同。在某些项目中，项目的复杂性使项目完成或结束日期成为最大的挑战。有许多关于项目成本的例子，例如开发解决重大健康问题的新药、生产新产品以产生关键现金流，以及公司凭借新技术取得市场竞争优势。这些例子表明在某些情况下，项目进度的压力超过了项目成本的压力。

项目预算的准确性与项目团队已知信息的多少有关。在项目的早期阶段，制定详细预算所需的大量信息常常缺失。为了解决信息缺乏的问题，项目团队制定了不同级别的项目预算估算。 概念估算（或“大概估算”）是使用最少的知识开发的。 概念估算的主要输入是专家知识或过去的经验。过去执行过类似项目的项目经理可以使用这些成本来估算当前项目的成本。

当了解更多信息时，项目团队可以制定粗略的数量级 (ROM) 估算。 诸如建筑物的近似平方英尺、工厂的生产能力以及开发软件程序所需的近似小时数等其他信息可以为提供ROM估算提供基础。 在项目设计更加完整之后，可以完成项目详细估算计划。 例如，当项目团队了解房屋的房间数量、材料类型和建筑位置时，他们可以提供详细的估算。 这个详细估算并不是房屋的出价。

项目成本是根据工作进度和完成该工作的估计来跟踪的。 根据成本估算，将已完成工作的成本与该工作的预算成本进行比较。 如果成本明显偏高或偏低，项目团队会探究预期成本与实际成本之间存在差异的原因。

项目成本可能会偏离预算，因为市场价格与预期不同。 例如，住房项目的木材估计成本可能高于预算，或者劳动力的小时成本可能低于预算。 项目成本也可能因项目绩效而有所不同。 例如，一个项目组估计河上桥梁的钢结构设计需要 800 个工时，但实际花费了 846 个工时。 项目团队捕获工作预算成本与实际工作成本之间的偏差，根据需要修改估算并在偏差反映趋势时采取纠正措施。

项目经理负责确保项目团队根据可用的最佳信息制定成本估算，并在获得新的或更精确的信息时修改这些估算。 项目经理还负责根据预算跟踪成本，并在项目成本显着偏离项目估算时进行分析。 然后项目经理采取适当的纠正措施，确保项目绩效与修订后的项目计划相匹配。

项目质量 Project Quality

项目质量侧重于反映项目目的的最终产品或服务可交付成果。项目经理负责制定项目执行方法，明确了解预期的项目可交付成果和质量规范。 房屋建筑项目的项目经理不仅需要了解房屋中的哪些房间将铺设地毯，还需要了解需要何种等级的地毯。人流量大的房间就通常需要高档的地毯。

项目经理负责制定项目质量计划，该计划定义质量期望并确保满足规范和期望。 通过记录规范和期望来深入了解项目可交付成果对于制定良好的质量计划至关重要。 确保满足规范和期望的流程被整合到项目执行计划中。 正如项目预算和完成日期可能会在项目生命周期中发生变化一样，项目规范也可能发生变化。 质量规格的变更通常与成本或进度变更在同一流程中进行管理。 分析变更对成本和进度的影响，并在适当的批准下，对项目执行计划进行变更。

PMI 的《项目管理知识体系指南》（PMBOK 指南）中有一章是关于项目质量管理的。 本章中的材料类似于优秀的运营管理文本中的材料。

虽说旨任何渐进式的质量管理改进技术都可以应用于项目工作流程，但小型项目的特征（独特且持续时间相对较短）使管理改进的吸引力较小。 与制造业务一样，项目重工（Project Rework）流程会增加产品或服务的成本，并且通常会增加完成重做活动所需的时间。 由于受到项目的持续时间限制，在项目早期开发适当的技能、材料和工作流程对于项目成功至关重要。 在更为复杂的项目中，尽早分配时间来制定计划了解和发展适当水平的技能和工作流程。

如果你在执行多个相似类型的项目管理工作，你可能会发现流程改进工具对于识别和改进其他项目的基本流程非常有用。流程改进工具还可以帮助确定成本和进度改进的机会。快速找到改进机会可以对项目绩效产生影响。在项目的早期阶段，即规划阶段，投入时间和资源以寻求改进是最为重要的。然而，在项目的后期阶段，随着满足项目进度目标的压力增加，项目文化往往不利于对工作流程进行更改。

另一个另一个应用流程改进工具的机会是在具有重复流程的项目中。例如，一个建造多栋相似房屋的房屋承包商可以通过评估前几栋房屋的工作流程来寻找改进机会。如果承包商建造的房屋数量超过五个，那么每个工作流程投资1,000美元就可以为每栋房屋节省200美元，这将是一项很不错的投资。

项目团队：人力资源 Project Team

在合适的地点和合适的时间为项目配备合适的人员是项目管理团队的一项重要职责。 项目通常有两类团队成员：职能经理和流程经理。职能经理和团队专注于项目的技术。 在建筑项目中，职能经理将包括工程经理和施工主管。 在培训项目中，职能经理将包括专业培训师； 在信息技术项目中，软件开发经理将是职能经理。 项目管理团队还包括项目过程经

理。 项目控制团队将包括在估算成本、成本跟踪、计划成本和调度成本方面具有专业知识的流程经理。 项目经理需要职能和流程专业知识来计划和执行成功的项目。

因为项目是临时的，所以项目的人员配置计划通常既反映项目所需的熟练团队成员的长期目标，也反映反映项目性质的短期承诺。 团队成员通常会协商确切开始日期和结束日期来满足个人和项目的需求。 项目的不同阶段也有不同的人员配置计划和决定。 在项目的早期或概念阶段的团队成员通常不需要配置在后期或项目收尾阶段。 在概念或收尾阶段通常不需要配置实施阶段的团队成员。 每个项目阶段都有人员配备要求，复杂项目的人员配备需要详细规划，以便在正确的时间及区域拥有正确的团队技能。

通常来说，核心项目团队致力于管理从启动到收尾的项目。 核心项目管理团队的成员包括：项目经理、项目控制、项目采购，以及功能管理的主要成员或项目技术专家。 虽然较长期的项目可能比短期的项目经历更多的团队更替，但对于任何项目来说，拥有能够在项目阶段保持连续性的团队成员是很重要的。

例如，在一个大型商业建筑项目中，负责建筑施工场地设计的土木工程团队将在设计的早期阶段作出最大的贡献。 土木工程负责人将根据需要带来不同的土木工程专业。 随着土木工程工作的完成和结构工程的顺利进行，大部分土木工程师将从该项目团队从任务中解脱出来。 职能经理、工程经理和土木工程负责人等将在整个项目期间提供专业知识来解决可能出现的技术问题并处理变更请求。

项目团队成员可以从多个不同来源分配到项目。 特许项目的组织可以是—组织内的职能部门指派有才能的经理和员工﹑与个人或机构签订合同担任项目的员工职位﹑为项目临时雇用员工，或是这些人员配置选项的组合。 这种人员配备方法允许项目经理创建项目组织文化。 一些项目文化更加结构化和注重细节，而另一些则结构化程度较低，角色和沟通要求不那么正式。 项目经理创造的文化类型在很大程度上取决于项目的类型。

沟通 Communications

成功完成复杂项目需要团队合作，而团队合作需要团队成员之间的良好沟通。如果这些团队成员在同一栋大楼里工作，他们可以安排定期会议，互相走进对方的办公室得到快速答案，甚至在其他办公场合非正式地讨论项目。在现今的全球经济中，许多复杂项目涉及来自分散地点的团队成员，而在同一建筑内有效的会议类型并不适用。使用电子通信方式而无需面对面会议的团队被称为虚拟团队。

沟通可以分为两类：同步和异步。如果所有参与沟通的人同时参与交流，则该沟通是同步的，电话会议是同步通信的一个例子。当参与者在不同的时间交互时，则该沟通是异步的。（单词开头的字母“a”表示“非”）。通信技术需要各种兼容的设备、软件和服务提供商，与全球虚拟团队的通信可能涉及许多不同的时区。建立有效的沟通需要一个沟通计划。

项目风险 Project Risk

风险存在于所有的项目中。项目管理团队的角色是了解项目中存在的各种类型和程度的风险，然后制定和实施计划来减轻这些风险。风险代表了项目生命周期中可能发生的事件，这些事件将对项目目标的实现产生负面影响。风险的类型和数量因行业类型、复杂度和项目阶段而异。项目风险计划还将反映项目经理和关键利益相关者的风险偏好。人们对风险的舒适度不同，项目团队的一些成员会比其他人更不愿承担风险。

制定风险管理计划的第一步是识别潜在的项目风险。有些风险很容易被识别，例如加勒比地区出现破坏性暴风雨的可能性，而有些风险则不太明显。许多行业或公司都有根据过去经验制定的风险清单。建筑业研究所发布了一份包含100个项目风险的清单，提供项目风险的例子和领域。没有任何一个风险清单能包含所有潜在的风险。清单的价值在于激发对项目潜在风险的讨论和思考。

项目团队分析已识别的风险，并估计风险发生的可能性。然后，团队估计事件发生时对项目目标的潜在影响。这个过程的结果是一个按照发生可能性和对项目的潜在影响程度进行排序的预估项目风险清单。

项目团队随后制定风险缓解计划，以降低事件发生的可能性或在事件发生时降低对项目的影响。风险管理计划被整合到项目执行计划中，并将缓解活动分配给适当的项目团队成员。在风险分析中识别到的所有潜在事件发生的可能性极小。而至少一个事件发生的可能性是很高的。

项目风险计划反映了项目的风险偏好，并在投资缓解措施与项目效益之间取得平衡。较为常见的风险缓解方法之一是使用应急预算（或称“备用金”）。应急预算是项目团队为应对未预见事件而设立的资金。高风险项目通常会有较大的应急预算。如果团队知道哪些活动具有最高的风险，应急预算可以分配给具有最高风险的活动。当风险不易与特定活动相关时，应急预算会在单独的行项目中标识。该计划包括项目生命周期内定期的风险计划审查。风险审查评估当前计划的有效性，并探索之前未识别的可能风险。

项目采购 Project Procurement

项目采购工作因项目类型而异。通常情况下，在较为简单的项目中，客户组织会提供采购服务。在这种情况下，项目团队确定项目所需的材料、设备和用品，并提供产品规格和详细的交货时间表。当母公司的采购部门提供采购服务时，项目的联络人可以帮助采购团队更好地了解项目的独特要求以及项目进度表中时间敏感或关键的项目。

在规模较大且较为复杂的项目中，需要专门的人员采购和管理项目所需的设备、用品和材料。由于项目的暂时性，设备、用品和材料是作为项目成果的一部分或用于执行项目的工作而采购的。例如，为建筑项目采购的砖块将作为项目成果而采购，而砂浆搅拌机是为执行项目工作而采购的设备。在项目结束时，为执行项目工作购买或租赁的设备将被出售、归还租赁机构或以其他方式处置。

更复杂的项目通常会通过不同的采购和管理方法来采购。商品是根据最低报价购买的常见产品。商品包括建筑项目中的混凝土、办公用品，甚至是研究项目的实验设备等物品。第二类采购包括为项目指定的产品。能够生产这些产品的供应商会竞标合同。合同的授予可以包括价格、能否按项目进度要求完成、产品的适用性以及其他对项目重要的考虑因素。为新钢厂制造炉子就是由项目供应商提供、专门为研究项目设计和建造的设备就是另一个例子。这些供应商的表现成为项目的重要组成部分，项目经理会分配资源来协调供应商的工作和进度。第三种采购方法是开发一个或多个合作伙伴。获得钢厂主要部分设计合同的设计公司以及正在进行研究关键子部分的研究公司都是潜在的项目合作伙伴的例子。合作伙伴为执行计划做出贡献并被整合进去。当合作伙伴分享项目成功的愿景并对项目情感投入时，合作伙伴表现最佳。项目管理团队制定并实施项目采购计划，以识别最有效和最高效的采购方法来支持项目进度和目标。

项目利益相关方管理 Project Stakeholders Management

人员和组织对项目来说可以有许多不同的关系。最常见的是将这些关系分为将受到项目影响的人员和组织以及可以影响项目的人员和组织。

成功的项目经理将在项目早期识别利益相关方。对于每个利益相关方，重要的是要确定他们想要或需要什么，以及他们对项目具有的影响或权力。根据这些信息，可以确定需要与利益相关方或利益相关方团体沟通，并创建利益相关方管理计划。利益相关方登记表用于识别和跟踪项目与每个利益相关方之间的互动。此登记表必须定期更新，因为新的利益相关方可以随时出现，并且特定利益相关方的需求和兴趣水平可能随着项目进展而发生变化。

Scrum开发概述

“Scrum”是另一种正式的项目管理/产品开发方法论，也是敏捷项目管理的一部分。Scrum是橄榄球术语（scrimmage）的一个词，意思是重新开始比赛的一种方式。它类似于每隔X周重新启动项目工作。它的基本思想是你不真正知道如何事先计划整个项目，因此你开始并建立经验数据，然后从那里重新计划和迭代。

Scrum使用连续的Sprint进行开发。Sprint类似于小的项目阶段（理想情况下为两到四周）。其基本思想是需要花费一天的时间来计划现在可以做什么，然后开发计划中的内容，并在Sprint结束时展示出来。Scrum使用开发团队的短暂日常会议，检查昨天完成了什么，明天计划完成什么，以及是否有任何事情阻碍了团队成员完成他们承诺的任务。在Sprint结束时，已经展示的内容可以进行测试，然后开始下一个Sprint周期。

Scrum方法定义了几个重要的角色。它们是：

产品负责人：项目的业务负责人，了解行业、市场、客户和项目的商业目标。产品负责人必须与Scrum流程密切配合，特别是Sprint的规划和演示部分。

Scrum Master：有点像项目经理，但并不完全相同。Scrum Master的职责主要是消除阻碍开发团队进展的障碍，教导产品负责人如何在开发工作中最大化投资回报（ROI），促进团队的创造力和授权，提高团队的生产力，改进工程实践和工具，运行每日站立会议，跟踪进展，并确保团队的健康。

开发团队：自组织（轻度领导），授权组。他们参与每个Sprint的规划和估算，进行开发，并在Sprint结束时展示结果。已经证明，开发团队的理想大小为7 +/- 2。开发团队可以分成“小团队”，并“群集”于在Sprint规划会议上创建的用户故事上。

通常，产品的开发方式是这样的：有一个“前线”（当前冲刺的故事/任务），一个“后方”（下一个冲刺的故事）和一个“冰箱”（以及一些后来的故事和流程变更）。可以将产品分解成以下结构：产品 — 特征— 故事—任务。

通常使用“故事点”进行努力估计（微小= 1 SP，小= 2 SP，中等= 4 SP，大= 8 SP，巨大= 16+ SP，未知=？SP）。故事可以是各种类型。用户故事是非常常见的，它们描述了用户可以在给定起点处执行的操作以及不同操作的结果。其他类型的故事来自以下领域：分析，开发，QA，文档，安装，本地化和培训。

每个迭代周期的计划会议需要产品负责人、Scrum Master和开发团队的参与。在计划会议中，他们为即将到来的迭代周期设定目标，并选择要处理的产品积压清单的子集（拟议的故事），开发团队将故事分解为任务并对其进行评估。开发团队和产品负责人进行最终谈判，以确定以下迭代周期的积压清单。

Scrum方法论使用指标来帮助未来的规划和跟踪进展，例如“燃尽图” – 剩余的小时数与天数之间的关系，“速度” – 实际上是团队所花费的工作量。（大约三个具有相同团队的迭代周期之后，人们可以对团队未来的工作情况有所了解。）

使用Scrum方法的一些注意事项：1）需要有承诺、成熟的开发人员；2）仍需要在前期或早期进行重要的需求定义、一些分析、架构定义和角色及术语的定义；3）需要公司和产品负责人的承诺；4）最适合需要频繁发布或更新的产品，对于一旦发布后不允许频繁升级的大型全新产品而言效果较差。

项目管理办公室

许多大型甚至中型组织已经建立了一个部门来监督和支持整个组织的项目。这是为了减少高失败率项目的数量（请参阅项目管理概述章节）。这些办公室通常称为项目管理办公室或PMO。

PMO可以是组织中所有项目经理的归宿，也可以只是为所有项目经理提供资源，他们向各自的部门报告。

PMO的典型目标是：

• 帮助确保项目与组织目标相一致
• 为项目经理提供模板和程序
• 提供培训和辅导
• 提供协调支持
• 了解项目管理领域最新趋势
• 作为项目报告和教训的储存库

贡献者和归因 Text Attributions

This chapter of 企業策略: 高管項目領導指南 Strategy Consulting: A guide for executives leading projects is a derivative of the following text:

• Table 4.1 by Adrienne Watt. Licensed under a CC BY 4.0 licence.
• Text discussing PMBOK and all text after “Project Stakeholder Management” is by Adrienne Watts and licensed under a CC BY 4.0 licence.

This chapter adapted and remixed by Adrienne Watt from the following sources:

• Introductory text and text under “Project Management Institute Overview” adapted from “History of Project Management” in Project Management by Merrie Barron and Andrew Barron. Licensed under a CC BY 4.0 licence.
• Text under “Introduction to the Project Management Knowledge Areas” was adapted from “Introduction to the Project Management Knowledge Areas” in Project Management From Simple to Complex by author whose name has been removed at the request of the original publisher. Licensed under CC BY-NC-SA 4.0 licence.