不好的消息就是有時我們仍然需要繃緊變更控制的嚴格性。不要不切實際的期望 IT 項目交付團隊在需求范圍不斷變更的情況下還能夠遵守進度和預算。
我指導團隊將一個項目中的精化階段看作“sandbox”時間。IT 團隊利用這段時間指出什么是可行的，以及如何去做。同樣地，用戶也可以利用這段時間精確地指出他們所希望的是什么。
一旦精化“sandbox” 階段結束之后，我們就將進入項目的產品化階段。此時，項目經理需要繃緊變更控制或者無法按要求交付的風險。圖 1 描繪了這一增長處理過程控制的概念。請注意：“變更控制的嚴格性”曲線并不一定如這張圖表中所描繪的那樣在構建階段中如此快速地增長。這取決于您的機構核項目的獨特方面。對于同用戶的契約關系來說，在構建中較早地制定嚴格的變更控制程序也許是必須的。對于同用戶的協作和信任關系來說，您可能將繃緊處理過程控制推遲到構建的后期，并且“變更控制的嚴格性”曲線也將會向右移動。
圖 1: 隨著項目的進展，變更控制的嚴格性也在不斷地加強。
教育我們的出資方是一個關鍵問題
不幸的是，許多“敏捷的 RUP”項目經理并不改變他們的行為，或者設置適當的期望，他們在整個開發周期中總是從一個迭代移動到另一個迭代。
用戶通常沒有接受過理解跨越 UP 階段的變更重點的訓練，Gary Evans 喜歡將它稱之為項目的季節。他們明白在項目的早期他們擁有相當大程度的變更自由度，并且自然地假設這種自由度能夠貫穿于項目的始終。我曾經向出資方展示過迭代后的演示模型，意在展示處理過程在向前移動到執行新的需求之前，首先會召開需求引出會議！項目經理有時會將比當前迭代中執行的需求更多的需求添加到未完成的工作單中！這確實是一種十分挫敗的體驗。
看起來許多接受過不是基于 UP 的敏捷性訓練的項目經理并不能夠充分地認識到對于增長的變更控制嚴格性的需要。他們以同樣的方式管理每一次迭代，并且不能夠設定完全符合用戶的期望。