其中项目范围管理对其他各项产生直接或间接的影响，项目的范围直接决定了项目组成员架构，决定了时间、费用、人力资源、项目风险等。同时间接影响了项目质量、沟通、采购等内容。可以说项目范围是否定义的精准，直接决定了项目的成败。要真正完整理解并制定好一个项目的项目范围，需要从以下几个方面着手。

一、 理解什么是项目范围

    要定义一个完整精确的项目范围，首先要了解什么是项目范围。项目范围包括哪些内容。项目范围会收到哪些因素的约制。

    所谓的项目范围，通常是指在一次项目活动中需要完成的内容和活动，一个项目的范围最主要的部分是客户的需求。要定义精确的项目范围，需要深入的了解客户对项目的期望与需求。然而，期望只是一种理论上的需求，它与真实的需求不能等同看待。

    项目范围究竟包括哪些内容，这个需根据项目的实际情况来定义。不过以下内容肯定是项目范围不可缺少的部分：

    1.项目结束时，我们需要交付给客户的内容。以PLM项目实施为例，包括完整可用的系统，里面可能包括文档与物料管理的内容，工程变更管理的内容等等；项目的各种产出文档比如安装手册，SOP，需求分析文档等。

    2.项目过程中，为完成客户需求，客户需提交给项目执行者的各种资料。

    3.项目过程中双方沟通与交换意见的机会与文档等都属于项目范围定义的一部分。比如我们需定义项目期间的各种例会等。

    然而，客户的需求也不一定要转化为项目的范围内容。真正的项目范围除了客户的需求外，还受各种客观约束条件限制。在约束条件之外的需求通常不能转化为项目的范围，除非增加额外资源。比如一套PLM系统，可以完成诸如文档、物料、变更等管理内容。但是如果客户提出完成库存管理的需求，以PLM系统而言就无法完成。这就是客观约束条件的限制。但是如果客户同意在该项目期间内容通过二次开发与ERP进行这方面功能的集成的话，该项需求就可以成为项目范围，这也就是增加了额外资源。

    通常，一个项目的正确范围应该是客观约束条件与客户需求的交集（如下图一）。项目范围不能超越客观约束条件，也无需超越客户的需求。

图一

    在具体执行项目时，项目范围定义越细致越清晰也就越好，一个好的项目范围管理不但代表项目团队的项目管理水平，也是项目成功的必要条件。

二、 认识项目范围管理的重要性

    说项目范围管理非常重要，这个可以说任何一个做项目的人都不会否认。但是，是从心底认识到了呢还是嘴上认识到了？这个就不一定了。我们见过太多因为项目范围定义模糊不清而导致项目做成无底洞直到项目失败的案例。

    这些人为什么看到这么多失败案例还继续对项目范围管理的重要性熟视无睹呢？这个通常可以从三方面来探讨原因：

    其一是时间问题。现在很多项目甚至在项目范围的轮廓都还未清晰的情况下就已经将项目时间安排好。结果是项目来适应时间，而不是时间遵从于项目范围。这样往往导致没有足够时间来定义项目范围就匆匆开始项目的执行。这是一种本末倒置的项目执行方法。可以说没有项目管理者愿意这样做，但是迫于各种内外压力他们又不得不这样做。

    某个项目组就曾经就遇到过一个这样的项目，客户希望该项目组能够在四十个工作日内完成PLM系统与ERP系统在某个功能上的集成。通过时间预估，该项目组发现无论如何，在四十个工作日内都无法完成。但是客户非得如此。迫于内外压力，该项目组还是接下该项目。由于时间过于紧迫，该项目组无法对客户的需求做详细的了解，仅凭以往做类似项目的经验去理解客户的需求。到了后来，发行根本扭头不对马嘴。客户的需求根本不是该项目组经验里存在的东西。最后弄到双方不欢而散。

    其二是客户对范围了解不清，这个是项目管理中一个非常常见的问题。客户对这个项目有迫切需求，但是对自己到底需求哪些内容不甚了解，而导致项目无法完整的定义出项目范围。当项目真正开始执行时，客户慢慢的在执行过程中开始对自己的需求有了精确的了解，然后就开始不断的要求项目成员修改、添加项目内容。导致项目时程及资源的安排一次次的被打乱。项目执行一次次的偏离预定目标。其实对于这种状况，作为项目管理者理论上应该有能力帮助客户。当客户对自己的需求范围理解不清时，一个有行业经验的项目管理者，完全可以通过引导、询问和假设的方式，用自己的经验与客户一起把客户的需求理清。但是如果是对客户这个行业没有经验的管理者，恐怕就做不到这些。项目范围的需求完全由客户说了算。没办法对客户的需求进行梳理与建议。

    由于缺乏行业经验，导致项目延期甚至失败的例子也屡见不鲜。某个军工企业，因为管理需要需上一套PLM系统。三年来，已经有4家PLM实施者被扫地出门。谈起这段痛苦的PLM上线之途。该军工企业的IT负责人不无叹道：“这帮人根本不了解我的需求。”如家该军工企业依然在寻找一个有该行业实施经验的团队来为期实施PLM系统。

    其三是技术至上论。技术至上论也是导致项目失败的重要原因。技术至上者往往对项目执行之外的管理熟视无睹。他们任务项目是否成功，完全在于技术上是否可行。其他的都是次要原因。持这种观点的人往往将项目理想化，的确，如果你有足够的资源，只要技术可行，理论上这个项目一定是成功的项目。技术至上者往往对项目范围管理嗤之以鼻。他们很少去深入了解客户的需求。客户说出的任何需求，他们只从技术上考虑是否可行。全然不过其他资源是否能够满足这个需求。同时，技术至上者很少甚至不去写什么需求文档。他们往往认为，写和不写都一样，客户的需求都应该满足——除非技术上不可行。

    技术至上论导致项目失败的例子更是司空见惯，这里就不举例了。

    以上三种状况是导致项目范围失控的主要原因。归纳起来包括客户和项目执行者双方的原因。但项目执行者往往应承担更大的责任。因为客户项目的是主动方，而项目执行者是项目的被动方。当项目失败时，项目执行者将收到更大的损失：花了时间，拿不到钱，丢失潜在的商业机会，还有最重要的是您的信誉受到损害。

三、 合理进行项目范围管理

    概而言之，要管理好项目范围，需要做到三个深入了解：一要深入了解客户需求，二要深入了解客观约束条件，三要深入了解行业背景。

    深入了解客户需求，就是需要花时间去了解客户当前的问题所在，客户对当前项目有什么期望。通常，客户的需求不一定全是真命题，有时候是个假命题：看似一个正常的需求，实则通过分析，你会发现它其实不是个需求，或者该需求已经包含于其他需求之中。比如在PLM项目中，同样是文档管理，很多客户会告诉你我的产品相关的文档要怎样管理，我的项目产出物(Delivery)相关的文档管理要怎样管理。这些看似两个需求，其实归纳起来都是文档管理的需求。要深入了解客户需求，就要有深厚的客户所在行业知识背景。没有相关知识背景，就会被客户的需求牵着鼻子走。无法透过现象看到客户的本质需求。深入了解客观约束条件则是对双方提供的工具和所处的环境要有深入的认识。以PLM项目为例，项目执行者需要了解其所实施的系统的功能，所使用的软硬件环境等。

    要管理好项目范围，需要一个完善的项目范围计划。我们在清楚客户需求后，需要将客户需求书面化，进行项目范围计划的制定。首先定义项目的宏观范围，然后对宏观范围进行细化。对客户的每个需求进行评估、归类、分析等，并设定需求的执行条件和期望目标。比如，在PLM系统中，我们对某个流程签核进行需求评估时，需要确认该流程使用于哪些变更；流程每个状态的类型；每个状态的签核者、观察者；在这些状态中流程使用者都拥有哪些权限等等都需要一一理顺，成条成文。

    要管理好项目范围，需要对每个需求的可用资源进行合理分配。合理分配资源，是项目范围管理的一个重要内容。这些资源包括人力资源、时间资源、成本资源等。

    要管理好项目范围，还需要有一个好的需求变更管理机制。一个制定的再好的项目范围，也不能保证在项目执行过程中没有需求变更产生。一点产生了需求变更，则项目的各项资源都被打乱，需要重新进行分配。资源的重新分配小到进行时间资源的局部调整，大到人力资源，时间资源甚至成本资源等各项资源的再安排。所以良好的需求变更机制是非常必要的。需求变更管理作为项目范围管理的一部分，是在项目进行之前，由项目执行者和客户之间事先商定的一套关于项目需求变更的管理办法。需求变更包括客户对已有的需求进行修改或者客户添加新的需求。