交流和規模
如果項目中只有一個人，那麼位唯一的交流路徑就是這個人和顧客之間的交流。隨着項目成員的增加，交流路徑也隨之增加，但是二者之間的關係並不是加性的，而是乘積性的，即交流路徑的條數大致正比於人數的平方。交流路徑越多，則畫在交流上的時間也就越多，因交流而出錯的機會也就越大。更大的項目要求採取一些組織技術來改善交流效率，或者有意識地對其加以限制。
通常改善交流效率的常用方法是採用正式的文檔。而不是讓50個人以各種可能的方式相互交流，而讓他們閱讀和撰寫文檔。
項目規模的範圍
評估項目規模的方法之一就是考慮項目團隊的規模。
項目規模對錯誤的影響
項目的規模既會影響錯誤的數量，也會影響錯誤的類型。也許不會想到錯誤類型也會受影響，但隨着項目規模的增大，通常更大一部分錯誤要歸咎於需求和設計。
在小項目中，構建錯誤大約佔所有被發現錯誤的75%，方法論對於代碼質量的影響不大，對應用程序質量最大的通常是編寫程序的各個開發者的技能。
在更大的項目中，構建錯誤總數的比例逐步下降到50%左右；而需求錯誤和架構錯誤則彌補了其中差額。推測起來大概是因爲項目越大，所需的需求分析和架構設計越多，所以這些活動產生錯誤的機會也就會相應地增加。
項目規模對產生率的影響
對於小項目，影響因素是程序員的素質；隨着項目規模和團隊規模的增大，組織方式對產生效率的影響也將隨之增大。
項目規模對開發活動的影響
活動比例和項目規模
對於小型項目，構建尤爲最主要的活動，它佔了整個開發時間的大約65%。對於中型項目，構建仍處於主導地位的活動，但是它所佔的比例已經下降到了大約50%。對於非常大型的項目，架構、集成和系統測試佔去了更多的時間，而構建活動變得不再那麼占主導地位了。
不論項目的規模如何，有些技術總是很有價值：有訓練的編碼實踐、讓其他開發者審查設計和代碼、好的工具支持，以及使用高級語言。這些技術對項目很有價值，對大項目的價值更是無法衡量。
程序、產品、系統和系統產品
代碼行數和團隊規模並不是影響項目大小的僅有因素。另一個更敏感的影響因素是最終軟件的質量和複雜度。
沒能認識到程序、產品、系統以及系統產品在精緻度和複雜度上的區別，是導致估算出偏差的一個常見原因。程序員用他們開發“程序”的經驗來估計開發一套系統產品的進度，可能會低估10倍。
方法論和規模
在軟件開發領域中，項目越正規，不得不寫的文件數量也就會越多，用於確認已將完成的工作。做這些文書工作可不是因爲寫起來很有趣。撰寫他們的原因在於：你要協調的人員越多，那麼爲了與他們相互協調，所需要寫的文檔也就越正規。
撰寫文檔的目的並不在於文檔本身。例如：寫配置管理計劃的目的不是要鍛鍊寫作技能。先寫計劃的關鍵在於，它能迫使仔細考慮配置管理，並且把計劃向每一個人解釋。
