2025年PMP 学习七 -第5章 项目范围管理
5.4 创建 WBS
1.定义与作用
| 定义 | 把项目可交付成果和项目工作分解成较小的，更易于管理的组件 |
|---|---|
| 作用 | 对所要交付的内容提供一个结构化的视图 |
2.输入，输出，工具与技术
3. 创建WBS的依据（输入）
-
项目管理计划：创建WBS中使用的项目管理计划是范围管理计划。范围管理计划定义了如何根据项目范围说明书创建WBS。
-
项目文件：主要包括：
- 需求文件：详细描述了各单一需求如何满足项目的业务需求。
- 项目范围说明书：描述了需求满足的工作以及不包含在项目中的工作。
-
事例环境因素：会影响创建WBS过程的行业标准，包括项目所所在行业的WBS标准，这些标准可以作为创建WBS的外部参考资料。
-
组织过程资产：能够影响创建WBS过程的组织过程资产主要包括：用于创建WBS的政策、程序和模板；以及项目的项目档案；以往项目的经验教训等。
4. 分解（工具与技术）
WBS的分解方法、流程：
- 识别和分析可交付成果及相关工作
- 确定WBS的结构和编排方法
- 自上而下逐层细化分解
- 为WBS组件制定和分配标识编码
- 核实可交付成果分解的程度是否合理
5 WBS
- 对于项目团队为实现项目目标，创建所有可交付成果而需要实施的全部工作范围的层级分解；
- 工作分解结构每向下分解一层，代表着对项目工作更详细的定义；
- 是后续管理工作的主要依据，是项目时间、成本、人员等管理工作基础；
- 两种表现形式：树形结构、列表形式。
WBS 知识扩展 -1
重要的知识
WBS 知识扩展 -2
6. WBS分解注意事项
- WBS必须是面向可交付成果的：项目的目标是提供产品或服务，WBS中的各项工作是为交付可交付成果的活动；
- WBS必须符合项目的范围：WBS必须包括包括了完成项目的可交付成果的活动；（100%原则）
- WBS的层次应支持计划与控制：WBS底层不但要支持项目管理计划，而且要求让管理层能够监督和控制项目的进度和预算；
- WBS中的元素必须有责任人，而且只能有一个负责人；
- WBS应控制在4~6层；
- WBS应包括项目管理工作，也包括分包出去的工作；
- WBS的编制需要所有（主要）项目成员的参与；
- WBS并非一成不变：在完成了WBS之后的工作中，仍然有可能需要对WBS进行修改。
7. 范围基准（输出）
- 批准的范围说明书、工作分解结构（WBS）和相关的WBS词典；
- 项目范围说明书：包括对项目范围、主要可交付成果、假设条件和制约因素的描述。
- WBS：对项目团队为实现项目目标，创建所有需交付成果而需要实施的全部工作范围的层级分解。工作分解结构向下分解一层，代表着对项目工作更详细的定义；
- 工作分解结构：
- WBS的最低层是带有特标识符的工作项；
- 规划包：一种在项目控制阶段高层工作任务的工作分解结构组件，工作内容已知，但详细的进度活动未知；一个控制账户可以包含一个或多个规划包。
- WBS词典：包括以编制标识符、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量标准、验收标准、技术参考文献、协作信息。
WBS 词典
| 项目名称： | 准备日期： | ||
|---|---|---|---|
| 工作包名称： | WBS编号： | ||
| 工作描述： | |||
| 理程碑： | 到期日： | ||
| 1. | |||
| 2. | |||
| 3. |
| 编号 | 活动 | 资源 | 小时 | 单价 | 合计 | 数量 | 物资 | 成本 | 合计 | 总成本 |
|---|---|---|---|---|---|---|---|---|---|---|
质量要求：
修改要求：
技术信息：
合同信息：
5.5 确认范围
1. 定义与作用
| 定义 | 正式验收已完成的项目可交付成果 |
|---|---|
| 作用 | 1. 使验收过程具有可观察性； 2. 通过确认每个可交付成果来确保最终产品、服务或成果获得验收的可能性。 |
2. 确认范围 vs 控制质量
| 确认范围 | 关注可交付成果的验收（客户确认） |
|---|---|
| 控制质量 | 关注可交付成果的准确性，是否满足质量要求（团队确认） |
3. 确认范围的步骤
- 确定需要进行范围确认的时间；
- 识别范围确认需要哪些投入；
- 确定范围正式接受的标准和要求；
- 确定范围确认会议的组织步骤；
- 组织范围确认会议。
4.输入，输出，工具与技术
5. 确认范围的依据（输入）
-
项目管理计划：
- 范围管理计划：定义了如何正确验收已经完成的可交付成果。
- 需求管理计划：描述了如何确认项目需求。
- 范围基准：用范围基准与实际结果对比，以决定是否有必要进行变更，采取纠正措施或预防措施。
-
项目文件：
- 需求文件：将需求与实际结果进行对比，以决定是否有必要进行变更，采取纠正措施或预防措施。
- 需求跟踪矩阵：包含与需求相关的信息，包括如何确认需求。
- 质量报告：该报告内容包括由团队管理或质量管理部门的全部质量保证项目、改进建议，以及在控制质量过程中发现的情况。
-
经验教训记录：在项目早期阶段的经验教训，可以为验收可交付成果的效率与效果提供帮助。
-
工作绩效数据：工作绩效数据可能包括符合需求的过程度、不一致的数量、以及在某些时间段内开发展现的次次数。
-
核实的可交付成果：核实的可交付成果是指已完成，并按照质量要求过程检查为正确的可交付成果。
6. 检查（工具与技术）
- 可交付成果是否是确定的、可确认的；
- 每个可交付成果是否有明确的里程碑；
- 是否有明确的质量标准；
- 审核和确认是否有清晰的表述；
- 项目范围是否覆盖了完成产品或服务的所有活动；
- 项目范围的风险是否太高，是否能够降低可预见风险对项目的冲击。
7. 干系人关注点
| 干系人 | 关注点 |
|---|---|
| 管理层 | 范围对项目的进度、资金和资源的影响。 |
| 客户 | 产品范围，项目的可交付成果是否完成产品或服务。 |
| 项目管理人员 | 可交付成果是否足够修订和必须完成，时间、资金和资源是否足够。 |
| 项目团队成员 | 项目范围中自己参与的元素和负责的元素。 |
8. 验收的可交付成果（输出）
- 由客户或发起人正式签字/批准的符合验收标准的可交付成果；
- 应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。
9. 变更请求（输出）
- 对于已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应记录在案。
- 可能需要针对此些可交付成果提出变更请求，开展相应的缺陷补救工作。
5.6 控制范围
1. 定义与作用
| 定义 | 监控项目和产品的范围状态，管理范围基准变更的过程。 |
|---|---|
| 作用 | 在整个项目期间保持对范围基准的维护。 |
2.输入，输出，工具与技术
3. 控制范围的依据（输入）
-
项目管理计划：
- 范围管理计划：记录了如何控制项目和产品范围。
- 需求管理计划：记录了如何管理项目需求。
- 变更管理计划：定义了如何管理项目变更的过程。
- 配置管理计划：定义了哪些配置项需要正式变更控制，以及针对这些配置项的变更控制过程。
- 范围基准：用范围基准与实际结果对比，以决定是否有必要进行变更，采取纠正措施或预防措施。
- 绩效测量基准：使用绩效测量基准与实际结果对比，以决定是否有必要进行变更，采取纠正措施或预防措施。
-
项目文件：
- 需求文件：用于开发任何对商定的项目或产品范围的偏离。
- 需求跟踪矩阵：有助于跟踪任何可变更或变更范围基准的任何偏离对项目目标的影响，它还可以提供受控需求的状态。
- 经验教训记录：项目早期的经验教训可以运用到后期阶段，以提高验收可交付成果的效率与效果。
-
工作绩效数据：包括收到的变更请求的数量，接受或拒绝的变更请求的数量或核心复杂度，确认和完成的可交付成果的数量。
-
组织过程资产：能够影响控制范围过程的组织过程资产主要包括：现有的、正式的和非正式的与范围控制相关的政策、程序和指针；可用于监控和报告的方法与模板等。
4. 数据分析（工具与技术）
- 偏差分析：用于将基准与实际结果进行比较，以确定偏差是否处于临界区间内或是否需要采取纠正或预防措施。
- 趋势分析：旨在审查项目在持续时间中的变化情况，以判断持续效应是正在改善还是在恶化。
- 确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。
5. 范围蔓延 VS 镀金
真题
- 在项目实施期间，一些团队成员抱怨说他们对项目可交付成果不确定。若要确保项目团队按照项目范围工作，项目经理应该怎么做？ D
A. 审查执行、责任、咨询和知情（RACI）矩阵。
B. 更新沟通管理计划，澄清期望。
C. 与团队分享项目进程。
D. 将工作分解结构（WBS）分发给团队。
- 新的软件产品的实施阶段已基本完成，下一阶段是测试和实施。项目提前进度2周，在进入最后阶段前，项目经理最应该关注（）。A
A. 确认范围
B. 质量控制
C. 业务报告
D. 成本控制
