專案範疇管理與WBS再探

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

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

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

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

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

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

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

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

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

不,不是如此。

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

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

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


Outline式的WBS範例

(上圖,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, 3rd edition 2004, PMI)

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

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

延伸閱讀
若有轉貼需求,請來信討論。 轉貼時禁止修改內容及標題、須保持所有連結、禁止商業使用,並且必須註明原文標題、連結、及作者訊息。
覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
張國洋 Joe Chang

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

Joe G+ ICON Joe LInkin ICON

13 則讀友回應

  1. 邱必洙 2012-08-09 08:45:35 第 13 則

    回應一下版主大大,雖然我也認為PDM較好用,但很遺憾的,部分的政府單位業主(如:交通部公路總局)還是要求承包商提送ADM的網圖。公務人員考試仍經常出現ADM的考題,所以ADM的軟體還是有需求的。

    • Joe Chang 2012-08-09 13:24:54

      不過我目前真的不知道任何ADM的軟體工具。 所有接觸過的,都是PDM的工具...

  2. Lin 2010-06-22 19:36:27 第 12 則

    恩~= ="可惜

    看來我的論文 在描述ADM的時候只能用文字與圖了
    沒辦法用實做了。

    版主真的很感謝你,解答我這麼多問題...感謝

    • Joe Chang 2010-06-22 20:58:29

      順便提醒你一下,實務上應該幾乎沒人在用ADM了

  3. Lin 2010-06-22 15:21:06 第 11 則

    真的嗎?我第一次用這類型的軟體,還不太清楚市場動態
    原來現在的主流是用結點圖呀?

    所以P6目前已經不支援箭線圖囉?
    不知道microsoft project 會不會支援呢?

    看來我得好好充實結點圖的知識了(笑

    • Joe Chang 2010-06-22 19:31:56

      據我了解這類軟體從來都沒做過ADM

  4. Lin 2010-06-22 14:29:57 第 10 則

    不好意思 版主 在冒昧打擾一下

    請問您知道 結點圖 如何切換成 箭線圖 嗎?

    • Joe Chang 2010-06-22 14:56:24

      唔...這年頭應該沒有主流軟體畫箭線圖了吧?

  5. H 2010-06-22 01:54:51 第 9 則

    大家的回應都蠻有「味道」的

    • Joe Chang 2010-06-22 12:05:01

      很有味道是啥?