项目管理案例讨论“如何有效开展项目变更管理”

[ 日期：2019-3-14 ]

项目变更管理是指项目组织为适应项目运行过程中与项目相关的各种因素的变化，保证项目目标的实现而对项目计划进行相应的部分变更或全部变更，并按变更后的要求组织项目实施的过程。

项目变更管理的目的是以一种对于项目影响最小的方式改变现状。它包括以下主要内容：

(1)了解变化。在项目实施过程中，项目组织要经常关注与项目相关的主客观因素，及时发现和把握变化，认真分析变化的性质，确定变化的影响，适时进行变化描述。

(2)进行变更处理。当变化了的各种因素影响到了项目的顺利实施时，项目组织必须及时进行计划变更，以确保项目目标的实现。项目计划的变更应征得项目主体的同意，项目组织还应及时向其反馈变更及变更执行情况。

(3)监控变更合理性。变更处理总是根据项目实施的客观需要进行的，但并不是每次变更都是合理的。

项目变更因多种变化而存在，其形式也多种多样，但主要的有以下几种：

(1)项目范围变更。政治因素、法律因素和技术因素多种因素都会影响项目范围，而且这种影响在一定条件下是无法抗拒的。

(2)项目进度变更。

(3)费用预算变更。

(4)项目合同变更。项目合同变更通常是指由于一定的法律事实而改变合同的内容和标的的法律行为。在项目合同变更时，当事人必须协商一致，这将会使合同的内容和标的，亦即使项目发生变更。合同变更的法律后果将产生新的权利和义务关系。

(5)项目人力资源的变更。

案例：一家中国、欧洲合资的汽车零部件公司，中方公司控股，为汽车主机厂提供系统总成产品。

项目A的目标是为客户准时交付系统总成。该项目有两家客户，欧洲有一家客户，中国有一家客户，两家客户也是欧洲母公司和中国合资公司的关系，主要由欧洲母公司负责主要的开发工作。

该总成由120个子零部件组成，且该系统总成产品的技术成熟度不高，没有平台产品可供参考，开发难度大。主要产品开发团队在欧洲(欧洲母公司)，主要的采购、供应商质量保证及生产团队等在中国(合资公司)，相当于欧洲有一个项目团队，中国有一个项目团队，两个团队协同完成该项目；此外，欧洲有一个项目经理，中国合资公司也有一个项目经理，且欧洲项目经理权力大于中国合资公司项目经理。

目前项目A处于设计冻结和下级供应商定点及模具开模的关键节点。虽然产品的设计方案并没有经过完整充分的验证，但是迫于进度的压力，项目组决定冻结目前的设计方案，启动下级供应商的定点和子零部件的模具开模工作，即产品验证试验与子零部件供应商定点及模具开模并行进行。

欧洲团队有一个更改管理系统，涵盖了更改需求提出、更改评估、更改批准、更改实施等环节，而中方没有。

案例项目存在的问题

1、由于设计成熟度不高，即使设计已经冻结，但是子零部件的技术方案变更频发。下级供应商刚要开始启动模具的制作，变更就发生了。如果持续等待变更，进度来不及；如果不管变更，后续出现模具报废的可能，项目将陷入两难的境地；

2、由于变更频发，整个项目的材料成本不受控；

3、欧洲团队与中方团队并没有公用的变更管理系统，导致有些变更信息不能及时由欧洲传递到中国，有些变更的决定在没有参考中方团队评估结果的情况下就被执行了。会出现中方采购在使用旧版图纸让下级供应商进行模具制作。

案例项目需解决的问题

在这种情景下，如何在材料成本受控的情况下按时顺利完成下级供应商定点工作？

案例补充

1、首先，欧洲这个公司是一个比较成熟的企业，各种系统和流程比较成熟。合资公司成立的时间不长，还没有相应的流程和系统。因为主要的研发工作，包括研发的输出结果都在欧洲完成，因此合资公司要通过欧洲系统才能实施变更(获得更新的图纸，技术文件等)。目前变更信息共享的方式：只是通过邮件和周例会的形式，对接人比较多，且信息传递不及时。

2、中方评估变更主要有3方面：

1)虽然主要研发工作在欧洲，但是中方也有开发人员参与，也会提出一些优化方案；

2)生产线的设计团队在中方，变更会对产线方案产生影响，因此需要评估；

3)主要的采购及供应商质量团队在中方，下级供应商端的对变更的评估信息需要中方与供应商沟通并传递到整个团队。

3、项目控制委员会：通常是欧洲的项目团队先会向欧洲的评审委员会汇报项目状态，然后再向合资公司的评审委员会汇报。委员会构成：合资公司的总副经理，欧洲的项目总监及技术总监等四人组成。委员会权限：负责整体项目状态控制，同时控制重大变更。确认该项目是否具备相应的成熟度往下一个里程碑走，并提供相应的资源支持。

4、变更的决策：在欧洲，欧洲的项目经理会跟Team沟通后，自己做变更的最终的决策。但是在合资公司，目前没有明确的流程规定，项目经理没有这么大的权力，由领导层做决策(变更控制委员会)。目前所有的技术变更都是批准的状态，还没有被拒绝的情况出现。

案例应对措施回顾

针对问题1的应对措施：

整个团队对每个零件从技术成熟度(试验完成情况，供应商反馈等)、质保、生产工艺等几个角度形成成熟度的综合评估。把成熟度分成几个等级，根据成熟度分批次进行供应商的定点和模具启动。决定定点和启动模具的部分立即执行，如果后续出现变更再走变更流程，从而保证Timing。

( 注：成熟度大体的逻辑就是每个部门打分，每个部门的权重不一样，工程部门的验证完成情况比重最大。成熟度是给项目控制委员会汇报过的，领导批准的。)

针对问题2的应对措施：

每两周，根据变更的情况和零件定点的情况梳理材料成本，并向项目控制委员会汇报，从而控制材料成本。

(注：该委员会对单体和整体的费用都进行控制，但存在双重项目管理的弊端。两个团队并行工作会存在一定的问题，计划进一步明确双方的职责划分。对于变更管理，后续的计划是大家利用一个系统，实现整体的项目变更控制。)

针对问题3的应对措施：

欧洲团队派一个人常驻在中国合资公司的同事，该同事有欧洲的系统权限，并作为欧洲团队与中国团队数据传输和更改管理的枢纽，即：中国团队可以通过他及时获得欧洲的变更通知，并把中国团队的评估结果通过他及时反馈给欧洲团队；同时，中国团队可以通过他可以及时获得最新的SOR(Specification of Request)、Drawings 等技术资料。为了变更的及时性，变更的决策主要还是由欧洲的团队或者说欧洲的项目经理做决定。

嘉宾总结

类似的案例在合资项目、合资企业和当前快速迅捷、复杂项目环境下还是比较常见的。这个案例感觉更像是个项目集，而且是双头管理、跨文化、跨部门的项目集管理。

项目本身又牵涉未成型的新品研究，变更管理的复杂多变程度可想而知。

第一，针对这种局面，案例应对措施中显示合资公司已经认识到情况的严重性并采取了一些措施。个人建议，项目管理委员会成立之后，也许还可以视情况发展看是否需要设立、任命项目总经理，把责任、界面理的更清楚些。

第二，变更管控方面，除了内部已经采取的措施之外，对外部供应商相关联的变更管控也可以整合到项目整体变更管理控制体系中。这个整体变更管理控制体系建立运行起来后，不妨在变更的预判、提前介入上多放些精力。

第三，如果有必要，可以通过专题的周例会、管理委员会的双周会加强对复杂、重要变更的管控。

第四，项目管理委员会中建议添加商务、法务、财务人员进去。其中，财务人员是要针对费控的，对项目推动可能会有“反”作用，但这有利于增加变更管理控制的各方面平衡，因为过度合意是变更控制和项目管理的一大忌。

评论：如何有效控制需求变更

需求变更对软件开发项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以实施需求变更之前必须做好控制。需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。

(1)明确合同约束，建立需求基线 需求变更给软件开发带来的影响有目共睹，所以在与客户签订合同时，可以增加一些相关条款，如限定客户提出需求变更的时间，规定何种情况的变更可以接受、拒绝或部分接受，还可以规定发生需求变更时必须执行变更管理流程。虽然软件开发合同很难在签订之初就能够精确定义每项需求，单靠合同是帮不上忙的，但也不能忽视合同的约束力。 明确和树立需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(客户参与评审)，建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线，做到小需求可以变更，但大方向要力保不频繁变更。例如，对于项目中的需求，可以实行分级管理，以达到对需求变更的控制和管理。

(2)建立变更审批流程 在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低开发效率，浪费时间。正是这种观念才使需求变更变得不可控，最终导致项目的失败。因此，小的需求变更也要经过正规的需求管理流程，否则会积少成多，积重难返。 明确需求变更审批环节、审批人员、审批事项、审批流程。这么做的目的有两个：一是将客户下达变更的流程尽可能地规范化，减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的无效变更。二是留下书面依据，为今后可能的成本变更和索赔准备好“变更账”。凡未履行审批程序的“变更”，一律是无效变更不予受理。

(3)分级管理变更，定时批量处理 软件开发项目中，“客户永远是对的”和“客户是上帝”并不完全正确，因为在已经签定的项目合同中，任何新需求的变更和增加除了影响项目的正常进行以外，还影响到客户的成本投入收益。因此，用户不断提出对项目进度有重大影响的需求对双赢也并不是好事。 当遇到客户提出需求，不及时处理可能会使项目不能验收通过时，也不能一味拒绝不予开发。因此，当客户坚持变更新需求时，可以建议客户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。例如，每周或每两周甚至每月召开一次需求变更专题会议，集中研究处理这些零碎变更事项，主动控制好工作节奏，尽量避免由于处理零碎变更而影响项目进度。针对会议结果可向客户正式提交一份需求变更计划，注明变更引起的时间、成本、工期代价和增加工作量等。要求客户配合需求变更计划，确定变更时限，控制变更规模，过时变更不候，离谱变更不做，保大局弃小变。

(4)安排专职人员负责变更管理 有时开发任务较重，开发人员容易陷入开发工作中而忽略了与客户的随时沟通。因此，需要安排一名专职的需求变更联络人员，负责与客户及时交流，跟踪和汇报需求变更完成进度和情况。同时，可以成立项目变更控制小组，负责裁定接受哪些变更，小组由项目所涉及的多方人员共同组成，应该包括客户方和开发方的决策人员在内。

(5)确认客户是否接受变更的代价 要让客户认识到变更都是有代价的，要和客户一起判断需求变更是否依然进行。例如，变更是没有问题的，但是要明确客户能否接受由此引起的如进度延迟、费用增加、效率下降等问题。一般来说，如果客户认为该变更是必须的(不是其上级领导拍脑袋提出的)就会接受这些后果。通过与客户协商，这样开发团队即使没有回报，也不会招致公司和客户双方的埋怨。 如果客户认为该变更虽然有必要但是可以暂缓，双方签署备忘录后留待以后解决。如果客户认为该变更可有可无，多数情况下会取消变更。这样即可防止频繁变更，也让客户认识到不是所有的需求都需要变更。