第五章 项目范围管理
5.1 范围管理概述
项目范围管理需要做以下三方面工作：
明确项目边界。
对项目执行过程进行监控
防止项目范围发生蔓延
一、项目范围的概念
项目范围是为了达到项目目标，为了交付具有某种特制的产品和服务，项目所规定要做的。
信息系统项目中，实际上存在两个相互关联的范围：产品范围和项目范围。
产品范围是指信息系统产品或者服务所应该包含的功能；
项目范围是指为了能够交付信息系统项目所必须做的工作。显然，产品范围是项目范围的基础。
二、项目范围对项目管理的意义
1、清楚项目工作范围和内容，为准确估算费用、时间和资源打下基础；
2、为各项计划打下基础，是项目进度测量和控制基准；
3、确定具体工作任务，有助于划分责任和分派任务
三、项目范围管理的主要过程
(1)规划范围管理
(2)收集需求
(3)定义范围
(4)创建工作分解结构
(5)确认范围
(6)范围控制
第五章 项目范围管理
5.2 规划范围管理
一、规划范围管理
项目范围管理计划是一种规划的工具，说明项目组将如何进行项目的范围管理。具体来说，包括如何进行项目范围定义、如何制订工作分解结构、如何进行项目范围核实和控制等。
二、编制范围管理计划的工具和技术
1、专家判断
2、会议
三、编制范围管理计划的输出
(1) 范围管理计划
(2) 需求管理计划
(1)范围管理计划
范围管理计划是项目或项目集管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。对将用于下列工作的管理过程做出规定：
制定详细项目范围说明书；
根据详细项目范围说明书创建WBS；
维护和批准WBS；
正式验收已完成的项目可交付成果；
处理对详细项目范围说明书的变更。该工作与实施整体变更控制过程直接相联
(2)需求管理计划
需求管理计划描述将如何分析、记录和管理需求。需求管理计划的主要内容包括（但不限于）：
如何规划、跟踪和报告各种需求活动
需求管理需要使用的资源
培训计划
项目干系人参与需求管理的策略
判断项目范围与需求不一致的准则和纠正规程
需求跟踪结构，哪些需求属性将被列入跟踪矩阵
配置管理活动，例如，如何启动产品变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限
第五章 项目范围管理
5.3 收集需求
收集需求是为实现项目目标而确定、记录并管理干系人的需要和需求的过程。本过程的主要作用是，为定义和管理项目范围（包括产品范围）奠定基础。
一、需求的分类
需求可以分成不同的类别，有利于对需求进行进一步完善和细化。
业务需求。整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。
干系人需求。干系人或干系人群体的需要。
解决方案需求。为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征。
功能需求是产品能开展的行为。如流程、与产品的互动。
非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量。如可靠性、性能、安全性、服务水平等
过渡需求。从“当前状态”过渡到“将来状态”所需的临时能力，如数据转换和培训需求。
项目需求。项目需要满足的行动、过程或其他条件。
质量需求。用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。
二、收集需求的工具和技术
访谈
焦点小组
引导式研讨会
群体创新技术
群体决策技术
问卷调查
观察
原型法
标杆对照
系统交互图
文件分析
三、收集需求的输出
需求文件
需求跟踪矩阵
1、需求跟踪
需求跟踪的目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求。
需求跟踪有两种方式：
（1）正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
（2）逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。
正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。
2、需求跟踪矩阵
需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。
使用需求跟踪矩阵，可以把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。
需求跟踪矩阵提供了跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。
第五章 项目范围管理
5.4 定义范围
定义范围是制定项目和产品详细描述的过程，主要作用是明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确产品、服务或成果的边界。
一、定义范围的工具与技术
1.产品分析
对于那些以产品为可交付成果的项目（区别于提供服务或成果的项目），产品分析是一种有效的工具。
产品分析技术包括产品分解、系统分析、需求分析、系统工程、价值工程和价值分析等。
2.备选方案生成
备选方案生成是一种用来制定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法。许多通用的管理技术都可用于生成备选方案，如头脑风暴、横向思维（发散思维）、备选方案分析等。
二、项目范围说明书的内容
产品范围描述
验收标准
可交付成果
项目的除外责任
项目的制约因素
假设条件。假设条件是指当前不能确定的、未经验证但仍被视为正确、真实或确定的因素。
三、项目范围说明书的作用
确定范围
沟通基础
规划和控制依据
变更基础
规划基础
区分：项目范围说明书和项目章程。
第五章 项目范围管理
5.5 创建工作分解结构(WBS)
创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。
本过程的主要作用是，对所要交付的内容提供一个结构化的视图。
项目的工作分解结构( WBS)是管理项目范围的基础，详细描述了项目所要完成的工作。
工作分解结构是将项目划分为可管理的工作单元，以便这些工作单元的费用、时间和其他方面较项目整体而言较容易确定。
工作分解结构对于所有的项目都非常重要，因为它是费用估算、进度估算、资源计划、风险管理计划、活动定义的基础和依据。
一、工作分解结构的层次
工作分解结构把项目整体或者主要的可交付成果分解成容易管理、方便控制的若干个子项目或者工作包，子项目需要继续分解为工作包，持续这个过程，直到整个项目都分解为可管理的工作包，这些工作包的总和是项目的所有工作范围。
工作包的大小也是需要考虑的细节，如果工作包太大，那么难以达到可管理和可控制的目标，如果工作包太小，那么工作分解结构就要消耗项目管理者和项目组成员的大量时间和精力。
作为一种经验法则，8/80规则建议工作包的大小应该至少需要8小时来完成，而总完成时间也不应该大于80小时（两周）。
例：WBS最底层的工作单元被称为工作包，以下关于工作包的叙述中，正确的是（ A ）
A.可依据工作包来确定进度安排、成本估算等工作
B.工作包可以非常具体，也可以很粗略，视项目情况而定
C.如果项目规模很大，也可以将其分解为子项目，这时子项目可以认为是一个工作包
D.工作包的规模应该较小，可以在40小时之内完成
1.WBS 有两种表示形式：
分级的树型结构
列表形式
2.里程碑
里程碑是项目中的重要时点或事件。标志着某个可交付成果或阶段的正式完成。
3.控制账户
控制账户是一种管理控制点，在该控制点，将范围、预算（资源计划）、实际成本和进度加以整合，并将它们与挣值进行比较，以测量绩效。控制账户可是WBS某个层次上的要素，可以是工作包，或更高层次的要素。一个控制帐户可以包含多个工作包，但一个工作包一定属于一个控制帐户，绝不会属于多个控制帐户。
4.WBS词典
是工作分解结构的支持性文件，用来对工作分解结构中的控制账户和工作包做详细解释。详细程度可根据具体需要确定。
WBS词典的内容包括：
○ 账户编码标识； ○ 工作描述；
○ 假设条件和制约因素； ○ 负责的组织；
○ 进度里程碑； ○ 相关的进度活动；
○ 所需资源； ○ 成本估算；
○ 质量要求； ○ 验收标准；
○ 技术参考文献； ○ 协议信息。
二、分解
以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层
以主要可交付成果作为分解的第二层
1.分解需要的活动
识别和分析可交付成果及相关工作
确定工作分解结构的结构和编排
自上而下逐层细化分解
为WBS组件制定和分配标识编码
核实交付成果分解的程度是恰当的
2.分解工作分解结构应把握的原则
(1) 在各层次上保持项目的完整性，避免遗漏必要的组成部分。
(2) 一个工作单元只能从属于某个上层单元，避免变叉从属。
(3) 相同层次的工作单元应有相同性质。
(4) 工作单元应能分开不同的责任者和不同工作内容。
(5) 便于项目管理进行计划和控制的管理需要。
(6) 最低层工作应该具有可比性，是可管理的，可定量检查的。
(7) 应包括项目管理工作，包括分包出去的工作。
3.工作分解结构的作用
(1)明确和准确说明项目范围，项目组成员能够清楚地理解任务的性质和需要努力的方向。
(2)工作分解结构清楚地定义了项目的边界确定项目需要做的工作和不需要做的工作。
(3)为各独立单元分派人员，可以确定完成项目所需要的技术和人力资源。
(4)针对独立单元，进行时间、费用和资源的需要量的估算，提高估算的准确性。
(5) 项目进度控制的基准。
(6) 将项目工作和项目的财务账目联系起来。
(7) 确定工作内容和工作顺序。
(8) 估计项目整体和全过程的费用。
(9) 工作分解结构有助于防止需求蔓延。
第五章 项目范围管理
5.6 确认范围
一、确认范围
确认范围是确认项目的可交付成果和用户的期望是否一致。
范围确认应该贯穿项目的始终，从WBS的确认或合同中具体分工界面的确认，到项目验收时范围的检测。
在信息系统中，范围确认并不是容易的事情，它的不容易主要体现在与用户的沟通上。每个人对项目范围所关注的方面是不同的。
管理层所关注的是项目范围对项目的进度、资金和资源的影响
客户主要关心的是产品的范围，关心项目的可交付成果是否足够完成产品或者服务。
项目经理关注可交付成果是否足够和必须完成，时间、资金、资源是否足够等。
团队成员关注自己参与和负责的元素，自己的工作时间是否足够。
二、项目利益相关人进行范围确认时，要检查：
(1)可交付成果是否是确实的、可核实的。
(2)每个交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件。
(3)是否有明确的质量标准。
(4)审核和承诺是否有清晰的表达。所有的这些表达必须清晰，并取得一致的同意。
(5)项目范围是否覆盖了需要完成的产品或者服务进行的所有活动，有没有遗漏或者错误。
(6)项目范围的风险是否太高，管理层是否能够降低可预见的风险发生时对项目的冲击。
如果在范围确认工作中发现项目范围说明书、工作分解结构中有遗漏或者错误，需要向项目组明确指出错误的内容，并给出修正的意见。项目组需要根据修改意见重新修改项目范围说明书和工作分解结构。
在范围确认的工作过程中也可能会出现范围变更请求，如果这些范围变更请求得到了批准，那么也要重新修改项目范围说明书和工作分解结构。
三、范围确认采用的方法
1.检查
是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。是否满足干系人要求和期望。
2.群体决策技术
群体决策就是为达成某种期望结果而对多个未来行动方案进行评估。群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序。
一致同意。每个人都同意某个行动方案。
大多数原则。获得群体中50%以上的人的支持。
相对多数原则。根据群体中相对多数者的意见做出决定，即便未能获得一部分人的支持。
独裁。某个人为群体做出决策。
四、术语的比较
1.确认范围与核实产品
2.确认范围与质量控制
3.确认范围与项目收尾
第五章 项目范围管理
5.7 控制范围
控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。范围控制涉及到影响范围变更的因素，确保所有变更请求、推荐的纠正措施或预防措施按照项目整体变更控制处理。
一、范围变更的原因
项目外部环境发生变化（如法律、对手的新产品)
范围计划不周
有错误或者遗漏
出现了新的技术、手段和方案
项目实施组织发生了变化
项目业主对项目要求发生变化等。
所有的变更必须记载，范围控制必须能够对造成范围变更的因素施加影响，估算对项目的资金、进度和风险等影响，以保证变化是有利的，同时需要判断范围变更是否发生，如果已经发生，那么对变化进行管理。
信息系统项目建设过程中用户不断提出的新的要求和建议，项目应该坚持“决不让步，除非交换” 的原则，尽可能减少范围蔓延的可能性。
所有的范围变更必须在项目的工期、费用或者质量要求上有相应的变更。
二、范围变更请求
范围变更的原因是多方面的
范围的变化是必然的，项目组无法阻止变化，也不能完全预言变化
虽然许多新的分析方法能够容纳一些变化，但它们并非解决信息系统复杂性的“银弹”，根本原因就在于信息系统的复杂性。
三、范围变更实现
项目的初期改变项目的范围要比后期容易
避免信息系统项目范围在项目进行后进行重大修改，合理的需求分析非常重要
不要把项目变成新技术的测试平台。如果有必要，在组织中建立专门的实验室是非常好的解决方法。
范围变更需要及时告知项目的相关利益人
---------------------
原文：https://blog.csdn.net/qq_26562641/article/details/78106454