范围管理是什么？
项目范围管理包括了确保项目做且只做成功完成项目所需的全部工作的工作的各过程。管理范围主要在于定义和控制项目应该包括什么和不应该包括什么。项目范围各过程包括：确定项目的需求、定义规划项目的范围、创建范围基准、范围的变更控制管理以及范围核实等。
范围是什么？
基于项目范围我们知道正确的范围应该是只做成功完成项目所需的全部工作。产品范围定位某项产品、服务或成果所具有的特性和功能。项目范围为交付具有规定特性与功能产品、服务或成果而必须完成的工作。这个过程用于确保项目组和项目干系人对做为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解。
案例分析
M集团是希赛信息技术有限公司(CSAI )多年的客户，CSAI已经为其开发了多个信息系统。最近，M又和CSAI签订了新的开发合同，以扩充整个企业的信息化应用范围，张工担任该项目的项目经理。张工组织相关人员对该项目的工作进行了分解，并参考了公司同M曾经合作的项目，评估得到项目，总工作量60人月，计划工期6个月。项目刚刚开始不久，张工的高层经理S找到张工。S表示，由于公司运作的问题，需要在4个月内完成项目，考虑到压缩工期的现实，可以为该项目在增派两名开发人员。张工认为，整个项目的工作量是经过仔细分解后评估得到的，评估过程中也参考了历史上与K企业合作的项目度量数据，该工作量是客观真实的。目前项目已经开始，增派的人手还需要一定的时间熟悉项目情况，因此即使增派两人也很难在四个月内完成。如果强行要求项目组成员通过加班等方式追逐4个月完成的目标，肯定会降低项目的质量，造成用户不满意。因此，张工提出将整个项目分为两部分实现，第一部分使用三个半月的时间，第二部分使用三个月的时间，分别制定出两部分的验收标准，这样不增派开发人员也可以完成。高层经理认为该方案可以满足公司的运作要求，用户也同意按照这种方案进行实施。六个月后，项目在没有增加人员的前提下顺利地完成，虽然比最初计划延长了半个月的工期，但既达到了公司的要求，客户对最终交付的系统也非常满意，项目组的成员也没有感受到很大的压力。
原因
软件项目的范围主要是由系统需求构成的，而系统需求既是难以把握的，也是容易调整和控制的。软件系统的需求来源于用户需求，在软件项目目标是满足用户需求的情况下，对于相同的用户价值可以定义出不同的系统需求。举一个简单的例子，用户的需求是“解决口渴的问题”，那么最简单的系统需求可以是递上一杯水，复杂一些的可能是递上一杯热水，更复杂的是递上一杯经过多层过滤的纯净水，当然也可以是打一桶虎跑泉的水，然后沏上一杯龙井茶。用户当然希望用买矿泉水的钱换一杯正宗的龙井茶，但这样的项目范围肯定会导致项目失败。
既然项目范围界定不清是一种很常见的现象，而这种现象又是大家所不想见到的。那么，我们必须分析出现这种现象的原因。我认为造成这种现象的出现有以下三方面的原因：
第一，是企业一级的责任——没有完善的项目管理体系来指导项目的管理。这种情况是最糟糕的，如果是这种原因，那么项目的成败往往需要靠项目经理个人的管理、领导能力。这种情况项目成功的可能性非常小，大部分项目都是以失败而告终；
第二，是企业及项目组共同的责任——对项目没能制定出清晰规范的范围变更控制过程。企业有管理体系，但不够完善和规范，对项目组的变更过程的制定没能起到有效的指导作用。变更是不可避免的，只要有效地加以管理、控制，同样可以达到各方满意的结果；
第三，是对范围的定义不够明确，做不到可量化、可验证程度。很多时候都是一些定性的要求、而不是定量的，例如“界面友好，可操作性强，提高用户满意度”等。类似这些模糊的需求就是导致后续项目扯皮的根源。项目范围的明确定义，有经验的项目经理及系统分析员将起到至关重要的作用。
由以上的论述，可以得出结论：完善的项目范围管理是整个项目最终成败的关键。那么，怎样才能做好项目范围管理呢？
如何实施呢？
首先，我们必须先了解项目范围管理的一些科学过程。做好项目范围管理主要可以分为启动阶段、规划阶段、监控阶段。启动阶段包括制定项目项目章程和干系人识别。规划阶段主要包括需求的收集、定义范围、创建工作分解结构等子过程。监控阶段主要包括核实范围和控制范围。下面将详述此过程怎么做这个过程。
启动阶段
启动阶段包含了获得授权、定义一个新项目或现有项目的一个新阶段，正式开始该项目获阶段的一组过程。通过启动阶段，能够定义初步的范围和落实初步财务资源，识别那些将相互影响项目总体结果的内外部干系人，确定项目经理。启动过程输出项目章程和干系人清册、干系人管理策略。其中项目章程是一个重要的文档，这个文件正式承认项目的存在并对项目提供一个概览。项目章程将粗略地规定项目的范围，这也是项目范围管理后续工作的重要依据。项目章程中还将规定项目经理的权利以及项目组中各成员的职责，还有项目其他干系人的职责，这也是在以后的项目范围管理工作中各个角色如何做好本职工作有一个明确的规定，以致后续工作可以更加有序地进行。因此，千万不能忽略项目的启动过程。
规划阶段
规划阶段主要包括收集需求、定义范围、创建工作分解结构几个过程。
收集需求
需求是指项目发起人、客户和其他干系人的已量化且记录下来的需要与期望。项目一旦开始，就应该足够详细地探明、分析和记录这些需求，以便日后进行测量。收集需求旨在定义和管理客户的期望。需求是工作分解的基础。成本、进度和质量规划也都要在这些需求基础上进行。收集需求的技术手段主要包括访谈、焦点小组会议、引导式研讨会、群体创新技术、群体决策技术、问卷调查、观察、原型法。收集需求阶段主要的输出是需求文件、需求管理计划、需求跟踪矩阵。
需求文件描述了各种单一需求将如何满足于项目相关的业务需求。一开始肯定只有概括性的需求，随着信息的增加而逐步细化。只有明确的（可测量和可测试）、可跟踪、完整的、相互协调的，且主要干系人愿意认可的需求，才可能做为基准。
需求管理计划描述在整个过程中如何分析、记录和管理需求。主要包括：
如何规划、跟踪和汇报各种需求活动
配置管理活动
需求排序
产品测量指标以及这些指标的理由
需求跟踪结构即哪些需求属性需要列入跟踪矩阵，并可以在哪些文件中追踪到这些需求
需求跟踪矩阵
主要是一张需求与需求源的表格，以便在整个项目生命周期中队需求进行跟踪。典型的属性包括独特的识别标志、需求的文字描述、收入该需求的理由、所有者、来源、优先级、版本、现状和实现日期、验收标准等。
定义需求
定义需求是制定项目和产品详细描述的过程。应根据启动过程中记载的可交付成果、假设条件和制约因素来编制范围说明书。定义需求产出物为项目范围说明书。范围说明书描述的是项目可交付的成果，以及为提交这些可交付成果而必须开展的工作。它为评价变更请求或额外工作是否超出项目边界提供基准。详细的范围说明书应该包括范围描述、产品验收标准、项目可交付成功定义、项目的除外责任、项目制约因素、项目假设条件。
创建工作分解结构WBS
工作分解结构的建立对项目来说意义非常重大，它使得原来看起来非常笼统、非常模糊的项目目标一下子清晰下来，使得项目管理有依据，项目团队的工作目标清楚明了。
WBS是以工作结果为导向的工作分解。制定好一个WBS的指导思想是逐层深入。先将项目成果框架确定下来，然后每层下面再把工作分解。控制账户是一种管理的控制点。在控制点上，把范围、成本、进度加以整合，并把他们的挣值进行比较，以测量绩效。
工作分解结构词典包括以下内容：账户编码标志号、工作描述、负责组织、进度里程碑清单、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、合同信息。
制定范围基准
范围基准包括项目范围说明书、工作分解结构WBS、工作分解结构词典。范围基准相当于一个标杆，后续的时间管理计划、成本管理计划都是依托于范围基准进行制定，当范围基准进行调整，其他部分都将无法避免的需要进行调整。
范围说明书与系统解决方案、软件需求说明书几者的区别？范围说明书描述了要做什么，做完了提交什么成果。系统解决方案解决如何做的问题，阐述采用什么技术、变成语言、网络架构、管理规范等，解决方案更多的是一种积累或思路展示。软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。它的编写依据就是工作范围说明书、解决方案以及与用户的需求采集，它又将会成为概要设计的依据。软件需求说明书说明的内容，主要是对项目产品特征和特性进行描述，而不牵涉双方的责任和义务。
监控阶段
核实范围
核实范围与质量控制区别，核实范围主要关注可交付成果的验收，质量控制关注可交付成功是否正确已经是否满足质量要求。所以一般先进行核实范围，然后再进行质控控制。
控制范围
控制范围是监督项目和产品的范围状态、管理范围基准变更的过程。对项目范围进行控制，就必须保证所有的请求变更、推荐纠正措施或预防措施都经过实施整体变更控制过程的处理。定期产生工作绩效信息，描述哪些可交付成果已开始，其进展如何，哪些可交付成果已完成。
一个项目的范围计划可能制订的非常好，但是想不出现任何改变几乎是不可能的。因此对变更的管理是项目经理必备的素质之一。变并不糟糕，糟糕的是缺乏规范的变更管理过程。范围变更的原因是多方面的，比如用户要求增加产品功能、环保问题导致设计方案修改而增加施工内容。项目经理在管理过程中必须通过监督绩效报告、当前进展情况等来分析和预测可能出现的范围变更，在发生变更时遵循规范的变更程序来管理变更。
参考资料：
项目管理知识体系指南
百度百科：项目范围管理