計劃的共識和保證。
4、對總體計劃、階段計劃的作用認識不足
項目經(jīng)理認為計劃不如變化快，項目中也有很多不確定的因素，做計劃是走過場，因此制定總體計劃時比較隨意，不少事情沒有仔細考慮，或者是有一種等一下再說的想法；階段計劃因工作忙等理由經(jīng)常拖延，造成計劃與控制管理脫節(jié)，無法進行有效的進度控制管理。那些號稱“所見即所得”的OA，邊做、邊提需求、邊改、邊完善的“四邊形”的所謂“快速”軟件開發(fā)也可能竟然是本企業(yè)周期延續(xù)最長的項目，因為無休無止的需求變更而永無止境。從項目的計劃階段來看，因為邊做、邊提需求、邊改、邊完善，所以他們首先就對計劃沒有信心，基本上計劃對他們來說只是應付，久而久之，對計劃方面的鍛煉意識不如其他項目，甚至養(yǎng)成不容易改掉的習慣。
5、任務和職責劃分不夠清晰或有遺漏
目標、任務的分解不夠清晰、工作有遺漏，沒有確定項目組成員職責的差別，如程序員的職責都籠統(tǒng)地寫成“編碼”。其主要原因是一些新任的項目經(jīng)理是由程序員提拔起來的，不太熟悉軟件工程各階段工作職責中某些具體工作的分配，無法按任務分清每個人的責任。如應該分清楚需求人員該做什么、設計人員該做什么、編碼人員該做什么、測試人員該做什么。責任似乎很容易分清，但大家卻經(jīng)常聽到“這是需求的事”、“這是設計的事”這樣的爭論，嚴重的造成項目組內(nèi)部的糾紛扯皮。就是因為這些新的項目經(jīng)理對一項具體工作，如界面設計、數(shù)據(jù)規(guī)格等應該由需求分析人員來做，還是設計人員來做分不清楚，還有就是做到什么程度算概要設計，什么程度算詳細設計，職責上也要搞清楚。建議新上任的項目經(jīng)理應該多學習軟件工程的相關知識。
6、項目任務分工或進度計劃表的顆粒度太大
常見的現(xiàn)象有對任務持續(xù)時間進行不切實際的估計；或未考慮到任務的相互依賴關系而造成遺漏工作。其主要原因是軟件工程的分析與設計經(jīng)驗的不足，無法細化系統(tǒng)需求，并從需求推導出設計，根據(jù)設計去分配任務。根據(jù)細化的需求也可以分配任務，但是由于需求中的功能點和設計中的模塊往往不是一一對應的，如一個需求功能點需要一系列的模塊來實現(xiàn)，多個需求功能點也可以共用同一組模塊加上不同的設置參數(shù)來實現(xiàn)。所以根據(jù)設計來確定程序代碼階段的任務分配比較合理。需求是整個項目的基礎、需求的清晰顆粒度對后面的工作及工作計劃的準確性至關重要。項目計劃的準確度是以一開始以需求（包括設計層需求）為基礎得出的工作結構分解的完整性、清晰性為基礎的。如果沒有這個基礎，項目計劃就不可能做得很準確。在無法準確制定項目計劃的情況下，對其風險要足夠重視，并制定出具體可行的對策。如果對整體的需求或工作結構分解無法一次完整的清晰，就應當把它先分解為幾個大塊，分塊進行，已經(jīng)清晰的先制定本塊（階段）計劃，下一環(huán)節(jié)的工作也可以開始（分塊）進行。再項目開始階段往往還沒有得到詳細的需求成果，因此根據(jù)項目計劃漸進明晰的特點，在需求調(diào)研分析階段過后，需求成果清晰是，應當及時細化項目計劃，在概要設計完成時，要更進一步地細化后面編碼測試階段的詳細計劃。
7、與上一種情況相反的是計劃表的顆粒度太細
就是說軟件開發(fā)的工作雖然可以被劃分為若干階段，但是這些階段不應該是整齊劃一的。雖然每個環(huán)節(jié)階段成果是下一環(huán)節(jié)階段成果的基礎，但即使在階段成果通過評審之后下一環(huán)節(jié)對上一環(huán)節(jié)也應當隨時進行檢查驗證，上一環(huán)節(jié)根據(jù)下一環(huán)節(jié)的驗證檢查情況進行調(diào)整。在上一環(huán)節(jié)沒有得出可以供下一環(huán)節(jié)開展工作的基本成果時，下一階段的投入可能是浪費時間。“按任務分清每個人的責任”并不是說上一環(huán)節(jié)的人員在初次完成