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