项管：范围管理

（一）规划范围管理-计划

作用：创建范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，作用是在整个项目中对如何管理范围提供指南和方向

输入：

1. 项目章程
2. 项目管理计划
3. 事业环境因素
4. 组织过程资产

工具和技术（方法）：

1. 专家判断
2. 会议

输出：

1. 范围管理计划：规定了①制定详细的项目范围说明书 ②根据详细的项目范围说明书创建WBS ③维护和批准WBS ④正式验收已完成的项目可交付成果 ⑤处理对详细范围说明书的变更。
2. 需求管理计划：如何分析、记录、管理需求

（二）收集需求-计划

作用：为实现项目目标而定义并记录干系人的需求的过程

输入：

1. 项目章程
2. 范围管理计划
3. 需求管理计划
4. 干系人管理计划：包括①关键干系人所需参与程度和当前参与程度 ②干系人变更的范围和影响 ③干系人之间的互相关系和潜在交叉 ④项目现阶段的干系人沟通需求 ⑤需要分发给干系人的信息 ⑥分发信息的理由，以及可能对干系人参与所产生的影响 ⑦分发信息的时限和频率 ⑧随项目进展，更新和优化干系人管理计划的方法。
5. 干系人登记册

工具和技术（方法）：

1. 访谈：与干系人直接交流，通常是一对一。
2. 焦点小组：有主持人，分主题、分小组讨论。
3. 引导式研讨会：跨职能人员讨论。
4. 群体创新技术：是指可以组织一些群体活动来识别项目和产品需求，群体创新技术包括头脑风暴法、名义小组技术、德尔菲技术、概念／思维导图、亲和图和多标准决策分析等。
   1. 头脑风暴法：面对面，快，容易受别人影响；属于群体创新技术。
   2. 名义小组法：头脑风暴后，对创意进行排序；属于体创新技术。
   3. 思维导图：把头脑风暴中创意整合成一张图；属于群体创新技术。
   4. 亲和图：大量创意分组，然后找关系，同类的放在一起；属于群体创新技术。
   5. 多准则决策技术：对众多方案进行评估和排序的技术，不确定性下的决策准则（风险管理）；属于群体创新技术。
5. 群体决策技术：达成某种期望结果，而对多个未来行动方案进行评估的过程。本技术用于生成产品需求，并对产品需求进行归类和优先级排序
   1. 德尔菲技术：背靠背，匿名，多轮次，取得一致意见100%同意；属于群体决策技术
   2. 大多数原则：超过50%同意；属于群体决策技术
   3. 相对多数原则：候选超过两个时使用；属于群体决策技术
   4. 独裁：一言堂；属于群体决策技术
6. 问卷调查：通过设计书面问题，向为数众多的受访者快速收集信息。
7. 观察：针对不愿意说出需求，可以工作跟踪（看）和/或参与观察（做）。
8. 原型法：先造出该产品的实用模型，原型是有形的实物，符合渐进明细理念
9. 标杆对照：将实际的项目实践与可比项目的实践进行对照，识别最佳实践，形成改进意见，为绩效考核提供依据
10. 系统交互图：对产品范围的可视化描绘
11. 文件分析：通过分析现有文档，识别与需求相关信息，挖掘需求

输出：

1. 需求文件：描述各单一需求将如何满足与项目相关的业务需求。主要干系人认可的明确的、可跟踪的、完整的、相互协调的需求可作为需求基准。主要内容包括：业务需求，干系人需求，解决方案需求，项目需求（服务水平、绩效、安全、合规性、验收标准），过渡需求，与需求相关的假设条件、依赖关系和制约因素
2. 需求跟踪矩阵（RTM）：提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束时候都能交付。还为管理产品范围变更提供了框架，应在RTM中记录需求属性（来源、优先级、版本、状态等）

（三）定义范围-计划

作用：制定项目和产品详细描述的过程。

输入：

1. 项目章程
2. 范围管理计划
3. 需求文件
4. 组织过程资产

工具和技术（方法）：

1. 专家判断：
2. 产品分析：针对以产品为可交付成果的项目，产品分析是一种有效的工具。包括：
   1. 需求分析：分析用户需求是什么，需求工程师与项目经理共同参与。
   2. 系统分析：分析系统应该如何架构，系统分析员参与。
   3. 系统工程：包括系统分析、系统设计、系统综合评价等。
   4. 产品分解：产品分解结构（PBS）通过树状结构反应产品各类部件，每类在结构中出现一次。
   5. 价值工程与价值分析： 相同点：公式 V=F/C （价值=功能/成本），对项目的范围（功能）和成本进行分析 差异点：价值工程，在产品设计阶段进行价值与成本革新活动，项目运行前。 价值分析，在开始量产后，进行价值分析以降低成本或提高价值，项目运行后。
3. 备选分案识别：是一种用来制定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法。主要方法：头脑风暴、横向思维、备选方案分析。
4. 引导式研讨会：

输出：

1. 项目范围说明书：对项目范围、主要可交付成果、假设条件、制约要因素的描述。详细描述了项目的可交付成果，以及为创建这些可交付成果而必须开展的工作。记录了整个范围，包括项目和产品范围。代表了项目干系人之间就项目范围达成的共识。
   1. 制约因素的特点：不可变、限制了团队的可选方案、不是渐进明细的、是必须接受的。
   2. 假设条件的特点：是渐进明细的、是风险识别的一项重要输入、是有时间限制性的、当时所能得到的最准确信息为基础。
2. 项目文件（更新）：

（四）创建工作分解结构（WBS）-计划

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

输入：

1. 需求管理计划
2. 需求文件
3. 项目范围说明书
4. 事业环境因素
5. 组织过程资产

工具和技术（方法）：

1. 分解：把项目范围和可交付成果划分为更小的、更便于管理的组成部分，工作包是WBS最底层的工作，分解程度取决于所需的控制程度。
2. 专家判断

输出：

1. 范围基准：是一组文件，包括WBS、WBS词典、范围说明书
2. 项目文件（更新）

（五）确认范围-监控

作用：正式验收项目已完成的可交付成果的过程。

输入：

1. 项目管理计划
2. 需求文件
3. 需求跟踪矩阵
4. 核实的可交付成果：控制质量的输出，先项目内部质量检验合格，在提交给外部验收（内部）。
5. 工作绩效数据：XXXX

工具和技术（方法）：

1. 检查：指开展测量、审查与确认活动，来判断工作和可交付成果是否符合需求和产品验收的标准。也被称为审查、产品审查、审计、巡检。
2. 群体决策技术：XXXX

输出：

1. 验收的可交付成果：符合验收标准的可交付成果应该由客户或发起人正式签字批准（外部）。
2. 工作绩效信息
3. 变更请求
4. 项目文件（更新）

（六）控制范围-监控

作用：监督项目和产品的范围状态、管理范围基准变更的过程。

输入：

1. 项目管理计划
2. 需求文件
3. 需求跟踪矩阵
4. 工作绩效数据
5. 组织过程资产

工具和技术（方法）：

1. 偏差分析：确定实际绩效与基准的差异程度及原因的技术。可利用项目绩效测量结果来评估偏离范围基准的程度。 控制的重要工作包括：1、确定偏离范围基准的原因和程度；2、决定是否采取纠正或预防措施。。

输出：

1. 工作绩效信息
2. 变更请求
3. 项目管理计划（更新）
4. 项目文件（更新）
5. 组织过程资产（更新）

---

·需求管理计划：如何分析、记录、管理需求。

需求的状态：进行中、已取消、已推迟、新增加、已批准、已分配、已完成等。

·里程碑：在每个分解单元中都存在可交付的成果和里程碑。里程碑标志着某个可交付成果或者阶段的正式完成。里程碑和可交付成果紧密联系在一起，但并不是一个事物。可交付成果可能包括报告、原型、成果和最终产品。而里程碑则关注于是否完成。

·工作包：位于WBS每条分支的最底层的可交付成果或项目工作组成部分。工作包的大小应该是8-80个小时能够完成。

·控制帐户：简称CA，是一种管理控制点，是工作包的规划基础。在该控制点上，把范围、成本和进度加以整合，并把它们与挣值相比较，以测量绩效。控制帐户设置在工作分解结构的特定管理节点上。每一个控制帐户都可以包括一个或多个工作包，但是每一个工作包只能属于一个控制帐户。

·规划包：在控制帐户之下（工作包之上），工作内容已知但尚缺详细进度活动的WBS组成部分。规划包是暂时用来做计划的。随着情况的逐渐清晰，规划包最终将被分解成工作包以及相应的具体活动。

·WBS词典：制作WBS过程中，要给WBS的每个部分一个帐户编码，它们是成本、进度和资源使用信息汇总的层次结构。需要生成一些配置文件，这些文件要和WBS配合使用，称为WBS词典，也称为WBS词汇表，WBS词典可能包括：帐户编码、工作描述、假设条件、制约因素、负责人或组织单元、进度里程碑、相关的进度活动、所需要的资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等。

·创建WBS分解的原则：1、功能或技术原则；2、组织结构原则；3、系统和子系统原则；

·WBS表示形式主要有树型结构和表格形式，树形结构图的WBS层次清晰、直观性和结构性强，但不容易修改，对大的复杂的项目很难表示出项目的全貌；表格形的直观性较差，但能够反映出项目所有的工作要素。也有『鱼骨式的』，但不常用。

·物料清单：用于描述生产一个产品所需的实际部件、组件和构件的分级层次表格；

·项目的范围基准：被批准的详细的项目范围说明书和与之相关的WBS及WBS字典作为项目的范围基准，并在整个项目的生命周期内对之进行监控、核实和确认；

---

范围管理计划

1. 制定详细的项目范围说明书
2. 根据详细的项目范围说明书创建WBS
3. 维护和批准WBS
4. 正式验收已完成的项目可交付成果
5. 处理对详细范围说明书的变更

范围说明书包含内容

1. 项目目标
2. 产品范围描述
3. 项目需求
4. 项目边界
5. 项目的可交付成果
6. 项目的制约因素
7. 假设条件

创建WBS的主要活动

1. 识别和分析可交付成果及相关工作。
2. 确定WBS的结构和编排方法。
3. 自上而下逐层细化分解。
4. 为WBS组件制定和分配标识编码。
5. 核实可交付成果分解的程度是否恰当。

创建WBS的分解过程中应该注意8个方面

1. WBS必须是面向可交付成果的；
2. WBS必须符合项目的范围；
3. WBS底层应支持计划和控制；
4. WBS中的元素必须有人负责；
5. WBS一个工作单元只能从属于某个上层单元，避免交叉重属；
6. WBS应该包括项目管理工作，也要包括分包出去的工作；
7. WBS的编制需要所有（主要）项目干系人的参与；
8. WBS并非是一层不变的。

WBS分解的方法

1. 项目生命周期各阶段作为分解的第二层，产品和项目可交付成果放在第三层。
2. 主要可交付成果作为分解的第二层。
3. 整合可能由项目团队以外的组织来实施何种组件（如外包），然后作为外包工作的一部分，卖方须编制相应的合同。

需求管理的需求状态

1. 已建议：该需求已被有权提出需求的人建议；
2. 已批准：该需求已被分析，估计了其对项目余下部分的影响（包括成本和对项目其余部分的干扰），已用一个确定的产品版本号或创建编号分配到相关的基线中，软件开发团队已同意实现该项需求；
3. 已实现：已实现需求代码的设计、编写和单元测试；
4. 已验证：使用选择的方法已验证了实现的需求，例如测试和检测，审查该需求跟踪与测试用例相符。该需求现在被认为完成。

范围确认的一般步骤

1. 确认需要进行范围确认的时间。
2. 识别范围确认需要哪些投入。
3. 确定范围正式被接受的标准和要素。
4. 确定范围确认会议的组织和步骤。
5. 组织范围确认会议。

范围变更的主要内容

1. 影响导致范围变更的因素，并尽量使这些因素向有利的方面发展；
2. 判断范围变更是否已经发生；
3. 范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理；

确认范围与质量控制区别

1. 确认范围强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求；
2. 质量控制一般在确认范围之前进行，也可以同时进行；确认范围一般在阶段末尾进行；
3. 质量控制属内部检查；确认范围则是由外部干系人对项目可交付成果进行检查验收；