第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部门需要投入更多的精力向业务部门介绍执行项目涉及哪些步骤。
