一群对于过程改进有热情的组员是试点成功的保证。他们要有热情去学习新的流程，要有热情去沟通在执行新流程当中遇到的问题，他们要有热情去克服进行中的困难，而不是抱怨，他们要有热情去总结和改进新的流程，使它更完善，最总要的是，他们要有热情作为新流程的传播者，把流程象星星之火一样在组织中开展。一个坚决支持过程改进的领导是必不可少的。象任何其他的变革一样，一个坚决支持变革的领导是不可缺少的。在一切顺利，大家赞成的时候，也许感觉不到什么。但当变革遇到阻力，遭受暂时的困难时，这种坚决的支持就是变革是否可以继续进行的保证。因此，在过程改进的初期，于企业的高层进行沟通，让其了解到过程改进的必要性和预期的前景是十分必要的。同时最好在过程改进的开始阶段，一个誓师大会的举行也是鼓舞士气的上佳方法。在过程改进的过程中也要注意及时的通报进行的过程，取得的成果。当然在遇到困难，或需要高层支持时，更要及时开口。(这对于技术人员主持的过程改进尤为重要。)要有选择的对于KPA进行改进，不一定是最薄弱的KPA，最重要是选择你可以控制的KPA。关于这点其实并不涉及CMM的技术问题，而是一个管理问题。这里有个现实的例子，一家企业的管理有点乱，高层希望可以通过CMM的过程改进，来提高企业的产品质量，理顺工作的流程。于是任命了一个开发组的主管(代称A)，来主持这个过程改进。 结果A在选择KPA的时候，认为首先应该对于实行需求管理和变更管理。因为开发组的同事们都抱怨，需求经常改变，造成的返工很多，在最终期限的压力下他们不得不经常加班。 这个本事没有问题，可是需求管理和变革管理的发起基本是在系统分析组，而这个组在行政上不归他管。公司也没有因为要进行过程改进而把他提高到一个高的级别(即使是暂时的)。
现在问题来了，虽然他花费了心思去设计的流程。并对于需求部门和相关部门组织了培训。可是在进行试点的时候，他发现，当他去评审需求分析组的工作时，别人很反感。而且对于有些需求的变革也推诿到销售人员、客户等因素。同时，流程中只要有一点不太合理的地方，就抱怨的很厉害。最后试点结束，他自己很累，试点的结果也不好，改善的目标没有实现。整个过程的改进处于一种微妙的处境。最后，试点的流程并没有推广。其他的KPA过程改进也不再进行了，随着时间的推移，过程改进在企业中也不在有人提起。知道这位开发组的主管错在哪里吗? 他选错了KPA，他选了一个不属于自己管辖范围的KPA作为起点。他跑到一个不属于他的地方开始指手画脚，他是个不受欢迎的人。注定了，在一开始他就面对着对立和抱怨。这样的团队是无法经受一点点挫折和失败的。若他一开始选择配置管理，这个至于他管理范围的KPA，他可以利用手中的权利、资源和威信，组织试点。可能情况就好的多。 又或者企业的高层给这个开发主管一个虚职，比如过程改进项目组组长，并任命其他组的组长为过程改进项目组成员。情况也会完全不同。
对于过程的改进要有度量。不必一开始就是数字化的，也可以是感性的体会。但要把这些也要收集起来。 一个有力的对比可以堵住反对者的嘴。不要因为度量管理是CMM4级的内容就在实施低级别的CMM时放弃度量。一套流程需要一系列度量的数据来说明它改进了多少。而度量的数据将会为它赢得预算和支持。当然度量作为CMM4级的内容，也是有一定的道理的。收集一套完备、准确的度量是需要大量人力的。但是在一开始，也许我们可以借助一些好的工具达到同样的效果，而不必花费大量的时间和精力。在我就自己做过一个简易的BUG管理工具，并和数据库相连。在项目结束时我可以轻易的了解项目中有多少BUG、BUG分布如何，BUG的原因统计等度量数据。我只是用了几个SQL语句就掌握了我需要的度量。
另一个例子是微软推出的PROJECT SERVER(注：不是广告)。以前项目经理要了解实际的项目进度并不是件轻松的事，项目经理要去问组员××模块，你开发的如何啦?然后收集好所有组员的进度，填写自己的项目进度。由于这相当的花费时间，过去进度基本上一周汇报一次。 可是有了PROJECT SERVER你只要按个‘请求进度’的按钮，组员直接通过WEB填写与他相关的进度就可以了。项目经理就可以得到整个项目的进度了。不必拘泥于CMM的级别。这一点在CMMI中已经有体现了，CMMI不再只有一种级别的模式，还增加了持续改进的模式。即，可以按过程域进行改进，而不是过去按级别进行改进。比如，CMM5级的技术革新管理。其实，在现在新技术层出不穷的当今，一个企业不会因为还没到CMM5级就不需要技术革新管理。换一种数据库，换一个开发工具，甚至是换一种开发过程等都是一直发生的。若需要完全可以把这个KPA先实施改进。不是每个人都喜欢改进的过程，特别对于要增加其工作量的过程。有时必须牺牲一些过程的严谨性，去简化过程。毕竟有过程比没过程好。也许在看到了这条时很多人会不以为然，说：这样做肯定过不了CMM评审。对，这样确实肯定过不了CMM级别的评审，可是只要可以对于过程有改进，对于软件质量有提高，就可以了。对于中小软件企业，一个有效的(可以满足高层对于过程控制的期望)，简易的(是所有基层工作人员可以理解的，无须大量培训的)，可行的(不会大量增加基层人员的工作量，不会影响开发速度和效率的。 名言是：‘我不要那种原先2天可以完成的项目，因为应用了过程，现在要5天才可以完成的所谓的过程’。)和低成本的(公司一年才赚多少，我可不想把钱全用来采购工具软件)过程才是最重要的。
