项目管理师备考笔记：十大管理之范围管理

范围管理的重要性（范围是基础性和全局性的工作）：

1.项目范围来自于项目目标,完成项目工作范围是为了实现项目目标

2.项目范围管理及控制的有效性，是衡量项目是否达到成功的一个必要标准

3.在项目中不断重申项目工作范围，是项目中实施控制管理的一个主要手段

4.项目范围管理可以详细、清楚地界定分工界面和责任

5.项目范围管理能确定项目边界，明确主要可交付成果，范围管理能提高对项目成本、 进度和资源估算的准确性

6.项目范围管理影响到项目的成功，在实践中,范围蔓延是项目失败最常见的原因之一。

项目范围管理需要做以下三个方面的工作：

①明确项目边界 ②对项目执行工作进行监控 ③防止项目范围发生蔓延。

范围蔓延 – 未对时间、成本和资源做相应调整，未经控制的产品或项目范围的扩大。

范围镀金 – 团队内部原因造成的范围蔓延。项目人员为了“讨好”客户而做的不解决实际问题、没有应用价值的项目活动。客户没有提新需求，项目自己做了额外客户不需要工作

范围潜变----团队外部原因造成的范围蔓延。范围潜变是指客户不断提出小的、不易察觉的范围改变，如果不加控制，累计起来导致 项目严重偏离既定的范围基准，导致项目失控和失败

注：如果已经出现了范围蔓延，一样需要走变更流程

产品范围与项目范围：

①产品范围是指产品或者服务所应该包含的功能，项目范围是指为了能够交付产品， 项目所必须做的工作。

②产品范围是项目范围的基础，产品范围的定义是产品要求的描述，而项目范围的定义是产生项目管理计划的基础，两种范围在应用上有区别。

③项目的范围基准是经过批准的项目范围说明书、WBS和WBS词典。判断项目范围是否完成，要以范围基准来衡量。产品范围是否完成，则根据产品是否满足了产品描述来判断。

④产品范围描述是项目范围说明书的重要组成部分，因此，产品范围变更后，首先受到影响的是项目的范围。

启动

规划

1.规划范围管理

对如何定义、确认和控制项目范围的过程进行描述。

Input	tools&technology	Output
1.项目管理计划 2.项目章程 3.事业环境因素 4.组织过程资产	1.专家判断 2.会议	1.范围管理计划 2.需求管理计划

1.编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，在整个项目中对如何管理范 围提供指南和方向。范围管理计划需要项目管理团队全员参与。
项目范围管理计划可能在项目管理计划之中，也可能作为单独的一项。根据不同的项目，可以是详细 的或者概括的，可以是正式的或者非正式的。
范围管理计划的内容：①如何制订项目范围说明书②如何根据范围说明书创建WBS③如何维护和批准 WBS④如何确认和正式验收已完成的项目可交付成果。⑤如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相联。
2.需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求。
需求管理贯穿于整个过程，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。
需求管理计划的内容：①如何规划、跟踪和汇报各种需求活动②需求管理需要使用的资源③培训计划 ④项目干系人参与需求管理的策略⑤判断项目范围与需求不一致的准则和纠正规程⑥需求跟踪结构⑦配置管理活动| | | |

2.收集需求

为实现项目目标，明确并记录项目干系人的相关需求的过程。

Input	tools&technology	Output
1.范围管理计划 2.需求管理计划 3.干系人管理计划（规划干系人管理的输出） 4.项目章程 5.干系人登记册	1.访谈 2.焦点小组 3.引导式研讨会 4.群体创新技术 5.群体决策技术 6.问卷调查 7.观察 8.原型法 9.标杆 10.系统交互图 11.文件分析	1.需求文件 2.需求跟踪矩阵（连接需求与需求源，用于对需求进行跟踪）

1.收集需求的工具与技术有访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、问卷调查、观察、原型法、标杆对照、系统交互图、文件分析等
1）访谈：通过与干系人直接交谈来获取信息。典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。结构化–事先准备好一系列问题，有针对地进行； 非结构化–只列出一个粗略的想法，根据访谈具体情况发挥。
“一对一”，一对多、获取机密和敏感的信息，直接交谈、深入了解
2）焦点小组会议：由一位受过训练的主持人引导预先选定的干系人和主题专家（SME）进行互动式讨论。
焦点小组的参加者往往是同职能，同一领域、或有相似背景条件的人；是“一对多”的群体访谈，最终是为了获取整个焦点小组更有价值的集体意见。
3）引导式研讨会：把主要干系人召集在一起，集中讨论来定义产品需求（也需主持人）
引导式研讨会能快速定义跨职能需求和协调干系人差异，着重于形成既定目标的一致意见。
常用：
-联合应用开发JAD：常用于软件开发行业，强调由用户与项目开发团队一起共同定义需求。
-质量功能展开QFD：常用于制造行业。三步骤：1、收集客户需要 2、分类和排序3、设定目标。
-用户故事会：用于敏捷。三部分构成：干系人角色，干系人想要什么，为什么想要它
4）问卷调查：设计一系列书面问题，向众多受访者快速收集信息。
受众多样化、快速完成、成本低、地理位置分散、适合开展统计分析
缺点：缺乏灵活性、无法了解细节及更隐性的信息、干系人不重视、真实性差
5）观察：也称“工作跟踪”，直接察看个人在各自的环境中如何执行工作和实施流程。参与式和旁站式
不愿说、不能说、说不出来的需求、挖掘隐藏的需求。
6）原型法：在实际制造产品之前，先造出实用模型，据 此征求对需求的早期反馈。
步骤：①模型创建；②用户体验；③反馈收集；④原型修改；
减轻风险、渐进明细、敏捷、故事板
7）群体创新技术：组织一些群体活动来识别项目和产品需求
-头脑风暴：收集创意，不进行分析及投票或排序。
原则：庭外判决原则（不质疑、不分析、不批判、不反对）、追求数量、 各抒己见、自由鸣放、探索取长补短和改进办法
直接头脑风暴法（头脑风暴法） --尽可能激发创造性，产生尽可能多的设想；
质疑头脑风暴法（反头脑风暴法）–对提出的设想、方案逐一质疑，分析其现实可行性
-名义小组技术：促进头脑风暴，通过投票排列最有用的创意，以便进一步头脑风暴或优先排序。 是头脑风暴法的深化应用，是更加结构化的头脑风暴法；可以使那些不善言辞的参与者也能充分发表自己的意见（投票中体现）。
-德尔菲技术：一种组织专家就某一主题达成一致意见的一种信息收集技术。
专家回答问卷，并对每一轮给出反馈意见，专家的答复只能交给主持人，以保持匿名状态。
客观，但过程比较复杂，花费时间较长。
-概念/思维导图：从头脑风暴中获得的创意整合成一张图，反映创意之间的共性与差异，激发新创意。
-亲和图：从头脑风暴中获得的创意，根据相似性进行分组，以便进一步审查和分析。
-决策矩阵，用系统分析方法建立多种标准，可用于识别关键事项和合适的备选方案，并通过一系列决策对众多备选方案进行评估和排序。


8）群体决策技术：为达成某种期望结果而对多个未来行动方案进行评估。群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序。
方法：一致同意、大多数原则（半数以上）、相对多数原则（候选项超过两个）、独裁
9）标杆对照：将实际或计划做法与行业内或行业外的可比组织的做法进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。
10）系统交互图（Context Diagram）–范围模型的例子。是对产品范围的可视化描绘，显示业务系统以及与人和其他系统之间的交互方式（如： DFD、用例图等）
11）文件分析（Document Analysis） --通过分析现有文档，识别与需 求相关的信息，来挖掘需求
2.需求文件描述各种单一的需求将如何满足与项目相关的业务需求。
需求分为项目需求和产品需求：
-项目需求包括：商业需求、项目管理 需求、交付需求等。
-产品需求包括：技术需求、安全需求、性能需求等。
双向跟踪，包括正向 和反向跟踪，每个配置项的需求到其涉及的产品（或构件） 需求都要具有双向可跟踪性。
-正向跟踪：检查需求文件中的每个需求是否都能在后继工作产品（成果）中找到对应点； 以免需求被做漏、做偏
-反向跟踪：逆向跟踪， 检查设计文档、产品构件、 测试文档等工作成果是否都能在需求文件中找到出处。(是查需求源头，了解为什么要做这个需求,来源背景和原因是什么)

① 从用户原始需求可向前追溯到需求文件,可区分受变更影响的需求，确 保需求文件包括所有用户需求
② 从需求文件回溯到相应的用户原始需求，确认每个需求的出处
③ 从需求文件追溯到产品元素，可知每个需求对应的产品元素，从而确 保产品元素满足需求
④ 产品元素回溯到需求文件，使项目团队成员知道产品元素存在的原因 (如果设计元素或测试案例无法回溯到需求文件，则可能是镀金;如果孤立的产品元素是一个正当功能，则可能是需求遗漏)
⑤ 需求文件之间的跟踪,便于更好地处理各种需求之间的逻辑相关性,检查需求分解中可能出现的错误或遗漏。
3.需求跟踪矩阵表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪（能力）矩阵， 需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格。

需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（例如，进行中、已取消、已推迟、新增加、已批准、已分配、己完成等）和状态日期。

3.定义范围

制定项目和产品详细描述的过程，是明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确产品、服务或成果的边界。详细描述产品范围和项目范围，编制项目范围说明书，作为以后项目决策的基础。

Input	tools&technology	Output
1.范围管理计划 2.项目章程 3.需求文件 4.组织过程资产	1.专家判断 2.产品分析 3.备选方案生成 4.引导式研讨会	1.项目范围说明书 2.项目文件更新

1.产品分析：对于那些以产品为可交付成果的项目，是一种有效的工具。
2.备选方案生成：用来指定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法
3.项目范围说明书:是对项目范围、主要可交付成果、假设条件和制约因素的描述。记录了整个范围， 包括项目和产品范围。
内容：①产品范围描述②验收标准③可交付成果④项目的除外责任⑤制约因素⑥ 假设条件
主要作用：①确定范围②沟通基础③规划和控制依据④变更基础⑤规划基础

4.创建工作分解结构(WBS)

把整个项目工作分解为较小的、易于管理的组成部 分，形成一个自上而下的分解结构。
里程碑标志着某个可交付成果或者阶段的正式完成。重要的检查点是里程碑、重要的里程碑是基线

Input	tools&technology	Output
1.范围管理计划 2.项目范围说明书 3.需求文件 4.事业环境因素 5.组织过程资产	1.分解 2.专家判断	1.范围基准 2.项目文件更新

1.范围基准–经过批准的项目范围说明书、WBS、WBS词典，只有通过正式的变更控制程序才能进行 变更，它被用作比较的基础。
1）项目范围说明书：是对项目范围、主要可交付成果、假设条件和制约因素的描述。记录了整个范围， 包括项目和产品范围。
2）WBS–全部工作范围的层级分解（有助于防止范围蔓延）
-控制账户是一种管理控制点。在该控制点上，将范围、预算 （资源计划）、实际成本和进度加以整合，并将它们与挣值进行比 较，以测量绩效。*控制账户是WBS某个层次上的要素，既可以是工作包，也可以是比工作包更高层次上的一个要素。*如果是后一种情况，一个控制账户中就包括若干个工作包，但一个工作包仅属于一 个控制账户。项目管理团队在控制账户上考核项目的执行情况，即 在控制账户的相应要素下，将项目执行情况与计划情况进行比较，以便评价执行情况好坏，并发现与纠正偏差。
-规划包是指在控制账户之下，工作内容已知但尚缺详细进度活 动的WBS组成部分。规划包是在控制账户之下、工作包之上的WBS 要素。规划包是暂时用来做计划的，随着情况的逐渐清晰，规划包最终将被分解成工作包以及相应的具体活动。
-工作包位于工作分解结构最底层的可交付成果或项目工作组成部分。工作包应便于完整地分派给不同的人或组织单元，所以要求明确各工作单元直接的界面。工作包应该非常具体，以便承担者能明确自己的任务、努力的目标和承担的责任。作为一种经验法则，8/80规则建议工作包的大小应该至少需要8小时来完成，而总完成时间也不应该大于80小时
3）WBS词典–也称为WBS词汇表，它是描述WBS 各组成部分的文件。针对每个WBS组件，可能包括账户编码标识、工作描述、假设条件和制约因素、负责人或组织单元、进度里程碑、 相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等，是详细描述可交付成果、活动和进度信息的文件（有助于评价变更的影响
4）WBS的建立
-分解是一种将项目可交付成果和项目工作分解成 较小的、更易于管理的组件的技术。要将整个项目工作分解为工作包，需要开展以下活动：
①识别和分析可交付成果及相关工作。 ②确定WBS的结构和编排方法。 ③自上而下逐层细化分解。 ④为WBS组件制定和分配标识编码。⑤核实可交付成果分解的程度是恰当的
-创建WBS时对工作的划分原则包括：
①功能或者技术原则。在创建WBS时，需要考虑 将不同人员的工作分开。 ②组织结构③系统或者子系统。总的系统划分为几个主要的子系统，然后对每个子系统再进行分解。
-WBS分解的方法
①项目生命周期的各阶段作为分解的第二层，产 品和项目可交付成果放在第三层
②主要可交付成果作为分解的第二层
③整合可能由项目团队以外的组织来实施的各种 组件（例如，外包工作），然后作为外包工作的一部分，卖方需编制相应的合同WBS。
-WBS表示形式有分级的树型结构（组织结构图式）和表格形式（列表式）。
树型结构图的WBS层次清晰、直观性和结构性强，但不容易修改，对大的、复杂的项目很难表示出项目的全貌。
表格形式的直观性比较差，但能够反映出项目所有的工作要素（大项目）。
也有鱼骨图形式，但不常见。
-WBS分解注意8个方面：
①WBS必须是面向可交付成果的。
②WBS必须符合项目的范围。
③WBS的底层应该支持计划和控制
④WBS中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个人参与。
⑤WBS的指导，WBS应控制在4〜6层。
⑥WBS应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作。
⑦WBS的编制需要所有（主要）项目干系人的参与， 需要项目团队成员的参与。
⑧WBS并非是一成不变的。在完成了WBS之后的工作中，仍然有可能需要对WBS进行修改。
补充：
（1）在层次上保持项目的完整性，避免遗漏必 要的组成部分。
（2）—个工作单元只能从属于某个上层单元， 避免交叉从属。
（3）相同层次的工作单元应用相同性质。
（4）工作单元应能分开不同的责任者和不同的 工作内容。
（5）便于项目管理计划和项目控制的需要。
（6）最底层工作应该具有可比性，是可管理的， 可定量检查的。
（7）应包括项目管理工作，包括分包出去的工作。

执行

监控

5.确认范围

正式验收已完成的可交付成果。确认范围应该贯穿项目的始终。
确认范围的步骤：
①确定需要进行范围确认的时间
②识别范围确认需要哪些投入
③确定范围正式被接受的标准和要素
④确定范围确认会议的组织步骤
⑤组织范围确认会议。

确认范围与项目收尾的不同之处在于：
①虽然确认范围与项目收尾工作都在阶段未进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目（或阶段）所要做的流程性工作。
②确认范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品。

范围确认完成时，同时应当对确认中调整的WBS及WBS字典进行更新。

确认范围与质量控制的不同之处在于：
①确认范围主要强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求（质量标准）。
②质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行,而质量控制并不一定 在阶段未进行。
③质量控制属内部检查，由执行组织的相应质量部门实施；确认范围则是由外部干系人（客户或发起人）对项目可交付成果进行检查验收

Input	tools&technology	Output
1.项目管理计划 2.需求文件(做验收参考) 3.需求跟踪矩阵 4.核实的可交付成果（控制质量的输出） 5.工作绩效数据	1.检查 2.群体决策技术	1.验收的可交付成果 2.变更请求 3.工作绩效信息 4.项目文件更新

1.检查也称为审查、评审、审计、走查、巡检、测试等，是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。

6.范围控制

控制范围是监督项目和产品的范围状态、管理范围基准变更的过程，其主要作用是在整个项目期间 保持对范围基准的维护。对项目范围进行控制，就必须确保所有请求的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程的处理。在变更实际发生时，也要采用范围控制过程来管理这些变更。
范围变更控制的工作： ①影响导致范围变更的因素，并尽量使这些因素向有利的方面发展。 ②判断范围变更是否已经发生。③范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理

Input	tools&technology	Output
1.项目管理计划 2.需求文件 3.需求跟踪矩阵 4.工作绩效数据 5.组织过程资产	1.偏差分析（非计算，只是针对工作包）	1.工作绩效信息 2.变更请求 3.项目管理计划更新 4.项目文件更新 5.组织过程资产更新

项目范围管理案例分析：
范围管理可能问题： ①没有挖掘到全部隐性需求，缺乏精确的范围定义；②没有有效的范围管理，造成二次变更；③对范围 控制不足；④没有和客户进行需求确认。⑤没有对风险进行有效管理⑥没有对质量进行有效控制
范围管理应对措施： ①对项目范围进行清晰定义，并根据定义对工作进行分解，制定WBS；②对项目进行合理估算，对工作 量有量化的把握；③对项目范围进行有效控制；④重新定义项目范围必须得到高层和客户的确认；⑤进行沟通管理，协调多个项目干系人之间的矛盾。

收尾

---