2013年-2014年，筆者參與了一個大型項目，云平臺下做資源、資產、電子運維管理，由德勤負責需求集成、HP負責系統門戶和硬件集成，PCCW負責實施集成。IBM、中興、亞聯、億陽等十幾家廠家做開發分包。項目合同額好幾億。當時我在PCCW負責資源的實施管理，與中興、亞聯、億陽一起完成所有省份的實施，一期完成北京、山東、福建的實施。這也是我第一次接觸如此規模的項目，管理多家廠商與周邊十幾家廠商協調溝通。但不幸的是這個項目最終以暫停建設的方式告一段落（好幾億的項目，涉及客戶上上下下各個部門上千人配合工作，誰也擔不起失敗的責任，只能是暫定建設）。后面跟同事討論和復盤項目失敗的原因和如何挽救這個項目。
失敗的原因總體來說有如下幾條：
1、 系統結構框架流程混亂。
2、 廠家分工不合理
3、 沒人牽頭做差異比對
4、 廠家利益牽扯斗爭嚴重
5、 項目大躍進式前進
下面一一闡述這幾個問題。
1、系統結構框架流程混亂
這個項目是行業內其他的集團公司（甲）和集團公司（乙）已經建設過類似的項目，并經過十余年的完善開發，目前已經基本上可以使用。集團公司（丙）的幾個領導考察后，覺得這個項目效果不錯，讓上馬該項目。但又不想花費十年時間去調整，想借鑒使用甲和乙的成功經驗。所以超了個捷徑，讓所有參與甲和乙這些項目的廠商都來參加丙公司項目的建設開發。本意是好的，而且丙公司和甲乙公司管理的東西和相關的流程基本類似，如果使用這些廠商做這些項目多年已有的經驗，確實能大大減少這個項目的成本和工期。
但由于有三個大項目，涉及的開發廠商太多，管理起來太復雜，丙公司就找了國際上知名的幾家公司做總體管理。HP做系統門戶和硬件集成，并沒有太大問題，HP是老牌的設備廠商和IT廠商，提供硬件，做系統門戶駕輕就熟。PCCW做實施管理，有一定的問題，PCCW沒有做過這幾個系統的人。不過從幾個開發廠商那臨時挖角挖來幾個人，而且實施管理來說相對簡單，了解這個系統，跟進實施進度即可，問題也不太大。德勤做需求管理相對來說問題很大，德勤是世界排名前三的咨詢公司，做一些管理咨詢問題不大，但做這幾個系統的需求管理完全不是他們的專業所在，臨時從幾家公司挖人，挖的人也不是很對。德勤做資源需求的人是從廠商那挖了個研發經理（張三）做需求設計。研發經理做需求和產品經理做需求完全是兩個概念，張三每次是根據我們大家提的問題，臨時解答，尋求解決方案。產品經理做系統需求是先做一個總體框架，然后做里面的需求設計。
在前期做開發，調整階段，因為各個廠商都是在自己原有系統上做調整，問題還不是很明顯。到了幾個廠家匯總版本，試跑業務流程時，才發現業務流程跑不通。此時再做調整的話，成本就很大，幾個開發廠商也不愿意調整自己的流程，而此時張三也給不出一個調整的方案。所以后期在業務流程跑不通，一次又一次的延遲向丙公司董事長匯報項目的情況。我們建立的董事長匯報群，每周都在為此做準備，每次又不得不放棄。一直延續到項目暫停建設。
2、廠商分工不合理
做資源的幾個廠商都是在甲和乙公司負責十幾個甚至更多省份的資源項目，做了十幾年的資源系統，相對來說資源系統和流程比較暢通，在甲和乙公司已經基本上用起來了。但是丙公司為了加快進度，把資源系統功能一分為三，每個廠商負責一塊系統的調整開發，以為這樣會大大加快進度。殊不知，這卻大大延遲了系統的交付進度，甚至直到項目暫定建設，也沒完成系統的整合。
幾個開發廠商在甲和乙公司開發系統時，都是單獨負責某些省的系統，他們各自有各自的設備建模、數據庫設計、流程設計、字段定義。他們的接口規范和字段定義、流程都不一樣，在丙公司做融合時，花費了很大的精力去調整，仍然有很多對接不上（德勤公司也沒給大家做整體流程設計、統一的接口規范和字段定義）。
3、沒人牽頭做差異比對
甲和乙公司的整體業務和設備基本上和丙公司大致相同，但是還是有些許差異。丙公司建立年限更早，有一些特有的設備，丙公司的各個部門管制職責與甲和乙公司也不盡相同。丙公司的地址定義、局站命名規范，設備命名規范等與甲和乙公司也不完全相同。但是丙公司并沒有人牽頭做差異比對，德勤作為需求把控方，也沒提出做丙公司實際情況與甲乙公司情況差異對比，沒有安排所有的開發廠商做調整，開發廠商還是沿用甲和乙公司的規范和流程。導致在山東、北京、福建做試點時，現場的用戶使用起來，發現數據對應不上，職責混亂，錄入系統的數據也是詞不對題，數據質量完全無法保證，也沒人引導他們做系統字段講解和錄入數據標準定義，因為開發廠商也不知道丙公司的實際情況，按照甲和乙公司的規范進行講解，但與現場實際情況往往也對應不上，收到了現場用戶無數的反饋和投訴。開發公司把這情況匯報給PMO，協調德勤出面答疑，德勤也沒有人牽頭負責。
4、廠家利益牽扯斗爭嚴重
一期的資源項目是三家開發廠商一人負責一個省，但是后期其他省份會按照這三個試點省的使用情況進行分配。三個開發產商為了自身的利益，在合作開發的過程中，自覺地把一部分核心腳本和程序隱藏起來，不告訴其它廠商。導致后期融合三家版本到省份實施試用時，每個省都沒辦法真正使用起來。另外兩家負責模塊版本中總有各種各樣的坑。
后期想想，如果想要做成資源項目，讓三家開發廠商進入，確實會大大加快項目的進展，但是系統功能不能一分為三，而是讓三個廠商每家做一套資源系統，各自在一個省份試運行。這樣他們使用原有的業務流程，需要調整的只是與丙公司實際情況的差異。而他們的公司有專門的產品和需求部門，有豐富的差異比對和落地實現經驗，而且又有比賽竟比性質，所以他們也會加大投入資源，短期內完成流程和規范的調整。讓試點盡快用起來，以便增加后面幾十個省份額的競爭。（不要小看一個公司的能動性，在給甲公司的一次評比后，億陽版本落后很多，甲集團公司點名批評了下，準備下期更換，億陽召集六十多人去陜西用戶那封閉整改，兩個月完成了兩百多個整改點，后期一舉打敗了其他資源廠商，占領了大半的資源市場）。
需求架構一定要找一個做過這個項目的公司，而非找一個名氣大的公司。如果資源系統讓中興、億陽、亞聯其中的一家做需求管理，可能成本沒德勤那么高，但效果會更好。
5、項目的大躍進形式前進
我入職PCCW后，領導安排跟進資源實施管理，但是看到丙公司發的進度計劃就有些詫異，一星期完成調研，一星期完成開發，一星期完成版本合并，一星期完成實施，下個月給領導匯報完成情況。當時就覺得不太現實，億陽做資源系統，在甲公司做了十幾年，光梳理流程和設備建模，數據錄入就花了十幾年的時間，才把常用的設備建模，讓數據質量勉強達到要求，業務流程基本能跑通。其中經歷了多少產品經理和需求人員去各個省份、研究院和集團公司去確認需求。前前后后根據開發和使用反饋，甲公司召集了各個專業的專家和各個廠家的大拿，梳理下發了五六版各個專業的模型規范。研發熬了多少個通宵，進行了無數次百日大會戰，出了幾十個版本，才完成了甲公司基本業務流程。我們熬肝熬夜配合各省各專業的維護人員，導了無數次的數據，調整了無數次，定義了無數的考核規則，好多地市用戶也被扣了無數分（一分十萬），才讓數據質量勉強達標。
丙公司讓我們一個月完成所有的進度，這不是開玩笑么？可看了所有的人，也不像開玩笑的意思，所以的進度安排都是按照一個月來開展的，因為領導著急要成果，所以時間緊湊些。結果每個月都是按照這個月能完成定計劃，到月底又自覺延期到下個月去完成。但沒有一個人給領導反饋，按照一個月定計劃，所有的細節開展不了，沒辦法交付出一個可以使用的系統。如果定一個長期規劃，不需要十年，三年其實也勉強夠。但是沒有一個人提出這個，也導致，所有需要細細梳理的項都沒有開展過。每個月都是做大框架梳理，但其實對系統建設完善改進有限。每周開發廠商都在查漏補缺，而非去開發功能。
當然這個項目失敗還有很多其他的原因，在此我就不一一闡述。

總結

以上是生活随笔為你收集整理的一个失败项目的总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。