项目管理：如何平衡客户和公司利益

显示全部楼层 · 2014-7-14 11:41:47

作者：廖文忠发表：2004.04.02 来源：中国计算机用户

　　案例
　　在某公司的项目管理课堂上，小李、小王等人正在七嘴八舌地议论纷纷。原来，大家正在讨论小王的公司最近碰到的两个颇为有趣的项目。
　　据小王介绍，这两个项目分别由两个项目经理来担任。其中，项目经理A属于“谦虚”型，对于客户提出的问题，无论大小都给予解决，客户对此非常满意。然而，项目进度却拖得较长。而且，客户总想把所有的问题都改完再说，项目已经一再延期。
　　相比之下，项目经理B显得稍有些“盛气凌人”，对于客户提出的问题，大多都不予理睬，客户对此不是很满意。不过，该项目的进度控制得较好，基本能按期完成项目。
　　话刚一说完，小李就抢着说：“A比较像我。一般，在和我的一些战略客户打交道的时候，我基本是有求必应，与客户的关系处得如鱼得水。这样做肯定不会错。就像前天，我连合同都写错了，找到客户，人家二话没说就同意改了。你说，如果是B的话，可能吗？”
　　小王对此不以为然，“对项目经理来说，成本、质量和时间是最为重要的三要素。与客户的关系当然很重要，但也要全盘考虑项目的各要素。对于用户的要求，应该在有限的范围内给以解决，但不可以做出太大的牺牲。一味的迁就用户将会使整个项目失败。”
　　小林接着小王的话说：“当前，国内的项目，一般情况下是由销售出面签单，再由项目经理接手后续的工作，因此客户关系多在事前已经搞定。发生新的情况后，可以由公司的公关部出面与用户进行协调，项目经理可以在此过程中坚持一下原则，与公司的公关部，一个红脸，一个白脸，唱一出好戏。”
　　小赵反驳道：“不管怎样，客户才是第一位的。客户可以给你带来收入，也可以给你带来更多的客户和工作。有什么道理不多配合一下他们呢。说实话，我对B的做法蛮欣赏的，可惜行不通。因为客户是上帝，如果照B的做法，后果会造成作一次项目丢掉一个客户，太不划算了。”
　　上面案例中提到的问题，想必不少项目经理都经历过了。实际上，这个课堂中提出的问题，清晰地刻画了当前国内不少IT项目经理的尴尬境地。
　　迁就，or拒绝？
　　如果按B的做法，对客户的要求一概不理，自顾自地按照最初的设计和计划闭门开发，很可能会由于没有用户的参与，使得开发出来的产品与用户的需求相处甚远，导致验收通不过，收不回尾款而使公司利益受损。
　　对于客户来说，达不到需求的满足而浪费了投资，客户的利益亦受损。事实上，客户不满意，则项目就不算成功，项目经理的成绩就不算好，项目组成员的辛勤劳动最后就只能落得个“没有功劳，只有苦劳”的份。
　　如果按A的做法，完全顺着客户的意见走，客户满意度就一定会高吗？其实也不一定。由于需求变更，会带来工作量的大量增加，甚至可能会出现大量的无效劳动，既拖延了进度，也打击了项目组的士气。进一步说，频繁变动的需求也会导致质量管理困难大增，测试标准和测试计划需要随时跟着调整。此外，项目工作往往是需要成员之间的紧密配合才能完成。频繁的变更要求,会导致成员之间的协调工作变得困难，给产品质量留下许多隐患。
　　以上所有这些问题会造成项目风险极大地提高，项目可能会让成员看不到未来在哪里。进度一拖再拖，设计一改再改，“臭虫”越来越多，士气越来越疲，公司越来越不满意，用户开始越来越急。到最后，项目经理会发现这个项目已经成为了一个“不可能完成的任务”。
　　既不能一概拒绝客户的变更要求，也不能一味地迁就客户，其实，这里面可以采取具体的措施。
　　那么，如何才能够把握拒绝和迁就的“度”呢？这些措施如何才能够发挥作用呢？这需要项目经理首先明确自己的角色和职责。明确了这个，才会知道项目经理需要怎么去做才可以实现角色的要求。
　　掌握“平衡”要先认清“角色”
　　在客户面前，项目经理代表公司。因此，需要项目经理时刻紧记，维护公司的良好、专业的形象，为公司争取最大的利益。
　　与客户建立并维持良好的合作关系，有利于在客户心目中树立公司的形象。对于客户的变更要求，要让客户明确知道变更的后果，并进行充分地沟通，获得客户对变更带来的时间和费用的可能增加表示认同，以避免公司的利润受损。
　　在项目中，项目经理要保证客户的需求得到切实的满足，以获得高的客户满意度。为此，项目经理要在开始确定项目范围的时候，与客户密切合作，评估范围变更的频度和程度，以建立有效的变更管理机制，允许客户的变更要求得到必要的满足。同时，通过合理的变更，来不断清晰客户的真实需求，明确产品的最终功能和性能要求，使产品最终达到满足客户切实需求的目的。
　　在项目组成员面前，项目经理是一个管理者。项目经理要预先进行项目筹划，要先“纸上谈兵”。同时，项目经理还是一个领导者，要领导项目组成员克服困难，避免项目变更带来的无效劳动、进度延迟等后果打击成员的士气，要保证成员始终保持良好的心态和积极的热情与客户协作，完成变更的要求。
　　在公司里，项目经理是作为项目与公司各相关部门沟通的界面。项目经理要代表项目与其他相关部门就项目变更带来的相应变化进行沟通、协商，以获得来自其他部门的必要的协作。
　　在上级领导面前，项目经理既要作为项目结果的最终责任人，对公司负责。还要作为项目组的代表，为项目组争取公司领导的支持。对于变更带来的工作量的增加、工作强度的提高，应该有相应的激励措施以巩固项目组成员的劳动积极性。
　　项目经理在明白了自己的位置和责任后，就会明白上文讲到的案例，表面上看起来是一个对客户的变更要求“拒绝还是迁就”的问题，实质是项目经理对自己的角色和职责不清楚，以致在实际的项目工作中，按照自己的经验和性格，采取了“一味地迁就或者一概拒绝”这样简单的处理办法。
　　如果我们不先弄清楚项目经理的角色和职责，仅仅简单照搬书上介绍的变更管理措施，那么在实际执行时，“谦虚型”的A依然会同意许多的客户变更要求。同时发现那些变更管理措施除了给自己增加工作量外，对于减少客户的变更要求丝毫起不了作用；而“盛气凌人”的B将发现，这些变更管理措施是一个阻碍客户提出变更要求的有力工具，通过繁琐的变更申请程序、复杂的变更评估流程，让客户知难而退。这样的后果，只能是客户更加不满意。
　　如何平衡客户、公司、项目组和领导之间的利益，保证项目组成功提供项目产品并使客户满意，是项目经理最大的挑战，这个挑战远大于来自产品技术本身的难度。
　　客户的变更要求是项目与生俱来的特性，项目经理要积极面对挑战，把头从纷繁复杂的技术工作中抬起来，环顾四周，认清自己所处的位置，明确自己应负的职责，努力促使项目成功达到目标，以满足客户需求。
　　毕竟，客户的满意是项目是否成功的最终标准。

千问 · 2014-7-14 11:41:47

项目管理数据分析项目中的风险管理
作者：吴达荣,联信永益科技有限公司发表：2004.06.10 来源：中国计算机报

随着我国各部门、各行业信息化建设的推进，面向操作层和管理层的各种运营支撑系统、管理信息系统正逐步建成和走向完善。在积累了较丰富的信息化经验和数据后，面向决策层的各种数据分析系统越来越受到重视。
软件项目都存在着这样那样的风险，这是由软件项目的创造性本质决定的。而数据分析项目的建设不仅需要克服一般软件项目的常见风险，而且数据分析项目由于以下两个原因，相对一般面向操作层、管理层的信息系统而言具有更大的风险：
1. 数据分析系统通常是面向决策层为主，受核心领导的个人习惯、工作作风、知识背景影响较大，在系统范围和系统性能方面存在着很多不确定性因素。
2. 数据分析系统，特别是各种数据挖掘系统，需要依靠数学模型。而对数据模型的应用需要系统分析，设计人员应具有较好的数学背景知识，同时对所分析的行业业务非常了解。而这些往往又是以数据仓库为基础，对计算机软硬件技术要求很高。
在本文中，作者将根据数据分析项目的特性，结合自身的工作实践，重点讨论数据分析项目的风险识别、风险分析和风险应对。
风险识别
由于数据分析项目的需求在开始常常是模糊的，而数据分析技术又是非常复杂的，因此数据分析项目都具有较大风险，国内国际许多决策分析系统、客户关系管理系统的失败都证明了这一点。这就需要组织层和项目经理在实施数据分析项目时更加注重风险管理。在项目的启动，也就是策划阶段注重进行项目风险分析，做好风险管理计划。采用相关的分析工具和分析手段，根据项目的本身特点、范围估计、技术条件、历史数据做好风险值的分析。在项目实施过程中，不断地、持续地监控风险的变化，努力规避、消除风险。
在具体的风险识别过程中，我们要重点注意以下风险：
1. 需求不确定性的风险；2. 决策层沟通障碍的风险；3. 分析技术路线的风险；4. 其他风险。
风险分析
前述数据分析项目的三大风险对项目的影响都是非常大的，如果按定性的风险分析方法，影响都是“高”级。如果按第一项计算影响性，分值都在0.8以上。
需求不确定性风险还会导致项目进度、成本、质量、资源、合同等相关风险，使项目处于失控状态。在实际工作中，我们多次遇到项目都快要收尾了，依然出现客户领导对系统提出“在客户分析方面需要拔高”、“在经营指标分析要加强体现X部长讲话精神”之类模糊不清的需求。
决策层沟通障碍风险容易使最终决策领导对项目期望保留在项目竞标阶段，理想而抽象，项目组不能真正理解领导的需求，甚至无所适从，大量工作“跑题”浪费，使时间和成本的投入成倍增长。
技术路线风险可以直接导致项目失败。项目的目标、范围超过了项目组所选技术。所选产品号称拥有而实际并不成功的分析模型，项目组自身对产品并不熟悉，无疑会使项目处于毁灭性的风险中。像某国家级银行采用SAS和Cognos实现的全国性信贷分析系统几乎无法使用就是典型案例。
风险规避
风险分析活动分析的目的在于建立处理风险的策略。一个有效的策略最好能规避风险。而风险规避的最好方式是把风险控制在项目启动阶段，把项目损失减小到最小程度。根据本人长期负责数据分析的项目经验，以上三大数据分析项目风险可以采用以下措施规避或减小：
1. 项目经理同客户最高决策层拥有畅通的沟通渠道；
2. 项目开发模型采用迭代模型；
3. 审慎运用尚处于研究阶段的分析技术与模型；
4. 层次较高、结构合理的项目组织结构；
5. 多参考专家意见。
由于数据分析项目中数据建模、数据重组、样本设置等对技术要求比较高，而聚类分析、神经网络、决策树、数理统计、时间序列分析等又是开发性的计算机或数学问题。所以数据分析的结论、综合解释、评价数据、知识探索、模型调优等，还是要依赖行业专家。
一个项目组的技术力量毕竟有限，所以数据分析项目的开发一定要多进行专家评审，多参考专家意见。并对专家意见进行汇总，及时地通知客户及其它干系人，采用“光环效应”影响客户，增强客户对项目方案、项目技术的认可程度并保证项目的成功。

千问 · 2014-7-14 11:41:47

新项目管理——改变种群习性的努力
作者：中国计算机用户发表：2004.06.16 来源：中国计算机用户

从关注“工程”转向了实施工程的“组织”，这是现代项目管理的灵魂所在。项目管理不再仅仅是工具，而是关于组织、组织的成熟程度、组织能力、组织智商的学问和技术。
说“21世纪将是项目管理的时代”这番话，是基于古典项目管理方法与IT的结盟所带来的重大变革。计算机和互联网在技术手段上为古典项目管理方法的解决之道，提供了无数“好看又好吃”的锐利武器。
然而，冷静下来一想也并非一点问题没有：到底是什么，使得“项目管理”这个其实是“工匠的话题”，足登大雅之堂了呢？
计算不再是瓶颈
一些组合高手眼里，兼并、重组、整合、风险投资，都可以摆在“项目”的显微镜下。
现代项目思想兴盛的一个主要原因，恐怕多少是因为策划一个项目的成本在计算机大兴其道之后大幅降低。像1960年代的载人宇宙飞船项目，以及“曼哈顿计划”，大量消耗在巨量方程组求解和迭代中的资金，足以使“项目管理”成为令人敬畏的行当。
当时，项目管理往往对应着水坝工程、核电站项目、高速公路项目和17轧棍连轧机大修项目等一系列耗资巨大、费用昂贵、周期漫长的“活动和事务”。在现代项目管理中，谋划一个项目的主要障碍，已经不是计算，而是想象力。
组织的复杂性
观察项目管理复兴的恰当背景是信息技术。信息技术对项目管理的影响不仅仅在技术层面，更在组织结构层面。对于新型组织而言，项目的“工序安排和资源配置”，仅仅是项目管理的表面现象，有价值的是项目团队带来的横向整合能力。这种能力是“项目管理内在的特质”。团队能够做到横向的联合作战与纵向的沟通协作。项目管理可以有效避免在企业中产生的思路不清与衔接困难。
从这个意义上说，项目管理如此流行的原因可以概括为：项目管理是面向成果的（关注任务的完成）；项目管理是基于团队工作的；项目管理借助内部资源提供跨职能部门的解决方案；项目管理通过借助外部资源以有效降低成本；项目管理是柔性的（可变化的）。难怪《财富》预测：项目经理将成为21世纪年轻人的首选职业。
软件蜕化为项目　
自从1969年“软件危机”成为一个学术术语以来，克服软件危机的努力一直在“工程项目管理”的认识框架下进行，比如结构化软件方法，原型化软件方法和面向对象的软件工程方法。工程方法的最大特征就是，先有设计，然后有作品。
然而，软件工程管理和其它工程管理相比还是有其特殊性，比如，软件是知识产品，进度和质量都难以度量，生产效率也难以保证；软件系统复杂程度也是超乎想象的。虽然如此，软件项目管理的工程特征并没有改变，软件工程的“分析-综合”架构并没有改变。
在这种情况下，“软件工程”这个听上去没毛病的术语，实际上潜藏着极大的危险：将软件问题仅仅当作“工程项目”，就忽视了“软件”这一智力活动的最丰富、最多彩的一面。“软件”成为“项目”，可能已经丧失了灵魂。
关注软件组织的能力
应当说，美国卡耐基－梅隆大学软件工程研究院1984年提出的“软件能力成熟度模型CMM”，把注意力引向了正确的方向，这是一个全新的视角。工程问题很容易被简化为工具是否锐利的问题，简化为一个根据目标演绎的过程。工程失败也可以从项目管理上寻找原因。但组织的成熟水平，的确是软件开发的核心问题。
CMM首先不是单纯地考察项目，而是考察组织，以及组织的演进。CMM强调的是组织的能力，而不是项目管理过程中一些更多地以规则、方法面目出现的东西。
CMM的探索，把软件项目关注的焦点，从工程本身转向了实施工程的组织，这是现代项目管理的灵魂所在。项目管理不再仅仅是工具，而是关于组织、关于组织的成熟程度、关于组织的能力、关于组织的智商的学问和技术。
组织行为的改善，可以视为种群习性的迁移，其意义远远大于一次次孤立的猎食行动（项目）。

千问 · 2014-7-14 11:41:47

理论是一套一套的
理论与实际脱节

千问 · 2014-7-14 11:41:47

最初由 w39 发布
[B]理论是一套一套的
理论与实际脱节 [/B]
理论是用来指导实际，实际是用来完善理论

千问 · 2014-7-14 11:41:47

是一个平衡的过程，没有一个项目经理什么需求都答应，或者什么需求都屏蔽，那是SB
很难总结规律性的东西，大多是根据具体情况决定
需要平衡几个方面：
1、需求的重要程度
2、客户放弃的可能性
3、如不满足，对项目质量的影响
4、成本
5、时间风险

千问 · 2014-7-14 11:41:47

理论这玩艺，入门的时候看看就行了！
要不成名了，讲讲也不错！
呵呵！

千问 · 2014-7-14 11:41:47

俺都还没到讲讲的程度，只好苦苦在其中挣扎了。

千问 · 2014-7-14 11:41:47

这老男人讲得挺有道理。
不错，实际过程我就是这样，该与客户理论的时候就得红脸粗脖子，总不能什么都顺着客户来。这不是在卖硬件，一个问题电话，联想的人立马屁颠屁颠地赶到，呵呵。
基本上很多软件公司都是以自己的产品为主导，尽量要求客户往你的软件靠笼。能不能做到这一点那就是你的本事了。

千问 · 2014-7-14 11:41:47

平衡客户与公司之间的利益是销售人员和高层管理人员的事情，项目经理在涉及这方面问题的时候需要与这些人员有密切的配合，以排除一些团体内部的障碍，为项目实施铺路。项目经理应该做的是摆平个人对项目的要求以及项目对个人的要求。