第 6 章　项目管理概论

一、考情分析

二、学习目标

三、知识点精讲：PMBOK 的发展与项目基本要素

3.1 PMBOK 的发展

项目管理协会（Project Management Institute, PMI）成立于 1969 年，是目前全球最具影响力的项目管理专业组织。PMI 发布的《项目管理知识体系指南》（A Guide to the Project Management Body of Knowledge, PMBOK 指南）将项目管理知识体系定义为项目管理领域公认的良好实践的总和，是本项目师考试项目管理部分的主要理论来源。

PMBOK 指南的演进脉络必须理清：

• 1996 年，PMBOK 指南正式发布第 1 版，确立了以知识领域为核心的组织框架；
• 2017 年，发布第 6 版，形成「五大过程组 × 十大知识领域 × 49 个过程」的经典结构，过程导向达到顶峰；
• 2021 年，发布第 7 版，结构发生根本性转变：从基于过程的标准转变为基于原则和绩效域的标准，围绕价值交付系统，提出 12 项项目管理原则与 8 大项目绩效域，强调项目管理的最终目的是交付价值而非机械执行过程。

官方教程（第 4 版）以 PMBOK 第 7 版知识体系为主线，同时保留了过程组与知识领域框架，形成「原则—生命周期—过程组／知识领域—绩效域」的双轨知识结构。这一结构正是本教程第 8—18 章的组织方式。

3.2 项目的定义与特征

按照 PMBOK 指南的定义：项目是为创造独特的产品、服务或成果而进行的临时性工作。这个定义包含两个不可分割的关键词——「独特」与「临时」，加上计划编制上的「渐进明细」，构成项目的三大特征：

• 临时性：项目有明确的开始时间和结束时间。临时性不等于持续时间短——一个为期十年的新能源基地建设仍然是项目；临时性的准确含义是「有始有终」，而项目所创造的产品、服务或成果往往在项目结束后长期存在。
• 独特性：每个项目都在不同程度上不同于其他项目，即使采用相同的材料、由同一个团队建造。独特性体现在可交付成果层面，而不是说项目中的每项工作都不重复——项目中完全可能包含重复性的操作。
• 渐进明细：项目的范围、计划等是随着信息不断增加而逐步细化和完善的。早期只能做粗颗粒度规划，随后逐步细化。渐进明细是有计划、受控的细化，绝不能成为范围蔓延的借口。

项目对组织的两大贡献也常被考查：项目驱动变革——项目使组织从当前状态转变到期望的未来状态，是组织变革的载体；项目创造商业价值——价值可以是有形的（货币资产、固定资产、股东权益等），也可以是无形的（商誉、品牌认知度、公共效益、战略一致性等）。

3.3 项目成功的标准

传统的项目成功标准是「铁三角」式的约束平衡：在约定的范围、进度、成本、质量之内交付成果。现代项目管理的成功标准在此基础上扩展：项目成功不仅是按时按预算交付成果，还包括相关方满意度、预期收益的实现以及与组织战略目标的一致性。判断一个项目是否成功，应当在项目启动时就与相关方共同明确成功的衡量标准，而不是事后单方面认定。此外，「项目成功」与「产品／业务成功」要区分开：项目按期按预算交付了成果，但产品投放市场后失败，则项目层面可能算成功、业务层面算失败。

3.4 项目、项目集、项目组合与运营管理的关系

先掌握两个核心定义：

• 项目集：相互关联且被协调管理的一组项目、子项目集和项目集活动，以便获得分别管理所无法获得的效益。项目集管理强调协调 component 之间的依赖关系，追求「1+1>2」的效益协同。
• 项目组合：为实现战略目标而组合在一起管理的项目、项目集、子项目组合和运营工作的集合。项目组合中的项目或项目集不一定相互依赖或直接相关。项目组合管理关注「做正确的项目」：战略匹配、优先级排序、资源分配与治理。

三者自上而下形成层级：战略 → 项目组合 → 项目集 → 项目。项目组合管理侧重「做正确的事」，项目与项目集管理侧重「正确地做事」。运营管理则负责在项目交付成果后维持业务的持续运转，同样可以通过项目组合纳入统一治理。

项目与日常运营的对比（必背表）

3.5 项目内外部运行环境

项目总在特定的组织与市场环境中运行，环境因素分两大类，后续所有章节都会反复引用：

• 事业环境因素（Enterprise Environmental Factors, EEF）：项目团队不能控制的、将对项目产生影响、限制或指令作用的各种条件。内部 EEF 包括组织文化、组织结构和治理框架、设施和资源的物理分布、信息系统软件、员工能力等；外部 EEF 包括市场条件、社会和文化影响与问题、法律限制、商业数据库、学术和技术研究、政府或行业标准、物理环境要素等。
• 组织过程资产（Organizational Process Assets, OPA）：执行组织所使用的任何来自参与项目的组织的正式或非正式的计划、过程、政策、程序和知识库。包括：各类模板（项目计划模板、风险登记册模板等）、标准化的生命周期与变更控制程序、财务控制程序，以及历史信息和经验教训知识库。

3.6 项目管理与产品管理

产品管理关注产品的全生命周期——从产品概念、开发、增长、成熟到退出市场。项目与产品的关系：一个产品的生命周期中可能包含多个项目（如某产品先后经历「新产品研发项目」「重大改版项目」「合规性改造项目」）；反过来，项目管理的输出也可能成为持续运营的产品的起点。产品管理可以以项目形式（如新产品引入项目）开展，也可以以持续运营的形式开展，这取决于组织的产品战略与管理模式。项目经理在产品导向型组织中应当理解自己在产品生命周期中的位置，与产品负责人、产品经理协同工作。

四、知识点精讲：组织系统与组织结构

4.1 组织系统

组织是一个由人、流程、制度构成的系统，项目在组织内运行，必然受组织系统的影响。组织系统由两大构件组成：

• 治理框架：组织中行使权力的规则、政策、程序、规范、关系、系统和过程，规定了决策权与问责机制，是项目治理的母体。项目治理为项目相关方提供一个报告决策、解决争议的框架。
• 管理要素：组织内部职能部门划分、职权与职责的授予、管理幅度与管理层次等管理结构安排。管理要素决定了项目经理向谁汇报、能调动什么。

组织系统决定了「项目在组织中的生存土壤」：治理框架影响项目的决策与审批效率，管理要素影响资源的获取与使用。同一个项目经理放在不同的组织结构中，其权力空间可能天差地别——这就是下一小节的核心考点。

4.2 组织结构对项目的影响（必背对比表）

组织结构从「纯职能」到「纯项目」是一条连续光谱，矩阵型处于中间地带，又按项目经理的权力强弱分为弱矩阵、平衡矩阵、强矩阵。记忆主线：从职能型到项目型，项目经理的权限、资源可用性、预算控制力、专职程度单调递增；职能经理的控制力单调递减。

各结构的适用性与代价也应当理解：职能型专业分工深、技术能力强，但跨部门协调难、项目响应慢，适合以专业深度为主的工作；项目型目标聚焦、指挥统一、响应快，但资源重复配置、团队成员项目结束后「无家可归」、组织规模成本高；矩阵型兼顾专业积累与项目聚焦，但「一个员工两个领导」，双头汇报天然存在冲突，对沟通与协商要求最高。

五、知识点精讲：项目经理的角色

5.1 项目经理的定义与职责

项目经理是由执行组织委派、领导团队实现项目目标的个人。项目经理对项目成果负全责，其工作远不止「盯进度」：项目经理要在范围、进度、成本、质量、资源等相互竞争的制约因素之间进行权衡，管理干系人期望，带领团队把计划变成成果。项目经理不同于职能经理（管理职能领域、提供专业 oversees 的持续运营）和运营经理（负责保证业务运营的高效性），他是临时性、目标导向的角色。

5.2 项目经理的影响力范围

项目经理的影响力不局限于项目团队内部，而是由内向外扩展：

• 项目内部：带领项目团队，管理可交付成果的交付与相互竞争的制约因素；
• 组织层面：与职能经理、其他项目经理、项目治理委员会、项目集与项目组合管理人员互动，争取资源与支持；
• 行业与学科层面：关注所在行业的知识发展，参与项目管理学科的知识贡献（知识分享、社区实践）；
• 跨领域层面：在专业学科之外（如其他行业、其他专业领域）扩展影响力，建立跨界视野。

5.3 项目经理的能力模型：PMI 人才三角

PMI 提出的人才三角（Talent Triangle）刻画了现代项目经理的三大能力维度：

六、知识点精讲：12 项项目管理原则

PMBOK 第 7 版（也是官方教程第 4 版）以「价值交付系统」为顶层框架，以12 项项目管理原则为知识体系的基石。原则不是操作规程，而是指导项目决策与行为的「总纲」，无论采用预测型还是适应型方法都必须遵循。考试对原则的考查集中在「名称—要义」的对应与场景归属判断。

6.1 十二条原则总览

6.2 逐条精讲

原则 1：成为勤勉、尊重和关心他人的管家

管家式管理是指以诚信、关心和信任的方式开展活动，对组织内外的资源负责任地使用和维护。管家的责任体现在四个层面：在组织内部对人员、财务、设备等资源的维护与合规使用；在组织外部维护并提升组织声誉；在环境与社会层面关注可持续发展；在职业层面维护项目管理职业的知识与操守。考试关键词：诚信、关心、合规、负责任地使用资源。

原则 2：营造协作的项目团队环境

项目由团队交付。本原则强调项目团队是「由承担共同目标的人员组成的跨职能协作单元」，团队成员共同拥有项目成果与责任，人人参与、共享信息、共担风险。项目经理的职责是营造让每个人都能发挥所长并参与决策的环境，而不是把人当作被分配任务的资源。

原则 3：有效地与干系人互动

干系人可能影响项目决策与成果，也可能被项目影响。项目经理应尽早、主动地开展干系人识别，理解他们的需要、期望与利益，建立并维护建设性关系，让他们在恰当的时机以恰当的方式参与。消极被动的干系人沟通是项目失败的高发原因。

原则 4：聚焦于价值

价值是项目成功的最终指标。价值由接收方（客户、组织、干系人）感知和定义，不只是「按时交付」。项目团队应持续评估目标与实现路径是否仍能带来最大价值，必要时调整方向。关键词：价值交付、持续评估、以客户为中心。

原则 5：识别并响应系统交互

系统思维要求把项目视为一个由多个相互作用的子系统（需求、进度、成本、团队、外部环境）构成的整体：单独优化某个子系统可能损害整体绩效。变更一个约束会通过系统交互传导到其他部分，因此要整体地权衡，而非割裂地处理。

原则 6：展现领导力行为

领导力不是项目经理的专利——任何团队成员在任何层级都可以展现领导力。领导力风格（指令型、参与型、服务型等）应当根据情境与人员成熟度调整。管理与领导的区别：管理关注流程与秩序，领导关注愿景与激励，卓越的项目经理两者兼备。

原则 7：根据环境进行裁剪

几乎不存在两个完全相同的项目，因此「一套过程打天下」必然水土不服。裁剪是指根据项目规模、复杂度、行业与组织治理要求，选择合适的方法论、过程、工具、文档与治理方式，做到够用而不繁冗。裁剪应尽早开始、持续迭代。

原则 8：将质量融入到过程和可交付物中

质量是「可交付成果满足需求的程度」。本原则要求把质量内建于过程之中——通过过程设计预防缺陷，而不是依赖事后检查与返工；同时保持持续改进的心态（如借鉴质量改进方法），让质量成为团队的共同承诺。

原则 9：驾驭复杂性

复杂性来源于人类行为、系统行为、不确定性和模糊性，以及技术创新等因素，且会随项目推进动态变化。驾驭复杂性没有万能公式，前提是保持警觉：持续扫描复杂性的早期信号（如矛盾信息、利益冲突、多重依赖），再采取分解、试验、迭代等应对策略。

原则 10：优化风险应对

风险既是威胁（负面的）也是机会（正面的）。本原则要求项目团队主动识别和管理风险，在整体风险暴露与预期回报之间取得平衡：既不能盲目冒险，也不能为规避所有风险而放弃价值创造。

原则 11：拥抱适应性和韧性

适应性是应对变化、调整方式方法的能力；韧性是受到冲击后吸收恢复并继续前进的能力。项目环境不断变化（需求、技术、干系人），团队应拥抱变化、采用迭代与增量方式小步前进，并保持从挫折中快速学习与恢复的能力。

原则 12：为实现预期的未来状态而驱动变革

项目是组织从当前状态走向期望未来状态的载体。驱动变革意味着：识别变革的驱动力与阻力，让受影响的干系人为变革做好准备，克服「安于现状」的惯性，确保新成果真正被采纳并转化为价值，而不是「系统上线了、没人用」。

七、知识点精讲：生命周期、过程组、知识领域与绩效域

7.1 项目生命周期与项目阶段

项目生命周期是项目从启动到结束所经历的一系列阶段。阶段的划分方式多样：可按主要可交付成果划分（需求分析阶段、设计阶段、开发阶段、测试阶段），可按专业分工划分，也可按时序或资金流划分。阶段的结束通常以完成某项主要可交付成果为标志，阶段之间的衔接点是「阶段关口」（也叫里程碑、阶段评审、阶段门），在关口处评估绩效、决定项目继续、调整还是终止。

注意两组概念不能划等号：项目生命周期 ≠ 产品生命周期（产品生命周期可以包含多个项目）；生命周期 ≠ 过程组（过程组是管理活动的逻辑分组，在每个阶段内部都可能被反复使用，而不仅仅是项目级别的先后阶段）。

7.2 四种开发生命周期类型（必背对比表）

项目生命周期按需求确定性与交付节奏，可分为四种典型类型：

四种类型的关系可以这样理解：迭代型通过一系列重复的循环活动来开发产品，有利于尽早获得反馈、降低不确定性；增量型是逐渐增加产品的功能，先交付一个可用子集再逐步补全；适应型（敏捷）同时具备迭代与增量的特征，适用于需求面临大量变更、需要干系人持续参与的项目；混合型则是预测型与适应型的组合，整体框架走预测、局部模块走敏捷。

7.3 五大过程组

过程组是项目管理输入、输出、工具与技术的逻辑分组，五大过程组及其要点：

两个考试常考的细节：监控过程组贯穿项目始终（不是只在「执行之后」进行）；过程组之间不是严格串行，规划与执行可以相互交叠，且过程组在每一个项目阶段内部都可能被反复使用。

7.4 十大知识领域

知识领域是按「管什么」对项目管理知识做的分类，官方教程将知识点组织为十大知识领域，分别在第 8—17 章展开：

记忆口诀：「整范进成质，资沟险采干」（整合、范围、进度、成本、质量、资源、沟通、风险、采购、干系人）。注意与旧版教材对照：新版已无「人力资源管理」这一名称，取而代之的是「项目资源管理」。

7.5 八大绩效域概览

绩效域（Performance Domains）是 PMBOK 第 7 版引入的视角，是一系列相互关联、共同促成项目成功的活动。第 18 章将逐一展开，此处先建立总览：

7.6 价值交付系统

价值交付系统（Value Delivery System）是本章的顶层框架：项目是价值交付系统的组成部分。价值交付系统是一个业务系统，它以持续流动的方式创造、交付和维持组织价值，其组件包括项目、项目集、运营工作，以及项目组合管理、组织治理等支撑环节。项目通过交付可交付成果，帮助组织实现成果（outcomes），成果进而转化为效益（benefits），最终实现价值（value）。价值交付系统把项目与组织战略直接连接起来——这也是「聚焦于价值」原则的制度化表达。

八、典型案例分析

案例：某集团「智慧园区」项目群的立项与组织困境

背景：某大型产业集团启动「智慧园区」建设，包含智慧安防子项目、能耗管理子项目、园区一卡通子项目和运营指挥中心子项目。集团采用职能型组织结构，CIO 办公室的王工被口头指定「牵头」该项目群，没有正式任命文件，预算由各职能部门分别控制。项目启动八个月后，安防子项目即将验收，一卡通与指挥中心却因涉及多部门数据共享反复扯皮；集团高层开始质疑「智慧园区到底带来了什么」。

问题描述：项目群进展严重失衡，跨部门子项目停滞，高层对项目价值产生动摇。

问题诊断（分点）：

1. 组织结构不匹配项目形态。多个相互关联、需要协调管理的子项目本质上是项目集，而职能型结构中项目经理权限很小、预算由职能经理控制，跨部门协调天然乏力——违反了「组织系统应支撑价值交付」的基本逻辑。
2. 项目经理缺乏正式授权。「口头牵头」意味着没有项目章程、没有正式任命，项目经理不具备跨部门调用资源的职权，也无法依据治理框架解决争议。
3. 子项目间依赖关系未被管理。指挥中心依赖一卡通与能耗数据，属于典型项目集内部的组件依赖，需要项目集层面的统一规划与接口管理，而不是各子项目各自为战。
4. 价值衡量标准缺失。高层「质疑价值」说明立项时未与干系人共同明确项目成功的衡量标准与效益目标，违背「聚焦于价值」原则。

改进建议（分点）：

1. 将「智慧园区」按项目集正式立项，设立专职项目集管理办公室，四个子项目统一纳入项目集协调管理；
2. 由集团高层签发正式的任命文件与项目章程，明确项目经理（集）的职责、权限与汇报关系，必要时将组织结构调整为强矩阵；
3. 建立跨部门数据共享的接口标准与例会机制，对依赖关系进行统一登记与跟踪；
4. 与干系人共同定义价值指标（如通行效率提升、能耗下降幅度、事件响应时间），在阶段关口定期评估并对外沟通。

命题落点：本案例可考「该组织属于什么组织结构，对项目造成什么影响」「四个子项目应按项目还是项目集管理、为什么」「项目经理应如何获得授权」。答题要点全部落在本章：组织结构权限梯度、项目集定义（关联 + 协调 + 效益）、章程与授权、聚焦价值原则。

九、考点速记卡