矛和盾
我感到惊奇的是我在上个月与Terry就已经有过一次会议了。Terry是一个项目经理，她所管理的项目是要把老式的车间报告搬到Web上去。当我在上个月遇见她的时候，我就想她只需要四个星期就可以完成任务了。可是现在已经过了六个星期了，还要四个星期的时间。
“Terry,”我说到。“究竟发生了什么？你的项目花的时间比预计的要长很多，但我没有看见也没有听说你已经落在时间表的后面了。
“有一些项目范围上的改动使我们不得不推迟结束的时间，”Terry说。“但是，你可能会高兴，我正在进行范围改动的经营。每个改动都是经过了赞助商同意的，所以我们得到了额外的经费和时间上的推延。”
“那么怎么解释没有人抱怨呢，”我问到。“你得到了哪些类型的改动要求？”
“它们大多数都是增加额外的特色和功能，对我们目前的软件的改动很小，”她说。“那就是为什么我们能够对付其中的大多数。它们并不需要我们这个团队做太多的工作。”
“那么以后会怎样呢？”我问到。“你能够在四个星期内完成这个项目么？”
“这不清楚，”她有点担心的说。“大多数的车间主任都没有足够的Web经验。他们现在越来越熟悉这个环境，他们就发现他们应该加入更多的功能。”
“喔，那还不完全是好事，”我说。“软件项目应该是暂时的工作来产生一套可发布的软件。它们需要在一定的时候结束。我恐怕你会处在一个不好的境地，你的项目没完没了的进行下去，做一些很小的改动带来增加的，但是不重要的商业利润。”
Terry 同意我的观点。“实际上，我想开发团队已经开始失去注意力和热情了。我有些担心我们开始变得有些懒散了。”
“我们应该跟你的赞助商谈谈结束这个项目的事情了，”我建议。“这不是说他们就没有机会做更多的改变了。如果额外的修改确实存在商业价值，让我们在以后在考虑加强它们。”
忠告
在大多数项目里，项目的赞助商着眼于在双方同意的预算和时间界限的范围内完成原定的工作。但是在一些情况下，赞助商更加松懈，他们开始在软件施工的过程中同意或大或小的范围改动。
只要项目经理和赞助商积极的管理和授权这些改动，这就不会变成项目范围的蔓延。但是，在这些情况下，项目经理需要到达一个截止点，也就是说这个时候将不再接受任何额外的改动。这使得开发队伍能够集中精力于最后的测试和最终的软件实现。
Terry的项目就是一个好的可以做出这种截止点的项目。她将项目的范围管理得很好，但她和她的赞助商也引入了风险。当人们在过分的追求完美的解决方案的时候，使开发团队变得粗心和精力分散的风险就越大，这就意味着降低的软件质量和将来可能出现的更多问题。
在这一点上，一个更好的方法是和赞助商一起停止所有的改动。对新的改动的建议仍然可以被考虑，但是它们会被放在一个按优先级排列的后备列表上。
这个列表会在程序开始运行并稳定以后再进行考虑。这些改动现在就可以看成是应用程序的加强了。支持团队可以完成它们，或者它们就被放到一个新的第二阶段的项目中去。
