經過 20 年的應用，人們發現經典專案過程存在很多問題，這迫使人們研究它存在的問
題，以期找到解決方案。經典專案管理最困難的問題是專案難以規劃，做出來的計畫往往會
出錯。於是開發小組往往走向兩個極端：要麼是不做規劃，這樣的小組根本無法回答「你們
什麼時候能完成？」這樣的問題。要麼是在計畫中投入大量的精力，直到自己確信計畫是正
確的，但這種「正確」往往是自欺其人的，這種計畫可能更全面，但不意味著更準確或更有
用。因為軟體的特點不確定性是始終存在的。
儘管經典專案管理把費用、質量（功能目標）、時間設定為最重要的三角約束，遺憾的
是很多人的研究都告訴我們，傳統方法不一定會得出滿意的答案，下面是很多人做的研究結
果：大約 2/3 的專案會顯著超出費用預算（lederer and prasad 1992）。
產品中 64%的功能很少或者從不會被使用（johnson 2002）。
一般專案花費的時間會超出進度表 100%（s***ish 2002）。
這就迫使我們仔細研究專案失敗的原因，歸納起來可以有 5 個原因。
1）初期的估計偏差可能很大
下圖顯示了 boehm 所考慮的不確定性在順序開發過程不同點的範圍，這個圖稱之為不確
定性錐形。 圖上表明，在專案定義階段，對進度估計的偏差可能達到 60% ～160%，也就是
說乙個預 期 20 周完成的專案，實際花費可能在 12～32 周之間。而在寫下需求之後，估計
的偏差可能還在±15%，這時的 20 周預期可能實際上可能會花 17～23 周。這麼大的預估偏
差根本就無法實施有效的專案管理。
2）活動不會提前完成
設想某乙個資深程式設計師正在為乙個產品編制乙個有趣的新功能，同時他還承擔了乙個為
cmmi 審核準備文件的任務，他會怎麼樣分配時間？毫無疑問，他會把大部分時間用於編制
這個有趣的程式，而準備審核只留下了剛剛夠用的時間，而且是到最後才不得不草草完成。
實際上這種行為非常普遍，以至於有了乙個名稱叫帕金森定律（parkinson』s law，1993）：「工
作總是要拖到最後一刻才完成。」
如果一項工作在甘特圖上分配了 5 天，處理這個活動的員工一定會用滿 5 天，即使能夠
提前完成，他也會通過增加一些花哨的修飾（鍍金需求），或者嘗試著用一些新的熱點技術。
在不少企業文化中，一項活動提前完成，往往被指責為當初他做的估計不準確，或者會另派
其它的任務給他，為什麼要冒這個風險來提前完成呢？人的本性就是如此：用多餘的時間去
做一些對自己有價值，但對別人不一定有用的事情。
3）延誤沿著進度表向下傳遞
由於傳統的計畫是基於活動的，因此它們主要關注活動之間的依賴性。考察下面的甘特
圖，它顯示了 4 項活動及它們之間的依賴關係。
如果需要提前完成測試，就要求一些事件的幸運巧合：
對中間層的編碼提前完成，而它受到向資料庫新增資料表這一活動完成時間的影
響。對使用者介面的編碼提前完成。
提前安排好測試人員。
關鍵之處在於，即使乙個如此簡單的案例中，在啟動測試之前也有 3 件事情必須發生，
但是下面任何一件事情，都可能導致測試推遲：
使用者介面編碼結束時間延誤。
對中間層編碼花費時間超出計畫。
中間層編碼花費時間符合要求，但是向資料庫新增資料表結束過晚，導致延誤了測
試時間。
未安排好測試人員。
也就是說提前啟動測試需要完成很多事情，其中一件事情延誤，都可能導致總體上的延
誤。事實上我們已經確認了活動很少會提前完成，所以發生的絕大多數事情是延誤，而這種
延誤會沿著進度表傳遞下去，最終導致後續專案很少會提前啟動。
4）不按照優先順序開發功能
傳統專案管理方法不一定能夠帶來**值產品的第三個原因是，制定的計畫沒有按照對
使用者或者客戶所具有的價值大小來排列工作的優先順序。很多傳統的計畫實際上假定工作都可
以完成，工作的順序主要是由依賴性來決定。但是隨著專案結束時間的逼近，開發小組會匆
忙放棄一些功能以跟上進度，由於不是按照功能優先順序順序開發的，某些被放棄的功能反而
比交付的功能更重要。
5）忽視了不確定性
傳統規劃方法的第 4 個缺點，是不承認不確定性的存在。人們假定最初的需求分析就可
以產生對產品來說完整的、完善的定義。我們假定使用者在計畫覆蓋的整個時間內都不會改變
想法，他們的觀點也不會更細化，也不會提出新的需求。
與之類似，我們還忽視了如何構建產品這樣的不確定性，某種技術在實現中才發現並不
一定合適，但我們已經給它分配了確定的時間（兩個星期），事實上我們不可能指望一開始
就確定專案程序中所需要的所有活動，但我們又不願意承認這一點。
在分析了傳統專案管理方法所存在的問題以後，我們對那麼多專案令人失望就不會感到
奇怪了。基於活動的規劃方法分散了我們對功能的注意力，而功能才是衡量客戶價值的單元。
本來專案的參與者滿懷好意的把多工處理當成解決延誤的辦法，結果卻造成專案更加的延
誤。當進度表剩餘時間不夠的時候，不可避免地要放棄一些功能，由於開發人員是按照最有
效的開發方式來安排進度的，因此放棄的功能對使用者來說不一定是價值最低的。
忽視使用者需求的不確定性，會導致雖然按時完成了任務，但很多後來發現的重要功能沒
有辦法加入，或者即使加入了但要不是專案延誤，或者不恰當的降低質量。
這是在這些分析的基礎上，我們就必須考慮解決這些問題的辦法。
導致專案失敗的原因
在csdn上看到一篇有關專案失敗原因的帖子，覺得寫得還是蠻有道理的，現總結如下 1.需求與調研 需求不明確，導致流程不清晰 與客戶過多交流技術問題，導致其總是挑毛病，改需求，專案陷入拉鋸 做專案最容易失敗的一點就是客戶一把手沒有重視進來，如果一把手很重視這個事情，基本上就成功了60 了，以後就是和客...
專案管理 導致專案管理失敗的五個關鍵原因
1 依據少得可憐得專案資訊進行至上而下的計畫專案管理者聯盟 專案計畫的責任始終都是每次研討會的熱點討論話題。這裡似乎達成了乙個共識，就是似乎個體就能夠計畫專案，設定最後期限，建立預算而不需要或很少需要前線人員的輸入。很多人忘記了高層管理通常是哪些控制和了解資源的個體，正如他們控制和了解組織的偉大使命...
專案失敗的原因
據standish group每年對資訊系統專案進行的調查發現，只有17 的專案達到了既定目標，有50 的專案需要更改目標，剩下33 的專案則被取消了。是什麼原因導致那麼多專案失敗呢？通過總結大致分為13個方面的原因 1.未正確定義問題 專案就是乙個計畫要解決的問題。如果沒有很好的理解問題，那麼我們...