项目的实施工作，何以谓之成功？由于软件产品的特殊性，决定了这种项目的成功标准是很难被量化的，验收缺少清晰的数字指标。对于客户而言，在一个合同里面获得最大的管理价值，包含最广泛的业务应用，是他们对成功的看法；而在供应商眼里，项目就是项目，早日验收早日回款，是他们追求的目标。双方立场的差异，导致项目在进行中会出现各种情况影响到项目的验收。如何减少分歧，按期完成项目，就成为了项目组最大的挑战。

    一般来说，我认为项目的实施需要遵照以下方针：加强沟通，精细计划，全力推行，利用资源，随机应变。

    怎么解释呢？“加强沟通”，沟通是应该占据项目组成员最多时间的工作。他们不光要跟客户沟通，还要跟后方的销售人员、开发人员、测试人员多交流，以及包括了项目组内部的信息交换。实施人员应该是信息的中转和汇总的枢纽，获得的信息量越大，项目现状就越透明，对后续工作的把握就越大。PMBOK中提到，一个项目经理有90％的时间都是在沟通上，可见这项工作的重要性。
“精细计划”，这个需要考验PM的功力。一个合理的计划，是项目能够成功的先决条件。PM要最大化了解项目的相关信息，包括资源、风险、客户特点等等，然后制定出一个适合项目特征，甲乙双方都有能力去实施的计划，并界定出项目边界和里程碑。从这一刻起，就要为项目的最终验收开始努力。

    “全力推行”，指的是项目小组成员要明确以验收为中心，计划是准绳的目标，想方设法去按照计划推动项目的开展。这个过程中肯定会出现各种各样的状况，也是项目最复杂，头绪最乱的时候。运用各种手段，来全力保障计划的按期执行甚至提前进行，是项目组所有成员的职责。

    “利用资源”，资源是什么？只要一切有利于项目推进，有利于最终验收的人、财、物，甚至气候、政治动态等等，都是资源。例如说甲乙双方的高层领导是资源，一台大内存的测试PC是资源，哪怕即将来临的雨季也是资源。项目经理要善于考虑可以利用的资源，敢于申请资源，然后把它用在项目所需要的地方，来解决一切干扰项目进度的问题。

    “随机应变”，没有到来的时间里总是充满了未知的因素，有不少是风险管理中无法预料的事情。这个时候该怎么处理，处理的后果会产生什么影响，还有没有更合适的办法。。。。。。都在考验PM。这就需要PM运用其综合能力，包括经验、技术能力、个人性格等，临时来找到有效的解决意见。

    以上谈到了项目实施的主要方针，我们再来看几个真实的案例，从中进一步理解。

    案例一：

    某PM所做的一个局级OA项目，经过前期的工作以后已经进入了试运行阶段，情况良好，正准备验收。这时机关上调来了一个常务副局长，他提出OA中缺少劳资管理的功能，需要补上。PM并没有马上允诺或拒绝，而是找甲方关系较好的人员作了了解，原来此领导原来是主管人事出身，只对这块比较有发言权。PM就找到了这位副局长，提出要为他专门做两张报表，能够从既有数据中进行人事相关信息的分析。领导很高兴，也不再强求需要专门的劳资管理模块。项目进度因而几乎没有受到影响，最终顺利验收。
 
    分析：

    OA和HRM有关系么？显然差别很大。但是客户是不能随便得罪的，尤其是一个刚上任有实权的二把手。这个时候要思考领导提出此需求的原因。新官上任，一般要烧几把火，一个正在进行中的项目当然要留下他的个人烙印。所以说，其实他真正的需求不在于搞劳资管理，毕竟这一块业务以后也不归他主管，其主要目的还是为了树立威信。了解了这一点就好办了，给他两张“量身定做”的报表，既能体现他的个人意志，又表达了对他的尊重，最关键的是开发工作量很小。这个事件中，PM的及时沟通和思考决策，起到了决定性的作用。

    案例二：

    某CRM项目，已经到了试运行阶段，原计划下周二验收。这时PM得知对方主管领导下周三要出国考察，想到对方可能没有心思准备验收的工作，便与对方沟通后把验收时间改到领导回国以后。却不料领导考察了国外的先进管理思想以后，回来决定大幅修改自己的业务管理模式，原有的CRM内容因此有大半失去作用。项目几乎等于要重头再来一次。

    分析：

    重视计划永远是正确的，甚至要想办法让条件成熟的后续工作提前开始。这个案例中的PM就犯了错误。领导要出国，没心思召开验收会是正常的。但是PM应该有很多办法来促成项目的及时验收。例如说找各业务主管对各模块分别书面签字验收，然后只需要领导最后签字确认即可。或者找公司领导汇报，争取一笔资金，找个名目通过SALES交给领导（通常情况下项目都有回扣点数），同时谈谈马上验收的事宜。反正是在计划安排的时间内，这种顺水人情领导当然乐意。而且，对于领导去做业务考察这件事，PM居然没有联想到跟自己项目业务的关联，敏感度太低。
案例三：

    一个PDM项目，需求调研已经完毕，正处于开发阶段。这时客户提出想把PDM和常用的三维设计软件PRO/E进行集成，实现两套软件的数据交互。根据PM的经验和技术人员的反馈来看，这个集成的难度相当大。但PM却一口答应下来，然后向客户提出需要对方配合的工作：请客户方找PRO/E公司，以大客户的身份要求PRO/E提供所需的数据接口。但是进行这种洽谈的话，用户需要提供正版序列号。实际上这家公司所用的PRO/E全是盗版，领导为此犹豫不决。PM更进一步地提出让他们干脆采买几套正版，不过即使是一套正版，价格也在80万以上。权衡再三，最终客户还是主动放弃了这个需求。

    分析：

    出现超出开发能力但又符合项目边界的需求是项目中最让人头疼的问题。这种事情一旦解决不好，很容易让客户对供应商的水平产生怀疑，双方合作产生裂痕，进而影响验收。这个案例中的PM相当懂得随机应变，他答应客户去做这个需求其实是张空头支票。但是通过巧妙的处理方式，最终的结果却是需求被主动放弃，而且客户对PM的好感增加。不过采用这样的办法是有风险的，只有事先作好调查，心里有较大把握，才能付诸实施。

    案例四：

    某企业即将上马一个ERP项目。由于以前该企业曾经有一次实施ERP失败的经历，所以这次的新项目让企业相关部门感到紧张，谁也不想碰这个摊子，一致主张低调启动项目。但是供应商的PM却力主召开一个隆重的启动大会，在得到企业方主要领导的支持后，又找公司高层出面，请到了对方企业的上级主管到会，还在会上宣读了以各个业务部门骨干为成员，某领导为组长的项目实施小组名单。在害怕项目失败的压力下，小组的各成员和责任领导战战兢兢，尽力配合好实施的每一处工作，还团结一致消除企业内部的杂音，争取早日验收早日完事。这个项目果然进行得异常顺利，在规定时间内达到了各项功能指标，通过验收。

    分析：

    信息系统对于很多企业而言，都不是离开它就干不了事的东西。所以客户中出现散漫或者抵触对待项目的情况比比皆是。这个时候最好的办法就是把客户跟自己捆在一条船上。在这个案例中PM很强势，他首先说服了对方领导调配各个主要骨干来参加项目组，然后又让对方的上级主管知晓此事来暗地施加压力。这种情况下的项目干系人，唯一的想法恐怕就是安全过关，能用就行。既然抓住了企业中最能说上话的业务骨干，又降低了他们的心理期望值。这样的项目，不验收都难。

    案例五：

    某PM主导一个工厂的技术改造项目。天天和项目组成员一起泡在对方的车间里，和对方技术人员面对面交流。经过几个月的埋头苦干，逐步完善了系统，最终达到了可以验收的地步。这时PM去找对方的总工提出召开验收会。总工大吃一惊：“你们事情做完了？做到什么程度了？我怎么不知道？”于是总工又找来主要的几个负责人，开会了解情况。虽然系统已经可以满足对方的需求，但是既然领导专门开会，当属下的自然要憋出几个新想法来。再加上总工的个人意见，这个项目又出现了较大的需求变化，进度被迫延迟了。

    分析：

    做项目切忌“埋头苦干”。当PM很需要会做表面工作。日请示月汇报，这样才能让领导重视。不管客户上级主管有没有时间或者兴趣了解项目状况，该做的日报、周报、月报、阶段性报告。。。。。。一定要按期递交到领导的案头，就算对方不看，也混个脸熟。而且做了些什么事情，都是有记录可查的。如果领导不清楚情况，哪怕下面的具体办事人员再认可，对项目也没有太大的作用。