真正厉害的项目经理，既能交付得了项目也能控制得了范围

真正厉害的项目经理，既能交付得了项目也能控制得了范围

项目实施中，项目经理会遇到各种问题，其中很典型的问题就是客户不停的要求项目组满足他们的各种需求，需求不断扩展，项目经理考虑到客户满意度，又不好意思拒绝，心里也明白不能不停的答应客户的各种需求。这样的循环中，工程无法进行验收，项目的时间成本、人力成本浪费巨大。

在这里，需要提及一个“范围管理”的概念，项目中哪些该做，哪些不该做，做到什么程度，都是由“范围管理”来决定的。那么，到底什么是“范围管理”呢？ 

有没有一些项目经理遇到这样一种情况，项目组参与一个项目做了半年，项目的合同范围是客户自己编写的，项目经理在了解到基本需求后就开始施工，根本没有太多的交流，需求文档就更没有这个东西存在了。

工程进展深入以后，用户不断提出新需求，每天追着项目团队成员解决各种问题，项目实际成了一个无底洞，没完没了的往下做，实在做不下去了，只能无期限的往项目里面堆人。

这个例子听起来感觉很无奈，其实真正做项目经理的，才会体会到这其实是一个项目范围管理的问题。所以工程项目实施前，一定不要吝惜花费时间，去做客户需求的调研，并切记要准确控制好项目范围。孙子兵法中多次提到“知”字，在一个项目中，我们应该知道对方需要什么，自己要去做什么，这是项目成功的而基础。那么首先要明确的是想范围管理中的范围是如何定义的？

一、如何定义项目范围，它又是什么？

先来看看什么是项目的定义，项目就是为完成产品或服务所做的一次性努力。这里有两个范围的概念，分别是产品范围和项目范围，在确定范围时首先要确定最终产生的是什么，它具有哪些可以清晰界定的特性，要注意的是特性必须要清晰，以认可的形式表达出来。比如文字、图表或某种标准，能被项目参与人理解，绝不都能含含糊糊，模棱两可，在此基础之上才能进一步明确需要做什么，才能形成所需要的产品。

产品范围是指产品或服务所包含的特征和功能，项目范围是交付具有特定特征和功能的产品或服务所必须要完成的工作。

举例说明一下，某客户的项目交付，客户购买了欣尧公司的诸多产品，客户在欣尧项目组完成了产品测试后提出了需求，原文如下：截止目前，防火墙、服务器、交换机、路由器的配置已经基本完成，并进行了切换测试，完成了大部分配置和测试工作。

后期请项目组继续在现场对各个环节的细节进行完善，对防火墙相关配置、网址过滤等功能继续进行测试和培训。

并且客户提出了提供上网代理的要求，这个是目前这个产品甚至主流防火墙没有的功能。

看到这里，就可以很明确的知道，客户虽然进行了测试的签字确认，但是工程中没有确定项目范围，提出了培训的需求，没有确定产品范围，又提出了防火墙代理的要求。

这就使得项目不能一次性签字验收通过，这就是需求范围的不停扩大，导致不能及时闭环。

二、那如何做好范围管理？

范围管理保证项目包含了所有要做的工作，而且只包含要求的工作，它主要涉及定义并控制哪些是项目范畴内的，哪些不是。范围管理的基本内容包括：项目启动、项目计划编制、范围合适、范围变更控制等等。一下所描述的是其中比较重要的部分：

1.编制范围计划

要做一个优秀的项目经理，管理好项目范围，那良好的技术和方法是必须的。项目失败的原因中，计划失败是最多的，一年之计在于春，一天之计在于晨，老祖宗都知道项目开始的时候，计划有多么重要。

首先要周密的做好范围计划编写，范围计划编写是将产生项目产品所需进行的项目工作（项目范围）进行文字性细化和归档成文的过程。做范围计划需要考虑很多信息，比如：

产品描述，首先要清楚最终产品的定义才能规划要做的工作；

项目章程（典型的例子是合同）是非常主要的依据，通常它对项目范围有了粗线条的约定，范围计划就是在此基础上进一步深入和细化。

范围计划中个究竟应该包含哪些内容呢？不同的计划详尽程度自然不一样，其中范围说明和范围管理计划必须包含在内。

范围说明在项目参与人之间确认或建立了一个项目范围的共识，作为未来项目决策的文档基准，范围说明中至少要说明项目论证、项目产品、项目可交付成果和项目目标。

项目论证是商家的既定目标，要为估算未来的得失提供基础，项目产品是产品说明的简要概括，项目可交付成果一般要列出一个子产品级别的概括表。

例如：为一个设备集成项目设置的主要可交付成果可能包括：设备网络的拓扑设计和实施，设备的安全性设计和实施，传输布线等。任何没有明确要求的结果，都意味着它在项目的可交付成果之外。

项目目标是要考虑到项目的成功性，至少要包括成本、进度表和质量检测，项目目标应该有标志：如成本单位，和绝对的或相对的价值：如不少于150万美元等。

不可量化的目标如：客户的满意程度，要承担很高的风险。说的明白一点，范围不要说什么满意啊，客户感知之类的词语，一定要具体量化的数字、表格和图表上来。

范围管理计划是描述项目范围如何进行管理，项目范围怎样变化才能与项目要求相一致的问题。它应该包括一个对项目范围预期的稳定而进行的评估，比如项目范围进行了怎样的变化，变化频率以及变化了多少。

范围管理计划也应该包括对变化范围怎样确定，变化应该归为哪一类型，实际上做到这些特别困难，但绝对有必要对这些问题进行清楚的描述。

2.范围分解

计划明确了，然而具体应该做那些事情，还没有明确到位，因为完成项目是一个复杂的、耐心梳理的过程，必须采取分解的手段把主要的可交付成果分成更容易管理的单元才能一目了然，最终得出项目的WBS（Work Breakdown Structure：工作分解结构）。恰当的范围定义对项目成功十分关键，当范围定义不明确时，变更就不可避免的出现，很可能造成返工、延长工期、降低团队士气等一系列不利的后果。

比较常用的方式是以项目进度为依据划分WBS，第一层是大的项目成果框架，每层下面再把工作分解，这种方式的优点是结合进度划分看起来只管，时间感强，在评估中容易发现遗漏或多出的部分，也更容易被大多数人理解。

3.范围变更

一个项目的需求范围，即使做的再好，也很难避免需求变更，比如基建的改变、产品功能的增加、设计方案的变更。变更并不一定都是坏事，但是变更一定要准许规范的变更管理过程。所以变更一定要做到预测可能出现的范围变更，在发生变更时，按照变更程序来管理变更，具体的变成流程，需要项目组结合实际情况进行讨论和研究。

如何做到严格、高效、实用的项目范围变更流程，对管理项目非常重要。