1. 创建工作分解结构WBS

1.1. 自上而下的分解结构

1.2. 把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程

1.3. 用来确定项目范围的

1.3.1. 包括分包出去的工作

1.3.1.1. 【21上选40】

1.4. 输入

1.4.1. 项目范围管理计划

1.4.2. 项目范围说明书

1.4.3. 需求文件

1.4.4. 事业环境因素

1.4.5. 组织过程资产

1.5. 工具与技术

1.5.1. 分解

1.5.1.1. 在层次上保持项目的完整性，避免遗漏必要的组成部分

1.5.1.2. 一个工作单元只能从属于某个上层单元，避免交叉从属

1.5.1.3. 相同层次的工作单元应用相同性质

1.5.1.4. 工作单元应能分开不同的责任者和不同的工作内容

1.5.1.5. 便于项目管理计划和项目控制的需要

1.5.1.6. 最底层工作应该具有可比性，是可管理的，可定量检查的

1.5.1.7. 应包括项目管理工作，包括分包出去的工作

1.5.2. 专家判断

1.6. 输出

1.6.1. 范围基准

1.6.1.1. 【21下选43】

1.6.1.2. 经过批准的范围说明书、工作分解结构(WBS)和相应的WBS词典组成了范围基准

1.6.2. 项目文件更新

1.6.2.1. 更新需求文件

1.7. 项目管理的基础

1.7.1. 项目的所有规划和控制工作都必须基于工作分解结构

1.7.2. 后续管理工作的主要依据

1.7.3. 有助于防止需求和范围蔓延

1.8. 需要所有项目干系人的参与

1.9. 逐层向下分解的

1.9.1. 应控制在3〜6层为宜

1.10. 各要素应该是相对独立的，要尽量减少相互之间的交叉

1.10.1. 【21下选40】

1.11. 一般用图表形式表达

1.11.1. 分级的树型结构

1.11.1.1. 一些小的、适中的应用项目中用得较多

1.11.2. 表格形式

1.11.2.1. 一些大型的、复杂的项目中使用还是较多的

1.12. 里程碑

1.12.1. 某个可交付成果或者阶段的正式完成

1.12.2. 具体时间+在这个时间应完成的事件

1.12.3. 关注事件是否完成

1.13. 最低层的工作单元被称为工作包

1.13.1. 位于工作分解结构每条分支最低层的可交付成果或项目工作组成部分

1.13.2. 8/80规则（80小时原则）建议工作包的大小应该至少需要8个小时来完成，而总完成时间也不应该大于80小时

1.13.3. 分配到一个控制账户

1.13.3.1. 控制账户是一个管理控制点

1.13.3.1.1. 【22上选40】

1.13.3.2. 设置在WBS中选定的管理节点上

1.13.3.3. 可能包括一个或多个工作包

1.13.3.3.1. 【19下选39】

1.13.4. 一个工作包只能属于一个控制账户

1.13.5. 工作分解结构词典

1.13.6. 从逻辑上讲，不能再分了

1.14. WBS编码设计

1.14.1. 任何等级的一位项目要素，是其余全部次一级项目要素的总和

1.14.2. 所有子项目的编码第一位数字是相同的，再下一级的工作单元的编码依此类推

2. 确认范围

2.1. 正式验收已完成的可交付成果

2.2. 正式验收己完成的项目可交付成果的过程

2.3. 控制质量过程通常先于确认范围过程

2.4. 由于范围的确认可以是阶段性的，所以交付物可能是中间交付物。这涉及到系统集成项目的验收问题，即可先分批验收，最后再终验，但是每一次验收都需要客户的书面确认

2.4.1. 【22下选40】

2.5. 使验收过程具有客观性；同时通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性

2.5.1. 【19下选41】

2.6. 确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求

2.6.1. 【21下选41】

2.6.1.1. 【21上选41】

2.7. 应该贯穿项目的始终，从WBS的确认或合同中具体分工界面的确认，到项目验收时范围的检验

2.8. 输入

2.8.1. 项目管理计划

2.8.2. 需求文件

2.8.3. 需求跟踪矩阵

2.8.4. 核实的可交付成果

2.8.5. 工作绩效数据

2.8.5.1. 【22上选42】

2.9. 工具与技术

2.9.1. 检查

2.9.1.1. 【20下选41】

2.9.1.2. 审查、产品审查、审计和巡检

2.9.2. 群体决策技术

2.9.2.1. 【19上选44】

2.10. 输出

2.10.1. 验收的可交付成果

2.10.1.1. 以书面的形式正式签字批准

2.10.1.2. 没有被客户接受的交付物也应当记录下来，同时还要记录未被客户接受的原因

2.10.1.3. 可以是阶段性的

2.10.1.3.1. 可能是中间交付物

2.10.2. 变更请求

2.10.3. 工作绩效信息

2.10.4. 项目文件更新

2.10.5. 【22上选41】

3. 范围控制

3.1. 监督项目和产品的范围状态，管理范围基准变更的过程

3.2. 问题

3.2.1. 未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延

3.2.1.1. 【21上选42】

3.2.2. 得不到投资人的批准

3.2.2.1. 【21下选42】

3.2.2.2. 客户通常只能提出范围变化的要求，但却没有批准的权力

3.2.2.2.1. 【19上选45】

3.2.3. 项目小组未尽责任

3.3. 需求变更及项目范围变更一定要遵循由变更控制委员会制定的变更控制流程

3.3.1. 【19下选42】

3.4. 缺乏沟通有可能导致范围或需求不符合客户要求，有可能导致范围变更

3.4.1. 【22下选41】

3.5. 在整个项目期间保持对范围基准的维护

3.6. 输入

3.6.1. 项目管理计划

3.6.2. 需求文件

3.6.3. 需求跟踪矩

3.6.4. 工作绩效数据

3.6.5. 组织过程资产

3.7. 工具与技术

3.7.1. 偏差分析

3.7.1.1. 一种确定实际绩效与基准的差异程度及原因的技术

3.8. 输出

3.8.1. 工作绩效信息

3.8.2. 变更请求

3.8.3. 项目管理计划更新

学系统集成项目管理工程师（中项）系列17b_范围管理（下）相关推荐

学系统集成项目管理工程师（中项）系列28_后记
1. 回顾 # 学系统集成项目管理工程师(中项)系列字数更新日期 (2023年) 1 01_法律法规 5587 5月17日 2 02_文件和标准 1389 5月13日 3 03_职业道德规范 99 ...
系统集成项目管理工程师计算题（进度管理计算）
本系列文章将会对系统集成项目管理工程师考试中出现的各类计算题进行汇总解析,并给出分析过程,帮助考生备考复习.更多复习内容请在微信搜索小程序 "系统集成项目管理工程师高频考点". 进 ...
学系统集成项目管理工程师（中项）系列03_职业道德规范
1. 职业道德 1.1. 涵盖了从业人员与服务对象.职业与职工.职业与职业之间的关系 1.2. 是所有从业人员在职业活动中应该遵循的行为准则 1.3. 包括爱岗敬业.诚实守信.办事公道.服务群众和奉献 ...
学系统集成项目管理工程师（中项）系列10_立项管理
1. 系统集成项目管理至关重要的一个环节 2. 重点在于是否要启动一个项目,并为其提供相应的预算支持 3. 项目建议 3.1. Request for Proposal, RFP 3.2. 立项申请 ...
学系统集成项目管理工程师（中项）系列22a_信息化知识（上）
1. 战略资源 1.1. 信息 1.2. 土地 1.3. 能源 1.4. 材料 2. 信息information 2.1. 客观事物状态和运动特征的一种普遍形式 2.2. 控制论 2.2.1. 维纳N ...
学系统集成项目管理工程师（中项）系列17a_范围管理（上）
1. 包括确保项目做且只做所需的全部工作,以成功完成项目的各个过程 2. 项目工作明确划定边界 2.1. 什么是包括在项目之内的 2.2. 什么是不包括在项目之内的 3. 项目其他各方面管理的基础 4 ...
学系统集成项目管理工程师（中项）系列15_质量管理
1. 质量(Quality)的定义 1.1. 反应实体满足主体明确和隐含需求的能力的特性总和 1.2. 明确需求是指在标准.规范.图样.技术要求.合同和其他文件中用户明确提出的要求与需要 1.3. 隐 ...
学系统集成项目管理工程师（中项）系列23a_信息系统集成及服务管理（上）
1. 提供的专业信息技术咨询服务.系统集成服务.技术支持服务.运行维护服务等工作 2. 信息技术咨询服务 2.1. 信息系统集成及服务的前端环节 2.2. 为企业提供信息化建设规划和解决方案 3. 原 ...
学系统集成项目管理工程师（中项）系列20_变更管理
1. 许多项目失败的原因就是由于对变更的处理不当 2. 变更管理是为了使项目实际执行情况和项目基准相一致而对项目变更进行管理,其可能的结果是拒绝变更或调整基准 3. 分类 3.1. 性质 3.1.1. ...