项目范围管理

项目范围管理

  确保项目做且只做所需要的全部工作， 项目范围管理主要就是确认那些工作是项目范围内的，那些工作是项目范围外的。是其他方面管理的基础

• 产品范围。某项产品/服务或成果所具有的特征和功能。 面向客户
• 项目范围。为交付项目所必须完成的工作。 项目范围有时也包括产品范围。面向项目团队
• 裁剪时需要考虑的因素。因为每个项目都是独特的，所以项目经理需要裁剪项目范围管理过程。裁剪时应考虑的因素包括（但不限于）：
  • 知识和需求管理。
  • 确认和控制。
  • 开发方法。
  • 需求的稳定性。
  • 治理。

规划范围管理（本过程仅开展一次或仅在项目的预定义点开展）

  为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。（定义/确认/控制/项目范围的规则，相当于指南和规范）

作用：在整个项目期间对如何管理范围提供指南和方向。

范围管理计划是项目或项目集管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。

规划范围管理：输入

1. 项目章程。
2. 项目管理计划。
   • 质量管理计划。在项目中实施组织的质量政策、方法和标准的方式会影响管理项目和产品范围的方式。
   • 项目生命周期描述。项目生命周期定义了项目从开始到完成所经历的一系列阶段。
   • 开发方法。开发方法定义了项目是采用瀑布式、迭代型、适应型、敏捷型还是混合型开发方法。
3. 事业环境因素。
4. 组织过程资产。

规划范围管理：技术和工具

1. 专家判断。
2. 数据分析。
   - 备选方案分析
3. 会议。

规划范围管理：输出。

1. 范围管理计划。 范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。将对用于下列工作的管理过程做出规定：
   • 制定项目范围说明书；
   • 根据详细项目范围说明书创建 WBS；
   • 确定如何审批和维护范围基准；
   • 审核的可交付成果
2. 需求管理计划。 需求管理计划是项目管理计划的组成部分，描述将如何分析、记录和管理项目和产品需求。主要内容包括（但不限于）：
   • 如何规划、跟踪和报告各种需求活动；
   • 配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限；
   • 需求优先级排序过程；
   • 测量指标及使用这些指标的理由；
   • 需求跟踪矩阵，有助于确保需求文件中的每项需求在项目结束的时候都能交付

收集需求（且仅开展一次或仅在项目的预定义点开展）

  为实现项目目标而确定/记录并管理相关方的需要和需求的过程。（就是收集并记录相关方的需求，梳理/记录及整合需求）。

作用：为定义产品范围和项目范围奠定基础，需求必须是可测量的、文档化的

需求是指完成项目所必须具备的条件或能力。需求将成为工作分解结构（WBS）的基础，也将成为成本、进度、质量和采购规划的基础。

收集需求：输入

1. 项目章程。描述了高层及的需求
2. 项目管理计划。
   • 范围管理计划。范围管理计划包含如何定义和制定项目范围的信息。
   • 需求管理计划。需求管理计划包含如何收集、分析和记录项目需求的信息。
   • 相关方参与管理计划。 从相关方参与计划中了解相关方的沟通需求和参与程度，以便评估并适应相关方对需求活动的参与程度
3. 项目文件。包括（但不限于）：
   • 假设日志。假设日志识别了有关产品、项目、环境、相关方以及会影响需求的其他因素的假设条件。
   • 经验教训登记册。经验教训登记册提供了有效的需求收集技术，尤其针对使用迭代型或适应型产品开发方法的项目。
   • 相关方登记册。相关方登记册用于了解哪些相关方能够提供需求方面的信息，及记录相关方对项目的需求和期望
4. 商业文件。
5. 协议。
6. 事业环境因素
7. 组织过程资产。

收集需求：工具和技术

1. 专家判断
2. 数据收集。
3. 数据分析。
4. 决策。
5. 数据表现。
   • 亲和图。 用来对大量创意进行分组的技术，以便进一步审查和分析。把具有亲近关系的需求进行分类
   • 思维导图。 把从头脑风暴中获得的创意整合成一张图，用以反映创意之间的共性与差异，激发新创意。找出各需求之间的先后因果关系
6. 人际关系和团队技能。
7. 系统交互图。系统交互图是范围模型的一个例子，它是对产品范围的可视化描绘，显示业务系统（过程、设备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式
8. 原型法。原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。

收集需求：输出

1. 需求文件。 需求文件描述各种单一需求将如何满足与项目相关的业务需求。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。需求的类别包括：
   • 业务需求。 整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。
   • 相关方需求。 相关方或相关方群体的需要。
   • 解决方案需求。为满足业务需求和相关方需求，产品、服务或成果必须具备的特性、功能和特征。 解决方案需求又进一步分为功能需求和非功能需求：
     • **功能需求。 功能需求描述产品应具备的功能，**例如，产品应该执行的行动、流程、数据和交互。
     • **非功能需求。 非功能需求是对功能需求的补充，**是产品正常运行所需的环境条件或质量要求，例如，可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等。
   • 过渡和就绪需求。 这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力，如数据转换和培训需求。
   • 项目需求。 项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素等。
   • 质量需求。 用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如测试、认证、确认等。
2. 需求跟踪矩阵。需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果（将需求来源和可交付成果联系起来）的一种表格。是跟踪需求的一种方法，包括（但不限于）：
   • 业务需要、机会、目的和目标；
   • 项目目标；
   • 项目范围和 WBS 可交付成果；
   • 产品设计；
   • 产品开发；
   • 测试策略和测试场景；
   • 高层级需求到详细需求

PS(了解):需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（如进行中、已取消、已推迟、新增加、已批准、被分配和已完成）和状态日期。

定义范围

执行项目和产品详细描述的过程。（确定工作范围和边界）

作用：描述产品、服务或成果的边界和验收标准。

定义范围：输入

1. 项目章程
2. 项目管理计划
3. 项目文件
   • 假设日志。
   • 需求文件。
   • 风险登记册
4. 事业环境因素
5. 组织过程资产

定义范围：工具和技术

1. 专家判断
2. 数据分析
3. 决策
4. 人际关系和团队技能。
5. 产品分析，确定项目产品应该具备的功能，即明确产品范围，产品分析技术包括（但不限于）：
   • 产品分解；
   • 需求分析；
   • 系统分析；
   • 系统工程；
   • 价值分析；
   • 价值工程。

定义范围：输出

1. 项目范围说明书，是对项目范围、主要可交付成果、假设条件和制约因素的描述。项目范围说明书可明确指出哪些工作不属于本项目范围。（描述那些做，那些不做）详细的项目范围说明书包括以下内容：
   • 产品范围描述。 逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征。
   • 可交付成果。 为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述可略可详。
   • 验收标准。 可交付成果通过验收前必须满足的一系列条件。
   • 项目的除外责任。 识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，有助于管理相关方的期望及减少范围蔓延。
2. 项目文件更新
   • 假设日志。随同本过程识别出更多的假设条件或制约因素而更新假设日志。
   • 需求文件。可以通过增加或修改需求而更新需求文件。
   • 需求跟踪矩阵。应该随同需求文件的更新而更新需求跟踪矩阵。
   • 相关方登记册。如果在本过程中收集到了现有或新相关方的更多信息，则记录到相关方登记册中。

创建WBS(仅开展一次或仅在项目的预定义点开展)

  将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。（分解项目工作为各个组件的过程）

作用是，为所要交付的内容提供架构,WBS是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。最低层的组成部分称为工作包，其中包括计划的工作。工作分解结构及工作产品或可交付成果分解结构。工作包是阶段性的。

创建WBS：输入

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

创建WBS：工具和技术

1. 专家判断
2. 分解，分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术；工作包是 WBS 最低层的工作，可对其成本和持续时间进行估算和管理。 要把整个项目工作分解为工作包，通常需要开展以下活动：
   • 识别和分析可交付成果及相关工作；
   • 确定 WBS 的结构和编排方法；
   • 自上而下逐层细化分解；
   • 为 WBS 组成部分制定和分配标识编码；
   • 核实可交付成果分解的程度是否恰当。
   • 以项目的声明周期阶段作为第二层或者可交付结果作为第二层

WBS 分解方式

• 以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层
• 以主要可交付成果作为分解的第二层，
• 纳入由项目团队以外的组织开发的各种较低层次组件（如外包工作）。随后，作为外包工作的一部分，卖方须制定相应的合同 WBS
• 滚动式规划：要在未来远期才完成的可交付成果或组件，当前可能无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见，才能够制定出 WBS 中的相应细节。

创建WBS：输出

1. 范围基准，范围基准是经过批准的范围说明书、 WBS 和相应的 WBS 词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。
   • 项目范围说明书。 项目范围说明书包括对项目范围、主要可交付成果、假设条件和制约因素的描述
   • WBS。 WBS 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。工作分解结构每向下分解一层，代表对项目工作更详细的定义。
   • 工作包。 WBS 的最低层级是带有独特标识号的工作包。
   • 规划包。 一个控制账户可以包含一个或多个规划包，其是一种低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知。
2. WBS词典(详细描述WBS的文件)，WBS 词典是针对 WBS 中的每个组件，详细描述可交付成果、活动和进度信息的文件。 包括（但不限于）：
   • 账户编码标识；
   • 工作描述；
   • 假设条件和制约因素；
   • 负责的组织；
   • 进度里程碑；
   • 相关的进度活动；
   • 所需资源；
   • 成本估算；
   • 质量要求；
   • 验收标准；
   • 技术参考文献；
   • 协议信息。
3. 项目文件更新
   • 假设日志
   • 需求文件

确认范围

  是由项目发起人、客户和其他主要相关方正式验收已经完成并被核实为质量合格的可交付成果，WSB 中列的每一个可交付成果在完成之后，都要及时进行质量合格性核实（控制质量过程），及时进行实质性验收（确认范围过程）

作用：使验收过程具有客观性；提高可交付成果验收的可能性。

确认范围：输入

1. 项目管理计划

   • 范围管理计划。
   • 需求管理计划。
   • 范围基准。

2. 项目文件

   • 经验教训登记册。
   • 质量报告。
   • 需求文件。
   • 需求跟踪矩阵。

3. 核实的可交付成果，核实的可交付成果是指已经完成，并被控制质量过程检查为正确的可交付成果。

4. 工作绩效数据

确认范围：工具和技术

1. 检查。 检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。
2. 决策

确认范围：输出

1. 验收的可交付成果
2. 工作绩效信息，工作绩效信息包括项目进展信息，例如，哪些可交付成果已经被验收，哪些未通过验收以及原因
3. 变更请求。 对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案。可能需要针对这些可交付成果提出变更请求，开展缺陷补救。
4. 项目文件更新
   • 经验教训登记册。
   • 需求文件。
   • 需求跟踪矩阵

控制范围（在整个项目期间开展）

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

作用：在整个项目期间保持对范围基准的维护

控制范围：输入

1. 项目管理计划
   • 范围管理计划。
   • 需求管理计划。
   • 变更管理计划。
   • 配置管理计划。
   • 范围基准。
   • 绩效测量基准。
2. 项目文件
   • 经验教训登记册。
   • 需求文件。
   • 需求跟踪矩阵。
3. 工作绩效数据
4. 组织过程资产

控制范围：工具和技术

1. 数据分析
   • 偏差分析，偏差分析用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防措施
   • 趋势分析，趋势分析旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。

控制范围：输出

1. 工作绩效信息

2. 变更请求

3. 项目管理计划更新

   • 范围管理计划。
   • 范围基准。
   • 进度基准。
   • 成本基准。
   • 绩效测量基准。

4. 项目文件更新

   • 经验教训登记册。
   • 需求文件。
   • 需求跟踪矩阵。

补充：

• 德尔菲技术，强调多位专家反复多轮论证，得出唯一结论，匿名
• 范围蔓延，指未经控制的项目范围逐渐扩大，导致的结果就是镀金
• 100% 原则，即工作分解结构必须且只能包含100% 的工作，是用来确定项目总范围的，必须是以可交付成果为导向的。通过把 WBS 底层的所有工作逐层向上汇总，来确保既没有遗漏的工作，也没有多余的工作。

收集需求工具和技术

收集原始需求：

• 个人调查法
  - 访谈，一对一，有助于识别和定义所需产品可交付成果的特征和功能。访谈也可用于获取机密信息。
  - 问卷调查，一对多，地点分散、统计，向众多受访者快速收集信息
  - 观察和交谈，以便挖掘隐藏的需求。
• 小组调查法
  - 头脑风暴，帮助项目团队和客户产生和收集与需求相关的多种创意
  - 焦点小组，焦点小组是召集预定的相关方和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。常由背景相似者参加会议
  - 名义小组，召集一群人作为名义小组，通过匿名投票来排列每个人的创意的优先顺序
  - 引导 ，主要是引导式研讨会，收集和协调跨部门需求，邀请不同背景、部门或领域的相关方代表参加，识别一些跨界需求并协调需求矛盾。
• 联系对比法
  - 系统交互图，该系统与其他系统之间的接口关系
  - 原型法，通过原型、由相关方使用并提出反馈意见，来逐渐明确相关方需求
  - 标杆对照 ，用可比项目的最佳实践作为标杆，来确定本项目的需求

引导式研讨会

• 联合应用开发，软件开发行业，强调由项目开发团队和用户一起共同定义需求
• 质量功能展开，常在制造业的新产品研发项目中使用，开发出最能满足用户需求的那些功能
• 故事会，参会者一起创建关于相关方需求的故事，相关方的角色，相关方想要什么（需求），相关方为什么想要它（想利用它获取什么利益），经常产生于需求研讨会

控制账户/规划包和工作包

• 控制账户，用来进行项目范围/进度/成本/质量控制的，是一种管理控制点，用来考核项目执行情况
• 规划包，是一种在控制账户之下，工作包之上的WBS要素，还未分解出详细进度计划所需的活动，只是暂时用于项目计划编制工作。不能直接付诸执行，必须先分解成工作包
• 工作包，只能属于一个控制账户，是最底层的WBS要素，最小的可交付成果