目录
一、概述
二、范围计划的编制
2.1 项目中包含的范围
2.1.1 产品范围
2.1.2 工作范围
2.1.3 总结
2.2 范围计划编制的成果
2.2.1 范围管理计划
2.2.1.1 概述
2.2.1.2 内容
三、创建工作分解结构
3.1 概述
3.2 WBS目的和用途
3.3 WBS分层结构
3.3.1 分层结构图
3.3.2 结构图说明
3.4 WBS 词汇表
四、范围确认和控制
4.1 概述
4.2 范围确认
4.2.1 概述
4.2.2 范围确认的内容
4.3 范围控制
一、概述
范围是项目目标的更具体的表达。在信息系统项目实践中，需求蔓延是项目失败最常见的原因之一，往往在项目启动、计划、执行，甚至收尾时还在不断地加入新的功能无论是客户的要求，还是项目团队成员对新技术的试验，都可能导致项目范围的失控，从而使项目在时间、资源和质量上都受到严重影响。范围管理就是要确定项目的边界，也就是说，要确定哪些工作是项目应该做的，哪些工作不应该包括在项目中。这个过程用于确保项目千系人对作为项目结果的产品(或服务)，以及开发这些产品所确定的过程有一个共同的理解。
二、范围计划的编制
2.1 项目中包含的范围
在信息系统项目中，实际上存在两个相互关联的范围，分别是产品范围和工作范围(项目范围)。
2.1.1 产品范围
产品范围是指产品(或服务)所应该包含的功能。产品范围是工作范围的基础；产品范围的定义是信息系统需求的体现；产品的需求分析侧重于软件技术。产品范围描述是项目范围说明书的重要组成部分，因此，产品范围变更后，首先受到影响的就是工作范围。在工作范围调整之后，才能调整项目的进度表和质量基线等。
2.1.2 工作范围
工作范围是指为了能够交付项目所必须要做的工作。工作范围的定义是产生项目计划的基础，工作范围管理则更偏向于管理。
2.1.3 总结
两种范围在应用上有区别。
项目范围对项目的影响是决定性的，只有完成了项目范围中的全部工作，项目才能结束。因此一个范围不明确或干系人对范围理解不一致的项目不可能获得成功。范围不明确最可能的后果是项目的范围蔓延，项目永远也做不到头；对范围的理解不一致的结果往往使项目组的工作无法得到其他干系人的认可。要防止这些事件的发生，首要任务就是要编制好范围管理计划。
2.2 范围计划编制的成果
2.2.1 范围管理计划
2.2.1.1 概述
范围计划编制的成果就是范围管理计划。范围管理计划是对项目的范围进行确定、记载、核实管理和控制的行动指南，与项目范围计划不同，范围计划描述的是项目的边界，而范围管理计划描述的是项目组将如何进行项目的范围管理。具体来说，包括如何进行项目范围定义，如何制订 WBS，如何进行项目范围核实和控制等。
范围管理计划应该对怎样变化、变化频率如何，以及变化了多少这些项目范围预期的稳定性进行评估。
范围管理计划也应该包括对变化范围怎样确定，变化应归为哪一类等问题的清楚描述。事实上，在项目的产品范围还没有确定之前，就需要确定这些问题是非常困难的，但是仍然有必要进行。
2.2.1.2 内容
项目范围管理计划可能在项目开发计划之中，也可能作为单独的一项。项目范围管理计划可以是正式或非正式的，极为详细或相当概括的，具体视项目的需要而定。一般而言，范围管理计划应包括如下内容：
- 根据项目初步范围说明书编制详细项目范围说明书的过程。
- 能够根据详细的项目范围说明书制作WBS，并确定如何维持与批准该WBS的过程。
- 规定如何正式核实与验收项目已完成可交付成果的过程。
- 控制详细项目范围说明书变更请求处理方式的过程，该过程与整体变更控制过程有直接联系。
三、创建工作分解结构
3.1 概述
WBS 把项目整体或者主要的可交付成果分解成容易管理、方便控制的若干个子项目，子项目需要继续分解为工作包。持续这个过程，直到整个项目都分解为可管理的工作包，这些工作包的总和就是项目的所有工作范围。
3.2 WBS目的和用途
创建 WBS的目的是详细规定项目的范围，建立范围基准。具体来说，其主要目的和用途如下：
- 明确和准确说明项目范围，项目组成员能够清楚地理解任务的性质和需要努力的方向。
- 为各独立单元分派人员，规定这些人员的相应职责，可以确定完成项目所需要的技术和人力资源。
- 针对各独立单元，进行时间、费用和资源需求量的估算，提高估算的准确性。
- 为计划、预算、进度安排和费用控制奠定共同基础，确定项目进度测量和控制的基准。
- 将项目工作与项目的财务账目联系起来。
- 清楚地定义项目的边界，便于划分和分派责任，自上而下将项目目标落实到具体的工作上，并将这些工作交给项目内外的个人或组织去完成。
- 确定工作内容和工作顺序。可以使用图形化的方式来查看工作内容，任何人都能够清楚地辨别项目的阶段、工作单元，并根据实际进展情况进行调节和控制。
- 估计项目整体和全过程的费用。
- 有助于防止需求蔓延。当用户或其他项目干系人试图为项目增加功能时，在WBS 中增加相应工作的同时，也就能够很容易地让他们理解，相关费用和进度必须也要做相应的改变。
3.3 WBS分层结构
3.3.1 分层结构图
WBS是面向可交付物的项目元素的层次分解，它组织并定义了整个项目范围。当一个项目的 WBS 分解完成后，项目相关人员对完成的 WBS 应该给予确认，并对此达成共识。然后，才能据此进行时间和成本的估算。最普通的WBS如下表所示：
3.3.2 结构图说明
WBS的上面3层通常由客户指定，不应该和具体的某个部门相联系，下面3层由项目组内部进行控制。这样分层的特点有:
- 每层中的所有要素之和是下一层的工作之和。
- 每个工作要素应该具体指派一个层次，而不应该指派给多个项目。
- WBS需要有投入工作的范围描述，这样，才能使团队所有人员对要完成的工作有全面的了解。
在每个分解单元中，都存在可交付成果和里程碑。里程碑标志着某个可交付成果或者阶段的正式完成。里程碑和可交付成果紧密联系在一起，但并不是一个事物。可交付成果可能包括报告、原型、成果和最终系统。而里程碑则关注于是否完成，例如，正式的用户认可文件。WBS中的任务有明确的开始时间和结束时间，任务的结果可以和预期的结果相比较。
最底层的工作单元称为工作包，由于它应该便于完整地分派给不同的人或组织，所以要求明确各工作单元直接的界面。工作包应该非常具体，以便承担者能明确自己的任务、努力的目标和承担的责任，工作包是基层任务或工作的指派，同时其具有检测和报告工作的作用。所有工作包的描述必然让成本会计管理者和项目监管人员理解，并能够清楚地区分不同工作包的工作。同时，工作包的大小也是需要考虑的细节，如果工作包太大，则难以达到可管理和可控制的目标；如果工作包太小，则WBS就要消耗项目团队成员的大量时间和精力。
努力水平(LevelOfEfor，LOE)也称为投入水平，是指测量不容易用明显的成就来衡量的辅助性工作(例如，与供应商或顾客的联系工作)的一种手段。这类工作的特点是在一段时间内以均匀的速度进行。
3.4 WBS 词汇表
在制作 WBS 的过程中，要给 WBS的每个部分赋予一个账户编码标志符，它们是费用、进度和资源使用信息汇总的层次结构。需要生成一些配套的文件，这些文件需要和WBS 配套使用，称为 WBS 词汇表或 WBS 字典，它包括 WBS 组成部分的详细内容、账户编码、工作说明、负责人、进度里程碑清单等，还可能包括合同信息、质量要求、技术文献、计划活动、资源和费用估计等。
要注意的是，很多书籍上都详细讨论了WBS的创建方式，事实上，创建WBS没有所谓的“正确的”方式，既可以使用白板、草图等，也可以使用专门的项目管理软件，例如，Microsoft Proiect等。
四、范围确认和控制
4.1 概述
在对项目范围进行了定义，编制了详细的WBS之后，接下来的事情就是要让项目干系人确认范围，以及在项目实施过程中，对范围进行控制，确保项目范围按照既定流程进行变更。
4.2 范围确认
4.2.1 概述
在信息系统项目中，范围确认并不是容易的事情，主要体现在与用户的沟通上。项目组倾向于让用户确认范围以尽快开始后面的工作，而用户则可能认为自己什么也没有看到，怎么可以确认呢?因此，项目经理必须有足够的能力与用户沟通，让用户意识到，虽然项目范围确认是正式的，但这并不意味着项目范围就是“铁板一块”，不能再修改了。同时，要让用户知道，无论是现在更改范围，还是以后更改范围，都会引起项目进度和费用上的变化。
4.2.2 范围确认的内容
范围确认主要是确认项目的可交付成果是否满足项目干系人的要求。把项目的可交付成果列表提交给项目干系人，同时，也应该展示项目的进度安排。项目于系人进行范围确认时，要检查：
- 可交付成果是否是确定的、可核实的。
- 每个交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，例如，客户的书面认可。
- 是否有明确的质量标准，也就是说，可交付成果的交付不但要有明确的标准标志，而且要有是否按照要求完成的标准，可交付成果和其标准之间是否有明确的联系。
- 审核和承诺是否有清晰的表达。项目投资人必须正式地同意项目的边界，项目完成的产品(或服务)，以及项目相关的可交付成果。项目组必须清楚地了解可交付成果是什么。所有这些表达必须清晰，并取得一致同意。
- 项目范围是否覆盖了需要完成的产品(或服务)进行的所有活动，有没有遗漏或者错误。
- 项目范围的风险是否太高，管理层是否能够降低可预见的风险发生时对项目的冲击。
每个干系人对项目范围所关注的方面是不同的。例如，管理层关注的是范围对项目的进度、资金和资源的影响，这些因素是否超过了组织承受能力，是否在投入产出上具有合理性；用户主要关心的是产品范围，关心项目的可交付成果是否达到预定的目标：项目管理人员主要关注可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法；项目团队成员主要关心项目范围中自己参与的元素和负责元素，通过范围定义中的时间线检查自己的工作时间是否足够，在项目范围中自己是否有多项工作，而这些工作又有冲突的地方。
在范围确认的过程中，如果发现项目范围说明书、WBS中有遗漏或者错误，需要向项日组明确指出错误的内容，并给出修正的意见，项目组需要根据这些意见修改相关文档。在范围确认的过程中，也可能会出现范围变更请求，如果这些请求得到了批准，那么，也要修改相关文档。
4.3 范围控制
在信息系统项目的实施过程中，项目范围难免会因为各种因素而发生变更。例如，项目外部环境发生变化(例如，法律、对手的新产品等)：范围计划不周，有错误或者遗漏；出现了新的技术、手段和方案；项目实施组织发生了变化；客户对项目或者项目产品的要求发生了变化等。所有的这些变化，即使是“好”的变化，对项目管理人员而言都令人不安。项目范围定义了项目应该做的和不应该做的，那么对于范围变更，就不能随意进行。对于用户不断提出的新要求和建议，项目组应该坚持“决不让步，除非交换的原则，尽可能减少范围蔓延的可能性，所有的范围变更必须在项目的工期、费用或者质量要求上得到相应的变更。
所有的变更必须记载，范围控制必须能够对造成范围变更的因素施加影响，估算对项目的资金、进度和风险等影响，以保证变化是有利的。同时，需要判断范围变更是否发生，如果已经发生，则就要对变更进行管理。
对范围变更进行控制时，要以WBS、项目进展报告、变更请求和范围管理计划为依据。对于有合同的项目而言，项目范围变更必须遵守项目合同的相关条款。进行范围变更控制必须经过范围变更控制系统。有关变更控制系统的知识，将在后续章节中介绍。
好了，本次内容就分享到这，欢迎大家关注《项目管理》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！
