在發展WBS時最常見的問題是，專案經理會直覺地想使用過程、活動、工作當成WBS元素，例如「需求分析」、「軟體設計」。儘管PMBOK告訴讀者：WBS沒有一定的拆解方法。但是，讀者可不能因此而迷失，認為WBS元素怎麼拆都對；所以，什麼都可以當成WBS元素。基本上，WBS除了支持計畫的發展之外，很重要的是會成為後續專案管理的依據。吾人在管理專案的時候，最重要的就是對專案成本、時程、技術績效的掌握與控制。要做到成本、時程、與技術績效的掌控，我們得需要有"具體"的東西，才能估計成本、時程、以及賦予技術績效。也因此，不論是PMBOK或是美國軍方的標準，均特別強調，WBS是產品導向(美國軍方說法)或交付項目導向(PMBOK的說法)(或以之為WBS的定義)。而專案經理在發展WBS時，就必須遵循WBS的定義(產品導向樹狀結構，或交付項目導向樹狀結構)發展WBS結構。

WBS亦為專案及工程管理中許多規劃活工作的基礎：

下圖為另一個與電腦軟體有關的WBS：

在上圖中的WBS裡，依據美國軍方WBS手冊的說法，對於開發上具有高成本或高風險的計畫，應適度地再向下層拆解，亦即可以達到Level 4與Level 5，或者更低。在美國軍方的經驗裡，軟體系統的發展，不論其屬於人事系統或是太空梭的導航軟體，在開發過程中圴屬高風險與高成本的計畫。故而在此其WBS發展的指導手冊裡，發展至Level 4與Level 5。上圖可以與五樓的圖做比較。

對於軟體系統專案的WBS，在PWBS階段裡，主要任務產品不論向下拆幾層，均要注意要拆到有機會個別描述CSCI之外觀、功能、非功能需求。這些所謂的外觀、功能、非功能需求，實務上是描述在WBS字典中的，WBS字典的初版，是由獲取方的專案經理負責撰寫。

----------------
引文: