需求管理在项目管理中，其实就是范围管理，客户想要实现的需求，就是项目要实现的范围。只是在实践中，甲方想要的需求和乙方所做的范围就像是两个圆，它们的关系可能是相离、相交、包含、重合，一下能达到重合的，多半是理想情况，多数情况下，是要把两个相交的圆，想办法弄成重合或是尽量重合。
为什么一开始，就不能画个重合的圆呢？这与项目的一次性、独特性、风险性等特性有关。项目不同于产品，可以多次重复复制，它往往是根据特定客户的特定需要而新建的，在这之前，没有人知道项目的成品究竟是什么样子，只能有个初步的设想和规划，项目实施方，是否能够完全理解客户的需求也是个问题。对于和业务挂钩的软件项目来说，业务也不是一成不变的，业务怎么变，往往依据外界环境，而外界环境会怎么变，又有很多不确定的因素。在项目的进行过程中，又会遇到什么样的事件，也充满很多不确定性。如此种种，造成了项目的范围管理既重要，又有些许无奈。
重要之处在于，范围是项目实施的基本蓝图，没有范围，项目也就不知道该从何处下手，更不知道要做什么、不做什么。无奈之处则是因为无论前期计划得有多么好，还是不可避免地会遇到范围发生变更，不得不在后期进行调整和改动。
项目管理中，范围管理包括5个部分，依次是：收集需求，项目范围定义，创建工作分解结构，项目范围确认和项目范围控制。
1.收集需求是项目范围管理的首要工作
有需求，才有项目做。需求不仅仅解决客户想要什么的问题，还要考虑到具体的市场环境、竞争关系、技术水平、法律政策等。这么看来，收集需求可不是一个轻松的活儿。
你可能要从项目的重要干系人那里，了解到足够充分的信息，并将这些信息综合起来，从而构思整个项目的需求。于是也就有了第二步，定义项目范围。
2.项目范围定义的主要工作是对收集到的需求进行进一步分析、归纳、整理，明确项目的目标、基本内容、可交付成果等，输出项目范围书
关于项目目标的确定，管理学上常用SMART原则，该原则也常常被用在目标管理上。即目标应该具备以下5个特质：Specific（具体性）、Measurable（可衡量性）、Attainable（可实现性）、Relevant（相关性）/Result-oriented（关注结果）和Time-based（时间性）。
3.创建工作分解结构，是把大目标逐步细化成小目标的过程
让你一口吃进去一颗西瓜显然很是费劲，但若是切成一小块一小块吃，就容易多了。工作分解结构也是如此，把大目标按照一定的逻辑层次划分、再划分，分解成一个个明确的、可行动的小任务。有了这些小任务，行动起来就知道该如何着手，对于如何分配工作、如何控制进度、如何保障质量、哪里需要控制风险，也都指明了方向。
4.确认项目范围
工作分解结构创建好了，是不是立刻就能开始干活儿了？且慢，别忘了和你的客户确认一下，即第四步，确认项目范围。这是不是他想要的，这样的分解是否合理、是否有遗漏？如果没有问题，签字确认后，这个工作分解结构才算是能够正式采用了。
5.项目范围的控制
最后一步，就是项目范围的控制，也常被叫做需求变更。尽管前期做了那么多准备和确认工作，但也难以保证项目在实施的过程中不发生变化。有时候是外界环境变化导致项目需求变更，有些时候是在定义范围时出现了错误或遗漏，也可能是在项目进展过程中，组织发生变化，或者客户对产品的要求有所变动。
变动发生后，就需要对原有的范围做一些修正，即偏差分析。分析这些变化对整个项目带来的影响，对现有的工作分解结构进行改动，必要时对进度和成本也要进行适当的调整。相关的文档也需要及时更新。
如何能做好项目的范围管理呢？作为需求的提出方，需要尽可能明确地表达想要实现什么样的目标、描述清楚流程、关键节点；对项目的实施方来说，则是要在前期尽可能了解和熟悉客户的业务，甚至能够站在更高的角度、更全面地思考，对于客户未曾考虑到的细节，也要进行沟通和确认，更要设身处地地站在客户的角度思考如何使用、如何操作。
写到这里，不由得想起自己最近在做的一个项目，在实施前与实施方的项目经理和开发人员沟通时，看到他们拿着我们的需求一脸懵逼、却连连点头说自己明白了的样子，就意识到后期会有很多问题，果然不出所料……真是一把辛酸泪~~~
