在眾多的專案中，缺乏合理的進度安排是造成專案延期最主要的原因，這比其他所有因素加起來影響還要大。這個災難是怎麼發生的呢？
所有系統的進度安排背後第一個錯誤的假設是：一切都將運作良好，每項任務僅需要花費它“應該”花費的時間。對於創造者，只有在實現的過程中，才能發現我們構思的不完整和不一致性。
程式設計人員通過非常純粹的思維活動構思程式，所以很容易自信的認為實現過程中不會遇到困難。然而我們的思維是有缺陷的，專案越大，能夠按照計劃順利進行的概率就越小。
在估計和進度安排的過程中使用“人月”作為工作量單位是十分荒謬的，是一個帶有危險和欺詐性的神話，他暗示著人員數量和時間可以相互替換。然而人數和時間的互換僅僅適用於，某個任務可以分解給參與人員，並且他們之間不需要相互交流的情況。
當不能分解時，人手的新增對進度沒有任何幫助，大多數程式設計工作都具有這種特徵。就像你無論找幾個媽媽，孕育一個生命總是需要10個月的時間。
對於可以分解的情況，增加人手可以加快進度，但是會提高成本，2個人的效率可能僅等於1.5個人。原因在於溝通、培訓、交流等事物增加了工作量，而且所增加的工作量可能會完全抵消任務分解所產生的作用。
軟體開發作為一項系統工作，溝通、交流的工作量非常大，它會快速消耗任務分解所節約下來的時間。
系統測試進度的安排往往是程式設計中最不合理的部分，都過於短了。很少專案允許為為測試分配一半的時間，然而大多數專案的測試實際上是花費了進度中一半的時間。
不安排足夠的測試時間將會是一場災難，由此造成的專案延期成本高昂，在早期規劃時，保留充分的測試時間非常重要。
作者建議進度安排：
1/3 計劃
1/6 編碼
1/4 構建測試和早期系統測試
1/4 系統測試，所有的構建已完成在本章中，作者試圖告訴我們，專案之所以延期，很大部分原因是因為專案在最初的計劃階段，就錯誤的估計了專案進度。
管理人員很容易會認為專案功能完成就意味著開發完成了，沒有為測試階段安排較長時間的意識，往往測試的時間只能佔到專案週期的1/8甚至更少。這明顯是犯了樂觀主義的錯誤，專案管理人員甚至比開發人員更加樂觀。
如果不是站在專業的角度上，似乎很難理解測試階段所花的時間，更難理解的是為什麼增加人手不能讓專案進度加快。