WBS(Work Breakdown Structure)是專案規劃的重要元素，我們在進行專案規劃的時候，常常犯的一個錯誤，就是從直接選擇一個專案發展的策略(或模型)(例如，Waterfalls、Incremental、Evolutionary，或者Spiral等)，再設法套到專案裡，然後從這個模型所規劃的產出去訂里程碑。這種做法，以筆者的經驗來說是不可行的。因為，不論是多大的專案，在產品上、技術上的決策，事實上遠比決定專案發展策略來得更為複雜。因此，我們在專案規劃上若是以過程為著眼，就算是採用的是Grand Design Strategy(亦即「瀑布式」發展過程)，也將無法做完專案，因為你會陷在過程階段劃分的泥沼中，不知道專案的下一步該怎麼走。而就在這當中，耗盡了時間與預算。

　　WBS是產品導向的，透過樹狀結構的方法，將專案產品分割，直到可以管理的最小單位(但也不能太細，否則會使整合與管理的成本升高)。接著我們就可以根據這些細分出來的工作項目元素，去估算工作時間、成本、所需資源、技術、相關風險。由於這些工作產品的項目是可以管理的，因此，我們也就可以從WBS轉出產品的組態項目(CI)。另外，我們也可以經由WBS的階層關係，了解各工作產品間的相互關係、工作次序等等。由此，我們就可以訂出整個專案工作網狀圖，並以每個工作的工時，訂出專案的要徑(Critical Path)。另外，每個工作產品都是以由上而下的設計、由下而上整合與測試的瀑布式開發方式產出。由於每個產品已經明確地劃分出來，因此，可以很明確地指派出去給功能單位，或開發單位負責實作。而最重要的是，專案的成本就可以精確地計算出來。

　　產品在經過WBS劃分之後，我們就可以預判出專案的可能風險。以績效要求為例，我們要求系統的整體績效每分鐘應能處理1000筆資料，如果沒有以WBS來看，我們實在看不出來達到每分鐘處理1000筆資料的風險何在，但如果我們從WBS來看，我們會發覺，影響每分鐘1000筆資料之績效達成的風險，可能會有網路的問題、硬體的問題、資料庫的問題、系統架構的問題、程式設計的問題、甚至於使用者操作習慣的問題等等……。而種種這些項目都將會是專案管理的重要議題，相對於管理規劃、技術規劃、財務規劃、人力資源規劃、風險管理規劃等等納入專案管理計畫書的相對段落中。

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