專案失敗因子

Bernstein(1996)提到如果衡量專案成功的界定是錯誤的，並用數 字來代表專案管理者的感受，這可能是危險的舉動，因為衡量結果 可能是不合理的建議，也就是說，一直以來符合這些標準的因素可 能一直都是錯誤的。

Atkinson(1999)定義專案失敗分為兩種類型，類型一是事情做錯，

例如規劃不良、估算不精確以及缺乏控制等；類型二是事情沒做、

做得不夠完整或者是可能已經完成，但是卻使用不完整的成功標準 來檢視。

舉例來說，建置一個購物網站，但因使用者需求定義不明，不 了解使用者操作流程，導致開發完成的網頁不好用，這是類型一所

23 

指的「事情做錯」；而購物網站根據使用者需求及使用流程完成網 頁開發，但因未多加考慮會員登入的其他方式，只提供一種會員登 入方式，這就是類型二所指的「事情做得不夠完整」。

Lyytinen & Hirchheim(1987)定義之資訊系統失敗主要包含四項 概念：

1. 規劃失敗：當系統的設計目標不符合使用者需求，系統就會 被認為是失敗的。人們普遍認為，系統設計的目標和要求，

可以預先定義清楚，但系統開發過程可能基於成本考量，以 致開發完成的系統不為使用者接受。

2. 過程失敗：未能於既定的預算與時間內完成開發也會導致資 訊系統失敗，常見的結果是當一個資訊系統的開發成本和時 間大量超支時，將直接否定該系統所帶來的利益。但其實這 類型的失敗原因是因為專案管理表現欠佳所造成。

3. 無替代性方案：大量被使用的系統不一定意味有高使用者滿 意度及系統績效佳，可能的原因是因沒有其他替代性方案可 選擇所致。

4. 期望失敗：系統無法滿足其利害關係者的要求或期望。不只 是系統無法提供合適的技術與規格，而是利害關係者的期望 值和實際情況之間存有差異。

Flowers(1996)定義當資訊系統發生下列情形時即代表系統是失 敗的：（1）系統整體運作效能不如預期般順暢；（2）使用者拒絕使 用或未充分利用；（3）系統開發成本超過系統折舊年限；（4）系統 複雜性太高或者是專案管理問題導致放棄開發。

Sauer(1993)提到資訊系統開發應有停損的機制，概念為當系統 因某些原因無法繼續完成開發，就因先中止進行，直到獲得相關資 源與支持後，再繼續完成開發，此方法反而有機會能支持系統的持 續運作。

Yeo(2002)認為資訊系統發生失敗的情形仍然十分廣泛，此現象 普遍存在於各行各業，資訊系統專案管理於理論與實際上仍有一段 差距需要學習，尤其是對於專案失敗的研究。Yeo 提出資訊專案失

24 

敗因子因素分析方法，嘗試用不同的研究方式試圖分析釐清資訊專 案中較易產生困擾的因素，尤其是專案管理領域。

研究結果顯示資訊專案失敗因子的前十項主要因素包含有：（1）

專案規劃；（2）企業文化；（3）專案管理與管控；（4）業務流程與 系統設計；（5）資訊系統專業人員；（6）資訊技術；（7）使用者；

（8）主辦管理；（9）政策及（10）商業規劃。

黃茂榮（民 98）提出專案不成功的原因，除了在開發導入階段 的執行過程，未能善於應用PMBOK^® Guide 提出的九大知識領域與 五大流程外，在專案成案之前的機會登錄階段與競標與簽約階段可 能就已經鑄下不可挽救的專案失敗因子。

Standish Group(1995)報告中提到，83.8％的軟體開發專案是失 敗的，失敗的原因主要包含兩種類型：（1）專案已完成並持續營運，

但超出預算及原訂完成時間，並提供與原先規定較少的功能，此類 型佔52.7％；（2）專案於執行過程中被取消，約佔 31.1％。該報告 提出專案失敗主要原因包含以下幾點：

1.需求不完整，約佔 13.1%。

2.缺乏用戶參與，約佔 12.4%。

3.缺乏資源，約佔 10.6%。

4.不切實際的期望，約佔 9.9%。

5.缺乏行政支持，約佔 9.3%。

6.需求及規格不斷變更，約佔 8.7%。

7.缺乏規劃，約佔 8.1%。

8.不再需要，約佔 7.5%。

9.缺乏專案管理，約佔 6.2%。

10.技術能力不佳，約佔 4.3%。

11.其他，約佔 9.9%。

McConnell(1996)提到專案經典失誤（Classic Mistakes），意指一 些無效的專案管理作法經常被人們使用且可預期會得到壞的結果，

25 

這就可稱為是經典失誤。McConnell 將專案經典失誤分為四大類型，

分別是人員、程序、產品及技術四大類，分別說明如表2.7：

表2.7 專案經典失誤因子

類別 主要失誤原因

人員 1. 破壞的動機比生產效率和品質影響更大，可能影響團 隊成員之間的工作關係。

2. 最常見的抱怨為專案領導人被抱怨害怕處理問題員 工。

3. 在專案快結束時增加新的團隊成員，猶如火上加油。

程序 1. 於專案初期花費太多時間確認需求，以致壓縮後續專 案的執行時程。

2. 對於專案開發時程評估過於樂觀，導致執行壓力大。

3. 風險管理能力不足。

4. 外包廠商越多專案風險越大。

產品 1. 產品添加不必要的功能與設計。

2. 產品功能差異性超過 25%，增加開發複雜性。

3. 開發人員著迷於開發新技術，而不顧市場真正需求。

4. 研究導向的發展使失敗的風險增加。

技術 1. 選錯技術。

2. 花費太多時間學習新技術與作法。

3. 技術升級所造成的問題削減新技術帶來的好處。

資料來源：本研究整理。

Nelson(2007)延續 McConnell(1996)對於專案經典失誤類型的定 義，調查1999-2006 年間共 99 個資訊專案發生失誤的原因，研究結 果發現：

1. 專案經典失誤主要包含：（1）過程中的失誤，約佔 45%；（2）人 的失誤，約佔43%；（3）產品的失誤，約佔 8%及（4）技術失誤，

約佔 4%。這說明技術很少成為專案失敗的原因，而且專案經理 應該首先留意管理流程與人。

26 

2. 專案範圍變更沒有在十大錯誤排名之內，主要在於專案經理能夠 掌握變更並且處理與聯繫；而研究結果也發現近幾年承包商失敗 造成專案錯誤的情況日益提升。

3. 最主要的專案失誤發生在專案驗收審查階段，表示如果專案經理 能將注意力集中在更好的專案檢核調度、利害關係人管理和風險 管理，就能提供專案成功機率。

Nelson(2007)也提出七項避免專案失誤的最佳作法，若能將這些 技術與概念運用得當，將有助於避免產生專案失誤，七項作法包含：

（1）避免不足的評估及調度能力；（2）避免無效的利害關係人管 理；（3）避免無效的風險管理：如系統開發的複雜性增加，風險數 量及嚴重程度就會增加；（4）避免無意義的專案規劃；（5）避免無 法達成的品質保證；（6）避免能力不足的專案成員或團隊；（7）避 免無效的專案支持：獲得高階主管支持一直以來是專案成功的重要 因素。

綜合上述諸位專家學者之論點，彙整專案失敗因子定義如表 2.8。

本研究所定義之專案失敗因子包含『需求不完整』、『缺乏使用者參 與』、『缺乏資源』、『缺乏行政支持』、『缺乏辨識風險能力』、『技術 能力不佳』、『採購能力不佳』、『管理不佳』、『未執行品質保證』、『預 算超支』及『不切實際的期望』。

27 

表2.8 專案失敗因子定義一覽表 相關研究 年份 提出之看法或定義

Lyytinen & Hirchheim 1987 資訊系統失敗主要包含四項概念：規劃失 敗、過程失敗、無替代性方案及期望失敗。

Standish Group 1995

專案失敗主要包含兩種類型：

Flowers 1996

資訊系統發生下列情形即代表失敗：

McConnell 1996 專案經典失誤分為四大類型，分別是人 員、過程、產品及技術四大類。

Atkinson 1999

專案失敗分為兩種類型，類型一是事情做

28