PMP/高项 项目范围管理

项目范围管理

概念

确保项目做而且只做成功完成项目所需的全部工作的各过程。管理项目范围主要是在定义和控制哪些工作应该包括在项目内，哪些不应包括在项目内。

最好就是做且只做范围内的事情

内容

项目范围管理内容

作用

• 为项目实施提供工作范围的框架

• 提高资金、时间、人力和其他资源估算的准确性

• 确定进度测量和控制的基准，便于对项目的实施进行有效的控制

• 有助于清楚地分派责任

过程

刚拿到PMBOOK的时候，感觉真是无从下手，这个过程、输入、输出、技术与工具到底代表什么，有种不知道讲的都是些什么玩意的感觉。

过程：其实就是一个管理的操作步骤，项目管理过程，就是项目管理该执行的操作。

输入：就是执行这个操作，需要的东西或者前置条件。

技术与工具：就是在执行操作过程中运用到的思想、方法、表格、应用软件等

输出：就是这个操作完成后会产出什么东西（一般都是各种文档），或者相应可交付、可度量的东西。

规划范围管理

规划范围管理：是创建范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，在整个项目中对如何管理范围提供指南和方向。

规划好项目范围该如何管理，可以有效的减少项目范围蔓延的风险，计划好范围管理该做的事情，可以让我们对于项目中遇到与范围相关的内容可以有明确的指导做法。客户认可的管理计划可以让我们沟通实施起来更加通畅，减少扯皮。

输入

项目管理计划：依据项目管理计划中已批准的子计划来创建范围管理计划

项目章程：项目章程提供了高层级的项目描述和产品特征

事业环境因素

组织过程资产

工具技术

专家判断-专家判断是指由具备相关知识和经验的各方所提供的意见

会议-项目团队可以参加项目会议来制定范围管理计划

输出

范围管理计划：是项目或项目集管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。

主要内容：制定项目范围说明书；根据详细项目范围说明书创建
WBS；确定如何审批和维护范围基准；正式验收已完成的项目可交付成果

需求管理计划：需求管理计划是项目管理计划的组成部分，描述将如何分析、记录和管理项目和产品需求。

主要内容：如何规划、跟踪和报告各种需求活动；配置管理活动；需求优先级排序过程；测量指标及使用这些指标的理由；反映哪些需求属性将被列入跟踪矩阵的跟踪结构

收集需求

**需求：指发起人、客户和其他干系人的已量化且记录下来的需要与期望。**让干系人积极参与需要发掘和分解工作（分解成需求），并仔细确定、记录和管理对产品、服务或成果的需求，能直接促进项目成功。需求是工作分解结构的基础。成本、进度和质量规划也都要在这些需求的基础上进行。

收集需求：为实现项目目标而定义并记录干系人的需求的过程，旨在定义和管理客户期望。

收集需求的重点是工具与技术，在实际应用中该怎么沟通，和选择采用哪种方法与客户沟通非常重要。在大项目中也有专业的BA来做需求分析，分析完成后也有相应的需求评审，评审过后的需求才拿给开发来做相应的设计。但在小项目中，只能项目经理来做兼职了，这就要求项目经理不仅要把管理做好，还要把需求和技术连接起来，相当的High。

输入

范围管理计划–范围管理计划使项目团队知道应该如何确定所需收集的需求的类型

需求管理计划–需求管理计划规定了用于整个收集需求过程的工作流程，以便定义和记录干系人的需要

干系人管理计划

项目章程–可从项目章程中了解总体项目需求以及关于项目产品的总体描述，并据此制定详细的产品需求

干系人登记册–可用来识别那些能提供详细的项目和产品需求信息的干系人

技术与工具

收集需求主要是在于应用方面，所以对如何操作这个过程要求很高，合理的应用以下方法，了解相应方法的优点，缺点，来决定方法的应用场景。除了下面这些，还有其他的很多方法，但在实际中，掌握好几种常用的，并把它们运用熟练更重要。

1．访谈——一对一的交谈，可以挖出客户更深层次的需求。

2．焦点小组会议——召集预先选定的干系人和主题专家，了解他们对所提议产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。

3．引导式研讨会——快速定义跨职能需求和协调干系人差异的重要技术。召集主要干系人集中讨论定义产品需求。

4．群体创新技术——常用的群体创新技术：

• 头脑风暴法：产生和收集对项目需求与产品需求的多种创意

• 名义小组技术：通过投票来排列最有用的创意。是头脑风暴法的深化应用。

• 概念/思维导图：把从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。

• 德尔菲技术：由一组选定的专家回答问卷，并对每一轮需求收集的结果再给出反馈，专家的答复只能交给主持人，以保持匿名状态

• 亲和图法（KJ法/Affinity
  Diagram）:把大量收集到的事实、意见或构思等语言资料，按其相互亲和性（相近性）归纳整理这些资料，使问题明确起来，求得统一认识和协调工作，以利于问题解决的一种方法。

• 多准则决策分析：借助决策矩阵，用系统分析方法建立如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序。

5．群体决策技术——为达成某种期望结果而对多个未来行动方案进行评估。

• 一致同意

• 大多数原则

• 相对多数原则

• 独裁

6．问卷调查——通过设计书面问题，向受访者快速收集信息。

7．观察——直接观察个人在各自的环境中如何开展工作和实施流程。当产品使用者难以或不愿说明他们的需求时，需要通过观察来了解细节。观察也称为“工作跟踪”。

8．原型法——在实际制造产品之前，先造出该产品的实用模型，并据此征求对需求的反馈意见。在经过足够的重复之后，就可以从原型中获得足够完整的需求，并进而进入设计或制造阶段。

9．标杆对照——将实际或计划的项目做法与可比项目的做法进行对照，以便识别最佳实践，形成意见，并为绩效考核提供依据。

输出

• 需求文件：描述各种单一的需求将如何满足与项目相关的业务需求。

只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。

这里有一个SMART原则：一般来描述项目目标需要符合的标准，在需求中也适用：

Simple：简单易懂，太复杂的目标无法凝聚项目团队人心。

Measurable：结果可测，即可以用量化的标准去检验成败。

Achievable：力所能及，即达到目标的途径必须是可行的。

Relavent：符合利益，当然是符合干系人共同的相关利益；

Time Frame：阶段性的，可以分阶段实现，积小胜为大胜。

主要内容：

业务需求–整个组织的高层级需要，在银行里科技就是为业务服务的

干系人需求–干系人提出的与项目相关的需求

解决方案需求–为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征

过渡和就绪需求–这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力，如数据转换和培训需求。

项目需求–项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素等。

质量需求-用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准

• **需求跟踪矩阵：**是一张连接需求与需求源的表格，以便在整个项目生命周期中对需求进行跟踪

作用：

把每一个需求与业务目标或项目目标联系起来，有助于确保每一个需求都具有商业价值。

为管理产品范围变更提供了框架。

应记录各项需求的相关属性。这些属性有助于明确各项需求的关键信息。）

定义范围

定义范围：制定项目和产品详细描述的过程。

主要作用：明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确项目、服务或成果的边界。

定义范围在范围管理中就是决定我们项目该干多少事情的过程了，虽然项目是渐进明细的，但大体范围是不变的。把需求定在一个可控的，让人舒适的范围会让项目更好做一些。这个范围定义的时候尽量不要比实际少，该算工作量的就该把工作量统计出来。

输入

范围管理计划–是项目管理计划的组成部分，确定了制定、监督和控制项目范围的各种活动。

项目章程–对项目和产品特征的概括性描述，以及项目审批要求。

需求文件

组织过程资产

①用于制定项目范围说明书的政策、程序和模板；

②以往项目的项目档案；

③以往阶段或项目的经验教训。

技术与工具

产品分析：对于那些以产品为可交付成果的项目（区别于提供服务或成果的项目），为开发一个更好、更明确的项目结果而进行的分析。如产品分解、系统分析、系统工程、价值工程、价值分析

备选方案的识别：实现项目的目标成果并不局限一种方案，为了防范风险我们常常要准备许多备选方案

专家判断：由来自项目内部和外部的具备专业知识或受过专门培训的人组成一个专家小组，该小组的成员凭借其专业知识和经验对所获得的信息进行分析和判断，以决定是否批准某项决议或采取某种措施

引导式研讨会：这个在收集需求里就有

输出

项目范围说明书

• 详细说明项目的可交付成果和为提交这些成果而必须开展的工作

• 是干系人对项目范围的共同理解，说明了项目的主要目标

• 是项目团队能够实施更详细的规划，在执行过程中指导项目团队的工作

• 构成了评价变更请求或增加的工作是否超出了项目边界的基准

更新的项目文件

干系人登记册、需求文件、需求跟踪矩阵

创建WBS

WBS-Work Breakdown Structure
工作分解结构，这个直接翻译真是蛋疼，感觉肯定是找不出来更好的名字了，只能这么叫着了。

创建WBS：是把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分的过程。

WBS：以可交付成果为导向的工作层级分解，其分解的对象是项目团队为实现项目目标、提交所需可交付成果而实施的工作

工作包：计划要完成的工作包含在WBS最底层的组成部分。

控制账户CA：**项目成本核算中使用的 WBS
组成部分，**每个工作包都是控制账户的一部分，而控制账户则是一个管理控制点。在该控制点上，把范围、预算和进度加以整合，并与挣值相比较，以测量绩效。

WBS字典：对工作分解结构组成部分进行更详细的描述

范围基准：被批准的详细的项目范围说明书和其相关的WBS以及WBS词典
注意：

可以针对工作包安排进度、估算成本和实施监控，但并不能直接通过WBS明确人员的责任。

范围说明书和需求文件里有详细的需求内容，创建wbs也就是把需求变成了详细的工作事项，完成这个项目需要多少个步骤，就如同把大象放进冰箱需要多少步一样，然后再看每个事项方法都该包含在哪个对象中，也就是工作该分配给谁来做。这个时候项目经理对于整个项目就应该有谱了，团队整个参与wbs的编制工作，在团队成员心中也就大概能知道自己适合做项目中的哪部分工作，按wbs的工作包来界定工作范围，也避免了重复工作的可能。

输入

• 范围管理计划–定义了应该如何根据详细项目范围说明书创建WBS，以及应该如何维护和批准WBS

• 项目范围说明书

• 需求文件–需要产出什么项目结果，需要做什么来交付项目及其最终产品

• 事业环境因素

• 组织过程资产

技术与工具

分解：把项目可交付成果划分为更小的、更便于管理的组成部分，直到工作和可交付成果被定义到工作包的层次

分解到何种程度，这个是实际管理中的重点，分解的多了管不过来，分解的少了没有什么跟踪的意义，或者时间上拖太长不利于估计时间和工作量。

这在实际中感觉比较好的方法是：项目经理负责协调管理上层的，大块的内容；继续分解的任务下放到项目团队，每个人在分到上层工作包时继续分解为个人可在每周、每天把控的工作事项，最后汇总进行管理。

工作分解结构可以采用多种形式

• 把项目生命周期的各阶段作为分解的第一层，把产品和项目可交付成果放在第二层；

• 把主要可交付成果作为分解的第一层；

• 按子项目进行第一层分解。

专家判断：需要依据各种信息，把项目可交付成果分解为更小的组成部分。专家判断常用于分析这些信息，以便创建有效的WBS

专家判断也是各个地方都可以用，在实际中就是请教专业人员，谈需求就找BA，技术上就问开发，业务上就问专业的业务人员，每项工作在组织中总有擅长的人员，找这些人核对其实就是专家判断。

创建WBS方法：

方法	优点	挑战
自上而下	有利于项目现状报告	要持续关注，保证没有遗漏工作包
自下而上	从所有可交付成果和工作内容开始倒推到项目	要在编制之前确定所有的可交付成果
WBS 标准	格式固定	要求项目符合标准
WBS 模板	为创建WBS提供了一个起点	同上

• 有利于确保结构合乎逻辑

• 有利于头脑风暴，发现可交付成果

• 有利于添加新的可交付成果

• 要将WBS划分到充分细分层次，便于管理层监控

• 保证包含了所有的工作包

• 要确保工作包的汇总整合合乎逻辑

• 容易疏忽大的方面

• 增强了不同项目的一致性

• 可能会包括不必要的或遗漏一些可交付成果

• 不适合所有项目

• 有利于确定需要的细化程度

• 增强了不同项目的一致性

创建WBS原则：

• 进行充分的层次分解：分解到有利于有效管理的详细层次，既不能太小，也不能太大。

• 100%原则：下一层次是对上一层次百分之百的分解。充分、满足，没有遗漏，是WBS的核心特点。

• 滚动式规划：等到可交付成果或子项目的信息足够明确后，才能制定出工作分解结构中的细节。

• 适用于根据项目或组织的具体要求进行跟踪：提供逻辑的汇总点和控制点。

• 分解后的任务应该是：可管理的、可定量检查的、可分配任务的、独立的。

• 在适当层次分配责任：分解到一个工作可以授权一个人（部门）负责，与（RAM）和（OBS）建立关联。

注意：

• 构成WBS的是项目的工作而不是项目成果的内容

• 一个工作任务只能在WBS中出现一次

• 一个子项目的工作内容是下一级工作任务之和

输出

范围基准–经过批准的范围说明书、工作分解结构（WBS）和相应的WBS词典。

• 项目范围说明书包括产品范围描述和项目可交付成果，并定义用户对产品的验收标准。

• 工作分解结构定义每一项可交付成果，并把可交付成果分解为工作包。

• 工作分解结构词典对每一个工作分解结构要素的工作和技术文件做详细说明。

更新的项目文件

确认范围

• 范围确认是由客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收。本过程对可交付成果的确认和最终验收。

• 如果这个项目已提前终止，这个范围确认过程也应该证实并应以书面文件的形式把它的完成情况记录下来。

• 确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。经质量检查合格的可交付成果才能进行范围确认。

可交付成果有时候比较大，等最后验收的时候再确认是否符合范围，这就很爆炸。在实际中需要比可交付成果更小的粒度来进行验收和确认，减少变更的内容。在项目过程中还需要不断地完善范围，避免出现项目缺胳膊少腿在最后验收的时候才发现。

输入

• 项目管理计划-包含范围管理计划和范围基准。

• 需求文件

• 需求跟踪矩阵–连接了需求与需求源，用于在整个项目生命周期中对需求进行跟踪

• 核实的可交付成果–是指已经完成并经实施质量控制过程检验合格的可交付成果

• 工作绩效数据

技术与工具

检查：是指开展测量、审查与核实等活动，来判断工作和可交付成果是否符合要求及产品验收标准。有时也被称为审查、产品审查、审计和巡检等。

群体决策技术

这个合格不合格的话也是由客户来决定，但在验收之前，项目经理就该把整个给确认一遍，预防总是胜过事后补救。

输出

• 验收的可交付成果

①符合验收标准的可交付成果应该由客户或发起人正式签字批准。

②应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。

③这些文件将提交给结束项目或阶段过程。

• 变更请求

①对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案，并提出适当的变更请求，以便进行缺陷补救。

②变更请求应该由实施整体变更控制过程审查与处理。

• 工作绩效信息

• 项目文件更新

控制范围

控制范围：是监督项目和产品的范围状态、管理范围基准变更的过程。

对范围进行控制，就必须确保所有请求的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程的处理。

项目范围蔓延：未得到控制的变更

输入

• 项目管理计划

①范围基准（用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或采取预防措施）

②范围管理计划（描述如何管理和控制项目范围）

③变更管理计划（定义管理项目变更的过程）

④配置管理计划（定义配置项，定义需要正式变更控制的内容，并为这些配置项和内容规定变更控制过程）

⑤需求管理计划。

• 需求文件-需求应该明确（可测量且可测试）、可跟踪、完整、一致且得到主要干系人的认可。

• 需求跟踪矩阵-需求跟踪矩阵有助于发现任何变更或对范围基准的任何偏离给项目目标所造成的影响。

• 工作绩效数据

• 组织过程资产

技术与工具

偏差分析–是一种确定实际绩效与基准的差异程度及原因的技术。

①可利用项目绩效测量结果评估偏离范围基准的程度。

②确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施。（常用的偏差分析法为挣值法）

输出

• 工作绩效信息–是有关项目范围实施情况（对照范围基准）的相互关联且与各种背景相结合的信息，包括收到的变更的分类、识别的范围偏差和原因、偏差对进度和成本的影响，以及对将来范围绩效的预测。这些信息时制定范围决策的基础。

• 变更请求–对范围绩效的分析，可能导致对范围基准或项目管理计划其他组成部分提出变更请求。

• 项目管理计划更新

• 范围基准更新
  如果批准的变更请求会对项目范围产生影响，那么范围说明书、工作分解结构及工作分解结构词典都需要重新修订和发布，以反映这些批准的变更。

• 其他基准更新如果批准的变更请求会对项目范围以外的方面产生影响，那么相应的成本基准和进度基准也需要重新重新修订和发布，以反映这些批准的变更。

• 项目文件更新—需求文件和需求跟踪矩阵。

• 组织过程资产更新

实际应用

在范围管理中，范围的确定是重中之重，项目范围管理也不能按书上的照搬过来，都采用的话那可能真是全职的项目经理，但实际中的项目并不会有那么舒服的情况，但对于项目范围的管理我们也要养成思考以下问题的习惯，实际项目范围管理的过程我认为有以下事情：

1. 要干多少事情，项目有多少需求；

2. 哪些事情该干，确认项目范围内的需求；

3. 哪些事情不该干，确认项目范围除外的需求；

4. 哪些事情可以以后干，确认项目后续可以有的需求；

5. 该干的事情怎么干，分解需求、分配人力资源；

6. 东西好了最后拍板的人拍板了没有，确认范围

7. 老的事情有变化怎么办，出现了新的事情怎么办，控制项目范围。

有多少需求就是有多少活，收集需求的时候就需要和相关方好好的谈了，把各个方面利用各种手段尽可能全的将需求给收集并且描述出来。业务方面的跟业务部门的人谈，环境方面的和系统组的人谈，开发方面的和开发人员谈，确认好谁提出、谁负责、谁跟踪、谁确认、谁验收。根据描述全的需求来确定项目要干多少事情，把需求给具体化，全部记录下来。

哪些事情该干，多数时候客户的需求都是在天上的，也不是所有的需求对于项目成员都是能实现的，只有团队能够让需求实施落地的事情才是项目该做的事情。作为项目经理一定要清楚自己的团队可以干好什么样的事情，干什么样的事情效率高，质量好，干什么样的事情的事情会很爆炸。对记录下来的需求进行分析，分析该如何实现这些需求，在作为专家谈需求的时候，就需要对客户进行引导，既达到客户所需要的效果，又方便团队实施，比如客户提出一个难以实现的需求，我们可以根据上层需求提供容易实现的建议方案；再比如由于资源协调等原因不好实现的需求，是不是可以延后或者取消。

哪些事情不该干，就需要我们确定好除外责任，就是这个东西我们说好就是不做的。虽然我们多数时候是确认好我们要做的就好了，但是不该干的事情，不包括在项目范围内的事情提前说明清楚的话会省很多扯皮的事情，而且对于分析该干的事情里面，也一定要同时分析这个内容里不干的事情才行，同时确认好你的理解和客户的理解一定是一致的，最好落在纸上。曾经碰上个事情：客户要求做一个网站，网站对于我们的理解就是网页端嘛，非常简单，谈需求的时候就没有想那么多，和开发说明的时候也没想那么多，在验收的时候，客户结果是用手机打开的！没错，用手机打开的，发现页面全是乱的。我们说只做了能电脑看的，客户说现在谁还不用手机看！就要重新把项目给改一遍了。这种隐含的意思一定要注意了

哪些事情可以以后干，在和客户谈需求的时候，需要深入的理解客户所需。作为领域专家的话也需要有服务意识，提供可以拿出的最好的，最优质的服务给客户，帮助他们分析和提出其他需求，确认哪些需求可以做为这次项目之后的延伸。这些事情可以是由于工期紧的原因，单后续必须要做的事情，可以是过程中发现的可优化内容，可以是其他与项目相关的事情。为项目考虑，为客户考虑，都是为了把事情做到尽善尽美，提高相关方整体的满意程度。

该干的事情怎么干，客户的需求都是大体上的，概括性的，而对于项目来说需求必须转化为事情，事情怎么干同样需要与客户洽谈说明并且由客户确认。因为如果需求是服务方面的，客户当然可能对于你怎么提供对应的服务会有所要求。对于和客户确认好的事情，需要详细明确的记录在纸面上（没有歧义），这些事情就是可以干的事情了，将事情分模块，分解开来，确认可干的人力资源，选择最合适的人力资源。

东西好了最后拍板的人拍板了没有。这就是有没有让需求落地，达到客户的预期目标的问题。包括了，阶段性的单个需求是否被满足，项目最终的整体验收是否符合要求。项目是渐进明细的，需求是分解的，分解完成的单个需求是否都符合要求将决定项目整体是否符合客户需求。在完成单个需求的时候及时与客户沟通确认，确认是否符合要求非常重要，可以避免后续一次性验收的大改。虽然客户不一定会全程跟项目，但也必须要在重要阶段参与项目，若不参与其中的风险跟客户说明清楚，相信客户也会有所考量，毕竟一般项目投入的资源都不少，达不到想要的效果会很亏。

老的事情有变化怎么办，出现了新的事情怎么办。这个问题一定要在项目初期与客户沟通清楚，确认好应有的方案，达成共识。项目需求、事情有变化很正常，有些项目时间短，发生变化的可能性不大，但有些项目时间长发生变化的概率就大了，取消的也有可能。大家都认可的变化，走变更流程，该加钱加人的加钱加人，不该被接收的变化，就需要好好的拒绝一下。新的事情可以往后调整排期，可以加人、加班赶工，也可以只登记一下，不做处理。

对于项目范围和需求的事情，最重要的就是和客户达成一致的认可，思想上的统一。项目的范围控制在项目的整个生命周期都该进行全方位的把控，也就是项目经理必须要对哪些事情该干，哪些事情不该干有一个非常清晰明确的把控。

项目范围把控的好不好，将决定你下面的人将要干多少活，会活成啥样。作为一个项目经理，项目上干多少活都是谈出来的，如果你是开发可能感觉项目经理所做的事情不多，但是实际上项目经理是以另一种形式来影响项目，也将直接决定开发要干多少的活。若项目经理没有控制好项目范围，累死开发也干不完需求，求你的项目经理当个好人吧，不要乱答应需求，不然把大家都埋进去坑也填不完。

思维导图