專案週會過程
問題1：你的工作是否和原計畫有偏差？
問題2：具體會有哪些偏差？
問題3：偏差的資料記錄在**，儲存在**？
問題4：資料的**是什麼？
問題5：誰來檢查這些資料？誰來記錄這些資料？
問題6：記錄的資料跟誰匯報？
序號
原計畫
現實情況
執**況
最終結果
現在要求出具的證據
1按照乙個專案正常的流程開始做，做需求 做剪裁、做估算、做計畫
2對照wbs的工作分解，禪道每週錄入工作任務
沒做錄入的任務時間不正確
不能發現工作任務之間的邏輯關係
3專案經理根據錄入的工作任務關閉禪道的任務
沒做專案經理通報工作任務
錄入禪道的任務是否和wbs有偏差，不清楚
檢查每個文件的出具時間、文件中任務花費的工時
（評審、培訓、qa檢查、cm管理）
4專案經理完成任務工作檢查後，得到專案的偏差資料，然後填表
沒做工時統計不正確、工作分散無法聚集到一起，cmmi2級都達不到
工時偏差的證據是不是禪道裡面記錄有
5qa匯報過程檢查和產品檢查、各種評審的問題、工作量，度量與分析的結果。
沒做現場進行qa審計，耗散大量的人員會議時間
工時統計不正確，偏差統計不出來
6cm匯報配置項狀態和基線發布、變更情況、工作了，度量與分析的結果。
沒做配置項狀態報告沒有記錄wbs
調整後的文件變化情況
文件提交的時間、版本、作者、審批、qa檢查、評審
7需求工程師匯報需求調研的過程，
使用者需求和需求規格說明書的跟蹤情況、工作量、度量分析結果。
沒做工時和提交的文件時間不匹配。需求跟蹤沒有任何依據。
是否專案組評審、qa審計和王煒做的技術檢查
8設計工程師匯報軟體設計花費的工時，
提交的文件和時間，是否通過評審
沒做工時偏差統計不出來
是否專案組評審、qa審計和王煒做的技術檢查
9開發工程師匯報編碼花費的工時，
產品版本的整合情況，匯報需求跟蹤情況
沒做開發人員不清楚整合過程，
無法回答問題，並且這個問題沒有能夠及時被專案組發現
是否專案組評審、qa審計和王煒做的技術檢查
10測試工程師匯報測試的工時，
產品的缺陷情況，匯報需求跟蹤情況
沒做是否專案組評審、qa審計和王煒做的技術檢查
會議分為：專案周例會、專案里程碑會
會議準備
1.會議前pm、cm、de、te、qa各自去準備開會需要的報告，報告的內容見《cmmi3專案文件一覽表》。
比如：qa的工作，根據wbs計畫安排，qa做過程審計、產品審計，出相關檢查表和檢查報告。禪道系統中錄入自己本週的工作任務，計畫工時和實際工時。
注意：里程碑會議和週會每個人要準備的報告是不一樣的。
2.周會議期間內的工作任務已經錄入完成，並標識任務的狀態是否完成。
3.wbs已經設定了基線，並且有cm儲存了基線的版本。
週會召開
1.會議上各個成員去匯報自己本週的工作成果，出具文件或者**成果（檢查文件的撰寫時間、撰寫文件花費的工時、撰寫人這些都對不對）。
2.專案經理決定是否工作任務完成，並關閉工作任務。在wbs上更新任務完成的時間、花費的工作量、實際完成工作的人員（要更新wbs達到統計工作量、成本、進度偏差的目的）。
3.qa協助專案經理在會議上，填寫每週的《專案資料跟蹤表》的工作量統計、進度偏差、會議記錄。
4.專案組成員協助專案經理填寫《專案風險管理報告》、《專案問題跟蹤表》。
5.cm核對本週配置項的提交情況、是否評審、是否qa已經進行了檢查，儲存本週的《配置項狀態報告》。
6.本週會議結束後，本週的度量分析結果提交到svn儲存。
7.隨機從問答系統中，抽取幾個問題詢問各個角色，回答不出來，現場無法給出答案的問題，將問題記錄下來。
8.本週的工作成果已經檢查無誤，且已經達到基線發布的條件，然後由cm完成基線發布申請表、基線發布報告。
9.一周的工作會議結束後，再進入第二週的會議。
里程碑會議召開
1.里程碑會議是將各個階段的資料進行彙總，因此要準備各項需要準備的報告、錄入禪道的資訊要完整並且經過了專案週會的檢查。
2.里程碑會議期間，專案經理要安排人員填寫各類度量與分析的**，qa確定要填寫的度量與分析**，並進行模板的分發。
3.為減少大家的工作量，本週召開了里程碑會議，就可以不再做本週的專案週會，在wbs上面將週會標註為***里程碑會議即可。
4.里程碑會議發現的問題、風險同樣需要記錄到《專案風險管理報告》、《專案問題跟蹤表》。
5.上個里程碑如果進度、成本、資源、問題較多，需要回顧上個里程碑的資料，以及發現的問題、風險是否解決。
6.里程碑會議結束後，qa檢查資料度量與分析表是否填寫完成，需求跟蹤是不是也做完了，然後提交到配置庫儲存。
7.cm發布基線。
會議例外情況處理
1.會議過程中，發現wbs中的時間或者任務有問題。
解決方案：
b.基線已經發布，將累計錯誤修訂後的版本儲存好，然後申請wbs的變更。
wbs的變更不引起計畫基線變更時，可直接變更wbs，不變化基線版本。
wbs的變更引起計畫基線變更，cm計畫、qa計畫、ma計畫、總體計畫修改完成後，cm重新發布計畫基線。
c.實際的工作任務多出wbs時，儲存過基線的wbs可以直接增加任務，並記錄任務的資訊。
d.進度、成本的偏差大於或者小於某個值，專案要進行風險的管理，嚴重超標，可能是計畫做的不對，要修改wbs和專案計畫，重新發基線出來。
e.實際任務完成情況和原計畫有偏差，屬於正常情況，只要度量分析的結果不超過規定的值，原計畫可以保留繼續使用。超過規定值後，由專案經理決定是否沿用原計畫，還是做計畫的變更。
2.與會人員沒有做會議準備，比如禪道的任務沒有錄入完，某個報告沒有做等。
a.準備的內容是否差的太多，取消會議，另外安排時間。要記錄是誰未完成什麼工作導致會議不能進行。
b.準備的內容可以現場完成，會議繼續。
專案里程碑達成的標準
里程碑是重要的檢查點，是專案中關鍵的事件及關鍵的目標時間，是專案成功的重要因素。里程碑是確保完成專案需求的活動序列中不可或缺的一部分。比如在開發專案中可以將需求的最終確認，產品移交等關鍵人物等作為專案的里程碑。基線 baseline 基線重要的需要確認的里程碑，軟體生存期各開發階段末尾的特定點，在這...
做好里程碑就是專案成功了一半
眼睛盯住細節的，是工程師 眼睛盯住結果的，是老闆 眼睛盯住過程的，是專案經理 並不是說結果不重要，但結果是靠過程來保證的。對於專案控制來講，里程碑就是最有效的過程控制手段。專案管理要經歷很多過程，涉及到很多內容包括 專案干係人梳理，工作分工安排，各部門高效協作溝通等，很多專案時間跨度特別大，整體涉及...
專案里程碑評審的關注點
1 專案工期情況 關鍵路徑是否按計畫完成了？如果沒有按計畫完成 提前或拖期的原因是什麼？在後續階段如何採取改進措施？對後續階段的工期有什麼影響？2 任務進展情況 計畫完成的任務情況 計畫完成的任務有哪些？提前完成的有哪些？提前完成的任務工作量有多少？未完成的任務有哪些？未完成的任務工作量有多少？3 ...