在所有成員領悟到提交合格產品所需要的關鍵過程元素之前，項目往往陷入某個特定主題的細節的沼澤中。然后，當項目拖后時，大家就會怪罪以前被過分強調的某些活動，或者是怪罪大家不理解其用處的某些活動，“嘿，我早就告訴你需求管理（或者是用例、收集項目度量數據、使用 配置管理、使用缺陷跟蹤工具、召開項目狀態 會議里面的一個或幾個）會放慢我們的進度！你不信！”
有一個“精華或要素”列表讓 團隊成員采用一種更系統、更全面的方式來思考和執行整個軟件開發過程。一旦一個過程框架或“構架”到位了，團隊成員就能更有效的面對和處理單個的問題域（大部分時間我得承認，需求管理應該在列表的頂部）。同樣，一開始就標識顯然的問題以及相關的 風險，并且確定處理他們的優先級，也是很重要的，這樣，團隊才能在早期就根據需要采取相應的解決或緩解對策。