用人月來衡量一項工作的規模是一個危險和帶有欺騙性的神話，因為它暗示了人員數量和時間是可以互相替換的。(注:人月是用來衡量工作量的，規模是通過功能點或代碼行等方式來衡量的，規模除以個體生産率後可以得到人月資料)。
這裡進一步來描述人月不能互換的原因，
- 首先是任務能否拆解，
- 即使能夠分解任務間是否存在互相的依賴和限制，
- 分解後是否增加會增加相應的溝通，
- 以及由于分解任務而引入的分解和後期內建等額外的工作量。
當軟體産品的規模增加的時候，複雜度成倍增長，進而導緻這些要素之間不是單純的線性關系，這是人月神話的啟示之一；同時由于軟體項目本身的生命周期模型和工序任務限制，導緻對于一定規模的軟體産品研發，無論投入多少的資源，都有一個最短工期的限制，在這個最短工期下投入再多的資源也沒有用。
如果一個系統按功能點估算有200個功能點，按一個功能點200-300行代碼計算，整個系統規模在5萬行代碼左右。這是一個中小型的項目或系統。如果按照總生産率80行/天計算，則總工作量在20人月左右。
根據非線性關系我們可以估計理想情況或者說成本效益最好的情況是投入5人4個月完成，當人數增加一倍時候進度隻能壓縮到3個月。當人數再增加到15個人的時候，進度壓縮到2個月，這個時候增加再多的人就已經沒有用了，對于這種規模的的系統，2個月可能就是進度極限了。
對于大型項目，書中給出了推薦的工作量比例分布(計劃1/3,編碼1/6,單元測試和內建測試1/4,1/4系統測試)。很少有項目為測試配置設定一半的周期和時間，也很少有項目真正隻給編碼配置設定1/6時間。根據個人實際軟體項目開發的經驗，大概的經驗資料是(需求1/4，設計實作1/2,測試1/4)。中小型項目能夠配置設定到1/4的測試工作量已經是比較大的一個值，這意味着一個10人左右的團隊需要配置2個專門的測試人員)。
非線性增長
我們講當規模增長的時候，工作量并不是非線性增長，周期也不是非線性增長。其中工作量的增加
- 第一個重點增加在了系統分析設計，需要将複雜的系統進行分解；
- 其二在後期內建和測試，需要将分解的各個功能子產品內建群組裝。
對于産品規模增加的時候，對于詳細設計和編碼階段工作量可以任務是一種線性的增加，非線性部分指數增加的工作量都展現到了前期的分析設計和後期的內建和測試上面。
當我們假設是線性的時候，我們主觀的去縮減了這兩頭的工作量。如果縮減了系統分析和總體設計的工作量，則可能帶來整個産品結構的不穩定，後果往往是整個産品推倒重來；如果縮減了後期內建和測試的工作量，則不可避免的是導緻項目延期。
樂觀主義者喜歡假設我們開發的是零缺陷的系統，但對複雜的軟體系統而言這僅僅是個神話。
進度落後根源
對于進度落後的問題根源，我們可以做如下考慮。
1.需求本身頻繁變動而且不受控，開發頻繁的修改和返工，全是無效工作量。
2.開發人員技能本身問題，或者是開發效率低，或者是對業務需求了解不深。
3.開發人員自身的态度和責任感，是否有一種能夠刺激他們潛在創造激情的氛圍。
4.沒有一個安靜專注的環境，經常被各種無意見的會議，電話和瑣事打斷。
當進度出現嚴重問題時候最有效的方法仍然是消減任務，與其傳遞10個不可用的功能點，還不如傳遞5個優先級高的功能點。其二進度落後的時候，盲目的加班往往是無濟于事的。
按照時間管理的方法論，你越忙的時候你越該停止下來，好好的檢討究竟慢在哪裡，瓶頸和根源究竟在哪裡，隻有當問題的根源真正被挖掘出來和解決後，才可能真正提高效率和加速度。