交付標地 VS 工作

上次提到,WBS是我們為了完成專案目標所必須產生的「交付標的」(Deliverable)。 而「交付標的」因為是個最終的結果、服務、或是產品,通常我們都是以名詞來做描述。 比方說颱風夜的準備中:泡麵、棉被、DVD、Wii 是交付標的;結婚典禮準備中:喜帖、喜餅、鮮花、氣球等是要達成目標所需要有的東西;而一個設計新車的專案中:設計圖、模具、原型機、測試清單等等可能是我們不同階段要能交付的結果。

當把WBS完整的列出來後,我們僅是定義了整個專案的規模與範疇(scope)。 我們雖然知道最後要得出甚麼東西,但..這些要怎麼得到呢? 也因此,我們要再以此為依據,繼續發展「為了完成每項交付標的所必須執行工作的清單」。 這樣的清單有個名稱叫做「作業清單」或「活動清單」(Activity List)。

舉例來說,我打算自己煮晚餐。 所以我起個專案叫做Dinner Operation;根據我的需求我設了四個主要的WBS。 

WBS的範例 

如之前文章提到,WBS一般是以Hierarchical (階層式)的方式來呈現。 最上面標示專案名稱的為Level 1的WBS。 而下層Level 2則展現了要完成這專案所必須交付出來的主要成果;Level 3 所列的牛肉、豆干還有海帶,則是Level2滷味拼盤的細分 – 也就是完成滷味拼盤所必需要要包含的成果。

但這些東西列出來後,不表示蝦仁炒蛋自己就會長出來。 我必須要做些事情才能得到這樣的成果;而要做的這些事情,我們稱之為Activity。 比方說:
工作清單 (Activity List) 

每樣Activity 都是一個動作,畢竟我們總是要做些事情才能完成蝦仁炒蛋這整件事情。 而因為每件Activity都代表是個動作,所以需要花時間;也因為是動作,需要資源來投入協助(如需要人來工作、需要用到特別的機具設備、或需要耗用原料)。 而所有這些人力、物力、甚至材料都需要花錢才能取得。 也因此,Activity是我們評估完成「交付標的」時最小的時間及金額的計算單位

舉例來說
工作、資源與工時 

當我們有這樣的預估,且也俱備所有資源(人、物、及材料)的單價(如一顆雞蛋NT$5元、一小時的人力NT$100元)時,我們就可以依照上面的設想來計算每一項Activity的可能成本。
包含了工作、資源與成本 

當有所有Activity的成本後,我們更可以累加計算蝦仁炒蛋這項「交付標的」的成本;而當我們最後掌握所有同階層「交付標的」的成本後,我們甚至可以計算上層「交付標的」的成本。 意思是說,滷味拼盤的取得成本將是下面牛肉、豆干、海帶之總和;而「滷味拼盤」加上「蝦仁炒蛋」加上「糖醋魚」加上「飯」的成本就是我們執行晚餐專案的總成本。

雖然其中的資源需求多僅是我們的「預估」甚至是「猜測」的,但是當我們是以工作本身來做預估時,我們分散了預估的不準確性。 因為若我們從來沒做過某個產出時,我們很可能無法想像到底做整個「蝦仁炒蛋」要花多少錢或花多少時間。 但若拆解成完成所需的工作時,我們將較容易推估單項工作所需的時間與資源需求。 就算如此計算出來的成本預估還是有誤差,那誤差相對也較小。 等到最後我們把所有Activity的預估成果累積計算後,我們算出的「交付標的」之總所需時間與成本需求相對就較具有參考性。 更重要的是,我們日後將可回顧這些推估的原始依據為何? 專案行進中也將有更為具體的事項來做監控(如到底最後用了四顆蛋還是三顆蛋),更是方便結案後的檢討。 而這把成本跟做的事情連結在一起的規劃以及追蹤方式,我們稱為ABC (Activity Based Costing)。

說到這裡,有個問題不知道是否有人會想問? 上圖WBS的架構中我把滷味拼盤拆解成牛肉、豆干、跟海帶,但是為何蝦仁炒蛋不拆解成蝦仁跟炒蛋呢?

原因在於這範例中,我的預想是滷味拼盤下層的產出有可能來自於不同的地方或是以不同的手法製作後,最後才裝盤整合放在一起。 也因此下面每項細的產出確實可能需要做不同的事情、投入不同的資源才能達成。 但是蝦仁炒蛋雖然包含了蝦仁跟蛋,但產生蝦仁炒蛋所需的作業其實不特別需要去區分是針對蛋或蝦仁的(可以一起準備也可以一起炒),也因此目前這樣的拆解也就夠細了。 所以WBS的拆解沒有對或錯,當涉及專案的內容、執行方式、或是案子的前提假設與限制不同時都有可能會不同。

另外一個可能會有人問的問題是 – 在蝦仁炒蛋下「製作」這項Activity為何不分得更細緻些呢? 以製作而言,確實可以再定義的更細緻: 比方洗蝦仁、打蛋、攪拌、下鍋、倒油等等。 那為何我僅用「製作」這樣一個動作包含這些所有事情? 這裡的做法一樣沒有對與錯,而是需要專案主導者判斷之處。 因為有時候我們可能需要監控到很細、也有可能我們不需要。 這裡僅能提供一個大原則:在規劃時我們必須要小心拿捏; 如果我們定義的不夠精細,以至於之後專案展開時無法清楚掌握大方向時,那我們規劃花的時間很可能其實都是白白浪費。 但反之,若是我們展的太細導致之後需花很多時間做調整、收集資料、回報進度,但這些多花的時間卻不能讓我們更好的管理我們的大方向時,那這多的細緻度就沒必要了。

覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
張國洋 Joe Chang

現為識博管理顧問執行長,也在台灣百大上市櫃公司擔任管理講師與專案顧問。歷年客戶包含工研院、台積電、廣達、富智康、光寶集團、台灣大哥大、遠傳電信、中鼎工程、建國工程、台橡公司、大同公司、三陽工業、TVBS、特力屋集團、城邦集團、誠品集團等。 為了對抗雙魚座的感性,一直在努力強化理性思維與邏輯思考。 相信邏輯發展能解構任何事物,並讓我們找到合宜的人生策略與方向。

Joe G+ ICON Joe LInkin ICON

2 則讀友回應

  1. Joe Chang 2009-02-24 14:14:38 第 2 則

    如果要做當然可以
    只是這範例裡頭我就沒搞這麼複雜了...
    若簡單的想像,WBS Dictionary界定了編碼、誰負責各道菜、帳戶歸總、進度認定規則等隨附著WBS的詳情資訊..

  2. 阿智 2009-02-24 13:54:27 第 1 則

    您好,PMBOK有提到WBS Dictionary.
    WBS與WBS Dictionary可以作為範圍基準(Scope Baseline)的參考.
    所以您每道菜是否都有對應的WBS Dictionary呢?