范围的概念包含两方面：
- 产品范围：产品或服务所包含的特征或功能；
- 项目范围：为交付具有规定特征和功能的产品或服务所必项完成的工作。
项目范围（Project Scope）是指生产(开发)项目的产品所牵涉到的工作和用来生产(开发)产品的过程。
两层含义：
- 必需的工作（无范围萎缩） —— 遗漏后会造成项目范围的萎缩
- 仅需的工作（无范围蔓延） —— 额外增加会造成项目范围的蔓延
项目范围管理是指对项目包括什么与不包括什么的定义与控制过程。这个过程用于确保项目组和项目干系人对作为项目结果的项目产品以及生产(开发)这些产品所用到的过程有共同的理解。
启动过程或项目章程(立项报告)完成后，项目范围管理开始进行，其主要过程有：
- 范围计划编制
- 范围定义（WBS）
- 范围核实
- 范围的变更控制
项目范围计划是指形成正式文件，为将来的项目决策建立基础，包括怎样判断项目和项目阶段已经成功完成的基本标准。简单地说，就是编写项目范围说明书（或工作约定书等等）的过程。
项目范围计划过程的主要输入（收集和参考的资料）包括项目章程(目标)和项目概述（包括产品描述、项目约束、项目条件假设等），而其主要输出（结果）是形成书面的范围说明书。
目标必项符合SMART原则：具体、可以度量、可行、可证明和观察、截止日期。
- 专家判断：在制定项目范围管理计划时，利用专家就以往同等项目的范围管理方式所做出的判断。
- 样板、表格、标准等
项目范围计划主要内容包括项目论证（可行性分析的简要内容）、项目目标、范围简述、项目交付成果简述、工作或服务内容（通常是乙方或厂商、开发方）、约束、假设和风险说明等等。
项目范围定义就是把项目的主要可交付成果分为较小的、更易管理的单元。
项目范围定义的输出（结果）就是工作分解结构（WBS）。
结构分解的工具是工作分解结构WBS(Work Breakdown Structure) ，它是一个分级的树型结构，是将项目按照其内在结构或实施过程的顺序进行逐层分解而形成的结构示意图。它可以将项目分解到相对独立，内容单一的，易于成本核算与检查的项目单元，并能把各项目单元在项目中的位置与构成直观地表示出来。
核心思想：化整为零
WBS的特点：强调结构性和层次性。按照相关规则（其内在结构或实施过程）将项目可交交付成果逐层分解开来，得到不同层次的项目单元，然后对项目单元再作进一步的分解，得到各个层次的活动单元。
类比法
类比法是以一个类似项目的WBS模板为基础（如PROJECT中的模板），制定本项目的工作分解结构（又如SAP的例子，有成熟的方法论）。许多组织建有项目的WBS以及其它项目文档的知识库。
自上而下法（系统思考法）
自上而下法常常被视为构建WBS的常规方法，即从整个项目开始，逐步将它们分解成下一级的多个子项。这个过程就是要不断地增加级数，细化工作任务。
自下而上法（头脑风暴法）
自下而上法是要让项目各个团队（成员）从一开始就尽可能地确定项目有关的各项具体任务，然后将各项具体任务进行整合，并归并到一个整体活动或WBS的上一级内容当中去。这种方法一般都很费时，但这种方法对于WBS的创建来说效果好。
工程项目中会用到，在IT项目中使用较少。注意团队间工作的接口。
对工作单元进行编码以后，还要说明每个单元的负责人、工作内容、经费预算等（WBS词典）。
4级WBS（4个数字）
第1位数：表示整个项目
第2位数：表示子项目要素编码
第3位数：表示子系统要素编码
第4位数：表示具体活动单元（工作包）编码
工作包是指处于工作分解结构最低层的可交付成果或产品，工作包原则上不超过两周(80小时法则，软件项目不超过3天)。
- 在各层次上保持项目内容的完整性，尽量避免遗漏工作单元。
- 一个项目单元只能从属于某一个上层单元，不能交叉。
- 项目单元应能区分不同的责任人和不同的工作内容。
- 项目结构分解应能方便工期、成本、质量等的控制。
- 详细程度适中。
WBS词典（字典）：是一个详细描述WBS每项条目信息的文件
范围基线：核准的项目范围说明书、WBS、WBS词典
- 范围核实是项目干系人对项目范围的正式承认。
- 项目组必须形成一些明确的文件（文档），说明项目产品范围及其评估程序，以评估是否正确和满意地完成了这些产品。
- 范围核实后，是项目将来进行验收的基准。
保持项目范围和用户需求的前后一贯性是非常重要的。
如果出现需要改变原定实施范围的需求，应以正式文档方式提出，项目小组成员必须谨慎考虑项目范围的改变或需求的改变，将对整个项目进程可能产生的影响，必须在批准后才能进行，在实施过程中必须加以跟踪。
范围变更的原因
- 项目外部环境发生变化
- 项目需求调研不够周密详细，有一定的错误或遗漏
- 国际上出现或设计人员提出了新技术、手段或方案，可以大幅度降低软件开发成本
- 用户单位本身发生了变化
- 客户对项目、项目产品或服务的要求发生变化
批准程序
- 提出项目变更、需求变更申请报告。
- 对于较小的范围改变，需要项目经理查阅和签字批准并内部存档，然后提交双方项目协调小组。
- 凡涉及到整个项目进展，费用成本调整较大的改变，必须交由双方（甲方和乙方）项目领导小组批准通过。
变更申请样式表
变更要求 |
系统名称： 序号： |
申请人： 日期： |
申请变更内容及状态： |
申请变更原因： |
变更影响度： 变更影响分析： |
变更类别： ☑A功能方面 ☑B运行功能方面 ☑C文档方面 |
授权人签字： 日期： |
管理目的是：
1.控制需求变更
2. 减小需求变更对项目的影响
需求变更管理RCM过程
- 记录变更日志
- 分析需求变更对工作、产品的影响（质量等）
- 估计变更请求所需的工作量 ，重新估计交付成果的进度（延后多少？）
- 估计增加或减少的成本
- 得出评审结果（通过否？）
- 若评审通过，则更改相应的工作产品（如软件） ，使其与变更的需求保持一致
- 若评审未通过，将需求变更请求表及相应文档存档
跟踪执行
- 需求变更申请报告签字后，开始正式执行；
- 调整相应的实施计划；
- 确定负责人，优先级等；
- 进度报告定期提交项目主管检查。
范围变更流程示意图
