Ocean PMP BLOG

專案結不了案:

無論你是管理階層、專案經理或專案成員應該都有下列這些經驗不知專案怎麼才能結案

1)       需求愈來愈多怎麼也做不完

1.           來自於管理階層的需求愈來愈多(sponsors)

2.           來自於客戶(customers)

3.           來自於使用者(end users)

4.           來自於專案關係人(stakeholders)

5.           來自於專案團隊本身(project team itself)

需求愈來愈多怎麼也做不完，我們稱為 scope creeping, 就是許多不在專案範疇的(小)需求未經 change request procedure就被專案成員接受執行，正確的方法是將不同需求記錄評估(包括可行性分析、範疇、時間、成本、品質、風險…)，許多的需求看似簡單，但分析後才發現範疇很大，所以專案經理要謹記專案範疇，要去發現是否有任何變動，當發生時要走上述的change request procedure，把原範疇當phase I，新的需求列入phase II 是比較好的做法，否則永遠做不完，請不到款也會傷害團隊士氣 。

再舉例來說某專案目標是將產能增加10%，該專案執行相當順利，最後階段管理階層說那好我們將目標提高到20%，我們大家努力看看是否能達成，這個目標 ok，問題出在那裡？會出在專案經理有沒有認知到這是與當初專案目標不同，當初是以10%為目標訂出專案範疇不是以20%為目標，所以如果不走change request procedure 重新 plan怎麼可能達成20%目標(除非當初 over design)。

2)       專案工作都做完了，可是發現並沒有達到預期目標，因為RAM(responsibility matrix assignment)所列每個單位/人分配的工作都執行完成，所以成員認為專案應該完成

1.           問題出在將專案需求轉成專案範疇說明書時或專案範疇說明書轉換成WBS時或WBS細分時出了問題，好比公司今年要將某產品的成本降低10%，所以很明確該專案需求是某產品的成本年底前降低10%，可是在範疇說明書時，是將各個單位需執行的活動工作列出，這個時候就出現問題，這些活動與成本降低我相信一定相關，但是這些活動執行完成時是否就能在年底前降低10%的成本目標，我是有很大存疑，那應該要怎麼做我們來看看。首先我們要先瞭解甚麼是專案的Deliverable(交付物)，上述的 deliverable很明顯的是” 某產品的成本年底前降低10%”，然後再往下分到各部門時還是要連結這個交付物，譬如工程部要節省$10M、製造部要節省50M….，這些描述就要擺在WBS的第一層，所以我們說WBS是deliverable oriented，再細分後個別執行後再重組時是要與 deliverable 密切聯繫。

Ocean