项目范围的变更是不得不接受的一个现实,情况总是在变化的,对于项目而言,范围的明确定义十分关键,这要求销售在技术协议以及商务合同中要十分严谨和明确,目前我们的合同评审流程基本上能够确保这一条件,但是,变更是无法阻挡和回避的,必需要正确面对,对于项目而言,范围的变更必将引起成本,时间的变更,因此,根据项目的整体情况平衡三者关系就是项目经理日常工作的一个重点,管理变更产生的源头,分析变更是项目经理不能逃避的责任和义务,也是项目成败的关键。在变更发生时对于变更的控制以及应对能力是项目经理基本能力的体现,也是评价项目经理的一个重要指标。无论是有利、不利的变更,必将产生风险,因此,对于因变更产生的风险的识别、分析、应对也成了项目经理的主要职责和重要能力体现。因此,必需要对变更加以控制,从而推动项目的最终成功。 仔细看了合同变更流程描述后,个人认为其中有些许问题以及个人的想法和建议,具体如下: 1.按照目前流程规定,"成本在1万元以内的变更设计工程师得到其部门经理的批准就可变更": 如果发生了第一周变更1万,第二周变更1万。。。如果因为一次变更而导致项目范围的无限蔓延的化,那么在这种情况下,对于项目处于总体掌握的项目经理将难以控制项目,可以说项目经理的控制力因此条的规定而被削弱,设计工程师可以根本不用理会项目经理的担心和建议,越过项目经理产生变更,同时,变更的总价控制在此流程中没有体现,如果累计变更值达到了10万,20万,项目将失去控制。 这种现象在目前的项目执行中已经发生多次,工程师如果没有丰富的经验以及沟通技巧,对于项目全局又没有概念的情况下,客户的更改将会轻易的被接受,项目经理仅仅能够知道发生了变更而无法介入其管理,也就是项目经理有被架空的风险。这些看似微小,不足以影响大局的变更在没有经过仔细的成本、时间、风险分析时,仅仅靠某一领导作出决定的话,个人认为项目的执行风险只会增加,不会比现在有所改进。 再者说,对于变更的认识,销售经理、项目经理和技术工程师之间也存在不同的观点,因而如果按照这个流程来执行的话,很有可能会造成矛盾的激化,工程师同意更改,项目经理、销售工程师处于全局考虑不同意(发生概率低),工程师不同意更改,项目经理、销售经理认为没有必要为此得罪客户和设计院(发生概率极高),以上两种情况都会产生矛盾,如果项目经理的技术能力薄弱的话,无法说服对方,只能被动接受,达不到双赢的局面,长久下去,必将激起更大的矛盾。 2.若成本在10,000元之上,30,000元之内,设计工程师需提交变更申请表,经部门经理批准后方可执行,并抄送项目经理。项目经理应尽量与客户协商,争取得到补偿; 此条的看法同上。从描述中可以更加的感觉到项目经理被架空的情况,对项目控制力进一步的丢失。同时,项目经理应尽量。。。这样的描述根本没有量化和可考核性,争取不到就回轻易放弃,时间一久极有可能演变成消极接受、被动接受的工作风气,目前这种情绪已经出现,反正是ABB受损失,不管个人的事情,同时解释起来也很好解释,一句客户不同意,影响客户关系轻松化解!再者,如何去争取?怎么争取?认真负责的项目经理又要组织会议和工程师来讨论,听取意见,进而分析,如果项目经理的个人魅力和领导力不足的话,工程师消极配合的话,根本无从谈起争取二字!同时也有可能丧失了挽回损失的最佳时间!如果在变更提出的同时授权人员共同协商,权衡利弊,制定行动方针和策略,将会缩短应对时间,项目经理可以取得主动权,更好的控制项目。 3.若成本超过30,000元,设计工程师需提交变更申请表,经部门经理批准后提交给项目经理,等待项目经理的通知。项目经理收到设计工程师提交的变更申请表后,会同项目管理部经理、区域销售经理、销售经理、销售总监等讨论 同样,此条规定会产生以上两点看法中的所有问题。会同这么多的大老板来讨论的可行性个人认为几乎为零!同时,老板们又要了解一遍事情的具体经过以及评估报告,不仅造成了时间的浪费,还造成了效率低下! 对于整个合同变更的管理有如下建议:(我十分推崇PMI的变更控制流程,因此结合这种理念提出建议) 变更由发生变更的第一负责人提交给项目经理该变更的情况,项目经理制定时间、成本、范围、初步的风险分析的评估报告,然后由项目经理提交变更控制委员会审议(CCB),可以通过开会、授权的方式集体讨论变更对项目的时间成本范围的影响,主要还要评审由此产生的风险,以及应对措施。 如果变革可以接受,则由CCB做出决定,形成正式的批准文件,明确下一步的做法,各部门按照决定进行工作,如CCB认为条件不足或其他原因,则应说明问题,返回项目经理,由项目经理更新后再次提交审议。因此,在提交正式评估报告给CCB之前,项目经理需要做认真、仔细的评估,召集各个相关部门以正式、非正式的方法进行分析,形成客观、可靠、真实的评估报告,这样,该份报告会涵盖所有由此变更所产生的影响以及提出变更的理由,还有项目经理结合项目情况做出的建议(涵盖技术、成本、范围、时间、风向等信息),这样,CCB完全可以节省时间,直接做出决定,大大的提高决策效率。 正如前面所说的,为了防止范围的蔓延,应该明确每一个项目所能接受的变更成本的累计上限,制作相关的datebase,从而进行有力的控制和管理,同时,应规定所有的变更都必须是书面的,只能执行经过书面批准的变更,防止范围的蔓延,因此,文档应该有效、透明的记录,制作变更状态表,表明所有项目的变更内容以及目前的状态,在每一个项目中设立专门的文件夹存放提出的变更请求以及批复,在变更状态表中还应该明确指出批准的变更的具体负责人以及目前的执行情况等相关信息,从而为管理层监督项目,项目经理控制、执行项目提供强有力的工具。 关于变更控制委员会(CCB)的组成可以按照成本影响进行制定,例如,可以授权项目经理直接批准多少金额以内的变更,单次超过多少金额后应该将申请以及评估报告提交给那些人进性判断和决定,以及累计金额达到多少时项目经理应该给出历史信息以及产生问题的详细报告等等。 总之,项目经理对于项目的绝对控制权不能丧失,在目前公司的平衡矩阵,甚至有点弱矩阵倾向的组织结构中,如果我们轻易的交出控制力,个人认为对于公司的战略发展以及项目管理部的发展,甚至项目经理本身的发展都将产生负面影响!项目经理的权利是靠各种手段取得的,专家权,法定权,参照权,领导力等等,但是这一切都是在充分授权的情况下才能实现的。按照目前的这个流程,此流程一出,项目经理必将被架空,同时对于个人的工作积极性也将产生深远的不利影响。项目经理需要在工作中成长,这就要求我们必需完全的参与项目中去,但是从这个流程中我感觉到了参与程度在被动下降,于公于私都不利。再退一步,抛开项目经理的权利不说,在流程不成熟的情况下推出流程,时间一长必然形成你说你的,我做我的的现象,流程也只能流于形式了,我们目前的close meeting已经有这样的征兆了!因此,为了确保更加有效的执行项目,使得项目经理的个人能力得到提升,流程能从根本上帮助控制项目和提高效率,
|