实施阶段

项目经理在这个阶段最主要的责任，不是管理做项目的人，而是帮助他们管理自己，也就是帮他们理清思路，从而顺利完成自己的任务，并通过这种方法不断让他们分享这种责任感。

必须定期审查目标与计划，做出必要的修正，寻找完成计划的最佳途径。任何计划一旦启动，项目经理必须跟踪到底，监督、帮助计划执行人有质量地完成计划。

项目经理必须清楚地知道工作中整个团队每个人的性格特点，所做的计划一定要跟踪到行动被有质量落实为止。

项目经理要天天看大计划和子计划，对项目计划要设计跟踪手段。每个阶段工作完成后，要对质量有清楚认识，并将其作为下一阶段执行和考虑的原始输入数据。

在现场的时候，应该每天都面对面和团队成员沟通；即使不在现场，也应该保持一定频率的电话、邮件和短信沟通。除了和自己团队成员每天沟通，还要和客户每几天进行一次沟通，只不过这种沟通可以选择一种成本比较低的方式。沟通要有持续性。一件事情一旦启动沟通，就一直坚持到这个事情被处理完毕，并得到客户认可为止。

项目经理一定要同时听取客户和团队成员的意见后，再综合决策。必要的时候，还可以咨询商务团队和公司主管的意见，再做行动决策。

团队的生命周期可以划分为形成期、震荡期、规范期、成熟期、休整期。

形成期：项目经理要明确方向、明确职责，进行员工培训，向团队说明工作目标、工作范围、质量标准以及进度计划。
震荡期：要认识并处理各种矛盾和冲突，鼓励团队成员对有争议的问题发表自己的看法，并准备建立工作规范。
规范期：项目经理要带头形成团队的文化和氛围。通过激励手段，让团队成员放下各种心理上的包袱，提高责任心和相互信任度，让他们将行为标准和工作任务紧密地结合起来。具体而言，要鼓励提建议，让成员在提建议的过程中感受到团队发展与自己休戚相关。工作的时候，要对成员工作进行授权，激发他们的责任心；结束之后还要有表扬和奖赏。
成熟期：项目经理应该集中精力关注进度、成本、质量等事关全局的事情，其他工作应当适当放权，还要根据需要随时更新工作方法与流程，推动经验与技术的交流，提升管理效率。
休整期：项目经理要做好团队成员的思想引导，说明调整的必要性和意义，让员工认同组织调整的决定。

团队成员的选择要以合适为主。具体而言：

认同组织价值观，又具备所需能力的人，要重用。
不认同组织价值观，但具备所需能力的人，要慎用。
不认同组织价值观，又不具备所需能力的人，要辞退。
认同组织价值观，但不具备所需能力的人，要安排难度较小的工作。

结构决定行为，元素会继承系统的意志，符合系统意志的元素会达到最大。所以，做项目的时候需要的不是安全意识，而是安全的系统结构。

常见的组织结构类型有职能型组织、矩阵型组织、项目型组织。

职能型组织：

每名雇员都只有一位明确的上级，人员可按照专业分组。

优点：相同专业的员工在一个部门，对于实现技术进步有帮助；部门员工只有一个上司，工作只需要向唯一的上司汇报。

缺点：在项目工作中没有一个明确的项目经理，各职能部门均是对分配给自己的项目任务负责，而不是对项目最终成果负责；跨部门的协调需要经过信息的多次上下传递以及水平传递，领导只能在信息不对称的条件下做决策；需要各部门协作、面对跨职能部门的复杂项目时，效率就会十分低下。

矩阵型组织：

既有人对项目负责，又能有效利用组织资源。

优点：把职能分工与组织合作结合起来，从专项任务的全局出发，促进组织职能和专业协作，有利于任务的完成；把常设机构和非常设机构结合起来，既发挥了职能机构的作用，又保持了常设机构的稳定性，使行政组织具有适应性和灵活性，与变化的环境相协调；在执行专项任务时，有利于专项专业知识与组织职权相结合；项目成员是临时的，这些团队成员可以在同一时间段承担多个项目，使组织资源能够得到充分利用；非常设机构在特定任务完成后立即撤销，可以避免临时机构长期化。

缺点：各项目团队与各职能部门关系多头，协调困难；项目经理的权力与责任不相称，如果缺乏有力的支持与合作，工作就难以顺利开展；项目团队是非常设机构，其成员工作不稳定，利益容易被忽视，所以他们往往缺乏归属感和安全感。

矩阵型组织还可以根据项目经理和职能经理的权力对比进一步分类。

弱矩阵，即项目经理的权力小于职能经理的权力。弱矩阵保留了职能型组织的大部分特征，其项目经理的角色更像是协调员或联络员，而非真正的项目经理。

平衡矩阵，即项目经理和职能经理二者的权力相当。虽然承认全职项目经理的必要性，但并未授权其全权管理项目和项目资金。

强矩阵，即项目经理的权力大于职能经理的权力。强矩阵具有项目型组织的许多特征，拥有掌握较大职权的全职项目经理和全职项目行政人员。

项目型组织：

以项目组作为独立运行的单位，项目组拥有专用的项目资源，团队成员通常集中办公，大部分资源都用于项目工作，项目经理有很大的自主性和职权。也有被称为“部门”的组织单元，但这些部门要么直接向项目经理报告，要么为各个项目提供支持服务。

优点：有明确的项目经理对项目结果实现承担责任，并且可以充分利用项目组的专用资源。

缺点：对企业的资源利用程度不够，而且项目资源被各项目组独占。当项目需要这些资源时，固然能及时获得，但当项目不需要这些资源时，很难从项目组释放。

常见的团队类型有外科手术室、交响乐队式、爵士乐队式、足球队式。

外科手术室：

关键任务由团队核心负责人亲自动手完成，成功率比较高。缺点是团队核心负责人事必躬亲，较为劳累，也不利于人才培养和团队成员的迅速成长。

比较适合两种情况：一种是关键工作必须由资深专业人员亲自操作项目；另一种是一个资深的项目经理带着一批新手的项目团队。

交响乐队式：

假定项目团队成员都是勤奋的、能干的、积极的，团队成员会负责任地将事情做好。在这种情况下，项目经理大胆使用团队成员，给他们强化工作授权。

项目经理要做的事情主要就是指导和鼓励团队成员，自己的工作较为轻松，项目团队成员可以得到历练并迅速成长。

但这种团队类型对组织和成员有一定要求：组织要有明确的工作任务分工体系，团队成员对整个组织及其他成员了如指掌；团队领导要有大胆用人的气度，敢于授权；团队成员要训练有素，勇于承担责任，能够自我指导，有良好的团队意识，配合默契。

爵士乐队式：

团队成员之间并不存在严格的上下级关系，每个人的作用都是相互补充的，共同为了达到目标而努力。团队成员根据实际情况做出调整，自主管理和分配任务，灵活应对各种挑战，通过实践中的合作完成目标，而不是靠严格的计划和命令。

团队成员在项目中不断磨合调整，以达到最佳的整体效果。但这种模式要求团队各成员都是专业的，能够熟练自己的业务；而且团队各成员还熟悉项目情况，不仅能做好自己的工作，还具备总体和系统意识，能够保持与其他成员的协调。

足球队式：

尽管每个成员的任务在项目中可能会根据实际情况进行调整，但每位队员都有明确的角色和职责。团队成员需要能够在不断变化的环境中快速做出决策和计划。

队员在清晰的分工基础上，通过积极主动的职能变换来配合其他成员，以应对项目中的各种情况。这种模式要求团队成员之间有基本分工，但有些中间地带要求大家积极和灵活地跑动完成这些工作。

团队成员之间需要保持高度配合、相互支持。而且在团队之前，团队成员之间要有非常明确且共同的目标，具有互相补位的意识，不计较个人得失。团队成员还要能够根据形势迅速达成一致，共同进退。

无论选择哪种组织结构和团队结构，核心原则都是：没有最好的，只有最合适的。

项目经理要善于使用团队责任例会来建立团队责任机制。可以在项目整个周期内每周举行一次，每次通常不超过 30 分钟，让团队中的每个人都了解项目状态，并对可能的解决方法畅所欲言。人多力量大，就总能找到解决办法。

根据项目的特点，可能也会增加一些微型团队责任例会或检查会。微型例会的频率由项目经理和团队成员共同决定。微型例会并不是为了单纯见面交流，而是为了控制关键路径的某个特定目标。

项目到了特殊阶段，可能会需要召开微型例会，不需要所有团队成员出席，也不用代替日常的核心团队责任例会。

团队责任例会有四个目的：

通过审视整体项目规划，让团队把项目当作一个整体。
要求团队成员汇报上一周完成的工作情况。
通过项目成员不断完成新的工作，保证项目前进。
让项目经理了解哪里存在困难。

项目经理想要让其他人对工作负责，那么就有四个基本行为准则：

让团队成员说明为什么没有完成任务。
展现尊重，通过换位思考理解对方的处境。
明确期望，重新布置任务，更新截止时间。
让团队支援知道，项目团队在乎每个人的承诺和职责，他们是项目成功最重要的一部分。

项目经理还可以不定期地与团队成员进行绩效对话。

项目经理在对话中要思路清晰、有逻辑，最重要的是给予足够的尊重。要用坚定但友好的语调，清晰说明目的和事实。阐述问题之后一定要停顿几秒。全程要有同理心，要换位思考，尽力理解对方的观点。不需要表示自己同意或不同意，也不需要为自己辩护。

谈话之前，可以先写一个对话计划表，包括：

对话目的。
事实：考虑自己想和对方分享什么。说明每件事或对方犯的错误时，要有理有据，最好能举出例子。
影响：想好每件事的影响，以便让团队成员对项目整体情况有所了解。
后续工作：一旦对方觉得自己能够被理解，就可以让他们自己提出解决方案。这时要明确列出希望对方做的具体任务，以及对他的承诺；同时做到履行承诺，对具体行动规划达成一致，并确定下一次对话的时间。

在实际工作中，项目经理还要协调冲突。最典型的就是矩阵型组织中项目与部门之间的冲突。

项目经理可以明确目标，并让每个人知悉；解释理由的时候，一定不要解释过多。也可以设定一个可以短期实现的里程碑。第一个里程碑要简单一点，让成员能够迅速达到。总之，不要让团队成员闲下来。

有时候项目经理还会面临项目间的冲突。对于这种冲突的解决方法，项目经理追求的应该是“可行”，而不是“合理”。

实施阶段，项目经理还要进行客户培训，而且客户培训也是实施的关键。

项目经理管理多个项目的根本出路，是在客户企业培养替代者，而不是指望我方公司配置大量实施替代资源。培训也是项目成本控制的关键手段，项目团队要有极强烈的培养替代者的意识。

在企业建立一个实施团队，让项目团队得到额外资源保障，让企业项目团队的关键人员推动项目实施。在项目里做培训，根本目的是让客户在很短的时间内可以自己独立实施项目，而不是仅仅会使用某些操作。

项目经理千万不要觉得客户企业的领导或中层干部是应该配合工作的，特别是面对一些国营单位。客户企业领导如果没有拿项目的事情作为内部斗争的武器而从中作梗，就已经算作合作了。

不是所有项目的客户都具有被培养的潜力。但是在大部分项目里，从来就不缺乏能够培养成一个好的实施者的客户，而且这样的人只要一个就足够了。

实施顾问与客户管理员之间是存在不同的。实施顾问要求技术全面，能够靠体系化方法推进项目，在一些理念和思路上比较清晰。客户管理员只需要知道和他们相关内容的部分维护，能够利用企业实际潜规则推进项目，而且要更了解客户企业实际情况和业务特点。

实施顾问要向客户灌输一个重要理念：我方公司的工作，只是保障项目所运行业务需要的产品功能完整可用；利用产品具体跑业务流，是企业自己的事情。只有客户企业自己也可以独立实施、维护产品了，项目的实施才算真正成功，并获得长期保障。

成功的培训周期一定不长，一定是在最短时间内不断反复强化某些业务环节的操作，形成习惯。

项目经理不要指望客户自己会自发地在一段时间应用后掌握操作。客户需要经过一段时间内大量练习、强化掌握后，再逐步琢磨如何应用，最终达到运用自如。

培训工作质量不高，主要原因通常有 4 个：

缺少高质量的、按业务组织的培训教材：必须建立一套完整的、结合业务的培训教程，并使其具备快速传授的能力。
培训者的能力缺少验证：项目经理要请实施顾问讲内部公开课，看一看他到底是否具备清晰、明白、讲清产品功能和业务流程的能力。可以采用“一次通过即获得培训资格”的考核方式进行。一个好的培训人员，对其培训能力的验证，在一段时间内只需要经过一次就行，而这个能力至少能在一年内都发挥巨大的作用。
不重视培训工作：实施顾问一定要重视培训，想办法让客户自己会用、爱用产品。要想重视客户的培训，首先要重视我方员工的培训。如果有条件，可以对员工组织 Training the Trainer。
忽视软能力培训：所有实施顾问应具备的软能力，都要最终传授给客户。

要根据不同培训对象、不同培训内容、不同培训阶段、不同培训师资进行培训内容策划。

不是企业每个客户都要培训的，而是选择一个或几个重点客户培训，确定其掌握基本能力，然后辅导重点客户培训别的客户，逐步扩大影响。

要想好每个阶段目标客户应该掌握的内容，作为自己实施目标的一部分，并通过相关培训活动实现：

业务调研培训：重在告诉客户工作方法和相互沟通配合方式。
解决方案培训：重在告诉客户产品业务模型和整体解决思路。
功能验证培训：重在让项目组或系统管理员掌握产品基本操作，进行功能验证。
辅导上线培训：重在让一般客户掌握相关部分业务操作，让管理员掌握常用配置和维护工作。
项目管理培训：重在让核心客户掌握项目管理基础技术。

如果企业比较大，就需要策划培训批次以及每次培训的内容。除此之外，还要考虑如何将培训工作成果汇报给企业，并形成共识。

项目经理要主动让领导知道，如果遇到问题，可以请谁负责解决。一旦有重点客户，可以在实施顾问的辅导下，独立培训别的客户进行操作。或者在大面积普及操作目的达到后，项目经理要立即给企业领导汇报。

除了通过汇报成绩确定项目进入一个新的里程碑外，还要要求客户企业主管领导表扬这样的客户，保持其积极性。同时也要让企业领导知道，项目团队是真的来做好项目的，所以项目团队不但提供产品，还在真正为企业培养人才。

培训之前，把培训计划制定好，并通知到最终参加培训的客户。培训计划应该先在内部经过大家确认，落实资源后再提交客户。一定要合理安排，做到高效紧凑。

主要内容包括：培训目标、培训时间、培训内容、培训师资、培训地点、签到方式、考核方式。

考核和反馈可以验证培训效果的两个方面：

客户掌握程度：通过培训考核完成。
项目团队成员现场培训的质量：通过客户企业学员培训反馈表来了解。

必须要结合企业实际业务，准备适当难度的培训考题。

培训成绩原则上要反馈给个人和企业相关组织部门。项目团队可以采用鼓励优秀、淡化落后，以先进示范带动整体提高的这么一个策略，促进培训深入开展。

培训完成之后，要请企业学员填写培训效果回馈表。同时，我方自身应该完善培训体系，使培训标准化。考核和效果反馈表等等都可以作为模板。

客户、企业学员的培训效果反馈表要提交给项目经理和公司相关培训管理部门，由项目经理安排实施顾问再进行技能培训，改善学习。

培训时，实施顾问要利用一切机会，通过各种易于接受的方式，把思路、操作或配置传递给客户，从而从客户处获得回馈，改进实施过程。

同时，要在培训中互相学习，抓住一切机会向客户学习业务知识，随时记录培训中发现的问题，并回馈给我方公司，对产品进行持续改进，或者调整产品配置。

客户上手学习时，一定要有熟练操作者辅导答疑。实施顾问在培训中要及时、大胆、诚恳地鼓励客户的每一个进步。

在培训过程中，要完成产品思路、管理理念和培训方法的灌输，还要培训客户处理问题的流程，把记录产品缺陷和分析缺陷的方法传授给客户，让客户可以按照要求提供此类资料。

在满足以下 5 个条件之后，即可进行现场推广：

经过充分的现场功能验证，确定产品功能基本能串联起一个或几个基本业务流，并得到客户项目组的书面认可。
产品的稳定性和其他性能，在可预见并发生的环境下，能够达到可使用要求。
针对基本业务流的业务操作手册全部编制完成，并对相关客户完成培训。
客户企业和我方公司都可以投入一定资源，主要是客户方的可独立推广资源。
准备工作细致。

做现场推广有这么几个策略：

组织高质量的业务调研：

在对产品比较熟悉的情况下，做业务调研可以边调研边建立原型测试。

对关键客户组织成功的培训：

从一开始到现场工作，就要反复安排大量精心组织的培训活动，让客户理解自己的思路。项目解决方案或思路一定要组织各种类型的会议，在现场反复讲解，达成一致。

非常关键的问题不要有意回避或模糊化。大方向确定之后，一些小的技术细节可以淡化，不要在一开始的时候就纠缠细节。

培训的时候，在操作上应该准备实例化的内容，应该让主导客户操作后，自我评价掌握程度，直到其熟悉为止。培训思路要站在业务流的高度进行规划，让客户相信项目团队对他们业务理解非常准确且到位，打消客户的顾虑。

提前做充分的内部业务验证：

内部业务验证一定要自己亲手模拟测试，而不是依赖产品测试部门的结论。项目团队要发现产品是否有易用性、性能和功能上的问题。发现之后要尽快提供给公司相关部门，寻求替代解决方案，或者列入可接受的版本发布计划里。

不要幻想一个对新功能、新版本不熟悉的人去现场指导客户实施，会有好效果。熟悉的过程只能通过内部验证来反复强化，而且内部验证阶段还需要准备新功能培训教材和升级数据等相关指导材料。

内部验证不需要等到产品完全没有缺陷后才能启动后续工作，而是通过自己验证后充分评估产品对主要业务线的支持程度：有多少是可以通过沟通克服的，有多少是无法解决且必须解决后才能推广的，有多少是必须解决但可以暂时忍受的。

这期间要及时和规划开发部门沟通，达成一致的解决意见。最终在现场客户发现缺陷之前，项目团队要做到心中有底、有对策、有替代方案。可以承诺客户大致解决时间，并按时间兑现，而不是抱怨项目团队总拿着有问题的版本来。

做现场验证：

也就是让客户项目组充分评估新版本的价值和不足之处，确定是否升级。一旦升级后出现客户不满，就可以事先采取对策来克服。

如果验证结论不能满足业务要求，千万不要到处时装推广，宁可回去申请项目延期，把产品改好再来推广。

要完成对客户培训的过程，让客户组、项目组承担起实施责任。而且还要做好推广风险评估，提前采取对策。最后验证先通过给领导汇报取得支持，再召开项目推广启动会。

选择适当的推广边界：

一般情况下，要考虑解决完一个业务环节再往下走，把繁复的企业业务化整为零，设计为相对完整的几个部分，逐个部分实现。每个部分一定要有一个清晰的效益愿景做牵引，逐步扩大应用范围。

建立和客户的个人友情：

实施顾问可以和客户一起进行广泛的日常交流，一起吃饭、娱乐，增进感情。但建立和客户的友情未必都是靠请客吃饭造就的，请客吃饭一般不会建立深厚的友情。友情是在项目的同甘共苦中建立的。

想要实现快速推广，还有一些技巧：

项目经理在项目关键阶段重点投入实施资源，确保让某一业务快速进入真实可用状态，然后再逐步减少实施投入。
没有达到这个业务目标，宁可暂时牺牲其他项目的响应，尽量避免同时在多个项目中调度响应、引发资源冲突的局面。必要的时候，牺牲一些项目的短期客户满意度是值得的。
多人同时协同负责多个项目时，项目经理必须保证每个项目至少有两名人员可以互相替代。
一块业务上线之后，后续现场服务工作要么不来；要来就解决一些问题，不要因为客户有要求就盲目去现场。
日常现场工作要多请示、多汇报、多写量化汇报材料给高管，并把功劳说成客户企业项目组的。以帮助客户企业项目组谋取政治利益的方式，培养客户企业内部的支持人和内部教练。

现场推广进行不顺利的原因，无外乎这么几个：

项目边界总在变更。
没有与客户建立诚信：

项目经理一定要做好最坏的打算，对客户承诺要慎重，说到做到，有问题就全力保障问题及时解决。项目经理一定要给客户留下两个印象：一个是项目团队很认真、守信；另一个是项目团队时间珍贵。项目团队每次只能解决关键问题，实施还是要靠客户自己解决。

缺少客户企业高管支持：

达成一致的实施方案要给客户高管汇报，汇报要点在于：目标是否认同、资源投入计划是否可行、可能会有哪些风险、采取了哪些措施保障、如果出现一些项目阻力，需要提前得到领导哪些授权或政策支持等。

取得高管支持最有效的手段，就是建立和高管的汇报机制。但是每次汇报的时候，应该准备一些积极的、值得肯定的、的确有进步的内容。

没有激发客户的主动性：

一般情况下，项目团队只需要在现场解决问题、培训技能、沟通后续工作计划、完成本次业务目标，就必须返回。客户项目组不能解决问题的时候，项目团队要全力促成问题解决。一旦解决，项目团队在第一时间安排现场响应。如果项目团队解决不及时、不顺利，要第一时间通报，请求客户的理解支持。

推广实施方案没有和客户达成一致：

业务推广必须和客户项目组达成一致意见。要和客户达成一致，并非是某个业务方案在技术上可用或不可用，而是项目团队是否找准客户认可的价值点。

为了让客户认可推广目标对应的业务流，项目团队往往要想好关于业务价值的说辞，说辞推导要有力，而且要有资料、事实证明，有可清晰看到的价值。工作细节需要沟通确认，而且计划分解得越详细，执行力就越强。

如果目标、思路、策略都得到了确认，项目经理就可以和客户项目组一起建立一个计划，落实大家的设想，再发动大家按计划运行。一旦计划确定，要立即行动。项目经理应该督促团队按计划高质量完成工作，催促客户项目组按照计划完成约定的内容，并提供技术支持。除非有系统不能解决的问题，否则在技术支持阶段就不需要大面积现场投入资源。

如果客户按计划执行，项目经理需要不断主动了解进度，形成一种进度回馈，根据进度快慢采取适当措施，保障项目目标在实施周期内实现。

要推广的业务流不完整：

项目调研完成之后，项目经理一定要拿出完整的业务流实施思路和方案。项目团队调研的过程中，未必一定要搞清楚所有业务流和实现方案才能往下走。项目团队可以先解决完一个业务环节再往下走，把客户企业复杂的业务流程化整为零，形成相对完整的部分。

用一个清晰的效益目标牵引或作为愿景，促成客户企业各个业务流程不断上线。对于单个业务流程而言，配置一定要完整，一定要可以看到这个系统把客户企业实际中哪些事情真正实现了，而且实现得还比较方便，甚至是暂时不太方便，但可以完整实现标准业务流。

产品总是出问题：

一个理智的实施顾问开始工作的限定条件，就是用可能存在缺陷的系统来解决问题。一个优秀的实施顾问的价值，就是用最小的现场工作时间，让客户把系统用起来，用最小的开发工作量把流程跑起来。

项目经理必须采取主动的项目控制对策，提前加强对产品的验证，根据自己项目业务流程不断模拟测试，发现是否存在严重问题，并采取相应的对策解决。如果不是严重问题，可以先寻求替代方案，不影响项目实施进度，然后让我方公司规划部门将最佳解决方案纳入可接受的版本规划时间。

寻求替代方案应该是群策群力的过程。如果我方公司响应能力不足，项目团队要将其作为项目风险，提前和客户沟通，寻求支持和理解。

如果存在严重问题，就应该全力在我方公司开发层面推动解决产品问题，然后再去现场。

实施顾问一定要自觉花费大量时间做业务流验证，确保项目功能可用、够用，能够支持一个或几个完整业务流，没有重大产品隐患之后，再去现场推广。客户现场可以少去或不去，但是每次去之前一定要很清楚自己能解决什么问题，哪怕是一个很小的问题。解决问题、完成培训、客户落实后续计划后，就可以回来。

如果产品还有问题且一定要去现场，前提是项目经理还有其他可选择的业务方案或管理行为要去解决，这些问题可以和发现的问题独立存在，没有冲突。

在项目实施过程中，项目经理只要觉得具备一定条件，就要主动提出验收。验收是否顺利，往往取决于双方对验收目标是否一致。项目经理不断提出验收要求，就可以不断对业务目标进行清晰定位。反复几轮之后，验收目标就清楚了。这个时候，双方项目组该解决的问题就应尽快解决，不能解决的问题要想办法变通。

一个项目的验收未必是一次性活动，也不是某个点的成功或个人能力就可以做成的，而是由一系列验收准备工作组成的。在最终验收之前，项目团队要将很多阶段工作细化并得到认可，

验收前，除了做好可交付成果证明文档工作外，还要多花时间搞清楚客户的验收流程，千万不要让客户用不适用于本项目的质量体系来要求本项目的产品。验收前，双方一定要确认验收方法。如果是用测试验收，那必须有测试计划和测试用例。如果客户企业认为产品不符合要求，那么就应该用正式文档说明产品和最初设计相背离的部分。

整个实施过程中，要不断通过详细备忘录来约定和强化验收条件，并强调我们正不可逆转地接近验收条件。关键项目进展一定要形成备忘录，并取得客户确认。

一般模式是按照业务内容分成几个阶段目标，完成一个业务目标，就完成一个阶段的验收，并收取一部分实施费用。

项目验收的最小条件，是一个或几个基本业务面能够开始大面积应用。这些基本业务面是不是很简单，或者功能是不是很稳定，或者人员是不是一定全部上线，或者业务面上是否存在可改进功能，这些问题都不一定有统一规定。

但是，只要客户看到这些基本业务面可以运行，并承认这个可预期的结果，项目就可以提出来验收。

合同边界里没有涉及的一些好功能或者有价值的地方，实施过程中，项目团队可以不全部告诉客户，在验收前作为交换条件，和客户置换很难实现的其他技术要求。

要想成功验收，必须设置清楚一系列与项目应用业务层次挂钩的里程碑。

客户最终关注的是业务是否可用，并不关注是否一定得实现所有产品功能，也不是说将一些所谓的技术难点解决了，客户就同意验收。客户要的只是验收的实实在在的效果。

在进行业务调研的时候，就要主动控制项目的业务边界，将一个个业务流根据企业实际情况合理组织实施顺序，形成项目实施计划中的里程碑点。明确达到里程碑点的业务上线条件，并得到双方一致正式认可。

项目团队必须在深刻了解客户业务基础之上，提出客户企业的业务目标，阐明项目价值所在，让客户接受业务目标，并按照这个业务目标去实施，而不是纠缠于有什么功能或没有什么功能。

成功验收的核心就是项目边界的确定。项目经理应该想办法让客户一起参与解决方案思考过程，变成客户自己推导出来的业务实施目标。

如果要开验收会，最后汇报工作的质量要争取达到让企业领导满意的高度。

汇报会前期要准备好一套模拟现场环境的演示环境，要有足够真实的数据；要设计一套体现应用特色、介绍流程的材料；还要准备一套详实的汇报材料和相应的演示文稿。

最好在验收大会前，将相关汇报工作和现场应用情况与企业领导做相关汇报，并得到充分认可。

理解客户真实的问题，是顺利验收的关键。实施验收时，一定要确保交付成果的状态满足客户对产品的要求。

而且越早谈回款，越早明确验收边界，项目边界越清楚，就越容易验收。此外，实施进度越快，也越容易验收。

某块业务应用得到部分客户认可，就是催款的最佳时机。一旦项目某个业务进入可以使用状态，项目经理就要主动谈验收条件，明确验收和回款的关系。

一旦项目目标一致清晰之后，项目经理就要全力保障回款条件实现。

如果根据验收条件，项目存在开发需求，那么项目团队应该在第一时间向公司提出需求和改进意见，并强力推动纳入公司内部版本开发规划，为计划回款争取时间。

不管项目实施得好不好，只要开口要钱，客户马上就会提出现在付款不合适的理由。这个时候项目经理就要趁机明确：现在条件不合适，具备什么条件了才合适。

要钱被拒绝不可怕，可怕的是搞不清楚为什么被拒绝。项目经理要和客户不断强化回款条件。有了回款条件，就等于给自己清晰约定了工作目标，把这个工作目标写进后续工作备忘录，达成一致意见后落实。

回款条件也不是一谈就要立即写成备忘录。先不断提出各种可行回款条件，逐步优化，选择合理的条件让双方认同，并不断利用各种给上级领导汇报工作的机会明确，最终写到备忘录里，成为未来验收工作开展的依据。

一旦彻底达到回款条件，就要请商务人员去做商务工作，技术人员可以去催钱，但最好不要直接接触钱。

客户很难连续拒绝三次请求，特别是每次拒绝之后，项目团队都把工作约定要求推进一步的时候。在客户出现松动的时候，千万不要轻易撤离现场，不见回款不走人，把回款当作意志较量。