在衆多軟件項目中，缺乏合理的進度安排是造成項目滯後的最主要原因，它比其他因素加起來的影響還要大。導致這種災難如此普遍的原因又是什麼？首先，我們對估算技術缺乏有效的研究，更加嚴肅地說它反映了一種悄無聲息但並不真實的假設---一切都將運行良好。第二，我們採用的估算技術隱含地假設人和月可以互換，錯誤地將進度和工作量互相混淆。第三，由於對自己的估算缺乏信心，軟件經理通常不會有耐心持續的估算這項工作。第四，對進度缺少跟蹤和監督。在其他工程領域中，經過驗證的跟蹤技術和常規監督程序，在軟件工程中常常被認爲是大膽的革新。第五，當意識到進度的偏移的時候，下意識（以及傳統）的反應是增加人力。這就像使用汽油滅火一樣，只會使事情更糟。越來越大的火勢需要更多的汽油，從而進入了一場註定會導致災難的循環。
系統編程的進度安排背後的第一個錯誤假設是：一切都將運作良好，每一項任務僅花費它所“應該”花費的時間。對於這種瀰漫在編程人員中的樂觀主義，理應受到慎重的分析。Dorothy Sayers在她的《創造者的思想》（The Mind of the Maker）一書中，將創造性活動分爲三個階段：構思、實現和交流。書籍、計算機或程序的存在，首先是作爲一個構思或模型出現在作者的腦海中，它與時間和空間無關。接着，藉助鋼筆、墨水、紙張，或者電線、硅片和鐵氧體，在現實的時間和空間中實現它們。然後，當某人閱讀書籍、使用計算機和運行程序的時候，他與作者的思想互相溝通，創造過程從而得以結束。
當一件東西不順應“我們”設定的思路，其實，這只不過是我們的驕傲使判斷帶上了主觀主義色彩。在單個的任務中，“一切都將運行正常”的假設在進度上具有可實現性。因爲所遇到的延遲是一個概率分佈曲線，“不會延遲”具有限定的概率，所以現實情況可能會像計劃安排的那樣順利。然而大型的編程工程，或多或少包含了很多任務，某些任務間還具有前後的次序，從而一切正常的概率變得非常小，甚至接近於零。
成本的確隨開發產品的人數和時間的不同，有着很大的變化，進度卻不是如此。我們認爲用人月作爲衡量一項工作的規模是一個危險和帶有欺騙性的神話，它暗示着人員數量和時間是可以互相替換的。人數和時間的互換僅僅適用於以下情況：某個任務可以分解爲給參與人員，並且他們之間不需要相互的交流。這在割小麥或者收貨棉花的工作中是可行的；而在系統編程中近乎不可能。軟件開發本質上是一項系統工作----錯綜複雜關係下的一種實踐，溝通、交流的工作量非常大，它很快會消耗任務分解所節省下來的個人時間，從而，增加更多的人手，實際上是延長了而不是縮短了時間進度。
在進度安排中，由於順序限制所造成的影響，沒有哪個部分比單元調試和系統測試所受到的牽涉更徹底。而且，需要的時間依賴於所遇到的錯誤、缺陷的數量及其難以捕捉的成程度。理論上，缺陷的數量比預料的要多得多。因此，系統測試進度的安排常常是編程中最不合理的部分。特別需要指出的是，不爲系統測試安排足夠的時間簡直就是一場災難。因爲延遲發生在項目快要完成的時候。直到接近項目的發佈日期，纔有人發現進度上的問題。因此，壞消息沒有任何預兆，很晚纔出現在客戶和項目經理面前。另外，此時此刻的延遲具有不同尋常的、嚴重的財務和心理上的反應。在此之前，項目已經配置了充足的人員，每天的人力成本也已經達到了最大的限度。更爲嚴重的是，在用軟件支持其他商業活動（計算機硬件運送、新設備操作等）的情況下，若在即將發佈時出現延誤，所付出的二次商業代價是非常高昂的。實際上，上述的二次成本遠遠高於其他開銷。因此，在早期進度策劃時，允許充分的系統測試是非常重要的。
計劃三分之一，編程六分之一，構件測試和早期系統測試四分之一，系統測試，所有的構件都已經完成四分之一。
簡化的Brooks法則：向進度落後的項目中增加人手，只會使進度更加落後。
這就是去除了神話色彩的人月。項目的時間依賴於順序上的限制，人員的最大數量依賴於獨立子任務的數量。從這兩個數值可以推算出進度表，該表安排的人員較少，花費的時間較長（唯一的風險是產品可能會過時）。相反，分派較多的人手，計劃較短的時間，將無法得到可行的進度安排。總之，缺乏合理的進度安排是造成項目滯後的最主要原因，它比其他因素加起來的影響還要大。