向失敗的IT專案學習

無論如何，既然專案都已經失敗了，不如就仔細檢討，並寄望能從失敗的專案有所學習，因此Computerworld的《IT's biggest project failures -- and what we can learn from them》挑選出雖然失敗、但能從中有所學習的IT專案，希望以此作為前車之鑑。

IBM / Stretch專案。Stretch是IBM在1956年替美國軍方的Los Alamos國家實驗室研發打造的超級電腦專案代號，目標是希望建構出世界第一部且最快的電晶體超級電腦，五年後所完成的產品為7030。若檢視Stretch專案當初所訂的目標，這是失敗的專案：執行速度未達要求、成本過高。但這個專案引進了包括我們現在熟悉的管線、記憶體保護等相當多的處理器技術，對業界很有價值。

Knight-Ridder / Viewtron服務。有時候走在太前端也不見得是好事；Knight-Ridder在1983年推出的Viewtron服務，如果晚個15到20年推出，應該會更獲好評。Viewtron是一套透過電腦接收資訊的家用服務系統，提供轉帳及購物服務，並能傳送新聞及廣告資訊。但可惜的是，這套服務在當時未能獲得太大的迴響。

加州及華盛頓州政府 / DMV專案。加州及華盛頓州政府在1990年代各自試著將汽機車監理業務電腦化，但卻在花費千萬美元公帑之後鎩羽而歸、放棄專案。兩個州政府的專案同樣面臨不斷追加預算的問題，然而錢並非萬靈丹，這兩個專案的共同教訓是，如果專案很明顯的注定會失敗，苦撐不如盡快終止。

FoxMeyer / ERP系統。1993年，全美第4大藥品經銷通路商FoxMeyer總共斥資上億美元，選擇以思愛普的產品，並透過安達信管理顧問公司協助系統整合，原欲導入ERP及倉儲自動化系統。原本的專案目標是希望新系統每年能節省4千萬美元，但萬萬沒想到反而使得FoxMeyer破產倒閉，而FoxMeyer也決定控告這兩家公司。雖然此案當中沒有人想要搞垮FoxMeyer公司，但參與專案的人是不是真能完成、並讓系統上線，卻是值得玩味。

蘋果 / Copland專案。Copland是蘋果內部於1994年開始研發的作業系統專案代號，原本是被寄予對抗Windows 95的Mac System 8。但或許是因為被賦予過度的期望，Copland的功能越加越多，也就是feature creep；功能過多的軟體專案，常會因為做不完、做不出來而「肥死」。Copland最終雖然未能成為正式產品，而蘋果也在兩年之後停止了Copland專案，但開發Copland的過程所累積技術，對蘋果發展後續的作業系統--尤其是OS X，依然很有幫助。而話說回來，過多且失焦的功能常會變成專案的癌細胞，別讓專案偏離原本的目標。

Sainsbury / 倉儲自動化。Sainsbury是英國連鎖超市龍頭，在2003年於其物流中心啟用的自動化系統，卻發生嚴重的條碼讀取問題，雖然這家公司在2005年聲稱整套系統能如預期運作，但兩年之後，花費相當於2.6億美元的整個專案還是作廢了。錯誤的作法不會隨著時間而變得正確，多拖無益。

加拿大政府 / 槍枝登記系統。Electronic Data Systems和SHL Systemhouse從1997年6月開始替加拿大政府設計槍枝登記系統，原本預算2百萬美元，但最後竟然花了6億8千8百萬美元，而日後的維護費用也相當嚇人。問題類似：如果專案的範圍和規格不知節制的任意擴張，專案成本當然也得跟著擴張。

此外，美國聯邦調查局的Virtual Case File軟體專案、國土安全部門的虛擬邊界專案、人口普查部門的手持裝置採購案，都很可能步上失敗專案之路。相較於私人企業，政府部門的專案佔了這些專案的多數，這樣的結果看似政府部門的專案容易失敗，但嚴格來說，是因為公部門通常比私部門受到更多的監督，若有專案失敗，也比較難以遮掩。最重要的是，既然別人都已經寫下血淋淋的失敗記錄，我們更應該記取失敗的教訓，並且要避免再犯同樣或類似的錯誤。