不好的消息就是有时我们仍然需要绷紧变更控制的严格性。不要不切实际的期望 IT 项目交付团队在需求范围不断变更的情况下还能够遵守进度和预算。
我指导团队将一个项目中的精化阶段看作“sandbox”时间。IT 团队利用这段时间指出什么是可行的，以及如何去做。同样地，用户也可以利用这段时间精确地指出他们所希望的是什么。
一旦精化“sandbox” 阶段结束之后，我们就将进入项目的产品化阶段。此时，项目经理需要绷紧变更控制或者无法按要求交付的风险。图 1 描绘了这一增长处理过程控制的概念。请注意：“变更控制的严格性”曲线并不一定如这张图表中所描绘的那样在构建阶段中如此快速地增长。这取决于您的机构核项目的独特方面。对于同用户的契约关系来说，在构建中较早地制定严格的变更控制程序也许是必须的。对于同用户的协作和信任关系来说，您可能将绷紧处理过程控制推迟到构建的后期，并且“变更控制的严格性”曲线也将会向右移动。
图 1: 随着项目的进展，变更控制的严格性也在不断地加强。
教育我们的出资方是一个关键问题
不幸的是，许多“敏捷的 RUP”项目经理并不改变他们的行为，或者设置适当的期望，他们在整个开发周期中总是从一个迭代移动到另一个迭代。
用户通常没有接受过理解跨越 UP 阶段的变更重点的训练，Gary Evans 喜欢将它称之为项目的季节。他们明白在项目的早期他们拥有相当大程度的变更自由度，并且自然地假设这种自由度能够贯穿于项目的始终。我曾经向出资方展示过迭代后的演示模型，意在展示处理过程在向前移动到执行新的需求之前，首先会召开需求引出会议！项目经理有时会将比当前迭代中执行的需求更多的需求添加到未完成的工作单中！这确实是一种十分挫败的体验。
看起来许多接受过不是基于 UP 的敏捷性训练的项目经理并不能够充分地认识到对于增长的变更控制严格性的需要。他们以同样的方式管理每一次迭代，并且不能够设定完全符合用户的期望。