在項目過程中，通過監(jiān)視成本差異和進(jìn)度差異以及成本效率指數(shù)、進(jìn)度效率指數(shù)的變動，預(yù)測超過成本和進(jìn)度滯后的情況后采取對策。在分析計劃與實績差異的原因及對策時，可以使用圖表化、頭腦風(fēng)暴法+KJ法。如果計劃與實績差異過大，應(yīng)該考慮縮小項目范圍等對策。

頭腦風(fēng)暴＋KJ法

頭腦風(fēng)暴(brain storming)和KJ法都是發(fā)現(xiàn)問題和解決問題行動中實施創(chuàng)造性開發(fā)的方式。

頭腦風(fēng)暴法又叫作集思廣益法，它通過創(chuàng)造一個無批評的自由的會議環(huán)境，使與會者暢所欲言、充分交流、互相啟迪，產(chǎn)生大量創(chuàng)造性的意見，其目的是利用組合腦力刺激創(chuàng)造性，想出更多更好的主意。其作用在于：打破思維定勢，鼓勵開放性的思考；發(fā)揮集體智慧，在他人的看法上建立自己的意見；打破溝通障礙，形成團(tuán)隊精神；防止少數(shù)人控制會議。其實施步驟如下：(1)將頭腦風(fēng)暴的中心議題寫在白板、膠片或掛圖上，確保每個人都充分理解中心議題的含義。(2)項目組成員輪流發(fā)言，任何意見都會得到肯定。輪流的過程鼓勵大家參與，但任何人如果沒想好則發(fā)言可以隨時跳過。(3)將每一條意見用大號字寫在膠片或掛圖上。用原話記錄每條意見，不作任何解釋。(4)繼續(xù)輪流發(fā)言，直到每個人都沒有意見為止。(5)復(fù)查意見記錄，去除完全重復(fù)的條目。小心識別并保留在用詞上有極細(xì)微差別的意見。頭腦風(fēng)暴法對于認(rèn)識現(xiàn)狀、整理問題、討論問題過程中挖掘參與人員的意見非常有效。在PMBOK所謂范圍、成本、質(zhì)量、溝通、風(fēng)險等知識領(lǐng)域的管理中比較有效。

在問題并不明朗的情況下通過KJ法可以使問題逐漸清晰起來。所以，在軟件開發(fā)過程中，多用于需求分析、業(yè)務(wù)分析等。在項目計劃階段，對于PMBOK所謂風(fēng)險管理知識領(lǐng)域中的風(fēng)險識別、對策立案等方面比較有效。但是，如果理解KJ法的成員比較少，其使用會比較困難。特地集中起來的創(chuàng)意和意見如果僅僅簡單加以分類，難以引出問題點和創(chuàng)意點。

檢查清單/模板

在項目執(zhí)行期間，可以由項目管理團(tuán)隊作成檢查清單或者模板(checklist/template)，也可以由項目管理室那樣的支持項目管理的組織在項目審查和監(jiān)督的成功案例和失敗案例的基礎(chǔ)上作成。檢查清單或者模板是組織的佳實踐，通過這些經(jīng)驗的積累可以提高項目管理的效率，有助于防止失敗。檢查清單用于確認(rèn)作業(yè)或工程是否存在遺漏。模板作為產(chǎn)出物的雛形式樣，具有WBS、網(wǎng)絡(luò)圖、需求變更書、進(jìn)展報告書、合同標(biāo)準(zhǔn)文件等形式。通過雛形的靈活運用，經(jīng)驗較淺的項目管理者可以明白必須做些什么，并能在其他項目中重復(fù)利用。

軟件開發(fā)項目管理檢查清單：天氣晴雨表

檢查清單用于確認(rèn)作業(yè)或工程是否存在遺漏，是反映項目管理是否存在問題的“天氣晴雨表”。下面是軟件開發(fā)項目管理的一個檢查清單，比本章中所言“軟件開發(fā)項目管理過程中的禍根及其后果”更加詳細(xì)。通過這個清單，可以發(fā)現(xiàn)項目管理存在的問題，并采取措施加以改善。

需求式樣晴雨表

    是否存在穩(wěn)定的、完整的、書面的需求式樣？
    是否已經(jīng)需求事項煞費苦心地與顧客進(jìn)行了溝通和確認(rèn)？
    是否存在需求式樣尚未確定以“暫定式樣”開始作業(yè)而事后返工的情況？
    是否為了確認(rèn)顧客的需求而對“需求式樣書”進(jìn)行了審查？
    是否根據(jù)顧客提供的產(chǎn)品式樣書而直接進(jìn)入了設(shè)計作業(yè)？
    是否在作業(yè)途中不斷變更或追加需求式樣？
    是否按照項目編號規(guī)則對每項需求賦予了惟一的編號？
    是否已經(jīng)明確顧客方的項目推進(jìn)體制以及終決策者？
    是否攝于顧客的特權(quán)優(yōu)位性而不經(jīng)討論地接受顧客的需求變更？
    是否在遠(yuǎn)遠(yuǎn)超越自身能力而根本無法完成的情況下不能清楚地說“不”？
    是否在作業(yè)已經(jīng)進(jìn)入測試階段后還發(fā)現(xiàn)需求式樣理解有誤？
    是否以單一窗口接收顧客的需求，確保一窗口輸入？
    項目組成員的作業(yè)是否基于新需求信息，而不是已經(jīng)失效的歷史信息？

項目計劃晴雨表

    是否將估算視為一種特殊的技能，并將估算當(dāng)作一個小項目？
    是否定期對項目計劃實施重新估算并根據(jù)實際情況加以調(diào)整？
    是否對作業(yè)文檔等成果物的“量”進(jìn)行了估計？
    是否以適當(dāng)?shù)膯挝贿M(jìn)行了作業(yè)量的估計？
    項目作業(yè)是否具有詳細(xì)的日程表？
    日程表確定之后，如果和實際情況出入較大，是否進(jìn)行了調(diào)整？
    是否接受了不切實際的開發(fā)日程，而其結(jié)果是，日程表僅僅成為一種形式？
    “工作量”和“難易度”是否會因為擔(dān)當(dāng)者的不同而出現(xiàn)巨大變動？
    是否因為實際進(jìn)展超前于計劃而沒有思考項目計劃本身存在的精度問題？

團(tuán)隊管理晴雨表

    是否存在明確的軟件開發(fā)行動單位：團(tuán)隊？
    是否雖然叫作團(tuán)隊，但是并沒有認(rèn)識到協(xié)作而是專注于工作任務(wù)的分擔(dān)？
    管理者是否仍然承擔(dān)以前作為技術(shù)者所承擔(dān)的具體開發(fā)作業(yè)任務(wù)？
    項目管理者是否僅僅根據(jù)自己的經(jīng)驗而將需求式樣直接分派給“個人”？
    項目管理者是否總是認(rèn)為項目沒有什么值得注意的問題？
    團(tuán)隊成員是否知道項目作業(yè)內(nèi)容的相互關(guān)系及其優(yōu)先級？
    是否在項目啟動之后仍然還有項目組成員感到無所事事？
    是否經(jīng)常有特定的項目組成員總是加班到深夜？
    團(tuán)隊成員是否知道并遵守統(tǒng)一的作業(yè)規(guī)范？
    是否從作業(yè)流程上、從團(tuán)隊協(xié)作上追究過程序缺陷的真正原因？
    團(tuán)隊成員是否在相互察看成果物后產(chǎn)生提高自己的作業(yè)水平的意識？
    當(dāng)問題難點解決之后，是否向項目組成員介紹解決該問題的思維和方法？
    項目組成員的出勤時間是否經(jīng)常相差很大而不尋找原因？
    項目組成員在遇到技術(shù)難題時是否與項目組其他成員溝通并尋求支援？
    項目組成員在討論問題時是否出現(xiàn)無條理的、非建設(shè)性的討論？