在眾多軟體專案中，缺乏合理的時間進度是造成專案滯後的最主要原因，它比其他所有因素加起來的影響還大。導致這種普遍性災難的原因是什麼呢？
1.期望一切運轉良好
首先，如何進行合理的估算，建立在一種悄無聲息，但並不真實的假設之上——一切都將運作良好。但是從來不可能有這種一切運作良好的專案存在，
因為執行者是人，而人就會犯錯，理解偏差，對原有程式碼的不瞭解，無效溝通等等諸多問題都會在執行者身上出現。
畢竟對於各種千奇百怪的需求，除非是之前做過，否則，你永遠不知道會遇到什麼問題，一句隱藏在需求文件中某個旮旯角的話語，有可能就要耗掉一個技術2天甚至3天的時間。
而這，往往會在需求評審時被有意無意的忽略掉，畢竟最重要的需求評審在當前的需求開發中
往往會被要求儘量縮短時間，“產品已經設計完了，你們技術儘快開始，月底上線，沒問題吧！”
2.混淆進度與工作量
第二，我們採用的估算技術隱含地假設人和月可以互換，錯誤地將進度與工作量相互
混淆。一個鍋蒸一個包子需要3分鐘，那麼三個鍋蒸一個包子呢，難道只需要一分鐘麼？
當業務耦合度非常高的時候，某塊任務往往只能交給一人來寫，不然隨之帶來的溝通成本
以及聯合除錯成本經常使得增加的人力做的更多的是無用功。但是往往上級領導為了表示對專案的重視，通常會向專案中增加人員，而增加的人員往往也是一頭霧水，面對大量的程式碼無從下手，畢竟程式設計不是壘磚，需要在瞭解原有專案的基礎上進行工作。
3.估算無法貫穿始終
因為需求工期一般是是估算，不是精確地計算，專案經理通常不會有耐心持續地進行估算這項工作。當專案中某個模組遇到棘手問題時，往往無法估算具體解決時間，即使估算後也無法增加時間，畢竟月底上線的要求猶在耳邊迴盪，這時候去要時間很可能換來的只有一句話“要時間沒有，你們週六日加班吧！”。
4.進度缺少跟蹤和監督
其他工程領域中，經過驗證的跟蹤技術和常規監督程式，在軟體工程中常常被認為是無謂的舉動。但是在軟體工程方面，跟蹤往往也是無效果，畢竟大多數企業加需求就像喝水一樣輕鬆。領導知道不能讓玻璃幕牆換成瓷磚，但是提的這個軟體功能點需要多少時間，那可就沒領導知道了。臨到上線，領導開啟網站一看，提幾個新需求，往往就是幾個不眠不休的日子。
5.錯誤的解決方案帶來的反效果
當專案經理意識到進度的偏移時，下意識（以及傳統）的反應是增加人力以及加班。
方向錯了，努力再多也是白費。新加入的人員往往需要一段時間才能形成戰鬥力，而長時間的加班往往帶來的是員工的精神和身體上的疲倦，這兩者往往都是飲鴆止渴。
為什麼專案開發永遠缺乏合理的時間？上面五點之中有沒有你們延期的理由？