WBS之所以重要，如同上篇所提它是一個定義案子範疇(scope)的工具；而範疇之所以重要，則在於我們唯有能先清楚的定義出最後要「交出甚麼」，我們才知道專案到底要「做甚麼事」。 也因此，透過WBS這工具，我們將把專案所有的「交付標的」(Deliverable)以有系統的方式詳列出來。

在案子的初期正確辨識出Deliverable是很重要的一件事，因為不管是甚麼專案，專案一開始的目標通常都很抽象，很可能是「增進人類福祉」這種遠大的目標。 但抽象的目標若不能「具像化」，那案子要不就在大夥各自解讀下朝著不同的方向展開，要不就是專案進行中將遭遇到難以數計的重大變更並讓所有人都又累又挫折。

WBS的制定不表示這些事情可以完全不發生。 但最少這是一個用來「降低這些事情的機率或影響性」的手段。 舉例來說，籌劃一個「讓人開心的生日派對」就是個很抽象的目標。 畢竟甚麼叫開心？ 怎麼算是讓人開心？ 十個人可能有十個答案。 哪個正確？ 又哪個不正確？ 可能都正確，也可能都不正確。 只有當大家能把抽象的概念轉化成可「具體」取得、產出、或交付的成果、物件、或服務時，你才開啟了那道跟別人溝通甚至達成共識的門。 比方說，我可能覺得讓別人開心的生日派對要有蛋糕、有禮物、還要每個人輪流倒立著來唱生日快樂歌。 直到我把這些交付事項都定義出來且述諸文字後，其他人才能判定這些東西是否真有滿足專案的原始需求。 可能大家不介意唱生日快樂歌，可是倒立唱？ 恐怕就沒太多人同意這會很愉快。 那「倒立唱歌」這項恐怕就是一個無法正確對應目標的交付標的，這標的就得被調整或是刪除。

換句話說，Deliverable讓所有專案相關人員了解，當專案宣稱完成時，你是否有辦法能客觀的定義專案的結果是「完整」的？ 你將提供甚麼給你的客戶、你的業主、你的老闆、或你的委託人？ 最終如何能來驗證專案產出了正確的結果？ 必須要有一份對內對外所有人都認同且接受的「交付標的」清單才能讓我們回答這些問題。

也因此Deliverable能否正確定義將影響專案成敗；而WBS則是「Deliverable」具體拆解的一種展示工具。

WBS基本的型態可以是如上一篇文章中類似購物清單的簡單形式。 這清單將是「所有」後續規畫的起點；WBS做得出來還不表示後面規劃就能完整正確，但如果WBS做不出來，後面的規劃可說是必然「全不可信」。 也因此，唯有確定這些「交付標的」確實能滿足專案目標後，我們才該繼續考慮這些東西要怎麼做？ 誰來做？ 做多久？ 如果來不及或沒能力自己做到，那可不可以外買或發包？ 不然所有預估恐怕都只是浪費時間。

講到這要岔題一下，購物清單這東西真的是還滿實用的。 以我自己那非常壞的記性來說，若原本去超級市場預期要買十樣東西。 不做清單的話，不管出發前再怎麼默念，只要進入賣場經歷試吃攤位各種小點心的催化後，每次都能讓我忘了買其中八樣。 結帳時雖然還是買了十樣，只是其中八樣卻總會是那些原來毫無規劃要買的試吃品。 這有個專門術語叫做Scope Creep (範疇漸增、也有人翻譯成範疇潛變)

這是列出清單(做WBS)的另一個目的 ─ 幫自己畫一條線！ WBS幫我們控制專案範疇及避免範疇潛變。 當有一個比較的基準時，專案進行中成員就能清楚知道該專注於哪裡；哪些才是我們真正該交付的產出。 爭議發生時、或是新需求被提出時，也就能幫團隊聚焦。 大家才知道對哪些提議應該說「不」；確保團隊成員不會、也尤其不該花時間精力做些原始並不被預期的事情。 如上例，跑去超級市場如果沒明確的清單來規範我時，我很可能原本要買的沒買，卻胡亂買了一堆試吃攤上很好吃但回家後沒辦法處理的大盒味增、法式大蒜奶油、以及冷凍烏龍麵。(說起來..法式大蒜奶油目前確實還躺在我家冰箱中)

這在專案執行上恐怕更是常見。 如果原本要做的東西定義的很抽象，在專案過程中大家往往就開始加油添醋，想把自己的好意、靈感、想法都帶進來，最後往往導致方向彼此衝突、進而造成時間不夠、產出相互牴觸，甚至最後完全無法收拾。 這是為何？ 因為當沒有聚焦下，什麼新功能、新事件、新原件、新需求看起來總都很棒很好 (就如同超市試吃的產品)。 會被新東西、新需求模糊了我們的心神；我們會胡亂接受變更，亂接受新功能，亂接受提議，亂接受….. 最後大家加班到要死要活，卻反而離目標越來越遠。 長久下來大家還以為大幅變化就是專案本質。

不，不是如此。

專案確實是有其變動性，但不表示該是沒有方向。 也因此，我們手上需要一個明確定義好的交付標的清單，也就是WBS。 它告訴我們方向為何，讓我們評估怎麼樣是做完了，也讓我們在過程中確保到底做了甚麼，又還有多少沒做。

簡單的WBS形式可以如同個購物清單，而在大型專案下WBS可能會很複雜。 一般多以Hierarchic(階層式)或是Outline(條列式)的形式來展現。

(上圖，Hierarchic(階層式)的WBS範例) (Practice standard for WBS 2ed edition)

(上圖，Outline(條列式)的WBS範例)

在上圖中，最上層的階層是專案自己(如上圖中的Bicycle)，稱之為Level 1 WBS。 第二層(Level 2)則是此專案最主要的交付標的。 而這些主要的交付標的有時候還是很籠統或是抽象，因此為求管理方便以及專案實務可以進行，我們通常還會繼續往下展細。 這有個術語叫做Decomposition，這將一直執行到我們可以確實掌握足夠清晰的「交付標的」為止；WBS的最下層也有個名稱叫做Work Package(工作包)。 在這樣的架構下，每一層WBS將為下層交付標的之總合，每一次的拆解也表示專案最終產出更加詳細之描述。 (Each descending level represents an increasingly detailed definition of the project work.) (PMBoK, 3^rd edition 2004, PMI)

當這架構最後終於產生後，也就表示我列出、也具像化了所有我們在這專案中預期產生的結果或是目的。 這東西如能獲得所有人的共識(包含團隊及專案委託人)，就表示我們手上具備了一個最後專案完成時，我們可以回頭對照、檢視、與查驗「範疇完整度」的清單；也才可以開始進行後面的規劃。

專案要能繼續，這東西絕不可缺。

如果你想要了解專案管理的核心觀念，也歡迎你參考【101專案管理一日特訓班(7PDU)｜專案管理課程】，這堂課不強調 PMP 證照考試的相關內容，而是更深入專案管理的核心觀念。

不僅會有 PDU 點數，更能幫助你建構更扎實的專案管理基礎。