软考系统集成2：范围管理思维导图模板

编制范围管理计划过程

过程

输入

项目管理计划

依据“项目管理计划”中已批准的子计划

项目章程

依据其中的项目背景信息来规划各个范围管理过程

提供了

高层级的项目描述

产品特征

出自项目工作说明书

组织过程资产

政策

程序

历史信息

经验教训知识库

事业环境因素

组织文化

基础设施

人事管理制度

市场条件

工具与技术

会议

目的

指定范围管理计划

与会人员

项目经理

项目发起人

团队成员

干系人

范围管理各过程的负责人

专家判断

输出

范围管理计划

描述了如何定义、制定、监督、控制、确认项目范围

需求说明书的编制方法、要求

特点

是“项目管理计划”的组成部分

是制定“项目管理计划过程”、其他范围管理过程的主要依据

需求管理计划

描述了如何分析、记录、管理需求，阶段与阶段之间的关系对管理需求的影响

收集需求

过程

输入

范围管理计划

使团队知道应该如何确定所需收集的需求的类型

需求管理计划

规定了用于“收集需求”过程的工作流程

以便定义干系人的需要

干系人管理计划

了解干系人的沟通需求、参与程度

评估、试运营干系人的参与程度

项目章程

了解项目产品、服务、成果的高层级描述

据此收集详细的需求

干系人登记册

了解哪些干系人可以提供需求信息

工具与技术

访谈

通过与干系人直接交谈来获取信息的正式 / 非正式的方法

焦点小组

召集干系人、专家，了解他们对产品、服务、成果的期望和态度

引导式研讨会

召集主要干系人，讨论，定义产品需求

特点

快速定义跨职能需求和协调干系人差异的重要技术

有助于参与者之间建立信任、改善沟通，从而达成一致意见

比单项会议更早发现问题，更快解决问题

群体创新技术

识别项目和产品需求

常用的技术

头脑风暴法

本身不包含投票/排序

名义小组技术

排列最有用的创意，一边进一步开展头脑风暴/优先排序

概念/思维导图

以反映创意之间的共性、差异

亲和图

对大量创意进行分组，进一步审查分析

多标准决策分析

借助决策矩阵，建立多种标准。从而评估、排序方案

风险水平

不确定性

价值收益

群体决策技术

为达成某种期望结果，对多个未来行动方案进行评估

作用

生产产品需求

对产品需求进行归类、优先级排序

问卷调查

设计一系列书面问题，向众多受访者快速收集信息

适用场景

受众多样化

需要快速完成调查

受访者地理位置分散

适合开展统计分析

观察（工作跟踪）

直接查看个人在各自的环境中如何执行工作、实施流程

原型法

在实际制造产品前，先造出该产品的使用模型，并据此征求对需求的早起反馈

渐进明细、反复循环

标杆对照

将计划的做法与其他可比组织的做法比较

优点

识别最佳实践

形成改进意见

为绩效考核提供依据

系统交互图

对产品范围的可视化描绘，显示业务系统、与人和其他系统的交互方式

文件分析

通过分析现有文档，识别与需求相关的信息，来挖掘需求

输出

需求文件

描述单一需求将如何满足与项目相关的业务需求

格式

简单

按干系人、优先级分类列出全部需求

详细

包括内容提要、细节描述、附件等

主要内容

业务需求

干系人需求

解决方案需求

项目需求

过渡需求

与需求相关的假设条件、依赖关系、制约因素

需求跟踪矩阵

把产品需求从来源连接到能满足需求的可交付成果的一种表格

提供了在整个项目生命周期中跟踪需求的一种方法

定义范围

概述

制定项目、产品详细描述的过程

明确收集的需求哪些将包含在项目范围内，哪些排除在项目范围外

任务

详细定义项目的范围边界

应该做的

不需要做的

过程

输入

范围管理计划

项目章程

需求文件 / 批准的变更申请

组织过程资产

政策

程序

项目档案

经验教训知识库

工具与技术

产品分析

旨在弄清产品范围，把对产品的要求转化成项目的要求

技术

产品分解

系统分析

需求分析

系统工程、价值工程、价值分析

专家判断

备选方案生成

来源

头脑风暴

横向思维

备选方案分析

引导式研讨会

输出

项目范围说明书

对项目范围、主要可交付成果、假设条件、制约因素的描述

内容

项目目标

衡量项目成功的可量化标准

包括成本、进度、质量方面的具体目标

特点

要有一定属性、计量单位、一个绝对或相对的数值

产品范围描述

描述了项目承诺交付的产品、服务、结果的特征

特点

早期粗略，后期详细

项目需求

描述了项目承诺交付物要满足合同、标准、规范 / 其他强制性文档所必需具备的条件 / 能力

项目边界

严格定义项目内包括什么，不包括什么

项目的可交付成果

在某一过程（阶段、项目）完成时，产出的任何独特的并可核实的产品、成果、服务

也包括辅助成果

项目管理报告、文件

形式

可略可详

项目的制约因素

具体的与项目范围有关的约束条件

特点

“项目范围说明书”的约束条件比“项目章程”中列出的多、详尽

假设条件

与范围相关的假设条件，以及当这些条件不成立时对项目造成的影响

项目文件更新

至少包括

干系人登记册

需求文件

需求跟踪矩阵

创建工作分解结构WBS

过程

输入

范围管理计划

范围说明书

需求文件

事业环境因素

项目所在行业的WBS标准

组织过程资产

用于创建WBS的政策、程序、模板

以往项目的项目档案

以往项目的经验教训

工具与技术

分解

把项目范围、可交付成果逐步划分为更小的、更便于管理的单元，直到可交付物细分到足以用来支持未来的项目活动定义的工作包

分析信息，以把可交付成果分解成更小的组成部分

专家判断

输出

范围基准

范围说明书

工作分解结构 WBS

作用

是后续管理工作的主要依据，是时间、成本、人力等管理工作的基础

定义工作范围

定义项目组织

估算、控制费用

估算时间周期、安排进度

明确项目各方的工作界面

形成清晰的职责使命

定义绩效考核、控制的基准

原则

各要素应该是相对独立的，减少相互之间的交叉

逐层向下分解

100%的项目工作，不能是其他工作

相同层次的工作单元应用相同性质

最底层工作应有可比性，可管理，可定量检查

应包括项目管理工作，包括分包出去的工作

必须面向可交付成果

WBS的元素只能由一个人负责

WBS的编制需要所有干系人的参与

常用的表示形式

分级的树形结构

优点

层次清晰

直观

结构性强

缺点

不易修改

对于复杂的项目很难表示项目的全景

适用场景

小的、适中的应用项目

表格形式

优点

反映出项目的所有工作要素

缺点

直观性差

适用场景

大的、复杂的应用项目

某些概念

里程碑

标志着某个可交付成果（阶段）的正式完成

和“可交付成果”紧密联系，但不是一个概念

区分

“可交付成果”

报告

原型

成果

最终产品

“里程碑”

具体时间

在这个时间应完成的事件

工作包

最低层的工作单元（最底层的可交付成果）

位于工作分解结构每条分支最底层的可交付成果组成部分

在制作WBS的过程，把每个工作包分配到一个控制账户，为工作包建立唯一标识

1个控制账户，包括若干个工作包

1个工作包仅属于1个控制账户

WBS词典

针对每个WBS组件，详细描述可交付成果、活动、进度信息的文件

内容

工作概述

账户编码

资源需求

管理储备

确认范围

概述

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

特点

贯穿项目的始终

以书面文件的形式把它完成情况记录下来

作用

使验收过程具有客观性

通过验收可交付成果，提高最终产品获得验收的可能性

有助于清楚的责任划分、任务分配

区分

“确认范围过程”

关注可交付成果的验收

“控制质量过程”

关注可交付成果的正确性、是否满足质量要求

过程

输入

项目管理计划

范围管理计划

定义了项目已完成可交付成果的正式验收程序

范围基准

范围说明书

WBS

WBS词典

需求文件

需求跟踪矩阵

工作绩效数据

工作绩效信息

合适的可交付成果

工具与技术

检查（审查、产品审查、审计、巡检）

<div>开展测量、审查、确认等活动，来判断工作、可交付成果是否符合需求、验收标准、干系人的要求期望</div>

P287

群体决策技术

输出

验收的可交付成果

由客户/发起人以书面形式正式签字批准

变更请求

对已完成但未通过正式验收的可交付成果、其未通过验收的原因，记录在案

工作绩效信息

包括项目进展信息

哪些可交付成果开始实施

进展如何

哪些可交付成果已经完成（验收）

项目文件更新

包括定义产品 / 报告产品完成情况的任何文件

范围控制

概述

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

工作内容

影响导致范围变更的因素，尽量使这些因素向有力的方向发展

判断范围变更是否已经发生

确认

范围变更发生时管理实际的变更

确保所有被请求的变更按项目整体变更控制处理

“范围控制”&&“xxxx”的联系

项目范围变更控制、管理 （整体变更管理）

对项目中存在 / 潜在的变化采用正确的策略、方法，以降低项目的风险

经常遇见的问题

范围蔓延

未经控制的产品 / 范围的扩大

未对时间、成本、资源做相应调整

得不到投资人的标准

客户等项目干系人只能提出范围变化的要求，但没有批准的权力，只有“项目投资人”才可以

项目小组未尽责任

他们有很多机会和客户交流，所接到的范围变化要求也最多

他们必须及时发现项目范围的变化，并报告给项目经理

如果把所有额外工作都自己承担，就很可能无法按时完成任务

用户需求变更

一定要有明确的需求变更管理控制、范围管理管制，否则很容易导致项目的失控

需求基线

定义了项目的范围

每次需求变更并经过需求评审后，都要重新确定新的需求基线

随着项目进展，需求基线将会 ↑ ，容许的需求变更会 ↓

过程

输入

项目管理计划

范围基准

与“实际结果”比较，决定是否要进行变更、纠正/预防

范围管理计划

描述了如何监督、控制项目范围

变更管理计划

定义了管理项目变更的过程

配置管理计划

定义了哪些是配置项，哪些需要正式变更控制

需求管理计划

描述了如何分析、记录、管理项目的需求

需求文件

需求应完整、明确、可跟踪、一致得到主要干系人的认可

需求跟踪矩阵

有助于发现变更（或对范围基准的任何偏离）给项目目标造成的影响

工作绩效数据

变更请求数量

收到的

接受的

完成的可交付成果的数量

组织过程资产

工具与技术

偏差分析

确定实际绩效、基准的差异程度、原因的技术

利用“项目绩效测量结果”评估“偏离范围基准”的程度，确定偏离范围基准的原因、程度，并决定是否需要采取纠正/预防

输出

工作绩效信息

有关项目范围实施情况的、相互关联且与各种背景相结合的信息

收到的变更的分类

识别的范围偏差、原因

偏差对进度、成本的影响

对将来范围绩效的预测

是制定范围决策的基础

变更请求

预防措施

纠正措施

缺陷补救

改善请求

项目管理计划更新

范围基准更新

如果批准的变更请求会对项目范围产生影响，那么范围说明书、WBS、WBS词典都要重新修订、发布

其他基准更新

如果批准的变更请求会对项目范围以外的方面产生影响

项目文件更新

需求文件

需求跟踪矩阵

组织过程资产更新

造成偏差的原因

所选的纠正措施、选择理由

从项目范围控制中得到的其他经验教训