项目范围管理：修订间差异
（→范围说明书） |
无编辑摘要 |
||
| 第1行： | 第1行： | ||
=项目范围管理的概念= | ==项目范围管理的概念== | ||
==项目范围管理的含义及作用== | ===项目范围管理的含义及作用=== | ||
项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。 | 项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。 | ||
| 第10行： | 第10行： | ||
• 项目范围——为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围有时也包括产品范围。 | • 项目范围——为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围有时也包括产品范围。 | ||
== | ==收集需求== | ||
收集需求是为实现项目目标而确定、记录并管理干系人的需要和需求的过程。 | 收集需求是为实现项目目标而确定、记录并管理干系人的需要和需求的过程。 | ||
| 第35行： | 第29行： | ||
===收集需求的输入=== | |||
[[范围管理计划]] | [[范围管理计划]] | ||
| 第49行： | 第42行： | ||
===收集需求的工具与技术=== | |||
[[访谈]] | [[访谈]] | ||
| 第74行： | 第67行： | ||
===收集需求的输出=== | |||
[[需求文件]] | [[需求文件]] | ||
| 第80行： | 第73行： | ||
[[需求跟踪矩阵]] | [[需求跟踪矩阵]] | ||
==编制范围计划过程的输入== | |||
==编制范围计划== | |||
规划范围管理是创建范围管理计划，书面描述将如何定义、确认和控制项目范围的过程。 | |||
本过程的主要作用是，在整个项目中对如何管理范围提供指南和方向。 | |||
===编制范围计划过程的输入=== | |||
[[项目管理计划]] | [[项目管理计划]] | ||
| 第89行： | 第89行： | ||
[[组织过程资产]] | [[组织过程资产]] | ||
==编制范围计划过程所用的技术和工具== | ===编制范围计划过程所用的技术和工具=== | ||
[[专家判断]] | [[专家判断]] | ||
[[会议]] | [[会议]] | ||
==编制范围计划过程的输出== | ===编制范围计划过程的输出=== | ||
[[范围管理计划]] | [[范围管理计划]] | ||
[[需求管理计划]] | [[需求管理计划]] | ||
==范围定义== | ==范围定义== | ||
定义范围是制定项目和产品详细描述的过程。 | 定义范围是制定项目和产品详细描述的过程。 | ||
本过程的主要作用是，明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确项目、服务或成果的边界。 | 本过程的主要作用是，明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确项目、服务或成果的边界。 | ||
===范围定义的输入=== | ===范围定义的输入=== | ||
| 第114行： | 第114行： | ||
[[组织过程资产]] | [[组织过程资产]] | ||
===范围定义的工具和技术=== | ===范围定义的工具和技术=== | ||
| 第123行： | 第124行： | ||
[[引导式研讨会]] | [[引导式研讨会]] | ||
===范围定义的输出=== | ===范围定义的输出=== | ||
| 第129行： | 第131行： | ||
项目文件更新 | 项目文件更新 | ||
== | |||
==创建工作分解结构（WBS）== | |||
===WBS 的作用和意义=== | ===WBS 的作用和意义=== | ||
创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。 | 创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。 | ||
本过程的主要作用是，对所要交付的内容提供一个结构化的视图。 | 本过程的主要作用是，对所要交付的内容提供一个结构化的视图。 | ||
===WBS 包含的内容=== | ===WBS 包含的内容=== | ||
| 第154行： | 第158行： | ||
WBS 词典是针对每个 WBS 组件，详细描述可交付成果、活动和进度信息的文件。WBS 词典对 WBS 提供支持。WBS 词典中的内容可能包括（但不限于）：账户编码标识；工作描述；假设条件和制约因素；负责的组织；进度里程碑；相关的进度活动；所需资源；成本估算；质量要求；验收标准；技术参考文献；协议信息。 | WBS 词典是针对每个 WBS 组件，详细描述可交付成果、活动和进度信息的文件。WBS 词典对 WBS 提供支持。WBS 词典中的内容可能包括（但不限于）：账户编码标识；工作描述；假设条件和制约因素；负责的组织；进度里程碑；相关的进度活动；所需资源；成本估算；质量要求；验收标准；技术参考文献；协议信息。 | ||
==WBS 创建工作的输入== | |||
===WBS 创建工作的输入=== | |||
[[范围管理计划]] | [[范围管理计划]] | ||
| 第165行： | 第170行： | ||
[[组织过程资产]] | [[组织过程资产]] | ||
==创建 WBS 所采用的方法== | |||
===创建 WBS 所采用的方法=== | |||
[[分解]] | [[分解]] | ||
| 第180行： | 第186行： | ||
• 整合可能由项目团队以外的组织来实施的各种子组件（如外包工作）。随后，作为外包工作的一部分，卖方须制定相应的合同 WBS。 | • 整合可能由项目团队以外的组织来实施的各种子组件（如外包工作）。随后，作为外包工作的一部分，卖方须制定相应的合同 WBS。 | ||
==WBS 创建工作的输出== | |||
===WBS 创建工作的输出=== | |||
[[范围基准]] | [[范围基准]] | ||
项目文件更新 | 项目文件更新 | ||
== | ==项目范围确认== | ||
确认范围是正式验收已完成的项目可交付成果的过程。 | 确认范围是正式验收已完成的项目可交付成果的过程。 | ||
| 第209行： | 第216行： | ||
确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。 | 确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。 | ||
==项目范围确认的输入== | ===项目范围确认的输入=== | ||
[[范围管理计划]] | [[范围管理计划]] | ||
| 第220行： | 第227行： | ||
[[工作绩效数据]] | [[工作绩效数据]] | ||
==项目范围确认所采用的方法== | |||
===项目范围确认所采用的方法=== | |||
[[检查]] | [[检查]] | ||
[[群体决策技术]] | [[群体决策技术]] | ||
==项目范围确认的输出== | |||
===项目范围确认的输出=== | |||
验收的可交付成果 | 验收的可交付成果 | ||
| 第234行： | 第243行： | ||
项目文件更新 | 项目文件更新 | ||
== | ==项目范围控制== | ||
控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。 | 控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。 | ||
本过程的主要作用是，在整个项目期间保持对范围基准的维护。 | 本过程的主要作用是，在整个项目期间保持对范围基准的维护。 | ||
==项目范围控制与用户需求变更的联系== | |||
===项目范围控制与用户需求变更的联系=== | |||
用户变更必须控制在可控范围之内。 | 用户变更必须控制在可控范围之内。 | ||
需求变更及项目范围变更一定要遵循由变更控制委员会制定的变更控制流程。 | 需求变更及项目范围变更一定要遵循由变更控制委员会制定的变更控制流程。 | ||
==项目范围控制与项目整体变更管理的联系== | |||
===项目范围控制与项目整体变更管理的联系=== | |||
在整个项目周期内，项目范围发生变化，则要进行范围变更控制，范围变更控制的主要工作如下。 | 在整个项目周期内，项目范围发生变化，则要进行范围变更控制，范围变更控制的主要工作如下。 | ||
| 第263行： | 第274行： | ||
（3）项目小组未尽责任 | （3）项目小组未尽责任 | ||
==项目范围控制的输入== | |||
===项目范围控制的输入=== | |||
[[范围管理计划]] | [[范围管理计划]] | ||
| 第274行： | 第286行： | ||
[[组织过程资产]] | [[组织过程资产]] | ||
==项目范围控制所用的技术和工具== | |||
===项目范围控制所用的技术和工具=== | |||
[[偏差分析]] | [[偏差分析]] | ||
==项目范围控制的输出== | |||
===项目范围控制的输出=== | |||
[[工作绩效信息]] | [[工作绩效信息]] | ||
2023年5月17日 (三) 14:57的版本
项目范围管理的概念
项目范围管理的含义及作用
项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。
管理项目范围主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内。
在项目环境中，“范围”这一术语有两种含义：
• 产品范围——某项产品、服务或成果所具有的特性和功能。
• 项目范围——为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围有时也包括产品范围。
收集需求
收集需求是为实现项目目标而确定、记录并管理干系人的需要和需求的过程。
本过程主要作用是，为定义和管理项目范围（包括产品范围）奠定基础。
需求的分类：
- 业务需求。整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。
- 干系人需求。干系人或干系人群体的需要。
- 解决方案需求。为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求：
- 功能需求是关于产品能开展的行为。
- 非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量。
- 过渡需求。从“当前状态”过渡到“将来状态”所需的临时能力。
- 项目需求。项目需要满足的行动、过程或其他条件。
- 质量需求。用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。
收集需求的输入
收集需求的工具与技术
收集需求的输出
编制范围计划
规划范围管理是创建范围管理计划，书面描述将如何定义、确认和控制项目范围的过程。
本过程的主要作用是，在整个项目中对如何管理范围提供指南和方向。
编制范围计划过程的输入
编制范围计划过程所用的技术和工具
编制范围计划过程的输出
范围定义
定义范围是制定项目和产品详细描述的过程。
本过程的主要作用是，明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确项目、服务或成果的边界。
范围定义的输入
范围定义的工具和技术
范围定义的输出
项目文件更新
创建工作分解结构（WBS）
WBS 的作用和意义
创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。
本过程的主要作用是，对所要交付的内容提供一个结构化的视图。
WBS 包含的内容
WBS 是对项目团队为实现项目目标、创建可交付成果而需要实施的全部工作范围的层级分解。WBS 组织并定义了项目的总范围，代表着经批准的当前项目范围说明书 中所规定的工作。
WBS 最低层的组件被称为工作包，其中包括计划的工作。工作包对相关活动进行归类，以便对工作安排进度、进行估算、开展监督与控制。在“工作分解结构”这个词 语中，“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身。
要素：
- 子项目是整个项目中的一个半独立、便于管理、较小部分。
- 控制账户是一个管理控制点。在该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值相比较，以测量绩效。
- 工作包是 WBS 最底层的组件。把每个工作包分配到一个控制账户，并根据“账户编码”为工作包建立唯一标识。每个控制账户可能包括一个或多个工作包，但是一个工作包只能属于一个控制账户。
- 规划包是 WBS 的组件，位于控制账户之下，工作内容已知，但详细的进度活动未知。规划包位于控制账户之下，一个控制账户可以包含一个或多个规划包。
- 活动是为完成工作包所需的工作投入。
- 任务是工作的一般内容。
WBS 词典是针对每个 WBS 组件，详细描述可交付成果、活动和进度信息的文件。WBS 词典对 WBS 提供支持。WBS 词典中的内容可能包括（但不限于）：账户编码标识；工作描述；假设条件和制约因素；负责的组织；进度里程碑；相关的进度活动；所需资源；成本估算；质量要求；验收标准；技术参考文献；协议信息。
WBS 创建工作的输入
创建 WBS 所采用的方法
创建 WBS 的方法多种多样。常用的方法包括自上而下的方法、使用组织特定的指南和使用 WBS 模板。可以使用自下而上方法对 WBS 子组件进行整合。WBS 的结构
可以采用多种形式，例如：
• 以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层。
• 以主要可交付成果作为分解的第二层。
• 整合可能由项目团队以外的组织来实施的各种子组件（如外包工作）。随后，作为外包工作的一部分，卖方须制定相应的合同 WBS。
WBS 创建工作的输出
项目文件更新
项目范围确认
确认范围是正式验收已完成的项目可交付成果的过程。
本过程的主要作用是，使验收过程具有客观性；同时通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。
确认范围应该贯穿项目的始终。如果是在项目的各个阶段对项目的范围进行确认工作，则还要考虑如何通过项目协调来降低项目范围改变的频率，以保证项目范围的改变是有效率和适时的。确认范围的一般步骤如下。
（1）确定需要进行范围确认的时间。
（2）识别范围确认需要哪些投入。
（3）确定范围正式被接受的标准和要素。
（4）确定范围确认会议的组织步骤。
（5）组织范围确认会议。
确认范围与控制质量
确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。
项目范围确认的输入
核实的可交付成果
项目范围确认所采用的方法
项目范围确认的输出
验收的可交付成果
项目文件更新
项目范围控制
控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。
本过程的主要作用是，在整个项目期间保持对范围基准的维护。
项目范围控制与用户需求变更的联系
用户变更必须控制在可控范围之内。
需求变更及项目范围变更一定要遵循由变更控制委员会制定的变更控制流程。
项目范围控制与项目整体变更管理的联系
在整个项目周期内，项目范围发生变化，则要进行范围变更控制，范围变更控制的主要工作如下。
（1）影响导致范围变更的因素，并尽量使这些因素向有利的方面发展。
（2）判断范围变更是否已经发生。
（3）范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理。
常见问题：
（1）项目范围蔓延
（2）得不到投资人的批准
（3）项目小组未尽责任
项目范围控制的输入
项目范围控制所用的技术和工具
项目范围控制的输出
项目管理计划更新
项目文件更新