工具
组织在实践CMMI过程中，提升和改进研发管理能力的同时，也面临着辅助过程改进工具的挑战，缺少工具支撑，CMMI的规程、流程，尤其量化数据统计分析的推行成本非常高，往往使许多组织望而生畏；实践证明能够很好支撑CMMI落地的工具有：微软Project Server、IBM Rational系列工具、青铜器RDM研发管理系统、TechexCEl DevSuite。CMMI工具至少要满足如下特点：
1. 以项目运作为主线条，至少包含计划进度管理、工时管理、文档管理、变更管理、风险问题管理、量化管理。
2. 强大的流程自定义能力，能够支撑不同组织根据自己的要求自定义相应的流程。
3. 量化数据收集与分析能力，能够自定义项目质量目标，根据项目质量数据自动汇总组织的能力基线；同时要有智能报表能力。
4. 知识管理能力，尤其要实现情境化知识管理，能够将项目历史实际数据直接作为知识进行分享、重用，知识管理要与操作人的行为关联。
5. 工程技术要全覆盖，至少要涵盖需求分析与需求管理、测试管理（测试计划、测试用例、测试执行）、需求跟踪管理、文档管理、评审与验证管理。
人员素质
1、明白什么叫有价值的积累，先是对你个人，其次才是顺便帮公司做了积累。
2、深入一线，发现她们并忠实地记录它们。CMMI里的SP、GP，只是协助你，提醒你在哪个环节，什么东西可能是有价值了。你去收集一下，别视而不见了。由于还有1个企业和你个人的角度不同，立场不同的问题。例如，REQM里收集需求，对个人技术方面的积累尽管不多，但对企业是至关重要的，一次需求变更，没详细写清楚，忘记了到顾客那里去签字落实，可能就会给企业造成很大的损失。做为1个合格的EPG，是必须有这份责任和义务把每个环节都做到最好，这是职业道德所在。同时也是对自我延伸的1个好机会，学会一些和人的沟通，倾听，把专业的东西以平易的方式表达。这些也都算是EPG额外的收获。
通常情况下，为了按时按量完成项目，一线的骨干，对写日报、周报、文档都很不屑。EPG也很迁就，事后再补，这也不失为1个提高效率的好办法。但过去1个月半年了，我们正常人的记忆都能想象，很难记住细节。无非就是敷衍。这也在情理之中。你总不能让1个明天就要交东西的小组，今日晚上在通宵努力解决BUG的同时，还写什么报告，这也不尽人情。但作为EPG不能只把眼光集中在这妇人之心上。要想的更远。为何会把项目推到这么晚，BUG还没解决完?难道要永远这样下去吗?项目中是有许多不可预测的因素，甚至是开发人员常说的"手气问题"，"人品问题"。但这些是必须控制的，也是通过经验能够控制的，所谓艺高人胆大。艺的高低，就是经验的积累决定的。
那怎么解决这种两难的问题呢?逼着技术骨干写心得，人家没时间也的确压力很大。不写，公司又得不到有效积累，积累的都是垃圾流水。有个公司的办法和经验到能够借鉴一下：
公司内部搞了个BBS，把不同类型的工作分成不同的组，有纯技术的，JAVA组，C++组等，也有PPT组，甚至动画组，界面组。大家把自己平时的工作积累FTP上去，甚至制作方法，遇到问题和解决方法的文档都丢上去，开始怎么想，用了多少套方案，最后选择了什么。自我感觉怎样。把这些心路历程都写成文档。丢到阳光下，大家评论。用点击率和"顶"的人数而言明谁写的是心得，谁在写垃圾。大家都是1个公司的，很容易实名。直接纳入考核机制中。做为一线人员，大家也有动力来写，自己的聪明才智有了展现的平台，虚荣心和荷包都得到了相应的满足。何乐而不为呢?
EPG适时的评估大家的成果，并把他们分到项目里。协助项目总结，甚至在平时遇到问题时，直接协助技术人员做必要记录。项目进度松时，再督促项目人员完善内容。以达到对个人和公司积累的最大化。
EPG应该明白学习和积累是个终身的过程，对公司如此，对个人也是如此。CMMI是个辅助，辅助我们对公司做积累，也协助我们个人做必要的积累。公司必须逐步走向更高的管理水平，发展平台。
