INFO6007 Week 09 Leadership, Governance and Alignment 讲课总结
INFO6007 Week 09 讲课总结：Project Leadership, Governance and Alignment
课程：INFO6007 — Project Management in IT，Semester 2 2026 来源：讲义 PDF + tutorial（无转录稿） -
Lecture - INFO6007 Week 09 - Project Leadership, Governance and Alignment.pdf（66 页） -Tutorial sheet - INFO6007 Week 09+Tutorial answer sheet Week 09参考：Schwalbe, K. (2018). Information Technology Project Management, Communication Management, pp. 425–462。
本讲把三个概念放在一起：Leadership（人与方向）、Governance（监督与问责）、Alignment（战略契合与价值），中间插入了 沟通管理三过程（PMBOK 知识领域）。讲义的比喻：
概念 比喻 Leadership 船长——激励船员、掌舵 Governance 导航系统和规则——确保船安全地保持航向 Alignment 目的地——确保船驶向组织真正想去的地方 ⚠️ 本周 tutorial 是 Week 8 采购管理的练习（CityCare 案例，第八章）；本周内容在 Week 10 tutorial（HealthPlus 案例）练。
零、课程公告：进度评估与期末考试
进度评估（Progress Evaluations）
- 剩余的进度评估改为双周：Week 9 和 Week 11
- 全学期共 5 次评估机会，取最好的 3 次；每次最高 2 分
- 最好三次（满分 6）换算为 10 分；仍占总成绩 10%
- 例：
期末考试信息（重要）
| 项目 | 内容 |
|---|---|
| 形式 | 4 道题，每题一个简短情景 + 3–4 个小问 |
| 时长 | 2 小时 + 10 分钟阅读 |
| 分值 | 每题 15 分，共 60 分 |
| 范围 | 讲座或 tutorial 中讲过的任何主题 |
| 不直接考 | 阅读材料和客座讲座（但可用来充实答案） |
| 可带 | 一张双面 cheat sheet（手写或打印）、非编程计算器、双语词典 |
| 练习卷 | Week 11 发布 |
| 复习安排 | Tutorial 12、13：考试练习；Week 13 讲座：复习 |
讲义原话：练习所有 tutorial 题和讲义末尾的问题——这也是本系列每篇最后都整理 tutorial 的原因。
小组项目最终报告
- 由各模板汇总而成，可加封面和目录
- 报告必须结构连贯，不能是碎片化的拼接
一、三个基础概念
| 概念 | 定义 | 保证什么 |
|---|---|---|
| Leadership | 引导和激励项目团队实现目标 | 让 IT 项目中「人」的一面有效运作 |
| Governance | 提供正式的监督与控制结构，让项目保持问责 | 在范围、预算和合规边界内交付 |
| Alignment | 确保项目目标与组织战略和业务需求一致 | 交付的不只是技术，而是业务影响 |
三者共同影响决策、资源利用和交付价值的能力。
二、项目领导力
Project leadership：激励、引导和影响项目团队与干系人实现项目目标的能力——超越仅仅管理任务和进度。
关键方面：愿景与方向、激励与鼓舞、不确定性下的决策、变革管理、干系人参与。
Project Management vs Project Leadership
| 方面 | Project Management | Project Leadership |
|---|---|---|
| 定义 | 应用知识、技能、工具和技术来计划、执行、控制项目，在范围、时间、成本、质量约束内达成目标 | 激励、引导、影响团队和干系人实现目标 |
| 特征 | 任务导向、流程驱动；确保遵守治理框架和标准；关注效率、资源分配和交付物 | 人员导向、愿景驱动；建立凝聚力和信任；在不确定中给方向；关注长期价值、采用和转型 |
| 关注 | 任务、流程、工具 | 人、愿景、影响力 |
| 目标 | 按范围、时间、成本、质量交付 | 激励、对齐、推动采用和价值 |
| 方式 | 控制、计划、监控 | 激励、引导、适应 |
| 导向 | 短期效率 | 长期影响 |
Leader vs Manager
| 方面 | Leader | Manager |
|---|---|---|
| 关注 | 人、愿景、鼓舞 | 流程、任务、控制 |
| 时间导向 | 面向未来：「我们要去哪？为什么重要？」 | 面向当下：「怎样高效正确地完成？」 |
| 方法 | 激励、影响、赋能 | 计划、组织、监控、控制 |
| 风格 | 灵活、适应、愿意冒险 | 结构化、有条理、规避风险 |
| 结果 | 投入度、创新、长期价值 | 按时、按预算、按范围交付 |
💡 考试不会让你二选一——好的 PM 两者都要：用管理保证交付，用领导力保证采用和价值。
领导风格（接续 Week 6）
| 风格 | 特点 | 优势 | 风险 |
|---|---|---|---|
| Transformational（变革型） | 鼓励创新、拥抱新技术、推动数字化转型 | 高投入、高适应性 | 可能忽视运营细节 |
| Transactional（交易型） | 关注结构、奖励与惩罚 | 问责清晰、纪律性强 | 扼杀创造力和主动性 |
| Autocratic（独裁） | 单方面决策、严格控制 | 紧急情况下决策快 | 常用会导致士气低、缺乏团队输入 |
| Laissez-Faire（放任） | 放手，给高技能专业人员自由 | 鼓励自主和创新 | 团队缺乏经验时导致混乱 |
| Adaptive / Agile（自适应/敏捷） | 灵活、情境化，随项目需要、团队动态和业务优先级调整；赋能团队、快速适应、促进协作，而非依赖僵化层级 | 在控制和赋能之间平衡 | 需要很高的觉察力和技巧来切换风格 |
讲义说自适应/敏捷领导是业界当前最主要、增长最快的风格之一。
在 IT 场景中的应用： - 敏捷软件开发：领导者是 servant & enabler——清除障碍、促进沟通、帮助团队自组织 - 数字化转型：确保与战略目标（效率、自动化、客户体验）对齐，推动全组织采用和文化变革 - 云/基础设施项目：管理跨职能团队（网络、安全、开发），处理风险、维持干系人沟通、随技术挑战调整计划
为什么 IT 项目需要领导力
- 驾驭复杂性和不确定性：技术变化、需求演进 → 帮团队快速适应、在压力下果断决策
- 驱动团队动机与绩效：激发多角色协作，建立士气、信任和问责
- 对齐业务战略：弥合技术执行与业务愿景之间的鸿沟——项目不只是技术上「能跑」，还要交付真实业务价值
项目领导者的核心技能
沟通、适应性与灵活性、风险管理与批判性思维、战略思维与愿景、决策与问题解决、干系人管理与谈判、领导与人员管理、情商（Emotional Intelligence）。
三、沟通管理三过程
沟通管理是 PMBOK 的知识领域之一（也是小组项目的一份模板）。
| # | 过程 | 核心 |
|---|---|---|
| 1 | Plan Communications Management | 谁需要什么信息、谁提供、用什么渠道、何时 |
| 2 | Manage Communications | 按计划收集、创建、分发、存储和检索信息 |
| 3 | Monitor Communications | 监测沟通是否有效、及时、准确，并调整 |
1. 规划沟通管理
确定项目的沟通需求，定义信息如何被收集、分发、存储和管理——确保正确的信息在正确的时间以正确的格式到达正确的人。
目标： - 识别干系人的沟通需求 - 确定沟通方法和渠道 - 定义角色和职责 - 设定沟通频率和时间 - 记录沟通标准 - 规划反馈和双向沟通
NSW 案例：受众（赞助人、交付团队、运营人员、用户）、信息（进度、决策、风险、上线准备）、渠道（会议、仪表盘、简报、支持更新）、节奏（周报、阶段关口、上线更新）。示例规则：紧急安全问题立即通知赞助人和安全负责人；常规进度留在周报里——体现按严重程度分层的升级路径。
2. 管理沟通
按沟通管理计划收集、创建、分发、存储和检索项目信息。
目标：落实沟通计划；确保信息流准确及时；促进协作与反馈；维持干系人参与；处理信息请求和问题。
NSW 案例：
| 沟通需求 | 做法 | 渠道 | 负责人 |
|---|---|---|---|
| 项目进度 | 汇总里程碑、依赖和需要的决策 | 周报 + 项目会议 | PM |
| 试点反馈 | 把可用性问题和支持主题告诉交付团队 | 试点评审 + backlog | 产品负责人 |
| 安全问题 | 说明严重程度、用户影响、应对和责任人 | 受限范围的升级简报 | 安全负责人 |
| 上线准备 | 确认容量、支持安排和用户指引 | 准备会议 + 上线通告 | 推广负责人 |
3. 监控沟通
监测和衡量项目沟通，确保其有效、及时、准确并符合干系人需求，必要时调整。
目标：监测沟通有效性；识别缺口和问题；确保合规与标准；实施纠正措施。
NSW 案例的监控指标（很实用，可直接写进答案）：报告是否按时、决策是否被延误、问题是否被反复提问、升级是否被遗漏；沟通不起作用时调整受众、渠道或时间。
四、IT 项目治理
IT Project Governance：指导、监控和控制 IT 项目的政策、角色、职责、流程和决策结构框架；确保项目与组织目标一致、符合标准、管理风险、交付价值。
四个关键组成：治理结构、流程与政策、角色与职责、工具与报告。
治理结构的三个主要角色
1. Steering Committee（指导委员会 / Project Board）
由高层干系人组成，提供战略指导、监督和决策权。
组成：项目发起人、高级业务代表、IT/技术负责人、财务/PMO 代表、其他干系人。
为什么需要：确保 IT 项目交付真实业务价值；作为升级问题的决策机构；防止范围蔓延或与组织目标脱节。
主要职责： - 批准项目章程和商业论证 - 设定战略目标和成功标准 - 批准重大交付物、变更和范围调整 - 通过报告和仪表盘监控进度 - 解决升级的问题和冲突 - 确保风险管理计划充分 - 确认收益实现（benefits realisation）
2. Project Management Office（PMO）
集中化的组织单元，标准化项目管理实践、提供治理支持、确保项目与业务战略一致；是项目团队、领导层和干系人之间的桥梁。
主要职能：治理支持、绩效监控、培训与辅导、工具与流程管理、风险与问题管理。
角色：PMO 主任、项目控制员/分析师、项目支持专员、方法论/质量专家。
好处：
| 好处 | 说明 |
|---|---|
| Consistency | 标准化流程提高质量和可预测性 |
| Efficiency | 优化资源分配、减少重复工作 |
| Transparency | 向干系人和高管清晰报告 |
| Alignment | 项目与战略目标保持一致 |
| Continuous Improvement | 沉淀经验教训和最佳实践 |
3. Project Sponsor（项目发起人）
高级管理者或干系人，倡导项目、提供资源、对项目成功负最终责任；是项目团队与组织战略领导层之间的纽带。
重要性： - 提供权威：授予 PM 执行计划、获取资源的能力 - 确保对齐：让项目紧扣业务战略 - 支持风险管理：帮助处理超出 PM 权限范围的组织或战略风险
三者对比（易混）： - Sponsor：一个人，对单个项目负最终责任，出钱、给权、扫清组织障碍 - Steering Committee：一组高层，对重大决策集体拍板，处理升级 - PMO：常设部门，跨项目地提供标准、方法、工具和监控
治理机制
指导、监控和控制 IT 项目的结构化方法和实践。
目标： - 确保决策由正确的人在正确的层级做出 - 定义关键问题的升级路径 - 明确定义角色、职责和权限 - 监控风险、执行政策、确保符合标准和法规
常见机制：
| 机制 | 作用 |
|---|---|
| Steering Committee | 战略指导、批准重大变更、监控绩效 |
| PMO | 标准化流程、监控 KPI、支持 PM、确保方法论遵从 |
| Project Sponsor | 倡导项目、批准预算、解决升级问题 |
| Stage-Gate / Phase-Gate reviews | 在关键里程碑设正式检查点，批准进展、交付物和资源分配 |
| 绩效报告与仪表盘 | 预算、进度、范围、风险、质量指标的可见性 |
| 风险与问题升级程序 | 定义风险和问题如何报告、评估、解决 |
| 决策框架 | 谁能在什么情况下做什么决定（决策权限） |
| 审计与评审 | 独立检查合规、质量和与治理标准的一致性 |
📝 Question Bank Q5（阶段关口发现成本超预算 25% 且关键供应商退出，团队以「已完成的工作会被浪费」为由要求继续）——这就是 Phase-Gate 的作用：关口决策应基于剩余成本与剩余收益，已投入的是 sunk cost（沉没成本），不应影响「是否继续」的判断。
常见治理挑战
| 挑战 | 后果 |
|---|---|
| 决策和问责模糊 | 混乱、延误、互相推诿；关键决策被拖延，干系人不知道找谁审批 |
| 关键干系人没有充分参与或知情 | 交付物与业务目标脱节；IT 系统采用率低 |
| 项目信息不及时、不准确、不清晰 | 团队误解需求；干系人不知道风险和进展 |
| 执行时没有与组织目标明确对齐 | IT 投资未能交付预期业务价值 |
| 治理流程没有主动监控或升级风险 | 问题在无人注意中升级，导致延误或失败 |
| 团队或干系人抵制治理流程或决策 | 延误、合规降低、采用率低 |
最佳实践
- 在项目开始时就明确定义治理机制
- 把治理融入日常运作，而非当作独立活动
- 确保所有决策和审批透明并有记录
- 用工具和仪表盘自动化跟踪和报告
- 按项目规模和复杂度调整——小项目需要更轻量的治理
Menti 题：项目进度落后，开发者说优先级不断变化，业务方说很少收到更新——作为项目领导者第一步做什么？ 参考思路（自拟）：建立统一的优先级决策机制 + 固定沟通节奏，例如「召开干系人优先级对齐会议」——两个症状分别指向治理（谁决定优先级）和沟通（没有定期更新）。
五、IT 项目中的对齐
Alignment：确保 IT 项目的目标、活动和成果与更广泛的业务战略、干系人期望和组织优先级和谐一致。
对齐的四个维度
| 维度 | 含义 |
|---|---|
| Strategic Alignment | 项目支持组织的长期目标、使命和愿景 |
| Business-IT Alignment | IT 方案交付真实业务价值，而不只是技术产出 |
| Stakeholder Alignment | 高管、终端用户、客户和监管方的期望被妥善管理和满足 |
| Team Alignment | 团队对目标、角色和优先级有共同理解 |
为什么对齐重要
最大化业务价值；减少无用功（避免开发对业务没用的功能）；提高干系人满意度；改进决策（按战略契合度排列项目和资源优先级）；提升采用率（符合用户需求和工作流的系统更容易被接受）。
五个对齐框架
| 框架 | 提出者/来源 | 用途 |
|---|---|---|
| SAM（Strategic Alignment Model） | Henderson & Venkatraman | 业务战略与 IT 战略对齐最常被引用的框架 |
| Balanced Scorecard（BSC） | Kaplan & Norton | 把项目活动与战略目标挂钩的绩效衡量框架 |
| COBIT | ISACA | IT 治理与管理框架 |
| ITIL | — | IT 服务管理最佳实践（Week 11–12） |
| TOGAF | The Open Group | 企业架构框架，让 IT 架构与业务战略对齐 |
Strategic Alignment Model（SAM）
两个维度：
| 维度 | 内容 |
|---|---|
| Strategic Fit（战略契合，纵向） | 外部：业务环境 & IT 环境（战略层）；内部：组织结构 & IT 基础设施（基础设施层） |
| Functional Integration（功能整合，横向） | 业务战略 ↔︎ IT 战略；业务基础设施 ↔︎ IT 基础设施 |
四个域（2 × 2）：
| Business（业务） | IT | |
|---|---|---|
| External / Strategy | ① Business Strategy：愿景、目标、竞争定位、市场方式 | ② IT Strategy：IT 如何支撑或驱动业务战略（技术范围、IT 治理、能力） |
| Internal / Infrastructure | ③ Organisational Infrastructure & Processes：结构、角色、决策流程、能力 | ④ IT Infrastructure & Processes：硬件、软件、网络、应用、IT 能力 |
答题套路：SAM 题通常问「哪几个域之间断了，怎么修」——找出哪两个格子之间的连线没对上（例如 IT 战略追求「迁移速度」而业务战略要「客户体验和合规」→ ①↔︎② 断了）。
为什么 SAM 重要：确保 IT 项目与业务价值直接挂钩；帮助避免错位；为 IT 与业务高管之间提供沟通框架。
Balanced Scorecard（BSC）
传统指标（利润、ROI）只衡量过去；BSC 把财务 + 非财务指标整合起来，跟踪战略是否真正被执行。
| 视角 | 问题 | 指标 | IT 例子 |
|---|---|---|---|
| Financial | 「股东怎么看我们？」 | 收入增长、ROI、成本节约、盈利 | ERP 是否降低了运营成本？ |
| Customer | 「客户怎么看我们？」 | 满意度、留存、获客、服务质量 | 新 App 是否提升了客户体验评分？ |
| Internal Business Process | 「我们必须擅长什么？」 | 效率、质量、创新、交付时间 | DevOps 流水线是否缩短了发布周期？ |
| Learning & Growth | 「我们能持续改进、创造价值吗？」 | 员工技能、知识管理、IT 能力、文化 | 云工具培训是否提升了生产率？ |
记忆：财务 = 股东，客户 = 客户，内部流程 = 擅长什么，学习成长 = 能否持续。考试常让你为某项目各写一个指标——每个视角写一个可衡量的指标即可（见第七章 HealthPlus 的参考答案）。
敏捷：与价值流对齐
Value stream：组织为向客户交付价值（产品或服务）而进行的一系列活动；关注端到端的价值交付，而不是部门孤岛的产出。
| 类型 | 含义 |
|---|---|
| Operational Value Streams | 业务如何向终端客户交付价值（客户支持、产品交付） |
| Development Value Streams | 组织如何开发支撑运营价值流的系统和软件 |
六、整合：领导力 + 治理 + 对齐
| 支柱 | 作用 | 缺失时 |
|---|---|---|
| Leadership — 人与方向 | 设定愿景、激励团队、管理变革 | 士气低、沟通差、期望管理不善 |
| Governance — 监督与问责 | 定义角色、职责、结构和决策机制 | 范围蔓延、问责不清、风险无人管 |
| Alignment — 战略契合与价值交付 | 把项目与业务战略和成果连接起来 | 交付的技术解决不了业务问题 |
三位一体（the triad of success）： - 领导者提供愿景和影响力，治理提供制衡 - 领导者传达业务愿景，让团队的日常工作与之对齐 - 治理框架确保项目组合映射到战略目标 - Leadership drives the people. Governance provides the rules of the game. Alignment ensures everyone plays the right game.
七、课后案例：SmartCampus 项目
大学启动 SmartCampus：新门户（选课、缴费、注册）、时间表与通知 App、用于提升学生留存的数据分析。 - 领导：PM 技术强但不善激励团队、不善与学术人员沟通，沟通崩溃 - 治理：没有指导委员会或决策结构；隐私合规考虑得太晚 - 对齐：IT 追求「酷炫功能」（如游戏化），不支持提升学生留存的战略 - 结果：18 个月后超预算、落后、学生觉得门户难用，领导质疑其价值
参考要点（自拟）：
| 问题 | 要点 |
|---|---|
| 更有效的领导风格 | 变革型 / 自适应：清晰传达「提升留存」的愿景，主动与学术人员沟通，按情境切换风格 |
| 应有的治理结构 | 指导委员会（学术、学生服务、IT、隐私/法务代表）；积极的发起人；阶段关口；隐私合规作为早期关口；明确的决策权限和升级路径 |
| 如何错位 | IT 战略（功能炫技）与业务战略（留存）脱节——SAM 的 ①↔︎② 断裂；分析模块应优先于游戏化 |
| 相互强化 | 没有治理 → 没有地方纠正错位；领导弱 → 无法把愿景传给团队、也无法推动治理；错位 → 成果无人用 → 进一步削弱领导的信誉 |
| 最主要因素 | 可论证为治理缺失（它让领导和对齐问题都无法被及时发现和纠正）；也可论证对齐（方向错了做得再好也没价值）——关键是给出理由 |
八、Tutorial（Week 9）：CityCare 预约系统采购
本周 tutorial 是 Week 8 采购管理的练习。
背景：CityCare 在悉尼有 5 家诊所，计划 4 个月内上线在线预约系统，预算 $180,000。需要：开发与集成、云托管与部署、独立网络安全测试、20 台标准平板。内部有 2 名熟悉现有系统的开发者，但云部署和安全测试经验有限，且要兼顾日常运维。CityCare 希望保留对患者数据的控制、避免过度依赖单一供应商。
Activity 1-1：Make-or-Buy
| 组件 | 建议 | 理由 |
|---|---|---|
| 预约系统开发 | 外包 | 内部开发者产能有限；有经验的供应商有助于赶上 4 个月期限；CityCare 保留需求和验收决策权 |
| 系统集成 | 内部负责 + 与供应商协作 | 内部开发者熟悉现有患者管理系统；有助于控制敏感数据、降低供应商依赖；需仔细规划其可用时间 |
| 云托管与部署 | 购买托管 + 外包专业部署 | 缺乏云经验；专家配置环境，CityCare 保留访问权限和服务要求的控制 |
| 独立安全测试 | 外包给另一家专业机构 | 专业能力 + 独立性（不能让开发商自己测自己） |
| 20 台标准平板 | 购买 | 标准品，可按规格、价格、保修、交期比较 |
降低供应商依赖：要求文档、知识转移、适当的源代码和配置访问权、清晰的交接安排。
Activity 1-2：RFP 还是 RFQ？
| 采购 | 文件 | 理由 |
|---|---|---|
| 预约系统开发 | RFP | 需要比较方案、集成方法、经验、交付计划和成本 |
| 20 台平板 | RFQ | 能明确数量、技术规格、保修和交期，比较同等产品的报价 |
Activity 1-3：SOW 示例（预约系统开发）
| 要素 | 示例 |
|---|---|
| 范围 | 开发允许患者预约、接收提醒、查看预约详情的系统；与 CityCare 开发者协作连接现有患者管理系统 |
| 交付物 | 配置好的应用、集成接口、测试结果、源代码、技术文档、员工培训材料 |
| 截止日期 | 第 3 个月末交付可测试系统，留第 4 个月做验收测试、修正和部署 |
| 验收标准 1 | 所有约定的关键预约和集成测试用例通过，包括创建预约、显示正确详情、防止重复预约 |
| 验收标准 2 | 在约定测试集中，至少 99% 的提醒在计划时间后 5 分钟内送达指定测试接收者 |
验收标准必须可衡量——「系统要稳定」不行，「99% 在 5 分钟内送达」才行。
Activity 1-4：合同选择
推荐 Firm Fixed-Price——前提是先商定清晰的范围和可衡量的验收标准： - 在有限预算内价格可预测 - 卖方通常承担低估工作量的成本 - CityCare 仍需承担自身延误、需求不清和批准的范围变更带来的风险 - 付款与已验收的里程碑挂钩，配合正式变更流程
替代：如果集成需求仍不确定，可以用 T&M——但需要支出上限、定期评审和工作审批来控制额外成本风险。
Activity 2 Part A：供应商加权评分
| 标准 | 权重 | Vendor A | Vendor B | Vendor C |
|---|---|---|---|---|
| 技术能力 | 0.30 | 4 → 1.20 | 5 → 1.50 | 3 → 0.90 |
| 医疗行业经验 | 0.25 | 3 → 0.75 | 5 → 1.25 | 3 → 0.75 |
| 按期交付能力 | 0.25 | 4 → 1.00 | 3 → 0.75 | 5 → 1.25 |
| 成本（分高 = 更划算） | 0.20 | 5 → 1.00 | 2 → 0.40 | 4 → 0.80 |
| 总分（满分 5） | 1.00 | 3.95 | 3.90 | 3.70 |
| 排名 | 1 | 2 | 3 |
推荐 Vendor A——成本、技术能力和按期交付的综合最强。 权衡：医疗经验不如 B → 应核查推荐人，确认 A 理解临床工作流和集成要求。 A 与 B 只差 0.05——授予合同前应核实评分依据，实际报价也必须在预算内。
为什么先查必须项？ 必须项是 pass/fail 条件，低价或高技术分无法弥补安全或数据处理上的不合格；先筛合格者，再加权比较。
Activity 2 Part B：控制采购
合同授予 6 周后，供应商报告延期两周；演示中提醒功能时有失败；供应商要求支付下一笔里程碑款（合同规定付款以测试通过和正式验收为条件）；CityCare 又提出合同外的多语言功能。
Q4 如何回应延期和提醒失败： - 索取证据：更新的进度表、未完成工作明细、提醒测试结果、原因说明 - 评估影响：对集成、安全测试和 4 个月上线期限的影响 - 商定纠正措施：要求有责任人和期限的恢复计划，包括修复并重测提醒功能 - 监控进展：定期复审交付和纠正措施 - 升级：项目层面解决不了时，让双方有权决策的人介入 - 合同里程碑的任何调整走正式变更控制；恢复计划要包含必要的质量检查
Q5 是否批准里程碑付款？ 不批准。付款以测试通过和正式验收为前提，条件尚未满足。应记录未达标的标准、书面通知供应商、安排修正后重测；满足合同条件后再付款。
Q6 多语言功能如何处理？ 这是范围变更，走正式变更控制： 1. 记录所需语言、功能和业务理由 2. 评估对成本、进度、测试和支持的影响 3. 考虑选项，包括推迟到首次上线之后 4. 由 CityCare 有权决策的人批准 5. 开工前更新合同、SOW、进度和验收标准
关键区分：多语言 = 新需求（范围变更，可能要额外付费）；修复提醒缺陷 = 已在范围内的要求（供应商自己的责任，不应额外付费）。
Q7 三个供应商绩效指标 + 一个应急措施：
| 指标 | 目标示例 |
|---|---|
| 里程碑准时率 | 剩余所有合同里程碑按约定日期完成，每周复审 |
| 提醒可靠性 | 验收测试中至少 99% 的提醒在约定时间窗口内送达 |
| 关键缺陷解决 | 最终验收时无未解决的关键缺陷；每周复审缺陷和重测结果 |
应急措施：识别备用供应商，在恢复计划失败时接手剩余工作的一部分；保持最新文档和对代码、配置的访问以支持交接；启用前评估额外成本和过渡时间。
九、本周考点速记 / 易错点
- 考试：4 题 × 15 分 = 60 分；2 小时 + 10 分钟阅读；双面 cheat sheet；阅读材料和客座讲座不直接考。
- Leadership（人/愿景/长期）vs Management（任务/流程/短期）；Leader 面向未来、Manager 面向当下。
- 五种领导风格及风险：变革型（忽视细节）、交易型（扼杀创造力）、独裁（士气低）、放任（新手团队会混乱）、自适应（需要高超的切换技巧）。
- 沟通管理三过程：Plan → Manage → Monitor；「正确的信息、正确的时间、正确的格式、正确的人」。
- 治理三角色：Sponsor（一个人、最终负责、给权给钱）、Steering Committee（高层集体决策、批章程、处理升级、确认收益实现）、PMO（常设、跨项目标准化）。
- 治理机制：阶段关口、绩效仪表盘、升级程序、决策框架（谁能决定什么）、审计。
- 小项目用轻量治理；治理要融入日常。
- 对齐四维度：战略、业务-IT、干系人、团队。
- SAM 四域：业务战略 / IT 战略 / 组织基础设施与流程 / IT 基础设施与流程；两维度 = 战略契合 + 功能整合。
- BSC 四视角：财务（股东）、客户、内部流程（擅长什么）、学习与成长（持续改进）。
- 五个框架：SAM、BSC、COBIT（IT 治理，ISACA）、ITIL（服务管理）、TOGAF（企业架构）。
- 价值流：运营价值流 vs 开发价值流。
- Tutorial 计算：加权评分
；先查必须项再加权；付款以验收为前提；新功能 = 范围变更，修缺陷 ≠ 范围变更。
十、本讲与前后的衔接
| Week | 内容 | 关键词 |
|---|---|---|
| 6 | 资源管理 | 领导风格初版、激励（本周扩展） |
| 8 | 采购管理 | 合同、加权评分（本周 tutorial） |
| 9 | 领导力、治理与对齐 | 指导委员会、PMO、发起人、SAM、BSC |
| 10 | 整合管理 | 变更控制委员会（CCB）、整合变更控制；tutorial 做本周的 HealthPlus 案例 |
| 11–12 | ITSM / ITIL | ITIL 也是对齐框架之一；ITIL 4 SVS 中的 Governance 组件 |
本周是后半学期的「枢纽」：Week 10 的整合管理需要治理结构（谁批准变更），Week 11–12 的 ITIL 把「对齐」和「治理」从项目层面延伸到持续的服务层面。