【案例正文 】
E供职于一家从事军品软件开发的民营企业，客户一般为国家或者军方背景的公司和机构。这些客户(甲方)由于具有绝对的资金和资源优势，并且有着十分广阔的供应商来源，加上半个世纪以来的形成的体制内的权威传统，在对待自己的供应商(乙方)时态度常常十分粗暴，不允许讨价还价，遇到问题也没有商量的余地。这些因素决定了甲乙关系中，甲方处于绝对的强势，而乙方处于绝对的弱势，这对乙方公司开展项目的项目经理来说，简直更是个噩梦。 E供职的这家公司属于典型的职能型组织结构，项目经理只能是个项目联络员的角色，但既然负责项目，哪怕是零权限，也得承担起责任，至少承担痛苦。
这里对一个刚刚交付不久的项目进行描述，对其中的现象和问题进行分析，由于这些问题可能具有普遍性，所以期望通过抛装引玉，引发大家的思考，为同类问题和项目寻求解决方案。
2014年10月，甲乙双方开始针对项目进行接触，甲方提供了《技术协议》，技术协议对项目的功能和性能做出了规定，但规定十分笼统和简陋。乙方基于甲方提供的《技术协议》对项目的规模和开发工作量进行了评估，评估方法也相对初级，结论是投入3个人力，3个月时间可以完工。乙方基于这个评估向甲方提供了报价，并最终拿到了项目的合同。
乙方于2014年11月正式启动项目，并立即开始了《系统需求规格说明书》的编写，过程中上门与甲方面对面沟通若干次，邮件沟通若干次，反反复复修改无数稿，并于2014年的最后一个工作日进行了内部预评审，为客户正式评审做准备。同时不停协调甲方评审《需求规格说明书》的时间，几次最后决定仍被放鸽子。
经过几番折腾，在2015年1月中旬的一天，乙方终于等来了甲方的评审团，这个评审团包括1个总设计师，1个项目办人员和5个技术负责人员，经过4个小时的激烈讨论，在提出若干整改意见之后宣布评审通过。
甲方是按照瀑布模型对乙方的项目开发工作进行要求的，但在需求文档等待评审的间隙，乙方并行完成了系统设计文档的编写。
问题是，截至需求文档通过评审为止，甲方都没能提供系统必须的和甲方自研系统之间的接口协议，甲方的意见是先做可以做的。
在设计文档完成之后，甲方团队迅速开始了系统的编码工作，用了6周的时间，在2015年3月中旬完成了用户界面相关的功能，到此为止，乙方团队已经花掉了3个半月的时间，除掉中途的春节放假，事前评估的3个月时间已经用完了。
就在这个时候，甲方提供了一版34页的系统接口协议，乙方团队加班加点，用了2周的时间将接口协议实现并集成了系统中。
然后甲方发布了接口协议的更新版本，这个更新版本有48页，经过分析发现，与其说这个是更新版，不如说是个全新版，因为这个版本推翻了上个版本中90%的ICD。又经过2周的时间，新版本ICD被实现和集成到系统中，这时候时间已经到了2015年4月中旬，超出预期4个月。
接下来，应甲方的要求，乙方奔赴甲方公司进行了系统最新状态的演示，甲方提出了一些修改意见和一些针对业务的细化意见，并说明仍然有部分需求尚不清楚。针对客户的这些需求，乙方又花了4周时间完成了变更和功能增加。此时，时间已经到了2015年5月中旬，超出预期5个月。
客户的变更单又来了，此处花去两周时间。
接下来，客户要求系统联调了，从此乙方团队开始了出差的日子。
从2015年5月底开始的26周时间中，乙方按照甲方的要求一直两地奔波，大部分时间在甲方的实验室度过，这期间出现的现象有以下几类：
(1)需要联调计划好的某设备(甲方自研)时，突然发现该设备的负责人(甲方人员)出差了;
(2)需要联调B设备(甲方自研)时，临时才知设备因故障返厂维修了;
(3)需要调试某设备(甲方自研)时，甲方上级单位通知开会，乙方人员回宾馆自己玩;
(4)联调某设备(第三方承制)时发现数据对不上，排查三天，最后发现甲方提供给我方和第三方设备承制商的接口协议不一致;
(5)联调某设备(甲方自研)是数据不对，经排查可以认定是甲方开发人员的编程错误造成的，可是甲方人员坚持自己是对的，而该成员具有一定的背景，别人不好反驳，所以负责人向乙方要求通过乙方的修改来保证联调结果的正确。
由于各种奇葩的状况不断，用了足足26周的时间才完成系统的联调，何其漫长!这时，时间已经到了2015年11月月底。超期7个多月。
2015年12月21日，这是个伟大的日子，这天，在各种斡旋之下，客户通过了该系统的验收评审。然而，前提是乙方在评审中声明，在甲方提出修改要求时，乙方需要配合。
一个评估为3个月的项目在经过14个月的癫狂之后，终于平静下来。这期间甲方提供的书面更改单25份，口头更改随时进行，从头到尾，唯一不变的就是变更。
在这个项目之后，乙方公司拒绝了甲方的新项目，这算是这个而失败项目的一个教训!
E作为一个零权限的项目联络员，全程忍受了这个项目中的全部尴尬和痛苦，然而却无能为力，相关的职能经理也无能为力，项目始终在失控中运行。
最后甲方基本满意，乙方崩溃了!
