客户领导所能够起到的作用
客户方与项目管理工作对接的客户领导对下决定不了用户的用户体验，出于避免大多数人的抱怨，他们往往会比其他用户对产品的期待更高，要求更严。他们所能起到的对项目管理工作正面的作用，最多只是在对公司其他部门的需求控制上起拍板作用，而很难对他自身的需求尤其是高层的需求进行控制，尽管他们与项目承建方“在一条船上”。
产品的架构决定了定制开发工作的进度及质量
有点技术架构概念的人就会非常明白。要给客户定制开发几十个业务流程，大部分都是配置工作的话，架构合理可以省略多少步骤，这些省略的步骤对项目管理工作来说就是时间、就是成本。如果产品架构本身的开放向不够，那么定制开发工作开发的功能就只能够与产品的架构层次捆绑了，哪怕项目团队想过自身的努力以提升新开发功能的健全性、友好性，往往是徒劳的，即使可以完成也是基本上相当于完全单独的开发，所消耗的时间及在有限的时间内所能保证的质量是有限的。
有些架构较好的产品，项目的源代码是完全在开发人员手中的，而实际上又不会导致产品平台源代码的泄露。开发人员手中的代码始终是项目开发功能所需的，这样给开发人员的工作展开亦带来了很大的便利。
如下图所示的是一种不错的架构：
当时上述架构产品有公司领导说，高中生都可以通过培训做他们的开发人员。笔者也用过这个产品平台，它所有的机遇表单页面的开发、流程的配置都是基于配置的，包括所有的建表、数据字典以及数据字典的应用，各种字段的相互关联。该产品平台可以很好的进行开发功能的集成、第三方报表的集成、权限表单显示级的管理等。可以说在传统的B/S架构的业务系统中是不错的web端产品架构。
产品一开始给用户的体验感不够好，项目经理的工作就会越被动，在客户面前的话语权就越低
如果产品给用户的体验感不好，首先感到焦虑的是对接的客户领导，他们对于公司内部说一些不好的话都是敏感的，尤其是当这些话牵扯的自己的工作时。这个时候项目管理工作的天平就不得不向客户方倾斜，我们需要通过更加严苛的开发功能质量保证、用户体验感良好的功能交互设计、快速的运维反应、卑躬屈膝的做事态度来逐渐消弭客户所产生的不满，企图在验收之前扳回局面，让项目得以顺利的验收。项目得以完成并顺利验收是项目经理与生俱来的使命。这会是管理工作十分地被动，本来可以完全推掉的需求，不得不再实际开发中加以一定的考虑，尤其是对于主要讨好对象的客户对接领导。这个时候对接的客户领导会针对下面的意见提出一些对产品改进的一些想法，尽管有些想法是不可行的，但当项目经理直接告诉他们时，他们可能会趁机发一肚子牢骚，所以稳妥的办法往往是先跟客户保证哪些是可以改进的，哪些是需要跟研发、开发沟通下的，等你把大部分的改进完成后放到客户面前再说哪些改进不可行被搁置了，这时候有所成果客户显然很容易接受的。客户的有些想法虽然是不可行的，但当他们刻意提第二遍时就不得不变相的去做了，这个时候最好将对方的技术人员也拉过来，一起讨论如何变相实现，这样做才能保证是有所成效的。当客户对项目经理所说的一些话“这种功能不可行”的话半信半疑时，不得不说在客户面前的话语权有多低。有的客户虽然不是技术人员出身，但却坚信“不要在我面前说不行，做信息化的没有什么功能是不可行的，不行的话就是你们技术水平不行”。结合之前在客户面前的表现，恍然大悟了一点：很多功能从具体的用户嘴中说出对你来说有很大挑战，或者压根不可行的，都不能直接的拒绝，而说这需要跟总办（对接客户）讨论一下；当跟你对接的客户在身边时，你要很自信的说这种功能从技术上实现没问题的，尤其是跟对接客户一起跟其他部门特别是跟高层在一起的时候，千万不要说他们所提出的功能不可行、产品不能实现什么，要说“好，没问题！好，可以实现。”，当所提出的需求超合同范围时也得先说“这种问题从功能上实现没有任务问题，只是需要结合合同综合考量一下！”。
总之意思就是说在其他部门、高层面前一定要给足
对接客户面子，要清楚很多部门用户可能只是头脑风暴似的说说自己的观点，时间久了可能他们自己就忘了；但是其他部门领导的意见最好认真考虑一下，你要多为自己对接客户拉一些支持他的盟友最起码不要因此事而“反对”他，尤其是这些说得上话的盟友。对接客户的工作好做，项目管理的压力会少很多，并且会相对顺利。
举个例子来说，在某证券公司的一个OA项目，项目进行到一定阶段，公司负责此类工作的高层想要了解一下项目进度，管你准备没准备好，高层说今天上午10点就是上午10点。当对接客户带我们过去汇报，高层领导自己体验了下业务系统，针对存在的问题发表了自己的指示，并描述了他当时规划的初衷。最后的时候问了句：“你们的产品的HD版本怎么样，我准备给公司其他高层没人配备一部iPad，方便移动办公。”
“HD？”我跟我的小伙伴都惊呆了，公司只退出了安卓版本、iOS版本，没有推过HD版本啊。“就是针对iPad上使用的高清版。”办公室一位机要岗的人员提示道。本来想说我们没有此版本的时候，看到对接客户焦虑的使了个脸色，心想既然都是ios平台，产品应该也可以在iPad上使用，便说：“哦，HD版本的正在测试，在此次上线前可以推出。”高层似乎也看出了端倪：“那就好，我之前跟其他高层说过让他们用iPad使用OA进行办公，到时候可别不能用！”汇报完，在下楼的路上，我就赶紧打电话给研发，说明了情况，研发IOS版本在iPad肯定是可以跑起来的，只是说没在iPad用过，不知道效果，做HD版的可以，不过需要排计划，最快需要两个月左右。针对公司如此的紧张的研发情况，作为项目经理的我只能自己多动手解决项目情况。自费买了部iPad
Air2设备进行测试效果。后面在设备上进行了一定测试，针对IOS版本运行效果存在的问题与客户讨论后由项目总监跟公司研发进行讨论该进，在上线前也算是推出了HD版本。很多时候就是这样，很清楚项目及产品存在问题的是在一线的项目管理工作者么，这种问题哪怕在最初被反馈给公司高层也是有意或者无意的无视，更倾向于相信研发经理对项目管理工作的职责，而迟迟未认识到问题的本质。这在我之前说过，公司高层仍在拿十年前的那一套来做现在的项目：就是产品一开始都是不成熟的，甚至是可以不健全的，只有在跟客户开发的过程中不断改进；这样来说产品对用户体验度差、产品被客户指不成熟，便不是主要问题，那么主要问题就出在项目管理工作上了。后来我听到客户对我公司老板说过几句关于我的话：”小袁做事情很认真、负责，很多时候他的这种态度都让我想哭，大家都是人，我觉得问题是小袁在你们公司资历太浅，根本无法调动你们的大后方。“
这是我最佩服这位客户的地方，认识问题很到位，在后面对项目的阶段性指示中也很到位，对我也很关照。顺便介绍一下这个项目背景：这个项目最初是由其他部门的一位项目经理接手，需求分析了两周左右后，什么事都没做的就交给了下一位项目经理；下一位项目经理到时开始认真做，该项目经理刚来公司没多久，之前只是专做项目管理的工作，对业务并不是很熟悉。我在最初进入该项目时是以需求分析角色的，呆了一周后
这个项目经理因为家庭原因，不能长期出差，提出回到上海。本来公司是要安排给另外一位经验丰富的项目实施人员的，但被他拒绝，当时他也劝我不要接。而因为我当初太年轻、高估了自己而接了。好的一方面是，摸爬滚打负责项目管理、负责需求、负责架构部署工作等工作而迅速的成长了起来，最终可以独当一面。坏的一方面是，我以后的职业生涯中怕是再也接不到比这更具挑战性的项目了，正如项目总监所说，你做完了这个项目，后面就没有能够难倒你的项目了。最终项目在公司的惨淡经营中上线，完成了一阶段的目标。也就是在恶劣的情况下，在跟客户各方面人员、跟公司各方面人员沟通的过程中，学会抓住了很多沟通的关键，提升了在公司的地位，让同事不再觉得我是个鲜肉，同时也反思了很多造成各种问题的原因并并总结出一些个人的心得。这就是所谓的经验吧。项目干系人？不就是这些人么，只是在你由于产品半拉子、团队人员结构不合理等导致项目管理无法顺利开展而造成了各种问题时，你的话语权就低了。哪怕你认识到了问题的关键，而你却不能够促进研发承认自己的产品不好而不断改进，却不能阻止商务因为公司持续运营继续接项目而分散你所能协调的本就不足的开发人员；却不能再跟客户公司高层汇报时说：”我们目前不支持HD版”。在任何实际的情况面前，PMPOK中关于关系人管理的知识都只能作为实际情况前的指导思想罢了