每個項目經理都希望能有效地控制項目進度。但這件看似簡單的事情，實際操作起來卻常常不盡如人意。即使在成熟的大公司裏，有着完善的項目管理流程，配備着一流的團隊，項目延期事件還是頻頻發生。這裏分析主要的三個原因。
常見的原因之計劃不清
很多項目經理，計劃做得很漂亮，卻總是計劃趕不上變化。原因 在於，有些時候，按工作量預估的發佈日期卻得不到領導的同意，領導有時會說我們現在就是和時間賽跑，這個項目必須在某某時間發佈。這將致使計劃推倒重來，一切都要趕進度。而對於其他團隊成員來說，這份計劃沒有同他們商量，無異於強壓任務。項目還沒開始，抱怨聲就不絕於耳。因此，項目工具選得好、任務劃分細 致清楚只是做好計劃的基礎，更重要的是項目計劃要得領導和團隊成員的認同，並願意爲之全力以赴。
總之，想做好項目計劃，要做好以下三點。
- 項目計劃前，先和產品經理、上級領導溝通好，確定這個項目的輕重緩急。
- 團隊成員要達成一致意見，項目經理不可獨斷專行。
- 項目計劃要細化到天、功能點要責任到人、確定里程碑點。
常見的原因之需求問題
需求中的功能點要在PRD（產品需求文檔）中羅列清楚，業務流程要寫得完整清晰，交互細節要體現在視覺稿中。要組織項目組所有成員參加PRD評審，評審時要 針對具體的問題，給出明確的處理意見。暫時不能確認的問題，問題跟進人要在限定時間內給出反饋，項目經理可以制定問題跟進表格。
項目進行中 的需求變更，儘量在前期提出。在項目管理的過程中，當前期的需求和計劃都確定後，項目經理不能只顧着跟進開發和測試的進度，也要階段性地和需求方多溝通， 讓他們及時反饋意見。不要等到臨發佈時，產品經理跑過來說“我要的不是這樣的，這裏要改一下”。永遠不要把問題留到最後一分鐘，要超前一步，留有餘地。下 面是一個真實的案例。
案例情景：該項目的整個週期爲2個月，有3輪功能測試。當第3輪功能測試結束時，也就是即將進入預發佈階段時，產品經理纔給出用戶反饋並要求按用戶的反饋修改。改動的地方涉及到頁面的樣式、文案、SQL語句和校驗邏輯等，總共可能有20多個文件要被改動。
項目經理建議只改頁面的樣式和文案，其他部分先不要改，等下次升級維護時再改，否則可能會影響發佈。而在多次交涉無果的情況下，開發人員只能硬着頭皮修改，測試人員只能再重新測一輪。雖然大家努力地按需求方的要求做了，但項目延期已不可避免了。
常見的原因之溝通不暢
爲某項目臨時組建的團隊往往來自不同部門，團隊成員之間不熟悉，此時，要爲團隊建立一個溝通通道，確保溝通順暢。常用方式爲：
- 建立一個內部網絡空間，所有文檔資源統一存放，供團隊成員共享；
- 利用即時聊天工具，建立一個項目羣，每天通報項目進度；
- 建立項目郵件組，所有變更達成一致後，發送郵件確認；
- 每天要開15分鐘晨會，每週一次週會，每週發送項目週報；
- 跨團隊項目，最好申請獨立的項目室，所有項目組成員坐在一起工作，降低溝通成本。
評論：
1）對於項目時間強壓，這個有時候的確是甲方要求，有時候是領導強壓。項目團隊不是不可以加班，但是加班的輔助補貼等要及時兌現。團隊可以奉獻一次，二次，但這樣下去失去的是人心。
2）產品經理在產品要發佈前才提出修改，這完全是產品經理能力問題。
3）建立一個內部網絡空間，所有文檔資源統一存放，供團隊成員共享；這個問題充分說明了作者的團隊沒有配置管理工具！！！
4）團隊技術成熟度低+項目時間緊，這種情況下，技術帶頭大哥就非常重要，技術帶頭大哥的主要工作就不是編程了，而是解決重要的技術問題，然後花大量時間去檢查技術團隊的程序，文檔質量。