文章目录
一、规划范围管理
定义：规划范围管理是为了记录如何定义、确认和控制项目范围及产品范围。
作用：在整个项目期间对如何管理范围提供指南和方向。
开展次数：仅开展一次或仅在项目的预定义时开展。
1、输入
1、项目章程。项目章程记录了高层级的需求。
2、项目管理计划
- 质量管理计划:在项目中实施组织的质量政策、方法和标准的方式会影响管理项目和产品范围的方式。
- 项目生命周期描述:定义了项目从开始到完成所经历的一系列阶段。
- 开发方法: 开发方法定义了项目是采用预测型、适应型还是混合型开发方法。
3、事业环境因素：组织文化、基础设施、人事管理制度和市场条件等。
4、组织过程资产：政策和程序、历史信息和经验教训知识库等。
2、工具与技术
1、专家判断。专家利用自身的技能或经验来做出判断。
2、数据分析
- 备选方案分析: 只要是制订计划一般都有备选方案分析。
3、会议
参会者包括项目经理、项目发起人、选定的项目团队成员、选定的干系人、范围管理各过程的负责人以及其他必要人员。
3、输出
1、范围管理计划
范围管理计划是项目管理计划的组成部分，范围管理计划可以是正式或非正式的，非常详细或高度概括的。
输
2、需求管理计划：需求管理计划是项目管理计划的组成部分，主要内容包括:
- ① 如何规划、跟踪和报告各种需求活动;
- ② 配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限;
- ③ 需求优先级排序 过程;
- ④ 测量指标及使用这些指标的理由;
- ⑤ 反映哪些需求属性将被列入跟踪矩阵等。
二、收集需求
定义：收集需求是为实现目标而确定，记录并管理干系人的需要和需求的过程。
作用：为定义产品范围和项目范围奠定基础。 开展次数仅开展一次或仅在项目的预定义时开展。
注意点：
1、需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。
2、让干系人积极参与需求的探索和分解工作(分解成项目和产品需求)，并仔细确定、记录和管理对产品、服务或成果的需求，能直接促进项目成功。
3、需求将作为后续工作分解结构(WBS)的基础，也将作为成本、进度、质量和采购规划的基础。
1、输入
1、立项管理文件
2、项目章程。项目章程记录了项目概述以及将用于制定详细需求的高层级需求。
3、项目管理计划
- 范围管理计划: 包含如何定义和制定项目范围的信息。
- 需求管理计划: 包含如何收集、分析和记录项目需求的信息。
- 干系人参与计划:从该计划中了解干系人的沟通需求和参与程度，以便评估并适应干系人对需求活动的参与程度。
4、项目文件
假设日志: 识别了影响需求的其他因素的假设条件。 干系人登记册:了解哪些干系人能够提供需求方面的信息，及记录干系人对项目的需 求和期望。 经验教训登记册:提供了有效的需求收集技术，尤其针对使用敏捷或适应型产品开发 方法的项目。
5、协议：协议包含项目和产品需求。
6、事业环境因素：组织文化、基础设施、人事管理制度、市场条件等。
7、组织过程资产：政策和程序;包含以往项目信息的历史信息和经验教训知识库等。
2、工具与技术
1、专家判断。专家利用自身的技能或经验来做出判断。
2、数据收集
- 头脑风暴:一种用来产生和收集对项目需求与产品需求的多种创意的技术。
- 访谈:通过与干系人直接交谈，来获取信息的正式或非正式的方法。访谈的典型做法是 向被访者提出预设和即兴的问题，并记录他们的回答。
- 焦点小组: 召集干系人和主题专家讨论议题，比一对一访谈更有利于互动交流。
- 问卷调查:是指设计一系列书面问题，向众多受访者快速收集信息。问卷调查方法非常适用于受众多样化，需要快速完成调查，受访者地理位置分散并且适合开展统计分析的情况。
- 标杆对照:将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的，也可以是外部的。
3、数据分析
文件分析:指审核和评估任何相关的文件信息。可供分析并有助于获取需求的文件包括，协议;商业计划;业务流程或接口文档; '业务规则库;现行流程;市场文献;问 题日志;政策和程序、法规文件，如法律、准则、法令等;建议邀请书;用例等。
4、决策
- 投票:本技术用于生成、归类和排序产品需求。
- 独裁型决策制定:采用这种方法，将由一个人负责为整个集体制定决策。
- 标准决策分析: 该技术借助决策矩阵，对众多创意进行评估和排序。
5、数据表现
- 亲和图: 用来对大量创意进行分组的技术，以便进一步审查和分析。
- 思维导图:把从头脑风暴中获得的创意整合成一张图，用以反映创意之间的共性与差异，激发新创意。
6、人际关系与团队技能
- 名义小组技术:是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便 进一步开展头脑风暴或优先排序。
- 观察和交谈: 是指直接察看个人在各自的环境中如何执行工作(或任务)和实施流程。 通过实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的 需求。
- 引导:引导与主题研讨会结合使用，把主要干系人召集在一起定义产品需求。
7、系统交互图。系统交互图是对产品范围的可视化描绘
8、原型法
- ① 原型法是指在实际制造预期产品之前，先造出该产品的模型。原型包括法缩产品、 计算机生成的二维和三维模型、实体模型或模拟。原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。
- ② 故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。
3、输出
1、需求文件
- ① 只有明确的(可测量和可测试的)、可跟踪的完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。
- ② 业务解决方案和技术解决方案。前者是干系人的需要，后者是指如何实现这些干素人需要的方案。
- ③ 需求的类别一般包括：业务需求；干系人需求；解决方案需求（又进一步分为功能需求和非功能需求）；过渡和就绪需求（如数据转换和培训需求）；项目需求；质量需求。
2、需求跟踪矩阵
需求跟踪矩阵把产品需求从箕来源连接到能满足需求的可交付成果的一种表格。
三、定义范围
定义：定义范围是制定项目和产品详细描述的过程。
作用：描述产品、服务或成果的边界和验收标准。 开展次数 需要在整个项目期间反复开展
1、输入
1、项目章程。项目章程中包含对项目的高层级描述、产品特征和审批要求。
2、项目管理计划
范围管理计划: 记录了如何定义、确认和控制项目范围。
3、项目文件
- 假设日志:
- 需求文件: 识别了应纳入范围的需求。
- 风险登记册: 包含了可能影响项目范围的应对策略
4、事业环境因素。组织文化、基础设施、人事管理制度、市场条件等。
5、组织过程资产。 用于制定项目范围说明书的政策、程序和模板;以往项目的项目档案;以往阶段或项目的经验教训等。
2、工具与技术
1、专家判断。专家利用自身的技能或经验来做出判断。
2、数据分析。可用于定义范围过程的数据分析技术是备选方案分析。
3、决策。可用于定义范围过程的决策技术是多标准决策分析。
4、人际关系与团队技能。
5、产品分析
产品分析技术主要包括:产品分解、需求分析、系统分析、系统工程、价值分析、价值工程等。
3、输出
1、项目范围说明书
项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度。详细的项目范围说明书包括内容有:
- 产品范围描述:项目章程和需求文件中所述的产品、服务或成果特征。
- 可交付成果:为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产
品 成果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。 - 验收标准:可交付成果通过验收前必须满足的一系列条件。
- 项目的除外责任: 明确说明哪些内容不属于项目范围，有助于管理干系人的期望及减少范围蔓延。
虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程度完全不同。项目章程包含高层级的信息，而项目范围说明书则是对范围组成部分的详细描述，这些组成部分需要在项目过程中渐进明细。
2、项目文件(更新)
假设日志、需求文件、需求跟踪矩阵、干系人登记册
四、创建 WBS
定义：创建工作分解结构(WBS)是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。
作用：为所要交付的内容提供架构。
开展次数：仅开展一次或仅在项目的预定义时开展
注意点：
1、WBS是对项目团队为实现项目目标，创建所需可交付成果而需要实施的全部工作范围的层级分解。WBS组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。
2、WBS最低层的组成部分称为工作包,其中包.括计划的工作。工作包对相关活动进行归类，以便对工作安排进度，进行估算，开展监督与控制。在 “工作分解结构”这个词语中，“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身。
1、输入
1、项目管理计划
范围管理计划: 定义了如何根据项目范围说明书创建WBS。
2、项目文件
- 需求文件:详细描述了各种单一需求如何满足项目的业务需要。
- 项目范围说明书: 描述了需要实施的工作以及不包含在项目中的工作。
3、事业环境因素
4、组织过程资产
2、工具与技术
1、专家判断。
专家利用自身的技能或经验来做出判断。
2、分解
- 分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。
- 工作包是WBS最低层的工作，可对其成本和持续时间进行估算和管理。需要注意：
-
① WBS必须是面向可交付成果的;
② WBS必须符合项目的范围：在WBS中，所有下一级的元素之和必须100%表上 一级的元素。
③ WBS的底层应该支持计划和控制;
④ WBS中的元素必须有人负责，而且只有一个人负责,这个规定又称为独立责任原则。
⑤ WBS应控制在4〜6层,同一级元素的大小应该相似，一个工作单元只能从属于 某个上层单元，避免交叉从属。
⑥ WBS应包括项目管理工作,也要包括分包出去的工作。
⑦ WBS的编制需要所有(主要)项目干系人的参与
⑧ WBS并非是一成不变的，在完成了 WBS之后的工作中，仍然有可能需要对WBS 进行修改。
3、输出
1、范围基准
范围基准是经过批准的范围说明书、WBS和相应的WBS词典,只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。范围基准是项目管理计划的组成部分。
- ① 项目范围说明书：项目范围说明书包括对项目范围、主要可交付成果、假设条件和制约因素的描述。
- ② WBS：WBS是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。
- ③ 工作包：WBS的最低层是带有独特标识号的工作包。这些标识号为成本、进度和资源信息的逐层汇总提供了层级结构，即账户编码。控制账户则是一个管理控制点，控制账户包含两个或更多工作包，每个工作包只与一 个控制账户关联。
- ④ 规划包：规划包是一种低于控制账户而高于工作包的工作分解结构组件,工作内容已知，但详 细的进度活动未知，一个控制账户可以包含一个或多个规划包。
- ⑤ WBS字典
WBS字典中的内容一般包括:账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等。
2、项目文件（更新）
五、确认范围
定义：确认范围是正式验收已完成的项目可交付成果的过程。
作用：① 使验收过程具有客观性；② 通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性；
开展次数：需要在整个项目期间定期开展。
确认范围的步骤：确认范围应该贯穿项目的始终, 确认范围的一般步骤包括:
- 1 确定需要进行范围确认的时间
- 2 识别范围确认需要哪些投入
- 3 确定范围正式被接受的标准和要素;
- 4 确定范围确认会议的组织步骤;
- 5 组织范围确达会议。
从检查的详细程度来说，核实产品、确认范围和质量控制是递进的、越来越细的检查过程。
1、输入
1、项目管理计划
- 范围管理计划: 定义了如何正式验收已经完成的可交付成果。
- 需求管理计划: 描述了如何确认项目需求。
- 范围基准:用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
2、项目文件
- 需求文件:将需求与实际结果比较，以决定是否有必要进行变更，采取纠正措施或预 防措施。
- 需求跟踪矩阵:含有与需求相关的信息，包括如何确认需求。
- 质量报告: 该报告内容可包括由团队管理或需上报的全部质量保证事项、改进建议 以及在控制质量过程中发现的情况的概述。
- 经验教训登记册:在项目早期获得的经验教训可以运用到后期阶段，以提高验收可交付成果的效率与效果。
3、工作绩效数据 。工作绩效数据可能包括符合需求的程度、不一致的数量、不一致的严重性或在某时间 段内开展确认的次数。
4、核实的可交付成果 。核实的可交付成果是指已经完成，并被控制质量过程检查为正确的可交付成果。
2、工具与技术
1、检查
检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。
2、决策。可用于确认范围过程的决策技术是投票。
3、输出
1、验收的可交付成果
符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人 那里获得正式文件，证明干系人对项目可交付成果的正式验收。这些文件将提交给结 束项目或阶段过程。
2、变更请求
3、工作绩效信息
4、项目文件(更新)
- 需求文件: 记录实际的验收结果，更新需求文件。
- 需求跟踪矩阵:根据验收结果更新需求跟踪矩阵，包括所采用的验收方法及其使用结果。
- 经验教训登记册: 更新经验教训登记册
六、控制范围
定义：控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。
作用：在整个项目期间保持对范围基准的维护。
开展次数：需要在整个项目期间反复开展
控制范围过稗应该与其他项目管理知识领域的控制过程协调开展。未经控制的产品或项目范 围的扩大(未对时间、成本和资源做相应调整)被称为范围蔓延。
1、输入
1、项目管理计划
- 范围管理计划:记录了如何控制项目和产品范围。
- 需求管理计划: 记录了如何管理项目需求。
- 变更管理计划: 定义了管理项目变更的过程。
- 配置管理计划:定义了哪些是配置项，哪些配置项需要正式变更控制，以及针对这些配置项的变更控制过程。
- 范围基准:用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施 或预防措施。
- 绩效测量基准:使用挣值分析时，将绩效测量基准与实际结果比较，以决定是否有必 要进行变更、采取纠正措施或预防措施。
2、项目文件
- 需求文件: 用于发现任何对商定的项目或产品范围的偏离。
- 需求跟踪矩阵:有助于探查任何变更或对范围基准的任何偏离对项目目标的影响，它还可以提供受控需求的状态。
- 经验教训登记册: 项目早期的经验教训可以运用到后期阶段，以改进范围控制。
3、工作绩效数据
工作绩效数据可能包括收到的变更请求的数量，接受的变更请求的数量或者核实、确认和完成的可交付成果的数量。
4、组织过程资产
现有的、正式的和非正式的与范围控制相关的政策、程序和指南;可用的监督和报告的方法与模板等。
2、工具与技术
1、数据分析
- 偏差分析：用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是要采取纠正或预防措施。
- 趋势分析：旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。
确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项且范围控制的重要工作。
3、输出
1、工作绩效信息
包括收到的变更的分类、识别的范围偏差和原因、偏差对进度和成本的影响，以及对 将来范围绩效的预测。
2、变更请求
分析项目绩效后，可能会就范围基准和进度基准，或项目管理计划的其他组成部分提出变更请求。
3、项目管理计划(更新)
- 范围管理计划: 更新范围管理计划，以反映范围管理方式的变更。
- 范围基准:有时范围偏差太过严重，以至于需要修订范围基准，以便为绩效测量提供 现实可行的依据。
- 进度基准:有时进度偏差太过严重，以至于需要修订进度基准，以便为绩效测量提供现实可行的依据。
- 成本基准:有时成本偏差太过严重，以至于需要修订成本基准，以便为绩效测量提供现实可行的依据
- 绩效测量基准: 有时绩效偏差太过严重，需要提出变更请求来修订绩效测量基准，以便为绩效测量提供现实可行的依据。
4、项目文件(更新)
- 需求文件:可以通过增加或修改需求而更新需求文件。
- 需求跟踪矩阵: 应该随同需求文件的更新而更新需求跟踪矩阵。
- 经验教训登记册:更新经验教训登记册，以记录控制范围的有效技术，以及造成偏差 的原因和选择的纠正措施。