軟件開發的各個過程分類過于精細，制定進度計劃時各項工作過于緊湊、沒有彈性，造成的后果是，定期提交項目進度階段報告的制度只有在表面上起到效果，按照計劃的時間表提交階段成果也只是在表面上起到效果。

　　低估了軟件開發項目實現的條件

　　低估軟件開發項目實現的條件表現在低估技術難度、低估協調復雜度、低估環境因素這樣幾個方面。

　　首先是低估技術難度。軟件開發項目團隊成員，有時甚至是企業的高級項目主管也經常低估項目技術上的困難。低估技術難度實際上也就是高估人的能力，認為或希望項目會按照已經制定的樂觀項目計劃順利地實施，而實際則不然。軟件開發項目的高技術特點本身說明其實施中會有很多技術的難度，除了需要高水平的技術人員來實施外，還要考慮為解決某些性能問題而進行科研攻關和項目實驗。

　　其次，低估了協調復雜度，也低估了多個項目團隊參加項目時工作協調上的困難。軟件開發項目團隊成員比較強調個人的智慧、強調個性，這給項目工作協調帶來更多的復雜度。當一個大項目由很多子項目組成時，不僅會增加相互之間充分溝通交流的困難，更會增加項目協調和進度控制上的困難。

　　另外，企業高級項目主管和項目經理也經常低估環境因素，這些環境因素包括用戶環境、行業環境、組織環境、社會環境、經濟環境。低估這些條件，既有主觀的原因，也會有客觀的原因。對項目環境的了解程度不夠，造成沒有做好充分的準備。

　　未考慮軟件開發過程的循環、迭代特性

　　因為“上有政策、下有對策”，強行的規定會使人產生一些錯誤的認識：如在項目計劃中“規定”某個時間只能做某某類別的事情，那么嚴格執行的后果就是編碼階段就不能修改文檔;另外錯誤的“里程碑”概念可能會使大家輕易地相信上一個階段的工作成果都是“通過評審”最終定稿了，而實際上可能只是因為時間到了該提交的人提交、該評審的人評審了。如果上下階段是不同的人就根本不會去檢查其中是否還有錯誤;如果上下階段是同一個人，就可能非正式地修改上一階段的錯誤，但占用的時間和精力卻是下一階段的，并且這樣的修改時沒有記錄的。這樣關于階段進度控制的措施實際上只是在表面上有效。

　　最為普遍的情況是，用戶在合同中限定了提交軟件系統的時間，實際上這個時間對完成項目任務來說是遠遠不夠的，但計劃只能按照合同來進行，所以要不用戶讓步，要不只能按照時間的約定提交實際上還未完成的軟件系統。

　　完成系統的安裝，但這時候的“完成階段任務”只是一個表面現象，系統雖然安裝了，但可能是沒有經過嚴格徹底測試的，也可能是只完成了部分的功能，省略了某些功能，有些是整塊功能省略，有的是省略了某些功能的某個過程，如數據錄入里面隱含的數據錄入前缺省值設置、數據錄入檢驗等功能，而是實現了比較粗糙的功能。

　　這樣，系統交付并不意味著項目的完成，而在項目交付之后還要花更多的時間。