回归顾客——项目管理中的顾客管理策略
文/Peter I.Dimov, Petya S.Alexandrova 译/赵克琛，Aswini Kumar Tumu
为了留住客户，你必须信守承诺。不过，首先你必须保证所承诺完成的东西确实是顾客想要且需要的。
当你力图使客户满意时，请记住，一点小小的让步就可以维持顾客忠诚度并产生大量利润。《忠诚的价值：增长、利润与持久价值背后的力量》一书的作者弗雷德里克·莱希赫尔德认为：因不同的行业而异，顾客流失率降低5％，利润就会提高25－85％。
管理顾客期望并留住他们的业务对于项目成功和公司成长来说至关重要。总部位于美国康涅狄格州斯坦福德市的施乐公司在其顾客研究中发现，“非常满意”的顾客重新购买公司产品的可能性较一般顾客高18倍。如果你关注于如何使顾客满意，你将会确保你的行动产生许多令人愉悦的回报。
如果项目干系人没有精确的信息足以判断在指定的日期和预算内将会完成的内容，他们就必须依靠自己头脑中对于交付物的模糊印象了。一旦客户的心目中存在不现实的观点，那项目经理就被迫完成这不可能的任务了。相反，项目团队应该预先把所有的选择呈现给客户，这样他们可以做出可靠的决定并且提出清晰的需求。
根本原因
顾客的期望来源于过去的购买经历、建议、市场信息、竞争对手信息和你的承诺。有五种不同层次的客户需求：
l 明确的需求。顾客明示他们的需求或者工作说明书。这些需求来源于顾客基于其信念、理解和技术知识所形成的对解决方案的印象。不过，这种印象可能会是歪曲的、片面的或者错误的。
l 真实的需求。这些需求代表了顾客真正需要的东西。你甚至不用提出一些提示性的问题就可以明确需求。
l 补充的需求。此类需求作为真实需求的补充，成为整体框架的重要组成部分。例如，在没有危机质量与服务的前提下，客户必须节省成本。
l 有胜于无的需求。客户往往将此类需求视为额外的需求，所以其优先级比较低。不过，实现这种需求会另客户非常高兴。例如，针对全新会计系统进行的互动培训计划将会增加成本。但公司的确需要这样的计划以轻松快速的适应新系统。
l 秘密的需求。这种需求来源于私人原因。通常，采购官员和项目经理希望其商业头脑被公司认可以便提升其职业生涯。一些额外的功能和交付物可以帮助他们。尽管为项目买单的是公司，但做决定的是这些人。
你不能盲目地给客户提供任何东西，许多项目就其客户提出的需求和期限来说，就如同镜中花，水中月。如果你只是简单地把客户提出的所有东西罗列为需求，你很可能令客户抱憾而结束项目。为了发现客户需求，你需要从项目层面深入到业务策略的领域。理解了业务流程，你才会发现客户的真实需求。
管理客户需求意味着要做两件事情：查明客户心目中的产品形象；朝着项目成功的方向修正这种形象。简单来说，即找出客户没有明确的需求并向他们说明建造产品的代价。
第一步，建立沟通渠道和信任关系。
项目团队通常会在与客户建立顺畅的沟通渠道之前冒险进入需求收集、设计和建造阶段。一个有效的沟通渠道包括统一的术语和对协议和假设的共识。除非各方使用公认的协议，否则信息会被视为“杂音”去除。
使用双向的沟通渠道来确保你能清晰地理解客户期望、需求及假设。把你对需求的理解反馈给客户，这样可以较容易地达成共识。
然而，即使你理解其他各方提供的信息，你还需要承认其有效性。美国弗吉尼亚州阿灵顿市的世通公司解决方案部门高级经理布鲁斯·J·伯恩哈特说：“如果信任是双方关系的关键部分，那么信誉就是信任关系的日常表现。在每日与客户通过各种方式进行的沟通中，项目经理有机会获取或者失去信誉。一旦损害了信誉，客户不会信任以后的任何事情直到项目被取消。”
第二步，交流有意义的相关信息。
为了避免误解，你必须熟知客户的性格、想法、背景和他们使用的行话及术语。倾听顾客的艰难经历、批评、做人原则和闲谈。
开辟出正式和非正式的沟通渠道。在项目的任何阶段，对于以下事项都应达成共识：顾客的价值主张、整合销售策略和服务交付模式。
无论客户和供应商都应能够以自己的方式清楚描述项目的价值。要随着项目的进展及时更新呈现给客户的销售策略，必须反复确认其有效性以避免在项目完成前过时。
服务交付模式定义了客户和所有运营支持团队之间的接口形式。本质上，这个模式代表了客户与项目团队合作的经验，这包括沟通方式、状态报告、原型和单个功能的演示及批准、合同和工作意向。总之，服务交付模式表达了项目中的客户关系如何发展，这种关系通常会留下持久的印象。
为了避免误解和不实际的期望，你需要对客户进行有关项目流程、方法和实践等方面的培训。单页的流程图是一种很好的工具，它能展示每个流程的关键元素。变更管理记录可以避免项目范围蔓延并重排新需求的优先级。项目团队必须与客户交流备选方案，然后解释最好的解决方案。总之，将客户转变为合作伙伴。
以下是美国加州弗里蒙特市Accrue软件公司的案例。在2001年7月，总部位于美国纽约州罗彻斯特市的伊士曼柯达公司需要一套系统来迅速分析大量数据并识别客户的购买模式。原始信息来源于柯达公司分布在全球29个地点的互联网渠道。仔细评估之后，伊士曼柯达公司选择了Accrue公司的软件。
Accrue遵循了“培养客户”的原则，他们向柯达团队展示了如何使用软件将顾客行为分析提升到一个新的层次。Accrue团队启动项目的第一件事情是面向客户团队所有成员的产品培训，其目的是确保需求分析使用的是共同的术语。
第三步，建立一套评价成功的标准。
为了评价项目是否成功，你必须创建一套双方均认可的评价尺度。如果项目团队达到了期望值，客户就会满意。如果没有目标测量标准，也就无法严格地把握进度。
另一个案例，1999年，佐治亚州税务局需要一套处理商业税务票据和支票的新系统。旧系统的能力已经不足并且需要许多人轮班操作。从收到一张支票到存款进银行的平均时间在当时是两个星期左右。这份合同被授予了诺斯罗普·格鲁曼公司。
一个由佐治亚州税务局和诺斯罗普·格鲁曼公司组成的联合IT团队撰写了需求和系统定义文档。由于当时正处于税收旺季，时间压力迫使联合IT团队没有建立正式的验收标准。不幸的是，计划使用并接收这套系统的团队并没有被邀请参与最初的需求分析。结果不出意料，IT团队创建的最初需求与使用团队的期望之间存在较大差距。
用户感觉到被排除在需求讨论的范围之外，而且没有项目成功的验收标准，所以，他们很不情愿接收这套系统。双方的管理团队通过谈判、变更和培训等手段尽力促成一致意见，并完成了系统部署。
在系统投入运营之后，从收取支票到存款的时间缩短到几天甚至几小时。佐治亚州税务局用了短短三个月的时间即利用额外利息收入收回了系统开发的投资。虽然投资回报是衡量一个项目成功的有力佐证，但如果使项目干系人参与到绩效评价决策中的话，项目的交付可能会更加顺畅。
第四步，召开项目进展会议。
误会和误解会在项目进展会议上暴露出来。在会上有诸多事项需要完成：创建并维护项目状态文档；与客户和团队成员交流关键的交付物，包括进度、项目计划更新、未完成任务条目和对上级的状态报告；此外，还要将这些信息汇报给管理层。
这种会议不应该成为唯一的沟通方式，但它们会是与客户交流的合适方式。1990年代中期，位于华盛顿特区的美国第三大电信公司MCI曾致力于寻找将部分销售流程自动化的方法。MCI成立了两支团队分别代表客户（MCI商务市场部门）和供应商（MCI内部IT团队）。项目团队收集了需求后开始了开发工作。尽管两支团队经常沟通，但没有设立沟通事务和关注的正式会议。
常规的进展会议促进了团队沟通并提高效率。他们开发的新软件赋予了MCI销售团队在销售效率方面的明显优势。
每个项目都有风险。顾客认为，没有什么风险比与一支反应迟钝的团队合作更加危险的了。所有技术、组织和市场风险都会被轻易地忽略。
另外，与客户共享风险管理计划会使他们确信你掌控局势并对潜在问题有所准备。风险会随着项目生命周期发展而变化。在项目早期阶段，如果你展示了识别并减轻风险的能力，随着项目进展，高层管理团队会重视你的判断和建议，并且会做出一些“艰难的选择”以控制风险。
监督顾客满意度
世通公司的布鲁斯·伯恩哈特强调，与客户管理层建立及时顺畅的沟通渠道是必不可少的。与客户管理层建立一种积极的关系，以备将项目的挑战问题汇报给高层之需。
当管理层与客户在战略高度上维持着一种紧密关系时，你和你的团队就会理解客户的组织需求、全局规划和总体的战略方向。
作者简介：
Peter I. Dimov是美国弗吉尼亚州阿灵顿市InterImage公司软件开发部门经理。他拥有15年的IT从业经验，曾开发和管理过诸多软件系统，客户包括IBM、雷声公司、诺斯罗普·格鲁曼公司、埃克森－美孚、MCI和Qwest。
Petya S. Alexandrova是美国弗吉尼亚州费尔法克斯市Digital Enterprises公司的创始人兼总裁。该公司成立于1994年，业务范围涉及项目管理、咨询和软件服务。
为了留住客户，你必须信守承诺。不过，首先你必须保证所承诺完成的东西确实是顾客想要且需要的。
当你力图使客户满意时，请记住，一点小小的让步就可以维持顾客忠诚度并产生大量利润。《忠诚的价值：增长、利润与持久价值背后的力量》一书的作者弗雷德里克·莱希赫尔德认为：因不同的行业而异，顾客流失率降低5％，利润就会提高25－85％。
管理顾客期望并留住他们的业务对于项目成功和公司成长来说至关重要。总部位于美国康涅狄格州斯坦福德市的施乐公司在其顾客研究中发现，“非常满意”的顾客重新购买公司产品的可能性较一般顾客高18倍。如果你关注于如何使顾客满意，你将会确保你的行动产生许多令人愉悦的回报。
如果项目干系人没有精确的信息足以判断在指定的日期和预算内将会完成的内容，他们就必须依靠自己头脑中对于交付物的模糊印象了。一旦客户的心目中存在不现实的观点，那项目经理就被迫完成这不可能的任务了。相反，项目团队应该预先把所有的选择呈现给客户，这样他们可以做出可靠的决定并且提出清晰的需求。
根本原因
顾客的期望来源于过去的购买经历、建议、市场信息、竞争对手信息和你的承诺。有五种不同层次的客户需求：
l 明确的需求。顾客明示他们的需求或者工作说明书。这些需求来源于顾客基于其信念、理解和技术知识所形成的对解决方案的印象。不过，这种印象可能会是歪曲的、片面的或者错误的。
l 真实的需求。这些需求代表了顾客真正需要的东西。你甚至不用提出一些提示性的问题就可以明确需求。
l 补充的需求。此类需求作为真实需求的补充，成为整体框架的重要组成部分。例如，在没有危机质量与服务的前提下，客户必须节省成本。
l 有胜于无的需求。客户往往将此类需求视为额外的需求，所以其优先级比较低。不过，实现这种需求会另客户非常高兴。例如，针对全新会计系统进行的互动培训计划将会增加成本。但公司的确需要这样的计划以轻松快速的适应新系统。
l 秘密的需求。这种需求来源于私人原因。通常，采购官员和项目经理希望其商业头脑被公司认可以便提升其职业生涯。一些额外的功能和交付物可以帮助他们。尽管为项目买单的是公司，但做决定的是这些人。
你不能盲目地给客户提供任何东西，许多项目就其客户提出的需求和期限来说，就如同镜中花，水中月。如果你只是简单地把客户提出的所有东西罗列为需求，你很可能令客户抱憾而结束项目。为了发现客户需求，你需要从项目层面深入到业务策略的领域。理解了业务流程，你才会发现客户的真实需求。
管理客户需求意味着要做两件事情：查明客户心目中的产品形象；朝着项目成功的方向修正这种形象。简单来说，即找出客户没有明确的需求并向他们说明建造产品的代价。
第一步，建立沟通渠道和信任关系。
项目团队通常会在与客户建立顺畅的沟通渠道之前冒险进入需求收集、设计和建造阶段。一个有效的沟通渠道包括统一的术语和对协议和假设的共识。除非各方使用公认的协议，否则信息会被视为“杂音”去除。
使用双向的沟通渠道来确保你能清晰地理解客户期望、需求及假设。把你对需求的理解反馈给客户，这样可以较容易地达成共识。
然而，即使你理解其他各方提供的信息，你还需要承认其有效性。美国弗吉尼亚州阿灵顿市的世通公司解决方案部门高级经理布鲁斯·J·伯恩哈特说：“如果信任是双方关系的关键部分，那么信誉就是信任关系的日常表现。在每日与客户通过各种方式进行的沟通中，项目经理有机会获取或者失去信誉。一旦损害了信誉，客户不会信任以后的任何事情直到项目被取消。”
第二步，交流有意义的相关信息。
为了避免误解，你必须熟知客户的性格、想法、背景和他们使用的行话及术语。倾听顾客的艰难经历、批评、做人原则和闲谈。
开辟出正式和非正式的沟通渠道。在项目的任何阶段，对于以下事项都应达成共识：顾客的价值主张、整合销售策略和服务交付模式。
无论客户和供应商都应能够以自己的方式清楚描述项目的价值。要随着项目的进展及时更新呈现给客户的销售策略，必须反复确认其有效性以避免在项目完成前过时。
服务交付模式定义了客户和所有运营支持团队之间的接口形式。本质上，这个模式代表了客户与项目团队合作的经验，这包括沟通方式、状态报告、原型和单个功能的演示及批准、合同和工作意向。总之，服务交付模式表达了项目中的客户关系如何发展，这种关系通常会留下持久的印象。
为了避免误解和不实际的期望，你需要对客户进行有关项目流程、方法和实践等方面的培训。单页的流程图是一种很好的工具，它能展示每个流程的关键元素。变更管理记录可以避免项目范围蔓延并重排新需求的优先级。项目团队必须与客户交流备选方案，然后解释最好的解决方案。总之，将客户转变为合作伙伴。
以下是美国加州弗里蒙特市Accrue软件公司的案例。在2001年7月，总部位于美国纽约州罗彻斯特市的伊士曼柯达公司需要一套系统来迅速分析大量数据并识别客户的购买模式。原始信息来源于柯达公司分布在全球29个地点的互联网渠道。仔细评估之后，伊士曼柯达公司选择了Accrue公司的软件。
Accrue遵循了“培养客户”的原则，他们向柯达团队展示了如何使用软件将顾客行为分析提升到一个新的层次。Accrue团队启动项目的第一件事情是面向客户团队所有成员的产品培训，其目的是确保需求分析使用的是共同的术语。
第三步，建立一套评价成功的标准。
为了评价项目是否成功，你必须创建一套双方均认可的评价尺度。如果项目团队达到了期望值，客户就会满意。如果没有目标测量标准，也就无法严格地把握进度。
另一个案例，1999年，佐治亚州税务局需要一套处理商业税务票据和支票的新系统。旧系统的能力已经不足并且需要许多人轮班操作。从收到一张支票到存款进银行的平均时间在当时是两个星期左右。这份合同被授予了诺斯罗普·格鲁曼公司。
一个由佐治亚州税务局和诺斯罗普·格鲁曼公司组成的联合IT团队撰写了需求和系统定义文档。由于当时正处于税收旺季，时间压力迫使联合IT团队没有建立正式的验收标准。不幸的是，计划使用并接收这套系统的团队并没有被邀请参与最初的需求分析。结果不出意料，IT团队创建的最初需求与使用团队的期望之间存在较大差距。
用户感觉到被排除在需求讨论的范围之外，而且没有项目成功的验收标准，所以，他们很不情愿接收这套系统。双方的管理团队通过谈判、变更和培训等手段尽力促成一致意见，并完成了系统部署。
在系统投入运营之后，从收取支票到存款的时间缩短到几天甚至几小时。佐治亚州税务局用了短短三个月的时间即利用额外利息收入收回了系统开发的投资。虽然投资回报是衡量一个项目成功的有力佐证，但如果使项目干系人参与到绩效评价决策中的话，项目的交付可能会更加顺畅。
第四步，召开项目进展会议。
误会和误解会在项目进展会议上暴露出来。在会上有诸多事项需要完成：创建并维护项目状态文档；与客户和团队成员交流关键的交付物，包括进度、项目计划更新、未完成任务条目和对上级的状态报告；此外，还要将这些信息汇报给管理层。
这种会议不应该成为唯一的沟通方式，但它们会是与客户交流的合适方式。1990年代中期，位于华盛顿特区的美国第三大电信公司MCI曾致力于寻找将部分销售流程自动化的方法。MCI成立了两支团队分别代表客户（MCI商务市场部门）和供应商（MCI内部IT团队）。项目团队收集了需求后开始了开发工作。尽管两支团队经常沟通，但没有设立沟通事务和关注的正式会议。
常规的进展会议促进了团队沟通并提高效率。他们开发的新软件赋予了MCI销售团队在销售效率方面的明显优势。
每个项目都有风险。顾客认为，没有什么风险比与一支反应迟钝的团队合作更加危险的了。所有技术、组织和市场风险都会被轻易地忽略。
另外，与客户共享风险管理计划会使他们确信你掌控局势并对潜在问题有所准备。风险会随着项目生命周期发展而变化。在项目早期阶段，如果你展示了识别并减轻风险的能力，随着项目进展，高层管理团队会重视你的判断和建议，并且会做出一些“艰难的选择”以控制风险。
监督顾客满意度
世通公司的布鲁斯·伯恩哈特强调，与客户管理层建立及时顺畅的沟通渠道是必不可少的。与客户管理层建立一种积极的关系，以备将项目的挑战问题汇报给高层之需。
当管理层与客户在战略高度上维持着一种紧密关系时，你和你的团队就会理解客户的组织需求、全局规划和总体的战略方向。
作者简介：
Peter I. Dimov是美国弗吉尼亚州阿灵顿市InterImage公司软件开发部门经理。他拥有15年的IT从业经验，曾开发和管理过诸多软件系统，客户包括IBM、雷声公司、诺斯罗普·格鲁曼公司、埃克森－美孚、MCI和Qwest。
Petya S. Alexandrova是美国弗吉尼亚州费尔法克斯市Digital Enterprises公司的创始人兼总裁。该公司成立于1994年，业务范围涉及项目管理、咨询和软件服务。