指導委員會應該在整個項目生命周期的早期開始關心項目的質量問題。我們不能僅僅根據已經完成的項目來衡量項目的進展，這樣當我們發現質量差的時候已經太晚了，這是我們低估了檢測需要付出的努力。在可迭代化方法中，我們很早有次品率的指標，也很早要求投入精力來進行檢測，但是管理委員會可能不知道需要在整個項目的早期開始費心問一些有關質量的問題。因此，初級的RUP項目管理者可能不能遵從RUP的指導方針，在一開始的時候不能全面地檢測。但是不幸的是，很多這樣的管理者聲稱他們在用RUP管理項目，但是他們其實還是在采用瀑布式技術。通常來說，他們會將他們的任務計劃按照RUP方法組織階段分類，尤其是在測試領域。指導委員會必須檢查確認項目管理者在項目開展的早期有測試者，并且給測試者分配好任務檢查使用情景下的任務執行情況。
總之，委員會應該對項目組做出以下的要求：
使用演示版本展示項目進度：
你完成了多少用例場景?
在這次迭代過程中你完成了什么功能?
在下一次迭代過程中你將創建什么功能?
說明你已經完成的系統的質量：
缺陷數是多少，并且這些缺陷的嚴重級別是什么？
缺陷趨勢是怎樣的？（發現率和解決率）
消除不必要的關閉
將RUP引入傳統的瀑布式環境一個富有挑戰性的方面是：它對于結束的依賴性大大降低。人們只有在確保文檔是完整和準確的情況下才會結束文檔。因此，他們總是傾向于坐等而耽誤了決策，這會推遲決策，從而減慢項目的進程，浪費經費。作為新的選擇，RUP承認我們從過去的經驗中得到的知識：在任何情況下文檔都不可能完整和精確。因此RUP指導方針鼓勵我們接受這樣的現實：所有事情都會改變，都會往前走。.
軟件開發界流行的名言是：你付出的努力的20%用以完成你80%的工作。因此這意味著你需要付出你80%的努力來完成剩下的20%的工作。很符合邏輯推論的結論是：在項目的迭代過程中，好先做完那80%的工作，然后再完成那剩下的20%。敏捷的迭代開發都和追求“足夠好”有關，你會在你的工作中繼續改進你的產品。相關利益方和項目開發組連續的日常協作保證項目的進展而言，是一個比間歇生產和關閉正式文檔方法好得多的方法。
然而，對于重要的項目工件，我還是會要求正式關閉的文檔，比如在先啟階段結束時的遠景文檔和軟件開發計劃，還有在精化階段結束時。通常，當項目組對整個需求有更進一步理解的時候，在精化階段的結束會產生重大的變更。盡管我傾向于調整范圍維持預算和計劃，但是有時重新規劃剩下的迭代開發階段是很有意義的，尤其是在你不能夠降低功能范圍，或者在項目還存在著交付功能的不確定性而引入另一個精化階段的迭代的情況下。
不斷調整計劃和期望
我經常說管理一個瀑布式的或者傳統的項目，在項目的前80%非常直接而有趣，在那段時間內，任務是線性的，在一段時間內你可以集中注意于一項規則（比如需求）. 然而當集成和測試開始的時候，你會經常發現不是模版不能整合，測試很費勁，系統架構有缺陷，執行效果很差，是用戶提出這個應用不是他們所需要的。如果你在管理一個瀑布型的項目，你在項目臨近結束的時候，需要找一個借口將這個項目轉交給另一個可憐人。
管理一個RUP項目在開始的階段會更有些挑戰性，因為我們同時考慮各種條件約束，包括需求、編程以及測試。然而在接下來的階段，非正式溝通和良好的生命周期管理工具支持會使得項目的復雜性容易管理得多。
對一個RUP項目管理者來說困難的階段是精化過程的末期。這時候他們會發現范圍、預算以及時間計劃沒有意義。這時候他們不得不做出很艱難的決定，可能還需要重新規劃整個項目的一部分。但是這也有好的一方面，這發生在項目的先啟階段，這時候能讓相關利益方調整他們的期望。
在整個項目的后，盡管我們可能不能達到相關利益方開始的 預期， 我們應該可以達到我們在精化階段后達成的協議所規定的要求。讓相關利益方學會期望團隊實現在精化的后階段所擬訂的要求，而不是他們開始所期望的要求，這是成為一個成功RUP項目管理人的關鍵所在。
我希望我已經向大家說明，在建立部門應用軟件的時候，采用不斷增強的版本策略可以在IT投資上有非常顯著的好處。RUP為這種方法提供了很好的指導。我希望您的組織可以考慮這種方法。 如果你已經決定創造一個迭代化軟件開發環境，那教育相關利益方非常重要，你必須讓他們懂得RUP項目的合作特性。你的指導委員會管理你開發應用的方法對你的成功有效地使用預算，避免傳統瀑布式方法的不佳行為有著非常重要的意義。
祝你好運！
