在項目過程中，通過監視成本差異和進度差異以及成本效率指數、進度效率指數的變動，預測超過成本和進度滯后的情況后采取對策。在分析計劃與實績差異的原因及對策時，可以使用圖表化、頭腦風暴法+KJ法。如果計劃與實績差異過大，應該考慮縮小項目范圍等對策。
頭腦風暴＋KJ法
頭腦風暴(brain storming)和KJ法都是發現問題和解決問題行動中實施創造性開發的方式。
頭腦風暴法又叫作集思廣益法，它通過創造一個無批評的自由的會議環境，使與會者暢所欲言、充分交流、互相啟迪，產生大量創造性的意見，其目的是利用組合腦力刺激創造性，想出更多更好的主意。其作用在于：打破思維定勢，鼓勵開放性的思考；發揮集體智慧，在他人的看法上建立自己的意見；打破溝通障礙，形成團隊精神；防止少數人控制會議。其實施步驟如下：(1)將頭腦風暴的中心議題寫在白板、膠片或掛圖上，確保每個人都充分理解中心議題的含義。(2)項目組成員輪流發言，任何意見都會得到肯定。輪流的過程鼓勵大家參與，但任何人如果沒想好則發言可以隨時跳過。(3)將每一條意見用大號字寫在膠片或掛圖上。用原話記錄每條意見，不作任何解釋。(4)繼續輪流發言，直到每個人都沒有意見為止。(5)復查意見記錄，去除完全重復的條目。小心識別并保留在用詞上有極細微差別的意見。頭腦風暴法對于認識現狀、整理問題、討論問題過程中挖掘參與人員的意見非常有效。在PMBOK所謂范圍、成本、質量、溝通、風險等知識領域的管理中比較有效。
在問題并不明朗的情況下通過KJ法可以使問題逐漸清晰起來。所以，在軟件開發過程中，多用于需求分析、業務分析等。在項目計劃階段，對于PMBOK所謂風險管理知識領域中的風險識別、對策立案等方面比較有效。但是，如果理解KJ法的成員比較少，其使用會比較困難。特地集中起來的創意和意見如果僅僅簡單加以分類，難以引出問題點和創意點。
檢查清單/模板
在項目執行期間，可以由項目管理團隊作成檢查清單或者模板(checklist/template)，也可以由項目管理室那樣的支持項目管理的組織在項目審查和監督的成功案例和失敗案例的基礎上作成。檢查清單或者模板是組織的佳實踐，通過這些經驗的積累可以提高項目管理的效率，有助于防止失敗。檢查清單用于確認作業或工程是否存在遺漏。模板作為產出物的雛形式樣，具有WBS、網絡圖、需求變更書、進展報告書、合同標準文件等形式。通過雛形的靈活運用，經驗較淺的項目管理者可以明白必須做些什么，并能在其他項目中重復利用。
軟件開發項目管理檢查清單：天氣晴雨表
檢查清單用于確認作業或工程是否存在遺漏，是反映項目管理是否存在問題的“天氣晴雨表”。下面是軟件開發項目管理的一個檢查清單，比本章中所言“軟件開發項目管理過程中的禍根及其后果”更加詳細。通過這個清單，可以發現項目管理存在的問題，并采取措施加以改善。
需求式樣晴雨表
是否存在穩定的、完整的、書面的需求式樣？
是否已經需求事項煞費苦心地與顧客進行了溝通和確認？
是否存在需求式樣尚未確定以“暫定式樣”開始作業而事后返工的情況？
是否為了確認顧客的需求而對“需求式樣書”進行了審查？
是否根據顧客提供的產品式樣書而直接進入了設計作業？
是否在作業途中不斷變更或追加需求式樣？
是否按照項目編號規則對每項需求賦予了惟一的編號？
是否已經明確顧客方的項目推進體制以及終決策者？
是否攝于顧客的特權優位性而不經討論地接受顧客的需求變更？
是否在遠遠超越自身能力而根本無法完成的情況下不能清楚地說“不”？
是否在作業已經進入測試階段后還發現需求式樣理解有誤？
是否以單一窗口接收顧客的需求，確保一窗口輸入？
項目組成員的作業是否基于新需求信息，而不是已經失效的歷史信息？
項目計劃晴雨表
是否將估算視為一種特殊的技能，并將估算當作一個小項目？
是否定期對項目計劃實施重新估算并根據實際情況加以調整？
是否對作業文檔等成果物的“量”進行了估計？
是否以適當的單位進行了作業量的估計？
項目作業是否具有詳細的日程表？
日程表確定之后，如果和實際情況出入較大，是否進行了調整？
是否接受了不切實際的開發日程，而其結果是，日程表僅僅成為一種形式？
“工作量”和“難易度”是否會因為擔當者的不同而出現巨大變動？
是否因為實際進展超前于計劃而沒有思考項目計劃本身存在的精度問題？
團隊管理晴雨表
是否存在明確的軟件開發行動單位：團隊？
是否雖然叫作團隊，但是并沒有認識到協作而是專注于工作任務的分擔？
管理者是否仍然承擔以前作為技術者所承擔的具體開發作業任務？
項目管理者是否僅僅根據自己的經驗而將需求式樣直接分派給“個人”？
項目管理者是否總是認為項目沒有什么值得注意的問題？
團隊成員是否知道項目作業內容的相互關系及其優先級？
是否在項目啟動之后仍然還有項目組成員感到無所事事？
是否經常有特定的項目組成員總是加班到深夜？
團隊成員是否知道并遵守統一的作業規范？
是否從作業流程上、從團隊協作上追究過程序缺陷的真正原因？
團隊成員是否在相互察看成果物后產生提高自己的作業水平的意識？
當問題難點解決之后，是否向項目組成員介紹解決該問題的思維和方法？
項目組成員的出勤時間是否經常相差很大而不尋找原因？
項目組成員在遇到技術難題時是否與項目組其他成員溝通并尋求支援？
項目組成員在討論問題時是否出現無條理的、非建設性的討論？
