總結
圖1提供了項目管理者對改進時間和價值過渡的觀點，我們都應該努力實現這一理念。它為概括有效實現指導式領導（我在四項推薦中所暗示的）提供了一個很好的抽象視角。我通過畫出開發進度-時間圖展示了三個項目的外觀，其中進度是用可執行百分比定義的，也是用目標的可演示形式。在這個意義下的進展是與結果確實相關的，正如我前面描述過的，而且通過可執行演示是很好度量的�？蓤绦胁灰馕吨暾�、適應或是符合規格；但是它確實意味著軟件是可測試的。
當使用這種度量方法時，典型的傳統工程項目管理風格序列是（1）通過文字設計和詳細（經常過于詳細）工件實現的早期成功，（2）承諾在生存周期后期完成可執行代碼，（3）由不可預見的實現問題和接口二義性造成的集成噩夢，（4）使系統工作起來的巨大的預算和時間壓力，（5）末期不甚理想的產品，沒有時間進行重新設計，后（6）一個脆弱、不可維護的產品推遲發行。
我這里介紹的現代管理方法把集成加入到了設計階段，并經過一系列可演示的版本發布，于是也使得架構上重要的缺陷更早出現，能夠在生存周期目標的上下文中被解決。順流而下的集成噩夢被避免了，同時避免的還有以后的補丁和軟件修正。結果是一個更為健壯和可維護的產品的按期發行，于是產品在經濟上成功的可能性也更大了。
使用傳統方法管理的項目，陷于集成的無效性和實質設計問題的發現過晚，把總資源消耗的40%花在集成和測試活動上，而這些努力大多帶來的是過量的碎片和返工。采用迭代過程和指導式領導的現代項目發行一個產品，上述活動只消耗了預算的25%。
我討論了真正使用迭代開發精神管理的項目的四種成功模式。每個模式表現了一種平衡，它能夠幫助團隊掌控制做產品和獲得經濟效益的路徑：
用戶需要與設計資產間的平衡
創造性過程的自由性與生產過程的嚴格性間的平衡
產品進度與實驗性的識別背離的平衡
抽象觀點與通過測試進行的切實評估間的平衡
根據我的經驗，前例中的傳統項目外觀仍然是普遍的，是我們見到的一半以上項目的特征。盡管這些項目中的多數使用傳統的工程管理方法，有一些聲稱使用了現代迭代開發。但是，由于不采用指導式領導，它們沒能成功取得預期的商業結果。也許的項目有四分之一采用了現代模式，但只有八分之一能夠在目標外觀上進行操作。正是從這些不固定的外觀和成功的結果上我觀察出了本文所討論的風格的一致使用問題。
和建造一座橋比起來，軟件項目管理真的更像管理一部電影作品嗎？也許不是這樣，特別是在產品的后幾個階段。但是我希望這種類比能使讀者從不同的參考中來審視軟件項目管理技術。這些模式不是新的。它們在很多組織，以各種不同的程度，在廣泛領域內經過了實踐（盡管不太經常）。如果你深入研究在實踐中使用這些模式，你會發現它們都著眼于處理管理上的人與團隊工作的方面，很少帶有科學、工程或是制造業的偏見。我認為采用指導式管理的組織更容易取得經濟上的成功——甚至可能一鳴驚人。
