那么，什么是项目范围和项目范围管理呢?项目范围是指产生项目产品所包括的所以工作及产生这些产品所用的过程。项目干系人必须在项目要产生什么样的产品方面达成共识，也要在如何生产这些产品方面达成一定的共识。
项目范围管理是指对项目包括什么与不包括什么的定义与控制过程。这个过程用于确保项目组和项目干系人对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解。
本文从两个真实的案例开始。第一个案例，是09年项目组内部基于一个管理理念，开了一套分析报表。刚开发出来时，为了想加快这套分析报表的成熟和推广，因此首先选了一个关系不错的单位做试点，想通过该单位使用，创建一个样板，然后在公司全面推广。愿望是美好的，而现实总是没有愿望那么美好。这套分析报表的理念，与该单位的管理思路不一致，更要命的是，项目组和该试点单位，都对这个报表产品没有一个清晰的愿景。于是，项目实施的过程，就是重复着“项目组修改-用户验证-不满意再修改-再验证”。之前预计一个月的实施周期，结果实施了一年后还看不到结束的迹象，最后只好宣告失败，以终止该实施项目。在这个过程，项目组正常的产品开发受到影响，而用户的正常月度考核指标，也不同程度的受到了影响。项目管理论坛
第二个案例，还是与报表相关，是一个报表定期推送的产品，即定期生成统计报表，然后通过邮件的方式直接推送给相关的用户。这个产品，项目组内部经过了多次的调研，获得到了真实的需求，产品开发完成后，内部试运行了一段时间，且相关的培训文档和 实施推广流程都定好了之后，才在各单位进行推广。这次推广实施的效率很高，基本上每两周就完成一个单位的实施，且用户反馈很好。
正反两个案例，笔者都全程参与了，因此在最近的复盘会议上，项目组一致认为，一个成功的实施项目，应该要有以下个要素：
第一：练内功：实施推广的产品，要有核心的价值，给用户带来的实实在在的收益。项目经理博客
首先，要有拿得出手的东西，能切实给用户还带来价值，或者是解决用户当前重要或紧急的问题。当有了这样一个核心价值，那么，即使提优化或修改，也会围绕着核心价值这个中心来来进行。转自项目管理者联盟
需要克服的是，不要认为是在公司内部，大家可以互相理解，东西差一点，也就将就着用，再说是实施嘛，肯定要有修改。第一个案例中，大家开始的心态就是这样，到了最后，觉得“理解”的成本实在太高，高到无法接受了。
第二：定方案：确定实施方案，让用户心中有数。
定方案，主要是指确定实施的步骤，以及在各步骤，需要被实施单位配置的事项、步骤准出的准则，通过这个实施方案，主要是明确项目组和被实施单位的职责，让被实施的单位，做到心中有数。
有了这样一个理解一致的方案，项目组与实施单位沟通时也更容易，因为大家对整件事理解是一致了。从心理上来说，人总是在追求一种安全感，如果让用户知道整个步骤，那么可以让用户感觉到，一切还是可控。
第三：说丑话：明确实施的范围，让用户的期望回归合理。
对于IT系统这样的产品，产品开始使用后，可能存在或多或少的不足甚至是缺陷，因此在实施前，需与用户确认哪些情况的修改项目组会响应，那些情况的修改，项目组不会考虑响应。当然在具体的表述，一般我们是从实施的目标说起，说这个主要是验证该产品是否适合实施单位，因此只会响应哪一类的修改请求。重点的一点，是要与实施单位明确：只要对实施的范围达成了一致，才能启动实施过程，
实施，如果连范围都确定不了，那么这个实施，基本上会是一个失败的实施项目。对于失败的项目，越早结束越好。另外，，一开始就明确这个范围，那么用户在提变更需求时，首先要过滤一下，看看是否该提，这样一来，大大减少双方的的沟通成本。
第四：有变更? CCB：业务单位和项目组是一家，控制蔓延最重要。
实施过程中的例外情况，应该通过CCB会议的方式，大家一起来决策。CCB的成员构成，建议由实施项目的项目经理、项目组核心成员、实施单位的领导和核心成员。通过CCB会议的方案，集体决策，让实施单位融合到实施项目里来。
在CCB会议，大家要紧扣项目目标，严格控制范围。范围蔓延，应该项目组和实施单位都要来控制的现象。
之所以要采用双方CCB会议的方式，主要是避免以某单方面武断的结论，引起另一方的不满，从而在实施过程中，双方不能形成合力。项目管理者联盟
