INFO6007 Week 10 Integration Management 讲课总结
INFO6007 Week 10 讲课总结：Integration Management
课程：INFO6007 — Project Management in IT，Semester 2 2026 来源：讲义 PDF + tutorial（无转录稿；Canvas 上有本周录播链接，本文未据此整理） -
Lecture - INFO6007 Week 10 - Integration Management.pdf（59 页） -Tutorial sheet INFO6007 Week 10+Tutorial answer sheet Week 10参考：Watt, A. Project Management (2nd ed.)；Schwalbe, K. Information Technology Project Management (9th ed.)；Hiatt (2006) ADKAR；Kotter (1996) Leading Change；Kübler-Ross (1969)。
本讲是一堂「收束课」：先把前面学过的 九个知识领域 和 五个生命周期阶段 串一遍，再讲把它们粘在一起的 整合管理（Integration Management），最后加入 组织变革管理（Change Management）——「交付了系统」不等于「人们用起来了」。
⚠️ 本周 tutorial 是 Week 9 领导力/治理/对齐的练习（HealthPlus 案例，第八章）；整合管理本身在 Week 11 tutorial 练。
一、PMBOK 框架回顾
PMBOK（Project Management Body of Knowledge） 由 PMI 出版，是全球公认的项目管理标准。它把项目管理组织为 5 个过程组（Process Groups） 和 10 个知识领域（Knowledge Areas），说明做什么以及如何整合各过程。
五个过程组
Initiating → Planning → Executing → Monitoring & Controlling → Closing
十个知识领域（讲义逐一回顾）
| # | 知识领域 | 目的 | 关键活动 | IT 例子 | 讲授周 |
|---|---|---|---|---|---|
| 1 | Stakeholder | 识别、参与和管理干系人以满足期望 | 识别、规划参与、管理参与、监控参与 | 让业务用户、IT 团队和供应商对系统需求达成一致 | W2 |
| 2 | Scope | 定义包含什么、不包含什么 | 收集需求、定义范围、创建 WBS、确认和控制范围 | 确定新模块的功能而不越界 | W3 |
| 3 | Schedule | 规划和控制时间线 | 定义活动、排序、估算工期、制定和控制进度 | 规划敏捷 sprint 或瀑布里程碑 | W3 |
| 4 | Cost | 规划、估算、预算和控制成本 | 估算、确定预算、控制成本 | 云基础设施、许可证、开发资源预算 | W4 |
| 5 | Quality | 交付物满足标准、干系人满意 | 规划质量、QA、QC | 软件通过测试并满足安全/合规标准 | W5 |
| 6 | Resource | 规划、获取和管理人员、设备和材料 | 资源规划、估算、获取、建设和管理团队 | 高效分派开发、测试和系统管理员 | W6 |
| 7 | Communication | 确保信息及时有效流动 | 规划、管理、监控沟通 | 向干系人报告进度、更新 sprint 进展 | W9 |
| 8 | Risk | 识别、分析和缓解风险 | 识别、定性与定量分析、应对规划、监控 | 规划服务器宕机、安全漏洞或需求变更 | W7 |
| 9 | Procurement | 从外部获取商品、服务或成果 | 规划、实施、控制、关闭采购 | 雇用云服务商、购买软件许可证 | W8 |
| 10 | Integration | 协调以上所有领域 | 见第四章七个过程 | — | W10 |
Menti：你认为最重要的知识领域是哪个？ 讲义没有给标准答案。一个站得住的回答是 Integration——因为它是唯一横跨所有过程组的领域，其他领域的决策都要经过它来权衡；也可以论证 Stakeholder 或 Risk，关键在理由。
二、项目生命周期五阶段（以 NSW 数字驾照为例）
NSW 数字驾照：2017 年 11 月 Dubbo 首试 → 悉尼东区海滩和 Albury 扩大试点 → 2019 年 10 月全州上线。干系人：Service NSW、Transport for NSW、NSW Police、持照人、查验方。
1. Initiation（启动）
| 项目 | 内容 |
|---|---|
| 目的 | 正式启动项目，定义目标 |
| 关键活动 | 制定项目章程（正式授权）；识别关键干系人；可行性研究（技术、财务、运营） |
| 输出 | 项目章程、干系人登记册、初步范围 |
| 关键考虑 | 项目有清晰目的和发起人支持 |
NSW：章程写明目的（实体驾照的安全数字替代品）、目标（便捷访问、被接受的身份证明）、范围（Service NSW App 中与驾照记录关联的驾照）、权限（发起人、PM、初始治理）；可行性评估技术集成、安全、隐私、运营和资金。示例：章程授权在更大范围推广之前先开发和试点。
2. Planning（规划）
| 项目 | 内容 |
|---|---|
| 目的 | 制定实现目标的详细路线图 |
| 关键活动 | 定义范围、WBS、制定进度、估算成本和预算；规划资源、风险、沟通和采购；汇总成项目管理计划 |
| 输出 | 范围说明书、进度、预算、风险计划、项目管理计划 |
| 关键考虑 | 好的规划减少不确定性、设定现实期望 |
NSW 四步：定义范围（功能、排除项、验收标准）→ 建立进度（设计、集成、测试、试点、推广）→ 规划资源与成本（团队角色、供应商、预算和储备）→ 整合各计划（质量、风险、沟通、采购、变更控制）。
3. Executing（执行）
| 项目 | 内容 |
|---|---|
| 目的 | 执行工作，产出项目成果 |
| 关键活动 | 分派和管理资源；开发交付物（编码、配置、测试）；实施 QA 和沟通计划；管理干系人期望 |
| 输出 | 工作绩效数据、完成的交付物 |
| 关键考虑 | 需要强有力的协调和监控 |
NSW：动员团队 → 开发 App 和集成 → 测试质量和安全 → 运行试点、支持用户 → 准备全州推广；产出可工作的软件、测试结果、试点反馈、运营就绪。
4. Monitoring & Controlling（监控）
| 项目 | 内容 |
|---|---|
| 目的 | 跟踪进展、识别偏差、实施纠正措施 |
| 关键活动 | 对照范围、进度、成本基线衡量绩效；对范围、进度或成本变更执行整合变更控制；监控风险、质量、资源和沟通 |
| 输出 | 绩效报告、已批准的变更请求、计划更新 |
| 关键考虑 | 在执行期间持续进行 |
NSW：衡量进度 → 对比基线 → 复审风险与质量 → 批准变更 → 更新计划和报告；监控范围变更、进度偏差、成本偏差、质量问题。
5. Closure（收尾）
| 项目 | 内容 |
|---|---|
| 目的 | 正式完成并关闭项目或阶段 |
| 关键活动 | 获得交付物的正式验收；经验教训会议；释放项目资源；归档文档 |
| 输出 | 最终项目报告、经验教训、正式验收、关闭的合同 |
| 关键考虑 | 恰当的收尾保证知识转移并为未来项目铺路 |
NSW 收尾：
| 活动 | 做法 | 输出 |
|---|---|---|
| 确认验收 | 发起人确认约定交付物和推广成果 | 正式验收 |
| 关闭合同 | 核对供应商工作、付款和剩余义务 | 关闭的合同 |
| 总结经验 | 复盘试点、上线、支持和治理经验 | 经验教训 |
| 移交与归档 | 把支持责任移交给运营，存档项目文件 | 移交包、最终报告 |
📝 Question Bank Q1（远程医疗预约系统上线 6 个月后团队仍每周加功能、答疑、修 bug，「项目永远做不完」）：加新功能 = 项目工作（或新项目），答疑和小修 = 运营（ITSM）；病根是范围蔓延 + 没有收尾标准——启动时就应在章程中写明成功标准和收尾条件，上线后正式移交给运营（这也是 Week 11–12 ITSM 的切入点）。
Question Bank Q4（没批章程就开始做原型）：跳过的是 Initiation，缺失章程、干系人登记册、初步范围；补救是暂停扩展工作、补章程并获批准、补做干系人识别。
Menti 题：安全漏洞要多两周和额外经费，而上线日期临近
A. 按安全团队估算申请延期两周和追加经费，批准后再修订计划 B. 评估安全修复对各项计划的影响，比较可行的应对方案，提交推荐的变更请求供审批 C. 把开发者从非必要功能调去修安全问题，再为由此产生的范围和资源变化申请批准 D. 让发起人在延期和削减范围之间二选一，然后再评估所选方案的详细影响
最合适是 B（讲义未公布答案，此为依据整合变更控制推断）： - A 只看了时间和成本两个维度，没做整体影响评估 - C 先做后批——绕过了变更控制 - D 先决策后评估——顺序反了，把分析责任推给发起人 - B 正是整合变更控制的标准顺序：评估跨计划的影响 → 比较方案 → 提交推荐 → 审批
知识领域 × 生命周期映射
| 知识领域 | 启动 | 规划 | 执行 | 监控 | 收尾 |
|---|---|---|---|---|---|
| Scope | ● | ● | |||
| Schedule | ● | ● | |||
| Cost | ● | ● | |||
| Quality | ● | ● | ● | ||
| Resource | ● | ● | ● | ||
| Communication | ● | ● | ● | ||
| Risk | ● | ● | ● | ||
| Procurement | ● | ● | ● | ||
| Stakeholder | ● | ● | ● | ● | |
| Integration | ● | ● | ● | ● | ● |
（按 PMBOK 第 6 版过程归属整理）只有整合管理在五个阶段都出现——这就是它被称为「胶水」的原因；启动阶段只有整合（制定章程）和干系人（识别干系人）。
三、IT 项目的独特性
| 特征 | 说明 | 例 |
|---|---|---|
| High complexity | 多个相互依赖的系统、应用和技术；集成硬件、软件、网络和云 | ERP 需要财务、HR 和 IT 协调 |
| Rapidly changing technology | 技术演进快，容易过时；项目中途可能要适应新工具 | 项目周期中从本地服务器切到云 |
| Intangible deliverables | 产出是软件、系统等无形物；以功能、性能、用户满意度衡量 | 网页或 App 在部署前用户「看不见」 |
| High stakeholder involvement | 开发、测试、运维、终端用户、管理层都要参与；错位会导致范围蔓延或失败 | 定制 CRM 需要销售、市场和 IT 的输入 |
| High uncertainty & risk | 需求、技术性能或集成都有不确定性 | 意料之外的 bug 推迟发布 |
| Dependency on requirements accuracy | 小误解会级联成大延期或返工；常用敏捷应对需求演进 | 登录流程理解错误 → 大规模重新设计 |
这六点正好对应前面各周：复杂性 → 整合管理；技术变化 → 风险；无形交付物 → 质量；干系人 → 干系人/沟通；不确定性 → 风险；需求依赖 → 范围管理。
四、整合管理
Project Integration Management：在整个项目生命周期中协调所有过程和活动，确保项目达成目标。常被称为把项目粘在一起的「胶水」。
核心观点： - 每个知识领域（范围、进度、成本、质量……）都必须对齐和整合 - 确保决策、变更和活动被协调，避免冲突和重复
实践中的整合工具
| 工具 | 例 |
|---|---|
| PMIS（项目管理信息系统） | MS Project、Jira、Asana、Trello |
| Dashboards | 实时显示进度、风险、成本和资源 |
| Change Control Board（CCB） | 批准/拒绝项目变更的团队 |
| 文档与知识库 | Wiki、Confluence、SharePoint（经验教训、最佳实践） |
七个整合过程（PMBOK 第 6 版，必背）
| # | 过程 | 所在阶段 | 说明 |
|---|---|---|---|
| 1 | Develop Project Charter | 启动 | 写明目标、干系人、高层需求的启动文件 |
| 2 | Develop Project Management Plan | 规划 | 汇总所有子计划（范围、进度、成本、质量、风险、沟通、资源、采购、干系人参与） |
| 3 | Direct and Manage Project Work | 执行 | 按计划执行任务、协调团队 |
| 4 | Manage Project Knowledge | 执行 | 捕捉经验教训、维护文档、运用组织知识 |
| 5 | Monitor and Control Project Work | 监控 | 用 KPI 和仪表盘跟踪绩效，确保项目在轨 |
| 6 | Perform Integrated Change Control | 监控 | 审查和批准变更请求，防止范围蔓延 |
| 7 | Close Project or Phase | 收尾 | 正式验收交付物、释放资源、归档文档 |
记忆：「章程 → 计划 → 执行 → 知识 → 监控 → 变更 → 收尾」，正好按五个阶段排开。
整合变更控制与 CCB
整合变更控制的典型流程：
- 提交变更请求（谁、为什么、改什么）
- 影响分析——跨所有维度：范围、进度、成本、质量、风险、资源、采购
- 评估方案（接受、推迟到下一版本、部分接受、拒绝）
- CCB 审批（按决策权限，重大变更上报指导委员会）
- 更新基线和相关计划，沟通给干系人
- 实施并跟踪
为什么叫「整合」变更控制？ 因为任何一个变更都会同时影响多个知识领域——比如加一个功能，范围变大 → 工期延长 → 成本增加 → 测试增加 → 风险变化 → 可能要追加采购。单独看任何一个维度都不够。
讲义课后题：整合管理如何防止范围蔓延、超支和延期？ ——通过正式的整合变更控制（任何变更必须先做全局影响评估并获批）、统一的基线（范围/进度/成本三个基线绑在一起），以及持续的监控。
五、变更管理（Organisational Change Management）
⚠️ 这里的「变更管理」是组织变革管理（让人接受新的工作方式），不是上面的「整合变更控制」（管理项目范围/基线的变更请求）。考试中要看清语境。
为什么重要
- 项目成功不只是交付技术方案
- 真正的价值出现在人们理解变化、采用新工作方式并持续下去之后
三步：① 交付方案（范围、进度、预算；技术、流程、产出）→ ② 支持采用（干系人、培训；信心与行为）→ ③ 实现收益（使用和价值；改进的成果）
项目管理 vs 变革管理
| Project Management | Change Management | |
|---|---|---|
| 关注 | 范围、进度、预算、质量 | 沟通、参与、就绪度 |
| 做什么 | 协调资源、供应商和交付工作；构建并上线方案 | 建立干系人信心、培训和支持；帮助人们采用新工作方式 |
| 核心问题 | 「我们交付得好吗？」 | 「人们在成功地使用它吗？」 |
Successful IT change = delivery + adoption
变革管理在生命周期中的位置
| 阶段 | 变革管理活动 |
|---|---|
| Initiate | 讲清变革的理由；识别发起人和受影响群体 |
| Plan | 绘制干系人图谱和影响；规划沟通和培训 |
| Build / Test | 让用户参与演示和试点；收集反馈并改进 |
| Go-live | 培训、支持、管理切换；提供帮助渠道和变革大使（champions） |
| Benefits | 跟踪采用率并强化；复审收益并改进 |
PM 要点：把采用相关的任务、负责人和衡量指标加入计划——不只是技术任务。
Kübler-Ross 变革曲线
典型阶段：震惊/否认 → 愤怒 → 讨价还价 → 低谷 → 探索 → 接受。
在项目中的用法： - 预期会有不同反应——抵触是正常的 - 尽早并经常沟通「为什么」 - 倾听顾虑、承认不确定性 - 上线后提供培训、工作辅助材料（job aids）和支持 - 寻找快速胜利（quick wins）以重建信心
PM 的实操变革行动
| 行动 | 要点 |
|---|---|
| Communicate the why | 解释业务理由；展示对用户有什么变化 |
| Map stakeholders | 谁受影响？谁能影响采用？ |
| Support adoption | 培训、工作辅助、试点；经理和大使 |
| Measure uptake | 使用率、反馈、合规性；上线后调整 |
讲义参考文献里还列了 ADKAR（Hiatt）：Awareness → Desire → Knowledge → Ability → Reinforcement；以及 Kotter 的变革八步。讲义正文没有展开，答题时可以提一句作为框架。
迷你案例：新报告仪表盘推广
公司用在线仪表盘取代电子表格汇报项目状态。仪表盘技术上已就绪，但团队负责人仍在发电子表格（他们信任旧流程），培训出席率低，各团队报告不一致。
参考答案（自拟）：
| 问题 | 要点 |
|---|---|
| 可见的采用风险 | 用户继续用旧流程 → 新旧并行，数据不一致，仪表盘价值无法实现 |
| 优先关注的干系人 | 团队负责人——他们是数据的提供者，也是团队行为的示范者 |
| 两个变革行动 | ① 向团队负责人讲清「为什么」并让他们参与改进仪表盘（变成 champion）；② 设定旧流程的停用日期，同时提供短时、按需的培训和 job aids |
| 一个交付行动 + 一个采用行动 | 交付：增加从电子表格导入的功能降低切换成本；采用：由管理层只在仪表盘上审阅状态，形成强化 |
| 变化起作用的证据 | 按时通过仪表盘提交的团队比例、电子表格邮件数量下降、报告一致性、用户满意度 |
两组要点
变革管理：技术交付≠成功变革；采用工作要早开始；沟通、培训、支持减少阻力；上线后跟踪采用和收益。
整合管理：连接所有知识领域；贯穿生命周期协调；管理 IT 项目的复杂性；批准变更前评估对整个项目的影响；用基线、仪表盘和经验教训指导决策；支持采用和正式收尾，移交给运营。
六、课后案例：EduTech 在线学习平台
开发 Web 与移动应用、与大学现有数据库集成、满足数据隐私法规、协调多方，6 个月交付。中途：大学要求增加虚拟实验室功能；与现有数据库的集成有性能问题；团队成员被抽调导致资源波动。
参考要点（自拟，Week 11 tutorial 有相近的官方答案，见 Week 11 文章）：
| 问题 | 要点 |
|---|---|
| 虚拟实验室请求时最关键的整合过程 | Perform Integrated Change Control（评估对范围、进度、成本、质量、风险的影响，CCB 审批或推迟到 v2）+ Develop/Update PM Plan + Monitor and Control Project Work |
| 保持干系人知情的工具 | Jira 仪表盘、变更日志、定期指导委员会会议、Confluence 决策记录 |
| 映射到生命周期 | 启动（章程、干系人：大学管理方）→ 规划（集成、隐私计划、6 个月进度）→ 执行（开发、集成）→ 监控（变更请求、性能问题、资源波动）→ 收尾（验收、移交运营、经验教训） |
| 整合薄弱会怎样 | 未经评估就加功能 → 范围蔓延、错过 6 个月期限；性能问题无人统筹 → 上线后用户体验差；资源被抽走无人上报 → 关键路径延误 |
| 一条经验教训 | 「在规划阶段就对遗留数据库做性能基准测试，并在合同/章程中明确中途新功能的处理规则（默认进入 v2 backlog）」 |
七、Tutorial（Week 10）：HealthPlus 保险的云迁移
本周 tutorial 是 Week 9 领导力、治理与对齐的练习。每组扮演一个角色（CIO/发起人、指导委员会、PM、IT 团队、运营与客服、合规与风险）从各自视角回答。
案例：中型健康保险公司 HealthPlus 把遗留理赔系统迁到云平台，目标是可扩展性、减少宕机、加快理赔审批改善客户体验。 - 领导问题：PM 技术强但缺乏沟通和激励能力 → 团队士气低 - 治理缺口：指导委员会开会不规律，预算超支和合规要求的决策被拖延 - 对齐问题：IT 关注迁移速度，运营和合规关注数据安全和法规遵从 → 团队间紧张 - 纠正措施：新沟通计划、定期指导委员会、PM 领导力培训（转向自适应风格）、引入平衡计分卡 - 结果：晚了三个月，但性能、合规和客户满意度都提升了
Q1 领导力：什么风格更好？
自适应/变革型领导——激励团队、关注个人需求；鼓励 IT、运营和合规之间的开放沟通与协作。这种风格帮助 PM 把技术专长和人员管理连接起来，减少士气低落和沟通不畅。
Q2 治理：缺失了哪些结构/机制？
- 指导委员会应定期开会，批准关键决策并监控风险
- 发起人应更积极地参与，支撑与组织目标的对齐
- 缺少清晰的升级路径和问责
- 风险与合规监督机制薄弱（尤其是数据安全和隐私）
Q3 对齐：项目如何与战略错位？
- IT 关注迁移速度和技术功能，而非可扩展性、合规和客户体验这些战略目标
- 运营和合规的优先级（数据安全、法规遵从）没有纳入项目规划
- 没有正式框架把项目活动映射到战略目标 → 紧张和错位
Q4 整合：三种失败如何相互强化？
| 链条 | 机制 |
|---|---|
| 领导差 → | 团队动机弱、沟通不清 → 加剧 IT 与业务目标的错位 |
| 治理弱 → | 决策延误、风险无人管 → 领导无法有效推行方向 |
| 错位 → | 优先级冲突 → 给领导带来压力，也冲击治理结构 |
| 合力 | 项目延误、预算超支、成果次优 |
用一个框架重新对齐
SAM：哪些域断了，怎么修？
断裂： - Business Strategy ↔︎ IT Strategy：IT 追求迁移速度，而非客户体验等战略目标 - Organisational Infrastructure ↔︎ IT Infrastructure：团队未协调，合规和运营被边缘化
修复：按战略目标重新评估 IT 举措；加强 IT、运营和合规之间的跨职能沟通；把 KPI 同时映射到 IT 和业务目标。
BSC：追踪哪 4 个指标？
| 视角 | 指标 |
|---|---|
| Financial | 项目预算遵从率、云基础设施带来的成本节约 |
| Customer | 对门户性能的满意度、理赔审批时间 |
| Internal Process | 宕机时间、系统响应时间、理赔处理错误率 |
| Learning & Growth | 员工培训完成率、团队技能提升、云最佳实践的采用 |
价值流：如何围绕客户价值重组工作？
- 识别端到端价值流（如「理赔处理」「客户支持」）
- 围绕每条价值流组建跨职能团队
- 按交付给客户的价值排序功能和任务（更快的理赔审批、安全的处理）
- 建立持续反馈回路，确保 IT 交付与业务成果一致
💡 答题提示：答案里的指标都可以写得更「可衡量」，例如「理赔平均审批时间从 X 天降到 Y 天」「月宕机时间 < Z 小时」——这正是 Practice Exam Q4(c) 对 SLA 指标的要求方式。
八、本周考点速记 / 易错点
- PMBOK = 5 个过程组 + 10 个知识领域；能说出每个领域的目的和一个 IT 例子。
- 生命周期五阶段的输出：启动（章程、干系人登记册）、规划（项目管理计划）、执行（工作绩效数据、交付物）、监控（绩效报告、批准的变更）、收尾（正式验收、经验教训、关闭的合同）。
- 整合管理 = 胶水，唯一贯穿五个阶段的知识领域。
- 七个整合过程：章程 → 计划 → 指导与管理工作 → 管理知识 → 监控工作 → 整合变更控制 → 收尾。
- 整合变更控制的顺序：评估跨计划影响 → 比较方案 → 提交推荐 → CCB 审批 → 更新基线（Menti 题选 B）。先做后批、先决策后评估都是错的。
- CCB 是批准/拒绝变更的团队；PMIS、仪表盘、知识库是整合工具。
- IT 项目六特征：复杂、技术变化快、无形交付物、干系人多、不确定性高、高度依赖需求准确性。
- 组织变革管理 ≠ 整合变更控制；成功的 IT 变革 = 交付 + 采用。
- Kübler-Ross 曲线：否认 → 愤怒 → 讨价还价 → 低谷 → 探索 → 接受；用法：沟通「为什么」、倾听、培训支持、quick wins。
- 采用工作要早开始，并把采用任务和指标写进项目计划；上线后跟踪采用率和收益。
- 项目 vs 运营：上线后的答疑、小修属于运营；没有收尾标准会导致「项目永远做不完」（Question Bank Q1）。
- Tutorial：领导、治理、对齐三者相互强化；SAM 找断裂的域；BSC 每个视角写一个可衡量指标。
九、本讲与前后的衔接
| Week | 内容 | 关键词 |
|---|---|---|
| 2–8 | 各知识领域 | 本周统一回顾 |
| 9 | 领导力、治理与对齐 | 指导委员会、SAM、BSC（本周 tutorial） |
| 10 | 整合管理 | 七个过程、整合变更控制、CCB、变革管理 |
| 11 | ITSM 与流程 1 | tutorial 做本周的整合 × 采购过程映射 |
| 12 | ITSM 与流程 2 | ITIL 的 Change Enablement 是运营阶段的变更控制 |
从项目到服务的桥梁：本周收尾阶段的「把支持责任移交给运营」，就是 Week 11–12 ITSM 的起点；Week 12 讲义专门有一页「How does Project Management link to ITSM?」。