导图社区 信息系统项目管理师（第3版） 范围管理
- 31
- 0
- 0
- 举报
信息系统项目管理师（第3版） 范围管理
信息系统项目管理师（第3版）范围管理：定义范围是制定项目和产品详细描述的过程，其主要作用是明确所收集的需求中哪些包含在项目范围内，哪些排除在项目范围外，从而明确产品、服务或成果的边界。
编辑于2022-09-15 09:38:01 广东- 信息系统项目
- 相似推荐
- 大纲
（信管）范围管理
项目范围管理是为了达到项目目标，交付具有某种特质的产品和服务项目所规定要做的工作。 项目范围管理工作内容： 1.明确项目边界，那些该做，哪些不该做 2.对项目执行工作进行监控，该做的都做了，没有多做也没少做 3.防止项目范围发生蔓延 范围管理领域输入、输出、工具和技术表如表 5-1 所示。 
范围管理概述
1.项目范围管理就是要做范围内的事，而且只做范围内的事，既不少做也不多做。 项目范围管理需要做以下三个方面的工作： ①明确项目边界； ②对项目执行工作进行监控； ③防止项目范围发生蔓延。
2.产品范围是指产品或者服务所应包含的功能，项目范围是指为了能够交付产品，项目所必须做的工作。 产品范围是项目范围的基础，产品范围的定义是产品要求的描述； 而项目范围的定义是产生项目管理计划的基础。 判断项目范围是否完成，要以范围基准来衡量； 而产品范围是否完成，则根据产品是否满足了产品描述来判断。 产品范围描述是项目范围说明书的重要组成部分，因此，产品范围变更后，首先受到影响的是项目的范围。
3.项目的范围基准是经过批准的项目范围说明书、WBS 和 WBS 词典。
7、规划范围管理
创建范围管理计划，书面描述将如何定义、确认和控制 项目范围的过程
1.规划范围管理是编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，其主要作用是在整个项目中对如何管理范围提供指南和方向。
2.范围管理计划是制定项目管理计划过程和其他范围管理过程的主要输入，包括如下内容：
（1） 如何制定项目范围说明书。
（2） 如何根据范围说明书创建 WBS。
（3） 如何维护和批准 WBS。
（4）如何确认和正式验收已完成的项目可交付成果。
（5）如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相联。 项目范围管理计划可能在项目管理计划之中，也可能作为单独的一项。 根据不同的项目，可以是详细的或者概括的，可以是正式的或者非正式的。
3.需求管理贯穿于整个过程，其最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。 另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全控制其影响范围，始终保持产品与需求的一致性。
4.需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求。 主要包括以下内容：
（1）如何规划、跟踪和汇报各种需求活动。
（2） 需求管理需要使用的资源。
（3） 培训计划。
（4）项目干系人参与需求管理的策略。
（5）判断项目范围与需求不一致的准则和纠正规程。
（6）需求跟踪结构，即哪些需求属性将列入跟踪矩阵，并可在其他哪些项目文件中追踪到这些需求。
（7）配置管理活动。
输入、输出、工具
输入
1.项目章程
2.项目管理计划
3.事业环境因素
4.组织过程资产
工具与技术
1.专家判断 （１）
基于某应用领域、知识领域、学科和行业等的专业知识而做出的，关于当前活动的合理判断。这些专业知识可来自具有专业学历、知识、技能、经验或培训经历的任何小组或个人 (也叫德尔菲法) (1)贯穿项目始终 (2)质量管理3过程没有
2.引导技术（２）
（头脑风暴、冲突处理、问题解决、会议管理等）。 头脑风暴、冲突处理、问题解决和会议管理等，都是引导者可以用来帮助团队和个人完成项目活动的关键技术； 有一个引导者
输出
1.范围管理计划
范围管理计划要对下列工作的管理过程做出规定： 1.如何制定项目范围说明书 2.如何根据范围说明书创建WBS 3.如何维护和批准WBS 4.如何确认和正式验收已完成的项目可交付成果 5.如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相连
2.需求管理计划
需求管理计划的内容 1.如何规划、跟踪和汇报各种需求活动 2.需求管理需要使用的资源 3.培训计划 4.项目干系人参与需求管理的策略 5.判断项目范围与需求不一致的准则和纠正程序
8、收集需求
为实现项目目标而确定、记录并管理干系人的需要和需求的过程
1.收集需求是为实现项目目标而确定、记录并管理干系人的需要和需求的过程，其作用是为定义和管理项目范围（包括产品范围）奠定基础。
2. 需求的分类。
（1）业务需求： 整个组织的高层级需要，如解决业务问题或抓住业务机会，以及实施项目的原因。
（2）干系人需求： 是指干系人或干系人群体的需要。
（3）解决方案需求： 是为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征。 解决方案需求又进一步分为功能需求和非功能需求。 功能需求是关于产品能开展的行为，如流程、数据以及与产品的互动等。 非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量，如可靠性、安全性、性能、服务水平等。
（4）过渡需求： 从当前状态过渡到将来状态所需的临时能力，如数据转换和培训需求。
（5）项目需求： 项目需要满足的行动、过程或其他条件。
（6）质量需求： 用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。 QFD对质量需求进行了细分，分为基本需求、期望需求和意外需求。
3.收集需求的工具与技术主要有访谈、焦点小组、引导式研讨会、群体创新技术、多标准决策分析、群体决策技术、问卷调查、观察、原型法、标杆对照、系统交互图、文件分析等。
（1）访谈： 通过与干系人直接交谈来获取信息的正式或非正式的方法，是最基本的一种收集需求的手段。
（2）焦点小组： 将预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。 由一位受过训练的主持人引导大家进行互动式讨论。 焦点小组往往比一对一的访谈更加热烈。 焦点小组是一种群体访谈而非一对一访谈，可以有6〜10个被访谈者参加。| 针对访谈者提出的问题，被访谈者之间开展互动式讨论，以求得到更有价值的意见。
（3）引导式研讨会： 邀请主要的跨职能干系人一起参加会议。 引导式研讨会对产品需求进行集中讨论与定义。 研讨会是快速定义跨职能需求和协调干系人差异的重要技术。 由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见。 该技术的另一个好处是，能够比单项会议更快地发现和解决问题。
（4）群体创新技术： 是指可以组织一些群体活动来识别项目和产品需求，包括头脑风暴法、名义小组技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析等。
1) 头脑风暴法：各抒己见。
2)名义小组技术： 通过投票来选出最有用的创意，以便进行进一步的头脑风暴或优先排序。 名义小组技术是头脑风暴法的深化应用，是更加结构化的头脑风暴法。
3)德尔菲技术： 经过多次综合各专家的观点，最终形成一个各专家都认可的方案。 可以防止个人的观点被不正确地放大。
4)概念/思维导图： 是用一张简单的图将从头脑风暴中获得的创意联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。
5) 亲和图： 又称为KJ法，是针对某一问题，充分收集各种经验、知识、想法和意见等语言、文字资料，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决的一种方法。 亲和图的核心是头脑风暴法，是根据结果去找原因。
6)多标准决策分析： 是借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。
4.多标准决策分析：在组建项目团队过程中，经常需要使用团队成员选择标准。 通过多标准决策分析，制定选择标准，并据此对候选团队成员进行定级或打分。 根据各种因素对团队的不同重 要性，赋予选择标准不同的权重。
（5）群体决策技术： 是为达成某种期望结果而对多个未来行动方案进行评估。 群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序。
（6）问卷调查： 是指通过设计书面问题，向为数众多的受访者快速收集信息。
（7）观察： 直接观察个人在各自的环境中如何开展工作和实施流程。
（8）原型法： 是一种根据干系人初步需求，利用产品开发工具，快速建立一个产品模型展示给干系人，在此基础上与干系人交流，最终实现干系人需求的产品快速幵发的方法。
（9）标杆对照： 将实际或计划的做法与其他类似组织的做法（如流程、操作过程等）进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的“类似组织”可以是内部组织，也可以是外部组织。
（10）系统交互图： 是对产品范围的可视化描述，显示系统（过程、设备、信息系统等）与参与者（用户、独立于本系统之外的其他系统）之间的交互方式。 系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。
（11）文件分析： 就是通过分析现有文档，识别与需求相关的信息来挖掘需求。 可供分析的文档很多，包括商业计划、营销文档、协议、招投标文件、建议邀请书、业务流程、逻辑数据模型、业务规则库、应用软件文档、用例文档、其他需求文档、问题日志、政策、程序和法规文件等。
4.收集需求过程的主要输出有需求文件和需求跟踪矩阵。 需求文件描述各种单一的需求将如何满足与项目相关的业务需求。
5.需求文件的内容包括（但不限于）： ①业务需求；②干系人需求；③解决方案需求；④项目需求；⑤过渡需求；⑥与需求有关的假设条件、依赖关系和制约因素。
6.需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。
7.可跟踪性是项目需求的一个重要特征，需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规则、系统组件及帮助文件等。可验证性是需求的最基本特性。
8.每个配置项的需求到其涉及的产品（或构件）需求都要具有双向可跟踪性。 所谓双向跟踪，包括正向跟踪和反向跟踪，正向跟踪是指检查需求文件中的每个需求是否都能在后继工作产品（成果）中找到对应点； 反向跟踪也称为逆向跟踪，是指检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处。 具体来说，需求跟踪涉及五种类型，如图 5-2 所示。

9.箭头表示需求跟踪能力联系链，它能跟踪需求使用的整个周期，即从需求建议到交付的全过程。
10.从用户原始需求可向前追溯到需求文件，这样就能区分出项目过程中或项目结束后由于变更受到影响的需求，也确保了需求文件中包括所有用户需求。 同样，可以从需求文件回溯到相应的用户原始需求，确认每个需求的出处。
11.由于在项目实施过程中，产品需求转变为设计和测试等实现元素，所以通过定义单个需求和特定的产品元素之间的联系链，可以从需求文件追溯到产品元素。 这种联系链使项目团队成员知道每个需求对应的产品元素，从而确保产品元素满足每个需求。 第四类联系链是从产品元素回溯到需求文件，使项目团队成员知道每个产品元素存在的原因。 如果不能将设计元素或测试案例回溯到一个需求文件，就可能出现镀金行为。 当然，如果某个孤立的产品元素表明了一个正当的功能，则说明需求文件漏掉了一项需求。
12.第五类联系链是需求文件之间的跟踪，这种跟踪便于更好地处理各种需求之间的逻辑相关性，检查需求分解中可能出现的错误或遗漏。
13.表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪（能力）矩阵，需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格，如表 5-2 所示。

14.应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。 需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（如进行中、已取消、已推迟、新增加、已批准、已分配、已完成等）和状态日期。 另外，为了确保干系人满意，可能需要增加一些补充属性，如稳定性、复杂性、验收标准等。
输入、输出、工具
输入
1.项目章程
2.范围管理计划
范围管理计划要对下列工作的管理过程做出规定： 1.如何制定项目范围说明书 2.如何根据范围说明书创建WBS 3.如何维护和批准WBS 4.如何确认和正式验收已完成的项目可交付成果 5.如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相连
3.需求管理计划
需求管理计划的内容 1.如何规划、跟踪和汇报各种需求活动 2.需求管理需要使用的资源 3.培训计划 4.项目干系人参与需求管理的策略 5.判断项目范围与需求不一致的准则和纠正程序
4.干系人管理计划
5.干系人登记册
工具与技术
1.访谈（5）
通过与干系人直接交谈，来获取信息的正式或非正式方法
2.焦点小组（６）
召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度的一种启发式技术
3.引导式研讨会（７）
把主要的跨职能干系人召集在一起，通过集中讨论来定义产品需求的一种启发式技术(JAD和QFD) 跨职能
4.群体创新技术（头脑风暴、思维导图、亲和图、多标准决策分析）（８）
用于在干系人群体中激发创意的技术，包括：头脑风暴法、名义小组技术(排序)、概念/思维导图(关联)、亲和图(同类)、多标准决策分析
5.群体决策技术（一致同意（德尔菲）、大多数、相对多数、独裁）（９）
对多个备选方案进行评估的技术，用于生成产品需求并进行分类和优先级排序
6.问卷调查（１０）
设计一系列书面问题，向众多受访者快收集信息
7.观察（１１）
直接观看个人在各自的环境中如何执行工作（或任务）和实施流程的一种技术
8.原型法（１２）
在实际制造预期产品之前，先造出其实用模型，并据此征求对需求的早期反馈的一种方法 渐近明细
9.标杆对照（１３）
将实际或计划的实践（如流程和操作过程）与其他可比组织的实践进行对照，以便识别最佳实践、形成改进意见，并为绩效考核提供依据
10.系统交互图（１４）
对产品范围的可视化描绘，显示业务系统（过程、设备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式。
11.文件分析（１５）
通过分析现有文档，识别与需求相关的信息的一种启发式技术
输出
1.需求文件（业务/干系人/解决方案/项目）
2.需求跟踪矩阵
1）业务需求、机会目的和目标 2）项目目标 3）范围描述/WBS可交付成果 4）产品设计 5）产品开发 6）测试策略和测试场景 7）高层级需求到详细需求
9、定义范围
制定项目和产品详细描述
1.定义范围是制定项目和产品详细描述的过程，其主要作用是明确所收集的需求中哪些包含在项目范围内，哪些排除在项目范围外，从而明确产品、服务或成果的边界。 由于在收集需求的过程中识别出的所有需求未必都包含在项目中，所以定义范围过程就要从需求文件中选取最终的项目需要，然后制定出关于项目及其产品、服务或成果的详细描述。
2.产品分析是一种有效的工具。 通常针对产品提问并回答，形成对将要开发的产品的用途、特征和其他方面的描述。
3.备选方案生成是一种用来指定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法。
4.作为定义范围过程的主要成果，项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。 项目范围说明书记录了整个范围，包括项目范围和产品范围，详细描述项目的可交付成果，以及为提交这些可交付成果而必须开展的工作。
5. 项目范围说明书包括如下内容：
（1）产品范围描述。
（2）验收标准。 定义可交付成果通过验收前必须满足的一系列条件，以及验收的过程。
（3）可交付成果。
（4）项目的除外责任。 通常需要识别出什么是被排除在项目之外的。 明确说明哪些内容不属于项目范围，有助于管理干系人的期望。
（5）制约因素。 列出并说明与项目范围有关且限制项目团队选择的具体项目制约因素。
（6）假设条件。
6. 项目范围说明书的主要作用： ①确定范围；②沟通基础；③规划和控制依据；④变更基础；⑤规划基础。
输入、输出、工具
输入
1.项目章程
2.范围管理计划
3.需求文件
4.组织过程资产
工具与技术
1.专家判断（１）
基于某应用领域、知识领域、学科和行业等的专业知识而做出的，关于当前活动的合理判断。这些专业知识可来自具有专业学历、知识、技能、经验或培训经历的任何小组或个人 (也叫德尔菲法) (1)贯穿项目始终 (2)质量管理3过程没有
2.产品分析（１６）
针对产品提问并回答，形成对将要生产的产品的用途、特征和其他方面的描述(包括:产品分解、系统分析、需求分析、系统工程、价值工程和价值分析)
3.备选方案生成（１７）
一种用来制定尽可能多的可选方案的技术，目的在于识别执行项目工作的不同方法。(包括:头脑风暴、横向思维、备选方案分析)
4.引导式研讨会（７）
把主要的跨职能干系人召集在一起，通过集中讨论来定义产品需求的一种启发式技术(JAD和QFD) 跨职能
输出
1.项目范围说明书
项目范围说明书的内容 1.产品范围描述 2.验收标准 3.可交付成果 4.项目的除外责任（排除在项目之外的） 5.制约因素 6.假设条件 项目范围说明书的作用 1.确定范围 2.沟通基础 3.规划和控制依据 4.变更基础 5.规划基础
2.项目文件更新(干系人登记册、需求文件、需求跟踪矩阵)
10、创建WBS
把项目可交付成果和项目工作分解成较小的、更易于管 理的组成部分的过程 WBS内容：1.里程碑 2.工作包 3.控制账户 4.规划包 5.WBS词典 WBS工具： 1.分解： 1）分解的原则：功能或者技术原则、组织结构、系统或者子系统 1.项目生命周期的各阶段作为分解的第二层，产品和可交付成果在第三层 2.主要可交付成果作为第二层 3.整合可能由项目外部组织来实施的各种组件作为外包工作的一部分，卖方需指定想要的合同WBS 2）工作过程：编制高层工作—分配管理员职责-分解工作分解结构-分配指着-编写项目范围说明书-审批工作分解结构-批准的工作分解结构 3）注意事项： 1.WBS必须面向可交付成果 2.WBS必须符合项目范围 3.WBS底层支持计划和控制 4.WBS有且只能有一个人负责WBS的元素 5.WBS的指导而不是原则，控制在4-6层，超过6层应分解为子项目 6.WBS应包括项目管理工作 7.WBS编制需要所有干系人的参与 8.WBS并非一成不变 WBS的作用： 1）明确说明项目范围 2）清晰定义项目边界 3）为各自独立单元分派人员 4）针对独立单元进行进度、成本和资源需求的估算 5）为计划、预算、进度安排和费用控制奠定共同基础 6）将项目工作和财物账目联系起来 7）确定工作内容和工作顺序 8）有助于防止范围蔓延 WBS词典的内容：账户编码标识、工作描述、假设条件和制约因素、负责人或组织单元、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等
1.创建WBS是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程，其主要作用是对所要交付的内容提供一个结构化的视图。
2.里程碑标志着某个可交付成果或者阶段的正式完成。 重要的检查点是里程碑、重要的里程碑是基线。
3.工作包是位于WBS每条分支最底层的可交付成果或项目工作组成部分，工作包应该非常具体，以便承担者能明确自己的任务、努力的目标和承担的责任。 工作包的大小需要遵循 8/80 原则。
4．控制账户是一种管理控制点，是 WBS某个层次上的要素，既可以是工作包，也可以是比工作包更高层次的一个要素。 如果是后一种情况，一个控制账户中就包括若干个工作包，但一个工 作包仅属于一个控制账户。 项目管理团队在控制账户上考核项目的执行情况，即在控制账户的相应要素下，将项目执行情况与计划情况进行比较，以便评价执行情况好坏，并发现与纠正偏差。
5.规划包是指在控制账户之下，工作内容已知但尚缺详细进度活动的 WBS 组成部分。 是在控制账户之下、工作包之上的WBS要素，是暂时用来做计划的。 随着情况的逐渐清晰，规划包最终将被分解成工作包及相应的具体活动。
6.WBS词典，在制作WBS的过程中，要给WBS的每个部分赋予一个账户编码标识符，它们是成本、进度和资源使用信息汇总的层次结构。 需要生成一些配套的文件，这些文件需要和WBS配套使用，称为WBS词典。 WBS词典也称为WBS词汇表，它是描述 WBS 各组成部分的文件。
7．创建WBS过程的工具与技术主要有分解和专家判断，要将整个项目工作分解为工作包，通常需要开展以下活动：
（1）识别和分析可交付成果及相关工作。
（2）确定 WBS的结构和编排方法。
（3）自上而下逐层细化分解。
（4）为WBS组件制定和分配标识编码。
（5）核实可交付成果分解的程度是恰当的。
8. 分解的原则。
（1） 功能或者技术原则。 在创建WBS时，需要考虑将不同人员的工作分开。
（2） 组织结构。 对于职能型的项目组织而言，WBS也要适应项目的组织结构形式。
（3）系统或者子系统。 总的系统划分为几个主要的子系统，然后对每个子系统再进行分解。
9.在进行WBS分解时，可以有如下三种方式：
（1）将项目生命周期的各阶段作为分解的第二层。
（2）主要可交付成果作为分解的第二层。
（3） 子项目作为分解的第二层。
10.WBS不是某个项目团队成员的责任，应该由全体项目团队成员、用户和项目干系人共同完成和一致确认。
11.较常用的WBS表示形式主要有分级的树型结构（组织结构图式）和表格形式（列表式）。 树型结构图的WBS层次清晰，直观性和结构性强，但不容易修改，对大型复杂项目很难表示出项目的全貌，适用于中小型项目； 表格形式的直观性比较差，但能够反映出项目的所有工作要素，适用于大型项目。
12.在分解的过程中，应该注意以下八个方面。
（1）WBS必须是面向可交付成果的。 项目的目标是提供产品或服务，仅仅是一连串特别的活动。
（2） WBS 必须符合项目的范围。 WBS必须包括也仅包括为了完成项目的可交付成果的活动。
（3）WBS的底层应该支持计划和控制。 WBS是项目管理计划和项目范围之间的桥梁，WBS的底层不但要支持项目管理计划，还要让管理层能够监视和控制项目的进度和预算。
（4）WBS中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多人参与。
（5） WBS的指导。 作为指导而不是原则，WBS应控制在4〜6层。 当然，大项目可以超过6 层。
（6）WBS应包括项目管理工作，也要包括分包出去的工作。
（7）WBS的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与。
（8）WBS并非是一成不变的，完成了 WBS 工作后，仍然有可能需要对WBS 进行修改。
13.当一个项目的WBS分解完成后，项目干系人对完成的WBS应该给予确认，并对此达成共识。 WBS的目的和用途主要体现在以下八个方面。
（1）明确和准确说明项目范围，项目团队成员能够清楚地理解任务的性质和需要努力的方向。
（2）清楚地定义项目的边界。
（3）为各独立单元分派人员，规定这些人员的职责，可以确定完成项目所需的技术和人力资源。
（4）针对独立单元，进行时间、成本和资源需求量的估算，提高估算的准确性。
（5）为计划、预算、进度安排和费用控制奠定共同基础，确定项目进度和控制的基准。
（6）将项目工作和项目的财务账目联系起来。
（7）确定工作内容和工作顺序，将项目分解成具体的工作任务，就可以按照工作任务的逻辑顺序来实施项目。 WBS可以使用图形化的方式来查看工作内容，任何人都能够清楚地辨别项目的阶段、工作单元，并根据实际情况进行调节和控制。
（8） 有助于防止需求蔓延。
输入、输出、工具
输入
1.范围管理计划
范围管理计划要对下列工作的管理过程做出规定： 1.如何制定项目范围说明书 2.如何根据范围说明书创建WBS 3.如何维护和批准WBS 4.如何确认和正式验收已完成的项目可交付成果 5.如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相连
2.项目范围说明书
项目范围说明书的内容 1.产品范围描述 2.验收标准 3.可交付成果 4.项目的除外责任（排除在项目之外的） 5.制约因素 6.假设条件 项目范围说明书的作用 1.确定范围 2.沟通基础 3.规划和控制依据 4.变更基础 5.规划基础
3.需求文件
4.事业环境因素
5.组织过程资产
工具与技术
1.分解（１８）
把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。
２.专家判断（１）
基于某应用领域、知识领域、学科和行业等的专业知识而做出的，关于当前活动的合理判断。这些专业知识可来自具有专业学历、知识、技能、经验或培训经历的任何小组或个人 (也叫德尔菲法) (1)贯穿项目始终 (2)质量管理3过程没有
输出
1.范围基准（经过审批的范围说明书、工作分解结构WBS和相应的WBS词典）
WBS内容：1.里程碑 2.工作包 3.控制账户 4.规划包 5.WBS词典 WBS工具： 1.分解： 1）分解的原则：功能或者技术原则、组织结构、系统或者子系统 1.项目生命周期的各阶段作为分解的第二层，产品和可交付成果在第三层 2.主要可交付成果作为第二层 3.整合可能由项目外部组织来实施的各种组件作为外包工作的一部分，卖方需指定想要的合同WBS 2）工作过程：编制高层工作—分配管理员职责-分解工作分解结构-分配指着-编写项目范围说明书-审批工作分解结构-批准的工作分解结构 3）注意事项： 1.WBS必须面向可交付成果 2.WBS必须符合项目范围 3.WBS底层支持计划和控制 4.WBS有且只能有一个人负责WBS的元素 5.WBS的指导而不是原则，控制在4-6层，超过6层应分解为子项目 6.WBS应包括项目管理工作 7.WBS编制需要所有干系人的参与 8.WBS并非一成不变 WBS的作用： 1）明确说明项目范围 2）清晰定义项目边界 3）为各自独立单元分派人员 4）针对独立单元进行进度、成本和资源需求的估算 5）为计划、预算、进度安排和费用控制奠定共同基础 6）将项目工作和财物账目联系起来 7）确定工作内容和工作顺序 8）有助于防止范围蔓延 WBS词典的内容：账户编码标识、工作描述、假设条件和制约因素、负责人或组织单元、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等
2.项目文件更新（需求文件）
11、确认范围
正式验收项目己完成的可交付成果的过程
1.确认范围是正式验收项目已完成的可交付成果的过程，其主要作用是使验收过程具有客观性，同时，通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。 确认范围包括与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的正式验收。
2.确认范围的主要工具与技术是检查和群体决策技术。 检査也称为审查、评审、审计、走查、巡检、测试等。
3.确认范围应该贯穿项目的始终，一般步骤如下：
（1）确定需要进行范围确认的时间。
（2）识别范围确认需要哪些投入。
（3）确定范围正式被接受的标准和要素。
（4）确定范围确认会议的组织步骤。
（5） 组织范围确认会议。
通常情况下，在确认范围前，项目团队需要先进行质量控制工作。 例如，在确认软件项目的范围之前，需要进行系统测试等工作，以确保确认工作的顺利完成。
4.项目干系人进行范围确认时，一般需要检查以下六个方面的问题：
（1）可交付成果是否是确定的、可确认的。
（2）每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件。
（3）是否有明确的质量标准。
（4）审核和承诺是否有清晰的表达。
（5）项目范围是否覆盖了需要完成的产品或服务进行的所有活动，有没有遗漏或者错误。
（6）项目范围的风险是否太高，管理层是否能够降低可预见的风险发生时对项目的冲击。
5.确认范围与核实产品： 核实产品是针对产品是否完成，在项目（或阶段）结束时由发起人或客户来验证，强调产品是否完整； 确认范围是针对项目可交付成果，由客户或发起人在阶段末确认验收的过程。
6. 确认范围与质量控制的不同之处。
（1）确认范围主要强调可交付成果获得客户或发起人的接受； 质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求（质量标准）。
（2）质量控制一般在确认范围前进行，也可同时进行； 确认范围一般在阶段末尾进行，而质量控制并不一定在阶段末进行。
（3）质量控制属内部检查，由执行组织的相应质量部门实施； 确认范围则是由外部干系人（客户或发起人）对项目可交付成果进行检查验收。
7. 确认范围与项目收尾的不同之处。
（1）虽然确认范围与项目收尾工作都在阶段末进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目（或阶段）所要做的流程性工作。
（2）确认范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品。
输入、输出、工具
输入
1.项目管理计划
2.需求文件
3.需求跟踪矩阵
4.工作绩效数据
5.确认的可交付成果
工具与技术
1.检查（102）（审查、产品评审、审计、走查、巡查）
检查工作产品，以确定它是否符合书面标准
２.群体决策技术（一致同意（德尔菲）、大多数、相对多数、独裁）（９）
对多个备选方案进行评估的技术，用于生成产品需求并进行分类和优先级排序
输出
1.变更请求
2.工作绩效信息
3.验收的可交付成果
4.项目文件更新
12、控制范围
监督项目和产品的范围状态、管理范围基准变更的过程
1.控制范围是监督项目和产品的范围状态、管理范围基准变更的过程，其主要作用是在整个项目期间保持对范围基准的维护。
2. 范围变更的原因。
（1）政府政策的问题。
（2）项目范围的计划编制不周密详细，有一定的错误或遗漏。
（3）市场上出现了或是设计人员提出了新技术、新手段或新方案。
（4）项目执行组织本身发生变化。
（5）客户对项目、项目产品或服务的要求发生变化。
3. 范围变更控制的主要工作。
（1）影响导致范围变更的因素，并尽量使这些因素向有利的方面发展。
（2）判断范围变更是否已经发生。
（3）范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理。
输入、输出、工具
输入
1.项目管理计划
2.需求文件
3.需求跟踪矩阵
4.工作绩效数据
5.组织过程资产
工具与技术
1.偏差分析（１０３）
确定实际绩效与基准的差异程度及原因的一种技术
输出
1.变更请求
2.工作绩效信息
3.项目文件更新
4.项目管理计划更新（范围基准更新、其他基准）
5.组织过程资产更新（造成偏差的原因，所选的措施和理由，得到的经验教训）