【研究報告解密】軟體專案為何總是走向失敗？

這是一個新的系列，我會找一些研究報告，並搭配著我的個人經驗，嘗試為大家說明研究的內容。並希望通過研究這些報告，能為專案管理者和任何跟專案有關的人仕，帶來一定的啟發和幫助。

這次找來的是一編在2007年於Journal of Information Systems Management發表的研究報告，報告的作者是Stephen P. Keider，報告題為《軟體開發專案為何會失敗》（Why Systems Development Projects Fail）。它之所以吸引我，有兩個很重要的原因。

首先，我主要管理的都是軟體開發專案，對這個領域再熟悉不過。其次，我不斷尋求改善專案管理的方法，希望能有效提高專案的成功率。而要做到這一點，最好的方式就是去了解別人曾掉進過哪些「陷阱」，這樣我們才能在往後的日子裡繞道而行。

因此，在接下來的文章裡，我將會和你分享這份報告的重點，並搭配我個人的實戰經驗作說明。如果你也對這個主題感興趣，希望提升自己的專案管理能力，相信這篇文章會對你有所啟發。

成功專案的條件

在我們深入探討專案為何會失敗之前，得先聊聊一個更根本的問題：到底什麼樣的專案，才稱得上是「成功」？

很多人第一時間想到的，可能都是專案經理們掛在嘴邊的「鐵三角」——在預算內、時間內完成所有交付。但這份報告的作者 Stephen P. Keider 指出，這只是基本門檻。真正成功的專案，還必須達成一個更重要的目標，那就是——為使用者創造實質的價值，也就是提升他們的效率。

作者將這種「效率提升」細分為三個層面，這也恰好印證了我在實務中的觀察：

1. 經濟效益 (Economic Effectiveness):
說白了，就是這個系統上線後，能不能幫公司「開源」或「節流」。是能為企業賺到更多的錢，還是能省下不必要的開支？根據我的經驗，過去大部分投資軟體開發的老闆，心裡想的都是前者——如何靠新系統拓展市場、增加收入。但有趣的是，隨著近年 AI 專案的興起，風向似乎變了。現在，更多老闆開始關注如何用 AI 來「節流」，自動化繁瑣的工作，把錢花在刀口上。

2. 技術效益 (Technical Effectiveness):
作者將技術效益定義為「強化資料處理的能力」。這聽起來有點抽象，但其實非常好理解。想像一下，過去老闆要一份銷售報表，他的助理可能得花半天時間，從各個 Excel 檔裡撈資料、整理、製圖，整個過程既耗時又容易出錯。而今天，許多 AI 專案的核心價值正在於此：它們能快速整合海量、多樣的資料，並以極具洞察力的方式呈現出來。這不僅是單純的加速，更是從根本上提升了我們處理和理解資訊的能力。

3. 營運效益 (Operational Effectiveness):
最後，也是最直接的效益，當然是反映在企業的日常營運上。例如，過去生產一件產品需要一整天，但在導入新的生產排程系統後，製作時間縮短到了半天。這意味著，光是這項系統的投入，就讓產能直接翻了一倍。理論上，這也應該能為企業帶來更多的收入（當然，前提是東西要賣得出去啦）。

所以，這就是報告中定義的「成功專案」。對我來說，這個定義點出了一個殘酷的真相：一個準時、沒超支，但沒人想用、無法帶來任何效益的專案，其實是包裝精美的失敗品。

反過來說，即使專案稍微延遲或超支，但只要它最終能為使用者帶來實質幫助、為公司創造價值，那它在我心中，依然是一個值得慶祝的成功。

那麼，雖然每位專案管理者都渴望著自己專案的成功，那為卻在專案實施的過程中走向失敗呢？接下來就來到作為專案管理者最需要關心的重點，管理錯誤上面。

六大管理錯誤

俗話說，羅馬不是一天建成的，專案的失敗也不是。一個專案最終走向失敗，往往不是因為單一的災難，而是源於管理過程中的失誤累積而成。那麼，到底是哪些管理上的疏忽，會把一個充滿希望的專案推向深淵呢？作者為我們總結了以下六個經典的管理錯誤：

1. 迷失的系統目標
軟體開發專案有個非常普遍又詭異的現象：系統的「最終使用者」幾乎從不參加專案會議。需求往往是透過 IT 部門或某些「業務開發部門」「轉述」過來的。正因為這種間接溝通，開發團隊就像在玩「傳話遊戲」，很難真正理解系統到底要解決什麼痛點、達成什麼目標。
以我個人的血淚經驗來看，這種專案的結局幾乎都一樣：在系統交付給終端使用者時，才發現功能不符合他們的使用習慣、流程對不上實際的業務場景，接下來就是無止盡的修改地獄，耗盡了團隊的士氣和公司的預算。

2. 對變更成本的「選擇性失憶」
這個世界只有一件事永恆不變，就是沒有變更的發生，專案也一定。因此，專案經理必然要面對變更帶來的連鎖反應。而導致專案失敗的關鍵，往往不是變更本身，而是專案經理在面對變更時，選擇了「假裝沒事」。他們沒有誠實地把變更所需要的額外時間和成本，重新反映到專案的總時程和預算中。換句話說，需求增加了，但死線和預算卻紋風不動。這不是在管理專案，而是疏忽職守。

3. 「先跑再說」的失控計畫
在我的經驗中，這通常是技術團隊最常犯的錯誤。他們總覺得「哪有時間做計畫，先寫程式再說！」，一旦開發工作啟動，就再也沒人想回頭去補那份枯燥的工作計畫了。所有人的眼光都盯著還剩下多少功能要完成，卻沒人知道完成這些功能到底需要誰、在什麼時候、做什麼事。
在缺乏正式計畫的情況下，團隊責任變得模糊不清，每個人都「想到什麼就做什麼」，最終專案經理手上沒有任何控制的韁繩，只能每天燒香拜佛，祈禱專案能奇蹟般地如期完成。

4. 用戶缺席的功能確認
系統功能是為了服務用戶而生，這句話天經地義。但如果在方案定義的開發過程中，用戶從未參與功能規格的制定，甚至不知道系統的介面長怎樣、有什麼限制、該如何操作，那最終的「驗收」只會變成一場「批鬥大會」。
我可以很肯定地說，根據我的經驗，只要缺乏用戶在前期對功能規格的簽字確認，他們就必定會在驗收時，提出雪片般的修改要求。這不是用戶在找麻煩，而是我們從一開始就沒有讓他們參與進來。

5. 形同虛設的系統測試
一個軟體系統，理應經過千錘百鍊的測試，才能交付到用戶手上。因此，專案經理必須為測試設定明確的標準，例如單元測試覆蓋率要達到多少、核心業務場景是否都已通過測試等。
一個缺乏嚴謹測試就匆匆上線的系統，不僅會因充滿 Bug 而引發用戶不滿，更會因為後續無窮無盡的修補和更新，大幅拉高整體的維護成本，得不償失。

6. 被遺忘的「最後一哩路」：系統替換
專案的結束，不只是新系統上線而已，更重要的是如何讓用戶順利地從舊系統過渡到新系統。如果最終使用者在新系統上線前，對它一無所知，那麼即使新系統功能再強大，也會因為巨大的學習曲線和操作慣性而遭到抵制。
因此，專案團隊除了埋頭開發，更要規劃好這「最後一哩路」的工作：包括舊資料如何遷移、使用者培訓如何安排、上線後的支援服務由誰負責等等。這些看似瑣碎的工作，卻是決定系統能否真正落地生根的關鍵。

以上六點，就是作者在報告中提出的管理失誤。我個人認為，這每一點都切中要害，幾乎是所有失敗專案的共同基因。

作為專案管理者，我們必須時刻對這些警訊保持敏感，並主動出擊。例如，用戶不願開會？那我們就主動敲門，帶上誠意和原型（Prototype），解釋直接溝通的重要性。面對需求變更？我們更不該害怕談錢和時間，而是要專業地把「代價」攤在桌上，讓對方清楚知道每個決定的份量，並由他們來權衡取捨。

學會辨識這些管理錯誤，是我們的第一步。但有時候，專案的敗象並不明顯，而是像空氣中的煤氣味，需要我們有更敏銳的嗅覺。

接下來，讓我們換個角度，從一個「旁觀者」的視角，來看看專案執行過程中，有哪些細微的信號，正悄悄預示著它可能走向失敗。

七大危險信號

前面我們討論了管理層面的失誤，但很多時候，我們不是專案經理，無法深入細節。這時，我們需要換一個角度，像一位偵探一樣，從旁觀者的角色，觀察專案過程中是否出現了某些預示著風暴即將來臨的「危險信號」。

1. 消失的專案狀態報告
這大概是所有信號中最明顯的一個。很多專案經理同時負責多個專案，他們可能會以「太忙」或各種理由，停止提供專案狀態報告——無論是以口頭匯報、書面文件還是簡報的形式。
請記住：一個如果連定期報告都沒有的專案，我們就有理由對其管理狀況產生懷疑。這背後通常只有兩種可能：要嘛，經理根本沒在管這個專案，心思都在別處；要嘛，專案本身就沒有一個合理的計畫，所以他也報告不出個所以然來。
當專案經理無法清晰回答專案的現況時，並不代表團隊不努力，而很可能代表團隊正在「瞎忙」。他們只是在「見步行步」地把專案往前推。至於最終能不能推到正確的終點？我想，可能只有上帝知道了。

2. 資訊孤島與孤立主義
專案經理在過程中，理應會收集到許多寶貴資料，例如過去類似專案的技術選型、行業背景資料等。這些資訊是團隊的公共資產，而不是他個人的秘密武器。
如果他沒有將這些資訊有效地分享給團隊成員，反而像情報頭子一樣，以一種神秘兮兮的方式獨自處理，那麼專案的前景就不太樂觀了】這種行為等於是在自己和團隊之間砌起了一道高牆，讓團隊在黑暗中摸索，而他自己則成了資訊的孤島。

3. 風平浪靜的「零變更」
我們前面說過，變化是專案的常態。那麼，一個從頭到尾都「風平浪靜」、沒有任何變更的專案，反而是最可怕的信號。
這通常意味著兩種情況：要嘛，專案經理從未定期向用戶展示開發進度和實際操作畫面；要嘛，用戶的參與度極低，根本沒把這事放在心上。無論是哪一種，後果都是災難性的。
作者在報告中特別警告：如果一個專案在完成度達到 95% 時，才開始湧入第一波變更請求，那麼最終很可能導致 300% 的成本超支和長達六個月的延期。因為這時候的變更，等於是推倒重建。

4. 過度沉迷於「怎麼做」而非「做什麼」
如果一位專案經理或他的團隊，開口閉口都在強調技術有多牛——例如他們用的軟體框架多先進、硬體伺服器多強大、AI 模型多精準——那麼這個專案的結果，大概率不會好到哪裡去（除非這個專案就是為了IT部門自己而做的）。
因為軟體的核心價值是為了解決用戶的痛點。技術只是工具，是解決痛點的助力。如果團隊的重心從「痛點」轉移到了「工具」本身，我個人認為這就是典型的本末倒置。
試想一下，一位醫生在你面前滔滔不絕地說他的藥有多厲害、手術刀有多鋒利，卻對你的病情心不在焉，你還會相信他能治好你嗎？

5. 危險的「過早編程」
這和前面提到的「先跑再說」是兄弟檔。如果專案團隊在軟體規格都還沒確定的情況下，就興高采烈地告訴你：「我們已經開始寫程式了！」。這時你不該高興，而該警惕。
這幾乎保證了他們後續需要不斷地推翻重寫，引發更多的系統 Bug 和技術債。因此，如果規格尚未塵埃落定，請不要急著要求團隊「動起來」，而是應該要求他們「想清楚」——加速完成軟體規格的確認，並在所有利害關係人都點頭同意後，再投入實作。

6. 被忽視的人員更迭風險
對於大型或長期的專案來說，團隊成員的變動幾乎是必然的。這本身不是問題，問題在於專案經理是否預見並準備了應對方案。
如果專案經理的風險登記冊上，根本沒有「核心人員流失」這一項，也沒有為此預留相應的知識轉移時間和招聘緩衝資金，那麼一旦真的有主要成員離開，專案的進度必然會遭受重創，甚至陷入停滯。

7. 迷戀技術的「單一成就」
這一點與第四點相互呼應，但更聚焦在專案經理個人的價值觀上。如果一位專案經理評價專案成功的標準，只在於他開發的軟體功能多強大、架構多複雜、設計多靈活，這種「技術本位」的思維，最常出現在剛從技術崗位轉為管理崗的專案經理身上。
當你和抱持這種態度的專案經理合作時，真的要多加小心。因為他們的目標可能不是交付一個能解決問題的產品，而是打造一個能寫進自己履歷的「技術傑作」。

以上，就是作者在研究中發現的七大危險信號。這些信號的價值在於，它們讓專案的利害關係人——無論你是客戶、老闆還是協作部門——都能擁有一個「儀表板」，用來監測專案的健康狀況。

當你看到這些警示燈亮起時，就該主動與專案團隊溝通，協助他們一起面對和解決問題，而不是等到最後再來究責。

在了解了管理失誤和危險信號後，我們終於要觸及問題的核心了。接下來，讓我們看看作者的研究中，究竟把專案失敗的矛頭，指向了哪些最主要的原因吧。

專案失敗真正的原因

經過前面幾輪的鋪陳，從「成功的定義」到「管理的失誤」，再到「危險的信號」，我相信各位心中大概已經拼湊出專案失敗的輪廓了。

說實話，有些專案的失敗，確實是因為技術選型錯誤或架構設計失誤，這些有時並非專案經理一人能掌控的範圍。
但接下來要揭示的這些核心原因，矛頭幾乎都直指專案經理本人。與其說是客觀的失敗，不如說，是專案經理的「失職」或「不作為」，親手將專案推向了失敗。

現在，就讓我們直搗黃龍，看看這份研究報告最終的核心結論：軟體開發專案失敗的七大「元兇」。

1. 元兇一：失能的計畫
一切混亂的根源，始於一份粗糙甚至不存在的專案計畫。這直接導致團隊成員不知道自己的職責是什麼，搞不清楚「誰該在什麼時候，向誰交付什麼」。最終，團隊無法有效地協同合作，讓設計、開發、測試、部署等一系列工作變成一盤散沙。

2. 元兇二：蠕變的範圍
專案範圍定義不明確，加上用戶早期參與的缺失，必然導致專案後期無止盡的修改。開發團隊只能在舊代碼上不斷「打補丁」，層層疊加，最終系統變得臃腫不堪、難以維護，就像一座搖搖欲墜的違章建築。

3. 元兇三：無意義的回顧
在缺乏良好管理的專案中，即使開了回顧會議，也往往淪為一場鬧劇。這讓我想起過去參與過的一個專案，那場回顧會簡直是「甩鍋大會」的典範：每個人都在指責他人的錯誤，為失敗的結果尋找藉口。會議上沒有人提出任何建設性的改善方案，只有在相互指責的口水戰中草草收場。這樣的「回顧」，除了製造團隊矛盾，毫無價值。

4. 元兇四：遲鈍的預測
優秀的專案經理像個天氣預報員，能從微小的跡象中，預測到可能嚴重影響專案的風險。他們總能在暴風雨來臨前，找到那片關鍵的烏雲。然而，如果專案經理缺乏這種敏感度和預測能力，他就只能淪為一個「救火隊員」，被動地在問題爆發後焦頭爛額地去應對。

5. 元兇五：懦弱的堅持
有時候，最可怕的不是走得慢，而是走在錯誤的路上卻不敢停下來。即使專案看似進展順利，也並不代表它正朝著正確的方向前進。專案經理需要具備一種「自我懷疑」的精神，不斷反問自己和團隊：「我們為什麼要這麼做？這真的是最佳方案嗎？」
而缺乏勇氣的管理者，即使內心隱約感覺到方向錯了，也會抱著僥倖心態，選擇「繼續錯下去」，期望奇蹟發生。

6. 元兇六：失控的變更
面對雪片般飛來的修改請求，一個失控的團隊沒有任何章法可言。他們處理變更的方式是「想到哪，做到哪」。這一次，他們可能想起來要更新規格文件；下一次，可能記得要通知用戶；再下一次，可能乾脆什麼都不做，直接上手改程式碼。這種混亂的變更控制，是滋生 Bug 和混亂的最佳溫床。

7. 元兇七：無力的團隊
如果專案團隊的核心成員（如分析師、設計師、程式設計師）技能不足，又或者缺乏系統性的培訓來彌補差距，這時專案經理的態度就至關重要。
如果他選擇了默默接受，硬著頭皮往前推，那麼專案通常只有兩種結局：一是徹底失敗，宣布告終；二是團隊在「做中學」的過程中，磕磕絆絆地交付了一個產物，但早已遠遠超出了最初的時間和成本目標，名存實亡。

以上，就是這份研究為我們揭示的、導致專案失敗的七個核心原因。

不知道你在閱讀時，是否有那麼一兩個瞬間，感覺心頭一震，彷彿看到了自己或團隊的影子？

我認為，這篇文章最大的價值，不是讓我們去指責過去的失敗，而是提供了一面「鏡子」。身為專案管理者，我們可以藉由這面鏡子，重新審視自己正在進行的專案，誠實地問自己：

• 我的計畫足夠清晰嗎？

• 我的團隊是不是正在「瞎忙」？

• 我是否有勇氣，對一個錯誤的方向喊停？

專案管理從來不是一門只靠工具和流程的科學，它更是一門關於溝通、勇氣和承擔責任的藝術。希望這篇文章的內容，能成為你工具箱裡的一件利器，幫助你避開那些常見的陷阱，從而穩健地提高每一個專案的成功率。

感想

人最大的敵人，或許就是自己的盲點。我們不能對自己不知道的東西做出改變。像是從未意識到，團隊之所以一團混亂，根源竟是自己那份潦草的專案計畫；又或者是因為害怕給人「製造麻煩」，而硬著頭皮接下一個技能不符的團隊，天真地寄望能靠一己之力彌補所有差距。

坦白說，在整理這份研究報告時，我好幾次都感到毛骨悚然。因為我發現，過去在管理專案時，那些自己有意或無意的行為、那些看似無關緊要的決定，其實都像蝴蝶效應一樣，一點一滴地將專案推向了難以預料的結果。

但幸運的是，恐懼之後，迎來的是清醒。我終於認識到了這些可能導致專案失敗的思維與行為模式，從而能夠開始思考「下一步」該如何行動。

雖然這份認知，未必能在一夜之間扭轉乾坤，但我堅信：

一切的改變，都始於「認知」。

期望每一位在專案管理路上奮鬥的夥伴，都能透過不斷地自我覺察、改善自己的管理能力，最終為我們身處的這個世界，打造出更多真正有價值、能解決真實問題的好軟體。