專案結案流程圖：由交付到簽署確認
專案結案流程圖：對照驗收準則驗收、待修項目清單、移交與支援、最終開票、合約關閉，以及發起人的正式簽署。
甚麼是專案結案流程圖：由交付到簽署確認流程
一個專案通常會結束兩次。在實務上，它結束於最後一項交付項目推出、團隊開始談論下一件事的那一日；在形式上，它要到幾個星期之後才結束——最終發票結清、採購訂單關閉、紀錄歸檔、發起人簽名。結案出問題，正正就在這兩次結束之間的空檔裡。人被重新調配，那位知道還有哪份合約未關的同事已經調去了另一個計劃群組，而一個所有人都認為已經完成的專案，還在持續消耗成本編號與授權費用。把結案流程寫下來，主要就是為了縮短那段空檔，並為餘下的每一項工作安排一位負責人。
這張圖由交付之後開始，而不是之前。它不是推出決策：到底要不要推出，是一次就緒程度的判斷，/yue/templates/推出放行決策流程 上的放行與否決策樹覆蓋那道關卡。它也不是專案仍在進行時改動範圍的路徑，那屬於 /yue/templates/變更控制流程 上的變更控制流程。而且它止步於交付項目變成某個人日常工作的地方：一旦營運接手，故障走 /yue/templates/事故管理流程 上的事故管理，進一步的改動走 /yue/templates/變更管理流程 上的變更管理。夾在這些鄰居之間、而且通常是專案裡最缺乏文件的那一部分，正是本頁所要梳理的：驗收、移交、錢、紀錄、學習與簽署。
整條路徑橫跨五條泳道——專案經理、專案團隊、客戶／發起人、財務與 PMO——分為五個階段：結案觸發、驗收、移交、商務關閉，以及總結與簽署。佈局中有兩處是有意為之的選擇。已完成的專案和被提早叫停的專案由同一個觸發點進入，因為一個被終止的專案仍然需要令它做了一半的工作獲得驗收、令它的合約被關閉、令它的經驗被記錄下來——它只是要結案的範圍較小而已。另外，發起人的最終簽署是一個帶有回路的決策，而不是一道手續，於是尚未了結的事項會回到圖中已經存在的那份待修項目清單上，而不是被一揮而過，或者被記到另一份沒有人維護的清單裡。
本流程圖涵蓋的內容
本範本包含
- 五條泳道——專案經理、專案團隊、客戶／發起人、財務與 PMO——鋪開在五個階段上：結案觸發、驗收、移交、商務關閉，以及總結與簽署。
- 兩種觸發共用一個入口：「結案類型？」回答已交付或已終止，其中已終止一支先經過發起人泳道中的「議定終止範圍與截止日」，再匯回同一份交付項目清單與驗收路徑。
- 把驗收當作一次核查而不是一場會議：對照驗收準則檢視交付項目清單，「交付項目是否全部驗收通過？」回答通過或有缺口，有缺口的記入待修項目清單，由專案團隊處理妥當並覆檢之後，才簽署驗收紀錄。
- 帶有支援安排的移交：交付項目轉交營運，發起人議定支援期與保養期，好讓服務台接手的日期在專案解散之前就已確定。
- 財務泳道中的商務關閉：開出最終發票並核對成本，然後「合約與採購訂單是否已關閉？」把仍有未結事項送回專案經理去了結索償與訂單——只有回答已關閉才會釋放團隊並重新分配資產。
- 一段以真正的決策收結的 PMO 收官：經驗總結工作坊、專案紀錄歸檔，以及一次已排期的效益檢討，然後是「發起人是否簽署結案？」，其中仍有待辦事項回到待修項目清單，已簽署則抵達「專案正式結案」。
何時使用本範本
- 你們組合中的專案在實務上早已完成，卻從未在紙面上關閉，於是成本編號一直開着，組合報告裡還算着幾個月前就停下來的工作。
- 交付項目在沒有書面驗收的情況下就被移交，而關於某件東西是否達到了它的準則的爭論，要等團隊被重新調配之後才開始。
- 營運接手了成果，卻從未議定過保養期或支援期，於是每一個推出後的缺陷都要逐件去談。
- 你們開過經驗總結工作坊、也寫成了文件，卻從來沒有人讀，因為沒有任何東西把它們與一個有人會去檢索的檔案庫連起來。
- 你們要在一個 PMO 之內統一結案，並且需要一張圖同時覆蓋已完成與被取消的專案，而不必維護兩套流程。
運作方式
把泳道改成與你們的交付模式相符
把客戶／發起人換成適用的一方：外部客戶是在合約之下簽署驗收，內部發起人是依據商業論證簽署，而你們需要的證據並不相同。如果財務與 PMO 由同一個人負責，就把它們合併；但即使在小型機構裡，也請把專案團隊泳道與專案經理泳道分開，因為修補工作與催進度是由不同的人來做的。
在使用這張圖之前先把驗收準則訂下來
「對照驗收準則檢視」只有在準則是在專案開始時寫下、並標明為必須或期望的情況下才有意義。請在這張圖所匯總的清單裡逐項交付項目地記錄它們，好讓驗收成為對照一份清單的核查，而不是檢視會上形成的一種看法。凡是從未議定過的準則，請把它記為一條經驗，而不要在結案期間重新談判。
界定甚麼算待修項目，以及誰可以豁免
在缺陷與變更之間劃一條線：缺陷入待修項目清單，變更則退回變更控制，根本不是結案事項。然後指明誰有權在仍有未了結待修項目的情況下驗收一項交付項目、他們這樣做時必須記錄甚麼，以及餘下工作要在哪一日之前完成。沒有這些，待修項目清單就會變成結案悄悄停擺的地方。
把支援與保養條款寫進移交
寫明保養期的長度、期內由誰修復缺陷、由誰付費，以及支援轉交給服務台或日常營運團隊的日期。同時列出必須隨交付項目一併移交的東西：操作手冊、管理員憑證、授權與訂閱的擁有權、監察，以及營運一方具名接收的那個人。
先把錢關掉，再釋放人
在開出最終發票的同時，為專案的成本編號設一個截止日期，好讓遲來的入帳不會挪動一份已核對過的預算。逐項處理未結的採購訂單、應計費用、保留金與分判商索償，因為正是這些令一個看起來早已完工的專案在財務上長期開着。本圖只有在「合約與採購訂單是否已關閉？」回答已關閉之後才釋放團隊，而這個先後次序是刻意的。
趁團隊還在一起時開經驗總結工作坊
在人散開之前就開這場工作坊，而不是等報告寫完之後，並且記錄的是決定與成因，而不是情緒。按你們的合約、稅務與審計責任所要求的年期，把專案紀錄歸檔到一個人們真的會去檢索的地方。現在就為效益檢討訂下日期、指定一位專案以外的業務負責人，並記錄基準量度，然後發佈這張圖，並把發起人的簽署對照它記錄下來。
常見問題
甚麼是專案結案流程？
它是把一個已完成或已停止的專案變成一個已關閉專案的那一段次序。在本圖中，它由一個結案觸發出發，經過對照驗收準則檢視交付項目並處理任何待修項目、以議定的支援期與保養期移交給營運、最終開票與成本核對、合約與採購訂單的關閉、團隊與資產的釋放、一場經驗總結工作坊、專案紀錄的歸檔，以及一次已排期的效益檢討，最後以發起人的正式簽署結束。單看每一項工作，都不算難。令結案失敗的原因在於：每一項工作都歸屬於不同的職能，而在交付結束之後，它們沒有一項是任何人的首要事項。
專案移交與專案結案有甚麼分別？
移交是結案裡的一個步驟，而不是結案的同義詞。移交把交付項目及其文件轉給將要運行它的人，並釐清保養期內由誰修復缺陷。結案則是專案本身停止存在所必須發生的一切：驗收被記錄，發票開出且成本核對妥當，合約與採購訂單關閉，資源被釋放，經驗被採集，紀錄被歸檔，簽署被取得。一個專案可以完全移交妥當，卻因為一張採購訂單從未關閉而繼續開着好幾個月——這正是本圖把商務階段與移交階段分開的原因。
一個被取消或提早終止的專案該如何結案？
走同一個流程，只是範圍較小。在本圖中，已終止分支加入一個步驟「議定終止範圍與截止日」，它確定哪些會被做完、哪些被放棄，以及工作停止的日期，然後匯回正常路徑。其後的一切仍然適用：已經建成的部分被驗收或被正式撇帳，合約按其終止條款而不是完成條款關閉，包括任何取消費用在內的成本被核對，經驗總結被記錄。PRINCE2 在其專案結案流程中作了同樣的區分，把準備計劃內結案與準備提早結案分開處理。
專案結案清單應當包含甚麼？
交付項目已對照議定的驗收準則核查且結果被記錄；待修項目或已處理妥當，或在具名負責人與日期之下被接受；已移交營運，文件、憑證與授權擁有權一併轉移；保養期與支援期已議定，並有服務台接手的日期；最終發票已開出且貸項已入帳；成本已核對，專案成本編號已關閉、不再接受入帳；合約、採購訂單、應計費用與保留金已關閉；團隊已釋放，資產、授權與存取權限已重新分配；經驗總結工作坊已舉行；紀錄已歸檔；效益檢討已排期並有負責人；正式簽署已記錄。
誰簽署專案結案？
由發起人或客戶簽署，依據是專案經理的建議。有兩個簽署經常被合併，值得分開來看。驗收簽署說的是交付項目達到了它們的準則，由擁有那些準則的人給出。結案簽署說的是專案本身可以停止了，它還要求商務與行政工作已經完成，由批准了這筆錢的發起人給出。在本圖中，它們是客戶／發起人泳道中兩個不同的步驟，而由 PMO 保管紀錄。如果發起人暫不簽署，未了結的事項會回到待修項目清單上，而不是進入一條電郵串。
專案結案在 PMBOK 與 PRINCE2 中處於甚麼位置？
《PMBOK 指南》第六版把它稱為結束專案或階段，是專案整合管理之下的一個過程；第七版轉向了原則與績效領域，不再把它列為一個獨立過程，儘管同樣的工作仍然必須完成。PRINCE2 有一個專案結案流程，涵蓋計劃內結案與提早結案、產品移交、專案評估，以及向專案管理委員會提出結案建議。這張圖與兩者都相容，也不綁定於其中任何一個：它以泳道繪製，因此角色是明確的——而這正正是兩套方法都留給你們自己去界定的那一部分。
推出後的效益檢討應當在甚麼時候進行？
在交付項目投入使用足夠久、以致商業論證中的效益可以被量度之後；這通常是數月而不是數星期，並且完全取決於當初承諾了甚麼。在結案期間就把它排期的意義在於：這是還有人對這個問題負責的最後時刻。把日期訂下來，指定一位業務一方而非專案一方的負責人，並趁那些知情的人還在的時候記下基準量度。一次日程表上沒有日期的檢討，是結案步驟裡最可靠地會消失的一項。