案例背景

IEM Company 正在 RedGate Technology 現場進行影像與晶圓傳送系統升級。第一台升級設備發生電腦「藍畫面」故障，依公司升級程序，問題超過6小時未解決即升到 Level 4。設備最終停機 3天，而整個升級原承諾在 2週內完成。

問題／衝突

故障無法在模擬器中重現，原系統工程師又在兩週前離職，留下的新工程師對產品線不熟。團隊發現原本風險規畫主要集中在設計與供應鏈，只納入中、高風險活動，也假設 Technical Support Group 會自行負責現場實施計畫。

事實上，技術支援團隊並不知道專案經理已把現場實施責任視為他們的完整責任；專案範疇與風險計畫之間出現明顯斷裂。

決策點／實施

團隊重新檢視時程、範疇與風險規畫。由於設備必須如期交還生產，專案經理提出增加第二班人力以追回3天延誤；團隊同時繼續重測電腦、詢問其他工程師並尋找根因。

Program Manager Julia 質疑原風險計畫是否過度排除低風險活動，以及是否忽略長期可靠性測試與現場實施風險。她要求團隊重新整合各功能責任。

原書狀態／結果

案例在團隊意識到風險規畫、專案範疇與實施責任彼此不一致時結束，沒有揭示最終根因與升級專案最終結果。

原書討論問題

1. 有人認為這些風險計畫是錯的。你認為可能錯在哪裡？Julia 是否應同意原風險計畫？
2. 專案風險規畫在以下面向可如何改善：專案組織、實施、策略、領導？
3. 團隊下一步應如何恢復專案？

原書本 A 檔未提供正式解答。

參考分析（教學延伸／依本章內容推論）

風險清單若只涵蓋「看起來重要」的技術項目，卻忽略交接、知識流失、現場實施與責任界面，就可能對真正會中斷專案的風險失明。風險管理必須跟完整 WBS 與責任分工一起檢視。