之前几篇，聊了如何监控项目进度，成本和质量，监控这个话题还有最后一个方面 —— 如何监控项目范围。
项目范围其实在项目初期就已经确定，基于那个确定了的项目范围，项目经理做计划，定成本，要资源。
但是事实上，随着项目的展开，项目需求经常会发生变化。我们之前也分了几篇讨论项目的需求管理，为的就是在项目范围发生变化的时候，项目计划，项目成本，项目交付物都能够同时更新。
所以从这点而言，项目经理在每天追踪项目的时候，需要同时监控项目范围。那么具体怎么做呢？
1. 收到的需求建立Excel记录
针对每一个变更，有自己的变更ID，变更内容，影响分析以及最终状态，是同意添加到项目还是拒绝。
2. 由专人负责变更需求的跟踪，确保所有的变更都能够走完整个流程。
即收到变更请求后的影响分析，然后发送回客户方，等待客户定夺是否要加入项目中。最终将客户的决定更新到Excel中，如果同意，则更新项目计划，项目成本，和项目范围。如果不同意，则保持原样。
3. 针对客户同意的需求变更，需要更新相关文档
相关的文档包括，项目计划，项目成本，项目范围，RQM的更新，以确保新增的功能能够不被遗漏的设计，实施，测试。
这里着重讲一下变更流程。我在之前的一篇以也有讲过，需要在项目开始初期就设定变更流程。（详细请看第二十三篇）
现实项目中，经常会发生客户随意变更的情况，于是团队玩命的加班为了应对客户的变更。这就是项目变更流程没有执行好的情况。从而造成项目范围增加了，工时没有相应增加。面对交付日期，团队只能玩命赶。
这是不提倡的一种做法。任何的变更，是需要客户相关人员批准的。随意的变动，一方面会造成项目团队疲于奔命。另一方面，对于最终交付的功能也是一种考验，是否要求增加功能的成员能够代表客户来提这个需求？还是仅仅是此人的单方面想法？
对于多团队协作开发的项目中，此类问题尤其明显。跨国团队追求的各地区标准化统一化，而各个地区的当地团队则更专注于解决当地特有的问题。出发点不同，谁都没有错。只是这样就会造成全球团队和当地团队需求的矛盾，一旦矛盾听谁的？更严重的是，很多情况下，当地团队的需求，全球团队根本不知情。此时做还是不做？
这个时候需求变更流程就展现了存在的意义。而对于自己团队，通过Excel维护每一个变更的状态，无论对内还是对外，都可以做到有迹可循。从而大大减小团队间的沟通鸿沟。并且针对每一个变更，相应的项目计划，成本等等都可以做到一旦批准一起随着项目范围的增加而增加。从流程上降低了只变范围不变计划的情况，减少了开发人员疲于奔命的赶得情况。
所以对于项目范围的监控，是确保项目能够按时交付的重要一环。切不可掉以轻心。
