项目变更在所难免。项目的任务、期望及组织的最终目标，都应根据业务变化而变更。
实际上，项目实施过程中进行变更并不总是坏事，很多时候还是一件好事。首先，客户通常都不能确定其所希望的解决方案具有何种功能和特性。其次，就算客户十分清楚终极目标，商业环境亦会随着时间不断变化，因此项目的需求也会发生变化。 对于公司内部的软件开发过程，额外的功能能够让你的产品比你的竞争对手更胜一筹。但是，如果你发布软件的时间推迟一两个月，那么这个优势就会丧失。通过控制你开发过程的费用并按时发布软件，你的项目就会取得成功，而不需要损失软件制作过程中的灵活性。 总而言之，不论你喜欢不喜欢，项目的变化总是在那里！变更不可避免。
站在实施方（乙方）的角度，项目过程就是“绑架客户上咱们贼船的过程”，而站在委托方（甲方）的角度，项目过程就是“逐步移交主动权的过程”。 实际上，发生变更不是问题，问题是许多变更处于“非管理状态”
一个变更管理的流程示例如下：
在变更时，需要界定以下几个问题：
·变更发生时要确定你能做些什么以及不能做些什么。
·规定一个大家都同意的办法，以便提出变更并评估其对项目基准的影响。
·说明批准或者不批准变更所需的时间、费用。
尤其重要的是，要明确以下工作：评审变更会引起哪些连锁的变更，以及如何对这些变更进行管理；变更效果达到后要不要更改管理标准等。
变更是不可避免的，当变更发生时，一定有要正式的变更机制，冷静应对。可以变更，但要经过一些程序、填一些单子，当然还得等上一段时间。
有时候客户喜欢变更是因为你喜欢接受客户的变更请求。这简直是一个悖论，因为没有一个项目管理者喜欢变更。当客户提出变更，假如你顶不住压力同意了变更，这在事实上会给客户一个信号：变更是可以被接受的，只要对项目团队施压就行。你要“谨慎对待客户的第一次变更要求”。能否用一个正式的理由拒绝第一次变更至关重要。需要说明的是，这个正式的理由必须是在项目开始前就制订好的规矩。一个临时搬出来的规定往往会被视为一种强词夺理，极可能会激怒对方。
项目变更的审批可以参考下表：
你如果想改变在变更中的被动局面，必须改变一下过去那种小心维护客户关系（简直是讨好）的行为，营造一切按照规矩行事的文化。
