在敏捷開發、devops(開發運維)和相關的管理技術的時代，IT項目失敗甚至不是個事兒了嗎?可悲的是，答案是肯定的。

 

在過去，IT失敗往往意味著代價高昂的失敗之作，大規模的軟件實施時間過長，超出預算。那些失敗可能而且仍然會發生。例如：IBM未曾完成的1.1億美元的升級到賓夕法尼亞州的失業補償制度。

 

但是今天的IT失敗往往與過去的不同，因為敏捷、devops(開發運維)、持續交付和快速失敗的運動已經改變了IT處理項目的本質。這些迭代的管理方法和理念旨在最大限度地減少項目出岔子的可能性，但事實是IT項目仍然失敗，只是以新的，有時甚至是更陰險的方式失敗。

 

以下是七位IT領導者和分析師對如今的IT項目失敗狀況的看法。

 

 

目前，加利福尼亞州科羅納市的首席信息官Chris McMasters引用了幾年前在前雇主進行的為期18個月的SaaS客戶關系管理系統的實施情況，在那里IT部門與銷售部門的領導層一起了解業務需求并定義要求。

 

他說：“我們以為我們有了所有必要的決策支持并知道結果應該是什么，但我們到達項目盡頭，而銷售人員不想要。阻力極大。高層管理人員是支持的，但是用戶之間有不信任。”

 

基于云的CRM被宣布為破產和報廢——這表明即使項目按時按預算完成，它們依然可能失敗。

 

McMasters說：“失敗可能以很多不同的形狀和形式出現，無關乎產品有多閃亮，或者它能做一千件事情。對我來說，如果我們沒有提供終端用戶期望的結果，那就是失敗。”

 

McMasters說如果IT更多地關注營銷新系統的好處而不是項目執行，那么它更有可能獲得成功。他說：“我們沒有達到本該有的參與度。我們本該與業務更好地合作。”

 

CRM作為一個失敗的項目，它的實施并非絕無僅有。項目管理研究所(Project Management Institute)2017年的職業脈搏(Pulse of the Profession)報告發現，受調查對象所監督的戰略舉措中有28個被認為是徹底失敗。 3000多名項目管理專業人員中有37%的人回答引證說缺乏明確的定義和/或可實現的里程碑和目標以評估作為失敗原因的進展，其次是溝通不暢(19%)、高級管理層缺乏溝通(18%)、員工抵制(14%)和資金不足(9%)。

 

說到錢，同一份報告發現，由于項目績效不佳，組織每投資10億美元就平均浪費9700萬美元。這比2016年的1.22億美元的浪費要好些，但仍然有大量的現金損失。

 

 

專家說，盡管采用新的方法論和管理技術意味著阻止壯觀的失敗，但傳統上使IT項目處于失敗風險的很多因素仍然存在于企業中。資源不足、咄咄逼人的時間表、成本低估、被忽視的需求、意料之外的并發癥、治理不善以及錯誤代碼等人為錯誤都可能導致項目失敗。

 

普華永道(PwC)的2017年全球數字智商調查調對來自53個國家的2216名業務和IT領導人進行了民調并詢問他們是什么阻礙了數字化轉型。約64%的受訪者表示IT與業務之間缺乏合作是元兇，58%的人表示是因為不靈活或緩慢的流程，41%的受訪者表示缺乏新技術和現有技術的整合，38%稱是過時的技術，37%b把矛頭指向熟練隊伍的缺乏。

 

專家說，同時，用于判斷項目是否成功還是失敗的標準已經擴大，以反映今天的技術舉措的重要性。PMI的2017職業脈動報告指出，“成功的定義正在發展。范圍、時間和成本的傳統措施在當今競爭環境下已經顯得不足了。項目提供它們著手做的工作的能力——即預期的收益——同樣重要。”

 

研究確認了他們的項目中有80%或以上是按時按預算完成的，同時滿足原始目標和業務意圖;它將這個組別歸類為“冠軍”。報告還強調，這些冠軍投資于幾個共同領域，其中包括項目專業人員的領導技能、福利實現管理、項目管理辦公室、積極參與的高管以及敏捷項目管理實踐。

 

研究公司IDC的分析師Stephen Elliot估計，IT項目中有30%至35%可能被視為失敗。 Elliot將很多這樣的失敗歸因于業務優先級或目標的變化。他說，這意味著技術運作良好，但并沒有提供業內目前所期望的結果。在這些情況下，由于缺乏有效的溝通和協作——“在這里決定是制訂了而但沒有得到傳遞”——而這恰恰在IT項目失敗方面罪責難逃。

 

他說：“在這個以客戶為中心的世界里，我將‘失敗’定義為你公司的聲譽或利潤或收入已經受到負面影響。失敗仍然是真實的，與其說它與技術故障有關，比如因為有人沒有檢查主路由器上的配置，不如說它與業務流程有關。”

 

其他人也表示認同。 IT認證提供商美國計算機行業協會(CompTIA)的產品高級總監James Stanger表示：“如果你按時按預算將事物整合起來，但它沒有做到客戶想要的或用戶需求的，那么這無濟于事。”

 

 

有一些趨勢，特別是敏捷和devops方法，有助于減輕現代IT商店中的大規模項目失敗的可能性。

 

Elliott說：“從理論上說，這種編寫代碼的新方式，即以小塊為單位進行自動化測試，并且迭代直到它清理然后移動到下一個塊，提供了一個安全網。你更頻繁地檢查錯誤，因此輸出的應該是更高的質量——所以處理恰當的話，它不應該中斷這么多。你可以更快地推出更新的功能，同時還能夠降低高故障點。”

 

自動化在開發和測試中的日益普及也有助于減輕故障發生的可能性。正如Elliott所說：“如今的大多數故障仍然與人為因素有關——錯誤代碼，導致中斷的網絡配置，負載均衡不良。這個東西真的很復雜，而且錯誤在所難免。但是隨著自動化的到來，應該減少人為的錯誤，特別是在腳本和應用程序部署和網絡方面。”

 

組織層次的變化也有助于降低風險。各單位的高管有望攜手合作、快速前進、迅速調整;事實上，根據分析師和顧問的說法，領先的組織能顧及更多的自主權來修正路線以實現這種文化。

 

Stanger說：“今天人們更愿意說，‘讓我們隨著進展重新定義它。’這是今天與20年前相比最大的變化之一。”

 

McMasters說，他試圖通過更多地關注一個項目應該實現的目標來管理失敗的風險。他采用devops原則將工作分解成更小的部分，在這里問題可以更快地浮出水面，并在思路可以安全地回火的地方運行試點項目(從而允許創新而不會對業務產生重大影響)。

 

他還認為“強大的項目管理運動已經通過IT”，以幫助減輕IT部門以及其它部門的失敗風險。他表示，這項運動有助于技術領導者及其業務部門的同僚更好地闡明項目應該完成的工作——以及項目不該完成的工作。這將成功的定義從按時按預算標準轉變為業務目標的實現。

 

 

同時，關于企業失敗的觀念轉移有助于重塑組織對風險的態度。Elliott說：“現在失敗沒關系，只要你從中汲取教訓。有些公司真的很感激失敗，只要事情越來越往好的方面發展，人們從失敗中汲取教訓并變得越來越聰明，他們知道什么該做什么不該做。”

 

當然，Elliott和其他人指出，那些更加不忌諱失敗的組織也會努力減輕風險，使用沙盒環境和試點項目以及迭代開發，以限制因某些事情的發生可能導致的損失量。McMasters說：“他們正在減輕最終出大事的風險。”

 

韋斯特蒙特學院(Westmont College)的副校長和首席信息官Reed A. Sheard見證了這種文化轉型是如何取得積極成果的。他說他和其他首席信息官都明白并不是所有的項目都是平等的; 每個人在成功時都會帶來不同的潛力，如果失敗，則帶來不同程度的后果。考慮到這一點，他說：“我們要對可以失敗和不可以失敗的地方作出判斷。”

 

他列舉了最近的兩個舉措來說明他的觀點。第一個舉措突出了實施一個管理學校入學過程的新平臺，這是一個關鍵任務，因為不符合用戶要求和具體期限將是毀滅性的，因為入學是組織的核心職能之一。Sheard表示，他積極參與項目，評估進度和資源。它于2015年7月成功上線。

 

第二個舉措集中在一個允許校友網絡虛擬化的平臺的提供。Sheard說，他的團隊試圖建立一個安全的、用戶友好的平臺，但最終無法實現這些目標。工作人員努力保護系統，驗證用戶和并用正確的信息填充用戶資料。

 

他說他對該項目的失敗很坦然，因為他們在嘗試中學到很多東西。“我們因經歷了一些失敗而成為專家。所以我能很輕松地從為期兩年的工作脫身，因為我們在平衡安全性和可用性方面超級精明。”他補充說，他的團隊使用新發現的知識與供應商合作，最終提供一流的產品。

 

其他人將這種心態——愿意失敗的心態——看作想要創新并保持競爭力的組織的關鍵組成部分。

 

賓夕法尼亞州拉德納鎮的WGroup是一家幫助企業優化業務績效并創造價值的公司，他的負責人Terry Coull表示：“如果你不斷學習并不斷改進，那么你可能會不斷失敗。對于那些在這個連續體中的事物，這意味著你正在調整、適應、你是靈活的——所以你在小團隊工作和交付。所以你的項目失敗并不像以前那么大。在舊的瀑布式世界里，你可能會失去一年，然后才發現失敗。”

 

 

這些最新的企業文化趨勢和IT方法當然不能保證成功，也不能完全防范項目失敗。其實有些人說現代IT商店里有些元素甚至會加劇可能導致項目被取消的問題的可能性。

 

有一位專家指出了敏捷和devops方法的潛在問題。波士頓大學凱斯特羅姆商學院商學院(Questrom School of Business)的信息系統教授兼校長Marshall Van Alstyne說：“你解決了較小的問題，但是隨后你[建立]這些大型的綜合系統，其中大規模的問題在你達到規模之前是不可見的。。

 

他說，例如使用這些迭代方法的IT團隊可能會發現，他們的新的軟件特性和功能在每一個步驟中都可以工作，但是隨后發現應用程序在完全部署后整體運行不正常。他補充說：“在某種意義上說，你所做的是將系統升級到一個程度，在這里系統將在更高一層出故障”，他補充說，將這個情景與醫生“治愈”一個病人的個別癥狀進行比較，不能治療較大的病癥將引發所有的癥狀。

 

同時，業務部門和IT部門之間的筒倉可能會增加項目失敗的風險，因為業務部門主管接受了技術并試圖將最新和最牛的技術資本化，無論他們是否充分了解或徹底審查了他們的選擇。

 

美國普華永道的首席技術官兼首席技術專家Chris Curran說：考慮到越來越多的技術支出來自業務部門的預算，而不是IT的資金。他指出普華永道的2015年全球數字智商調查顯示，技術支出的68%超出IT預算。

 

他指出：“這鼓勵了領導人盡快做出重要的事情并盡可能專注，他們會外出并參與SaaS和第三方供應商和云端。云端和SaaS既增加了速度，又獲得了新技術，同時也為項目失敗做出了貢獻。[業務領導者]直接外出參與這些產品，但后來意識到他們需要訪問企業數據或企業IT基礎設施的其它部分，他們不知道他們需要這些，所以項目被停滯或委派或取消或重新定義范圍。”

 

他指出，普華永道在過去三年的其它調查中也發現，引發項目失敗的第一個原因是“僵化或緩慢的過程”。其他主要原因是缺乏技術型團隊和第三方的問題。

 

此外，雖然IT基礎架構，特別是硬件上的基礎架構的改進有助于降低災難性故障的風險，但仍然存在老舊的工具、技術債務和手動流程，在這里當項目上線時，小而大的錯誤可能會導致大規模的故障。

 

Elliott說：“風險依然存在。”他解釋說即使一個新的應用程序運行正常，其被引進大環境時其新老技術形成的復雜網絡可能會導致問題。“應用程序在網絡上運行，并且它們是全球性的，它們往往運行在其他人的設備上。如果故障可以發生的話會有很多層次。”

 

最后，重要的是要記住，無論涉及技術的項目失敗的原因是什么，如果IT無法實現，IT可能會受到責備——無論是否公平。

 

Stanger說：“到最后關頭背黑鍋的往往是IT，這就是為什么IT必須非常小心。”