项目范围管理包括确保项目且只做所需的全部工作
在项目环境中，范围有
产品范围：某项产品，服务或成果所具有的特性和功能
项目范围：为交付具有规定特效与功能的产品，服务或成果而必须完成的工作。项目范围有时也包括产品范围
管理项目范围所需的各个过程及支持工具与技术，会因项目而已。经过批准的项目范围说明书、工作分解结构（WBS）和相应的WBS词典构成项目范围基准。
应该根据项目管理计划来衡量项目完成情况，根据产品需求来衡量产品完成情况。项目范围管理各个过程需要与其他知识领域中的过程整合起来，以确保项目工作能实现规定的产品范围。
项目范围管理概述
1.规划范围管理
规划范围管理是创建范围管理计划，书面描述将如何定义，确认和控制项目范围的过程。作用是在整个项目中对如何管理范围提供指南和方向
规划范围管理：输入，工具与技术和输出
范围管理计划是项目或项目集管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。制定范围管理计划和细化项目范围始于下列信息的分析：项目章程中的信息，项目管理计划中已批准的子计划，组织过程资产中的历史信息和相关事业环境。范围管理计划有助于降低项目范围蔓延的风险。
1.1 规划范围管理：输入
1.1.1 项目管理计划
依据项目管理计划中已批准的子计划来创建范围管理计划，他们会对用于规划和管理项目范围的方法产生影响
1.1.2 项目章程
依据项目章程中的项目背景信息来规划各个范围管理过程。项目章程提供了高层级的项目和产品特征。产品特征出自项目工作说明书。
1.1.3 事业影响环境
影响规划范围管理过程的事业环境因素有
组织文化
基础设施
人事管理制度
市场条件
1.1.4 组织过程资产
影响规划范围管理过程的组织过程资产有
政策和程序
历史信息和经验教训知识库
1.2 规划范围管理：工具与技术
1.2.1 专家判断
1.2.2 会议
1.3 规划范围管理
1.3.1 范围管理计划
范围管理计划是项目或项目集管理计划的组成部分，描述将如何定义，制定，监督，控制和确认项目范围。范围管理计划是制定项目管理计划过程和其他范围管理过程的主要输入。主要管理过程有
制定详细项目范围说明书
根据详细项目范围说明创建WBS
维护和批准WBS
正式验收已完成的项目可交付成果
处理对详细项目范围说明书的变更
1.3.2 需求管理计划
是项目管理计划的组成部分，主要描述如何分析，记录和管理需求。
主要内容有
如何规划，跟踪和报告各种需求活动
配置管理活动
需求优先级排序过程
产品测量指标及使用这些指标的理由
用来反映哪些需求属性将被列入根据矩形的跟踪结构
2. 收集需求
收集需求是实现项目目标而确定、记录并管理干系人的需要和需求的过程，作用是为定义和管理项目范围（包括产品范围）奠定基础。
收集需求：输入，工具和技术与输出
收集需求的数据流向图
让干系人积极参与需求发掘和分解工作，并仔细确定，记录和管理对产品，服务或成果的需求，能直接促进项目的成功。需求是指根据特定协议或者其他强制性规范，项目必须满足的条件或能力，或者产品，服务或者成果必须具备的条件或者能力。需求包括发起人、客户和其他干系人的已量化且书面记录的需要和期望
需求分类有
业务需求 整个组织高层级需要
干系人需求
解决方案需求 为满足业务需求和干系人需求，产品，服务或成果必须具备的特征，功能和特性，可分为
*功能需求 关于产品能开展的行为
*非功能需求 对功能需求的补充，是产品正常运行所需的环境条件或质量
过渡需求
项目需求
质量需求
2.1 收集需求：输入
2.1.1 范围管理计划
范围管理计划试项目团队应该如何确定所收集的需求的类型
2.1.2 需求管理计划
需求管理计划规定了用于整个收集需求过程的工作流程，以便定义记录干系人的需要
2.1.3 干系人管理计划
从干系人管理计划中了解到干系人需求和参与程度，以便评估并适应干系人对需求活动的参与程度。
2.1.4 项目章程
从项目章程中了解项目产品，服务或成果的高层级描述，并据此收集详细的需求
2.1.5 干系人登记册
从干系人登记册中了解哪些干系人能够提供需求方面的信息。干系人登记册也记录了干系人对项目的需求和期望。
2.2 收集需求：工具与技术
2.2.1 访谈
访谈是通过干系人直接的交谈来获取信息的正式或非正式的方法。访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。
2.2.2 焦点小组
焦点小组是着急预定的干系人和主题专家，了解他们对所讨论的产品，服务和成果的期望和态度。由一个受过训练的主持人引导大家进行互动式讨论
2.2.3 引导式大会
引导式大会把主要干系人召集在一起，通过集中讨论来定义产品的需求。讨论会是快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于参与者之间建立信任，改进关系，改善沟通，从而有利于干系人达成一致意见
2.2.4 群体创新技术
常用的群体创新技术有
头脑风暴发 用来产生和收集对项目需求与产品需求的多种创意技术，本事不包含投票或者排序，但常与其他群体创新技术一起作用
名义小组技术 用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步展开头脑风暴或优先排序
概念／思维导图 把从头脑风暴中获得的创意整合成一张图的技术，以反应创意之间的共性和差异，激发新的创意
亲和图 用来对大量创意进行分组的技术，以便进一步审查和分析
多标准决策分析 借助决策矩阵，用系统分析法建立诸如风险水平，不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术
2.2.5 群体决策技术
群体决策技术是为了达成某种期望结果，而对多个未来行动方案进行评估的过程，用于生成产品需求，并对产品需求进行归类和优先级排序 主要方法有
一致同意
大多数原则
相对多数原则
独裁
2.2.6 问卷调查
问卷调查是指设计一些列的书面问题，让众多受访者快速收集信息。适合于手中多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析。
2.2.7 观察
观察是指直接观察个人在各种的环境中如何执行工作（或任务）和实施流程。当产品使用者难以或不愿清晰说明他们的需求时，就特别需要通过观察来了解他们工作细节
2.2.8 原型法
原型法是指在实际制造预期产品之前，现造出该产品的实用模型，并据此征求对需求的早期反馈。
2.2.9 标杆对照
标杆对照将实际或计划的做法（如流程和操作过程）与其他可比组织的做法进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。对比可能是外部或是外部
2.2.10 系统交互图
系统交互图是范围模式的一个例子，他是对范围的可视化的描述，显示业务系统（过程，设备，计算机系统等）及其与其他系统（行动者）之间的交互方式，显示了业务系统的输入，输入提供者，业务系统的输出和输出接收者
2.2.11 文件分析
文件分析是通过分析现有文档，识别与需求相关的信息，来挖掘需求，可分性的文档有
商业计划
营销文献
协议
建议邀请书
现行流程
逻辑数据模型
业务规则库
应用软件文档
业务流程或接口文档
用例
其他需求文档
问题日志
政策
程序和法规文件
2.3 收集需求：输出
2.3.1 需求文件
需求文件描述各种单一需求将如何满足与项目相关的业务需求。开始只要高层级的需求，后来随着有关需求增加而逐步细化，只有明确的，可跟踪的，完整的，相互协调的，且主要干系人愿意认可的需求才能作为基准。需求文件主要包括
业务需要 ，包括
⑴可跟踪的业务目标和项目目标
⑵执行组织的业务规则
⑶组织的指导原则
干系人需求，包括
⑴对组织其他领域的影响
⑵对执行组织内部或外部团体的影响
⑶干系人对沟通和报告的需求
解决方案需求，包括
⑴功能和非功能需求
⑵技术和标准合规性需求
⑶支持和培训的需求
⑷质量需求
⑸报告需求
过渡需求
项目需求
⑴服务水平，绩效，安全和合规性等
⑵验收标准
与需求相关的假设条件，依赖感系和制约因素
2.3.2 需求跟踪矩阵
需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵，可以把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。需求跟踪矩阵包括
业务需要，机会，目的和目标
项目目标
项目范围/WBS可交付成果
产品设计
产品开发
测试策略和测试场景
高层及需求到详细需求
需求跟踪矩阵示例
3 定义范围
定义范围是指定项目和产品详细描述发过程。作用是明确所收集的需求是否包含在项目范围之内，从而明确项目，服务或成果的边界
定义范围：输入，工具和技术和输出
定义范围的数据流向图
3.1 定义范围
3.1.1 范围管理计划
范围管理计划是项目管控计划的组成部分，确定了制定，监督和控制项目范围的各种活动
3.1.2 项目章程
项目章程中包含对项目和产品特征的高层级描述，还包括项目审批要求
3.1.3 需求文件
使用需求文件来选择哪些需求将包含在项目中
3.1.4 组织过程资产
能够影响定义范围过程的组织资产包括
用于制定项目范围说明书的政策，程序和模板
以往项目的项目档案
以往阶段或项目的经验教训
3.2 定义范围：工具与技术
3.2.1 专家判断
获取渠道包括
组织内部的其他部门
顾问
干系人，包括客户和发起人
专业与技术协会
行业团体
主题专家
3.2.2 产品分析
产品分析包括产品分解，需求分析，系统工程，价值工程和价值分析
3.2.3 备选方案生成
备选方案生成是一种用来制定尽可能多的潜在可选方案技术，用于识别执行项目工作的不同方法，如头脑风暴，横向思维，备选方案分析等
3.2.4 引导式研讨会
具有不同期望和专业知识的关键人物参与工作会议，有助于就项目目标和项目限制达成跨职能的共识
3.3 定义范围：输出
3.3.1 项目范围说明书
项目范围说明书是对项目范围，主要可交付成果，假设条件和制约因素的描述，记录了整个范围，包括项目和产品范围。详细的描述项目的可交付成果以及创建其所开展的工作，同时代表项目干系人之间就项目范围达成的共识。并且描述是否要做的工作详细程度，决定项目管理团队控制整个项目范围的有效程度。主要包括
产品范围描述
验收标准
可交付成果
项目的除外责任
制约因素
假设条件
项目章程是高层级的信息 ，而项目范围说明书对项目范围的详细描述
项目章程与项目范围说明书的内容
3.3.2 项目文件更新
更新项目文件包括
干系人登记册
需求文件
需求跟踪矩阵
4 创建 WBS
创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小的，更易于管理的组件过程。作用是对所要交付的内容提供一个结构化的视图
创建WBS：输入，工具与技术和输出
创建WBS的数据流向图
WBS是对项目团队实现项目目标，创建可交付成果而需要实施的全部工作范围的层级分解。WBS组织定义了项目的总范围，代表着经批准的当前项目范围的说明书中所规定的工作。WBS最低层的组件被称为工作包，其中包括计划的工作。工作包对相关活动进行归类，以便对工作安排进度，进行估算开展监督与控制
4.1 创建WBS： 输入
4.1.1 范围管理计划
范围管理计划定义了应该如何根据详细项目范围说明书和创建WBS，以及如何维护和批准WBS
4.1.2 项目范围说明书
项目范围说明书描述了需要实施的工作是否属于项目，同事也列举和描述了会影响项目执行的内外部制约和限制条件
4.1.3 需求文件
详细的需求文件对理解项目结果，交付项目及最终产品都很重要
4.1.4 事业环境因素
项目所在环境的WBS标准，可以作为创建WBS的外部资料
4.1.5 组织过程资产
主要包括
用于创建WBS的争吵，程序和模板
以往项目的档案
以往的项目经验教训
4.2 创建WBS：工具和技术
4.2.1 分解
分解是把项目范围和项目可交付成果逐步划分为更小，更便于管理的组成部分的技术，通常可以开展
识别和分析可交付成果及相关工作
确定WBS的结构和编排方法
自上而下逐层细化分解
为WBS组件制定和分配表示编码
核实可交付成果分解的程度是否恰当
4.2.2 专家判断
分解到工作包的WBS实例
创建WBS的方法自上而下的方法，使用组织特定的指南和使用WBS模板。WBS采用的形式有
以项目生命周期的各个阶段作为分解的第二层，把产品和项目交付成果放在第三层
以主要交付成果作为分解的第二层
整合可能由项目团队以外的组织来实施的各种子组件。作为外包工作的一部分，卖方制定相应的合同WBS
WBS实例：以阶段作为第二层
WBS实例：以主要交付成果作为第二层
4.3 创建WBS：输出
4.3.1 范围基准
范围基准是经过批准的范围说明书、工资结构分解（WBS）和相应的WBS词典，只用通过正式的变更控制程序才能进行变更，他被作为比较的基础，是项目管理计划的组成部分 包括：
项目范围说明书 包括项目范围，主要可交付的成果，假设条件和制约因素的描述
WBS 是项目团队为实现项目目标，创建所需可交付成果而需要实施的全部工作范围的层级分解。
WBS 词典 针对每个WBS组件，详细描述可交付成果，活动和进度信息文件，对WBS进行支持，内容包括
* 账户编码识别
* 工作描述
* 假设条件和制约因素
* 负责的组织
* 进度里程碑
* 相关的进度活动
* 所需资源
* 成本估算
* 质量需要
* 验收标准
* 技术参考文献
* 协议信息
4.3.2 项目文件更新
需要更新的项目文=文件包括需求文件，可能需要在需求文件中反应经批准的变更。
5 确认范围
确认范围是正式验收已完成的项目可交付成功的过程。作用是验收过程具有客观性，同时通过验收每个可交付成果，提高最终产品，服务和成果获得验收的可能性
确认范围：输入，工具与技术和输出
确认范围的数据流向图
有客户或者发起人审查从控制制度过程输出的核实的可交付成果，确认这些可交付成果已经完成并通过验收，需要的依据是：从项目范围管理知识领域的各种规划过程获得输出（需求文件和范围基准），以及其他知识领域的各种执行过程获得的工作绩效业绩
确认范围过程与质量控制过程的不同之处，前者关注可交付成果的验收，后者关注可交付成果的正确性和是否满足质量要求 ，控制质量过程先于确认范围过程，但二者可以同时进行
5.1 确认范围：输入
5.1.1 项目管理计划
项目管理计划包含范围管理计划和范围基准。
5.1.2 需求文件
需求文件列明了全部项目需求，产品需求及对项目和产品的起哦他类型需求和相应的验收标准
5.1.3 需求跟踪矩阵
需求跟踪矩阵连接了需求和需求源，在整个项目周期中对需求进行跟踪
5.1.4 核实的可交付成果
工作绩效数据包含符合需求的程度，不一致的数据，不一致的严重性或在某段时间开展确认的次数
5.2 确认范围：工具与技术
5.2.1 检查
检查是开展测量，审查与确认活动，来判断工作和可交付成果是否符合需求和产品验收标准，也称作审查，产品审查，审计或巡检
5.2.2 群体决策技术
当由项目团队和其他干系人进行确认时，可使用这些技术达成结论
5.3 范围确认： 输出
5.3.1 验收的可交付成果
符合验收标准是可交付成果应该由客户或者发起人正式签字批准
5.3.2 变更请求
对已完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案，可能需要针对这些可交付成果提出请求进行缺陷补救。
5.3.3 工作绩效信息
工作绩效信息包括项目进展信息
5.3.4 项目文件更新
需要更新的项目文件包括定义产品或报告产品完成情况的任何文件，需经过客户或发起人的签字批准
6 控制范围
控制范围是监督项目和产品的范围状态，管理范围基准变更过程。作用是在整个项目期间保持对范围基准的维护
控制范围：输入，工具与技术和输出
控制范围的数据流向图
6.1 控制范围：输入
6.1.1 项目管理计划
可用于控制范围的项目管理计划有
范围基准
范围管理计划
变更管理计划
配置管理计划
需求管理计划
6.1.2 需求文件
需求应该明确（可测量或可测试），可跟踪，完整，一致且得到主要干系人的认可，记录完好的需求文件便于发现任何对于批准项目和产品范围的偏离
6.1.3 需求跟踪矩阵
见2.3.2 需求跟踪矩阵有助于发现任何变更或范围基准的任何偏离给项目造成的影响。
6.1.4 工作绩效数据
工作绩效数据包括变更请求的数量，接受变更请求的数量，或完成的可交付成果的数量等
6.1.5 组织过程资产
影响控制范围的组织过程资产 包括
现有的，正式的和非正式的，与范围控制相关的正常，程序和指南
可有的监督和报告的方法与模版
6.2 控制范围：工具与技术
6.2.1 偏差分析
偏差分析是确定实际绩效和基准的差异程度及原因的技术。可应用项目绩效测量结果评估偏离范围基准的程度，确定偏离范围基准的原因和程度，并决定是否需要采取纠正和预防措施
6.3 控制范围：输出
6.3.1 工作绩效信息
本过程产生的工作绩效信息是有关项目范围的实施情况（对照范围基准）的，相互关联且与各种背景相结合的信息，包括收到变更的分类，识别的范围偏差和原因，偏差对进度和成本的影响，以及对将来范围的预测，是制定范围决策的基础
6.3.2 变更请求
对范围绩效的分析，可能导致对范围基准或项目管理计划其他组成部分提出变更的请求，包括预防措施，纠正措施，缺陷补救或改善请求。需要经实施整体变更控制过程的审查和处理
6.3.3 项目管理计划更新
包括
范围基准更新
其他基准更新
6.3.4 项目文件更新
包括
需求文件
需求跟踪矩阵
6.3.5 组织过程资产更新
包括
造成偏差的原因
所选 的纠正措施及选择理由
从项目范围控制中得到的其他经验教训
评论