俗話說：萬事起頭難，而在專案的世界中，結案更難。

通常時間是一大因素。
同樣的，我也將結案分類成「明確的結案」和「模糊的結案」

明確的結案
**客戶驗收：**這個是最基本但也是最困難的方式。在我的專案經驗裡，簽約前花的時間很長，簽約後啟動很快，系統分析很快，開發測試也很快，但是一到了「客戶驗收」，就是長期抗戰的開始，或許是自己專案沒有管理得很好，感覺上要讓客戶在驗收報告書上面簽下他的名字，就像要了他的樂透頭彩彩券一樣。有些時侯，走到大家都累了，就各退一步，我也不要求客戶簽名，客戶也口頭承諾「算驗收，案子結一結」。
**收到尾款：**雖然這是個很明確的結案檢核方式，但是有兩個吊詭的地方要注意：
一、收到尾款和「客戶驗收」和「事情做完了」並沒有必然的先後順序，甚至沒有表面上的關聯性；
二、不要天真的以為你的老板會以「收到尾款」做為結案時間點，以我的經驗，許多老板在簽完合約之後就認為已經結案了，簽約後續的執行都應該在一眼瞬間完成。
**召開結案會議：**跟Kick-off會議一樣，這也是我個人最偏好的結案點，一來可以找大家一起坐下來，做做專案檢討，好一點的還能講講專案裡的酸甜苦辣，在可樂和比薩的幫助下，大家可以鬆口氣，放鬆一下，然後離開會議室，繼續另外的專案。然而，比起Kick-off會議，結案會議更不受到重視，召開的機會似乎少之又少，我開過不少Kick-off會議，但是我連「結案會議」的英文要怎麼翻都不知道，如果你知道，請告訴我，謝謝。

模糊的結案
**時間久遠：**這是個很奇怪的情況，當上述所有「明確的結案」的條件都沒有成立時，有時就會落入這種「模糊的結案」的情境。譬如說：老板找我去，「聽說最近Web2.0很熱門，去研究一下」，於是我就找幾個人(其實只有一個人)去上網看看，下載一些程式庫，寫個demo系統，對公司內部人員做了個展示研討會，然後就等待老板下一步指示，久而久之，老板也不再提起這件事，那這件事就算自動結案了。

關於結案，我有一個良心建議，就是：如果有驗收項目，一定要簡單明瞭
例如：千萬不要寫「1.系統規格文件」(「系統規格」是泛用字眼，可以是乙份文件也可以是幾十份文件)，要明確地寫「1.系統需求規格書」「2.系統分析規格書」「3.系統設計規格書」。

更重要的是，寫了幾個名稱就要有幾份名稱「完全」相同的文件，這是年輕一代比較容易犯的錯誤，我不只糾正過一次，請專案成員修改文件名稱，由「系統須求規格書」改成「系統需求規格書」；由「專案系統分析規格書」改為「系統分析規格書」，重點不在於「名稱」，重點在於「交付事項要與當初合約所記載的交付事項一模一樣」，一模一樣一字不差不是過份的要求，也不是龜毛，而是讓甲乙雙方安全回壘，事後也較無爭議的一種做法。

下集預告：專案人生─(16)專案管理的九個領域