小的結構文檔：源代碼是文件
除了API文檔，微軟不對其產品結構生成相應的文檔，雖然有時高級開發員可能會寫下高層結構。對復雜的特性，許多開發員在某些點記錄并復查特定于他們所負責的結構細節，但此工作是可選的，并不強制執行。除了源代碼文件與特性說明，為數不多的組為新程序員準務了描繪某層結構的文檔（主要的數據結構，如何工作等等）。但是這些文件并不時常更新，經理們也不要求項目組生成此類內部文檔。在有關的說明文件中，并不涉及實現問題。開發員應該知道如何去實現，或者能夠去學會。記錄的關于結構的文檔如此之少是因為“一個開發員的工作是編寫我們要賣的代碼，而不是花時間寫高水平的設計文件”，“設計文件不應與源代碼分離”。分割代碼與“保持事情的簡單”。
特性小組和作為"內容專家"的小組領導
特性小組一般由一個領導和3至8名開發人員組成，工作于相關的特性領域。小組的規模常常視小組領導的經驗和能力而定。特性小組領導向項目開發領導匯報并負責項目的全部開發工作；而項目開發領導則擁有對產品的更為全局性的觀點，從而有可能發現不互相關聯的問題。在特性小組中的每個人均是此領域的“專家”，他們了解如何使用產品、了解競爭對手的產品、了解未來將向何處去。通常為便于交流，提高軟件的組織結構（軟件傾向于映射出構造它的組織的結構），應保持特性小組的小規模。
原則五：靠個人負責和固定項目資源實旋控制
對于軟件項目而言，精確估計產品的開發與交付進度是很困難的。對此微軟采取的方法是將進度安排和工作管理的責任推到底層，即單個的開發人員和測試人員那兒去。這保證了每個人除了作為小組的一部分外，還負有個人的責任。單獨的開發人員設立他們自已的進度表，程序經理把單獨的進度表匯總起來，再加上緩沖時間，以制定出一個全面的項目進度表。頂層的總經理也固定人員與時間等基本資源，以確保項目集中并限制其努力與創造程序。
關鍵的目標，尤其對應用軟件，是指明產品的目標出品日并爭取盡可能長久地堅持它。程序經理和開發員從出品日回溯，規定中間的項目里程碑的日期。這個“固定的出品日法“的中心在開發員身上。以避免因為項目沒有固定的結束點，導致在終無用的設計、再設計和測試的循環中消耗一年或更多的時間。
開發人員做出他們自已的進度估計
“日期設定方法"。但是開發人員一般會做出較樂觀的估計，因此開發經理還需對他們所提供的日期進行調整并加上緩沖時間以避免因因信息不完全而出現的問題。微軟這種制定進度的方法的優點在于：它從人們那兒得到更多的合作，因為日期是自已定的，不是經理定的；進度總是富有進取性，因為開發人員不可避免地會低估他們真正需要的時間。
對細致的任務的進度估計
微軟的第二個進度安排方法是：對要完成的任務做非常詳盡的考慮，在此基礎上請開發人員給出他們對“實現”的估計，以此力圖“促使”更加現實主義并避免過度低估。
通常微軟把任務細化到4小時（半天）到3天之間。對于準確進度的安排，微軟的經理是這樣認識的：“任何任務只要超過一星期，那人們一定沒有充分地全盤考慮它。任何任務某人估計只用少于半天可完成，則他對它考慮得太多了。他應該用更多的時間去編程，更少的時間來考慮”。對于類似類于Windows NT之類的操作系統而言，進度安排更加困難，對其一般以幾天或者半周為工作單位進行進度估計。
安排開發人員與小組進度時的心理學
當項目變大時，微軟把員工分成小組。然后經理把進度的責任和所有權盡可能地分發下去，直到小組和個人；這使二者都產生了一種擁用工作的感覺。它還在小組中，個人中，尤其是小組領導中造成強烈的跟上其它同事預計進度的壓力，因為經理可能再平衡進度，從落后的小組或個人手中拿走工作。這樣，同事間的壓力使經理不需要太多的努力可以對個人或單個小組的進程實施嚴格控制。
"固定的"出品日( RTM: Release To Manufacture)
為了把創造力約束在時間限制之中，微軟現在在新產品或者產品新版本開始前爭取固定出品日，至少是有出品日的內部目標。這給人們施加砍去特性和集中在一個項目上的壓力，逼迫他們去苦苦思考應將哪個新特性加入產品中。雖然終產品的交付目標可能是由高級執行人員設定，但是開發人員與小組仍然設定他們自已的進度表。
微軟一般根據預先的時間進度的大致估計出一個RTM日期，然后向前回溯相應的各個Milestone日期，如RC、Beta、Tree Lock、UI Freeze、Feature Complete以及CC（Code Complete）等等各個Milestone的相應日期。制定出十分詳盡的產品研究開發時間進度表，產品開發組的各個成員以這個進度表為目標統一協調工作。微軟十分強調軟件開發過程中的Teamwork Spirits，這種理念貫穿在微軟各個產品開發的各個階段。這也是微軟得以成功的一個十分重要的原因。
小結：同步－穩定開發法
計劃階段
定義產品的想象性描述、說明與進度
想象性描述 產品和程序管理部門運用廣泛的顧客意見來確定和優化產品的特性。
說明文件 基于想象性描述，程序管理部門與開發組定義特性的功能，結構問題，以及各部分間的相關性。
制訂進度表與構造特性小組 其于說明文件，程序管理部門協調進度表，安排出特性小組，每個小組包括大約1名程序經理，3 - 8個開發員，3 - 8個測試員(以1:1比例與開發員平行工作。)
開發階段
用3 - 4個順序的子項目，每個產生一個里程碑式的產品發送，來完成特性的開發。程序經理協調開發過程。開發員設計、編碼、調試。測試員與開發員配對，不斷進行測試。
子項目1 前1/3的特性：重要的特性與共享的構件。
子項目2中間1/3的特性。
子項目3后1/3的特性：不重要的特性。
穩定化階段
全面的內外部測試，后的產品穩定化以及發貨。程序經理協調OEM與ISV，監督從顧客得到的信息反饋。開發員進行后的調試與代碼穩定化。測試員發現并清除錯誤。
內部測試 公司內部對整個產品做詳盡的測試。
外部測試 公司外在的"β"測試點，象OEM，ISV以及終用戶處對整個產品做詳盡的測試。
發貨準備 為批量生產準備發布后的“金盤”（Golden Disk）與文檔，制作之前，還需要進行各種嚴格的檢查：如政治敏感性術語檢查、病毒檢查、文件相關性檢查等。
