台灣時間2021年3月23日至29日間，長榮海運公司的長賜號貨輪在埃及蘇伊士運河擱淺(註1)，不僅造成該運河每日龐大的轉運作業停擺，連帶影響全球相關產業的供貨，對全球經濟(特別是油價)帶來不小的波動。

當地政府為了盡速疏通運河，派出挖土機試圖清除貨輪前端淤泥，但挖土機和長賜號不成比例的差異，很快就被網友笑稱是「工程師資源和業務承諾」的寫照，後來各種詼諧甚至惡搞的圖文紛紛出爐。除了讚嘆網友的創意之外，也讓人意識到，原來大家對職場上這種不對等的落差有如此深切的感慨。

雖然每家企業的行事風格不同，企業和老闆們是否過度畫大餅也並非我們可以掌控的，但本篇文章將從範疇、品質這兩個管理面向來檢視，看看長賜號事件可以為我們在專案管理的學習上帶來什麼樣的啟發。

「確認範疇」是專案一開始相當重要的任務，很多工程師與PM、業務之間的認知差異，甚至是委託者和承包商之間的誤會，就來自於範疇的界定不清楚，導致雙方各說各話。要描述一個專案的範疇，首先必須定義邊界，以長賜號擱淺的案件來看，任務可以簡單區分為「清除淤泥」、「減輕重量」、「拖曳船隻」三個大方向，但淤泥要清除的邊界到哪裡? 是船頭陷入泥砂的區塊? 還是延伸到船頭周圍幾碼的範圍? 這是委託方交辦任務時必須要清楚告知的，而承包商為了自己的權益，也應該主動了解全貌，因為其他作業的成敗，可能也會影響淤泥清除範疇的界定，當長賜號順利迴正後，是不是還有場復的作業要進行? 例如泥沙的回填、運河周邊的補強等等。 

角色不同對範疇的解讀自然有所差異，對蘇伊士運河當局而言，任務目標是盡快排除長賜號擱淺事件，並讓運河恢復正常營運，因此只要運河一天無法消化轉運量，這個專案就一天不會結束。而對清除淤泥的承包商來說，則是專注在處理「造成長賜號卡住無法移動的泥沙」，如果事前雙方沒有明確界定範疇，那麼清除過程中造成的其他影響(例如淤泥的處理、前述的場復作業等)，很可能就會變成事後爭議的問題點。

委託方與承包商可以透過合約來約束，但公司內部協作就無法如此白紙黑字規範(雖然大公司內多少還是有龜毛的協作單位)，因此會議紀錄、Email等形式往往就成為跨部門之間留存證據的方法，PM若希望減少跨部門工作的推託，該花時間填寫的紀錄或該發送的郵件就盡量不要缺漏。

與範疇息息相關的另一項任務，是完成後的驗收準則，在軟體開發的領域裡，從初期定義範疇的use case diagram、執行階段的flow chart，一直到驗收使用的test case(註2)，基本上是有一定的脈絡依循，多少的spec就會衍生多少的test case，多一個或少一個都是工程師及品管人員會追究到底的。這個目的在於精確檢驗開發的項目是否完全依據產品規格來製作，不但有憑有據，藉由spec及test case的數量還可以來估算所需的作業時間。

但在軟體開發之外，或者無法具體量化的工作項目，該如何定義驗收準則呢? 通常還是要盡量找出可以比較的基準，例如清除的淤泥範圍，至少須包含長賜號可垂直升起的上下空間 ; 船隻拖曳的距離，至少要使長賜號遠離港口幾公里以上。基本上而言，以「達成什麼目標」當作準則會比完成多少量更加貼近專案需求，畢竟「清除50噸淤泥是否能夠使貨輪浮動」是無法被確認的。除此之外，還必須排除其他因素的影響，例如「垂直升起的上下空間」便是不考慮船隻拖曳的情況，避免將不同的工作權責與成效混為一談。

當然，實務上來說，像長賜號這一類重大的突發事件，不一定適合用這種在商言商、斤斤計較的方式來界定範疇，因此在執行期間，勢必經過不少協商、妥協、互助等過程，這也是不同專案必然會出現的差異，如果一昧使用同一套制式論點來執行專案，反而會衍生更多問題，因此PM必須學習依據不同屬性的專案，將專案管理的精神妥善發揮。

註1 : 長賜號擱淺事件共歷經151小時，出動共約5台怪手挖沙清淤、至少12艘拖船搶救，估計滯留貨物金額達120億美元，改道的船隻航程至少增加3500英里、運河營運收入每天減少約1400萬-1500萬美元。

註2 : test case是軟體工程中用來進行測試驗證的基準，通常是根據規格內容，以功能項目逐條列舉操作情境及預期的結果，測試者根據它來檢查專案產出是否正確。