Ocean PMP BLOG

很多人把需求當作是 Scope of work，因為需求通常簡短敘述，乍聽之下會以為很簡單(可參考另一篇文章，”只加一個欄位你(IT)計較什麼”，如果未經思索可能會忽略原來有一堆工作要做，我想大家都有過這種經驗，輕率的答應一些不該答應的工作，回來做下去才發現並非如此，後悔莫及。Sales有時也不小心的 over commit 一些事，回來交給PM才知道，雖然是簡單的一句話，那可是會做死人的。我們也常說，老闆說一句，下面的就做不完，不是嗎？

好，如何把那一句話(需求)分成那一堆工作，方法就是用 WBS(work breakdown structure)：

(1)     怎麼分解:

n            By Project Life Cycle：意思是為了達成需求，我們朝下列幾個階段來想每個階段到底需要做那些工作，然後一層一層的往下細分，逐步地將需求分解成一項一項工作。

l           Requirement Hearing、System Analysis、System Design、Coding、UAT

l           Site Survey、Drawing、Material Preparation、Manufacturing、Factory Test、Shipping、Installation、Commission、Pilot Run、

n            By Project Management Life Cycle: Initiation、Planning、Execution、…

n            Other ways：無論用甚麼角度去分解，唯一原則是，最後的各項工作都是為了要將產品或服務交給客戶，我們稱為 deliverable oriented。Ex: 備料、人員外派訓練。

n             

(2)     下列是工作分解的好處：問一個問題為什麼要做工作分解？最起碼你要答對第三項，因為要將工作分配給不同專長的

 resources 來做，這樣才會快、成本低，品質好，風險低，對吧！

n            提升成本、工時、及資源預估的精確度。

n            定義績效衡量與管制的基準線。

n            促進明確的職責分派。

n            範圍縮小較易達成，提昇組員信心及成就感(管理基本技巧)。

(3)       分解到第幾層：

n            依時間

l           方便Review 配合你 project status review meeting。

l           配合你簽 Time sheet 週期，你的 team members 要送每週工作表(網路或紙本)給你簽核時。

l           經驗法則 8 - 80 hour(1 day – 2 wks) 。

n            不能再邏輯地細分下去(Cannot logically subdivided further)：該工作沒有界面，換句話說該工作從開始到結束中間，不會受其他活動進度的干擾，意思是你的 team members沒有機會跟你說，因為誰的進度落後所以造成他進度落後

n            有個有意義的交付物

n            可以外包出去

(4)     如何運用 WBS

n            Further breakdown to the Activity level

n            工作分派(RAM, responsibility assignment matrix)

n            Activity duration and cost estimation

n            Network diagram、Scheduling(時間排程，WBS->work package->activity->activity sequence->resource Est.->duration Est.->develop project schedule)

n            Cost Budgeting

n            採購分析(Plan purchase acquisition)

n            風險管控(Risk Mgt.)

n            品質標準(Quality standard)

n            聘用人員(Staffing/Recruting)

n            Scope baseline for Scope Monitoring&Controlling needs

n            可供下一個專案的使用(Lesson learned, organizational process assets)

分解的原則及該WBS 的敘述及重要事項，我們會記錄起來，這個記錄稱為 WBS dictionary，講白一點就是WBS 的名稱是短短的敘述，無法讓人瞭解全貌，為了避免誤解及不必要的Gold Plating(多做)，所以要做備註。最容易且精準的WBS 就是參考過去歷史資訊(historical information)，也就是每次完工時做 lesson learned所累積的組織流程資產( organizational process assets)，WBS 觀念也常運用在採購作業中，承包商、供應商總是喜歡將報價工項包成一大項，業主採購就是要你分解，看看為什麼這麼貴，到底錢藏到那裡。

通常WBS 分解原則第一層是依專案生命週期(Project Life Cycle)來分的

Ocean