多年來，我一直在教育和指導項目組，如何成功地使用包含在IBM® Rational Unified Process®（或者RUP）中的迭代化方法。我發現懂得迭代化方法并且將之運用于實踐的團隊在運用RUP的時候，會比使用傳統的瀑布式方法的團隊更有效率，更能集中精力。
不過，在這樣的團隊組織中，負責對軟件開發項目做出重大的資金和管理決策的籌劃指導委員會，通常對迭代化開發實踐不太熟悉。他們不能提出正確的問題來估計項目進度，并且他們也不能提供適當的管理指導。
這篇文章概括了一些管理者和指導委員會在指導迭代化軟件開發中，必須采用的一些方法。采用這些方法，他們能夠使比較缺乏的IT資金優化，并且能夠集中精力開發出能夠提供大商業利潤的軟件特性。
持續為小項目提供資金來適應不斷變化的需求
在許多組織中，都有一個每年的固定安排，是為不同部門的應用軟件進行預算和安排不同的優先級，通常這些決策都是基于非常主觀的商業案例來確定的，包括不太可靠的成本估算和無形的利益。但讓人奇怪的是，這些組織常常會批準大的項目， 即使歷史證明，這些大的項目失敗的可能性是大的。這說明一些部門多年來沒有足夠資金來建立一個應用軟件，用以記錄他們訂單的商業需求變化。當那個部門該年的資金終到位的時候，通常他們不但請求滿足他們的需求的應用軟件特性，而且還想象出一些他們認為他們在未來的五年中可能能用到的特性，直到他們的下一輪資金到位。我們把這種現象稱為叫"軟件膨脹"： 在應用軟件上加上一些尚有疑問的商業價值。當組織將現有的軟件遷移到一項新技術時，這種趨勢也很常見。
比用來構建部門級應用軟件的 "每5 年的大項目"方法更好的是，使用一種版本策略，該策略和很多產品公司構建軟件的方法類似。這種方法需要不斷地通過新版本改進軟件，在一段時間內逐步增加新的功能。
商業行為會不斷改變，因此應用軟件需要相應地不斷演進。因此，一項每 年20萬美元的預算比每5 年100萬美元的預算好。 版本策略有以下的一些優勢：
范圍協商變得更容易。
因為相關利益方知道將來總會有新的版本，他們會更愿意將一些目前不是特別重要和必要的對軟件特性的要求推遲到下一個版本。
軟件膨脹更容易得到避免。
相關利益方傾向于只支持那些可以帶來大商業利潤的特性。
需求抽取是連續的。
你能夠在相關利益方提出要求的時候滿足他們。你不必讓用戶再次重新解釋他們的業務——可能是對著一個不同的人——每個一到四年。
可以適當保持資源。
由于正在進行的項目比較小，你可以保持資源的完整無缺，成為一個更有效的團隊，研究表明，小的團隊比大的團隊更有效率。
你可以在很長一段時間內調整過程改進。
在新項目的先啟階段，生產力通常比較低，直到團隊終建立了規律的節奏。
在一個正在執行的項目中，你可以基于迭代評估不斷改進該項目的各個方面。
你可以大化工藝投資。
由于你開發了度量標準和其他一些項目數據，比如構架藍圖、模式和機制，你可以不斷地從整個生命周期管理工具中獲得實際利益。
我鼓勵各個組織改變他們的每年預算方法。我建議用以下方法來取代根據不可靠的商業項目來制定各部門IT預算的方法：
給大多數部門分配固定的資金。
每年根據前一年該部門所得的利潤來調整資金的多少。
這種方法鼓勵每個項目都有效地使用資金，這樣他們不會危害下一年的獲得的資金水平。因為每年相關利益方必須證明他們所做的是正確的，他們不會憑空想象他們接下來會做什么。
通過觀察所獲得的真實的商業利益，你會很快發現部門會從附加的自動控制中獲利多，同時將他們獲得的資金提高到適當水平。要求連續的、可說明的IT投資可以讓你優化預算撥款。當然，至少保留你IT預算的一部份也是很謹慎的行為，這可用以保持更大的主動性來適應大的商業項目或者變化。
制定嚴格的時間安排，但是保持靈活的特性
我經常告訴人們我的項目總能準時和不超支。但是我通常不會解釋其實這些項目的一些功能經常會和相關利益方原來希望的不同。這讓我們知道，在我們行業中準確地制定一個重大項目功能范圍，價格或者時間是非常困難的。我們的項目功能的范圍總是會由于需求，資金，技術這些不確定因素而變化。改變項目的資源，技術或者截止日期會比調整該項目的功能范圍影響更大。
在一個RUP項目里，生命周期由四個不同的階段組成：先啟，精化，構建和產品化。 雖然我們很早開始開發軟件并且持續不斷地在整個項目中都在開發軟件，但是，我們的重點在這些階段會有所改變。在開始過程中，我們關心的是，用所需要的小工作量來確定我們的高層功能范圍，決定該項目進一步執行是否有意義（做或不做的決定）。
