第五章 项目范围管理
★项目范围管理包括确保项目做且只做成功完成项目所需的全部工作的各过程。
★管理项目范围主要在于定义和控制哪些工作应包括在项目内，哪些不应包括在项目内。
★项目范围管理的过程包括：
☆收集需求，为实现项目目标而定义并记录干系人的需求的过程
☆定义范围，制定项目和产品详细描述的过程
☆创建工作分解结构，将项目可交付成果和项目工作分解为较小的、更易于管理的组成部分的过程。
☆核实范围，正式验收项目已完成的可交付成果的过程
☆控制范围，监督项目和产品的范围状态、管理范围基准变更的过程
★在项目的环境中，“范围”这一术语有两种含义：
☆产品范围，某项产品、服务或成果所具有的特性和功能。
☆项目范围，为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。
★范围基准
☆经批准的详细项目范围说明书以及相应的工作分解结构、工作分解结构词典，构成项目的范围基准。
☆在整个生命周期中，对这个基准范围进行监督、核实和控制。
★在进行项目范围管理的五个过程之前，项目管理团队应先进行规划工作。
☆这部分规划工作是制定项目管理计划过程的一部分，会产生一份范围管理计划，用来指导项目范围的定义、记录、核实、管理和控制。
☆基于项目的需要，范围管理计划可以是正式或非正式的、非常详细或高度概括的。
★项目范围和产品范围的衡量
☆根据项目管理计划来衡量项目范围是否完成
☆根据产品需求来衡量产品范围是否完成
★项目范围管理各过程需要与其他知识领域中的过程整合起来，以确保项目工作能实现规定的产品范围。
5.1 收集需求
★收集需求是为实现项目目标而定义并记录干系人的需求的过程。
☆仔细掌握和管理项目需求与产品需求，对促进项目成功有重要作用。
☆收集需求旨在定义和管理客户期望。
★需求指发起人、客户和其他干系人的已量化且记录下来的需要与期望。
☆项目一旦开始，就应该详细地探明、分析和记录这些需求，以便日后进行衡量。
☆需求是工作分解结构的基础。
☆成本、进度和质量规划也都需要在这些需求的基础上进行。
★需求开发始于对项目章程和干系人登记册中相关信息的分析。
★需对组织把需求分为项目需求和产品需求
☆项目需求包括商业需求、项目管理需求、交付需求。
☆产品需求则包括技术需求、安全需求、性能需求。
5.1.1收集需求：输入
1.项目章程
★项目章程中包含了总体项目需求以及项目产品的总体描述，可据此制定详细的产品需求。
2.干系人登记册
★干系人登记册可用来识别那些能提供详细的项目和产品需求信息的干系人。
5.1.2收集需求：工具与技术
1.访谈
★访谈是一种通过与干系人直接交谈，来获得信息的正式或非正式方法。
☆访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。
☆通常采取“一对一”的形式，但也可以有多个被访者和/或多个访问者共同参与。
☆访谈有经验的项目参与者、干系人和主题专家，有助于识别和定义项目可交付成果的特征和功能。
2.焦点小组会议
★焦点小组会议是把预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。
☆由一位受过训练的主持人引导大家进行互动式讨论。
☆焦点小组会议往往比“一对一”的访谈更热烈。
3.引导式研讨会
★通过邀请主要的跨职能干系人一起参加会议，引导式研讨会对产品需求进行集中讨论与定义。
☆研讨会是快速定义跨职能需求和协调干系人差异的重要技术。
☆由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见。
☆该技术的另一好处是，能够比单项会议更快地发现和解决问题。
★联合应用开发（或设计）（JAD），这是在软件开发领域的一个例子
☆这种研讨会注重把用户和开发团队集中在一起，来改进软件开发过程。
★质量功能展开（QFD），这是制造行业的一个例子
☆QFD从收集客户需求（又称“顾客声音”）开始，然后客观地对这些需求进行分类和排序，并为实现这些需求而设置目标。
4.群体创新技术
★可以组织一些群体活动来识别项目和产品需求
☆头脑风暴法。
用来生成和收集对项目需求与产品需求的多种构想的一种技术。
☆名义小组技术。
通过投票来排列最有用的构想，以便进行进一步的头脑风暴或优先排序。
名义小组技术是头脑风暴法的深化应用。
☆德尔菲技术。
由一组选定的专家回答问卷，并将每一轮需求收集的结果再给出反馈。
专家的答复只能交给主持人，以保持匿名状态。
☆概念/思维导图
把从头脑风暴中获得的构想，用一张简单的图联系起来，以反映这些构想之间的共性和差异，从而引导出新的构想。
☆亲和图。
这种技术可以将大量构想分类，以便审查和分析。
5.群体决策技术
★群体决策就是对达成某种期望结果的多个未来行动方案进行评估。
☆群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序。
★形成群体决策的方法很多，例如：
☆一致同意。每个人都同意某个行动方案。
☆大多数原则。获得群体中50%以上的人的支持。
☆相对多数原则。根据群体中相对多数者的意见做出决定，即便未能获得大多数人的支持。
☆独裁。某一个人为群体做出决策。
6.问卷调查
★问卷调查是指通过设计书面问题，向为数众多的受访者快速收集信息。
☆如果受众多、需要快速完成调查，并想要使用统计分析法，就适宜采用问卷和/或调查方法。
7.观察
★观察是指直接观察个人在各自的环境中如何开展工作和实施流程。
☆当产品使用者难以或不愿说明他们的需求时，就特别需要通过观察来了解细节。
☆观察，也称为“工作跟踪”，通常由观察者从外部来观察使用者的工作。
☆观察也可以由“参与观察者”进行。
☆“参与观察者”需要实际执行一个过程或程序，体验该过程或程序是如何完成的，以便挖掘出隐藏的需求。
8.原型法
★原型法是指在实际制造产品之前，先造出该产品的实用模型，并据此征求对需求的反馈意见。
☆原型是有型的实物，它使干系人有机会体验最终产品的模型，而不只是讨论抽象的需求陈述。
☆原型法符合渐进明细的理念，因为所有原型都需要重复经过制作、试用、反馈、修改等过程。
☆在经过足够的重复之后，就可以从原型中获得足够完整的需求，并进而进入设计或者制作阶段
5.1.3收集需求：输出
1.需求文件
★需求文件描述各种单一的需求将如何满足项目的业务需求。
☆只有明确的（可测量且可测试的）、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。
☆需求文件的格式多种多样，既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。
★需求文件的组成部分包括：
☆业务需求或需抓住的机遇：描述当前局面的不足以及启动项目的原因；
☆可跟踪的业务目标和项目目标；
☆功能要求：描述业务流程、信息，以及与产品的内在联系。
☆非功能性要求：如服务水平、绩效、安全、防护、合规性、保障能力、保留/清除等;
☆质量要求；
☆验收标准；
☆体现组织指导原则的业务规则；
☆对组织其他领域的影响。
☆对执行组织内部或外部团体的影响；
☆对支持和培训的需求；
☆与需求有关的假设条件和制约因素。
2.需求管理计划
★需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求。
☆生命周期各阶段间的关系对如何管理需求有很大影响。
☆项目经理必须为项目选择最有效的阶段间关系，并记录在需求管理计划中。
☆需求管理计划的许多内容都是基于该项关系的。
★需求管理计划的内容包括
☆如何规划、跟踪和汇报各种需求活动；
☆配置管理活动
例如，如何启动产品、服务或成果的变更，如何分析其影响，如何进行跟踪和汇报，以及谁有权批准变更；
☆需求排序过程
☆产品测量指标及使用这些指标的理由
☆需求跟踪结构，哪些需求属性将列入跟踪矩阵，并可在哪些项目文件中追踪到这些需求。
3.需求跟踪矩阵
★需求跟踪矩阵是一张连接需求与需求源的表格，以便在整个项目生命周期中对需求进行跟踪。
☆需求跟踪矩阵通过把每一个需求与业务或项目目标联系起来，从而确保每一个需求都具有商业价值。
☆它为人们在整个项目生命周期中跟踪需求提供了一种方法，
☆有助于确保需求文件所批准的每一项需求在项目结束时都得到实现。
☆需求跟踪矩阵为管理产品范围变更提供了框架。
★跟踪需求的路线包括
☆从需求到业务需求、机会、目的和目标
☆从需求到项目目标
☆从需求到项目范围/WBS中的可交付成果
☆从需求到产品设计
☆从需求到产品开发
☆从需求到测试策略和测试脚本
☆从宏观需求到详细需求
★应在需求跟踪矩阵中记录各种需求的相关属性。
☆这些属性有助于明确各项需求的关键信息。
☆需求跟踪矩阵中的典型属性包括：独特的标识标志、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、现状（如活跃中、已取消、已推迟、新增
加、已批准）和实现日期。
☆为确保干系人满意，可能需增加的补充属性包括：稳定性、复杂程度和验收标准。
5.2 定义范围
★定义范围是制定项目和产品详细描述的过程。
☆详细项目范围说明书的编制，对项目成功至关重要。
☆应该根据项目启动过程中记载的主要可交付成果、假设条件和制约因素，来编制项目范围说明书。
☆在规划过程中，由于对项目有了更多的了解，所以应该更具体地定义与描述项目范围。
☆应该分析现有风险、假设条件和制约因素的完整性，并在必要时补充其他风险、假设条件和制约因素。
5.2.1定义范围：输入
1.项目章程
★项目章程中包含对项目和产品特征的概括性描述，以及项目审批要求。
☆如果执行组织不使用项目章程，则应取得或编制类似的信息，并用作制定详细范围说明书的基础。
2.需求文件
3.组织过程资产
★可能影响定义范围过程的组织过程资产包括
☆用于制定项目范围说明的政策、程序和模板；
☆以往项目的项目档案
☆以往阶段或项目的经验教训
5.2.2 定义范围：工具与技术
1.专家判断
★专家判断常用来分析制定项目范围说明书所需的信息。
★专家判断和专业知识可用来处理各种技术细节。
2.产品分析
★对于那些以产品为可交付成果的项目（区别于提供服务或成果的项目），产品分析是一种有效的工具。
☆每个应用领域都有一种或几种普遍公认的、把概括性的产品描述转变为有形的可交付成果的方法。
☆产品分析技术包括产品分解、系统分析、需求分析、系统工程、价值工程和价值分析等。
3.备选方案识别
★备选方案识别是用来为项目工作提出不同执行方法的一种技术。
☆有许多通用管理技术都可用于备选方案识别，如头脑风暴、横向思维和配对比较。
4.引导式研讨会
5.2.3定义范围：输出
1.项目范围说明书
★项目范围说明书详细描述项目的可交付成果，以及为提交这些可交付成果而必须开展的工作
☆项目范围说明书也表明项目干系人之间就项目范围所达成的共识。
☆为了便于管理干系人的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。
☆项目范围说明书使项目团队能开展更详细的规划，并可在执行过程中指导项目团队的工作。
☆它还为评价变更请求或额外工作是否超出项目边界提供基准。
★项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度。
★详细的项目范围说明书包括以下内容
☆产品范围描述。
逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征。
☆产品验收标准
定义已完成的产品、服务或成果的验收过程和标准。
☆项目可交付成果。
可交付成果既包括组成项目产品或服务的成果，也包括各种辅助成果，如项目管理报告和文件。
对可交付成果的描述可详可略。
☆项目的除外责任。
通常需要识别出什么是被排除在项目之外的。
明确说明那些内容不属于项目范围，有助于管理干系人的期望。
☆项目制约因素。
列出并说明与项目范围有关、且限制项目团队选择的具体项目制约因素。
例如，客户或执行组织实现确定的预算、强制性日期或强制性进度里程碑。
如果项目是根据合同实施的，那么合同条款通常也是制约因素。
有关制约因素的信息可以列入项目范围说明书，也可以对立成册。
☆项目假设条件。
列出并说明与项目范围有关的具体假设条件，以及万一不成立而可能造成的后果。
在项目规划过程中，项目团队应该经常识别、记录并验证假设条件。
有关假设条件的信息可以列入项目范围说明书，也可以对立成册。
2.项目文件（更新）
★可能需要更新的项目文件包括
☆干系人登记册
☆需求文件
☆需求跟踪矩阵
5.3 创建工作分解结构
★创建工作分解结构是把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分。
☆工作分解结构是以可交付成果为导向的工作层级分解
☆其分解的对象是项目团队为实现项目目标、提交所需可交付成果而实施的工作。
☆工作分解结构每下降一个层次就意味着对项目工作更详尽的定义。
☆工作分解结构组织并定义项目的总范围，代表着现行项目范围说明书所规定的工作。
★计划要完成的工作包含在工作分解结构最底层的组成部分中，这些组成部分称为“工作包”。
☆可以针对工作包安排进度、估算成本和实施监控。
☆在“工作分解结构”这个词中，“工作”是指经过努力所取得的成果，如工作产品或可交付成果，而非“努力”本身。
5.3.1创建工作分解结构：输入
1.项目范围说明书
2.需求文件
3.组织过程资产
5.3.2创建工作分解结构：工具与技术
1.分解
★分解就是把项目可交付成果划分为更小的、更便于管理的组成部分，直到工作和可交付成果被定义到工作包得层次。
☆工作包是工作分解结构的最底层，是能可靠地估算和管理工作成本和活动持续时间的位置。
☆工作包的详细程度因项目大小与复杂程度而异。
★要把整个项目工作分解成工作包，一般需开展下列活动：
☆识别和分析可交付成果及相关工作
☆确定工作分解结构的结构与编排方法
☆自上而下逐层细化分解
☆为工作分解结构组成部分制定和分配标识编码
☆核实工作分解的程度是必要且充分的
★工作分解结构可以采用多种形式
☆把项目生命周期的各阶段作为分解的第一层，把产品和项目可交付成果放在第二层。
☆把主要可交付成果作为分解的第一层。
☆按子项目进行第一层分解。
子项目（如外包工作）可能由项目团队之外的组织实施。
作为外包工作的一部分，卖方需指定所承包工作的工作分解结构。
★对工作分解结构上层的组成部分进行分解，就是要把每个可交付成果或子项目都分解为基本的组成部分，即可核实的产品、服务或成果。
☆工作分解结构可以采用列表式、组织结构图式、鱼骨图式或其他方式。
☆通过确认WBS下层的组成部分是完成上层相应可交付成果的必要且充分的工作，来核实分解的正确性。
★不同的可交付成果可以分解到不同的层次。
☆某些可交付成果只需分解一层，即可到达工作包的层次，而另一些则需分解更多层。
☆工作分解得越细，对工作的规划、管理和控制就越有力。
☆但是，过细的分解会造成管理努力的无效耗费、资源使用效率低下以及工作实施效率低。
★滚动式规划
☆要在未来远期才完成的可交付成果或子项目，当前可能无法分解。
☆项目管理团队通常要等到这些可交付成果或子项目的信息足够明确后，才能制定出工作分解结构中的相应细节。
★100%规则
☆工作分解结构包含了全部的产品和项目工作，包括项目管理工作。
☆通过把工作分解结构底层的所有工作逐层向上汇总，来确保没有遗漏工作，也没有增加多余的工作。
☆这有时被称为100%规则。
5.3.3创建工作分解结构：输出
1.工作分解结构
★工作分解结构是以可交付成果为导向的工作层级分解。
☆其分解的对象是项目团队为实现项目目标、提交所需可交付成果而实施的工作。
☆工作分解结构每向下分解一层，代表着对项目工作更详细的定义。
★为工作包建立控制账户，并根据“账户编码”分配标识号，是创建工作分解结构的最后步骤。
☆这些标识号为汇总成本、进度与资源信息建立了层级结构。
★控制账户是一种管理控制点。
☆在该控制点上，把范围、成本和进度加以整合，并把他们与挣值相比较，以测量绩效。
☆控制账户设置在工作分解结构中的特定管理节点上。
☆每一个控制账户都可以包括一个或多个工作包，但是每一个工作包只能属于一个控制账户。
2.工作分解结构词典
★工作分解结构词典是在创建工作分解结构过程中产生并用于支持工作分解结构的文件。
☆工作分解结构词典对工作分解结构组成部分（包括工作包和控制账户）进行更详细的描述。
★工作分解结构词典的内容包括：
☆账户编码标识号
☆工作描述
☆负责的组织
☆进度里程碑清单
☆相关的进度活动
☆所需的资源
☆成本估算
☆质量要求
☆验收标准
☆技术参考文献
☆合同信息
3.范围基准
★范围基准是项目管理计划的组成部分
★范围基准包括
☆项目范围说明书。
项目范围说明书包括产品范围描述和项目可交付成果，并定义用户对产品的验收标准。
☆工作分解结构。
工作分解结构定义每一项可交付成果，并把可交付成果分解为工作包。
☆工作分解结构词典。
工作分解结构词典对每一个工作分解结构要素的工作和技术文件做详细说明。
4.项目文件（更新）
★可能需要更新的项目文件包括需求文件
☆如果在创建工作分解结构过程中提交了变更请求并获得批准，那么应当更新需求文件，以反映经批准的变更。
5.4 核实范围
★核实范围是正式验收项目已完成的可交付成果的过程。核实范围包括：
☆与客户或发起人一起审查可交付成果
☆确保可交付成果已圆满完成，并获得客户或发起人的正式验收。
★范围核实与质量控制的不同之处在于
☆范围核实主要关注对可交付成果的验收
☆而质量控制则主要关注可交付成果是否正确以及是否满足质量要求。
☆质量控制通常先于范围核实进行，但两者也可同时进行。
5.4.1核实范围：输入
1.项目管理计划
★项目管理计划中包含范围基准
☆项目范围说明书
☆工作分解结构
☆工作分解结构词典
2.需求文件
★需求文件列明了全部项目、产品和技术需求，以及项目和产品需求必须满足的其他需求，连同相应的验收标准。
3.需求跟踪矩阵
★需求跟踪矩阵连接需求和需求源，用于在整个项目生命周期中对需求进行跟踪。
4.确认的可交付成果
★确认的可交付成果是指已经完成并经过实施质量控制过程检验合格的可交付成果。
5.4.2核实范围：工具与技术
1.检查
★检查是指开展测量、审查与核实等活动，来判断工作和可交付成果是否符合要求及产品验收标准。
☆检查有时也被称为审查、产品审查、审计和巡检等。
5.4.3核实范围：输出
1.验收的可交付成果
★符合验收标准的可交付成果应该由客户或发起人正式签字批准。
☆应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。
☆这些文件将提交给结束项目或阶段过程。
2.变更请求
★对已经完成但为未通过真实验收的可交付成果及其未通过验收的原因，应该记录在案；
☆并提出适当的变更请求，以便进行缺陷补救。
☆变更请求应由实施整体变更控制过程审查与处理。
3.项目文件（更新）
★作为核实范围过程的结果，可能需要更新的项目文件包括定义产品或报告产品完成情况的任何文件。
5.5 控制范围
★控制范围就是监督项目和产品的范围状态、管理范围基准变更的过程。
☆对项目范围进行控制，就必须确保所有请求的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程的处理。
☆在变更实际发生时，也要采用范围控制过程来管理这些变更。
☆控制范围过程需要与其他控制过程整合在一起。
☆未得到控制的变更通常称为项目范围蔓延。
☆变更不可避免，因而必须强制实施某种形式的变更控制。
5.5.1控制范围：输入
1.项目管理计划
★项目管理计划中包含以下可用来控制范围的信息：
☆范围基准。
用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
☆范围管理计划。
范围管理计划描述如何管理和控制项目范围。
☆变更管理计划
变更管理计划定义管理项目变更的过程。
☆配置管理计划
配置管理计划定义配置项，定义需要正式变更控制的内容，并为这些配置项和内容制定变更控制过程。
☆需求管理计划。
需求管理计划说明将如何规划、跟踪和汇报需求活动，以及如何启动对产品、服务或成果需求的变更。
需求管理计划还会说明将如何分析变更的影响以及谁有权批准这些变更。
2.工作绩效信息
★工作绩效信息是关于项目进展情况的信息，如那些可交付成果已开始，其进展如何，那些可交付成果已完成等。
3.需求文件
4.需求跟踪矩阵
5.组织过程资产
★可能影响控制范围过程的组织过程资产包括
☆现有正式和非正式的、与范围控制相关的政策、程序和指南
☆可用的监督和报告方法
5.5.2控制范围：工具与技术
1.偏差分析
★可利用项目绩效测量结果，来评估偏离范围基准的程度。
☆确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。
5.5.3控制范围：输出
1.工作绩效测量结果
★工作绩效测量结果包括计划与实际技术性能的对比，或其他的范围绩效测量结果。这些信息需要记录下来并传递给相关干系人。
2.组织过程资产（更新）
★可能需要更新的组织过程资产包括
☆造成偏差的原因；
☆所选的纠正措施及其原因
☆从项目范围控制中得到的其他经验教训。
3.变更请求
★通过范围绩效分析，可能会提出对范围基准或项目管理计划其他组成部分的变更请求。
☆变更请求包括预防措施、纠正措施和缺陷补救。
☆变更请求需要由实施整体变更控制过程来审查和处理。
4.项目管理计划（更新）
★范围基准（更新）
☆如果批准的变更请求会对项目范围产生影响，那么范围说明书、工作分解结构及工作分解结构词典都需要重新修订和发布，以反映这些批准的变更。
★其他基准（更新）
☆如果批准的变更请求会对项目范围产生影响，那么相应的成本基准和进度基准也需要重新修订和发布，以反映这些批准的变更。
5.项目文件（更新）
★可能需要更新的项目文件包括
☆需求文件
☆需求跟踪矩阵
