1） 專案週期估算
專案週期估算的時候必須考慮幾個因素：專案成員的技術水平、職業的素養、被激勵的程度。如果沒有把握的話，應該盡量悲觀的估計，方法是先估計正常的週期，然後乘乙個係數。
2）盡早qc（質量檢查）
很多時候，團隊成員的技能水平往往達不到要求的目標，那麼，如果等到方案階段快要結束的時候再次檢查方案的質量就太遲了，要麼得到低劣粗糙基本不能用的概要設計，要不然準備宣布方案階段延期。所以，在方案設計取得階段性成果的時候就應該啟動qc，並且不斷qc，每乙個關鍵的交付都應該qc（通常需求分析報告、需求規格說明書、概要設計、**、測試案例、切換方案都需要qc）。
3）輸出
開發階段的輸出不僅僅是**，還有可能有效能優化報告（針對效能需求）、配置說明（配置模組），這些應該明確的安排到wbs（工作分解結構）中進行跟蹤。
4）模糊任務的跟蹤
在接近階段切換的時候，有很多模糊的任務需要用checklist跟蹤，比如切換到sit（系統整合測試）階段時，就需要跟蹤設計評審意見的落實、**評審意見的落實情況，並且這個跟蹤應該盡早，並提醒成員盡早反饋。
5）明確的任務
不要給專案成員分配模糊的任務，任何任務都要有明確的輸出，同樣的道理，文件編寫任務應該指定明確的模板。
6）不可控時間的預留
有很多進度不能由pm把握，比如提交官方的tr（評審），就應該預留充足的時間，以免對專案總體進度產生惡劣影響。
7）測試
系統的測試計畫是必須的，測試一樣要用矩陣來進行跟蹤，每個功能點、每個意外情況都要跟蹤起來。盲目的測試往往也可以發現問題，但更可能的遺漏掉更加重要的問題。
8）工作日誌
不管專案成員做了什麼，都應該要求他們用工作日誌記錄下來。這樣可以防止偷懶 :)
專案管理經驗分享
我的專案經驗分為專案啟動前，專案開發中，專案維護中三個階段總結。一 專案啟動前 1 需求分析 根據需求給定的需求說明書，去仔細分析理解每乙個需求任務，評估功能需求的可做性 技術可行性，評估功能的實現和耗費的資源 人力和時間 的可支援性。例如 在tulipb b02 專案開發過程中，在使用者遠端許可權...
專案管理經驗借鑑
要馬兒好，又要馬兒不吃草 這句話不知是誰 發明 的 發明這句話的人，想來是專案管理的高手。為什麼？因為專案管理的精義，就是 又要馬兒好，又要馬兒不吃草。乙個成功的專案，通常有三個要素 這三個彼此互斥的要素，就像乙個等邊三角形的三邊一樣，缺了一邊，或任何一邊比其它兩面邊短，我們就不能再稱這個三角形為等...
專案管理經驗學習
軟體專案評估表 專案名稱 評估日期 評估者 評估輪次 評估結果 功能點 費用 工作量 理由技術引導方法選擇 工具 技術 目的 簡介 會議管理 使會議更順暢，在計畫的時間內完成會議議程。內容包括安全注意事項的,會議目的，會議議程，對參會人員的行為要求，參會人員對會議的期望以及角色的定位與分工。介紹 分...