合同管理

来源:互联网 发布:mysql 创建唯一索引 编辑:程序博客网 时间:2024/03/29 20:18

     项目管理里面合同有很多种类别,但是大家肯定都想把风险转嫁到另外一方头上,所以选择合同类型要谨慎,对自己有利,同时也要保持激励机制

1、Fixed-Price(FB)固定价格。这种合同中国人最喜欢用,因为感觉价格OK了,己方的风险就固定了。而且因为工作量评估就是IT行业评估成本的主要办法,但是工作量评估实在是不够准,尤其是一些风险看不清的项目,实际能有评估的两倍的都有。但是,我个人觉得,因为中国的很多项目都是谁做谁评估,所以大家都有习惯朝多了评估,这种方式未见是最合适的。但是如果风险非常大,或者就是不知道风险在哪里,到底多大的项目,甲方的建议用这种方式,可以转嫁风险,同时要获得乙方高层的承诺,保证即便工作量大量超出也不加钱,这样的风险的确转嫁了不少。

2、框架协议+time Material。说白了就是做多少,算多少。这种比较适合供应商在现场办公的,先有个框架协议,表示甲方和乙方的合作方式,一天多少钱等等,供应商来一天就签一个time sheet,然后最后算总账。外国的公司最喜欢这种方式。在风险比较明确的时候,而且确保供应商人品的情况下(不是诋毁供应商,但是为了避免有人磨洋工),也就是一些大公司的感觉比较Professional的那种实施顾问,而且管理比较严格一点的公司,可以采用。这样的公司比较保险,一方面可以和乙方的管理经理沟通,这样的项目大概要多少时间,他们有信誉保证,也不会冤甲方的,另外大公司项目都做不完,它都犯不着和你耗时间。为什么风险比较明确的时候用这种好一点呢,因为大公司都会有比较严格一点的人力成本核算方式,超过成本是比较严重一点的,如果采用FB的话,他们就会严格按照官方的流程来估计,比如测试三轮、啥啥N轮,这样按照官方的手册做才能保证不超支(或者说超支了才有官方的手册做借口),实际上可能风险比较明确,两轮测试就够了,但是因为一般甲方是保证效果的,如果第二轮测试就没问题了,多半也不会非做第三轮不可,从成本上说,甲方就损失了一些钱,还不如time sheet,大公司的实施人员还是有良好的职业素养的,所以这样大家都好。

3、项目管理里面的合同还有其他的我都没有用过,但是真的很鼓励大家用用,因为合同是真的有激励作用的。抄下来给大家。
a) Cost-Plus-Fixed Fee(CPFF,成本报销加固定费用)/Cost-Plus-Percentage-Fee(CPPF,成本报销加百分比费用)
    用于无法确定准确价格的情况
  成本变化但费用不变
  卖方风险低
  会没有成本控制的动机。

b)Guranteed Maximum-Shared Saving(GMSS) 确保最大限度的节省
  卖方付固定价格,按实际造价报销至顶限价格
  在确保线下节省部分双方共享
  卖方负责超过顶限的部分
  谈判合同中最好的一种形式。
这种方式看上去我觉得是风险不固定时候甲方和乙方比较共赢的方式,但是好像合同类的难度在于合同模板,没有找到一个法律上比较严密的模板。

c)Fixed-Price-Incentive-Fee(FPIP)固定价格加鼓励费用
  为卖方提供固定价格加奖励费用
  鼓励卖方降低成本
  双方共享结余,共担风险
这种觉得长期研发的项目可以用

d)Cost-Plus-Incentive-Fee(CPIF)成本报销加鼓励
  报销允许量的成本加上预先规定的奖励优越表现的奖金
  如果实际成本低于目标成本,买方和卖方按规定的方法分享节省的部分


这种也觉得长期研发的项目可以用


甲方与乙方的关系

项目没有开始的时候,甲方好比挑老婆,那可要睁大眼睛看,乙方的长处、缺点、特点都要摸得一清二楚。之后就是平衡,在众多老婆中间挑一个。
合同签了,乙方都是甲方的老婆了,没有原则性错误的时候,甲方最好和乙方是一家人,大家是利益共同体。

甲方要不厌其烦的告诉乙方:项目有什么问题,你告诉我,不能协调的资源我们出面,有问题我们共同承担。乙方的人常常对自己内部不能协调的资源难以启口,好比没法说自己娘家人的不是,所以有的时候乙方会掖着藏着,或者自己拼命协调,等上面说No的时候项目又拖了不少时间了。所以甲方友好的态度很重要。

甲方还要不厌其烦的告诉乙方:我没办法帮你加钱,但是可以帮你省钱。就是说合同没法改,但是可以尽快完成项目,减少彼此的时间+人力资源费用。

虽然甲方这么想,但未必乙方这么想。所以,甲方一定还要设定自己的底线。比如,项目经理一定要符合几大要求(有责任心、沟通能力强……),某个时间一定要完成什么里程碑,诸如此类,甲方的友好是要有条件的。但是一定要态度够温和,而立场够坚定。

双方都记得万万不好撕破脸。一旦撕破脸,很多时候大家都绕着走,慢慢的就会形成沟通障碍。而且越是高层越会发现障碍不可逾越,也许这就是人性的弱点,高位的人是容不得某些事情的。

一句话,有合作,有斗争。

不能控制的供应商的后果

我是东一个主题,西一个主题的胡写,想起什么说什么,主题之间未必有太大关系了。大家也就胡乱看吧。

最早之前说过的,因为F部门坚持选了一个我的老大W不能控制的供应商,后果在验收的时候就会出来。F部门希望我们可以为他们开发报表,所以我们要求供应商提供数据字典和数据流向说明,主外键关系。供应商是死活不给。然后出现供应商总是说:
1.当初我们约定初验的时候没有说那些东西,所以我们只是在说初验。
2.你们最后的一批需求我们也是说在终验前做完,但是你们初验都没做,我们就是在做最后的开发,没到终验,也就没有成果。

说白了就是供应商和我们掐上了,他们不给我们最最后的一批需求,我们不给他们初验。他们会一天打2、3个电话到F部门坚持选他们的人那里去,于是,终于连最后一个支持者都倒戈了……

可怜的F部门的原支持者,完全没有和供应商阶级斗争的经验,难过无比。

这个惨痛的项目告诉我们什么呢

 

1)通常来说,如果选供应商的意见不一致,可以上报,由更高级的人仲裁,如果是势均力敌的两方谁也没有依附谁的那种,就可能出现其中一方把很多责任推到选供应商的那方头上,而且承担责任多的这方又没有 PM以及和供应商斗争的经验的话,基本一开始就注定了结果是失败的。

 

2)高层关系重要呀重要,甲方PM和乙方PM一定会因为很多原因大打出手,还不是靠彼此高层协调。高层不合,他们就是神仙打架,我们凡人遭殃;高层琴瑟和谐,我们就是小孩子拌嘴,风轻云淡就过去了。

 

3)早期的高层PK就是占领心里制高点,赢了就插上自己的旗帜,万一输了,尤其是甲方输了,最好赶紧撤退,换个阵地,不要硬抗呀。

因为甲方乙方的PM都知道事情搞不定就上报,到时候就是高层PK。所以早期甲方和乙方斗争的时候就决定了胜利方掌握主动权,失败方产生心理阴影,大家都是人啊,没啥不同,想想自己就知道高层也多少都会这样的。
   a) 甲方早期斗争获胜。甲方老大兴高采烈的控制住了乙方老大,如果甲方PM搞不定了,老大也会出面轻松搞定,毕竟乙方老大心理上已经输了一筹,有了心理阴影就容易听话得多。
   b) 甲方早期斗争失败。甲方老大就会绕着走,不和乙方的老大接触,你们F部门当初谁选的,谁负责。老大们都是顶顶爱惜面子的,一旦失败,就不会说我脱了面子求你。事情就没法解决了,要么就是拖着,要么就是甲方的人吃了亏。


4)没有项目管理经验的职能部门,不要和IT部门硬争。善良的职能部门,长期对内工作着,不知道外面有多么险恶的供应商,不是人人都想和你搞好关系长期合作的,而且有的时候是供应商最早是想长期合作的,但是过程不尽人意,他们也知道只怕第一单就是最后一单了,所以也不怕惹急你了,收回钱才是上上策。当初惹火了自己的IT部门,焦头烂额的时候,就没有人帮忙了。
甲方的人内部团队多重要呀,咱们一定要注重内部的和谐啊,这样才是相互扶持的团队嘛。

 


转  http://www.itpub.net/viewthread.php?tid=786732&extra=&page=2

原创粉丝点击