第一篇：项目经验教训总结
4月28日上午，公司桥梁改建和桥梁新建项目经验教训总结会在公司会议室召开，公司总经理汪云峰，副总经理韩家武、吴红波，总工程师李孝林及各部门、各项目部负责人参加会议。会议由汪云峰总经理主持。
本次会议的议题为：一是对刚刚结束的桥梁新建、改建项目管理过程中存在的问题进行总结分析，为今后类似项目的实施提供管理经验;二是针对公司目前所处的外部竞争环境，进一步提高公司各职能部门的管理水平，降低企业管理成本，适应市场竞争和企业发展的需求。
会议首先听取了桥梁新建、改建项目负责人对项目实施过程中存在问题的汇报，并对今后改进方向达成如下共识：建立项目风险防范控制体系，从经营投标阶段开始做好各项风险分析和管理控制工作;建立健全的项目策划制度，在项目实施前期做好项目人员配备、材料采购、机械设备使用、安全质量进度成本控制等各项管理工作的策划，保证项目实施的可控性、科学性;严格施工组织计划和施工方案上报制度;加强项目安全管理，提高项目全员安全意识，进一步健全人员岗前培训及各级安全交底制度;完善岗位责任制度，实行目标责任考核，加强对项目成本的管理与控制;建立合作单位登记及资信等级分类制度，维持长期稳定的合作单位，确保工程的质量、安全和进度;加强项目部与公司后勤职能部门的沟通与协调，各职能部门要实际深入到项目各阶段的管理，做好各项服务工作;项目各项工作的开展要做到有据可依，公司综合部负责为各项目部提供所需的各项制度、流程等相关文字资料。
会上，公司各职能部门结合部门管理职能，检讨了管理中存在的不足及改进的措施，汪总做了相关指示：综合管理部在制定项目经理岗位职责的基础上，进一步明确项目人员岗位职责，并做好人员调动、离职交接工作;项目每月资金计划拨付款项要做到专款专用，不得挪用;财务部要根据目前财务管理工作中存在的问题，尽快制定和完善相关的流程和制度，制度中应有具体的奖惩措施，其中项目出纳为项目财务管理工作的直接责任人，项目经理为主要责任人;项目资金计划拨付表会签过程中，各部门要做到权利义务对等基层工会工作经验交流报告，对签字同意或者不同意拨付的款项给出具体原因，以帮助项目部进行改进;材料管理工作要加强材料过程控制，完善材料管理手续，降低材料使用中的损耗和消耗，减少库存资金的占用;审计部门要做好过程审计工作，及时发现项目管理中存在的问题。
会上，公司副总经理韩家武、吴红波，总工程师李孝林根据公司目前所处的阶段及管理中存在的问题，分别从加强基础管理和制度建设、健全项目策划制度、加强公司质量安全管理和人员培训等方面作了发言，并指出，问题是企业发展的着力点，是工作的方向，正视和解决问题是企业前进的动力，只有不断发现问题、认识问题、解决问题，企业才能得到持续不断的发展。
会议最后，公司总经理汪云峰要求各职能部门要根据会议讨论的内容，结合公司及项目实际情况，于五月份完成公司现有制度的修订和完善工作，并确保各项管理制度的适应性、有效性、可操作性。
第二篇：项目经验、教训与建议总结
以下是本人在某电子商务项目过程中的一些经验、教训与建议，和大家一起分享，供参考：
项目管理方面
除了常用的项目管理注意事项外，项目过程中主要总结了以下几点经验：
1.项目要想最终成功完成，两种角色不能少，并且要能在整个项目开发过程中给予开发人员指导。一是业务责任人，要求对业务比较了解，对功能需求方向明确，并能随时解答开发人员的疑问。二是技术架构责任人，在开发前期，搭建整个项目框架，制定简单可行的规范，并在开发过程中，跟踪开发人员工作成果，纠正错误。如果项目人员较紧，无法安排专职业务和技术总责任人，可以由项目经理自已担任或批定其它人兼任；
2.竞价通2制定项目计划时，采用两级计划。即针对项目制定一份总计划，功能分解只到模块一级。再制定一份功能分解详细进度计划，要求模块责任人针对单个模块制定具体进度计划，要求将功能分解到至少页面一级。开发过程中，针对详细计划跟踪，及时发现问题和延迟。
沟通管理方面
项目沟通主要体现在产品和研发，研发和测试，研发和各门户等等。由于门户是第三方，且有5个门户，所以在沟通方面，采用以下措施，避免了沟通不畅：
1.如果是项目阶段完成，知识（工作成果）需要从一个部门转移到另一个部门，采用了基于文档的多次培训，讨论会方式；
2.会议，培训正式沟通之外的临时沟通，指定了各部门责任人单一接口沟通方式，使问题可以得到及时的，统一的解决；
3.和第三方门户沟通时，同样双方指定责任人，并尽量制定进度计划，达成一致；
团队建设方面
项目过程中采用了组长负责不同功能模块结构，组长对细节功能进行分解和分工。21位开发人员中，5位以学习方式参于。项目中期，由于开发人员的频繁调动，出现了一定的人员风险，但在剩余5位开发人员的努力下，还是顺利的完成了项目。
需求管理方面
项目过程中主要得出以下需求控制经验：
1.竞价通2同样存在需求变更频繁问题。需求要在前期尽量完成(至少80%)，否则在以后研发过程中会影响进度及人力资源安排，以及造成部分工作量的浪费。研发开始后，如果的确需要变更，可以采取按变更流程阶段性提交。
2.需求的规范化。在需求分析阶段，应对业务流程及功能进行反复确认，并按现有业务模拟演示几次，这样会及早的发现需求遗漏的部分，特别是对于有业逻辑的项目，更为重要。书写文档时，可以简单采结构分析方法或面向对像方法中一种（产品部可以只完成业务分析部分），这样不但可以让文档系统化，也可以在业务和技术人员之间找到一种沟通的语言，避免研发开始后再重复去做一些工作。
第三篇：经验教训的总结
识别出经验教训
在项目的过程中，应该经常地收集经验教训典型经验报告。一般是在问题被识别和解决的时候、在过程审核或其他方便的时候进行。在以下情况，更加正式的教训总结应该作为项目评审过程的一部分：在每一个项目阶段结束的正规评审时，或当一个“教训”变得很明显时(通常来说已经造成了“伤害”)。任何教训都应该在项目评审后迅速被利用，或被其他相关项目利用。在项目启动时设置一个经验教训日志，将有助于把这个过程作为一个项目的核心管理过程的一部分。鼓励其使用，并把定期评审日志作为风险管理过程的一部分，将有助于使它对工作团队的工作更加相关和更有意义。伴随着项目进程而持续进行的经验教训的总结，也将使项目结束报告时总结关键经验教训变得更容易。
一直等待到项目结束时再去识别、记录和分析经验教训的危险之处在于，到那个时候大多数项目团队成员也已经将焦点集中在下一个项目上，对上一个项目进行总结的动力有所放缓。因此，只有一小部分可能对未来的项目有价值的经验能被记录和传递。项目经理不能对他的项目进行正式的经验教训评审——评审者需要是一个项目集管理中的独立的一个对等的单位（也可能是项目管理办公室功能的一部分）。项目集管理的作用是提供输入来进行审查或评论。然而，直到所有必需的可交付成果最终敲定之前，项目都不能算完成。如果“总结经验教训”是其中的一个项目要求，项目经理就应该负责确保这个流程被有效地进行。
执行后评审
执行后评审（PIR：PostImplementationReview）也会生成经验教训总结，但这是在项目完成后发生的另外一个过程。执行后评审关注的是要测量项目创造的利益之间的关系，最关键的问题是：“所有的过程都成功了吗？”。
执行后评审应该围绕识别需求、定义项目、执行项目以及项目的交付物为创造商业价值产生多少效益的问题。
经验和教训总结关注“把项目做好”，执行后评审关注的是组织“做好的项目”。
知识的管理
总结经验教训的一个挑战是，如何保障可以很容易地搜集信息和迅速提供给那些有需要的人。组织需要为这些经验教训发展出一个关于客户的清晰的理解。这将影响经验教训总结程序的目标、模板或工具的开发、必要的过程与影响的测量。当前团队的需求很可能会不同于未来的团队和经理的需求。
使系统用户友好和可以有效地记录和检索经验教训是至关重要的。如果经验教训未正确索引或索引并没有反映出该组织内工作的上下文，检索信息是很困难的。关于如何建立一个有效的经验教训知识管理系统的一些有价值的想法已经由美国生产力和质量中心(APQC)发表了。主要的推荐是：
1.确定战略目标
当一个组织设计一个经验教训总结的程序，组织可以追求两个主要的战略路径。一个组织必须定义这些经验教训将被如何使用，以确定最好的方法。理想情况下,一个组织应能使两条路径都有可能实现,认识到这两条路径都需要不同的流程、人力和投资:
第一个，专注于支持当前的进程或项目团队将“经验教训”构建到项目或者过程的管理方法。这需要定期收集经验教训信息，并且项目具有信息的循环反馈系统，使团可以立即得到这些信息。
第二个，专注于创建一个机制,使得经验教训可以提供给未来的项目或用户。经验教训需要被正确的索引、分类和存储在一个可用的检索系统中，使得这个机制具备效率。
2.使经验教训方法与流程优化结合在一起
如果企业拥有广泛部署和成熟的过程或者项目优化方法，一个“经验教训”的价值将会得到明显提高。该组织需要在整个系统中都具有过程改进的能力，所以当项目识别出重要的经验教训,组织可以调整其过程以避免在复现的机会下面再重复出现问题。
3.创立强势管理过程和定义清晰的规则
强势的管理是一个有效的经验教训总结程序的关键成功因素。因为强势的管理提供了一个良好定义的监督和执行的通用方法。所有的干系人都应该知道谁具有过程的管理权限，知道负责支持和执行各个过程的规则是什么。理想情况下，这些应该是一个实体的职责，一个可能是项目管理办公室。
4.将经验教训集成到核心过程
所有的经验教训过程都依赖于良好定义、良好管理、以及有恰当资源的收集活动。通过将经验教训方法整合到项目的计划、启动、执行、监控和收尾过程中，组织可以确保关键的经验被获取。当经验教训的获取和重用被视为工作中的一个关键部分，雇员们就会更倾向于寻求经验教训作为指引。
5.在关键点上发挥杠杆作用
大部分成功的经验教训总结过程都关注与人的互动。训练有素的主持人是抽取和提炼经验教训的专家，能帮助团队发现哪里做得好，哪里做得不好，如何避免问题的发生。这些能帮助现有的团队通过反省进行学习，并且保证经验教训能够被正确捕捉以供未来参考之用。专家还应该对“经验教训”进行梳理和编辑，使得对他们的描述是一致、简明、精确和有意义。这使得信息可以被有效的使用以及避免组织学习“错误的经验”。
6.令获得的经验教训易于访问
经验教训应该是那些有兴趣想知道以前的经验可能会对目前的努力产生什么样的影响的雇员能很容易获取的。这要求具备一个设计良好的内容管理策略，可以通过技术入口进行访问，或者有可能是能多点访问工作经验交流报告。为达到这个目的，需要一个设计良好的知识管理系统，系统具有良好的索引、搜索以及交叉引用功能，系统使用者可以快速地找到相关的数据。这个知识管理系统同样需要具备一个可以将在不同项目上发生的同样的经验教训进行合并的程序。当然，所有贡献经验教训的项目都应该被索引。
7.定期评审和发布经验教训
管理过程应该能够迅速发布那些有用的经验教训，但是不可以在评审和验证上进行妥协。
8.鼓励参与
组织应该提供过程去训练、去设定期望、去帮助雇员发现通过有效利用经验教训而得益的机会。
9.评估进步与影响
当设计一个评估经验教训效果的程序时，应该考虑以下因素：测量信息源与接收者，测量过程和影响，个体和组织的重用性等。对绩效和影响的评估是至关重要的。正确的测量组合可以帮助跟踪进步过程，以及将经验教训的价值示范给项目团队成员、商业领导以及高管们看。知道哪些经验教训被扩展整合到日常工作中可以鼓励参与者并刺激过程改进。
4月28日上午，公司桥梁改建和桥梁新建项目经验教训总结会在公司会议室召开，公司总经理汪云峰，副总经理韩家武、吴红波，总工程师李孝林及各部门、各项目部负责人参加会议。会议由汪云峰总经理主持。
本次会议的议题为：一是对刚刚结束的桥梁新建、改建项目管理过程中存在的问题进行总结分析，为今后类似项目的实施提供管理经验;二是针对公司目前所处的外部竞争环境，进一步提高公司各职能部门的管理水平，降低企业管理成本，适应市场竞争和企业发展的需求。
会议首先听取了桥梁新建、改建项目负责人对项目实施过程中存在问题的汇报，并对今后改进方向达成如下共识：建立项目风险防范控制体系，从经营投标阶段开始做好各项风险分析和管理控制工作;建立健全的项目策划制度，在项目实施前期做好项目人员配备、材料采购、机械设备使用、安全质量进度成本控制等各项管理工作的策划，保证项目实施的可控性、科学性;严格施工组织计划和施工方案上报制度;加强项目安全管理，提高项目全员安全意识，进一步健全人员岗前培训及各级安全交底制度;完善岗位责任制度，实行目标责任考核，加强对项目成本的管理与控制;建立合作单位登记及资信等级分类制度，维持长期稳定的合作单位，确保工程的质量、安全和进度;加强项目部与公司后勤职能部门的沟通与协调，各职能部门要实际深入到项目各阶段的管理，做好各项服务工作;项目各项工作的开展要做到有据可依，公司综合部负责为各项目部提供所需的各项制度、流程等相关文字资料。
会上，公司各职能部门结合部门管理职能，检讨了管理中存在的不足及改进的措施，汪总做了相关指示：综合管理部在制定项目经理岗位职责的基础上，进一步明确项目人员岗位职责，并做好人员调动、离职交接工作;项目每月资金计划拨付款项要做到专款专用，不得挪用;财务部要根据目前财务管理工作中存在的问题，尽快制定和完善相关的流程和制度，制度中应有具体的奖惩措施，其中项目出纳为项目财务管理工作的直接责任人，项目经理为主要责任人;项目资金计划拨付表会签过程中，各部门要做到权利义务对等基层工会工作经验交流报告，对签字同意或者不同意拨付的款项给出具体原因，以帮助项目部进行改进;材料管理工作要加强材料过程控制，完善材料管理手续，降低材料使用中的损耗和消耗，减少库存资金的占用;审计部门要做好过程审计工作，及时发现项目管理中存在的问题。
会上，公司副总经理韩家武、吴红波，总工程师李孝林根据公司目前所处的阶段及管理中存在的问题，分别从加强基础管理和制度建设、健全项目策划制度、加强公司质量安全管理和人员培训等方面作了发言，并指出，问题是企业发展的着力点，是工作的方向，正视和解决问题是企业前进的动力，只有不断发现问题、认识问题、解决问题，企业才能得到持续不断的发展。
会议最后，公司总经理汪云峰要求各职能部门要根据会议讨论的内容，结合公司及项目实际情况，于五月份完成公司现有制度的修订和完善工作，并确保各项管理制度的适应性、有效性、可操作性。
第二篇：项目经验、教训与建议总结
以下是本人在某电子商务项目过程中的一些经验、教训与建议，和大家一起分享，供参考：
项目管理方面
除了常用的项目管理注意事项外，项目过程中主要总结了以下几点经验：
1.项目要想最终成功完成，两种角色不能少，并且要能在整个项目开发过程中给予开发人员指导。一是业务责任人，要求对业务比较了解，对功能需求方向明确，并能随时解答开发人员的疑问。二是技术架构责任人，在开发前期，搭建整个项目框架，制定简单可行的规范，并在开发过程中，跟踪开发人员工作成果，纠正错误。如果项目人员较紧，无法安排专职业务和技术总责任人，可以由项目经理自已担任或批定其它人兼任；
2.竞价通2制定项目计划时，采用两级计划。即针对项目制定一份总计划，功能分解只到模块一级。再制定一份功能分解详细进度计划，要求模块责任人针对单个模块制定具体进度计划，要求将功能分解到至少页面一级。开发过程中，针对详细计划跟踪，及时发现问题和延迟。
沟通管理方面
项目沟通主要体现在产品和研发，研发和测试，研发和各门户等等。由于门户是第三方，且有5个门户，所以在沟通方面，采用以下措施，避免了沟通不畅：
1.如果是项目阶段完成，知识（工作成果）需要从一个部门转移到另一个部门，采用了基于文档的多次培训，讨论会方式；
2.会议，培训正式沟通之外的临时沟通，指定了各部门责任人单一接口沟通方式，使问题可以得到及时的，统一的解决；
3.和第三方门户沟通时，同样双方指定责任人，并尽量制定进度计划，达成一致；
团队建设方面
项目过程中采用了组长负责不同功能模块结构，组长对细节功能进行分解和分工。21位开发人员中，5位以学习方式参于。项目中期，由于开发人员的频繁调动，出现了一定的人员风险，但在剩余5位开发人员的努力下，还是顺利的完成了项目。
需求管理方面
项目过程中主要得出以下需求控制经验：
1.竞价通2同样存在需求变更频繁问题。需求要在前期尽量完成(至少80%)，否则在以后研发过程中会影响进度及人力资源安排，以及造成部分工作量的浪费。研发开始后，如果的确需要变更，可以采取按变更流程阶段性提交。
2.需求的规范化。在需求分析阶段，应对业务流程及功能进行反复确认，并按现有业务模拟演示几次，这样会及早的发现需求遗漏的部分，特别是对于有业逻辑的项目，更为重要。书写文档时，可以简单采结构分析方法或面向对像方法中一种（产品部可以只完成业务分析部分），这样不但可以让文档系统化，也可以在业务和技术人员之间找到一种沟通的语言，避免研发开始后再重复去做一些工作。
第三篇：经验教训的总结
识别出经验教训
在项目的过程中，应该经常地收集经验教训典型经验报告。一般是在问题被识别和解决的时候、在过程审核或其他方便的时候进行。在以下情况，更加正式的教训总结应该作为项目评审过程的一部分：在每一个项目阶段结束的正规评审时，或当一个“教训”变得很明显时(通常来说已经造成了“伤害”)。任何教训都应该在项目评审后迅速被利用，或被其他相关项目利用。在项目启动时设置一个经验教训日志，将有助于把这个过程作为一个项目的核心管理过程的一部分。鼓励其使用，并把定期评审日志作为风险管理过程的一部分，将有助于使它对工作团队的工作更加相关和更有意义。伴随着项目进程而持续进行的经验教训的总结，也将使项目结束报告时总结关键经验教训变得更容易。
一直等待到项目结束时再去识别、记录和分析经验教训的危险之处在于，到那个时候大多数项目团队成员也已经将焦点集中在下一个项目上，对上一个项目进行总结的动力有所放缓。因此，只有一小部分可能对未来的项目有价值的经验能被记录和传递。项目经理不能对他的项目进行正式的经验教训评审——评审者需要是一个项目集管理中的独立的一个对等的单位（也可能是项目管理办公室功能的一部分）。项目集管理的作用是提供输入来进行审查或评论。然而，直到所有必需的可交付成果最终敲定之前，项目都不能算完成。如果“总结经验教训”是其中的一个项目要求，项目经理就应该负责确保这个流程被有效地进行。
执行后评审
执行后评审（PIR：PostImplementationReview）也会生成经验教训总结，但这是在项目完成后发生的另外一个过程。执行后评审关注的是要测量项目创造的利益之间的关系，最关键的问题是：“所有的过程都成功了吗？”。
执行后评审应该围绕识别需求、定义项目、执行项目以及项目的交付物为创造商业价值产生多少效益的问题。
经验和教训总结关注“把项目做好”，执行后评审关注的是组织“做好的项目”。
知识的管理
总结经验教训的一个挑战是，如何保障可以很容易地搜集信息和迅速提供给那些有需要的人。组织需要为这些经验教训发展出一个关于客户的清晰的理解。这将影响经验教训总结程序的目标、模板或工具的开发、必要的过程与影响的测量。当前团队的需求很可能会不同于未来的团队和经理的需求。
使系统用户友好和可以有效地记录和检索经验教训是至关重要的。如果经验教训未正确索引或索引并没有反映出该组织内工作的上下文，检索信息是很困难的。关于如何建立一个有效的经验教训知识管理系统的一些有价值的想法已经由美国生产力和质量中心(APQC)发表了。主要的推荐是：
1.确定战略目标
当一个组织设计一个经验教训总结的程序，组织可以追求两个主要的战略路径。一个组织必须定义这些经验教训将被如何使用，以确定最好的方法。理想情况下,一个组织应能使两条路径都有可能实现,认识到这两条路径都需要不同的流程、人力和投资:
第一个，专注于支持当前的进程或项目团队将“经验教训”构建到项目或者过程的管理方法。这需要定期收集经验教训信息，并且项目具有信息的循环反馈系统，使团可以立即得到这些信息。
第二个，专注于创建一个机制,使得经验教训可以提供给未来的项目或用户。经验教训需要被正确的索引、分类和存储在一个可用的检索系统中，使得这个机制具备效率。
2.使经验教训方法与流程优化结合在一起
如果企业拥有广泛部署和成熟的过程或者项目优化方法，一个“经验教训”的价值将会得到明显提高。该组织需要在整个系统中都具有过程改进的能力，所以当项目识别出重要的经验教训,组织可以调整其过程以避免在复现的机会下面再重复出现问题。
3.创立强势管理过程和定义清晰的规则
强势的管理是一个有效的经验教训总结程序的关键成功因素。因为强势的管理提供了一个良好定义的监督和执行的通用方法。所有的干系人都应该知道谁具有过程的管理权限，知道负责支持和执行各个过程的规则是什么。理想情况下，这些应该是一个实体的职责，一个可能是项目管理办公室。
4.将经验教训集成到核心过程
所有的经验教训过程都依赖于良好定义、良好管理、以及有恰当资源的收集活动。通过将经验教训方法整合到项目的计划、启动、执行、监控和收尾过程中，组织可以确保关键的经验被获取。当经验教训的获取和重用被视为工作中的一个关键部分，雇员们就会更倾向于寻求经验教训作为指引。
5.在关键点上发挥杠杆作用
大部分成功的经验教训总结过程都关注与人的互动。训练有素的主持人是抽取和提炼经验教训的专家，能帮助团队发现哪里做得好，哪里做得不好，如何避免问题的发生。这些能帮助现有的团队通过反省进行学习，并且保证经验教训能够被正确捕捉以供未来参考之用。专家还应该对“经验教训”进行梳理和编辑，使得对他们的描述是一致、简明、精确和有意义。这使得信息可以被有效的使用以及避免组织学习“错误的经验”。
6.令获得的经验教训易于访问
经验教训应该是那些有兴趣想知道以前的经验可能会对目前的努力产生什么样的影响的雇员能很容易获取的。这要求具备一个设计良好的内容管理策略，可以通过技术入口进行访问，或者有可能是能多点访问工作经验交流报告。为达到这个目的，需要一个设计良好的知识管理系统，系统具有良好的索引、搜索以及交叉引用功能，系统使用者可以快速地找到相关的数据。这个知识管理系统同样需要具备一个可以将在不同项目上发生的同样的经验教训进行合并的程序。当然，所有贡献经验教训的项目都应该被索引。
7.定期评审和发布经验教训
管理过程应该能够迅速发布那些有用的经验教训，但是不可以在评审和验证上进行妥协。
8.鼓励参与
组织应该提供过程去训练、去设定期望、去帮助雇员发现通过有效利用经验教训而得益的机会。
9.评估进步与影响
当设计一个评估经验教训效果的程序时，应该考虑以下因素：测量信息源与接收者，测量过程和影响，个体和组织的重用性等。对绩效和影响的评估是至关重要的。正确的测量组合可以帮助跟踪进步过程，以及将经验教训的价值示范给项目团队成员、商业领导以及高管们看。知道哪些经验教训被扩展整合到日常工作中可以鼓励参与者并刺激过程改进。
