專案變更申請流程圖（範圍、成本、時程）
專案變更申請流程圖：變更登記冊、影響評估、容許偏差決策、督導委員會審批，以及專案基準的重新訂定。
運作方式
把泳道改成與你們角色相符
把申請人、專案經理、專案團隊、財務與變更審批方／督導委員會，換成你們實際擁有的角色。在小型專案裡，變更審批方可能就是一位發起人，財務可能只是一位以電郵審閱數字的業務夥伴。請合併泳道，而不要畫出並不存在的管治機構，並把泳道數目控制在五條以內，好讓這張圖仍然讀得下去。
把你們的容許偏差寫在決策旁邊
「是否在專案經理的容許偏差之內？」只有在背後有數字時才有用。寫下專案經理可以批准的成本與時程偏差幅度，再加一條範圍規則，例如不得改動已議定的交付項目、效益或合約責任。如果你們運行 PRINCE2，這就是專案管理委員會下放的容許偏差，它還可能附帶一筆變更預算，好讓例行變更根本不必送到委員會。請在啟動時就把限額議定，而不是等到它第一次被試探的時候。
界定影響評估必須包含甚麼
把「記錄影響評估」做成一份真正的範本：對範圍、時程、成本、品質與風險的影響，資金來源，考慮過的備選方案，一項建議，以及不作為方案。指明每個維度由誰評估、他們有多少時間——因為一份要做三個星期的評估，最後會變成一個沒有評估就作出的決定。
指名變更審批方及其開會節奏
在督導委員會檢視這一步上記錄：審批人是誰、是否需要法定人數、他們多久開一次會、以及進入議程的截止時間。明確決定會議之間會發生甚麼：要麼由一位具名人員緊急批准並在下次檢視上匯報，要麼變更等着。把這一點留空，正正就是那些在走廊上被批准的變更的來源。
令暫緩帶上時限
一項被暫緩的變更需要一個覆議日期、一位負責人，以及登記冊中一個仍然有效的狀態——這就是這裡的暫緩分支回到其後的督導委員會檢視，而不是回到一個終點的原因。在每次檢視上查核被暫緩的項目，把已被形勢超越的項目連同理由一併結案，好讓登記冊反映的是決定，而不是把它們堆積起來。
訂下重訂基準的規則，然後發佈並為這張圖做版本管理
寫明哪些已批准的變更會觸發一次正式的基準重訂，哪些只是被吸收進預測，並要求在新的基準版本上記錄變更編號。保留此前的各版基準，好讓幾個月後仍然解釋得清楚一項偏差。然後把這張圖分享到工作真正發生的地方——變更申請表旁邊、專案手冊裡——並保留它自身的版本歷史，好讓你們能說明程序是甚麼時候改的、為甚麼改。
常見問題
專案變更申請與 IT 變更管理有甚麼分別？
它們回答的是不同的問題。專案變更申請問的是一份已議定的基準——範圍、成本、日期，往往還包括效益——是否應當改動，而這個決定是商務性的：要花多少錢、會延誤甚麼、由誰出資，以及商業論證是否仍然成立。IT 變更管理問的是一項針對正式服務的變更能否推出，而這個決定是營運性的：對用戶的風險、測試、停機時段與回滾。如果對話裡出現的是 CAB、變更日曆與回滾方案，請使用變更管理流程圖。如果出現的是督導委員會、一個修訂後的完工日期與一條預算科目，那麼這張圖才是對的。
一份專案變更申請應當包含甚麼？
足以讓另一個人不開會也能評估它：改動的是甚麼、為甚麼改，由誰在甚麼時候提出，觸發因素是甚麼——一項新要求、一個缺陷、一個外部依賴、一個被推翻的決定——緊急程度如何、誰會受到影響，以及甚麼都不改會發生甚麼。評估補上其餘部分：對範圍、時程、成本、品質與風險的影響，資金來源，考慮過的備選方案，以及一項建議。請把這兩者作為各自獨立的紀錄保存。申請是申請人的原話，評估是專案的回答；把兩者合併，事後就再也看不出當初實際要求的是甚麼。
誰批准專案變更申請？
這取決於規模，而這正是本圖中容許偏差決策的用途。落在專案經理啟動時獲授權的偏差幅度之內的變更，在專案經理泳道內獲得批准並被登記。超出的一律送交變更審批方，通常是督導委員會、專案管理委員會或發起人。PRINCE2 把變更審批方描述為專案管理委員會可以下放的一個角色，有時還附帶一筆變更預算，好讓例行變更不必佔用一次完整的委員會決定；PMI 的整體變更控制則以變更控制委員會做同一件事。無論你們叫它甚麼，都請把限額寫下來：一個未有界定的容許偏差意味着，要麼甚麼都升級，要麼甚麼都不升級。
暫緩一項變更究竟意味着甚麼？
意味着決定被推遲，而不是被拒絕——通常是因為影響還未清楚、這項變更取決於另一個決定，或者它本來就屬於較後的階段或版本。它只有在暫緩帶上時限時才管用。在本圖中，暫緩分支通往一個擱置步驟，在其後的督導委員會檢視上重新提交，而不是通往一個終點，因為一項沒有回路的暫緩變更，就是一次沒有人需要說明理由的否決。請為每一個被暫緩的項目給出覆議日期、負責人，以及登記冊中一個看得見的狀態。
每一項批准的變更都必須重訂基準嗎？
凡是改動了專案承諾交付甚麼、甚麼時候交付、以及花多少錢的，都要重訂基準。否則偏差報告衡量的是一份你們已經同意放棄的計劃，而每一份狀態報告都需要口頭解釋。請保留此前的各版基準，而不是覆蓋它們，在新版本上記錄變更編號，並寫下批准日期。在容許偏差內批准的小變更通常被吸收進預測，而不觸發正式的基準重訂——請在計劃裡寫明哪些屬於哪一類，好讓兩個人讀同一份報告時得到同一個數字。
這個流程如何遏止範圍蔓延？
靠的是在變更被議定之前、而不是在它交付之後，就令它的代價看得見。範圍蔓延很少是一個大決定；它是一連串被團隊吸收、從未送去評估的小增補。這裡真正起作用的控制有三項：登記冊，令每一項申請都有一條紀錄；影響評估，令沒有人在看不到它對日期與預算做了甚麼之前就批准一項增補；以及容許偏差限額，令專案經理清楚知道自己的權限到哪裡為止。這個流程無法阻止變更，也不應當阻止——它令變更成為有意識的、可追溯的。