1. 建立正式的申请和处理流程
虽然众多项目管理人员对于变更可能带来的巨大影响有深刻的理解，但令人不解的是我们常常看到这些变更的提出、讨论和执行却常常停留在口头上。这样做有两个弊端：首先是时间一长，无论是当事人还是开发团队的其它成员都说不清楚变更是因何发生以及结果怎么样了。显然，这对于提高项目管理质量、改进开发过程是很不利的。其次是由于缺乏形式上的约束和对变更冲击的定量化分析，变更会被非常随意地提出、或被草率地执行，大大影响了项目的进展和开发质量。因此建立一个正式的变更处理流程并真正得以实施非常重要。
2. 定量化的变更冲击分析
变更作为一个计划外的风险因素对项目肯定存在冲击，只是大小的差别。因此，如果能够定量化地评估变更带来的影响就能帮助开发团队作出正确的应对决策。这就是变更管理中的冲击分析环节。上面谈到了，分析的基础是追踪矩阵，它记录了项目管理要素之间的联系关系。从这些关联关系中我们可以找到每一个潜在会受到影响的要素，评估对其的影响，从而组合出变更对整个项目可能造成的冲击。
从上面的例子可以看到，即使是加了一个看似与其他关系不大的需求，也会造成一系列的潜在影响，更不用说是在需求众多、关系复杂的大型应用系统开发项目中了。
3. 组成变更控制管理委员（CCB）
作为变更管理的一个核心控制环节，变更控制委员会（简称CCB）起决策和管理作用。它通常由客户代表和开发团队代表共同组成，负责评估变更冲击以及 决定是否要实施这样的变更。这种综合了需求方（客户）和开发方（开发团队）力量的委员会能够较好地权衡变更代价，从而减少了单方面考虑变更所带来的不利影响。
4. 不要忽视变更执行的管理
在实践中很多开发团队虽然组成了CCB并有一定的处理流程，却往往忽视了对于变更执行的管理。而变更实施的好坏、完整性对于项目本身的影响同样是巨大的。在这方面，根据冲击分析和变更评审的结果，建立一个变更任务列表并且追踪它的执行是一个很好的实践。
总结
软件项目与传统的工程项目有着很大的不同，这种不同导致描述需求的方式，实现需求，进行项目计划、监控项目进度的方式都有很大的不同。由于这种不同，传统的基于任务的项目管理方法对于应用类的软件项目并不适用。这里我们提出以需求为中心的软件项目管理。 通过提高需求描述的质量、采用小版本发布策略、将用户需求作为小版本的目标来组织和计划项目开发、积极应对需求变更、提供以用户需求为中心的项目进展视图，从而和客户一起来保证项目的成功。