Ocean PMP BLOG

花了半個月把 Initiation 寫完了，總共約 15 篇，依專案管理五大流程的順序，接下來應該談到 Planning，因為上星期公司裡的PMP有個聚會，剛好談到要如何應付客戶需求持續變更的問題，所以在談 planning前我們先跳到 Monitoring&Controlling 流程裡最重要的章節 integration change control(整體變更控制)。
話說當某個 change request 被提出後，他對專案目標的影響會僅侷限於單一一個領域嗎？還是須先經由專案團隊先作評估到底影響有多大，再由 change control board 來審查是否同意，舉例來說，IT收到內部需求要建立一個資訊傳遞管理系統，取代目前透過e-mail更新 Excel file 的機制，當你的專案成員完成需求分析、SA(系統分析)、SD(系統設計)後開始進行 coding到一半時， 這時 End user跟你提出要增加一個欄位，這時如果你是專案的 team member你該如何？我知道大部分非 IT base 的 end user的說法:「不就只增加一個欄位，應該很簡單，你計較什麼，幫忙加一下」， end user會把增加欄位這件事，想成與在 Excel file 按右鍵新增一欄一樣簡單，你要是沒有想清楚，礙於人情義薄雲天的一口答應，那麼鐵定是災難的開始，標準的 Scope creeping，寫不完的程式，人家在休假，你在加班。
為什麼這樣說，因為我在公司就負責一個這樣系統，我是 End user 與 IT 之間的窗口，個人有深刻感受，我們來看看增加一個欄位會影響多大，假設該系統有 20個步驟，每個步驟需要讓不同部門人員來更新再傳送至下一部門，另有10個可供相關單位查詢進度資訊的畫面，20支報表，還有一些運算做告警及 KPI 達成率分析，增加一個欄位你說變動有多大，單單重新分析20個步驟、10個畫面、20支報表，還有那些運算機制是否與該欄位相關，可能就要花掉一個星期，這就是為什麼要有 integration change control流程，當你完成評估後，要記得估出所需更動的範疇有多大(scope)，需要多少 manpower (cost)，要多少時間(time)，最後一定要再給一張 Quotation讓 management 及End user了解變動有多大，是否還要變更。每次上課講到這個案例時，IT base的學員都會頻頻點頭，身有同感。
Ocean