PM的牛肉在哪裡?再談WBS

20121118_Beef Cutting Chart_1

工作分解結構(Work Breakdown Structure, WBS)是許多專案管理初學者第一個碰上的專有名詞。你知道有MBA學位的人和沒有MBA學位的人最大區別在哪嗎?有種說法是,前者擅長在對話中饒管理名詞,而且一定要有英文縮寫,類似這樣:

MBA一號:「你知道今天我Boss有多Evil?他在Board Meeting因為KPI的Issue和CFO互相finger pointing,最後竟然Blame on me,這明明就是RD Head和QC Team間的communication有Gap嘛!這些人真是Crazy,WTF!」

MBA二號:「Calm down!你的coffee都快被你噴成cappuccino了。FYI,你Boss站在你背後很久了,Good Luck!」

同樣的,考上PMP的人WBS也都朗朗上口,幾次和PMP聊到WBS,我都得到非常「正確且標準」的回覆,對話大概像這樣:

我:「你們平常會用WBS嗎?」

PMP一號:「當然!WBS就是工作分解結構嘛!Work Breakdown Structure。(得意)」

PMP二號:「沒錯,而且WBS是屬於Scope Management,是Project Planning階段重要的output!(自信)」

我(心中的OS):「WTF,Good Luck!」

好吧,這樣的回答確實「無懈可擊」,但也「無用至極」。這讓我想起一個笑話:

有位冒險家搭熱氣球旅行,結果被風吹到陌生的地方迷路了。他看到地面上有個工程師走過,就降下來問他:「請問你知道我現在在哪裡嗎?」

工程師:「當然,你現在在距離地面10公尺高度的地方!」

知道WBS的定義,知道(或聽人說)WBS很重要,並不能代表真正了解WBS的本質和目的。在發表我的看法之前,我們先翻開PMBOK大辭典看看WBS的解釋:

Work Breakdown Structure (WBS). A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project.

這段解釋中,有個關鍵字我認為常被初學者(甚至教PMP的講師)給忽略,這個字重要到甚至還出現了兩次,那就是Deliverable。這個字有人翻做「交付標的」,有人翻成「產出物」或「交付物」,沒錯!WBS基本上就是基於專案「最終的成果」來做的「逆向拆解」。一幅完整的WBS是告訴我們,當這個專案完成的那一天,將會包含這些「元件」,不多不少,彼此也沒有重複!

嚴格說來,WBS和所謂的工作清單(Activity List)是很不一樣的概念。WBS的每個方塊是必須被完成的「元件」(Deliverable or Product);而Activity則是為了完成該項元件,而必須採取的「行動」(Action or Movement)。所以一位觀念正確的PM,做出來的WBS通常是以「名詞」來表示,而Activity的描述中總是會有「動詞」。例如某個婚禮籌備專案中:

WBS元件:喜帖(名詞)

對應的Activity:尋找廠商、選擇花色、確認樣本、填寫信封、寄送喜帖…(動作)

所以說,當專案團隊制定WBS時,大家思維應該是反向的。先釐清這個專案完成時該是甚麼樣子,期待當中包含甚麼部件,腦海中有個圖像(就像我這張牛肉解剖圖)後再逆向去拆解成個別的組件。這就是為什麼專案管理很強調「需求分析」,而WBS是釐清需求的一個重要工具與手段!有時候WBS一畫出來才發現,原來大家對專案的想像根本都不一樣,好加在還沒真的開工。這也就是我們常常強調,一定要先規劃,不要急著動手的原因。

WBS的重要性除了展現在釐清需求與範疇外,另一個目的就是工作分派。除非是一人專案,不然沒有比適當地切分工作,讓對的人做對的事更重要的了,如果這個專案考慮外包,那適當地切分工作更是關鍵,這就是為什麼PMBOK說WBS是採購規劃(Procurement Planning)的要件之一!(p.318 PMBOK 4th Edition)

工作拆分出去了,下一步就要監督有沒有被做好。這時WBS又成了專案績效評估的基準。多數的專案報告中都是用WBS來當作主要的群組條件,因為越是複雜的專案,老闆們越不可能親自監督每個細節的工作,最好的方式就是以WBS的大項目來彙整,看到異常的WBS時再去檢討其中的細節,這才是比較有效率的方法。所以WBS在這裡可說是What Bosses See!

WBS重不重要?當然重要,說他是專案管理的基礎建設絕不為過!WBS等於把利害關係人的需求與專案範疇畫成明確的圖像,把大目標拆解成數個容易管理的小目標,如此團隊才知道該做甚麼事,需要多少時間,也才能進一步評估所需要的成本。WBS幫助我們分派工作,幫助我們切分工作給外包商,分派出去後也能以同樣的結構來監控他們的績效,幾乎整個九大知識領域都和WBS環環相扣。

要制訂出一套好的WBS其實需要不少經驗累積。莊子裡面有個庖丁解牛的故事大家都聽過。庖丁對文惠君說了這麼一段話,我覺得跟WBS的概念頗能呼應:「我剛開始殺牛的時候,眼中看到的是一條牛。三年之後,我看到已經不是牛,而是牛的五臟筋骨。到了現在,我已經不用眼睛看,就可以憑心領會牛的筋骨脈絡。我的刀遊走在骨與骨相接,骨與肉相接,或是筋骨間的縫隙,沒有阻礙,遊刃有餘,迎刃而解!」要將一個專案美妙地切分妥當,確實有些專業門檻,這也就多數專案管理嚇嚇叫的企業,多半會儲備公司的過往的專案範本做為參考。因為同一家企業中必定有許多專案是相似的,前人的經驗往往是新手PM最佳的教材。

庖丁又說:「一般廚子,看到牛就拿刀又割又砍,每個月就得換一把刀;好一點的廚師,只割不砍,一年換一把刀;至於我的刀已經用了十九年,殺了數千頭牛,仍然一樣鋒利。雖然如此,每當我要支解一頭牛前,我仍會摒氣凝神,充分掌握牛的結構,才開始緩緩下手…」這說明了兩件事,第一,工作切割良好,能夠減少滯礙,流程才會順暢;第二,先掌握整體,看清楚才下手,別衝動!

不管你對牛排有沒有興趣,只要你的工作和專案有關,都建議好好花些功夫在WBS上。有效掌握WBS,就有效掌握專案管理的精隨!

BTW,各位PM,最後這個Key Point非常地Critical,Good Luck!

覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
姚詩豪 Bryan Yao

成大土木所與美國西北大學專案管理雙碩士、識博公司共同創辦人、普錸資訊資深副總、國際專案管理師(PMP)、甲骨文與微軟認證顧問。曾任紐約市環保署顧問、MWH Global, Inc.專案控制經理,參與國內外多項大型專案並擔任百大企業之諮詢顧問。擅長以詼諧的筆觸以及理性的思維來探討生活中的大小事。文章常轉載於《商周》、《天下》、《經理人》等媒體。與張國洋合著《三年後你的工作還在嗎?》以及《沒了名片,你還剩下什麼?》。

Bryan G+ ICON

9 則讀友回應

  1. 鄺友良 2016-07-15 14:06:51 第 9 則

    Deliverable 就是"交"什麼出來的意思. 你說你做了. 你有什麼證據? 如果你能取得(交出)某某的簽署,那你的工作就算完成.

    工作: 去探討XXX的可能性
    Deliverable: 一份可能性研究報告 (一定要由某人簽定.. 附合什麼準則..)

    工作: 寫CODE for XXX function
    Deliverable: A piece of tested coding with Sign Off.

    本來自己一個去做就不會那麼煩. 但係項目管理就是要分拆分解再分工. 但分了之後 對工作的描述就不能只是.. 完成XXX. 而是要 "交什麼出來" 那個方向去想.


  2. 余丹 2014-05-07 15:50:52 第 8 則

    我觉得你这些关于专案管理写的非常好,能不能帮忙提供一下WBS的软件

    • Bryan Yao 2014-05-08 09:15:07

      我自己都是用Oracle Primavera P6或是Microsoft Project這類專案管理軟體來做WBS,但這些軟體功能強大,WBS只是眾多功能之一而已。
      如果你的目的只是繪製WBS,建議可以直接用Microsoft Visio的流程圖工具(其中有類似樹狀圖的模板,Word, Excel, PowerPoint的繪圖功能也有),或是試試看以下這個WBS Tool(我也是Google到的,自己沒用過)
      http://www.wbstool.com/

      Good Luck!

  3. RogerSkywalker 2013-10-20 07:10:15 第 7 則

    針對WBS在實務上運用碰到一些問題,在這裡請教不知是否恰當。

    首先針對 deliverable 是否要是實體產品(可觸碰的?)?

    另外在WBS的圖中,是否相同LEVEL 的型態必須相同。比方說LEVEL2 全是Deliverable, 但level3 能否有些是更仔細的deliverable 而一些已經拆分成 process or activities ?

    謝謝

    • Bryan Yao 2013-11-06 16:00:17

      針對問題一,是否所有deliverable都要是實體物?

      答案是未必,事實上也不可能,因為很多專案是屬於企劃或是服務性質,未必有實際的產品被做出來,好比「博物館設計專案」或是「客戶服務流程設計」這類的project。話雖如此,我們仍希望所有的deliverable能盡量做到【有完成或是沒完成,是清清楚楚,一翻兩瞪眼】的,這樣才能做到良好的範疇管控。

      一個比較好的做法是,所有的deliverable盡量是以一份文件,或是某個里程碑的形式來表達。比方說剛剛提到的博物館設計案,「概念設計書完稿」當作一個deliverable是比較明確的,純粹叫「概念設計」就比較含糊,我們很難定義這個概念設計到底完成了沒,除非我們真正拿到一本【概念設計書】,而且被核定為完稿。

      針對問題二,WBS各level的型態是否要相同...

      這也沒有強烈的規定。但我自己擔任顧問的經驗,我會建議企業針對同一類型的專案,前2-4層WBS盡量標準化,從第3或第4層開始,再讓PM依據個專案的特性自由發揮。好比WBS第2層統一用專案的phase(階段),第3層統一用system(系統)之類的。這主要是為了高階主管的方便,他們可以用一個相同的角度來審查各專案的狀況。

      以上。

  4. taylor shieh 2012-11-27 21:01:27 第 6 則

    可參考PMI 所提腳踏車的例子..

  5. taylor shieh 2012-11-20 19:34:03 第 5 則

    以電子業來說:
    會與客人簽定SOW ( Statment of Work ), 定義工作的流程/範圍.

    • Bryan Yao 2012-11-23 16:38:35

      工程業、軟體業也是有一樣的習慣!