因此，项目管理不是分立的，在企业内部是需要通过管理逐步成熟。当然，对这个的理解，也是后来慢慢体会的。这得益于公司开展的一些培训，个人参加业内的一些交流活动和自身的认证。

　　在公司项目运作了一段时期后，领导认识到分立的项目管理在资源共享、风险控制方面的不足，恰逢那个阶段CMM认证刚刚风行。于是，公司便拿出一笔钱，要通过CMM2认证。个人很幸运参与到这个认证过程中，并被指派为EPG组长。

　　起初，我个人对这样的认证比较反感(相信很多公司的技术人员都有同感)，认为更多是要求大家多写一大堆文档，项目的效率和质量不一定能提升(很不幸，后来认识到老板也是这种态度，导致项目认证的终止)。在做完项目管理流程制定和后期较长时间的实践后，自己对它深邃的内涵有了深入理解。

　　关于CMM体系，相信大家现在已经很有认识了，它将组织成熟度定义为5个等级--初始级、可重复级、已定义级、已管理级和优化级。对于CMM2，简单的说可以认为它是项目级的，即建立了项目管理体系;CMM3 是组织级，强调软件工程过程和管理过程已经被定义和集成。从上面的定义，我们可以看出CMM2主要是建立体系的项目管理制度，是有意义的。

　　在开展CMM2认证的过程中，涉及费用问题，我们选择了一家不是很知名的认证公司帮助咨询(当时CMM认证公司还很少，费用也很高的30-50万)。公司先从各行政部门抽调1-2名工程师作为CMM2认证组成员，然后咨询老师便开始了枯燥、单调的CMM培训。在大家基本了解什么是CMM2之后，开始依据公司现状建立项目管理制度。这个过程是最痛苦的过程。因为本身技术人员在文档撰写工作方面不是很有心得，特别是制定一个从无到有的项目管理制度本身就很有挑战(改变一个人的行为方式是很艰难的，制度的制定势必会激起很多所谓的冲突)。若干个KPA的程序、规程、指导书、模板、checklist等都经历了2 -3遍的撰写、评审和修改，CMM项目组很是疲惫，大家占用了大量的业余时间。

　　最后，终于将体系文档建立起来，进入实际项目参照执行阶段。问题恰恰就在这个阶段爆发了。前面提到，老板有改进的初衷并投了资，同时却对CMM2认证有一定个人成见。在项目参照执行阶段，原计划选定的2个项目组，由于涉及项目产品上线的压力和部门经理的阻力，老板大手一挥--暂不执行认证!于是，认证很遗憾的停止了。但是，整个EPG组整理的项目管理制度和体系后来在大家的努力推动下被落实下来，对项目成功运作打下了坚实基础。特别是，这个过程培养了一批在项目管理有深入理解的人才。

　　这批人深入理解了项目管理中需求管理的重要性、项目计划制订的严谨性(项目计划包括进度计划、配置计划、质量保证计划等)、变更的严格控制和项目总结(日常、milestone和项目收尾的总结)。这些是项目成功的基础，也是cmm2中的精髓。

　　进一步说，项目管理的成熟可以参照CMM/CMMI 5层等级的思想来描述，1-5级的项目成功的关键可以用下面这个QA作用图来描述：

　　我们可以看出，低成熟度的项目管理的成功更多工作是通过在过程中的指导和监督来保障，而高成熟度的则是通过在组织内部的度量和过程改进，用数据、制度来保证项目的成功。

　　也就是说，在低成熟度等级下，需要抽取各项目最佳实践来定义过程，并指导过程的试施， QA 在这方面的工作最多。随着过程的完善、制度化和实施， QA 的工作重点逐渐转向了过程评审和产品审计。当企业的过程成熟度达到 4 级或 5 级以后，对过程的遵守已经成为员工的一种习惯，过程和产品的审查需求减少，而度量和过程能力的优化又成为 QA 的工作重点。

　　现在，我们国家的项目管理多处于l2-l3的地位，如何整理最佳实践定义过程指导项目开发是项目总监的重要工作。最佳实践有哪些?需求撰写、需求评审等等，从实践来到实践中去。

　　回过头来看，一个组织如果提升其项目管理能力，来自内因的动力是最关键的。在这种动力下，人们制定的流程、规范是切合实际的，落实也是扎实的，也能理解、把握 CMM等管理模型的深邃。如果改进的动力来自外因，通常是所谓的“不通过某某认证公司无法接什么什么项目”，那么它的学习是形式化的，势必被开发人员、项目经理最终抛弃，走入形式化。

　　正是通过CMM2这个项目的锻炼，培养了我系统思维、步步为营推进的工作习惯，也使得自己在项目管理方面获得了升华。拓展了视野，打开了与行业同仁交流的窗口!