8.2 失敗專案的教訓
不論你規劃得多仔細,失敗還是會發生。但失敗不只是一個結果——它帶著值得保留下來的教訓,可以用在下一次。
這一節會從幾個角度,走過失敗專案常見的原因與警訊,讓你能更早看出來,並阻止它擴散。
1. 目標模糊,或在中途漂走
- 不同的利害關係人對結果有不一致的期望,而且從沒被對齊
- 商業目標從來沒有被清楚寫下來,所以每一邊各自解讀
- 公司的優先順序在專案中途改變,原本的目的悄悄漂走
沒有穩定的方向,就算專案準時上線,也會被記得是一場失望。
2. 風險與問題沒被好好溝通
- 問題追蹤表變成形式——填了卻沒人真的處理
- 第一線的聲音傳不到做決策的人
- 風險減輕與備援計畫缺席或太薄
沉默的文化——或是把難開口的對話一直推遲——會讓早期風險幾乎沒辦法處理。
3. 「人」這一面被忽略了
- PM 或其他關鍵主管被指派得太晚,或根本沒被指派
- 審查與核可變成走過場
- 成員流動,交接不完整
穩定的人與清楚的責任歸屬,和排程一樣重要。任何一邊崩了,其他都會跟著搖晃。
4. 專案管理沒在運作
- 狀況看得很清楚,但決策被延遲或迴避
- 原本講好的規則——審查、進度更新——並沒有真的被遵守
- 報告交了,但沒有引發任何行動
「我們知道,但沒做」是失敗專案裡最常出現的模式之一。
案例:電商網站翻新(零售公司)
概要:一個 8 個月、B2C 電商網站的全面翻新案,在接近上線時被中止。
- 從一開始 KPI 就模糊,需求一直變
- 跟使用者端的協調很薄,規格確認一直延後
- 關鍵成員辭職,連續性與交接都斷了
- 品質問題在發布前堆積,專案最後被取消
這個案子結合了「目的模糊」、「領導斷層」、「溝通薄弱」——任何一個單獨都還能撐,湊在一起就把專案推過了能挽回的點。
結論:失敗是一連串被忽略的訊號
專案失敗不是一個錯誤造成的。它是累積的訊號、被延後的決策、以及從沒發生的對話的結果。
所以早一點注意到那種「卡卡的感覺」——並且有勇氣、有系統去停下來、談一談、修一修——才是真正的預防。
在 AB 裡長這樣
上面每一種失敗模式,在 AB Project Management 都有對應:範圍模糊 → 專案描述 + Wiki「不在範圍」頁面,讓範圍有個不會漂走的家;隱藏的風險 → 類型為 Risk 的任務搭配定期 check-in,讓風險保持活著,不會被埋進某張試算表;升級太晚 → 變更歷史頁籤自動記錄狀態與負責人變動,所以升級不是另一份報告;知識孤島 → Wiki 頁、留言、附檔都跟專案在一起,不會散落在各種磁碟與信箱;責任不清 → 負責人欄位逼著每個任務都掛上一個名字。AB 並不能阻止…