關於項目失敗的小結

有那麼一則笑話,講的是養魚。養魚每週要換次水，我常忘。就只好每週換次魚了。我以爲世界的事物總有那麼一絲類似的地方。好比這個養魚的笑話，和咱們此次項目管理失敗的總結有一些類似之處。

此次討論一下項目管理的失敗，爲何討論失敗？有句話說失敗是成功之母，咱們討論失敗，是爲了規避失敗，趨近成功。也就是那句話，大方向對了，通向成功也只是拐個彎而已，但若是錯誤了，離成功只會愈來愈遠。

1.什麼是項目的失敗？

通常狀況下，它不知足系統所包含的管理者、用戶，或者其餘受影響的項目干係人的要求。項目失敗一般意味着不能知足成本、工期安排、績效、質量、安全或者相關的目標要求。又或者咱們開發出來的軟件產品的功效與客戶所需求的不能達成一致。

固然，從用戶的角度和開發者的角度，項目失敗有多是對立的，好比一個失敗的軟件項目，耗費了開發者的成本，可是他的用戶卻從項目中得到大量的利好或者利潤。失敗只針對開發者而已。但其實，我認爲，這只是一個經濟上的暫時失利，而利好，卻可能經過用戶的口碑相傳，獲得另外一個項目的開發機會。

? 太平洋老總嚴介和剛下海的時候，接一個30萬的工程項目，但預算下來，預計虧損5萬元左右。他跟手下說：「虧5萬不如虧8萬，就讓他多虧一點吧」。結果，以最快的速度，最優異的質量用70天的時間幹完本來140天的活。後來，驗收的時候以各項指標所有優秀予以驗收，贏得好評，接到上千萬的工程。

因此從這個意義上說，有時候這個項目虧了，也賺了。但若是成本的超支，軟件又沒有知足用戶的指望，那確是很糟糕的事。固然，先不考慮工程項目和IT項目的區別，好比工程項目有行業標準，而IT項目卻沒有。

2.形成失敗的緣由。

有些失敗是不可避免的，由於它們超出了人力所能預期、避免或者影響的範圍。這種類型的失敗源於難以解決的技術難題以及其它不可預見或者不可控制的外力。不過，這並不是是大量項目失敗的緣由。相反，失敗一般是因爲「缺陷」引發的，這些缺陷存在於：

項目和用戶組織——態度、實踐和結構。

??項目最終產品——硬件、軟件和組成部件。

這些缺陷每每是相互聯繫的，好比，一個拙劣的軟件產品一般會追溯到設計時的失誤，而設計失誤又多是因爲需求分析是不徹底或者沒有體現用戶的指望，接下來又能夠追溯到管理過程上的失誤等等。而咱們的缺陷管理或者說控制項目的管理又容許低劣的設計、糟糕的質量、不充分的檢查因素沒有通過糾正就過關，最終會致使軟件產品自己的失敗。

? 網上報帳的工資發放單是一個自動流程，有HR系統發起，經過接口傳到網上報帳自動提交，大大的方便了用戶的操做，而自動發起後的下一個環節，必需要設置好審批人，不然傳過來的單子會將沒法提交而擱置在系統裏變成廢單，沒法提交或者退回，這樣，必需要求實施者在配置流程的過程當中按照必定的規則設置好。按照需求這項功能可能已經完成，但卻也留下不少的缺陷，沒有考慮到提交失敗的處理，爲之後系統出現問題埋下伏筆。這多是一個缺陷管理的縮影。

3.項目失敗的項目管理緣由

致使項目失敗的項目管理緣由能夠分爲3個層次、14個緣由。

第一層次：項目管理環境中的失敗

這些失敗的根源能夠追溯到項目組織與項目目標、項目任務、高層管理部門以及更大的環境之間的不適當的「配合」。它們包括使用對於項目目標和項目環境來講不正確的項目管理方法或模型，以及缺少高層管理部門對項目的支持等。

1.不恰當的項目管理方法

項目不具有正確的組織結構、項目經理或者團隊（以技能、經驗、權力、正規性、複雜性來衡量）來「配合」項目。例如：

? 項目組織結構、計劃和控制與項目環境、項目經理的哲學，以及公司文化或目標不一致或者不協調。

? 更多的重點放在保持團隊的忙碌而不是放在結果上。團隊成員分配沒有考慮其適合的技能和經驗。

? 要麼是沒有人對整個項目負責，要麼是項目經理的責任、指望和權力不明確或者未定義。

? 一個在過去的項目中成功的項目團隊、項目經理或者項目結構被「塞」進一個新項目，而不考慮當前項目的獨特要求或者當前項目環境的不一樣特徵。

2.缺少高層管理部門的支持

高層管理不給予達成項目目標所必需的積極的、持續的支持。例如：

? 高層管理部門沒有把足夠的責任或權力下放給項目經理，或者沒有支持項目經理的決定或行動。

? 公司沒有按照高效的項目管理所須要的政策和程序作出改進（預算、計劃、控制系統、報告和受權關係等）。

? 高層管理部門沒有參與審閱項目的計劃和進程。

第二層次：項目管理系統中的失敗

這些失敗的根源能夠追溯到項目領導及錯誤實踐。它們包括項目經理在項目生命週期中對系統方法的忽略，以及項目管理技巧的錯誤應用等。具體的能夠歸結爲：

1.不勝任的項目經理

擔任項目經理職位的人不具有領導和管理項目的背景、技能、經驗和我的品質。例如：

? 項目經理不能面對矛盾，分析問題，從而提出深層的，適合用戶需求和項目原始需求的方法，不能爲了項目的最大利益而進行有效的努力。

? 項目經理不能對一個傳統的工做環境作出調整來適應新項目的變化和不肯定性。缺少在短期限制和有壓力的環境下高效工做的能力。

? 項目經理在技術和管理技能上不能使人滿意。有時這源自於所謂的彼得法則的變動：將一個優秀的技術人員任命到一無所知的管理職位上。

2.忽略了項目的系統本質

項目沒有被當成一個系統來對待。項目的單元和步驟被劃分紅獨立的部分，而沒有考慮它們相互之間的做用。例如：

? 硬件、軟件、資源和設施被單獨的看待而沒有考慮它們與整個項目目標的關係。將重點放在各個單獨的活動上而不是放在項目整體目標上。

? 系統開發的演變過程被分段地看待，而沒有考慮隨後的或者先前的階段。這在對於將來階段糟糕的計劃和對於過去階段不恰當的評估中表現很明顯。問題從一個階段傳送到下一個階段。

3.管理技巧不恰當或者錯誤的運用

項目管理技巧被曲解或者被不恰當地運用。問題在於項目經理、項目團隊或者被運用的技術自己。例如：

? 項目經理未能將非技術的計劃、協調及控制與項目活動所需的技術區分開來。如PERT、WBS、績效分析和團隊建設等，這些技巧被錯誤的應用或者根本就沒用上。

? 項目經理未注意到項目的人力、行爲方面。他沒有創建一個項目團隊，幫助團隊成員理解項目目標，也沒有激勵項目團隊成員朝着目標一塊兒工做。

? 用到的技術太複雜或者太簡單而不適合特定的項目。工期安排和報告對於項目決策來講過於詳細或者不夠詳細。更簡單、更恰當、更適合小型項目的能動性技巧由於偏心複雜的（可是笨重的或者不須要的）計算機化的報告系統而被忽略了。

第三層次：在計劃和控制過程當中的失敗

這些失敗的根源來自於項目計劃和控制過程。

一些錯誤的源頭，像效率低下的溝通和不充分的用戶參與，會在項目的任何階段發生，須要給予持久的注意。

其它的，像不恰當的定義、估計、工期安排或者控制等主要發生在項目的某些階段。

1.項目中沒有良好的溝通

這些問題的產生是因爲信息的質量、準確性，或者時間性的缺少，以及粗劣的數據收集和記錄，或者未能將信息分配給那些須要信息的人。例如：

? 在項目的早期，關於目的、責任和接受標準的信息沒有作成文獻資料。

? 在項目中沒有關於項目狀態或者對於計劃或最終產品的變動的信息記錄和報告。

? 沒有召開足夠的會議來收集和發佈信息。討論沒有足夠深刻，也未能提出探索性的問題。對項目開發沒有作項目日誌或者審查記錄。

2.缺乏用戶的參與

用戶或者顧客未能參與計劃、定義、設計、實現過程，用戶的需求被忽視。這是最常常被提到的項目失敗的根源之一。

? 用戶可能感到尷尬或者不舒服於是想盡可能減小參與。一些用戶被邀請的時候甚至抵制參與。

? 項目團隊的行爲阻礙了用戶的參與。項目團隊的成員可能表現高傲，這使得用戶感到本身被忽視或者感到自卑。這樣的行爲限制了用戶與項目團隊之間的信任，使相互的溝通變得緊張。

3.不充分的項目計劃

項目細節的分析和計劃不充分、馬虎，從之前的項目得來的報告和建議被忽視。管理不是預先作好準備，而是當事情出現的時候才作出相應的安排。

4.不充分的項目定義

模糊不清的、錯誤的、讓人誤解的項目定義或者缺少項目定義是被常常提到的一個失敗的緣由。對於技術要求、任務或者項目範圍沒有正式的定義。定義問題來源於：

? 缺少提案、WBS、責任矩陣以及工做責任等的定義，或者這些提案的定義準備得很糟糕。

? 在定義項目範圍、任務和要求的時候缺少用戶的參與。項目團隊對用戶的操做一點也不熟悉，不能指導一個與用戶的要求相關的設計。

5.糟糕的時間和資源估計

對資源需求、活動工期、完成日期的估計不現實。糟糕的估計發生是由於：

? 沒有利用相似項目的標準或者文件來估計本項目會持續多長時間。

? 作估計時沒有考慮員工的經驗，而是假設全部的職員都是專家，他們均可以毫無差錯地工做。

? 估計是由不熟悉細節問題的人作出的，那些負責工做的人沒有參與作估計。

? 沒有足夠的時間來作估計。

? 用戶施加壓力，要求項目快速完成，這就致使制訂了不切實際的完工日期，並刪除了「沒必要要的」任務，諸如文件記錄等。

6.不正確的工期安排和資源處理

工期安排和資源分配不正確、沒有預期工做、沒有備用資源。

? 未能預期估計資源需求並作好預先安排，當資源問題出現時才進行處理。沒有顯示項目中可用技能的詳細目錄。

? 項目職員被從新委任或者整個換掉，但沒有調整工期安排以彌補失去的時間或者學習時間。

7.在執行階段爲數衆多的變動

對原始要求作了變更，但沒有對相應的工期安排、預算或者計劃的其它部分作改動。這種疏忽致使不充分的項目溝通、低劣的項目定義、用戶參與的缺少以及馬虎的項目控制等。

8.不恰當的控制

項目管理不是預期可能有什麼問題而是在問題出現的時候才進行處理；控制集中在對於平常事務的處理而不是看到潛在的問題環境；直到項目結束日期，管理部門才查看項目是否準時。控制問題的根源：

? 工做任務的定義太大而不能進行有效的控制；工做組或者工做團體太大而不能被監督；里程碑太遠以致於不能對項目進行分步監測。

? 不遵照設計、記錄、測試或者評估的標準或規範。審計員沒有進行仔細的評估。

? 在項目早期出現問題時沒有嘗試去解決。控制過程不是前瞻性和預防性的，而是回顧性和修補性的。

? 對於爲保證項目目標的完成所須要的資金沒有預測或者計劃。

9.項目終止的計劃很拙劣

不知道什麼組成了項目的完成或者最終產品，接受的標準是什麼，或者誰必須終止項目；沒有正規的終止程序來處理目標、績效、最終產品、以及維護問題等；這些問題常常和拙劣的項目定義以及缺少用戶參與聯繫在一塊兒。

? 當項目終結尚未被清楚的定義時，項目甚至在通過長時間的中止後仍然被容許繼續進行以作出有成本效益的進步。

? 當用戶沒有參與計劃時，對於最終的接受條件會有更多的分歧。在接受以後，對於最終產品的問題未加識別就經過，或者無論用戶的不滿而被容許繼續向前。

諸如養小魚，如何使它們都能存活，那怕一個地方出錯了，均可能致使其死亡。項目管理亦不例外，由於成功的方式可能有不少種，但失敗可能就那麼一個錯誤就能致使，阿里巴巴馬雲說過，我不清楚我怎麼作成功的，但我卻清楚的知道我每一次是怎麼樣跌倒的。經過理解失敗再去分析項目成功的重要因素，纔可以保證項目在正確的道路上按計劃不斷地推動。