工程变更要灵活应对

newmaker

欢迎访问e展厅 展厅 3 管理咨询与服务展厅 企业文化, 战略管理, 生产管理/工业工程, 营销管理, 知识管理, ... 变更，有人欢喜有人忧 对待变更的两种心态 项目很少会准确无误、一成不变地按照项目管理计划进行，因而变更控制必不可少。其实在项目监控过程中，最花费精力的一项工作就是变更控制。 随着项目进展，项目干系人会提出这样那样的变更请求，每一个做项目的人都要有这样的心理准备，变更是不可避免的。 所谓变更请求，就是因扩大或缩小项目范围、调整进度、更改费用或预算，以及修改策略、过程、计划或程序等而发出的请求；所谓变更控制，就是识别、记载、批准或拒绝以及控制对于项目基准的变更。 为什么有的人那么喜欢变更呢?因为他们是这样想的：“不是说车到山前必有路嘛，到时候再说好了。这样不就可以减少前期人、财、物的投入了嘛!我还可以不做或少做事先计划，我的技术缺陷或能力缺陷别人就发现不了。大家先打混账，到时候如果我是甲方，我要你乙方增加点什么东西，你敢小加吗?你不加，我就卡你工程款。如果我是乙方，我就给你列出一张变更清单，你不给我加点钱，我就不往下做，或制造一点系统障碍。”这类人往往乐此不疲．总以为得了便宜．其实在业内早已名声狼藉，最后必然众叛亲离。 为什么有的人又那么害怕变更呢?因为他们是这样想的：“变更导致范围无限蔓延、进度延宕、成本超支，自己的工作毫无进展、不见绩效，个人奖金全泡汤了。如果变，老板不乐意；如果不变，客户不满意。反正我是老鼠钻进风箱里，两头受气。”这类人对变更恨之入骨，对变更请求咬牙切齿，结果往往对变更带来的机会也视而不见、置若罔闻。 用流程控制变更 项目变更可能来自项目内部，也可能来自项目外部，可以根据法律强加变更要求，也可以根据合同选择变更。有的人会针对工作内容、时间、费用等直接提出变更要求，有的人则喜欢转弯抹角地间接提出变更要求。因此，为了有效地审核和控制变更，就要有一套变更控制系统或流程。为了对变更进行审核，就要设立变更控制委员会。 变更控制系统(ChangeControlSystem，CCS)，本质上是一套有案可稽的正式程序、制度或流程，它规定了项目可交付成果和项目文档的控制、改变与批准方式。 变更控制委员会(ChangeControlBoard，CCB)是一种由项目干系人组成的正式组织，负责审议、评价、批准、推迟或否决针对项目基准所提出的变更，并对所有相关决定和建议进行归档记录。 变更控制委员会的人员组成通常是：买卖双方的管理层、项目经理、技术专家等。 成熟的项目管理在处理变更时都非常强调这一点——所有变更行为都应该遵循流程。建立变更流程并不难(图5—6就是最基本的变更流程)，关键在于有些人不愿意建立变更流程，不相信流程的作用，总认为车到山前比有路，或者凭自己的经验到时再说无妨。我们强调，要想控制好项目，不论是甲方还是乙方，事先建立双方认可的变更流程，于项目双方均有百利而无一弊。 不管哪种变更，有经验的项目经理人都会恪守以下两条戒律： · 只有正式提出的书面变更请求才能受理； · 只有经过批准的变更请求才能付诸实施。 唯有如此，项目变更控制才会有序，项目变更导致的成本开销才会在控制范围内，项目群的资源冲突才会最小化，项目组合中的组织战略价值才会得到有效实现。 灵活应对工程变更 对于工程项目来说，变更是指由于工程特性、自然条件、人为因素或合同双方当事人出于对工程进展的考虑等，所引起的工程实施新需求或变化。 工程项目的变更处理，国际上一般遵循FIDIC条款。FIDIC是国际咨询I程师联合会的简称，该联合会于1913年在欧洲比利时根特成立，现总部在瑞士洛桑。FIDIC在土木工程、电气与机械工程、工程咨询服务、工程总承包等领域的采购、招投标、合同管理、转让与分包、延期及变更处理、保险、索赔、违约处理等方面，开发了很多具有可操作性的规范和方法，贡献卓著。当然，并非有了FIDIC，工程项目的变更争端就销声匿迹了，但至少，相较于IT界的供应链管理系统集成项目、制造业的产品研发项目，工程界发生变更时可参照的客观标准相对较多，因而也相对更为有序。 FIDIC对工程变更范围的主要规定如下： · 不可预见情况的出现； · 外部环境的变化； · 由业主或第三方提出的设计改变； · 由承包人提出的施工方法和工艺要求的改变； · 监理工程师的有利于工程进展的协调和变更指示。 FIDIC对工程变更的处理有三大原则：第一，容许变更的事宜，一般应在合同中写明；第二，变更只能在原合同规定的工程范围内变动，不能对工程性质大加改变，否则应重新订立合同；第三，只有监理工程师才有权指令工程变更。 根据FDIC的最新规定，工程量清单的内容变更，幅度在合同总价的15％之内不考虑调整间接费用，超过则要考虑。例如：一条路段原设计建造19座小桥，承包商按此规模报价，并将混凝土梁预制工场建设费按惯例开列在“承包人驻地建设”支付项中。后来发生变更，要求减去9座，由于工场已建但生产任务减半，承包人显然受损；反之，若增加9座桥，承包人自然受益。因此在具体操作时，还应由监理工程师与业主和承包人对实际情况进行分析，协商后再对间接费用进行增减或不作调整。 变更控制过程中的配置管理 配置管理在IT产品开发项目、系统集成项目、IT服务管理方面应用甚多，也是这类项目或工作中管理变更的常用工具。配置管理就是识别和确认系统的配置项，记录和报告配置项状态和变更请求，检验配置项的正确性和完整性等活动构成的过程。 在项目管理中应用配置管理，是为了达到三个目标：第一，建立一种渐进的方法，能够始终如一地识别针对既定基准的变更，以及提出变更请求，并估计这些变更的价值与有效性；第二，通过考虑每项变更的影响，为连续验证项目和改进项目提供机会；第三，为项目管理团队提供一种机制，能够始终如一地同利害关系人沟通所有变更。 在项目整体变更控制过程中，相应的配置管理活动包括： · 配置识别：确定与核实产品配置、标识产品与文件、管理变更， 以及保持信息公开的基础。 · 配置状态核算：捕捉、存储和评价有效地管理产品和产品信息所需的配置信息。 · 配置核实与审计：查明配置文件中确定的性能与功能要求已经达到。 下面我们来看看在IT服务支持中，是如何实施配置管理活动的。 案例研讨 IT服务支持中的配置管理 在大多数应用领域，变更控制系统是配置管理系统的一个组成部分，特别是在IT服务管理中，配置管理有详细明确的架构和规程。 IT配置管理的目的是：提供IT基础架构的逻辑模型；支持其他服务管理流程，特别是变更管理和发布管理的运营。IT配置管理的侧重点是：计量所有IT资产；为其他流程提供准确的信息，为事故管理、问题管理、变更管理和发布管理提供基础；验证基础架构记录，并在必要时纠正有关记录。 IT配置管理的主要活动包括： ．配置管理规划：确定配置管理策略；组建配置管理小组并任命负责人；分析现状、制订详细实施计划。 ．配置识别： 范围、属性、标识符、基准线、配置结构和关系、命名规范。 ．配置项控制：注册新配置项及版本；更新配置项记录；许可证管理；撤销或删除配置项时保存有关记录；保护各种配置的完整性；定期检查配置项以确保存在性和合规性，并相应更新配置管理数据库。 ．配置状况报告：基准线和发布标识符；系统协同软件的最新版本；系统变更次数；基准线和发布版本的数量；配置项的使用情况；对基准线和发布版本的比较结果。 ．配置验证和审核：实施配置管理数据库后；实施配置管理6个月后；重大变更前后；灾难恢复后；发现未授权的配置项后。 客户的需求为什么总是在变 大多数变更来自于客户或项目甲方。那么，如何对待这类变更，项目管理者就应该有一个正确的心态。当系统或产品不断成熟，客户认识水平提高了，就有可能也有权力提出变更，因此我们不必大惊小怪，只要搞清原因、遵循流程，就能处理好变更，进而处理好客户关系。 要搞清原因，就要学会深刻理解客户的需求，要琢磨客户为什么会提出需求变更。客户提出变更，原因可能如下： · 项目前期需求分析的沟通不到位甚至错位； · 客户业务部门提出了新的要求； · 客户对于项目产品的认识水平提高了； · 客户组织内部或外部的政策性影响。 在找到原因的基础上，我们还要进一步分析变更对项目本身是有利还是不利，对客户组织的长远发展是有利还是不利，然后通过变更控制委员会来确定是否要实施该项变更。特别是对于重大变更，应该遵循这一流程。在实战操作中，无论是拒绝变更还是接纳变更，项目经理不应自作主张、草率拍板。 控制范围蔓延的实用手段 众所周知，由变更引起的项目范围蔓延，对项目危害目大。这些危害表现如下：系统整体结构日渐紊乱，产品质量不断下降；系统或工程日益庞大预算超支，进度拖延；简单问题复杂化，管理难度大增；扯皮增加，项目干系人关系恶化，士气低落。 那么，如何有效控制范围蔓延呢?我们建议采用如下措施和手段： ．一开始就对项目目标、范围、约束条件和成功标准作出明确说明； ．让项目干系人理解变更的合理性、必要性及所需资源和成本，共担风险； ．准确定位范围蔓延的始作俑者，寻找成本的合理承担者； ．从配置管理角度出发，在技术上采用更为“健壮”的结构，尽早隔离可能导致变更的特性； ．尽早成立变更控制委员会； ．采用强势处置法，充分利用规则，包括需求定义报告、合同条款等加以约束； ．采用弱势处置法，有限承受，加以记载； ．采用折中处置法，学习谈判与沟通技巧，侧重在时间与成本、资源与特性上折中； ．采用另项处置法，分阶段实施，新立项目。 下面，我们来看看我所碰到的一个世界顶尖企业的项目经理所面临的问题，以及他所采取的错误做法，以此引以为戒，避免在我们自己的项目中重蹈覆辙。 案例研讨 一个悲剧性的BPR试点项目 我曾经涉及一个项目，该项目是CN电信南方某省公司的业务流程重整（BPR)试点项目，系统建立在EAI平台上，承担项目的是世界著名的IT公司。 为了实施该项目，公司从台湾请来了一位咨询顾问担任项目经理，这位仁兄给台湾电信做的类似项目据说没人敢恭维，但他确实不乏咨询顾问的天才，比如在描绘蓝图时口若悬河，具体表现在合同草签和设计阶段的范围定义，竟然作出如此描述： “以本项目合同的SOW为优先，以世界顶尖咨询公司MK公司去年为CN电信所做的BPR方案为范围，同时把省公司的OA、北京总部的业务流程等一并纳入系统实施。”规模之宏大，令人叹为观止；范围界定之混乱，绝无仅有。 我指出其问题时，他却很不以为然，居然说：“需求描述归需求描述，实现交付归实现交付，到时候给客户一个基本系统就行了。” 现在的客户不是傻瓜，你既然会“忽悠”别人，别人也会顺水推舟啊。项目做到一半的时候，有一天客户方对他说： “记得你以前说过，MK公司的BPR方案都在我们这个项目的范围内，有劳你给我们全实现了吧!” 他哭笑不得，说：“项目应该以合同SOW为基准啊!” 客户回答：“那怎么行?我们已经把你的话向北京汇报过了，过两个月领导要来视察，要看的就是你说的那种规模。” 此时双方都已骑虎难下，于是各执一词，开始大会叫小会吵，天天唾沫横飞。双方激烈地争论、痛苦地协调、无奈地折中，项目范围却在不知不觉中日渐蔓延。 当项目一期告一段落的时候，范围整整超出原来一倍，工期延长了两倍，但客户还是很不满意，抱怨不断，彼此感情大伤。客户对项目的评价是：还不如由一个小IT公司给东部某个地级市公司做的系统。 至于那些项目成员，身心疲惫，常年不得回家，士气日益低落。换了好几茬项目经理，全公司都知道这是一个问题项目，人人避之不及。更令人吃惊的是，一年后的春节， 曾经共事过的技术组长打电话给我，第一句话是新年好，第二句话问我能不能救救他。我问怎么回事，他说： “还在那个项目里，但想逃亡，你有没有其他项目给口饭吃?”我说： “不至于吧，有项目做就有饭吃，你有饭吃应该知足啊。” 他说：“有项目做确实应该知足，但这个项目看不到尽头。”电话那头最后传来一句凄惨的结语：“我一辈子做下去无所谓，可我常年没法回家，我老婆昨天提出要跟我离婚了!” 当计划不如变化 计划不如变化，本来是说客观情况变化太多，但到了计划无用论者嘴里，成了一句经典的嘲弄之语。嘲笑得没错，因为有些人确实不把计划当回事，特别是有些用户总觉得如果不再加点什么功能，就对不起自己，从而导致计划毫无严肃性可言。但另一方面，我们既然是做项目的，回顾一下项目的本质就该知道，项目经理人必须作好时刻应变的心理准备。不是有这样一句话吗——一切都是变的，除了变化是不变的。 那么，对于“计划不如变化”，有没有对策?当然有。下面就是我的建议，也是很多资深项目经理经常采用的对策： · 做好变更的心理准备； · 滚动式规划； · 从客户视角考虑项目问题； · 把领导当客户； · 加强沟通，减少摩擦； · 把变更变成机会。 事实上，对于做项目的人来说，“计划不如变化”又算得了什么呢?还有比“计划不如变化”更为经典也更为考验人的一句话，那就是“变化不如讲话”。谁讲话?领导。领导一发话，项目经理还有什么招数?所以有人觉得在中国做项目，是无规可循的。 其实，大可不必那么悲观。既然客户的认识是会提高的，既然领导是人不是神，因此，无论客户还是领导提出变更，都是很正常的，关键是做项目的人要有好的心态。 应对变更，滚动式的、渐进改善的规划不失为一种方法。当然，还需要辅以沟通，避免误解，并晓之以利害，甚至动之以情，这样达成共识就相对容易一些。而更为高瞻远瞩的做法是，把领导当客户，从客户视角看问题，这样就有可能把变更变成机会。我在上海的一个市政工程项目中，就碰到这样的事情：当领导发话要求工程进度提前时，承包商不理解，因为不可能提前，于是认为是外行瞎指挥，先抵触后骂娘。后来，各路承包商从市场角度来看问题，发现领导与自己有许多利益一致的地方，自然找到了工期提前的方法，结果皆大欢喜，领导政绩斐然，承包商也拿到了更多订单。(end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (6/22/2009)