INFO6007 Week 01 Introduction 讲课总结

INFO6007 Week 01 讲课总结：Introduction

课程：INFO6007 — Project Management in IT，Semester 2 2026 讲义：Lecture - INFO6007 Week 01 - Introduction.pdf（56 页） 参考：Watt, A. Project Management (2nd ed.)；Schwalbe, K. IT Project Management (9th ed.)

第一讲一半是课务，一半是概念。概念部分的核心是 三重约束（Triple Constraint） 和 项目 / 项目集 / 项目组合三层管理。

⚠️ Week 1 没有 tutorial（tutorial 从 Week 2 才开始）。本讲的配套练习在 Week 02 Tutorial 里 —— 那份答案文档开头就写着 "Drawing from Week 1 lecture"。

---

一、课务信息

上课安排

项目	安排
Lecture	每周四 19:00–21:00，面授 + Zoom 直播（须用学校账号登录）；录播 24 小时内上 Canvas
Tutorial	必须选课；周二至周五，从 Week 2 开始；面授；务必出席 —— Week 6–12 有每周进度评估
Consultation	每两周一次，从 Week 2 起，周四 10:00–11:00（Zoom）

平台

• Canvas —— 录播、讲义、tutorial slides、作业规格、每周阅读、公告、提交入口与评分标准
• Ed Forum —— 与同学交流、向 tutor/TA/教授提问；公告也会发在 Ed 上
• 课程邮箱：info6007@sydney.edu.au

课程期望

• 除课堂外每周投入约 6–9 小时
• 课前读完每周阅读材料（讲义强调这样才能对课程脉络有透彻理解）
• 每周至少查一次 Canvas；每天至少查一次 Ed Forum
• 遇到困难及时告知教师；也要诚实、及时地告知队友

---

二、考核结构（务必记清）

考核	权重	说明
Early Semester Feedback Task (EFT)	5%	选择题 / 判断题，Canvas 开卷；考纲为 Week 1–3；Week 4 进行
Weekly progress evaluation	10%	在 tutorial 中进行；基于 GitHub 项目看板与项目报告进度；Week 6–12 共 7 次，取最好 5 次
Group Assignment	25%	4–5 人小组，必须在同一 tutorial 内组队；Week 13 提交小组报告
Final Exam	60%	限制性开卷：允许一张 A4 cheat sheet（双面，手写或打印均可）；案例分析题

合计 = 100% ✅

weekly progress 取 7 次中最好 5 次 ⇒ 可以丢 2 次。但既然它绑定 tutorial 出勤，能不丢就别丢。

Hurdle Requirement（及格门槛）

必须同时满足两个条件： ① 笔试至少 40% 且 ② 总评至少 50 分

⚠️⚠️ 未达门槛者，无论平时平均分多高，最终成绩最高只记 45 分。

笔试	总评	结果
35%	60	⚠️ 不通过 —— 最终记 45
45%	48	⚠️ 不通过 —— 最终记 45
45%	55	✅ 通过
40%	50	✅ 通过（刚好压线）

第一行最值得警惕：总评 60 分看起来很安全，但笔试只有 35% 就直接被降到 45 分。 期末考占 60% 且有 40% 的独立门槛 —— 平时分补不了笔试的窟窿。

其他

• Best Project Certificates —— 授予在项目质量、概念应用和团队协作上表现突出的小组
• Guest Lecturer —— 业界专业人士授课。讲义提到：往届曾有学生通过客座讲座获得暑期实习，后转为兼职工作。⚠️ 场次信息只在 Ed Discussion 公布

---

三、什么是项目

PMBOK 定义

"A project is a temporary effort/work undertaken to create a unique product, service, or result." —— PMBOK® Guide, 6th Edition (2017), p. 4

项目的四个关键特征

特征	含义
Temporary（临时性）	有明确的起点和终点；不是持续运营（ongoing operation）
Unique outcome（独特性）	目标是产出新东西 —— 产品、服务、活动等
Specific objectives（特定目标）	满足特定目标或要求、解决某个问题
Constraints（约束）	在范围、时间、成本、资源的限制下工作

「临时性」是最容易被考的一条：项目有终点，运营没有。 「维护公司的邮件系统」是运营；「把公司邮件迁移到 Microsoft 365」是项目。

IT 项目的六个例子

软件开发、系统集成、基础设施升级、网络安全项目、数据与分析、网站/应用。

---

四、IT 项目为什么天生难做

IT 项目是以技术为核心、旨在交付数字化解决方案、系统或服务的举措。 IT 项目运行在充满不确定性和变化的环境中。

四个根本原因

原因	说明
需求会演进	组织是在过程中才逐渐搞清楚「什么是可能的」
产出往往无形，前期难以定义	这是 IT 相对于建筑等行业最本质的差异
与既有系统集成带来隐性复杂度	—— 后续几乎每一周的讲义都会重提这一条
必须在信息不全时做决策	不能等所有信息齐了再动

讲义给出的结论很值得记： 「成功的 IT 项目不仅依赖技术能力，更依赖专业判断和适应能力。」

六种常见失败模式

模式	说明
需求不稳定或理解不清	volatile or poorly understood requirements
低估集成与依赖的复杂度	这条在 Week 4 成本管理里以「最高频估算错误」的身份再次出现
成本与进度估算中的乐观偏差	optimism bias
业务团队与技术团队错位	misalignment
治理薄弱、决策权不清	weak governance, unclear decision rights
交付过程中干系人参与有限	limited stakeholder involvement

讲义的点睛之笔： 「这些问题很少是单纯由技术造成的。」（These issues are rarely caused by technology alone.）

---

五、项目管理

PMBOK 定义

"the application of knowledge, skills, tools, and techniques to project activities to meet project requirements." —— PMBOK® Guide, 6th Edition (2017), p. 10

项目管理的七个关键要素

要素	要回答的问题
Scope（范围）	项目要达成什么？交付物是什么？
Time（时间）	要花多久？截止日期是什么？
Cost（成本）	预算多少？需要什么资源？
Quality（质量）	产出是否达到要求的标准？
Risk（风险）	什么可能出错？如何缓解？
Communication（沟通）	信息如何在干系人之间共享？
Resources（资源）	需要什么人、工具和技术？

这七个要素几乎就是本课程的周次大纲：Week 3 范围+时间、Week 4 成本、Week 5 质量、Week 6 资源，后面还有风险与沟通。

没有项目管理会怎样

范围蔓延（Scope Creep）、沟通不畅、错过截止日期、预算爆炸、技术失败、干系人不满。

项目经理需要的技能

类别	技能
核心 PM 技能	规划与排程、范围管理、风险管理、预算与成本控制、质量管理、文档与报告
软技能	沟通、领导力、冲突解决、谈判、决策、适应力
技术技能	理解 PM 方法论；工具如 Jira、Trello、Asana；报告
战略技能	干系人管理、商业敏感度、变革管理
💡 加分特质	既注重细节又有大局观、压力下保持冷静、主动解决问题、有同理心的团队领导者

---

六、三重约束（Triple Constraint）

三重约束指定义并塑造任何项目的三个关键因素。

约束	内容	变化的影响
Scope（范围）	完成项目所需的工作；功能、职能、任务、交付物	范围变化（即 scope creep）会影响时间和成本
Time（时间）	项目的进度或工期；截止日、里程碑、时间线	延期通常意味着成本增加或范围缩减
Cost（成本）	完成项目的预算；资源、人力、工具、软件、基础设施	超预算可能需要缩减范围或延长工期

三条传导规则（必背，Week 2 tutorial 直接考）

变化	后果
范围增加	时间和/或成本通常会增加
时间缩短	成本可能增加、范围可能减少，或交付必须变得更高效
预算削减	范围可能减少、时间可能延长，或质量/风险受到影响

注意第三条的措辞里出现了「质量」，而前两条没有。 这暗示了一个贯穿全课程的要点：质量不在三角形的三条边上，但它往往是被挤压时的隐藏泄压口。 当范围、时间、成本三者都被锁死时，唯一能「悄悄」让步的就是质量 —— 这正是 Week 05 质量管理里「Time vs Quality」权衡讨论的起点。

---

七、项目成功

「成功不再只是『按时、按预算』，还包括交付价值。」

成功的多个维度

Time	Cost	Scope
Quality	Stakeholder Satisfaction	Business Value
Team Performance	Sustainability	User adoption and satisfaction
Alignment with strategic goals	Long term operational impact	Risk management and flexibility

三个关于成功的常见误解

误解	为什么错
「按时按预算完成 = 成功」	如果产品不可用或没有价值，那就不是成功
「达成业务目标就够了」	忽视团队士气或干系人意见会造成长期损害
「所有成功都是即时可见的」	有些项目的影响只在长期才显现（尤其 IT、研发、转型类项目）

第一条误解是全课程反复出现的主题： - Week 4 说「按时但超预算的项目在干系人眼里同样是失败」 - Week 5 的 Hershey's ERP 案例 —— 项目「完成」了却仍被视为失败 - Week 5 的选课系统讨论题 —— 所有测试都通过了，上线却崩溃

三次从不同角度攻击同一个误解，说明这是本课程的核心观点之一。

---

八、三层管理：项目 / 项目集 / 项目组合

Project Management → Program Management → Portfolio Management 这三层代表在组织中管理工作时递增的战略监督与协调层级。

	Project（项目）	Program（项目集）	Portfolio（项目组合）
定义	交付一个具体产出（产品/服务）	一组相关项目，被协调管理以获得单独管理无法实现的收益	一组项目集和项目，为达成战略业务目标而分组
管理者	Project Manager	Program Manager	Portfolio Manager 或 PMO
关注点	既定的范围、时间、预算（三重约束）	相互依赖、风险、战略对齐	投资决策、资源分配、战略优先级排序
核心目标	交付一个成功的项目	跨多个项目交付业务价值	最大化价值并与组织战略对齐
层级	战术执行	战略协调	企业级对齐
例子	上线新网站、开发手机 App	数字化转型项目集、HealthTech 系统推广	IT 组合（网络安全 + 云 + AI + 生产力工具）、产品组合

区分三者的关键在「目标」那一行： - 项目问「这件事做成了吗？」 - 项目集问「这几件事合起来产生了业务价值吗？」 —— 重点是「单独管理无法实现的收益」 - 项目组合问「我们该不该做这些事？」 —— 它是唯一会「砍项目」的层级

---

九、项目管理框架

Project Management Framework 是定义项目如何被规划、执行、监控和完成的结构化方法，提供指南、流程、工具和最佳实践。

四个核心组成

• Project Lifecycle（项目生命周期）
• Processes and Knowledge Areas（过程与知识领域）
• Tools and Templates（工具与模板）
• Methodologies within the framework（框架内的方法论）

为什么要用框架

• 保证跨项目的一致性
• 降低风险、提高可预测性
• 改善沟通与问责
• 用结构化流程支持决策
• 与组织目标和标准对齐

---

十、课后思考题与案例

⚠️ 讲义给的 5 道题（注意有一道超纲）

1. ⚠️⚠️ 项目生命周期的五个阶段是什么？能简要解释吗？
2. 范围、时间、成本在三重约束中如何相互作用？
3. 项目、项目集、项目组合的区别是什么？
4. 列举三个 IT 项目管理常用工具及其用途。
5. 如果干系人在项目后期提出重大变更，你该采取哪些步骤？

⚠️ 第 1 题在本讲讲义里找不到答案 —— 讲义 p45 把 "Project Lifecycle" 列为框架的核心组成之一，但从未展开讲五个阶段。

答案在 Week 02 讲义 p9（不是阅读材料）：

阶段	目的	输出
Initiation / Defining	在高层次定义项目并评估可行性	项目获批并被正式启动
Planning	建立指导团队的全面计划	获批的项目管理计划
Execution	按计划执行实际工作	交付物被开发和评审
Monitoring & Controlling	跟踪绩效并按需调整	状态报告、更新、纠偏措施
Closure	收尾、交付成果、复盘	最终报告、经验教训、客户签字

💡 第 4 题的答案在讲义 p33：Jira、Trello、Asana。 💡 第 5 题的答案要到 Week 3 才完整：走正式变更控制流程 —— 评估对时间、成本、资源和质量的影响，再批准/推迟/拒绝。

案例：Aurora Tech 的 CRM 项目

背景：Aurora Tech 启动内部 IT 项目，为销售部门构建定制 CRM 系统。 工期 6 个月，预算 $500,000。涉及软件开发、与遗留系统集成、用户培训。

出了什么问题

问题	说明
范围蔓延	销售负责人在执行期间多次要求新功能，且没有走正式变更管理
沟通不畅	开发者与终端用户需求脱节，导致可用性问题
干系人参与不足	销售团队在测试阶段未被纳入，导致返工
低估技术复杂度	与遗留系统的集成造成反复延期

结果

指标	数值
工期	6 个月 → 10 个月，延期 4 个月（超出 66.7%）
成本	超支 40% ⇒ 约 700,000
后果	CRM 系统采用率低，对 IT 部门的信任下降

这个案例的精髓在最后一行： 项目最终「交付」了，但采用率低、信任受损 —— 正好呼应本讲「按时按预算 ≠ 成功」和「用户采纳度是成功维度之一」两个要点。

另外注意四个问题里有三个是「人」的问题（沟通、参与、变更管理），只有一个是技术问题（集成复杂度）—— 这正是讲义那句「这些问题很少是单纯由技术造成的」的实证。

三道案例题的答题方向

问题	方向
主要失败原因？	范围蔓延（无变更控制）为首；其次是干系人参与不足和低估集成复杂度
更好的项目管理实践如何预防？	正式变更控制流程；明确的范围说明书含 exclusions；让销售团队参与 UAT；对遗留系统集成用三点估算而非单点值
该用什么工具或框架？	WBS（把集成拆成独立工作包，暴露真实工作量）；RTM（追溯需求，识别哪些是范围外的）；Jira 看板跟踪；EVM 早期发现偏差

---

十一、考点重点

1. 考核结构：EFT 5% + 每周进度 10% + 小组作业 25% + 期末 60%；每周进度 Week 6–12 取最好 5 次。
2. Hurdle：笔试 ≥ 40% 且 总评 ≥ 50，否则最高只记 45 分。
3. 项目的 PMBOK 定义与四个特征，尤其 临时性（有起终点，不是持续运营）。
4. 项目管理的 PMBOK 定义与七个关键要素。
5. IT 项目难做的四个根本原因，尤其 产出无形、前期难定义。
6. 六种常见失败模式；「这些问题很少是单纯由技术造成的」。
7. 三重约束的定义与三条传导规则（Week 2 tutorial 直接考）。
8. 质量不在三角形上，但它是被挤压时的隐藏泄压口。
9. 项目成功的多维定义；三个误解，尤其「按时按预算 = 成功」是错的。
10. 项目 / 项目集 / 项目组合的对比，重点是三者目标和关注点的差异。
11. ⚠️ 项目生命周期五阶段（讲义未讲，来自阅读材料）：启动 → 规划 → 执行 → 监控 → 收尾。
12. Aurora Tech 案例：超支 40%、延期 4 个月，四个问题中三个是「人」的问题。

---

十二、本讲与后续的衔接

Week	内容	本讲埋下的伏笔
1	导论、三重约束、三层管理	—
2	PM 方法论、需求收集、项目启动	补上本讲未展开的「生命周期五阶段」
3	范围管理 + 进度管理	范围与时间两条边的展开；范围蔓延的正式定义
4	成本管理	成本这条边的展开；「低估集成」在这里成为最高频估算错误
5	质量管理	质量这个「隐藏泄压口」被正式提上台面
6	资源管理（含客座讲座）	七要素中的 Resources

本讲的三重约束是整个课程的骨架： Week 3 讲范围和时间，Week 4 讲成本，Week 5 讲质量 —— 后面四周就是把这个三角形（加质量）逐条拆开细讲。

---

十三、关于 tutorial

⚠️ Week 1 没有 tutorial —— tutorial 从 Week 2 才开始。

本讲的配套练习是 Week 02 Tutorial：三重约束权衡，其答案文档开头明确写着 "Drawing from Week 1 lecture, students will reinforce their understanding of triple constraints"。

这句话也顺带证实了本课程 tutorial 比 lecture 慢一周的固定节奏：

Tutorial	实际练的内容
Week 2	Week 1（三重约束）
Week 3	Week 2（方法论、干系人）
Week 4	Week 3（范围蔓延、WBS、关键路径）
Week 5	Week 4（EVM 计算）