變更可以避免嗎?

Mar. 13, 2020

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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