IT專案與傳統專案的區別
傳統的專案需要經歷的時間長，使用的是有形資源，專案成果是通過對資源的消耗與形態的轉化來逐步實現的。IT專案的實質是“知識轉移”， 專案是以無形的智力產品為專案目標。典型的IT專案是IT系統的建造(如系統集成)和軟體開發專案。
因此說，IT專案的實質是“知識轉移”，而建造專案的實質是“資源消耗”。當然，並非說IT專案中不存在“資源消耗”，也不是說傳統專案中沒有“知識轉移”。這一點應該得到辨證的理解。
積極溝通對任何專案而言，在起始階段就必須定下開發和合作的溝通機制，這一點很重要。在專案啟動後要有效地實行開放溝通。專案出現失敗的跡象時，開放的溝通管道更是不可或缺。專案管理者要跑到利益相關者的辦公室去，解釋該專案為什麽行不通。要告訴別人專案會失敗不是件容易的事，但如果已經有了良好溝通的基礎，至少可以使一件不容易的事變得稍微容易一點。
不要找藉口
有時候一個專案失敗後，大家都遮遮掩掩的，沒有人出來解釋專案怎麽出的岔子和失敗的原因。如果是你負責這個專案，應該站出來收拾爛攤子，承擔責任，不要找諸如“採購部門未能完成對專案申請檔的審批和簽字”之類的藉口。
注意專案早期出現的失敗徵兆
從表面上看，很多專案都在順利運行，但仔細一點的查一下就會知道專案進行得並不順利。精明的專案經理能感覺到一個專案可能失敗。他們會注意專案裡的工作人員出現壓力過大的情況和專案任務出現了不應該出項的延遲等跡象。他們看到這些徵兆後會立即介入。通常情況下，專案經理可以扭轉專案失敗的頹勢，但有時候也會回天乏術。及早地確認一個專案可能會失敗，提前採取必要行動，就可以有效地減輕該失敗專案的影響。
要有即時叫停的勇氣
大多數專案經理都是樂天派，能想出不少好點子，是解決問題的能手，他們能找到辦法成功地完成幾乎每一個專案。但事情也有不好的一面：同樣是這些專案經理，他們面對一個失敗的專案時會誓不言敗。這些人擁有絕不言敗的基因，他們無法明白某個專案是沒有指望成功的。承認一個專案的失敗不是件容易的事，但一旦你確切地知道一個專案必然會失敗後，就要拿出勇氣來，快刀斬亂麻叫停專案，避免更多的浪費。
事後分析
這個專案到底為什麽會失敗呢？專案失敗後，多數人都不願提起，想把這件事情忘了，此為人之常情。作為專案經理，要反其道而行之，並且要求你的員工反其道而行之。專案取消後要進行詳細的分析，要在大家還記得細節時開展討論。與團隊成員開會討論時要營造一個理解的、輕鬆的、友善的環境，這一點也很重要。
轉弊為利
爛掉的專案也有利用的價值。這些價值可能是一些出自該專案的優良業務規則，這些規則可以用在以後的專案裡，或是某個員工在該專案裡表現優異，可以在以後的專案裡賦予重任發揮其特長。在做專案分析時，要和團隊成員一起找到這些“好東西”，讓他們瞭解到儘管專案失敗了、沒有達到主要目標，但也產生了價值，這對他們來說是一個不錯的經歷。
檢討各種得失因素
專案經理應該評估自己一方(和其他方)在專案裡的表現。雖然專案的重點是具體的東西，多數專案經理也知道政治因素也會影響到專案的進行。不同的因素都可能導致專案失敗，如客戶不合作，或是有內訌，或是IT人員之間不合作，或者外部供應商沒有跟上。由於這些原因，專案經理應仔細檢討各個環節以及各種政治因素的得失(自己做，不是與團隊成員一起做)。
設置返回點
處理失敗的專案有點像駕駛一架戰鬥機。應該時時知道專案在什麽時候撤退，要帶好降落傘。應該在專案啟動前預先與團隊和利益相關者一起設定一些檢查點。這些檢查點的形式通常是專案週期裡的評估分數，專案團隊和利益相關者可以根據檢查點對應的評估分數，有必要時決定是否需要叫停一個專案。在專案裡設置這些檢查點可以保證開放的溝通、保證各方參與專案的評估、減少出現不愉快的可能性。
制定備用方案
因為無他計可施而要放棄一個專案肯定讓人不爽。因此要準備好一個備用方案，有必要時用上備用方案，不會影響到專案的勢頭。例如，你想建個私有雲，但專案進度有些跟不上，或許可以換個思路，找個IaaS (Information-as-a-service資訊即服務的縮寫)供應商設置所需的雲環境。
為專案和預算規劃不同的階段
在設定專案檢查點的同時，應該按階段開發專案，按階段設定相應的預算。應該將一個專案分成更小的、更易於管理的階段，分段做出相應的預算分配。這樣做以後，要叫停一個花了幾百萬美元、一年多人工的專案就會容易得多。
文章節錄：中國專案管理者聯盟
ProjectClub 專案俱樂部為一群專案經理人組成的平台，網站分享專案運作的各種專案管理手法與實用專案工具，並分享如何提昇職場人的軟技巧與硬實力。
