Mar. 13, 2020

變更管理程序

        今天來談談專案變更管理程序。首先先談談提出變更的單位與變更的內容有哪些。專案的變更不外乎來自於需求與規格變更，人員或是資源變更、預算優先順序造成的變更、品質因素造成的變更等等。

        需求或是規格變更大部分來自於顧客或事業務部門，最常見的問題就是規劃階段對市場掌握度不是很足夠，一旦專案啟動後，對市場的掌握度提高，不得不提出規格變更的需求。這部分對專案經理人而言是最痛苦的一件事，因為很多的設計可能都要重新來過，專案推遲也是自然。

        另一種變更也是令專案經理人很難處理的，就是人事異動。成員離職、調動(被抽掉離開專案)等，在所難免，然此種變更最容易造成業務銜接上的問題，是無法避免的變更。至於資源與預算優先順序變更的部分，由於是企業內部的重大經營方針改變，責任往往不在專案經理人身上，所以問題不大(其實很大，因為前面的投資都可能泡湯，問題不大是針對PM來說)。

        專案變更看似無法避免，那就只好迎戰，問題是該如何做。首先專案變更的程序應該有個基本流程，凡事依據流程處理之。變更管理的流程應該涵蓋：

        變更需求提出→登錄→專案影響評估→設計審查(必要時與立案程序一樣)→決策→承受或是退回→計畫調整→進入控管程序

        提出變更要求(就如ECR一樣)：要求變更或是變更發生的時候，應該有個程序，以書面化的方式來管理。並且需求單的內容應該包含要求變更的範圍、變更的理由、原因，當然提出變更者雖然無法很精確的知道變更對專案的影響，但還是希望能毛估一下變更對專案的可能影響。如此作法有助於避免變更的浮濫。

        登錄：一旦有變更申請提出，也應該有一個正常的程序列入記錄，而不該只是一個會議上口頭說說而已。如果有專案事務局的話，就由專案事務局為之，不然的話由PM自行記錄。此程序在ISO的精神上可以做到書面化與回溯管理。就專案管理而言，這些素材都是未來結案時檢討的重點。

        影響評估：PM一旦接到需求變更申請時，應該立即針對變更需求，進行詳細的評估。評估變更後對專案的可能影響，以作為專案決策依據。評估的內容不外乎時程、範疇、成本、預算、以及品質等等的衝擊。如果衝擊很大已超乎PM個人的決策權限，提請層峰進行擴大審查會議也都是必要的程序。

        設計審查：此部分依據影響程度大小，做法有所不同，主要由PM依實際需要判斷之。如果是輕微的影響，或許只要專案內部討論即可。如果影響程度中等，或許就要透過審查機制，進行一些調整(如預算或是時程等)。但是如果影響程度已超出PM的掌控能力，就要以最初立案的程序，進行擴大審查。這也是品質保證體系的精神所在(風險管理與品質保證)。

        判斷與決定：當然審查完後一定要做個決定。大部分的專案變更要求，都是被接受的多，但有時如果影響很大，中途夭折的專案也不是沒有。審查完後當決定接受時，就該有個變更後的計畫修訂案出台。內容必須有變更部分的敘述，特別是動用到額外的預算時，更必須依此計畫變更來申請追加預算。所以決策下定後，還有後續的一些內控程序要走完。

        如果層峰認為變更帶來的影響太大，選擇不接受變更，則問題就回到基本點上。當然這種情形不常見，除非高階主管對計畫的重視度很高，否則都不會在此節骨眼作文章。

        計畫調整：PM依據申請內容，針對專案的影響，立即展開計畫調整。也同時補足一些內控程序，譬如預算追加、人員申請、計畫修訂等。修訂完後的計畫，如果要嚴謹一點的話，還必須提出報告。(一般都沒有再多此一舉)

        進行日常管控：PM依據調整後的計畫，進入專案管控程序。

        明日來談談變更管理的注意事項。