9.2 项目范围管理
项目范围管理是为了实现项目的目标，对项目的工作内容进行控制的管理过程。它包括范围的界定，范围的规划，范围的调整等。
项目范围是指为了成功达到项目的目标，所必须完成的工作。简单地说，确定项目范围就是为项目界定一个界限，确定哪些方面是属于项目应该做的，哪些不应该包括在项目之内，从而定义项目管理的工作边界，明确项目的目标和主要的项目可交付成果。
在项目环境中，“范围”（Scope）一词包括两方面的含义，一是产品范围，即 IT 服务项目“产 品”即是服务，所包含的特征、功能以及需达到的级别；二是项目范围，即为交付具有规定特征和功能的产品（即服务）所必须完成的工作。在确定范围时首先要确定最终产生的是什么，它通常以服务级别协议的形式明确的记录在服务协议中（Service Agreement，简称 SA）。要注意的是 SA必须要清晰明确，以被客户认可的形式表达出来，比如文档、图表或某种已定义的标准文件，确保所有项目干系人对 SA 的理解达成一致。在此基础之上，才能进一步明确，需要做什么工作才能产生所需要的产品（即服务）。也就是说产品范围决定项目范围。
本章的主要内容包括： - 收集需求：为实现项目目标而定义并记录干系人的需求的过程；
- 定义范围：制定项目和产品详细描述的过程；
- 创建工作分解结构（Work Breakdown Structure，简称 WBS）：将项目可交付成果和项目工作分解为较小的、更易于管理的组成部分的过程；
- 核实范围：正式验收项目已完成的可交付成果的过程；
- 控制范围：监督项目和产品的范围状态、管理范围基准变更的过程。
下图是一个范围管理过程的流程图，表达了这些过程和它们的输入、输出，以及与其他知识领域过程之间的关系。
这些过程之间及其与其他领域的过程之间彼此互相影响。根据项目需要，每个过程可能会需要一个或多个个体或团体的努力。一般来说，在每个项目阶段，每个过程通常至少发生一次。
尽管这里提到的这些过程是作为各自独立的组成部分给予了明确的界定，但是，在实践中它们是以各种形式重叠和相互影响的。
在项目背景下，范围这个术语可指： - 产品范围：表示产品即服务的特性和功能。IT服务产品范围包含系统效能、平均无故障时间、设备范围、用户范围等指标的描述，即服务所包含的特征、效果和感受等;
- 项目范围：为了完成具有所规定特征和功能的产品必须完成的工作，其中一些工作的内容和执行标准通常在运营级别协议（Operational Level Agreement，简称 OLA）中有明确描述。项目范围是否完成，以项目管理计划验收作为衡量标准；而产品范围是否完成，以客户的业务需求达成作为衡量标准。两种范围管理需要很好地集成起来，以确保项目工作能产生所规定的产品并准时交付。
项目的几个生命周期阶段和管理过程，项目的一次性及临时性，共同决定了项目的工作范围都是有限的、可控的，不是无限制的和无序的。
项目范围的定义可以是广义的，也可以是狭义的，根据项目不同、管理层的需要不同，再集中结合具体项目的特点进一步阐述。既然完成项目工作范围是为了实现项目目标，那么如何有效地、全部地完成项目范围内的每项工作，是每个项目管理者不得不思考的问题。因此对项目范围管理及控制的有效性，是衡量项目是否成功的一个必要标准，项目范围的管理不仅是项目管理计划的一个主要部分；同时在项目中不断地重申项目工作范围，有利于项目不偏离轨道，是项目中实施控制管理的一个主要手段。
项目范围管理不仅是让项目管理和实施人员知道为达到预期目标需要完成哪些具体的工作，还要清楚项目相关各方在每项工作中清晰的分工界面和责任。详细、清楚地界定分工界面和责任，不但利于项目实施中的变更管理和推进项目发展，减少责任不清的事情发生，也便于项目结束时项目范围清晰地确认。如一个核心机房运维项目，包含有网络设备、小型机和 ERP 软件等，集成商提供设备和安装，客户提供项目实施场所，软件供应商负责软件开发和各项应用实施，IT 服务供应商负责系统整体运维，到底每一方要完成哪些工作，这些工作彼此间的界限如何（含时间界限等），要确认得很清楚，以便可以很快找到具体的责任人并及时提出解决方案，同时能够回避一些不必要的风险。
项目范围的来源，一般而言是客户的一个明确的项目目标或具体需求，任何一个项目的启动过程都有其明确的目的（或目标），因此在讨论项目范围管理的时候，不可能脱离项目的目标。
在项目范围管理过程中，最常用，也是必须要熟悉的工作分解方法是 WBS。WBS是一种以结果为导向的分析方法，用于分析项目所涉及的工作，所有这些工作构成了项目的整个工作范围。WBS为项目进度、成本、变更的计划和管理提供了基础。制定工作分解结构的必需完成工作包括：识别和分析可交付物、确定工作分解的结构和排序方法、自上而下细化分解工作、为工作包分配标识编码、核实工作包是否充分且必要。
项目范围确认是指项目干系人对项目范围对正式承认，但实际上项目范围确认是贯穿整个项目生命周期，从开始项目管理组织确认 WBS 的具体内容，到项目各个阶段的交付物检验，直至最后项目收尾文档验收，甚至是最后项目评价的总结。
项目范围变更控制实际发生在项目实施阶段，也就是计划执行阶段，只有具体实施项目，才有可能产生项目范围的变更，因为项目环境、资源水平和管理能力等因素会造成项目范围在实施过程中的增加或减少。对项目范围变更控制的主要工具是建立并运用项目变更控制系统，规范变更控制，划清相关责任。往往由于多种因素造成项目需求的模糊和不断的更改，从而给项目增加了控制难度和风险，因此，这就更需要项目管理者发挥其应有的能力和作用，做好项目的控制工作和管理工作。
9.2.1 需求收集
定义和管理项目范围影响到整个项自的成功与否。如：一个重要的项目需要做正式的、仔细的和时间性强的范围计划。常规项目则很少需要文档和详细审查。需求收集是项目管理小组为制定范围管理计划需要做的首要工作。需求收集可以帮助团队定义项目范围，制订详细的范围说明书，定义和编制工作分解结构，验证和控制范围。
（1）需求收集的输入
收集需求是为实现项目目标而定义并记录干系人的需求的过程。仔细掌握和管理项目需求与产品需求，对促进项目成功有重要作用。如果已经和客户签订了服务合同，那么合同条款即为项目需求基准。但通常在实际 IT 服务项目启动过程中，需求收集活动一般发生在服务合同签署之前，这就要求项目经理必须要准确的收集内外部客户的需求以免项目偏离目标。一般而言需求收集，需要如下输入内容：项目章程、初步范围说明书、干系人登记册。
项目章程
项目章程记录业务需要、对客户需求的理解，以及需要交付的服务或成果，例如：
- 项目目的或立项原因；
- 项目目标的验收标准；
- 项目的总体要求；
- 总体预算及大体上的计划；
- 对项目经理的授权。
通常来说项目章程有可能是以客户合同、内部书面授权书、管理层邮件或口头授权等形式提交到 IT 服务项目经理。IT 服务项目经理通过项目章程获取对项目范围的初步了解，同时获得组织机构内部的正式任命。
初步项目范围说明书
初步的项目范围说明书记录了为实现项目目标而需要完成的工作范围，此文件一般由客户方通过邮件、口头、非正式文件或正式合同等形式向内部或者外部的服务供应方提供。服务供应方以此为依据初步了解项目需求，并在之后的活动进一步细化和明确需求。
干系人登记册
干系人登记册记录了项目相关的内外部所有干系人，通过对干系人相干利益的识别，有助于项目团队更好的收集和理解客户需求，从而完善项目范围定义。
在 IT 服务项目经理接受项目任命的同时会获得初步项目干系人名单，但是项目经理仍然需要详细分析项目章程，进一步扩大项目干系人范围，以便完成完整的项目干系人登记册，确保不会遗漏某一方干系人的利益。
通常 IT 服务项目的干系人会涉及到：
- 客户方
- 采购决策人；
- 采购流程执行相关人；
- 项目实施参与相关人；
- 其他业务相关方；
- 其他利益相关方。
- 服务供应商
- 项目管理办公室（Project Management Office，简称 PMO）；
- 内部审计相关人；
- 财务、法务等流程相关人；
- 项目工程师；
- 服务销售；
- 其他业务相关方；
- 其他利益相关方。
- 第三方
- 竞争对手；
- 下级承包商；
- 上级分包商；
- 其他业务相关方；
- 其他利益相关方。
（2）需求收集的输出
需求文件
需求文件描述了客户的各种具体需求。可测量、可跟踪的、完整的、且项目主要干系人认可的需求，可以作为项目的需求基准。
需求文件的格式可以是多种多样，既可以是一份列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。
需求管理计划
需求管理计划描述在整个项目生命周期中，如何收集、分析、记录和管理项目需求。需求管理计划归纳为变更管理的子流程，同时也是整个项目管理计划中的一部分。
需求跟踪矩阵
需求跟踪矩阵是一张体现项目需求与业务需求的对应关系的表格，以便在整个项目生命周期中对需求的实现情况进行跟踪，有助于确保每一个已执行或计划执行的需求都具有商业价值，有助于确保需求文件所批准的每一项需求在项目结束时都得到实现。
9.2.2 范围定义
在初步项目范围说明书中已文档化的主要可交付物、假设及约束条件的基础上，准备详细的项目范围说明书是项目成功的关键。在项目规划中，项目经理了解了更多的项目信息，项目范围应被更详细地进行描述。项目经理应检查假设和约束条件的完整性，并根据项目需要，增加必要的补充假设和约束条件。项目团队或其他对项目范围有不同见解的项目干系人，可以基于此履行和准备项目分析。
（1）范围定义的输入
范围定义的输入包括以下内容：
对项目有重要影响作用的组织组织内部的正式或非正式的组织计划、组织政策、流程程序和工作指南等，还包括知识库，经验教训总结和历史项目信息。
在进行项目规划时应特别关注的是：
- 适合于范围计划编制的组织政策；
- 与范围计划编制和管理相关的组织流程；
- 可用来在当前项目规划过程中作参考的过去项目形成的历史信息；
- 批准的变更申请。
经变更管理流程核准的需求变更能引发项目质量、范围、成本或进度的变更。变更申请有多种形式：口头的或书面的，直接的或间接的，外在的或内部的，法律或契约要求的等。
（2）范围定义的输出
范围定义的工作，会进一步形成详细的范围说明书，以及对项目的管理计划进行更新。
详细项目范围说明书
详细项目范围说明书描述了项目的可交付物和产生这些可交付物所必须做的项目工作。项目范围说明书在所有项目干系人之间建立了一个对项目范围的共识，描述了项目的主要目标，使团队能进行更详细的规划，指导团队在项目实施期间的工作，并为评估是否为客户需求进行变更或附加的工作是否在项目范围之内提供基线。详细的范围说明书直接或以引用其他文档的方式包括以下内容。
- 项目和范围的目标：这些目标包括衡量项目成功的可量化标准；
- 产品范围描述：描述了项目承诺交付的服务或结果的特征和约束条件。如：SLA 级别、服务支持时间、涉及用户识别、涉及硬件识别、涉及系统识别等。当需求的形式和实质改变的时候，它将提供充分的细节来支持后期的项目计划更新；
- 项目服务边界：边界严格地定义了项目内服务包括什么和不包括什么，特别是不包含在项目范围中的边界工作。明确说明哪些内容不属于项目范围，有助于管理干系人的期望；
- 项目的可交付物：可交付物包括通过项目实施生成的产品、能力、结果和附属产出物（如项目管理报告和文档）。依靠项目范围说明书，可交付物可以被描述得比较概要，也可以很详细；
- 产品可接受的标准：定义了接受可交付物的标准；
- 项目的约束条件：描述和列出具体的与项目范围相关的约束条件，其对项目团队的选择会造成限制。如，客户或组织发布的预算或任何强加的日期（进度里程碑）都应被包括在内。
- 当一个项目按合同执行时，合同条款通常是约束条件。项目范围说明书的约束条件比项目章程中列出的约束条件更多更为详尽；
- 项目的假设：描述并且列出了特定的与范围相关的假设，和这些假设对项目的潜在的影响。
- 作为计划过程的一部分，项目团队应该经常识别、记录和确认假设。项目范围说明书中列出的假设比项目章程中列出的假设更多，更加详细；
- 已批准的变更：这一节包括任何项目干系人委托的已批准的变更。已批准的变更应用于项目目标、可交付物和项目工作中。
更新项目管理计划
由于范围定义过程的变更会导致项目管理计划做相应的更新。对于项目管理计划和它的辅助计划的必要的变更（补充、修改、修订）通过整体变更控制来处理。
9.2.3 创建工作分解结构
（1）项目工作结构分解的目的和意义
工作分解结构（WBS）是面向可交付物的项目元素的层次分解，它组织并定义了整个项目范围。WBS 是一个详细的项目范围说明的表示法，详细描述了项目所要完成的工作。WBS 的组成元素有助于项目干系人检查项目的最终产品。WBS 的最低层元素是能够被评估的、安排进度的和被跟踪的。
项目的 WBS对项目管理有着重要的意义：
- 通过 WBS，把项目范围分解开来，使项目相关人员对项目一目了然，能够使项目的概况和组成明确、清晰、透明、具体。使项目管理者和项目主要干系人，如投资人或客户，都能通过 WBS把握项目、了解和控制项目过程;
- 保证了项目结构的系统性和完整性。因为分解的过程要求包含项目的所有工作，这样才可能在规划和实施项目中保证不会存在遗漏，进而达到了项目的完整性;
- 通过 WBS，可以建立完整的项目保证体系，因为这个分解过程将项目的总目标关注的重点，如进度、成本和质量等分解到可控制的各项目单元，便于执行和实现目标要求;
- 项目 WBS 能够明确项目相关各方的工作界面，便于责任划分和落实;
- 最终工作分解结构，可以直接作为进度计划和控制的工具;
- 为建立项目信息沟通系统提供依据，便于把握信息重点，是项目各项计划和控制措施制定的基础和主要依据。
（2）创建工作分解结构的输入
范围定义后，创建工作分解结构，前者的输出是后者的输入，包括：
（3）创建工作分解结构的输出
工作范围分解的结果就是形成工作分解结构；同时完成项目范围管理计划的更新，因为实际的工作分解过程，也是对项目范围描述准确清晰和合理与否的一个检验过程，如果出现偏差，应该及时更正。
WBS 和 WBS字典
工作分解结构描述的是可交付物和其组成要素的具体内容，定义了整个项目的工作范围。如果一个工作不在 WBS 内，那么，这个工作就会被排除在项目范围之外。项目相关人员对完成的 WBS 应该给予确认，并对此要达成共识。工作分解结构每细分一层就表示对项目要素更细致的描述。
WBS 的最低层次通常是指工作包。通常，在 WBS 中每一个工作包被指定惟一的标识，这些标识反映各级成本和资源的结构。这些工作包被分解成各项活动，以便进行项目进度安排。
WBS 中包含的元素（包括工作包）细节通常在工作分解结构字典中加以描述。WBS 字典是WBS 的配套文档，用来描述每个 WBS 元素。对每一个 WBS元素，包括其工作说明、相关活动列表和里程碑列表。其他信息包括承办组织、开始和结束日期、资源需求、成本估算、负载量、合同信息、质量要求和提高工作质量的技术参考资料。在适当的情况下，每个 WBS 元素应当与 WBS字典中的其他元素交叉参照。
更新项目管理计划
如果在创建 WBS 过程中发生变更，则项目管理计划可能需要被升级。项目管理计划和辅助计划中被请求的变更（补充、修改、修订）通过整体变更控制来处理。
在制定 WBS时，对于发现的针对项目范围的缺乏合理性和正确性的情况，应该给予及时更正，修改项目范围说明书和相应的范围管理计划。根据实际需要，必须通知相关的项目干系人。
9.2.4 范围确认
范围确认是项目干系人（统一名称）正式接受已完成的项目范围的过程。范围确认需要审查可交付物和工作成果，以保证项目中所有工作都能准确、满意地完成。项目范围确认应该是贯穿项目的始终，从 WBS 的确认（或合同中具体分工界面的确认），到项目验收时范围的检验。如果项目被提前终止，范围确认过程应以书面文件的形式把它的完成情况记录下来。范围确认与质量控制不同，范围确认是有关工作结果的接受问题，而质量控制是有关工作结果正确性的审核。这些过程一般并行，以确保可接受性和正确性。
（1）范围确认的输入
项目管理计划
项目管理计划合并与整合了其他各规划过程所输出的所有子管理计划和基准。其包括但不限于：
- 项目所选用的生命周期以及各阶段将采用的过程；
- 项目管理团队对项目流程的挑选结果；
- 一份变更管理计划，用来明确如何对变更进行监控；
- 一份配置管理计划，用来明确如何开展配置管理；
- 为处理未决事宜和制定决策所需开展的管理层审查。
项目管理计划可以是概括或详细的，也可以包括一个或多个子管理计划。每个子计划的详细程度取决于具体项目的要求。通常一个完整的项目管理计划包括（但不限于）：
- 进度基准；
- 成本绩效基准；
- 范围基准；
- 范围管理计划；
- 需求管理计划；
- 进度管理计划；
- 成本管理计划；
- 质量管理计划；
- 过程改进计划；
- 团队组建计划；
- 沟通管理计划；
- 风险管理计划；
- 采购管理计划。
可交付物
可交付物是那些已经被完全或部分完成的部分，并且是指导和管理项目执行过程的输出结果，是项目或项目某阶段的部分或全部的交付成果，当然也可能是客户或上层管理比较关注的里程碑事件完成结果。
项目范围说明书
项目范围说明书详细描述了将被审查的项目产品的产品范围。
WBS 和 WBS字典
WBS 和 WBS 字典用于范围的定义和确认项目进行中的工作成果是不是项目的一部分。
（2）范围确认的输出
交付物的验收
包括被客户或项目发起人接受的文档，或项目交付成果的认可证明。这种接收是有条件的，特别是在某个阶段的结束点上。
在实际项目中，交付物验收通常是指客户对 IT 服务的阶段报告或阶段性产品的签字确认；这种确认通常会伴随预先约定的阶段性客户付款的发生。
更新 WBS和 WBS字典
WBS 和 WBS 字典帮助定义范围，依据范围确认过程的结果要进行相应的更新。
9.2.5 范围控制
范围控制涉及到以下内容：影响范围变更的因素，确保所有被请求的变更按照项目综合变更控制处理，范围变更发生时管理实际的变更。范围控制与其他控制过程完全结合。未控制的变更经常被看作范围溢出。变更应当被视作不可避免的，因此要颁布一些类型的变更控制过程。
变更是项目干系人由于项目环境或者是其他的各种原因的要求而对项目计划进行修改，甚至是重新规划，而这一类修改或变化就叫做变更。项目范围的变更控制就是是为了对项目中存在的或潜在的变化，采用正确的策略和方法成功地处理它，使其对项目目标达成的影响最小。
变更产生的原因
项目管理者必须对变更进行控制管理。一般情况下，造成项目范围变更的原因很多，主要有：
- 项目外部环境发生变化，如新政策、组织战略调整；
- 项目范围的计划编制不周密详细，有一定的错误或遗漏；
- 出现了新的技术或方案，能够大幅度节省成本；
- 项目实施组织本身发生变化；
- 客户对项目或服务的要求发生变化。
变更控制的焦点问题
许多情况下，作为项目管理者在进行范围变更控制时，更关心的问题是：
- 对造成范围变更的因素施加影响，以确保这些变更得到干系人的一致认可；
- 确定范围变更对项目的整体影响；
- 对实际的变更实施过程进行管理，以免影响进一步扩大。
（1）范围控制的输入
范围管理计划
范围管理计划是范围控制的主要依据。
WBS 和 WBS字典
WBS 和 WBS 字典定义项目的范围基线。
工作绩效信息
绩效报告提供项目绩效信息，如已经完成的中间可交付成果。
绩效报告是直接可以反映当前项目执行情况的文件，可以从项目范围相关的绩效报告中获得范围绩效的信息，以此作为项目变更控制的一个依据。同时，绩效报告也能提醒项目团队预测项目的未来性，把握项目范围变更控制的风险。
批准的变更需求
范围变更是对达成一致的、WBS 定义的项目范围的修改。已经接受的范围变更经常需要调整成本、时间、质量、进度以及其他项目目标。
在项目实施过程中，可能由于项目环境的变化，项目前期工作的过失，项目额外工作的增加，甚至是 WBS 制定的错误等都有可能造成项目的变更，影响到项目范围的增大和减小。变更形式有很多种，书面的、口头的，直接的、间接的，外部的和内部的等，有些变更根据需要是强制性的。
（2）范围控制的输出
范围控制的结果是：
变更请求
范围控制的结果能产生变更请求，变更的处理要符合项目综合变更控制过程。
变更请求是对已被认可的 WBS 所确认的项目范围的任何修改。范围变更经常要求对成本、时间、质量和其他项目目标进行调整。
建议的纠正措施
纠正措施是为达到将来预期的与项目计划一致的项目绩效而采取的任何措施。
更新组织过程资产
应该把各种变更的原因，纠正措施被选择的理由，以及从范围变更控制中得出的其他形式的经验教训，当作文件记录下来，目的是把这些资料变成历史记录的一部分存入历史数据库，为项目管理组织执行当前项目和其他项目积累经验，提供参考。
更新项目管理计划
由于变更，相应的基准文档要进行修改并重新发布，如项目的范围说明书和 WBS，以反映批准的变更，形成新的基线作为未来变更的基准。
对项目管理计划和它的辅助计划的变更请求要通过综合变更控制进行处理。
更新 WBS和 WBS字典
WBS 与 WBS 字典帮助定义项目范围，并用于验证工作结果是否是项目的一部分。
************************************************************* 返回到首页 《ITSS认证IT服务项目经理培训教材》_试用版连载http://www.itilxf.com/thread-36762-1-1.htmlITSS、培训、服务、资格、评估、ITSS培训师、ITSS评估师、实施ITSS、ITSS符合性、ITSS服务工程师、ITSS服务项目经理、ITSS标准、ITSS咨询、ITSS工具、IT服务监理、ITSS体系、ITSS服务质量、评价、指标、运维、治理、咨询、ITSS出版物、ITSS产品、服务监理工具、服务质量评价工具、标准符合性评估工具、服务管理工具、服务治理工具、系统监控工具、辅助决策分析、服务支持管理、基础设施监控、ITSS基础教材、ITSS标准、ITSS服务人员培训教材、标准化、专业化、人员（People）、流程[1]（Process）、技术（Technology）和资源（Resource），简称PPTR、规划设计（Planning&Design）、部署实施（Implementing）、服务运营（Operation）、持续改进（Improvement）和监督管理（Supervision），简称PIOIS、服务交付规范、资源要求、外包管理、服务交付、分类、代码、服务指南、通用要求、指标体系、ITSS落地实践交流-QQ群：21542747
| 
转播
分享
淘帖
()