项目中常见的变更有两种，“范围变更”和“需求变更”。 

     范围变更可以通过事前<工作说明书中>中的明确定义进行界定，判断和管理都相对简单。对于工作范围中没有定义的内容，项目经理就可以明确拒绝（但怎么说“不”非常有讲究！），并可以转化成为商务问题由销售出面解决。 

　　而需求变更不但数量大，且界定和管理都要复杂的多。软件项目中，例如界面风格的改变，数据库字段的变化等，都涉及极大的工作量，而且在需求分析阶段很难保证一次正确。我所在的公司中，这类变更也是让项目经理最头疼的。 

•  评估：请技术人员对于变更的涉及的范围，引发的工作量和风险，以及对进度的影响进行客观的量化评估。切忌不可夸大，否则会丧失客户的信任，造成额外的困难。  项目管理培训
bbs.mypm.net
　　•  确认：将评估的结果与客户一起进行讨论，与客户一起决策。告诉客户“我可以改，但对项目的影响是…”，客户也是讲道理的，大多数情况会达成一致。即使有时客户一时难以接受，但讨论的焦点也会集中到客观的评估结果上来，而不是涉及项目经理的性格、甚至对客户尊重不尊重的这类问题。 
     项目管理者联盟文章
　　上述方法是变更管理的基本要点。但如果只能执行管理流程，对项目经理来说那才仅仅是及格。优秀的项目经理，还能够在这个过程中保持甚至加深与客户的关系！   blog.mypm.net

　　如何做到这点呢？理解客户！仔细思考就会发现，客户需求的表面之下，往往隐含着真正的“需要”。举个生活中的例子，买衣服时对颜色、款式和面料等会有多方面的需求；而这之下隐含的需要却可能是为了“御寒”，可能是为了“漂亮”，还可能是为了“体面”。如果能够弄清客户的需要，往往能够提供服务时能起到事半功倍的效果。  项目管理培训

　　这里，我想用所在公司内部的一个最佳实践案例说明：  项目经理博客
项目经理博客
　　小H貌不惊人，甚至一着急还会有点口吃。刚刚被提拔负责一家银行的报表系统开发。本来进度已经非常紧张，但客户负责人突然要求增加十几张报表，并要求一周内必须完成。一个开发组长为此与客户发生了激烈的争执，双方都非常生气。 

　　小H知道后，直接找到了该客户。  项目经理博客

　　首先，他对下属的行为进行了道歉。之后，问了一个非常关键的问题：“为什么这几张报表这么急？”。听到小H这样问，客户情绪已经缓和了许多。于是介绍说，这是行长会议的决定，为满足新的监管要求必须限期完成。他本人已经向行长作出了承诺，压力也很大。 
项目管理者联盟
　　小H说：“你的难处就是我的难处！保证在本周内完成这些报表！”。听到小H这样说，客户已经变得有点感激了。没等小H开口，便说：“这事最急，其他可以先放放”。 
项目管理者联盟
　　经过两个人的沟通，一起修改了项目计划：立刻开始新报表的开发，同时将10张报表移到二期开发。而此后小H便与客户成为了好朋友，持续从客户那里拿到项目，项目规模也越来越大。每次客户的签约时的条件之一就是小H必须是项目经理，直到几年后小H被提升为公司的一名高级项目经理。 
    
　　项目中的倾听和理解是多么最重要！而真诚的沟通，更是远比那些所谓“红脸”“白脸”的技巧来得重要. 

　　因为范围变更相对容易，接重点谈谈如何管理“需求变更”。先要扭转一个观念：管理变更的目的绝对不是不让客户变更，更不是扳着面孔一口回绝，而是要让变更受控，让变更有秩序的进行。  bbs.mypm.net

　　为此，一个比较有效的方法是在项目开始前就制定变更管理流程，并与客户达成一致。 

　　变更管理流程可以根据项目的具体情况设计，但个人认为有四个关键控制点一定不能放松，那就是：授权，审核，评估，确认。  项目经理博客
项目管理者联盟
　　•  授权：只有经过授权的客户接口人才能提交变更单，只有经过授权的项目接口人才能接受变更单。这样做一来可以保证变更都被有效记录，二来可以避免客户内部尚未达成一致的变更被提出来。 

　　•  审核：项目经理要对书面的变更分析，分出轻重缓急，并与客户沟通。哪些应该回绝，哪些可以推迟，哪些可以接受。经过项目经理过滤之后，变更的数量应该可以大大减少。