第九章 项目范围管理（下）
9.3 定义范围（define scope）
针对需求明确要做哪些事不做哪些事，描述产品、服务、成果的边界和验收标准。
定义范围需要从需求文件中选取最终的项目需求，需要多次反复开展定义范围的过程。
输入：
项目章程（有成功标准和验收标准，高层级描述、产品特征等）、需求文件、项目管理计划、项目文件（需求文件、假设日志）、环境
工具与技术：
产品分析：将高层级产品描述转变为有型的可交付成果，包括产品分解、系统分析、需求分析、系统工程、价值工程、价值分析等。
备选方案分析：制定尽可能多的备选方案。
决策：多标准决策分析
人际关系与团队技能：引导，协调不同专业知识的干系人，达成跨职能的共识。
项目章程英文（project charter）
输出：范围说明书（project scope statement），是对项目范围、主要可交付成果、假设条件和制约因素的描述，作用：记录了整个范围包括项目和产品范围，描述了项目可交付成果，还代表干系人之间就项目范围所达成的共识。为了便于干系人期望，可明确指出哪些工作不属于项目范围内。（背诵）
9.4 创建WBS
项目范围说明书，文件内容不直观，但图表达更为直观。将文字转化为WBS图表。
WBS（work breakdown structure），工作分解结构，每一个组件就是一个可交付成果，最底层的80小时可完成的可交付成果，称为 工作包。
WBS定义：把可交付成果分解为工作包，组织并定义了项目总范围。包括工作包（80小时内完成的可交付成果）、规划包（工作内容已知，但详细进度活动未知，是低于控制账户高于工作包的结构组件，体现滚动式规划）和控制账户（针对每个wbs组件，详细描述可交付成果、活动和进度信息的文件，有助于评价变更的影响）。
工具与技术：重点，曾考过10次，背诵。
分解：把项目范围和可交付成果逐步划分为更小，更便于管理的组成部分的技术。
1，识别和分析可交付成果，依据是项目范围说明书；2，确定WBS的结构和编排方法，可参考范围管理计划，里边都是指南；3，自上而下逐层分解；4，为WBS组件定制和分配标识编码。5，核实可交付成果分解的程度是否恰当。
工作包：WBS最底层组件，对其成本和持续时间进行估算和管理。
创建WBS，就是将整个项目工作分解为工作包。
WBS结构三种形式
1，每一层都是可交付成果
2，把项目生命周期的各个阶段放到第二层，其他层都是可交付成果。
3，纳入由项目团队以外的组织开发的各种低层次组件（比如外包），做为外包工资的一部分，卖方需要定制相应的合同WBS。
8个注意事项：
1，WBS是面对可交付成果；
2，必须符合项目范围（100%原则），所有下一级元素之和必须100代表上一级元素；
3，wbs底层要支持计划和控制——支持项目管理计划、进度和预算的控制；
4，元素必须只有1个人负责（独立责任原则）；
5，WBS控制在4~6层，如果超过6层需要继续分解；
6，wbs应包括项目管理工作，也要包括分包出去的工作；
7，wbs编制需要所有（主要）干系人参与；
8，wbs并非一成不变。渐进明细的。
控制账户
是一个管理控制点，人为设定的，可以与组织的财务程序连接，在该控制点上，把范围、预算和实际成本、进度加以整合，与挣值做比较，以测量绩效。
每个控制账户可能包含一个或者多个工作包，但一个工作包只属于一个控制账户。
控制账号设置在较高层次或者较低层次上，就表明项目管理团队想要对项目实施“粗管” 还是 “细管”。
输出：
范围基准
经过批准的项目范围说明书、WBS、WBS词典，只有通过正式的变更程序才能进行变更，它被用作比较的基础。
记录了整个范围，包括项目和产品范围。
9.6，控制范围，监控过程组
控制范围（control scope）：监督项目和产品的范围状态，管理范围基准变更的过程。
作用：在项目期间保持对范围基准的维护，确保所有变更请求、纠正措施、预防措施都通过实施整体变更控制过程进行处理。
输入：
项目管理计划、需求文件、工作绩效数据（执行过程中收集的第一手工作数据表数据，接受的变更的数量，核实确认和完成的可交付成果数量 ）、组织过程资产
工具与技术：
数据分析：
偏差分析，将基准和实际结果做比较，确定偏差是否处理临界值区间内或是否有必要纠正或预防措施。
趋势分析：审查项目绩效随着时间的变化情况，判断绩效是否正在改善或恶化。
输出：工作绩效信息、变更请求、项目管理计划更新、项目文件更新。
9.5 确认范围，监控过程组
确认范围（validate scope）客户或者发起人正式验收已完成项目的可交付成果的过程。
作用：使验收具有客观性，通过确认每个可交付成果，来提高最终产品、服务或成果验收的可能性。
确认范围需要检查的问题：
1，可交付成果是否是确定、可确认的。
2，每个可交付成果是否有明确的里程碑，是否有明确可辨别的事件。
3，是否有明确的质量标准。
4，审核和承诺是否有清晰的表达。
5，项目范围是否覆盖了需要完成的产品或服务所进行的所有活动，有没有遗漏或者错误。
6，项目范围的风险是否太高，管理层能发能够降低可预见风险发生时对项目的冲击。
干系人的关注点（重点）：
1，管理层，关注范围对进度、资金和资源的影响，是否超出了组织承受范围，投入产出是否合理。
2，客户，关心产品范围，项目的可交付成果是否能够完成产品或服务。
3，项目管理人员，关注可交付成果是否能够和必须完成，时间、资金和资源子否足够，主要的潜在风险等。
4，团队成员，关心自己参与和负责的元素，检查工作时间是否足够。
另外，客户和团队成员往往有在当前版本中加入所有功能和特征的意愿，是一种潜在风险。
输入：
核实的可交付成果：是验收的对象，已完成冰杯控制质量过程检查为正确的可交付成果。来自于质量管理中 控制质量的子过程。
项目管理计划：包括 范围管理计划（定义了如何验收可交付成果）和需求管理计划（描述了如何确认项目需求），以及范围基准（用基准和实际结果做比较）。
项目文件：需求文件（将需求和实际结果比较）和需求跟踪矩阵（含有和需求相关的信息，包括如何确认需求）。相当于反向验证。
技术与工具：
检查（审查、产品审查、巡检），查的是结果。开展测量、审查与确认等，判断工作和可交付成果是否符合需求和产品的验收标准。验收测试是一种典型的确认范围的技术。检查查结果，审计审过程。
输出：
验收通过，则输出：验收了的可交付成果：符合验收标准的可交付成果由客户或者发起人签字批准。
从客户或发起人获得正式文件，证明干系人对交付成果的正式验收。
验收不通过：
输出：变更请求，按照步骤：1，记录原因；2、提交变更申请流程；3、缺陷补救。
