规划范围管理
|
输入 |
工具 |
输出 |
|
项目管理计划 (质量管理计划、项目 生命周期描述、开发方法) |
专家判断 |
范围管理计划 |
|
项目章程 |
会议 |
需求管理计划 |
|
事业环境因素 (组织文化、基础设施 、人事管理制度和市场条件) |
数据分析(备选方案分析) |
|
|
组织过程资产 (政策和程序、历史信息和经验教训知识库) |
规划范围管理:是为了记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。
主要作用:是在整个项目期间对如何管理范围提供指南和方向。
本过程仅开展一次或仅在项目的预定义点开展。
范围管理计划
范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项 目范围。可以是正式或非正式的，非常详细或高度概括的。用于指导:制定项目范围说明书。 根据详细项目范围说明书创建 WBS。确定如何审批和维护范围基准。正式验收已完成的项目可 交付成果。
需求管理计划
需求管理计划的主要内容包括:1如何规划、跟踪和报告各种需求活动。2配置管理活动， 例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限。 3需求优先级排序过程。4测量指标及使用这些指标的理由。5反映哪些需求属性将被列入 跟踪矩阵等。
收集需求
|
输入 |
工具 |
输出 |
|
立项管理文件 |
专家判断 |
需求文件 （业务需求、干系人需求、解决方案需求、过渡和就绪需求、项目需求、质量需求） |
|
项目管理计划 (范围管理计划、需求 管理计划、干系人参与计划) |
数据收集 （头脑风暴、访谈、焦点小组、问卷调查、标杆对照） |
需求跟踪矩阵 |
|
项目文件 (假设日志、干系人登记册 、经验教训登记册) |
数据分析（文件分析） |
|
|
项目章程 |
决策 （投票、独裁型决策制定、多标准决策分析） |
|
|
协议(项目和产品需求) |
数据表现 （亲和图、思维导图） |
|
|
事业环境因素 (组织文化、基础设施 、人事管理制度、市场条件等) |
人际关系与团队技能 （名义小组技术、观察和交谈、引导） |
|
|
组织过程资产 (政策和程序;包含以 往项目信息的历史信息和经验教训知识 库等) |
系统交互图 |
|
|
原型法 |
收集需求:是为实现目标而确定，记录并管理干系人的需要和需求的过程。
主要作用:是为定义产品范围和项目范围奠定基础。
本过程仅开展一次或仅在项目的预定 义点开展。
名义小组技术:是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一 步开展头脑风暴或优先排序。名义小组技术是一种结构化的头脑风暴形式，由四个步骤组成: 1向集体提出一个问题或难题，每个人在沉思后写出自己的想法;2主持人在活动挂图上记 录所有人的想法;3集体讨论各个想法，直到全体成员达成一个明确的共识;4个人私下投 票决出各种想法的优先排序，通常采用 5 分制，1 分最低，5 分最高。 为减少想法数量、集 中关注想法，可进行数轮投票。每轮投票后，都将清点选票，得分最高者被选出。
故事板:是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。在软件开发 中， 故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。
需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。包括以下内容:
(1)业务需要、机会、目的和目标。
(2)项目目标。
(3)项目范围/WBS 可交付成果。
(4)产品设计。
(5)产品开发。
(6)测试策略和测试场景。
(7)高层级需求到详细需求。
定义范围
|
输入 |
工具 |
输出 |
|
项目管理计划（范围管理计划） |
产品分析 |
项目范围说明书 (产品范围描述、可 交付成果、验收标准、项目的除外责 任) |
|
项目章程 |
专家判断 |
项目文件(更新) (假设日志、需求 文件、需求跟踪矩阵、干系人登记册) |
|
项目文件 （假设日志、需求文件、风险登记册） |
数据分析 （备选方案分析） |
|
|
事业环境因素 （组织文化、基础设施、人事管理制度、市场条件） |
决策 （多标准决策分析） |
|
|
组织过程资产 （用于制定范围说明书的政策、程序和模版；以往项目的项目档案；以往阶段或项目的经验教训等） |
人际关系与团队技能（引导） |
定义范围:是制定项目和产品详细描述的过程。
主要作用:是描述产品、服务或成果的边界和验收标准。
本过程需要在整个项目期间多次反复开展。
项目范围说明书:是对项目范围、主要可交付成果、假设条件和制约因素的描述。明确指 出哪些工作不属于本项目范围。包括内容有:产品范围描述;可交付成果;验收标准;项目 的除外责任。
创建工作分解结构（WBS）
|
输入 |
工具 |
输出 |
|
项目管理计划 (范围管理计划) |
分解 (分解活动、WBS结构、注意事项） |
范围基准 (项目范围说明书、WBS、工作包、规划包、WBS字典) |
|
项目文件 (需求文件、项目范围说明书) |
专家判断 |
项目文件(更新) (假设日志、需求 文件) |
|
事业环境因素 (项目所在行业的WBS标准) |
||
|
组织过程资产 (用于创建WBS的政策 、程序和模板;以往项目的项目档案; 以往项目的经验教训等) |
创建工作分解结构(WBS):是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。
主要作用:是为所要交付的内容提供架构。
它仅开展一次或仅在项 目的预定义点开展。
分解:是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技 术。
工作包是 WBS 最低层的工作，可对其成本和持续时间进行估算和管理。 .
要把整个项目工作分解为工作包，通常需要开展以下活动:
(1)识别和分析可交付成果 及相关工作。
(2)确定 WBS 的结构和编排方法。
(3)自上而下逐层细化分解。
(4)为 WBS组成部分制定和分配标识编码。
(5)核实可交付成果分解的程度是否恰当。
WBS 的结构可以采用多种形式:
(1)以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层。
(2)以主要可交付成果作为分解的第二层。
分解注意事项:在分解的过程中，应该注意以下 8 个方面：
(1)WBS 必须是面向可交付成果的。
(2)WBS 必须符合项目的范围:WBS 必须包括也仅包括为了完成项目的可交付成果的活动。100%原则，在 WBS 中，所有下一级的元素之和必须 100%表上一级的元素。
(3)WBS 的底层应该支持计划和控制。
(4)WBS 中的元素必须有人负责，而且只有一个人负责。
(5)WBS 应控制在 4~6 层。一个工作单元只能 从属于某个上层单元，避免交叉从属。
(6)WBS 应包括项目管理工作(因为管理是项目具体工作的一部分),也要包括分包出去的
工作。
(7)WBS 的编制需要所有(主要)项目干系人的参与。
(8)WBS 并非是一成不变的。
范围基准的组成是经过批准的范围说明书、工作分解结构(WBS)和相应的 WBS 词典。
工作包:是 WBS 的最低层是带有独特标识号的工作包。这些标识号为成本、进度和资源信息的逐层汇 总提供了层级结构，即账户编码。
控制账户:则是一个管 理控制点。在该控制点上，把范围、预算和进度加以整合，并与挣值相比较来测量绩效。每个控制账户可能包括一个或多个工作包，但是一个工作包只能属 于一个控制账户。
规划包:是一种低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细 的进度活动未知，一个控制账户可以包含一个或多个规划包。
确认范围
|
输入 |
工具 |
输出 |
|
项目管理计划 (范围管理计划、需求 管理计划、范围基准) |
检查 （审查、产品评审、审计、走查、巡检） |
验收的可交付成果 |
|
项目文件 (经验教训登记册、质量报 告、需求文件、需求跟踪矩阵) |
决策(投票) |
变更请求 |
|
核实的可交付成果 |
工作绩效信息 （项目进展信息） |
|
|
工作绩效数据 (符合需求的程度、不 一致的数量、不一致的严重性或在某时 间段内开展确认的次数) |
项目文件（更新） （需求文件、需求跟踪矩阵、经验教训手册） |
确认范围:是正式验收已完成的项目可交付成果的过程。
主要作用:1、使验收过程 具有客观性;
2、通过确认每个可交付成果来提高最终产品、服务或成果获得验收的 可能性。
确认范围过程应根据需要在整个项目期间定期开展。
范围确认的一般步骤:
(1)确定需要进行确认范围的时间。
(2)识别确认范围需要哪些 投入。
(3)确定范围正式被接受的标准和要素。
(4)确定确认范围会议的组织步骤。
(5) 组织确认范围会议。
范围确认与质量控制不同，范围确认是有关工作结果的接受问题，而质量控制是有关工作 结果正确与否，质量控制一般在范围确认之前完成，当然也可并行进行。质量控制是核实的 可交付成果，范围确认是验收的可交付成果。
项目干系人进行范围确认的内容:
(1)可交付成果是否确实的、可确认的。
(2)每个交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件。
(3)是否有明确的质 量标准。
(4)审核或承诺是否有清晰的表达。
(5)项目范围是否覆盖了需要完成的产品或 服务的所有活动，有没有遗漏或错误。
(6)项目范围的风险是否太高，管理层是否能够降低可预见性的风险对项目的影响。
确认范围主要是项目干系人(例如，客户、发起人等)对项目的范围进行确认和接受的工作，每个人对项目范围所关注的方面是不同的: 管理层主要关注项目范围:是指范围对项目的进度、资金和资源的影响，这些因素是否 超过了组织承受范围，是否在投入产出上具有合理性。
客户主要关注产品范围:关心项目的可交付成果是否足够完成产品或服务。
项目管理人员主要关注项目制约因素:关心项目可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法。
项目团队成员主要关注项目范围中自己参与的元素和负责的元素:通过定义范围中的时间检查自己的工作时间是否足够，自己在项目范围中是否有多项工作，而这些工作是否有冲突 的地方。
控制范围
|
输入 |
工具 |
输出 |
|
项目管理计划 (范围管理计划、需求 管理计划、变更管理计划、配置管理计 划、范围基准、绩效测量基准) |
数据分析 (偏差分析、趋势分析) |
工作绩效信息 （收到的变更的分类、识别的范围偏差和原因、偏差对进度和成本的影响、以及对将来范围绩效的预测） |
|
项目文件 (需求文件、需求跟踪矩阵 、经验教训登记册) |
变更请求 |
|
|
工作绩效数据 (收到的变更请求的数 量，接受的变更请求的数量或者核实、 确认和完成的可交付成果的数量) |
项目管理计划（更新） （范围管理计划、范围基准、进度基准、成本基准、绩效测量基准） |
|
|
组织过程资产 (现有的、正式的和非 正式的与范围控制相关的政策、程序和 指南;可用的监督和报告的方法与模板 等) |
项目文件 （需求文件、需求跟踪矩阵、经验教训登记册） |
控制范围:是监督项目和产品的范围状态，管理范围基准变更的过程。
主要作用:在整个项目期间保持对范围基准的维护。
本过程需要在整个项目期间开展。
产品范围和项目范围
|
产品范围 |
项目范围 |
|
指某项产品、服务或成果所具有的特征和功 能。 |
包括产品范围，是为交付具有规定特性与功 能的产品、服务或成果而必须完成的工作。 |
|
产品范围的完成情况是根据产品需求来衡量的 |
项目范围的完成情况是根据项目管理计划来衡量的。 |
|
“需求”是指根据特定协议或其他强制性规 范，产品、服务或成果必须具备的条件或能 力。 |