您的位置: 说明：项目管理案例系列由项目管理者联盟[PMU]制作推出，版权所有。该系列以PMU会员实际项目案例为蓝本，结合项目管理专家点评和PMU会员分析，真实、深入、可鉴。
（一）案例正文
国内某著名财务软件开发商为我公司开发资金预算系统，在开发过程中，我们说服厂家进行现场开发。本月底该系统要准备双轨运行，该项目的项目经理和开发团队关系不够紧密，管不住人；在与我们沟通时，他总觉得他们的产品比较成熟，走的路线都是对的，造成了开了很多次协调会，但是开了等于没开，项目经理一不向上级反映，二不与我们良好沟通，造成关系僵硬。
我公司也去函该厂家，就此问题提出解决办法。我想请大家帮我分析一下，对于这样的情况，我公司今后对于开发厂家的项目经理要提出什么样的要求。
（二）点评专家
曹济 独立顾问，IEEE/PMI/IFPUG 会员, 现任信息产业部 IT 项目经理认证专家委员会成员, 国际软件标杆组织技术顾问/中国联络人，北京随济科技首席顾问。为多家IT组织提供过项目管理、质量管理、项目量化管理、软件估算与度量、软件评审、标杆管理、CMM/CMMI等方面的培训与咨询服务。
曹济点评：
您好，王芬，看来甲方也烦恼啊。
避免这样的情况可以采用两种途径，第一种是请监理公司，由监理公司对实施中的项目进行管理。第二种就是从甲方自己的角度制定项目管理体系和相应的办法。
我们在项目管理中也会有“斗智斗勇”的提法。通常来讲甲方在项目中还是非常强势的，因为国内现在都是买方市场嘛！所以甲方的位置通常不会这么被动。甲方为了争取项目的主动权和控制权，也需要相应的制度与方法辅以支持，否则就只能是采用“不验收”这个杀手锏了，而这种方法往往两败俱伤，对于甲方反倒伤害更深。
例如采用制度化的方法就要求在甲乙双方建立统一的项目管理委员会组织，项目经理定期要向委员会报告，项目中的问题自然不会被掩盖了。如果没有这样的机制，则甲方很可能只能通过项目经理接触乙方的高层。遇到一个责任心不强的项目经理，那就麻烦喽！
所以可以对人员提出具体要求，例如责任心、主动性等。但更有效的方式是甲方除了合同约束之外，可以建立相应的项目管理机制对乙方以及项目经理进行约束（要强调的是约束往往是双向的），以保证项目最终的成功。
（三）项目管理者联盟网友点评
分析1：软件为管理服务 作者：张翼
甲方希望按照企业的实际要求开发软件，乙方希望在已有的产品基础上经过配置、剪裁而形成系统，这种现象在企业信息化的项目中普遍存在。推荐江苏威特集团王甲佳先生在第二届中国企业信息化用户论坛上的演讲《再说企业信息化的主动权》，附后。
已有的产品技术架构可能比较合理，具有开发成本低，稳定性高、实施周期短等优点，在实际业务与产品功能相近的情况下，建议采用这种开发思路。
但企业在发展过程中，会根据自身的特点，形成一套合适的管理思想和方法，他们对信息化的要求往往不是现成的软件所能满足的，这种现象已经逐渐凸现出来，近两年来也开始得到开发商和企业的重视。
具有企业特色的管理思想和方法是不容忽视的，它们可能是企业核心竞争力的组成部分，在企业信息化的建设中，我的意见是，与其低价购买不适用的软件，不如增加投入，定制符合需求的专用软件系统，这样才有可能实现促进企业管理水平提升的目标。
本案例的对策：
1、根据合同的约束，要求乙方项目经理按照公司的实际要求开发软件系统。乙方项目经理与开发团队关系不够紧密，管不住人，是他的管理能力问题，可以向开发商反映，要求加强管理。有可能的话，公司应该派一名控制力强的人员作为甲方项目经理，主导项目的开发。
2、如果因为要满足需求而延长项目开发周期，应说服公司的管理层，需求满足程度与开发周期，对于公司来讲，当然要取前者。
3、如果乙方项目经理不能按照要求改变开发思路，则要求乙方更换项目经理。
4、如果乙方坚持现有的思路，我认为宁可赔款中止合同，也没有必要去开发一个不合用的软件，这方面的教训很多。
总之，软件是为管理服务的，如果无法满足管理的需要，即使软件开发成功了，项目也是失败的。
附：《再说企业信息化的主动权》江苏威特集团有限公司CIO 王甲佳
一、什么是主动权？
● 主动权首先必须是自己能控制的；
我们的论坛是用户论坛(注：第二届中国企业信息化用户论坛)
展现了一种来自用户的声音
很可能就此从卖方走向买方
● 在合理分配资源的情况下实现战略目的；
分包、外包将控制在一个相对专业的范围之内，也就会实现对需求分析、系统规划、技术实现等方面的专业分工。逐步淡化软件公司提供的“一揽子解决方案”
● 主动权来自多重挤压下的旺盛需求
商业包装使人们对管理软件的认识处于朦胧与不对称状态
用户的旺盛需求得不到满足形成了对主动权的渴求
二、主动权的尴尬？
还是要拿自己公司的事情做例子
刚刚过去的3月份，我们有一个强烈的需求——泛CRM项目。其中的境遇让人感慨万千。
● 需求方的信息化战略与战术“十二字”方针
▲ “大市场”就是以满足市场需求为最高追求，我们就是要通过信息化手段把它细化，透析出具体需求，形成订单，以客户为载体来满足市场的需求甚至引导需求；
▲ “小生产”则是把自己的生产功能精致化，通过很好的秩序控制在产能最大化和客户需求满足最大化之间形成平衡，这个方面是信息化有很大作为的领域，也是传统ERP最具有价值的MRP部分！
▲ “广协作”主要是从供应链的角度来认识的，从原料供应商、辅料供应商、工装工艺合作方等等伙伴那里取得资源来满足客户需求，信息化在这个层次的功用主要是为了让过程信息得到有秩序的交换，为多方所共享，以提升我们供应链整体的运作效率；
▲ “深情报”是上述三个层面有效运行的成果，也是指导三个层面高效运行的灵魂。是一个在企业文化上协同、业务逻辑上严谨、资源结构合理、合作伙伴信任基础上的神经枢纽。
我们期望形成一个覆盖企业经营性活动与非经营性活动的资源管理与控制体系，让信息系统与企业实际完全贴合而且与时俱进！
● 我们定义CRM是满足客户需求全过程的控制与管理。
在这样的情况下就形成市场、销售、客户、订单、生产过程、商务过程等为管控对象的管理信息化。
● 供给方的管理软件提供方案
3月中旬我们接洽数十家软件公司，同许多专业人士进行交流，就我们所需要的软件结构来说，满足度一般要60%以下，现实需求满足度50%以下，但是能提供出我们公司的要求的软件还是比较困难的，尤其要求一种平台化的软件结构是很不容易。选择成熟软件公司，他们软件刚性较强平台性较差，平台软件公司则是相反，他们缺乏成熟的行业经验。
根据实际情况最后还是要在软件公司里面选择具有一定平台化特性的管理软件，一方面满足现实需求，另一方面又可以对后续的维护提供及时便后的支持，同时便于进行边规划边实施的操作，尤其有利于将来MRP范畴，SCM范畴以及BI范畴的信息化项目实施。
大部分管理软件公司希望在他们已经进入市场的多种软件中选择。然后提供较高成本的二次开发，以满足对当前的泛CRM需求。也有公司愿意提供完全定制服务。也有个别“领袖公司”对我们的需求提出了质疑，认为非常不专业，基本概念都搞不清楚，还做什么需求规划。
● 双方差异所在：
（1）软件公司希望在他们的ERP、CRM、OA、SCM等软件群组里面选择功能模块；希望在他们的软件逻辑里面进行需求定义。
（2）企业希望从实际需求出发，在一定的基础数据前提下实现客户导向战略，同时进行战术的协同。至于软件到底是什么名称，什么范畴并不特别关心。
在软件公司面前，企业用户的信息化主动权受到了极大的挑战！
三、主动权的回归？
● 回归要义之一：
企业成长特性和优秀的同时又很幼稚的成功特质不容漠视。
信息化是优化企业生态的崭新载体和因子，不是生态链条的羁绊。
● 回归要义之二：
客户导向流程与功能导向流程的本质区别就是现代企业和传统企业的本质区别。对软件公司也一样。
● 回归要义之三：
信息技术将回归到它固有的势力范围，从前台走向后台。对企业业务的把握是一切竞争力体系的核心。
信息化革命才有刚刚淅沥的春雨。
信息化的主动权
是企业的生命线
分析2：补充一些 作者：一孑
项目过程应该有监控和验收的环节，建议应该加强这两个环节（应该以甲方为主导，或第三方机构），项目经理的意图肯定代表着乙方的一些想法，建议应该明确你们的目标，不要给对方太多幻想。
项目经理代表的是乙方，但这个项目，乙方不应该由这么一个项目经理负责，应该尝试的与乙方面对面的沟通，解决这个问题。项目经理的好坏不是甲方来评价，甲方只需要评价当前的成果就够了。如果是店大欺客，那也就另当别论了。
合同很重要，应该仔细研究一下。
分析3：瓶颈问题 作者：于先生
软件公司为减少成本及周期而在现有产品基础上修整来完成项目，往往通过关系作用使项目勉强混过，这种投机行为是当今软件项目普遍问题，也从而导致软件应用缺陷。
通常解决这种问题应该有几个原则：一、以客户为中心 二、以需求分析为基础 三、以解决方案为依据 四、以应用为验证。
这个案例问题出在一和三上，开发必须以需求为中心，项目经理过于盲目自信而忽视真正需求导致项目遇到瓶颈，要解决问题必须回归到解决方案，并且要根据试运行时用户需要修改，不合适的管理者立即撤掉。
分析4：以产品满足项目，以需求适应解决方案的项目 作者：daijiangbao
这是典型的以产品满足项目、以需求满足解决方案，本末颠倒的做法，需要让开发商改正过来，开发商能完成产品，但是不可能就说项目管理就好，技术不能代替管理。
客户方的需求，例如招标文件、合同都是对开发商要在一定条件下满足的，双方对这些关键的具有法律意义的文本没有得到充分的重视，到最后只能是双输的结果。
不会开会，不会沟通。
另外，对于甲乙双方的这种开发，主导的是开发方的项目经理，开发方的项目经理有义务满足用户的需求，但是一定不能把主导方的地位颠倒了，否则必定出大乱。
对PMBOK来说，只有采购一章是写给甲方的（客户,对本项目而言），其他各章节都是针对乙方（开发方）来写的，且切不可把关系颠倒了
分析5：确定自己明白的就要坚持，否则不要干涉 作者：陈晨
很多情况是用户方出人配合开发方进行开发，用户方是业务专家而不是开发专家，
软件部分交给项目经理去做，用户方需要做的就是，协助明确需求，准确地描述工作流程和期望结果。而不要去考虑软件实现方法，最好也不要去指责对方人员。
需求确认时候逐句逐字读明白了认为正确了没有歧义了在签字。
做了该做的就等着收获吧。
项目完不成，或者有其他问题，有合同呢。
分析6：明确交付成果,严格验收 作者：黄飞生 (保留 SZFISION@YAHOO.COM.CN)
1 一定要拿到强势的主动权,让厂方明确是你方说了算。
2 双方细化标准,明确交付成果,严格验。.
3 管理问题要求厂方高层拿出具体措施限期解决.甚至需面对面沟通。
分析7：非正规建议，仅供参考 作者：中国武则天
1.按照合同规范要求开发商；
2.挖取该公司项目开发组的主要人力，组件自有的开发和维护团队(等项目逐步完善后再做打算)；
分析8：过程监理，做好验收 作者：ymy
1、用户方应该派出业务方面的专家，协助开发方进行需求整理，对整理出的需求规格说明书进行评审、确认，以次作为验收的标准；
2、具体的开发工作交给开发方处理，至于开发方的团队管理，也应是其内部问题，用户不应做干涉。如果，因开发方的管理，造成进度延迟、产品质量问题，那就需要与开发方高层领导沟通解决，不是找项目经理；
3、用户在产品开发过程中，可以聘请第三方监理，帮助管理。如无第三方监理，至少应该有自己的项目跟进人员，随时了解项目进展情况，召集协调会议，不一定只针对项目组进行协调，必要时可以进行高层领导之间的沟通。
4、系统上线前，用户应派出业务专家和一线操作人员进行需求确认测试，检验需求实现情况，做好验收。
分析9：提什么要求并不重要 作者：王海飞
向项目经理提什么要求并不重要（兵无常势，水无常形，不同的项目执行起来会有不同的要求），重要的是让对方派什么样的项目经理。另外，贵公司自己也有问题，在项目实施前为什么不明确项目范围和验收标准？这是你们两家都存在的一个问题。
