项目管理第五章项目范围管理内容_项目范围管理在规划过程组四个模块

大家好，又见面了，我是你们的朋友全栈君。

项目管理第五章项目范围管理

1. 项目范围管理：范围管理确保项目做且只做所需的工作，项目范围管理过程包括：
   1. 规划范围管理：为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。
   2. 收集需求：为实现项目目标而确定、记录并管理相关方的需要和需求的过程。
   3. 定义范围：制定项目和产品详细描述的过程。
   4. 创建WBS：将可交付成果和工作分解为较小、易于管理的组建过程。
   5. 确认范围：正式验收已完成的项目可交付成果的过程。
   6. 控制范围：监督项目和产品的范围状态管理范围基准变更的过程。
2. 范围管理的核心理念：
   1. 产品范围：某项产品、服务或成果所具有的特性和功能。
   2. 项目范围：为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。
   3. 项目范围有时也包括产品范围。
3. 不同生命周期的范围管理：
   1. 预测型：开始就对范围进行定义，对任何的范围变化都要进行渐进的管理，只有正式变更控制程序才能进行基准变更。
   2. 适应型或敏捷型：旨在应对大量变更，需要相关方持续参与项目，随同可交付成果的创建提供反馈和意见，并确保产品未完项反应他们的当前需求。
4. 范围管理的发展趋势和新兴实践，包括注重与商业分析专业人士的合作，以便：
   1. 确定问题并识别商业需求
   2. 识别并推荐能够满足这些需要的可行解决方案
   3. 收集、记录并管理相关方需求，以满足商业和项目目标
   4. 推动项目集或者项目产品、服务或最终成功的成功应用

规划范围管理

规划范围管理的输入：

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

规划范围管理的工具与技术：

1.专家判断，2.数据分析，3.会议

规划范围管理的输出：

1.范围管理计划，2.需求管理计划

1. 范围管理计划：用来指导项目范围的定义、制定、监管、控制和确认。
2. 需求管理计划（商业分析计划）：描述将如何分析、记录和管理项目和产品需求。主要内容包括（但不限于）：
   1. 如何规划跟踪和报告各种需求活动
   2. 配置管理活动
   3. 需求优先级排序过程
   4. 产品测量指标及使用这些指标的理由
   5. 用来反映哪些需求属性将被列入跟踪矩阵的跟踪结构

收集需求

1. 收集需求：为实现项目目标而确定、记录并管理相关方的需要和需求的过程，代表客户声音
   1. 需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。
   2. 需求包括发起人、客户和其他相关方的已量化且记录下来的需要与期望。
   3. 收集需求旨在定义和管理客户期望。
   4. 需求是WBS的基础，也是成本、进度和质量规划的基础，有时也是采购工作的基础。

收集需求的输入：

1.项目章程，2.项目管理计划，3.项目文件，4.商业文件，5.协议，6.事业环境因素，7.组织过程资产

收集需求的工具与技术：

1.专家判断，2.数据收集，3.数据分析，4.决策，5.数据表现，6.人际关系与团队技能，7.系统交互图，8.原型法

1. 数据收集：
   1. 头脑风暴：一种用来产生和收集对项目需求与产品需求的多种创意的技术。
   2. 访谈：通过与相关方直接交谈，来获取信息的正式或非正式方法；访谈经常是“一对一”的谈话，有助于识别和定义所需产品可交付成果的特征和功能，也用于获取机密信息。
   3. 焦点小组：把预先选定的相关方和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度，由一位位受过训练的主持人引导大家进行互动式讨论。往往比“一对一”的访谈更热烈。
   4. 问卷调查：通过设计书面问题，向为数众多的受访者快速收集信息，适合于：
      1. 受众多样化
      2. 需要快速完成调查
      3. 受访者地理位置分散
      4. 适合开展统计分析
   5. 标杆对照：将实际或计划中的产品、过程和实践，与其他可比组织（组织内部或外部）的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供一个基础。
2. 数据分析：可用于本过程的数据分析技术包括文件分析，文件分析用于通过分析现有文件，识别与需求相关信息来获取需求。可供分析的文件包括（但不限于）：协议，商业计划，业务流程或接口文档，业务规则库，现行流程，市场文献，问题日志，政策和程序，法规文件，建议邀请书，用例
3. 决策技术：
   1. 投票：对多个行动方案进行评估的集体决策技术，用于生成、归类和排序产品需求。
      1. 投票结果：一致同意，·大多数同意，相对多数同意。
   2. 独裁型决策制定：由一个人负责为整个集体制定决策。
   3. 多标准决策分析：借助决策矩阵，用系统分析方法建立多种标准，以对众多创意进行评估和排序。
   4. 德尔菲技术：
      1. 吸收专家参与预测，充分利用专家的经验和学识。
      2. 采用匿名或背靠背的方式，能使每一位专家独立自由地作出自己的判断。
      3. 预测过程几轮反馈，使专家的意见逐渐趋同。
4. 数据表现：
   1. 亲和图：用来对大量创意进行分组的技术，以便进一步审查和分析。
   2. 思维导图：从头脑风暴中获得创意整合成一张图，用以反映创意之间的共性和差异，激发新创意。
5. 人际关系与团队技能：
   1. 名义小组技术：通过投票来排列最有用的创意，以便进一步开展头脑风暴或优先排序。是一种结构化的头脑风暴形式，由四个步骤组成：
      1. 向集体提出一个问题或难题，每个人在沉思后写出自己的想法。
      2. 主持人在活动挂图上记录所有人的想法。
      3. 集体讨论各个想法，直到全体成员达成一个明确的共识。
      4. 个人私下投票决出各种想法的优先排序，通常采用5分制，1分最低，5分最高，为减少想法数量、集中关注想法，可进行数轮投票，每轮投票后，都将清点选票，得分最高者被选出。
   2. 观察与交谈：直接查看、工作跟随及参与观察。
   3. 引导：引导与主题研讨会结合使用，把相关方召集在一起定义产品需求，适合引导技能的情景包括：
      1. 联合应用开发（JAD）：注重把用户和开发团队集中在一起，来改进软件开发过程。
      2. 质量功能展开（QFD）：从收集客户需求（顾客声音）开始，然后项目经理对这些需求进行分类和排序，并为实现这些需求而设置目标。
      3. 用户故事：是对所需功能的简短文字描述。
6. 系统交互图（ContextD iagram s）：范围模型的一个例子，对产品范围的可视化描绘，显示业务系统以及与人和其他系统之间的交互方式。
7. 原型法（Prototypes）：
   1. 在实际制造产品之前，先造出该产品的实用模型，并据此征求对需求的反馈意见。
   2. 原型是有形的实物，它使相关方有机会体验最终产品的模型，而不是只讨论抽象的需求陈述。
   3. 原型法符合渐进明细的理念。
   4. 在经过足够的重复之后，就可以从原型法中获得足够完整的需求，并进而进入设计或制造阶段。

收集需求的输出：

1，需求文件，2.需求跟踪矩阵

1. 需求文件：描述各种单一的需求将如何满足与项目相关的业务需求。
   1. 需求渐进明细
   2. 只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的、且主要相关方愿意认可的需求，才能作为基准，包括：业务需求、相关方需求、解决方案需求、项目需求、过度需求、质量需求。
2. 需求跟踪矩阵：把产品需求从其来源连接到能满足需求的可交付成果的一种表格，在整个项目生命周期中跟踪需求，确保需求文件所批准的每一项需求在项目结束时都能交付。需求跟踪矩阵记录需求的相关信息，有助于明确每个需求的关键信息。

定义范围

1. 定义范围：是制定项目和产品详细描述的过程，主要作用是描述产品、服务或成果的边界和验收标准。
   1. 识别的所有需求未必都包含在项目中，所以定义范围就是从需求文件中选取最终的项目需求，制定出范围的详细描述。
   2. 在规划过程中，随着对项目有更多的了解，应该更具体地定义与描述项目范围。
   3. 应该分析现有风险、假设条件和制约因素的完整性，并做必要的增补或更新。

定义范围的输入：

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

定义范围的工具与技术：

1.专家判断，2.数据分析，3.决策，4.人际关系与团队技能，5.产品分析

1. 数据分析：包括(但不限于)备选方案分析。备选方案分析可用于评估实现项目章程中所述的需求和目标的各种方法。
2. 产品分析（ProductA nalysis）：产品分析可用于定义产品和服务，以描述要交付的产品的用途、特征及其他方面，用以把高层级的产品或服务描述转变成有意义的可交付成果。
   1. 产品分析技术包括：产品分解、需求分析、系统分析、系统工程、价值工程、价值分析等。

定义范围的输出：

1.项目范围说明书，2.项目文件更新

1. 项目范围说明书：对项目范围、主要可交付物成果、假设条件和制约因素的描述，记录整个范围，包括项目范围和产品范围。项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度，包括如下内容：产品范围描述，可交付成果，验收标准，项目的除外标准。
2. 项目章程与项目范围说明书：

创建工作分解结构WBS

1. 创建工作分解结构WBS：把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分，以可交付成果为导向的工作层级分解，分解的对象使项目团队为实现项目目标、提交所需可交付成果而实施的工作，每下降一个层次就意味着对项目工作更详尽的定义，WBS组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。
2. WBS的作用：WBS是对项目团队实现项目目标，创建可交付成果而需要实施的全部工作范围的层级分解。WBS组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。WBS最底层的组件被称为工作包，其中包括计划的工作。工作包对相关活动进行归类，以便对工作安排进度、进行估算、开展监督与控制。“工作”是指作为活动的工作产品或可交付成果，而不是活动本身。

创建WBS的输入：

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

创建WBS的工具与技术：

1.专家判断，2.分解

1. 分解（Decom position）：
   1. 目的：高效管理
   2. 程度：能够可靠的估算工作费用和持续时间，
   3. 步骤：
      1. 识别和分析可交付成果和工作
      2. 确定分解结构和编排方法
      3. 自上而下逐层细化
      4. 制定和分配标识编码
      5. 核实可交付成果的分解的程度是否恰当
   4. 不能分解：很远的将来要完成的成果，滚动式规划
   5. 其他：在创建WBS过程和活动定义过程都需要进行分解，区别：
      1. 在创建WBS过程中最终产物是可交付成果，是名词
      2. 在活动定义过程中最终产物是活动列表，是动词

创建WBS的输出：

1.范围基准，2.项目文件更新

1. 范围基准：范围基准是项目管理计划的组成部分。范围基准包括：
   1. 项目范围说明书：项目范围说明书包括产品范围描述和项目可交付成果，并定义用户对产品的验收标准。
   2. 工作分解结构：工作分解结构定义每一项可交付成果，并把可交付成果分解为工作包。
   3. WBS的构成包括：工作包、规划包和控制账户。
   4. 工作分解结构词典：工作分解结构词典对每一个工作分解结构要素的工作和技术文件做详细说明。
2. 工作包：WBS的最底层是带有独特标记号的工作包，只要具备了下列特征之一的可交付成果便可称之为工作包：
   1. 是WBS的底层
   2. 能够可靠地估算和管理工作成本和持续时间
   3. 能够比较快的被完成
   4. 有一个可交付的结果和有标志性的结束
   5. 可分配（由一个人/团队负责）
3. 规划包：低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细的进度未知。
4. 控制账户（ControllAccount）：是将范围、预算、实际费用和进度计划综合起来并与代表绩效的挣值进行比较的管理控制点。每个工作包都是控制账户的一部分。为工作包建立控制帐户，并根据“帐户编码”为工作包建立唯一标识，是创建WBS的最后步骤。是一种管理控制点，每一个控制帐户都可以包括一个或多个工作包，但是每一个工作包只能属于一个控制帐户。
5. WBS词典：针对每个WBS组件，详细描述可交付成果、活动和进度信息的文件，内容可能包括：所需资源，账户编码标识，成本估算，工作描述，假设条件和制约因素，验业标准，负责的组织，技术参考文献，进度里程碑，协议信息，相关的进度活动。

确认范围

1. 确认范围（Validate Scope）：是指正式验收项目已完成的项目可交付成果的过程。作用：
   1. 使验收过程具有客观性。
   2. 通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。
   3. 与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得他们的正式验收。
   4. 站在客户的角度，在项目的不同阶段，关注项目的进展一切正常，而不是仅仅到项目结束时才来验收。
2. 确认范围与控制质量：
   1. 区别：
      1. 确认范围主要关注对可交付成果的验收（客户与发起人参与）
      2. 控制质量则主要关注可交付成果是否正确以及是否满足质量要求
      3. 实施主体不一样
      4. 控制质量通常先于确认范围进行，但二者也可同时进行

确认范围的输入：

1. 1.项目管理计划，2.项目文件，3.核实的可交付成果，4.工作绩效数据

确认范围的工具与技术：

1.检查，2.决策

1. 检查（Inspection）：是指开展测量、审查与核实等活动，来判断工作和可交付成果是否符合要求及产品验收标准，检查有时也被称为审查（reviews）、产品审查（product review s）、审计（audits）、和巡检（walkth roughs）等。

确认范围的输出：

1.验收的可交付成果，2.工作绩效信息，3.变更请求，4.项目文件更新

1. 验收的（Accepted）可交付成果：
   1. 符合验收标准的可交付成果应由客户或发起人正式签字批准。
   2. 应该从客户或发起人那里获得正式文件，证明相关方对项目可交付成果的正式验收。
   3. 这些文件将提交给结束项目或阶段过程。

控制范围

1. 控制范围（ControlScope）：监督项目和产品的范围状态，管理范围基准变更的过程，确保所有的变更请求，都经过实施整体变更控制过程的处理，在变更实际发生时，也要采用范围控制过程来管理这些变更，控制范围过程需要与其他控制过程协调开展，变更不可避免，因而必须强制实施某种形式的变更控制：
   1. 范围蔓延：未经控制的产品或项目范围的扩大。
   2. 镀金：在范围定义的工作范围以外，项目团队主动增加的额外工作。

控制范围的输入：

1.项目管理计划，2.项目文件，3.工作绩效数据，4.组织过程资产

控制范围的工具与技术：

数据分析

1. 数据分析：确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。
   1. 偏差分析：将基准与实际结果进行比较，以确定偏差是否处于临界值区间或是否有必要采取纠正或预防措施。
   2. 趋势分析：旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。

控制范围的输出：

1.工作绩效信息，2.变更请求，3.项目管理计划更新，4.项目文件更新

1. 工作绩效信息：包括有关项目范围实施情况（对照范围基准）的、相互关联且与各种背景相结合的信息，包括收到的变更的分类、识别的范围偏差和原因、偏差对进度和成本的影响，以及对将来范围绩效的预测。这些信息需要记录下来并传递给相关相关方。
2. 项目管理计划更新：
   1. 范围基准更新：如果批准的变更请求会对项目范围产生影响，那么范围说明书、工作分解结构及工作分解结构词典都需要重新修订和发布，以反映这些批准的变更。
   2. 其他基准更新：如果批准的变更请求会对项目范围产生影响，那么相应的成本基准和进度基准也需要重新修订和发布，以反映这些批准的变更.

版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。

发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/190851.html原文链接：https://javaforall.cn