我们都要学会从项目失败中吸取教训，只要我们能够能有宽大的胸怀去面对它，那么犯错也不见是一件坏事。
其实影响我们项目失败的因素主要分为
--------------------------------------------------------------------------------
技术失败：
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系统的成功实现需要有效风险管理所支持的创造性思维。风险处理和变革是提高竞争优势的重要力量，但很大程度上还是取
决于组织文化对这些方面工作的鼓励和支持阿。当然项目也要及时对一些影响项目进度的功能模块进行调查并重新审视风险分
析工作（以及后续的风险管理工作），从而对基线进行重新评估并相应的调整计划。
8、始终评审项目的可行性
项目开始之后，时刻对项目成功的依赖条件进行监督是至关重要的。变更的影响可能导致最初的投资评估毫无意义。因此，商业案例应作为项目过程中一个持续使用的参考。如果认为投资的项目无法实现预期收益，就应当毫不犹豫的终止该项目。一旦作出终止项目的决策，就不要将这个过程变成一个冗长而麻烦的过程。放弃项目并继续前进，确保我们可以从这个过程中学到有用的经验。导致失败项目耗费高额成本的一个关键因素往往是由于终止项目本身这一过程过于冗长。
9、管理外部供应商
应当对供应商的质量管理系统予以足够的关注，以确保这些系统有效并可在现有质量系统中进行评估。过多地依赖承包商对系统交付能力的保证，或者在项目遇到问题时忽略承包商的参与都会带来巨大的风险。最重要的经验是必须与供应商建立亲密的关系，但不要过于依赖他们。无论何时，客户都必须保留他们对项目及其进程的所有权。也就是说，我们必须评审外部供应商的能力和财政立场，将其视为获取和履行过程的一部分。
10、为质量投资
引入质量系统并不便宜。但从长远来看，质量投资的失败将会严重影响整个项目的投资回报。缺少测试和缺陷预防措施仍然是造成项目失败的主要原因之一。
11、始终准备一份应急计划
风险管理过程的基础是确定和管理项目中的风险。因此，商业和IT相关人员必须开发应急计划，以便在真正发生无法交付的情况时采取措施。
12、确保高级管理层参与整个项目过程
有关IT项目的决策应视为商业决策而不是技术决策，并获得高级管理层的完全支持。高级管理层必须承担责任，并且对项目进行控制和跟踪。
13、项目必须拥有对其成功负责的所有者
项目必须有一个单一而有力的所有者，尤其当多方都将同时从项目成果中获得既定的收益时更是如此。在整个项目中，为满足每个人的意愿而做出了很多妥协，结果是未能满足任何人的意愿的。
14、确保所有新的软件开发项目所采用的过程至少符合CMM等级2的要求
作为最低标准，项目中所采用的过程必须能够支持配置管理、需求管理、软件质量保证和项目计划的基本要求。不要依赖交付项目的开发人员的敬业精神和专业知识，一旦他们离开，你的项目就会受到影响。
15、始终执行实现后评审并发布评审结果
没能执行实现后评审的后果很简单：即组织（更确切地说是个人）放弃了从错误中吸取教训的机会。实现后评审的目的在于确定项目对商业目标的满足程度。因此，评审的范围应涵盖项目的所有方面：商业目标、用户期望、用户满意度、预测的收益、技术需求、供应商管理和质量保证。实现后评审通常是软件项目中的最后一项任务，该任务通常会帮助我们提高对项目结果的认知并将其用于将来的项目改进。
16、项目管理经验和领导气质仍然很重要
成功交付软件项目的过程不仅仅是制定项目计划和书写报告，而是关于人员处理、冲突处理、协商谈判和影响组织中其他方面的过程。成功的项目的一个特征是有担任“领导“而不是“管理“的个体。一个成功的领导者会通过与愿意“更进一步”的团队的合作而赢得尊敬和回报。反过来，好的领导者将显出勇气、胆识、权威和领导人的风范。常言道，一个好的领导者应当是“获得属下的欣赏和尊敬，但被老板认为不够理智的人”。哈哈，这就见仁见智了。注意，如果没有行政人员的支持和商业所有权，即使领导者具有很强领导能力且经验丰富，也可能无力挽救项目。然而，一个成功的项目经理应有能力提前识别项目中的危险信号并采取相应的措施。选用经验丰富的项目经理对于及时交付软件项目并保持预算平衡至关重要。项目管理是一项需要花费时间掌握的技能，不能通过在“工作中学习”而获得。如果组织希望提高项目成功的可能性，他们必须投资进行管理培训计划，并制定有效且规范的项目管理框架。
其实影响我们项目失败的因素主要分为
--------------------------------------------------------------------------------
技术失败：
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系统的成功实现需要有效风险管理所支持的创造性思维。风险处理和变革是提高竞争优势的重要力量，但很大程度上还是取
决于组织文化对这些方面工作的鼓励和支持阿。当然项目也要及时对一些影响项目进度的功能模块进行调查并重新审视风险分
析工作（以及后续的风险管理工作），从而对基线进行重新评估并相应的调整计划。
8、始终评审项目的可行性
项目开始之后，时刻对项目成功的依赖条件进行监督是至关重要的。变更的影响可能导致最初的投资评估毫无意义。因此，商业案例应作为项目过程中一个持续使用的参考。如果认为投资的项目无法实现预期收益，就应当毫不犹豫的终止该项目。一旦作出终止项目的决策，就不要将这个过程变成一个冗长而麻烦的过程。放弃项目并继续前进，确保我们可以从这个过程中学到有用的经验。导致失败项目耗费高额成本的一个关键因素往往是由于终止项目本身这一过程过于冗长。
9、管理外部供应商
应当对供应商的质量管理系统予以足够的关注，以确保这些系统有效并可在现有质量系统中进行评估。过多地依赖承包商对系统交付能力的保证，或者在项目遇到问题时忽略承包商的参与都会带来巨大的风险。最重要的经验是必须与供应商建立亲密的关系，但不要过于依赖他们。无论何时，客户都必须保留他们对项目及其进程的所有权。也就是说，我们必须评审外部供应商的能力和财政立场，将其视为获取和履行过程的一部分。
10、为质量投资
引入质量系统并不便宜。但从长远来看，质量投资的失败将会严重影响整个项目的投资回报。缺少测试和缺陷预防措施仍然是造成项目失败的主要原因之一。
11、始终准备一份应急计划
风险管理过程的基础是确定和管理项目中的风险。因此，商业和IT相关人员必须开发应急计划，以便在真正发生无法交付的情况时采取措施。
12、确保高级管理层参与整个项目过程
有关IT项目的决策应视为商业决策而不是技术决策，并获得高级管理层的完全支持。高级管理层必须承担责任，并且对项目进行控制和跟踪。
13、项目必须拥有对其成功负责的所有者
项目必须有一个单一而有力的所有者，尤其当多方都将同时从项目成果中获得既定的收益时更是如此。在整个项目中，为满足每个人的意愿而做出了很多妥协，结果是未能满足任何人的意愿的。
14、确保所有新的软件开发项目所采用的过程至少符合CMM等级2的要求
作为最低标准，项目中所采用的过程必须能够支持配置管理、需求管理、软件质量保证和项目计划的基本要求。不要依赖交付项目的开发人员的敬业精神和专业知识，一旦他们离开，你的项目就会受到影响。
15、始终执行实现后评审并发布评审结果
没能执行实现后评审的后果很简单：即组织（更确切地说是个人）放弃了从错误中吸取教训的机会。实现后评审的目的在于确定项目对商业目标的满足程度。因此，评审的范围应涵盖项目的所有方面：商业目标、用户期望、用户满意度、预测的收益、技术需求、供应商管理和质量保证。实现后评审通常是软件项目中的最后一项任务，该任务通常会帮助我们提高对项目结果的认知并将其用于将来的项目改进。
16、项目管理经验和领导气质仍然很重要
成功交付软件项目的过程不仅仅是制定项目计划和书写报告，而是关于人员处理、冲突处理、协商谈判和影响组织中其他方面的过程。成功的项目的一个特征是有担任“领导“而不是“管理“的个体。一个成功的领导者会通过与愿意“更进一步”的团队的合作而赢得尊敬和回报。反过来，好的领导者将显出勇气、胆识、权威和领导人的风范。常言道，一个好的领导者应当是“获得属下的欣赏和尊敬，但被老板认为不够理智的人”。哈哈，这就见仁见智了。注意，如果没有行政人员的支持和商业所有权，即使领导者具有很强领导能力且经验丰富，也可能无力挽救项目。然而，一个成功的项目经理应有能力提前识别项目中的危险信号并采取相应的措施。选用经验丰富的项目经理对于及时交付软件项目并保持预算平衡至关重要。项目管理是一项需要花费时间掌握的技能，不能通过在“工作中学习”而获得。如果组织希望提高项目成功的可能性，他们必须投资进行管理培训计划，并制定有效且规范的项目管理框架。
扫一扫
574
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
