第7個錯誤

　　忽視出現的問題。

　　影響：問題是不會自行解決的。你忽視問題的時間越長，問題只會變得越嚴重，最終會增加項目的成本。

　　辦法：問題一出現，就要盡快調動盡可能多的利益相關者一起來解決問題。

　　第8個錯誤

　　沒有花時間來確定項目范圍。

　　影響：如果業務和IT部門事先沒有明確項目的范圍，項目到頭來很可能會失控。另外，IT部門也缺乏按時按預算完成項目、滿足業務部門預期目標所需的明確方向。

　　辦法：針對定義不明確的項目，最好的辦法就是拿出商業方案、確定項目范圍。

　　第9個錯誤

　　沒有看到項目之間的依賴關系。

　　影響：項目不是彼此孤立的，它們常常依賴同時開展的其他項目。如果項目經理看不到項目之間的依賴關系——比如一個項目需要另一個項目的人員參與，項目進度就會耽誤。這種耽誤會對所有項目帶來連鎖反應。

　　辦法：項目規劃期間就要考慮到項目之間的依賴關系，與利益相關者交談，并且繪制項目的示意圖，這有助于找出項目之間的依賴關系。

　　第10個錯誤

　　沒有考慮到“墨菲定理”。

　　影響：一旦某些“事故”出現，就會影響到IT部門。往往在IT部門收拾意料之外的殘局時，項目已偏離了軌道。

　　辦法：執行風險評估，這是項目規劃的一個環節。整個團隊群策群力，考慮可能會發生什么事情導致項目延遲或者偏離方向，或者無法滿足預期需求。然后，找到緩解這些風險的對策。

　　Primavera公司的CEO Koppelman說： “如果大家坐下來考慮一下潛在風險，就會列出相當多的風險。這項工作不需要很長時間，卻對項目上馬之前明白項目的薄弱環節大有幫助。”

　　Scannell舉例說，曾經有一家英國企業準備把大型機搬到新的數據中心。IT小組在周六用一整天的時間來拆卸大型機，以便次日能搬到新的數據中心。周日，IT部門帶著大型機在前往新數據中心的路上，遇到了游行活動，因道路封鎖而到不了目的地。他們只好開車返回原來的數據中心，重新把大型機裝了回去。這就是缺乏規劃預案導致IT部門做不必要工作的典型案例。

　　第11個錯誤

　　漠視變更管理。

　　影響：要是用戶不采用新技術，那么為了交付新的IT功能而投入再多的時間、資金和精力，也是白費力氣。

　　辦法：項目規劃階段，事先抽出時間考慮項目可能會在哪些方面遇到阻力，并且考慮好應對阻力的辦法。還要找出哪些利益相關者的工作會受到新功能的影響，并且計劃好如何向他們說明流程和工作流方面出現的變化。

　　應該明白，不是所有變更都是不好的。

　　第12個錯誤

　　項目進度計劃不完整。

　　影響：項目團隊的成員不知道應當何時交付什么樣的成果，這樣一來就很難按時完成項目。

　　辦法：要為項目安排進度報告，一個簡便的方法就是確定完成項目涉及的所有活動（比如確定范圍、征集需求、進行測試及實施），然后根據項目的最后期限為這些活動確定相應的預定日期。項目管理軟件有助于安排進度。

　　第13個錯誤

　　IT部門沒有要求延長不合理的最后期限。

　　影響：IT部門很可能面臨失敗，落下無法按時交付項目的壞名聲。IT部門會力求在CEO規定的項目最后期限之前完工。但不注意項目的依賴關系和總體計劃只會帶來更多的問題，從而更難按時交付。

　　辦法：IT管理人員要向CEO解釋，需要多少成本和資源才能在這個最后期限之前按時完工，并且讓CEO在成本、范圍和進度之間進行選擇。

　　第14個錯誤

　　與項目發起人和利益相關者沒有溝通好。

　　影響：IT部門滿足不了預期需求。如果IT部門把數千行數據描述系統功能和規格的電子表格交給業務部門，就有可能讓業務部門對|考試|大|項目范圍或者系統需求產生誤解。因為業務人員沒有時間去查看這么詳細的技術文檔。

　　辦法：讓到時會受到影響或者參與項目的每個利益相關者都大體上了解整個項目從設計到實施的過程。重點突出需要與業務部門聯系的活動，并且解釋為什么需要業務部門的參與。IT部門需要投入更多的精力向業務部門介紹執行項目涉及哪些步驟。