第 8 章 项目整合管理
整合管理是十大知识领域的「总纲」：它把范围、进度、成本、质量等九个专业领域的成果装配成一个整体，并始终代表项目全局利益做取舍。本章几乎每年都在综合知识中占 5–7 分，而「实施整体变更控制」更是案例分析科目的常驻主角——变更流程题做不对，案例一科基本无望。
一、考情分析
命题规律与抓分重点：
- 变更控制是第一命题点。变更请求的四种类型（纠正、预防、缺陷补救、更新）、CCB 的角色与组成、变更从提出到关闭的流程顺序，是综合知识、案例分析、论文三科的共同题源，务必形成条件反射。
- 「项目管理计划 vs 项目文件」年年设坑。命题人惯于把需求文件、风险登记册、问题日志等「项目文件」伪装成计划组件，考生必须能一秒归类。
- 章程与授权是送分点。章程由项目外部的发起人或 PMO 签发、正式任命并授权项目经理，这类题难度低但出现频率极高。
- 数据 → 信息 → 报告的加工链条常考排序。「工作绩效数据、工作绩效信息、工作绩效报告」分别由哪个过程产生、对应哪个加工阶段，是近年热点。
- 抓分策略：本章记忆量大但理解门槛低。把七个过程的输入输出表背熟、把变更流程图默画出来，综合知识 5–7 分可以全收，案例分析题也有了标准答题模板。
二、学习目标
| 目标层级 | 具体目标（学完后应能做到） |
|---|---|
| 知识层 |
|
| 能力层 |
|
| 素养层 |
|
三、知识点精讲：整合管理基础
3.1 什么是项目整合管理
项目整合管理包括为识别、定义、组合、统一和协调各项目管理过程组的各种过程和活动而开展的工作，是项目管理中兼具统一、合并、沟通与建立联系性质的过程。通俗地说：九大专业领域各自回答「某一维度怎么管」，而整合管理回答「这些维度拼在一起如何不打架」。教材反复强调，整合是项目经理的核心职责——整合管理是项目经理的责任，不能授权他人代替，因为它要求站在项目整体利益的高度做权衡取舍。
整合管理共包含 7 个过程，贯穿五大过程组：启动阶段的「制定项目章程」；规划阶段的「制订项目管理计划」；执行阶段的「指导与管理项目工作」「管理项目知识」；监控阶段的「监控项目工作」「实施整体变更控制」；以及收尾阶段的「结束项目或阶段」。
记忆口诀（7 个过程）：「一章程二计划，指导管理加知识，监控变更来收尾。」
章程（启动）→ 计划（规划）→ 指导与管理 + 知识（执行）→ 监控 + 变更（监控）→ 结束（收尾）。七个过程正好按过程组首尾相接，闭上眼睛能按顺序数出来，输入输出题就成功了一半。
3.2 执行整合：项目经理在哪里做整合
教材从三个层面描述项目经理「执行整合」的着力点，这是近年综合知识的选择题热点：
- 过程层面整合：把十大知识领域、五大过程组的过程作为一个整体来理解与协调，例如在编制进度计划时同步考虑成本与资源约束，而不是各领域各编各的。
- 认知层面整合：项目经理要用整体的、系统的方式思考，把经验和洞察力作为知识的补充，对「知道什么、如何运用知识、何时采取行动」进行整合。认知层面整合的产出可以视为一项临时的「能力知识」，即把理论、经验、商业逻辑捏合为决策能力。
- 背景层面整合：项目所处的环境不断变化，项目经理必须评估并整合项目与外部环境的相互影响，在新商业环境、新技术、新干系人诉求出现时动态调整项目方向。项目与项目管理都具有多样性，实现「作品」的唯一路径就是背景层面整合。
3.3 整合的复杂性
项目整合之所以困难，根源在于项目的复杂性。教材指出复杂性来源于多个维度：系统行为（项目各部分以不可预见的方式交互，涌现出整体才有的性质）、人类行为（不同个体与群体之间的行为差异、沟通障碍）、不确定性和模糊性（信息不全、多种解释并存）以及过程技术的创新（新技术带来新的交互方式）。项目经理应对复杂性的策略包括：必要时进行项目裁剪、利用项目管理信息系统（PMIS）、开展渐进明细式的规划，以及在大型复杂项目中设置专门的一体化管理机构。
3.4 管理新实践
教材列举了整合管理领域的新兴实践，它们体现了从「机械执行计划」到「动态整合价值」的转变：
- 使用自动化工具与数字化管理：借助信息化工具整合项目数据、实现信息共享，提高整合的效率与准确性；
- 使用可视化管理工具：让项目状态、风险与依赖关系透明可见，便于干系人对齐认知；
- 项目知识管理：把知识管理当作日常项目工作的正式组成部分，而非收尾时的补救动作；
- 增加项目经理的职责：在新环境下项目经理被赋予更多「混合」职责，包括对商业论证、效益实现的管理责任；
- 混合型方法：将预测型与适应型方法混搭使用，根据项目各部分的可确定程度选择生命周期策略，使项目管理「局部敏捷、整体受控」。
3.5 项目管理计划与项目文件
整个整合管理知识领域里有两种性质完全不同的文件体系，考试必须一秒分清：
- 项目管理计划：描述如何执行、监督和控制项目的正式且经批准的文件。它由两类组件构成——①各子管理计划（范围、需求、进度、成本、质量、资源、沟通、风险、采购、干系人参与等管理计划）；②三大基准：范围基准、进度基准、成本基准。基准是经变更控制批准的、作为绩效度量基础的版本。
- 项目文件：不是计划组成部分、但会影响项目管理工作的各类文件，如假设日志、需求文件、需求跟踪矩阵、里程碑清单、进度计划、风险登记册、问题日志、变更日志、经验教训登记册、干系人登记册等。
| 比较维度 | 项目管理计划 | 项目文件 |
|---|---|---|
| 性质 | 经批准的正式文件，是执行、监控项目的依据 | 支撑项目工作的过程性文件 |
| 组成 | 子管理计划 + 范围/进度/成本三大基准 | 假设日志、需求文件、需求跟踪矩阵、里程碑清单、进度数据、风险登记册、问题日志、变更日志、经验教训登记册、干系人登记册等 |
| 修改程序 | 基准部分必须走整体变更控制流程才能修改 | 一般由相应过程直接产生与更新，不涉及基准的调整无需提交 CCB |
| 典型误认 | 把「变更日志」「问题日志」错归入计划 | 把「进度基准」错归入项目文件（基准属于计划组件） |
高频陷阱：「进度基准属于项目文件」——错，三大基准是项目管理计划的组成部分；「需求文件属于项目管理计划」——错，它是项目文件；「项目管理计划一经批准就不能再改」——错，可以改，但改动必须经过整体变更控制批准。命题人尤其喜欢拿「基准」的归属做文章。
四、知识点精讲：制定项目章程与制订项目管理计划
4.1 制定项目章程（启动过程组）
制定项目章程是编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。其主要作用是：明确项目与组织战略目标之间的联系，确立项目的正式地位，展示组织的承诺，以及展示组织对项目的领导认可。
谁来签发：项目章程由项目以外的实体发布，如发起人、项目集或项目管理办公室（PMO）职员。章程一经签发，就标志着项目获得正式授权；章程任命项目经理、规定其职权，因此「先有章程、后有项目经理的正式权力」。对于多阶段项目，可在每个阶段开始时重新确认或修订章程。
主要内容：项目目的、可测量的项目目标及相关成功标准、高层级需求、高层级项目描述与边界定义、主要可交付成果、整体项目风险、总体里程碑进度计划、预先批准的财务资源、关键干系人名单、项目审批要求（用什么标准评价项目成功、由谁对项目成功下结论、由谁签署项目结束）、项目退出标准、委派的项目经理及其职责和职权、发起人姓名和职权等。
作用：①授权项目经理动用组织资源开展工作；②确立项目的合法地位，使项目与组织战略和运营活动联系起来；③为日后考核提供总体框架；④尽早确认并任命项目经理，越早任命越好，最好在制定项目章程时就任命。
| 输入 | 工具与技术 | 输出 |
|---|---|---|
| 立项管理文件 协议 事业环境因素 组织过程资产 | 专家判断 数据收集（头脑风暴、焦点小组、访谈） 人际关系与团队技能（冲突管理、引导、会议管理） 会议 | 项目章程 假设日志 |
理解提示：项目章程不必面面俱到，也不解决「怎么做」的问题——它只回答「做不做、谁负责、大致做什么、什么时候大致完成」。很多考生把它与项目管理计划混淆：章程由项目外的发起人签发、内容高层级粗粒度；计划由项目经理组织编制、内容操作级细粒度。这是选择题的高频对比点。
4.2 制订项目管理计划（规划过程组）
制订项目管理计划是定义、准备和协调项目计划的所有组成部分，并把它们整合为一份综合项目管理计划的过程。其主要作用是生成一份综合文件，用于确定所有项目工作的基础及执行方式。该过程仅开展一次或仅在预定义点开展。
教材特别强调规划的「渐近明细」特征：项目管理计划会通过整体变更控制过程更新与修订，逐渐变得精确而完整——规划不是一次写死，而是滚动细化、受控更新。编制计划的输入中，「其他过程的输出」占据了最大份额：各子管理计划与三大基准都是在这里被装配成整体计划的，这正是「整合」的字面含义。
| 输入 | 工具与技术 | 输出 |
|---|---|---|
| 项目章程 其他过程的输出 事业环境因素 组织过程资产 | 专家判断 数据收集（头脑风暴、核对单、焦点小组、访谈） 人际关系与团队技能（冲突管理、引导、会议管理） 会议 | 项目管理计划 |
记忆口诀（计划三问）：「谁签章程？发起人；谁编计划？项目经理；计划改不改？走变更。」
再配一句「章程授权、计划导航、基准锁线、变更放行」——四个短句覆盖了章程与计划关系类题目九成的考点。
五、知识点精讲：指导与管理项目工作、管理项目知识
5.1 指导与管理项目工作（执行过程组）
指导与管理项目工作是为实现项目目标而领导和执行项目管理计划中所确定的工作，并实施已批准变更的过程。其主要作用是为项目工作提供全面管理。这是一个「干活」的过程，但不只是闷头执行，还包括：执行计划中确定的工作、完成既定目标、实施已批准的变更请求（纠正措施、预防措施、缺陷补救）、管理项目接口与团队培训、收集工作绩效数据并传给相关过程、沟通与干系人互动等。
| 输入 | 工具与技术 | 输出 |
|---|---|---|
| 项目管理计划 项目文件 批准的变更请求 事业环境因素 组织过程资产 | 专家判断 项目管理信息系统（PMIS） 会议 | 可交付成果 工作绩效数据 问题日志 变更请求 项目管理计划更新、项目文件更新、组织过程资产更新 |
三个输出需要精读：可交付成果是在某一过程或项目完成时必须产出的独特且可验证的产品、成果或服务能力；工作绩效数据是在执行过程中收集到的原始观察值与测量值，如已完成的工作百分比、质量检查结果、成本支出明细——注意它是「数据」不是「信息」，尚未经过加工；变更请求可能由任何干系人在任何时候针对任何内容提出，随后进入整体变更控制过程裁决。
理解提示（数据—信息—报告链条）：指导与管理项目工作产出「工作绩效数据」（原始数据）；各控制过程把数据与计划比较后产出「工作绩效信息」（如偏差分析结论）；监控项目工作再把信息汇编成「工作绩效报告」（面向管理层的报告）。三者的产生过程与加工程度是常考排序题。
5.2 管理项目知识（执行过程组）
管理项目知识是使用现有知识并生成新知识，以实现项目目标，并且促进组织学习的过程。其主要作用是：利用以往项目积累的组织知识来改进项目成果，并使当前项目创造的知识可供组织后续项目使用。注意：知识管理关注的不只是显性知识文档的归档，更重要的是隐性知识的分享与应用。
显性知识与隐性知识：显性知识是可以编撰、易于用文字、数字、图片等系统化语言传达的知识，如文档、流程、数据库、经验教训登记册；隐性知识则难以言明、难以编码，存在于人的头脑、经验与行为习惯中，如个人经验、信念、预感、洞察力、技术诀窍。隐性知识只能通过人际互动、实践社区等方式传递。
知识管理方法：显性知识可以采用知识管理工具与信息管理工具来编撰与传播（文档库、项目管理信息系统等）；隐性知识的分享则高度依赖人际关系与团队技能——积极倾听、引导技术、领导力、人际交往（创建非正式网络）、大局观，以及实践社区和特别兴趣小组、同级回顾、讨论论坛等互动形式。教材强调：信任是知识分享的土壤，项目经理要营造互相接受与包容的环境。
| 输入 | 工具与技术 | 输出 |
|---|---|---|
| 项目管理计划 项目文件 可交付成果 事业环境因素 组织过程资产 | 专家判断 知识管理 人际关系与团队技能（积极倾听、引导、领导力、人际交往、大局观） 信息管理 | 经验教训登记册 项目管理计划更新 组织过程资产更新 |
经验教训登记册在项目早期创建，涵盖类别、情景描述与建议；项目全程更新；收尾阶段把其中相关信息归入经验教训知识库，成为组织过程资产的组成部分。这个「登记册 → 知识库」的去向是选择题爱考的细节。
小案例：只存文档等于知识管理吗？
背景：某公司每年做十余个信息系统集成项目，项目经理在收尾时都会把全套文档归档，但次年新项目仍重复踩同样的坑，同类接口设计问题反复出现。
问题诊断：①把知识管理窄化为显性知识的文档归档，缺少隐性知识（设计诀窍、失败教训）的提取渠道；②没有实践社区等非正式交流机制，资深工程师的经验锁在个人头脑里；③经验教训没有在项目进行中持续登记，收尾时匆匆补写，质量低。
改进建议：按「管理项目知识」过程要求，项目早期即创建经验教训登记册并全程更新；建立跨项目的实践社区与同级回顾机制；在收尾时将登记册内容归入组织过程资产的经验教训知识库。
命题落点：案例分析常给「文档齐全却重复犯错」的场景，要求考生指出隐性知识管理的缺失并给出措施——答题时务必分点写「显性/隐性」两类手段。
六、知识点精讲：监控项目工作
6.1 过程概述
监控项目工作是跟踪、审查和报告整体项目进展，以实现项目管理计划中确定的绩效目标的过程。其主要作用是：让干系人了解项目的当前状态并认可为解决绩效问题而采取的措施，同时通过成本与进度预测，让干系人了解项目的未来状态。监控贯穿项目始终，不仅在阶段末进行，也要在里程碑与控制账户层面持续开展。
监控项目工作主要涉及：把项目的实际绩效与项目管理计划进行比较；评估绩效以确定是否需要采取纠正或预防措施，并推荐必要措施；识别新风险并分析、跟踪和监测已有风险；维护项目信息的准确及时的数据库，并保持与项目干系人的沟通；为状态报告、进展测量和预测提供信息；做出预测以更新当前的成本与进度信息；在已批准的变更实际发生时监督其实施情况。
| 输入 | 工具与技术 | 输出 |
|---|---|---|
| 项目管理计划 项目文件 工作绩效信息 协议 事业环境因素 组织过程资产 | 专家判断 数据分析（备选方案分析、成本效益分析、挣值分析、根本原因分析、趋势分析、偏差分析） 决策（多标准决策分析） 会议 | 工作绩效报告 变更请求 项目管理计划更新、项目文件更新 |
高频陷阱：监控项目工作的核心输出是「工作绩效报告」，不是「工作绩效数据」也不是「工作绩效信息」。命题人常用三个孪生词设错：数据（执行过程产生的原始测量值）→ 信息（各控制过程加工后与计划对比的结论）→ 报告（监控过程汇编成的决策支持文件）。判断题干描述处于哪个过程，再对应输出即可。
七、知识点精讲：实施整体变更控制（必考专节）
7.1 过程定位与核心原则
实施整体变更控制是审查所有变更请求、批准变更、管理对可交付成果、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。该过程贯穿项目始终，仅由项目经理主导流程运作（受理、组织评估与传达结果），但批准权限在变更控制委员会（CCB）或文件中指定的其他角色。
本章最重要的一句话，请刻进肌肉记忆：任何未经批准的变更不得实施；任何经批准的变更都必须实施并纳入受控管理。教材表述的核心原则包括：①变更实施须以被批准的变更请求为唯一依据；②在变更实施前要确保形成正式的变更文件并获得批准；③变更请求必须详细说明变更的必要性与影响，供决策者全面权衡；④变更日志记录所有变更请求的处理过程与结果，便于追踪与关闭。
7.2 变更请求的四种类型
| 类型 | 含义 | 典型场景 |
|---|---|---|
| 纠正措施 | 为使项目工作绩效与项目管理计划重新保持一致而开展的活动——针对已经发生的偏差 | 实际进度落后，加班赶工把进度拉回基线 |
| 预防措施 | 为确保项目工作的未来绩效与项目管理计划保持一致而开展的活动——针对尚未发生的潜在偏差 | 预计台风影响施工，提前加固设备规避延期 |
| 缺陷补救 | 为了修正不一致的产品或产品组件而进行的活动——针对产品本身的质量缺陷 | 测试发现模块缺陷，返工修复使其符合需求 |
| 更新 | 对正式受控的文件或计划等进行修改，以反映修改或增加的意见或内容——针对受控文件/计划本身 | 根据客户新要求修改需求文件与相应计划 |
记忆口诀（四类变更）：「纠正是纠偏，预防是防偏，补救修缺陷，更新改文件。」
判断时先问三个问题：偏差发生了吗？问题在产品上还是在计划上？面向过去还是面向未来？答案组合起来类型就唯一确定了。
7.3 变更控制委员会（CCB）
变更控制委员会（Change Control Board, CCB）是一个正式组成的团体，负责审查、评价、批准、推迟或否决项目变更，并记录和传达变更处理的决定。关于 CCB 必须掌握四个判断：
- 组成：CCB 由主要干系人的代表组成，可能包括项目经理，也可能包括其他项目成员、客户或发起人代表；其具体构成在变更管理计划中规定，所有成员都有权在 CCB 内承诺其所在组织的立场。
- 角色：CCB 是决策机构——裁决变更「批不批」，但不负责执行变更；执行由指导与管理项目工作过程落实。对于涉及基准的重大变更，CCB 的批准意味着新基准的生效。
- 规模与层级：CCB 可以设置多个层级——某些变更由项目经理审批即可（变更管理计划中授权），涉及基准或重大目标的变更必须提交更高层级的 CCB 甚至管理层决策。
- 纪律：CCB 的决定必须记录（变更日志）并传达给所有相关干系人，以保证信息一致。
7.4 变更从提出到关闭的完整流程
教材给出的是各过程视角的分散描述，串成端到端流程如下（案例分析答题模板）：
- 提出与记录：任何干系人都可以在项目任何时点针对任何内容提出变更请求，变更请求必须以书面形式提交（口头提出也须补记录）；项目经理将请求记入变更日志。
- 评估影响：项目经理组织评估该变更对范围、进度、成本、质量、风险、资源等各方面的综合影响，以及不实施该变更的后果，形成评估结论供决策使用。
- 提交决策：将变更请求与影响评估提交 CCB 或变更管理计划中规定的审批者；由其决定批准、否决或延迟（延迟通常意味着需要补充信息）。
- 更新计划与文件：变更获批后，先更新受影响的项目管理计划与项目文件，把变更「落到纸上」，再进入执行。
- 实施变更：在「指导与管理项目工作」过程中执行批准的变更请求（纠正、预防、缺陷补救），并配置管理确保正确版本。
- 验证实施：通过质量控制等过程确认变更已正确实施、达到了预期效果。
- 沟通与关闭：将处理结果记录于变更日志并传达给所有相关干系人，最终确认关闭该项变更；未获批准的变更同样要记录否决理由并通知提出人。
高频陷阱：命题人最爱用「先斩后奏」情节设错——例如「开发人员应客户口头要求直接修改了功能」「为赶进度先实施变更、事后再补审批」。正确的应对永远是：先书面记录变更请求 → 评估影响 → 提交 CCB 审批 → 获批后实施。「先实施、后补批」与「口头变更直接做」都是违规操作，案例分析中见到就要写进问题清单。
小案例：一次「好心办坏事」的口头变更。
背景：某 MIS 项目中，客户业务科长私下对开发组长说「这个报表多加一列导出字段，很小的改动」。开发组长觉得改动小、客户关系重要，当晚就让程序员改了代码并上线演示。
问题诊断：①变更未经书面记录与影响评估就实施，违反「未经批准的变更不得实施」原则；②变更请求未提交 CCB 审批，绕过了整体变更控制；③没有更新需求文件、需求跟踪矩阵等受控文件，造成文档与系统不一致，为后续验收埋雷。
正确做法：开发组长应先向项目经理报告，由项目经理将该请求记入变更日志，组织评估影响（这一列字段涉及的数据源、界面、测试工作量），提交 CCB 决策；获批后再更新文件、安排实施与验证，最后将结果通知客户。
命题落点：案例大题常让考生「指出案例中变更管理存在的问题并给出改进措施」——按「记录、评估、审批、更新、实施、验证、沟通」七个环节逐一对照排查，就能稳定拿分。
八、知识点精讲：结束项目或阶段
8.1 过程概述
结束项目或阶段是终结项目、阶段或合同的所有活动的过程。其主要作用是：存档项目或阶段信息，完成计划的工作，释放组织资源以开展新的工作。结束项目或阶段包括行政收尾，具体内容有：为达到阶段或项目的完工或退出准则所必需的行动和活动，例如确认可交付成果已被接受、处理范围外的未决事项；为向下一个阶段或向生产和运营部门移交项目的产品、服务或成果所必需的行动和活动；收集建议、改进意见、对执行情况的总结；以及整理项目或阶段记录、归档项目文件，使项目或阶段的完整信息成为组织过程资产的组成部分。
| 输入 | 工具与技术 | 输出 |
|---|---|---|
| 项目章程 项目管理计划 项目文件 验收的可交付成果 立项管理文件 协议 采购文档 组织过程资产 事业环境因素 | 专家判断 数据分析（文件分析、回归分析、趋势分析、偏差分析） 会议 | 最终产品、服务或成果的移交 最终报告 组织过程资产更新（含经验教训登记册归档等） |
8.2 行政收尾的主要活动与顺序
行政收尾不是「一纸解散文书」，而是一组有先后依赖的工作，典型顺序如下：
- 确认验收：对照项目章程或范围说明书中约定的验收标准与退出标准，确认全部可交付成果已通过「确认范围」过程获得客户或发起人的正式验收（验收的可交付成果是本过程的直接输入）；
- 移交成果：将最终产品、服务或成果移交给运营部门或客户，完成必要的知识与培训交接，并按协议处理尾款等商务事项；
- 总结经验教训：召开总结会议（复盘会），评审项目绩效数据，编写总结与改进建议，把经验教训登记册内容沉淀为组织过程资产中的经验教训知识库；
- 归档文件：整理并归档全部项目文件与记录，更新组织过程资产，形成组织可复用的项目档案；
- 释放资源：解散项目团队，释放设备、场地等组织资源，使其投入新的工作，并做好团队成员的去向安排。
理解提示：「验收在前、移交在后、总结随后、归档兜底、释放资源收尾」。案例题若问「项目提前终止（如项目被取消）还需不需要行政收尾」——需要！即使项目失败或中途终止，同样要完成文件归档、经验总结与资源释放，只是没有可移交的完整成果。
九、典型案例分析
案例一：被变更拖垮的 OA 项目
背景：某公司 OA 系统项目，合同额 300 万元，工期 6 个月。项目启动后，客户方的各部门陆续提出大量「小调整」：先是行政部要求增加会议室预订模块，随后人事部要求门户页面改版，之后财务部又要求报销流程增加三级审批。项目经理王工与客户「关系很好」，认为都是小需求，均安排团队直接修改，未走任何审批流程。第 5 个月，项目延期一个半月，成本超支 20%，质量测试发现 40 多个缺陷，客户高层震怒，要求说明原因。
问题描述：请分析该项目在整合管理（尤其是变更管理）方面存在的主要问题，并给出改进建议。
问题诊断（分点）：
- 变更请求未以书面形式记录，未建立变更日志，变更的提出与处理均不可追溯；
- 未对每项变更进行范围、进度、成本、质量、风险的综合影响评估，「小改动」的累积效应失控；
- 绕过变更控制委员会（CCB），所有变更均未经审批即实施，违反「未经批准的变更不得实施」这一核心原则；
- 获批变更的前提（更新需求文件、需求跟踪矩阵、项目管理计划）完全缺失，导致文档与系统不一致，测试与验收失去依据；
- 未与客户高层建立变更沟通机制，干系人对变更影响不知情，直至失控才暴露；
- 从源头看，收集需求阶段对需求把握不足、范围边界定义不清，是变更频繁涌入的诱因。
改进建议（分点）：
- 立即冻结私下的「口头变更通道」，向客户宣布所有变更必须书面提交；
- 建立变更日志，记录每项变更的提出人、内容、评估结论、审批结果与状态；
- 由项目经理组织对每一项变更进行多维度影响评估，并给出「实施/不实施」的建议与依据；
- 组建或激活 CCB（由客户方、公司管理层、项目经理等主要干系人代表组成），按变更管理计划分级审批；
- 对已实施但未走流程的变更补充评估与审批，更新全部受控文件；
- 已造成的进度与成本偏差，通过挣值分析量化后向客户高层报告，重大的重新基线决策提交 CCB 与管理层。
命题落点：本题可演化出三问结构：①找出变更流程问题（考原则）；②写出正确变更流程（考七个环节）；③若变更全部被批准对项目意味着什么（考范围基准更新与重新基线）。答题时严格分点、使用教材术语。
案例二：仓促收尾留下的隐患
背景：某政务信息系统项目通过验收后，公司立即宣布项目结项。项目经理和核心成员次日全部转入新项目；系统运维由另一个部门接手，但接手时只收到一张光盘和一份部署文档；三个月后系统出现故障，运维人员找不到任何设计文档与接口说明，也联系不上原项目组成员，故障处置延误一周，被甲方通报批评。
问题描述：该项目在结束项目或阶段（行政收尾）方面存在哪些问题？
问题诊断（分点）：
- 未开展正式的知识管理收尾：经验教训登记册未总结归档，隐性知识（设计思路、故障处置经验）未随人员撤离而转移；
- 项目文件归档不完整，未按行政收尾要求把项目完整信息形成组织过程资产；
- 移交不充分：只交付了部署文档，缺少设计文档、接口说明等运维必需的资料，也未安排对运维人员的知识交接与培训；
- 资源释放过急，在成果移交与知识沉淀未完成前即解散团队，缺少过渡期安排。
改进建议（分点）：
- 在宣布结项前，按行政收尾顺序完成：确认验收 → 成果与知识移交 → 经验教训总结 → 文件归档 → 释放资源；
- 召开项目总结会，输出经验教训总结并将其纳入组织过程资产；
- 编制完整移交清单（源代码、设计文档、接口说明、运维手册），并组织对运维团队的培训与答疑；
- 与运维部门建立一段时期的支持机制（如留守联络人），保证平稳过渡。
命题落点：「行政收尾包括哪些活动、正确顺序是什么」是案例与论文双料考点；论文题「论项目的收尾管理」可直接套用本案例的诊断框架。
十、考点速记卡
| 考点 | 必背结论 | 记忆抓手 | 考法 |
|---|---|---|---|
| 整合管理的责任归属 | 整合是项目经理的责任，不能授权他人代替 | 「总装工位不可外包」 | 概念判断 |
| 执行整合三层面 | 过程层面、认知层面、背景层面 | 「过认背」 | 多选/单选 |
| 章程签发人 | 项目以外的实体：发起人、项目集或 PMO | 「局外人授权」 | 单选/场景 |
| 章程 vs 计划 | 章程高层级、签发即授权；计划操作级、由项目经理组织编制、经变更控制修订 | 「章程授权、计划导航」 | 对比辨析 |
| 项目管理计划组成 | 子管理计划 + 范围基准、进度基准、成本基准 | 「计划带三条基准」 | 归类判断 |
| 变更四类型 | 纠正（纠已偏）、预防（防未偏）、缺陷补救（修产品）、更新（改文件） | 「纠预补更」 | 场景匹配 |
| CCB | 审查、评价、批准、推迟或否决变更的正式团体；组成由变更管理计划规定，可含项目经理 | 「只批不做」 | 概念/场景 |
| 变更核心原则 | 未经批准的变更不得实施；批准的变更必须实施并追踪至关闭 | 「先批后做」 | 判断/案例 |
| 绩效三件套 | 数据（执行产出）→ 信息（控制过程加工）→ 报告（监控汇总） | 「数信报加工链」 | 排序/辨析 |
| 经验教训登记册 | 早期创建、全程更新、收尾归入组织过程资产知识库 | 「早建晚归」 | 时点判断 |
| 行政收尾顺序 | 确认验收 → 移交成果 → 总结经验教训 → 归档文件 → 释放资源 | 「验移总归释」 | 排序/案例 |
| 隐性知识管理 | 靠人际互动、实践社区、引导与倾听，不能只靠文档库 | 「隐性靠人」 | 场景选择 |
本章自测 共 15 题
建议闭卷限时 18 分钟完成，再逐题展开解析核对。错题请回到教材对应小节，并把错因写入错题本。
考查范围：整合管理 7 个过程的输入输出、项目章程、项目管理计划与项目文件、变更请求四类型、CCB 与变更完整流程、知识管理、绩效三件套、行政收尾顺序。
1.关于项目章程，下列说法正确的是（ ）。（考点：项目章程的签发与作用）
查看答案与解析
【为什么选 B】项目章程的本质是「组织对项目的正式授权」。授权必须来自有权调配资源的一方，即项目以外、层级更高的实体——发起人、项目集管理机构或 PMO。章程同时正式任命项目经理并赋予其动用组织资源的职权，这正是「先有章程、项目经理才有正式权力」的逻辑。
【A 错在哪】A 颠倒了授权关系：项目经理是「被章程授权的人」，自己给自己签发章程等于无授权，恰恰违背了章程由项目外部实体发布这一教材表述。
【C 错在哪】C 混淆了章程与项目管理计划、WBS 的粒度。章程是高层级文件，只描述项目边界、主要可交付成果、里程碑与审批要求，技术方案与分解结构属于规划阶段的计划与文件内容。
【D 错在哪】D 绝对化表述。多阶段项目可以在每个阶段开始时重新确认或修订章程；章程的修改虽须谨慎并经原签发方认可，但并非「不得修改」。
2.下列文件中，属于「项目管理计划」组成部分的是（ ）。（考点：项目管理计划与项目文件的区分）
查看答案与解析
【为什么选 B】项目管理计划由两大部分组成：①各子管理计划（范围、需求、进度、成本、质量、资源、沟通、风险、采购、干系人参与管理计划等）；②三大基准——范围基准、进度基准、成本基准。基准是经变更控制批准的绩效度量依据，属于计划组件。
【A 错在哪】A 风险登记册是识别风险等过程的输出，属于「项目文件」。命题人专门挑这类名字里不带「计划」二字的登记册来考归类，考生易被「很重要所以像计划」的直觉误导。
【C 错在哪】C 变更日志记录变更请求的处理状态，由整体变更控制过程维护，是项目文件，不是计划组件。
【D 错在哪】D 问题日志记录项目执行中被发现的问题及责任人，同样是项目文件。
3.某项目测试中发现某模块的输出结果与需求规格不符，开发团队提出修复该缺陷的申请。这一变更请求属于（ ）。（考点：变更请求的类型）
查看答案与解析
【为什么选 C】缺陷补救的对象是「不一致的产品或产品组件」。题干明确指向「模块输出结果与需求规格不符」这一产品本身的缺陷，修复它的活动就是缺陷补救。判断锚点是：问题出在产品上，而不是项目的绩效偏差或受控文件。
【A 错在哪】A 纠正措施针对的是项目工作绩效与项目管理计划之间的偏差（如进度落后、成本超支后把绩效拉回基线），对象是「项目绩效」而非产品质量缺陷。
【B 错在哪】B 预防措施面向尚未发生的潜在偏差，具有前瞻性；题干中的缺陷已经发生，不存在「预防」的时间指向。
【D 错在哪】D 更新针对的是正式受控的文件或计划的修改，对象是「文件」，而题干要修的是产品本身。
4.关于项目中的隐性知识，下列说法正确的是（ ）。（考点：显性知识与隐性知识）
查看答案与解析
【为什么选 B】隐性知识存在于个人头脑、经验与行为习惯中，难以用系统化语言编撰传达，因此其传递高度依赖人际渠道：积极倾听、引导、人际交往、实践社区、同级回顾等。这正是「管理项目知识」过程把人际关系与团队技能列为核心工具的原因。
【A 错在哪】A 「完整编撰与存储」恰是显性知识的特征；隐性知识若能完整文档化，就不再是隐性知识了。
【C 错在哪】C 经验教训登记册属于显性化的载体，只能承载被表述出来的一部分经验，无法替代人与人的互动交流，更不能作为「不组织交流」的理由。
【D 错在哪】D 与教材观点相反：隐性知识（技术诀窍、风险预感、设计直觉）对项目成败影响重大，管理项目知识的重点恰恰是促成隐性知识的分享与应用。
5.关于经验教训登记册，下列说法正确的是（ ）。（考点：管理项目知识的输出）
查看答案与解析
【为什么选 B】经验教训登记册是「管理项目知识」过程的核心输出，在项目早期创建，涵盖类别、情景描述与建议，在项目全程不断更新；到「结束项目或阶段」时，其中的相关信息被归档进入组织过程资产（经验教训知识库），供后续项目复用。「早建、常更、晚归」三个时间点都要记住。
【A 错在哪】A 收尾才编写意味着大量过程性经验已经流失，且违背「早期创建、全程更新」的教材表述。
【C 错在哪】C 经验教训包括「经验」与「教训」两面，成功做法同样要沉淀，否则组织无法复制成功。
【D 错在哪】D 经验教训登记册不是受控基准文件，其创建与更新无需 CCB 审批；CCB 只裁决变更请求。
6.项目执行过程中，客户提出增加一个新的报表功能。作为项目经理，接下来首先应该做的是（ ）。（考点：变更流程的起点）
查看答案与解析
【为什么选 B】变更管理的第一步是「受控的记录」。任何干系人提出的任何变更，都要先以书面形式记入变更日志，使其可追溯、可评估、可关闭。没有记录，后面的评估、审批、沟通都无从谈起。注意题干问的是「首先」，对应流程链条的第一环。
【A 错在哪】A 属于「先斩后奏」式违规：评估可以在记录之后进行，但「着手修改设计」意味着未经批准即实施变更，违反「未经批准的变更不得实施」。
【C 错在哪】C 变更请求是否被批准由 CCB 或授权审批者决定，项目经理无权直接拒绝；「先拒绝再说」也不是程序动作。
【D 错在哪】D 提交 CCB 是记录与影响评估之后的环节；跳过记录与评估，CCB 缺乏决策依据。
7.审计发现，某开发人员根据客户的口头要求，未经任何审批就修改了已交付的功能并上线。项目经理正确的处理方式是（ ）。（考点：未经批准变更的处置）
查看答案与解析
【为什么选 C】对已经发生的未批准变更，正确做法不是简单回滚或保留，而是「事后补程序」：把该修改补记为变更请求、组织影响评估、提交 CCB 审批。CCB 批准，则保留修改并更新相关受控文件；CCB 否决，则撤销修改恢复原状。这样既纠正了程序违规，又不武断损害项目利益。
【A 错在哪】A 「补办手续、保留修改」预设了批准结果，把 CCB 的决策权架空；若 CCB 否决，保留修改即持续违规。
【B 错在哪】B 该修改不是产品缺陷（功能本身可用），而是流程违规产生的未经批准变更，套用缺陷补救流程混淆了概念。
【D 错在哪】D 只处理人不处理事：已发生的未批准变更必须纳入变更管理流程闭环，否则文档与系统将长期不一致。
8.关于「工作绩效数据、工作绩效信息、工作绩效报告」三者，下列说法正确的是（ ）。（考点：绩效三件套）
查看答案与解析
【为什么选 C】三者构成一条加工链：执行过程（指导与管理项目工作）采集原始数据；各控制过程（控制范围、控制进度等）把数据与计划基准比较加工成信息（如偏差结论）；监控项目工作再把信息汇编成报告，供决策与沟通使用。粒度由粗加工到精加工，一一对应三个过程。
【A 错在哪】A 张冠李戴：指导与管理项目工作输出的是工作绩效数据，工作绩效报告是监控项目工作的输出。
【B 错在哪】B 把「数据」和「信息」的定义对调了。数据是未经加工的原始观察值与测量值，比较分析是「信息」的加工程序。
【D 错在哪】D 实施整体变更控制的核心输出是批准的变更请求与计划、文件更新，绩效三件套分别属于执行、控制、监控三类过程。
9.关于变更控制委员会（CCB），下列说法正确的是（ ）。（考点：CCB 的角色与组成）
查看答案与解析
【为什么选 B】这是 CCB 职能的教材级定义：一个正式组成的团体，负责审查、评价、批准、推迟或否决项目变更，并记录和传达变更处理的决定。注意它的职能边界——只「决策」，不「执行」。
【A 错在哪】A 教材明确 CCB 由主要干系人的代表组成，可能包括项目经理，「项目经理不得参与」属于反向编造。
【C 错在哪】C 绝对化且低效。变更管理计划中可以对部分变更授权项目经理直接审批，只有影响基准或重大目标的变更才必须提交 CCB；「一律上会」不是教材主张。
【D 错在哪】D 混淆决策与执行：批准的变更请求在「指导与管理项目工作」过程中由项目团队实施，CCB 不承担实施职责。
10.项目经理在编制计划时同步考虑进度安排对成本预算与资源可用性的影响，并以整体系统的眼光判断各项约束之间的相互作用。这体现的执行整合层面是（ ）。（考点：执行整合的三个层面）
查看答案与解析
【为什么选 B】题干的两个关键词是「整体系统的眼光」「判断约束之间的相互作用」——这正是认知层面整合的特征：用整体的、系统的方式思考，把经验、洞察力与知识整合为「知道什么、如何运用、何时行动」的能力。其产出被视为一项临时的「能力知识」。
【A 错在哪】A 过程层面整合强调把各知识领域、各过程组的过程作为整体来协调执行，重心在「过程与活动的统筹」，而非思维层面。
【C 错在哪】C 背景层面整合关注项目与外部环境（新商业环境、新技术、干系人变化）的相互影响与动态调整，题干没有涉及外部环境变化。
【D 错在哪】D 「组织层面整合」不是教材列举的执行整合层面，属于编造选项——执行整合只有过程、认知、背景三个层面。
11.下列各项中，属于「指导与管理项目工作」过程输出的是（ ）。（考点：指导与管理项目工作的输出）
查看答案与解析
【为什么选 C】指导与管理项目工作「干活并暴露问题」，其标志性输出正是：可交付成果、工作绩效数据、问题日志、变更请求（以及计划与文件的更新）。变更请求在此产生、交由整体变更控制裁决，是该过程「发现问题」的直接证据。
【A 错在哪】A 工作绩效报告是监控项目工作的输出，该过程只产出更原始的「工作绩效数据」。
【B 错在哪】B 核实的可交付成果是「质量控制」过程的输出（经质量检查确认正确），才作为「确认范围」的输入，不属于本过程输出。
【D 错在哪】D 批准的变更请求是实施整体变更控制的输出，且恰恰是本过程的输入——输入输出方向对调是本类题的经典陷阱。
12.某变更请求已获 CCB 批准，且该变更影响进度基准。接下来项目经理应该（ ）。（考点：批准后变更的处理顺序）
查看答案与解析
【为什么选 B】变更批准后的第一件事是「把变更落到纸上」：更新受影响的项目管理计划（包括被批准修改的进度基准）与项目文件，然后才在指导与管理项目工作过程中实施。先更新、后实施，才能保证执行依据（计划）与实际工作始终一致。
【A 错在哪】A 顺序颠倒：「先做后改」会造成实施期间无受控依据，实施与文档脱节，是典型的流程违规。
【C 错在哪】C 沟通结果属于流程末端的沟通环节，且「无需更新计划」直接违背受控管理要求。
【D 错在哪】D CCB 已批准，重新审批毫无程序依据；多此一举的选项往往用于迷惑对流程不自信的考生。
13.下列关于项目管理计划的说法，正确的是（ ）。（考点：项目管理计划的性质）
查看答案与解析
【为什么选 B】项目管理计划的构成是教材明确定义的两大块：①各子管理计划（范围、进度、成本、质量、资源、沟通、风险、采购、干系人参与等）；②范围基准、进度基准、成本基准。「子计划 + 三基准」是对该文件最精准的一句话概括。
【A 错在哪】A 绝对化错误：计划会通过整体变更控制过程更新与修订，逐渐精确完整——这本身就是教材强调的渐进明细特征。
【C 错在哪】C 发起人签发的是项目章程；项目管理计划由项目经理组织项目团队编制，经审批后生效。
【D 错在哪】D 需求跟踪矩阵是项目文件（收集需求过程的输出），不属于计划组件。
14.某项目的全部可交付成果已获客户正式验收，项目经理即将开展行政收尾。下列活动顺序正确的是（ ）。（考点：行政收尾的顺序）
查看答案与解析
【为什么选 B】行政收尾有明确的逻辑依赖：先完成成果向运营或客户的移交（知识、培训、商务结算），随后召开总结会沉淀经验教训（此时项目信息仍然完整、人员仍在岗），再把全部记录归档进组织过程资产，最后才释放资源、解散团队——顺序不可倒置，因为资源一旦释放，总结与归档就无从谈起。
【A 错在哪】A 把释放资源放在首位，人员一散经验教训即流失，且成果未移交项目就不算完成收尾。
【C 错在哪】C 在移交完成前释放资源，移交环节（培训、答疑、尾款配合）将失去人力支撑。
【D 错在哪】D 先归档后移交，而归档本应包含移交过程中产生的记录；且在总结之前归档，经验教训尚未沉淀即封存，次序混乱。
15.某项目因资金链断裂被公司中途取消，可交付成果无法全部完成。关于该项目的后续工作，正确的说法是（ ）。（考点：项目提前终止时的行政收尾）
查看答案与解析
【为什么选 B】「结束项目或阶段」适用于正常完工，也适用于提前终止的项目。终止型收尾包括：确认并移交已完成且可用的部分成果、处理范围外的未决事项、总结经验教训（特别是项目失败的教训）、归档项目文件形成组织过程资产、释放资源。这些活动的价值恰恰在失败项目上最大——避免组织重复付出学费。
【A 错在哪】A 与教材直接矛盾：提前终止的项目同样必须走行政收尾流程，「不了了之」会让组织损失全部知识沉淀。
【C 错在哪】C 文档「各自保存」等于弃置组织过程资产，违背归档要求，且解散团队不是收尾的全部内容。
【D 错在哪】D 项目已被取消，继续执行缺乏合法性与资金来源，混淆了「项目终止」与「项目延期」。