6、违背了循序渐进的思想

　　“以人为本，以过程为核心，以度量为基础，循序渐进”是当前各种管理模型的核心思想。管理的改进是文化的变革，要改良而非革命，不能拔苗助长，要冷水煮青蛙。一些软件开发中的基本实践看似简单，在企业里推行时却会困难重重，比如：需求文档化、设计文档化、计划文档化、同行评审、专职的测试等等。往往迫于商业目标的压力，在过程改进时，EPG会定义不切实际的改进目标，试图短期内见效，这样就要求项目组一次改进的地方太多，而这么做，很可能事与愿违，导致项目组比较抵触，即使短期内能够通过评估，一旦拿到证书，反弹也会比较大。

　　7、忽略了裁剪指南

　　裁剪指南比体系本身更重要。僵化的体系是不可能真正在组织里推行下去的，要保持体系的灵活与敏捷，就必须定义详细的、实际的裁剪指南，并在实践中逐步完善。EPG的成员往往试图包罗万象，将体系定义的相当完备，在过程定义、模板定义上花费了大量的时间，而忽略了裁剪指南是体系的更重要的部分。这样导致在实际推广中，体系可以裁剪的选择余地很少，针对具体的项目组，往往会让项目组多做一些无法产生价值的活动，这样项目组就会产生一些抵触情绪。

　　8、忽略了持续培训

　　在过程改进的初期会做CMMI的 introduction培训、过程域培训、管理技术的专题培训，在体系定义完成后，会做体系的培训。那些培训要么是集中在一段时间完成了，培训的密度比较高，效果并不好，要么间隔的时间比较长，培训后面时忘记了前面的内容。因此，需要在体系的推进过程中再将已经做过的培训的要点换个角度进行强化，使一些观念、一些做法深深的刻在每个人的脑子里，这样才能成为习惯，才能让执行者能够知其然，知其所以然，持之以恒地坚持下去。

　　9、缺乏足够的软件工程经验

　　这一条实际上是在选择EPG成员时犯的错误。以CMMI模型的博大精深，要想充分理解其内涵，理解其精神，没有足够的软件工程背景是比较困难的。而很多企业的EPG成员恰恰就缺乏足够的软件工程经验，有经验的员工都去生产一线做项目经理、做部门经理，去直接创造商业价值了，间接创造商业价值或者会带来长期效益的管理活动便让一些缺少经验的人来做了，这实际上一种“脑体倒挂”。缺少经验的人需要到一线去工作，去锻炼，去提高，那些有经验的员工则需要充分贡献出其经验，充分发挥他们在企业里的正面影响力，而不是成为过程改进的阻力，这才是他们的价值的体现。

　　10、过分依赖咨询公司

　　EPG成员在建立公司内部过程体系的初期，往往会过分依赖外部咨询公司，要求咨询公司提供已成型的过程体系文档。每个组织都有其自身的特点，产品方向可能不同、组织结构可能不同、企业文化可能不同、人员结构可能不同、外部的商务环境也可能不同，因此企业的作业流程、文档格式等都可能不同。如果机械的照搬，那么势必会造成EPG建立的标准过程并不适合本组织，从而使过程改进见效缓慢，甚至夭折。