超越对手—软件项目经理的18种实用技能

《超越对手—软件项目经理的18种实用技能》导读

发表时间：2007-9-26 张志 来源：e-works

关键字：IT项目管理 实施 技巧

信息化应用调查在线投稿加入收藏发表评论好文推荐打印文本

本书介绍了作者在实践中学习和摸索出的18种软件项目经理实施技巧，包括：如何做公司介绍、如何做售前调研、如何写售前解决方案、如何做产品演示、如何做技术交流、如何做公司考察、如何做用户考察、如何做高层沟通、如何开启动大全、如何做实施调研、如何处理用户需求、如何编制实施解决方案、如何编制实施计划、如何写工作备忘、如何做用户培训、如何做现场推广、如何做项目验收、如何有效回款。

本书介绍了作者在实践中学习和摸索出的18种软件项目经理实施技巧，包括：如何做公司介绍、如何做售前调研、如何写售前解决方案、如何做产品演示、如何做技术交流、如何做公司考察、如何做用户考察、如何做高层沟通、如何开启动大全、如何做实施调研、如何处理用户需求、如何编制实施解决方案、如何编制实施计划、如何写工作备忘、如何做用户培训、如何做现场推广、如何做项目验收、如何有效回款。

书中贯穿着变通性和创造性思维，是一个具备第一手经验的人的心得。

本书可供管理软件项目经理、咨询顾问及实施人员参考，也可以为企业信息化相关人员参考。

目录

我是一个项目经理（自序）

第一部分 售前顾问的核心技能

第一章 如何做公司介绍

介绍公司有三点一定要讲到：

业务讲到：要让客户清楚我们能为您提供什么，做什么，如何合作。

实力谈到：要让客户明白和我们合作为什么可以放心。

案例说到：要让客户知道我们不是在说大话，有很多用户和我们一起取得了成功，并有案可查。

只有和客户建立长期多次接触机会才能创造机会了解客户需求，拥有可能让客户逐渐认可公司的实力和能力的机会。

越是要做大项目，越是要让别人觉得你是一个值得交的朋友，而不是一个销售经理，所以未必要急于马上或者长篇大论介绍公司，要巧妙用自己推销公司，用公司推销自己。

• 案例

小李好不容易争取到一个潜在客户同意见面的机会，客户在谈话过程中想请小李介绍一下了解他们公司是做什么软件的，能解决什么问题。小李觉得这是一个激发客户购买兴趣的机会，就请允许客户给他10分钟时间，他借机把公司和产品做了全面介绍，结果滔

滔不绝讲了20分钟，最后留下一份精美公司数据给客户。

请问小李这样做对吗？

点评：

象上例的小李可以在客户提出介绍要求时先感谢客户的关注，再用很简短时间（2~3分钟）介绍公司和产品，主要是说明企业有哪方面的业务问题是可以考虑上我们的软件系统，这个过程中最重要的是判断客户这里是否存在项目机会（预算），如果有项目则应该考虑建议客户安排时间做更长的交流或者业务沟通的机会，在客户不愿意配合的情况下必须制造再次接触的理由。例如这次故意送一份简单的数据，下次再送一份更精美的公司资料上门创造更多接触机会。

如果没有项目就和客户约定保持良性沟通方式，确保客户想上项目的时候想起通知我们的公司就可以了，不应该耽误客户太多时间，更没必要发送精美公司介绍材料浪费成本；除非客户真有兴趣，业务人员恰好也有多余时间，那可以多谈一谈，更深入了解情况。

• 案例

小李开始一个正式介绍时，才讲了五分钟，客户有人打断他的发言，说我们想看一些实际的内容，公司介绍还有一些虚的概念理念就不要讲了，你演示下软件让我们看看怎样解决我们实际问题。

请问小李这时该怎样做？

点评：

如果事先有产品演示的准备，此时小李可马上表示：“我接受企业的意见，但与会还有人好象从来没有见过，因此请企业给我们五分钟用最短时间让我们介绍完公司，然后马上进入技术交流，好吗？”， 这样企业一般不会反对。

在这段介绍公司时间内注意讲要点和一些案例应用，同时快速根据大家对一些应用案例反应重新再组织一次自己产品演示思路。经过一个简短精练、着重强化公司专业地位的介绍后，配合的技术人员也可以很顺利地进入演示状态，效果自然很不错。

如果介绍前完全没有意识到客户会要求演示，并做好相应的预案准备，这次演示效果很难做到有效，只能尽量要求安排专门时间演示，强调这次约定的公司交流，不过可以先把产品简单沟通一下，留下转圜的伏笔。

此外也可以说管理软件是个系统，很难简单通过操作来演示，一般管理软件也是重点谈解决问题思路，而不进行具体接口操作，不过我们可以结合一些企业问题和案例介绍我们是如何做的，解决问题过程和方法是什么，大家觉得这样可以吗？

整个过程重在不慌不忙，沉着有序应对，给客户一个专业沉稳的印象。

一般客户对软件公司是很好奇的，又不生产物质产品，很难和其产品线比较，因此没有什么考察经验可以参照。要通过介绍让用户留下深刻印象并不容易，在总部介绍公司有“三讲” 窍门。

· 讲故事

不要呆板的介绍公司，而是要讲故创业事。例如我们谈公司人数可以请用户看老照片，

结合老照片讲公司创业艰辛到发展壮大历程，边讲边和客户互动，看着老照片，听着软件人创业的故事，客户就容易从心理上接受这个朴实认真的公司了。

·讲特色

特色主要指软件管理和业务上的特点。

一般管理上特色是结合组织机构介绍进行的，要给客户生动介绍公司的组织机构，介绍人可以和企业采用比方的方法，讲软件研发部就和客户比方成企业的生产车间，到测试组就和客户比方成企业的质检车间，这样企业就很快明白组织结构的作用和价值了。

业务特点是请客户看软件研发工具，例如请他们看源代码管理工具，看安全保密工具，请他们看软件自动测试工具，这些是客户很少见到，但见到后又很容易认可软件公司规范可靠的细节管理，而且有新鲜感。

·讲文化

在给客户在公司做介绍，不仅仅要介绍公司经历和管理特色，还要通过这些内容突出我们公司文化价值观，形成和客户的共鸣。

第二章 如何做售前调研

售前调研的目的

让客户认为调研者有足够能力了解企业业务流程问题所在和设计解决之道。

要随时给竞争对手制造门坎，了解竞争对手给我们设计的门坎。

调研获得的信息足够让后续工作开展。

售前调研和售后调研的不同

售前调研一般是为产品演示，技术交流做准备，同时在调研过程要注意突出自己强项，给竞争对手制造门坎。

售后调研一般是为解决方案，项目实施做准备，同时调研过程中要注意寻求项目价值点，利用价值点置换项目边界，尽量把项目边界最小化，项目才容易受控和成功。

售前调研一般没有确定正式合作伙伴，客户不太愿意配合，也不愿意投入太多时间精力。

售后调研有合同和目标约束，企业一般会花大力气配合启动。

售前调研一般由商务和客户协商时机，商务人员根据实际情况和客户协商确定是否需要调研，是先交流再调研还是先调研再交流，是在竞争对手之前调研还是之后调研。

售后调研在合同签定后必须尽快启动，而且应该在项目启动大会前后趁热打铁展开调研。

售前调研一般由于时机难以把握，不可控制因素太多，往往突发性强，客户也无法有足够精力和供货商沟通，因此对工作计划性要求不高，即使有计划安排更多也是形式上意义。

售后调研用户比较关注过程规范性，对工作计划性要求比较严格。

售前调研一般要协助商务攻关，所以不能轻易在现场不慎重地发表对业务或技术问题倾向性看法，要深入了解事实，策略性表达对问题的认识。

售后调研可以相对直接提出问题，摆事实，陈厉害，争取最大范围重视，进而获得管理支持。

售前调研一般很难见到企业高层，接触形式有限，时间有限，也不可能获得管理层明示支持。

售后调研前一般要和企业高管紧密接触，取得支持，可利用企业管理层力量要求企业人员配合进行。

售前调研结束后不一定需要给企业留下调研记录，往往是通过其它方式（交流，演示，方案）来验证调研质量。

售后调研每个阶段结束应有规范文文件记录每天调研工作，通过过程文文件来审核工作质量。

…… ……

案例

客户经理小李向公司申请咨询顾问来一个重要客户现场调研，但公司比较好的顾问近期都有任务不能响应，但可以派一个经验不太丰富的顾问来配合小李，小李申请这个调

研机会很不容易，而且客户项目快接近选型确认，不立即进行调研很可能导致后面工作被动，这个时候他该什么办？

点评：

越是重要客户，时间压力大的售前调研越要想办法争取有足够经验的人去现场工作，不能用经验不足的人去完成所谓这项工作。

没有经验的人在现场呆得越久越耽误在现场做工作的时机。如果难以协调到合适的人，安排一个水平不足的人员先去调研，这种人往往只能按照公司提供的模板找一些人，问一些问题，不可能在很短时间内抓住企业的关注点，提出的问题都很概念化和范本化，这样的调研质量很难让客户建立我们和竞争对手差异化区分。

因此小李应该和客户沟通，说明申请一个好的顾问调研对项目成功是非常重要也是负责任的体现，争取客户理解并调整调研时间，如果客户时间实在不能调整，就必须根据项目重要性确保公司安排高水平顾问到现场工作，哪怕时间短一点或牺牲其它不重要的项目。

此外小李下次和客户约定调研时间时，一定要在内部先和顾问沟通时间行程安排，这样才能从根本上提前预防这类工作冲突。

第三章 如何写售前解决方案

售前阶段不要轻易提供解决方案。

解决方案难写在哪里？

没有体系

没有个性

没有素材

没有时间

不好的解决方案十个特点

只有厚度，没有质量

只有论点，没有论证

结构不清晰

业务解决方案成为功能列表

口语书面语混杂，遣词造句不严谨。

没有认真检查，存在大量硬伤。

过于突出自我

没有体现公司产品最新进展

文字太多，图表很少

没有评审

方案检查清单（共61项）

好的方案应该设计一个好的封面，好封面的标准就是有视觉冲击力。

建议书的要求是简短紧凑，内容详实，目标规划清楚，便于客户高层决策，可以在一份建议书中形成几个可选技术方案，推动客户高管决策。

实施方案的要害是具不具备可操作性。这里面判断方法就是实施计划越是结合业务细化越具有可操作性。

投标书一定要坚决按照客户提供的招标书要求准备，客户如何要求就如何提供数据，不要任意发挥。

第四章 如何做产品演示

演讲更侧重对某一个问题看法的陈述，主要是交换观点，允许争鸣，听众可以不同意你的观点，但一定要捍卫你发言的权利。除了常见的演讲比赛外，很多时候演讲者是受邀请，以一种被尊重状态出场，是处于一种比较从容的心态下开始的。演讲的过程一般也是比较连续，不会被随意打断的。

答辩更侧重对话双方的交互，具有很强的考核目的，通过对答辩问题的反应，答辩主持方来主动判断他想获取的信息可靠程度。答辩的过程一般是不连续的，随时都可以中断响应不同的问题，答辩的节奏和压力也更为紧张，时间非常紧凑。

培训更侧重于传授操作，此时被培训者已经认可培训者所在公司和产品，在过程中更多的是教学相长，形式可以多种多样，根据不同培训层次灵活组织。

演示不然，演示是有极强的目的性。演示往往是要求在有限的时间内（但比答辩要舒

展），面对一群不同心态或者不明心态的人，快速地把自己所在公司、公司产品和服务，包括自己最大范围推销出去。演示过程中还要随时准备开始各种技术答辩，应付各种难。演示是追求主动影响客户（用户）的过程，售前演示也是主动和竞争对手竞争的过程，演示更是个人魅力展现的过程。

整个演示就是一场复杂的脑力游戏，看看我们有什么办法在短短1到2个小时内更能抓住客户的心！

• 售前演示的目的

·介绍公司，通过自己的言行和产品介绍展示公司的形象；

·强化自己的优势，给竞争对手设置一定的进入门坎；

·分析自己能为客户做什么，解决什么问题，愈是客户关心的问题愈要主动沟通和交流，让客户对软件产品技术和实施能力放心；

·进一步判断客户关注的项目重难点，了解我们前期准备的不足，采取针对性后续行动。

• 售后演示的目的

·详细介绍公司和产品，让广大具体用户认可产品，取得最大范围业务认同，减少实施阻力；

·宣讲对企业问题的认识，提出自己的业务解决思路，主动控制项目边界；

·通过现场互动进一步判断客户关注的价值点是否在项目边界内，确认是否要调整项目边界，尽快回馈给实施团队或公司决策

• 案例

咨询顾问小李和客户经理一起首次拜访了一个客户，并应客户交流做了一个感觉不错的产品演示，企业也表示出很大兴趣。

过了很久小李听说客户后来选择了另一家产品和能力都不如自己公司的供货商，为什么会这样呢？

点评：

大部分客户一开始并不了解管理软件的全部概念内涵，并对自己的业务需求也没有清晰化认识，往往在经过供货商多轮技术攻关后，客户才能比较清楚一些理论概念和自己的业务需求之间的关系，才能逐渐看懂产品演示，此时的产品演示也能达到目的。

过早的演示往往是对客户进行启蒙式教育。一个共同的经验是，企业对于自己完全不理解的事情，无论演示者水平如何出色，总体效果不会太好；对自己有足够了解的事情，即使演示者水平一般，企业还是能听懂个七八分。

很多客户经理其实缺乏销售管理软件的经验和从容自信的心态。因此当发现一个项目需求信息后，他们要么被动地随着客户要求走，要么就过于积极主动创造调研和演示的机会，期望通过一次良好的演示或者用户考察达到商务成功的目的。

实际上一个周期很长的管理软件项目匆匆忙忙去调研演示，效果往往不好，反而造成

工作被动。在需要长期跟踪的项目上，往往是早起的鸟儿没虫吃。因此演示最好在充分了解客户关注点的情况下开始，而且要充分考虑如何应对竞争对手的效果最佳。过早演示往往是一个无用的商务活动，还会为后续工作制造麻烦。

在大项目上是不会有太多的演示机会的，特别是在多竞争对手的情况下，宁可等到演示策划确定和准备就绪后，才和客户预约，哪怕耽误一些时间也不用担心，只要给客户解释清楚，客户一般都会理解的。

不要怕耽误一个月两个月时间，管理软件项目不在于跟进时间长短，而在于能否准确定位客户心理需求并给予良好解释。当然那些客户经理自己都没有跟踪，主动找上门来的紧急客户项目例外。

第五章 如何做技术交流

充分利用信息不对称

为什么存在技术交流呢？就是因为在IT管理系统和应用企业之间存在着严重的信息不对称。技术交流的诀窍就是如何有效利用信息不对称的空间去交流。

信息不对称就是利用大家对全力配合和目标定义的理解不同，让项目可以先进行下去，如果直接告诉客户需求不合理，可能会导致很严重后果（直接出局）的情况下，可以考虑先策略性进行回复，以期获得再次沟通或合作的机会。但在取得机会后，一定要在后续沟通中逐步引导客户意识到这些目标的不合理性，逐步把项目往客观的方向靠近。

利用信息不对称并不是利用客户对行业和产品的不了解去欺骗客户，说服他们购买，

然后让客户感觉到上当受骗。好的技术交流从理论上应该是针对客户的疑惑，依据业务现状和管理常识来解答，帮助客户得到一个合情合理，客观真实的解答。现在越来越多的用户趋于理性，只有用真诚的心态去交流，才能取得客户的信任和尊重。

• 案例

咨询顾问小李和客户经理一起参加一个客户技术交流，这个项目参加对手不少，小李他们是比较晚才进来的，客户告诉好几家供货商表示能够实现某功能和在三个月内完成实施，询问小李他们是否也能做到？

小李认为这个项目实施难度很大，在三个月完成非常困难，至少要六个月时间，这个时候他该怎样回答客户呢？

点评：

一个咨询顾问必须认识到目前在中国大部分项目上还多少都存在过度承诺，或者滥用信息不对称进行目的性很强的商业暗示的做法。

在项目中经常碰到客户要求供货商承诺做目前无法做到的功能，这种情况是非常难应对的局面，说能做好像是撒谎，说不能做好像是示弱，可能直接导致出局。有的项目对某些技术条件是硬性条款，拒绝就等于放弃。

有一些客户提出的要求本身就不具备合理性，例如有的客户要求无论出现怎么情况项目实施必须保证百分之百成功，有的客户要求项目实施周期必须在三个月内搞定，这些都是典型的不合理需求。

对不合理的技术要求，可以明白告诉客户“有所为，有所不为”的原则，争取深入沟通、了解这些不合理的技术要求到底是为了解决什么问题，这些问题是由哪些更根本的原因造成的，是否存在其它合理的解决手段。

如果是涉及实施周期问题，一般按实际需要理想周期介绍，如果客户对周期非常敏感，可以讲只要企业全力配合，合理定义项目目标，是可以在三个月内做到出成绩的。

其实大部分客户经过一段时间合作后都会趋于理性，可以接受项目边界和软件功能的调整，特别是真正进入合作后，谁也不愿意做一个没有成效但到处过度承诺的系统。如果大家都是追求成功，就一定能找到合理的妥协之道。

针对客户中不同性格的人，交流也要注意策略：

表现型的人要多让其发挥，我们只要因势利导即可，争取他认同我们的理念，并宣传他认同的观点；

对于控制型的人，我们要想一切办法让他认同我们专业性和灵活性，用比较恭敬的态度让其觉得利益上不会受到伤害；

对于友善型的人，我们一开始就要敢于宣讲，让其觉得我们的气势是建立在充分自信之上的；

对于分析型的人，这种人在技术交流时是最危险的，注意谨慎小心，言多必失的道理，话不在多，在于精确可验证。

针对感情上倾向支持自己的人，技术交流的目标是巧妙为其提供说法和炮弹以从内部

打击对手；

对于感情上中立的人，技术交流的目标是说服其成为支持我们的人，至少是无偏向的人；

对于倾向于支持对手的人，技术交流的目标是让其在心理上对对手的技术难点和实施能力患得患失，最后可能在压力下成为骑墙派。

对于想法特别多，思维跳跃的人，要冷静分析其想法的合理性，对客户想法和自己想法的矛盾之处做出合理解释，并提出自己的处理意见，否则很容易陷入一种被动响应的局面，成为客户引导软件供货商的局面。

对于没有需求的人，技术交流不要谈功能细节，要更多帮助其建立业务能力信任，甚至是个人魅力信任，有了信任，自然能判断出有什么需求可以帮助其解决。

对关注细节的人，要主动谈理念，让他感觉到高度；

对关注理念的人，要主动谈操作，让他感觉到理念在细节层面上已经落实。

对关注技术的人，要主动谈实施，让他意识到管理系统并非是一个技术决定的系统；

对关注实施的人，要主动谈技术，让他意识到没有良好技术基础保障，仅仅空谈实施方法也是无用的。

第六章 如何做公司考察

公司考察接待往往注意大的安排，但对细节落实关注不够，给客户留下不好的印象。

常见的考察细节错误举例：

1、没有通盘考虑每个行程的时间开销，及时通知每个活动负责人提前准备，按时启动，导致很多行程因为节奏拖沓被拉长，很多计划内重要交流内容被迫缩短，或者难以达到质量。在接待时，有经验的人应该预见到可能哪些环节要留足够时间余量，哪些环节可以挤出一些弹性时间，保证整体计划按进度来。

2、只注意安排有车接，没有注意告诉司机有几个人和多少行李（安排车过小），没有落实到具体司机，没有留司机联系方式，没有确认司机是否按时发车（特别是接早班火车或晚班晚点飞机时）；

3、住宿安排没有考虑客户报销要求，安排宾馆过贵或者票据不符合报销标准，客户住宿标准过低时没有想办法申请预算解决住宿问题；

4、早上或很晚接到客户时没有想好早餐或晚茶地点，临时又找不到合适地点；

5、接待所持的欢迎标语牌上企业名称不正确或者用简写称呼；

6、只注意落实每个接待环节负责人，没有和负责人沟通关于客户各方面的情况，导致各个配合接待的人心中无数；

7、没有亲自检查公司介绍材料中是否有和自己前期说法不一致的地方，并做好对策；

8、接待客户过程中在下车，交换名片，称谓，递水，入座等细节不注意商务礼仪；

9、没有提前规划餐饮，点菜时间长，菜样不好；

10、游玩安排不考虑天气因素，没有给客户准备好饮料食品和相机、伞具；

11、购买礼品没有考虑是否便于客户携带；

12、送客户走没有亲自送到站台，仅仅是到车站就走。

第七章 如何做用户考察

如何确认典型用户？

首先要将对公司市场工作最有利的典型用户筛选出来，这些用户其实在售前跟踪时就可以通过客户ABC分类加以明确，这样即使某些用户在第一次合作时项目金额并不大，也可以在在项目实施过程重点保障，重点投入。

一般选择典型用户名单考虑以下七个因素：

1） 应用效果。

有三类用户可以做典型用户。

第一是成功进行了大量应用的用户，最好的典型用户应该是每天都有大量人员利用系统进行工作，而且在实施过程中有很好的参考作用。这样有实际应用效果的用户最能让其它客户相信软件公司的能力；

第二是一些应用面还不够大，但基础资料都基本录入，典型业务流都可以实现的用户；

第三是应用很一般，但在技术上有特点的用户也可以考虑作为典型用户。

2） 商务关系。

所谓典型用户，就是能够替公司提供宣传的用户。这些用户论高管还是中层干部或者基层操作人员应该认同软件公司产品，愿意推荐软件公司的产品。

如果没有好的商务关系，用户甚至对软件公司还存在意见，即使应用情况不错，也要考虑是否适合做典型用户。典型用户的商务关系应该一直有专人负责跟踪和维护，仅仅靠客户经理和实施经理（要考虑客户经理和实施经理的稳定性问题）维护是不够可靠的。

3） 行业影响力。

影响力越大越好，一般情况下行业影响力大的用户公司应在商务和实施时区别对待，重点投入，而不要简单受项目金额大小左右，否则可能造成服务资源不够，做坏一个，丢掉一片。

4） 业务应用丰富。

不是一个用户实施比较成功，参观就一定有好的效果，要选择一个业务应用尽量丰富的企业，这样的考察效果才能达到全面完整。一般随生产模式（单件，多品种小批量，大批量）不同，业务应用丰富的企业也要选择几种类型才能适应不同生产类型用户考察需要。

5） 地域辐射力。

典型用户的地理位置应该交通方便，不然会增加客户交通成本，也增加公司接待成本，而且无法起到长期辐射作用。一个全国性公司一定要考虑在全国建立可参观考察的典型用户网络，仅仅只有几个典型用户参观考察对用户本身也是一种巨大的骚扰，而且对很多不方便出省考察的地域性客户，没有当地典型用户是很难做到有效辐射。地域还应考虑到周边游玩餐饮等因素，这也是客户接待考察环节中可以充分利用的资源。

6） 服务资源。

典型用户并非一定是所有问题都解决了的用户，往往是经常性需要服务的用户。因为应用深入，反而新的需求比较多，合作机会比较多。但很多时候典型用户在协助软件公司做一些参观考察工作，往往提出软件公司帮助免费解决一些软件应用问题，这样典型用户如果完全没有服务资源往往会出问题，难以让典型用户长期保持一个良好的考察状态。

7） 介绍资源。

典型用户接待效果在一定程度上取决于用户有将把业务和信息化实施相关问题介绍清楚的人员，如果有一个这样业务能力比较突出，信息化理念清晰，又全程参与项目实施过程的企业人员能介绍项目实际情况是最好不过。

典型用户确认条件未必一定要以现在是否可以立即考察做依据，而是应该综合以上因素后确定名单，然后通过一系列工作努力让这些合适的用户成为可以参观考察的用户。

选择典型用户的最关键因素就是这个企业本身业务典型不典型，行业辐射力大不大，其次是综合考察成本是否最经济。

• 案例

客户经理小李的一个客户要求看一看他们的成功典型用户，正好小李公司有一个做得不错的用户，经公司同意后就推荐客户去这家用户去考察，这家用户和小李的客户业务不完全相同，但没有更方便的考察用户了。在陪同客户去用户路上，他一直在担心用户考察效果。最后考察完成了，小李感到尽管用户实施效果不错，但好象客户感觉和他们企业关心问题不相同，要求小李再安排一家已解决他们关心问题的用户去考察。

小李在这个考察过程中到底该如何做才能更好呢？

点评：

很多软件公司感到困惑的一个问题就是管理软件项目实施效果往往和预期有一定差距，能全面应用软件全部功能的用户非常之少（这需要产品功能、性能、实施力量，业务客观需求，用户配合多方面因素成全），而很多选型客户总是希望看到一个自己需求类似、全面应用的用户，以放心选择合作伙伴。实际上不存在完美的典型用户。我们知道大部分情况下我们很难依据客户要求提供类似的考察用户。

客户经理总是把项目考察成功的希望寄托在让用户看到一个真实全面和类似应用的标杆上，对典型用户的考察效果全面寄托于样板客户的实施和应用水平。

按没有同行业典型用户无法成交项目的逻辑，则任何行业供货商都应该没办法做新领域的第一个项目，因为他们都没有样板用户。

事实上，客户经理可以选择一个有影响力的用户，最好与客户的生产类型比较接近。

在考察之前，客户经理最好是和用户介绍人面对面交流一次，听听他对一些关键问题的说辞，确保符合公司要求，防止说漏口或介绍自己认为是很得意的工作但恰恰是别的客户的忌讳的工作。

现场交流时客户经理可以安排用户主动问客户关心的问题，等客户说出自己的问题时可以根据情况要求用户立即强调这些问题在我们企业也存在，但通过上软件项目已经比较好的解决了难题，以此引发两家企业产生业务共鸣，让企业觉得的确考察的是类似行业性问题。

客户前来考察是提供脱离自己企业环境，可思考的机会，也是最容易接受别人思想的机会，整个考察工作如果精心准备和规划，自然能给客户留下深刻的印象，对项目成功起到关键的作用。

第二部分 实施经理核心技能

第二部分 实施经理核心技能

管理软件实施成功离不开优秀的实施项目经理。

对于非常庞大的项目，也许需要专职的项目经理，而它需要的是掌握项目目标定义、具备复杂组织目标和计划协调和沟通方面的专项能力。但目前国内大部分管理系统，合同金额现在很难超过300万，那么项目经理不仅要具备以上的组织、协调能力，还必须熟悉软件技术，了解业务，是一个综合性人才。

金额不高的管理软件项目经理必须要具备准确的技术判断力，但只拥有技术判断力的

项目经理也不足以完成项目实施，他还必须具备很多软能力。项目经理的软能力综合体现在目标设定，有效沟通，领导团队，指导下属四个方面，这些能力在实施不同阶段中都有很高的要求。

管理软件实施很少有一帆风顺的的项目，即使事后再看成功顺利的项目，其过程也是复杂艰辛的，在这个过程中，项目经理在质量和信念上的综合素质可能比他的智力和知识更重要。

好的项目经理绝对不是一个老好人，一个老好人往往不懂得拒绝，承受了过多自己不能承受的压力和责任，最终把自己压跨，把合作的团队也压跨。

好的项目经理一定是一个有责任感的人，一旦明白承诺了自己的目标，会想尽一切办法去完成任务，任务没有结束，项目经理内在的责任感会让他不眠不休地努力，推动事情往目标前进。

在前进的过程中，项目经理会象一块海绵一样快速学习，弥补自己在各方面的不足，直到建立自己对各种复杂业务的驱动能力。

经过无数次痛苦的磨练，项目经理慢慢就变成一个心态非常从容，但是决不轻易放弃目标的人。项目经理会由一个被业务驱动的人变成一个主动控制业务的人。

好项目培养好项目经理，好项目经理能成就好项目。

第八章 如何做高层沟通精彩观点摘要

在管理良好的企业一般是通过自下而上的流程去驱动基础业务，高管更多关注战略业

务层面工作，然后安排执行。在管理不佳的企业一般是通过自上而下的流程去驱动基础业务，高管不得不投入精力在业务部门调停争论，使大家投入精力到解决问题中去。

因此需要高管来推动业务有两种，第一种是非常紧急和重要的业务，按照常规的业务流程评审过程将使事情复杂化，失去敏捷的回应能力；第二种是牵扯到多个部门利益的新问题，暂时无法通过流程达成一致处理方式，也就是中层无法决策或达成一致的事情，请高管决策。

大凡领导都喜欢处理正式的文档。

有四类报告高管是不注意或不能有精力真正重视的：

过长的文档：给高管写的文字一定要在三四页纸甚至更短的页数内解决问题；

只提出问题，却没有清晰解决思路的报告：除了给高管带来烦心感外还有什么大的价值呢？

组织条理不清，逻辑结构混乱的文件：也是无法获得高管认同的。

只从自己角度思考问题，没有站在全局角度思考问题的文档：高管会觉得信息量太小而无法决策，报告也就不了了之。

切记：理性、客观的汇报工作是任何一个明智高管欢迎的作风。

第九章 如何开启动大会

不开启动大会的几种情况。

弱势软件公司签下了严重过度承诺的合同

国内软件公司绝大部分都是弱势公司，即使是一些产值很高的公司都不见得比一个国外小公司产品有影响力。

弱势公司为了击败强势公司，往往会用较低项目金额承诺一些定制开发。而强势公司完全可以要求企业按照其产品进行业务流程重组，尽管很多时候依据国内外咨询公司建立的新流程也未必高明和实用，实施效果也未必好。

这种过度承诺的项目从实施角度来看风险很大，很可能在项目启动后很长一段时间内软件供货商都很难拿出合适的产品到现场实施。此时，必须低调处理项目启动大会，甚至暂时不召开启动大会，在项目找到可实施路径的时候再召开启动大会更合理。

金额很小的项目可不召开启动大会

有的企业虽然签订了一个复杂的合同，但投入的费用其实很不合理，供货商出于种种原因还是签订了合同，此时指望供货商提供强大的后续支持不太现实，因此项目经理尽可能不扩大项目影响，这样可以在合理条件下尽量调整项目边界，使之可以达到可承受的成本范围内。

如果召开一个高调的启动大会，企业主管领导可能又号召大家动脑筋、提建议，发动面越广，项目需求越可能控制不住，此时高调的启动大会不但不能帮助项目顺利启动，反而很可能造成项目走不下去，企业的投入全部报废的后果。

在这种情况下项目经理完全可以和企业沟通，低调起步，取得一些成绩，得到企业各方面认同项目目标后，通过企业适当追加费用，把项目顺利完成。在这种情况下，低调反而是对项目的一种自我保护，会屏蔽掉很多不必要的干扰。

工具化，产品化的项目可不召开启动大会

现在上三维设计软件的企业很多，花费达到几十万的也不少，很多时候远远超过管理系统的投入，这里不讨论这种投入比例是否合适，但一个奇怪的现象就是，很多企业并不为这些花费不小的项目开启动大会。

原因很简单，工具型培训掌握的软件是没有实施风险的，业务部门很清楚掌握这些工具对业务和个人的好处，会比较自觉按领导要求去接受培训，在截止日期之前掌握软件，根本就没有召开启动大会发动全员重视的必要。

同样如果我们应用的是非常成熟的业务和系统模块，也可以快速调研、快速安装、快速培训、快速见效，那么也不需要召开启动大会，最多只需要召开一个推广大会，业务部门强化培训一段时间即可。

具备良好信息化实施经验和管理规范的企业不需要启动大会

如果企业的信息化工作已经成为一项日常工作，已经具备大量信息化项目实施经验，有良好的实施团队，信息化已经成为每个部门标准工具和日常流程中一部分的时候，再上一个新项目就不需要启动大会这种形式了。

经过充分磨合的用户可不召开启动大会

有的项目是老用户追加，再增加比较大的投入合作新项目，和软件供货商队伍磨合已经完成，新项目只是扩大应用深度，可以看做是历史项目不断的深入，此时也可不召开启动大会。不过在新项目业务流程验证完成后可以召开一个新项目上线动员大会。

无法摆平内部关系的项目可暂不召开启动大会

有的项目商务阶段过于复杂，选型结束后企业内部仍然存在矛盾，此时如果立即召开启动大会，很难快速化解矛盾各方，启动大会必然就流于形式了。这种情况下项目启动大会可以稍为缓一缓，创造出一些条件后再召开效果更好。

项目启动大会既约束企业，也约束软件供货商。企业对供应商专案组有合同约束手段，反过来软件项目组也一定要让企业项目组受到内部考核机制的约束，这样双方才能在启动阶段认识一致，同心同德完成项目实施。如果从启动阶段开始，企业项目组就变成软件供货商的监工，大部分时间用于检查软件供货商的工作，指责他们进度的拖延，而不配合软件供货商调度资源、推动进度的话，那么这个项目失败风险就增加了。

第十章 如何做实施调研

² 案例

项目经理小李和一个客户项目负责人约定要启动调研了，他写了份计划，说明调研派出团队人数和计划天数，还说明了调研要了解的大概内容，请企业确认能否按计划时间启动和开始。小李在得到企业肯定答复后来到现场，这才发现企业这边根本没有配合好，无论是要求准备的数据还是要求约的被调研对象，都没有准备。小李不得不调整计划，在现场重新落实计划的工作内容。

请问怎样避免出现这样的情况呢？

点评：

企业客观上都希望项目团队在现场的工作紧凑合理，不浪费彼此的时间。但用户并不清楚如何做这种调研，他们能做的就是按照软件公司意见尽量安排合适人员配合。

如果调研计划只是含糊说明某几天要来现场调研的话，实际上用户领导可能会回答，那你们先来，来了再说。结果到了现场发现准备不足，把大量时间都无价值的浪费在协调调研资源和等待上。

有的人把调研计划做好，告诉用户行程，就准备按计划去现场了，这样的调研者不及格。

有的人会提前发邮件或传真给用户，然后电话确认收到，然后和用户确认时间无问题，然后再去，这样的调研者60分。

有的人不但会确认计划时间，还会认真了解企业是否认同计划内容和是否有相关业务人员配合，得到肯定承诺后再去，这样的人80分。

有的人还会准备一些前期调研文卷和数据准备清单，让客户经理配合落实后再去调研，这样的人100分。

调研计划至少要做到80分！计划发给中国用户后，大部分用户一般是不会认真看和落实的，这是中国人做事的习惯，特别是一些地位不高的联系人，可能连为这个事找领导的协调能力都没有。所以打电话确认的时候一定要请用户确认是否可以按计划进行，得到

肯定答复后再出发，这样计划执行保障性会高一些，也给别人留下一个认真的印象。

² 案例

项目经理小李在调研过程发现一个客户项目中非常关注编码的问题，而企业的编码想实现编码规则，软件公司现有的产品肯定无法满足，小李花了很多时间说服企业项目负责人，指出企业现有的编码也是够用的，没有必要在启动阶段花费如此大力气折腾编码，项目负责人最后接受他的意见。小李用这种办法婉拒了很多客户需求，也就不投入精力进行这些方面的调研了，这样操作对吗？

点评：

控制用户的需求是合理的项目边界管理方法，只要和用户进行过充分沟通，达成共识，小李的做法是无可厚非的。

但如果在调研阶段发现用户认为是很有价值的问题是公司目前不能解决的问题，并不等于说服用户后调研工作中就可以回避。现在可以回避的问题不等于以后可以一直回避，更不等于在未来实施过程中永远不面对。合理的需求总是要冒出来，与其回避，不如先主动搞清楚，汇报给公司后群策群力，看看到底有什么办法可以解决。

如果有选择性问问题，就会遗漏一些关键性业务，这样对调研整体质量有影响，在后续制定解决方案工作中容易遗失业务环节。

如果确实不想引发用户一些天马行空的问题，或者的确不想引发他们高度兴趣的问题也有合理的回避方法，不过不是通过不调研达到，而是以单独认真记录，但不提供在正式

文档的方式规避。很多用户的很多需求都是一时灵感，没有经过认真思考，呈口舌之快，过了也就过了，不形成文字记录，用户自己也不记得自己说过什么了。

如果真是关键问题，会不断在后续阶段再提出来的，这个时候再确定写入正式档也不迟。

此外越是有公司产品明显不能解决的问题，越要调研清楚，搞清楚来龙去脉，为公司今后产品发展提供完整的需求建议。作为一家负责任的软件公司，首先要承认自己的软件不可能解决所有的问题，但一定要在发展过程中逐步解决更多的问题，调研时都回避问题，不就使公司产品失去了发展机会了吗？

真正的问题都是回避不了，绕不过去的。

第十一章 如何处理用户需求

处理用户需求需要知道的三件事：

用户提出的需求很少有不合理的，往往是用户提出的实现办法并不能真正解决问题而已。

用户提出的需求很少有不能解决的，往往是公司在现有资源情况下无法快速响应和服务而已。

用户提出的需求往往有简单的解决方法，如果答案很复杂，往往不是正解而已。

如何分析用户的需求

实施过程鲜有一帆风顺的，对于现有产品，用户提出不满，提出这样那样的问题是常有的事。用户提出需求的方式往往表现为强烈需要一个功能，这个时候很多实施人员可能开始考虑这个功能是否合理，是否容易实现，并以此为基础和用户展开谈判。

一个有经验的实施人员这个时候首先应该思考用户为什么有这个需求，不要光看需求的功能描述。首先应该考虑的是：用户这个需求的本来面目是什么。有时用户的需求也是用户自己加工过的，比如用户认为在某个窗体加个字段就可以实现这样一种业务，但实际上可能不是那么简单。因此，我们必须从需求出发把用户要解决的业务还原，然后再站在全局业务的高度考虑我们到底要解决的是什么问题。

还原了业务后我们可能会发现很多时候用户提出的需求往往是管理上的漏洞造成的，技术手段并不能解决业务问题，属于不合理的需求。

这个时候我们并不能轻易拒绝用户的需求，而是要和用户一起推导直到他们发现自己提出的方案并不能从根本上解决问题，然后再和用户探讨真正解决问题的办法，这样用户不但会收回自己的想法，还会建立对你分析能力的认可。

² 案例

项目经理小李接到一个项目，项目在商务阶段为了争取合同做了大量承诺，但实际上很多是软件很难开发满足的，这个时候企业负责人要求软件公司兑现承诺，否则不可能验收项目。

请问小李该怎么办？

点评：

管理系统销售为了争取合同很少有不过度承诺的，这是一种不可回避的现状。这种现状恰恰是造成实施人员的体现自身价值的机会，如何在最小化开发成本情况下有效解决业务问题，而不是指责销售团队，或者逼压开发团队。

很多过度承诺的内容是用户心血来潮的产物，真正在做项目时经过深入思考，用户也会接受理性的目标，不会反复追究。因此在调研阶段提供好的解决方案（提供清晰的项目目标和完整的业务方案）和与用户建立良好私人感情是多么重要！

此外由销售承诺的很多功能，其实未必是合理的需求实现方式，实施人员在业务调研过程中，往往有可能发现真正解决问题的办法。一旦和用户对某个需求功能实现方式形成僵局，实施人员首先要去了解业务，分析这个业务到底想解决什么问题，这个问题到底可以通过怎样办法来解决，可能能找到找到可替代的方案，甚至是更好更被用户接受的方案。

有的功能可以和用户一起评估这些要求和我们的主要项目业务目标的符合程度，如果需求对我们主要目标实现没有帮助，我们就可以尽力去说服用户先将精力集中在主要目标上，一个项目是不允许有太多分支目标来发散精力的。

如果个别用户还是非常固执要求实现自己的要求，一个有效的策略就是不主动激起用户讨论这些问题，淡化处理，拖一拖也就可能把问题拖掉了，这也是一种没有办法的办法。

第十二章 如何编制实施解决方案

没有清楚定义未来的工作远景的系统，追随者会越来越少。

实施解决方案和售前解决方案的不同：

1、从售前到实施解决方案要经过一个主体从软件公司能力宣传到企业业务支撑描述的变化。

售前阶段大部分项目不能提供详细业务调研的机会，所以售前解决方案以软件企业功能和实施经验为主，结合企业一些特色加以发挥，简单地说还是以软件公司为主，而售后解决方案是建立在详细业务调研基础之上，必须结合企业流程详细展开，以企业为主描述。

2、从售前到实施解决方案要经过一个从虚到实的变化。

售前阶段解决方案重在介绍一些理念和管理思路，总体上存在很多务虚的内容，比如项目目标主要从定性角度阐发，对价值主要从一般认识出发。

但经过业务调研后实施解决方案中要明确提出一些定量的目标，例如产品数据管理怎样叫做管理了，不能说不出所以然。同时实施解决方案对项目价值点要能结合部门，岗位和业务描述出在不同业务环节的不同岗位责任人能从系统中得到哪些方面的效益，进而支持企业的何种价值点，而不能再是放之四海皆准的泛理论推导。

同样在售前宣传的一些概念，要么在实施阶段找到落脚点，要么在实施阶段把这些天上的东西用地面的目标取代。

3、从售前到实施解决方案要经过一个从功能排列到操作串联的变化。

售前阶段对软件更多的是从功能列表角度去陈列，或者解释不同应用需要用到哪些功能，在实施方案就中就必须能够将这些功能真正串接成业务操作，让用户能看懂一个业务

在系统支持下从原始输入到最终输出的全部流程，而不能含糊其辞。

一份含糊的业务方案其实反映的是一个公司，一个项目经理对业务把握含糊不清的状态。这种没有业务串联的方案也难以指导项目团队成员有效完成配置和开发。

没有目标定义的项目很难获得成功。

编制实施阶段解决方案常见问题

第一、和售前方案几乎难以区别，都是价值点+功能手册的模式

实施阶段解决方案很容易从售前范本中学习到“假，大，空”的毛病，对软件价值缺少足够的逻辑论证，关键价值实现业务路径缺少分析。

实施解决方案很容易成为功能点的罗列，难以指导用户形成业务思路，也不能指导实施人员进行业务配置，也无法通过解决方案验证配置。

实施解决方案过多罗列价值点必要性不大，用户更愿意看到实现哪些业务流程，在过程中改善了哪些环节工作，是如何改善的，要如何实施，最终操作模式是怎样的。

软件功能点在软件功能手册中有，实施解决方案要针对企业业务进行数据建模分析，然后形成新的业务流程框图和操作思路说明。

第二解决方案对项目价值点关注很多，对项目目标关注过少，而且不细化，不量化，不提验证手段。

第三解决方案抄用历史模板图片，没有用用户的实际数据做图片。

第四在内容编排上和一些细节上不注意和售前方案呼应，基本不参考售前一些工作成果。

第十三章 如何编制项目计划

很多项目经理编制计划的过程就是参考软件公司内部的管理要求，借鉴一个历史模板加以修改的过程。甚至有不做计划，以为凭借自己的经验到现场一定就可以搞定。尽管机械地复制历史模版项目经理可以快速炮制出大量格式规范，内容丰富的实施计划，但是并没有技术含量，对实际工作也帮助甚微。

有的项目经理会义正言辞地辩称，这个世界其实“计划不如变化快”，整个项目实施过程就是踩着西瓜皮，走到哪里滑到哪里的过程，反正努力把它往前推动，尽心尽力就好。

现在很多计划一看就没有体现策划的过程，把软件公司业务方顺序当作项目过程分解依据，千篇一律。事实上所有的人都承认项目和项目不一样，不存在简单复制的关系，为什么计划这里却又可以理所当然地套用呢？

这些敷衍做法在实际工作中是大量存在的。我们可以将这一类人总结出一个共同的工作特性，那就是不做计划、消极地应付工作，处于受用户摆布的地位；而项目经理做计划的目的则正是希望。

设定里程碑容易出现两个问题，第一是把行动当作目标，第二是把完成重要关键事件和里程碑具体含义等同。

² 案例

项目经理小李一份项目计划目标中是这样写的：

计划目标：

· 和用户沟通工作计划

· 解决现场遗留的问题

·完成本次现场工作备忘录

然后再具体描述各项目标的子活动和时间配合安排。

这样编制计划有什么问题吗？

点评：

这样的计划目标看上去没有什么错误，但是所有这些目标看做是本次现场工作的一些活动更合适。沟通，解决问题，签署备忘录是实施人员在现场工作必须完成的一些活动，这些活动完成质量高低可以决定项目目标是否被达到，并不能认为做了这三件事情项目现场工作质量就高，就完成了项目目标。

本次现场工作目标和你整个项目的目标有什么关系？任何一个阶段工作都应该有利于项目总体目标或者某个分阶段目标实现，这个要实现的效果才是来现场工作的目标。

具体计划大部分实施人员就习惯列工作活动流水帐，并把完成流水帐作业内容作为受控的目标，而不关注本次现场工作要使项目达到怎样的状态。一个项目每个阶段每个人都这么流水帐写下去，项目到底要干什么，用不了多久大家都说不清楚，项目延期也指日可待。

这种流水帐计划还有一个巨大的负面作用，很容易将项目总目标一个个阶段中引入一些反复验证的技术细节，忘记了整个项目不是用于解决技术问题，而是要解决业务问题，使项目目标被转移到技术细节上。

第十四章 如何写工作备忘

备忘录首先要用书面的形式使自己完成的工作成果得到认可，让用户肯定公司在项目上的进展和努力。在工作成果得到确认基础上给项目的阶段工作做正面评价，为项目整体目标推进提前进行铺垫。一些重要的项目目标约定或者验收意见还可以单独写备忘录，在最终验收时可以作为参考依据。

备忘录要说明本次现场工作进行了哪些工作内容，达到了怎样的目的，和企业约定的下一步工作安排是什么，进度出现问题的原因是什么，哪些是企业的原因，哪些是软件供货商的原因。

备忘录最后要约定下一阶段双方工作安排，推动事情继续前进，尤其要注意约定的工作一定要在下次工作计划中体现。在后续工作中软件公司要尽量严格按照备忘录设计自己的工作计划，同时了解企业项目组约定的工作进展情况，如果企业项目组方面配合出现了问题，在下次备忘录中要明确指出责任承担方，给用户形成一定的压力，从而更好推动项目走向前进。

项目经理要让用户通过备忘录看到一个软件公司做事的规范性、一个项目过程中计划的承接性。

案例

项目经理小李在一个项目的实施过程中进展很不顺利，阶段工作结束后根本无法达到任何预期工作目标，这个时候用户对是否写备忘录没有什么要求。

在没有工作进展的时候是不是可以不写备忘录呢？ 点评：

只要有现场活动就必须写备忘录，备忘录不能报喜不报忧，对项目过程而言管理风险的价值比管理进度的价值更大。

备忘录是要付出额外的时间精力和管理成本的，但备忘录是一种过程活动的确认，是对下一阶段工作策略的达成共识的承诺。无论每次现场工作是否顺利还是要有一个清晰的备忘录，要清晰说明项目推动过程中出现的问题，在下次工作启动之前做哪些准备工作去解决。备忘录中一定要和用户沟通清楚下一步双方工作策略，不能因为工作进展不顺利就回避问题，更不能企图指望下一次现场工作，或者发行新版本后问题就会有进展。

如果可以预见在很长一段时间内现场工作都无法解决问题，那么写备忘录确实是一种折磨，是不断加深用户对和软件公司之间痛苦合作心态的记录。这种情况下可以技巧性地将几个阶段推进过程中积累取得一些进展后写一个总的备忘录，减少对彼此的刺激。

第十五章 如何做用户培训

IT项目经理必须明白一个事实：一个人在一段时间内只能负责有限个项目。

当企业自己本身没有或者找不到推动一件事情的内部动力的话，很难想象软件公司在现场有多大的作用。

项目经理管理多个项目的根本的出路是在企业培养替代者，而不是指望软件公司配置大量实施替代资源。

实施人员对培训目的要有一个清楚的认识：帮别人就是帮自己。

任何人在项目实施过程中都不要低估用户的智力和毅力。的确不是所有项目的用户都具有被培养的潜力，但在大部分项目中，从来就不缺乏能够培养成为一个好的实施者的用户，而且这样的人只要一个就足够了，只是项目团队自己并没有花时间去找到和培养这样的一个人而已。

在最短的时间内做最大量的事情，这就是成功将用户培养成替代者的秘诀。

没有好的教材也能做好培训，没有好的辅导讲解能力，很难做好培训。

对于一些大型项目，特别是用户执行力不够，现场培训效果不佳的项目，安排一次紧凑合理的总部培训会收到很好的效果。

第十六章 如何做现场推广

现场推广工作在具备四个条件情况下将非常顺利：

1） 经过充分现场功能验证，确定产品功能基本能连串起一个或几个基本业务流，并得到用户项目组书面认可；

2） 产品的稳定性和性能在可预见并发环境下性能能达到可使用要求；

3） 针对基本业务流的业务操作手册全部编制完成，并对相关用户完成培训；

4） 用户和软件公司都可以投入一定资源，主要是用户方有可推广资源。

优秀的实施人员的价值就在于用最小的现场工作时间让用户把系统用起来，就是用最小的开发工作量把流程跑起来。

案例

项目经理小李在一个项目上带领团队调研完成后，觉得基本上可以搞清楚企业业务流程，就带了三个人在现场封闭进行软件配置一个月，为此专门找用户要了一间办公室，每天都工作到晚上很晚。但用户对小李的工作不但不认可，还经常催促他们加快进度，小李感到用户太苛刻了。

点评：

推广失败的项目团队一种行为模式往往是项目团队把自己思路给用户一描述，甚至没有什么描述，就闷头大干，用户项目组不知道如何参与项目团队工作，只好去监督项目团队，成为项目的监工。而用户项目组又不清楚系统的思路和实施套路，只能按照领导意图来给项目团队施加压力，而不是和软件公司一起分担压力，这样状态下的项目自然难以受控。所以项目团队这样做的都是事倍功半的工作。

把用户，至少是用户项目组变成可实施的力量，并帮助他们推广实施项目，而不是依赖个人力量推动实施，把他们由项目监工变成项目执行者，项目团队成为监工和顾问，这样的实施才轻松有趣。

让用户真正参与项目实施工作，虽然用户累一些，但大家有了团队的感觉，心情反而更愉快，说个套话：往往在这个阶段和用户建立了战斗的情谊，为今后验收回款考察参观都奠定了牢固的基础。

所以项目团队在项目推广过程中要反复强调和贯彻和用户一起参与的方式，得到用户认可，在实际工作中落实。

例如软件安装，项目团队可以和用户约定，只示范装3台，然后安排用户方面的人装3台，项目团队在旁边指导，如果连续三次安装都成功，项目团队认为基本上问题不大，其它的都可以交给用户处理，项目团队只需要处理意外问题。

例如进行业务操作培训，项目团队先要经过讲解示范，确定用户项目组明白，立即请用户项目组操作，确定用户掌握了操作，那么后面的培训可以主动邀请用户项目组成员讲解，项目团队提供技术咨询，今后培训工作策划组织都可以逐步传授给用户项目成员负责，最后一般问题基本不需要项目团队出马，大面积基层用户都习惯和自己人交流解决问题，项目团队只负责解决软件的疑难杂症，而且某个业务被大部分人熟练掌握后，项目团队的工作主要就是新的业务流推广方案验证设计规划，还有保障项目进度的相关管理活动。

这样一轮轮循环，就可以让用户项目组慢慢成为实施的主体，而且在这个过程中用户项目组成员可以得到极大能力成长和进步，他们也会感谢项目团队的帮助。

第十七章 如何做项目验收

很多人会奇怪，项目验收条件还需要谈吗，肯定是按照合同和技术协议验收。

其实在业内目前大部分管理软件项目合同和技术协议现状是：不管项目金额大小，软件功能模块几乎是一个不少，用户要求软件公司承诺的服务内容和个性化开发也是一个不少。

软件供货商在竞争压力下很难完全杜绝的营销过渡承诺。在这种情况下如果要以完成合同和技术协议为标准进行验收，笔者以为达到合同原始要求发项目可能非常之少。

管理软件项目最开始一般技术协议只谈服务内容和实现目标，很笼统，结果在实施过程中很容易出现业务需求爆炸的情况，软件商难以应付。

这种情况下软件商就开始逐步细化产品功能点，按功能点确定软件细节，只要功能点满足，理论上就应该满足用户业务需要，用户就应该验收，至于业务能否运行，更多的是用户的责任，这里面更多的体现了软件商的自我保护。

实际运做时无论技术协议细致还是粗略，对大部分国内用户而言根本没有太大的参考价值，用户只会考虑其业务是否真的在系统上跑，并以此作为检验我们项目是否可以验收的标准，当然有的项目可以通过商务运做，在业务上线情况不太好的情况下也能验收。

所以现在管理软件项目一般模式是按照业务内容分几个阶段目标，完成一个业务目标就完成一阶段验收，收取一部分实施费用。

这种情况下项目验收的最小条件是一个或某几个基本业务面能够开始大面积的应用。

这些基本业务面是不是很简单，或者功能是不是很稳定，或者人员是不是一定全部都上线，或者业务面上功能是否存在可改进功能，这些问题都不一定有统一答案，但只要用户看到这些基本业务面可以运行并承认这个可预期的结果就可以谈验收。

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

成功项目验收的核心就是项目边界的确定。

实施人员平时做人要讲诚信，讲原则，才好验收，无非是三条：

• 做不到的事情千万别随意承诺；

• 承诺的事情一定要努力做到；

• 每次工作都使事情往前进步一点。

快速验收的心得

项目经理从一开始接手就必须建立三个内控里程碑目标。第一个里程碑是项目回款，第二个里程碑是树立样板，第三个里程碑是追加新合同。用做第三个里程碑的心态做第一个里程碑目标，看起来前期投入大一些，但自己投入也会促使用户投入，最终反而能更快实现第一里程碑目标。

越早谈回款，越早明确验收边界；越是边界清楚的项目，越容易验收。

实施进度越快越容易验收。实施周期越长的项目，新增需求越多，越不容易验收。

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

第十八章 如何有效回款

主动提出回款要求，这是很多实施人员最难做到的一点。不知道如何开口，开口后不知道如何回复用户的质问。

最难是开口要钱，开口后最难是觉得心安理得。很多实施人员总觉得项目做得还不够好，不好意思去要钱，用户一说你们哪里哪里还有问题还好意思来要钱，实施人员即使原来感觉做得不错也会灰心回去做技术工作了，因此回款这个事情最难的就是要理直气壮地去要钱。

每个项目回款要清楚如下信息：

谁是验收人？

验收标志是什么？（约定业务上线？约定业务可用？约定功能实现？约定配置和服务工作量做到？约定内容得到某人或某方（专家，省厅，总包方，监理方）认可？）

验收证明文档是什么？（签备忘录？软件公司标准格式验收报告还是企业指定格式的结项报告（验收报告）？或者是专家意见书或第三方监理意见书？）

文档签字方式是什么？（双方项目负责人签字认可？业务使用部门签字认可？如果有

多个业务使用部门或上下级部门要全部签字或是逐层签字？专家签字？需要第三方监理签字？ERP方（总包方）签字？）

验收方式是什么？（签字即可？开内部验收会？请专家或监理来开验收会（是否要准备项目各项资料，是否要准备汇报PPT或动画，是否要准备现场演示，是否需要企业的人亲自演示？）？专家组验收会？）

催款启动条件是什么？

催款金额是多少？

付款企业是否要做预算？预算周期是多长？回款资金是否可以进入或已进入预算？

谁是财务付款程序发起人？

谁是付款认可签字人？可能不止一个人，在每个阶段正常情况下要走几天，这些人出差是否频繁？

是否需要给流程中的关键人物兑现承诺？是否存在潜在可能打发的人？商务团队中谁负责维护和这些人的关系？

开的要求？（先开票再付款？先付款再寄票？是技术还是？开票单位名称、账号？前期已开是否收到？已开金额？）

企业扎帐日期？企业对口银行？银行扎帐日期？银行转帐周期？

企业资金情况和信用情况？他们期望采取或可接受的支付方式？（现金支付？支票支付？银行兑票？商业兑票？）