長賜號擱淺事件帶來的專案啟發

長賜號擱淺事件帶來的專案啟發

台灣時間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是軟體工程中用來進行測試驗證的基準,通常是根據規格內容,以功能項目逐條列舉操作情境及預期的結果,測試者根據它來檢查專案產出是否正確。

本站所有文章未經事先書面授權,請勿任意利用、引用、轉載。
覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
VictorHsu

曾經主修科學,也當過工程師寫過程式,其實最大的興趣卻是是寫文章說故事,目前在網際網路產業擔任PM工作。 自認只是職場上的小人物,但深知專案管理的知識應用廣泛,2011年取得PMP證照後,開啟對專案管理的學習之路,於是結合自身的經驗,以及大眾最熟悉的電影劇情,讓生活、理論與虛構的情節在專案管理的世界裡產生交集,期許能引領更多同好認識專案管理。