國 立 交 通 大 學
管理學院（運輸物流學程）碩士班
碩士論文
題目：以專案團隊及業主觀點探討資訊專案失敗因子
Exploring Failure Factors of Information Projects from
Perspectives of Project Team and Client
研 究 生：洪雅鈴
指導教授：馮正民 教授
康照宗 教授
中華民國一二年六月
以專案團隊及業主觀點探討資訊專案失敗因子
Exploring Failure Factors of Information Projects from Perspectives
of Project Team and Client
研 究 生 ： 洪雅鈴 Student: Ya-Ling Hung 指導教授 ： 馮正民 教授 Advisor: Dr. Cheng-Min Feng
康照宗 教授 Advisor: Dr. Chao-Chung Kang
國 立 交 通 大 學
管理學院（運輸物流學程）碩士班
碩 士 論 文
A Thesis
Submitted to Degree Program of Transportation and Logistics College of Management
National Chiao Tung University in Partial Fulfillment of the Requirements
for the Degree of Master of Science
in
Transportation and Logistics June 2013
Taipei, Taiwan, Republic of China
中華民國一二年六月
i
以專案團隊及業主觀點探討資訊專案失敗因子
研究生：洪雅鈴 指導教授：馮正民、康照宗 教授 國立交通大學管理學院（運輸物流學程）碩士班摘要
專案失敗是經常發生的，包含專案規模日益擴大、專案複雜度提升、 開發團隊愈趨分散，以及未於專案執行結束後進行檢討與改善等原因，導 致專案失敗層出不窮一直發生。依據前人的專案建置成功經驗，照著做專 案不一定同樣成功，但若未記取教訓，避免前人的失敗經驗，那麼一定會 造成專案失敗。本研究目的主要包含：（一）探究不同的專案角色及服務 年資對於「專案驗收通過」及實際執行時「發生的頻率」是否有看法差異； （二）利用已完成驗收之案例進行判別分析，提出專案驗收通過之判別方 法。經由 ANOVA 分析結果得知高階主管及業主認為管理不佳對於專案驗 收通過之影響程度具有顯著差異，同時，專案管理過程中一旦發生『需求 不完整』或是『缺乏使用者參與』的情形，將造成專案較大的損失，須優 先重視；另由判別分析可得知專案以低價得標、專案性質屬新建置案以及 專案金額為新台幣一百萬元以內可能導致專案驗收不通過。最後，本研究 提出專案管理五大避險策略，包含「避免專案需求不完整」、「避免專案 資源不足」、「避免管理不佳」、「避免缺乏使用者參與」以及「避免技 術能力不佳」，可作為實務上專案管理之參考。 關鍵詞：專案失敗因子、利害關係人、單因子變異數分析、判別分析II
Exploring Failure Factors of Information Projects from
Perspectives of Project Team and Client
Student: Ya-Ling Hung Advisors: Dr. Cheng-Min Feng, Dr. Chao-Chung Kang
Degree Program of Transportation and Logistics College of Management
National Chiao Tung University
ABSTRACT
Project failure is a common phenomenon. The factors including the increased size and complexity of the project, dispersed development teams, as well as the dislodged improvement reviews at the end of project execution contribute to an endless stream of project failure. Based on previous project paradigms, a new project does not necessarily experience an equally successful consequence. If a project does not follow the previous lessons to avoid project failure, it will destine to failure for sure.
The objectives of this study include: (a) exploring the relationship between roles played by project team and service period accrued from previous experience with respect to "project acceptance" and "frequency of failure occurrence at the practical implementation"; (b) using the complete project acceptance as the models for discriminant analysis. Through ANOVA analysis, it reveals that project executives and clients agree upon the poor project management contributing a significant impact to the project acceptance. Whenever the existence of "incomplete demands" or "dislodged user participation" results in a greater loss during the project management process, project team shall give high attention.
III
The discriminant analysis learned that the low bided projects, ad hoc nature of the projects and the new build projects amounted between NT$ 100,000 and NT$ 1million may lead to dissatisfied project acceptance. Finally, this study proposes that five project management hedging strategies including "avoidance of incomplete project requirements", "avoidance of insufficient resources", "avoidance of poor management", "avoidance of dislodged user participation", and "avoidance of poor technical capacity" can be used as a reference for project management practice.
Keywords: Project Failure Factor, Stakeholders, ANOVA, Discriminant Analysis
IV
誌謝
能在交大完成在職進修的歷練，真是人生中一段難忘的旅程。兩 年多前懷著尚未出生的小寶寶一起征戰交大考場，開學時正是品樂小 寶貝即將誕生的時候，就這樣展開在職進修及新手媽媽的生活！兼顧 工作、求學與照顧家庭的生活非常的緊湊，充滿未知與挑戰，隨著論 文即將完成的此刻，這一切的辛苦都化成甜美的果實，值得好好品嚐。 本論文得以順利完成，非常感謝恩師馮正民教授及康照宗教授兩 位教授給予學生的諸多指導，在學生對於研究方向舉棋不定時，兩位 教授給予關鍵的觀念啟發與建議，並以無比的耐心協助指正研究之缺 失，使本論文至臻完備，在此致上由衷的感激與敬意。論文口試審查 時，承蒙王榮祖教授與黃昱凱教授撥冗審閱本論文，指正本論文疏失 之處並惠賜諸多寶貴意見，對此表達誠摯的謝意。 求學期間，感謝交通運輸研究所全體教授給予學生諸多寶貴的知 識學問，並傳達最重要的自主研究精神，使學生於學業及工作上都獲 益良多。同時也要感謝何姐這兩年來給予的協助，讓我的求學生活得 以順利進展。最重要的是這兩年來一起求學、玩樂的交研所運輸物流 學程100 級的全體同學們，謝謝大家對於班上事務的用心安排及同學 間感情聯繫，讓我們共同留下許多美好的回憶。特別感謝靖侖、心如 及欣如這三位經常一起同組奮戰交報告的戰友們，有你們的協助才能 讓每一堂課都安然過關；還要特別感謝論文寫作期間威達、琡婷學姊、 維彬學長、育輝學長以及好朋友暉慈的關心叮嚀與指導，論文寫作過 程總有一股暖流湧上心頭。 最後，謝謝媽媽明智果斷的安排小寶貝的托育生活以及姊姊們的 分憂解勞；謝謝舅媽這兩年來對於小寶貝無微不至的照顧；還要謝謝 最親愛的老公永智在我週末念書及準備考試、寫論文的時候，能夠一 肩擔起照顧小寶貝的責任；謝謝您們的全力支持，使我能全心全意完 成學業，我愛您們！ 洪雅鈴 謹誌於 國立交通大學管理學院 （運輸物流學程）碩士班 中華民國102 年 6 月v
目錄
目錄 ... v 表目錄 ... viii 圖目錄 ... x 第一章 緒論 ... 1 1.1 研究背景與動機 ... 1 1.2 研究目的 ... 2 1.3 研究範圍 ... 2 1.4 研究流程 ... 3 第二章 文獻探討 ... 5 2.1 專案管理 ... 5 2.1.1 專案管理定義 ... 5 2.1.2 專案經理 ... 13 2.1.3 利害關係人 ... 13 2.1.4 資訊專案特性 ... 15 2.2 專案成功的界定 ... 17 2.3 專案失敗因子 ... 22 2.4 政府採購法 ... 28 2.4.1 採購標的 ... 28 2.4.2 招標金額級距 ... 29 2.4.3 招標方式 ... 29 2.4.4 決標原則及決標方式 ... 30 2.5 文獻探討小結 ... 31 第三章 研究方法 ... 33 3.1 研究架構 ... 33 3.2 研究設計 ... 35vi 3.2.1 問卷設計與尺度衡量 ... 35 3.2.2 問卷對象 ... 36 3.2.3 問卷內容 ... 36 3.2.4 專案成功與失敗判別分析案例來源 ... 39 3.3 統計分析方法與應用 ... 40 3.3.1 描述性統計 ... 40 3.3.2 影響程度-發生頻率分析矩陣 ... 40 3.3.3 單因子變異數分析 ... 43 3.3.4 專案成功與失敗判別分析 ... 43 第四章 研究結果與管理實務意涵 ... 47 4.1 基本資料統計 ... 47 4.1.1 專案角色 ... 47 4.1.2 專案服務年資 ... 56 4.1.3 專案失敗因子影響專案驗收通過程度及實際發生頻率統計65 4.2 影響程度-發生頻率分析矩陣 ... 73 4.3 單因子變異數分析 ... 75 4.3.1 不同專案角色對於「專案驗收通過」影響程度 ANOVA 分析 ... 76 4.3.2 不同專案角色對於實際執行時「發生頻率」ANOVA 分析 82 4.3.3 不同服務年資對於「專案驗收通過」影響程度 ANOVA 分析 ... 89 4.3.4 不同服務年資對於實際執行時「發生頻率」ANOVA 分析 91 4.4 專案成功與失敗判別分析 ... 93 4.5 管理實務意涵 ... 100 4.5.1 專案利害關係人對於專案失敗因子之看法 ... 100 4.5.2 專案成功與失敗判別 ... 101 4.5.3 專案管理避險策略 ... 102 第五章 結論與建議 ... 104 5.1 研究結論 ... 104
vii 5.2 研究建議 ... 105 參考文獻 ... 106 附錄一 ... 110
viii
表目錄
表2.1PMBOK®GUIDE九大知識領域及四十二項子流程特徵說明 ... 7 表2.2 專案管理流程群組與知識領域之對照 ... 11 表2.3 國內外相關研究對利害關係人定義一覽表 ... 15 表2.4 專案成功的界定 ... 19 表2.5 專案績效差距級別 ... 20 表2.6 專案成功之界定一覽表 ... 21 表2.7 專案經典失誤因子 ... 25 表2.8 專案失敗因子定義一覽表 ... 27 表2.9 採購金額級距類別說明 ... 29 表3.1 問卷預試修正建議彙整 ... 37 表3.2 定稿問卷衡量構面來源一覽表 ... 38 表3.3 定稿問卷基本資料題項 ... 39 表3.4 預測正確與錯誤分類表 ... 46 表4.1 基本資料統計概況－專案角色 ... 47 表4.2 不同專案角色對於「專案驗收通過」描述性統計 ... 48 表4.3 不同專案角色對於實際執行時「發生頻率」描述性統計 ... 52 表4.4 基本資料統計概況－專案服務年資 ... 56 表4.5 不同服務年資對於「專案驗收通過」描述性統計 ... 57 表4.6 不同服務年資對於實際執行時「發生頻率」描述性統計 ... 61 表4.7 影響「專案驗收通過」之整體統計排序 ... 68 表4.8 實際執行時「發生的頻率」之整體統計排序 ... 72 表4.9 「專案驗收通過」之影響程度與實際執行時「發生頻率」之排名 . 73 表4.10 專案失敗因子損失程度排名 ... 75 表4.11 不同專案角色－專案驗收通過影響程度排名 ... 76 表4.12 不同專案角色－專案驗收通過影響程度同質性檢定 ... 78 表 4.13 不同專案角色－專案驗收通過影響程度 ANOVA 分析 ... 79 表4.14『管理不佳』影響專案驗收通過程度之事後檢定 ... 80 表4.15『不切實際的期望』影響專案驗收通過程度之事後檢定 ... 81 表4.16 不同專案角色－實際執行發生頻率排名 ... 82 表 4.17 不同專案角色－實際執行發生頻率同質性檢定 ... 84 表4.18 不同專案角色－實際執行發生頻率ANOVA 分析 ... 85 表 4.19『缺乏資源』於實際執行時之「發生的頻率」事後檢定 ... 86 表 4.20『技術能力不佳』於實際執行時之「發生的頻率」事後檢定 ... 87 表 4.21『未執行品質保證』於實際執行時之「發生的頻率」事後檢定 .... 88ix 表4.22 不同服務年資－專案驗收通過影響程度同質性檢定 ... 89 表 4.23 不同服務年資－專案驗收通過影響程度 ANOVA 分析 ... 90 表4.24 不同服務年資－實際執行時發生頻率同質性檢定 ... 91 表4.25 不同服務年資－實際執行時發生頻率ANOVA 分析 ... 92 表4.26 案例屬性分類 ... 93 表4.27 案例屬性統計 ... 94 表4.28BOX’S M 共變數矩陣相等性檢定結果 ... 95 表4.29 典型判別函數摘要表 ... 95 表4.30WILKS’LAMBDA值 ... 96 表4.31 標準化的典型判別函數係數 ... 96 表4.32 結構矩陣 ... 97 表4.33 各組重心的函數 ... 97 表4.34 組別的事前機率 ... 98 表4.35FISHER'S線性判別函數之分類函數係數 ... 98 表4.36 分類結果 ... 99 表4.37 預測值 ... 99
x
圖目錄
圖1.1 研究流程 ... 4 圖2.1 專案利害關係人 ... 14 圖2.2 專案管理鐵三角 ... 18 圖2.3THE SQUARE ROUTE ... 18 圖3.1 研究架構圖 ... 34 圖3.2 資料分析步驟 ... 35 圖3.3 重要性與滿意程度矩陣 ... 42 圖3.4 影響程度－發生頻率分析矩陣 ... 43 圖4.1 衡量構面影響「專案驗收通過」程度之統計量表 ... 66 圖4.2 影響「專案驗收通過」的程度統計 ... 68 圖4.3 衡量構面於實際執行時「發生頻率」之統計量表 ... 70 圖4.4 實際執行時「發生的頻率」之統計 ... 72 圖4.5 影響程度－發生頻率分析矩陣 ... 741
第一章 緒論
1.1 研究背景與動機
如果人們相信可以從錯誤中學習實戰經驗，也相信統計數據表 示有三分之一的專案執行結果最後是失敗的，那麼公司組織必須要 培養如同軍隊規模般大小的專案管理團隊才能使專案順利運作 (Nelson, 2007)。依據前人的專案建置成功經驗，照著做不一定能同 樣使得專案成功，但若未記取前人的專案失敗經驗，採取避險措施， 那麼一定會造成專案失敗。專案失敗是經常發生的，包含專案規模 日益擴大、專案複雜度提升、開發團隊愈趨分散，以及未於專案執 行結束後進行檢討與改善等原因，導致專案失敗層出不窮一直發 生。 眾多中外專家學者同意時間、成本及品質是構成專案成功的最 基本要素(Oilsen, 1970)，但專案經理有時會做出明知故犯造成專案 失敗的行為，如低價搶標造成專案超支或是配合公司政策執行高風 險專案。此外專案成功和失敗是難以界定及衡量的，因為不同的人 有不同的看法(Thomas & Fernàndez, 2008)。專案經理人想知道到底 哪裡出了問題，以便能避免類似的錯誤再次發生(Nelson, 2007)，才 能於專案執行過程中降低風險及損失，提高專案成功機率。 專案管理是一種暫時性的組織與努力，經由事先確認的時間、 資源及履約條件，以創造出一項獨一無二的產品、服務或結果。這 表示專案管理是少數、特殊且臨時性的工作，較難以套用標準作業 流程來提供服務；同時這也是複製性低的工作，只有部分的專案產 出及建置成果能重製使用。專案管理技巧尤其是最關鍵的一環，一 旦管理不佳，就會面臨有形無形的風險，使得專案結果失敗。 為使專案成功，關鍵之靈魂人物－專案經理必須應用各項知識 領域與流程、確認專案目標、掌握專案現況與客戶需求、控制專案 風險及精準估計專案所需資源，配合有效的風險管理及進度追蹤管2 控，適時採取改善措施，並且掌握專案失敗因子，避開風險，提高 專案成功機率。 基於上述研究背景，本研究動機為綜整文獻所提出之專案失敗 因子，探討專案失敗因子對於專案驗收通過的影響程度以及於實際 執行時的發生頻率。同時，藉由分析已結案的資訊專案，進行案例 屬性統計分類及研究分析，找出專案成功或失敗的判別方法，提供 組織作為後續評估是否執行同質性專案之參考依據。
1.2 研究目的
綜合上述研究背景及動機，本研究目的試圖探究資訊專案失敗 因子對於「專案驗收通過」的影響程度及其於實際執行時所「發生 的頻率」，採用文獻探討、PMBOK® Guide 九大知識領域流程定義及 深度專家訪談等方式，收集專案失敗因子；使用問卷調查方式對專 案利害關係人進行專家問卷調查，了解不同的專案角色對於「專案 驗收通過」及實際執行時「發生的頻率」是否有看法差異以提出管 理實務意涵；並且針對本研究所收集的已結案案例，進行統計分類 及判別分析，提出專案成功與失敗判別方法；最後提出本研究之結 論。1.3 研究範圍
本文的研究範圍界定如下： 1. 專案失敗因子：因各產業特性不同而有差異，本研究是以國內外 歷史文獻所提出關於專案成功的界定、專案失敗因子定義及看法， 集結而成本研究所探討的資訊專案失敗因子進行探討。 2. 專案類型：現今各行各業資訊化程度很高，各類型資訊專案普遍 應用產業中，本研究所收集之專案案例不限制產業類別，主要探 討各產業中的資訊整合型專案。 3. 案例來源：案例係採用民國 96 至 100 年間，公告於政府電子採 購 網(http://web.pcc.gov.tw/pis/main/pis/client/index.do) 之 招 標 公 告案例，案例類型屬於整合軟體、硬體及通訊之資訊整合型專案， 並且已完成驗收結案。3 4. 不同的成員對於專案成功或失敗有不同的看法，本研究主要探討 之專案利害關係人包含專案經理、專案成員、業主、高階主管及 顧問專家。 5. 本研究係以 PMBOK® Guide 九大知識領域與四十二項子流程中 所定義之專案執行流程，經由專家訪談從子流程中挑選較關鍵的 項目，以此作為探討專案失敗因子的依據，研究分析並未涵蓋 PMBOK® Guide 所有流程。
1.4 研究流程
研究流程共分成五章。第一章為緒論，說明本文之研究背景與 動機、研究目的、研究範圍與研究流程。 第二章為文獻探討，共分成五小節，依據研究動機與目的，探 討專案管理、專案成功的界定、專案失敗因子及政府採購法等相關 文獻作為研究之基礎，並提出文獻探討小結。 第三章為研究方法，共分成三小節： 1. 研究架構：確立本研究之研究範圍及研究架構。 2. 研究設計：本研究使用問卷調查法探討專案失敗因子對於「專案 驗收通過」的影響程度及實際執行時「發生頻率」。本小節說明 問卷設計與尺度衡量、問卷對象、問卷內容及調查方式。 3. 統計分析方法與應用：本研究之資料以 SPSS 統計軟體進行分析， 使用描述性統計（Descriptive-Statistics）分析問卷基本資料、影 響程度－發生頻率分析矩陣（Degree of Influence – Frequency Analysis），探討專案失敗因子對於專案驗收通過的影響程度以及 於實際執行時發生的頻率、單因子變異數分（One-Way ANOVA Analysis ） 以 及 專 案 成 功 與 失 敗 判 別 分 析 （ Discriminant Analysis）。 第四章為研究結果與管理實務意涵，依已收集之案例及專家問 卷調查結果進行統計分類，提出研究結果及管理實務意涵。 第五章為結論與建議，依研究結果進行結論與就研究過程中之 限制與未來後續可能研究方向提出建議，完成本研究論文。4
本研究之研究流程如圖1.1 所示。
圖 1.1 研究流程
資料來源：本研究整理。
5
第二章 文獻探討
本章節主要由五個部分所構成，首先探討專案管理的定義及特性， 介紹本研究採用之專案管理來源依據，包含 PMBOK®專案管理知識體所 定義五大流程群組、九大知識領域及專家學者之論述；其次，針對專案 成功的界定加以歸納說明；再者，探討專案失敗因子作為本研究專家問 卷調查之問項；第四，整理政府採購法之相關規定作為本研究案例屬性 分類之參考依據；最後針對文獻探討進行小結。2.1 專案管理
2.1.1 專案管理定義
Oisen(1950)提到專案管理是應用工具和技術的集合，在時間、 成本與品質的限制下，使用多種資源完成一項獨特、複雜的任務， 每項任務需要不同的工具及技術，以便適應任務環境及任務目標。 英國專案管理標準BS6079(1996)對於專案管理的定義為：規劃、 監測與控制專案的各個面向，包含如期、符合預算、品質與績效， 以達成專案目標。 Reiss(1993)提到專案是在時間限制下，為實現明確目標的一項 活動，專案管理無法用簡單的描述來形容，必須結合規劃、變更機 制及管理。Lock(1994)認為現今的專案管理為因應現代化工業和複 雜的商業活動，需要更多的計劃、協調和控制。 Burke(1993)則認為專案管理是一個專業的管理技術，為了在強 大的單一責任制度下進行計劃與控制。Turner(1996)進一步指出，專 案管理可以被描述為：「將願景變為實際的藝術和科學」。根據PMBOK®（專案管理知識體指南，PMBOK® Guide）定義， 專案是一種暫時性的努力以創造出一項獨一無二的產品、服務或結 果，專案暫時性的本質係指它有一個明確的開始和結束。當專案的
6 目標已經達成，或專案目標將難以達成而被中止，或已不復存在， 就是專案的終止時刻。專案可以產生一項產品，它可以是最終品項 本身，或是其他產品的零組件；也可以是一種提供服務的能力或一 項結果就如一個產出或文件。雖然在相同的專案內可能出現重覆的 要素，但該重覆性並不會改變專案工作基本的獨特性。舉例來說， 許多公司都需要人事差勤系統，也為同一個資訊團隊所開發，但因 導入公司的企業文化及作業規定有所不同，就會產生不同的系統操 作流程、網路架構及使用者介面等（熊培霖等，民 98）。 根據PMBOK®定義，專案管理是應用知識、技能、工具和技術 於專案活動上，以符合專案之需求。專案管理是透過適當的應用與 整合包含於五大流程群組內之專案管理流程來完成。此五大流程群 組為起始、規劃、執行、監視控制及結束流程，說明如下：
1. 起始流程群組（Initiating Process Group）：
經由獲准開始專案或階段，以定義一個新專案或現存專案的一 個新階段等所要執行的系列流程。
2. 規劃流程群組（Planning Process Group）：
建立專案範疇、再定義專案目標及界定行動方針，以達成專案 承諾要達到的目標等所需執行的系列流程。
3. 執行流程群組（Executing Process Group）：
執行完成專案管理計畫書所界定之工作，以滿足專案的規格所 要執行的系列流程。
4. 控制流程群組（Controlling Process Group）：
追蹤、檢討並調整專案的進度與績效，辨識計畫內需要變更的 任何部分，並啟動相對應之變更等所需執行的系列流程。 5. 結案流程群組（Closing Process Group）：
完成橫跨所有專案管理流程群組的活動，以正式結束專案或階 段所需執行的系列流程。
五大流程群組適用於一個專案中的每一個階段；另PMBOK®中 所定義之九大知識領域，包含：整合管理、範疇管理、時間管理、
7 成本管理、品質管理、人力管理、溝通管理、風險管理及採購管理， 再細分為四十二項子流程，定義如表2.1。 表 2.1 PMBOK® Guide 九大知識領域及四十二項子流程特徵說明 群組/知識領域/子流程 子流程說明 I. 起 始 流 程 群 組 I.4 整合管 理 I.4.1 發展專案章程 發展出一份正式核准一個專案或階段 成立的文件，並書面記錄滿足利害關係 者需要與期許的初步需求。 I.10 溝通管 理 I.10.1 辨識利害關係人 辨識所有受專案影響的個人或組織，並 記載他們相關的利益、參與及影響專案 成功等相關訊息。 II. 規 劃 流 程 群 組 II.4 整合管 理 II.4.2 發展專案管理計 畫 書面記錄用以定義、準備、整合與協調 各附屬管理計畫書等所需活動。 II.5 範疇管 理 II.5.1 蒐集需求 定義及記錄符合專案目標利害關係者 （贊助人、顧客或其他利害關係者）之 需求。 II.5.2 定義範疇 發展出一份對專案與產品詳盡描述的 聲明。 II.5.3 建立工作分解結 構 將專案交付標的與工作分解為更小、更 容易管理。 II.6 時間管 理 II.6.1 定義活動 辨識為產出專案的交付標的所需執行 的特定行動。 II.6.2 排序活動 辨識及記錄所有專案活動間的關係。 II.6.3 估算活動資源 估計執行各項活動所需材料、人員、設 備或供應品之類型及數量。 II.6.4 估算活動期程 估計在預估的資源內完成個別活動所 需的工期數。 II.6.5 發展排程計畫 分析活動順序、工期、資源需求與時程 限制條件等以建立專案時程。 資料來源：PMBOK® Guide,2008、本研究整理。
8 表2.1 PMBOK® Guide 九大知識領域及四十二項子流程特徵說明（續一） 群組/知識領域/子流程 子流程說明 II. 規 劃 流 程 群 組 II.7 成本管 理 II.7.1 估算成本 發展出完成專案活動所需財務資源之 估算。 II.7.2 決定預算 彙總所有個別活動或工作包所預估之 成本，以建立被核准的成本基準。 II.8 品質管 理 II.8.1 規劃品質 辨識專案與產品的品質需求及／或標 準，並記錄專案將如何展示其品質符合 程度。 II.9 人力資 源管理 II.9.1 發展人力資源計 畫 辨識及記錄專案角色、責任、所需技能 與報告關係，並發展出用人管理計畫 書。 II.10 溝通管 理 II.10.2 規劃溝通 決定專案利害關係者資訊的需要並定 義一種溝通方式。 II.11 風險管 理 II.11.1 規劃風險管理 定義如何對一個專案實施風險管理活 動。 II.11.2 辨識風險 決定什麼風險會影響專案並記載它們 的特性。 II.11.3 執行定性風險分 析 經由評估並結合風險發生的機率與衝 擊來排定風險優先等級，以供進一步的 分析與行動。 II.11.4 執行定量風險分 析 數值化分析所辨識出的風險對整體專 案目標產生影響的量化方法。 II.11.5 規劃風險回應 發展備選方案及行動，以增加達成專案 目標的機會並降低風險造成的威脅。 II.12 採 購管理 II.12.1 規劃採購 以文件記錄專案採購決策，訂定採購的 方式及辨識潛在賣方。 III. 執 行 流 程 群 組 III.4 整合管 理 III.4.3 指導及管理專案 執行 執行專案管理計畫書所定義之工作，以 達成專案目標。 III.8 品質管 理 III.8.2 執行品質保證 稽核品質需求與品質管制衡量的結 果，以確保使用合適的品質標準與作業 規範。 資料來源：PMBOK® Guide,2008、本研究整理。
9 表2.1 PMBOK® Guide 九大知識領域及四十二項子流程特徵說明（續二） 群組/知識領域/子流程 子流程說明 III. 執 行 流 程 群 組 III.9 人力資 源管理 III.9.2 獲得專案團隊 確定人力資源的可用性與獲得完成專 案指派任務所需團隊。 III.9.3 發展專案團隊 改善團隊成員的職能、團隊間的互動關 係及整體環境，以提升專案績效。 III.9.4 管理專案團隊 追蹤團隊成員績效，提供回饋、解決議 題，管理變更等使專案績效最佳化。 III.10 溝通管 理 III.10.3 發佈資訊 如計畫地提供相關可獲資訊給專案利 害關係者。 III.10.4 管理利害關係者 期望 與利害關係者溝通及共事以符合其需 要，並回應所發生議題。 III.12 採購管 理 III.12.2 執行採購 得到賣方回應、選擇賣方並授予其合 約。 IV. 監 控 流 程 群 組 IV.4 整合管 理 IV.4.4 監控專案工作 追蹤、審查及調整專案進度，以符合達 成專案管理計畫書所定義的績效目標。 IV.4.5 實施整合變更控 制 審查所有的變更申請、核准變更，並管 理交付標的、組織流程資產、專案文件 及專案管理計畫書等變更。 IV.5 範疇管 理 IV.5.4 驗證範疇 正式接受以完成專案交付標的，包括客 戶或贊助人審查交付標的，以確保專案 產出被正確的接受。 IV.5.5 控制範疇 監視專案與產品範疇現況並管理範疇 基準變更。 IV.6 時間管 理 IV.6.6 控制時程 監視專案現況以更新專案進度及管理 時程基準變更。 IV.7 成本管 理 IV.7.3 控制成本 監視專案狀況以更新專案預算及管理 成本基準變更。 IV.8 品質管 理 IV.8.3 執行品質管制 監視與紀錄執行品質活動的結果，以評 估其成效並建議必要變更。 資料來源：PMBOK® Guide,2008、本研究整理。
10 表2.1 PMBOK® Guide 九大知識領域及四十二項子流程特徵說明（續三） 群組/知識領域/子流程 子流程說明 IV. 監 控 流 程 群 組 IV.10 溝通管 理 IV.10.5 報告績效 蒐集與發佈包括現況報告、進度衡量及 預測值等績效資訊。 IV.11 風險管 理 IV.11.6 監控風險 為整個專案執行風險回應計畫、追蹤已 辨識風險、監視殘留風險、辨識新的風 險、以及評估風險流程的有效性。 IV.12 採購管 理 IV.12.3 管理採購 管理採購關係、監視履約成效及視需要 實施變更及改正。 V. 結 案 流 程 群 組 V.4 整合管 理 V.4.6 結束專案或階段 完成所有專案管理流程群組中所涉及 的全部活動，以正式結束該專案或階 段。 V.12 採購管 理 V.12.4 結束採購 完成每一項採購，涉及驗證所有工作及 交付標的是可以接受的。 資料來源：PMBOK® Guide,2008、本研究整理。 以專案管理流程群組為經、知識領域為緯，可以得知九大知識 領域對照五大專案管理流程群組所產生的四十二項服務子流程，以 五大知識領域進行分類包含下列服務子流程，專案管理流程群組與 知識領域對照如表2.2。 1. 整合管理：發展專案章程、發展專案管理計畫、指導及管理專案 執行、監控專案工作、實施整合變更控制、結束專案或階段。 2. 範疇管理：蒐集需求、定義範疇、建立工作分解結構、驗證範疇、 控制範疇。 3. 時間管理：定義活動、排序活動、估算活動資源、估算活動期程、 發展排程計畫、控制時程。 4. 成本管理：估算成本、決定預算、控制成本。 5. 品質管理：規劃品質、執行品質保證、執行品質控制。
11 6. 人力資源管理：發展人力資源計畫、建立專案團隊、發展專案團 隊、管理專案團隊。 7. 溝通管理：辨識利害關係人、規劃溝通、發佈資訊、管理利害關 係者期望、報告績效。 8. 風險管理：規劃風險管理、辨識風險、執行定性風險分析、執行 定量風險分析、規劃風險回應、監控風險。 9. 採購管理：規劃採購、執行採購、管理採購、結束採購。 表2.2 專案管理流程群組與知識領域之對照 知識領域 專案管理流程群組 起始流程 群組 規劃流程 群組 執行流程 群組 監控流程 群組 結案流程 群組 4.整合管 理 4.1 發展 專案章程 4.2 發展專案 管理計畫 4.3 指導及管 理專案執行 4.4 監控專 案工作 4.5 實施整 合變更控制 4.6 結束 專案或階 段 5.範疇管 理 5.1 蒐集需求 5.2 定義範疇 5.3 建立工作 分解結構 5.4 驗證範 疇 5.5 控制範 疇 6.時間管 理 6.1 定義活動 6.2 排序活動 6.3 估算活動 資源 6.4 估算活動 期程 6.5 發展排程 計畫 6.6 控制時 程 7.成本管 理 7.1 估算成本 7.2 決定預算 7.3 控制成 本 8.品質管 理 8.1 規劃品質 8.2 執行品質 保證 8.3 執行品 質控制 資料來源：PMBOK® Guide,2008、本研究整理。
12 表2.2 專案管理流程群組與知識領域之對照（續） 知識領域 專案管理流程群組 起始流程 群組 規劃流程 群組 執行流程 群組 監控流程 群組 結案流程 群組 9.人力資 源管理 9.1 發展人力 資源計畫 9.2 建立專案 團隊 9.3 發展專案 團隊 9.4 管理專案 團隊 10.溝通管 理 10.1 辨識 利害關係 人 10.2 規劃溝通 10.3 發佈資 訊 10.4 管理利 害關係者期 望 10.5 報告績 效 11.風險管 理 11.1 規劃風險 管理 11.2 辨識風險 11.3 執行定性 風險分析 11.4 執行定量 風險分析 11.5 規劃風險 回應 11.6 監控風 險 12.採購管 理 12.1 規劃採購 12.2 執行採 購 12.3 管理採 購 12.4 結束 採購 資料來源：PMBOK® Guide,2008、本研究整理。 根據文獻探討及歸納整理，本研究所定義之專案管理為：一種 暫時性的組織與努力，經由事先確認的時間、資源及履約條件，以 創造出一項獨一無二的產品、服務或結果。另本研究使用PMBOK® Guide 所定義之「辨識風險能力」、「執行採購」及「執行品質保證」 作為問卷調查衡量構面之參考。
13
2.1.2 專案經理
根據PMBOK® Guide 所定義，專案經理是由執行組織所指派以 達成專案目標的人。專案經理的角色與功能經理或業務經理有所不 同，一般而言功能經理專注在提供行政領域的管理監督；業務經理 則負責核心業務的一個面向；而專案經理需要彈性、良好的判斷、 強而有力的領導、談判技巧及扎實的專案管理實務知識。同時專案 經理也是負責與所有利害關係者，特別是指業主、專案團隊成員或 其他主要的利害關係者溝通的主角，具有核心地位。 成功的專案管理需要專案經理擁有以下的特質： 1. 知識：這是指專案經理所知道的專案管理。 2. 績效：這是指當專案經理應用他們的專案管理知識所能執行或完 成的事。 3. 個人能力：這是指在執行專案或相關活動時專案經理的行為表現， 個人的效力包括態度、核心的人格特質、以及領導-引導專案團 隊達成專案目標及平衡專案限制的能力。 Eric &Villiers(2003)也提到專案經理需整合專案的各個部分並 掌握過程，以確保所有要素（人、任務及組織單位等）能緊密結合 以共同達成專案目標。2.1.3 利害關係人
利害關係人理論（Stakeholder Theory）最早由 Freeman(1984)在 《Strategic Management: A Stakeholder Approach》一書中提出，他將 利害關係人的概念與理論帶入企業管理的領域內，根據他的定義， 「利害關係人」是指：在一個組織中會影響組織目標或被組織影響 的團體或個人。這是一個組織管理和商業道德的理論，用於解決組 織管理中的道德和價值問題。後續發展從公司的董事會成員、雇員 及社區代表等三方利害關係人的觀點來提出公司的經營策略。因此 從企業的觀點來看，一個企業除了注重股東的權益外，必需同時顧
14 及員工、顧客、社區以及所有與企業有關的個人或團體，以企業擁 有者為核心的一個同心圓，層層向外擴散。 Struckenbruck(1987)認為最主要的利害關係人包含四種類型：專 案經理、高階經理人、客戶及專案成員，其他的利害關係人則包含： 專案使用者、其他客戶或專案工作者等。 Mallak et al.(1991)提出專案實施後相關的利害關係人包括：專 案工作者（Workers Involved with the Projects）、企業部門／政府機 構（Corporate Division/Governmental Agency）、母公司／政府（Parent Corporation/Government ）、 客 戶 （ Customers ）、 供 應 商 （ Capital Suppliers ） 、 分 包 商 - 顧 問 或 該 項 目 的 貢 獻 者 （Subcontractors-Consultants, Contributors to the Project）、使用者 （Users of the Project ）、 主 管 部 門 和 監 管 機 構 （ Authorities & Regulatory Agencies）、特殊利益團體（Public Represented by the Media）、公共媒體（Special Interest Groups）、遊說者（Lobbyists） 以及非人類，指科學的環境和自然環境（Non-Human, Scientific Environment and the Natural Environment）。專案利害關係人整理如 圖2.1。
圖2.1 專案利害關係人
15 PMBOK® Guide 中提到利害關係人泛指所有和專案有關的人員， 意指積極參與專案或利益可能會因專案的成效或完成而受到正面 或負面影響的個人或組織（如顧客、贊助人、執行組織或社會大眾 等）。利害關係人可能會對整個專案、其交付標的及專案團隊成員 等運用其影響力。專案經理必須管理與專案需求相關之各種利害關 係人的影響力，以確保專案成功。 彙整國內外相關研究者對於利害關係人之定義整理如表2.3。 表2.3 國內外相關研究對利害關係人定義一覽表 相關研究 年份 提出之看法或定義 Freeman 1984 在一個組織中會影響組織目標或被組織影響 的團體或個人。 Struckenbruck 1987 最主要的利害關係人包含四種類型：專案經 理、高階主管、客戶及專案成員。 Mallak et al. 1991 利害關係人包括參與專案工作者、企業部門/ 政府機構、母公司/政府、客戶、資本的供應 商、分包商（顧問或該項目的貢獻者）、使用 者、主管部門和監管機構、公共媒體、特殊 利益代表的工人團體、遊說者及非人類，指 科學的環境和自然環境。 PMBOK® Guide 2008 利害關係人泛指所有和專案有關的人員，意 指積極參與專案或利益可能會因專案的成效 或完成而受到正面或負面影響的個人或組織 （如顧客、贊助人、執行組織或社會大眾 等）。 資料來源：本研究整理。 根據文獻探討及歸納整理，本研究主要探討之專案利害關係人 包括：專案經理、專案成員、業主、高階主管及顧問專家。
2.1.4 資訊專案特性
Brooks(1986)認為軟體開發專案較一般專案管理難度更高，在於 軟體開發專案是由許多彼此環環相扣的概念所組成的，包括：資料16 集合、各個資料項目之間的關聯性、演算法以及各種功能的執行。 這 樣 的 本 質 是 抽 象 的 ， 因 為 不 論 有 多 少 種 不 同 的 呈 現 方 式 （Representation），概念的構造都是不變的。然而，軟體開發卻必 須達到高度的精確性與極度地詳盡。軟體開發真正的困難，在於這 種抽象概念構造的規範制定、設計與測試，而非只是在於軟體開發 的呈現方式以及測試該呈現方式的精確程度。軟體開發工作區分為 本質性－源自於軟體本質，屬於與生俱來的困難，以及附屬性－伴 隨在製造過程中所產生的困難，也就是非與生俱來的部分。如果上 述的概念是事實，那麼軟體開發將永遠是累人的事，在先天上就注 定不會有銀彈（No Sliver Bullet）。銀彈意指一種終極武器，能夠有 效完成想要達成的目標，如有效降低軟體開發的成本等。 錢一一（民93）提到軟體開發大概是人類創作中最錯綜複雜的 東西（從組成各部份的類型數量來看）。軟體開發的問題源自於本 質上的複雜性，軟體的使用者越多，維護成本就越高，因為使用者 越多，所發現到的錯誤也就越多。實際上，軟體系統的開發工作不 是只有寫程式而已，這樣的工作僅佔軟體專案六分之一的時間，其 他時程規劃還包含三分之一進行系統規劃、四分之一進行元件測試 以及四分之一進行系統測試。資訊專案的特性大多包含軟體開發， 因此資訊專案管理過程除須完成本質性軟體開發工作，還須解決眾 多伴隨軟體開發而來的問題，導致資訊專案之管理較一般專案之管 理有更高的執行風險。 Brooks(1986)提到人月（Man-Month or Person-Month）是個危險 並很容易就遭到誤解的迷思，因為它假設人力和工時可以互換，使 專案經理誤把工作量和專案進度混為一談。而軟體開發專案進行不 順利的原因很多，絕大部分都是缺乏良好的時程規劃所致，但若是 在已經落後的軟體開發專案中增加人手，只會讓專案進度更加落後。 在絕大多數大型軟體系統的經驗顯示，投入大量人力進行軟體開發 是最耗成本、最慢、最沒有效率，同時做出來的系統在概念上也最 不完整，軟體開發進度是越到後期進展越慢，但對專案經理而言， 越到專案後期就越希望專案進展得快些。
17 綜整專家學者的論述，本研究提出資訊專案特性為須把抽象概 念具體化，且須整合環環相扣的複雜問題。同時，投入更多的人力 不一定能將專案提前完成，可能還因此讓專案進度更加落後。此外， 資訊專案管理過程除須完成本質性軟體開發工作，還須解決眾多伴 隨軟體開發而來的問題，導致資訊專案之管理較一般專案之管理有 更高的執行風險。
2.2 專案成功的界定
依據前人的專案成功經驗，照著做不一定能夠使得專案成功， 但若未記取前人的專案失敗經驗，採取避險措施，則一定會造成專 案失敗。過去學者對於專案成功的界定有諸多的探討與看法，以下 依序整理並說明。 Oisen(1970)提出成功的界定包含符合成本、時間與品質，幾乎 是界定專案成功的圭臬。Atkinson(1999)指出成本、時間以及品質為 專案管理鐵三角（The Iron Triangle），如圖 2.2，其他學者如 Morris & Hough(1987) 、 McCoy(1987) 、 Saarinen(1990) 、 Turner(1993) 、 Turner(1993)、Ballantine(1996)、deWit(1998)、Wateridge(1998)等眾 多學者都同意成本、時間與品質應作為成功的界定，但不包含全部。 Wright(1997)則降低衡量專案成功的要素，以客戶的觀點，認為滿足 時間及預算是最重要的兩項要素。18 圖2.2 專案管理鐵三角 資料來源：Atkinson(1999)。 Atkinson 亦提到可以作為衡量專案成功的其他界定包含有：系 統的技術實力，組織所獲得的好處以及更廣泛的利害關係者群體 （間接效益）的好處，並將這些衡量成功的界定稱為（The Square Route），如圖 2.3，The Square Route 之相關定義如表 2.4。
圖 2.3 The Square Route
19 表2.4 專案成功的界定 專案鐵三角 資訊系統 利益（組織） 利益（利害關係人） 成本 品質 時間 可維護性 可靠性 合法性 資訊品質 用途 提高效率 提高效益 利潤增加 戰略目標 組織學習 滿意的用戶 社會和環境影響 個人發展 專業學習及承辦利益 資本供應商、開發團隊及 周邊社區的經濟影響 資料來源：Atkinson(1999)、本研究整理。 Alter(1996)認為兩種達成專案成功的衡量界定是符合流程與達 成組織目標。DeLone et al. (1992) 定義了六項衡量系統成功的因素， 包括：系統品質、資訊品質、服務品質、使用率、使用者滿意度及 淨效益。Gatian(1994)主張以用戶滿意度作為一個衡量成功的界定。 Saarinen(1990)認為使用率是一個專案成功的必要條件。
Pinto and Slevin(1988)認為專案成功的界定共有六項，包含：（1） 預算；（2）時間；（3）績效水準；（4）技術有效性；（5）組織有效 性（符合利害關係人之期待）及（6）組織效能（專案成果）。 Wateridge(1998)提出對資訊專案而言，成功不是一個非黑即白 的概念。雖然資訊專案失敗是很普遍的現象，但也沒有共同商定對 於成功或失敗的定義。專案成功的界定除了時間、成本及品質，還 應加上公司利益及商業化成功，包含： 1.專案有利於主辦者、所有者與承包商； 2.專案達成企業目標的三個方法（策略、技術、運作）； 3.專案吻合原先定義目標； 4.專案吻合品質門檻； 5.專案產品能吻合規範、預算與履約期限及 6.全部參與者在專案過程與對產出結果是愉快的。
20
Thomas & Fernàndez (2008) 提出專案成功與失敗是難以界定及 衡量的，因為不同的人有不同的看法，而且成功如何定義以及由誰 評估成功，會影響到最終對於專案成功與失敗的判斷。一般公司對 於成功的界定除了如期、如預算，還包括利益輸送、滿足業務目標 和業務連續性。此外，一些甚少在文獻中被提到的成功界定還包含： 贊助商滿意度、專案團隊的滿意度及指導小組的滿意度。 Deane et al. (1997) 則認為專案成功在於須關注專案的成果與 客戶的需求是否保持一致，避免潛在的差距。潛在差距代表目前的 專案成果是不正確的，代表著專案不符合規範的結果。表 2.5 列出 五種專案績效差距級別說明。 表2.5 專案績效差距級別 客戶實際需要的專案成果 差距 1 客戶描述所需要的專案成果 差距 2 專案團隊期望中的專案成果 差距 3 專案團隊計畫開發的具體項目 差距 4 交付給客戶的實際專案成果 差距 5 客戶所感受的專案成果 資料來源：Deane et al. (1997), 本研究整理。 Struckenbruck(1987)認為衡量專案成功是以人的觀點來衡量，能 夠界定專案成功最重要的四種人物包含專案經理、高階主管、客戶 以及團隊成員；其他則可能還包含系統或產品使用者或者是參與專 案的相關工作人員。
Walid & Oya(1996)認為須將影響專案成功與失敗因子之關聯性 加以分析才能真正得知專案易於何處出錯並須事先注意，因此發展 出一套評估架構，將關鍵因素分為四大部分，提出此四大因素是影
21 響專案成敗的主要關鍵點，分別是：（1）與專案相關之因素；（2） 與專案經理及專案成員相關之因素；（3）與組織相關之因素以及（4） 與外界環境相關之因素。 研究結果顯示專案關鍵成功因素與專案屬性有顯著的相關性， 對於專案經理而言這是非常有用的資訊。舉例來說，當規模及價值 為專案關鍵成功因素時，則該專案大多屬於矩陣型的組織型態；若 時間為專案成功的衡量界定時，則專案經理的管理技巧及與團隊成 員間的溝通則是重要的關鍵；此外，研究結果也發現因為商業環境 的快速變化，導致影響專案成功的因素也同時產生變化，如因應新 技術的應用，原本不相關的因素可能因此變成關鍵。綜合上述諸位 專家學者之論點，彙整專案成功之界定如表2.6 所示。 表2.6 專案成功之界定一覽表 相關研究 年份 提出之看法或定義 Oisen 1970 成本、時間與品質
Pinto & Slevin 1988 預算、時間、績效水準、技術有效性、 組織有效性（符合利害關係人之期 待）、組織效能（專案成果）。 DeLone et al. 1992 系統品質、資訊品質、服務品質、使 用率、使用者滿意度及淨效益。 Gatian 1994 用戶滿意度。 Alter 1996 符合流程與達成組織目標。 Saarinen 1996 使用率。
Walid & Oya 1996 影響專案成敗的主要關鍵點，分別是： 1.與專案相關之因素； 2.與專案經理及專案成員相關之因素； 3.與組織相關之因素 4.與外界環境相關之因素。 資料來源：本研究整理。
22 表2.6 專案成功之界定一覽表（續） 相關研究 年份 提出之看法或定義 Deane 1997 關注專案的成果與客戶的需求是否保 持一致，避免潛在的差距。 Wright 1997 以客戶的觀點提出專案須滿足時間及預算要求。 Wateridge 1998 時間、成本、品質、公司利益及商業 化成功。 Atkinson et al. 1999 專案管理鐵三角（成本、時間以及品 質）、系統的技術實力、組織所獲得的 好處以及更廣泛的利害關係者群體 （間接效益）的好處。
Thomas & Fernàndez 2008 如期、如預算、利益輸送、滿足業務 目標和業務連續性。 資料來源：本研究整理。 綜合上述文獻探討對於專案成功標準之界定是以時間、成本、 品質為主，少數的學者則以利害關係人的滿意度和滿足業務目標作 為界定。本研究歸納上述學者對於專案成功的看法，以符合時間、 品質、預算作為專案成功的界定。
2.3 專案失敗因子
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 專案失敗主要包含兩種類型： 1. 專案已完成並持續營運，但超出預算及 原訂完成時間。 2. 專案於執行過程中被取消。 專案失敗原因主要包含： 需求不完整、缺乏用戶參與、缺乏資源、 不切實際的期望、缺乏行政支持、需求及 規格不斷變更、缺乏規劃、不再需要、缺 乏專案管理及技術能力不佳。 Flowers 1996 資訊系統發生下列情形即代表失敗： 1. 系統整體運作效能不如預期般順暢。 2. 使用者拒絕使用或未充分利用。 3. 系統開發成本超過系統折舊年限。 4. 系統複雜性太高或者是專案管理問題導 致放棄開發。 McConnell 1996 專案經典失誤分為四大類型，分別是人 員、過程、產品及技術四大類。 Atkinson 1999 專案失敗分為兩種類型，類型一是事情做 錯，例如規劃不良、估算不精確以及缺乏 控制等；類型二是事情沒做或做得不夠完 整。 Yeo 2002 資訊專案失敗因子的前10 項主要因素包含 有： 專案規劃、企業文化、專案管理與管控、 業務流程與系統設計、資訊系統專業人 員、資訊技術、使用者、主辦管理、政策 及商業規劃。 黃茂榮 民 98 在專案成案之前的機會登錄階段與競標與 簽約階段可能就已經鑄下不可挽救的專案 失敗因子。 資料來源：本研究整理。
28
2.4 政府採購法
政府採購法係於民87 年 5 月 27 日公布；民 88 年 5 月 27 日施 行，經過多次修正，現今使用民100 年 1 月 26 日修正公布之版本。 其主要目標在於建立公開、透明、公平、競爭之政府採購作業制度； 提升採購效率，配合政府施政及經濟發展需要；創造良好之競爭環 境，使廠商能公平參與以及引入外國優良措施，改善現有制度之缺 失，創新政府採購作業。政府採購法所稱採購，指工程之定作、
財物之買受、定製、承租及勞務之委任或僱傭等
，其適用之採 購主體包含： 1. 自行辦理採購者：為政府機關、公立學校、公營事業。 2. 補助辦理採購：受補助之法人團體（補助金額超過採購金額之半 數且在公告金額以上）。 3. 委託辦理採購者：受委託機關及法人團體。 依據本研究所收集之案例特性，從政府採購法中挑選出與本研 究較相關之案例屬性定義進行介紹，包含：「採購標的」、「招標金 額級距」、「招標方式」及「決標原則及決標方式」。2.4.1 採購標的
分為工程、財物及勞務採購： 1. 工程採購：工程指在地面上下新建、增建、改建、修建、拆除構 造物與其所屬設備及改變自然環境之行為，包括建築、土木、水 利、環境、交通、機械、 電氣、化工及其他經主管機關認定之 工程。 2. 財物採購：財物指各種物品、材料、設備、機具與其他動產、不 動產、權利及其他經主管機關認定之財物。 3. 勞務採購：勞務指專業服務、技術服務、資訊服務、研究發展、 營運管理、維修、訓練、勞力及其他經主管機關認定之勞務。29
2.4.2 招標金額級距
採購金額級距分為四大類： 1. 公告金額十分之一以下之採購，稱之為小額採購。 2. 逾公告金額十分之一未達公告金額之採購，稱之為公告金額採 購。 3. 公告金額以上未達查核金額之採購，稱之為查核金額採購。 4. 查核金額以上未達巨額之採購，稱為巨額採購。 各類採購級距的金額上限依據採購標的有不同的規範，整體來 說，小額採購為新台幣 10 萬元以下之採購，適用於工程、財務及 勞務類。公告金額採購為新台幣10 萬元以上、100 萬元以下之採購， 適用於工程、財務及勞務類。查核金額採購應用於工程及財務類採 購標的，採購金額為新台幣100 萬元以上、5000 萬元以下之採購； 應用於勞務類之採購標的，則採購金額為新台幣100 萬元以上、1000 萬元以下之採購。巨額採購應用於工程類之採購標的，採購金額為 新台幣5000 萬元以上、2 億元以下之採購；應用於財務類之採購標 的，採購金額為新台幣5000 萬元以上、1 億元以下之採購；應用於 勞務類之採購，採購金額為新台幣 1000 萬元以上、2000 萬元以下 之採購。彙整採購金額級距說明如表2.9 所示。 表2.9 採購金額級距類別說明 級距/類別 工程 財物 勞務 小額 10 萬元以下 10 萬元以下 10 萬元以下 公告金額 100 萬元 100 萬元 100 萬元 查核金額 5000 萬元 5000 萬元 1000 萬元 巨額 2 億元 1 億元 2000 萬元 資料來源：本研究整理。2.4.3 招標方式
採購之招標方式，分為公開招標、選擇性招標、限制性招標及 未達公告金額招標方式：30 1. 公開招標：指以公告方式邀請不特定廠商投標。 2. 選擇性招標：指以公告方式預先依一定資格條件辦理廠商資格審 查後，再行邀請符合資格之廠商投標（依據政府採購法第 20 條 辦理）。 3. 限制性招標：指不經公告程序，邀請二家以上廠商比價或僅邀請 一家廠商議價（依據政府採購法第22 條辦理）。 4. 未達公告金額招標方式：指公開徵求廠商提供書面報價或企劃書、 （小額採購）逕洽廠商採購。
2.4.4 決標原則及決標方式
機關辦理採購，除政府採購法另有規定外，應訂定底價。底價 應依圖說、規範、契約並考量成本、市場行情及政府機關決標資料 逐項編列，由機關首長或其授權人員核定。唯機關辦理若有下列採 購情形，得不訂底價。但應於招標文件內敘明理由及決標條件與原 則：（一）訂定底價確有困難之特殊或複雜案件；（二）以最有利標 決標之採購；（三）小額採購。 決標原則及決標方式分為以下四類： 1. 最低標：訂有底價之採購，在底價以內之最低標為得標廠商。 2. 合理標：未訂底價之採購，標價合理（可由評審委員會建議金額）， 且在預算數額以內之最低標商。 3. 最有利標：綜合考量標的價格、品質、技術、功能、效益、特性 及商業條款對機關最有利者。 4. 複數決標：機關得於招標文件中公告保留採購項目或數量選擇之 組合權利，但應合於最低價格或最有利標之競標精神。 彙整政府採購法對於採購之定義說明及本研究所收集之案例特 性，歸納出本研究之案例屬性定義如下： 1. 採購標的：工程採購、財物採購、勞務採購。 2. 招標金額級距：小額採購、公告採購、查核採購、巨額採購。31 3. 招標方式：公開招標、限制性招標、未達公告金額招標方式。 4. 決標原則及決標方式：最低標、最有利標、複數決標。 5. 是否委外：委外、不委外。 6. 標案性質：新案、擴充維護案。 7. 驗收情形：通過、未通過。
2.5 文獻探討小結
如上有關專案管理、專案經理、利害關係人、資訊專案特性之 定義，以及專案成功的界定、專案失敗因子等相關文獻探討，綜整 本研究採用之定義小結如下： 1. 專案管理是指一種暫時性的組織與努力，經由事先確認的時間、 資源及履約條件，以創造出一項獨一無二的產品、服務或結果。 2. 專案經理是由執行組織所指派以達成專案目標的人。 3. 利害關係人包括：專案經理、專案成員、業主、高階主管及顧問 專家。 4. 資訊專案特性為須把抽象概念具體化，且須整合環環相扣的複雜 問題。同時，投入更多的人力不一定能將專案提前完成，可能還 因此讓專案進度更加落後。此外，資訊專案管理過程除須完成本 質性軟體開發工作，還須解決眾多伴隨軟體開發而來的問題，導 致資訊專案之管理較一般專案之管理有更高的執行風險。 5. 文獻探討對於專案成功的界定是以時間、成本、品質為主，少數 的學者則以利害關係人的滿意度和滿足業務目標作為界定。本研 究歸納上述學者對於專案成功的看法，以符合時間、品質、預算 作為專案成功的界定。 6. 文獻探討表示專案結果失敗是經常發生的，統計數據也表示有三 分之一的專案執行結果最後是失敗的，包含專案規模日益擴大、 專案複雜度提升、開發團隊越來越分散，以及未於專案執行結束32 後進行檢討與改善等原因，導致資訊專案失敗層出不窮一直發生。 本研究探討之專案失敗因子包含：需求不完整、缺乏使用者參與、 缺乏資源、缺乏行政支持、缺乏辨識風險能力、技術能力不佳、 採購能力不佳、管理不佳、未執行品質保證、預算超支及不切實 際的期望等十一項專案失敗因子，以期了解經常導致專案失敗的 原因以進行避免策略。
33
第三章 研究方法
依據文獻回顧及本研究整理，本研究探討專案利害關係人認為專案 失敗因子影響專案驗收通過之程度及於實際執行時發生頻率的認知感 受。3.1 研究架構
依據研究範圍及文獻探討的說明，本研究所採用的相關定義說 明如下： 1. 專案管理：指一種暫時性的組織與努力，經由事先確認的時間、 資源及履約條件，以創造出一項獨一無二的產品、服務或結果。 2. 專案利害關係人：指專案經理、專案成員、業主、高階主管及顧 問專家。 3. 專案成功界定：指符合時間、品質及預算。 4. 專案失敗因子：指需求不完整、缺乏使用者參與、缺乏資源、缺 乏行政支持、缺乏辨識風險能力、技術能力不佳、採購能力不佳、 管理不佳、未執行品質保證、預算超支及不切實際的期望。 本研究首先針對資訊專案之案例屬性、專案成功之界定、專案 失敗因子定義進行調查，包括文獻回顧及專家訪談，接著進行：（1） 案例屬性分類及判別分析，求出專案成功與失敗判別函數；（2）使 用問卷調查法蒐集研究個案，探討專案經理及主要利害關係人對於 專案管理認知上的異同，進行專案失敗因子影響專案驗收通過的程 度及發生頻率感受程度調查，最後彙整分析結果提出專案成功與失 敗判別函數、不同專案角色及服務年資之單因子變異數變數分析及 管理實務意涵，研究架構如圖3.1。34 圖 3.1 研究架構圖 資料來源：本研究整理。 資料分析共有五個步驟，步驟一共有兩個部份：（1）針對所收 集的案件屬性進行分類統計，並依據專案屬性變數進行判別分析， 以求得判別函數；（2）透過文獻回顧及專家訪談方式了解資訊專案 失敗因子並轉化為問卷題項，經由一連串的預試、訪談與刪題、修 正之後，得出最後的問卷。步驟二主要在於問卷調查方式設計及調 查對象確立，經由問卷發放與回收得到最後的回收數量，進行基本 統計分析。步驟三進行統計分析實作，採用 SPSS 統計軟體，經由 編碼與輸入後，檢查資料的相關數值，並進行問卷的有效性分析及 遺漏值的處理。步驟四進行衡量構面之影響程度與發生頻率矩陣分 析。步驟五以專案角色及服務年資為變數進行單因子變異數分析， 以了解各群組間的差異及各群在選擇變項的特徵。分析步驟如圖 3.2。
35 圖3.2 資料分析步驟 資料來源：本研究整理。
3.2 研究設計
3.2.1 問卷設計與尺度衡量
本研究主要採用問卷調查方法進行資料蒐集，問卷形式主要以 文獻回顧法整理出主要的問卷題項，輔以專家訪談取得專家意見， 並結合本研究之見解，集結成問卷之衡量構面。問卷設計包含問卷 填寫說明、衡量構面對於專案驗收通過的影響程度與發生頻率及填 答人的基本資料。 問卷衡量尺度採用李克特五點尺度衡量，以敘述句的方式呈現， 後面跟隨著許多選項，分別標示各種同意或支持的程度。本研究使 用由左至右，分別代表由完全否定到完全肯定，採名目尺度形式呈36 現，由 1－5 分代表，1 分代表「幾乎不影響」或「從不發生」、5 分代表「非常嚴重」或「總是發生」，以此類推。衡量影響驗收通 過程度之問項採用（幾乎不影響、稍微影響、尚可、嚴重、非常嚴 重）的選項；衡量發生頻率之問項採用（從不發生、偶爾發生、有 時候發生、經常發生、總是發生）的選項供填答者勾選（蔡雲陽， 民 96）。 問卷設計完成，進行問卷預試工作，針對本研究之研究對象包 含專案經理、專案成員、業主、高階主管及專家學者進行試填及試 問工作，以發掘問卷尚待改進之處與內容簡明程度，最後修正問卷 題項，使問卷內容符合簡單化與實際化。 問卷調查及回收的方式可分為兩種，包含紙本問卷及建立網路 問卷的方式，邀請符合問卷對象條件之填答人填寫，採用紙本填寫 方式者，由填答人於問卷填寫完成後直接交付回收；採用線上填寫 者，則透過雲端硬碟儲存問卷內容，本研究使用Google 所提供之線 上問卷設計服務。
3.2.2 問卷對象
本研究之問卷調查對象為具有產業資訊專案導入經驗之專案經 理及專案成員，以及客戶（本研究定義為業主）、高階主管及顧問 專家。根據 Struckenbruck(1987)所定義，專案最主要的利害關係人 包含專案經理、專案成員、業主以及高階主管，因此本研究採用此 論述，此外考量多數大型的專案有聘請顧問專家共同協助專案執行 之情形，本研究亦將顧問專家納入問卷調查之對象，以取得不同的 看法與見解。 此外，因各行各業都已普遍實施不同需求的資訊系統，並衍生 相關的資訊管理服務，且考量本研究著重在探討專案利害關係人對 於專案失敗因子的看法，因此不侷限於特定產業進行調查。3.2.3 問卷內容
37 本研究問卷內容包含三大部分：第一部分為問卷說明；第二部 分為填答人對於專案失敗因子於專案驗收通過與實際執行時發生 頻率的評分；第三部分為填答人的基本資料。 本研究於102 年 4 月 1 日至 102 年 4 月 8 日進行問卷預試，以 專案經理、業主、專家學者及高階主管為對象共5 人進行問卷預試。 預試結果主要呈現下列問題： 表3.1 問卷預試修正建議彙整 訪談對象 專案角色 專家訪談建議 A 業主 依據 PMBOK® Guide 定義之子流程作為衡量 構面問項之說明不夠明確，建議使用較白話 文的方式來說明。 B 專家/學者 1. 專案績效問項與衡量構面較不相關，建議 可刪除。 2. 基本資料調查部分可忽略「性別」、「年 齡」，可新增「專案年資」欄位。 C 高階主管 建議調整「專案驗收通過的影響程度」與「發 生頻率」之順序，以產生理論與實務上見解 不同之差異性。 D 專案經理 基本資料部分只需針對填答人之專案年資進 行調查，無須調查填答人所屬單位。 E 專案經理 問卷之衡量構面定義不易理解，不熟悉 PMBOK®者可能有看不懂的疑慮。 資料來源：本研究整理。 歸納問卷預試所蒐集之專家意見，修正問卷衡量構面之定義說 明，以較直述的說明方式呈現，使問卷更符合簡單化與實際化的設 計要求。定稿問卷衡量構面來源如表3.2 所示。
