技术失败：

1、领先技术的诱惑
2、不完善的技术设计
3、为非技术问题提供了技术解决方案
4、依赖软件包来满足需求
5、在开发生命周期过程中没有充分利用工具
6、以技术为导向进行开发

人为失败：

1、缺少行政人员的支持
2、缺少领导
3、没有敬业精神的项目团队
4、功能不全的项目团队
5、管理第三方失败6、缺少一个项目精英
7、缺少项目所有权
8、相关人员冲突
9、拒绝变更
10、敌对的组织文化
11、经验不足的项目经理
12、缺少商业理由
13、不清晰或模棱两可的商业优先级
14、缺少用户培训
15、相关人员动机不一致

过程失败：

1、缺少项目管理方法体系
2、缺少系统开发方法体系
3、缺少收益管理方法体系
4、缺少质量管理方法体系
5、未能确定和转移项目风险
6、未能管理需求
7、过长的项目时间表
8、测试不足
9、计算机化的”爆炸“方法

从项目失败中吸取教训是不断改进过程的重要组成部分，现在罗列一下一些主要的经验教训

1、管理用户预期。

即是我们的项目人员要从一开始就明白需要交付什么以及不要交付什么。要在项目中确定用户的需求和建立尽可能清晰的商业所有权。即使在最好的情况下，用户以前收到的信息也是有限的。通常情况下，我们很难确定能够提供反馈信息的合适用户。

在项目一开始就需要确定主要的用户需求，并且为主要用户提供时间，以便他们确定所在部门的需求，同时他们也有责任提供和验证信息并投入相应的资源。

2、项目规格说明书中必须考虑商业要求和用户需求。

首先要理清两个概念。

第一，项目是因为可确定且可测量的商业要求而产生并发展的。在软件项目初期确定的清晰目标将随着项目的进展而逐渐变得模糊，这是拥有过长的交付期限的项目所共有的特点。因此在项目开始之前，需要确定最终用户，以便在软件项目的设计和开发过程中充分考虑到他们的需求，同时用户也有责任而且需要采取相应的行动来帮助项目获得成功，这一点非常重要。用户需求构成了项目的分析和设计阶段中一个至关重要的环节。需求确定后，就要为这些需求确定基线，并将它们引入到配置管理系统中，同时使用变更控制对其进行管理。如果这些需求出现了变更或添加了新需求，则需要对项目进行影响分析，并对项目计划进行相应的修正。而像我们一些采用增量式和迭代方法开发软件的组织而言，还需要冻结每个软件版本的需求，并建立相应的机制（在确定的时间点和功能点进行版本控制，详细如项目的版本控制可以专门建一个文件夹用于版本控制，然后专人每天以该文件夹的更新文件搜索出来，以WINRAR保存完整路径进行打包，再解压便得完整路径下的每天更新的文件），以便向开 发基线添加新的具有更高优先级的需求（用户需求反馈中确定优先级）。

第二，项目规格说明书必须关注商业需求而不是技术解决方案。因此，即使从技术上讲已经存在明确的解决方案，但在进行项目评审时仍需将重点放在与商业相关的方面。

3、在批准资源以前测量和评估项目的规模和复杂度（重视实现性）。

技术力量的发展带来了一个不幸的后果，就是让我们相信，许多以前不可能实现的目标如今不但可以实现了，而且可以轻而易举地实现。有时候这种思想在项目的早期阶段通常表现为对项目的潜在收益过分夸大、过于庞大的项目范围定义以及过分乐观却相当危险且不够详细的项目规划。因此我们需要明确确定的是：

a、提议的项目进度表是否现实可行；b、项目的商业案例是否可行；c、解决方案在技术上是否可行；

软件项目的规模和复杂度是项目成功与否的一个决定性因素。

4、软件项目的引入必然会为组织带来广泛的变化。

新技术对使用新技术人员的角色和责任带来的不少的影响，容易导致有关程序角色和责任的不明确。因此在项目计划中纳入培训成本和时间进度以确保员工知道如何使用和维护系统是至关重要的。没有合理的培训就是永远不可能实现软件投资的全部潜在收益。更重要的是，缺少培训可能会为项目带来商业风险和运作风险，这些风险可能会最终威胁项目的长期可用性。

5、清晰可见的项目管理结构对项目至关重要。

在管理结构中必须存在定义清楚的角色、责任和义务。在项目的开始阶段就应该确定正式的报告结构以及与高级管理层交流的途径，同时在项目的整个过程中予以保持。

6、首先处理好人员问题

永远不要忘记，人才是项目成功的唯一最重要因素。人员开发计划必须与组织中的项目管理框架同步进行，从而提供培训、业绩评估、分派工作和职位晋升相关的机制。（哈哈，谁都希望项目团队里都是高度主动性和熟练技能的员工）

7、接受风险，但要严格管理风险

IT系统的成功实现需要有效风险管理所支持的创造性思维。风险处理和变革是提高竞争优势的重要力量，但很大程度上还是取决于组织文化对这些方面工作的鼓励和支持阿。当然项目也要及时对一些影响项目进度的功能模块进行调查并重新审视风险分析工作（以及后续的风险管理工作），从而对基线进行重新评估并相应的调整计划。