You are on page 1of 756

项目管理实践案例

(2008 版)
版权
本书《项目管理实践案例》是项目管理者联盟《案例》栏目中的案例分析。本书

中的案例及案例分析为项目管理者联盟网站版权所有。编辑者 Youran Luo( 2004

年 3 月 27 日通过美国项目管理协会 PMP 资格认证)在 7 年的 IT 系统集成项目

管理领域的经历了各种项目实践,也碰到了项目管理中的各种问题,很想将遇到

的问题呈现给进入项目管理领域的 PM。而项目管理者联盟《案例》栏目作为项

目经理排忧解难的互动平台,众多项目管理高手对各位 PM 实际项目中碰到的问

题提出最佳解决方案。本书谨将项目管理者联盟《案例》栏目中的案例进行了整

理,为广大 PM 在项目管理实践中提供一点借鉴和参考。特别重要的是,本书不

是对项目管理知识的论述,而是基于 PMI 的项目管理理念以实际的项目案例为

刚刚参加项目管理工作和已经是项目管理专家的 PM 提供实践参考,希望能为大

家打开一扇实践的窗口。

世界上没有一个项目是成功的!
No project is successful in the world!

版权所有,侵权必究!

第 1 页 共 756 页
目录

目 录
版权 ..................................................................................................................................................1
目 录 ................................................................................................................................................2
第1章 综合管理...................................................................................................................6
1.1 *有多少问题要靠流程解决?.................................................................................6
1.2 得罪了监理,如何完成项目验收? ..................................................................... 11
1.3 *技术出身如何做好项目经理? ...........................................................................15
1.4 如何面对这样的软件开发项目? .........................................................................22
1.5 供应链成本削减项目走入困境.............................................................................26
1.6 项目经理管理不力,技术负责人该怎么办 .........................................................32
1.7 三只老鼠折射企业的绩效管理问题 .....................................................................38
1.8 这样的项目如何进行管理?.................................................................................48
1.9 项目经理对技术是外行,如何掌控? ...................................................................56
1.10 半路接手项目,遇到的问题.................................................................................74
1.11 一个系统集成项目的烦恼...................................................................................101
1.12 我的项目研发为什么失败? .................................................................................109
1.13 如何管理和下派工作?.......................................................................................120
1.14 如何估算大型项目的工作量?...........................................................................126
1.15 项目经理应该为这些问题负责吗? ...................................................................131
1.16 如何取得团队的信任和支持!...........................................................................145
1.17 如何调动开发人员主观能动性? .......................................................................150
1.18 竞聘公司项目经理的问题...................................................................................155
1.19 无实权,如何有效进行控制?...........................................................................170
1.20 如何对项目经理进行绩效考核? .......................................................................173
1.21 如何制定切实可行的项目计划? .......................................................................179
1.22 亲身经历的一个失败的通信集成项目- 请大家给与分析................................191
1.23 项目为什么会失败? .............................................................................................202
1.24 项目组内应力的可怕破坏力...............................................................................208
1.25 如何更高效地开展、控制项目? .......................................................................214
1.26 分包项目现场管理的困惑...................................................................................221
1.27 项目经理A的苦恼................................................................................................225
1.28 项目经理的窘境...................................................................................................236
1.29 系统集成企业的危机...........................................................................................247
1.30 如何实施电子政务项目.......................................................................................255
第2章 计划执行...............................................................................................................260
2.1 *如何进行项目管理才具有执行力? .................................................................260
2.2 *项目管理与进度计划管理.................................................................................266
2.3 *进度控制中“人”的问题该怎么解决? .............................................................270
2.4 *我的软件项目应该如何启动? .........................................................................275
2.5 *如何控制好客户的变更需求.............................................................................277
第3章 范围管理...............................................................................................................282

第 2 页 共 756 页
目录

3.1 *客户需求不清楚引来的麻烦.............................................................................282
3.2 *这个软件项目的问题在哪.................................................................................285
3.3 *承包单位没有按照实际需求开发软件 .............................................................289
3.4 *软件开发项目范围、成本管理问题分析 .........................................................295
3.5 *如何走出企业信息系统建设项目范围管理的困境? .....................................300
3.6 如何控制项目的范围?.......................................................................................307
第4章 沟通管理...............................................................................................................313
4.1 项目沟通管理案例分析.......................................................................................313
4.2 新上任项目经理遇到的难题...............................................................................325
4.3 *项目沟通管理与会议管理问题 .........................................................................343
4.4 *项目中多种沟通不良的情况如何解决 .............................................................347
4.5 中途接手项目的人员沟通问题...........................................................................353
4.6 如何推倒项目组内的“部门墙”? .......................................................................360
4.7 项目中多种沟通不良的情况如何解决 ...............................................................365
4.8 如何和刁钻的客户进行沟通?...........................................................................373
4.9 如何协调各部门让其更好的服务于项目组 .......................................................375
4.10 如何做好“拍脑袋”项目的需求分析 ...................................................................377
4.11 老板不信任怎么办?...........................................................................................381
4.12 遇到逃避责任问题该如何处理...........................................................................387
4.13 如何处理授权和监督?.......................................................................................395
4.14 如何统一不同部门对问题的认识? ...................................................................401
4.15 如何协调这样的关系?.......................................................................................414
4.16 好团队突然空降一上司,如何相处? ...............................................................427
4.17 项目经理感觉疲于奔命!请赐教 .......................................................................443
4.18 项目进行中出现无法解决问题如何进行 ...........................................................448
4.19 项目管理以外的困惑...........................................................................................454
4.20 如何与上司沟通?...............................................................................................457
4.21 该如何与客户沟通?...........................................................................................462
第5章 进度管理...............................................................................................................468
5.1 客户为什么迟迟不肯验收?...............................................................................468
5.2 *客户要求压缩进度,项目经理怎么办? .........................................................469
5.3 客户需求变更导致延期怎么办? .......................................................................474
5.4 如何推进项目的验收工作...................................................................................477
5.5 项目组经常拖延进度的问题...............................................................................482
5.6 在甲方处开发,如何控制进度...........................................................................486
5.7 软件项目延期,怎么办?...................................................................................488
5.8 不能保证按时完成?...........................................................................................498
第6章 控制管理...............................................................................................................504
6.1 *面对客户的需求变更,接受还是拒绝? .........................................................504
6.2 如何控制好客户的变更需求...............................................................................512
第7章 成本与质量...........................................................................................................518
7.1 项目内部成本控制问题.......................................................................................518

第 3 页 共 756 页
目录

7.2 *赔钱的项目与企业的业绩.................................................................................522
7.3 项目人员成本超支问题.......................................................................................527
7.4 项目内部成本控制问题.......................................................................................531
7.5 项目工作量估计的困惑.......................................................................................537
7.6 如何使双方的项目团队协同工作 .......................................................................547
第8章 团队管理...............................................................................................................553
8.1 *如何组织运用项目的人力资源 .........................................................................553
8.2 *团队中有大量合作公司人员如何管理 .............................................................558
8.3 *如何控制IT项目中的人员流动问题? .............................................................561
8.4 *对项目成员能力不了解,如何进行工作任命和任务分配? ...........................567
8.5 *在“各自为战”的公司,我该如何展开工作? .................................................571
8.6 *项目团队如何拥有高的协调性 .........................................................................575
8.7 进度控制中“人”的问题该怎么解决? ...............................................................581
8.8 项目中“额外”的事 ...............................................................................................585
8.9 无技术背景的PM如何凝聚团队力量? .............................................................589
8.10 项目经理真的很轻松吗?...................................................................................592
8.11 如何分配项目奖金...............................................................................................596
8.12 团队中有大量合作公司人员如何管理 ...............................................................602
8.13 特殊的项目组成员如何管理?...........................................................................607
8.14 怎样建立虚拟团队?...........................................................................................616
8.15 当团队成员都迷上了网络...................................................................................621
8.16 个人习惯导致团队工作的困难...........................................................................629
8.17 被踢来踢去的皮球,他该咋办? .........................................................................637
第9章 人力资源管理.......................................................................................................646
9.1 *三只老鼠的“偷油”项目失败折射出的企业绩效管理问题..............................646
9.2 矩阵项目组织中的人力问题...............................................................................650
第 10 章 风险管理...............................................................................................................658
10.1 *谁是这起房地产事故的主要责任人 .................................................................658
10.2 *项目管理不力,技术负责人如何开展工作 .....................................................660
10.3 *如何有效规避工程项目投标风险? .................................................................666
10.4 派克电信公司项目风险管理案例分析 ...............................................................672
10.5 项目经理应该负什么责任? .................................................................................674
10.6 关于工程项目的投标风险问题...........................................................................680
10.7 合作开发项目陷入困境.......................................................................................686
10.8 版本控制的难题...................................................................................................693
10.9 如何权衡不同的方案...........................................................................................696
第 11 章 采购管理...............................................................................................................700
11.1 *供应链成本削减项目陷入僵局 .........................................................................700
第 12 章 多项目管理...........................................................................................................706
12.1 项目执行过程中强矩阵管理问题 .......................................................................706
第 13 章 项目经理核心能力...............................................................................................710
13.1 *项目经理应该为这些问题负责吗? .................................................................710

第 4 页 共 756 页
目录

13.2 *公司拖欠项目提成问题.....................................................................................717
13.3 *项目经理对技术是外行,如何掌控? ...............................................................721
13.4 *我一个朋友的项目困惑.....................................................................................728
13.5 被认为在偷懒的项目经理...................................................................................740
第 14 章 项目管理组织.......................................................................................................751
14.1 *项目管理部在公司的定位.................................................................................751

第 5 页 共 756 页
第 1 章 综合管理

第1章 综合管理

1.1 *有多少问题要靠流程解决?

有多少问题要靠流程解决?

[姓 名] 相乡 [单 位] 夏新电子 [邮 件] xiangx_nj@amoi.com.cn
[所属行业] 通信工程 [所属主题] 项目综合管理 [发布时间] 2007-7-9

【案例正文】
事情的起因是一个软件负责人和一个项目经理对于一个手机说明书文档的评审问题产生了
意见上的分歧,分歧是说明书是否要有某种格式才开始评审,软件负责人问我,流程上是不
是有规定,我说,这样的事情,没有必要从流程上定义,用文档开发工程师提交的那份文档
评审就可以了,公司已经出过这么多的产品,该提交什么样的文档,工程师一开始肯定就提
交什么格式了。他们的分歧出现后,我打电话问了一句文档开发工程师确认了一下,跟了一
下软件负责人的邮件,问题就解决了。不过后来软件负责人认为是因为我的出面,项目经理
才没有异议,所以类似的事情还是要写到流程中。于是我和他讲到沟通的重要,讲到在想办
法解决问题之前,要先把事情搞清楚,然后看看有什么好的解决办法,类似的多找一个人问
一句就解决的简单问题,就不要再依赖流程了。但是,他一直不同意我的观点,坚决拿法律
作类比,认为应该是法治而不是人治,认为只要发生分歧的事情,就写到流程中。我说,我
并不是要靠人治,但流程也是靠人执行的,它不可能规定到事情的所有细节,我们项目管理
的一个重要工作就是要处理类似的冲突和问题。要用妥善的处理问题的态度、方法(比如交
待任务时要让对方感觉到你考虑到对方的困难,本着平等合作的态度,而不是,如果你不做,
我要抄送给高级的领导等做法),才可能用最简单的方式解决问题。

大家觉得我们的观点谁的更靠近成熟的项目管理呢?

其实我并不是否认流程的重要性,我是我们单位流程的总接口人,我当然知道流程的重要并
会尽力维护流程的权威性,我只是不希望大家忽略沟通、交流的重要,把一切希望寄托在完
善的流程上。有些太细节的问题,应该是不需要流程就能化解的。

不过我也在考虑,有的问题要靠流程解决还是通过沟通、交流解决,可能确实比较难判断。
我原来的想法是否太中国化,是否不符合国际成熟项目管理的思想?或者并不利于国内企业
的项目管理的长远发展?

请大家帮分析一下,谢谢!

相关分析】

第 6 页 共 756 页
第 1 章 综合管理

·回复:有多少问题要靠流程解决?(2007-08-12) [作 者] 陈海山 [公 司] NT

我认为这是流程不完善导致的。
一个完善的流程体系不仅包含流程本身,还应该涵盖了流程中的角色定位、使用的工具和文档模版。
一个意外出现了,就需要考虑是否要改进已有的流程以避免第二次发生,这也是建立流程的根本目的。

·回复楼下(2007-08-06) [作 者] XX [公 司] NJ

非常感谢 suntsang,您的直言让我感觉到,如果身边能多几个这样的朋友,将对我帮助很大。

我想您的凡是可以流程化就流程化的观点,代表正规管理的一个特点。任何一个有领导角色的管理者,
都应该具备这种基本的素质。

不过,我们在实际工作中,对有的事情不进行流程化,会有好多原因,有可能是事情本身没有必要,
或者是考虑到制度化的成本,或者是企业文化和整体管理氛围。
遇到问题,首先不管有没有必要流程化,管理者都应该去想、去权衡;而是否真的去流程化,有一个
度的把握。

个人在管理方面也处于学习进步中,所以从大家的回复中收获很大。再次感谢!

·有多少问题要靠流程解决?(2007-08-03) [作 者] suntsang [公 司] 筹备中

LZ 不是好的 manager
把特殊事例的解决方案制度化流程化是很有必要的,可以有效解决今后同类问题的解决成本,也是大
规模生产的必由之路。沟通不是只有言语的,规范文档也是一个途径。
而且在有员工提出类似建议的情况下,还有如此意见,起码说明 LZ 的管理意识不到位,甚至有沉湎
于自己的个人魅力中的趋向
至于有不同点,而解决不了的时候,将问题提交给高层的做法是完全正确的 ,因为经理人就是为了
解决规范及预期以外的事情,如果高级经理解决本可以制度化的东西,不知道算不算玩忽职守。

·感谢各位参与讨论(2007-07-26) [作 者] XX [公 司] NJ

回复比预想的少,但是还是很有收获,也许这本身就是一个不怎么困难的问题。
在沟通好一些的团队中,这种事情也许根本就不会存在。但是我相信这种问题很多人都遇到过,有一
定的典型和普遍性。我们的团队欠缺沟通所以不能避免这样的问题发生。

也正因为此,让我把注意力一下子集中到沟通这个问题,正好当时项目经理也没有在,于是直接参与
了问题的处理。也许我做得确实多了一点,这是我以后需要注意的地方。但是当时也是希望我们的团
队成员能明白沟通的重要性,有的问题,多沟通一点就不是问题了。

在与团队成员沟通的时候,能首先从本职工作角度帮助他们分析问题出现的原因,并表述清楚(双重
角色的不同角度)。这是我通过大家的回复收获最大的一点。

第 7 页 共 756 页
第 1 章 综合管理

谢谢!

·是否靠流程解决问题(2007-07-16) [作 者] 周宏伟 [公 司] 驻马店市白云纸业有限公司

我认为以上所说的手机说明书的案例,在现实生活中有很多共性,一些人(许多吧)遇到一些模棱两
可的事情就是不给你办,除非你是领导、熟人等关系,写到流程中,一句话的事,没必要费许多口舌,
让他看到这个东西,流程上写得很明白,就应当办理,否则,流程是不允许的。

·最合适的方法(2007-07-13) [作 者] 尹海涛 [公 司] 北汽

项目中灵活性很重要,硬套流程那应该是职能部门所强调的。灵活性是基于事情层次的划分和轻重缓
急,当然这些区分需要团队成员一致的共识,这也是沟通必要性所在。

对于重要的节点事件一定要按照流程走;一些小点的事情则可以按照轻重缓急来酌情处理。

此中冲突,需要项目经理而不是你来干涉,几番磨合之后,自然达成共识。你唯一所做的应该是影响
项目经理接受你的观点。

·期待更多讨论(2007-07-13) [作 者] XX [公 司] NJ

我在认真体会大家的回复。特别感谢史鹏飞、teresa、梁桢的真知卓见,对于我来说,不仅是流程的
接口人,也是公司项目管理工作的引导者。这两个角色本身是矛盾的统一。在实际工作中,除了要和
大家讲流程,也要协助用好的项目管理的思想去做引导大家做事情。所以当出现矛盾的时候,检验的
一个大的标准就是是否对项目更有利。正如 teresa 讲的这样,我的这种思想也是传承了公司上司的
管理思想并且我个人认可。

大家也多次提到交流的重要性,个人非常赞同这一点。

我想我们关注的重点应该还是运用流程的一种态度,期待高手们更多的讨论。
谢谢!

·你也太早下结论了(2007-07-12) [作 者] 诚 [公 司] n/a

做为总接口人的你,是不是把你的定位搞错了。当软件负责人问这个问题的时候,他要的答案是:流
程上有这样的文档格式或没有。你应当咨询项目管理室(如果有的话)或项目管理流程工程师,把答
案给他就是了。

你一开始做错了选择,执意地去调解他们之间的矛盾,最后弄巧成拙,猴子跳到了你的身上,你甩也
甩不掉了。

第 8 页 共 756 页
第 1 章 综合管理

·最好需要按照流程和模板进行(2007-07-11) [作 者] 方飞 [公 司] 广州日立电梯

对于一个企业的某种产品的说明书来讲,应该是一份格式固定,且有相对固定的内容提纲的一份标准
性文件,一个可以指引作业者撰写,可以让评审员容易抓住重点的一份文件,这些对于管理上都是有
益的。话说回来,如果已经把说明书都按标准写完了,那按照格式整理的时间应该不需要多少,反过
来,如果没有按照标准写全的,那么按照格式整理就会发现存在的不足。项目管理的实际操作中也会
产生诸多的标准模板,我想应该是需要的。

·流程的目的是啥(2007-07-10) [作 者] 梁桢 [公 司] 百瑞杰信息咨询

现在都在提倡建立流程,建立流程的目的是什么?规范化,大家都能够通过规范化将事情有条理的完
成,一旦出现问题可以明显的知道问题所在,并有相关人做调整。

流程没有严格定义必须要做到什么样,只要整个团队能够正确理解,并且顺列衔接,那么当前的流程
就是最佳的。对于本案软件负责人过分最求流程似乎会影响工作效率,这也体现出当前体系中的确有
权责不清的问。

同时软件负责人在解决问题前缺少沟通,硬性依赖流程,有些教条主意,PMP 只是个理论体系,在使
用式需要因地制宜。

流程规范化的确需要时间和人治,就像做项目一样,总现有框架才有分工,最后才能顺利提交合格的
项目。

·制定流程前需要充分沟通(2007-07-10) [作 者] teresa [公 司] 广州

其实,需要问一句什么是流程,如果都是没有必要的和不实际,不知道为什么还要建立这样的流程。
制定流程,就是需要与当事人讨论,确认后出台的。然后根据实际运行出现的问题,适应调整。

就这个案例,也是实际中常见的,出现问题,大家都想解决问题,方便快捷的处理问题,这个我是赞
成的。不过要看事情的本质是什么,如果是固定的流程,文档需要那个格式提交,而有个性的项目经
理又不愿意,觉得那是形式,只要内容出来才是重点,这次的解决是依赖领导的介入,下次如果还出
现这样的问题,如何呢,所以修正流程是必要的,一定要与使用人沟通,忌讳闭门造车的流程编制。
在执行上,除非特殊情况之外,条件达到才可以进行评审。

有一句,如果决策人都觉得没关系,在乎结果,形式不重要,不必拘泥,其实没有必要采取严格规范
的管理,这个我觉得流程制度的制定是应公司规模和管理意识而定,没有条件或者不成熟的运作环境,
可以宽泛管理,不强求那么教条,有基本的管理流程即可,文档要求要素就可以了,未必需要按照格
式,等实施环境和意识到位,再作更成熟的完善!

第 9 页 共 756 页
第 1 章 综合管理

刚才看到一个文章说,企业项目管理方法的一致性和决策人的项目管理理念,都是项目管理的建设重
点,决策人的项目管理知识和理念的建设是重中之重,缺少决策层支持的项目管理文化建设将是空中
楼阁。

其实关乎理念和环境,无关乎国不国,不认为这中间有什么外国和中国之分,真的。

·尽量靠流程,注重交流(2007-07-09) [作 者] 史鹏飞 [公 司] 保密

项目经理的意见我个人认为更适合。虽然有些事,我们一两句就说完了,但不以程序或者流程的方式
确定下来,也许我们在以后的项目中,很容易就忽略了很多这样的必要流程和项目内的交流与沟通。
很多细小的风险就是这样通过对流程点的控制,达到防范风险和控制风险的目的。

但是通过案例的描述,我们发现,在这个案例中,项目组成员间的交流,似乎很少,沟通的力度也不
够,以至于,项目组内的工程师,对提交什么样的格式,在什么流程中该怎么样来具体的工作,都不
明确。

流程是个硬标准,但不要忽视私下交流沟通的重要性和必要性,很多在桌面上没有得到解决和沟通的
事情,私下里运用合适的方式,都可以得到解决和较好的满意度,同时,合适的私下交流,还可以得
到很多平时工作时间内得不到的意见和批评,这对于提高自身的能力来说,是很有益的。

至于总接口人,我个人的意见是,工作的方式不大合适。当下级或者同级要么是上级提出问题的时候,
做为一个管理人员来讲,首要的事情,并不是马上下手去解决问题,而是要调查和交流,去向问题发
生的项目组,与项目负责人,管理人,具体问题的经手人,与他们谈话,了解他们的意见,牢骚,欢
迎他们提出建议,然后我们再从整个项目的目的方向,有时候甚至还要从整个公司的发展方向和目标
的高度来看待这个问题,再与具体的经手人,负责人,一起来制定解决问题的方案和方法,提出相应
的解决问题的时间限制和技术要求。

·法制和人治都很重要(2007-07-09) [作 者] daijiangbao [公 司] 深圳市大视野企业管理顾


问有限公司

法制不能解决所有的问题,人治也不能解决所有的问题,无论什么国家,都是要把法制和人治结合在
一起。
项目管理也是一样,而且项目管理更偏向于人治,才显得沟通在项目管理中的重要性,这点不是太中
国化,也不是所谓的国际成熟项目管理思想都体现为法制,不要把中国说的一塌糊涂,妄自菲薄。

第 10 页 共 756 页
第 1 章 综合管理

1.2 得罪了监理,如何完成项目验收?

得罪了监理,如何完成项目验收?

[姓 名] 陈罡 [单 位] 北京 [邮 件] guyanf@163.com
[所属行业] 能源煤电油 [所属主题] 项目综合管理 [发布时间] 2008-5-4

【案例正文】
项目属于石油管道的测量项目,因为项目较大,我司仅承包管线测量的一段,我司
的项目启动相对较早,现在已处于成果验收阶段,其他承包单位目前刚刚启动项目。
(我司第一次做类似项目,为了进入这个行业,低价中标)合同签订时同甲方签订
协议,按规定完成合同规定的内容,项目没有监理单位。

项目按照要求进入成果整理和验收阶段,在验收时,却突然出现一家监理单位(监
理单位中小 A 是前期曾同我司竞争过该项目但未中标单位的员工,甲方也一直未说
监理单位的事情,个人分析,很可能是项目制作过程中同甲方的沟通不足,甲方隐
瞒验收情况)
,对我们的成果提出异议,但通过商务手段和其他专家对项目成果的认
可,项目的部分成果得以验收(需要实地的核实的暂未验收)。

验收会当日情形:验收会中,在监理单位的小 A 提出异议时,我司销售经理(公司
副总)当即顶撞,发表一些不太友好的言论,并且在验收会当晚的庆功酒会上把小
A 搞得烂醉,说了一些个人攻击的话,很是让对方出丑。

在对项目的剩余未验收成果组织实地验收时(我司技术人员前去,销售经理和项目
经理未去(个人认为是公司为了节省成本)),结果小 A 建议监理单位挑选一段项目
难度最大的地方验收,小 A 当场否定实地验收的项目成果(其他监理人员并非对项
目成果提出异议),并推翻前期已验收的项目成果(这个推翻理论个人认为不是太合
理,因为挑选的验收区难度最大)。

监理人员小 A 当场表态,给出两种方案:
1、需要销售经理尽快来甲方协商处理问题或监理亲自来我司找销售人员制定解决方
案(这是很明显的针对我司销售人员的),并且要求在一个月内完成(工期太紧);
2、要求我司以后不介入该类项目(个人认为现在的项目成果并不影响甲方的使用,
完全满足甲方的要求,甲方也认可,但就是监理的小 A 不认可,其他监理人员无异
议)。现在双方处于抵制状态,很难完成项目验收。

个人给公司提出的意见是通过商务手段(增加商务成本,同敌对的小 A 进行私下沟
通,并公开道歉)来解决会好一点。但这个项目的项目经理反对,认为必须对项目

第 11 页 共 756 页
第 1 章 综合管理

成果重新制作。可这样依然会增加项目成本(这个成本应该不低于通过商务手段解
决所花费的成本),并且会耽搁很长时间。个人认为这主要是因为项目经理不敢对销
售经理(毕竟是公司副总)直言,只能牺牲团队利益和时间去想办法挽回局面,把
成本拖在较长的阶段内,以转移领导的注意力。

请问:针对这种情况,这个项目该如何处理,怎么才能完成验收?
(我不是这个项目的成员,只是看到这个项目现在的情况,有些想法,想向各位请
教解决方案,谢谢!)

【相关分析】

·人情公关(2008-08-06) [作 者] 谭剑 [公 司] 中华商务网

案例中提到过,只有小 A 不认可项目成果;而实际也不影响甲方的应用,个人感觉,这事情就好办
了,打通其他监理人员关系,通过他们的关系,当面对小 A 道歉,委托其他监理做小 A 的工作。验
收工作不外乎人情关啊。

·以其人之道(2008-07-23) [作 者] anbh [公 司] beijing

从文章中的说明可以看出,项目的质量验收总体来说还算可以,可能也有些瑕疵,大多数的业主和监
理是通过的。所以,对这种监理应对业主和项目总监软硬兼施,以痛打落水狗的精神将这个监理搞掉。
作为一个承包商,如果连一个监理的刁难都处理不了,那就证明在项目的执行过程中与业主的关系没
有处理好。

·与监理无关(2008-06-03) [作 者] daijiangbao [公 司] 深圳市大视野-超越项目混沌

你只与客户有合同关系,与监理屁关系都没有,把合同完成了就完成了项目,与监理什么鸟事,怎么
会莫名其妙弄个卡脖子的监理出来,又不是你邀请来的。
要注意合同的排他性,只存在双方,这个项目你应该把监理纳入你的指挥下,不是他来卡脖子
不要被什么 fidic 中定义的客户方工程师所吓住,你可以与他们没有关系。

·比较郁闷 (2008-06-03) [作 者] 陈敏 [公 司] 南京天成金盾科技发展有限公司

只能商务和技术双管齐下了,个人很讨厌那种公报私仇的人,强烈鄙视!

·回(2008-06-03) [作 者] 陈敏 [公 司] 南京天成金盾科技发展有限公司

监理介入不应当和项目的参与方有利害关系的哈,不过中国目前的项目还真不能光按照项目标准走!

·未答完(2008-05-27) [作 者] 黄赟 [公 司] 赣州城建市政工程管理有限公司

第 12 页 共 756 页
第 1 章 综合管理

在中国,仅靠项目和工程的技术角度去思考和解决问题,没有问题也会成为问题,在两条腿走路,两
手都要硬,双管齐下才能做好项目

·无题(2008-05-27) [作 者] 黄赟 [公 司] 赣州城建市政工程管理有限公司

中国有着自己特殊的国情,做工程 做项目,不能简简单单的用工程或项目的思维

·项目最新进展!谢谢各位参与(2008-05-21) [作 者] 陈罡 [公 司] 北京

谢谢各位献计献策!

目前项目在我司的强烈要求下,原来的监理小 A 退出(不再监理该项目),不过项目成果还需要重新
验收。

总算看到了一线生机!

·悲哀(2008-05-20) [作 者] 程 成 [公 司] 广州建筑工程管理有限公司

我很同意“郁闷”的说法,但是,究其根底,是我国工程界的悲哀。也许说严重了,对不起。若大家
仔细想想,为何项目管理知识不能在国内工程中很好应用与总结?原因只有一点,我们不尊重自然科
学规律,人员素质远未达到。只要是甲方,你就得服从,不分青红皂白。
因此,该问题比比皆是。如何处理?除了“郁闷”说法外,你只有借助甲方了。高调一点,就是加强
沟通。

忍吧,退一步海阔天空。只要没逼你上绝路。

·得罪了(2008-05-11) [作 者] chow king lam [公 司] beria consultants limited

既然已经到了竣工阶段,不妨请甲方介入吧?

·aa(2008-05-10) [作 者] zhuangqm [公 司] sdrcu

1.甲方在确定监理公司时,未将监理单位及人员通知被监理单位。
2.参加监理的人员不能与甲方、被监理单位存在利害关系。
3.监理没有起到公平、公正的作用,而是带着浓厚的感情色彩。
4.监理方、被监理方、甲方没有建立良好的沟通机制,如工程例会、协调会等;出现问题也没有良好
的处理机制。

第 13 页 共 756 页
第 1 章 综合管理

·得罪了监理,如何完成项目验收?(2008-05-06) [作 者] 王元涛 [公 司] 济宁正通建设工程


有限公司(山东)

找个监理单位的中间人说和说和,想办法补偿小 A 的精神损失,然后象征性整改下就可以了。让小 A
给业主说通过。

·难(2008-05-06) [作 者] 木文竹 [公 司] 杭州

从正文中看到“要求我司以后不介入该类项目”这条要求,明显不是个人问题了,摆明了是找茬;“监
理单位中小 A 是前期曾同我司竞争过该项目但未中标单位的员工”,这表明是该单位的意思,大多数
专家都认可了,就小 A 一个人不认可竟然验收不了,又说明了客户的意思,呵呵,总的来讲,个人并
不赞同通过商务手段去摆平小 A,基本上是不可能的,个人觉得最可能的方法就是搞定客户。

·普通的事(2008-05-05) [作 者] kou [公 司] 百通

我觉得公司内部应该先讨论一下吧,看看那种方式更容易达到验收的目的。
从上文可以看出,坚持现有结论是对己方最为合适的。其它监理和甲方都认可了这方案。
1.可以采取些客户关系手段与 A 进行私下沟通,赔罪等方式。也可以换一个销售经理去和 A 沟通,态
度要诚恳,表明监理的重要性,对以前的事情要做深刻道歉。换取 A 收回他的表态
2.找甲方主管人和甲方领导进行沟通,说明数据已足够使用。从新做成本和时间浪费的不利性。只要
甲方同意,可以把 A 甩在一边不用满足他的表态。

·脚正不怕鞋歪,身正不怕影斜(2008-05-05) [作 者] 朱行军 [公 司] 保密

现在的项目大多数是有监理的。如果你们的项目质量做的没有问题,就不要害怕监理的刁难。如果你
们的项目质量有问题,那么你们首先要对存在质量问题的地方进行整改,然后进行验收。
作为施工单位,尊重监理单位,尊重监理的每一个人是最起码的,你不尊重别人,也就不要想别人尊
重你,更何况是在验收的庆功酒会上。如果前期验收真的存在问题,监理推翻先前的验收结论不是不
可能的,因为合同中隐含了这样的条款。至于小 A 的方案应该有监理单位或项目总监理工程师来决定,
并不是小 A 决定。
处理问题要符合相关规范和程序,行贿受贿不能解决问题,至于人身伤害更是不能解决问题,害了别
人也自己。
古语讲“解铃还须系铃人”,这是我认为的方法。仅供参考。

·郁闷(2008-05-05) [作 者] 木文竹 [公 司] 杭州

碰上这种事情真的好郁闷啊,是火冒三丈还是阴森冷笑或者面无表情甚至笑脸相迎就看一个人的修养

第 14 页 共 756 页
第 1 章 综合管理

和经历了。
大多数人都会火冒三丈,这种找茬的事谁碰上都不好受;不过《绝代双骄》里十大恶人中的笑弥勒说
得好啊——笑,一定要笑,哪怕你正把刀子捅向他,你也要对着他笑。
唉,我也碰到过这种事,说白了还是两种方法,公了和私了。目前项目监理制度混乱,也没有个特别
明确的标准,监理非要揪住一点小事不放,说实话还真是拿他没办法,公了的话,对项目成果重新制
作,重新完工时要是再找麻烦怎么办?不管什么项目谁能保证一点问题不出呢。
在项目质量基本上没有问题,并且其它专家也认可的情况下,通过商务手段搞定对方也许是个好方法,
但怎么保证别人见公司比较“好欺负”,不效仿这个方法来捞取好处,也许公开道歉就不必了,反正
都是花钱搞定事的,想必对方肯收钱的话也不会真的在意这么点“面子”。
我做的是 IT 的,信息化的监理不知道和传统实业监理又没有区别,不知道能不能通过法律方式解决
问题,也不知道能不能再找一家监理对小 A 的分析做下认证,证明他的提议是正确的。以前做 TI 从
来没见过有监理,现在也这样了,正在郁闷中,呵呵。有些监理真的是狗腿子,阎王好见,小鬼难缠
啊。当然,这样地监理倒是可以通过搞好客户关系搞定他,就是怕他在项目实施中不懂装懂指手画脚,
TI 监理有几家是正规的?呵呵

1.3 *技术出身如何做好项目经理?

技术出身如何做好项目经理?

[姓 名] PMU [单 位] PMU [邮 件] member@mypm.net


[所属行业] 综合应用 [所属主题] 项目综合管理 [发布时间] 2008-1-2

【案例正文】
Codeword 公司是一家为战斗机设计电子设备的中型公司,他们通过与其他公司竞争
来获得提供这种系统的合同,其主要客户是政府。Codeword 公司获得合同后,就成
立项目,完成工作。大多数项目的成本是 1000 万~5000 万美元,期限是 1~3 年,
Codeword 公司能同时开展 6~12 个项目工作,并处于不同阶段,有些刚开始,有些
则临近尾声。Codeword 公司拥有众多项目经理,他们向总经理负责,其他人员向他
们的职能经理负责。例如,电气工程师全都向电气工程经理负责,电气工程经理又
向总经理负责。职能经理把具体人员分配到每个项目中去。有些人完全为了一个项
目工作,有些则分时间在两三个项目中工作。尽管人员在具体项目中指定为该项目
经理工作,他们仍然受职能经理的领导和管理。

杰克•科瓦尔斯基(Jack Kowalski)已经为公司工作了 8 年。他在大学获得电气工程


的理学学士学位,毕业后,一直做到高级电气工程师,向电气工程经理负责。他从
事过各种项目工作,在公司里深受尊重,有希望成为项目经理。不久,Codeword

第 15 页 共 756 页
第 1 章 综合管理

公司获得一个 1500 万美元的合同,为一种新型飞机设计制造先进电子系统。这时,


总经理将杰克提升为项目经理,并让他负责这一项目。

杰克与职能经理一起为这一项目配备了现有最好的人员,他们大多数是亲密的伙伴,
以前曾与杰克一起在项目中工作过。然而杰克被提升为项目经理后,高级电气工程
师这一职位空缺,电气工程经理无法为杰克的项目分配合适的人员,于是总经理招
聘了一位新员工阿尔弗雷德•布赖森(Alfreda Bryson),她是从公司的竞争对手那里
挖过来的。她是电气工程的博士,有 20 年的工作经验,她的薪水标准很高,要比杰
克高。她被委派到杰克的项目中,专任高级电气工程师。

杰克对阿尔弗雷德的工作给予特别的关注,并提出与她会谈,讨论她的设计方法。
然而这些会谈几乎全由杰克一个人说,他建议怎样设计,完全不理会她的说法。

最后阿尔弗雷德质问,为什么他检查她工作的时间要比检查项目中其他工程师的时
间多得多。他回答说:“我不必去检查他们的工作,我了解他们的工作方法,我和他
们在其他项目上一起工作过。你是新来的,我想让你理解我们这里的工作方法,这
也许会与你以前雇主的工作方法不大一样。

另一次,阿尔弗雷德向杰克表示,她有一个创新设计方案,可以使系统成本降低。
杰克告诉她:“尽管我没有博士头衔,我也知道这个方案没有意义,不要这样故作高
深,要踏实地做好基本的工程设计工作。”

丹尼斯•弗曼(Dennis Freeman)是另一位分配到项目中工作的工程师,他认识杰克
已经 6 年了。在与丹尼斯•弗曼的一次出差旅行中,阿尔弗雷德说,她为杰克对待她
的方式感到苦恼:“杰克在项目中的作用,与其说是项目经理,倒不如说是电气工程
师。另外,对于电子设计,我忘记得比他知道得还多,他的电子设计方法早已过时。”
她还说,她打算向电气工程经理反应这一情况,她要早知道这个样子,决不来
Codeword 公司工作。

案例问题
1.你认为杰克能够胜任项目经理吗?说明原因。
2.杰克为这一新岗位做了哪些准备工作?
3.杰克与阿尔弗雷德交往过程中的主要问题是什么?
4.为什么阿尔弗雷德没有与杰克开诚布公地交谈他对待她的方法?
5.如果阿尔弗雷德与杰克直截了当地讨论,杰克会怎么反应?
6.电气工程经理对这情况的反应将会是什么?他会怎样处理解决?

【相关分析】

·技术出身如何做好项目经理?(2008-06-25) [作 者] 黄言敏 [公 司] 3G门户

第 16 页 共 756 页
第 1 章 综合管理

1.你认为杰克能够胜任项目经理吗?说明原因。
不能, 首先在杰克成为一名项目经理时, 对其工作职能没有很好的进行定位,导致心态和工作重心
没有进行过渡和调整。其次,在项目进行的过程中,杰克过多的干涉专业人才的工作, 导致在 team
内部出现了沟通障碍。另外, 整个案例没有出现杰克在管理方面的描述, 因此我更认为杰克是一个
技术的管理者,而不是项目的管理者。
2.杰克为这一新岗位做了哪些准备工作?
在这个项目准备过程中,杰克配备了大量优秀的人才,并且该 team 的成员与杰克长期共事,杰克对
各成员都非常了解。其次,在阿尔弗雷德加入该 team 时,杰克帮助其理解 team 的工作方式和方法,
这点非常有必要。
3.杰克与阿尔弗雷德交往过程中的主要问题是什么?
1. 缺乏总体把握意识,在项目进行的过程中,掌控范围过于细节化。
2. 缺乏项目框架管理经验, 在技术研讨的过程中,不能够接受他人的建议,没有提出多个方案进行
优化决策。导致项目风险控制没有达到最大化。

4.为什么阿尔弗雷德没有与杰克开诚布公地交谈他对待她的方法?
首先,我认为阿尔弗雷德没有与杰克开诚布公地交谈他对待她的方法是一个正确的选择,在阿尔弗雷
德与杰克的沟通中, 杰克对阿尔弗雷德和阿尔弗雷德提出的建议缺乏最基本的尊重,因此他们之间
的沟通是一种不平等的沟通,在此状态下,他们的沟通往往不能达到沟通者最基本的目的。
5.如果阿尔弗雷德与杰克直截了当地讨论,杰克会怎么反应?
在此条件下,如果阿尔弗雷德与杰克继续通论他们的沟通方式, 只会更加激化他们之间的矛盾,让
杰克无法容忍阿尔弗雷德在 team 中存在。
6.电气工程经理对这情况的反应将会是什么?他会怎样处理解决?
电气工程经理对此阿尔弗雷德与杰克彼此之间发生的问题做一个详细的了解,定位在此之中他应该扮
演的角色,尽量帮助和协调两者之间的关系,如果杰克在短时间内无法协调与阿尔弗雷德之间的关系
的话,电气工程经理应该承担起阿尔弗雷德与杰克之间桥梁的角色,以保证项目的最终目标。

·知人善任(2008-02-19) [作 者] Laurence Shan [公 司] Wicresoft

1.你认为杰克能够胜任项目经理吗?说明原因。
不能胜任,因为不懂得与人沟通,不能做到知人善任

2.杰克为这一新岗位做了哪些准备工作?
调配熟悉的组员加入项目组

3.杰克与阿尔弗雷德交往过程中的主要问题是什么?
Jack 用了自己不能完全信任的员工,并且事必躬亲。

4.为什么阿尔弗雷德没有与杰克开诚布公地交谈他对待她的方法?
她知道谈了也不会有结果,因为 Jack 听不进去。

5.如果阿尔弗雷德与杰克直截了当地讨论,杰克会怎么反应?

第 17 页 共 756 页
第 1 章 综合管理

Jack 自己不能意识到别人的感受,所以他的反应会是冷淡,或者回绝,不会有积极的结果。

6.电气工程经理对这情况的反应将会是什么?他会怎样处理解决?
找 Jack 谈话,让他意识到自己工作方式中的错误,如果难有起色则更换项目经理。

·技术出身的人很难当好项目经理(2008-02-18) [作 者] 123 [公 司] 123

1.就目前状态来讲,杰克无法胜任项目经理这一职位。他的思想还没有完全从技术专家转换到项目经
理上。他是一名很出色的技术专家,确是一名很糟糕的项目经理。作为项目经理,他应该更多关注整
个项目的进展情况,而不是单关注项目技术方面。
作为项目经理,杰克过分关注阿尔弗雷德的方案了,甚至有不信任的想法在其中。这在一个项目团体
中是很可怕的。项目经理切忌凡事一把抓。
2.“杰克与职能经理一起为这一项目配备了现有最好的人员,他们大多数是亲密的伙伴,以前曾与杰
克一起在项目中工作过。”杰克知道自己是初次胜任项目经理这个职位,因此,他为这个项目配备了
曾经与自己合作过的亲密伙伴。这对项目成功是很有必要的。
3.“阿尔弗雷德•布赖森(Alfreda Bryson),她是从公司的竞争对手那里挖过来的。她是电气工程的博
士,有 20 年的工作经验,她的薪水标准很高,要比杰克高。”这些先决因素导致了杰克的心理不平衡,
主要表现在“杰克对阿尔弗雷德的工作给予特别的关注,并提出与她会谈,讨论她的设计方法。然而
这些会谈几乎全由杰克一个人说,他建议怎样设计,完全不理会她的说法。”
当阿尔弗雷德质问杰克为什么他检查她工作的时间要比检查项目中其他工程师的时间多得多时,杰克
的回答只是为自己的行为编造了一个谎言而已。
甚至对于阿尔弗雷德提出的一个创新设计方案,他也是全盘否定。作为一名成功的项目经理,不应该
把个人的想法加注到项目中。
4.阿尔弗雷德经过几次与杰克沟通无效后,觉得与杰克面对面的谈根本不会出效果。如果通过杰克身
边信任的朋友、杰克的领导将这些意见转达给杰克效果反而会好些。
5.反应估计会有 3 种。1)双方不欢而散。今后项目中继续针锋相对。2)听取阿尔弗雷德的建议,努
力改变自己的工作作风。3)向技术总经理汇报,要求撤换高级电器工程师。
6.首先明确事情发展的起因,经过。再确定是否更换人员。他可以提高杰克的工薪待遇水平;可以给
杰克培训项目管理知识;可以撤换项目经理或者撤换阿尔弗雷德(当然这是下策)

·转变角色(2008-02-17) [作 者] mj [公 司] zzzkkdidk

1、杰克没有从一位技术专家到管理角色的转变;
2、杰克没有进行受到项目管理方面的培训
3、杰克没有转变工作重心
4、杰克缺乏项目经理最重要的沟通技能

如果要做一个合格的项目经理,杰克必需尽快从一个技术专家向管理岗位进行转变,学习项目管
理的相关知识,提高自已的沟通能力,使自已尽快转变工作角色。

·如何做好项目经理(2008-02-13) [作 者] wanglizhi [公 司] 滁州劳动信息中心

第 18 页 共 756 页
第 1 章 综合管理

杰克显然未准备作好项目经理的准备
建议 1.正确认识项目经理的职责
2.作好沟通
3.不要宥于过去的经验,技术上应该不是问题,尊重同行的想法
4.组织好团队

·技术人员做项目经理(2008-02-01) [作 者] 李平 [公 司] 暂时保密

杰克还是可以胜任的
1 杰克从技术工程师到项目经理目前只是缺少必要的管理技巧
2 杰克作为项目经理还是作啦很多工作的。比如杰克对阿尔弗雷德的工作给予特别的关注,并提出与
她会谈,讨论她的设计方法。原因是:你是新来的,我想让你理解我们这里的工作方法,这也许会与
你以前雇主的工作方法不大一样。

·科技人才当经理(2008-01-24) [作 者] 老杨 [公 司] 产品开发和系统集成

作为项目经理,不能一切都“谋由己出”,即使你认为自己一贯是对的,实际上,为了培养团队精神
和责任感,对于成员的意见要优先参考,我曾经试过采纳团队中并不十分看好的建议,结果竟然出乎
意料的好,条条大路通罗马,不要让你的技术特长当了自己的路;
推而广之,实际上,越是优秀的技术人才,成为优秀的项目经理的困难越大,敝帚自珍和以自我为中
心是这类人常犯的毛病,很不幸,杰克看来就是;
杰克应该怎样解决问题,我想首先要转变思想,迈克尔·K·巴达威博士的大作《科技人才当经理》
里面应该有答案,显然杰克应该站在项目经理而不是技术上帝的角度来思考和解决问题;
另外,这本书中说比较优秀的技术人员更有希望成为优秀的项目管理者,对我触动很大,实践下来,
发现也确实如此最后。
总结一下:
作为技术人员,有突出的优点就可以卓越,但作为管理人员,全面发展,没有突出的缺点才能成功,
所以不看好杰克能胜任项目经理。

·技术出身如何做好项目经理?(2008-01-15) [作 者] 何根华 [公 司] VXI (china)

1,很明显,杰克缺少作为一个合格 PM 的经验,他还需要历练.
首先,他在项目中充当的是技术人员的角色,而非管理人员的角色.
其次,沟通是项目经理最重要的技能,但杰克与阿尔弗雷德的沟通却很糟糕,杰克在与阿尔弗雷德沟通
时,只是一味的表达自己的意见并要求别人接受,对于阿尔弗雷德的建议并未加以考虑,有时甚至是粗
暴的拒绝.有时使用压制这种糟糕的沟通技巧.导致沟通失败,造成团队摩擦和矛盾.

第 19 页 共 756 页
第 1 章 综合管理

2,杰克为这个项目也做了不少的有益的准备,如,为项目匹配

·技术出身的项目经理应该怎样办才能成为合格的经理(2008-01-11) [作 者] yaoshiyong [公
司] 保定长城汽车

1、杰克不能够胜任项目经理,因为杰克在这个故事中不像一个项目经理,倒像是一个职能经理。没
有全盘把握和善于沟通的整体能力。
2、杰克在这个项目中配备了现有最好的人员,这些人员关系也与杰克密切,可以省去好多沟通工作
和对员工的整体了解掌握。友配备了一个电气工程博士。
3、没有鼓励手下和对手下的一个信任。在沟通方式方法也有问题。
4、因为她认为杰克的沟通管理方法部对,自己没有一个成型的想法。
5、杰克会全盘否定阿尔韦雷德的想法。
6、职能经理会找杰克沟通交流,他会采用会议评审的方法解决这个方案,并且交流关于对手下的想
法的肯定的交流。

·技术出身的项目经理应该怎样办才能成为合格的经理(2008-01-11) [作 者] yaoshiyong [公
司] 保定长城汽车

1、杰克不能够胜任项目经理,因为杰克在这个故事中不像一个项目经理,倒像是一个职能经理。没
有全盘把握和善于沟通的整体能力。
2、杰克在这个项目中配备了现有最好的人员,这些人员关系也与杰克密切,可以省去好多沟通工作
和对员工的整体了解掌握。友配备了一个电气工程博士。
3、没有鼓励手下和对手下的一个信任。在沟通方式方法也有问题。
4、因为她认为杰克的沟通管理方法部对,自己没有一个成型的想法。
5、杰克会全盘否定阿尔韦雷德的想法。
6、职能经理会找杰克沟通交流,他会采用会议评审的方法解决这个方案,并且交流关于对手下的想
法的肯定的交流。

·技术出身的项目经理应该怎样办才能成为合格的经理(2008-01-11) [作 者] yaoshiyong [公
司] 保定长城汽车

1、杰克不能够胜任项目经理,因为杰克在这个故事中不像一个项目经理,倒像是一个职能经理。没
有全盘把握和善于沟通的整体能力。
2、杰克在这个项目中配备了现有最好的人员,这些人员关系也与杰克密切,可以省去好多沟通工作
和对员工的整体了解掌握。友配备了一个电气工程博士。
3、没有鼓励手下和对手下的一个信任。在沟通方式方法也有问题。
4、因为她认为杰克的沟通管理方法部对,自己没有一个成型的想法。
5、杰克会全盘否定阿尔韦雷德的想法。

第 20 页 共 756 页
第 1 章 综合管理

6、职能经理会找杰克沟通交流,他会采用会议评审的方法解决这个方案,并且交流关于对手下的想
法的肯定的交流。

·技术出身的项目经理要更注重如何做管理工作(2008-01-07) [作 者] lee [公 司] 无

1、杰克不是个合格的项目经理。项目经理的职责是管理,它是艺术与科学结合,是为完成项目的目
标对各方面资源的集成管理。而不是做自己擅长的技术工作。
2、从案例中看,杰克只是沿用过去做设计师的经验来准备做项目经理的工作的。
3、杰克与阿尔弗雷德交往中的主要问题沟通问题。
4、阿尔弗雷德认为杰克缺乏管理能力,不能虚心接受别人的建议。
5、杰克或许能够反省自己在管理中存在的问题,更注重如何做好应做的管理工作,或者对此讨论不
屑一顾。
6、电气工程经理应当找杰克谈谈,帮助他认识到自身管理中的问题,建议他和阿尔弗雷德改变沟通
方式,解决他们之间的矛盾。

·卖盐的总是不自觉地考虑盐咸不咸(2008-01-06) [作 者] dajundalao [公 司] 暂时保密

先回答这六个问题:1、杰克做项目经理有点“卖盐的总是不自觉地考虑盐咸不咸”的味道,确切说,
他在项目经理的位置上还是在以经验管理来适应科学管理,当然,他当项目经理至少不是合格的。
2、杰克应该为这一新岗位准备一套管理方案和解决与沟通问题的办法,大多数的亲密伙伴是他项目
的宝贵资源,但他没有充分发挥好新加入团队员工的管理、激励和使用,阿尔弗雷德这一资源杰克用
得很差。
3、杰克与阿尔弗雷德交往中的主要问题是缺乏坦诚的沟通。
4、5、杰克表现出了过分的强势和不吸收好建议的独裁型风格,对员工造成了消极影响。
6、如果电气工程经理听取了这个情况,他的反应会有两个:一是找杰克这个老伙计谈谈,杰克认识
到自己的不足,邀请阿尔弗雷德仍然留在这个项目,完成剩余工作;二是协调另一名杰克喜欢或熟悉
的电气工程师,阿尔弗雷德与那位同仁互换。
再说说这个企业和杰克。
假如这个企业存在且案例是真的,那么说明国外企业与国内企业一样,也存在用人方面的问题,同时,
外国主管比中国主管更加固执。
杰克是个专家,被用到管理岗位上,其管理知识和技能的缺失使他时常超越不了自己,不自学地考虑
到自己优势与优越的那部分工作,以经验管理代替科学管理,以为拥有充分的资源就一定能够使项目
成功,结果当然是,项目圆满成功的概率较低。再有:面子能让一个项目撑多久?!

第 21 页 共 756 页
第 1 章 综合管理

1.4 如何面对这样的软件开发项目?

如何面对这样的软件开发项目?

深圳市大视野
[姓 名] daijiangbao [单 位] 企 业 管 理 顾 问 [邮 件] daijiangbao@hotmail.com
有限公司
[所属行业] IT 软件 [所属主题] 项目综合管理 [发布时间] 2007-12-4

【案例正文】
以下付款条件是深圳现在软件招标文件中惯常采用的方法:

1、付款方式:签订合同七天前中标人向采购人支付合同金额 10%的履约保证
金或保函;

2、系统软件开发费付款说明:合同签订后 15 个工作日内预付 30%预定金,系


统建成验收后两周内付合同中软件费用总金额 50%;一年期协助营运正常结束后付
10%,余款 10%为首年协助营运后下一年度的配合费,正常配合一年后支付。

深圳有众多的软件公司,按此方式进行软件项目,已经做死了很多软件公司。
虽然现在深圳的软件招标,动辄都是数百万元的开发费,但客户仍然不满意,又对
开发商出此歪招。

我也向这样的客户请教了一下为什么这样做,答曰:中标后,先逼着开发方打
10%的合同额过来做履约保证金,剩下的预定金等一概不给,让他们去开发,两年、
三年由开发商去做,只要是有一个人不满意,别说是能挣上一分钱,这 10%都别想
拿回去,这样就把自己的责任摆脱的一干二净。深圳本地的公司还好说一些,外地
的公司就不要谈能挣上钱了。

如果你是一家南京的软件公司项目经理,看好深圳的软件开发市场,报了一个
低价中标杀了进来,你将如何完成这样的软件开发项目,如何面对这样的 10%的履
约保证金,如何能够让项目获得利润,如何让客户满意?

【相关分析】

·还得用PMBOK(2008-07-29) [作 者] 大学生 [公 司] 扬州大学

第 22 页 共 756 页
第 1 章 综合管理

1,为政府开发项目,合同管理的作用就更加明显了,规定在项目过程中的权责利,更要说明资金不
到位相应应对措施。希望中国的法制逐渐完善,提升合同威慑力。
2,在项目范围管理上下功夫,制定详细的范围说明书,明确项目成功的标准,避免个人主观因素判
定项目的成败。软件开发本来就面临需求多变的问题,因此要建立科学的需求变更管理系统,设置相
应流程。
3,建立沟通机制,良好的沟通有利项目推进。资金能否及时到位,也要看项目经理的手段了。
4,案例中项目经理应先开发市场,其次考虑利润。应该进行有效的风险管理,假如开发资金真的不
能到位,建议先开发,然后交付高质量的产品或服务,这才是根本的生存之道

·我的看法(2008-02-27) [作 者] 郑生华 [公 司] 福州

如果真的像 DAIJIANGBAO 所说合同都是政府的格式合同,不能任何修改,那个人觉得真是没办法


做!如果可以补充条款,则:
1、肯定要明确项目范围、目标、需求等
2、肯定要明确初验、终验条件及付款条件等
3、肯定要明确维护等相关职责等
4、肯定要明确工作流程包括需求变更流程等

·答张观石(2007-12-22) [作 者] daijiangbao [公 司] 深圳市大视野企业管理顾问有限公司

对于张观石的意见我是有看法的。
总的来说,政府压迫开发商交出 10%的履约保证金,就是要压迫开发商去做,怎么还会拿开发费给
你?随你做两三年了,项目失败了政府一分钱损失都没有,还能倒赚 10%,纪检委怎么查都说的过
去,这样政府的乌纱帽也就保住了,无能的是开发商。
开发商不值得同情,因为不明白项目管理怎么做,用软件工程的理念从根本上来说就错了。

·与bona的商榷(2007-12-22) [作 者] daijiangbao [公 司] 深圳市大视野企业管理顾问有限公司

谢谢 bona 的意见,我来说一下我的观点:
1、 本人说的是 10%的履约保证金,不是违约金,这是招标文件中我照抄的一段话,违约金和履约
金不是一回事,这个明显的是政府违反招投标法的,但是站在中立的立场来看,政府也无奈,如同我
在案例中的介绍,我更同情政府,从项目的根本目标来说,没有让政府满意,开发商是不应该得到报
酬,但是开发商的软件项目管理在国内国外都是很成问题的,在实际项目中,不能拿那些理想环境来
套现实。
2、30%的首付在合同中也可以写,但是就不会执行了,我在案例中已经说明了,把 10%的履约保证
金压迫到手以后,首付就会千方百计不给的,逼迫开发商去开发,一般来说,傻的不透气的开发商也
就会就范,也就是 bona 所说的硬着头皮做,反过来开发商还会抱怨政府,是应该给自己两个耳光才
对。
3、30%-50%的时间间隔?据我所知没有那个开发商去过问,只是按照软件工程的基本理念,认为
做好了就会给钱的,而且采用的是招标文件中约定所谓格式合同,这个格式合同一点用都没有。
4、政府部门不是强势部门,是因为开发商把他们捧成了强势,实际上甲方,不论是政府还是企业都

第 23 页 共 756 页
第 1 章 综合管理

是弱势部门,不要被表面现象所迷糊。
5、需求不确定不是客户的错,还是开发商的错,在项目管理中就没有需求不明确这样的说法,是管
理的问题,用软件工程的方法来看待、开发软件项目,就会得出狗眼看人低的局面,这是软件工程不
适应软件项目的方面,但不是软件项目的错。

·难(2007-12-19) [作 者] 张观石 [公 司] test

这个问题其实不能说是项目管理的问题,而是商业谈判的问题。
这个案例中甲方的义务几乎为 0,而乙方则陷阱重重,深浅莫测,
如果甲方坚持这样,可能有他的理由,而你有即想要这个单的话。建议试试这个谈判筹码:进驻开发,
开发人员费用由甲方暂支出。我认为甲方的理由可能是担心费用给了,不做事,或拿了钱不认真做事。

·一些看法(2007-12-19) [作 者] bona_zhao [公 司] anonymouse

1、10%的违约保证金在那个项目中都有。

2、30%的首付预定金都不执行?

3、30%与 50%之间的时间多长?太长的间隔对乙方就意味着巨大的风险。

从案例描述来看,这个合同对甲方没有任何约束力。在这种情况下,乙方要么就硬着头皮做,要么就
壮士断腕,终止合同。

在如今的环境下,政府部门永远是强势的。

另外,做政府的项目经常遇到需求不确定,不清晰的情况,这与甲方技术能力的欠缺有一定的关系。
在频繁变更的情况下,做出的产品往往是一个四不像。甲方对产品不满意,也不单单是乙方的原因吧。

因此,乙方所能够做的就是:引导甲方明确定义需求;良好沟通;控制变更范围等并得到甲方书面确
认。但这些成功实施的前提就是一份对双方对等的合同。

·这是政府招标项目,呵呵(2007-12-18) [作 者] daijiangbao [公 司] 深圳市大视野企业管理


顾问有限公司

如果大家能上到深圳政府采购网站下载招标文件,你可以看到这些条款,不是我在乱说。
做政府的软件开发商,估计没有几个不抱怨政府的,但是反过来,软件开发商又做的怎么?政府又是
如何来抱怨开发商的?政府又多希望开发出的软件是满意的啊
对这类的项目,我们真的不能怪政府,在中国来说,软件开发几乎与开发费用没有什么关系,给开发
商钱少了做不满意,给钱多了也做不好,合同金额高都没有用,所以这是一个怪圈,到手的钱都挣不
到。软件开发过程规范了也作不好,不规范也不是不能验收

第 24 页 共 756 页
第 1 章 综合管理

关键是现在太多的乱七八糟理论冒充软件项目管理,什么软件工程、iso9000、cmm、cmmi、fidic 基
于土木工程的软件开发合同等,都不能解决这些问题。
但是这些问题用 pmbok 的现代项目管理是都能解决的,可惜的是没有什么人能看明白。

·你作为项目经理,将如何面对这样的项目?(2007-12-18) [作 者] momoninan [公 司] 凯迪

不管是什么样的软件项目,客户总会有不满意的。

但是像那种客户——“答曰:中标后,先逼着开发方打 10%的合同额过来做履约保证金,剩下的预
定金等一概不给,让他们去开发,两年、三年由开发商去做,只要是有一个人不满意,别说是能挣上
一分钱,这 10%都别想拿回去,”

我估计他们在市场上也存在不了长久,他们能这样对待乙方,不讲诚信只能混迹一时

·不合适(2007-12-17) [作 者] 孙灵芝 [公 司] 山东大学

这样也太不公平了吧,软件行业的利润很大?

·你作为项目经理,将如何面对这样的项目?(2007-12-13) [作 者] daijiangbao [公 司] 深圳
市大视野企业管理顾问有限公司

呵呵,这是真实的案例,你作为一个项目经理能把这个项目做好,获得很好的利润,让客户满意,你
就绝对是在软件项目管理上可以说登峰造极了,该案例的回答,你如果采用传统的项目管理或者是软
件工程的模式,只有死路一条,事实胜于雄辩的。
项目管理绝对不要搞成无病呻吟的一种做事方式,解决不了实际问题,解决这样的问题需要你能真正
领会现代项目管理,理解现代的商业,才能找到答案,我们常说,办法总比问题多,希望大家能真实
的从这类的案例中找到解决的办法,不必管什么博士、硕士、mba 等无用的帽子吓唬人,真实的把问
题解决好,使该项目走出软件工程的混沌,脱离软件项目的死亡之旅。

·明确项目范围、加强沟通管理(2007-12-06) [作 者] H.B Fang [公 司] HHU

1、签定合同时对开发项目的范围、界限和目标作出明确;
2、加强与用户沟通,了解需求和要求,并形成纸质文件备份;
3、在合同中,对双方违约责任明确处理方法;

·合同对等(2007-12-05) [作 者] dajundalao [公 司] 暂时保密

第 25 页 共 756 页
第 1 章 综合管理

首先卖方的履约保证金或保函与买方的预付款保证金对等,这样卖方风险就降低了.
其次,行业竞争的不规范和软件开发这个市场不规范使这个行业充满了陷阱,若低价位中标杀入,则需
慎重安排精兵强将来做这个项目,从南京到深圳,员工所适应的环境不同,项目干系人需要沟通并重新
改变原有思维方式去认识,要让客户满意就要有充分的沟通,并且要使自己做出来的软件让客户满意,
否则,肯定失败.
再次,如果要让你获得利润,则要从项目干系人特别是买方做文章,关系处好了,取得买方的认可和同
情了,如果可能签订一个补充协议,这样利润的问题就有保障了.

1.5 供应链成本削减项目走入困境

供应链成本削减项目走入困境

[姓 名] 张星 [单 位] 青岛 xx 股份有限公司 [邮 件] zwx520@hotmail.com
生 产 制
[所属行业] [所属主题] 项目综合管理 [发布时间] 2007-10-29

【案例正文】
本人所在企业是一个国内大型家电制造企业,因其流程漫长、供应链烦琐,致使成
本较高,为降低成本,特成立一个降成本项目组,预计在现有成本基础上下降 10%,
约几个亿吧。
项目一经成立,便投入大量的人力和精力来实施,并且领导也很重视,力度也很大,
调动各部门第一负责人召开启动会、每周对执行情况汇报等,很是轰轰烈烈,起初
效果也很明显,各各部门都排查了一下以往成本和费用不合理的地方,都列出了许
多可以降成本的小项目,把明显不合理的成本很快都降了下来。
项目当初定的是要在三年之内降几个亿,一个多月就降了五六千万,效果不错。可
再往下,大家不知道该怎么干了?从那里降了,好像又变成例行工作了。领导很着
急:这样下去成本肯定下降不了 10%;各项目负责人也很着急:想干,但如何能保
证自己干的事就是项目要的事呢,我到底该干那些事呢?
项目走到这里,好像基本已经停滞,或者说离失败差不远了。根据项目管理的流程
来总结,也许你会分析出:1、目标不清晰:10%,几个亿如何去实现,怎么分解目
标;2、WBS 不明确:项目开始处就要分解好,那些可做那些不可行,如果去做等;
3、供应链成本研究不透,到底那些成本可降。这是我对项目总结的原因,但现在仔
细分析以上三点,没有哪一点是一开始就可以分析清楚的,包括项目执行到现在也
没拉出一个供应链成本的总架构。
请各位有相关经验的项目经理对此项目剖析,最重要的是希望您能给点补救措施和
建议?

第 26 页 共 756 页
第 1 章 综合管理

【相关分析】

·可行性分析(2007-12-14) [作 者] 郑海涛 [公 司] ESC LILLE FRANCE

为什么要做可行性分析?你的项目目前的进展已经说明了.
1.你们的目标很明确,-10%,这个目标是怎么制定的?在确定项目目标前,是否对项目目标做
系统全面的可行性分析,"供应链成本削减项目",直到现在你的团队对供应链成本研究不透.
2.出现问题,就应该找出好的应对方法,尽所能,用最少的资源去获得最大的效果.
3.项目的失败不等于项目没有发挥效益(毕竟以减了几千万).

·分析问题的关键(2007-11-28) [作 者] 陈罡 [公 司] 北京

1、目标是比较明确,但需要首先明确这个目标是不是确实能够达到?如果能够达到,最好先把这些
做分解。
2、既然前期的执行效果还不错,那就坚持吧,不能对前期已经取得的不错的效果所迷惑。为什么能
不知道做什么呢?根据制作的 wbs,看哪些地方和可以缩减。
3、供应链搞不懂,你就会越来越迷茫的,不知道该怎么降,无从下手。

·CVA和供应流程再造(2007-11-06) [作 者] 范兰旺 [公 司] 广东外语外贸大学

项目的目标非常的清晰,10%,好几个亿。如果可以节省这 10%(几个亿)
,那么利润就增长几个亿,
要做到这个水平看来这家企业也不小。
在研究问题所在之后,你们得出的结论是“因其流程漫长、供应链烦琐,致使成本较高”,那么,项目
一开始就应该从供应链再造的思想出发,而不是小打小闹,项目的实施没有指导性的计划文件和监控
机制。
思考:
1、目标的制定是否合理?10%或者几个亿都不是小数目,成本压缩空间真的这么大么?
2、供应链是怎么样运作的?关键的路径在哪里?对供应链的研究必须透彻,每一个环节都可以压缩
成本,但要找出关键路径,找出瓶颈才能一针见血,入木三分。
3、是供应链再造项目还是成本压缩项目的问题?当然这两者可以是一体的。但出发点不同,实施的
方法也不同。供应链再造是让供应链的成本效益最优,而成本压缩是否不影响效益是值得商榷的。
4、补救的意义思考。项目开始前就错误了,实施过程发现了,那么是否还要继续呢?不应该为了完
成而完成,项目的失败不等于项目没有发挥效益。

·流程再造(2007-10-31) [作 者] 姚朝军 [公 司] 横河公司

根据所述情况,本人认为:首先应该从你们单位的供应链流程着手,分析哪些环节是必须的,哪些环节是
重要的,哪些环节有漏洞.然后想方设法把流程改造一下.

也可以考虑一下是不是你们的流程中存在不负责任或腐败的情况,当然,改革是要伤害某些人的
利益的.否则,成本永远也降不下来.

第 27 页 共 756 页
第 1 章 综合管理

·认真研究流程,做好流程工作的分解(2007-10-26) [作 者] lee [公 司] 无

1、从整个供应链研究流程,分解流程项目,按照成本高低项目排序,再优先分解成本高的项目,制
定降低成本的指标和计划。
2、工作从先易后难开始,解决流程关键问题
3、做好绩效评估工作

·做个长远计划(2007-10-25) [作 者] 刘海锋 [公 司] 日本本田零部件有限公司

一.从产品的材料/设计进行分析。
二.按照 PDCA 进行对现场合理改善。
三.可以从产品的设备进行分析。
应考虑全面体制。祝你们更上一层楼

·就那样(2007-10-24) [作 者] 朱兵 [公 司] 中国核工业华兴建设有限公司

世界范围多大,就有多大范围的降低成本的呼声,大家心理也都明白是怎么回事,那实施怎么就那么困
难呢.
各个公司都把降成本的事情挂在嘴边,成本的节约是靠时间来考验的,短暂的成本降低不能是整个公
司发展的规划,循序渐进的发展才是重要的.

·重新整合供应链(2007-10-23) [作 者] Andy.chen [公 司] 广州工博

单独的降成本没有任何意义,相信大家都明白成本与其它的服务具很大有关联,针对供应链的成本,其
实有很大一块可以从内部入手,从设计及工艺实现\库存管理\生产计划与物流全部都有文章可做,仅
仅向供应商要成本太不现实

·如何去分解(2007-10-20) [作 者] 刘庆涛 [公 司] 辽宁电力有限公司第二工程公司

1.产品生命周期角度去分解.
2.财务费用科目角度去分解.
结合以上两者做一下目标分解与 WBS 分解.

·一个供应链降成本的项目(2007-10-20) [作 者] 刘庆涛 [公 司] 辽宁电力有限公司第二工程


公司

对于国有企业,有很多不透明的东西,首先老总要有全力以赴变革的决心,成本降低是一个漫长的过

第 28 页 共 756 页
第 1 章 综合管理

程,这是必备的条件.如果具备了此条件,所做的变革成本之路才能进行下去.
1.首先要进行成本分解,成本分解的 WBS 结构.要搞清楚所有的成本都发生在哪些事项上,每一事项上
的成本是多少,也许有些工艺无法分解,可以有一个大概的数据.
2.与同行业去横向比较,找出本公司哪些环节成本高,哪些成本低,找出成本优势与劣势.从原材料采
购到加工制作与销售每一个环节都不能放过.找出劣势所在,是工艺效率低还是管效率低.是否可以考
虑把自己劣势外委加工.走专业化道路,做自己擅长的事情.

·考察市场,落实计划(2007-10-19) [作 者] 连甲虎 [公 司] 力帆汽车

降低成本是企业长挂在嘴边的问题。需要考虑几点问题:
1.哪些流程可以省略,那些可以简化。
2.通过市场考察,与相关行业比较制定符合实际的降成本计划。
3.制定降成本的近期计划和长远目标,把复杂的问题分阶段解决并对工作作出总结。

·供应链降成本工作是一个持续执行的过程,而不是短期行为(2007-10-19) [作 者] 王平 [公
司] BBK

目前,随着市场竞争的加剧,几乎各个公司都把降成本的事情挂在嘴边;但是现实的情况是,很少有
可持续执行的方法和步骤。

·项目目标一定要务实(2007-10-18) [作 者] 王金龙 [公 司] 廊坊市华夏房地产开发有限公司

首先应该分析成本降低 10%是否有根据,是跟社会平均成本相比还是高于这个标准。对于制造业来说,
盲目的通过降低成本来追求利润是不合适的,在如今这个竞争日益激烈的社会,应该从价值工程的角
度分析产品可以从那些方面降低投入;此外降低成本的初级阶段可能就是贵公司项目组开始做的事
情,降低成本就是杜绝浪费,提高劳动生产率,减少不必要的流程,当然这种工作在单前的技术水平
以及管理水平下也很会达到极限,所以在一段工作之后会觉得步履维艰,做这种工作利用项目管理的
基本方法 wbs(工作分解结构)以及流程图、鱼骨图等方法进行更加精细的分析是必不可少的。

·劳动分工加细(2007-10-18) [作 者] 李继波 [公 司] 学生

首先先把劳动分工加细,然后就能看出薄弱环节,提高员工的劳动技能
然后下达各部门每星期降低成本 1%,这样的要求一般感觉不高,做下来也没压力

·项目的实施需要计划(2007-10-17) [作 者] 赵永强 [公 司] Johnson Controls

第 29 页 共 756 页
第 1 章 综合管理

目前降的几千万是一些不合理的问题解决,所以感觉一下子出了很大的成就.
实际在刚开始作项目时,应该有一个分析(包括头脑风暴),哪些完全可以拿掉,哪些可以部分降,哪些
可以通过改变运作模式的方式降低.....再做项目时,10%是一个目标,一个 target,如何实现需要系
统的分析与协作.同时也可以把一个项目分解为几个子项目.在调研分析的基础上进行细化.

·重新审视项目(2007-10-16) [作 者] 飞翔 [公 司] 辽宁

首先该项目的前期计划工作没有完全的到位,给后续工作留下了隐患。需要更多专业项目管理人员加
入项目,也可咨询相关专家提出改正建议。
其次重新审视整个项目过程,用一些方法去发现问题,如头脑风暴,咨询专家等。
要有信心!!加油!祝顺利!~~

·目标分解,计划双份。(2007-10-16) [作 者] 1d [公 司] 耐普罗(深圳)公司

目标 10%太过笼统。不妨把目标分为近期可目标和远期目标。近期的就是浅在的容易实现的,也就是
案例中已实现的那部分。远期的是不易被发现的难实现的需要各个环节(包括供应商和客户配合的)。
对每一个目标编一个具体的计划.

·一个供应链降成本的项目(2007-10-15) [作 者] pengbo [公 司] 西南交大经济管理学院

1.对于给定的 10%目标,有没有经过合理的论证呢?
2.没有一个对项目本身研究很透彻的人。
3.对于现阶段,可以请专业的资讯专家进行资讯。

·一个供应链降成本的项目(2007-10-15) [作 者] 易明 [公 司] bireturn

从你的描述来看,对于项目管理前期所存在的问题已经有比较明确的认识,归结一下瓶颈在两部分:
1、缺乏理论指导,没有合适的供应链理论能够指导你进行成本降解。可以查找一下相关的资料。
2、没有能够对整个流程存在清醒认识的人才。可以发掘一下,说不定在项目中就能找到。
3、可以运用合适的流程管理工具,我用过的是 ARIS,不过只用来描述流程,至于成本分析和调整还
没有使用过,你可以请教相关的专家。

·一个供应链降成本的项目(2007-10-15) [作 者] 朱万海 [公 司] 河海

对于此,我个人想法主要有以下几点:
1. 弄清目标的具体情况, 如是怎么得出是能够降低 10%的成本,是通过参照同行业的标准或者是经

第 30 页 共 756 页
第 1 章 综合管理

过对本企业的过去经验,资料而得出的数字,是否可行,可实现,以及需要哪些部门或者其他辅助实现?
2. 制定一个滚动波计划, 通过分阶段计划来实现目标,以及根据实际情况修改相应的实施方案(如
短,中,长计划);
3. 监视实施的结果,对比结果与计划, 找出偏差原因以及采取相应措施进行处理;
4. 切实了解供应链业务,找出相应的着眼点,如可以采用新的业务管理系统.
5. 精简机制,减少不必要的流程,并加以记录以及加以详细分析,最好能采用实际的数据来加以证实
精简后的效率.

·建立企业运作的流程是建立WBS的一种形式(2007-10-13) [作 者] daijiangbao [公 司] 深圳
市大视野企业管理顾问有限公司

在 pmbok2004 版,首次把企业的流程看成是企业的资产,这是一个很大的进步,但是没有很明确的说
明企业流程是如何来建立。
实际上,要想把企业的流程建立好,需要将企业所做的工作,从头到尾按照时间顺序的排列,划分适
当的阶段,在每个阶段涉及到不同地点的公司、部门、人员的什么人、做什么工作以及如何做、为何
做、花费的时间等一系列工作,把这些内容层层分解,自然就会得到整个工作的流程,针对每一项工
作可以知道实际的成本及应该合理的成本,这些成本的差异就是能降低的成本,这个工作没有做,降
低成本就是一个空话,也只能是浮在表面上,就一些暴露出来的问题解决一部分。
在这个工作分析过程中,就可以发现流程中很多的不合理地方,需要把流程全部都梳理清楚,把不合
理的流程加以改正,把中断的流程接起来,在这个基础上来完成降低成本的工作就有基础了。
这个降低成本的工作,关键还在于 WBS 的建立,而且一定要到一定的层次,魅力在细节,把这些工作
做扎实,降低成本就是顺理成章的事。
可以就一些问题再深入探讨。

·从流程上分析、从项目干系人利益角度分析(2007-10-13) [作 者] 卢志坚 [公 司] 上海财经


大学

该项目是供应链管理,那么首先要分析整个供应链中各个环节(从流程上看)的成本,(从技术上来
看哪些可以节省,其中会触动哪些项目干系人,从项目干系人利益看节省的可行性,其次分析当前减
下来的是哪些成本,下一步可能可以减哪些成本,最后综合分析,拿出方案,让领导进行决策。

·从流程的角度思考问题(2007-10-13) [作 者] fasiondog [公 司] N

最主要的还是你们不知道如何去做,用什么方法解决问题。首要的,就是理清流程,观察每个环节的
成本,找到最可能的地方,在着手优化。

·删除不必要的流程(2007-10-12) [作 者] Voom chao [公 司] mitsubishi elevator

第 31 页 共 756 页
第 1 章 综合管理

所说的情况在国企中普遍存在,每个部门的利益其实是不能动的,所谓的降本基本上只能称之为节约。
跟本解决方法只能理清流程,能合并的环节合并,能删除环节的删除。

·关注每个项目的流程是否合理,规范流程,降低成本(2007-10-12) [作 者] 章毅 [公 司] 银
海软件

前期你是减少了明显不合理的费用,这只是表面的成本
目前建议你调查项目的流程,从流程中去规范项目,从而降低成本,项目流程清楚了,供应成本也就
清楚了。

1.6 项目经理管理不力,技术负责人该怎么办

项目经理管理不力,技术负责人该怎么办

湖南省公路机械工
[姓 名] 唐满 [单 位] [邮 件] tangman007@163.com
程有限公司
工程设计
[所属行业] [所属主题] 项目综合管理 [发布时间] 2007-9-10
安装

【案例正文】
一个高速公路的路基项目,路线长度 10.3km,工程造价 1 个亿,合同工期 14 个月.公司
是个民营企业,此项目是公司的第一个工程项目.项目从 2006 年 10 月开始进场,2007
年 4 月正工动工,截止到 2007 年 8 月底,工期已 5 个月,完成工程产值不到 10%.
工程进度上不去,主观上项目管理不到位,领导班子管理水平不高,项目人员积极性不
强,项目管理理念不成熟.造成人浮于事,工作效率极期低下.客观上征地拆迁影响很
大,工作面一直打不开.严重影响施工组织安排.
我做为项目部的技术负责人,项目部领导班子成员,对这种情况是看在眼里,急在心里.
多次向项目经理及公司领导反映这里的情况,并汇报了建议的方案,由于我是从 2007
年 6 月才进入这个公司,而项目经理却和老板有五六年的合作基础,项目一直沿着这
个管理模式在往下走!
请教各位,像这样的项目,像我这个位置,该如何开展工作?

【相关分析】

第 32 页 共 756 页
第 1 章 综合管理

·加强公司管理,规范开发流程(2008-08-06) [作 者] 谭剑 [公 司] 中华商务网

既然你已经提了合理化建议,上层不采取。你还可以多推荐一些其他项目案例给项目经理看。从其他
案例阐述你的观点,而不要直接针对现有项目的情况,你说多了,也许项目经理会醒悟。如果项目经
理执迷不悟,你要保持自己的职业操守,本着为人民服务的思想,将问题越级上报。

·从上层建筑出发(2008-05-19) [作 者] 苏志敏 [公 司] 株洲南车时代电气股份有限公司

首先要做好与领导的沟通,除非你不想在这做了

·培养你自己的贵人,就当做给天下人看(2008-03-18) [作 者] 四季风 [公 司] 兴库建设投资有限公司

假如你在爬山,项目经理是走在你前面的人,其他人是走在你后面的人.
这时的项目经理因种种原因累了,下面的人也没劲了,你离开合适吗,这不是你绝妙的表现机会吗?
我想,推推、扶扶你前面的项目经理,拉拉你后面的项目成员,是应该的,如果他们什么都做得很好,
可能你发展的机会就少些!

·做你该做的(2008-03-02) [作 者] yg20021112 [公 司] 施工单位

做你该做的,至少你的份内事该做到优秀.尽你所能为团队尽心尽力.
工程进度的拖拉可能有更多深层原因,不要仅仅看到表象.

·认真分析后,给项目经理或老板一个实在的建议(2007-11-20) [作 者] 李邦武 [公 司] 保密

我一直从事公路行业的施工管理,也当了几个高速公路的项目经理,对于工作分工,项目技术负责人
应该主管技术工作,项目的具体实施都是由项目经理负责组织实施,但在项目部例会上可以提出自己
对项目管理的看法或作法,供大家讨论。我相信一个当了五年项目经理的人不可能不采用好的建议或
办法。从总体上来看,项目部没有在项目开始之前制定详细的、可操作的施工组织计划,没有充分调
查清楚项目的相关难处,没有发挥纵横协调作用,引起项目严重拖后,作为老板,项目管理成本也要
考虑的,如果人为的延期势必造成管理费用的增加和以后赶进度增加人力、物力等产生的费用,否则,
一旦延期交付则业主会按合同进行罚款,老板会亏得很惨。建议作一份成本对比分析计划,供项目经
理或老板参考。

·技术负责人努力!(2007-11-15) [作 者] 翟磊 [公 司] 中铁四局五公司

从你所介绍的情况来看,你还是一个比较努力的人,希望不管结果如何,对于你的是走是留,先别过早
定论!我觉得项目如果做成这样也不是无可挽回,如果老板能真正重视起来这个项目,重视到像你这样
的一批人存在,重视他前期所做的努力和最初的期望,重新组织施工,还是有说不定的结果的.
建议 1.技术人员继续努力,在做好本职工作的同时,扩大自己的影响力,在力所能及的范围内去感染
领导和同事,使大家共同努力为这么一个关系他们直接利益的项目而振作 2.把以前的工作失误好好
总结,重新选定有能力的人员来组织施工 3.打理好各方面的关系,营造一个真正适合项目的氛围,真

第 33 页 共 756 页
第 1 章 综合管理

的还是这样没什么变化,老天也帮不了谁了.
以上仅作为本人观点,思路零乱,请多指教!

·内外分析(2007-10-24) [作 者] 姜先生 [公 司] 新华信

看到你的职位是技术负责人。那么你的主要责任就是要集中在技术层面,建议对于项目本身主要集中
在职务内,而对于项目管理方面实施建议权。
至于项目现况,可以弄清楚以下事实再考虑下一步如何走。
1.行业内类似项目管理情况如何,工程延期是不是经常的事情,一般都如何处理?
2、考虑利益相关方的关系。公司存在首先是以营利为目的,这是老板和项目经理必须考虑的(否则
就不需要项目的实施了);看看这个项目中老板的期望是什么?客户要求是什么?等等
3、资源情况
4、最为重要的:自己希望能够在项目中获得什么?

·直接跳巢(2007-10-24) [作 者] 兵兵 [公 司] 学校

这种事我觉得吧-本人为参加工作只是在学校的作为。你是说啥都没用你一个新人,我惹不起还躲不
起吗?而且跟那样的公司干也没用,浪费时间 。

·关键是沟通,了解背景,才有发言权。(2007-10-22) [作 者] 许肃 [公 司] 珉泰克(苏州)
国际公司

首先,关键是要和当事人-项目经理正面沟通,征求他的意见。在没有了解当事人的意见之前,自己
的看法有时是片面的。许多当时人(主管人员)都有许多不为人知的难处(有些也许还是老板的原因);
多听多了解背景,才有发言权。

其次,在了解背景以后,再根据情况,如果对方真心希望获得帮助,你就可以发表一些自己的见解。
最好有针对性,有可行性,而且不要以批评的口吻。

最后,要成为核心队员。这样对重要事件就有参与权,话语权,乃至决定权。

祝你好运。

·亂世出英雄(2007-10-12) [作 者] 小天 [公 司] 无

當然,這種管理是比較落後的,但是,這樣才可以體現出你個人的能力啊,戰勝這種局面,當亂世中的英
雄!!!!

第 34 页 共 756 页
第 1 章 综合管理

·管理自我,挑战项目(2007-10-10) [作 者] pulison [公 司] 上海

很高兴,能听到这样的项目技术负责人对自身项目的发展有这么负责的态度,项目的成功与否离不开
一个项目的群体,当然也需要项目经理的管理决策能力。
上面的几位都给出了各自不同的观点,也各有见地。下面只是我对该项目的分析。
项目管理不到位的原因不知道有没有考虑过?可能有如下原因:
第一:沿用以前的管理经验(经验过时),对新项目没有新的认识;
第二:项目经理不敢创新,怕变会失败,导致责任难以承担,任由事态按原来的管理模式发展;
第三:项目经理自身没有能力去变,他根本不知道如何去管理高速公路路基项目,不是他不变,是他
不知道怎么变。
以上原因可能都有之,所以沿用以前的管理模式,对于项目技术负责人,我想你首先要立足本职工作,
将自身的技术管理工作做好,但作为项目组成员,对项目的成败也有相应的责任,从自身的职业发展
角度也不能使项目失败,就有对项目的进展有知情权,监督权和建议权。
你的措施如下:
第一:你应和项目经理沟通,他们的真实项目,如原来的工期确定有误,他们知道但没告诉你;看项
目的
第二:你对项目应深入了解,对周围社会环境和项目组成员的状态(如工资收入、奖励措施、技术水
平等)进行了解,征地坼迁工作往往不是一个公司说了算,涉及到政府管理、资金到位、被征地对象
的合作程度,这就要客观分析,采取针对措施;
第三:内部管理,效率低下的原因你是否分析过?是项目经理的管理能力问题,还是老板的管理态度?
这涉及到用工制度的革新问题,技术人员的个人发展问题,还有就是工人的工资收入水平认可度等等。
你可以去深入了解该公司的组织结构、奖惩情况,是否能如你所提的建议方案解决,是短期的还是需
要长期的解决,这设计到一个公司的管理制度。
第四:你自身的发展问题,对于项目的发展受公司的管理制度的制约,你是否有能力来管理好该项目,
提的建议是否经过深思熟虑能够确保成功的?你如果有兴趣做项目管理的头,那你就以你自身的项目
为例,进行书面的项目管理计划,提交你们的老板,和他们深入探讨,如果认可你的观点,你可以协
助项目经理共同管理该项目,相信私人老板不会反对。

·找好平衡点(2007-10-10) [作 者] anbh [公 司] beijing

1、对这种项目,根本就不存在所谓的项目管理理念,老板和项目经理的思想是如何在减少投入,多
赚钱的情况下去完成工程。他们不会有正规的项目风险、项目费用的技术上的分析,所以以正常的项
目管理的理念去理解他们是不能够理解的。【不知对老板和项目经理的分析对不对?】我认为,首先
要分析他们到底想要做什么,尤其老板对项目的目标是什么?这样根据老板的目标对症下药。
2、进入公司已经一年了,应该说不短了。诚如 zgl 提到的,应该对最具体的问题去分析解决,而不
能只是笼统的给出问题和建议。这是领导能不能接受的关键。
3、如果应该做的都做了,项目还是如此,或者不能适应公司的目标和理念,只能提前找好下家了。

·方法总比问题多!(2007-10-06) [作 者] zgl [公 司] 浙江**置业集团

第 35 页 共 756 页
第 1 章 综合管理

“工程进度上不去,主观上项目管理不到位,领导班子管理水平不高,项目人员积极性不强,项目管理
理念不成熟.造成人浮于事,工作效率极期低下.客观上征地拆迁影响很大,工作面一直打不开.严重影
响施工组织安排.”
1、我认为我们首先要清楚的认识到:是要公司来适应你还是你去适应公司!我想大家的回答是肯定
的,是要我们去适应公司。每个公司都有他自己特色的管理体制和流程,你不管他是好的还是坏的,
如果你要在该公司发展,你就的去适应它;
2、要进行自身的角色定位,正所谓一个萝卜一个坑,每个公司或者项目部都设有相应的岗位,并明
确该岗位的工作内容、流程等,我想大家都应该明白这一点,为的就是分工明确,避免打乱战;在其
位,谋其职,忠其事!每个人所站的角度不同,处理事情会有千变万化!
3、我想你上面提到的都是一些比较笼统的问题,每个项目或多或少都会碰到一些,问题是你能否对
症下药,提出针对性的问题,并针对性的提出解决问题的方法,你是该项目的技术人,是项目管理的
核心成员,如果你提出的问题确实能够解决该项目的问题,使之加快进度,降低成本,我想,没有一
个公司会不听,因为赚的钱公司是大头,你说有那个公司不愿意多赚钱吗?
4、造成人浮于事的原因我认为也是多方面的,你作为项目的技术负责人,从上面来看,有没做到表
率作用,我前段时间看的一本书叫输赢,里面有一点我是非常认同的,讲的就是我们把过多的精力都
放在了内耗上;
5、如果你做了你应该做的事情,公司还是无动于衷,我想你就马上可以辞职了,道不同不相为谋!

·皇帝不急太监急(2007-10-05) [作 者] daijiangbao [公 司] 深圳市大视野企业管理顾问有


限公司

关你什么事?你又不是项目经理,你没有责任来这样说,失败的项目多了去了,都关你的事?
这样的项目,失败也不是项目经理的责任,自然有人承担责任,没有必要闲吃萝卜淡操心的,这种事
情不是不是你管的,也不是替换项目经理就可以的,把自己的工作做好就可以了,换了你当项目经理,
未必能比现在好,看不下去就离职了,与这件事没有任何的关系。

·建议不成就走人(续)(2007-09-28) [作 者] 杜征均 [公 司] 暂时保密

(续)对这个项目要开处方的话,首先是换项目经理,他的管理不力、安排不周导致了如今的结果;
其次是加强业务流程的管理以改变效率低下的现状;第三是加大经济激励措施以确保提高积极性和效
率;四是业余加强培训以提高管理观念;五是加强班子管理理念和管理水平的培训学习;六是加强工
作的计划性。

·建议不成就走人(2007-09-28) [作 者] 杜征均 [公 司] 暂时保密

就目前来说,这样的项目在国内相当普遍。老板取得项目是靠拉关系来的,用人也是任人为亲,重要
的位置及有实权的位置都是亲戚或心腹在把守,如你那样的位置只是有相应的经济待遇,事要由你办
但你说了不算没有决策权,造成如你一样的业务骨干员工在那里面基本上没有忠诚感。老板习惯撑不

第 36 页 共 756 页
第 1 章 综合管理

下去了就换个人来缓解一下所在项目的矛盾,从来不会从根上也就是他自己本身去解决问题,管理毫
无有效性可言(主要靠个人责任心和与管事的人之间的面子和关系)。他们以为换一个有能力的你应
能起死回生,但不会去碰实质性的问题,即使是明摆着的问题。他们宁愿花许多冤枉钱去疏通关系,
让业主认可他的滥工程也不会花大力气去提高自己的能力和水平,他们有一种定向思维就是工程和生
存凭的是关系而不主要靠能力,这也是这种企业最终会穷途末路的原因。
基于你所在的企业的状况,建议你先书面向老板和项目经理建议,建议不成就走人。建议的动因是对
老板和项目经理抱一线希望,希望他们能够重视问题、解决问题,确保项目成功;建议不成就走人是
说的结果:如果他们根本就不听建议,那么你对这个公司只剩下绝望了——一个没有管理效力的单位
下项目成功率较低的工程只能让你绝望,你的付出甚至唤不起他们的觉醒。
对这个项目要开处方的话,首先是换项目经理,他的管理不力、安排不周(如没有考虑好征地拆迁而)
导致了如今的结果;其次

·就事论事(2007-09-26) [作 者] fasiondog [公 司] fasiondog

“工程进度上不去,主观上项目管理不到位,领导班子管理水平不高,项目人员积极性不强,项目管理
理念不成熟.造成人浮于事,工作效率极期低下.客观上征地拆迁影响很大,工作面一直打不开.严重影
响施工组织安排.” 如果问题是这样被表述提交到领导哪里,估计是谁也不会处理,反而会把你开了,
要针对具体事件找到原因并给出方案,任何事情从技术的角度给出为什么存在问题,如何解决,不要
归结到“管理、人”上,如果问题的原因落到“管理、人”就是没有找到问题的根本原因,也是不可
信赖的。

·战胜自己,提高自己(2007-09-17) [作 者] 唐满 [公 司] 秘密

我很赞同史兄的观点,也曾想过跳槽。
但是仔细想想:又有哪个项目能够一帆风顺?
又有哪个项目在实施过程中没有困难?
如果能够将这些困难一一克服那么对自身也是一个很好的锻炼。

·辞职吧(2007-09-13) [作 者] 史鹏飞 [公 司] 保密

没啥好说的,无力回天.当然在一个公司里,就得以公司的形象和信誉为重.不过自己的形象和信誉
一样重要.
主观客观条件上,我个人觉得我是做不到,我也不想让自己在复杂化的情况下受拖累.对公司,对自
己都是个交待.希望公司能够请到合适的人.
况且.你并非项目经理.也没有自主权.技术负责人.恐怕对于公司来说,就是一个高级工人.
再一点,项目是否如期完工,要看和公司战略发展有相关利益联系.
如果拖是好事的话,为什么和尚不急道士急呢,
难得糊涂嘛.如果你真想做出成绩,在专业技术领域内做出成绩,还是换个地方吧.

第 37 页 共 756 页
第 1 章 综合管理

1.7 三只老鼠折射企业的绩效管理问题

三只老鼠折射企业的绩效管理问题

[姓 名] 廖华清 [单 位] 科健 [邮 件] kinssenger@163.com
[所属行业] 通信与网络 [所属主题] 项目综合管理 [发布时间] 2007-5-14

【案例正文】
三只老鼠一起去偷油喝。找到了一个油瓶,三只老鼠商量,一只踩着一只的肩膀,
轮流上去喝油。于是三只老鼠开始叠罗汉,当最后一只老鼠刚刚爬到另外两只的肩
膀上,不知道什么原因,油瓶倒了,最后,惊动了人,三只老鼠逃跑了。回到老鼠
窝,大家开会讨论失败的原因。最上面的老鼠说,我没有喝到油,推倒了油瓶是因
为下面第二只老鼠抖动了一下,所以我推倒了油瓶,第二只老鼠说,我抖了一下,
但我感觉到第三只老鼠也抽搐了一下,我才抖动了一下。第三只老鼠说:“对,对,
我因为听见门外有猫的叫声,所以抖了一下。

“哦,原来如此呀!”

企业里很多人也具有老鼠的心态。请听一次企业的季度会议:营销部门的经理 A
说:“最近销售做的不好,我们有一定责任,但是最主要的责任不在我们,竞争对手
纷纷推出新产品,比我们的产品好,所以我们很不好做,研发部门要认真总结。” 研
发部门经理 B 说:“我们最近推出的新产品是少,但是我们也有困难呀,我们的预
算很少,就是少的可怜的预算,也被财务削减了!“ 财务经理 C 说:“是,我是削减
了你的预算,但是你要知道,公司的成本在上升,我们当然没有多少钱。“ 这时,
采购经理 D 跳起来:“我们的采购成本是上升了 10%,为什么,你们知道吗?俄罗
斯的一个生产铬的矿山爆炸了,导致不锈钢价格上升。”

A、B、C:“哦,原来如此呀,这样说,我们大家都没有多少责任了,哈哈哈哈!”

人力资源经理 F 说:“这样说来,我只好去考核俄罗斯的矿山了!!”

面对这种情况,大家有什么好的解决方案吗?

【相关分析】

·风险管理和团队每个员工的责任心(2008-02-19) [作 者] 王晋桃 [公 司] 杭州市房产信息中心

第 38 页 共 756 页
第 1 章 综合管理

我觉得案例之所以失败反映了两个方面的问题:
一、风险管理不足
项目过程中需要将各种可能的风险事件以及概率估计出来,找好应对办法
二、项目的成功需要每个参与人员的努力
在项目实施之前需要激励每个参与人员全力参与其中,保证每个参与人员全心全力做好份内的工作。

·反驳绩效管理的盲点(2007-09-23) [作 者] 宋五哥 [公 司] 青岛软件

感觉各位分析都不错,可惜遗漏了一点。
案例的代表如下:
油是利润,是奖金分红; 第一只老鼠做最重要的,最容易产生绩效,享受分红. 如果油水不多,第一只
老鼠喝多了,以后就没油吃.
但是,第二只老鼠,第三只老鼠没油喝. 没有奖金,也没有激情,当然不在意第一只能不能喝到油.
如果有点油水给第三只老鼠,它会更认真,区分是真的猫叫,还是假的,猫有没有过来的意思,团队也
不容易垮.
==============================================
你说的好像乱七八糟的。你的观点跟绩效有关吗?
最下面的老鼠正是刚才的第一只

·职业信条(2007-09-10) [作 者] 刘志立 [公 司] 安徽华恒建设工程项目管理公司

我为团队服务,并分担团队的成败责任。坚持最高品德标准是没个人的职责。个人成败操之在我,我
必须从经验中不断学习。

·从管理的角度解决经营中存在的问题(2007-09-04) [作 者] 李志红 [公 司] 天津临港斯多而特码头有


限公司

公司应该有个总经理或管理层统筹把握,其职责就是解决管理中存在的问题,根据所遇到的问题,采
取相应的对策。

·人的思维多元可以避免管理危机(2007-09-03) [作 者] 牧洋女 [公 司] 中交三航局

难道这个企业每一个环节都要在一棵树上吊死吗?我看人力资源经理应该好好检讨一下企业每个环
节的用人问题.正如一个企业需要多元发展一样--产品是多元,客户是多元,资金是多元的,材料
供应是多元的,服务是多元的......企业管理人才的思维更应该是多元的,因为这不仅可以决定整个企业
的多元经营发展,而且可以使企业工作方法是多元的,解决危机渠道是多元的,在每一个管理环节上都
有多元的应对策略,否则任何一个环节出现问题都会造成整个管理链的破碎.

·提点小看法(2007-08-26) [作 者] lwghui [公 司] sddsasdadsadsa

第 39 页 共 756 页
第 1 章 综合管理

案例反映出公司在项目横向管理方面比较薄弱,本位主义比较严重,当然这比较普遍。一般而言各个
部门的工作相对独立,彼此信息缺乏有效的沟通。当然最后项目失败这也不全是项目经理的责任。项
目一般都有特殊性,但原则上需要多个部门协同作战,矩阵管理非常必要,项目经理要做好与职能部
门经理的沟通工作。这样追究责任时各找借口,互相推诿的情况就能尽量避免发生。

·也说两句(2007-08-26) [作 者] lwghui [公 司] sddsasdadsadsa

案例反映出公司在项目横向管理方面比较薄弱,本位主义比较严重,当然这比较普遍。一般而言各个
部门的工作相对独立,彼此信息缺乏有效的沟通。当然最后项目失败这也不全是项目经理的责任。项
目一般都有特殊性,但原则上需要多个部门协同作战,矩阵管理非常必要,项目经理要做好与职能部
门经理的沟通工作。这样追究责任时各找借口,互相推诿的情况就能尽量避免发生。

·工作协作与工作利益之间的关系(2007-07-20) [作 者] 邢利 [公 司] 大江东阳塑料制品有限
公司

还是歌里唱的好:团结就是力量
不知大家喜欢看动物世界节目中----狮子捕杀水牛
一、从表面上看:一群狮子通过追逐将一头水牛从水牛群中隔离出来,然后你抓一爪子、我咬一口、
他爬到水牛背上,最后将水牛杀死。情景非常血腥和壮观。
二、从内部看:是狮子集体协作、责任明确。开始大家分布在事先预订好的位置,确定目标,只要领
头的狮子一起动,大家都从各个方向朝着目标飞扑过去,将目标围住。然后大家从各个方向骚扰水牛,
等水牛的体力消耗的差不多时,一只负责爬到水牛背上,将水牛压倒。另一只负责咬住水牛的脖子,
杀死水牛,其他的就负责从各个位置压住水牛,不让水牛起身,最后将水牛杀死。其中只要有一个环
节出错,结果就是让水牛逃跑。

一个项目也是如此,每个部门即时独立的,部门与部门之间又是协作的,才可以完成项目。
总结:
有了协作不一定能够完成,但是没有了协作就一定完不成。

·三只老鼠折射企业的绩效管理问题 (2007-07-17) [作 者] yanlinggang [公 司] 广东佛山奥


园集团

没有那么深奥,很简单的管理问题,却搞的那么复杂了啊。案例中的老鼠不是解决问题,不是去发现
问题的解决,是在逃避问题,问题怎么能解决,这样的结果个个都成了硕鼠,会有鼠患的。至于问题
的内外都在其次,队伍团队建设,一开始项目相关人就要有一致的项目理解。

·绩效考核体制对项目执行团队的影响(2007-07-09) [作 者] 孙铁军 [公 司] 中信公司

第 40 页 共 756 页
第 1 章 综合管理

我较同意向健京的看法。
无论做为一个企业的远景战略发展,抑或是一个无论大小的项目执行过程,在工作目标明确之后,首
要的工作便是为实现这样的目标建立一个肯为之奋斗和贡献的团队。进来讲究贡献逐渐被现实主义淡
化,但一个团队的拼搏奋斗精神是实现项目目标的关键。
在此基础上,构建一套合理的绩效考核机制是对工作团队考评、激励、奖惩,特别是在实现目标过程
中防止出现目标偏离的重要管理手段,也是出现重大责任事故后分析原因、纠偏以及进一步预防后续
可能发生的类似风险的重要办法。同时,团队的领导人在此过程中也会起到至关重要的作用。
在老鼠案例中,三只充满激情的小老鼠构建了一个临时的团队,在实现有福同享有油吃的过程中,由
于各执一词,虽然之前也是分工明确,但由于下面两个基层工作的老鼠没有完成其该实现的功能,最
终导致有福共享有油吃的目标没有实现,而且还造成了内部出现了潜在的不信任危机。同时在这个小
团队中,缺少一个强力的领导,在出现问题时树倒猢狲散就不可避免。
在企业案例中,几个有明确职责接口和分工的部门,在实现销售指标的过程中也出现了类似老鼠偷油
的现象,这在企业管理中是经常发生的事情。时刻明确各自的职责、加强过程中的管理和监控、给予
团队的领导者充分必要

·绩效管理中的盲点(2007-07-01) [作 者] albertsu [公 司] 大众电脑苏州

感觉各位分析都不错,可惜遗漏了一点。
案例的代表如下:
油是利润,是奖金分红; 第一只老鼠做最重要的,最容易产生绩效,享受分红. 如果油水不
多,第一只老鼠喝多了,以后就没油吃.
但是,第二只老鼠,第三只老鼠没油喝. 没有奖金,也没有激情,当然不在意第一只能不能
喝到油.
如果有点油水给第三只老鼠,它会更认真,区分是真的猫叫,还是假的,猫有没有过来的意
思,团队也不容易垮.

·三只老鼠折射企业的绩效管理问题(2007-06-15) [作 者] 天风 [公 司] 北京建筑装饰公司

谁先动的,为什么而动?
就像多米诺骨牌,一个推一个。互相推诿。这不是偶然。

我觉得从具体哪个部门来分析就题论题不是办法,解决不了根本问题,这不是某一个
部门的问题,应该从大处着眼。
总的来说还是管理问题和机制问题。

·绩效管理不是追究责任,而是为了促进工作的完成(2007-06-08) [作 者] 倪东生 [公 司] 北
京中海纪元公司

第 41 页 共 756 页
第 1 章 综合管理

事情发生了,要分析原因,从中找出规避办法来,首先是项目经理的责任,没能识别风险,
做好风险规避,预先想到有可能猫会来,那怎么确认猫来了,确认了,怎么做等等,如果
做不到这一点,是项目经理能力不够,可以考虑通过培训等手段提高他的能力,或者帮助
他们进行风险识别,事后总结应该首先找出不足的地方,然后考虑以后再发生同样问题怎
么应对,过多考虑的应该是应对的很成功,怎么表彰,而不是应对失败怎么惩罚。

·fsadfasdf(2007-06-08) [作 者] 松 [公 司] 天啊

tajdslfkjasd;lkfjalskdfasdfjlk;as;dlfk a;dlfkjasl;kdfj al;dkjf;laskdf


ajskldfj;laskjdflkasjldfkjaslkfjwoiroiurfajkf;oiajfklajlkdfjlaskdflakwrpoirpoawi

·因该是个风险管理的认同问题(2007-06-08) [作 者] 苗小真 [公 司] 包头职业技术学院

个人感觉这因该是个风险管理的问题,三个老鼠既然决定去偷油,就必然存在风险,企业
也是一样,在大的市场中也必然存在众多的风险。风险是个双刃剑,风险高回报也高,这
是早已为人们所认识的,想得到多高会报久的承受多大的风险,这是必然的,故事中的老
鼠在开始的时候,只想到回报而忽略了对风险的认同,也就是为了得到那瓶油你愿意承担
的最大风险极限(可接受性)是多少,只有在风险可接受的程度达成一致得前提下,采取
行动才可能达到步调一致,而不至于时候产生推诿扯皮现象,回到故事中,如果最低下的
那只老鼠判断猫的声音很大,可能会带来生命危险,及时撤出,因该说是为了减少更大的
损失,相反如果猫的声音很远,万群可以不必管它。但在实际实践中,这个风险判断因该
是再协商达成的。
个人并不觉得惩罚是做好的办法,惩罚是一种手段,并不是做好事情的关键。试想这次惩
罚之后又遇到什么意外的时候,每个人首相想到的更会使如何免责。

管理权限,是解决这样问题的较为有效的手段,也是一个项目执行团队的基本管理手段。

·绩效考核给我们带来了什么?它应该给我们带来什么?(2007-06-07) [作 者] 向健京 [公
司] 北京世博伟业房地产开发有限公司

看到这个案例,我想到了我所经历的和我所看到的很多事情。在此也算是有感而发了。我们还是先看
看那三只可怜的小老鼠吧。
三只老鼠为了喝到放在高处的油,采用了叠罗汉的方法,为了让三只老鼠都喝到油,又采用了轮流叠
罗汉的方法,前两次叠罗汉喝油都成功了,但到了第三次失败了,原因是一声猫叫。这是一个项目失
败的案例,但更为失败且带有普遍意义的是后面的情节。三只老鼠头脑中不断闪烁着老爸那严厉的面
容,于是哥三个开始找原因,当然是能避免老爸臭骂的原因,于是就让那该死的猫承担全部责任吧。
这样,除了加深了老鼠家族和猫的仇恨外,对三只老鼠可以说是最好的结果了,虽然第三只老鼠没有
喝到油,但是也总比让老爸羞辱一番,外加今后不许参加如此有油水的活动强多了。
逃避责任是每个人的天性,没有多少人会愿意主动承担责任,况且有些事情的确不是不想做好,而是
没做好。我们先看看这个项目的启动过程。

第 42 页 共 756 页
第 1 章 综合管理

三只老鼠恐怕都是头一次进行这种活动,所以,在计划过程中没有能够很好的预见到,在活动的过程
中会出现猫这种情况,项目管理中叫风险。就这样一个意外事件(在三只老鼠看来)造成了项目的失
败(虽然不是完败)。其实,在组成这个行动小组时就出问题了,老鼠爸爸为什么不给他们委派一个
经验丰富的老鼠作老师呢?对于三个初出茅庐的小家伙你指望他无懈可击,那简直就是天方夜谭。所
以,项目的失败首先是老鼠老爸在人员安排上出了问题。
另外,我们大家都知道,项目处在一个比它本身大得多的环境之中,而项目管理只是项目成功的一个
必要条件,而非充分条件,也就是说项目管理可以提高项目的成功的概率,但并不能保证项目成功。
即使是一个有经验的项目经理,编制了很完善的项目计划,也同样不能保证项目的绝对成功。既然如
此,我们首先应该对项目失败有个正确的认识,作为领导,不应该项目一失败就马上想揪出几个坏蛋
来警告员工。这也是我们目前绩效考的问题所在。目前的绩效考核让人觉得是在揪坏蛋,而不是避免
错误发生。
以前曾在《参考消息》上看到过一篇文章,题目是《绩效考核搞垮了索尼》,文章是原索尼公司的一
名高管写的。文中写道,在索尼公司成长的初期,大家凭着一股激情和热忱,跟随着企业领袖,一同
将索尼公司推到了世界的顶峰。2000 年前后,公司引入了美国的精细化管理,绩效考核开始在公司
内推广,本想借此提高公司的工作效率,没想到,工作效率下降,矛盾增多,更为可怕的是大家没有
了激情,没有了与企业同生死,并以自己是索尼的员工而自豪的精神。索尼公司也在绩效考核的过程
中慢慢的离开了顶级公司宝座。
从以上的描述我们看到了绩效考核的另一面。目前,绩效考核成了大多数公司用以约束员工的一种工
具,领导用绩效考核结果来判断员工的工作状态,给与员工奖励和惩罚,员工为了避免惩罚,在绩效
考指标的制定上不断的注水,于是大家开始玩起了猫捉老鼠的游戏,企业也就在这种游戏中慢慢的消
耗掉。在上述文章中,曾经提到索尼公司的员工故意放宽工作指标,而作为员工的领导,在向上级汇
报时,再度放宽,就这样最终一个毫无进取精神的指标诞生了。即使是这样一个指标,大家也都因为
进取心的问题,而可能不会实现,否则,下一次的指标恐怕就不会这么保守了。
其实,这个案例的背后隐藏着目前的一个普遍问题,绩效考核到底给我们带来了什么?他应该给我们
带来什么?我们是需要激情,还是需要约束?我们的员工都是不能信任的吗?我们就那么恐惧失败
吗?
以上仅为个人的看法,但本人的亲身经历,使我对当前的绩效考核的目的和作用表示怀疑。

·三只老鼠折射企业的绩效管理问题(2007-06-06) [作 者] 王春宇 [公 司] 北京东方国信

首先,三只老鼠和企业问题存在以下的共同点:
第一. 在外因作用下引发内因。外因老鼠和油瓶以外的因素,也就是第三只老鼠所说的猫叫。和公
司成本提高的外部因素。
第二. 外因作用下产生的连锁反应。老鼠之间的不协调导致偷油失败和企业部门之间的合作出现偏
差导致的市场业绩下滑。
第三. 问题产生后的检讨推卸。都不承认主要责任在自己。

我们都明白,老鼠听见猫叫就发抖是一种条件反射,是本能。那么由于第三只老鼠的发抖导致第二只
老鼠的抖动就很正常了,第二只老鼠的抖动也是一种条件反射,是本能。第一只老鼠由于把自己的平
衡建立在第二只老鼠和第三只老鼠身上,那么它推倒油瓶也就不奇怪了。这样分析的话,整个过程实

第 43 页 共 756 页
第 1 章 综合管理

际上不涉及到其他方面,完全是因为条件反射,或者说是本能导致的。
而对一个企业来说,市场波动导致公司内部波动是一种本能,类似于老鼠的条件反射,可是作为企业
来讲,市场波动造成的影响是可以通过人为控制减小或者避免的。如何让各个部门之间独立和统一,
其实是企业需要研讨的问题,其次才是追究为什么市场波动造成公司利益下滑。
实际上,营销部、研发部、财务部、采购部四个部门之间所说的都是本能调节的问题,类似于老鼠。
可是我们还要想到一点,究竟是谁下达了命令,让财务部缩减了研发部的经费?这一系列连锁反应其
实都是由决策者造成的。也许有人会说,作为公司员工,应该在各种困境下努力拼搏,为公司做出贡
献。然而,能在困境中做出成绩的人太少了,大部分人都是按部就班的努力工作着。这就好比给你十
元钱,你能买十根雪糕,可是我现在给你五块钱,你买不来十根雪糕一样。
中国有句古话,叫“巧妇难为无米之炊”。销售部门因为没有给更多的新产品而导致市场下滑,似乎
有情可原了。研发部门因为经费不足而缩减了研发数量,也有话可说,财务部门因为采购成本增加而
减少了研发经费更在情理之中,采购部因为市场变化不得不提高成本没有错误。那错在哪里?
企业和员工之间经常这样对话:企业能给员工什么?员工能给企业做什么?问题是对立的。如何达到
一个平衡点,让企业利益最大化,让员工利益最大化,非常重要。很多企业都想用最少的投入获得最
大的产出,可是没有多少人是傻瓜,白干活不拿钱的人几乎没有。同样,也没有免费的午餐,不干活
白拿钱的工作也找不到。这个社会是功利的社会,想让各个部门利益最大化,需要的是利益平衡点,
需要的是决策者的领导艺术。

如果猫叫的时候,老鼠可以听而不闻,如果市场变化的时候,决策者可以选择最佳方案,那么所谓的
问题都会得到解决。

这个老鼠和公司绩效的问题,或许在很大程度上并没有关联。交流也好,沟通也罢,老鼠在任何时候
都是害怕猫的。
当然,这是我的理解,没有这方面的经验,所以观点可能是错的,既然作为讨论者,也算是从反方向
提出一些思路吧。

·主观因素找原因(2007-06-05) [作 者] 谈笑 [公 司] 上海环球

案例中推诿的内容都是客观原因。一件事的成功,不能单靠客观原因,主观因素应该占大比例。
我认为,出现状况受想象的不应该是推脱责任,而是从自身出发,想一想自己的责任。正如前边前辈
所说“新产品的研发和资金投入也未必成正比关系,一个泉思文涌的诗人就算喝酒也能写出好诗,而
一个莽汉天天大鱼大肉也未必想到什么”。所以,主观的问题解决了,客观的问题也就迎刃而解了。

·从不同的角度,有不同的原因(2007-06-04) [作 者] 李江博 [公 司] 华东师范大学

我和群里一些朋友交流了一下,大家达成了这样一个共识,这个是典型的责任推诿,并且预警机制做
的不好,团队的配合也没有达到默契的程度。“其实这个事情是不可能完全避免的,主要还是应该加
强应急机制,有时这个问题的出现是很偶然的,关键是看谁反应的快”群里朋友的原话。呵呵,第一次
评论,不到之处请大家指正!

第 44 页 共 756 页
第 1 章 综合管理

·责任要明确(2007-05-18) [作 者] 张华 [公 司] 中国石化宁波工程有限公司

三只老鼠相互推诿的原因在于他们之间的关系是联系非常紧密,相互之间无法形成的独立的责任标
准,因此,一旦有事,很容易就推诿到别的单位或者部门。
绩效的管理考核应该尽量量化并且要责任要明确,减少或者清晰各相关部门或者人员的责任界面。

·以动制动(2007-05-17) [作 者] xin [公 司] 湖南

市场瞬息万变,企业不管是面对内部竞争还是外部环境的变化都需要有未雨绸缪的准备,当产生问题
时我们应该合理应对,而不是互相推卸责任,大家应该互相信任体谅才是正确的做法.
市场销售出了问题,跟新产品的研发有一定的联系,但是如何在不利条件下保持企业正常运作在问题
之前是否考虑到?
另一方面,新产品的研发和资金投入也未必成正比关系,一个泉思文涌的诗人就算喝酒也能写出好诗,
而一个莽汉天天大鱼大肉也未必想到什么,所以研发应该更加注重人才的培养.
财务部方面应该要有所预算,根据对公司实际情况的分析来合理运作,这样在出现财务危机时应对自
如.
采购部应该掌握最新的原料信息,与供应商建立长久的合作计划,同时发掘新的合作伙伴.
另外我认为企业对于部门应该多予以奖励,不要只看见老鼠没喝到油,而忘记了第三只老鼠也许救了
三只老鼠的命.增加各部门的交流,也许下次第二只老鼠会告诉第三只老鼠:有我在上面盯着,你就不
用害怕了,这样第一只老鼠喝油,第二只老鼠把风,第三只老鼠全心支撑,何患无油?

·消息不等于信息(2007-05-17) [作 者] ForestLin [公 司] CATTSoft

任务失败无论何种主观解释都不能原谅,一定要对相关责任人进行处罚。

通过这个案例,能看出每个单元都把与自己相关单元的简单消息(或者信号)当成对自己有直接关联
的信息,体现出各单元没有有效的交流渠道,同时在这之上的层面也没有一个情报部门对所有与之相
关的消息收集、整理、分析、评估、使用的过程;最终导致了以讹传讹,一点点的不利消息夸大为影
响成败的关键因素。

作为公司,应该建立完整有效的情报体系,并给各部门间提供通常的沟通渠道,即使分享信息,对避
免类似失败应该会有帮助。

·三只老鼠折射企业的绩效管理问题(2007-05-15) [作 者] 林立 [公 司] 华创(北京)科技有
限公司

这个案例反映了一个项目管理中项目立项和计划的两个重要方面,首先,项目经理在项目计划时就没
有明确各项目成员的责任,这是造成最后相互推诿责任的主要原因。另外,项目经理在项目立项时对

第 45 页 共 756 页
第 1 章 综合管理

风险评估的不足也会导致项目无法正常完成。

·加强项目中的横向管理(2007-05-15) [作 者] dannyxia [公 司] 深圳

看完案例,第一个想到的就是项目横向的管理比较弱,也就是各部门的工作相对都很独立,彼此信息
不公开,缺乏有效的沟通。项目经理没有采取措施把各部门工作串连起来。所以到最后项目失败,追
究责任的时候就都开始找借口,互相推诿。当项目比较复杂,需要多个部门协同作战时,矩阵管理是
必要的,同时项目经理要做好与职能部门经理的沟通工作。

·三只老鼠折射企业的绩效管理问题(2007-05-15) [作 者] liuhongbin [公 司] seasun

问题的实质是相互的推委,例如销售的问题的主要原因是没有新的产品吗?开发的原因是单纯的没有
资金吗?等等,其实问题的存在是各个部门在寻找推脱责任的理由。

因此,我以为首先是解决问题原因的分析的问题,这是一种心态、一种方法,找出问题的主要原因,
而不是找出推脱责任的原因。
再者,我们需要针对问题找出解决的方法,可以进行跨部门的分析会议,针对问题找出解决的方法。
不要追究责任。我们的主要目的是解决问题,而不是主要惩罚某个人或某个部门,这是我们需要解决
的问题吗?
第三,根据分析的结论指定每个部门的行动计划,并组织实施以实现我们共同的目标。

·三只老鼠折射企业的绩效管理问题(2007-05-14) [作 者] 史鹏飞 [公 司] 保密

最主要的责任,和最主要的问题。是组织和责任分配,风险管理。
前期提出来偷油之前。没有认真的分析怎么样来做,怎么样做最好,或者其它的方案。进行对比分析,
判断。方案不能只考虑怎么做,还得再将风险和对策,一一考虑,应对。然后,选择适合的方案,进
行工作与责任分配。并明确领导与指挥人。将责任和工作分配与利益和能力挂钩。
分配完毕,预先演练一次,并明确可能的其它方案的内容。
接下来,要求各老鼠谈谈自己的要求和认识。根据各人情况和内容,进行针对性调整。
接下来,进行实际行动。
三只老鼠偷油,出现这个情况,和一个和尚挑水吃,两个和尚抬水吃,三个和尚没水吃,是一个道理。
问题出在那里?项目管理!那里有责任和管理。
下面的企业的案例。最主要的问题,也不是各部门经理。在那里?
在总经理。当然,各部门有各部门的责任,做的工作是什么样的结果,人力资源管理对各人另有评价
和价值认识。但和总的工作分配,和内部协调,组织,与市场应对来说,责任在总经理。
其它部门经理提出的,只是客观现实。环境就是这样,怎么样在这样的环境中取得成绩,这才是工作
内容的根本出发点。这是总经理的工作内容。罚,应该重罚总经理。

第 46 页 共 756 页
第 1 章 综合管理

·三只老鼠反映的项目缺陷(2007-05-14) [作 者] 荣庆 [公 司] 成都信息科技发展有限公司

一、在现在的市场中,企业生存和发展所依靠的是:
(一)低价格
(二)高质量
(三)高校售后服务
众所周知的,我们的项目管理共分为九大知识管理体系。但是,它始终是离不开三大目标管理:1 时
间——进度管理
2 成本管理
3 质量管理
在这三大管理中是相互依存的,同时又是相互影响的。能够很好管理这三大管理,那么在有着很好的
范围控制下,我们的企业就会在企业创新中不断前进和取得成效,现在我们不是在一味追求效率,而
是在不断强调效果。
二、在老鼠们的项目中共体现出 3 大管理:
(一)人力资源管理:共建一个高效有组织的团队。
(二)沟通管理:有目的地消除心理障碍,使团体凝聚力巩固。
(三)范围管理:考虑此项目所涉及的一系列任务。
(四)进度管理:合理分配时间。
(五)整体管理:事前准备。
(六)风险管理:明确责、权、利。

·一定要罚,一个都不能少(2007-05-14) [作 者] Danny [公 司] InsIT

遇到问题向别处推脱是一种心态,这种心态在项目出现问题时非常普遍.
员工说项目经理的工作不得力,监管不好,没有安排好计划.项目经理说出现意外,客户修改需求.公司
高层说天气不好,供应商不好,政府行政拖时间等.
总之人们经常说项目缺乏时间人员金钱,但从来不缺少失败的理由.

解决方案:首先是最上面的老鼠要被罚,它是主要做事的,其他的是配合它,失败的主要原因当然由它
负责.第三只老鼠和第二只老鼠一样受罚,它们没有很好的完成配合工作,导致项目失败.
我做项目要看结果,不管借口怎么样,失败就是失败.再华丽的借口也无法掩饰失败的丑陋.

其中罚的最重的应该是最上面的老鼠.在未明情况下放弃项目,也未对下面出现的情况进行沟通,导致
整个项目失败.

第 47 页 共 756 页
第 1 章 综合管理

1.8 这样的项目如何进行管理?

这样的项目如何进行管理?

北京东方飞扬软件
[姓 名] zhangmin [单 位] [邮 件] zhangmin@flyingsoft.cn
技术有限责任公司
[所属行业] IT 软件 [所属主题] 项目综合管理 [发布时间] 2007-4-16

【案例正文】
某公司签订了某省档案局一个项目,主要是为该用户开发一套档案管理系统和门户
网站,该公司为了拿到该项目,在价格上作了大量的让步,而公司没有对项目的范
围进行确定,也没有对项目的成本进行估算,就与用户签订了合同。
在项目启动后,由于对项目的范围没有确定,导致项目的需求总是再变化,项目
周期一再延期,用户也不满意,公司项目小组也很累,成本也很难控制!
这样的项目如何进行项目管理呢?
是不是所有的项目都可以管理好呢?

【相关分析】

·前期、过程(2008-04-21) [作 者] kou [公 司] 百通

这种项目是普遍存在的,sales or 公司为了签到单子或者为了先入为主,经常会这么去做.
1.主要是先看看公司行为的目的是什么,为了挣钱还是为了名声。确认这些后有助于你在项目和公司
的影响。
2.客户需求,你的计划书中要明确这些,客户的具体需求是什么,碰上这种比较虚的客户,应该派出
实战经验丰富的工程师去做需求调研,引导客户完成他们的需求,形成纸张文档,客户签字确认。这
块的时间估计会很长,但一定要做的细些,让客户从图片、结构全方位了解你的设计结构。一定要客
户签字确认这些。调研报告出来的时候最好和客户、客户领导开个研讨会,让客户领导认可报告。
3.实施过程,肯定会有变更,但要看是什么类别的,小类别的可以顺从他,尊重他的意志。大类别的,
要与客户沟通告诉他变更计划潜在的风险,让他的想法再成熟思考一下。客户执意去修改大类别的变
更,拿出以前签字的报告,向公司领导汇报,看公司决策。

·理论上所有项目都能管理好!(2007-07-04) [作 者] 龙七 [公 司] AMDOCS

每个项目如果所有的工作都做到位了,肯定是都能管理好的!我想这个我们大家都能理解.
但是现在我们所做的项目多数是已经出现了问题的项目,大家都认可在项目建立之初一定要确定好项
目范围和确定沟通机制,否则这个项目就已经有了隐患.但是为了得到项目,很多公司不但是价格上让

第 48 页 共 756 页
第 1 章 综合管理

利,而且在范围上也不够重视.现在的外国公司作的要好一些!

·分析,沟通(2007-06-01) [作 者] 马丘比丘 [公 司] 自由自在

1. 首先要分清项目干系人对该项目的期望, 在此案例中主要项目干系人有三类:

a. 用户. 一般来说最终用户(档案局)的期望都是"物美价廉", 希望功能越多越好, 并且质量越


高越好; 项目组对于用户的影响很小, 要充分发挥公司管理层的作用把项目组的影响"传递"到用户
那边去.

b. 公司管理层. 公司拿下了这种低价的项目一定有公司的原因, 比如, 可能是因为这个项目可


以带来一些其他的项目机会, 公司愿意在这个项目上给对方一些优惠....作为项目组, 应该把项目
中存在的风险清楚全面地分析给公司管理层, 比如, 如果不定义项目的范围会对我们有什么危害,
项目范围的定义应该包括什么内容, 应该具体到哪种程度, 又如,用户应该什么时候 SIGN OFF 需
求...同时, 项目经理应该和公司管理层关于这个项目做成什么样子就算成功达成一致.

c. 项目组成员. 让项目组成员了解我们所面临的挑战, 同时要让他们意识到现在的项目环境都


是复杂的,多变的, 尤其是 IT 项目. 项目经理也要拿出自己面对这些复杂问题的应对措施(比如,开
发一些 PROTOTYPE 和客户验证需求,充分向公司暴露项目的风险并寻求支持...)

2.这种高风险的项目一定要注意沟通, 让相关的人都了解项目的状态, 要不然到最后就是吃力


不讨好.

·错误的开始(2007-05-22) [作 者] 大兵 [公 司] 自由人

一、如果说为了拿到这个项目,而不管利润,那这样是不明智的,项目成员都不会用心去做,因为这是国
内普遍存在的现象,所以试想我们在谈合约时,可否在前期价格上把这些风险的损失加上去呢?
二、如果项目开始是以合同为依据,那就叫实施标准产品,此类项目既然涉及到二次开发之类的东西,
如果在合同中只注明大的范围,那么应该在合同之后立即展开项目需求分析,以确定详细的验收标准
或者范围;
三、从把握整体项目原则来说,这是个相当失败的项目,若要挽回经济损失,那及时补充需求,与客
户沟通,沟通再沟通这才是理想的!
本人从事项目管理不久,还是一名实话人员,若有什么不对之处,请大家指正

·一个外行看门道(2007-05-15) [作 者] CARSON [公 司] 北京青鸟商务

本人职位是项目策划经理,其实这个职位在我公司很尴尬。工作中不但要负责与客户之间的商务工作,
还要负责公司内部项目小组的协调管理工作。我不是项目管理的科班出身,但我来谈谈我在工作中的
一些实际体会吧。

第 49 页 共 756 页
第 1 章 综合管理

类似以上案例我至今已接手有三个。但是可以负责任的讲,这三个项目都完成的非常好,以至于
现在这个政府机构主动给我们项目做。

其实做政府部门的项目注意力应该放在与客户交流,沟通上;而内功应该用在产品的策划与设计
方面。
之所以这样讲是因为对客户单位性质,人员构成、内部潜规则的注意与研究,可以让你更好的把握客
户的期望值、诉求点以及最终的目的。作为政府机构,具体项目负责人来讲他们其实最终的目的还是
要把项目做好,这才是他们想要的。政府人员必然在技术方面欠缺的一塌糊涂,但是他对项目的运作、
协调等方面却一定是我们这些纯商业公司人员能力的数倍。所以作为项目管理人员要懂得扬长避短,
利用客户在项目运作方面的长处推进项目的顺利进行。同时你要用到你所有的专业知识去弥补政府类
客户这方面的欠缺。达到双赢就是目的。
接下来谈的就是项目或产品在前期的策划与设计。其实这点就是上面提到的需要我们利用专业知识弥
补客户不足的地方。在我做的这三个项目中,每个都是客户只有一个感性的需求,泛泛的需求。或者
可以说是一个标题性的需求。那么需要我们做什么呢?是怨天尤人?是责怪客户?甚至取笑客户?都
不是。我们要做的就是把客户提出的这个标题当作自己的课题。但是这个课题的套路我们应该尽量的
去符合客户的套路。顺着这样的思路,就需要你花费大量时间和精力在这张白纸上做文章了。文章做
完不要想当然,需要和客户进行反反复复的沟通,协调、协商等工作。直到能够取得客户 80%的认可
与确认。到此时其实你已经对项目整体的 80%进行了控制。

可能我说的都是些废话,但是在实际操作中很少有人能真正的从客户角度出发花费大量时间与精
力去尽心的为用户设计需求和产品。

本人写东西总是乱七八糟,凑合看吧。

·从案例分析的结果看PM的功力(2007-05-14) [作 者] 司 [公 司] 北京某软件公司

---------从案例分析的结果看 PM 的功力-------
申明,本人不是要攻击或批驳某些人,只是在谈一些自己的看法,如有让您不爽的文字,先行告罪。

看到这个案例的情况和各路大侠分析的精彩文字,感受颇深,谈几点自己的感受。
1、高手毕竟是少数。在近二十几个的分析,有深度能踩到关键点的分析不多,二楼的 emilly Ji 是
不可多得的优秀的 PM,没有上千人月项目管理经验的,是谈不出这番话的,个人非常推崇。
- emilly Ji 一文中开始首先把项目的环境进行了的定位,IT 政府大型项目,区区六个字,内涵了整
个项目的商务环境,包括项目特点、规模、类型、客户成熟度、客户关系、客户满意关键点、项目策
略等等。这是分析问题、解决问题的前提。纵观所有分析,能理解到此的寥寥无几!要明白,项目不
是独立存在的,它是生存于一个环境中的。
- emilly Ji 没有谈项目的成本、范围、风险等等,而是谈管理和沟通。高手出招,到底不同凡响!
把整个项目状态作为关注的重点,而不是单单的范围、风险。谋求的是改变现状的思路,以达到一个
合理的结果,而不是寻求最优的结果。
2、项目本生是一个系统。生存于一个更大的环境中,而她自己内部由人员、技术、风险、成本等个

第 50 页 共 756 页
第 1 章 综合管理

体组成,个体之间相互作用,并作用于项目本体,项目本体又会影响到个人的状态。比如范围,通常
在政府 IT 项目中,范围管理有两个难点,一是范围不确定,二是范围变化频繁。范围的变更直接会
影响到进度、里程碑、成本、资源、风险等。但你要求自己都不清楚要做什么内容的客户提供清晰的
功能描述,以此来规避在进度和成本上的风险,无异于 XXXX。如果真遇到那样成熟的客户,恭喜你,
你中奖了!在这个项目上,你也不会碰到范围不清的问题了!
3、项目管理是一门实践科学。看看回贴的内容,可以想象到“人造项目经理”在现实中的泛滥。
PM-BOOK 的痕迹谁处可见,张口就是范围、质量、成本。PM-BOOK 只是工具,PM 修行的更多是自己本
身。

·规范化管理(2007-05-11) [作 者] 郭景玉 [公 司] 北京航天金盾科技有限公司

作为一个开发型项目,《需求分析报告》是一切开发活动的根本,真不明白这个开发项目是怎么启动
的?在此同意上面各位的观点,动用公司的商务力量,进行商务协调。将双方拉回到会议桌旁,一个
是摆明目前的项目困境,另一个是重新确定需求和设定新的工作计划。项目开始后,客户与开发者实
际上是绑在一起的蚂蚱,谁也不会希望项目朝着不好的方向前进。所以,坐下来、拿出诚意进行协商
应该是一个可行的办法。

·这样的项目如何进行管理(2007-05-11) [作 者] emilly Ji [公 司] GBICC

看到这样的项目也是我经常会遇到的一些项目,项目启动的时候项目范围不清,为了夺标,商务把标
的押低,过程中业主和开发者关系紧张难以协调。或许做过 IT 政府大型项目的人对这些情况都不陌
生。我不想谈这样的项目有如何的不好,如何的难以管理,以及如何的没有在开始的时候确定范围,
成本曲线计划等,我只想谈谈项目在这样的生存环境下,如何管理和沟通,尽最大的努力来完成作为
项目组层次上的项目管理应该做的事情。
1、鼓舞项目团队的士气。项目进行到这个层次,项目组成员的感受是最不稳定的,这个时候很多项
目组成员会对项目出现绝望的情绪,甚至影响到项目进一步工作开展中来。这个时候项目组管理者一
定要注意缓解这种情绪的蔓延,要鼓舞士气。
2、项目长期的范围和目的不明确的情况下,要多和业主沟通,同时注意沟通的效率和频次。如果可
以和最高决策层沟通就直接沟通,当然沟通的时候需要准备的是完整的系统方案。你的需求方案可以
不拘泥于规定的格式,但是一定要利于理解。根据受众的不同而调整你的需求方案。另外对项目需求
管理要做一个动态控制的计划。不能指望一次就可以做好整个系统,而是根据需求确定的程度来步步
推进,动态控制需求及变更,过程中一定要将业主方的技术和业务负责人及项目关键关系人引入你的
需求变更控制流程中来。
3、项目进行过程中或许已经出现了这样那样的问题,但是对于科学的管理依然要坚持。项目管理中
有很多很好的工具和方法,不能因为项目出现问题而摒弃。我看到很多项目经理都会有这样的想法:
只要我交出的东西 ok,其中的过程你不用理会。这样的想法是错误的。行业里有一句话讲:上乘的
项目管理是效果和过程都实现好,中乘的项目管理是效果好过程马虎,下乘的项目管理是效果不好过
程 ok,失败的项目管理是过程效果都没有。我想这个项目进行到这个程度,作为项目组层次的管理
者来说一定要认清形式,在这个时候项目的结果很好已经不是我们最终可能或者追求的结果了。但是

第 51 页 共 756 页
第 1 章 综合管理

注重管理过程也许就要提到一个更加重视的程度。管理过程即可以反促进项目结果,又可以提高客户
对此项目的满意度,减少不满程度。
4、采用迭代型开发,合理分配你的资源来达到项目的最终结果。
总之,如果我们能尽最大的努力保证项目的完工,交一份中下乘项目管理答卷,无论从客户还是企业
的角度来说这个项目就是成功了!

·项目开始前必须明确项目的范围(2007-05-01) [作 者] 毛知新 [公 司] 湖南电力公司

在这案例中,存在的主要问题是对项目的范围没有明确的界定,对项目的成本没有估算,导致项目一再
延期.解决的办法有:
1、双方重新坐到一起,对已完成的工作进行测算。对尚未完成的工作进行测算,重新计算工作量。
重新界定项目的工作范围。
2、对已投入的费用进行核对,对后续将投入的费用进行估算。
3、对已完成的工作进行一个鉴定,将其划归项目的第一阶段。
4、对未完成的工作进行重新测算,按项目的进度、费用、时间、风险等方面进行重新的测算,重新
设计项目管理办法。
只有重新进行界定,项目才能进入正常的轨道。

·必须确定项目范畴(2007-04-28) [作 者] Ligf [公 司] excellence network

项目的三要素:成本、进度、质量

如果项目范围不定,上述三方面都无法控制,因此,关键点是抓住项目的范畴(需求)。如果已经进
行了一段时间,此时应该停下来,双方总结项目之前的问题,并重新框定需求范围,确定后续需要处
理的事项。务必是已经达成共识,才能进行下一步工作,否则是无底洞。

另外,可以适当利用高层的关系,既然公司能拿到这个项目,这说明上层还是有办法进行控制和协调
的,对于项目的范畴等,可以尽量走上层路线来达到项目继续前进的结果。

·三步走,帮你解决(2007-04-24) [作 者] 罗晶 [公 司] 国际化公司

第一,分析 Business.
不知道公司为什么要做这个项目.
项目的目地都不知道.所以第一要了解我们做项目的目的.可能是为了挣钱,也可能是为了其它.找出
原因.这个对于以后人员管理,沟通管理都是很主要的.
第二,马上确定范围
给客户交付一个你也不知道的产品.
确定你要交付的是什么东西.然后才能向这个方向努力

第 52 页 共 756 页
第 1 章 综合管理

第二,建立变更控制体制
管理就是控制.没有什么好说的.

·项目成败的评判标准(2007-04-19) [作 者] lintao [公 司] CATTSoft

上面绝大部分的观点基本雷同,我也赞同以上各位提出的实施建议。

项目成败除了要有严格的管理制度、出色的项目经理外,公司高层对项目的关注程度是至关重要的。
说到本案例,既然公司能够不惜代价签下这单,一定有公司高层的想法,也许有其它的战略意图,不
足为外人道也(比如进入公司的空白领域、抢夺市场分额、打压竞争对手等等目的;如果是糊涂蛋老
板,我就没话说了);说明公司高管对这个项目还是十分重视的,虽然在项目运作的过程中遇到了种
种困难,在这个前提下要及时跟高管交换意见,在取得高层对这个项目的意见后再作动作应该是明智
之举。

·这样的项目如何进行管理?(2007-04-19) [作 者] 史鹏飞 [公 司] 保密

赔钱是肯定的了。不过还是要死抓成本管理。
首先,暂停全部工作。组织相关人员,迅速的与甲方就需求与范围界定清楚并要以文档最好是合同的
方式固定下来,如果能要求甲方派出一个说话硬,管得了事的人为协调,更好。
然后,整理好以前开发的内容和成果,
项目组重新对项目进行审读,判断,研究。做出新的战略规划。
然后,迅速的针对项目,进行工作重新分配。切实的落实流程管理。保证时间与工作的时效性。
同时,必须尽早的先把网站架起来,保证起码一部分的用户能访问,那怕只能访问主页而不能再看到
其它内容。
接下来,一部分一部分的落实,对于甲方在开发期间提出的其它要求,或者意见,参照与甲方签订的
需求与范围书,进行处理。如果甲方再有其它要求,另计,另算。

·行动流程(2007-04-18) [作 者] 陈志强 [公 司] 联强国际

一 现有工作全部暂停,与客户方共同协商,确定双方各自选定项目管理人员,客户方必须能有一个可
以协调各方面关系的人作为联络窗口,最好这个人比较 POWER,说话管用的
二 以最快的时间来确定客户需求方向,并且这个方向一旦确立之后就不再变更,如果将来客户坚持还
要在此基础上做任何修改,所引起的一切后果均由客户方来承担(如工期再次延误等),
三 按确定好的需求方向来做出成本预算
四 网站应该比较快可以搭起来,以最快的速度,哪怕加班加点也要先把门户网站给做好,至少先保证
客户方能看到一部分成果
五 开发工作按照确定好的需求方向来有序进行,中途除非有特殊情况,否则不再接受无止境的修改意

第 53 页 共 756 页
第 1 章 综合管理

见,并且所有的修改请求都必须归口到客户方项目联络人,由他汇总后统一提出,不接受其他任何人的
独立修改请求.

·一点看法(2007-04-17) [作 者] 张慧勇 [公 司] 青牛项目管理部

从项目营销来看,为充分对项目进行可行性研究,从成本、利润上为做考虑。
从项目执行来看,对项目范围控制不当,未能在项目需求阶段和客户达成需求共识,可能也未采用合
适的原型设计。
从团队管理上来看,由于项目范围未控制住,工期一拖再拖,项目组成员变的疲惫这是难免的。

解决办法,目前阶段,应和客户进行沟通,再次确定项目范围,确定项目边界,对客户提出来的新需
求与客户确认,得到客户的认可(对客户的需求也要控制),做出明确计划,鼓励项目组成员,控制
需求范围,项目进度。

·看什么人,什么公司来做项目(2007-04-17) [作 者] 周波 [公 司] 深圳市X数码技术有限公司

我曾经有同样的经历。合同签定前的界面界定很重要,但有的公司为了拿到单,往往没有重视甚至故
意去模糊项目界面。并且项目经理是在合同签定之后任命的,更给项目管理增加了难度。这种项目,
项目经理的水平当然是关键,但项目承建单位对项目的态度、高层对项目的支持可以左右项目经理的
能力发挥。本例这种项目往往发生在公司的高层对项目不重视公司。如果你是该公司的一名项目经理,
那么写简历应该是一种可以考虑的选择。

·同意各位的意见(2007-04-17) [作 者] 马骁 [公 司] 施耐德电气

对于范围定义不够清楚的项目一开始就应采用 CPPC、CPIF、CPFF 合同来规避卖方风险。

如果已经签订的固定价格合同,就只能同客户加强沟通,尽快定义项目范围,重新估算成本和时间。
如果此时发现预算超额,没有利润可言,也要取得客户谅解,让客户从“双赢”的角度理解,没有利
润的项目质量很难保证,从而能够让客户同意根据新的结果追加预算,或签订新的合同。

·项目启动规划是失败的!(2007-04-17) [作 者] 蓝剑 [公 司] **

在与用户签订的合同的基础上,
1、积极主动与客户加强沟通,明确业主的需求;
2、确定项目的范围,制订详细的范围说明书;
3、由于项目已经延期,应加强对项目进度的监控,确定关键和非关键工作路径,改为并行工作,以
压缩进度,进行资源合理配置,同时有效控制项目风险;

第 54 页 共 756 页
第 1 章 综合管理

4、范围明确,成本也就很好控制,
5、如果业主的需求超出合同的范围,应追加项目合同费用。
6、项目进行到这样,与业主的沟通很重要,

·沟通与交流,重新取得利益平衡(2007-04-17) [作 者] 乔国杰 [公 司] 中兴软件技术

首先得承认这个项目是失败的,然后在些基础上采取补救措施,以重新达到双方利益的平衡。
双方都应该明白,在当前的情况下,单方面获利是不能可能了,只有当达到一个平衡点的时候,才能
在做出一个最优的方案,相对来说。这也是项目动作最基础的出发点。
外部是这样,公司内部也一样,市场与研发也要取得平衡。

·抓紧(2007-04-16) [作 者] 李 [公 司] 路安特

1.首先进行风险分析。
2.当务确定明确的范围。
3.核算出实际的成本和时间。
4.与利害关系者协商。
项目就是独特的,项目管理必须适应这种独特性,运用共有的,结合项目独特的把项目管理好!

·首先要做的事(2007-04-16) [作 者] luoyun [公 司] xx

对该项目,首先要做的是和客户一起,把已经完成的部分进行总结,自己公司要把已经付出的成本进
行计算。在此基础上和用户确定未来需求,制定新的计划,要充分考虑已付出的成本,在前期遇到的
问题,防止范围无限蔓延。

·合同类型(2007-04-16) [作 者] HSP [公 司] secret

出现这种情况在中国应该是很正常的,目前要确定所签的合同的类型,如果是 CPPC、CPIF、CPFF 合
同那就不用怕;如果是 FPPIF、FFP 合同,那就要亡羊补牢了,尽快草拟项目的范围清单和客户协商确
认,并提示客户会尽量满足更改的要求,但可能会影响交期!

·最简单的办法,亡羊补牢(2007-04-16) [作 者] 黄震 [公 司] BocSoft

最简单的办法,亡羊补牢
既然已经造成这种局面,双方就诚心、诚信、平等地面对面地谈
(1)确定详细地范围,确定后续变更范围地处理方法

第 55 页 共 756 页
第 1 章 综合管理

(2)确定所有地工期,按照工期投入资源
(3)经常沟通,最大限度地了解业主地意图,最大限度地让项目组地人了解项目地要求
简单吧
和人打交道是最难地。

·太简单了(2007-04-16) [作 者] 任鹰 [公 司] 暂无

最简单的办法,亡羊补牢
既然已经造成这种局面,双方就诚心、诚信、平等地面对面地谈
(1)确定详细地范围,确定后续变更范围地处理方法
(2)确定所有地工期,按照工期投入资源
(3)经常沟通,最大限度地了解业主地意图,最大限度地让项目组地人了解项目地要求
简单吧
和人打交道是最难地。

·是,所有的项目都是可以管理好的(2007-04-16) [作 者] daijiangbao [公 司] 深圳市大视野


企业管理顾问有限公司

所有的项目都是可以管理好的,关键是要按照项目成功的法则去管理,不要把不正确的、不合适的管
理理所当然的认为是正确的管理,对于软件开发项目,不能全部照搬软件工程的模式来管理,这是本
质性的问题。软件工程的理念和项目管理的本质是不同的,要认真区别、有机结合对待。

1.9 项目经理对技术是外行,如何掌控?

项目经理对技术是外行,如何掌控?

[姓 名] 孙戈 [单 位] 不公布 [邮 件] bjsun26@sina.com.cn
[所属行业] IT 软件 [所属主题] 项目综合管理 [发布时间] 2006-10-16

【案例正文】
项目经理 A,在公司有一定的亲和力,被领导和同事看成比较有能力的人,负责实
施过很多的项目,有不错的项目经验:近期被安排一个软件项目,但是 A 对软件开
发不懂,甚至开发流程都不了解,他该如何行使项目经理的职责,把这个软件项目
执行好呢?关键的问题是他不懂技术。

第 56 页 共 756 页
第 1 章 综合管理

问题:

他该如何领导项目团队?如何掌握项目进度?如何针对项目中的技术问题做指导?
在与用户沟通的过程中,如何让用户对自己的位置表示认可?

【相关分析】

·他未必是外行啊!(2008-07-21) [作 者] 四季风 [公 司] 兴库建设投资有限公司

看你写作中描述,他仅仅是技术上欠缺写,但不是做项目经理外行。
通读全文,感觉他具备做公司层领导的能力。
如果他不得不做项目经理,我相信他很快会找到好办法,激励团队成员积极实现自我,不断攀登项目
进步的高峰,预计三年内他将升级到公司级领导。

·挑选“技术顾问”(2008-05-20) [作 者] 王玉娜 [公 司] 上海天马微电子有限公司

1.建议他挑选一位经验和技术能力较强的人,担任顾问,负责技术层次的监督。
2. 参照同类项目的开发经验。

项目管理是一种经验,一种思路

·仔细听(2008-04-28) [作 者] 连甲虎 [公 司] 力帆汽车

我认为,各个行业在技术上差别很多,但是在管理方面却有着相同的内在章法。任何新产品的开发无
非是计划、实施、发现问题、解决问题、提交项目成果。所以,作为一个有能力的管理人员,只要仔
细的听取他们的员工的意见,加以分析讨论就能作出决策。这要求,多听,提意见一针见血。

·项目经理对技术是外行,如何掌控?(2008-04-18) [作 者] 王国华 [公 司] 烟台东华网络工程有限公司

1、首先要自信。你们的技术好,但我的的管理水平高。给胡锦涛理发的难道先具备国家主席的素质?
2、要和蔼可亲,团结一切可团结的力量,利用一切可利用的资源,找准突破口烧好头 3 把火。
3、尽快提高自己的软件知识,别讲外行话,办外行事。

·项目经理是外行(2008-03-31) [作 者] 孙杰胜 [公 司] 天津华苑产业园区方卫

在项目管理中对于专业性比较强的项目一般来讲项目经理要求对该行业有了解。否则项目计划可能都
无法完成,项目团队成员对项目的工作包完成情况更无法了解。为项目的顺利竣工埋下祸根。
当然也有很多项目经理对于所涉及到的项目行业知识储备不是很丰富也能圆满的完成项目。
其中包括有人举的例子:刘邦建立汉朝,建立汉朝的刘邦行军打仗不如韩信,治国安邦不如萧何。其

第 57 页 共 756 页
第 1 章 综合管理

实我国古代的这个例子恰恰与项目管理中的理念相吻合,不懂技术的项目经理一定要有一个项目技术
总监,当然项目技术总监要能够很好的为项目经理服务,不能自己另开朝堂。

·找到自己存在的价值(2008-03-17) [作 者] 老杨 [公 司] 产品开发和系统集成

项目经理存在的价值有很多种,可以是技术把关者,项目协调者,进度控制者,项目打杂者之一或者
多个,我想,技术上不懂是个瓶颈,但可以让技术总监之类的人员辅助,千万不要不懂装懂,否则就
会成为项目的阻力。

·何必技术好(2008-03-07) [作 者] gaozhen [公 司] shandongjingjixueyuan

刘邦建立汉朝......
萧何 张良 韩信

·不懂技术的软件项目经理(2008-02-26) [作 者] 申恩慧 [公 司] IT

项目经理是一个桥梁性质的人物,他不需要很好的技术但他一定要有很好的沟通能力和协调能力,所
以说 A 符合项目经理本质的需要在完成工作上是没问题的。
但是不懂技术如何划分项目和制定里程碑呢?我认为项目中必须有一个技术总监来协助,由技术总监
来对项目技术部分进行划分和对每部分所花费的时间进行评估,而项目经理则需要将非技术部分统筹
规划一下,当然如果真的不懂软件流程可以去看一本书,了解一下其他软件过程,我想既然做过项目
经理这个肯定不会难的,做项目就是人的集合,把人用好了项目就成功了!我想在这个案例中同样也
是这个问题!

·不是外忧,而是内患(2008-01-24) [作 者] 周预 [公 司] 湘潭

首先可以肯定,这个公司不小,项目也不小,因为中国 it 行业目前很少有全职项目经理,一般来说,
项目经理还兼了其他工作,如系统分析、程序员等工作。作为本案例来说,A 的作用暂时只能作为全
职项目经理,在工作中,边看边学了。
1、挑选一个技术专家作为搭档,我们的社会文化环境都希望当官(不知道项目经理算不算是个官),
学而优则仕,希望管人,而不希望被人管。实际上还是有一部分人只希望做纯粹的研发工作,不喜欢
管理工作的。找到这种人做自己的搭档,用你的管理能力实现他的技术才能。必要时工资薪水比自己
高都没关系,这需要企业有合理的薪酬制度和技术晋升体系,那种不当官就没有好待遇的企业肯定是
无法做到的。
2、项目进度掌控的基础是项目进度计划,制定计划也不是项目经理个人的事情,项目经理要加强与
成员的沟通,制定合理的进度计划,加强绩效考核,随时掌控进度并不是难事。问题是某些项目组成
员自己想当项目经理,或者心理不平衡(说实在的在所难免,换成我也心里不舒服),不配合项目经

第 58 页 共 756 页
第 1 章 综合管理

理工作才是最大的困难,呵呵,就怕窝里斗!!!
3、技术指导,项目经理不懂技术当然不能作技术指导。问题是在当今复查的 it 项目中,一个项目牵
涉到多个领域:软件、硬件、网络、集成等,即使是某方面的专家,也不是“全”家,能在数据库上
知道别人,不一定能在网络调试上知道别人,要借助公司甚至外部力量!作为项目经理应该选择好搭
档,并协调组织好他们形成一个团队,当然某方面的专家,有利于树立自身的权威,也可以减少企业
总体成本。
4、用户沟通的问题,并不是所有的客户都喜欢跟技术人员打交道,甚至有些用户讨厌那种满口专业
词汇的自以为是的技术人员,同用户打交道重要的是业务需求,而不是技术实现,当然同客户方的技
术人员打交道又是另外一码事!同时沟通是还可以请相应的技术人员一起参加了,无非是成本增加而
已!
作为项目经理 A 来说:除了加强自身学习以外,腰杆挺直,技术专家不一定是好的项目管理经理,所
以项目管理经理不一定就是技术专家!但切不可把自己当个什么鸟,不是自己的专业特长,要虚心向
技术人员学习,诚恳倾听专家意见。必要时建立自己的专家咨询名单,a 不是“有亲和力”吗,因该
容易。

·对技术是外行也有他的优势(2007-12-13) [作 者] 杨从容 [公 司] 云南建设银行

对技术是外行的项目经理虽然不懂技术,个人认为却也是他的优势.
因为懂技术的项目经理或者半懂不懂的项目经理很有可能在开发软件的过程中把自己给绕进去,而不
懂的话反而能专注于管理方面,我想也许更好吧

·找一个懂技术的人协助你(2007-11-30) [作 者] snock [公 司] 广州某软件公司

A 懂项目管理,但不懂技术,这对软件项目的研发确有很大影响.但如果他能找到一个懂技术和懂流程
的人协助他,作他的助手,那么做好这个项目是不成问题的.

·注重团队的力量和沟通的作用(2007-11-30) [作 者] 陈培刚 [公 司] 西钢设备工程部

充分发挥团队的作用,给团队的成员提供充分的发挥空间,同时要加加强沟通,包括团队成员的沟通,
项目干系人的沟通!

·外行如何管理内行?(2007-10-14) [作 者] 宋华先 [公 司] 秦武田制药

对于技术含量比较高的项目,如果项目经理不懂技术,那将给项目的管理增加很大的难度。比如,如
何设定进度,如何与技术人员交流,如何指导技术问题。即使项目经理再快速学习,也达不到内行的
程度。因此,需要单设一名技术经理协助项目经理,负责真个项目的技术部分;当然,项目经理也要
快速学习,不懂得如何做没关系,至少要知道关键点是什么。

第 59 页 共 756 页
第 1 章 综合管理

·外行项目如何掌控(2007-10-08) [作 者] iamsafe [公 司] 广州

作为软件开发为主的项目,最重要的还是技术,如果项目经理一点技术都不懂,第一不能服众,第二
对需求、项目时间可能都没有办法很好的控制。
项目经理至少要懂得一些基本的流程、功能实现的复杂程度,不需 1、要 coding,但是要明白原理;
2、要配备开发经理(技术经理)。对于技术层面的东西,由开发经理统筹,项目经理要和开发经理
经常沟通、确认项目计划、人员安排等等。在和客户讨论需求的时候,也要有开发经理在场,这样可
以避免需求的蔓延。但是开发经理仅仅需要记录或者评审需求,可以不用理会客户关系。
其他的项目管理 就是由项目经理负责了。

·haoxiang you dian duo (2007-09-18) [作 者] 松 [公 司] 天啊

我们公司是一个中型软件公司,大概有 300 多人,其中 200 多人做软件开发,目前我们公司的大部分


项目经理都是技术强人,因为是技术出生,他们更喜欢冷冰冰的电脑,因为电脑和人相对更容易控制。
公司一步步的发展,领导们发现技术出生的项目经理慢慢不能满足市场的要求。以前我们是做行业内
的软件,客户和我们之间的关系都很不错(都归省公司管理,大家是一家人嘛!),现在拓展了好几个
行业外的大项目,大家发现以前行业内的开发、管理方式慢慢不能满足管理需要了,项目需要更强的
管理能力。

所以最近公司决定把项目经理和技术经理分开,项目经理主要负责沟通协调,注重成本和范围,
而技术经理注重质量。

我们项目是一个行业外的大项目,我是最早的参与者、组织者,经过激烈的招标,我们公司才中
的标,所以理所当然的,我成为了本项目的项目经理。

因为项目重要,我们公司给我们项目配备了好几个高手,一个是 W,他以前是做呼叫中心的,Java
强人;另外一个是 X,一个行业专家,将近做了十年相关行业的软件,做到软件部经理职位,因为不
堪挤兑去年才来到我们公司;最近,来了一个软件工程硕士 H,他在读硕士之前就是系统级项目的开
发主力,在读软件工程硕士的时候实施了一个 ERP 项目;

作为项目经理,我很惭愧,主要是因为以下几点:

1、开始人很少,大概 5 个人,我、W、X三个人做需求,另外两个小虾学习、了解项目,但是
后来人变成 9 个的时候,我没有及时转变角色,仍然关注技术,没有认真分析客户的心理,没有合理
的阻止客户的一些不合理需求……,总之,从整理的控制上太注重细节,反而没有关注好怎样去应付
客户;

2、在内部关系上,我公私分得不清楚,W是我的好朋友,但是W是一个控制欲极强的人,他希
望什么讨论都以他的思想为主,否则就很不高兴,我在他不高兴的时候虽然把握好了方向,但是流露
出了担心(担心他不高兴,担心破坏我们之间的友谊)、照顾(虽然采纳了别人的意见,但是过度照

第 60 页 共 756 页
第 1 章 综合管理

顾他的情绪),这样对项目注影响很不好,幸好后来跟他挑明了,我们公是公,私归私。

这两大问题我到现在才控制得比较好,但是成本已经达到了 40 人月!

这种惨痛的教训希望能够给大家合理的启示!

也许是性格的原因,我虽然喜欢技术,也比较执着,脾气还不好,但是在做项目经理的时候,我
改变了很多,我会尽量吸收大家思想里面的优良部分,有机组织成一个统一的思想,但是我还是不明
白,为什么会有W这样的性格?难道做技术的人就这么难交流、沟通?难道做技术的人就不能容人?
难道有一天他当上项目经理,他就不怕别人不配合啊?也牛牛的桀骜不驯?

不多说了,我知道W虽然是我的好朋友,但是他极不希望我把握技术权限,而且对我做的决定心
里不满,积极性不高,后来我就把技术权限都划分出去了,现在他们积极性高不少了,我的技术足够
监督他们完成工作,我只要做好这个就行了!

正好公司准备把项目经理和技术经理分开,领导有在我们项目做试点的想法,我积极支持,并推
荐W做技术经理。哈哈现在他应该感觉好不少了,我做好必要的监督工作就行了。

真心希望W从此一路走好!

W提出项目经理和技术经理的分工如下,请大家替我想想,提提意见:

项目经理(Project Manager)
1、项目组日常管理工作。
2、组织项目组成员对项目规模、工作量、工期进行估计。
3、制订相应的执行计划,解决阻碍项目开展的矛盾和问题,以保障项目能够按照执行计划顺利进行。
4、定义项目目标。在特定技术、费用和时间的限制下,协调组织中的各种资源达成项目目标。
5、与客户、领导、市场人员进行沟通。向外界提供项目的可视性,如工作进度、质量状况等。
6、监督和控制项目的进度、效率和风险。
7、根据使命、目标和需求来进行项目范围管理。
8、按照项目计划组织项目验收。
9、与质量保障人员配合,组织实施切实可行的质量体系,以保证项

·项目经理对技术是外行,如何掌控?,(2007-09-18) [作 者] 张建 [公 司] UNEDET

项目经理完全不懂该项目的技术是不行的,如果这个项目你不懂,你一定要学习,努力掌握其基本框
架/流程,这样才能做到心中有数,不需要知道得太多,但是完全不知道是完全不行的。
另外,对于你不懂技术的项目,一定要信任技术总监,而且需要对项目的整体把握,利用自己在项目
管理上的能力来弥补在技术上的不足。毕竟,咱是项目经理,不是技术经理,咱的强项是项目管理,
而不是技术支持!

第 61 页 共 756 页
第 1 章 综合管理

·项目经理对技术是外行,如何掌控?(2007-09-10) [作 者] 罗忠艺 [公 司] 成都全友家私有限


公司

按照常理来说一个项目经理必须是懂本项目的相关技术的,但是现在此经理不懂。但是此经理有非常
好的人缘和人际关系可以弥补他在技术的不足。做项目本来就是把具有不同专长和技能的人聚集在一
起来完成特定的服务、成品和成果。此经理可以很快去熟悉软件开发的流程和大家保持良好的沟通以
弥补自己的不足。

·支持cao xi的陈述!(2007-09-06) [作 者] 陈万春 [公 司] PETL

支持 cao xi (Rockwell Automation littleqian@yahoo.com)的说法,同时,领导让其担当 PM,会基


于一点---他虽技术不很在行,但是基本框架还是能理解的。

·项目经理对技术是外行(2007-08-30) [作 者] tjh [公 司] cxgs

和项目经理保持良好的沟通并发现他的优点。发挥自己的技术优势,做到从大局出发,技术工作条理,
有序。把复杂的事简单化,把简单的事,标准化,把标准的事形象化。再不懂的经理,也会对你赞赏!
互惠互补,取长取短,好的团队成就的不仅仅是你的经理!

·沟通并支持(2007-08-27) [作 者] czpm [公 司] 工程有限公司

和项目经理保持良好的沟通并发现他的优点。发挥自己的技术优势,做到从大局出发,技术工作条理,
有序。把复杂的事简单化,把简单的事,标准化,把标准的事形象化。再不懂的经理,也会对你赞赏!
互惠互补,取长取短,好的团队成就的不仅仅是你的经理!

·多和技术总监沟通(2006-12-16) [作 者] 吴明刚 [公 司] 咸宁学院

软件开发里的技术总监(系统分析师)是对整个系统最了解的,他负责如何去完成软件,而 pm 负责
如何协调资源,时间,范围,两者对整个项目起着决定作用,所以 pm 应和技术总监多交流,将技术
重点转到技术总监上,自己专注于常规管理

·执行力-团队的力量(2006-11-29) [作 者] 谢仁禄 [公 司] 无

项目经理的重要任务首先是领导团队做好项目规划,其次是保证计划的执行力。因此我的建议是项目
经理应尽可能地利用领导的信任从公司领导处获得足够的优资源,充分发挥团队的力量,特别要用好
技术骨干的专业技能。

第 62 页 共 756 页
第 1 章 综合管理

·补充第 4 点(2006-11-27) [作 者] blueboyfly [公 司] ALSTOM

4.一个外行被领导任命为管理软件开发的项目经理,说明领导对你的信任,也就说明你可以从领导那
里获得更多的资源。项目经理 A 应充分利用这一点,获得领导的更大的支持。当然,在解决技术方面
问题时,要多听取大家的意见,形成决议后就立即执行。

·如何掌控外行项目(2006-11-27) [作 者] blueboyfly [公 司] ALSTOM

针对 IT 行业的项目管理,如果是外行,确实会遇到一些困难,但也并不是无从下手我建议如下:
1.针对 IT 项目,外行人员应对其过程和框架有一定的了解,所以应进行一次培训。不能认为 IBM 的
CEO 老郭搞定企业,你项目经理也可以搞定项目。管理层次越高,对技术的掌握要求就越低,但不要
忘记项目经理的层次要低于 CEO,对专业一点都不了解,会使你底气不足。
2.应和技术骨干进行交谈,制定出详细的计划。最好是可以找一位技术专家作为你的助理。
3.项目经理最重要的进行沟通和进度控制,求同存异,带领大家完成项目。

·项目经理对技术是外行,如何掌控?(2006-11-20) [作 者] 有一 [公 司] 安顺机械

对技术骨干适当放权,信任他们,并主动承担不可预见风险,使他们更好的工作。

·外行如何领导内行项目(2006-11-17) [作 者] tigerdeng [公 司] 烽火通信

一般来说,软件项目的技术风险大,专业性强,此类项目管理要求组建良好的项目团队,特别是关键技
术负责人,软件项目的架构等关键技术方案是决定软件项目成功的关键,充分利用公司相关专家资源,
可以调动项目组成员的主管能动性,项目经理不必是专家,如果本身太专业也可能影响你去采纳别人
的意见,反而可能陷入技术误区

·关于外行,如何掌控?(2006-11-17) [作 者] 苗小真 [公 司] 包头职业技术学院

借鉴有效的模版,也是快速有效的一种方法,其实质就是分析案例,找到的和你以前做的相似的共同
地和需要注意的地方

·外行,如何掌控?(2006-11-16) [作 者] 苗小真 [公 司] 包头职业技术学院

继续说一下,培训对你应该说是很有用的,在很短时间内对你开发项目在概念上有个很好地了解,项
目管理很重要的一环是顶一部分定义好了,很多活动就顺理成章了,然后是在实施阶段不断的沟通学
习,要灵活运用你以前的经验,在项目启动你会遇到一些困难,因为有好多专业人士不会信服你,你

第 63 页 共 756 页
第 1 章 综合管理

所作的就是要让他们相信你能,配备一个较高专业技能的经理助理是对你非常有帮助的

·关于外行,如何掌控?(2006-11-16) [作 者] 苗小真 [公 司] 包头职业技术学院

对于这个问题,我认为
1、不应该像有些人所说的,不懂技术不影响项目的成功,其实现实中,管理和技术所占的比例应该
在 5:5 左右。如果是开展的小项目,管理:技术可以是在 3:7 或者 4:6,而复杂的项目系统工程,
建筑工程管理:技术应该在 6:4 或者更多。
切实可行办法是,在项目开始前,开展一下集中培训
2、你有很好的经验就是所说的过程资产比较好,这是优势

·领导、服务(2006-11-11) [作 者] 登高望远 [公 司] 新鸿基

项目经理是一个 team 的领导者、服务者,大可不必作为具体的 operator。首先了解团队成员的能力,


特点,做好项目开发的架构,可以从中挑选合适人选作为技术主管,负责协调、管理技术问题。分析
团队的内部外部资源,为开发工作提供充分的环境支持。建立良好的团队氛围,鼓励沟通,创造美好
愿景。领导团队指定工作计划,充分发挥每个人的能力,给予每个人充分的信任。定期对计划执行情
况进行分析,做出相应调整。

·外行(2006-11-11) [作 者] 祥子 [公 司] huanbao

做到知人善任可也

·清晰定位,开拓资源、保证项目实施(2006-11-10) [作 者] 廖学峰 [公 司] 江西科泰华软件


有限公司

这种情况经常看到,但听说 IBM 的 CEO 郭士纳以前也只是卖糖水的,但他完成了 IBM 的成功转型,所


以我的想法是:

1、项目经理不一定是项目组中技术最好的人,但一定要是沟通能力最强的人,只有沟通能力强才能
明确项目的内在需求、当前问题、成员状态。
2、项目经理必须和最高层保持一致,确保得到明确的支持,这样才能把握项目的各类资源。
3、项目经理要具有远大的眼光,看到项目的前景,并具备良好的社会资源,保障项目组出现问题或
难题能够通过项目经理的资源快速解决

·项目经理(2006-11-08) [作 者] lydia [公 司] neau

第 64 页 共 756 页
第 1 章 综合管理

项目经理应该是:
领导面前的专家,
专家面前的领导!

·技术不是关键(2006-11-07) [作 者] xiaohu [公 司] shanxishenlongnengyuanjiaohuagongsi

一个好的项目的完成,不只取决于你的技术,而是你对项目的控制能力.控制得好,那你团队的技术
也就是你的技术了.不懂技术不要紧,有时候你的团队成员就是你很好的老师

·把握框架(2006-11-07) [作 者] 邵兵 [公 司] 齐齐哈尔

项目管理是个软专业,所谓软就是老话“样样通,样样松”。把握具体专业的流程框架对于一个职业
经理不应该是难事,何必要求他精通呢?马克思不懂蒸气机的技术原理,但这并未妨碍他写《资本论》。

·项目经理人选(2006-11-06) [作 者] 聂建伟 [公 司] 中海油天津渤海石油

我意见认为一个项目经理人选可以是外行,或文科背景。
当然有专业技术背景更好,若是外行,可发挥政治,人力资源,沟通管理的优势,不用过多深入到技
术细节中去,总体大局观较强。可选一过硬的技术主管作支持。

·项目经理对技术是外行,如何掌控?(2006-11-03) [作 者] 桂君 [公 司] 合肥市伟联科技有限
公司

外行领导内行是个不容忽视的问题,作为一个项目经理,了解和熟悉该项目所必须的技术也是有利于
项目的进行,也有利于和项目组成员进行沟通。
但作为一个项目经理不可能只做一个项目,在不同的项目中所涉及的技术也是有所不同,我们也不能
做到可以掌握这么多技术,毕竟人精力是有限的。
针对这样的情况,因为该项目经理有丰富的项目经验,对项目管理已经驾轻就熟,在该项目中可以考
虑为他配备一名经验丰富切实力过硬的技术工程师作为其副手,总体负责项目的技术方面的问题,其
直接向项目经理负责,然后有项目经理负责整个项目的管理和运作,包括与各方的沟通等工作。关键
是要做好与该技术工程师的沟通工作,给予一定范围的授权和充分的信任。共同确保项目的完成

·项目经理不能是天使,也不能是魔鬼。(2006-11-03) [作 者] small potato [公 司] RA

忘记了从哪里看到的:

第 65 页 共 756 页
第 1 章 综合管理

应该遵循中庸之道。项目必须严格的按照计划来执行。想成为一个完美的项目经理,应该相应的具备
的权利包括有:
1、技术权威:技术上的 NO.1 ,虽然项目经理不一样要非常精通技术。但是对于负责 IT 项目的经理,
至少是 IT 的从业人员。一些概念性的知识必须知道才行。可以不知道如何写 Java 的类,但是如果连
什么是 Java, ODBC...都不知道就有些让人笑话了。感觉会是外行领导内行。所以如果是一个软件项
目,项目经理最好也做过程序开发人员;如果是系统集成项目,项目经理最好也做过系统集成项目。
2、钱袋权威:可以决定项目成员的收入分配;目前大部分的项目经理都不是职能经理,不具备分配员
工资源的权利,所以有时候会和职能经理发生在人员资源分配问题上的争论。
3、行政权威:有上下级的职位区别;
4、领导权威:个人魅力
5、官僚权威:熟悉公司的流程;熟悉官僚的制度,但不要做官僚;尽量帮助团队减少为了应付官僚
制度而付出的额外的工作。

·项目经理要不要懂技术(2006-11-03) [作 者] cao xi [公 司] Rockwell Automation

My opinion:
You should have a better understanding now you are the PM, not the technique guy though you
are eager to do that. There will be someone in the team who can do the technique more better
than you - what you need to do is to trust them and encourage them, do not push your own
idea on them, especially from technique side. or, the other guy will be frustrated by this.

2. Remember the world is not so perfect as you image. Not all things are 100% perfect even
though we'd love to. Pay too much attention on the perfectness of trivial thing will cost
you too much time and lost the overview for the whole project.

3. Communicate. Technique guy does not good at communication and does not willing to
communictate. Sometimes they have such idea that whenever they provide the result,the product
to user, they will be satisfied. They appear lost from user since the project begins, user
do not know what they are doing, managers do not know too. Even if, in one million times,
the project succeed, in 99% chance, this project manager will be fired.

In summary, a PM should have strong communication skill and harmonious skill, not the strong
programming or some other technique skill.

·资源整合(2006-10-28) [作 者] 王文晋 [公 司] 北京商之道投资顾问有限公司

1、善于留意周边关系资源和项目团队人员专长
2、善于安排和“求助”他人为自己出谋划策,有时候“装傻”也是获得帮助的一种手段

第 66 页 共 756 页
第 1 章 综合管理

3、善于用“宏观”的思想和别人探讨问题,使他人在意识上接受和配合你的“领导”
4、善于交付“具体实务权利”,当“甩手”掌柜

·抓大放小,关注重点(2006-10-27) [作 者] 王汉林 [公 司] 东软

1、关注重点里程碑达成,同时根据项目特点,将部分权力下放给项目组的技术负责人,由他负责项
目整体技术实施。
2、与客户、项目组人员密切沟通,随时了解项目进展和问题,组织人员及时解决问题。
3、不懂技术不要紧,重要的是能找到懂技术的资源来帮助自己。

·建议(2006-10-26) [作 者] 高华 [公 司] 中国石油

一、信心
二、知人善用
三、控制好关键技术岗位
四、加紧补习软件知识。

·项目经理对技术是外行(2006-10-25) [作 者] fdc [公 司] fdc

项目经理对技术一点也不懂是决对不行的。最低要求也应当明白项目在做什么,如果下面要做什么,
做成什么样都不知道你怎么来领导呢。
管理是在懂行的情况才能管理,如果你不懂,想做好太难。

·TEAMWORK!!!(2006-10-25) [作 者] Tony Neptune [公 司] SIPSC

项目管理不是一个两个人的事情,再有能力的人,即使你是一个项目所涉及的知识你全面都掌握的人,
你也不可能靠自己的力量把项目管理好。
TEAMWORK 是关键。充分发挥你的团队的各方面的力量,通过项目团队人员的沟通,了解团队成员的
每个人的长处。运用你的丰富的管理经验和亲和力,调动和发挥团队成员各自的优势。
给他们一片天地,放心地去干吧!!!

·技术与管理(2006-10-24) [作 者] Spike [公 司] 花旗银行

管理与技术本来就是资深 IT 的未来发展的两个方向,有时鱼与熊掌不能兼得,但是不排除额外的高
手。
但是作为一个管理者不能不懂得系统逻辑和业务,建议这位管理者加紧熟悉系统的逻辑和业务,明确

第 67 页 共 756 页
第 1 章 综合管理

开发者负责的模块以及具体功能。这是最基本的,否则,这位项目管理者能什么?

·管理第一(2006-10-23) [作 者] 安乃红 [公 司] AMDOCS-LONGSHINE

首先应该学习相关的专业知识,让自己对软件开发有更多的认识,这样对项目的管理帮助很大!其次
是充分放权,让有专业知识的认识具体负责项目运作;再就是要把计划制定的很好,同时要坚决的执
行进度跟踪工作。这个可以保证项目的进度在可控范围。最后就是建议还是设立一个项目技术负责人,
专门负责技术工作。

·PM到底要做什么?(2006-10-21) [作 者] 杨梦云 [公 司] 上海蜗牛有限公司

这个案例比较好,个人以自己经验来做一个分析

1、首先作者分析了相关人士状态
不熟悉软件开发及软件工作流程
为人亲和,领导力强
楼主没有分析该人士的工作年限及以前工作经验?这点是分析该人士是否能驾御该工作的关键分析

2、就楼上朋友分析,跟人比较赞同 daijiangbao (深圳市大视野项目管理有限公司


daijiangbao@hotmail.com)

首先我们还无法清晰确认楼主所提的是否是纯软件开发。还是其他类的软件(因为有很多领域的软件
开发只是项目工程里的一个子节,而非全部)

3、我们这样来分析,个人提几套解决方案

首先我提出几个分析要点,其实也上几位朋友没有重点提到的(!= 不等于逻辑符号)
想法!=产品
产品!=商品
点子!=解决方案
项目管理!=软件管理
人月 只是提出了一种软件项目思维方式,而不是提出了一套所有解决商业项目方案

1)纯软件环境的项目经理,个人还是推荐为软件人士担任,这是必要的
比如制作 erp,制作 cms,制作 windows 等纯软件等
以上软件属于硬性单纯性软件开发,不包含其他大含量工程,主要以软件人士为主导

2)如果是复合型项目,如
商业游戏

第 68 页 共 756 页
第 1 章 综合管理

互联网项目
flash 项目
其他复合性项目
教育教学软件
以上项目特征是 不是以软件开发为首要,而是一个复合性质工程,如商业游戏,包含了商业软件,
商业美术,商业策划,商业音乐 商业测试 等五个比较独立但又复合管理的环节
以上项目特征补充:每个环节都包含大含量工作内容及工作流程,且管理为独立即复合。不以软件人
士为主导,软件经理与美术经理是并行工作的职位,而非驾御

这是偶对带有软件项目开发的项目类的大类分类,本人主要从事商业游戏/教育软件/互联网 it/动画
等项目工程制作及管理

复合型商业项目经理,其对能力要求比纯软件管理更加复合及更加 功能要求多。自然前提他需要懂
一些软件工程管理的基础知识及软件开发流程及方式(这是必要的)。
西方认为项目经理 90%在用于沟通,而国内是道德+人治国,所以 60%项目经理应该是在做事,40%在
协调。

分析这个问题首先要抛弃主观意识,即只要是带有软件的必然为软件人士来管理。这是错误的。其次,
我们要抛弃纯西方理论,而应该考虑国情及国内项目的常规管理方式(项目管理首要是管人,而非管
事,如果看过 目标管理 能本管理 管理规则 这一套依据德鲁克及国内人对项目管理经验书的人应该
对这个有清晰认识)。

复合型可以增加一个技术总监职位,即使项目经理自身就是软件人才,也有必要,其工作职能为辅助
于项目经理进行软件部分管理,因为 复合型项目 30%管理软件,70%管理其他分类部门,可见软件在
其中只占了一定的作用,而非全部,各主要部门缺一不可。
自然技术总监职位可以与主程并列,或者是 CTO 直接担任

纯型软件项目,则不需要为项目单独设置技术总监,管理人士自身就必须是 软件开发人士担任(建
议长期性人士)。

这是偶做各种大型复合型项目积累的唯一经验看法。

复合型项目经理能力(skill)
1、项目管理
2、商务/渠道/公关/媒体运作 经验(至少都熟悉)
3、企业管理(含企业运作,企业行政管理)
所以说复合型项目经理能力要比纯软件经理要强很多,就在这里,也是必要
首先不要把希望寄托于 boss 和行政经理,他们各尽其职,人月这本书也提到 把适合的人放在适合的
位置

第 69 页 共 756 页
第 1 章 综合管理

复合项目经理就是战前指挥元帅
纯项目经理不过是战斗里的将军,还非元帅

至于为什么,长期从事复合项目管理的人深刻思考一下,就会发现你是辅助皇帝的元帅,而非辅助元
帅的将军

·项目经理对技术是外行,如何掌控(2006-10-19) [作 者] 文佳 [公 司] 大学

他虽然是没有这个方面的经验```不过他有做其他项目的经验``
这个对他都是很有用的```按照管理项目的那样也是可以管理好软件项目的```管理上的经验是通用
的```现在不是有些软件项目管理师也不是出自于学计算机的```他们能管理好这个团队```这个是关
键```任何软件项目都是在一个团队下完成的 ```项目的进度是在他的指导下完成 ``做过项目的是
都知道项目的流程的``进度更要看这个的团队的合作和团队的能力```就象 《人月神话》中的那样``
什么样的工作交给能做的人```这样就能做到分工合理```自己的 位置``篮球教练有的不也是不会打
篮球的``为什么他可以当篮球教练呢````同样的``不是技术员 就不可以管理一个技术团队吗````

·根据自己的经验总结(2006-10-19) [作 者] 张平 [公 司] aaa

1. 弄清楚各个项目干系人对该项目的期望,确定沟通计划;
2。在组建项目组时注意关键技术职位(如 SA)的人员任命,尽量用足够了解的人,以降低项目风险;
3。扬长避短,尽量发挥自己在沟通需求上的优势,以得到项目组的 buy-in;
4。项目进度方面:结合客户需求,项目组共同设定 milestone,跟得紧一点,采取集中 buffer time
的方式,让每一个小的 WBS on schedule, 大的 schedule 就不会偏离太大;
5.学习开发流程,毕竟这是一个很基本的东西

·个人意见(2006-10-19) [作 者] 姬中柱 [公 司] 北京正邦高科

我虽然是技术出身,可是现在也不参与具体的编程工作.在目前的公司工作压力越来越大,虽然我做的
项目都还很顺利.个人感觉,这是由于沟通,同公司领导层的沟通不够,没有能够有效沟通.时间越来越
长,问题就越来越严重

·非常好的案例,但是。。。。(2006-10-19) [作 者] daijiangbao [公 司] 深圳市大视野项目


管理有限公司

对软件开发来说,项目经理不是技术经理,懂不懂技术不是项目成功的关键。
一个重要的问题是,象这样的开发是纯粹的软件项目,连软件开发技术人员的技术能力也不是本质、
关键性的因素,不能完全用软件工程的方式来做,国内、国外的软件开发,尤其是应用开发,走软件

第 70 页 共 756 页
第 1 章 综合管理

工程的路,几乎都走上的是一条死亡之旅。这是个世界性的问题。
对技术人员来说,常常抱怨的是所谓的需求不明确的问题,因为用户的要求,原没有达到可以编写程
序的程度。
但是用户的理解,不需要到这样非常底层的地步,实现技术是最底层的事,不该是用户高层次的指导,
所以用低层次的技术眼光来看待高层次的用户指导,自然就会得出所谓需求不明确的荒诞说法,越是
强调技术,越是把技术工作做不好,因为狗眼太低。
另外就是软件开发的流程,在国内基本上就没有所谓的流程管理,流程管理的困难又划分为阶段内的
流程管理,但是大家可以从面向对象的所谓标兵-rational rup 过程来看到的项目管理是什么,纯
粹是撞碎了项目管理的阶段划分,整个是一团乱泥,还谈什么流程管理?这种开发拿去软件工程也许
无所谓,但是软件项目就彻底的失去了阶段控制,项目能成功才真是见了鬼了,但是绝大部分人确相
信,软件项目就得是这样的见鬼开发,不见着鬼反而是不正常的,从死亡之旅中回来的项目经理,有
项目成功的成就感吗?
所以对本案例,项目经理不懂技术完全应该得到鼓励,但是技术人员懂技术、但几乎不懂真正的开发
技术将是最大的问题,这个问题对软件开发的危害比项目经理不懂技术更糟糕的多,因为这是根本不
对。

·取长补短!(2006-10-19) [作 者] junhoo [公 司] sino

提供一个流畅的沟通平台,有关技术的问题让技术人员相互交流;
控制进程的关键点;
利用人际关系,为自己构建一个和谐的团队氛围;
你是纵观全局的掌控者,不要过于关注技术细节,但必要的基础知识还是要学习的,并且软件基础只
是很简单!

·用人(2006-10-18) [作 者] 车山根 [公 司] 九江学院

项目经理的主要是沟通,用什么和别人沟通是你现在的战略。
分析自己的优势和劣势。
用自己的长处去和别人沟通,在各个部门以及各个技术人员之间让他们主动沟通,你就是他们之间的
催化剂。
在技术这一关,你要用自己的时间学习流程,因为这样你才有更多的问题和技术人员交谈。
在人际关系上面,你一定要和技术骨干做成好朋友,用他们的技术来补充自己的不足。
最后,一定要有信心。

·有意思的话题(2006-10-18) [作 者] yyy [公 司] aaa

开饭店的老板就必须会做菜吗?
开软件公司的老板就必须会编程吗?

第 71 页 共 756 页
第 1 章 综合管理

管软件项目的项目经理就必须会编程吗?

想想饭店老板该做什么事?饭店服务员该做什么事?想想饭店厨师该做什么事?

·补充:修改一点(2006-10-18) [作 者] 相乡 [公 司] 南京

其次是不断学习,努力去学习,你会学到越来越多的项目管理者所需要的技术专业知识(不是管理知
识)

·信心和学习(2006-10-18) [作 者] 相乡 [公 司] 南京

本来不敢说什么的,因为我也是非技术人员做项目管理。
不过,还是说几句个人的感受吧,供借鉴。
前面几个都提到了知人善任,这个当然很重要。案例中的这个项目经理当事人和安排他的领导应该也
会考虑到此事。

我觉得,首先要有一种信心,因为即便是技术人员,他也很难在所有的模块都很精通,所以相信自己
不比其他的项目经理欠缺太多。因为项目经理的技术水平不够的失败项目案例目前还很少。
其次是不断学习,努力去学习,你会学到越来越多的项目管理者所需要的管理知识。把握好各阶段的
报告文档,文档我们应该还是看得懂的吧,这很有助于控制质量和自身提高。

因为没有了技术思维的羁绊,也许你的项目经理更出色。
努力吧,领导也许正在锻炼你从而以后委以重任呢。

·需求支持(2006-10-18) [作 者] chiao [公 司] 成都

对目前的软件环境来说,技术外行做项目经理很难。但不是不可能。首先得有强有力的支持,高层的。
如何让下面的也证实项目经理的存在呢,对开发流程不能不熟悉,这个是最起码的要求。
然后要有好的开发经理或是系统工程师的支持,项目基本上可以运转起来。
其次就是项目经理要做好整个项目间的沟通交流等。

·我的建议(2006-10-18) [作 者] 陈锋 [公 司] SEVEX

1.知人善任很重要,借助他人的技术专长,让这个专家感到受到充分信任和授权.
2.在项目推进过程中,自己也要努力学习,提升自己的不足,与专业人士合作,并发挥自己在项目管理
上的整体掌控特长,达到双剑合璧的效果.

第 72 页 共 756 页
第 1 章 综合管理

·我的建议(2006-10-17) [作 者] 储知君 [公 司] 沪东中华造船集团有限公司

跨行业主持项目虽然是非常困难的事情,可是这也是成为优秀项目经理的必经之路!
首先,在开始项目之前,要了解项目小组中的技术专家;了解内容很多,比如他们最擅长的技术,他
们各自的个性和工作态度,他们的喜好等,总之要尽快将手下的技术方面的干将摸透;
其次,在知己知彼的前提下,采用相应的方法以收其心,彼之所欲,我先予之;不愁此猛将不为己出
力,有技术专家忠心效力,还愁自己不懂技术吗?
其实说到底,就是要知人善任,懂得沟通,懂得如何激励手下能人倾力而为!

·我的建议(2006-10-17) [作 者] 于佳 [公 司] 不提供

手下用有两个干将:
一、资深的需求分析员,帮助你做好需求分析工作,确定项目范围与边界,跟踪与管理需求变更。
二、资深的技术负责人,帮助你管理开发人员。做好项目架构,帮助解决技术难题。

·向毛泽东学习(2006-10-17) [作 者] daijiangbao [公 司] 深圳市大视野项目管理有限公司

pmbok 不容易看透该问题,建议去深入研究中国版的 pmbok-毛泽东选集,尤其是第一卷。


毛泽东戎马一生,确是个连枪都不会打的人,也就是说不懂一点技术的项目经理,但没有人说毛泽东
的项目不成功。
至于为什么毛泽东思想就是项目管理,从 pmbok 的观点认真看明白了就清楚了。
另外就是,软件工程不是软件项目,有极大的本质差别,尤其不能选择时髦的垃圾-采用迭代的方式
进行开发,是完全有悖于 pmbok 和毛泽东思想的。

·我的意见(2006-10-16) [作 者] Alan [公 司] 不公布

建议找一个团队中较为资深的程序员,做为开发经理,负责开发流程方面的设计、及对客户需要的引
导,直至形成最终的双方认可的质量标准

您的问题已经覆盖了项目管理的大多数内容了,简单的说,作为非应用领域的专家,只能去用好人,
当然,在启动的时候要有良好的沟通管理计划,什么事情汇报到什么人,减少在技术方面与程序员的
直接沟通。

第 73 页 共 756 页
第 1 章 综合管理

1.10 半路接手项目,遇到的问题

半路接手项目,遇到的问题

[姓 名] wangyiying [单 位] ZTE [邮 件] wangyiying@hotmail.com


[所属行业] 综合应用 [所属主题] 项目综合管理 [发布时间] 2006-9-25

【案例正文】
由于前任项目经理高升,同事 A 被选择做一个进程已过半的项目。

领导 B 在任命 A 做项目经理的时间,介绍说:此项目一切顺利,只要改动一下程序,
完成最后一阶段测试就大功告成了。但事实是,原 PM 没留下任何文档记录。已完
成的工作也没有文档固化下来,结果是客户要求改动的程序不是一点,而是很多,
而且本以为原来已完成的部分也有很多遗留问题,尽管 B 又给 A 的项目增加了资源,
但最后的结果是由于项目范围蔓延严重,没有达到预期的目标。

A 受到了领导的批评。麻烦各位专家帮忙分析一下,作为半路接手的项目经理,A
做错了什么,他应该怎样做?

【相关分析】

·高管B错了,您能够这么着?只能挨罚挨骂。(2008-07-23) [作 者] xieshiling [公 司] 济南科技有限公


1、从背景看,前项目经理是高人,项目进展到这种程度还能够高升,个人有背景或者有特长,能够
一俊遮百丑。
2、接任的项目经理 A,没有办法,只能先挨骂再说,否则,还会被前项目经理穿上小鞋。如果现在
的项目经理按照前面很多的分析说的,了解现状,整理信息,呈报上级去认识该项目的真相,估计会
引起很多后患,会存在给人印象不好,除非你能够做得更好。
3、项目经理 A 错了,错在机会不好。
4、项目经理 A 还是做了很多工作的,比如追加了资源来处理,结果还没有处理好,问题就是项目经
理 A 是该挨骂了,估计经验是不足的。下一步如何做,只能是多吃亏,多挨骂,才能够解决这个问
题。

·如何做好替罪羊(2008-07-14) [作 者] aaron [公 司] 公司

背景分析:前任项目经理带领的项目,领导 B 的看法是:此项目一切顺利,只要改动一下程序,完

第 74 页 共 756 页
第 1 章 综合管理

成最后一阶段测试就大功告成了。而事实是:原 PM 没留下任何文档记录。已完成的工作也没有文档
固化下来。
这说明前任项目经理有背景的可能性最大,公司管理也混乱,一个项目竟然没有任何文档,或者有文
档也不移交。
同事 A 接管项目后的工作个人认为从这些方面进行:
1、如同事 A 原来不是在此项目,他可以先通项目组成员逐个沟通,了解项目的现状;同领导 B 沟通
获取一些能获取的项目资料;同客户沟通了解项目的整体情况;
2、项目组成员按原安排工作;
3、写一份项目现状分析报告提交领导 B;
4、同客户沟通,根据目前项目形成一份工作计划;
5、获得许可后,按新计划执行。

·职场公交车(2008-07-01) [作 者] 沃双喜 [公 司] 西屋

新的项目经理 A 在中途好不容易坐上座位,可惜还没坐热就到终点站要下车了。这是职场的规则,
只可惜没能早坐上座位,所以运气不佳。
领导 B 看来很自信,但是他对项目的理解,管理和监控远远不够。否则,不会什么文档和记录都没
有的。遇到这样的领导和这样的时机,的确很有挑战性。
如果我是 A,当我接手时,如果没留任何资料,唯一的办法就是找项目组员了解项目进度,以及里程
碑。都有什么输出,尽可能的找,也要和客户侧面了解,最后列个清单和领导 B 用事实谈。
其实我也是新手,从质量转到项目不久,也只能从方法上谈。还请各位多给指点

·借鉴(2008-05-28) [作 者] 黄赟 [公 司] 赣州城建市政工程管理有限公司

我认为 A 接受后应该做以下几件事
1、对该项目做全方位的详细报告
2、对该项目需完成仍存在哪些问题
3、针对这些问题需如何去处理
4、可能存在的风险,如何规避或降低

·face the real world(2008-05-06) [作 者] daniel zhang [公 司] Shawgroup

I guess this is the real world we all have to face everyday


1. how often the senior manager will come in without knowing detail of the project and say..you
JUST/ONLY need do this, it is SIMPLE;
2. how often you have to be nice to your college esp manager even though you know, it was wrong, and they
are lying?
3.how often we DONOT know the real progress of project, what is percentage completion by the meaning of
REAL progress? so when people say"oh we almost done" means really almost done.
4.how often we got loose on contract and change management, so keep things slipping and make us look
bad????

第 75 页 共 756 页
第 1 章 综合管理

if you have seen all these problems here...is it all the problems we face EVERYDAY?
is it a suprise? not really?
so what is the problem?
there is only one solution for this: speak out or communicate it...
tell the bad news, lower senior manager and client's expectation, if they think you start
from 90, they expect you finish at 100; if they know you start fromm 50, they expect you
finish at 60, and they still happy.
happy boss and happy client are only measurements for project success.

·做法(2008-04-21) [作 者] 李敏策 [公 司] 杭州天夏

1、仔细查看合同、招投标文件后与可户协调确定项目范围;
2、与项目组成员讨论确定项目进度及遗留问题、解决方法,确定下一步的目标(呵呵,个人认为最
好大家一起吃个饭喝点酒,熟悉熟悉后,有什么说什么,发泄以下不满后,会比较好沟通,特别是这
种烂项目,大家都比较郁闷的);
3、与领导汇报说明项目现状及难度,仔细沟通并努力获取支持(比如可户提出比合理要求,这里就
需要公司派出商务人员来搞定,不要自己死撑着)。
4、所有问题纸面汇报,收到的人必须签字,以便有据可查。

·从行政上来看(2008-04-21) [作 者] 李敏策 [公 司] 杭州天夏

从行政角度来看,领导 B 不可能迟钝到这种程度;除非前经理从来没有如实汇报过工作,这就说明了
一个问题:前经理是领导 B 的心腹或者是领导 B 的领导的心腹,反正就是 B 要么管不了前经理的,要
么就很信任前经理的。
从作者描述来看,这个项目绝对是没有前途的,因此的出的结论是:此次临阵换将是为了保全前经理,
A 根本就是一个替罪羊。
A 最好的方式就是列出需要得到的信息及必须领导签字确认得到了多少信息(没得到也行,但必须让
B 确认该项信息没有得到);然后再与各方沟通,努力做好范围控制和进度控制,有问题及时上报 B,
不要不好意思,因为没有了后顾之忧,做起来反而能放开手脚,说不定真能把烂项目做好。
最后,如果每做好,反正前面已有铺垫,也怪不到你头上;做好了,说明你很有能力,换个环境吧,
这样的领导不适合你。

·被动防守 or 另辟蹊径(2008-03-08) [作 者] 李智攀 [公 司] 上海交通大学

A 接到这样一个棘手的项目,也的确不好办.
不过站在一个客观的角度,我觉得 A 有几处没做到位的地方,
1. 既然领导跟他讲了此项目很顺利,仅需改动一点很快就结束了,但领导对具体细节并不清楚,然而

第 76 页 共 756 页
第 1 章 综合管理

当 A 发现原 PM 没有留下资料与记录的时候,未能及时的与领导反应情况,而是一味的亡羊补牢,不去与
上级或是原 PM 及时沟通.
2.接手后是否沿用之前的 WBS,还是根据实际情况进行了修改,不合理的 WBS 导致范围蔓延严重.
3.接此项目之前,A 并没有进行细致的考察,或许前 PM 也觉得没做好,有机会高升,故意把这烂摊子扔
给哪个替罪羊也不一定呢.

·混乱的秩序、混乱的思维(2008-03-07) [作 者] 莫学赶 [公 司] 浙江邮海电子有限公司

我也曾遇到与你类似的问题,不过我是旁观者,不是当事人。

当时我们公司接手另一公司的工程,经过二次转手的,而且我们公司只是出清工。做这种事情,我本
人觉得就比较窝囊。偏偏我们内部管理也比较混乱,工程做到一半,就把负责人(A)调去培训,另
一人(B)来接手继续负责。其实这何谈负责,就甩手掌柜嘛,儿戏一样的。A 培训回来,B 很知趣,请
长假让位,这样 A 又重新接管。期间,又有诸多因素致使工期延误比如:1、承包公司与各负责人可
能沟通滞后或有断层(因为我们这经常换将),所以常返工;2、承包公司供应的材料根本不如期如
数到场;3、有些细部没做,A、B 两人竟没发现也没沟通,当然这样肯定不能通过验收。后来一塌糊
涂的失败。

说来是不是很窝火?难道他们没读过 ISO9002?

·人在职场,要注意保护自己(2008-01-22) [作 者] 周预 [公 司] 湘潭

首先提出以下观点:
1、临阵换将,大忌!对于项目组成员而言,需要适应一个新领导的行为风格,对于项目经理,又有
一个熟悉项目环境的过程,无疑增加了项目的风险,尤其在一个制度比不完善的企业内。但企业战略
需要如此,只好将就了。
2、企业的项目管理制度方面存在严重缺陷,作为一个软件企业,文档管理、范围管理、质量控制、
配置管理、合同管理等制度基本上没有或者流于形式,项目成败完全依赖于项目经理和成员的个人能
力,难有制度保证。
3、企业人力资源管理和绩效管理体系存在问题,提升一个问题重重的项目领导,又何以服众,又何
以满足企业的战略目标,明升暗降还可!

项目经理错了,错在以下几个方面:
1)工作交接过于轻率或经验不足。项目的移交必须由双方签字和双方的主管领导签字,移交了哪些
资料应书面记录已备将来分析责任之用。在本项目中,A 明显经验不足,连起码的文档都没有就接手,
挨批也不能怨天尤人了,吃一堑长一智吧。当然信息不对称也是一个原因之一。
2)不敢说“不”。对于这个项目而言,如果 A 在接手手续时,就知道项目资料不全,并预知项目风
险过大时,就要敢于说出自己的想法,要求前任提交必须的资料,切不可以以为领导提拔了自己,不
好意思也把不敢也罢说出自己的想法,尤其是前任项目经理将提拔为自己的上级时更是为难。这样往

第 77 页 共 756 页
第 1 章 综合管理

往吃亏在自己,卖了力还不讨好,要敢于表达自己的不同意见,毕竟先小人后君子嘛!至少比勉强接
受,后又挨批哑巴吃黄连强,要学会保护自己!
3)项目管理经验不足。在发现项目文档欠缺时,A 接手一个项目应先会同客户和本公司的商务及前
任项目经理确认项目目标和范围,达成共识,并文档化形成项目工作基础。

建议:A 应该这么做:
1、做好交接工作,移交清单应双方签字认可,可能的话应请双方主管确认,对于交接中发现的问题
应及时沟通,告知领导,切不可碍于面子,中国古话说得好,先小人后君子。
2、认清形势,由于信息不对称,A 不可能一下子发现项目的问题,应尽快熟悉项目,可以采取与项
目组成员、客户、商务等沟通,听取他们的建议意见看法,然后作出正确判断:
a)同项目组成员沟通,项目组成员熟悉项目工作尤其是本职工作,争取他们的支持并达成一致意见,
听听他们的坦诚的建议和意见,有点困难,需要一定的沟通技巧。
b)同客户沟通,理解他们的需求和期望。
c)查阅整理资料,包括商务合同等,确保对项目状况形成一个清晰的判断。
d)及时向领导沟通,报告项目状况,确保领导对项目有个清晰的判断,让领导认识问题的严峻性。
当然这样做容易造成人际关系紧张,需要权衡利弊和沟通技巧。
3、接手一个项目应先会同客户和本公司的商务及前任项目经理确认项目目标和范围,达成共识,并
文档化形成项目工作基础。
4、以项目目标和范围说明书为基础,进行项目绩效评估,重新进行项目计划调整,并争取公司支持
最佳必须的资源,争取客户理解和谅解,达到一致认识,并作为前一段时间工作的基线记录下来。

·A的失误与启发(2008-01-16) [作 者] 李永新 [公 司] SAP company

A 做为半路接手的项目经理,A 范了以下几点错误:
1、A 接手项目时没有与前项目经理进行充分的沟通,没有整理遗留问题,导致对项目一知半解的.
2、A 接手项目后没有与客户进行有效的沟通,没能控制项目的范围、及时控制客户的需求,导致客
户需求不断增加,增加了项目的难度.
3、A 接手项目后没能制定合理与有效的计划. 计划是有效实施的工具,具体明细的计划能够很好的
控制项目实施的进度. 如果 A 提前把项目风险分析与计划安排提早告诉 B,也就不会事后受到 B 的批
评了.

对于半路接手的项目经理,我觉得应该这样处理:
1,交接的时候把前任项目经理手上的资料或者是告诉你的内容尽量的记录和保留。(如果不完整也
没有关系,因为有可能他自己很多东西也没有记录或者保留)
2,项目交接后,召开项目小组成员碰头会,将项目的所有第一手资料进行整理(比如项目目前最新
状态等信息)
3,会后,将以上的资料进行整理和分析,如果还有什么不清楚的地方,再找人单独谈,或者与以前
的项目经理联系。
4,对于整理好后的项目,需要重新拟订时间节点,对项目的最基本的资料再次发给项目小组进行统
一。当然时间节点要提交给领导以及客户的项目经理进行知悉。

第 78 页 共 756 页
第 1 章 综合管理

5,接下来就是以前的一些非关键文件的补充和查找,这个可以自己补充也可以多方面搜集。对于客
户需要回签的文件,必要时找客户对应的联系人进行沟通索要。

·同情这个小A,质疑这个高管。(2008-01-15) [作 者] 逍遥游 [公 司] 某项目管理顾问公司

遇到这个的高层主管(A 和 B 项目经理共同的领导)有些来气:
1. 这个项目恐怕不是什么重要程度高的项目,否则不会临时更换项目经理,原项目经理也不会这么
轻易抛弃自己辛苦培育的项目。看来这个项目是鸡肋。
2. “原 PM 没留下任何文档记录。已完成的工作也没有文档固化下来,结果是客户要求改动的程序不
是一点,而是很多”说明这个公司项目管理流程有些乱啊~,这不是项目经理的问题,指头应该指指
这位“高层主管”,这样你就让 B 项目经理高升了?换哪个项目经理能够在这样的情况下做好?如果
幸好做好了,那么这个残缺不全的项目会不会也将在未来的项目升级时候出现问题?你的项目流程管
理咋整的~,从这个角度看,小 A 是个替罪羊。
3. 高层主管在更换项目经理的时候,其交接的质量是有问题的,没有的文档应该补齐,高层领导应
该对交接的质量把关并签字确认,而不是事后让他们给予相互的支持。
4. 高层主管找到的这个替补项目经理,恐怕也有练兵的意思,替补项目经理 A 也有了这个机会来证
实自己的能力,只是他证实了自己是硬汉,而不是个“成熟的”PM――发现了那么多缺少的文档,完
成部分有缺陷,需求的变更,拜托扛不住就不要死扛啊,多向领导反映,多诉诉苦,将丑话摆在前面,
将风险提前告诉高层主管,如果这么做了,高层主管有何批评的?
5. 半路接手的项目风险大,原先项目组成员也会有动摇怀疑,最好的办法是即使新任了项目经理 A,
原先项目经理 B 也应该留在项目里面做项目副经理,指导协助完成这个项目。待验收后,再脱离这个
项目。
6. 对小 A 报以深深的同情,头上的包碰的多了,也就成熟了,小 A 还是多碰早碰几个包好!

·多种对策(2008-01-06) [作 者] dajundalao [公 司] 暂时保密

如果 A 是沉稳型的,他接手项目的第一件事是对项目当前状况做一个全面盘点,明确现状、已完工作、
正在进行的工作及其进度、未完工作、与业主方沟通中潜在的工作等,有了这个明细,A 就对 B 有一
个总的交代,B 批评 A 是不可能的,事实在此,B 只有在先否定事实后才能批评 A。
如果 A 是职业型的项目经理,他会在接手后抓住关键问题,与原项目做一个很好的对接,从而保证项
目按原来管理模式动作、延伸,同时对业主进行全面沟通,定位业主需求与合同及原来关于项目范围
的资料作比较,并书呈 B,从而避免范围蔓延,保证项目成功。
如果 A 是意气型的项目经理,从大包大揽开始,不从细节入手,如果不给他配置原来他那帮得心应手
的人来打开局面,那么本案例中的结果在等着他,受到批评是轻的,严重的可能会受到更加严厉的处
分。
如果 A 是权变型的项目经理,他会把各方面关系处理好,把各类问题处理好,控制范围蔓延,控制好
“三角”,顺利甚至超值实现预期目标。
以上为分析的四种人,也相当于是四种对策。

第 79 页 共 756 页
第 1 章 综合管理

·列出清单(2008-01-01) [作 者] wishmadison [公 司] 中国

用一个文档, 列出你需要了解和在项目后期需要使用的所有信息, 和前任项目经理一起按照文档一


项一项地了解其完成情况, 完成的确认, 未完成的或不能提供的做标识. 然后根据相关情况对项目
进行重新评估, 预估风险, 并报上级领导.

·继往开来(2007-12-27) [作 者] 江西早 [公 司] 兴库建设投资有限公司

首先,友好认真地与前任沟通,就该项目继续进行请教他(她)的意见是最重要的前提.沟通中要坦诚和
信任为主,最好能建立友谊取得帮助,这对自己尽快准确掌握项目表面与潜在状况非常有帮助!也对前
任的关系层面继续转过来关心你的工作有意想不到的作用.
其次,在前任的参与支持下与项目团队见面,稳定团队情绪和士气.确保项目稳定推进.好比一条划到
河中的船,你必须依靠船上的人继续努力化向对岸,否则稍有懈怠,船就有可能加速漂离目的地.
最后,迅速验证情况,再根据实际进行调整.
总之,所有的管理,应该以不变为基础,除非确认非变不可或非紧急改变不可时,在顺应工作之需予以
改变.很多时候新人总是急于求成,急于表现自己,往往自己把本来可以转好的事拖差;把本来已经走
向光明的事情耽误,最后却归罪于前任.
事实上今天我们是继任者,或许明天我们自己就是前任.建议多考虑以下前任,并不妨碍继任者在未来
创新管理,毕竟未来总是属于年轻人!

·听听员工和客户的意见。(2007-11-30) [作 者] 黄明秀 [公 司] 北京三箭电子有限公司

看了大家都在发言我也想说几句。
1。首先把项目的最终目标和最终时间搞清楚。
2。搞清现阶段项目停留在哪里。
3。目前项目存在的问题。
4。听听员工和客户的意见。
然后深入分析加以总结,计划剩下的项目。

·下一次接手时你就这样做(2007-11-29) [作 者] snock [公 司] 广州某软件公司

1.了解项目总体目标.及公司和客户各自对这个项目的看法和期望.
2.深入了解项目目前的状态,进行全面总结.
3.重新制定一份项目行动计划,依据项目计划依次交付成果.(需要注意:每一次交付成果应该是可用
的)
4.对于中间的需求与范围变化,应走变更流程.

第 80 页 共 756 页
第 1 章 综合管理

·在接手前做好项目分析报告(2007-11-22) [作 者] 亭长 [公 司] 北京易事通科技有限公司

1、首先和前任项目经理(还在的情况下)做好项目的交接工作,尽量细致全面,同时要和客户进行
沟通了解整个项目的情况,以及目前的运行状况。
2、整理编写项目分析报告,在报告中指出项目的风险,以及存在的问题,将情况如实汇报给领导,
使领导层能清楚了解项目情况。

·慢慢来(2007-11-21) [作 者] sdc1009 [公 司] 山东创业房地产开发有限公司

我与你的处境差不多,也是刚刚接手了一个项目。由于对项目的当前状况了解的不够充分,也就接手
了,现在项目部的管理混乱。计划、目标、监控、执行等等,等等,一切全无,可以说是一塌糊涂。
怎么办?

·引以为戒(2007-11-19) [作 者] 刘海艳 [公 司] yf

很好的案例.学习中.
项目经理接手这一项目的第一件事是先澄清项目状态,第二,对项目工作下一步的详细计划,得到领导
的审批,就不会有现在的情况了.

·做好交接工作(2007-10-31) [作 者] 陈欢 [公 司] 汉隆

:) 这种情况还没遇到过,不过不敢说以后不会遇到,还是先学着点。楼上说的做好交接工作,很值
得学习。甚至可以延伸到其他工作领域

·半路接手的项目(2007-10-31) [作 者] 蒋振廷 [公 司] 算了

在一些小的软件公司或者是一些半路出家的公司来讲,项目的开发没有一个整体的流程,没有一个系
统的开发规范来说,出现这样的情况是正常的,但是我们要怎样解决这样的问题呢!
1.心态要正确,无论我们的项目最后成功了还是失败了,我们要认识到的是,这都是成长中的一些积
累经验的过程,不要有心理负担。
2.搞清楚自己的处境,项目是处于一个什么样的状态,沟通的结果自己要有正规的文档,在没有搞清
楚现在项目是个什么样子,项目要搞成什么样子的时候,不要轻易的就动手前进。
3.人和人之间看问题的方式和深度是大有区别的,因此不要轻易的认为自己懂了。
4.小蒋的格言送给你“正人先正己,做事先做人。”

·半路接手项目(2007-10-31) [作 者] Justin Wang [公 司] 宁波宁海

第 81 页 共 756 页
第 1 章 综合管理

楼住,你好!
你和我遇到的情况一样啊!
对于此事情我是这样处理的:
1,交接的时候把前任项目经理手上的资料或者是告诉你的内容尽量的记录和保留。(如果不完整也
没有关系,因为有可能他自己很多东西也没有记录或者保留)
2,项目交接后,召开项目小组成员碰头会,将项目的所有第一手资料进行整理(比如项目目前最新
状态等信息)
3,会后,将以上的资料进行整理和分析,如果还有什么不清楚的地方,再找人单独谈,或者与以前
的项目经理联系。
4,对于整理好后的项目,需要重新拟订时间节点,对项目的最基本的资料再次发给项目小组进行统
一。当然时间节点要提交给领导以及客户的项目经理进行知悉。
5,接下来就是以前的一些非关键文件的补充和查找,这个可以自己补充也可以多方面搜集。对于客
户需要回签的文件,必要时找客户对应的联系人进行沟通索要。
6,接下来就是按照计划执行,一切 OK!

·总结项目(2007-10-17) [作 者] 菜哥 [公 司] 保密

在接手时,通过和前任的沟通,做一个项目分析报告.从项目时间质量成本角度把目前项目的状态汇报
一下.同时借此把目前所有的问题暴露给领导.同时积极考虑解决措施,避免重蹈覆辙

·半路接手项目(2007-10-16) [作 者] 宋华先 [公 司] 秦武田制药

半路接手的项目往往出力不讨好,项目顺利完成,归功于前任项目经理计划开展的好,打下了好的基
础;出了问题,则是后任项目经理管理不善而导致。此项目的客观环境是公司没有严格的项目变更资
料交接制度。那么后续项目经理能做的就是和前任沟通,充分了解项目的信息,如果前任不甚配合,
则组织项目组成员重新讨论该项目,把其当成一个新的项目来计划安排,讨论后将问题及新的进度计
划报领导审批,备案。
对此项目的关键是一定要有书面的交接或批示。否则,有口说不清。最后擦不干净还沾自己一身。

·不是做错什么,而是应该怎么做?(2007-10-06) [作 者] zgl [公 司] 浙江**置业集团

你朋友的项目应该说跟我的项目差不多,不同的是我接手的是工程类项目;我觉得现在谈什么做错什
么已经是太迟了,应该去分析这个项目在管理上最大的缺陷是什么?从而去弥补缺憾,避免重蹈覆则,
我认为你朋友没有作好交接工作及信息的沟通与交流,缺少信息库的建立和运用,就象我们工程上的
工序交接和技术交底!

·一点个人看法(2007-09-27) [作 者] 崔吉宏 [公 司] 中原油田

第 82 页 共 756 页
第 1 章 综合管理

在工作交接过程中,新人没能在了解整体概况的情况下,就匆匆上马。信息了解不够。再者,新人最
好在领导的支持下召集前人和业主开对接会。

·赚点币(2007-09-18) [作 者] 松 [公 司] 天啊

多拿点分 可以方便下载大家的高见
或许....
确定一定以及肯定
我不否认否决以及否定
加油

·半路接手项目(2007-09-18) [作 者] 张建 [公 司] UNEDET

遇到半路接手的项目,首先应该分析该项目的执行情况,进展如何,有哪些问题,以后还有那些工作
等等,摸清楚情况,然后制定工作计划,并向领导汇报,(可能需要一定的时间)一定要把项目的风
险提出来,这样才能做到心中有数,另外,一定要取得领导的支持,无论是资源上,还是资金上等等。

·半路接手项目,遇到的问题(2007-09-08) [作 者] 罗忠艺 [公 司] 成都全友家私有限公司

1、我认为项目经理的突然升职,把一个在半路中的项目交给其他人来做。这样的情况应该避免发生,
因为项目具有太多的不确定的因素。再言,在一个项目中,由于前一个项目经理在做项目的时候没有
对在项目过程中所做的事情形成文档,这是前一个项目经理最失败的地方,一个项目不管他的成功与
否,必须做的就是项目文档的管理,把项目中遇到的事,做的事都形成文档,对以后的人来所是个借
鉴和只是沉淀的必然过程。
2、现在 B 领导叫同事 A 来接手这个项目,很显然他听了前一个项目经理的一面之词,说项目还有最
后一点小小的程序修改。最好了就大功告成了,很显然 B 领导没有这方面的经验,他不懂项目管理。
在系统修改一个小小的程序很有可能导致项目的失败,所以他应该叫前一任项目经理写个具体的交接
报告什么的。
3、对 A 来说,完全是糊里糊涂的接手了这个项目。他应和前一任项目经理进行详细的沟通,对先前
做的工作进行总结,分析相应的环节对以后会产生什么样的影响。对以后的工作进行一个详细的评估
形成一个评估的报告,然后对在项目规定的时间内,利用领导给定的资源,看能否完成项目范围、项
目的质量等。

·Hearing , looking ,analysising, then do it.(2007-09-05) [作 者] 张继林 [公 司] perlos


co.,ltd

1. need finish the handover through soft way, it is buffer to understand situation.

第 83 页 共 756 页
第 1 章 综合管理

2. Need call all of team member to hear some suggestions


3. Make risk analysis report and anctions to higher level,then make plan to implement.
4. To communicate with clients what's to do next step.and find some supports from higher
level as necessary.
5.monitor all of key points ,and take actions once accidnents happen.
6. Don't foget to get support from direct Boss.

·半路接手项目,遇到的问题(2007-08-30) [作 者] tjh [公 司] cxgs

中小企业尤其是私企比较常见这种问题。一方面需要注意处理好人际关系,防止老板偏听偏信,也避
免自己成为牺牲的羔羊。另一方面,以积极心态 PA 投入后续工作中,逐一解决问题。同时可以重新评
估该项目,制定分析报告和详细实施计划,主动和各方沟通

·一点简单看法(2007-08-29) [作 者] xylxyh [公 司] njmcc

本人粗浅看法,A 主要问题在于对项目交接的认识不够。
1.作为接手项目的管理者,没有能够完成项目交接的目的。
2.与上级也没有及时沟通,让其了解项目实际状况。
3.需求变更的部分要具体评估,分阶段完成目标。

·看法就这 先赚点分(2007-08-26) [作 者] lwghui [公 司] sddsasdadsadsa

中小企业尤其是私企比较常见这种问题。一方面需要注意处理好人际关系,防止老板偏听偏信,也避
免自己成为牺牲的羔羊。另一方面,以积极心态 PA 投入后续工作中,逐一解决问题。同时可以重新评
估该项目,制定分析报告和详细实施计划,主动和各方沟通。

·比较常见 关键还是要忍(2007-08-26) [作 者] lwghui [公 司] sddsasdadsadsa

中小企业尤其是私企比较常见这种问题。一方面需要注意处理好人际关系,防止老板偏听偏信,也避
免自己成为牺牲的羔羊。另一方面,以积极心态 PA 投入后续工作中,逐一解决问题。同时可以重新评
估该项目,制定详细实施计划,报老板批准重新来过。

·看清问题 积极心态(2007-08-26) [作 者] lwghui [公 司] sddsasdadsadsa

中小企业尤其是私企比较常见这种问题。一方面需要注意处理好人际关系,防止老板偏听偏信,也避
免自己成为牺牲的羔羊。另一方面,以积极心态 PA 投入后续工作中,逐一解决问题。同时可以重新评

第 84 页 共 756 页
第 1 章 综合管理

估该项目,制定详细实施计划,报老板批准重新来过。

·冷静分析(2007-08-26) [作 者] 吳春華 [公 司] 中鎂科技

从其案例的描述中,我有以下几点看法:
一,未对公司的项目管理工作室的工作制度进行改善及公司的相关信息的了解.例如,未对项目的资
料进行备案或做相关的记录,这是做项目管理工作中的一大大嫉.这也是导制B失败的导火线.
二,对交接工作的草率,对交接工作的形式不重视.
三,未对客户的相对的窗口进行交流.
四,主要是B对项目管理的工作经验不足的表现.

·了解项目的所处阶段与目前的状况!(2007-08-25) [作 者] 董新山 [公 司] 荣文灯饰(东莞)


有限公司

作为半路接手的项目经理,首先了解项目所处的阶段,与目前的问题真实情况,再目前真实告诉领导,
这样让领导知道你接手时的情况.最后,再针对问题进行解决,不让自己在领导面前受批评,同时也不
会让项目出现那么多遗留的问题无法处理!

·没有做错,只是命背!(2007-08-21) [作 者] 朱兵 [公 司] 中国核工业华兴建设有限公司

1、首先领导受到前任项目经理的误导,认为项目成功,注定了 A 的失败;
2、半路接手前要考察事实的真相,一定要前任将资料等交接完全;
3、高升的诱惑是大的,但是第一个项目被人设套一样的钻进去,不爽;
4、不认命的会积极与客户沟通,作出成绩来回应领导的信任。

·半路出家难(2007-07-26) [作 者] 陆莎 [公 司] 广州京华网络

其实大多数项目经理应该都是十分痛恨半路接项目(包括我在内)。但是公司领导发话,又不能不做,
那么我认为应该从如下几方面进行:
1、完善的交接:交接不仅仅是说两句,还要包括各类文档,各种相关人员的关系分析等等,都是要
交接的内容。同时前任项目经理还应当起到一个引路人的作用,帮助接任项目在客户面前建立权威,
避免后续项目经理在客户面前没有地位。
这个案例中,前任项目经理根本没有交接相关文档,而后任项目经理也没有检查文档等内容,这已经
成为隐患。
2、后任项目经理接手后应当首先与客户确认后续工作,每个人的做法都不同,及时与客户沟通,确
认项目情况,是很重要的。即使没有接任一说,随时确认项目进展也是必要的。
3、确认了后续工作后,应当分析后续工作的风险,通过分析,确定是否能在预期时间内完成,如果

第 85 页 共 756 页
第 1 章 综合管理

能则皆大欢喜,如果不能,则要分析原因,并且汇报给公司领导,至少要领导知道困难所在,不至于
出现后续的责难和批评等。
4、最后,就是和客户谈判了(实在不行,拉领导出来讲数),尽量减少开发量,控制项目范围。

·这么好的机会(2007-05-01) [作 者] 陈晨 [公 司] 河北保定智能电脑有限公司

提升了项目经理,呵呵好事情。
内容没有交接,这就是现状。
该怎么做呢?做好该做的事情。
项目经理走了,开发人员没有走。所以进度还是继续下去。
唯一就是 A 兼有了开发和项目经理的双重角色。
担子重了就要努力。
任何时候不要闷着头做事情。不过做技术的比较难突破这点。我就突破不了。
了解完情况后,根据情况 A 做一个详细计划,跟原有项目进度计划比较,呵呵原来没有就太好了。把
需要做的事情罗列清楚,然后交给向领导请教或者请求批准。领导看出你的把戏,但是也会理解你的
难处。你唯一现在要做的就是按照自己制定计划去完成他。请求一些资源用来与现在开发人员沟通。
领导肯定会支持的。身份变了职责也变了,要快速适应它,否则就是坐失良机。

·半路接手项目,遇到的问题(2007-02-11) [作 者] Bell [公 司] 惠州CK

1、找前任 PM 或其上級了解該項目的范圍,時間,進程,成本等方面的詳細信息。2、根據了解狀況,
重新審視該項目,並制定項目計劃。3、與項目成員積極溝通,以便盡快創熔入該團隊。4、與客戶溝
通,闡明項目的變更。及了解客戶的最新需求。

·积极投入、问题逐一解决(2007-01-24) [作 者] flyracer [公 司] **北京

积极投入项目工作中,对问题采取逐一解决.
1、全面了解接手项目时项目的情况
2、与前任项目经理全面沟通,协助完成已完工的资料和情况。
3、与用户全面沟通。
4、对项目进行重新评估。制定一份详细的实施计划,报公司领导,批准相关资源。
5、严格按计划控制

·积极应对(2007-01-10) [作 者] 马泽坚 [公 司] 贵州***科技发展有限公司

不管存在任何因素,既然已经接手项目那么作为一个项目经理就必须为你所接手的任务负责;
应该积极的投入工作,对存在的问题进行逐一排解;

第 86 页 共 756 页
第 1 章 综合管理

1、了解该项目的范围、资源、时间、目标;
2、与前任 PM 作一个全面的沟通,并要求协助完成项目已完工的各项工程的文档资料;
3、对项目实施到什么程度及阶段应该有一份详细的评估报告并上呈至公司高层领导;
4、以一个新项目的姿态去对待;
5、与客户作一次充分的沟通了解、并协商各项可能存在问题的地方;
6、制订一份详细的实施计划,严格对项目进行进度控制;

·用项目管理理论管理项目(2006-11-30) [作 者] 谢仁禄 [公 司] 无

1、原 PM 没有留下任何文档资料,说明项目管理处于无计划、无组织、无监控状态。因此新任项目经
理接手之前,应对项目的现有状态进行详细了解,并作出评估报告,特别对项目的后期风险要有充分
的分析。
2、新任项目经理接手项目后应对项目范围进行确认,并重新组织进行项目规划。
3、根据项目规划,争取必要的资源。

·找借口推脱(2006-11-20) [作 者] 潘琦 [公 司] 北京市门吉利磁电工程研究所

半路接手问题太多,做好了,功劳不是你的,做不好,责任也不是前任的。如果必须接手,就像楼下
说的:
1。交接文件物品的签收。
2。给自己一段时间参与项目的进行,全面的了解项目中的问题,并将这些问题一一汇总上报。
3。把发现的问题由前任解决,如果不能解决的话要遗留的话,最好在公司高层在场做个问题交接。

·尽量不干擦屁股的工作(2006-11-07) [作 者] 杰罗 [公 司] 无

如果必须去做,应该:
1、办好交接手续
2、提出一个过渡期
3、评估项目现状
4、写出评估报告及解决方案
5、与领导沟通,争取支持
6、在项目进展过程中,多与参与各方沟通协调
7、加强目标控制

·不要找理由(2006-11-07) [作 者] 饶崇辉 [公 司] DETE

1、出现了不好的结果,不是哪个主动愿意的,先分析分析原因;

第 87 页 共 756 页
第 1 章 综合管理

2、前任诸多问题是前任的,应该在接手之初深入了解,详细汇报,提出解决的办法;
3、范围无限扩大,是现任管理的问题,范围扩大应该是好事,机会来了,没有把握住,大大失误;
4、领导永远不会错,应该永远记住。

·半路接手项目,遇到的问题(2006-11-03) [作 者] 桂君 [公 司] 合肥市伟联科技有限公司

在一个项目中临时更换领导者就像打仗过程中临时换将一样,本身就存在很大的风险问题。
在本项目中原 PM 遗留下的问题如下:
1、无任何项目文档记录
2、没有已完成工作的文档记录
3、没有良好的项目管理计划,并缺乏必要的沟通
4、没有进行项目范围确认
A 应该做的工作:
1、尽可能与原项目经理进行一次沟通,了解该项目整体情况,包括项目需求、项目的范围、完成的
工作量、项目目标等,做到
心中对项目有一个大概的轮廓
2、重新梳理项目范围和流程,建立新的项目范围计划
3、逐渐将以完成工作建立补充文档

·半路接手项目,遇到的问题(2006-11-02) [作 者] 曹雄 [公 司] gzfda

了解不清,沟通不够。

1、既然已接手,就要按新的项目的态度来做。
2、摸清楚项目的实际情况并与干系人进行沟通,让各个方面都能够支持自己来做好此项目。
3、按照项目管理的过程严格执行。

·执行(2006-11-02) [作 者] 曾勇 [公 司] 丰产林公司

A 半路接手的工作,既然已经接手了,关键是在立即执行。
一、首先总结原来项目的执行背景,以及掌握执行进度,
收集原来资料,找出碰到不足与可取之处,
全面分析得出下一步执行方案。
二、执行之方案
项目执行目标明确化
员工责任清晰化,并要预估将要承担的风险。
应及时与领导 B 沟通。

第 88 页 共 756 页
第 1 章 综合管理

·半路接手,注重pmp因素(2006-11-01) [作 者] 刘先生 [公 司] rai

应就 pmp9 项因素分别接手,并就各因素的交接形成实质对接。
如果项目情况特殊,应考虑整体项目程序是否完善。

·半路接手项目,遇到的问题(2006-10-28) [作 者] xingzhou [公 司] 重庆城市建设投资公司

我反对把新任项目经理 A 当成 119 的救火员,因为这种做法不是管理,而是处理,管理与处理虽然一字


之差确有天壤之别.我们现代项目管理者提倡的是按项目管理的方法来对项目进行管理.

·半路接手项目,遇到的问题(2006-10-28) [作 者] xingzhou [公 司] 重庆城市建设投资公司

作为一个职业项目经理,对待自己接受的项目,不管她的状态如何,都应该把它视为一个属于自己的
完整项目来看待。中途接手的项目,对于整个项目来说它是一部分,但作为项目经理来说,可以把它
看成是(大型)项目的一个阶段,新新接手的项目经理可以把它视为子项目来接受。这就是 PMBOKDE
观点。
我认为:项目经理 A 既然接受了授权,就应该收集项目相关料。验证前一阶段的可交付成果。按照新
的项目来进行启动,计划,实施控制和收尾。作为一个有经验的项目经理,首先应该对前任项目经理
和领导 B 进行干系人分析,不但要了解他们在你项目中的干系,这有利于你的项目成功;还要了解他
们在你的职业中的干系,这有利于你在职业生涯中的发展。这样才便于你在处理本项目重要事件时,
采用何种方法的抉择。除了授权和前一阶段的成果验收之外,项目经理 A 还必须做一件重要的事情就
是:根据收集资料的情况,提交一份项目范围说明书。明确你接手的项目范围。并同时向领导 B 索取
必要的资源。其它就是顺理成章的项目管理的事情了。

·调查、沟通+汇报(2006-10-25) [作 者] Tony Neptune [公 司] SIPSC

这种情况,在国内的工程项目实施过程中经常会出现,但是在国外,这种情况一般不会发生,至少不
会发生工作调动没有交接。
遇到这种情况,最好的办法那就是:1、深入理解、研究当初签订的合同。明确客户提出的变更是否
属于合同范围内的事情,如果是,那你来干是义不容辞;如果是新加的或者是需要变更的,那么就要
找客户进行沟通和谈判,争取变更,如果客户不同意,只能按合同执行。2、迅速调查了解项目的实
际进展情况及存在的问题,在与客户沟通、谈判的同时向上级主管领导报告项目实际运作情况。

·救火队员,是最好的项目经理(2006-10-24) [作 者] 夏云 [公 司] 北京联信永益公司

首先要调整好心态,不要因为捡了个烂摊子,是给别人擦屁股的活。越有难度约有挑战性,应该激发
斗志,证明自己是个优秀的项目经理。

第 89 页 共 756 页
第 1 章 综合管理

及时做好交接工作,尽可能的从前任项目经理那里获取文档资料,与团队成员沟通,与客户沟通,了
解项目进展的真实情况,并尽量获取团队成员的信任。
及时向公司上层汇报项目真实情况,并提出自己的调整计划,需要获取的资源。争取得到公司上层支
持。

·交接工作很重要(2006-10-23) [作 者] 徐金晶 [公 司] 花旗银行

一般在前任提出离职的时候,有 1 个星期左右时间的工作交接期。此时作为上司,应该尽快指定项目
接班人,接班人就应该立刻于前任项目管理者进行详细而深入的沟通,与开发组沟通。这是非常重要
的。由于开发组人员只是熟悉系统局部的逻辑,所以重点还是在前任项目管理者身上,要把所有需要
的东西从他身上 copy 过来。
本人刚刚本科毕业,对于项目管理的具体方法不熟悉,但是有志成为优秀的管理者。沟通能力和思维
清晰是优秀管理者必备能力。

·应该建立相应的项目管理框架(2006-10-22) [作 者] 杨梦云 [公 司] 上海蜗牛有限公司

应该建立相应的项目管理框架

偶目前正好遇到了和楼主类似的事情。偶是这样来处理的。

1、与公司存在的负责人 快速摸底、调查清晰整个项目的概要、状态、需求,以前资源存在?
彻底判断分析清晰 公司当前情况、公司各总对项目的看法、公司员工情况(含潜规则及公司潜意识
流)、分析员工对项目的看法。(这步是最关键之第一步,至于为什么后面有说起)

2、与负责人协同快速制订 项目工程蓝图框架表(尽量详尽,按照 pmp 规则建立),这份表建立前提


自然与你能力有关系,你越熟悉类似项目越佳

3、根据项目工程蓝图表,与相关人员进行批量性摸底、接触、建立关系网(大概需要 1-2 周,超大


型可以放 1 个月)

4、分批量 建设需求的工程规范模板、工作流程文档。并快速组织起相关部门主管、组长 ,形成共


识,并开始 缓冲型使用你规范化的工作流程
(这里插一句,可能前期项目团队并未建立起项目管理规范操作行为及意识流,所以这个过程比较关
键,形成缓冲地带,逐步 建立共识,可以先与公司总经理取得共识,并逐步让其增压下层与你的接
触,而你重点是与最核心部分的员工(如程序主管)取得共识)

5、尝试第一个小项目模块。待一切都建设达到一个度时,可以尝试一个小项目模块,挥动相关资源
进行协作及工作。以检测 项目建设的合理性、当前进程状态、当前资源质量(包括人员工作的质量)。

第 90 页 共 756 页
第 1 章 综合管理

至于一些人、公司级操作潜规则,你可以按照你的方式来进行。这里就不 yy 了。

还有一种公司,从上到下都是作坊化工作,而公司内部矛盾严重到随时倒闭时。建议 楼主不如早点
跳槽,如果要留下做圣人,只有筹备好 大量的时间、物力、精力、甚至 money 与公司同奋斗(或许
最后还被老总一脚踢出公司当黑锅)。

分析这个问题,要首先分析公司当前情况,才能去判定 如何切入及管理这个公司的相关项目。不要
操之过急。

还有就是企业的产品是产品,而不是商品。公司肯定要将其逐步转型为商品。
那么你作为 pm 应该具备除技术思维外,还应该有一个公司流意识。应该清晰公司要做什么,产品如
何转变商品(可能潜在对接部门)。都应该作好心理准备。项目管理不同于工程执行,比如程序软件
项目经理,他的作用如果只局限于架构软件等基础作用,那这个项目如果临时换人,肯定比较完蛋(自
然大前提来自公司没有清晰的认识和使用 pmp 规范流程)。

所以说日益复杂的项目应该具备日益复杂经验的经理担任是必要的。

·进入角色、分布实施、有效沟通(2006-10-21) [作 者] 廖学峰 [公 司] 江西科泰华软件有限


公司

首先问题是明确已经发生了:
原来的 PM 走了,
文档没有了,
用户要求多了,
可能实现不了了

迅速进入角色:
1、项目实际情况摸底,包括项目小组进度情况、用户反馈情况
2、按照摸底情况调整原计划
3、将摸底情况和领导 B 沟通,进一步调整计划
4、和用户沟通,调整计划
5、按照调整计划后的实施

另领导 B,错误不大,但可原谅
1、业务型的领导可能不能掌握全部项目的实际进度
2、即使知道部分,那也不一定要明说,否则影响项目经理 A 甚至不会

支持-要知道自己应该做什么!自己的位置!

第 91 页 共 756 页
第 1 章 综合管理

·个人意见(2006-10-19) [作 者] 于佳 [公 司]

1、A 首先应做项目实核。将结果上报 B 领导。


2、与客户一起重新设定需求范围,分析遗留问题哪些是超出原项目范围的,走变更流程。
如果 A 接手后还有范围有范围严重漫延,只能说明他的范围变更控制的不好!

·確定工作範圍與預定目標(2006-10-17) [作 者] sherman wu [公 司] CS

Leader B:一開始已隱藏了任務的風險與真實情況,雖然增加了資源,但卻已深埋了管理危機
Manager A:1.工作交接時,應確認先前進度、目前作業內容項目,後續進度之情況。

但在現行企業中,這確是常見的通病。
而預防勝於治療,如欲改善,應由專案啟動時逐一比對確認,
並對遣漏文件、過程資料再建構與補足。否則任務執行時,必定會出現問題,以致於任務結果之失敗。

·尽快信息收集、立即项目分析(2006-10-16) [作 者] 莫泽辉 [公 司] GZ—Telecom

在国企这种救火队员很多,收到这类问题后,应尽快收集原有项目的信息着手进行项目分析,时间、
质量和成本的完成情况必须了解透彻,并出具分析报告;主动和领导沟通。一定要让领导知道,要不
项目出了问题就麻烦了。

·重要的是自己(2006-10-15) [作 者] anbh [公 司] beijing

1、接手前项目经理应自己了解项目的进展情况,公司的态度,客户的需求等。不能仅仅凭其它人的
分析和说法。
2、即使接手后也要将发现的问题、完成情况、风险等尽快以书面形式提供给公司领导及相关部门。
3、没有正式的交接,公司管理可见一般。防止在公司政治斗争中失落了自己。

·半路接手项目,遇到的问题(2006-10-14) [作 者] beiyue [公 司] Sym

大家的问题
Lead B:在项目期间提升人才做的不好.如果原项目经理提升后仍然有兼职负责完项目的责任,帮忙
PM:A 完成任务.比较好.
PM A:半路接项目,首先深入了解项目,写个预测报告.谈出可能的风险.

·重视项目收尾(2006-10-14) [作 者] 李谦 [公 司] 一汽

第 92 页 共 756 页
第 1 章 综合管理

对不起!刚才把帖子发错了。出现此问题可能有两方面原因造成:
1、项目交接不成功。不知道该企业是否有成型的项目交接流程。
2、太轻视了项目收尾工作。其实项目越到收尾时细节工作越多,但轻视细节害死人。

·项目管理很大程度在协调人际关系(2006-10-14) [作 者] 李谦 [公 司] 一汽

你所遇到的问题是中小企业,尤其是私营企业的通病,看似让你放手去干项目,但实际处处掣肘。
有两点要注意:
1、处理好人际关系,因为小企业太容易出现偏听偏信。
2、莫太在乎权力,只要事情达到目的就可以,反正小企业也别指望捞个一官半职。

·项目变更(2006-10-12) [作 者] 刘宇 [公 司] 大连市项目管理研究会

这应该属于项目变更问题。对于 A 来说,被任命为一个项目的新项目经理,从一开始就应该对项目本
身进行多方面了解。即便前任 pm 没有交接过任何文字性资料,那么也不应该完全听从领导 B 的意见,
毕竟他不是项目经理,对项目进程了解程度不够高。
在项目发生变更的时候,作为新项目经理至少要召开项目组负责人会议,针对进行了一半的项目作多
方面了解。重新划定项目范围,确认项目交付成果以及完成日期,弄清楚接手项目的时候项目完成度
如何,等等这些准备工作都做好,项目如何能完不成?

·工作交接、范围确定(2006-10-12) [作 者] 王志良 [公 司] 广州市盾建地下工程有限公司

1、前任项目经理离职时没有办理好交接手续是工程失败的一个主要原因;
2、后任接手后没有改变前任的工作氛围,导致工作范围没有确切限定。

·技术经理加上项目经理(2006-10-09) [作 者] cajan2 [公 司] IBM

看的出来,该公司的项目管理基本上不上正规.
两个项目经理都是自己公司的员工,居然都不做 transfer.
在我们这里,transfer 是专门作为一个项目来做的.我知道一个开发时间为 6 个月的项目,交接时间差
不多也是 6 个月.厉害吧,在 PMBok 中,风险管理里面说到风险的应对策略,把这个称为风险转移或者机
会共享.
其实过分的 transfer 和完全不做 transfer 都是两个不同的极端情况,在现实中还是被我们碰到了,
嘿嘿牛.这就是政治,不极端不是政治,一不小心就被坑了.

第 93 页 共 756 页
第 1 章 综合管理

·做好交接手续,核实工作情况(2006-10-09) [作 者] itpm.com.cn [公 司] 暂不公布

在做项目交接的时候,应该按照公司的要求,按照项目经理你自己的方法和要求做好交接。把交接的
东西都文档化 这样不至于责任到后来都是你背了。如果项目比较成功,你的功劳也是显示不出来的。
另个工作就是要核实 前一个人的工作情况。和项目本身的进展,质量情况,这样利于自己的工作。
对他对你都是有利的。

·作为项目经理的最基本的东西(2006-10-04) [作 者] 小李 [公 司] 福建

项目经理其实就是管理者,领导者,决策的执行者,既然他是个多从身份的人那就应该全面,客观的
考虑问题,要有发现问题,分析问题,和解决问题的能力。这就需要项目经理要有很好技术素质,人
际交往,当然专业能力也是要的。

·要知道自己应该做什么!自己的位置!(2006-10-04) [作 者] 王丰江 [公 司] 北京华深

首先:A 缺乏工作的主动性,他没有在接手项目后根据领导介绍情况,实地的到用户、项目团队成员
中了解真实的实际情况,因为领导介绍的情况可能会偏离实际情况,造成理解偏离。远离项目控制范
围。
其二:A 缺乏项目过程工作汇报,如果在项目过程中发现问题及时汇报给领导与项目团队,及时纠正
错误。
对于 A 应如何做,我认为 A 在接手项目听了领导介绍后,及时主动的与用户或项目团队成员了解项目
情况——包括进度、范围、文档、变更、时间要求、用户需求。真正理解项目内容、范围、进度要求、
已完成工作内容、存在问题、需要立即解决问题;根据理解写出报告并提交给领导与项目团队,尤其
体现出存在问题的主要内容,急需解决的问题,让项目相关干系人都及时理解与了解,为推动项目埋
下统一思想的伏笔。

·项目管理就是拍马屁(2006-10-04) [作 者] daijiangbao [公 司] 深圳市大视野项目管理有


限公司

用拼音输入:pmp,一般就会出现拍马屁这几个字,倒是说出了项目管理、项目经理的工作。
项目管理,就是项目经理搭起一个平台,能让领导、客户、实施团队都在这个平台作出贡献,项目经
理的价值是表现在别人对这个平台的贡献才体现的,项目经理不是兰博,项目团队也不是兰博手下的
小偻偻,这点一定要明确。
另外,项目管理是管理不是技术,这点很多人都没有理解好,对软件开发行业来说,可以说几乎都没
有项目管理,却都在大谈项目管理,很尴尬的事情。
软件开发离不开软件工程,软件工程中也讲项目管理,但是这种从技术的角度来看待项目管理,本身
就会造成狗眼看人低的局面,因为技术是最底层的东西,从这样的狗眼的角度(但愿不要理解成我在
骂人)来看待软件开发,尤其是应用软件的开发,自然会无病呻吟的得出什么软件危机、客户需求不

第 94 页 共 756 页
第 1 章 综合管理

明确等一堆说法,然后按照这些错误的说法想法,再去更加错误的采用一些方法,付出的代价是相当
昂贵的,但是却绝大多数的人认为,这就是软件开发,软件开发就得是这样的伤痕累累的结果。
可是,如果把软件工程与项目管理一比较,就非常清楚该怎么轻松的、高利润的完成软件开发,满世
界都在说项目管理是解决软件开发的唯一出路,道理都明白,可以一做起来就又落入软件工程灌输的
大黑洞中,呵呵,死的多惨都不明白是怎么回事,要不就是寻找什么印度模式,或者是微软模式,还
认为软件开发就得是这样的结果。
如何把软件工程灌输的理念这种巨大的风险,转换成项目管理中的巨大利润,这是摆在软件开发公司
面前的生存问题,实际上这是软件开发所谓高技术、高风险的集中表现,也应该转换成高利润才对(所
谓的三高啊,都要高啊),这不是胡话,是完全可以做到的,很大一方面取决于是用狗眼还是人眼来
看项目管理。
实际上 pmbok 就软件工程和软件项目管理在前几个版本都有明确的定义,为什么没有人去认真看,去
认真体会,去认真实践,自然会得出不俗的结果,软件开发项目的巨大成功,自然会给项目经理带来
很大的成就感,这才是项目经理值得一生都拥有的自豪。
无论是什么样的软件开发,都应该是获得巨大利润的项目。也无论是项目从什么阶段入手,也不在乎
什么烂摊子项目接手,唯有这样的项目,才能彰显项目经理的价值。

·如何解决(2006-10-03) [作 者] cao xi [公 司] RA

1。 新任项目经理不能盲目听信领导 B,原因:
1〉不知道是否这个领导 B 和这个已经高升的原项目经理有什么利益关系。是不是在如实地阐述问题
2〉领导 B 不是项目经理,不能如实地真正的了解原来项目的问题。
记住:
不能轻信别人,包括领导。他们会因为种种原因不会了解项目中所有的问题。

2。必须如实地了解项目的真实情况,意识到越是领导轻描淡写说没有问题的项目,其实越存在着大
的风险隐患。不要无辜的作了替罪羊!
1〉和项目成员开会,从他们那里知道项目的大致情况。如果项目真的进行得很烂,一定会有项目成
员把实际情况反映给你。将会议记录整理出来。
2〉和用户开会,了解一下用户的状态和对已经做完的任务的反映情况。好的坏的,客户一定会如实
告诉你。
基于自己了解到的情况,整理出一份报告。做到心中有数。这时候的项目经理应该了解到项目的真实
情况。
3〉要求和前任项目经理,领导 B 进行直接会谈.指出来项目目前存在的问题,用户的反应,文档的问
题。这不是推卸责任,而是在适度的保护自己。必须要让领导 B,如果领导 B 不是你的直接领导,还
必须让直接领导也明白:如果这个项目已经是个烂摊子,一切都处于混乱状态!你是在这样一种状态
下接受的任务,而不是说项目都进行得很好,是你来把项目管理的一塌糊涂的。当然如果你还要在公
司混下去,说这些话的时候一定要比较小心,就事论事,有理有据。同时考虑好在这种情况下应该有
什么好的办法来解决问题,而不是只是罗列问题给领导,毕竟,有时候,项目经理就是要临危受命!

项目经理需要准备的其他资料包括:

第 95 页 共 756 页
第 1 章 综合管理

1〉一份问题的列表清单,包括问题的严重性。
2〉重新审核项目资源和进度。注意一定要包括重新编写某些重要的项目文档,尤其是那些需要用户
进行签字的文档,比如说:用户需求文档,
3〉就项目资源,进度和领导们进行重新谈判。

记住
1。有的领导很“健忘”,一定不能只是简单的汇报一下就可以,所有的问题,会议内容都必须以报
告的形势呈现。省得到时候领导忘记了你说的什么。
2。一定不要再没有搞清楚所有问题之前,乐观的估计问题。
3。一旦发现了问题,要注意向领导反映。
4。注意和客户搞好关系,即使项目经过了努力,最终还是失败了,也最好做到让客户明白:这不是
你的错误,你已经竭尽全力。换了任何别的人,项目一定会更糟糕。如果还有问题,就是领导层的问
题。毕竟,有时候,项目就是一场政治斗争,而我们必须在某种程度上保护自己。文字

·错误的人被安排到了错误的位置(2006-10-01) [作 者] bomber [公 司]

临时接手中途项目/救火项目/烂摊子项目是比较常见的事,要保证项目后续工作的正常开展接手的项
目经理必须以我为主,有交接没交接\有资料没资料,新的项目团队必须在短期内尽快对项目作出一个
评价,以我为主确定下一步的计划报批.
俗话讲臭话尽快说,我最痛恨平时说没问题,做到最后却摊出一大堆理由求解脱的项目经理,项目团队
解决不了的问题不代表公司也解决不了.

回到案例:
A 作为项目经理,从案例字面看嫩的可以,需负主要责任,不一一点评了.
公司对项目交接似乎没有相应制度保障需改进.
公司任命无项目经验的 A 来收尾,也需承担部分监管\指导不力的责任.

·接口工作管理(2006-09-30) [作 者] tanfei [公 司] 金诺

有人调走有人接替,在公司的正常的运营过程中是正常的。但是,存在接口的问题,两个人如果没有
交接 A 就接手,前任项目经理就离开,这中间就会出很多问题,公司的这种管理从上面就是错误的。
所以,A 出错也就是应该的。

·不要火药味,不是我的本意(2006-09-30) [作 者] daijiangbao [公 司] 深圳市大视野项目管


理有限公司

说明一下:
1、二婚女人也有好的;

第 96 页 共 756 页
第 1 章 综合管理

2、本人下过金蛋,国内、国外的都下过。
3、如果说项目管理就是项目经理自己解决问题,那就彻底错了,错的一塌糊涂,解决不了问题还说
是别人的错,没有给自己留下解决问题的环境,好显示自己的项目管理,这真的是项目经理该做的吗?
4、哪家公司没有问题?项目就是解决问题的,不是拿来炫耀的,对领导有那么多的指责吗?指责领
导就是项目经理该做的事吗?

·解决问题应该有自己想法(2006-09-30) [作 者] 于先生 [公 司] 南方数码

前面的多位朋友的分析都切入了问题的实质,并且都有自己的解决方法,很到位。
个人认为,遇到问题先想如何解决,不管是国内国外还是什么伟人的理论,具体问题还应该具体分析。
光扯出一堆道理,没用!问题还搁在那。
解决问题要有自己的想法,不是总带着典型中国人的改良型头脑在别人的想法上评头论足。项目管理
者更该如此,有问题只能自己解决,谁会做你的肩膀。想在别人鸡蛋里挑骨头的人,首先自己下个蛋
看看,没准连蛋黄都没有,有什么资格在别人那挑。

·不光只看到A的问题(2006-09-29) [作 者] 钟焯文 [公 司] 广东天讯电信科技有限公司

看了前面多位的评论,觉得意见很中肯、很到位。

在此过程中,有几个问题:
1.领导 B 显然没有真正认识到项目的难度和状态,没有安排做好 PM 交接的工作,或者根本就没有给
充足的时间完成交接。这种因项目负责人突然蒸发而引起工作断层的现象现实并不少见。
2.前任 PM 没有真正把项目管起来,例如进度不清,文档不齐,工作安排不到位。假如这些都做得好
的话,决不会因为某一人的突然离开而导致一塌糊涂。
3.从字里行间可以看出,A 接手此项目时,因听信于领导的几句话:此项目一切顺利,只要改动一下
程序,完成最后一阶段测试就大功告成了,而没有足够的重视。轻视令到他忽略了潜在的风险。

·问题的关键(2006-09-29) [作 者] 于先生 [公 司] 南方数码

把企业当成项目来管理完全可以,但就不是纯粹意义上的项目管理,项目唯一性这种自相矛盾的话就
憋着别说!
抛开这个不说,问题的关键是项目管理者对项目的认知错误,没有了解清楚就下任务给对项目一无所
知的人,空对空的存在必然导致失败的结果。
这明显反映国内企业管理上存在的问题,阶级意识太严重,一个企业管理者如果有太多的地位意识,
那么太多的决策都得偏离方向,不懂项目管理的企业管理者尤为如此,然而做项目管理的能左右上级
吗?
企业管理做项目管理也好当别的也好,管理者一定要清楚问题在下结论,更要敢承担责任。不懂别装
懂!

第 97 页 共 756 页
第 1 章 综合管理

·同事A犯了什么错(2006-09-29) [作 者] 杨锋雷 [公 司] 上海久隆信息工程有限公司

2003 年备考 PMP,看到这样一个案例:


某项目进行到中期,项目经理 A 离职,项目经理 B 接手,项目经理 B 发现按照当前的执行情况,项目
计划肯定不能如期完成。此时,项目经理 B 应该怎么办?
1)告诉老板实际情况;
2)和项目组成员商议,采取挽救措施,并通报主管;
3)什么都不做;
4)拒绝接手项目;
显然,在本案例中同事 A 选择了(3)。

从结果来看,显然 3 不是最佳措施;而在中国的环境下,4 是我们无法选择的。那么,同事 A 可以怎


么做呢?

答案好像比较清楚,2 是最佳的措施。
分析问题、汇报问题、解决问题是项目经理工作的基本行为准则之一。

【另外】
如果同事 A 选择(2)措施的话,“和客户达成业务解决方案共识”和“后续工作进度安排”是首要
动作。

·企业管理与项目管理对立吗?(2006-09-29) [作 者] daijiangbao [公 司] 深圳市大视野项


目管理有限公司

项目管理不是小儿科,不是只能进行雕虫小技的管理。
我刚才说了,把企业当成项目来做,完全符合项目的唯一性,企业中出现的问题与项目管理中的问题
是一样的。
无论是国内还是国外,现在都把项目管理当成一个小儿科,这是悲哀的,去看一下毛泽东选集,就清
楚什么是项目管理,中国从来都不缺项目管理。
对于 A 来说,不存在该不该接项目的问题,关键是怎么能让项目干系人满意的问题,抱怨环境的不好,
不能给 A 的项目管理创造良好的环境,让 A 尽情的发挥项目管理,呵呵,说句实在话,有八抬大轿抬
着项目经理去干活,还要你项目经理干什么?什么地方凉快就在什么地方待着。

·机会留给有准备的人!(2006-09-28) [作 者] 韦昌勇 [公 司] xxx算机科技有限公司

A 有一个很好的机会表现自己的才华,可惜,他还没有具备这样的能力。有才华的人需要通过解决一
个个棘手的问题来表现自己的能力,所谓,天欲降大任于斯人也,必先。。。。。,呵呵。
B 没有留下文档,不代表工作就没有延续性,领导只是换了项目经理,又不是换掉整个项目团队!

第 98 页 共 756 页
第 1 章 综合管理

建议:
1。首先了解项目状况,而不是仅听领导一面之词。
2。评估自己能否按照计划完成项目,达到领导的期望。如果真的不行,就不要接受这样的任命,明
知道是一个火坑还往里面跳,没这个必要啊。
3。跟领导进行充分沟通,纠正领导对这个项目错误的印象。(实际项目做得很烂,领导确认为做得
很好),降低领导的期望。
4。严格控制项目范围,需求增加和变更,按正规的需求变更流程来走,包括项目计划跟着变更等等。

·很显然的企业管理问题(2006-09-28) [作 者] 于先生 [公 司] 南方数码

“领导 B 在任命 A 做项目经理的时间,介绍说:此项目一切顺利,只要改动一下程序,完成最后一阶


段测试就大功告成了。”原来项目经理哪去了?B 领导有什么发言权?B 领导如果对项目了如指掌还
要项目经理干吗!新老交接要在同职位间进行,相关的人哪去了!很显然企业人事管理有了缺陷!要
说 A 做错了什么,对待这样的管理层,错就错在不该接这个项目!

·常见问题(2006-09-27) [作 者] 王海飞 [公 司] XX通讯有限公司

做错的事情:
1、基本上没有什么交接工作;
2、信息采集不足。只听领导一面之词,没有与客户达到很好的沟通;
3、具有主动扛起黑锅的献身精神;
4、缺乏与领导的沟通。
如果我是 A,我会选择采取以下方式:
1、文档存储在项目管理中是一项非常重要的工作,移交时没有文档怎能放过。此时应及时将此情况
反映给本公司内部的项目干系人,实在不行的话,要及时拒绝接手;
2、增加信息收集渠道,掌控信息准确性;
3、采用《阶段性报告》/《日报》的形式及时反馈各种信息给项目干系人,并针对项目问题提出相关
解决办法,增加同领导的沟通;
项目经理接手半成品项目,是为了让其成功完成的,而不是去背黑锅的。在接手时若预盼到此乃一个
失败的项目,则要想办法脱手(呵呵,这有点违背职业道德),实在没办法也要让大家知道过错不在
你。
明朝表面是亡于崇祯,实则毁于万历(三十年不理朝政)。历史不能重演呀!!!
个人拙见。

·企业管理和项目管理在这个事情上有区别的吗?(2006-09-27) [作 者] daijiangbao [公 司]
深圳市大视野项目管理有限公司

把企业当成项目来做,不就是一样吗?

第 99 页 共 756 页
第 1 章 综合管理

项目作不好,企业也一定做不好

·半路接手项目,遇到的问题(2006-09-26) [作 者] 罗杰 [公 司] tpbirds

作为公司的领导者,应尽量避免让关键项目人原员调动流失。给下面项目的工作增添了更多不确定的
风险。
以上算是多余之谈;尽然这已半路接手的项目我们就先分析一下,该项目看似要“大功告成”,事实
上留一下了许多隐患--没有文档的项目。
首先没有文档(合同、需求说明书等)就不具备法律效益,致使客户要求更改程序;甚至该项目经理
A 在没有这些文档的报告下,进行了测试工作,可见忘记了测试的最终目标。
其次 B 给了 A 增加资源,并非是该项目项目中需要的源,没有确定项目范围边界,会致使资源的浪费。
A 面对以上问题,应确定客户的需求,确定项目的范围,有效的控制管理。
由于时间问题大致分析一下,个人意见,只供学习交流。

·本案例项目经理同时要有技术经理的能力(2006-09-26) [作 者] 游永明 [公 司] 广东省计算


中心

从案例描述可以知道,以前的 PM 使能够让整个项目运转正常的,但是居然 Doc 之类不够齐备,可见


以前的 PM 在项目管理的同时担当了技术经理的职位,这样项目才能继续下去。

A 的问题在于楼上大家提到的以外,还有一个就是对项目技术的把握度,也就是说对技术经理的把握。
这是一个比较明显的 PM 掌管一切的项目,PM 走了,估计同时还是技术核心走了,否则通过 A 和以前
的技术经理的沟通,这些都是可以重建的,虽然耗时间。

所以我认为 A 在针对项目的技术把握方面有所欠缺。

·首先澄清项目状况(2006-09-26) [作 者] xenie [公 司] s

A 一接手该项目时首先要做的就是弄清目前的项目进展状况,虽然在项目中项目经理最大,但是事实
上离不开领导 B,实际也证明项目经理最终的工作业绩是要由领导 B 来评判的。
如果 A 可以在一开始就将自己所接手的项目工作已经达到的程度,会遇到的问题和困难都一一呈现给
领导 B 看,就能扭转领导 B 的错误印象,及早地获得他的认同,以后的事情就可以好办得多。
当然之后他如何确保项目的顺利进行也存在一定的问题,一方面可能是个人能力,一方面也可能是不
可控因素,但是至少可以避免来自领导 B 的压力

·先建立组织结构(2006-09-25) [作 者] daijiangbao [公 司] 深圳市大视野项目管理有限公


第 100 页 共 756 页
第 1 章 综合管理

同意作者:zilion 的意见。
首先要建立项目的组织结构,建立沟通渠道,完成项目计划,把已有的工作表现出来,未完成的工作
也表现起来,建立变更管理机构。

·理想与现实(2006-09-25) [作 者] Jacky [公 司] Prowave

B 作为领导并不了解项目的真实情况,说明前任 PM 对工作的汇报仅仅是感性的。
A 作为接任的 PM,应该及时了解项目范围、资源以及计划进度,并要重新根据目前状况作出评估并向
领导汇报。

·项目经理可做的很多(2006-09-25) [作 者] zilion [公 司] 不公开

看看 A 应该做的,就知道 A 做错了什么了。
1、作为 PM,既然准备接手项目,不论 B 说什么,对项目进行情况作前期总结是必须的:当前状态,
人员情况,新的需求,风险...文档也是其中的一部分。
2、计划:接手项目后,除了分析当前状态,以后我准备怎么做?当前的任务是什么?资源有什么?
要多久才能完成?
很多人以为作计划是给领导看,实际上计划是帮你,在延期的时候怎么跟领导说不是你的错?是通过
计划,以及计划跟踪来实现的。
3、状态报告:项目进行中,每周都要把项目状态,尤其是存在问题向领导报告(一定是书面报告)。
案例中的问题如果早就报告给领导了,领导批评你,你就直接跟他说让他回头去看看你给过他的报告。

当然了,项目管理不只做这些。不过,如果这几个做了,你项目也许还是失败,不过,就不是你的问
题了。

·半路接手项目,遇到的问题(2006-09-25) [作 者] HurryBai [公 司] abcd

请问 A 在接手时有没有考虑过这些问题,有没有写过接手时应该收到的 DocumentList,在 List 中的项


目有没有全部收到,

1.11 一个系统集成项目的烦恼

一个系统集成项目的烦恼

第 101 页 共 756 页
第 1 章 综合管理

[姓 名] 周世清 [单 位] 不公开 [邮 件] ctele@126.com


[所属行业] IT 软件 [所属主题] 项目综合管理 [发布时间] 2006-8-28

【案例正文】
海正公司的赵晓东最近心里挺烦。公司前一段签了一个 100 多万的系统集成项目单子,由于
双方老板很熟,且都希望项目尽快启动,在签合同时也没有举行正式的签字仪式。合同签完,
公司老总很快指定赵晓东及其他 8 名员工组成项目组,由赵晓东任项目经理。老总把赵晓东
引见给客户老总,客户老总在业务部给他们安排了一间办公室。

项目进展开始很顺利,赵晓东有什么事都与客户老总及时沟通。可客户老总很忙,经常不在
公司。赵晓东想找其他部门的负责人,可他们不是推托说做不了主,就是说此事与他无关,
有的甚至说根本就不知道这事儿。问题得不到及时解决不说,很多手续也没人签字。

项目组内部问题也不少,有的程序员多次越过赵晓东直接向老板请示问题;几个程序员编的
软件界面不统一;项目支出的每笔费用,财务部都要求赵晓东找老板签字。赵晓东频繁打电
话给老板,其他人心里想,赵晓东怎么老是拿老板来压人。由此,赵晓东与项目组其他人员
和财务部的人员产生了不少摩擦,老板也开始怀疑赵晓东的能力。

内部问题:

1、项目内部成员越过项目经理直接请示老总;
2、项目内部人员对建设标准出现不统一情况;
3、项目支出财务部要求赵经理找公司老总签字;

结果:

1、项目组成员、财务部人员与赵经理产生摩擦;
2、公司老总怀疑项目经理的能力。

外部问题:

1、什么事情都与客户老总沟通,但老总很忙;
2、客户部门负责人推托,手续没人签字;

结果:1、在客户端的工作无法正常开展。

【相关分析】

第 102 页 共 756 页
第 1 章 综合管理

·你就是项目经理(2006-11-20) [作 者] 潘琦 [公 司] 北京市门吉利磁电工程研究所

1.自己都说了,老板指定你们 8 个人作为项目组,你就是本组的领导,要和项目组的成员开会说明这
一切:项目的所有问题交给你,由你再次传递出去。
2.在项目最初的时候就应该有对方的公司项目负责的联系方式,有问题直接找他

·这种方式很好!!(2006-11-16) [作 者] 王大勇 [公 司] 武汉

这种方式非常好,可以以点带面,从一个小项目的个体,逐步引申到所有项目的共性问题,从而在解
决这些问题的同时,也深入理解了项目管理的方式方法,比单纯的学习项目管理的理论知识印象深刻
的多!先谈点感受,然后再分析本人肤浅的观点!

·职权不明确(2006-10-25) [作 者] 杨杭 [公 司] 华立集团

在项目开始的时候一定要把项目分解,然后把职权明确掉.这个例子是很典型的职权不明确的例子

·项目管理的问题 (2006-10-20) [作 者] 章国新 [公 司] Qimonda IT (Suzhou)

cooperation and communication problem need to be handled properly.

·project management problem(2006-10-20) [作 者] 章国新 [公 司] Qimonda IT (Suzhou)

face the problem and communicate with team members

·计划与责任不明(2006-10-19) [作 者] junhoo [公 司] sino

项目计划不明确!
项目相关人员职责不明!
信息流不畅通

·项目内部成员越过项目经理直接请示老总(2006-10-05) [作 者] 王丰江 [公 司] 北京华深

项目内部成员越过项目经理直接请示老总;
原因分析:个人感觉,主要是因为项目经理没有很好的解决内部成员提出的问题。仔细想想,为什么
项目刚启动的时候没有发生这样的事情呢?所谓路遥知马力,就在与此吧!由此引发内部成员对项目
经理能力的怀疑!当然,这也不排除内部成员想借机会表现自己的嫌疑。
解决建议:组织全体内部成员开一次例会。要想成功的解决问题,首先要检讨自己。把自己这段时间
在内部管理上的失误说在台面上,不要躲闪。这一点很重要!管理最重要的因素之一就是亲和力。一
番由衷的感人肺腑的演讲之后,就要严肃的而且不容质疑的详细规定所有成员的职权范围!必要的时
候可以点破这样做的原因。但一定要注意,中心是要维护团队协作。

第 103 页 共 756 页
第 1 章 综合管理

·还是方法问题!(2006-10-05) [作 者] 王丰江 [公 司] 北京华深

最初就因该直接跟客户老板提出其指定一个联系人,或者关系很好的画就完全按照用户需求或实际情
况下在适度范围内行使你的权利。把项目进行下去。

·需要在客户中寻找联盟者(2006-09-28) [作 者] 韦昌勇 [公 司] xxxx算机科技有限公司

对于这个项目的外部问题,解决方法就是在客户中找一个对这个项目承担责任的人,建立联盟。

·有效的沟通(2006-09-27) [作 者] 罗杰 [公 司] tpbirds

类似的有效沟通我曾在一些相关案例中分析提过。
如何有效的沟通;
如何解决处理这些沟通障碍?
有时间我会写一编论文给大家参考讨论,再共通研究。

·合同要建立责任(2006-09-22) [作 者] daijiangbao [公 司] 深圳市大视野项目管理有限公


把客户的责任都没有建立起来,客户是没有责任去验收项目的,项目只有去失败吧。
失败是成功的亲妈?

·公司项目管理的问题(2006-09-17) [作 者] zhangmin [公 司] 北京东方飞扬软件技术有限责


任公司

通过这个案例,我觉得他们公司存在项目管理上的问题,同时项目经理缺乏协调和沟通以及谈判的能
力。

·注意方法(2006-09-15) [作 者] giant [公 司] 上海某研究所

同意上面搂主的分析,从对方公司找个工头管住他们,一切和他指定的人联系。文字

·给张成鹏同志顶下!!:)(2006-09-05) [作 者] 中国武则天 [公 司] 电信公司

给张成鹏同志顶下!!:)

第 104 页 共 756 页
第 1 章 综合管理

·什么是项目经理(2006-09-04) [作 者] 张成鹏 [公 司] 珠海置盟信息技术有限公司

我先说说如果我是这个项目的项目经理,我会如何去做。

首先:老总任命我为项目经理,我就承担了项目管理的责任,那么我就需要相应的权利,这点相信老
板是可以理解的,即使没有尚方宝剑,怎么也得有个圣旨什么的吧,我会制定一个项目实施计划,说
白了,计划解决两个问题,第一,职权问题,第二,经费问题。

计划中对人员的职责进行规定,这就确保了各级的工作汇报,避免了随后发生的越级汇报。

计划中还有相关项目费用的申请,我曾试过直接申请一笔费用作为项目经费,也曾试过获得低于一定
额度的费用可以由我签字直接报销。一般在项目启动阶段是蜜月期,找老板申请资金比较容易,后期
基本很难。

和甲方老总直接联系是个很麻烦的事情,最好由甲方老总亲自指定一个项目负责人,无论如何都要想
办法开一个项目启动会议,让甲方所有相关的业务人员都要参加,会议主要目的就是要确认甲方项目
负责人。凡事和甲方项目负责人沟通,由他去摆平他们内部的人,避免你和甲方业务人员的纠缠,但
前提条件是,你要先摆平甲方的这个项目负责人,一般采用方式是威逼利诱。所谓威逼,那他老总来
压他,利诱分为物质和权利。

要树立项目经理的权威,如果我的项目组有人直接向老板请示问题,我会采取两种方式解决,如果我
和老板关系较好,我会直接提出,由老板警告那些越权汇报的人,如果关系没好到那个地步,我会设
计一个陷阱给这些越级汇报的人,让老板怀疑他们的意图。夺回我对项目的控制权。

无论如何都要想办法获取自己老板的信任,如果失去老板的信任,则一定会出师未捷身先死,长使英
雄泪满襟。

我的体会是,项目经理更多的是在玩人。在甲乙双方的夹缝中求生存。

·验收成问题(2006-09-04) [作 者] daijiangbao [公 司] 自由职业

连个合同都没有签,不把客户的责任建立起来,项目只有倒霉的事,现在案例的分析,满篇都是暴露
出来的项目风险,后期风险爆发以后,有的难受了
能不亏本吗?不容易

·一个系统集成项目的烦恼(2006-09-01) [作 者] 史先生 [公 司] 保密

解决问题的关键是沟通。对内,要和下属还有老板沟通,相信只要和下属交心的去谈一下问题,是可
以解决的;和老板,则需要将工作的困难以及自己的想法说一下,当然,非要是按规章办事,那也不

第 105 页 共 756 页
第 1 章 综合管理

能因某个项目来破坏大局。 对外,和对方的老板来次比较深入的探讨,把问题摆出来,相信对方的
老板会给你明确的安排个负责人来负责。 总之,万事,皆在沟通,只有沟通到位,才能顺利的开展
好工作。

·拙见(2006-08-31) [作 者] Mr陈 [公 司] 华中科技大学

见笑了!
内部问题:

1、项目内部成员越过项目经理直接请示老总;
原因分析:个人感觉,主要是因为项目经理没有很好的解决内部成员提出的问题。仔细想想,为什么
项目刚启动的时候没有发生这样的事情呢?所谓路遥知马力,就在与此吧!由此引发内部成员对项目
经理能力的怀疑!当然,这也不排除内部成员想借机会表现自己的嫌疑。
解决建议:组织全体内部成员开一次例会。要想成功的解决问题,首先要检讨自己。把自己这段时间
在内部管理上的失误说在台面上,不要躲闪。这一点很重要!管理最重要的因素之一就是亲和力。一
番由衷的感人肺腑的演讲之后,就要严肃的而且不容质疑的详细规定所有成员的职权范围!必要的时
候可以点破这样做的原因。但一定要注意,中心是要维护团队协作。
2、项目内部人员对建设标准出现不统一情况;
原因分析:没什么好说的,绝对是项目的工作日报和进度验收没有做好。另外,项目的团队开发非常
不规范。
解决建议:项目经理一定要对于日报和进度验收提高重视程度,在例会上针对这个问题着重强调队内
交流。如果可能的情况下每天或者两天一次进行队内开发调整。当然,如果能有效的利用一套团队开
发工具软件就最好,这样的工具软件是一个很有效的避免类似问题的捷径。
3、项目支出财务部要求赵经理找公司老总签字;
原因分析:公司制度所限,原则上只能遵守!
解决建议:制度也是人定的,跟老总着重强调一下实效性!在不超出预算的情况下尽量省去繁琐的步
骤。效率是软件开发的关键,不要把时间浪费在没有必要的事情上!如果老总开明的话相信问题容易
解决!

外部问题: 这两个问题可以汇总来解决!

1、什么事情都与客户老总沟通,但老总很忙;
2、客户部门负责人推托,手续没人签字;
原因分析:客户公司重视程度不够,缺乏有效沟通!
解决建议:一个项目经理最主要的工作不是监督进度,而是一个沟通的问题!跟客户公司提出目前的
问题,申请客户公司特定一个对公司流程熟悉的人做项目代表。

个人的一点拙见,言语之中若有不敬实属无意!还往大家见凉!见笑了!

·一点异见(2006-08-29) [作 者] 于先生 [公 司] 南方数码

第 106 页 共 756 页
第 1 章 综合管理

1、内部对于越级汇报的问题,忌强行要求下属如何来做,首先出现这种问题说明赵晓东执行力难以
服众,这时采用强压方式一定适得其反,强权制度害人害己。最好能够和老总沟通确定职权范围后通
过老总让下属清楚汇报制度。
2、外部问题,一般像这种关系合同,客户对成果要求不会太高,只要不太差就行,因此对项目重视
程度相对不够。如果赵非要太认真,那最好找个时间与客户老总沟通,使其能放权于下属,如果对方
老总仍独权,那就顺其自然,项目延误也不是一个人的责任。

·重点提出解决方案,加强沟通和反馈(2006-08-29) [作 者] 一孑 [公 司] 一孑工作室

您也提到了,在项目初期,进展的还是比较顺利的,所以,先期无论是程序员还是老总应该都给予你
一定的支持,但随着项目的发展出现了众多问题,一些建议,共同探讨。
1、项目内部成员越过项目经理直接请示老总
先期这种问题应该没有出现,这种问题的发生,应该是由于你与领导的沟通及对下级问题或困难的及
时响应造成的,如果下级向老板反应的问题你也会定期向老板汇报,并且还可及时解决,从老板方面
这种问题以后就会杜绝,也不会出现老板对你的信任危机,对于下属,应该及时解决其问题所在,换
句话讲,每日工作只可能存在你的工作未完成情况,但决不能存在下属或你配合下属的工作未完成,
这种情况我不建议用权力下压,会产生逆反。
2、项目内部人员对建设标准出现不统一情况;
典型的就是沟通的问题了,一个团队对建设标准都不一致,项目还如何向前推进,建议加强沟通的管
理,多创造一些大家沟通的机会,同时,建立反馈制度,这种不一致的意见应在第一时间反馈到你这
里进行沟通解决。如果这种问题还存在,应通过建立的制度进行协调解决,不要强调个人权力,应强
调团队制度和团队利益。
3、项目支出财务部要求赵经理找公司老总签字
这个与贵公司的财务制度和项目结算方式有关,如果确实是制度所要求,那没什么好的办法。但如果
项目预算已经完成,你就应该具备一定的财务权力,这方面应该与贵公司的制度有关了。但建议你与
老总进行沟通协调,或作出更详尽的财务预算,与老总商定财务的支出方式,避免耽误进度。
以上问题如果可以得到很好的协调,至少你谈到的结果不会这么严重,但你所说的这三个问题确实可
直接导致所描述的结果。第一个结果是协调的问题,第二个结果是沟通和反馈的问题。
外部问题:
1、什么事情都与客户老总沟通,但老总很忙
老总都很忙,呵呵,所以,你和老总沟通的时候,应该是重点提出解决方案,不是提出问题让老总去
替你解决。你和老总沟通,重点是得到老总的首肯,不是让老总给你解决方案。这样的沟通会很有效,
也会逐步建立与客户老总的信任。
2、客户部门负责人推托,手续没人签字
这个项目可能是老总的关系做成的,如果这样这种问题势必就会产生,建议你还是提出你自己的解决
方案,有些问题是需要反馈的,但和打小报告是不同的,呵呵,所以,你必须把你的困难和建议的解
决方式提交给客户老总,期望他可以给你配合,你需要什么样的权力可以解决这个问题,你也要明确。
但还要重视另外一个问题,就是关系的维护,否则后期也会出现问题。
对于客户那边,一定要明确你的目标,该做什么,需要什么,谁可以给你提供,怎么来做,最好可以
预知问题,并提出解决方案。

第 107 页 共 756 页
第 1 章 综合管理

一些建议,仅供参考。

·需要赵晓东在管理能力和职场策略所有提升(2006-08-29) [作 者] 中国武则天 [公 司] 电信
公司

觉得赵晓东主要问题是出在对下和对上的管理问题,建议解决途径:
1,项目内部成员越过项目经理直接请示老总;
建议:可以借助项目进度会在会上直接对组员说明不可以越级沟通问题,并要求属下直接向他汇报;
必要时候可以考虑用权力压一压个别手下。“人善被人欺,马上被人骑”的道理他应该知道;
2,项目内部人员对建设标准出现不统一情况;;
建议:需要开会沟通,并将每项工作有计划的责任落实到人,并要求相关执行人定期汇报工作进展情
况或者写日报;
3,项目支出财务部要求赵经理找公司老总签字;
解决方法:如此公司财务有相关制度所以支出必须由老总签字的话,最好按照公司财务制度做;如果
该项支出很着急,可以让与财务沟通可通过电话或者邮件的形式让老总确定此事;
4,项目组成员、财务部人员与赵经理产生摩擦;
建议:针对组员建议私下多做些沟通工作,另外赵晓东应该学会独立的承担起一个项目的管理责任,
学会自己独自处理一些事情,一些小事情尽量不向老总汇报;否则就是副总的“通话筒”;
5,公司老总怀疑项目经理的能力。
建议:我个人觉得不是公司不放权力给他,而是赵晓东的工作责任没有做到位,才逐步让自己走向被
动;可以考虑多向副总汇报近期工作进展情况,项目进度会必要时候可以考虑让副总参加,从而来增
加老总对他的工作认知度;(学会做一些让副总放心的事情,必要时可以考虑做“秀”)
6,另外,赵晓东应该学会遇到“包袱”要自己扛,不要推给别人;一个好的管理者通常是想办法去解
决问题,而不是把问题放大推给别人;

·内因和外因(2006-08-28) [作 者] 梁桢 [公 司] 百瑞杰信息咨询

本案例的作者已经将内部问题和外部问题做了简要的概述,我想再将问题归纳的更简单些,希望没有
曲解作者的原意。

内部问题:公司领导没有给予正确的工作授权,致使项目经理无法行事项目管理的权利。因为没有授
权才会出现项目内部管理时没有决策权,无法掌握工作方向和人心。
外部问题:客户方没有相应的人员配合项目,导致问题最终汇总倒客户老总处,并且客户内部对于项
目的关注度相当低。

对于内部问题我认为,项目经理有必要和老板确定下自身的项目管理范围和权限,比如项目团队的管
理,工作进度的制定,奖惩机制的建立,部门间合作流程等。这对于日后公司内部执行项目管理和业
务流程都是一劳永逸的。因为从作者的描述来看,公司内部原先没有这样的机制或者该项目经理没有
做过项目管理。所以这次和老板的确定无论对公司还是对个人都是有益处的。

第 108 页 共 756 页
第 1 章 综合管理

对于外部问题我认为,主要是双方老板因为关系而敲定的合同,从客户的各个部门都还没有得知,所
以在配合上都存在障碍。项目经理可以建议联合对方老板集中部门经理开个项目前期的动员会,明确
该项目的重要性,确定个部门的联系人员,建立对方公司在该项目实施期间中出现问题的汇总制度和
解决机制,以为有些问题需要公司老板定夺的。最好对方能推举出一个项目联系人,该人需要对公司
流程相对熟悉,一般这应该由副总来承担该角色。
以上是我的拙见,希望指正。

1.12 我的项目研发为什么失败?

我的项目研发为什么失败?

[姓 名] PMU [单 位] PMU [邮 件] PMU@mypm.net


[所属行业] 综合应用 [所属主题] 项目综合管理 [发布时间] 2006-8-21

【案例正文】
4 年多前,具有综合专业背景的我离开信息产业部的研究所来到了一家民营的医疗器械企业,
任研发中心的临床信息系统项目经理,但万万没想到,我所主持的技术研发项目的失败,却不
是因技术不过硬的原因。

上层分歧给项目带来麻烦 我刚来的时候,这个项目已经立项了,只是一直没找到合适的人来
实施。总觉得我是在受命组建一个新的部门,组织文化是空白,不会有任何问题的,可是上层
的一些分歧却给我的工作带来了麻烦。

公司的总经理和技术副总在工作上有矛盾。作为总经理招来的部门级主管,我在上班前一直没
与技术副总见过面,不知道这是不是算总经理犯的一个错误,虽然越级的人事安排也许有他的
考虑。 总经理介绍了他的一个同学作为我们的技术合作单位,我开始与其有一些初级的技术
交流,技术副总一次偶然得知此事。于是我有了一大罪过:“你们探讨的问题都是代表公司的,
到底谁是技术副总?

总经理找我谈话时,我好半天没缓过气来。如果就数据库内某个字段的定义、用哪个芯片更好
点的问题都要请示技术副总,我这个岗位还有存在的价值吗?

我开始反思,认识到自己犯了一个很严重的错误:初来乍到,别人还没认清你的特点,信任度
还没建立起来,怎么就没注意请示汇报呢!随后,我向副总承认了自己没有及时请示汇报的错
误,并澄清了我们只是进行了一些技术交流,没有任何的越权行为。我开始注意调查,发现其
实质是副总对该项目不是很热心,并因此与总经理产生了分歧,加上以前的许多事情,矛盾一

第 109 页 共 756 页
第 1 章 综合管理

下爆发了,我又是总经理招来的人,合作方又是总经理的熟人,这个事情就愈发的严重。

直接上司有时比董事长管用 无奈之下,我只好把合作方砍掉,并且事事早请示晚汇报。 不能
在同一个地方跌倒两次,我总结发现,直属上司的支持比董事长都好使。高层只能在战略上支
持,战术上还是直属上司的配合。正应一句话“县官不如现管”。另外就是新到任的职业经理一
定要对履新的岗位进行认真调查,入职前与未来的上司和下属进行沟通是非常必要的。

这次事件平息了,但有些事我不得不变得无所作为。很多审批权限在副总手里,于是项目一拖
再拖。8 个月后,在公司上层不断的施压下,项目组终于开始组建。

成也老专家,败也老专家 我们的团队中,有一位资深工程师,一位从业不久比较熟练的软件
工程师,另外聘请了一位老专家作技术顾问。

随后的阶段,那位老专家起到了保驾护航的作用。然而,如果没有对老专家的“过度信任”,也
不会有产品推出后的狼狈局面。因为该设备要用到手术室中,手术室的电磁环境不但频率复杂,
强度还不小,可惜这是产品销售后才得到的发现,为时已晚。开发中,也曾有人提出这个问题,
用不用考虑一下干扰问题,那位老专家一句话:“我们以前做过的都没什么问题。”问题是该老
先生原来是做非手术室设备的,其电磁环境条件比手术室要好得多。我尝试着提了点反面意见,
被很不屑地化解了。

“阻碍社会进步的不是少年人的无知,而是老年人的固执”,终于有了切实的理解。在技术工作
中,作为项目经理,别相信任何不经调查就得出的“没问题”的口头保证,尤其是所谓资深老专
家对新问题的结论。昨天的经验往往是明天失败的导火索。在预研阶段,要把所有可能的试验
结果都呈现出来,再做定夺。预研即使失败,损失也小得多。

研发人员指挥生产的恶果 产品开发过程平静而又顺利地结束了。我们决定采取用户购买后测
试的方式。由于用户测试过于漫长,在进入这个测试之前,产品就归档转生产了。

在我供职的这家民营企业,其高层和 80%的中层干部都来源于一家老牌的国有医疗器械企业。
这家公司长期从事手术床设备的相关业务,后来的新人也都是为那两个项目配的,所以新项目
除了我和我的团队之外,无人过问。我们求教于别人,经常得到友好而又歉意的一笑。

图纸完成了,生产部只安排了一个小伙子学习生产这个产品,没有安排专门的工艺人员转化工
艺文件。这时手术床的设备产量已经不小了,并且中了几个大标,中标的机器都是成熟老机型,
生产人员也较熟练,所以生产部就把主力都安排到那边去了。对生产部来讲,中标机器的生产
是主要任务,我负责的机器就降到次要而又次要的地步,物流的供货也是优先别的机型。

我太急了,太需要有一个结果来证明,急功近利的结局就是不懂生产管理流程的项目部开发工
程师全力配合生产,犯了瞎指挥的错误,导致生产过程检验不规范、装机不符合要求、生产检
验文档不全、零件编号混乱,一句话,乱了,一切全乱了。

第 110 页 共 756 页
第 1 章 综合管理

但是,机器还是源源不断地被发走。我暗自祷告,产量一大,我们开发的产品占主体时,一切
会好起来的。

越俎代庖的代价 刚开始的装机和培训,服务部门的工程师没有人特别熟悉这台机器。于是服
务部的经理找到我求援,希望开发工程师能出差。为了确保机器能顺利推广开,我应承了下来,
服务支持文档、服务工程师的培训就这样耽误了下来。如此周而复始,最后只要有客户咨询或
投诉,就直接转到项目部,使项目部的很多具体工作进行不下去。

这还不是最糟糕的,开发工程师并未经过服务培训,而我们项目部的工程师对那些又不了解,
其安装和用户培训却又要做,可想而知,结果自然是不到位,最后对机器、服务的抱怨都集中
到了项目部上。

拆东墙补西墙的救火没能使流程理顺,这时又出现了机器抗干扰差的投诉,这原本通过预研可
以提前预防,现在也尾大难调。只好找了一所大学的教授协助解决,虽有改进,结果也不是很
理想。不过我实在没精力拿用户进行试验了,加上这番折腾,这个项目的利润被服务、退货、
换货耗掉了一部分,销售渠道对产品的反应也很不好,抗干扰差、服务差、发错货,等等。面
对危局,我无奈建议公司决策层停掉该项目。

这个故事结束半年了,每每回想,总是感慨:项目不是在最后才失败的,也许它一开始就是一
个错误,也许它的路线方向就是错的。

【相关分析】

·错过了多次补救的失败(2008-01-20) [作 者] dajundalao [公 司] 暂时保密

本案例中的项目经理,应该说是一个有几分头脑但不懂项目管理的项目经理。可以肯定,他的应变能
力很强,他所差的是一套方法。建议去学习一下系统的项目管理知识,这会让他的项目管理能力有质
的飞跃。
首先,他一进入公司时,没有规范起来管理这个项目,从可研到项目立项到项目干系人及对工作的分
解都省下了,这是纯粹的国内项目管理的路子,听从领导安排,自己有限地发挥主动,及时调整自己
以适应环境,但没有办法把项目体系调整适应,以走一步看一步来解决。
其次,项目执行中,没有一个规范的程序,致使专家在项目中以经验代替了科学管理,工作结构分解
不明致使埋下后来客户投诉的祸根。没有规矩的管理只能是使有经验者占据主动,而不是按部就班。
再次,生产流程没有得到支持和质量标准没有确立、售后配套没有跟上的情况,责任在项目经理自身,
无论是否被边缘化,他都应该按部就班地进行工作,而不是从上级或其他部门的喜好来决定开展自己
的工作,因为无论他们喜好与否,你项目的工作不是那些,省不下一个环节。
最后,流程的不确定使项目以乱而终。没有一个象样的流程使项目在服务环节左支右绌,忙乱无章。
同时,流程中的培训如同走过场,没有实质性地开展,使项目最终以乱收场。

·非常好的案例,谢谢楼主!(2007-10-27) [作 者] 宋华先 [公 司] 秦武田制药

第 111 页 共 756 页
第 1 章 综合管理

学习了楼主提到的案例,非常的详细,其中也提到了存在的问题及导致项目失败的原因。看完后的第
一感受是应验了“墨菲定律”:有可能出错的事情,就会出错。不是不出,而是时候未到。正是由于项
目进行过程中的“投机取巧”,导致了最终项目的溃败。有客观大环境的原因,也有技术细节的疏漏,
还有由于时间紧迫导致管理上面的混乱。虽然一个项目失败了,但是其经验教训却是令大家受益的。

·定位不明确,以及项目干系人管理欠缺(2007-10-13) [作 者] 卢志坚 [公 司] 上海财经大学

看完楼主的案例,感觉上最重要的是楼主定位不明确和缺少项目干系人管理,在管理层比较复杂的情
况下,项目经理其实权限很少,特别是在一个自己都不熟悉的环境下,这个时候,最重要的是先给自
己下定位,在这个项目中的位子,如何去为这些项目干系人服务,无论是高层还是项目中的老同志,
都是不能得罪的,决不可用所谓的刚性原则去管理,放低自己的位子,其实说好听点,就是面向服务,
从全局角度上,尽量为每个人通过他们想要的服务,并他们的想法和全局的目的统筹起来,无论是谁,
只要尊重他,并为他着想,从他的角度去回答他的问题,除非是存心找茬,否则都比较好沟通的。

·也说两句(2007-08-26) [作 者] lwghui [公 司] sddsasdadsadsa

我也有类似经历,身有同感。我觉得一开始就没有把内部关系理顺,当然不是新进人员能理顺的,但
可以找到处理好内部人际关系的正确途径,虽然效果不见得会好但应该这么做。后来出现的问题只能
说能力还有缺陷了有待提高了。

·管理岂能与技术混为一谈(2007-08-26) [作 者] lwghui [公 司] sddsasdadsadsa

套用 28 法则,任何项目的成功,管理才是关键,技术只是次要因素。技术肯定不能代替管理,只有
在有效管理下技术才能发挥作用。

·旧的思维观念导致项目失败(2007-07-11) [作 者] 毛毛虫 [公 司] 烽火

看了 LZ 的文章,感觉此事此景在国企单位是比比皆是,我总觉得都是一个观念的问题,传统的、不
科学的观念可能会直接导致项目经理举步为艰,大家都想要在项目中体现自身的“价值”,结果就是
人人都要参与,人人都要发表意见,得到的项目结果就是失败,失败,还是失败!

·项目经理自身的能力不足毁掉了这个项目(2007-06-06) [作 者] yaogm [公 司] Motorola

1. 首先应确定研发产品的范围。即项目团队的工作范围和相应的里程碑。
2. 组织团队,并建立相应的计划,包括进度计划,资源计划,风险计划等。考虑到该企业的现状,
应该在制定计划时要充分考虑到计划的弹性。
3. 加强同直接主管的沟通。该项目的失败主要的责任应该是项目经理的沟通能力不够,不能是和直
接主管沟通不够,而且和团队成员还有相关部门的沟通也明显不足,导致项目的每一步都进行得十分
艰难。

第 112 页 共 756 页
第 1 章 综合管理

4. 根据企业的文化,灵活掌握自己的项目管理方法。
5. 合理安排团队成员的职责,不能因为其他工作而耽误自己的本职工作。
6. 在产生了可交付物后,应明确项目结束。

总之,正是由于项目经理本人在项目管理方面的技能较差,包括计划、沟通、领导等方面,而导致了
项目的直接失败。

·我的项目研发为什么失败?(2007-03-25) [作 者] 施浩 [公 司] 尚没工作

看了这篇文章,长了不少见识.
我们都强调沟通,但有些矛盾靠沟通很难解决.
单纯从产品来看,还是有市场的.
技术副总与总经理的矛盾确实对项目产生了很大的影响.但这并不是致命的."很多审批权限在副总手
里,于是项目一拖再拖。8 个月后,在公司上层不断的施压下,项目组终于开始组建。"可见公司上
层对这个项目还是比较重视的.如果自己能和技术副总沟通的多些,应不至于这么久,毕竟这对他没什
么太大的实际利益.
接下来所犯的错误要严重的多,直接导致了产品的失败.当然确实太急于证明点什么,焦躁之下很多行
为便没那么理智了.能沉的住气做下去,项目还是有很大成功机会的.

·my viewpoints(2007-02-01) [作 者] HSP [公 司] secret

1,You have no risk analysis before starting it and there is no risk management in processing.
2,You have no a change controling programm, so you can not improve your project plan and
meanwhile your plan was implemented very good.
3,You have no the communication plan and your personnal skill is scarce.

·客户签样很重要(2007-01-18) [作 者] Jack Pan [公 司] 上海易罗信息科技有限公司

新项目的验证标准有两个方面,1.客户要求;2.LZ 公司制定的常规标准。
新项目开发前,会议讨论依公司技术状态能达成标准,制定相关 SIP,与客户深入分析各个 SPC。
开发过程中,适时检讨各项状态并反馈客户,要求客户在图纸技术要求样品上做要求并签字。

·重要的一课(2007-01-10) [作 者] 杰罗 [公 司] 无

这件事对一个项目经理的成长是一件好事:
一、要承担起应该承担的责任,而不是逃避。
二、项目管理经验很重要

第 113 页 共 756 页
第 1 章 综合管理

三、协调各方面的关系更重要,这是项目经理最最最重要的工作,如何在利益关系复杂的环境中生存
下去且有所成就,是一门最伟大的学问。
四、按部就班的开展工作,不要想走捷径,永远都不要想
五、好好总结,这个案例足够每一位项目经理受用一生。

·失败的原因到底在哪里(2006-12-27) [作 者] 刘宇 [公 司] 大连市项目管理研究会

看完你写的这起案例,我本人对你的遭遇深表同情,也对某些企业内部的官僚扯皮勾心斗角的作风表
示唾弃。不过 4 年之后的现在,我相信你一定成熟了很多。

对于你描述的项目,我觉得有这几点原因导致项目失败:

1、项目的计划不能够贯彻执行。若说项目没有计划,那是不可能的,有可能是计划制定的不够完善。
在你的项目中,计划执行的很不彻底。预研的时候,不把全部可能的实验结果都做出来进行分析,犯
下经验主义错误;销售的时候,本该进行培训,你却为了帮助服务部经理把开发工程师派遣出去,没
有坚持做培训,犯下越俎代庖的错误。不按计划执行,还要计划干吗?

2、项目组成员责权利不够清晰。如果说你是被总经理任命为该项目的项目经理,那么在项目中,项
目经理就是老大。但从你的描述中,我感觉你不像是一个项目经理,反倒像一个项目经理助理,啥都
决定不下来,连在一个老专家面前你都不能坚持原则,要求对产品进行相应测试。还有,在资源紧张
的情况下,你没有进行资源优化,却安排不合适的人到不合适的岗位--开发工程师去搞生产,不乱
才怪。

3、沟通有问题,不能够很好地解决冲突。项目经理是干什么的?其主要任务中就包含了沟通、协调、
解决冲突。如果你跟副总之间达成有效的沟通,让副总深刻体会到项目的利害关系,那么掌握审批权
的副总,又何以对项目不热心,造成项目拖延 8 个月才开始进行。可以说项目从那一刻开始就已经是
失败的,就算你加班加点赶工期,大半年的时间又如何找回来?

不过,总得来说,项目并不是完全失败,因为最终你建议公司放弃项目,这在很大程度上已经挽回了
损失。正所谓:亡羊补牢,为时不晚。

·分析(2006-12-18) [作 者] 王颖 [公 司] 不妨边

看了你的叙述,发现没有任何的工作可以使该项目成功.
首先写了很多,都是存在的问题.如果你把每项都解决好那下次项目成功的机会一定属于你.
pm 应该随时把自己当成在创业。此时你就不能抱有 进公司享受职位的快乐。而应该以创业心态去认
识项目、操作项目、验收项目、对接项目。
技术类项目除 pm 要理解相关技术(或掌握核心技术或技术人)外,更应该通盘熟悉一家企业经营的
全部流。
当你熟悉后,其实你认为你已经像个 boss,自然你不是 boss。但你要以 boss 心态来管理项目。因为

第 114 页 共 756 页
第 1 章 综合管理

这样你才熟悉上、中、下 、客户在想什么,他们需求什么。
项目成功的关键是领导的支持,如何处理与领导们的关系,使他们为项目出力.才是项目经理的能力的
体现.
技术问题要经过实际的论证,要用数据和试验说话,个人经验不足以作为项目最终的技术方案的依据.
老专家我们要尊重,但不能听之任之,实践(试验)是检验真理的标准,以前的试验结果在项目中的关键
位置要重新试验和论证.
很多研发项目经理都是技术专家担任,是项目失败的原因之一.人不能在什么方面都是专家.用其发挥
最大的能力才是项目成功的前提.管理是管理,技术是技术.不能混淆.

·事前的风险分析(2006-11-07) [作 者] 聂建伟 [公 司] 中海油天津渤海石油

作任何事情都要作风险分析,若可能的话。
此项目经理除了考虑技术因素外,还需考虑单位政治,文化
不同项目部门之间的关系,与领导汇报得到支持。要有大局观。
关键里程碑控制好,沟通的事占每天工作一部分,关键审批,技术确认要存档,不要卷入政治漩涡。
项目做好是第一任务。

·总结教训,迎接成功(2006-10-26) [作 者] 高华 [公 司] 中国石油

看了你的叙述,发现没有任何的工作可以使该项目成功.
首先写了很多,都是存在的问题.如果你把每项都解决好那下次项目成功的机会一定属于你.
项目成功的关键是领导的支持,如何处理与领导们的关系,使他们为项目出力.才是项目经理的能力的
体现.
技术问题要经过实际的论证,要用数据和试验说话,个人经验不足以作为项目最终的技术方案的依据.
老专家我们要尊重,但不能听之任之,实践(试验)是检验真理的标准,以前的试验结果在项目中的关键
位置要重新试验和论证.
很多研发项目经理都是技术专家担任,是项目失败的原因之一.人不能在什么方面都是专家.用其发挥
最大的能力才是项目成功的前提.管理是管理,技术是技术.不能混淆.

·goutong!(2006-10-25) [作 者] Tony Neptune [公 司] SIPSC

项目经理的第一,也是最后、最关键的任务——沟通。
什么事情都提前安排,沟通好了,用人所长。不会这样。

·学习与人建设更加强化的人际关系网(2006-10-22) [作 者] 杨梦云 [公 司] 上海蜗牛有限公


第 115 页 共 756 页
第 1 章 综合管理

学习与人建设更加强化的人际关系网

项目经理,不是简单的进去做技术就行。而是一个更加商业的角色。
1、首先除按照 pmp 规范建立相关的项目套装式管理、资源、流程外。应该建立一个强化的 人际关系

2、分析案例,可以得出楼主不擅长与顶层公司管理层打交道,甚至与其有严重的意识冲突而不知道
如何去划解(这是项目失败的原因主要因素)

3、pm 应该随时把自己当成在创业。此时你就不能抱有 进公司享受职位的快乐。而应该以创业心态


去认识项目、操作项目、验收项目、对接项目。
技术类项目除 pm 要理解相关技术(或掌握核心技术或技术人)外,更应该通盘熟悉一家企业经营的
全部流。
当你熟悉后,其实你认为你已经像个 boss,自然你不是 boss。但你要以 boss 心态来管理项目。因为
这样你才熟悉上、中、下 、客户在想什么,他们需求什么。

4、建立清晰的 人际资源管理意识,同上,你应该熟悉上、中、下 、客户在想什么,他们需求什么。


这就是项目客户管理。
项目 pmp 里不有个变更、前期需求、需求分析及随时更新的东西么?
楼主学习 pmp 不应该硬抄袭,而应该从实践中积累自己的流程及疏通化经验。

楼主应该加强人际交流及公司流管理及疏通经验。这一块可以使你在未来项目里逐步取得更大的成功
可能性。

目标管理这本书 有句话说得好。管理、项目管理,首先管理的资源是人,而不是技术。学习管人力
资源,是做任何经理的第一步。

·preparation and analysis(2006-10-20) [作 者] 章国新 [公 司] Qimonda IT (Suzhou)

need to do more preparation and analysis

·the skills of operate process(2006-10-19) [作 者] 陈锋 [公 司] SEVEX

one word,no do somethign if you are not make enough preparation and good conmunicaiton

·没经过验证就能批量生产?(2006-10-19) [作 者] 于佳 [公 司]

第 116 页 共 756 页
第 1 章 综合管理

没有经过严格的测试与临床试用,就敢批量生产与销售,是真无知者无谓!

·项目执行力(2006-10-14) [作 者] 李谦 [公 司] 一汽

同意楼下,项目不错。很可惜。有一点看法不知正确与否。
1、此项目失败,有一点重要的原因是计划执行力不强,连重要的型式试验都可以评一句话省掉。不
出问题才怪。
2、没有取得足够的支持,告诉你一个窍门。为什么不在开项目组成立会上将副总牵扯进来,这就需
要人际关系了。本来在此类企业这种关系应比国企好摆平许多,此类事情我干过。

·这实在是一个好案例(2006-10-10) [作 者] 杨杭 [公 司] ...

首先要说的是这个项目是一个好的项目,从后来市场反应可以看的出来,没完善的产品都可以很顺利
的推向市场,说明市场需求是大的,项目是可行的。
第二,从项目的计划以及过程管理是不完善的。从这个例子可以很明显的看出在项目后期的管理非常
的混乱,计划的不完善,资源的不到位直接导致项目无法很好的控制。项目经理以为产品推出项目就
差不多完了却把最重要的收尾工作给忽略了,作者也意识到了这个问题,说乱了,全乱了。
第三,在项目过程中对项目组成员无法很好的控制,老专家提出的也只是一言,项目经理怎样把项目
团队的意见中和并最终得出最可行的方针是非常重要的,否则就失去了一个团队的功能。
第四,此项目经理沟通和大局把握的能力欠缺,无论是横向的沟通还是纵向的沟通明显都不够,项目
无法得到其他部门的完全支持,这造成了产品推向市场的被动。
第五,对产品的控制太差,一个生产过程检验不规范、装机不符合要求、生产检验文档不全、零件编
号混乱的产品就这样交到市场只能说明研发该产品的项目团队是失败的

·dd(2006-10-03) [作 者] yangjin1234 [公 司] dd

同项目不是在最后才失败的,也许它一开始就是一个错误,也许它的路线方向就是错的。

·同意楼下的观点(2006-09-22) [作 者] daijiangbao [公 司] 深圳市大视野项目管理有限公


技术不能代替管理,技术要在有效的管理下才能发挥作用,一味强调技术是十分有害的,对任何项目
的成功,技术都不是成功的关键因素。
举例来说,毛泽东完成的新中国建立这场革命,实际上是一个延续很长时间的项目,但是毛主席就不
懂技术,他连枪都不会打,但他是指挥枪的。
如果认为一个小兵枪打的好就是一切都好,要当高级领导,不知道大家是否看到这样的结果,为什么
在我们现在这个相对技术不缺乏的时代,却还是把雕虫小技的技术看得比什么都重要,导致了很大的

第 117 页 共 756 页
第 1 章 综合管理

偏差还不知道问题出在什么地方?

·技术与管理(2006-09-15) [作 者] giant [公 司] 上海某研究所

我怀疑你在这整个项目中投入的主要精力是技术而不是管理。不是技术人员不适合做管理,而是没经
过管理培训的技术人员做管理是很不合适的。
我们研究所为了留住人,在 2004 年任命了一批中层干部(管理人员),但现在发现他们都有一个很
致命的缺点:自以为是。他们中的许多人只知道完成自己的事情就行了,而不知道要鼓动他的项目组
成员共同完成事情。我的一位老师说的相当好:现在的项目大部分的失败不是技术,而是管理。我的
这位老师,先后从事轮船制造,钻井勘探,系统集成,城市开发,项目管理等方面的工作。是位从技
术到管理模式成长的大家

·对目标的持续关注是成功的基础(2006-09-11) [作 者] 程天 [公 司] 全益物流有限公司

可以看出您希望靠综合的能力和专业精神,在进入新的企业负责重要项目时奋勇干一番事业。但是,
对目标的持续关注力度不够,影响了项目的执行和效果。
一开始就需要弄清,是否公司上下对此项目的期望一致。老总、副总、同级、下属,是否都希望这个
项目按什么什么方式成功,产出怎样的产品。这样就避免了大干一场才了解到自己掉进夹缝。
执行过程中也要始终把目标放在眼前。主要目标是速度快做出东西来,还是稳稳当当干出风险小于
◎◎##的东西来?你的目标和老专家的目标是否一致?
研发结束产品生命周期按理应该启动第二个项目,但因为研发项目的产出堪忧,也就谈不上第二步了。

·团队协作(2006-08-30) [作 者] zonghui [公 司] 上海

管理者主要是合理有效的组织项目团队,高效率的工作,及时解决团队中的问题;而该项目自始至终
都存在团队内部矛盾,导致该结果也是必然的。

·技术管理两个都没有做好(2006-08-29) [作 者] chiao [公 司] zxrjjs

可以看到,这个项目是失败的。
技术上有问题没解决,管理上更是有大问题。两者积累到一起,不能说是哪一方面的错。也许在项目
启动时就注定要失败,由于项目水平有限,相信大多数项目都要靠项目经理的强力带动及上层领导的
支持,不然很难做好一个项目。
我认为这个项目的问题是项目经理没有协调好各方面的关系,项目成员间没有进行有效的沟通,技术
上也很失败,但最重要的是没有搞好“需求”。仍停留在原始的级别上。

·火气不小,有代表性(2006-08-28) [作 者] daijiangbao [公 司] 自由职业

第 118 页 共 756 页
第 1 章 综合管理

这是个很敏感的问题,也是大家关心的问题,也是不服气的问题。
1、这个说法是早就有的,不是我杜撰。
2、技术和管理是不同的,尤其是国外,将技术和管理是分开的,当然绝对的分开是没有意义的,在
国内可以说绝大部分没有项目管理,所以就拿技术来代替管理,到最后出了问题还不明白是什么原因,
而项目管理是管理。不是技术,但是却有绝大多数人认为项目管理是管理技术的技术,是非常糟糕的
事情,一说项目管理就是指什么输入、输出、九大知识体系,显得这些管理技术过关了,项目就能做
好,我想大家应该可以从这样做的实际效果来得出正确的结论。
3、本案例说的实际上就是这样的事,是因为项目经理不能造成一个项目管理的平台,让这么多的项
目干系人不能对项目作出贡献,总是认为自己是项目经理,把工作做好了就可以了,为什么有这么多
的磕碰,不能理解,是的,从技术上是不能理解的,也不是理解万岁的问题,而是根本就不该这样做,
这些项目干系人,你如果不能很好的识别,让他们作出贡献,那么,他们不做出正面的贡献,就有可
能做出反面的贡献。
项目经理要会沟通会协调,要掌握平衡的艺术,这些都不是技术人员所擅长的,尤其是很专业的技术
人员,这更是一个做项目经理致命的弊病
技术和管理不是一回事,要在项目中很好的结合起来,相辅相成,不能用一方来代替另一方,需要更
加关注的是不能用技术来代替管理

·没有听过:“项目管理早就尖锐的指出,技术人员是不适合担任项目经理的”(2006-08-27) [作
者] 游永明 [公 司] 广东省计算中心

非常不明白楼上有人说:“项目管理早就尖锐的指出,技术人员是不适合担任项目经理的,尤其是技
术尖子,更是不适合做项目经理。”
不知道他的理论从哪里来,根据何在?不懂技术的来作 it 管理或者产品开发管理可能吗?你以为项
目管理就是决策层那种 XXCEO 的事情么,只推销过汽水的都可以做 IT 巨人的 CEO,但是技术管理和
高层管理是明显有区别的。

·沟通能力不够(2006-08-24) [作 者] 于先生 [公 司] 南方数码

感觉像是是一篇小说,说明你沟通难以抓住重点,详略模糊。项目一开始方向就偏离,你却很难决断
控制,一样表明作为 pm 最基本的沟通能力不强。

·预先计划,到位的管理(2006-08-22) [作 者] 刘杰 [公 司] 杰瑞集团房地产开发公司

读了你的案例
感觉这事情从开始就有点错误,而你又是从外单位聘来的,首先了解项目的具体情况然后再针对问题
进行分析,做出决策。
在工作中要与上级及时沟通,让他们知道你在做什么,这也是必须的!
在项目研发过程中,要使自己的管理理念真正到位,做到真正的“项目管理”!

第 119 页 共 756 页
第 1 章 综合管理

·产品研发管理方法-IPD(2006-08-22) [作 者] 洪布坤 [公 司] 普华

学习一下 IPD 研发管理流程吧,相信对你和你的产品研发项目管理有用。

·觉得还是你的管理能力没有做到位(2006-08-21) [作 者] 中国武则天 [公 司] 电信公司

刚刚看了你的案例,觉得主要问题应该在你,就是沟通,计划,策略,组织能力都做的不够。
1.首先你的案例完全可以用最直接方式告诉大家,结果你写了很多,说明你沟通能力不够好;
2.刚刚来公司在没有了解通彻的情况下,没有任何准备就直接接手一个这么重要的项目,你真是很
牛。。。
3.做项目执行前,没有看你提到任何执行计划或者方案;
4.在整合项目执行中你没有考虑到如何借助你的直接上司的能力去协助你完成此项目,一个人的力量
是有限的;项目是需要配合才能完成的,你是负责牵线的人;

·项目干系人分析不对(2006-08-21) [作 者] daijiangbao [公 司] 自由职业

从案例的叙述中就可以知道,有这样多的人都会对项目作出贡献,为什么不提供一个项目的平台给这
些人作出贡献?
项目经理的职责在于提供项目一个平台,让项目干系人在这个平台上作出职责内应有的贡献。
项目管理早就尖锐的指出,技术人员是不适合担任项目经理的,尤其是技术尖子,更是不适合做项目
经理,项目管理是管理,是艺术,不是技术,政治问题,权利斗争都是需要项目经理要注意的方面,
这些问题的解决才能体现项目经理的能耐,也才能团结更多的人在项目平台上作出贡献,显示项目管
理的价值,而不是技术的价值。
尤其是现在,技术从来就不是项目成功的关键因素,要记住从来就不是,技术这就是毛泽东所蔑视的
“纸老虎”,但是现在这样的纸老虎却满世界的乱跑吓唬人,而且大多数人都给吓住了,真是很不正
常的,需要还原这个世界的真实面目,这样才对项目成功有最直接的意义。

1.13 如何管理和下派工作?

如何管理和下派工作?

[姓 名] 陈代军 [单 位] 不公开 [邮 件] cdj_801276@163.com


[所属行业] 通信与网络 [所属主题] 项目综合管理 [发布时间] 2006-7-31

第 120 页 共 756 页
第 1 章 综合管理

【案例正文】
我公司为通讯工程行业,总公司给在 5 月 10 日给下属 10 个分公司下达了任务:要
求在 6 月 10 日提交各个分公司所在地区的基站故障统计。但是在 6 月初检查时发现
有 3 个分公司所统计的报告形式个不统一,杂乱无章。还有 4 个分公司说没有时间,
3 个分公司说没有接到此通知。

1:假如你是总公司技术总监,你将怎么办?
2:假如你是分公司总经理或区域维护主管,你将怎么办?

【相关分析】

·标准的统一(2006-11-08) [作 者] 聂建伟 [公 司] 中海油天津渤海石油

工程起步之前应统一好本项目所有标准,入报表,汇报沟通时间日期书面形式等。便于今后沟通,协
调。
定期招开所有分公司经理会议,沟通并接受反馈。
工程编码标准做好。

·执行力!(2006-10-05) [作 者] 王丰江 [公 司] 北京华深

单位的管理制度有一定问题!

·单位的管理制度有一定问题!(2006-10-05) [作 者] 王丰江 [公 司] 北京华深

自上而下信息发布,自下而上的信息反馈。
1.引用 PMBOK 方法论,规范标准;(杂乱无章)
2.利用 PMIS,促进有效信息传递;(没接受到通知)
3.建立企业知识管理系统,员工(经理/总监)内部培训,提高企业核心竞争力

·mj(2006-10-03) [作 者] yangjin1234 [公 司] dd

项目经理作为“项目目标”的“监护者”,需用 WBS 方法分解目标,用 RSKM 方法管理可能存在的问题;


同时,按照软件工程基本方法,给出“工作模板”——“提报数据的方法、格式”;
然后,编制“项目计划”——区域维护主管汇报进度表。

·如何管理和下派工作?,(2006-10-02) [作 者] badragon [公 司] 位无无我无

我觉得还要有公司的企业文化才可以在制度上进行管理

第 121 页 共 756 页
第 1 章 综合管理

·0(2006-09-30) [作 者] 袁骥 [公 司] 伟擎厦门管理咨询有限公司

告诉下司工作项目及目标,时间表,资源等即让其实施;
期中须进行适时地跟进。

·我的目标,谁会支持?(2006-09-29) [作 者] 杨锋雷 [公 司] 上海久隆信息工程有限公司

老板是用屁股决策的同志,项目经理是用方法征服群众的可怜人。
对于老板来讲,大家必须拥护我的决策;
对于项目经理来讲,我必须实现老板的目标而提高自己的薪水;
对于项目团队成员来讲,我以最少的时间完成任务,以便提高工作绩效。

在此项工作中,总公司技术总监担任“项目经理”角色,“区域维护主管”是我们的衣食父母
——“项目成员”。
项目经理作为“项目目标”的“监护者”,需用 WBS 方法分解目标,用 RSKM 方法管理可能存在的问
题;
同时,按照软件工程基本方法,给出“工作模板”——“提报数据的方法、格式”;
然后,编制“项目计划”——区域维护主管汇报进度表。

另外,视总公司和分公司的管理模式,采取适当“上传下达”方法,确保“工作任务和进度”的有效
传达。

方法理想了些,具体操作时随机应变。

·软硬件均不完善,典型的一盘沙(2006-09-27) [作 者] Louise [公 司] XX公司

无论说没有接到通知,或者是说没有时间的,都属于硬件问题

另外 3 家统计格式不一则属于软性问题。

对于硬性问题,得从上之下,要得到高层支持和整治才能有效,

而对于软性问题,则可以通过方法来解决:例如标准化的模板,细致的沟通和过程中监控。

个人建议,仅供参考!

·典型的沟通不到位(2006-09-27) [作 者] 安德鲁 [公 司] sidetaike

第 122 页 共 756 页
第 1 章 综合管理

这是典型的沟通不到位,也可以说是没有做到协作。如果你和分公司的对应窗口沟通没成效,你应考
虑和他的上司沟通,甚至总经理董事长。

·兴趣是第一(2006-09-26) [作 者] 罗杰 [公 司] tpbirds

学习激情的学者或项目经理,有兴趣研究的邮箱联系。

·自上而下,自下而上(2006-09-26) [作 者] 罗杰 [公 司] tpbirds

自上而下信息发布,自下而上的信息反馈。
1.引用 PMBOK 方法论,规范标准;(杂乱无章)
2.利用 PMIS,促进有效信息传递;(没接受到通知)
3.建立企业知识管理系统,员工(经理/总监)内部培训,提高企业核心竞争力。(没时间处理)

·如果我是总公司……(2006-09-16) [作 者] 梦游吧 [公 司] 中国传媒大学

1、布置任务应该有明确的接收者,每个分公司应该有固定的说得动话办得动事的人来接受总公司下
达的任务,不能逮着谁算谁;
2、任务的布置也不能只是一个简单的口头传达,应该形成书面形式,写出具体要求、期限,要求收
到任务的负责人先给回应,多些沟通才有可能把事情做好;
3、至于任务的完成,就是他们内部的分配问题了,你就抓着那一个人就成,这样会使你的工作简单
很多,避免互相推卸责任的现象。

·国企的办法(2006-09-05) [作 者] 张骁勇 [公 司] 中铁十七局集团四公司

在国企中任何事情要用 5000 的文化来做。你的事情其实不是什么大事。总共才 10 个分公司嘛,一个


个地打电话催:1、要说明你有难处,要他帮忙;2、随便问一下他们是不是有困难,如果有我可以给
你们老总联系一下,让他给协调解决一下(这其实就是恐吓);3、给他们最近期限,不能完成的话
就……如何如何。

·如果我是总公司(2006-09-01) [作 者] 梁永锋 [公 司] 茂名学院

到了日前的情况应该放宽日期,但要加强管理,明确责任。做成当前的局面,在技术方面应该有一定
的难度,作为技术总监的你,应该积极作技术指导。对一些不服从管理的子公司人员,应该要杀一警
百。

第 123 页 共 756 页
第 1 章 综合管理

·如果我是.....(2006-09-01) [作 者] 一阵疯 [公 司] 上海伍海气配

1.总公司技术总监
(1).弄请目标:要求在 6 月 10 日提交各个分公司所在地区的基站故障统计(已经有了);
(2)为了达成这样的目标,方法是什么?了前之前有没有这样的先例?几个公司之间的位置关系?得到总
公司的有那些授权?权利是什么?是否需要跟各个子公司相关人员或者高层进行沟通,了解他们的目前
任务情况.任务完成后绩效考核
(3)计划.根据(2)5W2H
(4)协调各个公司的资源,宣讲这个情况的重要性.
(5)监督/跟踪

·如果我是……(2006-08-23) [作 者] 古晓松 [公 司] 上海兰德公路工程咨询设计有限公司

1.假如我是技术总监
(1)我会问我自己故障统计这种事怎么没有统一的格式登录,怎么不是定期要做的,我干嘛去了?
(2)看“中国武则天的”。
(3)如果第(1)点是既有的,还发生这种情况,我会告诉他们“你们通通不要做,我来做(我来找
人做)”
2.假如我是分公司总经理或区域维护主管
赶快找人做(赶快做)

·如何管理和下派工作?(2006-08-17) [作 者] 袁月建 [公 司] sos软件工作室

1:假如你是总公司技术总监,你将怎么办?
2:假如你是分公司总经理或区域维护主管,你将怎么办?

·我们不缺策略,缺的是执行力(2006-08-07) [作 者] 牧野李 [公 司] 河南通信

规范制定是要执行的,执行力是关键.思路是很明显的,但是具体执行是需要很多努力的

·应该提高总公司的执行力(2006-08-06) [作 者] 游永明 [公 司] 广东省计算中心

比较典型的只有指令没有执行的案例。总公司发出通告,但是没有良好的沟通机制等原因,子公司没
有执行或者执行不合理。作为总公司的技术总监,应该首先明确这个问题是否组织结构问题,还是办
事流程问题。居然会出现子公司说不知道的情况,问题是属于比较严重的。
另外,报告格式不统一这是总公司指导不力的表现之一,因为下通告的时候你并没有指明格式,或者
说指明规范,当然不统一是正常的事情。

第 124 页 共 756 页
第 1 章 综合管理

至于子公司借口没有时间,这就是执行力的问题,需要高层的配合。

其它的问题陈克鑫说的很清楚了,呵呵

·最显著的沟通问题(2006-08-04) [作 者] 王海飞 [公 司] XX通讯有限公司

个人觉得这是个最显著的沟通问题,先把这个问题解决了再谈其他的东西吧!!!!

·如何管理和下派工作?(2006-08-03) [作 者] lydia [公 司] neau

建议您:
充分利用 project2002 这个软件进行时间与事件的有机统一,
加强总公司下达任务的强制力度,
对报告提交的内容\形式\期限等方面应该是总公司提前就做好的.
补救措施:
做好统一的报告提交文件,
并要求下属公司准时完成.

·管理流程的问题(2006-08-02) [作 者] Howard Hong [公 司] 上海普华

发生上述情况,根本的问题在于 3 个方面:
1、公司是否有相关工作流程?
2、如果有,流程是否完善?
2、如果有,那么是否执行了?

搞清楚了上面 3 个问题,接下来的处理工作就简单化了,在此不再赘述。

·很简单,告诉你(2006-08-01) [作 者] 中国武则天 [公 司] 电信公司

直接借助邮件来解决问题:
1.发邮件明确你的统计需求,并 CC 给下属十个公司的直接主管或者高层领导;
2.邮件中明细统计需求和完成时间后,在通过电话逐一跟进;
3.如果统计模板不规范,就尽快发给他们发一份规范模板;

如果是技术总监就把责任分配到人,这样执行会快些;如果是分公司总经理或区域维护主管就自己去
盯。

个人建议,请参考!!

第 125 页 共 756 页
第 1 章 综合管理

·任务分配和向上管理(2006-08-01) [作 者] 陈克鑫 [公 司] 索尼

作为技术总监
1、有必要向各分公司明确此统计的目的及其可以带来的利益;若是可能,最好在下发这类任务前,
与各相关人员和部门、各分公司交流以取得积极响应。避免作自我娱乐的动作。
2、设计合理简洁的统计表格,统一形式
3、以书面形式传达,避免产生误解或误差
4、指定负责此任务的专人进行跟进,确保及时准确的完成。

作为分公司总经理或区域维护主管,是需要服从总部的任务分配
的,但若是有不同意见,应该及时提出异议或者更佳的建议以及需求。

1.14 如何估算大型项目的工作量?

如何估算大型项目的工作量?

[姓 名] 周干妙 [单 位] 广东 [邮 件] ganmiaozhou@163.com
[所属行业] 综合应用 [所属主题] 项目综合管理 [发布时间] 2006-5-22

【案例正文】
我是一个九人开发团队的领头人。一般来说,我们所从事的是(项目)支持和强化
的工作,但是有的时候,我们被要求完成一项大型工作,而这项工作大到肯定可以
被作为一个项目来看待。

我们所面临的问题是:我们很难估算需要在这些大型项目上所花费的工作量和时间。
通常我们对工作量的估算不足,所以搞得在最后几个星期里才拼命加班完成所有的
工作。我正在尝试先预估工作量,然后在未来将其翻倍。有没有什么简单的方法能
够解决这个问题?

【相关分析】

·拙见(2008-03-12) [作 者] 韩文奇 [公 司] 无

本人推荐最新的 FFP 方法 用这个方法来评估你手头工作所需要的时间


误差基本小于 10%

第 126 页 共 756 页
第 1 章 综合管理

·做到可控、可收(2006-10-05) [作 者] 王丰江 [公 司] 北京华深

管理其实是一项十分复杂的工作,要做好前期应作大量分析工作,特别是大型、综合性项目。WBS
是一种分析方法,但其分解有时过于庞大,收不回来感觉。我推荐一种项目流程管理方式,即将项目
分解成不同模块,通过流程串联,每个模块进行详细分解,即可做到可控、可收

·WPS任务分解(2006-10-05) [作 者] 王丰江 [公 司] 北京华深

将项目细分,并逐步跟进审核看是否按时完成

·有工期的要求。(2006-10-05) [作 者] 王丰江 [公 司] 北京华深

任何一个项目的都首先要根据合同进度的要求编制工期预算,对大型项目还会将其进行分解成若干个
子项目或若干个阶段来实施,在将分解成的小项目或阶段制定更详细的工期预算,一直将项目的工作
进度或内容细分到月、周、日,然后在根据人力的配置分解到个人。根据工作量配置人员(这应当有
可参照的经验和记录,除非你对下面根本不了解)
,如现有人力不足,一是安排加班二是增人,作为
管理人员一定要每日检查工作任务完成情况,不能将工作量拖延下来,否则最后匆匆忙忙加班,质量
不能保证说不定还会延误交付。将项目分解、工期(进度)和工作量细分是关键,但一步步细化做下
去,并不是很难。

·做好前期项目单元分析工作(2006-07-20) [作 者] 郭贤峰 [公 司] 青岛

项目管理其实是一项十分复杂的工作,要做好前期应作大量分析工作,特别是大型、综合性项目。
WBS 是一种分析方法,但其分解有时过于庞大,收不回来感觉。我推荐一种项目流程管理方式,即
将项目分解成不同模块,通过流程串联,每个模块进行详细分解,即可做到可控、可收。对项目管理
是十分有用的

·这是一个难题(2006-07-17) [作 者] 秦胜利 [公 司] 广东轻工职业技术学院

大型工程的工程量确定了,也就可以根据相关的定额确定人员和工期了,工期也就可以预计了。
工程量的确定,首先需要请专业人士(不一定外请)对整个工程进行认真的研讨,做出任务分解,这
种分解是一项专业性很强的工作。尽量避免工程量过大或漏项,当然绝对准确也是不现实的。
其次,需要参考类似的工程,做出对比,对分解的任务进行对照,找到一个相对接近的数量。
第三,利用政府公布的相关定额和掌握的市场平均造价,对工程量进行再估算。

第四,提出的工程量估算,还要预留一定的修正系数,或不可预见的量。

·如何估算大型项目的工作量?(2006-07-06) [作 者] 百友子 [公 司] 佳讯飞鸿

1、有时候我们对于一个项目工作量估计不足,是因为没有很好地对项目任务进行分解;

第 127 页 共 756 页
第 1 章 综合管理

2、任务分解的方法比较多,但是 WBS 方法比较方便实用;


3、任务分解后,自然就需要我们认认真真的对待每一项细化的任务,而不是“瞒天过海”,一拍脑
袋,随便承诺了。任务分解,就需要考虑目前的能力、人力,并结合经验值,评估该项子任务所需的
工时;
4、每一个子任务的工时最好以 2 周(或小于 2 周)为单位,这样评估准确,控制也会比较到位;
5、如果我们对任务的内容不清楚,或者对项目的运作不熟悉,也可能分解时仍然会有被遗漏的地方,
但是通过这种方法,会使这类问题变得越来越少!而对项目驾驭的能力却越来越强!

·工期预算(2006-07-05) [作 者] 董晓云 [公 司] 江苏天技科技实业有限公司

任何一个项目的都有工期的要求。首先要根据合同进度的要求编制工期预算,对大型项目还会将其进
行分解成若干个子项目或若干个阶段来实施,在将分解成的小项目或阶段制定更详细的工期预算,一
直将项目的工作进度或内容细分到月、周、日,然后在根据人力的配置分解到个人。根据工作量配置
人员(这应当有可参照的经验和记录,除非你对下面根本不了解),如现有人力不足,一是安排加班
二是增人,作为管理人员一定要每日检查工作任务完成情况,不能将工作量拖延下来,否则最后匆匆
忙忙加班,质量不能保证说不定还会延误交付。将项目分解、工期(进度)和工作量细分是关键,但
一步步细化做下去,并不是很难。

·要估算准确!(2006-07-03) [作 者] 赵宏伟 [公 司] 东信北邮

首先最重要就是先把工作分解的合适了!

如果你没有把工作首先分解好,那所需工作的时间成本的估算就没有依据了!

只能是你自己拍脑袋决定 需要多少人工,

其次 分解好各种工作任务之后,每个工作包可以根据经验或者其他途径确定其所需时间

而且要知道不同工作之间的先后关系,哪些工作可以并发,哪些工作只能按顺序作。。。。

·进度评估(2006-07-03) [作 者] 刘文军 [公 司] 艺进装饰

估算项目进度是需要有大量工作经验加上对各项工种的熟悉程度及在施工时会出现的各种情况进行
评估

·分步和分类。(2006-06-08) [作 者] 汤江南 [公 司] 北京伽略电子系统技术有限公司

我估计你能提出这个问题,可能对项目管理知识不太了解,因此前面几个朋友给你建议的 WBS 图什么

第 128 页 共 756 页
第 1 章 综合管理

的不一定适用。我给你一点简单操作的建议。你搞一张表,按照项目整个过程可能需要执行哪些工作
的流程写下来,然后进行分类和分步--简单的统计学原理。再把你团队中的人员名单写下来,如果
你愿意,可以对这些人的业务范围和工作能力写下来。最后,做一点统计工作,来估算你的工作量。
比如:把任务写在 excel 表的纵列,把人员名单放在行格,对每一个任务分析每个人如果担任可能需
要的时间(比如熟练的一天、一般的 2 天、不熟练的 3 天),然后给每个人分配工作任务,使整个团
队的工作量基本上平均。方法二:把你的时间按日期在 excel 表的第一行从起点排到终点,再在第一
列上写上工作的任务,把每个任务从执行期的第一天到最后一天画上一根红线,再在这个表的最后一
列写上执行这个任务的人员名字。好了,你每天对照这张表看看你的项目是否按期在执行,如有落后
的,赶快催他们啊。
其实,这些东西地球人都知道。

·做好任务分解 (2006-06-08) [作 者] 安安 [公 司] 北京

用 WPS 任务分解,将项目细分,并逐步跟进审核看是否按时完成。

·很简单(2006-05-31) [作 者] daijiangbao [公 司] 自由职业

做好软件产品的分解,做好工作任务的分解,做好组织结构的分解,自然解决这些所有的问题

·如何估算大型项目的工作量?(2006-05-31) [作 者] 王海飞 [公 司] utstarcom通讯有限公司

鄙人觉得:
首先,必须要找到几个对这种项目有经验的人员共同进行评估;
其次,尽可能详尽的考虑其中的风险;
第三,借鉴相关性质的项目作为参考。

·准确的估算来自大量的经验(2006-05-29) [作 者] 王雄禹 [公 司] 中建国际建设公司

任何估算的准确性与否很大程度上取决与你的经验和对要估算的对象的认识深刻程度.

·不能简单地翻番(2006-05-29) [作 者] 孙先平 [公 司] Supersun china

如果只是简单地将工作量乘以一个系数,显然有失考量.
其实你业已做过几个这样的大项目,可以尝试一下总结一下:
1-哪些是影响项目进度的主要因素,找到了,放大该系数;
2-哪些是与预估工作量是未能考虑到的因素/造成偏差的因素,视为风险,放大该系数

第 129 页 共 756 页
第 1 章 综合管理

·软件项目工作量的估算(2006-05-29) [作 者] 黄伟 [公 司] 开发部

作为项目管理中的进度管理是非常重要的一个知识领域,其重要程度甚至超过了成本的管理,如果进
度失控,将给公司的形象,产品或服务获得客户的及时的认可都有很大的影响,因此,管理好项目的进
度是非常重要的,首先,无论项目的大小,我们都要依照项目定义好的 WBS,分析并提取其最底层的活
动,形成活动列表,并将活动列表进行排序,其次是获取相应的项目需求的资源,并作出资源计划,然后
对活动进行历时估算,最后做出项目的进度计划图,并分析好相应的关键路径,在关键路径上对项目进
行严格的控制.对于大型项目,建议同时采用滚动计划,这样作完上一阶段的工作,可以及时的评估和
跟踪下一阶段的进度计划,这样综合起来对进度进行控制,对项目的进度管理会产生非常大的作用.

·准备工作的重要性(2006-05-29) [作 者] 林相谦 [公 司] 南通四建集团有限公司

对于任何项目接手以后不能立刻就发给下面的执行人员.
首先作为领导人员应该对整个项目进行评估和整体的规划,
需要在大脑里面将整个项目先执行一遍.
然后根据以往的经验有重点的给下属安排任务,
作为领导者需要做的是督促手下分解目标的完成,
和相关界面的协调,而不是亲自为之,因为领导者需要掌控全局.
最后留一定的机动时间是必要的,
既可以使项目更加趋向完美,也可以作为不时之需.

·有问题请加入项目管理师(2006-05-29) [作 者] 段柯 [公 司] 徐州市

项目管理师 QQ 群:25428161 欢迎参加项目管理讨论~!

在此我们畅所欲言,在线分享,将项目管理进行到底!

验证时请输入:项目管理师

·如何将工作准确量化(2006-05-28) [作 者] 陈军辉 [公 司] 东北农业大学

如果团队对不了解的工作进行操作时时会发生任何情况的
作为领队应有预测风险的能力,量化工作应请教专家即有
经验的人员进行评估,并有针对性地做出解决风险的方案,
加班是下下策时间多方在前期准备上会好一些并且会收获
大一些

第 130 页 共 756 页
第 1 章 综合管理

·请有经验人估计(2006-05-23) [作 者] jackie [公 司] 灵图软件

如果你对项目过程比较陌生,不能估计各个阶段的时间,还是请些有经验的人做下 delphi 分析,算出


的时间再除以 70%-80%作为计划的时间比较好。

·我这样想是不是太幼稚了?(2006-05-22) [作 者] SP [公 司] 成都信息工程学院

不能叫公司领导把任务交给其他更合适的人吗?
或者向公司内部熟悉类似工作的人请教呢?

·拙见(2006-05-22) [作 者] 张辉 [公 司] 升德升(连云港)电子有限公司

对于每一个项目,如果计划完成日正好为项目交工日的话,那么,十有八九会在项目的最后一段时期加
班.最好在订计划时给项目一个机动时间,把计划完成日适当向前提前一点,这个是项目经理应该把握
的一点.

·分期计划并实时调整(2006-05-22) [作 者] 于晓溪 [公 司] 南方数码

大项目一般可以分为几个部分,首先根据各部分内容制定实施计划及进度表,计划时分两种情况:一
种是重复性劳动,比较容易估算时间;一种是还可以细分的,分得越详细越好估算时间。其次项目进
展过程需要根据前期进展情况适时修改进度。
当然,可以效仿类似案例经验。
如果没有,只能按部就班的作详细计划。

1.15 项目经理应该为这些问题负责吗?

项目经理应该为这些问题负责吗?

[姓 名] 赵卫峰 [单 位] 不公开 [邮 件] coffin@21cn.com


[所属行业] 综合应用 [所属主题] 项目综合管理 [发布时间] 2006-1-4

【案例正文】
陈伟明是公司的项目经理,在项目 A 筹备阶段就作为项目经理助理参与该项目,项

第 131 页 共 756 页
第 1 章 综合管理

目正式实施后被公司任命为项目经理。但使陈感到恼火的是:其他职能部门的经理
虽然为该项目安排了时间和人手,但他们更热衷于其他项目。同时陈还被告之不要
干涉部门经理对资源的调度和费用的预算。

半年之后,陈借向公司管理层汇报项目进度的机会想管理层说明了由于职能经理
不合作而造成的项目严重拖期情况,这次汇报引起了公司管理层的注意,他们投入
了更多的资源来使项目回到正常轨道上来,陈伟明不得不花费很多时间来准备文案、
报告和投影以及各种各样的会议。

公司管理层还为陈指定了一个项目经理助理,该助理认为应该通过计算机程序把
各种问题程序化,于是公司又投入了 12 个人来开发这个程序,在花费了巨额资金之
后,陈发现这个程序并不能实现其目标,他向一个软件供应商进行了咨询,得知若
要完成该程序,还需要多花费数倍的资金和两个月的时间,无奈之下,陈只好放弃
了该程序。

这个时候项目的情况已经很困难了,项目滞后了 9 个月,但还没有成型的单元完
成,客户对项目拖期问题非常关注,陈不得不花大量时间向客户解释存在的问题和
补救计划。

三个月之后,项目仍然没有大的进展,客户开始不耐烦了,尽管陈进行了大量的
解释和说明,但客户仍然不能接受严重拖期,于是指派了一个代表到项目现场监督
工作。客户代表要求找出问题并持续更新,继而试图参与进来解决问题,陈和客户
代表在一些问题上产生了激烈的冲突,导致两人关系恶化。

公司管理层最后撤换了陈伟明,项目 A 在超期一年之后,以预计费用的 140%最


终完成。陈伟明在项目 A 中遇到了很多项目经理都曾经遇到的困难,请你谈谈为什
么他被撤换下来,他应该为这些问题负责吗?

【相关分析】

·协调能力的缺失是根本原因(2008-01-06) [作 者] dajundalao [公 司] 暂时保密

该企业中,部门经理对资源有相当的控制权,项目经理实质是就是一个协调员,而从案例中看来,他
正好缺少协调方面的能力,这是小陈撤换的根本原因。
在这类企业当项目经理要有过硬的关系,或者他是一个在协调关系方面有突出才能的高手,否则,资
源调不动,权限没有还被“赶鸭子上架”,不被撤换才是奇迹呢!
小陈对内没有协调好与部门经理的关系,对外没有协调好与客户的关系,败几乎成了肯定,只是时间
问题。
第二个原因是,这个企业的体制是让部门经理职权大于项目经理,这让项目在执行中被动成为普遍现
象,这个企业应该负重要责任。

第 132 页 共 756 页
第 1 章 综合管理

第三个原因,陈对项目本身缺乏认识,对程序对项目的作用在没有充分论证的情况下任由其助理上马,
以至于走了一大段冤枉路,项目严重拖延,从而进一步引发客户危机。
第四个原因,小陈缺乏风险意识,他没有一套风险分析及应对策略,几乎是边走边看,这也为日后危
机的发生堤了隐患。
综上,小陈败是自然的。

·项目经理应该为这些问题负责(2008-01-03) [作 者] 叶利民 [公 司] 广东盛路通信科技股份有限公司

1、其他职能部门经理不配合他的工作,但他半年之后才向公司管理层汇报情况,浪费了太多时间。
2、项目助理的想法是否可行,未经过仔细的评估,既浪费钱又浪费了时间。

·项目经理应该为这些问题负责吗?(2007-08-30) [作 者] tjh [公 司] cxgs

良好的沟通协调能力是项目经理必须具备的一个素质,这个案例中的陈,明显没有充分的调动其他项
目相关的人力资源,首先是在决定项目参与人员的时候,没有充分考虑其他项目对该项目的影响,使
得项目小组成员在编不在岗,不能满足项目的开发进度。其次,在出现问题以后,首先应该考虑征的
公司的同意,重新确定项目小组成员或者与职能经理取得共识,争取他们的支撑,而不是听取助理的
建议。

·项目经理的态度与责任的处理关系 (2007-08-27) [作 者] 董新山 [公 司] 荣文灯饰(东莞)有限公司

作为项目经理对自己的做事思维出现错误,不要找客观原因,要对自己的项目整体进行控制,缺乏对
问题的风险管理能力!不知道怎样管理项目!在做项目过程中出现的问题不及时处理!导致项目失败!

·公司和项目经理都有责任(2007-04-28) [作 者] Ligf [公 司] excellence network

一、公司的责任
1、公司将一个人委任为项目经理,必须要为他提供相关的职位培训,使其能掌握相应的技巧。
2、需要向项目经理明确相关的项目要求,并从组织层面将项目的人员、职责确定好。
3、组织层面要有必要的制度规范对项目经理进行约束。

二、项目经理的责任
1、经验缺乏:没有制定详细进度计划、没有及时应对项目危机(项目经过半年后才向上级提出来)、
与客户争吵(激化矛盾)
2、做项目额外的工作,并花费大量的时间及精力,没有成本意识。

·职能经理与项目经理的关系学(2006-03-28) [作 者] 张俊 [公 司] 北京派得伟业信息技术有
限公司

良好的沟通协调能力是项目经理必须具备的一个素质,这个案例中的陈,明显没有充分的调动其他项

第 133 页 共 756 页
第 1 章 综合管理

目相关的人力资源,首先是在决定项目参与人员的时候,没有充分考虑其他项目对该项目的影响,使
得项目小组成员在编不在岗,不能满足项目的开发进度。其次,在出现问题以后,首先应该考虑征的
公司的同意,重新确定项目小组成员或者与职能经理取得共识,争取他们的支撑,而不是听取助理的
建议。

·该项目经理是有一定责任的(2006-03-24) [作 者] jacy [公 司] shanghai withub

我认为该项目经理是有一定责任的。
首先,当项目所需资源的获取在受到阻碍时,需要运用政治技巧或者较强硬的手段来解决。
第二,中间插入的一个管理程序的开发是本项目范围以外的内容,不应该放在必要完成的任务之列,
如果公司的公共部门可以解决这个任务则最好。
第三,该项目经理似乎没有对整个项目在前期做详尽的计划。
第四,该项目经理不应该与客户代表发生冲突,意见不一致时,应该尽量沟通。

·主要表现(2006-03-17) [作 者] 贺建林 [公 司] 海尔家居广州分公司

我同意主要的责任在项目经理。
项目经理在发现问题的同时未能通过适当方式及时解决问题.主要表现在于工作方法不当和管理经验
缺乏.对项目团队的驾御能力不够等.

·项目经理应负绝大部分责任(2006-03-17) [作 者] Henry [公 司] Cummins China

值得注意的是陈伟明在此项目进行中间角色进行过转换,由一开始的项目经理助理(筹备阶段)变为
项目经理(正式实施阶段)。但他事实上没有完成这个角色的转换,从整个过程来看,他只应该是一
名合适的项目经理助理。
1.他对项目正式实施前没有明确的计划(包括团队组建、实施计划、项目目标/范围、成本控制),
缺乏与项目干系人的共同沟通交流,导致初期公司高层/各部门经理没有形成统一的认识,明确目标;
在发现资源支持问题后,没有及时暴露该风险,导致项目在这种情况下运行了半年之久,好的开始等
于成功的一半,这样的开始导致项目比较被动。
2.缺乏对项目的整体把握/控制能力,在项目滞后的情况下,仍然花费巨大的人力/财力 /时间去做一
件不是必须解决的工作—项目问题程序化。本末倒置,超出了项目范围。没有及时将已经偏离正常运
行轨道的项目运转拉入正轨。
3.在项目滞后 1 年多,客户实施干预时,他仍旧花了大量的时间进行解释和说明,这是一种治标不治
本的做法,纸里包不住火,必然使得矛盾激化。从此案例未看出,项目经理与客户建立沟通交流体系。

·项目经理和公司都有责任(2006-03-16) [作 者] stormzz [公 司] lenovo

第 134 页 共 756 页
第 1 章 综合管理

1。项目经理发现问题未能及时汇报高层,是没有机会还是高层没有看到问题的严重性?直到风险变
成现实才引起重视。
2。助理:通过制造 BUG 解决 BUG,应该枪毙,项目经理没有抓住项目延期的核心问题,同意这么做
也是有责任的;
3。关于客户沟通,我不敢妄加评论,做为项目经理应该与客户保持良好的沟通,但项目经理也是人,
压力也很大,而且现在什么样的客户都有;
4。撤换项目经理可能是公司对客户的交代,但更换项目经理也可能会造成项目延期。

我觉得还是公司对项目经理的工作没有一个明确的态度。在这种前提下项目经理的工作是艰难的。

·项目经理应该对项目全权负责(2006-03-14) [作 者] guoweizhu [公 司] Magneti Marelli


Automotive Components

作为项目经理,应该对项目全权负责。

1。总的来说,陈在项目的风险管理和成本管理上做的不够。作为项目经理在做一新项目启动阶段要
做好三件事:项目建议书(技术可行性分析),项目投资申请报告(经济可行性分析),项目计划。
显然陈在项目之初,这三方面做的不够,或者说其公司的项目管理体制/程序不完善。
2。一开始就应该做好项目计划,并不断更新,而且每周进行项目例会跟踪项目进度,在项目的每个
关键时间接点(Milestone)做项目评审(有 Top Management 参与),从 Q(质量)C(成本)D(进
度)三个方面进行审核。这样其他职能部门经理也好对部门员工做好统筹安排,如果职能部门经理不
配合,在评审会议上就及时提出,不至于影响项目进度。
3。成本管理对于项目管理来说很重要,因为作为老板或客户关心的就是利润。在项目投资申请报告
得到管理层批准后,在项目实施时,不断对每个阶段成本进行记录跟踪,额外投资或成本超标至一定
程度必须要进行充分的分析,严格的审核。这样就不会出现助理花巨额资金开发程序又未成。
4。从某种角度来看,项目经理也是客户代表,显然陈在一开始就忽略了客户的利益。另外,项目经
理在对客户谈判时,又代表的是公司,与客户关系恶化当然不应该。

以上是我个人从事三年项目管理以来的一点拙见,说起来简单,实施的时候肯定有很多阻力。

·拙见(2006-03-13) [作 者] 郭彩云 [公 司] 三门核电

项目经理和公司都有责任:其一:作为项目经理,对于自己的职责不够明确,无法胜任一个作为领导
者的角色,在出现问题时没有摆正位置,在不明确目的的情况下做出错误的决策,使得公司付出惨重
的代价,作为公司方面,没有使各部门协调工作,使各项工作顺利开展,出现问题之后也没有人能够
冷静思考,做可行性报告,故而使错误越来越严重!

·各打 50 大板(2006-03-10) [作 者] 魏科丰 [公 司] 长江大学

第 135 页 共 756 页
第 1 章 综合管理

项目经理和公司都有责任。

·应该负责(2006-03-09) [作 者] 杨振 [公 司] 武汉科技大学

项目经理负有责任
1<但使陈感到恼火的是:其他职能部门的经理虽然为该项目安排了时间和人手,但他们更热衷于其他
项目>项目经理应发挥与其他部门沟通的能力,争取到更多的支持。
2<半年之后> 出现问题应及时向领导反映
3<说明了由于职能经理不合作而造成的项目严重拖期情况>推卸责任,使之与其他部门关系恶化
4<项目滞后了 9 个月,但还没有成型的单元完成>工作效率低下
5<陈和客户代表在一些问题上产生了激烈的冲突 >顾客是上帝,自己解决问题能力不足

·负责(2006-03-04) [作 者] 福甜 [公 司] 交通银行桂林分行

我认为他负有一定的责任:
1/在发现“其他职能部门的经理虽然为该项目安排了时间和人手,但他们更热衷于其他项目。同时陈
还被告之不要干涉部门经理对资源的调度和费用的预算”时没有及时向领导汇报,而是在半年之后才
汇报,这需要他负领导责任。
2/在花费了大量的资金去开发一个程序有没成效,最终又忍痛割爱,说明他连基本的可行性研究都没
做过,而是片面的相信了他的助理,这说明他理论和时间都不足,可见他出任这“项目经理”有花名
之嫌。
3/他在整个的项目实施都没做过风险计划,时间计划,成本计划

·责任很明确(2006-03-03) [作 者] wxh [公 司] qerw

完全是项目经理的责任.
1. 项目成员本来就来自不同的部门,必然受职能部门经理的领导.项目经理事先没有同相关部门沟通
好.
2. 如果遇到不配合的问题,要及时向职能部经理的上级汇报.争取他们的支持.
3. 工期延时,还要去搞什么计算机程序,这相当于又启动了一个项目.对项目的控制没有一点概念.

·怎么做好项目经理?(2006-02-28) [作 者] liliehua [公 司] INOAC HUAXIANG

1.<陈还被告之不要干涉部门经理对资源的调度和费用的预算>--说明了什么?陈的任命形同虚设!他
并没有因此而获得足够的权限(项目章程问题),恼火有什么用?及时得到 POWER 才是真的;
2.<半年之后>--太久了!同意其它人的分析;
3.<助理增加程序>--严重地改变了 WBS!项目不拖延才怪.不经过时间、成本等问题的分析的么?

第 136 页 共 756 页
第 1 章 综合管理

4.<项目滞后了 9 个月时的解释工作>--解释是必要的,但应急计划的有效性太差了;
5.<陈和客户代表在一些问题上产生了激烈的冲突>--项目经理的 85%以上的时间用才沟通上的,不是
为了吵架。尤其重要的是要解决问题!
所以,该公司本身应该就不具备进行该项目的资本(历史信息、以往的教训......都没看到有想到去
采用);陈伟明作为该项目经理还勉为其难!

·跨部门沟通(2006-02-16) [作 者] tao weijia [公 司] Channelon

问题的隐患在于项目经理没有跨部门协作的经验. 就算是这个项目受到上层的关注也避免不了其他
部门不于足够支持的情况.
前面的一位已经说的很好了, 项目一开始就要和需要协调的部门领导和上层领导一起沟通明确,协
作部门必须按照项目进度提供支持.
发生了问题没有采取好的解决方案. 当项目经理发现协作部门没有给予支持的时候不能直接捅到上
层说其他部门没做好工作.结果就是心不甘情不愿,老总问起了就盯一下,没人盯就马虎,甚至故意
拖你后腿. 协调能力的重要这时候改是发挥的地方了.
事情发展到这一步就无可挽回了.只有换人.

·项目经理应该为这些问题负责吗?(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

项目经理失职.
主要是他没有与下属进行很好的沟通.

·从公司、客户和职能部门的角度来分析(2006-02-05) [作 者] 王勇 [公 司] 远达网络

这个项目经理应该承担责任。
现我从公司管理层,客户,职能部门的角度来分析此问题。

首先,从公司管理层的角度来看此问题。
陈伟明是公司的项目经理,在项目 A 筹备阶段就作为项目经理助理参与该项目,项目正式实施后被公
司任命为项目经理。以及后面的公司指定项目助理;投入 12 人来开发程序解决问题;等等细节可以
看出公司对陈伟明比较重视,也可以说是培养他。
可惜的是他没有抓住机会并出现了一下问题:
a.沟通协调不强,在项目中遇到了资源问题不能自行解决。(但使陈感到恼火的是:其他职能部门的
经理虽然为该项目安排了时间和人手,但他们更热衷于其他项目。同时陈还被告之不要干涉部门经理
对资源的调度和费用的预算。)[/i]

b.判断不果断,居然发现了问题,拖上半年才汇报。[i]半年之后,陈借向公司管理层汇报项目进度

第 137 页 共 756 页
第 1 章 综合管理

的机会想管理层说明了由于职能经理不合作而造成的项目严重拖期情况

c.决策不够谨慎。尽管有通过创新解决问题的愿望,但是在具体执行的时候,选择了错误的时间,和
错误的方式。

d.不能勇于承担责任。出现问题的时候责怪职能部门,埋怨项目助理以及客户。

e.在和客户争执是不能妥善处理,使得矛盾更加激化。导致客户意见很大并投诉
综上所述,陈伟明不适合该项目经理的职位,建议换人。

其次,从客户的角度来分析问题。
1.该单位不能够满足我方的项目进度要求,该项目经理的能力是否有问题?
2.在该项目不能按照计划完成时,我方派人督促,该项目经理不尊重我方代表建议,是否沟通能力不
行。

考虑到上面两点,为了保证我方的利益不受到进一步的损失以及项目完成,我方应该尽快向施工方提
出更换项目经理的要求。

最后,从职能部门角度来分析问题。
1.我们手上一大堆项目要做,要安排人员和时间。这些项目那些重要那些不重要,从领导的态度里面
就可以看出来。
陈伟明没有办法让领导重视这个项目,光和我们嚷嚷要安排了时间和人手。不忙的时候可以满足他,
如果遇到项目优先级冲突的时候,那只有丢卒保车了。
2.陈伟明用公司高层压人。项目急,陈伟明不早点说,现在却通过领导压人。以后还怎么合作。

上面是我从公司、客户和职能部们这三个角度对楼主提出的问题作出的分析。不知道楼主是否认同。

·是项目经理的负责(2006-02-05) [作 者] Bob [公 司] siecom

失败原因有以下几点:
1.没有清楚地分派各项目成员的工作进度.
2.对项目进度控制力度不够.
3.沟通能力大差.
4.身为项目经理,在导入新的管理体系时,不务实导至最终失败.
5.身为项目经理,与客人沟通代表的是公司并不是个人,大情绪化导至与客人关系紧张.
最终建议该公司的老板炒掉他,或是降职处理.

·发现问题就要及时的解决(2006-02-01) [作 者] 姜世伟 [公 司] 站物

第 138 页 共 756 页
第 1 章 综合管理

在本案例中项目经理的败笔有三:
第一:缺乏有效的沟通,没有发挥项目资源的最大效用。
作为一个项目经理,首先要明确你这个项目所拥有的资源,并努力发挥资源的最大效用。在本案例中项
目经理由于没能与职能部门 的经理进行很好的沟通而导致人力资源的效用没能完全的发挥。
第二:盲目的引进新的管理工具,没有做好可行性分析。
当公司派来的助理经理说需要开发一个程序时,陈立即就同意了,当发现问题时,才向软件供应商咨
询,而此时大量的时间和资源成本都已经形成了。
第三:缺乏与客户合作的能力,不能刚柔相济。
在项目出现了诸多问题时,客户派来代表参与项目,陈却与代表发生了激烈的冲突,导致了两人关系
恶化。其结果只能是公司对项目组更加的不信任。

·沟通出现问题(2006-01-22) [作 者] 许春飞 [公 司] 上海宝山钢铁股份有限公司宝山分公司

个人觉得项目出现问题在于沟通问题:
1、没有及时向上级管理者汇报项目的问题,并获得上机管理者的支持;
2、没有增强团队的凝聚力,内部不团结。
3、项目经理的经验没有达到管理这个项目的程度。
4、项目管理团队在新增项目上没有进行充分的变更管理;
5、没有和客户保持紧密的联系,没有发挥客户的积极作用;
6、项目经理缺乏扭转乾坤的能力。
我觉得项目经理应该为项目失败负责,他没有正确的完成项目的有效计划、跟踪、控制及外围沟通;
在需求变更方面做的太差。

·沟通存在问题.(2006-01-21) [作 者] 叶雨 [公 司] x

平级沟通,向上沟通都存在问题.
向公司半年才反馈该情况的存在(当然,这个公司的高层也有问题,至少是内部管理制度还不够成
熟).从另外一方面,也能推断出该项目计划考虑不充分,监控也不到位.

在项目中途,随意增加一个开发而未果.变更控制/风险控制不够严格.

·项目经理通过以上方法可减少不必要的麻烦!!而将更多的时间投入到项目本身!!
(2006-01-17) [作 者] 尘埃落定 [公 司] 无

“给项目经理减压:接到项目以后,召开各部门会议!
拟订计划:一致通过各部门分工及进度控制,定期对照检讨
权责分明!!!!!————————个人认为:项目经理通过以上方法可减少不必要的麻烦!!而
将更多的时间投入到项目本身!!

第 139 页 共 756 页
第 1 章 综合管理

项目详尽的执行方案
详尽的实施计划
一致认定的目标
定期对照检讨
并穿插于各部门之间了解并确保项目计划的按期完工(避免能说不能做)

这对沟通协调能力以及丰富的实作经验都有很高的要求!!

·guandian(2006-01-15) [作 者] 李冯 [公 司] BJG

"在此项目中,在项目质量、费用控制、时间进度上,陈经理与公司都负有一定的责任:
1、首先,项目的目标并没有得到项目各执行部门的一致关注。
主要原因是公司对该项目的重视程度不足,不然不会有“不要干涉部门经理对资源的调度和费用的预
算。”陈经理的个人负有项目进度执行与总结的职责,但没有实现这一职能;缺乏有效的沟通手段,
严重影响项目的进度。
2、没有经过分析与评审的扩充资金是项目执行中的一种严重浪费。
无论是任何一种项目,在论证初期都应该进行详细的调研与方案的确定,包括各项资源与管理、监控
手段。如果匆忙上马,都将会导致项目质量、费用、时间等方面的严重浪费。
3、项目进度的严重拖期、与客户间不能良好的沟通并解决对以后业务的发展、公司的信誉都产生严
重的影响。
项目拖期 9 个月后,客户已经产生了不满并严重关注进程,甚至派人到现场监督;陈经理与客户代表
的争吵致使矛盾升级,这对于一个项目经理而言都是严重的过失,结果将会是该公司永久失去这个客
户。

在项目延期 1 年的过程中,我们可以回顾所有环节所产生的问题:项目执行方案不明确、项目目标没
有得到公司的重视,资源调配权没有交给项目经理,公司对项目进程缺乏有效的监控手段,项目的执
行过程扩大了资金费用,与客户的沟通存在严重的问题......
应该说:陈经理在这个项目中应该承担项目管理责任、费用超支责任、项目拖期责任甚至说还可能存
在的项目质量责任,应该被撤换;公司承担项目调研不充分、没有统一项目目标、项目缺少监控、盲
目扩充资金、没有及时调整项目管理人员的责任。"

我同意您的观点

·其他观点(2006-01-15) [作 者] 李冯 [公 司] BJG

“给项目经理减压:接到项目以后,召开各部门会议!

第 140 页 共 756 页
第 1 章 综合管理

拟订计划:一致通过各部门分工及进度控制,定期对照检讨
权责分明!!!!!

只要结果,不要过程,又何来干涉呢!!!!!!!!!!!!!!!!!!!!!”

我认为,当一个管理工作能够用上述如此简单的处理方式处理的话,我们的管理工作不必需要太高明
的管理着了;也许找一些小学生就够了

·分析(2006-01-15) [作 者] 李石求 [公 司] 北京齿轮总厂

1:没有充分利用高层的支持
2:没有一个详细的项目计划和控制方案
3:评审不够,没有备用方案

·客户导向,召开会议,拟订计划,只要结果,不要过程!(2006-01-13) [作 者] 尘埃落定 [公
司] 无

总公司确定客户导向的经营策略!

给项目经理减压:接到项目以后,召开各部门会议!
拟订计划:一致通过各部门分工及进度控制,定期对照检讨
权责分明!!!!!

只要结果,不要过程,又何来干涉呢!!!!!!!!!!!!!!!!!!!!!

·到底什么是项目管理(2006-01-12) [作 者] lingjie [公 司] 杭州信雅达系统工程股份有限


公司

对于项目经理是否有项目管理的经验这一点来说,每个公司都会存在把没有项目管理经验的技术人员
拉到项目经理的位置。这是客观存在的问题,因为对于公司来说不可能在每个项目中都配备一个项目
管理高手。对于被提为项目经理的技术人员这其实是一个很好的锻炼机会。但是做好项目管理并不是
管着下面的人做就可以的。
在这个案例中,陈并不具备项目管理的能力,并不是说他没有管理过项目就没有这样的能力,只是在
整个项目中他的表现体现出来的:
1、其他职能部门的经理虽然为该项目安排了时间和人手,但他们更热衷于其他项目。同时陈还被告
之不要干涉部门经理对资源的调度和费用的预算。在这样的情况下,陈应该学会沟通,对于项目经理
来说的确不能去干涉其他部门的资源调度,但是项目经理要做到的并不是去干涉,而是去协调。使其
他部门的资源更好的为自己的项目组所用。
2、在出现上面问题的情况下,陈没有及时的向上层领导反映,半年一次的汇报对于一个项目来说时

第 141 页 共 756 页
第 1 章 综合管理

间间隔过于长了,项目经理应该让上层领导时刻了解项目的进展情况,对于项目情况的汇报应每周提
交相关的项目状态报告。有的公司会配备高级经理监管项目,那项目经理就应该每周提交项目状态给
高级经理,如果说项目经理的汇报途径是公司领导,那么就应该提交给公司领导,这样才能让领导详
细的了解这个项目的情况。
3、陈这个项目经理太依赖与助理,公司配备的助理是协助项目经理管理项目的,他提出的意见项目
经理应该有选择的接纳,怎么能在没有风险、成本等预估的情况下就采用了助理的意见呢?这就是项
目经理的失职。项目经理在项目过程中需要对项目有全面的管理,全面的计划中要涉及项目管理的 9
大方面的规划。虽然文中没有提到该项目经理是否有制订计划,但综观全文,个人觉得该项目经理就
算有制订计划,也不是全面的计划。
4、在沟通方面陈是做的最糟糕的,在这个环节是最失败的。沟通也是一种学问,要是连起码的沟通
都无法做到,动不动就与其他部门或则是客户代表发生冲突,那这个人就不是一个好的项目经理。
撤换陈是正确的做法。陈应该自己反省一下。
对于公司的管理层来说,也存在了对项目关注不够的问题,但是对于项目经理来说不能过多的要求公
司领导主动的来关注你的仙姑,而是要你自己主动的去让领导关注。

·项目经理的责任(2006-01-06) [作 者] 孤独剑 [公 司] 中电科长江数据

作为一名项目经理应该对自己可利用的资源,包括会受到那些人的支持和阻碍.
陈所范错误:
一、不善于沟通。从陈被告之不要干涉部门经理对资源的调度和费用的预算和和客户代表在一些问题
上产生了激烈的冲突,导致两人关系恶化两件事上可见一斑。
二、没有威信,缺乏组织领导能力。为什么分配给陈的人手不愿做陈的项目,说明他没有威信,缺乏
组织领导能力。
三、没有项目管理意识。作为一名项目经理在做项目之前肯定要对项目进行统一规划,以便控制项目
的进度。虽然文中没有谈到陈有无做计划,但从当助理推荐开发计算程序把问题程序化时,陈等到程
序无法进行下去才去向有关公司咨询就说明他做事没有详细的计划。如果他是在开发程序之前就已经
做了咨询肯定就不会对程序进行开发,也就节约了资金。

·项目经理责任大(2006-01-06) [作 者] 王琪 [公 司] 北京农科院

一、没有充分利用高层的支持
二、没有详细的计划
三、解决问题比较拖延,盲目

·项目经理就是不要让问题留在自己手里(2006-01-06) [作 者] 牛小林 [公 司] 有空就来

同意大家的分析,其实,我认为项目经理的一个基本素质,可以从另外一个角度来分析,那就是尽量
做到:即使是项目出现了很大的问题,但是跟你个人无关,要做到这一点,需要:

第 142 页 共 756 页
第 1 章 综合管理

1。充分的沟通,让所有干系人都明白项目的重要性,项目拖延的严重后果。
2。明确项目组成员在项目组内部的职责和使命。
3。在充分沟通的前提下,制定切实可行的项目计划,必须要落实到人,到时间,一定要制定明确的
阶段性可提交成果的标准以及评审标准。
4。通过充分沟通,建立有效的项目汇报及沟通制度,定期向公司高层递送项目存在的问题和解决情
况,以及需要公司层面帮助解决的问题,以及各个问题不能及时解决的后果。
5。根据项目的周期和特性,制定项目跟踪和监控的时间粒度,对项目进行有效的监控,当项目进度
发生偏差时,在可控的范围内及时将你认为不可控制的风险,汇报给高层,并敦促高层解决问题。

如果你做到了以上几点,我想即使项目有问题,也不是你的问题了,换言之,如果项目出现的问题,
都是你提前预警了,并且提出了解决办法,但是即使上升到总经理那里也没有办法,你是不会承担任
何责任的,但是,如果出现的问题,你没有及时通知高层,或者没有及时采取必要的措施,那一定是
你的责任。

·浅析两点:个人与公司(2006-01-05) [作 者] 杨文卿 [公 司] 青岛海信光电科技

在此项目中,在项目质量、费用控制、时间进度上,陈经理与公司都负有一定的责任:
1、首先,项目的目标并没有得到项目各执行部门的一致关注。
主要原因是公司对该项目的重视程度不足,不然不会有“不要干涉部门经理对资源的调度和费用的预
算。”陈经理的个人负有项目进度执行与总结的职责,但没有实现这一职能;缺乏有效的沟通手段,
严重影响项目的进度。
2、没有经过分析与评审的扩充资金是项目执行中的一种严重浪费。
无论是任何一种项目,在论证初期都应该进行详细的调研与方案的确定,包括各项资源与管理、监控
手段。如果匆忙上马,都将会导致项目质量、费用、时间等方面的严重浪费。
3、项目进度的严重拖期、与客户间不能良好的沟通并解决对以后业务的发展、公司的信誉都产生严
重的影响。
项目拖期 9 个月后,客户已经产生了不满并严重关注进程,甚至派人到现场监督;陈经理与客户代表
的争吵致使矛盾升级,这对于一个项目经理而言都是严重的过失,结果将会是该公司永久失去这个客
户。

在项目延期 1 年的过程中,我们可以回顾所有环节所产生的问题:项目执行方案不明确、项目目标没
有得到公司的重视,资源调配权没有交给项目经理,公司对项目进程缺乏有效的监控手段,项目的执
行过程扩大了资金费用,与客户的沟通存在严重的问题......
应该说:陈经理在这个项目中应该承担项目管理责任、费用超支责任、项目拖期责任甚至说还可能存
在的项目质量责任,应该被撤换;公司承担项目调研不充分、没有统一项目目标、项目缺少监控、盲
目扩充资金、没有及时调整项目管理人员的责任。

仅是个人的观点。

第 143 页 共 756 页
第 1 章 综合管理

·公司就没有问题?(2006-01-05) [作 者] 涂金格 [公 司] 长飞公司

就公司这方面说说我的看法:
公司任命陈为项目经理是问题一,因为陈没有做项目经理的经验和通常的项目管理的知识;公司没有
运作项目的合理的规章制度是问题二,没有制度保障项目经理来调度资源肯定带来项目运作的困难;
当然,在这样一个公司的环境下,作为项目经理,更应该积极主动地寻求领导层的支持。

·一个错误(2006-01-04) [作 者] 天羽 [公 司] 林源教育咨询

任命他就是一个错误的开始(恕我直言)

从文章内容来看,他除了写好报告,就没有别的本事了。一个最开始自己就发现的问题,半年后才让
管理层注视起来,说明作为项目经理的他已经开始走向失败了。他没有承担起“直言敢谏”的责任。
之后,他又听从于助理的创意,盲从于依靠工具来解救已经下滑的项目,这是又一个乱决策的责任应
该由他来承担。
最后,不检讨自己的责任和失误,和客户代表激烈对抗,已经失去了原谅的机会。

这样的人,以后就不要让他在公司里混下去了。

·除了陈,还有谁应该负责任(2006-01-04) [作 者] 贺晓宁 [公 司] 中科院软件所

问题:
1,项目计划制定不完备,资源计划等于 0
2,计划变更,不进行详细的分析,带来项目无法控制
3,沟通不善,引起项目相干人员矛盾
不过这个项目经理也有处理正确的时候,虽然都是补救措施,但是有补救就可以了

·项目经理的责任(2006-01-04) [作 者] 王海飞 [公 司] utstarcom通讯有限公司

1、但使陈感到恼火的是:其他职能部门的经理虽然为该项目安排了时间和人手,但他们更热衷于其
他项目。同时陈还被告之不要干涉部门经理对资源的调度和费用的预算。
此项目得不到重视, 缺乏沟通——项目得不到重视是公司的问题,但是缺乏沟通、不向上层及时反
映情况,而是默默承受,这就是项目经理的问题了。一个典型的在沉默中灭亡的例子;
2、半年之后,陈借向公司管理层汇报项目进度的机会想管理层说明了由于职能经理不合作而造成的
项目严重拖期情况。
延误时机;既然发现了问题还不及时解决,半年之后?时间太长。同时也可以想象在这半年时间里,
项目经理工作做得是怎么样了?
3、又投入了 12 个人来开发这个程序,在花费了巨额资金之后,陈发现这个程序并不能实现其目标,

第 144 页 共 756 页
第 1 章 综合管理

他向一个软件供应商进行
了咨询,得知若要完成该程序,还需要多花费数倍的资金和两个月的时间。
目标不明确是主要原因,事先计划作的肯定很烂
4、三个月之后,项目仍然没有大的进展
补救计划作的很烂,而且缺乏监控,出现了恶果后才发现问题,说明了其项目监控做的之差
此项目的责任如果不归于项目经理,天理难容!!!

·同意(2006-01-04) [作 者] 秦轶 [公 司] 中国网通集团研究院

从案例的描述信息来看,我同意主要的责任在项目经理。
从某种意义上说,项目经理一旦接受了项目,就得承担项目的后果。
在这个案例,虽然存在一些问题,如职能部门的阻力,但这些都是常规性问题。
因此,我认为是项目经理缺乏沟通能力,表现在:
(1)不能与职能部门有效沟通
(2)未充分分析项目的组织环境,未能有效利用高层的支持
(3)将沟通寄托在程序系统上,而不是人

·项目经理的失败(2006-01-04) [作 者] tyminlau [公 司] TCL

总的来说,项目经理应该为上述问题负责.陈伟明的失败主要有以下的问题:
1.项目进行初期未制定严格的项目计划,造成项目在运作的过程中更改较多,比较随意,对项目运行中
的困难估计不足.
2.该公司的整个运营链不流畅,有十分严重的部门墙存在.而其作为项目经理,和各职能部门的协调沟
通不够,造成公司资源(人力,资金等)的严重浪费.
3.对整个项目的风险防范估计不足,缺乏必要的可行性研究.

1.16 如何取得团队的信任和支持!

如何取得团队的信任和支持!

[姓 名] 金爱平 [单 位] 不公开 [邮 件] aipingjin@hotmail.com


[所属行业] 综合应用 [所属主题] 项目综合管理 [发布时间] 2005-10-24

【案例正文】

第 145 页 共 756 页
第 1 章 综合管理

目前,由于刚接手新的部门,而且本人的工作阅历也很浅,对于接手部门的业务不
了解也不清楚,我也明白一个部门主管是不是一定要非常熟悉业务,否则他就是一
个不称职的,但是在短期内因为时间关系让我无法适应,那在这段时间内如何让我
的部属听从我的安排?怎么理顺团队成员的关系?

·外行管理内行(2006-01-04) [作 者] xiaoyue [公 司] E

郎咸平先生曾提出一个观念:要外行管理内行。
在某些方面,我认为他这个观点很有道理:他举了个例子,下属的专业人员写了一份报告,全篇
的专业用语,极少人能看懂,上司看后要求重写,上司说自己看不懂,并且如果你不能让看这篇
报告人明白你在说什么,那这篇报告如何让别人明白你做了些什么,有什么意义?
上司既然做了管理者岗位,那么他就不能专注于具体的技术问题。他的主要职责是整合资源,而
下属才是具体操作的人。而且越是高层的领导,管理的领域越多,不可能要求他在自己分管的领
域都是行家,除非他是神。比如说一位技术部门的领导,管理着机械、电子、生物等等各个分部
门,他本身是电子方面的行家,但是因为他管了这个部门,难道他就必须也是机械及生物方面的
行家吗?
个人看法,一起讨论。文字

·我没有经验,有点建议(2005-12-23) [作 者] duanlj [公 司] 不透露

先不要发号施令,或者搞什么新官上任三把火之类

先观察一下部门内的每个人,了解他们以前的工作,甚至私事

·交流沟通就是管理者最主要做的事情。(2005-12-07) [作 者] 潘谦 [公 司] NEC中科院上海软件开发
中心

首先还是了解和沟通是第一的。

第一 在不熟悉环境的情况下,首先你可以和你的团队每个人谈一遍,了解一下每个人的水平,
期望,能力。

第二 对于目前团队的实际情况不同采取不同的对策。
成熟部门:
如果部门目前都是成熟的项目比较稳定,不用急着改变什么,
而是寻找优化和改进点,逐步改进。
管理中也完全可以采用民主的作风,让部门的员工尽可能表
现出自己。

完全不成熟部门:
可能部门都是新人,需要你立刻确立部门的目标/制度和人员调整,

第 146 页 共 756 页
第 1 章 综合管理

部门经理做的事情最主要的就是合理运用人力资源和培养人才,来
达到部门的实际目标。
对于新人较多的状况,一般来说很多事情要你去教育指导和命令。
要提拔出自己能够信任的骨干,要求最好严格并制度化,在一开始
的严格要求可以让新人形成良好的习惯,才能以后让你轻松下来。

第三 部门长远的发展
一个部门的长远发展都要有部门的长期目标,要有长期目标的分解
目标,就是每个阶段部门要达到什么样的水平。
对于部门的每个员工也要关心了解,帮助他们制定自己的职业规划
和培养计划。也就是每位员工的成长计划。
建立起有效的绩效制度,定期让员工了解目前部门的发展情况和他
上级对他每个阶段的评价,帮助员工不断成长。

·快速进入角色,正确定位自己的职责(2005-11-23) [作 者] 拉尔夫 [公 司] 互联科技

公司任用您做部门管理者,肯定有您个人的魅力所在,所以您的工作阅历浅不是您管理好部门的
真正障碍。对新部门业务不熟悉也不是你的真正障碍。
您心理存在一个问题:手下听您的话——这个定位非常错误。要知道部门领导的职责是管理,和
部门其他人员都有自己的职责一样,缺一不可。您和部门职员是合作关系,合作共同完成部门的
事务,只不过所在的岗位不同而已。而不是谁听谁的问题。您部门下很多岗位的工作你都是无法
胜任的,因为他们是这些岗位的专家,你不是,也不要是。

您必须这样做:快速熟悉部门业务,快速熟悉部门管理的职责,然后按照合理的管理规则做好您
的管理的事。倾听您手下员工的建议,做好沟通,和安排,要多和属下沟通,要发扬民主作风,
不要做独裁者,不要做发号施令者。

在您开始不熟悉部门业务的时候,不听话的职员是促使您快速熟悉部门业务的因子,是好事。

让员工听话,您就要练好自己的管理水平,不要瞎指挥,如果自己的能力的确有限,本来就
无法胜任工作,那么请您立即充电,并且可以考虑请手下有经验的员工或者其他朋友(同事)做
好参谋。

让员工听话,需要您管理的专业水平和人格魅力来征服得手下职员听话,这样才是正确的定
位。

·提出自己的想法(2005-11-23) [作 者] 常川 [公 司] 西安电子科技大学

如果希望属下听从自己的安排,那么首先自己要拿出一个能让属下执行的安排,在这里,你说你
对这个行业不是很了解,那么就抓住主要问题,在向你的属下展示你做人的魅力的同时,通过沟
通等方式尽快了解这项业务,然后提出自己的独到的见解,发挥作为一个 Leader 的说服力,领导

第 147 页 共 756 页
第 1 章 综合管理

团队!一旦能够领导起这个团队,就已经成功了一半了!

·突出个人优点(2005-11-20) [作 者] 王生 [公 司] 广州智能化有限公司

既然被任命为项目经理,自然有独到之处,把你个人的独到之处显现出来,同时也要给予同事足
够的信任和支持!!!

·扬长避短(2005-11-14) [作 者] monk [公 司] 华润涂料

要真诚的谦虚,要扬长避短.对下属来说你要对他们有帮助,他们自然会配合你的工作.

·相信自已、相信同事(2005-11-11) [作 者] Lemme Wang [公 司] 不提供

对于接受一个新团队,或者刚被提拔为团队 Leader,我认为需要注意以下几个方面
1 . 必须相信自已一定能
2 . 必须相信你的同事,也相信他们能
3 . 与同事多沟通,谈出你的沟通模式以及沟通中的注意事
项, 特别是要提到求同存异的观点以及被拒绝时的心理
活动,要坦然接受被拒绝,相互尊重、包容
4 . 经常灌输职业化、敬业精神
5 . 强调团队内各同事必须紧密合作,随时 Open Door、
Online 接受别的同事请求
6 . 当你建立了团队的文化后,你就可以逐步推出你的管理制
度,诸如命令的执行力、工作汇报、任务跟进、任务验收、
任务完成评估等
7 . 最后,当你在带领团队遇到阻力时,如果不能通过其它方法
解决,则请寻求上司的帮助,如果上司支持你,则可以将你
认为不合作之同事 Kill 掉,不要手软,生活就这样。

·相信自已、相信同事(2005-11-11) [作 者] Lemme Wang [公 司] 不提供

对于接受一个新团队,或者刚被提拔为团队 Leader,我认为需要注意以下几个方面
1 . 必须相信自已一定能
2 . 必须相信你的同事,也相信他们能
3 . 与同事多沟通,谈出你的沟通模式以及沟通中的注意事
项, 特别是要提到求同存异的观点以及被拒绝时的心理
活动,要坦然接受被拒绝,相互尊重、包容

第 148 页 共 756 页
第 1 章 综合管理

4 . 经常灌输职业化、敬业精神
5 . 强调团队内各同事必须紧密合作,随时 Open Door、
Online 接受别的同事请求
6 . 当你建立了团队的文化后,你就可以逐步推出你的管理制
度,诸如命令的执行力、工作汇报、任务跟进、任务验收、
任务完成评估等

·真诚待人(2005-11-02) [作 者] 深黑色 [公 司] 上海

做项目经理和做人一样,首先要真诚待人,尊重别人,这些是个人魅力的关键。同时要讲究做事
原则和方法。

·老生常谈,却常是问题关键所在(2005-10-28) [作 者] 孙先平 [公 司] UT China

这个问题,讨论过多次了,确切的说,没有一个准确的方法或技巧可以解决。所谓因时和因地制宜,
别说是获得团队的支持和信任,获得一个人的信任和支持也是同样的道理。大概与以下几个方面
有关:
1、组织风格
2、个人魅力
3、团队组成或性质
4、工作性质
5、个人业务能力
6、项目性质或难度
7、沟通深度与广度
……

·分析环境,采取对策(2005-10-27) [作 者] fangrobert [公 司] superred

我认为这个问题与你企业的环境有关系:
1、如果你的企业文化是关系型的,就是大家比较注重彼此之间的关系,我跟谁关系好,就愿意配
合谁的工作。我认为你可以去跟你的部门同事搞好关系,聚会、大量个人之间的沟通都可以
2、如果你的企业文化是工作型的,就是员工都是以工作为重心,任务第一,大家之间的关系比较
淡薄,这样管理相对比较好做,做好规划,分配任务,进行考核,辅以一定的行政方法,应该是
有帮助的
不管是哪种方法,首先自己得融入这个环境中,方能更好的去执行。
个人实际工作中碰到的,仅供参考。

·如何取得团队的信任和支持!(2005-10-26) [作 者] 徐云波 [公 司] 上海GQY视讯股份有

第 149 页 共 756 页
第 1 章 综合管理

限公司

1. 首先要快速进入新角色. 首先要了解部门的现状,以及部门正在开展的工作,以及部门人员的
状况.
2. 沟通。要多与上级沟通,了解上级领导你对的期望,同时上级也要注意维护和树立你在新部门的
威信. 另外,你还要和部门人员进行沟通,了解他们的想法和心声, 及时协调和解决他们所关心的
问题。
3. 做事的基础还是做人.做人要光明磊落,不要授予部属话柄.
4. 培养个人魅力,才能获得团队信任和支持.

·新部门领导(2005-10-25) [作 者] 袁月建 [公 司] 北京富士通有限公司

作为一个新的部门领导.
你首先要做的是:沟通.因为你对业务不熟悉.那么在你沟通的过程中,其实也是你对业务熟悉的过
程.这样你才很快的去熟悉和了解你部门的目前状况.
然后根据你的了解,进行判断,制定出一份简要的计划.然后大家再讨论.一步一步深入.这样,你的
计划及符合大家的意愿.同时你也掌握了大致的进展.

·再贴一次(2005-10-24) [作 者] 天羽 [公 司] 林源教育咨询

这个案例已经讨论过很多次了。

1.17 如何调动开发人员主观能动性?

如何调动开发人员主观能动性?

[姓 名] 陈晨 [单 位] 电脑公司 [邮 件] seesunny@126.com
[所属行业] 综合应用 [所属主题] 项目综合管理 [发布时间] 2005-10-12

【案例正文】
我公司是做系统集成的公司,有 10 多个软件开发人员,待遇在本市同行业中是比较
不错的,略低于其他大城市。我们的主打产品是针对电力部门的产品,产品开发历
时两年多,分模块开发的每个人负责一部分,最终由项目经理整合。后来项目主要

第 150 页 共 756 页
第 1 章 综合管理

负责人离职。项目基本完成,实际应用中系统中存在很多的不稳定因素。

主要几个开发人员来往救火。现在开发人员都没有了开发初期的干劲。用户反映一
个问题,开发人员就找原因解决问题.整个开发部死气沉沉。而且是打不完的补丁。新
来的员工也是自己技术不好,也不主动去学。安排什么做什么。没有了危机感.也没有
了主观能动性。因为公司管理考核等各个方面一直属于作坊式管理。强调人性化。
现在如何才能调动开发人员的主观能动性是当前的最大问题。改变掉当前开发部死
气沉沉的局面。让大家在一个活跃的充满朝气的环境中工作。

各位有什么建议?

·心理问题 (2006-03-02) [作 者] YYC [公 司] 天下互联

我看不是什么其他的原因,可能是你们公司内部一些任免机制,或者报酬方面等等让员工觉得再
在公司干下去没有前途或者不顺心,一定要让员工有个良好的工作环境和心理环境

·团队(2006-01-21) [作 者] 克克 [公 司] 郑州 天远数码

1、团队建设很关键,不能只从薪资上给与,还要了解员工的职业生涯规划,给员工持续成长的空

2、每个项目一般都有项目奖金,按劳分配
3、找出每个人的闪光点,每个人的强项,按这些分别负责项目的某一方面,让大家一起参与管理

·guandian(2006-01-15) [作 者] 李冯 [公 司] BJG

企业文化是否出了问题了,倒看不出与项目管理有什么联系

·软硬兼施(2005-12-21) [作 者] 三石 [公 司] 江苏

预先通知,开分析会
设定目标,有奖有罚!

·用钱“砸”,呵呵!(2005-12-13) [作 者] 王海飞 [公 司] utstarcom通讯有限公司

在做一个项目过程中,千万不要忽视团队建设。整天面对 bug,所有的人都成了“消防队员”,对于
这种情况只要是个正常的人都会感到厌烦。在目前这个阶段,lz 要想让自己的队员在精神面貌上
有个立竿见影的改观,恐怕只有用钱“砸”了。其实我觉得,这个问题主要是与公司文化、团队建设、
个人职业道德息息相关的。要想解决这个问题,只有在平时多下功夫,lz 应该知道“台下十年功,
台上三分钟”的道理。

第 151 页 共 756 页
第 1 章 综合管理

·设定合适的目标(2005-12-07) [作 者] 潘谦 [公 司] NEC中科院上海软件开发中心

这种事情确实在很多公司都会碰到。可以通过分析的手法来解决的。

问题点:
开发人员每天对应 bug,没有干劲。
原因分析:
开发人员一般来说没有技术上的提高,仅仅是对应 bug。
提案:
目前没有明确的目标,仅仅是对应 bug 肯定无法让开发人员有干劲。可以通过提出改进目标。
1)通过在目前发现的问题点进行分析,对于系统薄弱的环节进行弥补。尽量在客户发现问题之前
就自己发现和解决问题。
2)整理 bug 的管理系统,从新分析目前系统的不足之处,准备提出下一个版本。整个系统进行进
一步的优化和提升。

·换人如换刀(2005-11-20) [作 者] 王生 [公 司] 广州智能化有限公司

看过“亮剑”吗?什么样的人带什么样的兵!

·Copy(2005-11-11) [作 者] AresChen [公 司] 北京

只有 10 来个人的小公司....我觉得应该是缺乏技术上的领军人物吧,或许有,但可能不再适合水
平越来越高的技术人员。

而且,你谈到救火,的确,对于小公司的产品来讲,这是很平常的事情,产生这种情况的原因就
是技术人员没有人去限制,而技术人员的天性又是“研究+破坏+贪图新鲜”,所以,一旦失去
对产品研发的内容的控制,往往就会出现你这种情况。

建议从两个方面入手:

1,客户需求整理:将客户所反应的问题整理清楚,不是所有的问题都需要及时修改,也包括 Bug
在内,以此入手做好版本控制,让所有的事情做到有计划。

2,大换血:这一点我也没有太大把握,换哪些人也不好说,但一定程度的人员更替,或许能带来
一些生机,看具体情况。

呵呵,好像你在 51cmm 也提出了这个问题,你 copy 我 copy,到这里再回答你一次。

第 152 页 共 756 页
第 1 章 综合管理

·增强凝聚力(2005-11-04) [作 者] miaogang [公 司] beijing

任何一个公司或则团队都“冬天”的时候,这是事物发展的必然规律。冬天来临的时候,一般我
们都会做好准备,每个人都知道。但如果准备不足,也就出现了目前的情况。我建议:要让冬天
里人心变暖。
1、提出明确的发展目标,要让所有人员参与其中。
2、制造必要的工作气氛
3、加强沟通,确定人员到底目前需要什么。
4、可以适当的开展集体活动。

·人是第一位的(2005-10-26) [作 者] 冯国馨 [公 司] DC

就项目管理角度出发,项目团队建设是最早进行的而且是最重要的,团队的基础又是个人能够得
到发展。公司能从这个角度出发,很多问题都迎刃而解。它不仅是项目经理要考虑的事情,更重
要是部门经理要做的事情。
我们公司也遇到这样的问题,分享一些:了解我们的团队需要什么,再对症解决。
其实,就这么几点:公司长远发展、工薪激励、工作氛围等几个问题。
项目经理、部门经理,通过平时与团队同事交谈等方式,了解我们的员工是否乐于从事正在干的
事情,描述一下理想的工作环境,他的兴趣在哪里。让团队明白为什么他们要于正在于的事情。

1、发展
公司有长远目标,这个目标又能和员工反馈、绑定在一起,大家才有原始动力。即个人的发展和
公司的发展明确的规划出来,他们有发挥空间。这个话题比较大,需要老总级别的人确定。
2、激励
工薪尽可能劳有所得,
这之外可以让激励多样化,比如设立一些评优将,增加一些福利,组织针对性的培训等等
3、氛围
组织技术竞赛,组织外出活动,组织聚餐,组织公告板宣传表扬优秀员工、让员工了解公司利好
消息,组织兴趣小组等等。

站在项目经理角度,先力所能及的开展团队建设工作,其他要求可以提给高层推动。
希望对你有些帮助。

·冬日暖阳(2005-10-22) [作 者] julie [公 司] free

你的项目组进入了疲倦期,人有时也会这样.犹如四季进入冬天.

项目组领导要如冬日暖阳,给大家希望。让疲倦者得到力量,让失望者充满信心、让无助者看到依

第 153 页 共 756 页
第 1 章 综合管理

靠、让心灰意冷者感受温暖。

同时,要重新设立项目组目标。这个新的目标要得到大家的认同、要郑重公布、要鼓舞人心。目
标要激励团队,“冬天来了,春天还会远吗?”

·我的一点想法(2005-10-20) [作 者] 黄晓华 [公 司] 广东华联软件科技有限公司

1、加强项目团队之间的沟通。
2、给团队的每个角色进行有效定位,也就是说谁是“接班人”,假如项目经理升职或离职,谁是
接班人,同样项目负责人也是。要给每个团队成队有个归宿感(觉得我们有前途)。

·我的一点愚见。(2005-10-17) [作 者] 刘超 [公 司] 上海泰克科技

我的建议:
1,作为领导你要有对公司的长期规划和详细的发展步骤,而且要把公司的发展规化诚恳的和员工
交流,让你的员工知道,这个公司不是“做一天和尚撞一天钟”的,这样他们会清晰的看到自己
的未来。
2,将公司的发展要和提高软件的开发管理水平和你的员工素质结合起来,可以采用比较合理的项
目管理和软件工程的指导方法,完善和改进和开发流程。要让员工知道,公司虽然不大,但是公
司的目标是达到一个成熟的软件公司的管理水平(例如 CMM L2)。这样一方面可以形成良好的学
习气氛,有利于新员工上手,一方面科学的流程,完善的文档能有效提高软件质量,大大降低将
来的维护成本。
3,及时更新新鲜血液。如果能将公司软件开发过程做到文档化,能沉淀和积累所有员工的经验,
能让新手很快上路,这样你就不会只依靠个别老员工。依你们的待遇,招人不是问题,现在计算
机系毕业的学生满地都是,你要给你的员工危机感。

·如何调动开发人员主观能动性?(2005-10-17) [作 者] 杨新华 [公 司] UTStarcom

从你们公司的情况来看,薪酬应该不是主要的问题。很多公司在特定的阶段都会出现这种情况。
个人觉得,工程师出现这种情况主要是一种疲倦感,无新的知识可学,面对大量的 Bug 感到心力
憔悴,觉得总是没有进展。
要改变这种情况,可以这么试一下。对项目中出现的问题组织大家讨论。一方面是为项目找问题,
另一方面也是员工扩展知识面的一个措施。此外,还应该对此阶段的工作做更细致的计划,制定
详细目标。有成果要大家分享,让大家感到整个团队的工作还是在往前走的。

·标准文档的细化(2005-10-14) [作 者] 小小 [公 司] 深圳

第 154 页 共 756 页
第 1 章 综合管理

1、做好维护文档资料,理顺开发、实施资料,让员工可以通过规范化文档来了解项目,尽快上手。
2、如果不能给解决问题员工在工资上提高,可以适当调休。
3、所谓学习型企业是针对那些岗位没有技术量的工作,但作为研发人员适当的请外来人员培训效
果会比较好。
4、组织深挖问题产生的根源,但要注意不是找责任,而是找为什么会产生这些问题,集体探讨根
源,堵绝同类问题。

·如何调动开发人员主观能动性?(2005-10-14) [作 者] 贺晓宁 [公 司] 中科院软件所

主观能动性的调动,要根据特有的环境和情况,主要手段无非是激励和薪酬制度,个人感觉薪酬
制度是用来巩固的主观能动性,激励才是调度和提高主观能动性的。贵公司的情况应该是要调动,
所以激励应试主要手段,实施员工培训和制定项目明确目标都是可行的方法。当开发人员士气很
好的时候,建立相应的薪酬制度会很有帮助

·建立学习型组织(2005-10-14) [作 者] 天羽 [公 司] 林源教育咨询

不管是集成业务还是应用软件业务,都会存在案例中的情况。主要负责人离开,主要开发人员救
火,积累下来的补丁包越来越大,新人无法掌握......
我们公司也曾经是这样的,走进开发人员的办公区,一片死气沉沉的,工程师们一脸的疲惫,见
面就问“还出差么”;程序员们堆坐在自己的格子里,彼此间的问候也是“没有什么别的 BUG 吧”
我们曾经尝试过通过 KPI 来改变这种局面,甚至建议公司启动新的薪酬系统,但是经过一段时间
别的事情的阻断之后,在和技术人员更频繁的工作之余的交流之后,我们发现大家的苦闷情绪大
都归于“没有更多的机会学习”。之后我们启动了员工教育项目,我们看到员工平日常说“没有
时间”和“加班加点”,在组织真正开始针对他们技能和素质的培训项目面前都变成了“一定参
加”,包括我们的客户平日基本不参加项目组的活动,现在也主动要求接受培训。
我们的经验是,建立学习型组织,才能长久的激励技术人员,激发他们的本能。同时也给新员工
一个真正进入的环境。

1.18 竞聘公司项目经理的问题

竞聘公司项目经理的问题

[姓 名] 张锦全 [单 位] 不公开 [邮 件] lanxue23@126.com


[所属行业] 综合应用 [所属主题] 项目综合管理 [发布时间] 2005-10-8

第 155 页 共 756 页
第 1 章 综合管理

【案例正文】
因公司要改组,我所在的工程部跟运维部将合并重组,会被划分为四个组团(项目组),
以前工程的实施没有指定项目经理的,但重组后,将独立结算,各自为政,项目的实施
采取四组之间竞投方式!
昨天我们去参加公司的项目组组长(项目经理)的竞聘!是单独面试的。大家都被问到
同一问题,我就不会回答了!问题是:
现在我有一项目重要的项目中标了,
但身为项目组长的我又不能到现场去视察情况,
单凭组团里的同事去给你实施,我怎样保证我的组员能多快好省地完成这项目?我
的组员有可能合伙骗我工程情况,令我浪费资源。而我又不能到现场去视察。在这
种情况,我如何管理好组团!我是没权力炒人,也不能事后通过罚钱来保证!因为
事后已经是让公司赔钱了!
那我如何才能保证项目的顺利开展!能达到如期限的效果呢???

帮帮忙!
他们没有给答案我,我也想不出什么好答案!

【相关分析】

·有效的执行力(2008-07-19) [作 者] 杜俊杰 [公 司] 无

这是一个比较实际的问题,但问题出在哪呢?就是你不能到场!我觉得保证项目的顺利开展问题在于
项目实施过程的监督,包括项目实施的监督和项目组员的工作监督,但是项目经理你本人却不能到场,
起不到有力的监督作用。这时我觉得你应该想想怎样使自己不到场和到场的效果都是一样的呢?要是
我的话,我会按照两步走!第一,让项目成员亲历现场,按照他们的分工不同,分工协作完成一本项
目的初步计划书,最后由你再和成员一起完善下制度方面的问题,形成一份完整的项目计划书;第二,
就是考虑监督的问题了,选派一位全职的项目助理,独立的执行监督权,我认为最好是年轻的,懂项
目的,这样做起事来比较热情,受社会的坏风气影响也很小,但是要绝对保证他的权利,明确他的职
责,这样让他代替了你执行项目的监督,也不至于支付过高的项目薪酬,不会出现成本超支的问题!
有了得力的监督力后,按照项目的计划执行项目,让项目助理每天给成员按照各自的表现进行绩效评
定,我想这个问题就解决了!而且在过程中,要相信职业人员的职业道德!这只是我个人的见解,希望
能够看到大家更好的解决办法!

·fghf(2008-05-23) [作 者] 王玉娜 [公 司] 上海天马微电子有限公司

1.收集客户的资料,明确客户需求。做到心中有数
2. 挑选得力干将,2-3 人,现场评估,各自作出项目计划书。
3. 比对以上资料,并讨论后,确认最终项目计划书和项目进程管坑。
4.项目成员定期提交报告,召开会议监督项目进程,及时调整。

·多项目管理(2008-04-25) [作 者] 马宏伟 [公 司] 湖南省建筑工程集团总公司

第 156 页 共 756 页
第 1 章 综合管理

这是多项目管理的问题,必须从项目组织建设、项目流程建设、项目制度建设着手,首先要解决资源
分配问题。然后采用单项目管理方法,进行项目计划、监控。

·沟通方式是多样的(2008-04-03) [作 者] captainhua [公 司] 惠州

面对面的沟通确实是最有效的,但也不是唯一的一种.作为最重要的连带责任负责人,在承担责任前要
想方设法搞到足够的信息来降低承担责任的风险.毕竟任何一个环节出问题,都会对项目造成不良影
响.
如果不能去现场,但总能找到"key man",那就通过手机/邮件/即时通讯软件等方式沟通,另外,也一定会
有合同等文档等方式.只要想办法,总能得到想要的情报.

·竞聘公司项目经理的问题(2007-08-30) [作 者] tjh [公 司] cxgs

1:一个好的项目经理,应当能够估计(类比或其他方式)出项目的大体情况的
2:让你的手下分别做一个项目计划
3:对照你的顾客提供的资料
4:三项合一,一个真实的蓝图在你的眼前了;你的手下还敢骗你吗?

·项目经理的授权处理问题(2007-08-28) [作 者] 董新山 [公 司] 荣文灯饰(东莞)有限公司

作为项目经理不是事事到场,但是你提前把项目的事项告诉下属,按照你意思去做就可以了!这事你
要受控哦!

·资源评估和分配(2007-08-14) [作 者] alex [公 司] 保密

这个问题太简单了,这不是项目经理会遇到的问题,只要从事过领导职位都应该会回答这个问题。简
单列举一些方法:

1. 人员选择。本来经理就是要能用人,用对人,你派出去的人要是你能够信任,有足够能力的。如
果事事都要项目经理做,就不是经理了。
2. 过程控制。在出去的时候要随时保持联系,了解进度,保持对过程的控制。
3. 奖惩。在之前要鼓励士气,之后要适当奖惩,口头表扬或批评,外出旅游,更有意义的工作,聚
餐等等。发奖金和开人是两个极端,本来就不鼓励使用,更别说还有限制了。

看来你功力还是没有够,先试着在技术上取得突破,然后再从事领导工作。

·很实际的问题(2006-11-23) [作 者] 方俞军 [公 司] 安徽淮南

第 157 页 共 756 页
第 1 章 综合管理

这个问题既实际但又较广大、空泛,因为在实际的项目中还需要很多必备的条件来补充解决问题的内
容。
但我想这个案例中最实际的问题还是加强项目控制的问题。

这个问题既实际但又较广大、空泛,因为在实际的项目中还需要很多必备的条件来补充解决问题的内
容。
但我想这个案例中最实际的问题还是加强项目控制的问题。

·进度控制和成本控制(2006-02-16) [作 者] 张青山 [公 司] 浙江交大龙山

现在需要关注的是以下两个问题:
在本项目的情况(见本项目情况描述)下怎么样做好项目进度控制与成本控制?
首先,要从项目计划着手,制定阶段性目标(包括进度与成本),并要求客户对阶段性工作进行书面
验收。只要阶段性目标一步一步完成,那项目就在控制之中了。
其次,要与项目组成员和客户保持良好的沟通,通过沟通掌握项目情况。内部沟通可以通过实施人员
定期的书面工作汇报(工作日志、阶段工作计划与总结等)来实现,外部沟通可以通过电话、邮件等
与客户保持联系。
最后,就是根据内(实施同事)、外(客户)部了解到的项目进展情况对比项目计划中的阶段性目标
完成情况对项目计划进行调整了。
对于组员可能合伙骗我工程情况的问题,就是项目人力资源管理的问题了,组员的目的无非就是得到
更多的利益,则可以根据项目完成情况制定一定的奖励措施,当然同时得说明利害关系。

·guandian(2006-01-15) [作 者] 李冯 [公 司] BJG

1:一个好的项目经理,应当能够估计(类比或其他方式)出项目的大体情况的
2:让你的手下分别做一个项目计划
3:对照你的顾客提供的资料
4:三项合一,一个真实的蓝图在你的眼前了;你的手下还敢骗你吗?

·团队的建设才是最重要的(2005-12-29) [作 者] kents [公 司] Guangzhou Precision

这是一个比较难的问题,但是在很多单位都会碰到类似的问题。在管理一个团队的时候,不是说一定
要求项目经理必须有人事权才能去领导的,在中国有中国的国情,管理是一门复杂的艺术。通常的情
况下,胡萝卜比大棒更好用,尤其作为项目经理要学会怎么使用免费的胡萝卜。
对于这个问题,我觉得最重要的是考你的管理才能,如何有效的激励团队,虽然利益很重要,但是作
为经理,要懂得利用自己的人格魅力和权威。作为经理,当然不能无原则的相信组员,但是也不能先
入为主的把组员都放在对立面。
我觉得最好的答案就是告诉主审,我有信心建设好我的团队,把整个团队团结起来,建立起一种积极

第 158 页 共 756 页
第 1 章 综合管理

向上的团队精神。俗话说,兵熊熊一个,将熊熊一窝。

·竞聘公司项目经理的问题(2005-12-14) [作 者] 王海飞 [公 司] utstarcom通讯有限公司

在这种情况下,要对获得的信息达到 100%准确肯定是不可能的,下面的人员难免会因为私利而采取
一些蒙蔽的手段,我觉得这是可以理解的。只要把握好总体方向,不要让他们影响到项目目标就可以
了。另外,培养一两个较有能力的亲信我觉得是个不错的方法,这也属于放权的一种;其次,要多关
心一下他们(例如生活方面的),让他们感觉到你是一位不错的领导,能够替他们解决问题。这样一
来,他们遇到一些工作问题就会找你来协助解决,也容易将项目中出现的问题暴露出来。纯属个人的
土办法,我曾经就这样实践过,效果还不错。不过感觉好像不太适合用于应聘时的回答,呵呵。

·实践问题,非理论(2005-12-06) [作 者] 梁松波 [公 司] 上海市标准化研究院研究中心

既然是项目组实际可能遇到的问题,而不是理论考试,建议你不要象书生一样回答按怎么的程序、步
骤解决,这样做只会给人以纸上谈兵,不会实践的印象。只需说出你的解决策略即可。比如将项目组
成员的利益与项目的成败挂钩。项目组成员有其它小动作的原因,无非是有利可图。前面有人提到的
用三个人,一个一把手,一个二把手,一个亲信,一把手和二把手还对立,三个渠道获得信息的方法
不可取。看似高明,一看就知道是什么意图,反而更不利于达到目标。头二号人物对立,你不是给自
己找事做嘛。

·不妨来个空城计(2005-12-02) [作 者] 张华伟 [公 司] 齐齐哈尔大学

案例有三点注意:
1、项目经理部在场;
2、派的项目组员有受贿嫌疑;
3、不能开出此成员。

项目经理派次组员区的时候谈话的内容有以下几点:
1、对其说有绝对的信任;
2、说一些这个客户的情况,并提及从朋友那里得到的和朋友在那位客户那里工作或是好朋友;
3、不经意间提及有受贿的同时的处理情况(可胡编),并报出同情。

另 次为权宜之计,事后应调整工作分配,既然一人不能开除,那么以后不要给其重要任务。

·沟通(2005-11-26) [作 者] czg [公 司] HEQIYUAN

1、制定项目组运作规范、制度;

第 159 页 共 756 页
第 1 章 综合管理

2、多与组员沟通;
3、加强和顾客沟通,了解真正情况。

·沟通(2005-11-26) [作 者] czg [公 司] HEQIYUAN

1、制定项目组运作规范、制度;
2、多与组员沟通;
3、加强和顾客沟通,了解真正情况。

·竞聘公司项目经理的问题(2005-11-25) [作 者] 凌华 [公 司] 中国电信

本人看法:项目前期对项目所要达到的目标作出定义,对实际情况作出分析,本项目的项目组长对项
目的实际情况都不清楚,一开始就乱了,我认为此项目要想实施的好比较困难。
问题分析:本案例项目组长所担心的问题是项目组成员和合伙人(客户)一起来欺骗组长,本人认为
项目组长应该和客户沟通好很关键,我想客户还是想把项目做好,毕竟是自己的出的钱,出了钱就要
买到自己所需要的东西,此方法应该是一个解问题的一个有效方法。项目组成员如果真的有这种想法,
我想项目组长应该弄清楚为什么项目组成员有这种想法,是不是某些方面的工作做的不够,一个项目
组需要的是凝聚力,认为组长应该在项组成员的思想上多做工作,一句话“精神和物质都是很重要
的”。此项目的情况需要建立一些奖罚制度来鼓励项目组成员。本人观点,谢谢!

·提出自己的想法(2005-11-23) [作 者] 常川 [公 司] 暂不公开

现在的问题是组员有可能合伙骗你,那么这个团队是一个面临崩溃的团队,但当务之急又不能大力搞
团队建设,在这样的情况下,我认为,简单的讲,为了保证项目顺利的实施,不能出丝毫差错,虽然
自己不能亲临现场,但要通过各种手段亲自操纵此事,决不能放任,当然这不是作为一个团队的办事
方式,但这种情况下,不得已为之。等次项目结了,或在此项目中进行团队建设,亡羊补牢尤为晚矣,
否则下一个项目还会遇到此种棘手的问题!以上仅是我的拙见,主要分析了一个方面的问题,仅供参
考,谢谢!

·我的分析(2005-11-21) [作 者] 张坤 [公 司] 中铁建设集团有限公司

1、既然有合伙欺骗的情况,必然是经济利益的问题。所以在项目实施前必须要有内容详实的成本分
析报告和成本控制方案,控制好项目进程和成本支出的协调性、一致性。
2、由于你本人不能到现场,所以更应该强调项目的计划性,对项目做更详细的任务分解和委派,务
必使人尽其责。建立项目队员周汇报和月汇报制度,汇报内容可能会出现假大空,所以同时还需要建
立客户回访制度,按时间和项目计划的节点调查客户满意度。
3、我个人认为在项目管理中务必体现出人性化的一面,所谓团队,就是团结的队伍,团队建设要始

第 160 页 共 756 页
第 1 章 综合管理

终向着健康、积极、团结的方向,充分发挥个人的积极能动性,这样你就能够保证你的组员多快好省
的工作了。至于采取炒人或罚款的方式过于粗暴了点、笨拙了点,不一定什么时候都是“亡羊补牢”。

·找个副经理(2005-11-20) [作 者] 王生 [公 司] 广州智能化有限公司

全权委托一个可信赖、有能力的人选做项目组的副经理,直接对你负责.

·我的分析(2005-11-18) [作 者] 喻国军 [公 司] 研发

1、分析组员合伙骗我的原因。不考虑平时与组员的关系不好,存在过结的原因,骗的原因无非是在
于利益!
2、做好项目计划,明确责权利,建立奖惩机制。既然有能力做项目经理,对所从事的项目肯定是比
较了解的。将项目分结成具体的任务,每个任务按以往验形成的资源定额分配资源,建立奖惩制度。
虽然不能通过事后罚钱来处理,但可能找过程中任务完成情况来进行其它的奖惩,比如上报公司通报
批评。
3、分里程碑检查项目情况,虽人不能到现场,但可以利用电话、照片、视频等工具查看。可以利用
业主等对项目的反映,间接得到项目情况。
4、加强团队沟通,建立定期的与不定期的报告制度。

·我的分析(2005-11-18) [作 者] 喻国军 [公 司] 研发

1、分析组员合伙骗我的原因。不考虑平时与组员的关系不好,存在过结的原因,骗的原因无非是在
于利益!
2、做好项目计划,明确责权利,建立奖惩机制。既然有能力做项目经理,对所从事的项目肯定是比
较了解的。将项目分结成具体的任务,每个任务按以往验形成的资源定额分配资源,建立奖惩制度。
虽然不能通过事后罚钱来处理,但可能找过程中任务完成情况来进行其它的奖惩,比如上报公司通报
批评。
3、分里程碑检查项目情况,虽人不能到现场,但可以利用电话、照片、视频等工具查看。可以利用
业主等对项目的反映,间接得到项目情况。
4、加强团队沟通,建立定期的与不定期的报告制度。

·竞聘公司项目经理的问题(2005-11-18) [作 者] 语琪 [公 司] 品高软件

大家都从不同角度进行全面分析,足以看出各人的思维和角度各有千秋。本人比较认同的是从:项目
“任务分解”、团队管理两个方面来处理:)

·个人以为这只是考试,基本想了解你的计划能力、风险能力、沟通能力、人事能力。

第 161 页 共 756 页
第 1 章 综合管理

(2005-11-12) [作 者] 刘瑞富 [公 司] SCUD

非常认同天羽兄的分析。

·竞聘公司项目经理的问题(2005-11-10) [作 者] 都市布衣 [公 司] 上海宇信

在这个题目中,作为项目经理,你的权力和所掌握的人力资源都已经确定。是无法改变的。
在你所述的情况是一种项目风险,为了能保证项目的成功,个人认为有几件事情要做好。一是项目计
划(还要有风险计划),二是沟通,三是项目控制(包括风险控制,应对措施)。
也许各个行业也有各个行业的特点。如果是一个软件企业,那么作为不能去现场的项目经理,你可以
让项目成员定时远程提交所做的工作,然后在你本地进行检测

·我的意见(2005-11-09) [作 者] 赵华 [公 司] 中国电信广州研究院IT系统部

我认为重点不是项目的计划,而是项目计划的监督。
那么有以下几点可以做:
1)谨慎分配外地项目组的角色。找出三个人:一把手、二把手、亲信。一把手是威信最高的,二把
手是和一把手对立而且具有一定威信的、亲信是你最信任的。
2)和项目组成员保持密切联系和沟通。分别向三个角色获取项目信息,还可以随机“慰问”项目成
员。定期的签名项目汇报是必要的。
3)和客户(甲方)、监理保持联系。
这样基本上能掌握项目的真实情况,及时发现问题。
发现问题后就好办了。
积极解决并和上级沟通。

·项目管理中的踢皮球能力(2005-11-09) [作 者] 许野平 [公 司] 济南黑格软件有限公司

一、不能去现场。

这一限制确定你必须采取书面形式控制你的项目进程。采用的技术是里程碑控制。和客户就项目进度
达成一致,然后对项目的进展和质量情况由客户反馈必要的书面信息。

为确保项目不出现大的失误,里程碑需要采用较小的增量。

二、没有权利炒人

你可以把员工业绩如实以书面材料(当然需要确切的数据)上报你的上司,如果上司不给你换人,你

第 162 页 共 756 页
第 1 章 综合管理

可以提出其它交换条件。例如项目延期,追加投资等。

总之,这个题目是考察你利用书面文档踢皮球的能力的。只要你能摆脱个人责任,项目是否能多快好
省地完成是你给你这个没实际权利的项目经理关系不大。

·问题分析(2005-11-08) [作 者] yatoto [公 司] 呀

两个方面分析:
1、最简单的方法就是书本上的知识,项目组织计划、实施计划、工期完成情况等计划和实际汇报工
作进行对照比对,看是否出现问题和计划和汇报不一致,每个人介绍的情况是否相同,出入是否很大。
如果还不放心可以要求现场图片传回。
2、第一条我已初步的进行控制,如果还不放心,首先考虑团队是否出现了问题?问题在那里?然后
从问题根源解决。或者说您在组建团队的时候就有问题,消极意见:离开团队。改进意见:通过第一
条的控制然后进行现场问题核实,作为一个项目经理主要职责是不能忘的,那就是沟通协调。项目经
理肯定会和甲方或乙方、监理方进行沟通问题,在沟通中可以侧面或正面了解现场情况,如果和现场
情况相符就不要太担心了,如果和汇报情况不一样,且差距非常大,您就要小心了。对是否需要到现
场或更换组员,就是你最重要和最直接考虑的问题。

·竞聘公司项目经理的问题(2005-11-08) [作 者] foxer97 [公 司] 上海某咨询公司

1.项目执行前制定详细项目计划并取得相关环节负责组员的认可。
2.设立项目奖金。

·以其人之道,还其人之身(2005-11-08) [作 者] 李福田 [公 司] 交通银行桂林分行

我觉得设置关键点是必要的,其次,对于领导说不给你亲自到现场,不给你炒人,你可以任命人啊
所以
你就选几个你的“亲信”到那里做督导啊,或者是请个监理公司常驻现场,总该可以的吧
还有就是要手下常常想你汇报项目进度,采用先进点的技术,如用数码相机,派你的亲信用摄影机去
过几天拍摄现场情况啊
等等啦

·设置关键点,分工合作(2005-11-07) [作 者] 宁方军 [公 司] 上海某环境工程技术有限公司

首先你要对该项目从总体框架上了解清楚,其次要做出相关的施工计划进度 ,设置几个不同的关键
点;然后由不同的人分管不同的工作;同时对于项目在现场的实施,建议采用一些数码设备, 如数
码相机对现场施工情况进行拍照存档,数码摄像机对整个现场进行摄像存档等;每天或每周由不同的

第 163 页 共 756 页
第 1 章 综合管理

人进行汇报工作--现场施工进度、施工情况,有必要让该汇报人汇报一些涉及其他人的工作;根据不

同人员的汇报情况,进行总体的总结及概括,是否存在欺骗性质。文字文字

·分析问题-解决问题的思路是真理(2005-11-02) [作 者] 李继续 [公 司] 银河公司

首先,重要项目中标,身为项目组长不能到现场去视察情况,为什么?是自身原因?领导原因?客观
原因?----搞清问题的前提,有利于问题的解决。
其次,身为项目组长没权力炒人,那么还玩什么经理?----纯粹不符合项目管理制度,辞职或罢选。
第三,核心问题是项目组长不能到现场去视察情况,组员有可能合伙骗,为什么?想骗?容易骗?骗
动机?最可怕的是合伙骗,太恐怖了,是不是自身有问题,如果没问题,那么就大胆干,不要再靠
“人”,靠合理有效的制度。

·竞聘公司项目经理的问题(2005-11-01) [作 者] 江留华 [公 司] 上海京海投资管理有限公司

1.项目团队是否是自家挑选的,如果是,则你应该有充分的信心认为不可能欺骗你
2.关键的问题是管理和制衡制度的建设,不是靠道德而是靠制度来管理才能减少人为因素的风险;
3.采样必要的信息化管理手段,建设科学管理的项目管理文化.
以上意见供参考.

·竞聘公司项目经理的问题(2005-11-01) [作 者] running [公 司] CCID

同意天羽的观点。
是测试题,而不是做项目。考的是你的理解力和项目控制能力。
题中描述的情况是已经存在的的,可能的情况是已经存在问你如何处理,而不是你如何重组或建立团
队或培养协作精神的时候。
所以,本人认为应当从以下几个方面回答:
1.除了领导限定的不可以条件,我还有没有或还能不能争取一点权利。比如:奖励机制?名誉惩
罚?。。。
2.建立完善的进度计划,设定任务检查点。要求组员定期提交报告,报告必须有甲方责任人签字,如
果没有甲方,那么就要委任一位现场项目组长(须慎重选择)
3.细节决定成败,一方面,从组员汇报的细节中,看看有没有不能自圆其说的,或者组员之间相互矛
盾的;另一方面,做好项目细节管理,比如,工作分解结构分解的工作包够不够细,时间分配细化到
什么程度等。
天羽强调的很重要:保持思路连贯、逻辑清晰就好了,另外最重要的就是讲话能力,要能够自圆其说。

·多方面考虑(2005-11-01) [作 者] 杨新华 [公 司] UTStarcom

第 164 页 共 756 页
第 1 章 综合管理

我有两点意见。
1. 既然担心组员联合骗你,应该有事先可以想到的一些理由。要针对这些可能的理由去和组员作沟
通。我想项目的完成对任何一个人都是有好处的,没有谁会无理由地和你过不去。
2. 除了从组员这里了解项目的情况外,也可以从别的渠道去了解一些(比如说,项目的客户),如
果有的话。

·防范于未然+沟通(2005-10-30) [作 者] 孤独剑 [公 司] 中电科长江数据

防范未然:
上任后你的项目组会不断的接到新的项目,因此第一件事你就得把你的组员分成几个团队.每接到一
个项目就派最佳的组合过去,组合最重要的要求:不要有人才的浪费,如果这个项目派去了过多的人
才,再接到一个项目你就可能组织不出能够胜任的团队了.这样你保证你项目组的效益最大化.
沟通:
(我的组员有可能合伙骗我工程情况)解决"骗"问题的最好方法是沟通.他们骗你工程情况有两种原
因:一、工程中出了问题怕你责任;二、想从项目中多捞点好处。
因此沟通策略如下 :1、与组员沟通。不但与每个组员要有书上上的沟通,还要有口头上的沟通。这
样既能知道工程的进展情况,工程进展中的难题是什么也能及时了解团队中人员的思想变动情况。2、
与客户沟通。既能建立与客户的良好关系又能知道团队给你的汇报是否属实。
如果本人的解决方案和不妥的地方请各位来信批评指正,在此感谢你的批评和指正。

·竞聘公司项目经理的问题(2005-10-28) [作 者] bluesnow [公 司] 上海

各位分析的都很好,应从远程项目管理的特点入手,主要规划好项目的进度,让组员相互协助相互制
约;要及时得到项目的进展情况,安排好项目情况的汇报和收集方法;还要和整个团队的人员相互沟
通,可以通过电视电话会议。

·因地制宜(2005-10-28) [作 者] 牛小林 [公 司] 有空就来

个人认为,可以从以下几个方面入手:
1。从项目的计划入手,进行任务和工作的拆分,然后任命不同的人负责不同的工作,让各个人员进
行单独和及时的汇报。
2。在以上的基础之上,通过各个侧面的信息,汇总出整个项目的情况(注意及时)
3。加强对采购和费用支出的控制力度。
4。和具体的单个负责人强调故意浪费,和腐化的后果。
5。建立相互监督机制和制度。
6。引入公司监管人员和机构。

作弊总不可能天衣无缝,只要你仔细,周全,总能发现问题的。

第 165 页 共 756 页
第 1 章 综合管理

·重点是团队管理及计划制定和监督(2005-10-25) [作 者] pradio [公 司] RADIO工作室

个人认为问题的实质是在远程的项目管理中项目经理需采取的措施,特别是团队管理的问题如何解
决。
首先,要明确在远程的项目管理下,沟通尤其重要。这包括同团队的沟通和同客户的沟通。在此方针
指导下,采取相应的一些措施:
1、是沟通方法的确定,如通过 EMAIL,MSN,视频电话,每日通报,每周通报,每月总结,同团队和
客户沟通项目进展的实际情况,相互验证,相互督促。
2、确定远程项目小组的角色和分工,尽量明确,各把一块,同时明确当地的小组的负责人,一切事
项向你反馈和贯彻计划,跟踪结果。
3、制定计划,包括进度计划和成本计划,并要求远程小组确认。防止遗漏。
4、准备记录可能的风险和风险应对计划,并实时跟踪。特别是要制定所提的问题“我的组员有可能
合伙骗我工程情况”的应对措施和你的底线,如:如果我的组员合伙骗我,我在什么范围内可以忍受,
超出什么范围,我要警告;超出哪一个范围,我要采取断然措施,包括亲自去一趟(告诉公司在这个
情况下还不批准的后果)。
5、计划制定且各方确认、实施后,要跟踪计划的执行情况。这是项目经理在执行过程中主要做的事
情,就像一个舵手,让船在各种激流的冲击下朝目的地行使,避免偏离航向。
6、总结:不管什么情况,项目最终的目的是实现目标,如果能在计划范围内完成项目,则有些资源
损失也是可以容忍的。
仅供参考。

·我也来说说(2005-10-22) [作 者] kaney [公 司] nothing

哈,我也来试试,

这种情况,既然问到了,就表示有可能会有这样的情况出现,项目经理不能去现场而只能遥控指挥的
问题,那么,如何保证项目进展,项目成功呢
我觉得从项目规划起,项目经理的选人是非常关键的,如果人员选的比较到位,除了技术,还有人品,
还有项目实施能力,这些人员到位后,下一步的主要工作,就是定期了解项目进度,特别指出的是,
作为项目经理,一定要有防风险的能力,如果不能去现场,那么这个项目经理还有一个能力要体现出
来就是预防风险的能力,将这些问题列出来,让负责具体实施或是具体研发的项目组成员回答,这样,
一方面是对项目进度有把握,另一方面,对项目风险情况也有所了解。
另外,还有做的一件事是就是沟通,除了与项目成员沟通之外,还要与局方进行沟通,从他们的口中
了解项目情况。
这样多角度,全方面的了解项目进度情况,才能保证项目的顺利进行。

·选人+流程(2005-10-22) [作 者] julie [公 司] free

1.选择有能力并且值得信赖的人成为你团队的成员。异地工作对选人的要求更高。

第 166 页 共 756 页
第 1 章 综合管理

2.建立项目团队工作流程和监控流程,让流程去发现问题,而不是通过项目经理一个人的走动检查.

3.在此方面可以参考的案例不少,比如跨国大公司在各个国家都设立分公司,分公司的运作基本靠本
地人员,公司的总 CEO 每年也去不了两次现场.

·4 点基本能解决问题(2005-10-18) [作 者] 梁桢 [公 司] 上海广平信息系统工程有限公司

首先,做为 PM 对于团队成员的选择是项目实施前就需要解决的问题,“用人不疑,疑人不用”的道
理需要每个项目经理自己必须清楚的处事原则,因为不那能去现场,所以派去实施的人必须有一定的
能力,总的说是团队建设问题。

其次,对于团队成员应该给予一定的授权,既是让其感觉能够得到信任,而且也避免项目中出现鸡毛
蒜皮的小事也适时报告的局面,拖延工程进度,总的说是项目中授权问题。

再次,团队成员若存在欺骗的情况无非也是需要增加收入,所以项目过程中应该建立奖惩制度,即项
目提前或者低于预算但又确保项目质量的情况下给予奖励,反之则报公司备案。当然这都需要公司在
项目结束之后有一个结算的过程,所以说这是个奖惩制度如何建立的问题。

最后,PM 必须必须是个有能力管理懂管理的人,而并非必须是技术强人。我个人推崇外行领导内行,
但必须是能自我学习的人。而不是指手画脚的人。

· 事情一定有答案(2005-10-17) [作 者] 褚四斌 [公 司] 中国广东

一定有答案,
但总会有更好的答案;

只要能自己解释自己的答案就是正确的;

从我的观点来看,可以通过两个方面来解决;
1.从感情上把大家拉到一条战线上,达成共识"项目的成败与每一个人息息相关";

2.从制度上来控制,如果出现欺骗的现象将来怎么样,虽然不能从经济上处罚,但可以通过公布名单的
形式来处罚,让他今后难以在行业内的名声变坏,这比经济处罚可能更加有效.

·竞聘公司项目经理的问题(2005-10-11) [作 者] 贺晓宁 [公 司] 中科院软件所

对于这个特殊的项目,合理的计划和合理的项目监控机制非常重要,同时项目管理者要有人力协调的
能力,使用合理的心理激励方法,建立合理的管理者形象,对避免不信任发生很有帮助。根据题目,

第 167 页 共 756 页
第 1 章 综合管理

使用惩罚手段避免团队不信任是不可能的。

·这是一个综合的问题(2005-10-11) [作 者] 边强 [公 司] 北京中科院软件中心

1 首先团结组员,良好的合作关系会防止问题的发生和隐瞒
2 不争功,不韪过,将功劳让给你的组员
3 良好的计划.细化所有的问题,并提出相关的解决方法.
4 合理的检查时间和手段,让问题早发现.周报或日报,及时发现开发过程中存在的问题
5 敢于对项目负责,对在项目中发生的所有承担责任
6 以个人的人格魅力瓦解可能的小集团

·竞聘公司项目经理的问题(2005-10-11) [作 者] 陈平 [公 司] dt

如果面试官考查你的应急能力,和逻辑分析能力,哪么这道题也就没有什么价值了。这种情况出现,
假设无法通过任何方式,方法能够解决你亲临现场的处境,哪就必须从制度设立上去考虑。哪一块会
给公司或项目带来重大损失,哪一块次之要进行一个排队(这也是制度设立的要本),例如采购这一
块最容易出现回扣,虚报,哪么就应该在这一块严加防范(科学合理的制度)。当然在这其中还需用
一些谋略,互为制之。项目成员所做的一切不利于公司或项目的都是以自身利益为前提,这一点只处
理好了,项目成员也就没必要提心掉胆的过日了

·竞聘公司项目经理的问题(2005-10-10) [作 者] zhansir [公 司] kunmingligongdaxue

我觉得首先应该确定计划是否详细,是否到位;其次应该知道 p、t、s、c 四方面有没有脱离方向,


如果没有的话,你可以不用去现场,但是答案是否定的,你就必须奔赴现场去控制局势。总之要根据
条件来看情况?

·补充(2005-10-09) [作 者] 一孑 [公 司] 一孑工作室

项目经理的优势是项目管理,有能力分析出项目的不合理之处,问题是当你明白后,如何处理?也许
需要一些勇气对领导说“不”,也许需要一些勇气改变管理模式,甚至需要一些勇气去承担不该你承
担的责任。
关于此问题是出题人给你限制条件,但这样的实际情况发生,那么你需要分析是什么样的问题产生了
这样的限制,如果是领导的指令,你需要和领导沟通,并加以解决。如果是你自己的问题,你需要自
我协调。让其合理,而不是任由一些不合理的现象发生。甚至当你无法改变时,你能做到的最大努力
又是什么?如何最大限度挽回项目的损失。
不建议避重就轻的回答此问题,既然出题人出了这道题,就应该已经考虑到回答人的几种答案了。

第 168 页 共 756 页
第 1 章 综合管理

·试题的目的在于了解面试者的应急能力(2005-10-09) [作 者] sunboy [公 司] 浙江省杭州市

严重同意天羽的说法!

·讨论一下(2005-10-08) [作 者] 天羽 [公 司] 林源教育咨询

赵兄,楼主的问题是个面试题目,意思是说如果下属合伙骗你 你将如何应对。我理解出题人的意思
是考你发生此类问题时你将如何处置,或是问你如何控制不值得信任的下属去完成指定的任务。现在
你说要如何如何团结下属,或是怎样怎样提高威信,楼主不能过关啊。是否可以展开说明一下如何事
前搞定呢?

·团结项目成员(2005-10-08) [作 者] 赵明禄 [公 司] 天津

在这个问题上,他们没能让信任,你猜想到他们在骗你。在做项目最主要的是,彼此信任。所以说,
你应该让你的成员听信于你,团结好全组的人。这样他们就不会骗你,你就可以了解到你想要的信息。
做项目不单是一个人的事情,而是靠全体的成员去完成的一个目标。你说到全体成员可能全伙骗你,
应该问题出现在你的身上。在过程中,也许有一些为了个人的利用,而做出一些不合项目的计划。这
证明你的威信不够,如果全听信于你,愿意跟着你,他们就会什么都听着你的指示努力工作,也会把
所有真实的信息反馈给你,让你了解整个项目的进度,费用等信息。现在的问题不是怎么回答上级的
问题,而解决怎么把全成员团结起来。好好努力吧!

·不是案例(2005-10-08) [作 者] 天羽 [公 司] 林源教育咨询

这不是一个正常的项目案例,而是一道试题。
你怎么作答都是可以的,关键是面试你的人并不想知道答案,主要想明白你的处理问题的思路,只要
你能够在三个问题的处置上保持思路连贯、逻辑清晰就好了,另外最重要的就是讲话能力,要能够自
圆其说。

简单的讲可以沿着:计划->任务分派->关键资源配置->计划跟进->阶段盈利点评审->......的顺序去
跟进项目。对可能的欺骗行为进行风险分析,并列出风险计划、沟通计划,而后并行跟进,充分利用
阶段盈利点评审活动去进行“事中”控制~验证和纠正。此外,你虽然没有权利炒人,但是你有考核
权利,这是你必须争取的,你的考核结果将直接影响到员工个人的利益和发展。

个人以为这只是考试,基本想了解你的计划能力、风险能力、沟通能力、人事能力。

第 169 页 共 756 页
第 1 章 综合管理

1.19 无实权,如何有效进行控制?

无实权,如何有效进行控制?

[姓 名] derikwoo [单 位] 不公开 [邮 件] derikwoo@hotmail.com


[所属行业] 综合应用 [所属主题] 项目综合管理 [发布时间] 2005-9-12

【案例正文】
公司上面最近匆匆开发一个项目,没有任何相关的资料,我被指任负责这个项目,
具体关于项目的细节让我和一位空降来的总监沟通,经过一段时间沟通才知道,这
个项目是外面公司拖进来借鸡生蛋的,具体的事情都是那位总监在做,我事实上只
能起到一定监督作用,但是经观察项目本身运行没问题,只是风险全部在我们一方,
一但风险控制不力有可能使公司很多业务瘫痪,上面又不放权下来,实在难办?我
应该怎么扮演好自己的角色?

【相关分析】

·还是尽量争取些权力来做好一点(2005-10-09) [作 者] tongjiang78 [公 司] 暂不透露

还是尽量争取些权力来做好一点

·把自己当做助理的角色了(2005-10-04) [作 者] 朱小文 [公 司] 国楚科技

这样的项目经常会存在的了,你把自己在项目中当做总监的助理,同时也是公司在这个项目中的监理
即可,助理是配合总监对公司的流程做好的规划,监理是不要让项目远离公司的项目目标。

·明确目的才能选用有效的方法(2005-09-29) [作 者] 牛小林 [公 司] 有空就来

你既然被任命为项目经理,你同时就被授予了一定的权利何义务,风险控制是项目管理 9 大范围之一,
在本案例中,沟通我认为是至关重要的一环,如果沟通不畅,不仅会造成你和总监的矛盾,同时,会
造成项目的失控。

为此,首先你要定义好沟通原则,比如,例会制度,周报制度,通过有效地沟通,切实及时有效的了
解项目的进展状况。

在"事前",要明确项目的目标和范围,资源状况和时间要求等。然后进行风险分析,给上级提供
风险分析报告,同时提出规避风险的建议和资源要求。根据项目的情况和项目的周期,设立有效的监
控时间间隔,对项目的风险化整为零,降低项目的风险。同时设立风险的监控标准,定期跟踪风险的

第 170 页 共 756 页
第 1 章 综合管理

变化趋势。

在“事中",要根据项目计划的检查点,落实检查得力度,这个要靠制定项目计划时对里程碑和阶
段性可交付成果的明确定义。及时发现风险变化趋势是否在掌控范围内,如果不是,或者项目的风险
朝不良的方向发展,就需要你及时通知项目的有关领导(首先和那位总监沟通),从而实现对象目的
合理干预。

在"事后",要及时总结。

·做个成功的项目经理(2005-09-28) [作 者] 银勇平 [公 司] 中南林学院

你所遇到的情况是项目经理最常遇到的问题,没有实权但要把事情做好,所以项目经理被描述身处众
林之中,到处充满危险。对于你现在的情况,要好好做好下面几件事情:
1、了解项目真正的背景,公司启动这个项目的目标是什么?
2、项目经理要处理好与每位项目干系人的关系。
3、特别注意跟项目干系人之间的有效沟通。
4、运用项目管理的方法对项目进行管理,并对项目风险实施动态的风险管理,控制项目风险。
5、最有效的权力是专家权与人格魅力权,利用本身的素质与的能力,建立真正有效的权力,做个成
功的项目经理。

· 做自己本份的工作(2005-09-28) [作 者] 褚四斌 [公 司] 佛山battenfeld Chen

首先是做好自己的本职工作,同时也要审时度势,善于分析问题,然后再去解决问题

·我的观点(2005-09-21) [作 者] 邢建明 [公 司] 重庆城市投资集团-洲际酒店投资有限公司

他们能借到你们这只鸡,可见借鸡之人与你们的 CEO 关系非同一般,甚至有更高的政治背景,在这种状


况下,你既要做好现在的工作,(因为你也要靠这只鸡得到生存和发展)也要穿好防弹衣,注意自身安
全。如果认为我说的有道理,请发邮件与我交谈。

·无实权,如何有效进行控制?(2005-09-20) [作 者] 臧中波 [公 司] 深圳

我觉得天羽分析的很有道理,你现在的主要工作应该是沟通和风险控制,横向和纵向的沟通都很重要。
风险评估要时时警惕,做出正确判断。及时和领导沟通。

·同意梁桢的意见,还是定位为项目助理(2005-09-20) [作 者] 赵昊彤 [公 司] 北京用友软件


工程有限公司

第 171 页 共 756 页
第 1 章 综合管理

定位自己的同时,要针对技术总监是空降的特殊情况,尽量协助他做好工作;另外,由于你肯定对公
司的情况更熟悉,可能一些必要的管理性工作要由你来主动完成,同时照顾到技术总监的意见就可以
了。
当出现了重大分歧的时候,你必须要明确表明自己的意见;如果你确信自己的意见是对的,你也可以
考虑通过其它渠道进行反映,避免公司在运作这个项目的过程中遭受损失。

·这个时候不妨先做个责任分派矩阵(RAM) (2005-09-14) [作 者] bb [公 司] 北京监理咨询

这个时候不妨先做个责任分派矩阵(RAM)

·这个时候不妨先做个责任分派矩阵(RAM) (2005-09-14) [作 者] bb [公 司] 北京监理咨询

这个时候不妨先做个责任分派矩阵(RAM)

·权利 源于对过程的价值贡献(2005-09-12) [作 者] 天羽 [公 司] 林源教育

通过你的描述看到的是一个孵化项目,个人理解:老板为了利益外包或分包进来这个项目,可能是想
利用公司的人力、物力和一些技术人员的空档期来锻炼队伍,为拓展业务作准备,这样想,也是看到
你们空降的技术总监似乎很了解项目的背景和实施细节。
那么,你的任务就是纯项目经理的事务了:沟通+风险跟进。我想你肯定有着丰富的经验和应变的处
理手段,不然你的老板也不会让你担当此任。你现在最大的困惑是对风险的控制权,因为技术总监在
你的项目组里,而他又是这个项目资料和技术的唯一掌握者,对吧。
如果是这样,我告诉你一个简单的办法:
1. 把自己的项目经理的内容定位在纯管理层面,把技术总监看成技术经理
2. 与技术总监一起建立风险防范计划和工作流程
3. 与技术总监协同定义项目组的整体沟通计划
4. 把你看到的问题通过 2、3 进行内部控制,通过已明确的沟通渠道向高层通报

为什么这样作呢,道理更简单,我们的权利从生产过程中获得的,不是上级指派的,而权利的虚实大
小,与我们的行为对生产过程的增值的贡献成正比的。这一点要时刻保持清醒,所谓的控制力不等于
授权,权利是从过程赋予你的,目前建立好相应的规避风险的控制过程才是最最重要的,这样当你设
置的期望授权点被触发时,只要沟通渠道畅通,你就会被授权,或是权利人物会直接介入,不管何种
情况发生,你的终极角色都是执行人,所以,在现阶段不要考虑授权问题。

·权利 源于对过程的价值贡献(2005-09-12) [作 者] 天羽 [公 司] 林源教育

通过你的描述看到的是一个孵化项目,个人理解:老板为了利益外包或分包进来这个项目,可能是想

第 172 页 共 756 页
第 1 章 综合管理

利用公司的人力、物力和一些技术人员的空档期来锻炼队伍,为拓展业务作准备,这样想,也是看到
你们空降的技术总监似乎很了解项目的背景和实施细节。
那么,你的任务就是纯项目经理的事务了:沟通+风险跟进。我想你肯定有着丰富的经验和应变的处
理手段,不然你的老板也不会让你担当此任。你现在最大的困惑是对风险的控制权,因为技术总监在
你的项目组里,而他又是这个项目资料和技术的唯一掌握者,对吧。
如果是这样,我告诉你一个简单的办法:
1. 把自己的项目经理的内容定位在纯管理层面,把技术总监看成技术经理
2. 与技术总监一起建立风险防范计划和工作流程
3. 与技术总监协同定义项目组的整体沟通计划
4. 把你看到的问题通过 2、3 进行内部控制,通过已明确的沟通渠道向高层通报

为什么这样作呢,道理更简单,我们的权利从生产过程中获得的,不是上级指派的,而权利的虚实大
小,与我们的行为对生产过程的增值的贡献成正比的。这一点要时刻保持清醒,所谓的控制力不等于
授权,权利是从过程赋予你的,目前建立好相应的规避风险的控制过程才是最最重要的,这样当你设
置的期望授权点被触发时,只要沟通渠道畅通,你就会被授权,或是权利人物会直接介入,不管何种
情况发生,你的终极角色都是执行人,所以,在现阶段不要考虑授权问题。

1.20 如何对项目经理进行绩效考核?

如何对项目经理进行绩效考核?

[姓 名] lvqing [单 位] 山西太原 [邮 件] lvyongqing007@126.com


[所属行业] IT 软件 [所属主题] 项目综合管理 [发布时间] 2005-8-26

【案例正文】
我公司主营信息技术系统集成,一直没有一套对项目经理进行科学的绩效考核流程。
现在只是按照在项目计划阶段制定的项目进度表考核,而 95%的项目由于实施过程
中的不确定因素导致延期。请教诸位公司如何实行绩效考核?

【相关分析】

·guandian(2006-01-15) [作 者] 李冯 [公 司] BJG

"关于对项目经理的绩效考核,我认为以下几点.希望能对您有所帮助:
1:目标明确.

第 173 页 共 756 页
第 1 章 综合管理

项目在实施以前,各个计划的制定是否合理,(合理:主要是任务的划分是不是根据员工的实际情况来进
行)
计划制定完以后.有没有按照计划去实施.如果实际与计划有冲突,是不是有修改的建议和方案.如果计
划与实际推迟,那么是不是有合理的对应方针.
作为一个项目经理,首先把这一点应该明确.
2:过程中出现的问题是否有应对措施.
从项目的开始,到项目的结束.在这个过程中会存在很多异常,他是否有必要的应对的措施.这一点很重
要.如果遇到问题就手足无措,那么他不是一个合适的项目经理.
3:问题的协调性
在做项目的过程中,肯定会出现任务的划分不合理.以及个人的进度快慢不一致.那么遇到这样的情况.
是不是还按照计划执行,还是会适当的调整一下局部的计划呢.
4:每周的工作报告
每周都要做一个项目的进步,根据项目实际情况.计划和实际的差别.而这周的工作安排.等等.要尽量详
细.
以上几点,是我个人的一些建议,希望能对您有所帮助.
流程的制作,需要一个过程,要根据公司的实际情况,来制定. "

谢谢指教

·guandian(2006-01-15) [作 者] 李冯 [公 司] BJG

感谢提出此问题,正好我也不太明白,一并学习

·责、 权、 利 要均衡(2005-10-18) [作 者] 张晋虎 [公 司] 太原市市政工程总公司

首先前提是 责、 权、 利 要均衡。
有多大的责任就要有多大的权利,一个项目的成败有项目经理负责,那么这个项目经理就需要有权利
此项目的各个环节并且从公司利益出发制定出衡量利益的标准。
评定项目经理也要细分,尽可能量化。
从成本,进度,人员分配,计划和各项财务指标利润大小多角度出发,对项目和人员的协调掌控能力
等等给评价。

·考核项目经理和考核其他人员没有什么区别(2005-10-11) [作 者] 陈晨 [公 司] 电脑公司

首先前提是 责、 权、 利 要均衡。有多大的责任就要有多大的权利,一个项目的成败有项目经理负
责,那么这个项目经理就需要有权利此项目的各个环节并且从公司利益出发制定出衡量利益的标准。
评定项目经理也要细分,尽可能量化。从多角度出发,如楼上各位所说,从成本,进度,人员分配,
计划和理性,对项目和人员的协调掌控能力等等。

·如何对项目经理进行绩效考核?,(2005-10-11) [作 者] zhansir [公 司] kunmingligongdaxue

第 174 页 共 756 页
第 1 章 综合管理

其实对项目经理的绩效考核本来就挺难的,建议用挣值分析!

·还是有一些可以量化的(2005-10-02) [作 者] 牛小林 [公 司] 有空就来

考核项目经理的地方有一些地方是可以的:

1。项目的成本控制。在同样的实施过程中,成本的使用多少是有比较的。

2。风险的控制,风险的提前发现,提前控制能力。

3。计划的变更次数,和计划的准确度。

4。设计好的客户满意度调查表。

这些都是可以考核的。

·主要还是成败论英雄吧(2005-09-20) [作 者] 不公开 [公 司] 不公开

对项目经理的考核我觉得就基本等同于对项目的考核,当然存在很有水平的项目经理由于其它原因,
导致管理的项目最终失败。
但是,考核项目经理就应该把握住一点,项目由项目经理负责,考核项目经理,就是考核项目。

·会应变才能做好管理(2005-09-19) [作 者] 天羽 [公 司] 林源教育咨询

楼下说得对,不合理的地方就要纠正。

如果是任务划分错了,项目经理要被扣分,如果划分得过于笼统,就重新调整,调整情况录入公司知
识库风险部分。如果是用人不当,项目经理要被扣分,调整情况依旧录入公司知识库风险部分,同时
那个员工的个人能力评价也要被记录在人力资源部的资源档案中。

·doit(2005-09-14) [作 者] john [公 司] na

在做项目的过程中,肯定会出现任务的划分不合理.以及个人的进度快慢不一致.那么遇到这样的情
况.是不是还按照计划执行,还是会适当的调整一下局部的计划呢

·doit(2005-09-14) [作 者] john [公 司] na

第 175 页 共 756 页
第 1 章 综合管理

每周都要做一个项目的进步,根据项目实际情况.计划和实际的差别.而这周的工作安排.等等.要尽量
详细

·doit(2005-09-14) [作 者] john [公 司] na

从项目的开始,到项目的结束.在这个过程中会存在很多异常,他是否有必要的应对的措施.这一点很
重要.如果遇到问题就手足无措,那么他不是一个合适的项目经理

·业绩(2005-09-14) [作 者] john [公 司] na

项目经理每周、每月向监理或业主提交的工作计划和工作总结是最好的评价依据,但因项目经理长年
在外,公司内部往往不注意收集相关的资料和信息,从而导致对项目实施状况无法准确掌握,进而无
法考核!

·业绩(2005-09-14) [作 者] john [公 司] na

项目成绩
主动性
积极性
日志考勤成绩

·业绩(2005-09-14) [作 者] john [公 司] na

项目成绩
主动性
积极性
日志考勤成绩

·工作业绩考核(2005-09-14) [作 者] john [公 司] na

项目成绩
主动性
积极性

第 176 页 共 756 页
第 1 章 综合管理

日志考勤成绩

·考核树 3(2005-09-14) [作 者] jeff [公 司] 独立顾问

最后强调一点:真正的绩效考核系统对于公司是伤筋动骨的事情,最好有外面的咨询公司进行,否则
会对业务冲击很大。

·考核树 2(2005-09-14) [作 者] jeff [公 司] 信产部专家组

考核系统:市场,职能,技术
项目经理属于技术类
考核关系:被考核人:项目经理。主要考核者:部门经理。参与考核者:技术专家组。 审核者:分
管技术副总
考核结果:可以分为 ABCD 几等。

考核要点:信息技术人员都倾向于对时间估计过少。
公司现把过去的项目业务离散化,统计过去项目中的时间,离散最小单位的例子:登陆页面需要两个
人时。之后在进行工作评估。

·考核树(2005-09-14) [作 者] jeff [公 司] 独立顾问

的确,做过的人都知道,由于无法衡量原因,信息系统集成行业人员绩效十分难于考核!
一般作法是给出考核树,切分主要项目。
例如:业绩、态度、能力
考核过程:月例会,沟通承诺;月末,填写考核表,考核沟通。项目结束,填写考核表,考核沟通。

·定义工作流程(2005-09-10) [作 者] 天羽 [公 司] 林源教育

系统集成类的项目基本上是可以衡量的,过程中的问题从经验上看不外乎:到货时间、设备配置难度、
工程图纸变更、接入调试冲突等等。这些问题基本上都应会有第三方参与,尤其是上 million 的项目,
更会有诸如 IBM 级别的行业供应商加入,他们的工程师完全可以解决他们的问题,这里凸现的不确定
性,就是:Just-in-time 上的不确定性。

基本的方法是定义你的集成项目的实施流程,很简单,把项目计划上的工作制成逻辑 GANTT,对每个
活动进行权重定义,然后规定事件完成的三种状态:完成=1,带故障完成=0,延误=-1。然后进行
积分,就可以考核他们了。

第 177 页 共 756 页
第 1 章 综合管理

·细化指标的同时做到实事求是(2005-09-06) [作 者] 廖中宇 [公 司] gas

既然是做工程,就一定要把绩效考核与进度、质量、安全挂钩:
1、对于质量、安全,可以依据现场查证、监理报告、工程量清单、技术设计等进行评定;
2、对于进度,则要以进度计划为依据进行考核。一方面,要求项目经理制订可行的计划,考虑到天
气、资金、人员等各项因素,而且用词要求准确易于查证,“基本完成”等类似的词语不要出现;计
划一经确定,在考核期间是不可以变动的,到期查证,未完成计划的,必须说明原因,分清主客观因
素,同时还要考虑延迟对总进度计划的影响,影响大的,项目经理是否及时上报,对于出现的延迟是
否做出补救措施

·进度控制、质量控制、资金回笼(2005-09-02) [作 者] 舒劲松 [公 司] 中体同方体育科技有


限公司经营管理部

我认为:系统集成公司的项目经理基本上独立完成一个工程的实施,工作独立性大,因此考核应从“工
程实施计划”着手,即每分配给项目经理一个工程时,应由项目经理编制“工程实施计划”,根据计
划,明确关键的进度考核点,在考核点 1 周内,由项目经理提交相关报告,通过分析报告内容进行考
核和实施奖惩,对于因业主原因未达到进度要求的,可调整进度考核点;对项目经理原因未达到进度
要求的,可进行处罚,同时明确追赶进度的具体措施;根据计划,明确关键的资金考核点,每次向监
理、业主申请的工程量的底单应在公司备案,批复的工程量同样应备案,如此,根据备案已确定的工
程量和工程合同约定的付款方式,可对项目经理进行资金回笼的考核,按时回款的进行提成和奖励,
延期回款和回款金额少的可降低提成比例或适当惩罚;业主向公司提出的正式函件可作为项目经理工
作质量评价最重要的依据,因为业主投诉表明一定有某些工作未到位;项目经理每周、每月向监理或
业主提交的工作计划和工作总结是最好的评价依据,但因项目经理长年在外,公司内部往往不注意收
集相关的资料和信息,从而导致对项目实施状况无法准确掌握,进而无法考核!

·如何考核项目经理(2005-08-31) [作 者] 李继续 [公 司] 银河公司

我认为:根据目标进行考核,是最合理和公正的。所以制定目标必须切实可行,考虑到一切可能发生
的情况。

·如何考核项目经理(2005-08-31) [作 者] 李继续 [公 司] 银河公司

我认为:根据目标进行考核,是最合理和公正的。所以制定目标必须切实可行,考虑到一切可能发生
的情况。

·进度控制(2005-08-29) [作 者] derikwoo [公 司] psi

第 178 页 共 756 页
第 1 章 综合管理

现在看来,问题在于项目初期范围定的不准,资源配置可能不合理,没有进行及时、定期的进度控制,
应首先建立定期报告制度,在现在实际进度恶化的情况下,报告周期要定的短一些,然后认真调查现
在的工程状态,包括进度,成本等的情况,和基准计划进行比较,找出恶化的工作包,真对恶化情况
分析,重新配置资源,制定工作包计划,争取控制项目

·如何对项目经理进行绩效考核?(2005-08-28) [作 者] 袁月建 [公 司] 软件公司

关于对项目经理的绩效考核,我认为以下几点.希望能对您有所帮助:
1:目标明确.
项目在实施以前,各个计划的制定是否合理,(合理:主要是任务的划分是不是根据员工的实际情况来
进行)
计划制定完以后.有没有按照计划去实施.如果实际与计划有冲突,是不是有修改的建议和方案.如果
计划与实际推迟,那么是不是有合理的对应方针.
作为一个项目经理,首先把这一点应该明确.
2:过程中出现的问题是否有应对措施.
从项目的开始,到项目的结束.在这个过程中会存在很多异常,他是否有必要的应对的措施.这一点很
重要.如果遇到问题就手足无措,那么他不是一个合适的项目经理.
3:问题的协调性
在做项目的过程中,肯定会出现任务的划分不合理.以及个人的进度快慢不一致.那么遇到这样的情
况.是不是还按照计划执行,还是会适当的调整一下局部的计划呢.
4:每周的工作报告
每周都要做一个项目的进步,根据项目实际情况.计划和实际的差别.而这周的工作安排.等等.要尽量
详细.
以上几点,是我个人的一些建议,希望能对您有所帮助.
流程的制作,需要一个过程,要根据公司的实际情况,来制定.

1.21 如何制定切实可行的项目计划?

如何制定切实可行的项目计划?

[姓 名] 张容 [单 位] 不公开 [邮 件] chengr@fiberhome.com.cn
[所属行业] 通信与网络 [所属主题] 项目综合管理 [发布时间] 2005-8-15

【案例正文】
我所从事的是一通信公司研发项目管理工作,主要是对公司所有项目进行管理,当

第 179 页 共 756 页
第 1 章 综合管理

然不是象项目经理那样管理到位,我想知道,项目经理在制定项目计划的时候,应
该怎样做?因为我感觉目前手中的项目计划很难做到过程控制,在进度跟踪中没有
明确的考核标准,项目计划有点形同虚设,希望各位大师不吝指教!

【相关分析】

·齐心协力(2008-07-04) [作 者] bjsun [公 司] 日本外包软件

制定计划的确是门学问,关键是切实可行。所以计划必须是成员都参与制定,最后由 pm 拍板的,这
样遇到问题,大家才能一起齐心努力。

·一点经验(2007-11-16) [作 者] 郭林海 [公 司] neusoft

制定切实可行的项目计划可不是一天两天能做到的,是靠公司组织的管理成熟度决定的.所以制定项目
计划的水平要跟公司的现状结合起来,如果公司还处于 CMMI1 的水平,项目只策划到里程碑并识别关
键路径就好了;如果公司还处于 CMMI2 的水平,就可更近一步完成沟通管理\质量管理\供应商管理等
内容计划.
另外如果项目周期较长,客户无法明确需求以及组织无法确认资源投入的时候,建议只详细策划最近的
里程碑工作.

·131(2007-09-18) [作 者] 松 [公 司] 天啊

李强是 A 公司的项目经理,其管理风格非常严厉。他要求团队成员严格遵循他的指示,强调使用正
式和非正式的控制方法,两年前在他被任命为项目经理时,很多人感到不满。在他任项目经理的前半
年中,14 个工地管理、工程和技术人员中有 8 个相继转到公司别的项目组或离开公司,而正当 A 公
司老板想调走李强的时候,紧张的局势得到了缓解,项目组中留下来的人及李强任命的人都接受了他
的领导方式。

在李强任期中,他成功地将项目建设成本减少了 10%,其进度也达到了项目管理分部主管、客户
和建筑师的要求,他对项目的管理紧张而有效,后来被另外一家公司相中,随后就跳了过去。

A 公司老板准备在项目组中提拔一个项目经理,但他发现没有人是李强的助手或可替代的人,后
来,老板安排首席测量员陈刚来担任项目经理。

·可以找一些 500 强的模板参考(2007-07-20) [作 者] charline [公 司] itt

你可以找一些 500 强的模板参考,那些代表着在这类行业中的楷模,


经验比较成熟,可适当的添加或双减,

你可上 TS16949 网,有很多汽车产品开发的案例,特别详细.....


你可以找一些 500 强的模板参考,那些代表着在这类行业中的楷模,

第 180 页 共 756 页
第 1 章 综合管理

经验比较成熟,可适当的添加或双减,

你可上 TS16949 网,有很多汽车产品开发的案例,特别详细.....

·项目计划(2007-07-10) [作 者] 谢凯荣 [公 司] 科瑞康

我也是与你一样从事研发项目管理工作.公司很多项目进度都会与计划相差很大,在工作中,我总结了
主要影响项目进度的因素:1、是需求的频繁更改。所以在计划前期必须做好有效的需求分析。2、是
人员多项目的参与工作。所以在做计划时,一定要考虑资源的工作是很过满。还要考虑一些临时任务
的加入。

当然,项目计划变更是不可避免的,特别是研发项目,我们只能尽可能去减少项目的变更。

·如何制定切实可行的项目计划?(2007-04-25) [作 者] willliam zhou [公 司] tju

建议定期查看具体项目经理的阶段报告和工期总结,最好把各个工作包的进度情况汇总到项目经理
处,分析后,列出未完成的项目进度,和与基准计划的比较分析,细化报告的内容更容易及时发现进
度恶化,进行控制 首先要细心地与每个子项目的经理们研究确定各个子项目的阶段性里程碑,事项、
时间、资源支持、质量要求、责任人、等等。然后综合项目群的所有里程碑,找出与你所在层次或级
别相关工作的关联,排出轻重缓急和相互关系。

·我的建议(2007-01-31) [作 者] zhangmin [公 司] 北京东方飞扬软件技术有限责任公司

项目计划的制定要细化,但再好的项目计划,总是会变更的,还需要对项目计划的执行和变更进行控
制。
1、把握项目的范围;
2、将项目的内容进行分解,达到可控制的程度;
3、与用户进行协商,确认项目的计划;
4、确保项目需要的各种资源。

·工艺审核(2006-12-11) [作 者] li-hongcai [公 司] 北京连创

我同意几位楼主的观点,个人感觉这个职业在中国还属于摸索阶段,也没有几个项目能把进度表
持续的维持下来.我认为计划固然必须有,但漂亮的计划看不到任何实质性的问题,如果开发工艺有
问题,计划早晚会变一堆废支.
我的想法是找几位技术经验相当丰富的人员去审核项目,确认项目在结构上,工艺上的问题.才
是真能控制的了进度.

第 181 页 共 756 页
第 1 章 综合管理

·如何制定切实可行的项目计划?(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

首先要细心地与每个子项目的经理们研究确定各个子项目的阶段性里程碑,事项、时间、资源支持、
质量要求、责任人、等等。然后综合项目群的所有里程碑,找出与你所在层次或级别相关工作的关联,
排出轻重缓急和相互关系。

·如何制定切实可行的项目计划?(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

在整个过程中,要统计以往变更情况,作好心理准备,避免过大过多变更,从而避免计划的反复变更,
保证其切实可行。这点是很重要的。

·如何制定切实可行的项目计划?(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

个人感觉这个职业在中国还属于摸索阶段,与各个项目经理之间的关系以及与公司管理层的关系都比
较难处理,

·如何制定切实可行的项目计划?(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

建议定期查看具体项目经理的阶段报告和工期总结,最好把各个工作包的进度情况汇总到项目经理
处,分析后,列出未完成的项目进度,和与基准计划的比较分析,细化报告的内容更容易及时发现进
度恶化,进行控制

·知人善用(2005-11-09) [作 者] 彬彬 [公 司] 仍然

每一个人都有他所擅长的,要想有好的进程也就需要给每个人量身定做他所适合的工作,才可以加快
进程。
你们好,我刚刚进入这个网站,希望大家多多帮助。

·主要是计划(2005-09-14) [作 者] 邱爱华 [公 司] Buaa

你的工作主要是计划,但希望也不要仅仅认为自己就是制定计划。
1、制定计划,要考虑计划是否具有可执行性。
2、检查没有产生执行力的计划与相关人员。
3、分析原因,调整计划,形成自己的制定计划的原则。

第 182 页 共 756 页
第 1 章 综合管理

·由上至下(2005-09-14) [作 者] 铆钉山 [公 司] 山西电网

讨论项目计划可以采取由上至下的方式。先划分项目的几个阶段,明确各阶段的目标,然后再细化

·分解任务(2005-09-14) [作 者] peter [公 司] qq.com

分解任务,达到对过程的控制,同时,分解目标,达到可考核的目的

·mudi(2005-09-14) [作 者] mike [公 司] quanso.com

每一个项目都有它的目标,制定项目计划就是围绕它的目标展开的.我个人认为,制定项目计划应该先
确定项目的各个里程碑.根据里程碑的先后顺序来制定项目计划:近的,就做详细的计划(包括项目人
员 资金的具体分配);远一点的,项目计划就只是做一个大概,因为变化快于计划,我们要根据变化不
断的改变计划.所以不必在最初的时候把所有的内容都详细规划好,留点余地我们可以更好的变通.把
目标完成的更好嘛!

·项目计划用以指导(2005-09-14) [作 者] killer [公 司] to8848

项目计划用以指导、监控项目的实施。
2、没有计划或者计划的质量差导致项目实施的随意性很大,导致项目的各个方面失去控制。
3、计划是项目的各项管理工作的水之源,源头的优劣决定了项目实施的质量。

·里程碑要点(2005-09-14) [作 者] jeff [公 司] 独立顾问

如果是以工作量为主的计划,几个事实供参考。
1、美国路线历程碑以业务为主,用户满意。
2、欧洲路线里程碑以时间为主,技术人员满意。
3、部分公司以技术为主,研发人员满意。
4、研发项目多以工作量为主,项目经理满意。

建议:以特性(Features)为主里程碑.

·先分清计划包括什么?(2005-09-14) [作 者] jeff [公 司] 独立顾问

项目计划有:进度计划,范围计划,人员计划,质量计划,风险计划等,不知道你具体说的是那个计

第 183 页 共 756 页
第 1 章 综合管理

划还是所有计划。
只提醒一点是:项目经理不负责创建详细的项目计划!

·计划不是永远不变的!!!(2005-09-12) [作 者] zjw2005 [公 司] qn

要想使项目成功,必须有良好的计划。特别是在复杂的大项目中。
有以下几点需要注意:
1、项目计划制定要有很好的依据,切实可行。
2、项目计划制定的同时,要做好项目预测和分析,这个作用就是纠偏用的。因为实际项目实施都是
在计划的基准线附近摆动。
3、注意项目中的变更问题,分成三个等级:领导级处理和确定范围的变更;项目经理处理项目中的
“例外事情”;项目实施人员处理实施过程中的小问题。

这样把遇到问题的接受人,确定下来后,就可以得到很好的控制。就可以按照计划基准线实施。

作为 PMO,就是要检查各个项目实施中的里程碑计划,如果有偏差,必须有反映。但是不要管得太细,
否则你就会左右下面的人做事。

·项目进度控制(2005-09-11) [作 者] 刘卫平 [公 司] 上海友胜计算机技术有限公司杭州技术


开发中心

有效控制进度依赖项目经理的个人能力(包括管理技能和技术技能)、核心技术人员的能力发挥程度
等,需要在多个方面进行管理:
1、合理设置 WBS(工作分解结构):行业知识和经验的体现;
2、范围管理,尤其是变更管理、版本管理;
3、成员沟通:人际技能的体现;
4、项目生命周期管理:本人愚见,瀑布型的计划一般来说是行不通的,就犹如初学 PCB 的工程师,
电源和地线都用自动不线!请参考其它模型;
5、获取上级领导支持:及时通报项目进度、反应异常情况;

·群组管理要务实(2005-09-10) [作 者] 天羽 [公 司] 林源教育

我理解仁兄的任务是:管理所有项目,也就是理论上讲的管理项目群组,这个职能有点儿像 PMO,项
目管理办公室。

你可以从网上下载一些文章,就知道应该怎么写你的项目管理计划了。

·计划与监控并举(2005-09-06) [作 者] sandywd [公 司] 上海锦富精密塑胶器材有限公司

第 184 页 共 756 页
第 1 章 综合管理

项目一旦开始进行,就要做好全程监控工作,定期比较实际进程和计划进程有何差异,如发现实际进
程落后于进度计划,就应该立即采取纠正措施。

·个人观点(2005-09-04) [作 者] 韦少才 [公 司] 桂林空军学院 7053

每一个项目都有它的目标,制定项目计划就是围绕它的目标展开的.我个人认为,制定项目计划应该先
确定项目的各个里程碑.根据里程碑的先后顺序来制定项目计划:近的,就做详细的计划(包括项目人
员 资金的具体分配);远一点的,项目计划就只是做一个大概,因为变化快于计划,我们要根据变化不
断的改变计划.所以不必在最初的时候把所有的内容都详细规划好,留点余地我们可以更好的变通.把
目标完成的更好嘛!

·再谈制定切实可行的计划(2005-09-01) [作 者] 李继续 [公 司] 银河公司

专家访谈里的一段话,但愿有帮助:
要有一个合理的进度计划。我们有的项目经理在制定进度的时候很草率,没有认真地分解工作任务,
任务分解不细,对工期的估计就会不准确。或者,有时候为了迎合老板的需求,或者客户的需求,制
定明知不合理的进度安排。所以,在计划阶段要下功夫做一个合理的进度计划。并且要进行正式的审
批并发布,因为计划是一件很严肃的事情。如果涉及到外部客户的项目,还要与客户达成一致,让客
户批准进度计划。这样可以对大家都形成约束。
所以我建议:分解任务,达到对过程的控制,同时,分解目标,达到可考核的目的。

·项目计划是项目执行的基本、首要因素(2005-09-01) [作 者] 张兴伟 [公 司] 单独

1、项目计划用以指导、监控项目的实施。
2、没有计划或者计划的质量差导致项目实施的随意性很大,导致项目的各个方面失去控制。
3、计划是项目的各项管理工作的水之源,源头的优劣决定了项目实施的质量。
4、首先明确项目的实施目标,项目是以目标为导向的,让团队成员明确项目目标和各自的工作目标,
有的放矢。
5、跟项目干系人充分沟通、交流,平衡干系人的利益,使大家参与到项目实施中来,让对项目不利
的因素尽量努力朝着有利的方向发展。
6、八仙过海,各显神通。充分调动大家的参与的积极性,发挥大家的聪明才智,因为项目初期,团
队成员的积极性是很高的,然大家对项目计划提出自己的建议,从而达成共识。
7、讨论计划的备选方案。
8、讨论项目计划可以采取由上至下的方式。先划分项目的几个阶段,明确各阶段的目标,然后再细
化。
9、要考虑客户、公司的组织结构,保证关键资源合理安排在你的项目中。

·计划还要有检查(2005-09-01) [作 者] 文宏伟 [公 司] 黑龙江省通信建设监理有限公司

第 185 页 共 756 页
第 1 章 综合管理

你的工作主要是计划,但希望也不要仅仅认为自己就是制定计划。
1、制定计划,要考虑计划是否具有可执行性。
2、检查没有产生执行力的计划与相关人员。
3、分析原因,调整计划,形成自己的制定计划的原则。

·同意王坚,变更控制决定一切(2005-09-01) [作 者] 李继续 [公 司] 银河公司

我认为大家的分析都很有道理,王坚的变更理论更有特色。
总结以下:
1、制定切实可行的目标,这是前提;
2、根据目标制定计划,计划要分阶段,而且可分解到人;(这样便于控制)
3、让实施人员根据工作实际提出意见,调整计划;(提前预测变更,防止中途变更过多,而且提前
沟通,让大家都对计划心中有数,并且达到一致认同)
4、启动计划,随时对比原计划与现实实行过程,及时发现偏离计划的情况,便于再次变更或调整计
划;(执行中务必上级监督,下级反馈,并且分阶段总结分析)
无论制定或调整计划,都是为了保证目标的实现,一定要牢记这个目标。一切为了这个目标而服务,
万不可为了制定计划而制定计划。
另,在整个过程中,要统计以往变更情况,作好心理准备,避免过大过多变更,从而避免计划的反复
变更,保证其切实可行。这点是很重要的。

我是西安交通大学的 MBA,目前已经进入了论文阶段,准备写项目管理方面,近来发现了这个网站,
真是太好了。我还在搜索项目管理方面的资料,有哪位能够提供好的资料、网站或建议给我,将不胜
感激。我的 MSN:happyreality@163.net

·苦做计划(2005-08-31) [作 者] 陈军辉 [公 司] 东北农业大学

还是目标控制。先把任务分解,并制定里程碑计划,分阶段制定目标计划,分阶段验收成果。对验收
结果进行客观分析后评价

·关键在过程管理(2005-08-31) [作 者] 一孑 [公 司] 一孑工作室

从制定计划而言,应该不难,但要合理,难的是按照计划执行。
沟通本身是一种监控。
合理变更又是计划维护的一部分。
风险管理又是保障计划可执行的必不可少的部分。
里程碑的设置既要合理又要兼顾团队的状态及能力。
如果是公司历史不长,要更多的利用团队资源。如果是一家成熟的公司,更多的利用公司沉淀的管理
经验。

第 186 页 共 756 页
第 1 章 综合管理

·责任制落实到人(2005-08-29) [作 者] sandywd [公 司] 上海锦富精密塑胶器材有限公司

制定项目计划时,要注意各个职能部门的权责落实到各个责任人,在项目进行的同时,阶段性的报告
制度是控制项目进程的关键,项目经理应对各个阶段报告进行分析总结,做到有问题及时解决。

·细化控制(2005-08-29) [作 者] derikwoo [公 司] PSI

建议定期查看具体项目经理的阶段报告和工期总结,最好把各个工作包的进度情况汇总到项目经理
处,分析后,列出未完成的项目进度,和与基准计划的比较分析,细化报告的内容更容易及时发现进
度恶化,进行控制

·项目计划制定需要对工作量详细评估(2005-08-21) [作 者] 段丽娟 [公 司] 京软科技

如果你做过的项目多,有丰富的经验,而且你对合同以及设计都了如执掌,那估算工作量就会变得轻
松多了!

还需要对项目中的技术难点进行特殊估算!

我们公司一般是项目经理对工作量进行估算,然后提交给技术总负责人评估,如果项目太大的话,需
要更上级的领导一起参与评估!

·也需要沟通(2005-08-20) [作 者] bankick [公 司] 西安

看到大家从各个层面对这个问题进行了分析,确实是高明。
但是在项目管理中,我们面对的不仅仅是资源的问题,也不单纯是权限的问题,我们还面对沟通的问
题,因为有项目管理制度的企业的管理往往比职能式的管理组织更加复杂,那么这里面沟通就显得尤
为重要,如果你想把管理过程很好的控制,沟通则是必不可少的,而且必须是有效的沟通。

·一个字,难!(2005-08-20) [作 者] 曹垣亮 [公 司] 北京普天银河通科技公司

同感,难!

·同感(2005-08-19) [作 者] stephnys [公 司] SZXXX

我现在做的和你的状况差不多.个人感觉这个职业在中国还属于摸索阶段,与各个项目经理之间的关
系以及与公司管理层的关系都比较难处理,尤其是涉及权力和流程的时候.个人感觉很重要的几点:1)

第 187 页 共 756 页
第 1 章 综合管理

持之以恒,不要因为有反对意见就放弃;2)向项目经理显示你正在帮助他而且行之有效;3)提高自己的
管理水平,不从具体技术下手而是从流程和效率着手.

有机会大家可以多交流交流.
Email: steph_yang@tom.com
Yahoo Messenger: nysic812@yahoo.com

·同感(2005-08-19) [作 者] stephnys [公 司] SZXXX

我现在做的和你的状况差不多.个人感觉这个职业在中国还属于摸索阶段,与各个项目经理之间的关
系以及与公司管理层的关系都比较难处理,尤其是涉及权力和流程的时候.个人感觉很重要的几点:1)
持之以恒,不要因为有反对意见就放弃;2)向项目经理显示你正在帮助他而且行之有效;3)提高自己的
管理水平,不从具体技术下手而是从流程和效率着手.

有机会大家可以多交流交流.
Email: steph_yang@tom.com
Yahoo Messenger: nysic812@yahoo.com

·如何制定切实可行的项目计划?(2005-08-18) [作 者] ddd [公 司] ddd

根据我的体会,有如下的看法:
1.将项目分成若干的小项目,由开发部门的相应工程设计人员跟进,确定各自的任务目标,定期进行检
查监控,了解各个项目的进展情况.
2.定期或不定期的进行交流沟通,掌握下属的工作动态,有策略的提醒各相关人员的工作情况.
3.做好项目的计划是项目成功的关键.

·要定期review schedule(2005-08-18) [作 者] 杨松城 [公 司] HAHA

刚开始计划不可能很完美,因为在执行过程中会有很多意想不到的事情会出现。我的体会是,分解项
目成小项目,然后在小项目上安排好要交付的结果和时间及责任人。剩下来就是提前 review,象王
坚所说那样,变更管理到位。目标就有希望了。

·我对项目计划的制定的看法(2005-08-18) [作 者] 张盛 [公 司] 华讯网络

根据我对参与的项目实施前后的经验,我想说几点,希望能对您有所帮助。
1、首先我想我们都会认同在项目实施过程中不可能完全地按照我们制定地项目计划一分不差地执行
完毕,项目计划必然会由于各种原因产生项目计划地变更。

第 188 页 共 756 页
第 1 章 综合管理

2、在制定一个合理的项目计划之前,我想您需要做比较充分的项目前期调研,包括对客户需求的尽
量准确的把握、对于您的项目组成员的个人能力、技术能力的把握以及您能够掌握的公司内其他资源
的调动能力的掌握。
3、如果您在一开始制定了计划,但是自己没有盯着这个计划执行或者您的项目组成员在实施时对您
的这个项目计划的没有很好的把握,并且在实施过程中您没有持续的对您的项目计划做必要的更新,
那么您的项目计划就真的会变的形同虚设了。因此您需要去避免出现我以上描述的几个问题。
4、至于您提到的考核标准,这个我认为还是贵公司内部是否有相关的制度来让您能有效的管理监督
您的项目组成员的工作情况。
以上是我的几点拙见,希望能对您有所帮助

·变更决定一切(2005-08-18) [作 者] 王坚 [公 司] 武汉环大科技开发有限公司

我在单位从事项目经理工作,多年来,发现项目计划无法兑现的最大原因是没有良好的

变更管理。一般,我们总在说“计划没有变化快”,制定再好的项目计划一到实践过程中,没有几天
就会被各种各样的变更所打乱。因此,没有良好的变更控制,一切项目计划都是空谈。我结合自己的
管理经验谈谈如何管理好项目计划。

第一,首先要控制住变更。要控制变更先要统计变更,在开始的时候我们不需要做很详细的项目计划,
而主要是依赖一个比较弱的任务分解提交的一个工作流系统。将每个步骤的责任人完成任务后进行状
态提交,将中途产生的变更作为一个新的任务添加到新的工作流中去。经过长时间的资料汇总统计,
可以得到一个人平均完成一个工作所需的时间、一个任务完成所需的时间、以及在一个项目中产生多
少个变更等具体数据。这些数据可以用作绩效考核,和质量评审的定量依据。

第二,经过长时间的变更管理之后,我们可以求出项目管理中的变更与项目计划存在差异的比例。这
样我们就可以比较接近实际的制定一个项目计划。通过变更核算可以适当将任务时长进行改变。

第三,同时结合变更管理系统,将每日的计划进行调整每天时进行跟踪,修改项目计划并调整前锋线。
这样,里程碑会随着你的项目进度变得越来越确定。当你有了 20 个项目的统计数据后,项目你就基
本上可以控制了。

·超越项目管理(2005-08-17) [作 者] 曹垣亮 [公 司] 北京普天银河通科技公司

你所在的岗位,需要用超越项目管理的思路来做。第一步你要比 PM 高,人家才能服你。所以许多企
业的项目管理办公室在有用与无用之间摆动。第二你的智慧,中国式的智慧。分析 PM 与 PM 团队、组
织的情况。

·项目运营质量小组的成立(2005-08-17) [作 者] sam [公 司] 保密

第 189 页 共 756 页
第 1 章 综合管理

在大公司而言,一个好的组织架构,不仅有纯项目线的支持,同时更需要公共线的支持,像项目执行
计划、项目执行质量、项目管理的监控和相应工作,完全可纳入一个项目质量小组,项目质量小组监
控所有项目组的工作流程,审核重大项目的执行情况,监督项目管理的质量工作,还有就是事件(超
出计划的事情)和问题(重复的事件)管理的执行情况,因为不同的项目线虽然有不同的业务,但对
于公司而言,有些项目线是共用一个平台的,运维和系统工程师解决的出发点往往是平台本身的,从
项目方面来优化和更新这些共用平台,就是项目质量小组的事情了,这样才可从出发点开始就统一大
家对于基础事务的工作共识。同样可对该项目质量小组做相应考核,主要考核指标可以为:项目质量
问题解决完成率或其他。人员组成方面,由每个项目线抽调一人做组员支持,组长可由你兼任,顾问
由你的老板或者更高级人员担任。

·公司PMO的角色(2005-08-16) [作 者] jameson [公 司] 中国软件集团

其实你提到的问题是公司 PMO 如何管理公司所有项目,我在公司也是这个角色,谈几点体会:


1、建立项目经理考核机制
2、每周汇总公司各项目状态报告,及时掌握各项目进展情况
3、公司的 PMO 要有资源分配权利,协调公司各项目人员
4、了解公司市场情况,及时为即将启动的项目,留好备用人员
5、对于多个项目,共用公司核心产品和通用组件,减少重复开发

总之公司 PMO 除了培训,制定公司项目管理规范外,还要对公司市场,技术,人员进行全面了解,这


样公司的所有项目才能统一协调。

·松散项目群的里程碑管理(2005-08-16) [作 者] 李大明 [公 司] WSP Shenghai

对较高级别或层次的项目管理人员来说,所谓项目管理往往是对比较松散的项目群进行管理,不能照
办一般项目经理的做法。我个人的体会是,首先要细心地与每个子项目的经理们研究确定各个子项目
的阶段性里程碑,事项、时间、资源支持、质量要求、责任人、等等。然后综合项目群的所有里程碑,
找出与你所在层次或级别相关工作的关联,排出轻重缓急和相互关系。你,作为松散项目群的项目经
理,就对这些项目管理节点和里程碑进行项目管理!我称之为:项目群的项目管理。

·我的不成熟看法(2005-08-15) [作 者] 曲文一 [公 司] 吉林大学

你的问题似乎项目经理没有认真制订项目计划,按道理来讲,项目计划制定的比较合理的话,其 WBS
结构应该粗细适中,而且每个工作任务都有可交付成果(对软件项目不适用)或是检查标准,不过要是
分得太粗了,就没法达到这一点了。

·Objective Management(2005-08-15) [作 者] Jonathan [公 司] 不公开

第 190 页 共 756 页
第 1 章 综合管理

我觉得制定计划有三点注意:
1、明确目标。只有这样才能将目标分解,然后根据时间、资源、成本制定计划;
2、计划可以按阶段实施,每个阶段都需要里程碑,并事先计划在里程碑时需要的交付物,在实施的
时候,就可以依据交付物来评估进度、质量及个人的 Performance 了;
3、计划最好是能参考具体实施人员的意见。

·Proactive, NOT Reactive(2005-08-15) [作 者] howard_hong [公 司] 上海普华

计划的制定一定要解决计划的可执行性问题,否则计划就会失去指导意义。具有很好可执行性的计划
在执行前,要解决计划执行的严肃性问题。所以我们项目提倡面向执行的计划管理方法,只有解决了
计划的可执行性问题,才能对实际项目工作安排启到指导和控制的作用。

Proactive, NOT Reactive 是多项目管理者的考验。

1.22 亲身经历的一个失败的通信集成项目- 请大家给与分析

亲身经历的一个失败的通信集成项目- 请大家给与分析

[姓 名] steven zhang [单 位] 暂不公布 [邮 件] hzshuo@etang.com


[所属行业] 通信与网络 [所属主题] 项目综合管理 [发布时间] 2005-4-11

【案例正文】
为某省某运营商建立一个业务平台,并采用合作分成的方式。也就是说所有的投资由我方负
担,平台投入商用之后运营商所收取的收入按照一定的比例跟我们作分成。
同一时间,平台有两个厂家一起进行建设,设备以及技术均独立,也就是说同时有两个平台
提供同一种服务,两个平台分别负责不同类型的用户。
但是整个项目进行了 10 个月,并经历了一个月试用期之后。准备商用的第一天,运营商在没
有任何通知的情况下,将所有用户转到了我们竞争对手的平台上去,也就是停止使用我们的
平台。
整个项目投资超过两百万,包括软、硬件以及各种集成、支持、差旅费用等等。现在我们所
有的设备被搁置但不能搬走,并没有被遗弃,运营商口头声称还会履行合同,按照原来的分
成比例给我们收入。但是我们无法得知每个月的使用情况、用户多少,所以根本无法知道我
们究竟应该拿到多少分成。所以,运营商的口头承诺根本如同鸡肋。
在出事当天,项目经理呆若木鸡。

第 191 页 共 756 页
第 1 章 综合管理

抛开别的因素不说,我想大家能不能给我一点启发:
1.从项目管理的九大知识体系来讲,我们能不能避免这样的事情发生?
2.出这样的事情,项目经理有没有责任?
3.对于‘合作分成’这样的平台建设方式,项目本身有什么样的特点?

【相关分析】

·案例点评!(2008-02-02) [作 者] 正南方 [公 司] 捷普电子

从项目管理的知识体系来看。。该项目没有做好几项工作:首先是沟通上存在问题。即签订项目协议
的时候合同上没有表示清楚双方必须履行的职责!由此又可以看出此项目在风险管理上存在很大的漏
洞。明知有竞争对手也参与此项目,项目经理却视而不见...可见项目经理在商业运作上的稚嫩。

完全赞同 张彤 的观点!

·失败通信系统集成项目(2007-11-21) [作 者] fu yongtang [公 司] HUAWEI

风险控制上,首先分成是信产部所不准的,立项论证上,是否充分认识到竞争者带来风险,也可能先
前依靠人发生变化,此一时彼一时也,我们太倚重人的因素了,对于合同重视程度不够。

·项目的可行性分析不够细致全面(2007-11-19) [作 者] 刘海艳 [公 司] yf

邹鸟学习中:
1.项目可行性分析过程中,要有充分的调研和分析.头脑风暴法听取多方意见.尤其是悲观派的想法不无
道理.把他们的想法作为风险来预防.
2.合作运营,就要明白对方的运营方式,对自己无法控制的领域要做好充分的风险分析.

·沟通管理(2007-05-17) [作 者] 孙毅 [公 司] 奥光通信

运营商的水是比较深的,如果从 9 大体系中,只能说你的风险管理、沟通管理上面出现问题,特别是
沟通管理。可以肯定的是你的对手的关系比你硬,对于出现此类项目首先搞定的是人,因为此类项目
在技术上的风险不大,关键风险在沟通管理上。还有就是在运作项目时,和利益相关的内容必须采用
合同方式体现,不能口头承诺。
在本项目开始阶段,当得知两个公司进行一个项目执行时,就应该明确的感觉到运营商的意图和想法。
同时在施工过程和甲方的沟通过程中对于甲方的态度变化必须明确察觉。关键人物必须重点攻关,最
好可以签下类似的协议,保证以后的收入。
危机应对,在出现此类问题以后,只有一条路就是当孙子,和运营商签订更加忍让的协议,签订新的
合同,从新进行项目攻关,保证公司可以收回成本。

·风险管理要增强(2005-09-12) [作 者] caoyue [公 司] 不

第 192 页 共 756 页
第 1 章 综合管理

这个事情的发生显然是在项目进程中没有对风险进行很好的管理.与运营商的合作权利业务应通过合
同明确将风险减到最低

·万恶源于源(2005-05-23) [作 者] 李福田 [公 司] 广西财经学院

其实项目本身就有问题。第一、既然是有竞争,项目经理就应该做好项目可行性研究分析。第二、风
险管理上没做好,作为一个大型、复杂、耗时较长的项目,风险管理做的好,企业自然没烦恼。第三、

合同管理也没做好!文字文字文字

·亲身经历的一个失败的通信集成项目(2005-05-20) [作 者] Alam [公 司] 澳門紡織集團

我觉得项目的过程本身到是没有什么明显的失败之出,之所以造成这样的结果是由于项目合同上没有
明确的列明双放需要履行的合同条款,而只是采取口头承诺的形式.这只能说明管理者的商业经验不
足,没有足够的法律意识.但是如果可以找到口头承诺的证据的话到也不是没有办法的,毕竟在法律上
口头承诺也是成立的.只要有足够的证据就可以要求对方履行承诺.

·项目目标没有充分定义(2005-05-15) [作 者] E.T. [公 司] N/A

从案例的情况来看,该项目经理未能全面地对项目目标进行评估。

事实上,该项目经理在项目启动之时就已经非常清楚同时有两家人在提供相同功能的平台,因此该项
目经理就应该很清楚“一山难容二虎”的道理,没有任何一家运营商会将自己的客户拆成两部分,分
在两个平台上管理的。从这个角度出发,如果把竞争对手的因素当成风险因素还是不够充分的。

此时,项目经理对于项目目标的定义就不能只停留在安装完成设备、按合同履行职责这样的层次上,
而是要定义在打败竞争对手,独占用户的高度上。这个目标才是与自己企业及用户的目标相一致的。

·风险控制(2005-05-14) [作 者] yk abc [公 司] boco

控制不严格
沟通不畅通
信息收集不全

造成严重后果

第 193 页 共 756 页
第 1 章 综合管理

·亲身经历的一个失败的通信集成项目- 请大家给与分析(2005-05-11) [作 者] 李洪亮 [公


司] 中太数据

合作分成?这可以定义成一个项目吗?不也是运营性质吗?
或者可以把前期建设看作一个项目,毕竟它有明确的可交付物,
如果可交付物即系统本身有问题,那是 pm 的责任,可案例并没有这方面的说明哦.所以,个人认为可以
认定的是合同执行中出现了偏差,但说到 PM 的责任好像有点证据不够充分吧.

·项目管理在竞争中生存(2005-05-10) [作 者] 王飞 [公 司] 西安工业学院

我是一个初步介入项目管理的项目人,此案例提醒大家完善自己才不会被淘汰和抛弃

·项目管理在竞争中生存(2005-05-10) [作 者] 王飞 [公 司] 西安工业学院

我是一个初步介入项目管理的项目人,此案例提醒大家完善自己才不会被淘汰和抛弃

·失敗的項目(2005-05-10) [作 者] david [公 司] MITAC

失敗的項目
貴公司為运营方建立的業務平台這個項目﹐目的是贏利﹐既然运营方沒有使用你們所使用的平台。就
說明是一個失敗的項目。首先﹐技朮上有差異﹔其次﹐PM 未能全面掌控整個項目。

·摆正自己的“角色”(2005-05-02) [作 者] 张彤 [公 司] 北京北大金秋新技术有限公司

从文字来看好象贵公司在这个项目运做中没有摆正自己的角色。
1、从本案的商业模式来看,贵公司与运营方实际上首先都是投资方,运营方投入的是品牌和渠道,
贵公司投入的是技术和资金,而从本案来看,您好象将自己定位为一个项目执行方,那么一开始您的
公司已经注定成功的可能性不大,出现这样的问题也在情理之中。
2、这个商业模式本身没有问题,有问题的是贵公司出现了一个潜在的竞争者而贵公司却“浑然不
觉”,毕竟在在利益和商业道德之间至少在目前多数人会选择利益,抛弃道德,这个是贵公司在做项
目可行性计划时的失误,至少,贵公司的可行性计划中对这方面的风险分析是有缺陷的。
3、贵公司不缺乏项目管理的经验,而缺乏必要的商业运做经验,我认为本项目的失败项目经理要承
担部分责任,毕竟在项目执行过程中一定会有很多“蛛丝马迹”表明运营商将会有违约的可能,这时
候项目经理应该及时向自己的组织通报项目存在的风险以便于贵公司的高层及时与运营商沟通并约
束对方履行合同,当然,本项目失败的根本原因在贵公司的高层,至少他们应该承担项目失败成本
85%的责任。
4、请贵公司检讨贵公司的业务战略。

第 194 页 共 756 页
第 1 章 综合管理

5、请贵公司的法律专家提高自己的业务水平和商业意识,毕竟他们的专业知识是服务于贵公司的业
务需要的。
6、也许贵公司的业务决策流程也有检讨的必要。

·竞争中的优势(2005-05-02) [作 者] lzfsdi [公 司] fsdicet

严格的说我并不认为这是个失败的项目。市场的竞争是残酷的。伴随着竞争的加剧及原有技术核心的
淡化-同一技术行业内有多个企业都具有相当的技术能力。即使这次合同被严格的履行了,你也不能
保证运营商会在以后的市场发展需求下,寻求其他的操作业务平台。
问题的关键可能在于两个方面:1、在近一年的合作活动中,你们未能察觉竞争对手扩大了业务平台
的开发范围,平台中已经包含了你们所做的内容。2、作为业主的运营商的态度变化,也未能有准确
了解。对市场竞争对手与顾客的重视程度不够可能才是该合同失败的关键。

·风险管理,不容忽视!(2005-05-02) [作 者] 韦少才 [公 司] 桂林空军学院 7053

我想这个案例中的风险管理并不理想,在和运营商的前期业务洽谈之中并没有明确的把各方的的责任
写入合同,如此就增大了一个项目的风险。这其中项目经理也许要负很大的责任,因为在一个项目开
始运作之前,项目经理有责任把一份项目开发的风险报告提交给上面的领导,并做好项目开发的可行
性说明把风险降至最低。在项目开发之后,项目经理有责任监督合作方的合同履行情况。如果一个项
目没有按照客户的要求完成,那么可以说这个项目是失败的。但是一个项目已经按照客户的要求完成,
那么这个项目可以说是成功的了,但是如果前期没有和客户做好责任条约的合同,而造成损失的话,
不仅是项目经理,全公司的人都只能呆若木鸡了。即使是合作方违反了道德规范,你也是奈何不得呢!
毕竟法律承认的是你的法律合同,你惟有能做的就是下次要谨慎。在一个项目中,风险管理占有相当
的比重。

·寻求解决问题是关键(2005-04-30) [作 者] 林金 [公 司] 福州装饰

听了以上的分析 我想就不用去对案例分析太多了 我想现在事情都发生了 解决问题是关键


对于合作方的这种行为已经构成了违法的行为了 这是一种出卖公司商业机密的行为 因为象顾客的
一些资料在业务为推销手段的企业中是属于一种商业机密 既然双方已经有了合作的伙伴关系 这些
顾客的信息已经是双方合作下的一个商业机密了 而对方在未得到我方同意下 将其出卖 应当追究其
法律责任 就算对方现在还运营商口头声称还会履行合同,按照原来的分成比例给我们收入 但是我们
无法得知每个月的使用情况、用户多少,所以根本无法知道我们究竟应该拿到多少分成
我想可以用法律手段解决问题的 但要是顾及到以后的合作问题的话我觉得这种合作伙伴我是不敢在
与其合作的了
人不是万能的 但很多经验是在慢慢积累的 追究谁的责任 而不去分析 与解决问题我想这不是一个
管理者遇到问题时的第一个想法

第 195 页 共 756 页
第 1 章 综合管理

·这几个方面可能出了问题(2005-04-26) [作 者] 赵磊 [公 司] Null

文字
1. 风险管理没有做好
PM 应对合同中定义不甚清晰的条款仔细追究,并与用户达成书面补充协议。在项目执行过程中更应
该时时跟踪并评估主要风险。“呆若木鸡”的反映说明该 PM 在这部分工作上的不力。
2. 与用户的沟通不良
这条不用详细谈了

·倾向于认为是商务上的问题(2005-04-20) [作 者] 吴吉义 [公 司] 浙江远文信息技术有限公


项目的目标是为运营商开发业务平台,如果说项目验收合格了。就应该算是成功了,至于后期的一系
列问题其实是商业上的一些问题。比如客户关系协调,商务合同等等,这些不是衡量项目失败成功的
关键指标。
不能太悲观,类似的情况还是比较多的。项目管理做最好,产品最好,客户要不讲信用什么的应该算
是企业运做上的问题。

·补充(2005-04-19) [作 者] 任志强 [公 司] 上海

1、项目项目主办人、技术方案供应商、运营商之间的关系要搞定。
2、与运营商沟通以书面开式

·关于您的问题。(2005-04-19) [作 者] 任志强 [公 司] 上海

1、你所提之问题,在国内运营商特别是增值服务平台建设中经常出现。如果从项目管理的角度能不
能避免,关键在于合约的执行。也就是说,当初依当初双方所订合同进行分解。本案中在项目执行中
你与运营商间基于项目的推进中是否留有各环节的报告与记录。特虽是当时的项目节点与里程碑是否
已经在合约中明确。
2、出现这样的事情项目经理如果是在正常履约的情况下,没有责任或者说谁违约在先,你能否举证,
证明对方违约。

3、对于合作分成的模式。有类似于 BOT 模式。其实这样的情况,一定要在合约中加以明确,这点很


重要。特别是做为运营商同时采用两个方案。那么你所订之合同是独占许可合同,还是普通许可合同
这点需要注意

·解决问题(2005-04-18) [作 者] easy work [公 司] 暂不公布

第 196 页 共 756 页
第 1 章 综合管理

问题出现了,呆若目鸡之后,要勇敢面对问题了.
首先,要去分析问题的原因.为什么客户选用了另外一个公司的平台,而不放弃了你们公司的?其中一
定有原因.
1. 是产品的质量问题? 如果是这样的话,要在技术方面进行补救,并和客户洽商合适的让步条款.
2. 是商务方面出了问题?如果是应该让销售部门和公司领导迅速和客户沟通,商讨解决方案.
客户启用你们的产品可能是有道理的,不管这种道理是桌上的,还是桌下的.
其次,在识别出原因,并且双方不能得到互利的解决方案的情况下,要迅速诉诸法律.和客户保持良好
关系是为了合作,但这种关系不能以牺牲你公司的存在或发展为代价.

·项目管理的实施如何深入是国内企业的软肋(2005-04-18) [作 者] forestlyl [公 司] 北京
IT

类似这种结局的项目很多,风险管理不再只是纸上谈兵,而应有具体的量化评估体系,具体的风险应
对对策。由此可见国内企业在项目管理的实施上还没有深入。有很多是整体环境和管理层的问题,但
项目经理也具有不可推卸的责任。

其一,国内企业对项目管理的实施很浅薄:一个普遍现象就是购买所谓专业的项目管理软件来做项目
管理,以为这样就可以解决一切问题,就很专业规范了。但企业本身的管理体系和软件的项目管理思
想格格不入,至少没有融和,或者是根本没有深入,在这种背景下的项目管理充其量也就是定期搞个
报表哄哄领导。所以一旦项目出现任何风险就会岌岌可危。

其二,项目管理体系不健全:由于企业管理层对项目管理知识的匮乏,导致公司没有一个比较健全的
项目管理体系,正是因为缺乏项目生存环境,所以项目经理们在实施项目的时候四处碰壁,无可奈何。
当然这并不是为项目经理推脱责任,这个道理就好像外企的职业经理人空降后全都夭折了一样。别忘
了项目经理的权利最重要,项目经理没有决策权,做什么都白做。

其三,项目管理的量化时代迟迟没有到来:这个案例的直接原因就是风险管理的缺乏,如果有一个好
的风险预警体系,这种问题应该很早能预料到,能够增加一些防范措施。我们现在所谓的风险管理只
是象征性的列个 risk list,没有一个很好的量化和评估过程,基本只是个文档。所以这样的管理都
是些面子过程。项目经理的职责是跟踪监控,那么没有具体的数据,所谓的监控只能沦为例行公事。

其实,导致这种状况的原因可能还有些更深层次的外部因素,比如国内企业目前基本是以市场为导向,
而中国处于一种市场经济的发展阶段,市场化并不成熟,各种因素导致了企业为了市场而急于求成,
本来就缺乏规范管理的企业就更谈不上项目管理了。

当然种种原因不足以说明我们的项目管理就不能进行了,在这个案例中,项目经理负有不可推卸的责
任,你的风险列表里是否已经识别到了这种合同风险或市场风险呢?如果有那么你是否采取过什么沟
通手段和措施。也许你没有根本解决这个问题权利,但你有努力挽救这种结局的责任和义务。

·项目经理的责任(2005-04-17) [作 者] 张冰 [公 司] 北京北方数惠系统技术有限公司客户支

第 197 页 共 756 页
第 1 章 综合管理

持部

我想再补充几点:
1、合同约定之后,合同的履行如何保障,谁来保障没有仔细考虑;
2、有一点,我没有搞清楚,请教一下案主:
在你的案例介绍里面提到,两个平台分别负责不同类型的用户。但是在商用的第一天,运营商将所有
用户转到了竞争对手的平台上去。
如果发生这样的问题,主要责任就是项目经理的。
原因:
a) 三方合作,目标定位非常明确的情况下,那么承接的两个单位不应该是竞争的对手,而是合作伙
伴;
b) 系统商用之前,会有一个试用阶段,在试用阶段的拥护数据准备,系统切换协调,合作伙伴的系
统运转情况都应该是项目经理必须关注的问题;

·合同和项目的监督机智(2005-04-17) [作 者] 张冰 [公 司] 北京北方数惠系统技术有限公司
客户支持部

我想再补充几点:
1、合同约定之后,合同的履行如何保障,谁来保障没有仔细考虑;
2、有一点,我没有搞清楚,请教一下案主:
在你的案例介绍里面提到,两个平台分别负责不同类型的用户。但是在商用的第一天,运营商将所有
用户转到了竞争对手的平台上去。
如果发生这样的问题,主要责任就是项目经理的。
原因:
a) 三方合作,目标定位非常明确的情况下,那么承接的两个单位不应该是竞争的对手,而是合作伙
伴;
b) 系统商用之前,会有一个试用阶段,在试用阶段的拥护数据准备,系统切换协调,合作伙伴的系
统运转情况都应该是项目经理必须关注的问题;

·项目经理不是万能的!(2005-04-16) [作 者] GaoDapeng [公 司] 北京南天软件有限公司

1、就该案例来说,项目经理的责任主要在于沟通不善,对客户的把握不到位,对项目关系人的期望
没有做好平衡!
2、项目发起人(一般是公司高层)或项目主管与客户、项目经理的沟通渠道不顺畅,这么大的事,
一般的项目经理根本就承担不了,事发之前,不管是项目经理还是项目发起人早应该有预感或获得某
种信息!
3、合同和风险管理不严;

第 198 页 共 756 页
第 1 章 综合管理

我个人认为该项目的责任不应该由项目经理一个承担!

·总结经验(2005-04-16) [作 者] 理想 [公 司] 长春工程学院

1.各位前辈都已经提到了关键词,风险控制。做任何一个项目都要承担一定的风险,所以在前期一定
要充分考虑。而且在合同里进行相应的约定。
2.项目经理有责任对整个项目的整体做全面控制,现在出问题了,他责无旁贷。
3.对于合作分成这种形式,本身就属于责任与权利不明确的形式。非常有必要在合同中加以明确。就
像有钱出钱,有力出力一样,作出区分。

综述,对于一个完整的项目,中期控制虽然很重要,但是前期控制作为一个基础,一定要打好。各种
调查以及最后合同的签定,都要慎重考虑。尤其是合同,毕竟法律承认的是合同。最后我建议你在做
一个没有接触过的项目或项目形式的时候,去查阅一些类似项目,把其中出现的问题在自己的项目中
要加重考虑!

·合同管理,风险管理的问题(2005-04-16) [作 者] 孙鹏 [公 司] 同济大学

首先在一开始制定合同的时候就应该意识到自己的风险很大,负责全部的资金,这是不公平的,既然
利益分成,那么风险也要分成,不能让自己承受全部的项目风险,这样在合同的拟定上就应该设计条
款以规避风险,并且应该作好充分的可行性研究和项目策划;其次道德风险的问题,对方的行为已经
违反了合同的精神,公司应该寻求法律手段保护自己了

·一点小看法!(2005-04-15) [作 者] 马渊鸿 [公 司] 安徽网龙

针对第一个问题,项目的风险管理应该在项目实施之前就应该做好,准备好风险出现时的应急措施。
任何项目可能都存在风险性,如何圆满处理和化解风险才是项目经理在做项目之时应该考虑的。
针对第二个问题,楼上网友也说了,项目经理如果在与运营商谈此项目之时,就参与进入的话,项目
经理是有推卸不了的责任,因为项目经理应该知道项目各方的权责利问题,尽可能把项目风险把握在
自己可控之中,并且有一定的法津依据。
针对第三个问题,“合作分成”这样的搭建平台的方式本身就具有很大的风险性,但是现在工作中这
种合作方式又普遍存在的,这样就要求项目经理应该具有很强的自我法津保护意识,在签署项目合作
协议时,应该规范合作各方的权责利的,规避项目风险!

·一点小看法!(2005-04-15) [作 者] 马渊鸿 [公 司] 安徽网龙

针对第一个问题,项目的风险管理应该在项目实施之前就应该做好,准备好风险出现时的应急措施。
任何项目可能都存在风险性,如何圆满处理和化解风险才是项目经理在做项目之时应该考虑的。

第 199 页 共 756 页
第 1 章 综合管理

针对第二个问题,楼上网友也说了,项目经理如果在与运营商谈此项目之时,就参与进入的话,项目
经理是有推卸不了的责任,因为项目经理应该知道项目各方的权责利问题,尽可能把项目风险把握在
自己可控之中,并且有一定的法津依据。
针对第三个问题,“合作分成”这样的搭建平台的方式本身就具有很大的风险性,但是现在工作中这
种合作方式又普遍存在的,这样就要求项目经理应该具有很强的自我法津保护意识,在签署项目合作
协议时,应该规范合作各方的权责利的,规避项目风险!

·项目经理该做什么?(2005-04-13) [作 者] 王勇 [公 司] 远达网络

目前,项目经理这一称呼被广泛的使用在各个公司,似乎使用了项目经理这一万金油后就万事大吉了。
但是实践的效果却要根据不同的公司背景和项目经理的知识和经验而定。
对于此案例,我认为:
1. 如果该公司的项目经理作为商务顾问的角色充分参与了前期的合同洽谈和签订工作,应该评估此
项目风险并且提交报告给公司的项目决策人。 至于评估合作分成的利益 VS 项目风险,以及如何转移
或者避免风险,需要项目决策人综合多方意见后决策。
就此项目而言,我认为如果要做风险必然存在,只是如何转移或者减小的问题。

2.出这样的事情,项目经理有没有责任?
如果前期项目经理没有参加合同洽谈和签订工作,只是负责实施。"在出事当天,项目经理呆若木鸡。
[/i]",这种情况应该是典型的沟通不够的结果。无论如何,[i],“准备商用的第一天,运营商在没
有任何通知的情况下,将所有用户转到了我们竞争对手的平台上去,也就是停止使用我们的平台。”,
前兆会在前期的项目试用期中从各种渠道逐步透露,并且可以提前采取措施。

·"空麻袋背米"的联想(2005-04-12) [作 者] 梁桢 [公 司] 上海广平信息系统工程有限公司

首先,公司由于被项目"合作分成"的利益所迷惑,所以对项目的可行性分析和风险分析做得很不够,才
会出现全额承担项目费用的情况,将自己的成本控制的非常高.所以项目经理、行政主管都有错

其次,虽然公司自身承担高额的成本,但对于合同条款的管理没有严格约束,这是导致运营商出现平台
停用后没有足够法律条款约束其的结果.所以律师、项目经理需要反省。

最后,公司需要对项目的技术进一步审核,修正存在的问题,以免运营商提出种种没有达标的借口,并
整理相关合同签订时,项目实施中,事后运营商出具的相关的文档为日后可能出现的官司准备.所以整
个项目团队都要积极参与。

·“沟通”的问题?(2005-04-11) [作 者] zzh [公 司] 华联超市

第 200 页 共 756 页
第 1 章 综合管理

我认为以上各位说的很有理,但是我想说的是:如果质量管理做得好,完全能符合对方的要求,那么
是否在项目进度中,和对方的沟通是否出问题了?

·合同漏洞(2005-04-11) [作 者] howard_hong [公 司] 上海普华

1)这是合同管理中巨大漏洞,项目风险控制没做好;
2)项目经理有没有责任就看合同的签订、审核过程;
3)这样带资建设的项目,合同违约条款必须是严谨的,看别人脸色的项目务必要考虑风险;

·作好合同管理、风险管理,运营模式管理(2005-04-11) [作 者] 刘杰 [公 司] 山东科技大学
土建学院

在本案中,应该首先重视的是合同管理,作好相关的工作,对这种新的运营模式,应该持谨慎的态度,
并且作好风险管理。
我认为作为项目经理应该从一开始就应该进入,加强自身职责,做好预测,对项目也应该加强管理。

·合作分成,应该是一个比较好的运营模式!(2005-04-11) [作 者] 赵宏伟 [公 司] 东信北邮

我们公司就有一个项目和某个运营商很做分成的方式进行的!

不过由于原来业务的用户发展缓慢,后由于新的业务发展迅猛,把原来那套系统干脆集成到下一个单
子,一起卖给了运营商!

看来我们的分成合作项目也没有成功!。。。

·发生这种情况 项目经理肯定有责任!(2005-04-11) [作 者] 赵宏伟 [公 司] 东信北邮

项目经理应该从一开始就介入这个项目,这项目的执行过程中肯定很多消息都会慢慢显露出来的! 应
该在项目的执行过程中,要有很好的控制!

·这种情况应该在最开始就要在合同里写明!(2005-04-11) [作 者] 赵宏伟 [公 司] 东信北邮

这种合作分成的项目,在相关合同中就应该明确合同的时间限制,一开始是否知道 2 个厂家同时在做
这个项目,应该在合同中说明 2 套系统最后会以怎样的方式进行用户的分配,还是完全竞争,谁的
系统运行好就是用谁的!那样你的风险就很大!这种情况如果能够避免也只能在最初的时候要考虑周
全!

第 201 页 共 756 页
第 1 章 综合管理

要不然发生之后怎么去诉讼都没有很大依据!

1.23 项目为什么会失败?

项目为什么会失败?

[姓 名] 严晓晶 [单 位] 南京 [邮 件] jackyanccie@163.com
[所属行业] 综合应用 [所属主题] 项目综合管理 [发布时间] 2005-1-8

【案例正文】
这个项目为什么失败?
背景:
一个大的集团公司的一个事业部。
要求和范围:
领导要求 3 个月以内 做一个能给研发人员作为参考的一个工作手册,手册的内容包括工作中
所有的问题的具体做法,有好的也有不好的,一方面当他们遇到困难时可以参考,另一方面是
作为事业部的一个管理财富。
过程:
任务落实到一个新到公司的同志,他根据领导的要求,组织了人员,并制订了计划。
人员结构:主要是搞研发管理的。
项目结构;根据不同产品线区分。
在项目启动会议中,所有的人员对这个提出了异议,认为没有必要做这个工作产品。经过多次
的讨论,最后是领导出面,强行的把大家的异议收敛,因此项目计划也变更多次,最后项目严
重延期,不得不暂停项目。
大家分析一下,到底出现什么事情了!怎么办?如何避免?

【相关分析】

·沟通是最重要的(2005-04-23) [作 者] 徐兆春 [公 司] 成都铁路运输学校

在开展项目的时候,作为项目的负责的,一定要做好项目规划,适当地做好沟通.考虑到可能遇到的问题,
用相应的方式来进行成员间的沟通,如果有必要,在第一次会时就让主要领导出面来做工作,这样大家
看到领导很重视,会从服从于权力的角度来开展工作.当然,我觉得更重要的是,尊重人性,这也是企业管
理中需要的.

第 202 页 共 756 页
第 1 章 综合管理

·没有调动项目成员的工作热情(2005-04-11) [作 者] 徐士元 [公 司] 天财通胜

我认为项目失败的原因主要是因为没有调动项目成员的工作热情,没人真正投入工作之中。其实,从
项目成员的角度看,没有热情是自然的现象。一种可能是认为认为公司不信任自己,不愿意把工作经
验拿出来分享;更大的可能是认为这样一个工作手册根本没有用处。另外,因为这是一个内部项目,
很可能也没有绩效考核,做好做坏对于员工个人没有影响。当无法和项目管理人员取得一致时,公司
领导出面用强制方式压制了个人意见。这样,员工们就是被迫去做一个自己没有愿望去做、做不好没
关系、做好了也没用的产品。显然项目失败是可以预期的。
在这样的局面下,项目经理需要协调和项目成员之间的关系,耐心与其沟通。比如,这个工作手册可
能对于老员工的实际意义不大,但项目经理可以利用自己新员工的身份,设身处地的说明手册对新员
工的好处,以一个新员工的身份请求老员工的帮助。一来可以建立和项目成员间的良好关系,二来可
以让项目成员认识到项目的必要性,认同做好项目带来的成就感,从而在没有经济利益的情况下激起
对项目的热情。同时,在项目进行中应注意阶段性的表扬激励,没有经济利益,精神上的满足也是有效
的。:)总之,对于这个项目而言,使用强制手段不是最好的选择,项目经理有时表现得低调一点并不
代表软弱。

·什么异议?(2005-03-03) [作 者] 小飞熊(flybear) [公 司] no

在项目启动时没有足够充分的动员起大家的积极性,而在出现阻力时对问题根源分析似乎也不够充分
(看文中的意思是马上做的决定)。另外,异议一词有的含糊。看来还是有人支持的(不知道有多少,
估计不会过半)。如果领导在第一次会议后,做更多的分析和沟通,情况很可能会好很多。

·思想不统一(2005-03-03) [作 者] bairimeng [公 司] 保密

呵呵,我经历过类似的项目,这种项目类似于推行知识管理。老板当然支持,老板的想法把项目经验
积累下来,变成公司财富,既可以供新人参考,降低对新人的要求,又可以防止人员流失带来的损失!
但这种项目的成功需要首先统一思想,让员工也能认识到项目对自己的好处。
员工抵触项目的原因大概有几个:
1、员工觉得公司因为不信任自己才做这个项目,不希望把自己经验共享出来;
2、觉得项目很难产生真正有价值的东西,当然基于几个假设,
(1)公司其它人水平有限,有高手自
己回去请教,
(2)即使记录了经验也很难找到,如何查找搜索?(3)内容需要与时俱进及时更新(似
乎很难做到)!

·项目为什么会失败?(2005-02-21) [作 者] 熊浩 [公 司] IT企业

沟通存在问题,是领导强行收敛异议后启动的,可能会造成目标没有真正统一,整个团队的工作态度
都存在问题。因而项目严重延期

·项目为什么会失败?(2005-02-21) [作 者] 熊浩 [公 司] IT企业

沟通存在问题,是领导强行收敛异议后启动的,可能会造成目标没有真正统一,整个团队的工作态度

第 203 页 共 756 页
第 1 章 综合管理

都存在问题。因而项目严重延期

·项目没有可行性研究!(2005-02-14) [作 者] WANGK [公 司] 重庆移动计费业务中心

如果一个项目没有进行可行性研究,究竟该不该做,那么失败的可能性就是大大的。领导的个人意志
成为项目立项的依据,危险!这样的事情太多太多。
从另外一个角度,也许领导有别的意图,呵呵,对领导或许是另外一个项目,比如,考察员工,呵呵

·项目失败的衡量标准(2005-02-04) [作 者] 王昊翔 [公 司] 上海北京-希望软件上海分公司


开发二部

从表面上看,由于工作手册没有完成,项目是失败了。
其实项目还是达到了领导的预期目的。
目的 1:
如果,该新员工有亲友高层(或客户)沟通途径的话,让他编制工作手册就维护和增进了横向交流沟
通。
目的 2:
树立自己提拔培养新人的形象,为汇集人心树立良好的领导形象。宣告自己改进工作流程的决心。
目的 3:
激励老员工和技术人员,告诉他们不进则退的道理。
目的 4:
让新人通过这个机会融入群体。
目的 5:
新人的项目失败给了老员工面子,增加了企业凝聚力。

所以说新人的失败也是明智的,领导很有面子,老员工也很有面子,新人今后也会得到老员工更多的
协助。

这个项目其实没有失败。领导只要收场到位(做得好),就是多赢的局面。

这个企业的领导是很有领导技巧的。

·失败是必然的!(2005-01-28) [作 者] 程宇 [公 司] 成都恒视

1、公司领导对该项目认识不足。同时对项目的认识存在问题。
2.人员选定有问题。作为新员工对公司的认识完全处在一个全新的起点,不适合做这种带有参考性手
册性质的文档。
3.人员的选定错误,造成了无法和有异议的同事进行沟通。最后由领导命令性质的安排。无法使大家

第 204 页 共 756 页
第 1 章 综合管理

齐心。
从公司的规模上来看,这样一个文档应该有其必要性!但是领导的思维错误让一个好的项目就此完了!

·还是要看有什么收益(2005-01-26) [作 者] Fusheng.Yan [公 司] TITSCL

总的来说一个项目最关键的是
需要干系人付出什么的努力成本,并带来什么样的收益。
下力不讨好的事情没有人做。
就短期而言,增加了工作程序和限制,平添不少工作量,恐怕没有什么大的好处!
要想得到支持得站在别人的角度多想想,究竟要付出多大努力有什么收益?要了解员工的真实想法,
也许所提的仅仅是借口,抵制外来新手的带领或者没有长远打算也许才是真实的想法!

·项目为什么失败(2005-01-25) [作 者] 江松霖 [公 司] leader group

大的集团公司会出现内部机构组织复杂、人员关系复杂等问题。面对这些可能是长期存在的问题,想
通过工作手册来解决是不现实的,但会起到一定作用,三个月的时间也不短了,如果做好计划,并按
计划进行,应该是可以实现的。
1,新员工受领导信任,领导也有意让他借此机会与同事进行沟通,尽快熟悉业务。但很可能受其他
员工冷遇,要看项目负责人的能力和表现了。
2,试想谁愿意给自己头上到紧箍咒呢?找到矛盾的所在,抓住主要矛盾,是员工们的工作态度,还
是结构体制问题,还是所在部门领导的问题。其实都有可能。
3,要有总工程师、总设计师这样的人支持。也就是说行政上和技术上都要有人支持。
其实,工作中的正确与错误的问题都是存在的,只要发现并仔细记录下来,有理有据,并认真归纳总
结出来,有行政、技术权威认可,大家又没什么疑义就可以了

·个人感受(2005-01-21) [作 者] 菜鸟一个 [公 司] 亚信科技

1、就这个项目背景而言,建立公司的 KM 是很有必要的,这样能充分达到知识共享,所以,在项目的
启动的时候必须强调这个项目建设成功对公司的意义,尤其对这么大的集团公司。
2、建设一个项目必须遵循项目的固有规律,包括项目经理的人选、项目的目标分析(可行性分析)、
项目 TEAM 的组织、建设、项目计划的合理评估、项目进度的控制等。
项目经理的人选在项目的建设重,起到至关重要的作用,我觉得项目经理的人选,即要有丰富的项目
管理、宏观的业务知识还有很强的有部门之间的沟通、协调能力。这个项目选择新人没有错,错的是
这个新人是否得到了高层领导的大力支持、各个智能部门之间的大力支持等等。
在就是项目的可行性分析,既然大家有意见,那不在项目启动的初期,就很有必要在整体高度上强化
建设这个项目的重要性,而不是一言堂。只要公司的各个部门、每位员工在对项目的目标的认识达成
一致,那么在以后的项目实施过程中就能得到很好的贯彻、执行等。
在就项目团队的构成、组织结构方面,也必须建得合理。如必须要有一个熟悉公司整体制度、流程等

第 205 页 共 756 页
第 1 章 综合管理

得业务专家。
只要项目计划、控制,就是项目经理的业务水平的问题了。所以,项目经理的人选至关重要。

·回复(2005-01-21) [作 者] 奥林匹克 [公 司] 中铁七局集团有限公司

领导没有错,领导的要求是正确的。
目的还是为了让你们少走弯路,员工对此认识不足,加强教育。

·一点建议(2005-01-19) [作 者] 李东和 [公 司] 京润

我感觉工作手册的制定事很有必要的,它可以使新员工很快上手,老员工在遇到问题时也有文件可查。
但是项目负责人不能由一名新员工担当,最好是由公司中能力在中上的老员工担当,他们即熟悉公司
流程,又有工作经验。

·项目是否可行(2005-01-14) [作 者] 刘治国 [公 司] 鞍山顿辉服饰有限公司

1、要求和范围:
领导要求 3 个月以内完成项目,领导对项目本身认识不足,不应在项目没有进行需求分析和计划就定
完成时间。这是错误的。
2、过程:
任务不应由新员工负责,只少有个资深员工给予协助。
3、人员结构:
不应只是搞研发管理的。其它相关部门管理人员也应参加。如:客户部门,对的开发的产品客户的反
应情况等。
4、项目结构;产品是多样化的也是有共性的,不应以不同产品线区分,应由产品同异性区分。
5、所有的人员对这个提出了异议,认为没有必要做这个工作产品,要加以重视,重新对项目的可行
性进行分析。领导的压制方法是不对的,应多听取员工对这个项目提出的异议,并对项目进行整改。

·还有一个因素(2005-01-12) [作 者] 严晓晶 [公 司] 南京

在项目严重延期侯,这个负责人也觉得无从下手。
适逢其他的部门需要人,这个负责人想去其他部门,于是领导就要这个负责人把这个项目转移给别人

·项目为什么会失败?(2005-01-11) [作 者] 奥林匹克 [公 司] 中铁七局集团有限公司

负责人是不是新人无所谓,关键在于采用什么样的方式最合适。

第 206 页 共 756 页
第 1 章 综合管理

我认为两个个人最好,一个负责,一个联络。
我认为座谈、交流的方式就足够了。也许要好几次,但是这样效果好,大家的参与有热情,畅所欲言!

·一点小建议(2005-01-11) [作 者] Nicolas Qi [公 司] classified

晓晶:
我的想法是:
这位领导的想法是好的,但管理方式有问题。
新人得到这样的锻炼,机会难得,领导似有器重之意。
建议:请领导指定资深员工支持。
召开会议,汇总信息。
参照历史资料,制定大致流程,内容不必过细。
请资深员工修改,请领导审核后,签字确认,下发。

敬请雅正!

·分析下这个项目(2005-01-10) [作 者] 梁桢 [公 司] 上海广平信息系统工程有限公司

首先,工作手册的制作是值得提倡的,这是将工作问题流程化解决的做好方法,能追踪问题的出去并
能及时解决。

其次,公司让 1 个新员工来做这件事有些不妥。新同事对事业部的工作流程不熟悉,对事业部的人员
不熟,所以在沟通和编制过程会出现很多问题。建议有资深人员参与到这个工作产品制作的的项目中
去。

再次,领导出面压制怨言的确不妥,不妨听听各方面的看法,召开个头脑风暴,我想工作手册的目的
就是在于提高效率。听听逆耳的声音有助于顺利将项目做好。

最后,希望这项目能顺利的完成

·需强调项目的必要性(2005-01-09) [作 者] 丁磊 [公 司] 沈阳工业大学

这个项目主要是由于项目成员对本项目的必要性认识不足造成的。 这点需要领导开会疏导,不要仅
压制。

第 207 页 共 756 页
第 1 章 综合管理

1.24 项目组内应力的可怕破坏力

项目组内应力的可怕破坏力

[姓 名] Allen Tian [单 位] 某医疗器械有限公司 [邮 件] allen_scar@sohu.com


[所属行业] 生物化工 [所属主题] 项目综合管理 [发布时间] 2004-4-1

【案例正文】
公司一新产品开发立项,要我作项目经理,目前此项目处于执行阶段。此前,我做
过的工作有用户服务部工程师,公司新产品的市场调研、临床验证,新项目的可行
性分析等。

近来我感受到了一些来自项目组内部的反弹力,主要体现如下:
1、项目组中个别成员未及时汇报工作进度,需要我去询问;
2、在项目组开会讨论时,对某一方面方案产生争论,一人因意见相左而中途离开,
退出讨论。

看了上述现象,您可能有种感觉,就是我这个项目经理太软弱。这里还有个细
节要指出,我来到该公司仅 7 个多月,也是刚刚本科毕业 7 个多月。不知这一点会
不会成为员工内心并不情愿服从我的管理的原因之一,该如何解决?本人深知沟通
在一个项目管理中的重要性,也极尽所能实现项目各干系方之间信息的高度流通性,
但初出茅庐,还请大家多多指导。

【相关分析】

·弄清楚(2004-05-17) [作 者] 胡拉拉 [公 司] MP

刚毕业可以担任项目经理的职责,非常有挑战的。
但是,有没有问过你的老板,看中你的什么而让你这样的出生牛犊负担这么重要的责任?你可以了解
清楚到底什么是你的长处?
当前你最大的问题就是不太能够在这帮技术人员中拥有老技术人员所有的威信,一般来说,从上到下
的推动是很有效的,因此最好就是你的老板在某种场合表达对你的看重和信任与希望。
更重要的是,你能够在工作中表现出你对整个项目的了解,对技术的基本把握,对项目成功的渴望,
对所有人员的尊重与希望,我想这样能够帮助你尽早的完成对于项目组成员的了解与沟通。

·项目中沟通比较重要(2004-04-29) [作 者] ierpku [公 司] 深港产学研基地

首先要祝贺你成为项目经理,希望要成为项目经理一定要多少年的工作经验的惯例在你身上能够得到

第 208 页 共 756 页
第 1 章 综合管理

突破,在交流沟通中展现你的个人魅力,让项目组有一个具体的目标,有一定的激励机制。

·努力去做好!(2004-04-26) [作 者] 马渊鸿 [公 司] 安徽

因为你现在刚毕业没有多长时间,公司员工对认知不深,你应该通过这个努力把这个项目做到最好,
至少让所有的同事都认可,你的问题也许就在于你的经验吧!当然做为项目经理,你应该用成绩说话!
别所有的公司员工真正认识你的能力!

·亲身的体验(2004-04-07) [作 者] 孔祥舜 [公 司] 北京航空航天大学

作为大学生,我其实没有权利说三道四,因为毕竟我也没有真正的工作经验。但是突然想到一个英语
老师对我们说过的话,具体是什么记不清了,但是理论意思就是,首先要抓住这个组织中对你最不满
意的沟通阻力最大的人与他成为真心的朋友,接下来的事情将会一帆风顺,海阔天空。我没有尝试过,
但是我自己曾经对这个老师不太满意,她的确是这么对我的,我深有体会,不妨试试!
别的一些关于沟通上的理论我懂得不多,前辈都已经说到了,也是很好的方法。如果我说的有什么不
对的地方,还请各位指正批评。

·主持会议的艺术(2004-04-07) [作 者] 黎岩 [公 司] 广东深圳

在主持沟通会议时,要讲究艺术,不仅仅要控制好会议的时间、效率,还要在会议过程中注意各成员的
情绪等,如果发现某成员因某问题在争论过程中有了情绪,要艺术地去打断、并进行心理平衡,这样
才能保持会议的持续性!
在一个项目中,意见相左的情况很多,怎样进行合理的平衡,就是一个项目经理能力之所在!上面的
几位在沟通上已经说的很多了,说到底,沟通是一个项目经理必备的能力。

·懂得什么重要,还需懂得解决方法(2004-04-07) [作 者] 杨非 [公 司] Jinni软件工作室

很认同 Tomxu 的分析。事实上,Allen Tian 提到的两个问题,在项目管理中是比较常见的。就第 1


个问题而言,是沟通的主动性问题。沟通需要双方共同努力,其中任何一方都有可能因繁杂的事务而
出现该类情况。此时,需要合理安排个人的工作时间表,即作为项目经理,在制定个人工作时间表时,
需要安排督促检查的任务项,而且通常不能等到某项任务结束日期到了才检查。第 2 个问题嘛,属于
会议进程的控制问题。作为项目经理,此时需要控制争执的态势,避免蔓延。通常可以建议会后小范
围讨论,这样可以缓和当时的气氛,留下进一步研究争执焦点和解决方法的时间,同时不至于影响会
议进程(毕竟会议通常不会讨论 1 件事情)。总之,项目和团队管理,需要把握一些切实可行的管理
技巧和技术。

·几点看法:会议是一种很好的沟通途径等(2004-04-07) [作 者] 赵宏伟 [公 司] 东信北邮

无论什么会议 正式的还是非正式 都是一种沟通形式,既然有人中途离开 原因可能很多的, 不仅仅

第 209 页 共 756 页
第 1 章 综合管理

是表面的一些现象, 这样你就需要更多的沟通与他!
另外你刚到公司 7 个月,不算很长的时间,就处在一个项目经理的位置,必然的威信不足, 你就应
该成这个机会,把自己的威信慢慢的树立起来!!
沟通的重要性是不必说,但是沟通的方法和方式,上级对下级的沟通就是分配任务等,下级对上级的
沟通就是汇报汇总等 平级的沟通就是一些头脑风暴等讨论。。。 这就是一种经验的积累或者说大一
点是阅历的积淀!
还有无论什么管理 都是一种控制 而控制主要的对象就是人,关键的也是人,人管理好 其他物等自
然就会被人管好!

·威信 不一定来自本人!(2004-04-07) [作 者] 赵宏伟 [公 司] 东信北邮

假设你有很好的“后台”:)也就是说你和你的领导,项目相干系人的领导都针对这个项目沟通得很充
分很好了,责任到人,这些就是你“威信”的后台,项目相干系人都有自己得直接领导(就是涉及到
自己得考核得),虽然说不要用领导来压人, 这就需要一些技巧,有时候不能过火,辅助致用,
最好的说服力 就是让你的团队 知道团队项目的共同目标,在项目团队里个人的目标, 让大伙明白
实现共同目标得同时有实现自己个人得目标, 这就需要引导大伙建立自己在这个项目中的目标,实
现此目标的途径,目标实现后的利益。。。。
形成一种向心力!

·update(2004-04-07) [作 者] 田立峰 [公 司] Sunray Medical-Apparatus Co.,Ltd

大家好!首先感谢多天以来各位提出的宝贵意见和建议,小弟受益匪浅。其中,大家提到的谦虚谨慎
一直是我的工作作风,我反而担心是否会因此而显得缺乏威严。
下面将这段时间的一些项目管理工作与大家分享:

3 月 30 日,临时决定,开了一次项目小组工作会议,(原因是意识到有些要求需项目组成员明确)
主要进行了两方面内容:

1、大略介绍项目管理的必要性和项目经理的职责;
项目管理的目的是为了更有效地保证项目质量,并且顺利进行,使项目各干系方都能满意。项目经理
的职责主要就是协调、沟通,保证信息的高度流通,有效控制项目进度与资源配置,保证项目顺利进
行。
目的是让项目组成员了解并接受项目经理及其管理。

2、指出前段时间工作中的不足之处,并提出今后的要求:
①及时汇报工作进度,同时鼓励自发进行项目组成员之间的协调。虽然一到两个星期有一次工作总结
会议,但为了项目经理能更好的掌控项目进度,要随时以非正式的形式告知工作近况;②任何意见、
建议都要及时提出,并说明理由。目的是营造一种轻松的工作氛围,使组内成员的想法能够及时交流;
③严格遵守会议纪律,不得擅自离场。

第 210 页 共 756 页
第 1 章 综合管理

会后私下与一位小组成员沟通时,该成员表示会上中途离开的那个人不会因为意见不一致就中途离
场。那么,我倒是感觉这个团队的纪律建设也是一个不可忽视的问题,并且也表明了我还不很了解项
目组成员。其实,此项目组的主要成员基本都是各职能部门的经理,而且都是比较负责的,但可能长
久以来,在运作项目的时候各职能经理是直接向公司高层领导负责,所以目前不太习惯多出来一个管
“闲事”的项目经理。

4 月 2 日,按原计划进行项目工作进度总结会议,会上我对多数提前完成的组员提出表扬,对未按期
完成工作的组员提出了批评,并表达了我的一个想法“引入评分制”,对各成员的工作进行打分评比,
并据此给予相应的奖励或处罚。讨论中,多数成员认为为时过早,缺乏可量化指标,因此取消了此项
措施。但我还是很想进行这方面的建设,让项目工作制度化,也可以为以后其它项目工作提供模板。

所以,截至目前,我又遇到了一个新问题:在项目管理过程中,何时、以何种形式引入何种绩效考核
或评分标准?是否有此类模板参考?

在上述项目管理工作中,肯定还有很多小弟没有意识到的问题,希望大家不吝赐!

·你需要权利!!!(2004-04-06) [作 者] 王栋 [公 司] 安捷康食品运输有限公司

找你们总经理,让他给你两样东西:1 个硬件--给你一个代表你可以管住手下权利的手杖。1 个软件


--让他对着大家讲,这个人是我请进来的,我充分相信他的能力。这个项目是我让他做的,大家都必
须为他开绿灯。谁和他过不去就是和我过不去。
但是!!!如果你真的还不具备凌驾大家的能力,我劝你还是从小做起,一个项目经理的职位,起码
要有成熟的思想,足够的经验,起码要做过 3 个部门,等你到 30 岁的时候。在考虑做项目经理。

·项目组内应力的可怕破坏力(2004-04-06) [作 者] Tomxu [公 司] 中国联通云南分公司数据


Allen Tian,你好!
对于刚毕业 7 个月,你就被任命为项目经理,表示祝贺!
但是,你要做好项目经理,也是有很大困难的.首先,你的威信何在,领导授予了你多大的权利和责任.
其次,你是否了解项目团队中的每一位成员,他们各自的经历,能力,工作方式和目标又如何.然而,现
实的情况中,领导的支持又相对模糊,如果你没有一定的成绩,就向领导要这要那,指责团队中的成员.
这并不可取.换句话说,领导任命你为项目经理,一则考验你的能力;二则希望你把项目相关的大部分
事情摆平,否则,要你干嘛.
回到你碰到的两个问题,对于你才到公司 7 个月,这确实很棘手.对于第一个问题,建议你与该成员单
独沟通,了解一下他的想法,是对你不服气,还是他的工作习惯所至,还是不习惯你的工作方式.很多时
候,问题产生于双方沟通不畅,对方都以为别人会知道,但是结果常常不是这样.然后,在一次相对正式
的项目团队会议上(最好能请领导参与),以正式的形式,向各成员提出要求和规定,提出相应的奖惩措
施,并征求大家的意见,如果没有意见,那么大家签字,以后照此执行.对于第二个问题,我认为应该从

第 211 页 共 756 页
第 1 章 综合管理

如何有效地主持项目会议入手.对于很多问题,发生争论是正常的,如果没有争论,项目执行可能已潜
在很大的问题.但是,对于争论性问题,讨论是必须的,但集中却最重要(很多问题需要你来拍板,当然,
有的问题可能要报领导讨论.但是,作为项目经理,项目的决策必须由你做).控制好会议的时长和效
率,共性问题共同解决,个性问题单独解决,不要浪费别人的时间.
另外,我想强调一点,任何人都希望被别人尊重和重视,作为项目经理,我们首先应当学会谦虚,学会与
各种人进行沟通.其次,项目经理应当好团队的教练.再次,在专业方面,项目经理应努力提升自己.

·必不可少的说服艺术(2004-04-06) [作 者] 戢明 [公 司] 苏州三星电子有限公司

就你的情况,主要的问题出在你自己说服别人的能力上!
今天的企业主要是以团队方式运作,没有多少人相信一个他不了解的“权威”,在这种情况下,说服
作为一种管理手段就显得格外重要。
这里所说的说服不是指将一个主意推销出去或让别人确信你看问题的方式的正确性,而是指你向他们
学习以及同他们协商以共同解决问题的方案的过程。主要从四个方面考虑:
1:建立可信度;
可信度来自两格方面:专门的知识,相信这一点你应该能满足,毕竟头头们不会找一个专业上都不称
职的人来做项目经理;另一点就是人际关系,你的任务不是如何去说服别人,而是学会倾听别人的意
见!
2:设定并找出共同利益范围;
要想让别人听你的,你必须让他们相信支持你的观点能给他们带来实际的利益,这里实际的利益并不
一定是指经济上的,鼓舞和激励他人的手段有很多,相信你也清楚。
3:提出生动可靠的证据;
好的证据不是普通的图表,主要是有吸引力的事件,或是切实的自身体会。
4:从感情上建立联系,产生共鸣。
取决于你的洞察力,寻找机会与他们交流,信任有时候是从酒桌上来的,共同的爱好绝对是一个好的
敲门砖。
最后,适当的妥协并不意味着失败,它恰恰是表现领导力的一种手段。

·管理要依托成熟的制度(2004-04-03) [作 者] 王志华 [公 司] 上海建工集团 203 工经部

工作进度提交必须形成制度,按原定计划进行考核。在原计划制定时,许多方参与、共同协商后制定,
对不及时提交的除了沟通、换位思考外,还应有必要的手段。
对于因意见相左而中途退出,应从方案的本身出发,若改方案为最优方案,则必须与该同志及时进行
私底下沟通,看是否出于个人原因。

·你对项目组成员有考核的权利么?(2004-04-02) [作 者] 华琰 [公 司] 用友公司

你对项目组成员有考核的权利么?

第 212 页 共 756 页
第 1 章 综合管理

这点也很重要

·搞好关系(2004-04-02) [作 者] Henry [公 司] 北京

我觉得你现在需要和团队成员搞好关系,要知道,管理并不意味着要在上面管别人。可以请大家抽抽
烟、吃吃饭,在一些私人的场合聊一聊

·首要的摆正的是你的心态(2004-04-02) [作 者] 王燕 [公 司] 双叶软件

正向上面那位朋友说的,你可能把这些小事看得太重了。说句实在话,刚毕业的人的确不是很适合有
一个很高的起点,因为这样你就不能站在他人的角度去考量问题

建议你先放下架子,用比较真诚的态度承认自已的不足,多征求组员的意见。另外,加强自已的专业
知识也是很重要的一部份。帮你的组员一起工作,不实为一个好办法。

最后要时刻提醒自已不要心急气胜(这是年轻人多半的毛病)

·你的实力展现给你的下属(2004-04-02) [作 者] 胖胖 [公 司] FTS数据入力

你刚刚进入公司不久,这种情况是难免的。因为你的下属在这个行业
比你要有更多的经验,但是,公司既然任命你来做经理而不是你的下属,就证明你在其他方面肯定有
过人的地方,你不这么认为吗?
与其跟他们好好的沟通(当然不否认沟通也很重要)不如将你过人的一面展现给你的下属,说白了,
就是让你的属下对你服气。至于汇报工作这一方面,我觉得应该有计划的每周或者每个月开一个终结
会,互相交流经验,这个很重要,因为你是刚刚踏入这个行业,还有很多地方需要跟有经验的同志学
习,面对他们你要显现的虚心一些。
不知道这些话,对你有没有帮助!!

·这种冲突不宜马上有个解决(2004-04-02) [作 者] 唐 [公 司] 北京蓝汛

这算他人的心理障碍,慢慢接受你就可以了,所以要:
创造途径多作私人交往,降低沟通障碍。
实力的展现是非常必要的。
领导是去爱别人,多从他人角度出发,然后才能让别人追随你。

第 213 页 共 756 页
第 1 章 综合管理

·项目经理不是职能经理(2004-04-02) [作 者] 蒋吉波 [公 司] 广东

项目经理不是职能理,你不能以职能经理方式来做项目.建议你换位思考你的组员,多了解他们内心,
应该能找到解决问题的方法.

·将阻力转为动力(2004-04-01) [作 者] 绿野人 [公 司] Inforeverest国际集团全球MES研发中


To Allen.Tian:
从你的题目上来看,你已经把这个现象看的很严重,对于如何帮助你来提高你在团队的威性或说更好
的让你与 Member 沟通,我没有什么好建议,我只是建议一点:把阻力转为动力,这是你锻炼的好机会,
是你展示你个人魅力,发挥你的才能的好机会.努力吧,支持你!

1.25 如何更高效地开展、控制项目?

如何更高效地开展、控制项目?

[姓 名] 秦健 [单 位] 北京市工程项目管理中心 [邮 件] philip218@21cn.com
[所属行业] 综合应用 [所属主题] 项目综合管理 [发布时间] 2004-3-9

【案例正文】
我在国内一大型的科研机构从事管理工作,现在单位组织二十几家单位开发一个项目,现在
处于规划阶段。项目分为三个专题,我们邀请了 9 名专家分成三个组分别编写三个专题的详
细研究内容和计划,现在出现了几个问题:

1.大部分专家工作不积极。由于分属不同的单位,而且与我单位没有隶属关系,各专家只有
在集中时才编写各自的计划,分散后就把该事放到一遍了,为此我们进行了 3 次集中,单任
没有达到很好的效果。
2.由于牵扯到经费的问题,各小组的研究内容有一定程度的重叠,通过协商仍无法有效地解
决。
3.项目开发人员分布在全国各地,项目启动后如何才能有效的控制项目的开发也是一个要很
好考虑的问题。
请问这种项目的管理该如何进行下去?

第 214 页 共 756 页
第 1 章 综合管理

【相关分析】

·拙见!(2004-04-19) [作 者] 李楠 [公 司] 杭州市信雅达软件技术有限公司

从质量管理方面角度来看,项目并不是朝着一个成功的方向发展的。
首先,项目在开展之前,应该有一个可行性报告形成。
其次,项目组成员比较分散,但还应该每个专题找出一个负责人(相当于小项目经理)
,每个小项目
经理根据实际情况制定相应的工作计划,最好用微软的 project,形成 mpp 图,以便日后进行计划的
跟踪。计划固然重要,更重要的是计划的跟踪,否则计划就形同虚设了。
再次,项目应该定期的召开项目例会(包括整个项目组的例会和每个专题项目组的例会)
,因为在例
会上,大家可以很好的沟通。例会后,要形成会议纪要。每周最好有一份项目状态报告形成,这些文
档都属于工作产品,项目的好坏和是否规范都是通过以上形式体现出来的。
项目还要形成风险列表,其中包括整个项目的风险和每个专题项目的风险,要提前预防风险的发生,
采取主动的方式。
每个项目组成员最好每周都填写一份工作情况汇报表,把每周的工作情况记录下来,以便日后做度量
数据的收集。
沟通对整个项目来说也是很重要的。应该掌握一些沟通技巧,要引导大家多进行沟通,这样才能更早
的发现问题。有时候,可以进行人员的搭配,
(有句俗话说,男女搭配,干活不累!也是有一定道理
的。:p)
针对项目组成员分布在不同的地方而言,我认为最好有一套配置管理工具(例如 cvs,vss 等),这样
可以通过网络了解到项目的最新动态,也可以进行版本控制的。

以上是本人的一点拙见!

·路过(2004-04-14) [作 者] 余波 [公 司] 中海石油工程股份有限公司维修公司市场经营部

1.关于这个问题,我们公司在项目运作的时候,也经常遇见,对此,我认为,应该与三个小组的专家
签定一个协议,明确其完成的时间,根据其完成各个里程碑点,给予付款。这其中您可以先支付预付
款担保,并要求其提供与您的担保金额等同的银行包涵。当然这只是个框架而已。
2.你们在与各小组之间签定协议的时候,考虑其研究内容,给其一个总价协议。
3.一个项目的良好运作,关键在于能有一个非常有威信和组织、协调能力的项目经理,根据工作计划,
实现遥控指挥。再者成立一个由各地负责人组成的项目管理委员会,每周或每月安排一次进度会议,
在会议中讨论并解决各个分支项目的运作情况。

·如何更高效地开展、控制项目?(2004-04-01) [作 者] Tomxu [公 司] 中国联通云南分公司数据部

秦健,你好!
看了你的案例后,我有几点意见,希望能给你带来帮助.
首先,我不太清楚你们这个项目的性质和组织情况.依我推测,你们的项目的实施环境是一个体制>效益
的情况,即你和这些专家之间的利益关系好比政府官员与某个行业的专家一样,没有直接的和相对明确
的领导关系和利益关系.这种情况下,仅通过金钱是解决不了问题的,这里牵扯到一些政治手段的问题
(千万别紧张,不要一谈到政治就反感,实际上,无论是一个家庭,企业,还是国家都存在政治,因为个人的

第 215 页 共 756 页
第 1 章 综合管理

背景,成长过程都不一样,所以行为方式,语言表达,欲望和目标也不一样.).所以,我建议你首先搞清楚,你
们企业与各专家,即干系人之间的关系和目标,分析他们的利害关系,权责关系,约束关系后,你才能更清
楚的知道该如何组织项目团队架构,管理项目团队,实施项目.谢谢!

·拙见!(2004-03-24) [作 者] 马渊鸿 [公 司] 安徽朗天

1。我比较赞同三个专题小组各自任命一个专题负责人,由三个专题负责人向项目经理负责,项目经
理管理三个负责人,并向他们下达相关任务。
2。就各小组的专家特长安排项目任务,在经费问题上应该保持基本平衡,任务量相当!
3。异地项目控制的问题,各地负责人对本地专家进行管理,并负责与项目经理沟通与协调的工作,
项目启动后,各地负责人汇总本地项目运作情况,集中向项目经理汇报,项目经理主要负责整个项目
的管理与各小组负责人的沟通协调就可以了!

一点不成熟的看法!!!

·项目实施的可行性(2004-03-23) [作 者] 龙广钱 [公 司] GMC

一个项目启动之前,最关键的是项目的可行性。我认为此项目执行将会非常困难,并且将会需要很多
的资金。

·几点看法(2004-03-22) [作 者] 赵宏伟 [公 司] 东信北邮

此项目处在规划阶段,更多的计划,
项目总是特殊 唯一的,具体的情况就是 组织是松散型的,异地的,空间上 和时间上都是比较难控
制,不过可以
在项目范围方面进行分解之后,当然考虑到可行

· 你提的几个问题(2004-03-22) [作 者] 赵宏伟 [公 司] 东信北邮

1,项目相干系人的积极性调动,相当于分属于不同部门(人力资源管理问题)这个需要沟通,得到
相干系人的领导的支持很重要,要让专家门给你干活需要让他们觉得这个很有兴趣!或者有 money
吸引:)就是如何激励和监督他们咯!
2,有关经济利益问题,这个是很重要的,象此各项目,各个单位都是独立核算的,所以 money 的问
题需要合同来约束! 针对不同小组之间工作内容重叠,就需要之前对工作分解和分工的时候,就做
到责任到每个小组成员,项目范围的界定
3,针对相干系人员在不同地方,对项目进展的控制,这个可以通过项目中分成小项目,每个地方一
个小项目,小项目又是一个相关的项目控制问题,对于整体的控制可以通过对每个小项目的控制管理,
一句话 沟通还是最重要的事情,尤其是这种很松散型的项目组织结构。。。。文字

第 216 页 共 756 页
第 1 章 综合管理

·几点拙见(2004-03-20) [作 者] 123456789 [公 司] 昆明理工大学

首先,在项目确立后要制定详细的计划,针对你们这种大项目,计划要做的非常详细,要具体的每个人.
其次,其次项目正式启动后具体的实施要时刻与计划对比,从中发现计划或者实施中的问题,
最后,至于激励和感情上的问题完全由你的上级和你自身决定,没有什么好说的啊
呵呵
我是新手,请多多执教

·明确问题的来源(2004-03-19) [作 者] 张明龙 [公 司] 网络

本项目可以说是一个比较大的项目,制定本项目必然经过相关的取证,也必有其可实施性。现在有了
问题只是表明初期的方案制定不完善。因此个人认为现在的工作重点不是找出解决某一问题的方式,
更重要的是找出项目出现问题的来源,只用找到了为何有问题才可以说解决问题,也就是要找到问题
的来源。解决问题的方式有好多,上面好多前辈都提出了很独到的见解。此项目继续下去的首要问题
是更正原有计划。
以上是本人一些不成熟的想法,请大家指教

·需要关注的几点问题(2004-03-18) [作 者] 孔祥舜 [公 司] 北京航空航天大学

开门见山。
问题 1,在项目启动时,是否正式成立了项目组,虽然成员隶属各个单位,但是在项目运作的过程中
必须要有一个总负责人也就是项目经理。
问题 2,还是在启动阶段,是否有关于项目界定的说明书,还有项目分工的安排,以及制定项目章程,
再有就是组织配置是否齐全例如,变更控制委员会等。
问题 3,整个项目的运作过程缺乏有效的监控,沟通,协调。

解决的办法:
首先,若以上所提问题存在,那就要首当其冲彻底解决;
其次,对于项目小组碰头会要给予充分地重视,做好准确地沟通,详细地记录会议结果,明确界定各
小组的下次会议前的工作范围,目标。这也是为了能够有法可依;
最后,是关于激励的问题。我认为这就是项目经理的工作了,如果和高层协调好了,应该不会是很大
的问题。

以上是我参考了各位前辈师伯的见地,提出自己的一些愚见,希望能够有所帮助。

·干系人分析(2004-03-18) [作 者] huangbo [公 司] E易电子商务网(www.e-163.com)

这些干系人他们从中能得到什么,是名还是利?

第 217 页 共 756 页
第 1 章 综合管理

即使没有,你也要划一个给他们看看,这就看你的本事了(这叫个人魅力,也就是所谓的感召力吧)。

·如何更高效地开展、控制项目?,(2004-03-17) [作 者] 杨晓勇 [公 司] 四川嘉华企业(集


团)股份有限公司

我个人认为还是计划的问题,没有一个详细的计划安排,导致在运作过程中,出现诸多的问题。但是
现在的问题,我觉得还是应重新调整工作思路,制订新的项目工作计划,具体情况如上面各位前辈所
讲的那样,此处不在阐述!

·问题的关键(2004-03-13) [作 者] 王洁 [公 司] 科兴有限公司

你所提及到三个方面:
1、9 名专家分成三个组分别编写三个专题的详细研究内容和计划
2、牵扯到经费的问题
3、项目开发管理的问题
我主要对 1,2 两个问题发表个人的问题
1、三个专题的详细研究内容和计划在所难免的会出现项目研究的交叉。所以、需要你们详细地分析
项目开发任务、和三个专题,对方案做出合理的调整、当然面对的是专家、你必须更是专家、三个专
题重点是不同的,你有三套方案,你自己的方案呢?其中有一个最关键的问题,专家的态度、你可要
注意、它们对方案的态度太值得怀疑,他们的方案根不用说了,方案如果涉及到经费问题、更加难办
了!注意:他们代表的是什么利益(;P
2、第一个问题解决 对于第二个问题我就不用说了
3、第三个问题、有好多成功的案例,自己去找吧!
呵呵
小弟学说!

·细化项目任务,利益和任务挂钩(2004-03-13) [作 者] 郭道猛 [公 司] 华中师范大学信息管


理系

我觉得首先要做的事是要尽量分析项目所要完成的任务,然后将项目任务细化,让任务责任到人,再通
过激励机制,以促使各成员完成其任务,并将任务流程制成图表(WBS 等),以控制和协调项目进程.其
中最重要的一环就是要将任务细化,制定日进程和周进程.
对于异地的协调问题可以通过任务图表和进程量化在网络上进行协调和控制.
正如以上几为大师所说,只要将说做的事和说得的利益很好的联系起来了,你所剩下的事就是控制项
目进度和目标管理.
对于 WBS 表和进程实际有误差是,也可以通过周进程工作汇报来进行适当修正.

·几点浅见(2004-03-12) [作 者] James li [公 司] use

第 218 页 共 756 页
第 1 章 综合管理

我觉得以下原因是比较值得重视的:
一、组织机构:贵项目的人员组织比较松散,而且项目成败与作为项目干系人的那些专家们的利益关
联比较小,做好做坏对他们影响不大。改正的办法是要么行政干预,要么利益驱动。俗话说“无利不
起早”。

二、沟通是关键:同地项目组沟通尚且费劲,何况异地乎?一定要制定一个例会制度、工作周志制度,
起到督促的作用。

三、需求整理要清晰,然后分解,各个小组分片包干,不存在重叠的问题。

·做好沟通和协调(2004-03-11) [作 者] 赵博 [公 司] 北京华铁海兴科技有限公司

1)制订一个比较明确的沟通计划,规定沟通的有方式(电子邮件、书面文档、电话等)、时间(定期
或非定期)、地点

(远程或集中会议等),将这个计划分别提交给各个小组,征求他们的意见,最后形成一个大家都认
可的沟通模式。

2)加强与专家们的感情交流,获得他们对您工作的理解。经常与各位专家保持联系,尽可能多了解
一定时期内他们的

工作和行程安排,与他们讨论工作时,尽可能不与他们的其它工作发生时间或资源方面的冲突。

3)仔细分析一下各个专家在这个项目上的利益何在,您的工作安排与他们的利益关联得越紧密,工
作就越好开展,然

后还要让他们明白您的安排对他们的好处。

4)在获得他们的好感的前提下,定期地、策略性地给他们适当的压力,比如在对他们表示问候和关
心的时候,然后顺

便问一下他们当前工作进展如何,让他们感觉到不抓紧就不太好意思。

5)对这些专家的学识、阅历和资格要给予充分尊重,但是不要捧得太高,特别是不能让他们认为没
他们某一个人项目

就不能进行下去,最好您所在的机构中也有专家或顾问存在,起一个平衡作用,使这些外部专家感觉
到您所在的单位的

档次也是很高的。应该让他们明白在这个项目上您是老板,他们应该尊重和服从您的安排,不能让他
们轻视您及您的单

第 219 页 共 756 页
第 1 章 综合管理

位。

6)对研究内容重叠的问题,我认为是工作分解结构方面有问题,可能分解得不够细,应该再仔细分
析一下,尽可能消

除这些重叠,然后在讨论究竟哪些人或单位来做这些事情。这方面工作越细,利益分配问题就越小。

7)项目开发人员分散各地的问题与专家的问题相似,如果专家的问题能够协调好,项目开发也就不
成大问题了。

本人见识浅陋,在项目管理方面还是个小学生,胡言几句,定不当之处,敬请高人指点。

·协调、奖励奖惩制度(2004-03-10) [作 者] 江城 [公 司] 厦门国贸集团

我认为可以通过以下两个方式进行:
1、充分发挥你的协调作用。在开展项目过程中,由于你项目特殊性,如果不做好协调工作,项目进
展相信不理想。协调完成各个小组的工作计划,再汇总制定项目完整计划,有些要协调解决的,要充
分沟通,协调解决。
2、建立一套奖惩制度。没有一定的奖励机制,项目参与人员不会有高的积极性。可以从项目参与人
员的利益为切入点,制定梯度奖惩制度。

·项目管理的具体操作方式(2004-03-10) [作 者] 陈名琨 [公 司] 厦门威迪亚建材工业有限公


针对你这个项目,我个人认为目前应先解决以下几个问题:
1。设立项目经理,下属三个小组,小组各设一个负责人
2。由于你们之前已经组织过几次会,各组对自己的任务应该有一定的了解,建议你们重新组织一次
会议,会前要求三个小组针对自己的具体情况把他们认为应该由他们做的全部的工作内容均做一份说
明,可由小组长负责联系其下面组员,收集及整理。在会上对三个小组的具体分工进行讨论,并最终
确定三个小组的工作内容。
3。每个小组针对自己的工作内容做出相应的工作计划来,由小组长进行计划可行性的评估及协调,
并将最终计划上报给项目经理,项目经理再根据三个小组计划进行协调安排,重新调整,并最终确定
各个小组的项目计划。
4。项目进度跟踪:这个环节最重要,建议要求每个项目小组每周进行一次项目进度报告,对与其它
小组有关联的关键点需进行确认,确保整个项目的顺利进行。
5。项目小组长的工作可能会相当繁重
以上是我的浅见,请大家指教

·利益导向的确立(2004-03-10) [作 者] 闫振海 [公 司] 泛友科技

第 220 页 共 756 页
第 1 章 综合管理

项目管理工作的方式各位已经从管理架构、管理模型\沟通协调等方面提出精辟见解,在此不再熬述。
在如此庞大非集约式项目中,如何有效地将项目付诸实施根本的瓶颈来自于项目各组成部分最关心的
莫过于项目本身对自己(公司或者团队)带来的切身利益(主要集中在高层)。
我认为大家应该深层次考虑此项目操作过程中的潜在驱动因素.
(有些突发事情,希望明天能补上)

·加强远程交流促进项目管理(2004-03-09) [作 者] 黄伟 [公 司] 西安交通大学

我觉得你们的现状的确不容乐观,尤其是你们项目成员的不集中,将给整个项目的进度,安排带来很
大的困难。因此,我个人觉得应该在项目开发方面引进一个完善的远程交流合作的平台,可以利用
NETMEETING 来定期召开网络会议促进交流,同时开通一个项目进展平台网站,需要项目成员定时将
自己的成绩,所做的工作文档,进行汇报放到网络平台,同时有效的利用网络平台促进远程交流以及
进度管理,让项目成员明白各自的进度,同时应该做好网络安全方面的工作防止项目资料外泻。至于
经费问题的扯皮应该是高层在对项目定义开发过程中有问题,不应该出现重叠性的工作。如果实在不
行应该,将经费用到真正有能力开发的项目组去,同时把一部分作为激励资金。

·加强远程交流促进项目管理(2004-03-09) [作 者] 黄伟 [公 司] 西安交通大学

我觉得你们的现状的确不容乐观,尤其是你们项目成员的不集中,将给整个项目的进度,安排带来很
大的困难。因此,我个人觉得应该在项目开发方面引进一个完善的远程交流合作的平台,可以利用
NETMEETING 来定期召开网络会议促进交流,同时开通一个项目进展平台网站,需要项目成员定时将
自己的成绩,所做的工作文档,进行汇报放到网络平台,同时有效的利用网络平台促进远程交流以及
进度管理,让项目成员明白各自的进度,同时应该做好网络安全方面的工作防止项目资料外泻。至于
经费问题的扯皮应该是高层在对项目定义开发过程中有问题,不应该出现重叠性的工作。如果实在不
行应该,将经费用到真正有能力开发的项目组去,同时把一部分作为激励资金。

1.26 分包项目现场管理的困惑

分包项目现场管理的困惑

[姓 名] 论坛网友 [单 位] 未知 [邮 件] yifeng@mypm.net
[所属行业] 工程设计安装 [所属主题] 项目综合管理 [发布时间] 2003-12-25

【案例正文】

第 221 页 共 756 页
第 1 章 综合管理

对于项目管理我是个新手,但很对项目管理很感兴趣。以下是我司在外项目管理的现状:
也许谈不上什么管理,请大伙看完之看给出一些建议?

现状:

随着公司业务的发展,由原来主流的室内产品转型到高速公路上应用的产品(ITS)。通常所
面对的有业主、监理、总包方(也就是我们的甲方);首先因为工程量较小(一二百万),且
主要产品在公司工厂生产,现场处理的主要有“基础及钢结构”的施工,由于是总包的分包所
以一般的工期都比较紧。目前我司的做法如下:

1、 市场部拿到订单后,把技术文件交到工程部,然后由总经理或工程部经理直接任命项目经
理,一般情况是上午通知你下午或第二天上午就得出发去现场,项目经理连现场的情况都不清
楚;同时还有公司采购部门有位采购员一同去现场找基础施工及结构制作厂商。

2、 项目经理到了现场之后,总包及监理方都认为来的这位项目经理什么都懂,要求马上得开
工,且要求相应的开工申请、施工组织计划、及施工图纸其它的资料。由于公司没有配备手提
电脑,一般的台式机项目经理都不带(还有部分项目经理不会使用 PC),所以这些文件资料
都反馈到公司由公司人员帮其编写,然而公司人员并不能完全的知道现场的环境,所以所编写
的资料部分不能令监理及总包满意。不满意就会打电话投诉到公司领导处及市场部,公司的领
导就不断的给公司编写人员压力且不能理解为什么不能令监理及总包满意的原因在哪?经过
无数次的电话联系、修改才能勉强符合要求。

3、 说是说项目经理然后项目部前期就是项目经理一人,到后期公司的产品到了现场安装后将
会有二到三人过现场协助安装。

4、 现开展的大部分项目工地上大小的事情都往公司反馈叫公司拿方案,项目经理在现场不能
合理的安排好自己工程上的事物(也许也是公司在经费上卡的严的因素),公司工程部在家的
二个人在公司领导的压力下给各个项目出解决方案,出了方案不要紧,如果是方案在现场实施
时出了问题,这两个人就惨了,问题都落到这两人头上。也就是说大部分的工作是由这二人完
成的。

5、 公司领导要求,每个在外施工的项目每天要传回“施工日志”一份,每周要传回“工作周
报一份”,每月要传回“租房费用申请单”一份等,一月的传真费在:300 人民币以上。

6、 项目经理外出的补助非常低,且没有岗位工资,大部分出去的人员加上补助还得亏上点钱。

7、 没有什么“项目目标责任书”,及其它的项目管理相关的文件。</P

当然还有些公司的管理制度上的问题,在这里我只想问,像这种分包公司怎么来组织开展
项目管理,怎么做到高效率的施工? 多谢!

第 222 页 共 756 页
第 1 章 综合管理

【相关分析】

·做好前期计划,加倍进行沟通(2004-04-18) [作 者] 王健 [公 司] 天津开发区泰达国际咨询监理有限公

从你叙述的情况来看,这家公司规模并不大,为了节约成本,相对来说就会在很多方面只是做出个外
壳,而其实里面到底有多少东西就很难说啦,前面的一些朋友谈的一些论点和意见都不错,但是建筑
业的不规范是大家都清楚的,举个例子:我们都知道,很多工程项目上给排水和暖通是两个专业的工
作,但因为它在一般工程管理中的比重问题,经常会出现一人身兼两职的情况。加之,现在的项目一
律都要求较高,甲方都希望自己的工程管理过程是由一些有经验、有能力的人来完成,而当这个项目
利润很低(现在很多项目都采取“最低价中标”的评选方式)或为了获取更多的利润时,公司就会安排
一些非甲方要求的层次的人员进行工作,造成甲方与监理的不断投诉(当他们发现贵公司派遣的人员
并非他们想想的那么完美,他们就会不断发难)
。关键的问题是怎样进行沟通,其实主动权在你们一
侧,不过要看是由项目经理来进行,还是由公司来进行(因为你们的项目经理好像并不能真正称之为
项目经理)。
建议:提前做出管理计划(可以是多个方案,至少是两个)
,勤与监理进行沟通,虽然现在有很多监
理不太按行业规定办事,但是如果你能在他考虑一些问题之前,已经开始考虑,并向他提建议或征询
意见,这样他会感觉到你们是真正在用心做这个项目,也就会换而真心的帮助你们、指点你们(因为
监理也是要承担很多责任的,他的工作职责就是怎样使工程顺利,甚至更好的完成)。
一点个人看法,仅供参考。

·分工明确,沟通不足——项目管理失败(2004-02-14) [作 者] 彭桃平 [公 司] 杭州中佳实业投资有限


公司

看起来,该公司的分工非常的明确,似乎到了划清界限的地步。而一项工作,往往是需要多方的配合,
该公司问题正是出在配合上。信息无法得到及时的沟通,专业设置过细过狭隘,往往导致专业的理论
化,目标的层次化和责任的模糊化。这都需要公司领导层加强项目管理,作好是有一个很好的配合计
划。及时集体研究讨论工作的分配和协作,同时就是要为各专业人员充一下行业知识的电,这很重要。

·建议(2004-02-02) [作 者] bushi [公 司] ::

建议在适当的时机,在你的公司内部(特别是中高层)进行项目管理的相关的培训。刚开始的时候不
用讲得太深,办成扫盲班,让他们至少知道正规的做法是什么样的。尽量引导他们发现自己的不足。

·重新评估自己的选择(2004-01-15) [作 者] bluesutone [公 司] 12

长久以来形成的企业文化根深蒂固,先入为主,要想将现代企业管理理念灌输进该公司上上下下,难
呐!不比另成立一个公司难。

·解决问题的建议(2004-01-05) [作 者] doknowing [公 司] :)

第 223 页 共 756 页
第 1 章 综合管理

简略谈几点:
一、现状:
1、领导不懂“管理”,且没有相关的意识;
2、中、基层目前仍按公司原有流程、办法工作,尚未有人提出“证据充分、可行性强、效益显见”的
管理方案来。
3、你在实际工作中感觉、发现到了一些问题,并且想解决它们。
二、基本建议:
1、可以先做一下这项工作:分析并绘制出现有流程、办法。
2、接着分析、总结出现有流程中各工序中的“部门、人员职责”,以及工序间的“交接界面”。
3、对 1、2 两条的结果进行分析,以其为基本点,归纳出“基级”的问题。----所谓“基级”,即是由基
本点可以直接得出的,显而易见的问题。----注意尽量不要延伸、演绎。
4、针对 3 所归纳出的问题,寻找“证据”,一两个就可以了。
5、在下一次,工作中出现上述问题中的某一个时,你恰逢其事,呵,大胆地向领导进言吧!当然,我
相信,在上面 1234 的过程中,你应该已经有了解决这些“基级问题”的合理方案了吧。
三、进阶建议:
1、在没有完成基本建议 1234 步聚,并有了解决方案前,紧记“勿言他失”。言完他失,却给不出一个
更优的办法来,是很要不得的。
2、在没有获得你的领导相当信任和欣赏前,最好不存有“一跃而为众人先”的想法。因为,一个再好
的方案,没有领导的相当支持和基层的认真执行,你一个人,是推动不了的。
3、如果可能,可以考虑从“总包”处“借力”。
4、最后一条建议:改造你的老板难度极高,要有“育幼”的思想准备,才能进行这项工作。
四、说明:
1、呵,第一条是,如果上述的话你看不懂,请先多阅读,我向来不怎么负责解释的。
2、如果存在不同意见,呵,不用讨论,请按你自己的想法去做吧。
3、我只是向你建议了如何解决这些问题的一种方法,你公司存在的问题,很多高手都已从各个角度
论述过了,请你自己汇集。

·没有眼光的暴发户行为(2004-01-03) [作 者] p3china [公 司] 北京

恕我直言吧,我认为贵公司目前面临的问题 80%以上应该归咎于企业领导,具体表现在:

1、目光短视,没有长远发展方向;
2、没有服务观、客户观;浑水摸鱼、一锤子买卖;
3、授权与信任危机问题;
4、没有建立系统的项目管理的概念;
5、不支持员工的培训与激励;
6、沟通系统不健全;
7、没有真正的项目经理。

关键是领导者的素质,如果他们小农意识,那么这样的公司就没有未来。

第 224 页 共 756 页
第 1 章 综合管理

·和(2003-12-31) [作 者] 姜延峰 [公 司] 信息管理中心

信任的問題。家族式企業的權利不能下放,一方面是後及人才的能力問題,但最主要的是信任的問題。
同時由於溝通渠道的狹窄(金字塔頂端直接聯係的舊是下面的 2 塊磚),很難了解實際的情況。我想
最實際的情況,可能是公司的領導並沒有全面的了解到您提到的情況,如果想要能夠解決您的問題,
我建議做一個完整清晰,並標明問題的項目流程圖,通過可以說得上話的經理,提交給強勢或者合適
的領導看看,如果沒什麽動靜。那就閃人吧。

·对项目经理的定位以及沟通问题(2003-12-30) [作 者] 闫振海 [公 司] 泛友科技

沟通问题在以往的案例中大家分析的比较多了,这里就不再熬述了,最要一点仍然体现在家族式的企
业文化观念没有改观,没有达到权力的稀释作用,也即没有实现职业化管理的转变。
从个人对项目管理的理解中认为该项目经理只不过是一个在执行合同期间贵公司委派的一名现场代
表,无法实现项目中任何的建议以及参与决策的权力;再者其无权利实现项目小组的组建、无法对项
目的评估以及项目协调的作用,从而报漏出项目维系的脆弱性以及隐含的分险。
原先也提到目前好多企业中普遍存在这种现象,认为任何一个可信任的人都会成为 xx 经理,代表公
司对外的一切活动,或者作为公司的形象工程的使者,这需要在两个方面考虑:一、他到底能不能切
实的承担并完成好这种使命,二、公司是否赋予与其职位相应的权限?这些方面贵公司好像都不具备,
已经成为一个企业经营与管理范畴的问题。

· 分包项目现场管理的困惑 (2003-12-30) [作 者] 邓成永 [公 司] 天光科技

贵公司的项目实施过程其实是参照你们以前的成功经念模式。
建议贵公司的领导和项目经理多参加项目管理的培训和内部员工的培训。

1.27 项目经理 A 的苦恼

项目经理 A 的苦恼

[姓 名] leeyuu [单 位] PMU [邮 件] liyu@mypm.net


[所属行业] IT 软件 [所属主题] 项目综合管理 [发布时间] 2003-5-12

【案例正文】
A 是去年二月份刚进入软件公司的,2001 届的软件本科毕业生。在公司最开始是做程序员,

第 225 页 共 756 页
第 1 章 综合管理

后来公司准备上马 j2ee,那时候公司没这方面的高手,A 和一群同事就看书学,后来 A 接手


了整个中间层到数据库这一部分的工作,作出了一定成绩。后面 A 还接触了一些主要是 awt
的东西,写可编辑的界面。并承担了一个大项目的部分分析任务。

2003 年春节前,公司任命 A 为某方案项目经理。春节以后,项目就开始着手准备。除了 A 以


外,还有一个主要负责技术监督的项目经理,A 负责人员调配。下面设各小组长。技术经理
和一个小组长都是公司公认的高手。很快 A 就发现她是整个项目团队中最不需要的人。技术
也好,文档方案也好都不必 A 动手,而且大家对公司对 A 的这个安排也并不服气。A 本着以
工作为重的原则保持忍让,认为公司安排给她的不过是个秘书角色,但随着项目发展,A 越
发对自己没信心。下面和上面的人直接通话,有些事情 A 都不知道,例如组员请假、人员重
新调整拉等等。项目组开始的时候有 20 个人,现在只有刚过半的人了。而人员调整的事情,
是公司出面与小组决定的,A 竟然不知道。技术上的事情,A 已经插不上手,她很怀疑公司
要拿出去的软件里面到底有没有过她的代码,也很怀疑原先在技术上她是不是还有一小点别
人可学习的地方。然而谁都觉得 A 从公司的这个安排中捡了大便宜。A 现在没事情的时候还
是学着写写代码,各个小组已经进入开发阶段,A 是更插不上手了的。她现在的想法就是尽
快结束项目,完成任务。

A 认为她既没有技术经验,社会经验也不够丰富,因此不适合做项目经理。各位对她的看法
和经历有什么看法呢。

【相关分析】

·如果专业不会干就做项目经理吧(2008-07-16) [作 者] dajundalao [公 司] 暂时保密

A 是那种被公司拔苗助长的主儿,而且公司用的刚好是她的短处而不是她的长处。这种现象在国有企
业很普遍:公司会认为,既然她这也行,那么她那也行,结果,这些速成的人肯定不能让下面的人服
气,同时这些速成的人如果不及时转变自己,那他就可能早早地陨落。
案例中 A 并没得到公司大多数的认可,包括项目团队。为什么会这样?一是 A 没有威信,二是 A 不
懂管理更项目不懂项目管理。再者,她原来在技术专业方面小有成就,对人员管理是张白纸,也不知
公司的领导脑袋怎么让车门子挤了,就这么安排,因而 A 不明白如何管理人力资源,当然别人只能
把 A 当摆设,被机构架空(不是被人架空)。
其实做项目经理与做专业是两个路子。做项目经理可以不明白专业性的东西,他只要懂管理就行,如
同杀猪匠不必成为生物学家,他懂得如何一刀让猪毙命、如何把猪毛刮净、懂得消费者需要什么样的
肉以及卖什么价就行。如果专业不会干,就做项目经理吧,会干专业,很可能把项目与专业衡量比较
起来干,如同老乡从外面拣了个大清花瓷碗回来,觉得又大又笨重无多大用,就觉得还是用它来喂猫
合适。
如果公司就是要拿项目为代价来培养 A,那么 A 会在经历数个项目、并不断地学习和提高后才能懂
得如何来管理项目、如何来当项目经理。
当然,亏的是谁,大家都知道。

·Talk to her boss(2008-06-14) [作 者] chow king lam [公 司] beria consultants limited

第 226 页 共 756 页
第 1 章 综合管理

I think "A" should talk to her boss and understand what is the boss' expectation of her.

·补充(2008-03-12) [作 者] 许 [公 司] eam

A 可以多与技术骨干和组长交流,多了解他们现有的困难,如果 A 能解决他们的问题,就能迅速建
立自己的威信。

·没有技术照样可以做PM(2008-03-12) [作 者] 许 [公 司] eam

项目经理不需要是技术高手,但一定要了解业务,要有驾驭团队的能力。

A 显然经验不足,在接手 PM 之前应该取得管理层的充分支持,不然工作很难做。

·解决的办法(2008-02-27) [作 者] 何将军 [公 司] 南京卡索系统工程有限公司

一、制定详细的项目计划和进度计划并提交管理层,最好签字确认;
二、客观分析目前实际进度;
1.如果比你的计划进度快,你可以不用多说,继续跟踪观察;
2.如果比你的计划进度慢,你可以提出切实可行的手段,挽回局面
三、分析项目进行过程中的不足之处,提出补救措施;
四、先不要急于管理,先取得管理层正式的、明确的项目授权;
五、树立威信!

·加强沟通,自身做起(2007-12-07) [作 者] 王晓明 [公 司] 中铁十一局一公司

从点滴做起,做好人员结构配置,提升自身人格魅力,加强沟通。

·A缺少自信(2007-11-30) [作 者] snock [公 司] 广州某软件公司

从文中看出,显然 A 缺少自信,又没能获得领导的扶持,导致无法履行项目经理的职责,在这种情况
下,A 肯定不是项目经理的合适人选.建议 A 先从一些小项目着手,多积累点经验.

·项目经理A的苦恼(2007-11-07) [作 者] liuwei [公 司] 珠海市安克电子技术有限公司

主要原因还是沟通能力欠缺,还有就是个人魅力不足,这是搞技术行业的通病,大多数人专心于技术方
面,社交方面的能力自然会忽视,当然有少部分人两方面还是可以兼顾的,现在主要的是能够及时的发
现自己的问题所在,拿来和大家分享解决就是一种很不错的途径.不要有问题连不知道自己都不知道,
那才是最可怕的.

第 227 页 共 756 页
第 1 章 综合管理

·经验和管理(2007-08-30) [作 者] 刘鹏程 [公 司] 郑州鹏程水处理有限公司

技术,可能你不是非常专业,但是既然任命你为项目经理。并且是人员方面的,那就需要仔细把项目
部人员框架布置好,通过调动项目组员的积极性来让项目顺利进行!
管理和技术经验是两吗事,要分开,不是没有技术能力的也能管好一个团队,带领他们前进吗。关键
是如何勾绘项目部!

·明确的组织结构和沟通渠道(2007-08-30) [作 者] tjh [公 司] cxgs

首先是 A 必须为她所在的项目团队画出一个清晰的组织结构框架,然后,获得公司上层的授权,把组
织结构图在整个项目团队里惯切。每一个项目组员都要明白各自的位置和任务。第二个是,组织里必
须有一个清晰的沟通渠道模式,每个成员所负责的事情向谁报告,及命令怎么样下达,沟通所采用的
方法和载体,都需要明确。
项目经理应该更注重管理方面的工作而不是技术上的问题,特别是当一个项目是有多个部门、公司、
或者事业实体合作的时候,管理就变的更加重要。

·角色的转变(2007-08-28) [作 者] 董新山 [公 司] 荣文灯饰(东莞)有限公司

A 在做项目经理时,应该知道项目的整个流程运作模式,自己承担的工作,不等着领导去下命令!要
认识到管理的真正的内涵,怎样让项目进行的顺利在你的协调下,站在主动位置!

·存在的必要(2005-04-17) [作 者] 王冬 [公 司] 华东理工大学

管理的意义之一就是帮助别人完成工作.A 仿佛已经被架空,应该找到需要自己发挥作用的地方,至于
用什么手段又要具体问题具体分析了.

·存在的必要(2005-04-17) [作 者] 王冬 [公 司] 华东理工大学

管理的意义之一就是帮助别人完成工作.A 仿佛已经被架空,应该找到需要自己发挥作用的地方,至于
用什么手段又要具体问题具体分析了.

·明确的组织结构和沟通渠道(2004-12-10) [作 者] 文荣鑫 [公 司] 无

我想首先是 A 必须为她所在的项目团队画出一个清晰的组织结构框架,然后,获得公司上层的授权,
把组织结构图在整个项目团队里惯切。每一个项目组员都要明白各自的位置和任务。第二个是,组织
里必须有一个清晰的沟通渠道模式,每个成员所负责的事情向谁报告,及命令怎么样下达,沟通所采

第 228 页 共 756 页
第 1 章 综合管理

用的方法和载体,都需要明确。
项目经理应该更注重管理方面的工作而不是技术上的问题,特别是当一个项目是有多个部门、公司、
或者事业实体合作的时候,管理就变的更加重要。

·亡羊补牢,为时不晚(2004-12-05) [作 者] 李林 [公 司] 中铝青海分公司

项目经理掌握者,财权、人权。可以说项目经理在什么时候在主动的位置,只不过位置上的控制权能
力的大小。但能力大小就在沟通的方式和力度。
年轻人的机会不错,但应该让自己成为中心。更何况一个项目中技术工作只是其中的一部分。

·A太缺乏经验(2004-04-20) [作 者] 徐 [公 司] 龙信科技

坦白讲 A 这个案例是比较失败的,就目前的情况来说做什么恐怕都有些晚了,没有自己的代码怕什
么?项目经理本来就不是程序员。当然在我们这个行业里,不懂技术会被小组成员瞧不起,但是也完
全没有必要去和技术人员去比拼技术比拼代码,工作性质的不同对人的要求也不同。总的感觉 a 失败
的主要原因是她的经验不够,同时对自己角色的理解和定位都不是很准确。以致造成无法挽回的后果。

·研发人员到管理人员的苦恼(2004-01-18) [作 者] 董三 [公 司] IBM

1、首先公司需要有完善的任职资格体系,提拔一个员工承担一定责任时需要相应的培训
2、项目组成员内部的职责需要划分
3、项目组需要开工会,明确成员与每个人的职责及其汇报关系

·一点小看法。(2003-11-16) [作 者] Erwin Y.C. Tung [公 司] ISD

这是一个定位的问题,请考虑自己在那个团队中究竟能够和适合干什么。

·权宜之计(2003-08-19) [作 者] 徐远飞 [公 司] 软件

你能管理他们,是因为你能担的起项目失败的责任

可以要求老总把你拉去骂一顿,然后你回去开掉几个不重要的人,然后对他们说!:“你们的责任我
替你们背下了,我没有出卖你们,希望你们能够配合我的工作。”权宜之计

·最难第一次(2003-08-07) [作 者] 韩松 [公 司] 武汉凯迪

第 229 页 共 756 页
第 1 章 综合管理

从该案例可以看出 A 在 j2ee 项目中是作出了相当不错的成绩(估计是技术方面)让领导赏识,从而


在接下来的项目中让其担任项目经理的,然而,做技术和做管理是两种差别很大的事情,技术较单一,
只要责任心强,容易出成绩;而管理,我个人认为,大多数人,如果不是学管理专业的,在学校里没
在学生会混过且混得不错的人,在毕业后的短短一两年内是很难学会管理好一个团队的。案例中的 A
显然是没有充足的思想准备迎接他的新角色,就象做技术的和跑市场的,跑市场的说搞技术的除了画
画图,做做标书外什么都不知道,做技术的说跑市场的除了请客吃饭外还能做什么。
我想就目前 A 的处境,临时抱佛脚来看项目管理书籍,恐怕是来不及了,而突然一反常态地与团队其
他成员搞“沟通”,也很有可能会引起其他的误解和猜疑。如 A 不采取措施而象现在这样“想尽快结
束项目,完成任务”,那么这个“项目经理”的经历对 A 肯定是个沉重的打击,而且在以后的日子里,
领导可能再不会给你这样的锻炼机会了。在公司里,同事之间多多少少会存在一些利益冲突,木秀于
林,风必催之,作为项目经理去管理以往平级的同事肯定也会遇到一些意想不到的困难。
如果我是 A 的话,眼下要做的事是尽快参与做一些公认比较困难、团队其他成员不愿做的技术活,毕
竟 A 在这方面还是有优势的,找回一点自信,也让团队其他成员信服,管理全局不行,管理好局部也
是好的,总比灰心丧气好;同时一定要注意与领导搞好沟通,必要时请领导出谋划策,只要方法得当,
领导是乐于为你支招的,毕竟你是在为他做事,而且我觉得每个人内心深处都有“好为人师”虚荣心。
至于其他 A 要做的,实在不是一时能学得来的,不管这个项目管理得成功与否,在项目完了之后,A
都一定好好总结一下,好为管理好以后的项目打基础。
以上是我个人的一点看法,不对之处还请朋友们批评指正!

·角色的变化(2003-07-23) [作 者] 项目管理者之一 [公 司] 无

我也是做软件开发的,现在在做项目经理,我想 A 的问题是没有对自己的角色做新的计划,这个本身
就是一个项目。人是年青了一些,这么早做项目经理,要多学一些项目管理上的知识,不要还在技术
上想有什么长远的进步,并与公司其他人的比较。看上面的案例,A 公司的领导还是对 A 有信任与期
望的,A 要再进一步做出与上层的沟通工作,第二,A 没有在项目的开始做 WBS,并且没有做实际上
的控制。也可以判断 A 所在的公司也是没有项目管理的经验,从组织上也不能适应项目管理的需要。

·让自己给别人做帮手:)(2003-07-17) [作 者] 孟晓林 [公 司] 网络业务部

项目经理的主要责任就是分配任务,自己就是去协调各个岗位之间的关系,在大家忙不过来的时候给
家帮助。本着学习的态度和每个岗位的人进行沟通,进自己最大的能力帮助没个需要帮助的人,这些
就够了:)

·项目经理不是那么容易做的(2003-07-15) [作 者] 田京平 [公 司] UNIHUB PMO

不仅需要有一定的技术背景,重要的是要有丰富的工作经验。大部分人都要遇到 A 的这种情况,毕竟
目前国内公司的项目管理意识不强阿,就作为自己的经验积累好了。

第 230 页 共 756 页
第 1 章 综合管理

·估计这个公司都没有推行项目管理,太混乱。(2003-07-06) [作 者] gxq [公 司] xxx

2001 年及以后毕业的,没有资格做项目经理(经验不足);
A 没有做好定位,认清项目经理的职责,A 完全可以不去做任何具体软件开发工作,但是 A 要规划监
督控制好整个项目按计划完成,满足 PCTS,向上级汇报进展状况等.
建议进行管理培训。

·do it youself(2003-06-29) [作 者] 李军 [公 司] 南京

我不是 A 的同行,但做为项目经理则有很多相似之处,我开始时也有同样的情况,在我一阵思想的痛
苦之后,作了以下几点:
1、明确自己的权利与责任
2、看到责任的内容,从而行使自己的权利
3、管理者不必知道太多的专业知识,是帅而不是将才
现在可以说我已成为我这个项目的核心,其实这里面有很多要自己好好体会

·自责并决心改进(2003-06-24) [作 者] 石敬辉 [公 司] 邢台路桥建设总公司

技术经验、社会经验可以通过学习及在日常工作中日积月累来丰富。通过本项目来评价自己是否适合
并胜任项目经理的岗位。如果能够判断自己喜欢并适合这个岗位,应抓住这次机会通过采用培训学习
掌握项目管理知识、主动与上级领导沟通了解其意图、与项目组其他成员谈话逐步获得他人的信任及
支持等措施来提高完善自己。

·Re(2003-06-18) [作 者] 王书成 [公 司] 项目部

项目经理一般是有技术方面升上去的,主要是角色转化的问题,技术人员是完成某一个特定的目标,
只有一种方法解决的。而项目经理,作为一个管理者是协调、计划、安排等工作,自己感觉没有做什
么东西,但实质上这方面很重要,风驰传媒的老总是学台拳道的,他领导的公司现在还不是行业的龙
头吗。主要是怎样发挥自己的长处,协调好个部门的关系,明确知己的权利。

·项目经理,人的能力(2003-06-11) [作 者] jim [公 司] world

个人觉得,一个人是否胜任某个职位,他的为人处世远远超过其他方面的能力!在很多场合大家都能
看到这样的例子,一个人对某个行业完全是外行,但是却能在这个行业里领导一批优秀的人才创造奇
迹!鲁冠球就是一个例子,小学文化!

第 231 页 共 756 页
第 1 章 综合管理

·当有技术人员转为项目负责时很多这种情况(2003-06-09) [作 者] 焦贵兵 [公 司] 软件公司

我个人认为,首先给自己定位,同时知道自己的权利和责任
其次,考虑自己的经验和能力,能否胜任

·首先要确定权限(2003-06-08) [作 者] 郭广云 [公 司] 中国船舶工业集团公司船舶系统工程


既然 A 是项目经理,首先就应该了解自已有什么权力,需要对什么负责。属于自己权力范围的事情要
主动与各方面沟通。如果自己属下的调动自己都不知道,只能说明 A 太不称职或者说公司管理实在太
混乱。

·主动性应该加强(2003-06-06) [作 者] yuanhai [公 司] 创联软件

项目经理应该能协调各方的资源,而不是象 A 等这领导或者公司来协调关系。应该积极的沟通和交流,
而不是被动的听从和被安排。

·沟通、理解(2003-05-27) [作 者] 至尊月 [公 司] 项目管理部

项目经理最主要的工作任务应该是:制定计划,安排任务,上下级之间的沟通枢纽,掌握和控制项目
的进度,保证项目成功结束,核算项目成本。
项目经理的技能:发现组员的长处和短处,及时发现(或预见)项目(可能)存在的问题,及时与相
关人员沟通(客户、上下级,其他技术人员和相关人员等),体谅他人(理解程序员、客户、上级领
导等的抱怨,)。

其中沟通是最主要的事情。
一定要保持心平气和——争吵永远解决不了问题。

·Re(2003-05-25) [作 者] 林昊 [公 司] 深圳科健

就如第一位回答的一样,项目经理不是天生的,大多数项目经理都是从技术升上去的,开始可能都很
难适应作为一个项目经理的责任,觉得其实应该多看看相关的项目管理方面的书籍,对于 A,个人觉
得首先应该考虑清楚自己的发展方向,如果觉得自己对于管理方面兴趣不是很大的话干脆就和公司说
明,如感兴趣的话那就首先要改变自己,向很多项目经理多多学习。

·项目经理不是天生的(2003-05-23) [作 者] 陈博 [公 司] 长天集团政府事业部

第 232 页 共 756 页
第 1 章 综合管理

1.A 的目标:项目成功,而项目成功的标志就是在预算或是可接受的工期及工时范围内完成项目取得
客户的认同,这是项目经理最主要的事,所有的一切努力都是为了这个目标。
2.A 做得对的地方:
以工作为重的原则保持忍让,这样保证了整个项目团队的一个基本的合作的可能性,是项目能够继续
开展,至少比不懂还要乱插手强多了。
学着写写代码,虽然技术不是项目经理的不要钻技术的牛角尖,不过在这种情况(现在大多数软件公
司都是这样)下,还是要做一点技术的积累,关键是积累的方向。
有一个主要负责技术监督的项目经理,这也应该是项目能够进行的关键,事实上目前大多数项目经理
同时担负了技术监督的职责
我觉得前面大家给的建议很好,另外加一点,A 可以逐步推行一些项目各方面的规范(包括人员调动
等项目事件),一个好的规范其价值自然会体现在整个项目中。再有就是项目经理不是天生的,每个
人的境遇不同但都有一个成长的过程,努力吧。

·Re(2003-05-20) [作 者] 过江龙 [公 司] 软件

2001 年。。2003 年,坦白的讲,A 绝对不够资历担任项目经理。


还好,本人曾经历,见识过两个完全没有软件背景的人做经理,供参考吧。失败的最大原因是不懂装
懂。。越是怕下属说不懂,越要装懂!
这种情况下,一定要有一个武林高手做指导,得到他的全力支持!
二是勇敢的承认自己技术的不足,得到下属的认可;
三是抓紧搞明白软件开发的全过程,Requirement Analysis, Structure, Design(System, class, If
have database),Coding, Debugging, Integration, testing.....
以弥补技术的不足。

·苦恼的解脱(2003-05-19) [作 者] 张清俭 [公 司] 大连

高级管理层对 A 的态度这里表述的不是很清楚,我如果是 A:
1、和上级沟通。就象前面几个说的那样,A 能够成为项目经理,高层是有一定原因的,也是有用意
的。可能高层不想让 A 知道,但对 A 的要求 A 应该很清楚。
2、和下级沟通。经常的和下级沟通才能够了解最新的资料,对他人越格的地方也能够及时发现并采
取措施。
3、干系人分析。对质量项目经理和关键的小组长进行分析,了解他们的要求和愿望。
4、不要气馁。生活中、工作中,不如意的事是经常的,要对自己正确的定位,这个项目还没有结束,
还有机会改变他人对你的认识。
5、发挥自己的长处和优势,对自己要自信,完成从一个技术人员到管理人员的转变。

·给高层的一点提示(2003-05-15) [作 者] 龚喜杰 [公 司] aerostrong

第 233 页 共 756 页
第 1 章 综合管理

在这个案例中,A 是失败的,这也是很多项目经理成长过程中要经历的。以上各位的分析大多从 A 的
角度出发的,我也非常的认同,定位不准、没有及时变更自己的角色和责任。但是我想从另外一个方
面来思考,从公司的高层来探讨 A 所遇到的问题。既然要让没有项目管理经验的 A 做项目经理,我想
公司肯定是想培养 A。但是我认为公司做的不够好,没有为 A 创造一个良好的环境。公司在如下几个
方面做的不够好:
应公开申明和强调 A 的角色,树立 A 的权威;
不应越过 A 直接和项目组成员协商;
不鼓励项目组成员越级汇报;
庭院里练不出千里马,项目经理的成长也需要一个好的环境支持。

·从现在开始改变自己(2003-05-15) [作 者] wing [公 司] SIEMENS

项目刚刚进行到一半,还来得及挽回。从现在开始改变自己的工作方式。
1 加强沟通,一方面是与下面的沟通,包括技术经理和小组长及没一个成员,如楼上所说建立权威;
另一方面是与领导层的沟通,注意:是沟通而不是打小报告,领导曾既已任命 A 为项目经理就一定会
给予支持的。在一个 team 中沟通是最重要的,项目经理是所有沟通渠道的中心,从现在开始负起项
目经理的责任来!
2 多学一些项目管理方面的知识,不要钻技术的牛角尖。

一些粗浅的建议,望笑纳。
但要知道 A 在该公司的处境目前不好,如不马上有所改变,无论项目成败,都不会再有做项目经理的
机会了。

·项目经理的职责(2003-05-14) [作 者] 连波 [公 司] hijoy

1.从项目立项开始,A 就应该规划整个项目组织架构并编写各队员包括项目经理的职责,然后给公司
审批。项目经理有项目经理的职责,如果明确了,就不会出现 A 在项目实施过程中没有用的情况了;
2.项目经理的职责是项目管理,他需要掌握项目管理的知识,对技术的东西只需要有所了解。沟通管
理是项目管理的重要一项,A 应该很好掌握并运用;

·以静制动(2003-05-14) [作 者] fatbig [公 司] MyHome

一个人总是有自己的优点的。这种情况下,要以静制动。

以静镇之。坚持完成自己的工作。

好处有以下:
1。提高自己的坚韧性。这往往是最让人敬佩的。争来争去的人只能得于一时。

第 234 页 共 756 页
第 1 章 综合管理

2。放松自己,能够和别人改善关系。只要项目够长,和你熟悉了,就不好不给你面子。
3。逆境中的学习,最是使人上进。如果下一个项目,主持的还是你,相信你应该已经能够站稳站好。
4。静可以致远。可以比别人早一步发现问题。不用你亲自作什么,当别人每次都发现自己想提的要
求和出现的问题,在你的邮件中都已经提到过了。你的位置就无法动摇了。

·改变心态,坚持原则,坚守阵地(2003-05-14) [作 者] 黄鹤 [公 司] 北京汇邦科技有限公司

新手上路,刚开始都会患得患失,放不开手脚,缺乏勇气,该管的不敢管,长期以往, 才导致目前
的局面!所以,A 应该再逐步的建立自己的威信,增强勇气,该管的要坚决管,夯实自己的阵地,不
要让别人轻易去挑战权威,否则慢慢的就会变动无足轻重,形同虚设,无视你的存在!要知道,权威
是使整个系统平衡并且前进的保证,,
A 刚从技术升为项目经理,需要摆脱原有的思维模式,认清角色,重新定义自己的职责----以最小的
成本,在最短的时间内保质保量的项目,至于软件内有没有你的代码,我觉得越少越好,最好没有,
有你的灵魂就行。
注意领导的艺术,培养领导的心理素质;我相信从下一个项目开始,A 的状态会大为改变,毕竟现在
是最困难的过渡期。

·自信、积极(2003-05-13) [作 者] 马静伯 [公 司] 化讯信息技术

从公司的这个安排来看:A 既没有技术特长也有没业务特长,那么选 A 作项目经理的原因可能有两个:


1、A 是一个有潜力的人,公司着重于培养
2、A 是一个工作态度好的人,而且社交能力出众,因为“A 负责人员调配”。
而最后 A 被项目所架空的主要原因在于自己。他应弄清楚高层用他的原因,也就等同于高层期望他发
挥什么样的作用。这样,在工作是就可以把握正确的方向。
另外,同事的排斥心理也是一个因素,按我的经验,一个新人初作领导,大多会有人不服,但是随着
时间的推移,这种现象就会慢慢弱化,但这取决于 A 要有足够的自信和积极的态度。而案例中的 A
好像恰恰缺少这两点,这也是导致这种情况的主要原因。

·确实很多这样的情况。(2003-05-13) [作 者] 卢池鱼 [公 司] gd

这个的话,自己先要把自己放到经理的这个角度,如果像上面说的那样,我想这个公司也不规范,要
是我,公司调人都直接掉,我就辞项目经理的位置。项目经理要负责整个项目的协调。与上面和下面
的技术人员的沟通,我觉得 A 她最缺少的就是沟通。

·初为项目经理(2003-05-13) [作 者] 陈荣森 [公 司] 研发部门

“没有技术 J2EE 方面的经验,就不合适做项目经理”。 这种观点是错误的。A 失败的关键可能是 A

第 235 页 共 756 页
第 1 章 综合管理

没有真正发挥公司对她所期望的作用。公司提拔她的理由是 A 虽然没有 J2EE 技术经验,但 A 毕竟做


过了两年多的编程、分析的工作,对整个软件项目管理的过程应该比较了解。所以公司希望 A 在项目
管理工作中能很好地定义项目,带领团队完成需求分析,并在定义合适的项目组织结构及岗位安排,
工作分解结构 WBS,产品结构 PBS,进度计划,预算,质量控制等项目管理环节中发挥应有的作用。
至以技术,只是项目管理中的一部分,怎么安排、利用技术专家的作用,也是 A 的重要职责所在。我
想,A 的失败应该在于她没有具备项目管理的知识,加上与团队队员沟通不够,导致失败。

·定位(2003-05-13) [作 者] 项目管理 [公 司] 无

我感觉在这个项目中 A 最欠缺的能力就是定位,公司任命其为项目经理时,他是如何定位的,他在公
司,在项目组中对自身的定位非常重要。客观的来讲,以A对组内的管理行为来看,A对自己的角色
是否有有效的定位很值得怀疑。同时A对自己的职业生涯的定位可能都有问题。
项目不难做,最难做的就是人,对A来讲还有好多事情要学习。至少从这个案例来看,A就没有系统
的学习过项目管理:)

·自信.色角(2003-05-13) [作 者] tong [公 司] General-tech

首先 A 已完全使去自信和勇气,其次没将自子定位为项目经理的角色.组员请假、人员重新调整等等项
目经理均不了解其团队旗人员调整的事情,A 怎能统筹安排整个项目的运行呢?

·沟通从心开始!(2003-05-13) [作 者] 李俊山 [公 司] UFSOFT

作为一个项目经理,最重要的不是自己如何能干,而是怎么样把你项目中的人员的能力发挥到极致,
这才是一个项目经理应该追寻的,一个项目经理不在于能干多少,怎么能干,重要的是他不能把项目
组的资源发挥到最大,所以积极有效的沟通和交流是免不了的!
人毕竟是有情感的,我不认为一个人处处受到打击和排挤,如果出现这种情况,一定要多找找自己的
原因,是不是在哪些方面让别人造成了误解,世上没有过不去的河!

1.28 项目经理的窘境

项目经理的窘境

[姓 名] leeyuu [单 位] PMU [邮 件] liyu@mypm.net


[所属行业] 综合应用 [所属主题] 项目综合管理 [发布时间] 2003-4-11

第 236 页 共 756 页
第 1 章 综合管理

【案例正文】
陈伟明是公司的项目经理,在项目 A 筹备阶段就作为项目经理助理参与该项目,项目正式
实施后被公司任命为项目经理。但使陈感到恼火的是:其他职能部门的经理虽然为该项目安排
了时间和人手,但他们更热衷于其他项目。同时陈还被告之不要干涉部门经理对资源的调度和
费用的预算。

半年之后,陈借向公司管理层汇报项目进度的机会想管理层说明了由于职能经理不合作而
造成的项目严重拖期情况,这次汇报引起了公司管理层的注意,他们投入了更多的资源来使项
目回到正常轨道上来,陈伟明不得不花费很多时间来准备文案、报告和投影以及各种各样的会
议。

公司管理层还为陈指定了一个项目经理助理,该助理认为应该通过计算机程序把各种问题
程序化,于是公司又投入了 12 个人来开发这个程序,在花费了巨额资金之后,陈发现这个程
序并不能实现其目标,他向一个软件供应商进行了咨询,得知若要完成该程序,还需要多花费
数倍的资金和两个月的时间,无奈之下,陈只好放弃了该程序。

这个时候项目的情况已经很困难了,项目滞后了 9 个月,但还没有成型的单元完成,客户
对项目拖期问题非常关注,陈不得不花大量时间向客户解释存在的问题和补救计划。

三个月之后,项目仍然没有大的进展,客户开始不耐烦了,尽管陈进行了大量的解释和说
明,但客户仍然不能接受严重拖期,于是指派了一个代表到项目现场监督工作。客户代表要求
找出问题并持续更新,继而试图参与进来解决问题,陈和客户代表在一些问题上产生了激烈的
冲突,导致两人关系恶化 。

公司管理层最后撤换了陈伟明,项目 A 在超期一年之后,以预计费用的 140%最终完成。

陈伟明在项目 A 中遇到了很多项目经理都曾经遇到的困难,大家都来谈谈为什么他
被撤换下来,他应该为这些问题负责吗?

【相关分析】

·真正落实项目经理责任制(2005-06-26) [作 者] 黄国银 [公 司] 马鞍山十七冶建筑工程有限责任公司

在陈伟明项目经理身上发生的,不是一偶然现象,带有一定的普遍性,项目部的设置还是公司领导的安
排,项目经理没有组建权,导致在实际工作中有令不行,不能发挥项目经理的核心作用.
陈伟明作为一名项目经理,应该知道自己的职责,行使项目经理的权利,不能等问题出现后向上级领导
汇报来解决.
公司给陈伟明指定一项目经理助理后,助理的提议应由项目经理决策,这次的决策又是错误的,这是工
作能力方面的问题.

第 237 页 共 756 页
第 1 章 综合管理

公司应真正落实项目经理责任制,项目经理要不断提高自身业务能力,大胆使用项目经理的职责和义
务.

·真正落实项目经理责任制(2005-06-26) [作 者] 黄国银 [公 司] 马鞍山十七冶建筑工程有限责任公司

在陈伟明项目经理身上发生的,不是一偶然现象,带有一定的普遍性,项目部的设置还是公司领导的安
排,项目经理没有组建权,导致在实际工作中有令不行,不能发挥项目经理的核心作用.
陈伟明作为一名项目经理,应该知道自己的职责,行使项目经理的权利,不能等问题出现后向上级领导
汇报来解决.
公司给陈伟明指定一项目经理助理后,助理的提议应由项目经理决策,这次的决策又是错误的,这是工
作能力方面的问题.
公司应真正落实项目经理责任制,项目经理要不断提高自身业务能力,大胆使用项目经理的职责和义
务.

·可怜的项目经理(2005-06-01) [作 者] 张彤 [公 司] 北京北大金秋新技术有限公司

这是一个极普遍的现象,要解决好这个问题首先要从组织的层面上提高多项目管理的水平,而这个项
目经理的业务经验也有待进一步提高。

·可怜的项目经理(2005-06-01) [作 者] 张彤 [公 司] 北京北大金秋新技术有限公司

这是一个极普遍的现象,要解决好这个问题首先要从组织的层面上提高多项目管理的水平,而这个项
目经理的业务经验也有待进一步提高。

·时间进度与质量(2004-09-28) [作 者] 邵毅敏 [公 司] 上海祥铭实业发展有限公司

在我看来,整个项目的时间进度的把握和质量的控制是最为关键,其他的事务协调应该以这两点为基
础。如果把案例中的人物理解为因为质量而延误时间的话,那整个领导层在项目开始时就已经犯了错
误,在项目初期就应该有充分的遇见,显然被任命的此项目经理是有欠缺的,亡羊补牢,为时已晚。

换了个角度,还请大家指点。

·责任不可推卸(2003-11-19) [作 者] 李子军 [公 司] 北京诺德信科技开发有限公司

陈伟明对于项目出现的问题负有不可推卸的责任:
1、不明白自己在做什么
陈伟明虽然没有太高的职务,但是为了保证项目完成,在遇到任何不利于项目前进的问题时,都要及
时、勇敢、果断的站出来,与各层面进行沟通,争取项目需要的一切资源。懦弱、容忍、做老好人,
最终结果只会导致项目失败、自身不保。
2、关键时刻做了草率的决策

第 238 页 共 756 页
第 1 章 综合管理

借助软件来解决管理问题是好事,但是软件不肯能完全解决管理的问题。何况,在项目开发的关键时
刻,不去解决现实问题,却花费那么多的时间、人力、金钱、精力去做管理软件,即使把软件做好了,
项目能否成功也是未知数,软件不是万能的。

陈伟明的许多做法,表明他不能胜任项目经理

·项目经理的窘境(2003-07-30) [作 者] 有感 [公 司] xyz

陈伟的案例是很有代表性的,我认为项目进行不下去的最重要原因是他得不到部门经理的通力支持!
如果人心不齐,我们如何能保证一个大型项目的成功?事情的关键因素还是"人"!
我认为项目经理从某种意义上也是一个各方利益的协调人,所以我在当项目经理后,提请公司总经理
批准我可以将项目成功后的提成奖金分一部分给部门经理,作为该部门管理费用,而且比例不小,因而
我的项目得到了部门经理支持,使我的工作省去了很多不必要的协调过程。这样一种“利益捆绑”的
做法才可能真正有效的调动公司各部门的资源来为项目服务。

·失误(2003-06-06) [作 者] 蒋吉波 [公 司] 广东

对此我认为陈的失误有如下几点:
1、领导的态度:领导给予关注,这是一个非常重要的资源。但陈没有充分的利用此资源,保持项目
的正常进行。
2、项目需求的风险分析:陈对本项目的整体把握不足,缺乏对项目的需求风险分析。
3、协调沟通不到位:问题的出现必须即时的协调沟通,而不是让问题延续。

·项目经理的能力(2003-05-29) [作 者] 陈首创 [公 司] 洛阳石化工程公司

在本项目中,陈伟明的失误是明显的,他具备搞好本项目的客观外部条件.首先在项目的初始阶段便介
入该项目,其次得到领导的授权.问题在于他对项目管理缺乏以下几个最基本的素质:
1:预见性
对项目中存在的风险提前测量,预见到各种风险和威胁的存在是一个优秀项目经理的最基本素质.在
公司矩阵项目管理结构中,人力资源的协调管理风险是经常要遇到的一个普遍问题.提前与职能部门
经理的沟通尤其重要.
2:主动性
主动性在项目管理活动中应该贯穿始终.项目管理不是书本上那些术语的堆砌及表格的罗列,发现问
题,跟踪问题并及时的解决问题才是动态管理的精髓.
3:协调力
项目经理的协调能力对项目的成败也很重要.协调能力较差的项目经理经常被职能部门当作皮球踢来
踢去的现象也屡见不鲜.
4:客户满意度

第 239 页 共 756 页
第 1 章 综合管理

作为一名项目经理除了掌握项目的计划,进度及控制三大基本点外,面对目前各行业激烈的市场竞争,
争取客户的满意度应该是优秀项目经理追求的目标。不仅让客户满意项目结果,还要注重过程满意,
这才能有力配合商务部门的工作。
综述以上几面,该项目的失败主要在于陈伟明的能力不足以担当项目经理一职.

·项目经理啊,项目经理(2003-05-20) [作 者] edward [公 司] 南天

1、作为公司,请正式任命项目经理。并在相关各方参加的启动会议上,明确项目经理的权利,而不
止是义务!!!
2、做为项目经理,你的职责不止是执行项目,而是管理项目。请在进入具体的实施工作前,对你的
项目计划(包括进度计划、资源费用计划)进行充分的论证。如果质量、工期、成本任何一方面有问
题,请提出,问题已经发生时,你将花费几倍的成本来完成你的错误。
3、做为项目经理,请提出你的风险计划。没有风险的项目不是项目。
4、做为项目经理,计划不是摆设,请跟踪(或指派人跟踪)你的计划,到严重延期时,一切问题都
将被放大数倍了!!!

项目经理啊,项目经理。做为一个成熟的项目经理,上述工作都不是你的重点,你的重点在于管理,
在于人!

·项目经理的窘境(2003-05-17) [作 者] 吴浩 [公 司] 航天清华

刚刚浏览过这个简短案例和大家的分析,感觉都非常有道理:从项目经理的个人能力和公司领导都有
责任。
我想提些问题和自己的一些粗浅想法
1.因为案例很简短,不清楚这个公司的组织结构是怎么样的,就是说项目经理和职能经理级别、授权;
我为什么这样问,因为我对该项目经理在半年后才向领导反映问题表示不解,这期间他做过什么努力
没有??(因为在我在的公司项目经理和公司领导沟通是依靠项目经理的经理,所以我对公司的组织
结构,上下级的沟通渠道非常关注。)
2.不清楚项目的规模??如果是一个大型项目(我的理解,如何和五个或五个以上的职能部门打交
道),就一定要有自己的项目经理助理;项目经理听着头衔不错,但责任重大,有时候又是光杆司令。
3.如何能任命一个合格或满意的项目经理??我认为项目经理的工作背景和性格非常重要。不知道大
家的看法。

·领导的责任(2003-05-14) [作 者] fatbig [公 司] MyHome

楼下的看法我不尽赞同。

因为领导有领导的工作。虽然有不到之处,但是还是一句话,

第 240 页 共 756 页
第 1 章 综合管理

失败无论如何是自己的责任。

因为领导明确了你的位置。
当知道你的需要后积极地支持了你。
并没有干扰你的工作。
并没有授权不足。
给了基本上充足的时间。

我想剩下的工作,还是项目经理自己工作不到位。

·从系统角度看待问题(2003-05-13) [作 者] Cecil [公 司] 不重要

案例主角纵有千般不是,其领导应承担主要责任:
1、用人不当。将不合适的人放在重要的位置上;
2、必须用此人时,领导必须加强督导与监控;
3、事后发现问题后,必须迅速做出反应,及时调整人员、资源,分清轻重缓急加以处理。
此案例里的结果是差不多最差的,如要评定,领导仅 3 分(10 分满分)
陈伟的最主要问题是对自己缺乏清醒的认识,还需要许多失败的磨练。

·三个问题(2003-05-12) [作 者] 马静伯 [公 司] 化讯信息技术有限公司

我觉得是三个问题:
1、公司内部关系协调的问题
2、项目管理方法的问题
3、与客户沟通的问题
先说 1,项目经理的主要职能之一就是协调团队内部和团队于其他部门的关系并为项目的正常进行争
取必要的资源。这个案例中只是其他职能部门的不配和,这还不算麻烦,如果高层对项目有误解尔不
能提供必要资源的更多,这些矛盾必须有项目经理来负责解决,否则就是不称职。
再说 2,项目管理有很多方法可以采纳,有很多思路可以借鉴,但是如果项目经理对项目没有足够深
入的了解,对团队没有足够客观的认识,对项目管理本身没有足够丰富的经验的话,那么林林种种的
项目管理方法只会看花他的眼,这是个功力问题,新手栽跟头难免的,不过案例中的思路我觉得不是
完全不对,使用工具来促进协助管理和使用工具来帮助开发都是最正确不过的想法,可是方法欠妥。
最后说说 3,这个问题其实很难要求所有的项目经理都合格,因为在国内告需求分析就像搞攻关,方
法是有,但是必须建立在灵活运用的基础上,不过楼下有一位说的对,和客户交流是为了找到问题和
解决问题的方法,而不是针对某个问题的相互说服。
总的来看,陈伟明本身素质不高,外部环境也不好。如果项目成功了,我倒真的找不出什么理由了。

·项目经理的窘境(2003-04-29) [作 者] 项目管理 [公 司] 无

第 241 页 共 756 页
第 1 章 综合管理

我对楼下的观点不是特点认同,对于大多数项目而言,项目最重要的因素是人.无论项目经理能力如何
之强,都不太可能控制项目干系人的人格特质和干系人的行为特质。

从楼下考虑问题的观点是,如果是我,我将如何来做,如何解决问题。可相同的行为,由于人的不同,
也有可能导致完全相异的输出结果。那么采用楼下的任何一种方法,比如加强沟通,加强计划与执行
等,是否能够有效的控制项目,我认为是不一定的。也许陈在某些方面也做得非常到位,至少在我看
来,陈向高层反映情况,并及时得到高层的支持,就说明他具备一定的沟通能力与政治技巧。

换一个观点,如果你就是陈伟明,你是否能够解释你的失败,你是否能够体会到项目失败的痛苦,你
是否认为这是你的责任。做为项目经理,成熟与否很大程度上取决于对人的理解与沟通。

在我看来,该案例的信息量并不是特别充分,以这类信息量,要将陈定性为是否是一个合格的项目经
理是有待商榷的。项目经理的职业道德里,立求公正客观亦是必须的,因此我觉得对于该案例,我只
能认同这个观点,成功的项目经理并不意味着成功的项目,而成功的项目并不意味着项目经理成功,
同时,失败的项目并不意味着项目经理的能力和水平。(仓促成文,见谅)

·下岗的教训(2003-04-18) [作 者] 文矛 [公 司] 中讯

1)感觉陈的管理风格是颇为消极的,静待事情恶化然后向上级转移问题。
2)对管理中的问题也仅限于就事论事,过于相信软件程序的力量。因为管理无常形,设计一种问题
管理处理程序本身也就违背了项目管理中首先需明确需求的原则。进而加重了整个项目组的负担。
3)没有利用好客户方代表,在项目严重拖期后,应与客户积极协商分阶段实施方案,而不是纠缠于
与用户讨论所有的问题。

·陈伟在各方面均需要提高(2003-04-18) [作 者] clerly [公 司] 神州网信

first test

·陈伟应该在项目管理各方面均需提高(2003-04-18) [作 者] clerly [公 司] 神州网信

恕我直言:陈伟现在还不具备做项目经理的素质,应该在项目管理的各个方面认真学习。从项目做的
过程来看,主要有以下问题:

1、沟通能力不足。不能很好地各职能部门经理沟通,也就无法及时获得项目实施所需要的资源,我
想如果沟通得当,这个问题可以解决。
2、本身没有主见。从向管理层单纯汇报问题,没有解决方案和听取助理的话,就很明显地反映出来
这一问题。管理层很支持他,但他却不能从管理层那里得到他想要的“东西”。助理是帮助他的,而
不是指挥他的。现在退一步想:即使软件开发成功,是否就万事大吉,恐怕就有有关软件的问题出现。
这里可能缺少一个严格的项目实施管理的流程。

第 242 页 共 756 页
第 1 章 综合管理

3、不能确认项目的关键问题所在。一个项目拖延 9 个月,还有什么问题不能解决的呢,这肯定是项
目经理人本身的问题:认识不到什么因素使项目拖延,更别说去解决了。
最后管理层是明智的:撤换

·过于明显的失败(2003-04-15) [作 者] 甘建文 [公 司] 工程部

1.在一个强矩阵的项目组织结构内部,项目经理的技术特征之一就是具备很强的政治敏感性,应该善
于调动各职能部门的利益关系,能够主动参与到项目中来.文中陈伟明在处理职能部门关系和向高层
领导反映问题时缺乏足够的技巧.
2.公司安排的项目助理在参与到项目中并未以问题为导向,而采取了新的管理程序并且没有经过计划
和认证就匆忙上马,反而使问题复杂化.
3.在客户被迫参与到项目管理中来的情况下,项目经理并未将其纳入到管理制度之下,使其必须遵守
项目流程和变更制度.另外从整个项目过程中陈伟明都表现出明显缺乏的沟通能力也是导致项目失败
的重要原因.

·管理意思形态(2003-04-15) [作 者] 考拉 [公 司] WONDERS

管理是为人的学问
项目目标的项目管理的结果,太关注于过程而不注重结果会导致无法承担的责任。
陈伟明明显初为经理,没有必要太显示管理的权威和考虑责任。
要有平常心,善于沟通的话,就可以取得其他部门的支持(别人关注其他项目的原因绝对是因为个人
的原因)“同时陈还被告之不要干涉部门经理对资源的调度和费用的预算。”姿态低一点,找到共同
利益就能解决问题。
“问题程序化”明显是想摆脱责任的做法,勇于承担责任不仅表现个人素质,而且能起到激励下属和
取得其他经理信任的效果。
管理方式是没有绝对正确的。项目本身就是以目标为驱动的,在适度的原则下,能使项目相关方利益
最大化就好。

·fw:项目经理的窘境(2003-04-15) [作 者] 尾工 [公 司] online

我觉得首先要培养服务意识,我们所做的所有努力都是为客户服务,从而得到认可,并实现价值的。
陈开始一味的追求内部流程的完美化,而不去考虑项目的进度控制,这显然是不合理的。追求内部完
美不是过错,但因为如果耽误客户的工期则在商业运作上犯了很大的错误。
我觉得可以把该项目先做下来,把问题暂搁置起来,在项目的进行中会不断出现新的矛盾,等做完几
个项目后,自己也能把矛盾梳理清楚,这时候在去开发新的流程控制,会降低很多风险。

个人意见,抛砖引玉。

第 243 页 共 756 页
第 1 章 综合管理

·完成项目工作是项目经理的唯一目标(2003-04-14) [作 者] 马征 [公 司] 中成集团股份有限
公司

陈伟明显然是一个没有经验的项目经理,可能是初为项目经理吧。因此这个案例的典型性在于如何将
书本的知识运用的实践中去,千万不要停留在本论坛转自 MARRY 从美国发回的感慨“PAPER PMP”的
层面上,项目管理本身既是一个知识体系,更是波澜壮阔的实践活动,“项目经理是干出来的,不是
学出来的”,其中滋味要亲口尝过梨子才能体味得到。

本来陈伟明有很好的条件将项目管好,他“在项目 A 筹备阶段就作为项目经理助理参与该项目,项目
正式实施后被公司任命为项目经理”,这样在项目初期他不至于因为摸不清项目的合同情况和背景情
况而陷入工作的被动,这对成功地迈出项目第一步十分重要,但显然他在项目开局阶段没能利用好这
个条件,而被公司组织机构的负效应给拖住了项目前进的步伐。

在公司矩阵项目管理结构中,项目经理起什么作用?陈伟明显然没有搞清楚,项目经理是矩阵项目管
理结构的中心连接点,他的任务就是对项目负责,他必须用智慧和一切可能的手段保证项目组织的运
行,如果没有各司其职的项目成员那么项目不就是个空壳子?巧妇难为无米之炊的道理世人皆知,因
此为了保证项目的成功,他必须想尽一切办法使人力资源到位,而不是因为部门的职能经理不给人就
干等着,而且一等就是 9 个月才向公司领导反映问题,这至少可以说明他的工作责任心太差!

对于项目的管理方式,陈伟明显然也心中无数,这个问题在他被任命为项目经理时就必须要明确,而
且应该写入项目的管理计划,怎么可能是在项目开始 9 个多月后才由新来的项目经理助理来决定“应
该通过计算机程序把各种问题程序化”呢?由于陈伟明对项目管理缺乏最基本的常识,因此造成了
“公司又投入了 12 个人来开发这个程序,在花费了巨额资金之后,陈发现这个程序并不能实现其目
标,他向一个软件供应商进行了咨询,得知若要完成该程序,还需要多花费数倍的资金和两个月的时
间,无奈之下,陈只好放弃了该程序。”的严重后果。在这里我还想说点题外话,项目的管理/控制
工具是与项目的具体情况密切相关的,绝不能把所谓的时髦作为选择的唯一标准,对一个具体的项目
来说,合适的管理工具/手段就是最先进的管理方式/方法!我曾经看到一个案例,一个 50 万元人民
币周期 2 个月的项目,采用挣值法进行管理,虽然这个项目经理把此作为得意经验侃侃而谈,但我觉
得他不是没事找事,就是没有真正采用挣值法,这就像一个家庭的月收入与开支基本持平,他却要雇
一个管家或者理财顾问来帮助他搞家庭预算,你说他不是烧得慌吗?但是,当前在项目管理界似乎存
在方法与手段上存在极大的误区,片面地认为采用了新的管理软件就完成了现代项目管理的变革,而
不是从观念革新入手解决项目管理问题,因此往往由于采取的是舍本逐末的方法而造成更大浪费。

最后是在对待客户关系上,在所有的公司以至 PMP 教案上都要明确地告诉你,客户是上帝,让客户满


意是项目经理的首要职责,但是陈伟明却在这个问题上最后栽了斤头儿。在项目已经滞后了 12 个月
还没有成型的单元完成的情况下,客户肯定会着急,因此指派一个代表到项目现场监督工作是非常必
要的措施。陈伟明对此首先应该对自己或者本公司的工作不到位感到自责,然后完全可以利用客户代
表进驻的机会,以外力来推动项目的加速进行,但是他显然对客户代表进驻有抵触情绪,因此未能抓
住最后的改善项目管理工作的机会。客户代表进驻肯定要找问题并试图参与进来解决问题,这种情况
有时会给项目的正常工作带来不利影响,在一般项目管理中应该尽量避免,但是在本案例中,客户代

第 244 页 共 756 页
第 1 章 综合管理

表的进驻是在非常情况下的非常措施,陈伟明完全没有认识到此情况的严重性,更没有化被动为主动
的能力,采取的是与客户代表“产生了激烈的冲突,导致两人关系恶化”的不智举动,公司这时的挥
泪斩马谡成为了唯一选择,陈伟明在 A 项目上的失败命运也是一个合理的结果。

下面再谈一下公司管理方面的问题。

从案例介绍的情况看,陈伟明所属公司从项目管理的角度看也不成熟。公司对项目的管理应采取在项
目经理负责制基础上的有效监督这样一种组织形式,因为项目不是项目经理的,是公司以完成项目目
标实现公司利润的经营活动,因此不能说任命了项目经理就万事大吉,必须通过矩阵管理体系的职能
部门通过项目组的报告/报表等随时掌握项目动态,对项目经理的工作及时给予帮助和指导,而不能
向本案哪样,在项目拖期 9 个月后,才通过项目经理的一次向公司领导的工作汇报才引起重视。因此
“最终项目 A 在超期一年之后,以预计费用的 140%最终完成”的结果,公司应该负组织领导不力的
责任,如果该公司这种项目管理方法不改变,很可能会干一个项目赔一个,这样不管是什么样的所有
制,公司都将难以继续维持下去。

其次,项目经理部采用的管理软件应该由公司统一安排,这样才有可能建立自己的数据库,实现公司
层面对项目的有效管理,该公司看来没有固定的管理软件,那么从公司发展的角度看,应该将已经上
马的 A 项目软件继续完成,并从公司的角度加以总结,而不应该在已经投入公司资源的情况下轻易放
弃,从这点看公司的管理层显然对今后公司的项目管理方式和方法没有真正进行过研究,还处在一种
自然发展的状态。

第三是在人员的安排上,陈伟明的能力不足暴露出来以后,公司可以采取换人或者从总部职能部门派
人蹲点等方式来解决,但加派项目经理助理的举动可能会造成由于职责不清而造成更大的被动,设身
处地的从陈伟明的角度看,他可能会认为新来的助理是来监视他的,因此产生抵触情绪而造成二人间
的冲突;或者认为你不是有本事吗,我什么都不干看你能怎么样,从而放弃了管理工作,在本案中似
乎是后一种情况,总之这种增加管理层次的方法往往由于不能形成合力而使工作带来损失。另外,在
用户方要求派代表进驻项目经理部的问题上,公司也应该出面予以谢绝,道理在前面已经说过,这里
不再重复。

综上所述,从本案例介绍的情况看,陈伟明在 A 项目中遇到的问题,应该说是由于个人不尽责、方法
不当、意气用事等主观问题造成的,因此他应该承担没有完成公司交付的项目管理任务的责任,如果
他能静心反思而不是采取推委的态度,他会从此失败的教训中成长为一个合格的项目经理。

·沟通为上(2003-04-14) [作 者] 宣晓锋 [公 司] 项目管理者联盟-mypm.net

这个案例非常的综合,项目超出时间和预算这么多,非常失败,失败的原因很多,严格地讲,每个关
系人,每个企业内部组织单元,都存在着问题。但是如果站在陈伟明这个项目经理的角度来分析,我
看主要还是沟通问题。

这个案例中,陈伟明所涉及的需要沟通的对象以及沟通结果,都陈述到了,职能经理,公司高层,项

第 245 页 共 756 页
第 1 章 综合管理

目成员(助理),客户等。但是依据陈述的情况来看,陈伟明都沟通失败。

1。与职能经理的沟通。职能经理没有给予项目 A 以足够的资源支持,无论理由如何,都是陈伟明关
系处理不妥,沟通不力的结果。项目要开动,资源先争取到位是第一步,不然延期的责任就是项目经
理的了,等延期的时候,再来埋怨职能经理,没有人会买帐。

2。与高层经理的沟通。沟通的时间太迟了,半年以后再来向高层说明情况。案例说的,高层给予支
持,已经很不错了。搞不好,高层还会说,这么严重的问题,直到现在才来说明情况?责任又是项目
经理的了--事实就是。

3。与项目助理的沟通。在是否采用项目管理软件,以及采用后决定启用这些问题上,决策得有些草
率。上软件,这种子项目,至少也得与高层沟通,与团队沟通,得到他们的支持才行。

4。与客户的沟通。客户是上帝,关系恶化,绝对是项目经理有责任的,没有任何理由。项目延期的
情况下,客户派出代表,事实上是对项目支持,一起使项目尽早完成的一种合作态度。项目组需要有
自己的意见,但是规范的合作,变更制度,客户至上的服务态度更重要。

项目是人来做的,项目进展得好坏是人决定的,如果项目进展中有羁绊,最可能的原因还是在人。

·项目经理的失误只之处(2003-04-11) [作 者] 马平 [公 司] 北京中青英才

1)陈伟作为项目经理没有做到与各职能经理的有效沟通,要知道沟通和协调职能是项目经理最主要的
工作之一导致了他在工作中的排斥地位,这是作为项目经理来说的失职。
2)应该就职能部门经理采取矩阵型的管理。而不是试图去统治和领导职能经理。矩阵型管理模式,
就是针对职能经理之间的沟通和管理而存在的。他最大的优点就是能帮助项目经理改变对资源的有效
控制。
3)没有做充分的证实和分析和可接受经验教训,就启用助理的程序化管理意见,导致了项目工作进
展的最终失败原因之一。
4)对于客户目标来说,客户的满意度与认可度才是最能说明此项目是否成功证据。与客户代表沟通
时重心工作应该是找到问题并尽快的令人满意的来解决问题,并不是就针对问题而与客户代表产生问
题。他的做法偏离了整体项目的最终目标。
5)对客户提出的刻意要求,应当首先需要客户代表提交变更申请,得到公司认可和项目使用者的认
可后再与客户代表沟通商议。如不能满足解决时,需要向客户代表包括项目发起人提交报告说明书,
说明一切所发生的事件,而不是自行的武断的给客户答复和操作项目。

·怎样避免白交学费(2003-04-11) [作 者] 李晓峰 [公 司] 歌华美盛工程咨询有限公司

项目经理的培养和使用对每一个组织都是重要工作。在培养项目经理时有时难免要交一些学费,如果
项目经理失败了,这些学费就白交了。
如何避免?

第 246 页 共 756 页
第 1 章 综合管理

好的组织都知道什么时候该交学费和如何交。本案例的组织好象不知道;
好的组织会明确告诉项目经理什么是他该学习的并提供帮助。
好的组织不会等到问题不可收拾的时候才进行控制。
好的组织知道自己能付出多少代价。
好的组织指导自身的优势和不足,尤其是不足。

组织的能力和项目经理个人的能力应形成互补,否则风险无法控制,白交学费在所难免。
本案例具有普遍意义,值得组织的领导层注意。

1.29 系统集成企业的危机

系统集成企业的危机

[姓 名] 杨杰 [单 位] 中迪 [邮 件] yangjie@anymacro.com
[所属行业] 综合应用 [所属主题] 项目综合管理 [发布时间] 1900-1-1

【案例正文】
我们公司现有员工 40 余人,主要以系统集成为主,集成中又以软件集成为主,市场覆盖整个
省。

但是现在遇到这样的情况,公司内部管理混乱,几乎没有管理,公司主要以上层人员把握,
包括技术和市场,公司内部老员工少,以新员工为主,新员工接触市场和技术相对较慢,主
要我们是做教育行业,懂教育的人少,技术覆盖范围广,同时还带有一定的深度。公司利润
现在处于负值,内部员工不团结,没有凝聚力,个人能力差,上面的要求又比较高,新员工
成长慢,公司出现断层,上层压力大,开始影响到他们的工作,有的甚至决定放弃。公司处
于一个相对不稳定的状态,老总又不是很在意这些情况,只以利润为主,公司出现恶性循环
趋势。

处于这种情况,出现了没有利润没有好的待遇,没有好的待遇员工不能保证基本待遇,员工
能力不高,开始不好好工作。高层保证待遇,但压力很大,因为能力相对不错,处于压力下,
开始动摇有离开公司的思想,于是公司发展愈来愈困难。
市场大,产品好,员工能力差,上层不以公司利润为主,思想不团结,老总又只看利润,怎
样挽救公司,让公司摆脱困境。
希望各位给一个好的建议。
裁员?压缩?改制?量化?

第 247 页 共 756 页
第 1 章 综合管理

附:公司结构
总经理(以市场为主)
市场副总 技术副总 管理副总
市场部经理(共八个市场部)
员工
同时还有两个特殊位置的人员:
1、管理顾问:在总经理之下副总之上,负责监督和协调副总之间的关系。(待遇与副总相同)
2、技术顾问:解决公司所遇到的特殊技术问题,综合性复杂的技术问题,一般处理不了的问
题。(待遇与副总相同)
希望各位给一个好的建议。

【相关分析】

·老板自身的问题,如自己不能改变,只能倒闭了!(2008-07-17) [作 者] 郭晓刚 [公 司] 同昌科技

管理层人员太多,龙多不治水呀,减少管理人员(1-2 人就行),压缩管理环节,提高管理效率!这样的公司也
就是小公司一个,管理越简单越好!如果老板不能改变,估计只能等倒闭了.

·从上到下的调整(2008-05-19) [作 者] 王玉娜 [公 司] 上海天马微电子有限公司

1. 企业高层领导的支持:*总应对企业的发展制定长期规划。
2. *顾问:协调高层和下属,管理和技术的关系,展开规划,细分到各部门。
3. HR:健全人才的培养和激励机制
4. 头脑风暴:根据市场定位和产品特性,调整企业的组织结构

·系统集成企业的危机(2008-04-18) [作 者] 王国华 [公 司] 烟台东华网络工程有限公司

1、老板本身对公司没有一个长远的规划,只考虑眼前利益,如果没有改变的话,只能是被市场淘汰,
建议看清现实规划未来。
2、一个有长远规划的老板也需要一帮能提中肯建议的副手,并能影响与管理老板。
3、一份好的制度并能正确执行它。

·企业管理,制度问题(2008-03-08) [作 者] 李智攀 [公 司] 上海交通大学

公司上层问题是关键,羊放不好,圈不住,不怪领头羊,而是牧羊人的责任.
公司显然不重视员工的培养,培训,以及自身的企业文化建设,造成了公司整体的凝聚力低下;

应该:高层碰头开会,深刻反省,找出主要矛盾,科学组织公司结构,明确责任分工,增强部门间沟
通,重视企业文化建设.

第 248 页 共 756 页
第 1 章 综合管理

·老板要熟悉公司的情况(2008-02-25) [作 者] 老杨 [公 司] 产品开发和系统集成

浮躁害人,很多老板一被叫*总后,就高高在上,不原意了解公司的具体运营情况,不原意亲身体会
现场的问题,而津津乐道于逐层汇报。公司有问题,需要老板首先要深入到各个部门了解问题所在,
然后才是分析问题和解决问题,否则一切无从谈起。
另外,公司要统一思想,从上层开始,明确目标和策略,否则下面的人无所适从,效率从何谈起?
项目经理可以结合实际给公司提交建议报告,看公司的反应,然后决定去留,这是比较积极的方式,
不建议盲目跳槽。

·企业管理问题,而不是项目管理问题(2008-01-22) [作 者] 周预 [公 司] 湘潭

首先应该明确一点:是企业管理问题,而不是项目管理问题。
案例介绍自始至终没有牵涉任何一个具体项目的运作,甚至在企业组织架构中也没有明确是项目型组
织还是职能型组织亦或矩阵性组织。

企业战略制定:“市场大,产品好。”按照资源导向和市场导向相结合的原理分析,企业战略应该非
常好确定呀!打理好的话,企业前途无穷啊!企业出现目前这种状况说明企业正处于一个转折点,调
整!

企业制度建设:不用多说,企业创业靠老板魅力,企业长远发展靠制度。

企业营运分析:“公司利润现在处于负值。”“市场大,产品好。”产品好,有市场,为什么不赚钱,
赔本买吆喝?企业应该加强进行项目成本分析,如果确实不赚钱,考虑企业战略转移。

企业人力资源:企业不注重人力资源建设,不注重企业文化建设,没有培养员工的忠诚度。老板急功
近利,只知道从员工身上榨取利润,“员工不能保证基本待遇”,“公司内部老员工少,以新员工为
主,新员工接触市场和技术相对较慢”。没有培训?!!员工又不是天才,至少不是个个都是!

项目化管理:抓住一两个核心项目,严格按照项目管理之要求运作,探索适合自己的项目管理制度,
培养一批核心员工,然后 copy 到其他项目组。

·生存(2007-12-20) [作 者] shi [公 司] s

作者没有给出企业的经营状况和历史信息.看案例好像该企业处于生存期.如果推断正确的话,这个阶
段的企业最重要的工作是找到合适的细分市场和开发适合这个市场的产品和服务,也就是说,生存是
这个企业面临的最大问题.企业内部管理有问题,是这个类型企业的普遍问题.

·上层建筑出了问题(2007-11-16) [作 者] 郭林海 [公 司] neusoft

第 249 页 共 756 页
第 1 章 综合管理

1.大海航行靠舵手,表面看你们老板的做法是正确的 组织结构和主抓市场;
2.问题出在管理顾问和管理副总上,分析如下
1)管理副总不懂管理,没有建立有效的管理制度和模式
2)管理顾问没有起到平衡和影响老板的作用,管理副总懂管理,也有想法,但是他的地位低下,得不到
有效的支持.
3.管理顾问是个摆设,没有什么作用,那就是老板的问题了.

对号入座,看是哪块的问题,只能通过变革或者换人解决.

·个人观点(2007-11-08) [作 者] zhaoyong [公 司] beijing huasun computer co.,ltd.

公司管理层的问题比较大,但是确实不是容易解决的问题。作为 PM 可能无能为力。过去常听到一句
话“体制问题”。
希望大家拍砖!

·系统集成企业的危机(2007-11-08) [作 者] liuwei [公 司] 珠海市安克电子技术有限公司

不识庐山真面目,只缘身在此山中.能提出这样的问题,可以看出你应该是项目经理之类的处境,我们
中国现有项目经理其实大多数只是个称呼而已,而并没有什么真正的实际权利,当然这也跟我们自身
的能力有很大的关系.有些人喜欢跳来跳去寻找合适自己的企业,而有些人喜欢并习惯于一家企业,不
管这家企业的现有效益和未来发展前景如何.你现在首要的是能够积极主动的寻找公司问题的根源在
哪里,能够主动的去思考问题其实是一件很有意义的事情,或许你来这里的目的是想有一位能人为你
量身订做一个适合你公司发展的方法,这样的思路是不可取的,古语说的好啊,授人以鱼不如授人以
渔.要从多个角度去发掘公司问题的所在,将其进行对比研究,抿记于心.俗话说:腹有诗书气自华,后
语:内装问题也不是豆腐渣.再者看你们公司的规模和人员配备,好象是领导多,干活的少,既然有那么
多市场部,那业务量又如何呢?好多小公司都是从大批量的业务发展起来的,熟能生巧就是从大量的劳
动中得出来的,如果公司业务不是很多,要想把项目质量搞好那更是一个漫长的时期.先把自己变成布
袋里的一个锥子,而不是密不透风的铁桶里的一个锥子,锥子放到布袋里总有露头的时候.

·走人(2007-09-26) [作 者] fasiondog [公 司] fasiondog

没有把企业当作产品、系统来经营、建造,只能说明公司没有长远打算,赶快走人

·zonghe wenti (2007-09-23) [作 者] wangjinlong [公 司] shanxijincheng

这是个综合问题,需要多头多放面多层次的综合治理,当然最主要的是老板的观念问题,作为综合管理
人员,需要撬动多年形成的恶习,从文化的行为上进行改革,当然每依次每一点都是不容易的事,及别

第 250 页 共 756 页
第 1 章 综合管理

制度的执行过程友好转,仍然需要长期的把持,才能有效.当然,这个难度不是你不能坚持,而是恶习的
强大,一次又一次地向你无理的纠缠,最终的目的就是搞跨你,让你无法巨细施政.

·fkasl(2007-09-18) [作 者] 松 [公 司] 天啊

李强是 A 公司的项目经理,其管理风格非常严厉。他要求团队成员严格遵循他的指示,强调使用正式
和非正式的控制方法,两年前在他被任命为项目经理时,很多人感到不满。在他任项目经理的前半年
中,14 个工地管理、工程和技术人员中有 8 个相继转到公司别的项目组或离开公司,而正当 A 公司
老板想调走李强的时候,紧张的局势得到了缓解,项目组中留下来的人及李强任命的人都接受了他的
领导方式。

在李强任期中,他成功地将项目建设成本减少了 10%,其进度也达到了项目管理分部主管、客户和建
筑师的要求,他对项目的管理紧张而有效,后来被另外一家公司相中,随后就跳了过去。

A 公司老板准备在项目组中提拔一个项目经理,但他发现没有人是李强的助手或可替代的人,后来,
老板安排首席测量员陈刚来担任项目经理。

·这不是项目管理层次人员考虑如何解决的问题(2007-09-05) [作 者] 老杨 [公 司] 产品开发
和系统集成

公司发展的方向,不是项目管理层次人员考虑如何解决的问题。
个人发展的方向,是公司里每个人都必须马上考虑的问题了。

·老板的观念是关键(2007-08-17) [作 者] hjh [公 司] 力鼎

这个公司的情况和我之前呆的公司真是非常的象,领导对公司的发展没有想法,你下面的员工再想作
为也没有办法,这种公司要吗老板自己转变观念,要吗你就赶紧走人。否则耗下去的结果就是等死,公
司死掉老板的损失那是他活该,而你在这样的公司你会有多少收获呢?

·公司发展方向的定位!(2007-08-14) [作 者] 王大勇 [公 司] 武汉

从你所描述的内容来看,我建议先深挖出现此种问题的最根本原因,找出症结所在。你所说的情况,
缺少一个前提条件,你们公司近几年的业绩状况,而不是单纯描述现状。建议从以下几个方面来分析:
1、近几年公司在全省教育行业所做的业务量(真实数据),最好运用图表方式,从多角度来对
比分析。
2、客户状况(老客户是否有流失,流失的比例;是否有新客户增加,比例)。
3、未批量更换老员工时,项目实施的情况(项目完成的周期、流程、激励机制、回款等),并

第 251 页 共 756 页
第 1 章 综合管理

进行全面的分析、对比,最终确定到底是单纯的技术、经验上的差距,还是否有其他方面的影响)。
相信通过以上分析,你便不难找出出现危机的深层次原因,通常情况下,找到出现问题的最根本
原因,解决方案其实可以很多的。
当你分析完毕,找到最终原因后,我们可以再探讨如何解决。

·组织架构调整,创新业务流程(2007-05-16) [作 者] 周杰 [公 司] 安徽喜客网络技术

一、招开中高层管理人员会议:
(1)人力资源:改组共建一个高效组织的团队。
(2)沟通管理:有目的地摶重拾员工信心,使团体凝聚力巩固。
(3)制定各中高层的范围管理:考虑公司发展所涉及的一系列任务。
二、中高层管理人员形成共识后,对老板洗脑。

·组织架构调整(2006-11-22) [作 者] 莫泽辉 [公 司] GZ—Telecom

1、调整公司业务流程,缩短市场响应速度。短时间内将管理顾问和技术顾问充实到市场部;先把公
司收入带上来。
2、调整公司管理层;让大老板参与到公司事务上来;
3、裁员和重新招人;对于当前的情况是用人,而不是培养人。所以必须招聘有用的人才。

·整顿...(2005-06-07) [作 者] 丁丁 [公 司] m

1、裁员:管理顾问,再寻找合适的人选。
2、人力资源管理:明确工作分析,加强绩效考核。
3、整顿:划分职责,明确利益,规范流程。

4、管理层的思维方式!要持续的方展,而不是短暂的利益。

·重拾信心、改善流程(2005-06-01) [作 者] 张彤 [公 司] 北京北大金秋新技术有限公司

面对这样的棘手问题,首先要鼓舞大家的士气,提高团队的整体凝聚力,在同时要改善公司的战略和
管理、业务流程。否则船散了也就沉了,大家都不免变成“落汤鸡”。呵呵。

·领导的决策是关键(2004-02-19) [作 者] 简妮 [公 司] SPCN

第 252 页 共 756 页
第 1 章 综合管理

企业管理得好是不好,领导的管理能力是关键.你可以不是业务高手,但一定要精于管理与用人.选定
好下属后给予充分的权利,实施板块有效管理后再进行总体上的系统化.因此此公司的领导层对企业
现状负有责任.

·帮老板洗脑(2004-02-12) [作 者] KEVIN [公 司] KEVIN

这一类型的公司谈不上管理,老板只是勉强为了生存而努力,很类似于刚起步的小型公司的操作,有
兴趣进一步分析的朋友请回我邮箱探讨。

·hi(2004-01-30) [作 者] rollli [公 司] a

兵熊熊一个,将熊熊一窝。高层的能力及其支持是很关键的,这不属于项目经理的职责。

·想重新站起来-成功因子(2004-01-17) [作 者] 周振球 [公 司] 成功因子

你们企业的现状,因该说在两年前就有很多人士提出了集成商的风险,想你们这样的企业情况的有很
多,他们也一样迷茫,寻找出路。
想重新站起来,要看你们公司有没有具备成功因子,很多矛盾,都是由于业绩的不如人意出现的,这
就是矛盾的主体,如何解决这一主要矛盾,是最关键的问题,当前最重要的就是解决她,目前,就你
表述的看,人力资源是非常齐全的,相信还是有出路的。至于如何签单,就是具体的操作了,好了,
希望对你们有启发。

·分提压力,合理用人(2004-01-16) [作 者] 小试牛刀 [公 司] XX网络公司

不要以为一个人或几个人可以撑起一片天,公司的建设要靠整个团队,而不是高层几个人,高层绝对要
洗脑!

·必须洗脑(2003-12-29) [作 者] sealin [公 司] 桂林

目前我们公司的情况差不多,唯一的办法先改变老总的意识,但由于老总一般都是几十岁的人,思维
意识在没有血的教训的情况下很难改变。

·当然不能倒闭了!(2003-12-25) [作 者] 朝阳公园 [公 司] 北京深思软件公司

首要的问题出在管理层,改制是必然的,农民企业家的弊端,也是现在大家经常讨论的,很多民营企

第 253 页 共 756 页
第 1 章 综合管理

业家参加各种名校的培训,也证明大部分企业家意识到了,他们在管理上的缺陷,我想你们的领导也
应该去学一学,但是现在所面临的是让企业活下去,所以可以聘请管理咨询公司为你们把把脉,通过
权威来强迫给你们公司开辟一条路(这也是为什么说很多管理咨询公司被当枪使的原因),这条路只
是缓兵之计,重要的是你们领导在管理思维上的转变。

·唯一出路-改制(2003-12-24) [作 者] 何健 [公 司] 成都华诚信息产业公司项目部

只有改制。
1.调整领导班子,管理顾问未起到应有的作用,应予以更换。
2.调整管理层思路,明确经营方针和目标
3.精简部门
4.提高员工待遇,设立相应奖惩制度,调动积极性

·……(2003-12-17) [作 者] ardour [公 司] :)

想到了以前的一位老总说过的话:“做好一个公司需要大家共同努力,搞倒一个公司总经理一个人就
够了。”
关键是老板怎样想的,如果他就认为这样乱忽忽的能赚点钱就行,谁也没办法。

·快改制吧(2003-12-12) [作 者] 胡中意 [公 司] 集成部

首先从公司的机构改革开始,文中提到有 8 个市场部,这之间的不协调可想而知(我是第一次听说一个
单位有这么多的市场部),总经理应该回到公司的领导位置上对公司进行全面的定位,其次就是公布公
司的处境并与过往对比分析,让每一个员知道困难看到前途(也就是充分进行内部沟通),然后由技术
强的带领新人进行工作,寓教于工作实践中,以提高公司整体技术水平.

·改(2003-12-10) [作 者] 陶德鹏 [公 司] 工程部

应该先整改,把公司内部的组织关系理顺,各个领导应该负责自己的负责自己的岗位,其次应该提高
员工的凝聚力,加强沟通和教育,应该有很好的激励机制。激发员工的动力。

·我的看法(2003-12-05) [作 者] 寇震 [公 司] 中铁十八局集团

你们公司最大的问题在于缺乏有效的企业管理及组织执行能力、企业文化

·倒闭吧(2003-12-04) [作 者] 寇震 [公 司] 中铁十八局集团

第 254 页 共 756 页
第 1 章 综合管理

"老总又不是很在意这些情况,只以利润为主",这样的公司除了倒闭或者出卖没有别的路子可走了,
因为这样的小企业,老板的为人决定一切。

·整改(2003-11-28) [作 者] ziye [公 司] volcano

这种情况,只要先在管理层进行整改,保证老板和管理层思路一致的情况下再进行其余的工作

1.30 如何实施电子政务项目

如何实施电子政务项目

项 目 管理 者联盟 项目管理者联盟
[姓 名] [单 位] [邮 件] yifeng@mypm.net
(PMU) (PMU)
[所属行业] IT 软件 [所属主题] 项目范围管理 [发布时间] 2003-1-10

【案例正文】
公司 A 是市政府背景很强的股份制企业,机制比较灵活(shanghai),目前该公司的
正在进行的一个项目是政府机关的一个 Mis 系统,现在整个开发全部完成,系统已
经试运行 2 个月左右,目前运行情况比较顺利,但是,目前有几个比较大的问题如
下:
1. 客户同公司关系特别密切(毕竟客户是机关)
,不能完全按照合同进展。
2.政府的工作节奏比较慢,在项目实施进程中,严重单方面拖延实施进度,造成项
目延期。(他们很小的项目决定需要开会讨论)
3.不可预测的项目变更风险(机关领导一句话,项目经理就要处理变更需求;可称
其为领导人风险)。
4.客户没有项目周期(软件项目)等认识,对合同规定的验收不予回应。这个需要
该公司老总才能协调。(项目经理没有这方面的权利)
项目经理在项目组中本来负责软件开发设计,开发后期被部门经理任命为项目主管,
对于客户主关需求变更,项目管理目前沟通的比较好。但对于一些政策性的变更,
则非常的难处理(需要必须改动),没办法,只有进行变更处理。该公司应该怎么才
能结束该项目呢。

·客户是上帝(2007-11-29) [作 者] 陈中民 [公 司] Canon

政府部门是一个强势部门,他有他自己的工作方式和工作习惯,对于一个企业来说,绝对不可能

第 255 页 共 756 页
第 1 章 综合管理

因为一个项目而要求政府部门对一些习惯、工作环境做一改变,而只能去适应。从另外一方面来
说,和政府部门有关系的企业,他所得到的项目是比较多的,不应该因为一个项目的得失而斤斤
计较,再说一个项目一般也不可能亏损,最坏也就不赢利罢了,所以投入资源相对多一点也不是
没有可能的。这一点我想公司老总应该非常清楚,了解。
对于怎样结束项目,我认为可以从以下几个方面考虑:
1、 加强双方领导的协调
2、 增加开发资源(人力、设备、资金),加快项目进度,尽可能地接受客户的合理要求
3、 反复和客户沟通,确认项目的边界
4、 超出项目边界的需求,记录需求,和客户沟通,商定增加在下一期的开发任务中。
5、 对于任何变更要有详尽的风险分析,告诉客户变更可能对在运行系统的影响,让客户接受这
样的风险,让客户来决定要不要变更,还是增加到下一期的开发任务中。

·如何实施电子政务项目(2006-12-30) [作 者] 刘用 [公 司] 广东省建筑集团公司

该案例谈到的是两个方面:客户满意度和项目风险问题。
项目变更主要是客户需求的变更,如果要对客户满意,我想关键是和客户沟通,要有原则(按合
同办事),不能给客户有很高的期望值,其实也就是一个度的问题的把握。
项目风险主要靠领导协调。

·如何实施电子政务项目(2006-12-30) [作 者] 刘用 [公 司] 广东省建筑集团公司

总体来讲,中国各级政府部门的信息化管理水平还是比较低的,工作人员大都是业务专家,计算
机的应用水平较低,网络化办公的意识还基本没有,尤其是在基层政府部门尤为突出。在这样的
客户面前,“客户需求”是无法在项目实施之前就清晰地描述和确认的。

·阶段化实施,划定关键点,协调客户关系(2006-12-14) [作 者] 埃文 [公 司] dd

一般来说,一个较大的电子政务系统,从硬件的采购到软件的实施确实需要一个长期的过程。在
这个过程中,对于软件企业来说,是一个不断与用户沟通协调的过程,关键是与项目干系人建立
良好的关系。

对于实施软件项目过程中,我们不能一味地苛求用户不能发生需求变化,而是我们先划定阶
段点,对于一般的而且目前非常实用的功能保证它能够立即实施。这个能够提高用户的满意度,
而且领导的政绩也有了。对于用户不断变化的需求,其实从另外一个方面来说,是我们的项目的
源泉,我们可以继续深挖项目。在这个期间需要公司的支持,比如带项目干系人出去参观类似案
例。提供他们的思路。

对于这个项目的实际使用者,一般来说,用户总会把几个部门的项目业务骨干弄过来作为需
求人员。对于这部分人,我建议在用户使用界面上化点功夫,比如提供他们自动导入程序,还有
能够尽量减少工作量的东西。让他们积极使用。有时间的话,项目经理多与他们沟通一下感情。
以后在他们的例会上就会给你说话,这样项目的进度和后续都用保证了。

第 256 页 共 756 页
第 1 章 综合管理

·维护方式(2005-06-07) [作 者] 丁丁 [公 司] m

客户是政府机关,单位机制。不太适应常规的市场经济运营方式。那就软件公司适应客户吧。

1、列举重要的指标点,让客户确认。
2、在合适的时间点,把项目由开发阶段过渡到稳定维护阶段。而且可以收取所谓的验收费用。(运
作~~~)
3、抽出原班人马,稳定一个阶段后,指定个人,就在现在做维护和简单开发(不限期),也是保
持良好的客户关系,和公司名誉。

·好的销售人员首先应该是好的项目管理人员(2005-06-01) [作 者] 张彤 [公 司] 北京北大
金秋新技术有限公司

如果在这样的项目中销售人员是好的项目管理人员就好了,他可以先巧妙地给有关领导组织一次
项目管理培训,如果领导能和项目经理对项目的实施有共同的语言,那么这样的项目实施起来只
会得到更多的支持。可惜,现在这样的销售人员太少了。

·分析干系人(2003-05-23) [作 者] 张清俭 [公 司] 大连

这是中国现阶段制度决定的。在接政府的项目时,干系人分析显得异常重要,一定要有风险分析
和应对计划,管理储备的比例也要增加,同时项目经理的沟通时间提高到 95%。

·服务客户,培养人才(2003-04-26) [作 者] 贺炜 [公 司] 西北工业大学

以前我们也曾接手这样的两个政府信息化项目,最终通过为对方培养人才脱手的。最后项目完成
后一个月,还偶尔要求我们过去,后来就完全由我们培养的政府自己的技术人员接手了。

·电子政务实施中的服务意识(2003-04-16) [作 者] 冷酷到底 [公 司] EXOA

电子政务建设必须经历“从无到有,从有到好”的过程,所以我们在事实电子政务的时候也必须
向用户灌输一个这样的理念,明白电子政务的建设需要过程需要时间,如果达成一个这样的共识
的话项目的实施相对来说风险会小的很多,所以晓川先生分析的非常的精辟,但是电子政务建设
出现了“用而不验”或“验而不用”那就是项目组的悲哀,所以实施电子政务项目必须要树立一
个服务意识,项目靠服务产生利润,而不是单纯的靠产品产生利润!政府向企业买产品,也要买
服务。项目应该将设计和实施划分开来,明确设计和实施的区别和界定,这样项目作的轻松,政
府用的放心,用户当然也是开心了(特别是领导,电子政务是很大的业绩),总结一句电子政务
项目实施要企业要作好定位,服务才是最能产生利润的。

第 257 页 共 756 页
第 1 章 综合管理

·关系与商务不能等同(2003-03-27) [作 者] 陈荣森 [公 司] 深圳市佳创

与客户关系亲密固然是好事,但不能等同于在做项目时都事事迁就于客户,朋友是朋友,商务是
商务,不能等同,否则会陷入很被动的局面。建议:
如果客户领导提出变更的想法,你不好意思明说,但你必须每次都向他列举这样的变更会给系统
带来很大的变更和变更的困难,以便给提出变更的客户压力,随着压力的积累,客户再次提变更
时会有压力而变得谨慎。

·如何实施电子政务项目(2003-01-15) [作 者] 石灵 [公 司] SIM

我同意晓川先生的说法。在我国的行政机构中存在的两个突出问题就是领导意志和作风拖沓。相
信在短期内这一现象难以消除。因此,阶段目标的制定就变得非常重要。管理水平的提高,往往
不在于某项重大制度的变革,而是基于许多细微的、渐进的变化。因此,在进行阶段目标的设定
时,要首先提供让政府各级部门感到方便的功能,使他们逐渐具有兴趣,从而形成一种良性循环,
其过程如同微软公司的软件发布一样。

·项目组需要面对变更(2003-01-10) [作 者] PMU [公 司] 项目管理者联盟(PMU)

该案例是目前电子政务软件公司面对的一个典型问题,研究表明,多数项目的失败在于项目范围
的随意变更,国内政府部门拖沓的工作作风和长官意志一向令以行动迅速著称的 IT 业内人士感到
无所适从,这也是许多电子政务项目没能取得预期效果的一个重要原因。但作为项目结果的接受
者,客户的要求应该是放在第一位的,说白了,项目是为了客户而存在的,应付客户变更需求产
生的风险正是一个成熟的团队需要具有的能力。对于这个项目中的范围管理和沟通管理,我们可
以听听下面几位项目管理资深人士和专家的意见。

·集体分析(2003-01-10) [作 者] 集体(1xqing等) [公 司] 项目管理者联盟(PMU)

Roran :
该案例谈到的是两个方面:客户满意度和项目风险问题。
项目变更主要是客户需求的变更,如果要对客户满意,我想关键是和客户沟通,要有原则(按合
同办事),不能给客户有很高的期望值,其实也就是一个度的问题的把握。
项目风险主要靠领导协调。

Lxqing:
一定要结束这个项目,这是对这个公司非常重要的事情。根据描述,正常项目结束看来是不可能
的了。
我认为结束的关键是项目经理和老板的沟通,使他产生迫切的结束需求,去和机关话事权的人进

第 258 页 共 756 页
第 1 章 综合管理

行沟通。但是除了项目经理和老板的沟通外,要准备好所有的有关文档资料。

Army:
项目中的领导人的作用是非常重要,我认为公司对需求的理解不一定有项目经理深,关键还是在于
经常的沟通引导。沟通的方式可以采取书面和其他方式相结合的方式,这样更便于沟通。

·高层参与,市场与技术配合(2003-01-10) [作 者] 尧川 [公 司] 北京美髯公科技发展有限
公司

上述案例是从事电子政务软件开发的IT公司都会遇到的问题,但是如何应付这种局面是需要一
整套市场和技术部门的配合,以及公司高层的把握才可以较好避免或减少上述案例的发生的。
1、首先,所有从事电子政务软件开发的公司,无论是市场人员还是技术人员,还是高层领导,必
须对中国电子政务的建设有一个明确的认识。即:电子政务建设是伴随着中国的政府机构和管理
体制改革而进行的,改革才是目的,电子政务软件的开发和建设只是手段,对于不断快速变革的
体制,项目需求不变是不可能的,还是由于甲方的特殊地位和特殊的时代,决定了用不同方式来
约束甲方需求的变化,最后只能变为一纸定文一样,这种想法和做法都是不现实的。
2、总体来讲,中国各级政府部门的信息化管理水平还是比较低的,工作人员大都是业务专家,计
算机的应用水平较低,网络化办公的意识还基本没有,尤其是在基层政府部门尤为突出。在这样
的客户面前,“客户需求”是无法在项目实施之前就清晰地描述和确认的。加之政府的具体工作
人员无法承担,一旦项目验收后,系统出现问题的责任,因此,用而不验的现象就成为普遍现象。
3、由于上述原因,电子政务系统开发的关键在于“制定阶段目标”,公司要先将电子政务系统的
特性与客户在理念上进行沟通,双方达成共识:理想、完善的系统是不存在的,改革在深入,认
识在提高,技术在发展,一味追求完善,不但是公司要出问题,系统也会不断的调整下去,得不
到应用,而系统的完善正是在应用中才能得以完善,工作人员也正是在应用中,认识和水平才有
所提高,转而提出更切合实际的需求,公司才能开发出更好的软件。项目才会在二期、三期……
中,随着机构,制度和技术的变革不断完善。
4、掌握了电子政务“阶段目标”的制定方法和操作技巧,与客户达成共识,用户需求变更的情况
就产生了两种方法①接受变更,立即执行;②接受变更,后期项目统一执行。这样既保持了客户
的良好关系,又避免了当期目标的拖延实施,造成项目延误。
5、如果市场人员定好了合同目标和工期,技术人员把握好了前期需求和后期需求变更,文档、记
录清楚,再加上公司高层领导和甲方领导的密切沟通,我认为大部分问题是会友好解决的,项目
也会顺利验收的。
6、操作中的关键环节:①合同的目标和工期,要明确阶段;②需求调查和需求变更要有清楚的文
档和会议纪要;③双方高层要经常及时地沟通;④阶段验收前,文档要齐全,阶段目标要保证实
现,后期目标调整要有承诺。
把握好项目的变更和不断提出新的阶段目标会使双方的合作得到更紧密的加强,从而各得其所。

第 259 页 共 756 页
第 2 章 计划执行

第2章 计划执行

2.1 *如何进行项目管理才具有执行力?

导读:项目执行力,是实现公司经营战略目标的关键点。只有激发出公司员工的激情,营造
一种特殊的企业文化氛围,才会有助于执行力的提高。本文就项目开发执行力的界定、项目
开发在执行中存在的问题以及如何采取应对措施几方面展开论述,并以事实证明,卓越的公
司不仅在战略规划上需要花费时间或努力,并同时表现出卓越的执行力。

(一)案例正文

我所在的公司是一家集研发、设计、生产、销售和服务的水电控制设备企业。公司规模不大,
约 80 人。公司的项目管理部门成立也只有 2、3 年时间。

我以前是技术工程部的副主管,今年年初时,转职项目管理部任副主管。目前我公司的项目
管理部应属于弱矩阵型,每个项目的成员来自各职能部门,职能部门主管的影响力和决定权
大于项目经理;项目的特点鲜明,每个项目的外部联络部分包括业主、设计院以及其他厂家,
内部要组织设计、生产和服务。

项目经理在项目启动之初就会制定执行计划表格,该表格由其他关键部门共同认可,但是在
执行的过程中始终不能够有效实现,而且由于项目经理的权利有限,当计划落空时,相应的
纠正和处罚程序极难实现。

盘点一年,展望将来,本人深感郁闷,但是奈何计穷无术,特此请教!

(二)专家点评

胡允清:华中理工大学工学硕士,高级工程师,PMP。资深项目管理实战专家、咨询顾问。
在汽车、摩托车和 IT 行业任职近 20 年,有丰富的项目管理实战经验和团队建设管理经验。
为数十家企业提供项目管理咨询和内训服务,主要客户有三星汽车、比亚乔摩托、天润物流、
小熊维尼(中国)家电事业部、长虹中山分公司、泰科电子、日精电子等。

胡允清点评:

这是项目管理实践中存在的比较普遍的问题。
判断一个项目组织是强矩阵型组织结构还是弱矩阵型组织结构,并不能以是否成立了一个专
门的项目管理部门来简单认定,最终还是要看项目经理和各个职能部门经理是如何分享项目
的控制权和项目资源的调配权。在一个近似弱矩阵型项目组织中,项目经理对项目成员的薪
酬、绩效评估、晋升等的影响力有限或基本没有影响力,在这种情况下,如何提高项目管理
的执行力,我给出一些建议供大家参考。
http://bbs.mypm.net

第 260 页 共 756 页
第 2 章 计划执行

(1) 执行力是与组织文化密切相关的,但组织文化的形成、发展和成熟是一个漫长的过程,
我们不能期盼在短时间内通过组织文化的调整改变来提高项目的执行力,但在组织内实施项
目管理是提高组织执行力的有效手段。
(2) 建立一个清晰的项目管理流程是项目管理部门首要的事情。项目管理流程是一个指导
组织内所有项目(至少是一类项目)的执行文件,它定义了相关人员和相关部门在项目活动
中的工作范围、工作过程和职责。这个流程一般由项目管理部门起草,经过相关部门讨论修
改,最终由项目管理部门、相关职能部门审批,最后由公司管理层终批生效。如果项目管理
部想拥有更多的项目控制权,这时候就可以利用一下公司管理层的影响力了。
(3) 在项目计划方面,尽量让项目成员参与项目计划的制订,让他们了解项目的全貌,参
与决定就意味着承诺,这样做出的项目计划才是职责明确的、可操作性强。尽量主持召开项
目启动会议,邀请一位公司高层参加你的会议就更是锦上添花了。
(4) 在项目工作安排方面,特别注意管理好各个接口,如项目成员之间或部门之间的工作
交接,技术交接、资源交接。交接处是最脆弱的、最容易出现问题的地方,就如同一根柑蔗,
总是断在有结的地方。
(5) 加强项目沟通,适量增加项目信息收集、整理、分析和发布的频次,这样能及时发现
项目问题,利于及时采取纠正措施。可以通过电子邮件等手段,及时将项目进展情况、存在
的问题和纠正措施通报给全体项目成员、不要忘记抄送给项目成员所属部门的经理,如果有
必要,甚至抄送给公司管理层。对工作交付好的成员要及时表扬,对工作交付差些的成员要
督促帮助他们改进,我想没有那一个项目成员愿意看到项目经理在电子邮件中向他提出改进
建议了。
(6) 项目结束时,千万不要草草了事,除了收集整理项目文档、作项目总结外,有条件的
话,主持召开一个总结会议。没有条件也要发一个电子邮件,宣布项目顺利结束,指名道姓
对项目成员和项目职能部门经理对项目工作的贡献和支持表示感谢,如果能从公司管理层争
取到一些物质和精神奖励就更好了。如果对达成绩效事先有奖励承诺,就一定要及时兑现。

项目管理是一门实践性的学科,没有一个方法能解决所有的项目问题。项目经理只有通过项
目的实践,不断提高自身的项目管理能力,形成自己的管理风格和人格魅力,才能逐步提高
项目的控制能力和项目的执行力。

(三)项目管理者联盟网友分析

分析 1、题目:职能部门协调 作者:潘谦

如果这个办法的实施推力不够,就任命一位副总为主管,推行好了之后,再转由一个项目经
理来接手。
个人觉得这个问题目前是不是不仅仅是流程定义的事情,很重要的是各个职能部门协调的事
情。
如果是一位副总为主管,相信职能部门协调的问题能够解决很多。如果不能做到这一点,作
为项目经理必须花时间在各个职能部门的沟通上,首先争取各个部门经理的支持,按时向部
门经理报告最新的情况。在这种弱矩阵中,很多项目组员可能都是对于直接的上司(部门经
理)比较敏感,对于项目经理到不是特别在乎。

第 261 页 共 756 页
第 2 章 计划执行

分析 2、题目:补充一点建议:强化管理制度 作者:一孑 (一孑工作室 feiw@163.co


m)

应该设法建立管理制度。通过管理制度约束大家的行为。弱矩阵组织结构项目经理的权限很
小,很难改变,所以,应该考虑向老总(或副总)推行较为严格的管理制度,从而约束大家,
加强各部门彼此之间的沟通与协调,更要有问责制。作为老总一般是愿意接受较为合理的管
理制度的,大家只需要按照制度办事就行,如果有问题,用制度说话。但有两点非常重要:
一、制度一定要合理、明确、可行。二、破坏制度的人往往是最有权利的人,要有预知。

分析 3、题目:个人建议 作者:飞泉流水

这个案例昨天看到,思考了好一阵,今天抽空进行了分析,给了点建议,肯定有不周之处,
望和大家一起交流。

1)、案例中所说公司组织结构是弱矩阵型(不应该是公司的管理管理部是属于弱矩阵型),
但从 PMBOK 上的准确定义,推断应该是强矩阵型,因为具有这样的特点:有项目管理部
(PMO),有专职的项目经理(PM),只是在具体工作安排中,没有部门经理权利大,这
不能做为弱矩阵的标准。在弱矩阵中,没有项目经理的职位,更不能安排工作,也没行政上
级反映项目情况,所以案例中所说公司组织结构是弱矩阵,是个不正确的认识。其实这个认
识很关键,因为这能看出公司领导层对公司项目管理的重视程度,个人认为成立了 PMO,
并有专职的 PM,是在公司给予项目管理很大的重视和投入,可能问题的关键是如何让 PM
O 更有效地工作,而不是没有相应权限展开工作,如何争取权力。

2)、案例中提交计划的制定得到了共同认可,但执行中时常落空,是因为 PM 权限有限,
纠正和处罚难执行。分析计划执行不到位,最终对公司产生了如何的影响,如果公司领导不
重视,说明项目执行还是满意的范围之内,以后制定计划可以根据以前项目的执行情况,制
定的更加有效和实用。如果公司领导不满意,追问起来,PMO 就可以提供数据资料,来说
明问题的原因在哪里,让领导根据反馈情况确定补救措施,并根据相应条款进行处罚当事人。
PMO 的负责人不要总认为问题很多,要从公司大环境来看待项目计划的执行问题,这样可
能会更客观公证一些,因为在有限资源下的工作,竞争是难以避免的,保证公司关键项目的
资源投入,其它项目的拖延是应该可以容忍的,也可以存在的。反过来说,制定项目计划时,
一定要站在公司大环境下,统一规划来分配资源,制定切实的计划,否则计划制定时,就是
不断和关键项目抢夺资源,必须项目计划是不可能执行到位的。所以计划执行不到位,有多
少执行因素,还是更多制定时的考虑不周,一定要分析清楚,简单一点,根据公司领导的态
度和决定,就可以判断出来。
上面针对案例中提出的问题,进行了二个方面的分析,从分析中得出的观点是加强 PMO 本
身的建设,提高项目管理的认识和运作水平。

由于案例中是需要建议方案,从分析的观点中,根据个人的知识水平及经验,提出 5 点建
议:
1)、加强 PMO 自身建设
加大 PMO 自身建设的投入,提高整个 PMO 理论认识和实践操作的水平,让 PMO 中的所
有 PM 都成为项目管理专家,也只有专家才能带出专业水平的项目,方法有:出去参加专门

第 262 页 共 756 页
第 2 章 计划执行

的项目管理培训,内部定期组织项目管理的学习交流,针对公司典型项目情况进行分析总结
经验教训。
2)、改进项目管理流程
改进项目管理的流程及模板,PMO 运行 2-3 年,肯定已有成文的制度和模板,制定一个项
目管理的流程和模板改进计划,定期有组织地更新和改进,减少一些人为的要求,让流程更
加实用,效率更高,让模板更加自动化,方便填写等。在改进流程的同时,也可以结合项目
考核标准进行一定的调整,引导项目人员关注主要问题。
3)、项目计划透明公开
计划的制定和维护,要求透明公开,尽可能信息化。计划制定时,让更多的项目成员参与其
中,让他们对计划做出承诺,而不仅仅是各个职能部门的经理,这样项目成员会更了解项目
情况,认识到工作取舍的优先性,即使经理布置了其它工作,他的心中还是会为项目的执行
做考虑。在项目计划制定完成并公布后,放到公司上上下下能经常看得到的地方,并定期(每
周)进行进度的更新,让参与项目的职能经理本身也能感觉到项目的压力,同时让公司领导
能经常了解项目的进度情况,感觉 PMO 工作的重要性,虽然更新和公布了项目计划,但项
目报告还是要定期提交的,因为影响项目目标的不仅仅是进度。
4)、建立项目的监督机制
有了项目的监督机制,能保证项目管理的流程和模板实施到位,虽然有 PMO 这样一个集体,
PM 能相互更多的交流和学习,但还是在具体工作上是不能替代的,就必须建立监督机制,
帮助 PM 认识项目中的不足,更客观地评价一个项目的真实情况,建议执行监督的人(QA)
最好独立于 PM,可以直接受 PMO 经理或公司高管层的领导。
5)、提高公司整体水平
提高公司整个的项目管理运作水平,要求 PMO 有项目管理宣传培训的计划,在公司内部,
不断宣传项目管理的思想,不断培训项目管理的流程及模板,对好的项目实施进行样板学习,
让公司所有人都关注和重视项目管理,理解项目管理的作用,成为项目管理的受益人。
建议就这些,总得来讲,案例的提出人不要郁闷,在 PMO 内部挖掘潜力,保持积极的心态,
在年前制定好 PMO 明年的整体计划,但也要量力而行,有所重点突破,首先让领导感觉有
效果的,逐步形成良性循环,推动公司发展,成就个人的一番事业。 项目管理者联盟文章,深入探讨。

分析 4、题目:我们也有这样的问题 作者:王婷

这可能是大部分项目经理都感到困惑的地方吧,企业给予的期望值和执行力不对等,导致在
真正执行的时候会遇到各种力不从心的困难,这和企业自身的机制有很大关系,也和国内的
项目管理机制不成熟有关系。作为项目经理,在很大程度上我们会在执行力上受阻,会受到
各个层面各个环节的困难,这也困惑我许久,我所能做的是一个很笨的办法,把各个相关环
节组织起来开会确定一些事情。

分析 5、题目:建立制度,加强授权,规范流程,做强势项目经理 作者:周小姐我觉得
您说的这种状况在很多公司都有。

当项目经理的授权不够充分的时候,项目管理的执行力是很难体现的。在项目早期,当项目
经理处于弱势的时候,不妨请分管项目的公司副总级领导担任项目经理(哪怕是一个名誉上
的);帮助落实项目管理流程、绩效考核制度。这一点项目经理必须要说服公司高层,否则
做不出什么的。

第 263 页 共 756 页
第 2 章 计划执行

另外,很多公司说是重视项目管理,但实际上执行中并不能真的从项目管理的角度来管理,
这时,项目经理必须从建立与完善项目管理流程、建立和落实项目管理绩效考核制度入手,
使项目管理真的得到落实,实际上落实的过程,就是变得强势的过程。随着项目管理发挥的
作用越来越大,公司对项目经理的授权也会逐步提升。当然,这中间还是有许多工作要做的。

分析 6、题目:理论结合实践 作者:何清华

感谢大家从各个方面对我所提出的案例进行了中肯的分析。经过近一年实际工作的磨练,我
已经能够深深感到自己需要更深的理论知识作为支撑,正如谭强 TX 说的好,自身能力是能
够左右事情的解决程度的,至少是能够影响项目的发展方向。因此我也决定进一步完善自己
项目管理理论的系统学习。为此我已经获得了某高校项目管理在职硕士研修班研读的资格,
目的不在于镀金,而在于学有所工、学有所用,以此来提高自身的理论修养,理论结合实际
来解决问题,并致力于建筑有自己所在公司特色的项目管理系统。当然在日后的探索和实践
过程中,还需要和大家一起进行开诚布公的探讨,希望和大家一起进步。再次感谢大家不吝
赐教,祝大家新年快乐。

分析 7、题目:过程清晰,职责清楚,绩效应用有对象 作者:杨锋雷

我公司也有专职的项目管理部,6 名专职项目经理负责 80 人开发团队的所有项目。从职能


关系上,各资源部门主管的影响力和决定权在执行情况上大于项目经理;
在项目过程中,我采取以下规则:

1)项目管理部经理和资源部门经理对等处理项目过程中项目目标和资源提供的决策问题;
2)项目经理按照项目目标,利用既定资源,完成项目目标;
3)在项目过程中,如果资源部门需要调动资源,需通过项目管理部的同意。 本文转自项目管理者联盟

4)资源部门负责完成项目的开发目标;项目经理对资源部门提供的资源的工作业绩进行考
核;由资源部门应用项目经理的考核结果。应该讲,通过项目流程清晰,职责清楚,可以为
项目经理提供充分的 Power。

分析 8、题目:如何进行项目管理才具有执行力? 作者:andyplay

个人觉得这和公司的整体经营策略有一定的关系。从老板的角度来看,企业的组织架构与管
理模式始终是为其利润来服务的。就目前公司的规模也许老板认为那种职能型的管理方式效
率更高、决策更快,短期内可以带来的利润也更高,而对于项目管理仅仅是期望能够有 PM
这样一个角色在各职能间起到沟通和协调的作用而并非项目的绝对领导。在这种机制下虽然
出现一些问题或项目的延误没人能够承担责任,但我相信项目经理本身也不会有太大的压力
和责任,因为权责在一定程度上还是对等的。

不过,随着公司规模的逐渐扩大,部门体系越来越复杂,公司整体的决策效率会降低,这时,
站在项目的角度,就迫切需要一个强有力的小老板--PM 来领导一个跨部门的团队来推动项
目的进行。项目经理在公司的地位和权力也会逐渐提升,当然所承受的压力与责任也会变大。
在这个阶段,项目管理本身也不会仅仅停留在那种人制的水平,而是需要借助各种有效的管
理工具和手段来加强项目管理的执行力。在这里,公司就非常需要建立一套切实可行的项目

第 264 页 共 756 页
第 2 章 计划执行

评估机制来对各部门体系进行制约,以敦促整个公司的每个项目干系人能够齐心协力的为项
目而奋斗。具体的操作上可以设计一些量化的表格或指标,并借助公司高层和质量部门来全
面推行。

分析 9、题目:如何进行项目管理才具有执行力? 作者:ZX

案例可以总的归结到一下几个方面:
1)、人事管理机制
任何一个人事管理机制的确定都是根据现有的贵公司,现有员工成分和资质,并根据公司现
有的人力资源能力来确定的。它同我们所熟知的生产力和生产关系之间的既矛盾由统一关系
是相似的;有矛盾就预示这发展,不发展就会没落。
案例中所说的项目管理部属于弱矩阵型,相信也是有一定特定原因的。要改变它是一个漫长
的过程,改变它的动力就是公司和员工的共同平衡发展。
2)、项目经理个人魅力
项目经理是一个项目小组的协调者,如何在项目管理过程中:保证内外沟通畅通,妥善协调
项目所需要的各个方面的资源,使项目组成员安心乐意为项目做出自己最大的努力。他(她)
应具有一定的管理经验和技巧;但其个人魅力也是很重要的。 项目管理者联盟文章,深入探讨。

绝大多数团队的都会按照团队等级去发展,先是命令指派性团队,最终达到自我管理的主动
团队。可以大胆的说:一个项目小组的团队等级很大程度上被项目经理所决定。
从项目组成员的分调和组成;项目磨合(项目组同公司);人员磨合(项目组内部/人员原有
部门);项目组制度形成;计划的制定和执行等,一系列的过程和工作项目经理的个人魅力
起到了决定作用。
3)、计划的制定、确认、实施、跟踪、变更
案例中提到“项目启动之初就会制定执行计划表格,该表格由其他关键部门共同认可,但是
在执行的过程中始终不能够有效实现,而且由于项目经理的权利有限,当计划落空时,相应
的纠正和处罚程序极难实现”这种方式是我所不赞同的,一个计划的制定就是为了指导项目
工作的有序进行,但是并不是说项目的进行就 100%按照计划进行;任何人的水平都是有
限的而且不可能预知到所有项目将来可能出现的问题和风险危机。起初项目计划是必要的,
但它并不是一旦制定就不能更改的。 http://bbs.mypm.net

一个计划制度,必然包括:计划的制定,计划的确定,计划的实施,计划的跟踪和计划的变
更。我认为其中:计划的实施、跟踪和变更尤为重要。在对实施的跟踪反馈实施过程中的问
题,并对计划进行及时的变更,这样才能够更好的起到计划的真正意义。

分析 10、题目:提高执行力! 作者:zheng rong

一、首先你需要得到公司对项目管理的支持,必要时可是同老板进行面对面的谈话,让老板
知道成立一个部门就要发挥一个部门的作用
二、在同老板交谈完后,你自己要提出一个可行的方案---加强执行力(比如可以提出各职
能部门同项目管理有关的人员的考核要把职能部门经理和项目经理的意见结合起来)
三、同其他部门的相关人员加强联系
四、在指定计划时同相关人员交流意见
五、多召开项目管理会议,加强同项目人员的联系 项目管理者联盟文章,深入探讨。

第 265 页 共 756 页
第 2 章 计划执行

分析 11、题目:商场 作者:谢天

其实管理二字很容易理解,管:则是管人与事物。理:就是把你所需要的资料和信息整理清
楚。说起管理曾经有老总问过我这么一句话说:“你知道管理的最终目的是什么吗?”我当时
的回答是:“利润”。他说错:“管理的最终目的还是管理”。为什么不是利润了?利润是物品
对企业所创造的价值。也许有人会误解物品还不是由人来管理的吗?没错物品是人员来管理
的,但是当你理解管理二字的意思的时候,你就知道物品只是有人把其整理的顺畅、优良、
价格定位。但是真正的利润则是商品和消费者之间的一种磨启和介质。其实这之间的问题处
于在管理则是管理,销售则是销售。认清楚二则之间的关系就行。现在的企业管理则往往都
是以管理来论利润,这是不切实际的一种定位,这样的利润就导致了现在要成立 3.15 消费
者权利日和这么多假货和水货的上市。

2.2 *项目管理与进度计划管理

(一)案例正文

某系统集成公司现有员工 50 多人,业务部门分为销售部、软件开发部、系统网络部等。经
过近半年的酝酿后,在今年一月份,公司的销售部直接与某银行签订了一个银行前置机的软
件系统的项目。合同规定,6 月 28 日之前系统必须投入试运行。在合同签订后,销售部将
此合同移交给了软件开发部,进行项目的实施。项目经理小丁做过 5 年的系统分析和设计
工作,但这是他第一次担任项目经理。小丁兼任系统分析工作,此外项目还有 2 名有 1 年
工作经验的程序员,1 名测试人员,2 名负责组网和布线的系统工程师。项目组成的成员均
全程参加项目。在承担项目之后,小丁组织大家制定了项目的 WBS,并依照以外的经历制
订了本项目的进度计划,简单描述如下:

1、应用子系统
1)1 月 5 日~2 月 5 日需求分析
2)2 月 6 日~3 月 26 日系统设计和软件设计
3)3 月 27 日~5 月 10 日编码
4)5 月 11 日~5 月 30 日系统内部测试

2、综合布线:2 月 20 日~4 月 20 日完成调研和布线

3、网络子系统:4 月 21 日~5 月 21 日设备安装、联调

4、系统内部调试、验收
1)6 月 1 日~6 月 20 日试运行 http://bbs.mypm.net

2)6 月 28 日系统验收

春节后,在 2 月 17 日小丁发现系统设计刚刚开始,由此推测 3 月 26 日很可能完不成系统


设计。请问问题发生的可能原因,小丁应该如何保证项目整体进度不拖延?

第 266 页 共 756 页
第 2 章 计划执行

(二)专家点评

王树文 毕业于中南大学,获硕士学位,现就职于广州华南资讯科技有限公司(上市公司),
从事过多个大型项目的开发和管理工作,目前任广州华南资讯科技有限公司软件质量保障总
监,兼任公司 SEPG 执行主席和软件测试部经理。

王树文点评:

问题一:我分析主要有如下两方面的可能原因: 本文转自项目管理者联盟

1、 小丁在进行项目进度计划安排时,可能没有考虑春节法定假日的情况,在工作安排上存
在严重不合理; 本文转自项目管理者联盟

2、 小丁对项目的监控力度不够,如果真有进度延误的问题,那么这个问题应该在春节放假
前(或更早)被发现。

问题二:小丁可以采用如下的措施来保证项目整体进度不被拖延:
1、 在编码阶段和测试阶段适当增加资源或安排适当加班,将这两个阶段的工期适当缩短些
(建议最好不要通过增加设计人员的办法来缩短设计工期);
2、 将试运行时间往后挪一点(因为从目前的计划来看,试运行的截止时间和系统验收时间
中间有一周的可“活动”时间),因此可以在这方面也做一点文章。

(三)案例分析

分析 1:初看后得 3 点感言 作者:梁桢

首先,因为小丁第一次做项目经理,而且兼任系统分析工作,所以在完成自身工作同时便有
了自身工作已经完成,剩下就是系统设计人员的工作,难免事不关己高高挂起的感觉,这是
项目成员升为项目经理后常会发生的惯性做法,此为其一。
项目管理者联盟,项目管理问题。

其次,从时间上来看,2 月正好是春节时间,在春节前往往没有严格的管理都会出现工作松
懈的情况,再加上春节放假 7 天,工作势必会拖延,这是在做 WBS 时没有考虑到的问题,
其为二。
最后,做为项目经理对项目负责,需要全程监督和控制项目,对于新升任项目经理必须对于
风险、成本、质量、沟通有全面的准备。

从笔者的文字来看工作被拖延了 2 周(10 个工作日)左右,所以需要加大工作强度,同时


必须严格把关系统设计的质量,时间紧迫的代价往往时质量的下降。文字结束前希望日后能
看到笔者对于已经完成的项目的分析和采取的措施和最终结果。

分析 2:不见得正确 作者:lxj

1.项目计划不切合实际,如:对困难估计不足 http://bbs.mypm.net

2.项目计划太粗,存在较大水分
3.各阶段目标及具体工作不明确,时间浪费

第 267 页 共 756 页
第 2 章 计划执行

4.团队建设环节薄弱,工作效率不高,协作精神差
解决的方法 本文转自项目管理者联盟

1.明确目标,争得团队认同
2.调整、细化各阶段计划

3.通过沟通,激励等方式建立良好的团队精神

分析 3:跟着感觉走 作者:张文锐

仅根据背景的简单描述,凭着文字表面的东西,可以简单分析原因如下几点: http://blog.mypm.net

1、小丁的 WBS 设置应该有问题。


项目组的成员均全程参加,在不同阶段应该有具体直接的责任人,责任人直接对项目负责,
小丁则需要保持与直接责任人的沟通,了解进度、发现问题;从字面上根本看不出除了小丁
之外的阶段负责人;
2、小丁对进度计划的控制有问题。 项目管理者联盟,项目管理问题。

进度计划确定后,应定期进行核对和调整。春节之后小丁才发现有问题,可见第一和第二阶
段的计划是失控的。
3、小丁的管理方式有问题。
从小丁的背景看,应属于技术出身转型作管理的技术型管理人才。应该说在解决技术问题上
具备得天独厚的优势,但是第一次作项目经理,难免亦从技术人员而非管理人员的角度出发,
安排人员、计划进度,从而在管理上有不到之处。

鉴于以上三点,建议小丁尽快做到:

1、马上停止着手发现问题症结所在,调整人员组成和职责划分;
2、和所有成员沟通,修正计划进度,并加强里程碑的控制;
3、转换管理方式,跳出纯技术管理的圈子。

分析 4:个人意见 作者:pty
谈几点个人意见:
1.由于刚从技术人员转为管理人员,制定的计划更多是从技术方面考虑,对于人员管理方面
考虑不足。
2.对于春节对人员影响考虑不足。 本文转自项目管理者联盟

3.管理过程中反馈环节存在不足。
建议:
1.调整、明确人员职责。
2.细化目标。
3.对整个团队说明目前情况,改变激励机制,加大工作力度,按时、保质完成目标。
项目管理者联盟文章,深入探讨。

分析 5:可惜。 作者:夏雪松

第一需求分析好像时间太长了,一个月,这个项目好像不是很大.
项目计划没有制定完善.控制还没有做好,春节后才发现进度存在问题,说明项目沟通也不

第 268 页 共 756 页
第 2 章 计划执行

是很好.
解决办法:
采取加班赶工,详细的做好剩余工作的 wbs,以及责任矩阵图.

每天都要监控项目的进度,加强沟通.如果开发人员的水平存在问题,那么可以向高层申请
高水平的开发人员.

分析 6:项目处于不可控状态 作者:许春飞

我觉得项目的前期准备不是非常充分,存在如下问题:
1、项目的 WBS 没有做到位,过于粗粒度,没有达到能够完成项目分配的粒度,因此小丁
根本就没有办法跟踪和评估项目的正确进度,因此导致在第一阶段就出现了项目延期。 http://blog.mypm.net

2、不仅系统设计将延期,实际上后续的综合布线计划有问题,完全可以提前到需求分析结
束后马上开始,因为这样安排不会造成资源和工期的冲突。
3、项目过程采用瀑布模型,无形中将增加项目风险。
建议:
1、重新考虑 WBS 结构,尽量符合可分配、可实现的原则; 本文转自项目管理者联盟

2、考虑部分工作同步开始,节约时间
3、适当的进行加班。

分析 7:问题 作者:张立人

感觉主要问题是 wbs 的分解太粗。这样对项目的计划,控制都会出现问题。


第一:要做好计划,计划就要尽量的细致,否则就无法采用项目管理的方法保证项目进度。
第二:资源也无法加载到工作任务上去。
第三:项目的质量也无法控制到点。
于是进度,费用,质量都得不到很好的保障。

分析 8:补充两点关于沟通和如何编制 WBS 的建议 作者:王勇

前面的许多高手已经发表了看法。有的从沟通的角度谈问题,有的从计划控制的角度谈问题,
还有的节假日影响的角度谈问题,等等。较多的人谈到了沟通的重要性。

我也来补充两点:
项目管理者联盟文章,深入探讨。

首先:沟通。项目中如果出现了问题,首先要检查的就是沟通管理。
1.团队的成员是否明确项目的计划,是否真的认可该计划?
2.各个工作的执行情况是否定期汇报了?从上文中可以看到,项目从 1 月 5 日开始,直到 2
月 17 日楼主才刚刚发现比原来计划晚了并且于可能原计划无法按期完成。
3.出现了问题,楼主没有主动和团队成员自行分析。
(或许分析了,只是没有在上文中谈到。)
如果有楼主自行分析的项目可能延期的原因的话,我想大家会提出更多的建议。 http://bbs.mypm.net

其次,WBS 编织过于简单。我认为楼主提供的项目计划是提供给老板或者客户看的,而不
是团队内部使用的 WBS,这种粗糙的 WBS 更不能作为编织项目计划基石。楼主只是给出

第 269 页 共 756 页
第 2 章 计划执行

了一个项目的大概框架和子系统的各部分的期望完成时间。从该 WBS 上面可以看出最底层


的任务的工期至少也在半个月左右。

如果任何一个任务出现了问题,再加上上面第一点谈到的沟通问题,就必然会出现楼主现在
遇到的问题。即延期和延期发生了较长时间才知道。
那么既然问题出现了,如何解决哪?

首先,检查沟通。大家一起分析出现延期,倒是是什么原因导致的。是否存在沟通问题?如
果存在的话,如何解决?

其次,沟通后重新 Update WBS 和项目的 Schedule. 项目管理者联盟,项目管理问题。

关于 WBS 和 Schedule 的编制。记不清是在 PMBOK 还是在其他的什么书上面看到的,WBS


中的任务的工期最好不要长于一周。如果长于一周,就可能出现失去控制的情况。

分析 9:项目风险分析 作者:王淼 本文转自项目管理者联盟

各位同行已经谈了很多有价值的观点,我这里再补充一点:
作为项目经理在接受项目时就应该充分考虑项目可能遇到这样或那样的的风险,并应作详细
的风险评估。案例中的小丁显然没有足够的经验。如果预计到进度滞后风险,则应在项目中
预留准备资源,如预留额外的设计人员,这样在风险真正发生时,可以避免整个项目进度滞
后。

分析 10:团队协作,加班加点 作者:wxh http://bbs.mypm.net

1. 项目估计有问题,项目管理必然要占用很多时间。导致小丁自己成了短木板,缺少一个
备份的系统分析人员。
2. 前期小丁对项目进度控制不力.系统设计延迟了 10 天的时间,这么长的时间后才发现。可
见平时对项目控制较差。
2. 沟通协调不够,有些事情可以证其它人去做,包括系统分析及设计工作.如果只是自己做,
项目可能会延迟更大。

解决:

1. 调整目标,协调人力加入项目。
2. 一般来讲,项目中质量是第 1 位的,考虑调整计划,延期完成。 http://bbs.mypm.net

3. 同项目组人员沟通,加班加点. 可以在软件设计,编码阶段压缩时间。

2.3 *进度控制中“人”的问题该怎么解决?

(一)案例正文

姓 名: 孙钰 所属行业:农林业

第 270 页 共 756 页
第 2 章 计划执行

所属主题:进度管理
邮 件: lbsy923@126.com

最近在工程管理中遇到以下几个问题:
1、设计承包商图纸供应跟不上进度; http://bbs.mypm.net

2、生产承包商的资金长期不足,现场项目经理权力有限,技术人员短缺,整体生产进度缓
慢;
3、施工承包商过分依赖建设单位,许多问题不能主动去沟通、协调、解决;
4、监理不能积极作好事前控制工作、为建设单位进行协调、监管出谋划策。 本文转自项目管理者联盟

以目前情况看,在建设单位资金充足的情况下,我认为应该是相应的“人”的问题,包括项目
经理、组织人员及其意识的问题,大家请发表一下自己的看法吧。应该怎么理解和解决这些
问题?

(二)专家点评

点评专家:李大明 山西沁水人。1982 年在重庆建筑工程学院道路桥梁工程系本科毕业,1


985 年公派留学英国伯明翰大学,1986 年获得英国工程管理硕士学位。

回国后参加京津塘高速公路建设,担任总监理工程师代表,致力推行菲迪克合同条款和工程
监理制度;随后负责世界银行在华贷款公路项目建设的协调管理;主编出版《京津塘高速公
路工程监理》、《高等级公路建设管理》等论著;先后荣获国家科技进步一等奖、交通部科
技进步特等奖、国家计委和团中央“共和国重点工程青年功臣”等奖励。2005 年起参加英国
WSP 顾问集团,担任 WSP 亚洲公司协理董事兼交通及基建总经理,以及 WSP 上海公司总
经理。

李大明点评:项目过程本来是由不同单位和个人执行的,不能指望参加项目的每个单位或个
人,都具备同等的项目管理专业知识和业务能力,甲方项目经理的任务就是要把设计、监理、
施工这些表现参差不齐的资源整合起来,力争顺利完成项目。因此,你遇到的问题是一个典
型的项目形态。

面对这种情况,项目管理的指导思想要明确,即:一定要立足于提高各个单位的项目管理意
识,加强沟通,少一些“监、管、查”,多一些“传、帮、带”,投入更多精力,加快管理节奏,
把大家散乱的步调和参差的表现逐步协调起来,争取赶上项目整体计划要求。

具体建议包括:

“加密控制,查找问题”—— 缺乏项目管理经验或管理素质低下的突出表现是:搞不清楚自
己的问题出在哪里,与整个团队似乎没有共同语言,你急他不急,急也急不在点子上。于是,
进度永远赶不上计划,计划永远追不上变化,拖累整体进展。这时,要加密控制节奏,可以
考虑把月计划协调会改为每周召开一次,把控制节奏调整为周节点控制,整个团队每周坐在
一起,对照每周工作节点完成情况,抠计划、查问题、碰对策,让潜在问题和风险一目了然,
让下一周的对策更加具体和有的放矢。几周下来,大家就能陆续被统一到正确思路和节奏上
来,就会有共同的项目语言和协调的工作步调。纲举目张,这是项目管理中关键的理念。

第 271 页 共 756 页
第 2 章 计划执行

“深入基层、逐个辅导”—— 家家都有一本难念的经,特别是在项目已经出现问题后,每个
单位都会有些困难情况,不方便或不可能在团队例会上充分反映,甲方项目经理应该理解和
体谅。可以在加密整体控制节奏的基础上,考虑建立一个现场办公会制度,甲方项目经理定
期(比如每周一次)到每个单位去单独进行沟通,了解真实情况和实际困难,并针对每个单
位的弱点、特点、困难和问题,单兵教练、解剖麻雀、个别指导,用项目管理的专业知识和
经验,手把手地帮助他们出谋划策、持续改善,使工作更加有的放矢,从而切实提高整个团
队的沟通、协调和执行能力。都说项目管理中沟通最重要,此言不谬。

“突出重点、抓住关键”—— 在控制节奏加密和逐个指导的基础上,就有条件针对各个单位
的不同情况和问题,适当简化项目管理的目标和程序,集中资源和精力,督促解决影响项目
执行的最迫切的关键环节,切不可泛泛而谈,大而化之,没有重点,最后仍然是了无用处。
比如,在我的一个项目上,施工图设计进度一度严重落后,经过连续几次周例会的跟踪分析
和向设计单位的详细了解,原因是暖通专业的设计深度不够,部分设备选型也受到外界因素
干扰,迟迟不能确定,结果导致电气、结构等专业的设计无法落实,不能及时出图。于是,
立即召开暖通专业的设计协调会,针对每个子项目的设计质量和深度以及主要设备选型,指
导和帮助设计单位发现问题,专家会诊,当场拍板,形势立刻改观。

所以,我的体会是,如果遇到有经验的或成熟的设计、施工和监理单位,建设单位项目管理
可以采取“跟着走”的办法,充分发挥各单位的积极性,无为而治,控制大局;只有在遇到问
题的时候适当地推动一下。相反,在您的这个项目情况下,恐怕要建设单位的项目经理“带
着走”、“领着走”了。很辛苦、很劳神、很吃力,但更有挑战性,我很喜欢这样的项目。哪
里说得不对还请多多原谅和指教。

(三)项目管理者联盟网友评论

分析 1:进度控制中“人”的问题该怎么解决 作 者:汪成
这种现象在工程实施过程中经常遇见,你不妨先组织各方项目经理和总监召开一次协调会,
把利害关系说清楚,强调并让大家充分意识到合同的严肃性,让大家都当面说,不要背靠背。
并形成记录。如果效果不好,可以分别找各单位的负责人,充分分析工程的现状及存在的问
题,要求适当调整人员甚至组织结构,以适应工程建设的要求。一般来说这样基本可以解决
了,当然可能有更深的问题,这种情况也曾见过,那就只能置之死地而后生了。

分析 2:奖罚重要 作 者:anbh (beijing abh1221@163.com)


既然建设单位资金充足,那么事情就很好解决:
1、根据项目的进展设定目标,对设计单位、施工、监理单位等进行奖罚,重点是奖,主要
对各承包单位的一把手。力度尽量大些。
2、如果这些分保单位的上级还可以合作的话,可以定期与上层进行沟通。保证各分包单位
的上级对项目支持,包括人员、资金和政治上的支持。
3、进行必要的惩罚,对现场不力的分包单位一把手清除出现场。首先要沟通,迫不得已才
这样做。应该做时就尽快做。
4、根据项目的进度进行付款,对分包单位进行成本核算。如果项目足够大,应要求分包单
位在现场设立银行帐户,保证专款专用。
5、业主要放下业主高高再上的心理去工作。项目经理没有权力,那么就抓住他们的上级领

第 272 页 共 756 页
第 2 章 计划执行

导。业主既要当好爷爷,必要时也要当好孙子。
6、沟通、沟通、再沟通、
7、在此种情况下,建设单位要有专业人才进行项目的组织。技术和管理上的专业。

分析 3:快速跟进的风险 作 者:xing jianming


孙钰你好:
看了你的案例就知道,你是按照快速跟进组织项目。任何快速跟进的组织方法都是有风险的。
在你决定采用这种方法组织项目的同时,你应该对此产生的风险进行评估.确定你对此风险
的承受度和相应的风险储备。现在看来你项目中的主要问题就是发生了快速跟进的风险.如
果现在风险的影响在你的承受范围内,那你就不必惊慌,尽量降低风险的影响,将工作节奏
调整到正常的状态上来。 http://bbs.mypm.net

要满足这点,你必须找到风险发生的原因.有时侯也不完全是设计院的原因,你要检查一下
你的功能需求是否提交完善。设计的技术标准是否有缺陷.这些都会影响设计单位的工作滞
后。
你在案例中所指的人,实际上都是你的合同相关单位,他们与你是买卖双方的共赢关系。在
这个案例中,主要问题还在业主方面,因为造成这种状态是由于业主快速跟进的组织风险所
引起的。如果你是该项目的业主方项目经理,你不但要尽快的调整好项目状态,同时还要做
好合同相关单位的沟通工作,避免索赔事件发生。

分析 4:实际中的通病 作 者:饶崇辉
1、你的问题是项目管理中的共性问题,作为投资方的管理,这几个问题是你对现状的抱怨。
首先要先解决你自己的问题,进度目标是否明确可行,线路和关系是否妥当,有没有设立适
当的激励机制和手段,重要的是对参建各方的要求和给报酬是否适当。
2、如果上述问题都解决了,那就需要更细致的管理,将项目进程中的每一个具体问题都列
举出来,将分析解决分给项目管理的每一位同志,由简入繁;
3、更重要的你要保持高度的热情和信心,把自己的积极情绪传染给周边的同志和相关各方;

分析 5:对症下药 作 者:杰罗
anbh 地分析很好
资金充足的情况下,应加大协调力度,建立共同目标,每一阶段的计划和每一个控制手段都
要与合作方的利益挂钩。特别重要的是,一定要找到一位协调高手和强有力的管理者统筹管
理。
1、重新审核计划
2、检查资源配备是否满足计划要求

3、建立工程协调例会,一周或三天,必须是负责人(能调动资源的人)参加。
4、加强跟踪控制,根据进度完成情况奖罚。
5、考虑设计现场办公。
6、施工单位一定要专款专用,可考虑建立专用账户。
7、与施工单位老总加大协调沟通力度
8、根据利益共享原则,监理单位、施工单位采取积极的和有效措施为建设单位产生的效益,
建设单位拿出一部分奖励。

第 273 页 共 756 页
第 2 章 计划执行

9、抓关键人物,抓典型。监理单位的总监水平非常重要,如工作不力,考虑换人。
必须注意的是,你看到的原因未必是真正的原因,包括合作方反映的。因此,多调查,特别
是合作方中的小角色和不满现状人员往往透露有价值的信息。
总而言之,必须对症下药,才能有效。

分析 6:问题的解决 作 者:张慧勇 本文转自项目管理者联盟

看了你的问题,我觉得可能你完全处于被动当中,甚至感觉很无奈,我认为,既然有这么多
问题,应该项目项目各方聚在一起(项目中能说了算的头头),把问题逐个的明确,并拟定
成文,明确各方权力和义务,各方遵守,并严厉执行,作为项目经理的你更责无旁贷,积极
主动的解决,并加大力度,解决到底。

分析 7:管理的艺术 作 者:陈圣文
所以说管理是一门艺术,不可能任何问题都有一个明确的解决方法。像孙钰提到的这个案例,
存在着多重问题,想一时解决是不可能的。“许多问题不能主动去沟通”,作为一个管理者,
平时就要培养领导对你的信任感才可以的。只有得到领导的信任才可以调动领导这个资源。
有了领导这个资源,在项目中就会顺手的多。

分析 8:不知道对不对 作 者:潘琦
1、在选择生产商的时候不能被公司的表面蒙蔽,如果有条件可以私下和生产商的员工聊聊,
或者在参观后的半个月来个突然参观。
2、如果自称大公司的话,那公司员工的私车拥有量会有一个比例的(比如 30%),国内公
司的项目经理的权力可以说是没有的,因为国内公司的老板不会把权力给自己的员工,因此
选择生产商最好是国外的公司。 项目管理者联盟文章,深入探讨。

3、给施工承包商一定的压力,而且这种压力要不时的给予。
4、还是老问题,国内的不知名的监理公司就是为了走程序和政策上需要才走进工程的,很
少有负责任的,这个问题就得业主和承包商要严格的按照合同去做了,一切以合同为主。

分析 9:明确目标、加强沟通、主动执行计划 作 者:谢仁禄 http://bbs.mypm.net

1、项目目标是否明确,如果已经明确,应尽快制定一个沟通计划,加强与各的沟通协调;
如果不明确,需尽快编制项目的总进度计划,包括设计进度、工程发包/分包、材料设备选
型/采购、劳动力组织、施工技术方案、现场施工组织等,对整个项目重新进行统筹安排。
2、项目需有一个能统揽全局的“项目经理”,如果业主直接参与管理,业主的项目负责人
应该承担此重任,如果业主不具有这种能力,应尽快授权给现场总监理工程师承担此重任。
如果现有总监能力不够,应更换总监。 项目管理者联盟文章,深入探讨。

3、加强沟通,明确各方想法,对症下药。采取相应激励措施,形成制度,调动各方积极性。
事实证明只有各方主动工作,计划才有执行力,项目才有可能按计划推进,光靠某一方来推,
其它各方消极不动,项目将停滞不前。

本文转自项目管理者联盟

第 274 页 共 756 页
第 2 章 计划执行

2.4 *我的软件项目应该如何启动?

(一)案例正文

我们公司是一家软件开发企业。现状是目前有个产品,但是存在很多问题,准备开发新版本,
之前版本存在的问题有一部分应该说是开发人员的问题,但是因为我来得时间不长,不甚了
解。整个公司都对新版本给予厚望,就目前的情况来说,老板希望技术团队有个大的改造,
但是我不想这么做,因为毕竟新人进来不见得合适、而且需要相当一段时间的业务熟悉期。
现在老板问我怎么做?我觉得可以有这么几步:

1、老板主持个动员大会;
2、完善部分规范、制度;
3、增加一些激励措施;
4、我同他们加强沟通,了解每个人的具体情况,帮助他们
5、加强项目监控

应该就可以了,实际上主要是营造一个好的氛围。其他还有什么么?希望大家帮帮手,对我
很重要,谢谢!

(二)专家点评

专家介绍:卢毅,清华大学 MBA,PMP,曾任某高科技公司项目管理副总裁,现任北京商
略达项目管理研究中心首席专家,国内著名的项目管理培训师和组织级项目管理体系规划咨
询专家。卢毅先生有十多年项目管理实战经验,亲自管理过几千万级的电信行业项目、几百
万级的多个电力行业项目和众多的生产制造、流通、物流等行业项目。历任项目经理、项目
总监、项目管理部门的总经理、公司分管项目实施的副总裁等职,在项目化经营管理、项目
管理方法论、多项目管理和建立公司级项目管理体系等方面有非常独到的见解和实战经验。

卢毅点评:

这个案例反映的是如何在项目启动时做好项目策划,其实这也是我在多次培训课中经常讲到
的一个重要概念。案例讲到的一些步骤,还不是太完整和具体,如何在项目启动前做好一次
项目策划是至关重要的。具体来讲,有以下几个主要方面:
(1)项目干系人分析:一切项目管理活动都应该从干系人出发!案例提及的干系人主要有
老板、技术人员,应该还有需求提出者、项目验收人员等公司其他人员,却没有提及。从案
例描述的情况看,项目经理的做法会有一定的问题,他没有分析各干系人的想法,尤其是他
提的步骤里没有就老板想换技术团队的想法做沟通的计划,将会是一个很大的问题。
(2)明确项目的合理目标:整个公司对新版本都有厚望,说明你很荣幸做了一个众人瞩目
的项目,但同时也说明很多人都对项目有期望。在这种情况下,明确了解和平衡所有项目干
系人的期望将非常重要!可惜,案例中的项目经理却一点也没有提及。在项目启动前在各干
系人之间达成一致、明确和合理的项目目标将直接影响项目是否能成功。目标又包括客户满
意、时间、成本、质量等因素,这些都需要明确。

第 275 页 共 756 页
第 2 章 计划执行

(3)清晰的项目范围:项目管理需要定义清晰的目标和范围,这是项目管理非常重要的一
步。然而,案例里却没有提及。老版本存在的问题是什么?新版本要达到的需求是什么?哪
些是新版本必须要完成的?项目范围不明确将会留下很多隐患。
(4)根据目标和范围确定项目资源需求:在项目前期,需要根据项目目标明确项目资源需
求。案例中还提到老板希望更换项目团队中的一些人,项目经理自己又不抬愿意更换成不了
解业务的新人,我感到他们沟通很不充分,一方面资源需求不明确,另一方面项目资源保障
也许有一定难度。
(5)制定项目计划:项目经理没有考虑时间计划,一般在项目启动时都需要有计划,很难
想象没有计划的项目如何执行和监控。

(三)项目管理者联盟网友评论

题 目:谨慎 作 者:李东和 (京润 lidonghe3682@163.com)


大家都说了很多了,我只想说说我的一点想法: 项目管理者联盟文章,深入探讨。

1、不要很快的对目前产品进行评价----否则太伤设计者的心了、容易产生抵触情绪;
2、你的计划中很好的调动了公司领导的支持,可否再在同时中寻找的一些支持;
3、在项目中分析出不足提出解决办法,最好是自己擅长的部分。
希望对您有用。

题 目:征服人心 作 者:xing jianming (重庆城市建设投资公司 xingzhou540608


@sina.com) http://blog.mypm.net

楼上两位提得很好,空降兵千万要注意着陆技巧。防止挂在树枝上,上下不得,搞得自己遍
体鳞伤。不要忘记实现项目目标光靠你一个人是不行的,你必须依靠整个团队的力量。你如
果不加考虑地在前期项目上动刀子,全盘否认以前的项目工作,就很容易挫伤团队成员的工
作热情。这对你实现性的项目目标不利。我觉得你不应该惊动领导。应该开展依次轻松的团
队活动(如组织郊游)。在一种轻松和谐的气氛下,组织团队成员畅谈对以前版本的看法。
你要仔细地去感觉成员们对次的反映。然后充分总结出以前版本的成绩和对新版本的贡献。
同时分析以前版本的不足之处,要让团队成员大家想法,如何对不足之处进行改进,整合可
用的部分作为新版本的可用资源。这样,你在不知不觉之中获得了你的专家权力,增强了团
队的凝聚力。同时也给你的新项目提供了廉价资源。节省了时间,降低了成本。我不是做 I
T 的。本意见是从项目管理的角度提出。妥否,自己权衡。

题 目:评估项目 作 者:吴明刚 (咸宁学院 wu.minggang@gmail.com)


首先要评估项目在公司中的地位,是主打产品?还是创新产品?原来产品的问题在于技术还
是市场,并以此来评估风险,做相应的工作,如果产品是主打产品,而其问题在于技术,就
应该专注于项目,专注于产品的产出,其需求不需要很大变化,只需专注改进产品,如果产
品是创新式的,用于夺取市声份额的,就应该专注于产品的需求上,当然,空降兵,对公司
文化的理解也是十分重要的,项目管理本就是项艺术活

题 目:“空降兵”要谨慎 作 者:lcmin (CIS lcmin@vip.sina.com)


1、因为原来产品有很多问题,所以老板才需要新的力量介入。这就隐含了你与原来开发团
队的冲突基础,很多人会抱着“看看这个人怎么做?”的心态,你稍不留意,就会陷入被动。

第 276 页 共 756 页
第 2 章 计划执行

2、可以考虑采取先融入再变革的策略。融入团队是通过解决关键问题获得信任、多方沟通
(要注意沟通的心态)、共同确定团队面对的问题等方法来实现的。 在融入团队前轻易不
要做大的变革。

3、问题一定是多方面的,要找自己最擅长的方面下手,是需求? 还是测试和缺陷跟踪?
是产品规划?还是软件架构?是数据库设计?还是很应用界面?等等,一定想办法找自己最
擅长的方面介入。 做出实效来,再扩散到其他。

4、要和老板沟通好,降低其期望值,争取更多的时间。夹在中间两头不讨好的情况并不少
见,“牺牲”的概率也很大。千万别以为自己有“尚方宝剑”就随意改变。

5、着重培养团队中的“有识之士”,即跟你理念一致的人,他们会原来的很多方面提出意见,
并会主动跟你建立信任关系。

题 目:功能第一 作 者:li-hongcai (北京连创 li-hongcai@hotmail.com)


我觉得关键点在客户的需求,弄明白用户真真不满意的部分,先不要动老代码,然后追加确认
后的功能.在这个过程中慢慢熟悉旧的代码.
这样让老板和客户都先知道我们做了一些事情.同时也为我们修改旧代码打下一个基础.
希望对你有帮助

题 目:还需落实外部因素 作 者:舒伟 (武汉 young_roader@126.com)


你的计划工作中,只调动了内部积极因素,应该还需要明确外部环境和资源
召开项目外部启动会议,或者简单点,直接由项目经理打电话预约,再亲自访问对方负责人,
说明人员与工作安排。(熟悉人员关系)

根据合同明确工作范围与工作目标(明确工作依据)。
根据范围管理,制定内部工作计划。

项目开始的阶段,多往客户那边跑,把关系混熟悉,这个时候也是逐步明确软件功能的关键
时刻,多准备文档。

2.5 *如何控制好客户的变更需求

(一)案例正文

目前,我在负责一个海外的通信工程项目,客户是当地的电信领域一个运营商。

由于客户是新进入当地市场,所以相关的经验比较匮乏。加之我公司对当地的一些情况不是
很清楚(我们曾努力过,但需要时间),这样从合同签订开始,用户的需求变更就非常频繁,
直接带来了成本和人力等方面的增加。

第 277 页 共 756 页
第 2 章 计划执行

在 PM 层面,我们可以制约他们的 PM。但是有时客户往往把一些事情上升到总裁的层面,
我们 PM 执行层面临来自市场的压力,往往就答应了变更。

请大家帮忙分析一下,在这种情况该如何控制用户的需求变更?

(二)专家点评

点评专家:李大明,山西省沁水县人氏。1982 年 2 月在重庆建筑工程学院道路桥梁工程系
本科毕业,1985 年公派留学英国伯明翰大学,1986 年 12 月获得工程管理硕士学位。

回国后,参加京津塘高速公路建设,担任总监理工程师代表,致力推行菲迪克合同条款和工
程监理制度;随后在交通部负责世界银行在华贷款公路项目建设的协调管理;主编出版《京
津塘高速公路工程监理》、《高等级公路建设管理》等论著;先后荣获国家科技进步一等奖、
交通部科技进步特等奖、国家计委和团中央“共和国重点工程青年功臣”等奖励。

李大明点评:

变更,既是客户的权力,也是客户的为难之处,乙方应该真诚体谅和积极配合。问题是,不
能让权力滥用,不能把本来不好意思的变更,宠惯养成堂而皇之的坏毛病。所以,作为乙方
的 PM,我们确实要想办法“控制变更”,目的是保证我们的有限资源能够尽可能配合“有效变
更”,同时尽可能减少“无效变更”对成本、工期和履约带来的负面影响。这是基本原则。

对待客户频繁的、自上而下的需求变更,建议迅速采取以下办法应对,避免事态蔓延,不让
客户养成随意变更的毛病:

1) 立即建议客户建立变更审批/下达制度,要求明确审批环节、审批人员、审批事项、审
批流程、审批表格样式……,目的有两个:第一,将客户下达变更的流程尽可能地复杂化、
官僚化和长期化,减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的“无效变更”。
第二,留下书面依据,为今后可能的成本变更和索赔准备好“变天账”。凡未履行审批程序的
“变更”,一律是无效变更不予受理,在避免乙方损失的同时,也有助于减少客户无谓的风险。
让我们以“加强管理、优质服务”为理由,说服客户把变更审批流程变得更困难些吧!

第 278 页 共 756 页
第 2 章 计划执行

2) 强化自身计划管理和节点控制的功夫,立即向客户正式提交一份各阶段主要工作节点和
技术关键事项的完成计划,注明任何可能的变更必然引起的时间、事件、成本/工期的代价
和增加的具体工作量,建议/要求客户配合这个计划,确定变更时限,控制变更规模,过时
变更不候,离谱的变更不做,保大局弃小变,推进项目前进。

3) 对于已经形成惯例的零星变更,要努力争取“集中研究、批量处理”,每周或每两周甚至
每月召开一次变更专题会议,集中研究处理这些零碎变更事项,主动控制好工作节奏,硬着
头皮顶住要求随时处理这些零星变更的压力,尽量避免由于处理零碎变更而影响项目运行的
总体态势。

4) 最后,按照客户爱走上层路线的习惯,乙方 PM 也要随机应变,手眼通天,善变求生,
将有关措施和意见随时抄报双方最高层留档备案,采取简报、文件、传阅、抄报、抄送、会
议等多种形式,掌握舆论主动权,逐步让不合理的随意频繁变更,成为客户不好意思开口的
尴尬事件,尽快形成正常的项目执行氛围和良好的工作习惯,也为可能受到影响的项目和变
更所带来的责任问题留下伏笔。
http://bbs.mypm.net

以上意见,仅供批评参考。希望魏先生的项目顺利圆满完成!

(三)项目管理者联盟网友评论

分析 1: 题目:老板的决定是对的 项目管理者联盟会员:奥林匹克 (中铁七局集团


有限公司)

变更带来的不一定就是成本的增加,客观分析变更内容,站在技术的角度向客户分析利弊,
如果确需变更,即使增加了成本也要满足客户需要,这是市场的要求,我相信满意的产品会
给你们带来应得的收入,有耐心就会有收获。

分析 2: 题目:我的建议 项目管理者联盟会员:zhangmin

用户需求的变更总是不可避免的,所以我们要以这种心态去接受和控制用户的需求,而不仅
仅是埋怨。是用户,那她就肯定会提出需求,而由于用户的问题,可能会导致需求频繁的变
更,针对这种情况,我觉得要做好如下几点:
1、作为开发商,要认真钻研用户的需求,了解用户的直接需求,挖掘用户的间接需求,同
时还要对用户需求具有前瞻性;
2、对用户提出的需求,要认真进行分析,包括需求的提出背景等等,也许用户对需求的提
出欠缺考虑,所以我们要认真分析用户需求;
3、即使用户提出了需求,必须按照一般的需求管理流程进行变更控制,该签字就签字,该
确认就确认,这样就保证了即使项目延期或失败,也能知道其原因。

分析 3: 题目:建议老板把自己换掉吧 项目管理者联盟会员:诚

变更的流程:
1. 用户提出变更申请(表格 1-用户申请栏)

第 279 页 共 756 页
第 2 章 计划执行

2. 用户 PM 签字(表格 1-用户 PM 审批栏)


3. PM 评估与交付时间确认( 表格 1-PM 评估/交付时间) http://bbs.mypm.net

4. 是否对原合同内容产生变更?是否影响后续任务进展?是否需要追加人力和其他开销?
(表格 2-变更申请)
5. 用户领导签字确认(表格 2-变更申请确认)
6. 每月变更记录上报自己领导(表格 3-变更清单)

如果你觉得项目快要失败了,就建议老板把自己换掉吧(建议参考华为的项目案例)

分析 4: 题目:量化变更 项目管理者联盟会员:大兵

客户的需求是永远不会满足的,可能一天一个样,为了达到控制的目的,我们可参照七步法对
变更的需求去做一个评估,将需求变更后产生的成本之类的东西进行量化,形成分析报告,提
交于双方领导,达到透明的目的,在允许情况下,才能做到让项目有条不紊进行.如果一味的妥
协那只会让项目进一步恶化!

分析 5: 题目:项目范围变更 项目管理者联盟会员:陆镭

该项目的变更管理到这一步已经非常难以控制了。只有尽量争取公司上层的支持,首先向公
司上层提交一份详尽的项目阶段说明书,明确的说明项目从开始到现阶段的所有细节并提交
相关的报告。说明如果继续迁就用户对项目进行变更,只能带来更大的成本和人力的压力。
项目的变更权尽量由公司上层决定,同时要挟用户如再增加变更就要收取相关的费用。

分析 6: 题目:配合客户,掌控 ECN 项目管理者联盟会员:Jack Pan 本文转自项目管理者联盟

客户的每一次 ECN 都是希望确保产品趋向完美,没有哪个消费者愿意花钱买“赝品”,所以


客户的 ECN,作为 PM 只能配合。
本文转自项目管理者联盟

但是,频繁的 ECN 说明两个问题,客户对于项目目标不明确、技术能力不到位,反映出 P


M 没能给出合理的建设性的专业意见。

PM 需要掌控客户及公司进度成本,PM 可以把客户的每一次 ECN 进行变更完成时间确认和


变更成本分析回复给客户。确认哪些需要收费变更,哪些可以 free 配合客户。这样既可以
维护客户关系,又不致造成公司无谓的损失。

分析 7: 题目:变更的决策 项目管理者联盟会员:daijiangbao
项目管理者联盟,项目管理问题。

客户的做法没有错,变更的批准要得到管理层的批准,项目经理没有批准变更的权力,尤其
是在商业社会中,以合同建立的双方,一般项目经理不是项目出资人,没有资格签署变更,
更不应该答应变更,这也是个资格的问题 项目管理者联盟,项目管理问题。

该问题的关键是合同签署的太烂,为什么不能把所有的需求搞定再签合同?为什么不把变更
的流程写入合同?变更管理的基础是基线,在基线的基础上再谈变更,客户需求制定的好,

第 280 页 共 756 页
第 2 章 计划执行

根本不需要变更,变更管理不是为了变更而采取的管理,要在签合同之前把准确的需求得到,
用法律来维持保护基线,用法律来管理无谓的变更。

第 281 页 共 756 页
第 3 章 范围管理

第3章 范围管理

3.1 *客户需求不清楚引来的麻烦

导读:需求分析阶段是一个项目的开端,也是项目成攻的基础。有统计指出,失败的项目中,
80%是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一,就是对需求
分析的把握程度。需求分析不象侦探推理那样需从蛛丝马迹着手,而是应该先了解宏观的问
题,再了解细节的问题。

(一)案例内容

我们是做手机设计的公司,有专门的项目管理部门,作为研发与外部的接口,在销售人员的
协助下完成与客户的需求沟通。 http://blog.mypm.net

这天,从销售方面提交过来一个信息,客户(A)要求对 X1 产品的 Y 组件进行更换另外型号


的组件进行技术评估。项目经理接到此要求后,发出正式通知让研发部门修改产品并进行了
测试,出了样机给客户试用。但结果客户非常不满的答复说,他们的意图并不是要单一改产
品的这个 Y 组件,而是在考虑要使用 X1 产品的主板放到 X2 产品的外壳中的方案,这个评
估只是这个方案的一部分。
销售部门其实知道客户的目的,但也未能向项目经理说明详细背景情况。经了解,他们只是
认为 Y 组件的评估是最关键的,所以只向项目经理提到这个要求。

请帮忙分析一下,这整件事的关键问题出在哪?我们要如何规避这样的风险?

(二)项目管理者联盟网友评论
http://blog.mypm.net

分析 1、题目:问题首先在客户身上 作者:陈靖

我个人认为,问题首先在客户身上。
是谁提出需求?是客户。需求不清楚是因为客户不知道自己要什么。我经常看到这样的情况,
客户提需求时的内部大战。技术部的客户要求满足 A、B、C,业务组的客户却着重于 E、F、
G。客户内部在打仗,我们作为服务的供应商就得反工,重作,才是最倒霉的。
问题的改变可以掌握在我们手中。
当然,我看得太少,还没有看到现实的例子。但我相信做这个行业的专家,给予客户强势的
引导。不是客户要我们怎么做,而是我们知道客户需要什么,并且让客户认同,真诚的为客
户解决问题。建立行业专家地位,以业绩建立客户的信息,可以把需求掌握在我们手中。

分析 2、题目:沟通管理 作者:赵文岗

我个人观点认为:这是由于沟通不畅造成的信息失真。
我在工作中经常遇见这样的情况,有时候由于客户的解释不清楚,或者我方销售的接受不清,

第 282 页 共 756 页
第 3 章 范围管理

常常使得我们出问题,以至于组件作出来后与客户要求不一致,和你的情况相似。
对此,我建议的方法是:
1. Double check 客户的设计变更要求,确保信息准确。
2. 与客户分享项目进程,在过程中发现、解决问题。 本文转自项目管理者联盟

分析 3、题目:缺少正确的流程 作者:stormzz

销售认为项目经理怎么连这都搞不清楚; 项目管理者联盟,项目管理问题。

项目经理认为销售怎么连这都说不清楚; http://blog.mypm.net

这种事经常发生,我们现在采取的办法是:
1。合同签订前项目经理(需求分析人员)直接见客户,取得第一手资料;
2。需求分析要和风险评估一起交销售签字;
前者可以相对准确获得客户需求,后者可以防止双方扯皮。为了这两点,公司要制定流程,
并强制执行。

分析 4、题目:如何有效进行信息传递

本案例出现错误理解需求的原因在于信息传递发生了失真。
要确保信息的传递准确必须做到:
(1)传递信息的全部
(2)传递真实的信息,即传递者尽量不要对信息进行加工。
(3)传递者具备传递信息的技巧。
从管理的层面,项目经理应该直接向客户求证需求。

分析 5、题目:项目经理的职责 作者:linfeng
项目管理者联盟,项目管理问题。

项目经理的职责在接到一个项目后,项目经理就是这个项目的直接领导及拥有最大的决定
权,拥有向上一级汇报的职责及向下分发任务的权力。
汇报就要有:
1、项目的需求及可行性的分析,需要确认客户的需求。而销售人员只是起到客户与经理人
的一个桥梁。
2、可行性分析需要提供该项目的大概的轮廓,并需要客户的确认。
3、只有在可行性得到通过后,才能对项目进行划分、分块执行,并且在执行过程中还要向
客户通报该项目的执行情况及客户是否有最新的想法以指导项目的完成。

分析 6、题目:项目管理流程及执行力 作者:齐彤彤

该案例的的表象在于企业没有准确了解客户的需求,其症结在于企业内部项目管理;项目管
理部门对于新的需求应有相应的可行性分析和立项审批流程进行管理;既不能因为客户要求
而改,也不能因为销售部门提出就改;需求是否必须变成项目需要流程控制;只有合适的,
没有最好的。
作为一个企业,肯定有自己的项目管理流程,要解决上述问题,需要从流程的合理性以及流
程的执行力两方面分析。

第 283 页 共 756 页
第 3 章 范围管理

分析 7、 题目:客户需求不清楚引来的麻烦 作者:周暾

认为存在以下问题:
1)两个部门的沟通存在问题。
2)项目经理在接受需求时太随意,没有和用户进行沟通确认,
也没有和销售人员进行进一步沟通,并且没有进行评估。 http://bbs.mypm.net

导致公司的花费不必要的人力成本,并且客户不满意。
3)公司在运做上存在漏洞,对于项目经理接受需求的这个操
作没有上一级管理者的审批。
后续应该:
1)应该追究项目经理的责任。
2)修改运做模式,增加部门主管的审核批复过程。
3)安排项目经理再次和用户进行沟通,明确用户的需求。

分析 8、题目:客户需要不清楚引来的麻烦 作者:naqz

感觉是个沟通管理的问题,部门之间的沟通协调方面有些问题,该项目的项目经理,一个项
目主要的干系人不光是最终客户,还包括部门的销售,以及该项目有所影响的所有人都为干
系人,该项目经理应该正确的认识到这个问题,公司内部没有很好的配合该项目的实施或问
题的处理,说明公司内部协调方面存在问题

建议:项目经理应该首先理顺公司内部的合作关系,并能得到高层的支持和授权,以便合理
的协调公司内部资源为项目服务
同用户建立良好的沟通机制,以便有效的获得用户的信息。

分析 9、题目:项目经理才是将客户需求转为开发需求的合适人选 作者:牛永芬
本文转自项目管理者联盟

个人认为,问题的关键在这里:“销售部门其实知道客户的目的,但也未能向项目经理说明
详细背景情况。经了解,他们只是认为Y组件的评估是最关键的,所以只向项目经理提到这
个要求。”也就是说,这是需求传递失真而不是需求变动带来的问题。
销售部门知道客户的功能需求,但是在不清楚功能需求(包括应用场景)和技术需求对应关系
的情况下,向项目经理传达了被曲解了的技术需求。而项目经理,在接到要求后,并没有了
解客户为什么有这样的需求,是为了解决什么问题、还是为了达到什么样的更好的效果。等
到客户不满意的结果反馈回来,才去三方验证想法。
要避免这类问题,最主要是项目经理在发出正式通知前一定要确保自己得到的信息是未经修
改的客户意图。销售方面最擅长的是与客户沟通,而不是分解开发任务。因此,应通过销售
反复了解客户的需求,而不能止于知晓销售传达的开发任务。必要时可以请销售联系客户直
接交流。
不管项目管理部门由几人组成,一定有一个最终负责的项目经理确保开发目标满足客户需
求。

分析 10、题目:需求验证 作者:天羽 (林源教育咨询 wangtianyu999@yahoo.


com.cn)

第 284 页 共 756 页
第 3 章 范围管理

在ISO9000 里面有这样的要求,任何组织都要对客户的需求及需求的变更进行再验证.... 项目管理者

联盟文章,深入探讨。

办法有二个:
1. 项目经理收到内部传递过来的信息后,安排客户面述需求;
2. 项目经理直接要求研发部门作设计,向客户提交设计进行验证,而不是样机。
此案例的问题就在于“我们认为客户的需求就是这样的,所以....”而没有关注“要客户亲自表
述他们的需求”

(三)专家点评

王景山介绍:有 10 多年欧洲海外项目管理工作经验,90 年代初归国后任、职于多家


知名家电及 IT 制造企业,分别从事新产品研发、项目管理企业发展规划及高层管理工作,
主持和参与过大量与欧美、中南亚公司的合作项目,包括新品研发、计算机软硬件研制、厂
房及设备改造、成套生产设备出口项目等,有丰富的项目管理和企业管理实践经验。王老师
撰写出版的书籍包括:《工业企业项目管理》,《研发项目管理》,《项目投资与决策》,
《项目过程与管理技术》等。

王景山点评:企业与客户沟通比较多的有市场部、设计(研发)部、质量保证部,这三
个部门都有可能获得客户的需求信息,有些企业曾试图将客户沟通窗口归结到一个部门,但
是专业技术问题不好解决。这个案例的关键问题是在获得客户信息后如何应对。

(1)理论上的解决方法是制订职责和程序进行评审(IS09000 是这样规定的)。职责和
程序能够解决“大的”或“正式的”客户需求如正式函件和产品订单。
(2)客户非正式或随机产生的需求也要有处理的方法。跨国集团的成熟做法是通过每周的
工作例会和部门报告解决。案例中市场部的反馈应当上会,会议上部门之间会刨根问底,尤
其是需要其他部门做事情的时候。另外上会以后,发生了错误市场部要负责。
(3)针对客户需求的应对,在成熟的大型跨国集团更多的是依靠企业人员的工作习惯形成
的,对于客户的任何需求,在部门之间深入研究应对或不应对,如何应对的方案,这样可以
避免应对的错误。因为任何应对涉及到动用企业的起源,应对的效果涉及到企业的声誉和市
场。

3.2 *这个软件项目的问题在哪

导读:在软件工程中,需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新
系统的目的、范围和定义时所要做的所有的工作。需求分析是软件工程中的一个关键过程。
在这个过程中,系统分析员和软件工程师确定顾客的需要。只有在确定了这些需要后他们才
能够分析和寻求新系统的解决方法。在软件工程的历史中,很长时间里人们一直认为需求分
析是整个软件工程中最简单的一个步骤,但在过去十年中越来越多的人认识到它是整个过程
中最关键的一个过程。

(一)案例正文

第 285 页 共 756 页
第 3 章 范围管理

我所在的公司是个 50 多人的小软件公司。现在我被分到一个五人的项目开发组,这个项目
已经开始两个月了,目前的进展是只有两人(包括我)在写文档,我负责写需求文档,其它
人都有事在忙别的事,项目暂由公司的上一层领导负责。我刚毕业,专业和软件没一点关系,
但没办法,没其它人,我必须得上;我没学过软件工程,也不知道一个项目下来应该具体怎
么操作。我觉得我现在这样工作,有很大问题。

首先,功能性需求都确定不下来,我想先把自己的想法写下来,然后项目组成员一起讨论确
定。事实上其它项目成员也没人关注这项目,就一直没有进行。我不能只等着,于是就往下
写。

现在麻烦的是,那个间接领导有时间,会来检查一下我的文档,他会突然有个想法,要加上
某某功能,又要去掉某某功能,然后我又按他要求修改;下次他检查时,结果又是这样,搞
得面目全非,我也形成不了自己的思想体系,只有揣摩他的意思。两月过去了,还在考虑功
能的问题,真是失败啊。难道这就是 RUP 开发的迭代过程?还是我们管理有问题,还是我
的想法有问题?

我觉得应该定下功能性需求,然后再根据功能写用例,再从开发角度上细化用例,根据用例
写时序图,组件图什么的,请问这个过程应该是什么样的?

(二)专家点评

潘东,上海交通大学计算机软件专业的博士,现任神州数码金融软件公司的副总经理,主管
公司的项目交付。曾任神州数码项目管理部总经理,具有丰富的项目管理经验。

潘东点评:这个案例表面上看是作者无法确项目的需求,但深层的问题是项目没有明确的“客
户”(因为案例的信息不全,这点仅仅是推测)。之所以如此推断,是案例中始终没有明确
提及有“谁”在“提出”需求,或者项目是给“谁”开发的?

如果客户是“谁”是明确的,作者“写需求文档”的过程,就应该是分析和整理“客户”需求的过
程,而不是按自己的“思想体系”创造需求的过程。

到底该由“谁”提需求呢?一般而言,应用软件由最终用户提出业务需求,软件产品由产品经
理进行产品定义。不管怎样,由项目组“自己”为“客户”定义需求都是不太妥当的,这有点像
裁缝按自己的尺寸给客户作衣服。

(三)项目管理者联盟网友分析

分析 1:要管理好你的需求 作者:潘谦

感觉你的项目还没有开始完全进入项目的状态。
文中所说的很多问题都是需求分析的问题,很多你的工作现在明显都在需求分析的过程,还
没有清楚的知道客户的真正需求,这不是 RUP 的问题,而是 RUP 要求首先实现的客户基本
需求,再此基础上迭代实现的增加需求。
第一,还是因该彻底的分析你的客户需要的是什么功能。

第 286 页 共 756 页
第 3 章 范围管理

很多时候客户不断的变化,是正常的,首先你要去发掘客户的真实需求是什么,一般来说可
以通过快速原型和客户不断沟通来做到的。
我觉得如果对于你来说没有时间作原型,就尽量确定最基础的需求是那些。而且必须得到客
户的确认。然后你再开始作用例设计-〉类设计。
第二,管理顾客的需求
客户的需求不断变化,但是不是每次客户的需求都要立刻对应的,RUP 的好处就在于你往
往可以把那些变化的需求放到下一个迭达中去。这样不会影响你这回迭代的开发
项目管理者联盟,项目管理问题。

分析 2:管理问题更多些、特殊情况可把领导的需求当作客户的需求、开发的步骤和图要根
据实际需要来定 作者:globemobile
http://blog.mypm.net

根据你说的情况,这只能叫做几个相关不相关的人以一种不好的方式在做一件事,而不是项
目组在做项目。
这不是 RUP 开发的迭代过程,管理问题更多些。
需求为什么由间接领导来定呢,是否其他项目的需求也是由领导来定的。如果是,则你们公
司一定有办法把自己的需求推销给客户,那么你可以把领导的需求当作客户的需求。但是沟
通要更加充分一些,不要今天一句、明天一点,那样永不成型。
另外两个人在写什么文档呢,是需求、还是可行性分析、还是规划、还是设计呢。
还有,开发的过程中需要的步骤和图要根据实际需要来定,不要根据书本来定。

分析 3:用好方法 作者:天羽

作需求的时候就是这样的,很多的想法一时间不能描述清楚,慢慢的时间过去了,反而清晰
起来,不断地往上面添加,但是这里有一个风险,就是思路不清。最后功能全部写出来了,
逻辑上却变得格外的复杂,或不可实现。
建议你用 MindManager 来梳理一下功能流,看看他的走向是怎么样的。我不知道你们的
文档的要求是怎么样的,但是 MindManager 确实能够帮助你的领导看清楚他有时间就过
来改动的功能们到底是怎样关联在一起的。有了这样的图,也许你也能够理解他的目标,你
的领导也能够理清思绪。

分析 4:需求管理与项目目标 作者:孙先平

在这个项目里,老板实际上变成了客户(我怀疑最终满足了这个客户,项目的结果可能就是
玩完了),要做好这个客户的管理;
另外项目的目标是什么?看起来,好象没有谁对这个项目负责,你只是个做文档的,有一点
需要提醒的是:你需要明白老板认为你是谁,如果老板默认你为项目经理,那你目前状况和
以后的情况都是比较糟糕的!如果没有,你只有建议权,那就当是一个学习的机会吧!

分析 5:需求本身就是一个项目 作者:孙先平 项目管理者联盟文章,深入探讨。

如果有必要,你可以把需求当作一个项目在做,只不过它与另一项目交织在一起而已.没有人
一开始就完全将需求弄得清楚,否则项目管理也没有意味了!
重要的是,你需要将需求中的关键点找出来,这样你不会在做到最后才发现,原来......后悔

第 287 页 共 756 页
第 3 章 范围管理

已经来不及了!
就这个案例本身不是一个简单的需求问题,是个管理问题,尽管大家在此讨论时不会给出一
个一定有效的方子,但是至少可以理一下思路,明确可能存在问题的地方,然后再对症下药!
各位提到的需求明确或管理需求,追根究底,还在于管理流程要理顺!那个间接领导时不时要
"灵感"突发,你有什么办法控制?

分析 6:可以这样想 作者:牛小林

我不太懂软件研发的项目经理,但是,可以明确的是:
你们的公司对这个项目不是很重视,或者人力资源不是很充足,或者还没有下定决心来投入。
但是,这对你并不是坏处,这对你应该来说是机会:
1.如果这时个重点项目,或者人力充足的话,不会你刚刚参加工作就能从事这样的岗位。
2.在这种情况,领导对项目目前的进展不抱太大的期待(请原谅我直言)。所以,即使项
目出现问题,你也会得到谅解的,除非有人想整你,但是你刚到公司这基本上不可能。
3.这可能是你来公司后不可多得的机会去施展你的才能,让公司认识你的潜力和价值。也
是你获得实践经验的大好时机。其实,公司是怎么认识你的,不就是看你做的每一件事情吗?
不就是看你的做事态度吗?
4.不要对领导的意见抱有抵触的情绪,你所了解的东西,和你的视角相对会有很多的局限,
你的领导往往会有更多要关注的东西,他也不一定会有时间给你讲清楚。你要学会站在他的
位置思考,多请示,汇报,多思考。
剩下的事情,我认为相对就要简单的多,就是两个“谦虚谨慎”和“不耻下问”。

分析 7:干系人分析是关键。 作者:郑承满
项目管理者联盟文章,深入探讨。

1.客户是谁?用户是谁?先将这两个问题解决了,找到关键干系人,就知道跟谁沟通,向
谁汇报,对谁负责。
2.关注 WBS,解决的问题可以先粗后细,先开始做 WBS,在需求上面在细化下去(大目标先定),
先将工作包做清楚了
在开始写你要写的东西。
3.将计划与执行进行跟踪,将所有的人工作纳入计划中来,变无序为有序。

分析 8:管理问题还是个人经验问题? 作者:赵昊彤

说句直来直去的话,这个问题根本不是什么奇怪的问题,在中国目前小软件企业中,这种问
题太常见了。
这就是典型的“不规范的公司+无经验的员工”所产生出来的现象!
据楼主说,这是一个 5 人的开发组,那么这么小的一个团队,如果一定认为是管理问题,我
觉得有点上升得太高了。这么少的几个人,如果在工作方式和沟通上都出现了问题,我觉得
主要还要归咎于项目组每个人的工作经验和工作态度,包括你们的那个间接领导。
当然,具体的情况我不清楚,不能在这里给出什么具体的建议,但是作为项目的管理者——
那个间接领导——至少要先在项目组内部统一对项目的认识、项目的迫切程度、项目的时间
要求、项目的重要性等基本信息,否则从何谈起说大家在做一个项目呢?
作为项目的成员之一——楼主——至少要主动和领导以及项目成员沟通,对自己手头的工作

第 288 页 共 756 页
第 3 章 范围管理

有一个基本的认识,在这个基础至少再提出自己的合理化建议,并说服领导或者征得领导的
同意然后再开展工作。
我觉得目前的问题根本不是什么项目管理问题,也不是什么 RUP 过程的问题,这些还都谈不
到呢,根本的问题是你们还没有形成一个项目团队,没有形成一个项目内部管理体系(哪怕
是很简单的,比如项目例会、项目日报、项目过程管理等)。
这就是一个小公司,自身不具备成型的 OSSP,人员经验又不足,也不具备基本的 PDSP,自
然就会发生这种现象。
还是先从提高楼主自身的工作经验来出发吧,别考虑太多了。

分析 9:这种做法很普遍 作者:duanlj 项目管理者联盟,项目管理问题。

从 LZ 透漏的信息的来看,这个项目合同额肯定不高,就说项目不大,你的疑惑大概很多人
都碰到过,一般小公司小项目大致是这么做的。
你所说的间接领导,他可能就是对这个项目的需求最清楚的一个,不直到让你开工之前给你
讲过一些相关的需求和行业知识没有,这样的项目这样的做法,经验就显得很重要,如果是
我,我不会安排刚毕业的来做需求文档。
所以阿,多和你说的间接领导沟通,争取他对你的理解的斧正,抱怨是没有用的,不要完全
按照书上的东西办事,事实证明这样的做法也是可以成功的。

分析 10:如何确定需求 作者:lingjie

对于需求确定来说本来就是一件很难的事情。特别是工程性项目。不知道楼主所说的项目是
属于哪种,看了全文个人认为应该属于研发性的项目,而研发性的项目需求前期确定一开始
就需要有一个需求调研和立项的过程。如果说你的公司连需求都没有调研过,没有立项过,
那这个项目到底要做什么就没有人知道了。对于写需求文档那都是在调研以及立项文档中都
已经确定了的。你要写的是详细的需求规格说明书,并不是你自己凭空可以想出来的。
你应该做好与领导的沟通,详细的确定需求再写说明书。这样就不会出现不知道写什么好了。
就你的描述,这个项目的团队也还没有形成。根本称不上是项目组。
楼主可以借这个项目提高自己这方面的能力,个人认为对你并没有什么坏处。但需要注意的
是不要一味的抱怨,应该好好思考一下你该怎么做。

分析 11:前期工作 作者:李石求 项目管理者联盟文章,深入探讨。

1.您现在所做的工作,仅是以后工作的铺垫
2.也许您的工作经验还不足,领导先安排您熟悉以下公司的情况,顺便要你帮着打打杂
3.当您的公司派其他专业人员参与进来后,您的项目算正式启动了
4.您千万别因当前的工作有所情绪

3.3 *承包单位没有按照实际需求开发软件

(一)案例正文

第 289 页 共 756 页
第 3 章 范围管理

国内某著名财务软件开发商为我公司开发资金预算系统,在开发过程中,我们说服厂家进行
现场开发。本月底该系统要准备双轨运行,该项目的项目经理和开发团队关系不够紧密,管
不住人;在与我们沟通时,他总觉得他们的产品比较成熟,走的路线都是对的,造成了开了
很多次协调会,但是开了等于没开,项目经理一不向上级反映,二不与我们良好沟通,造成
关系僵硬。

我公司也去函该厂家,就此问题提出解决办法。我想请大家帮我分析一下,对于这样的情况,
我公司今后对于开发厂家的项目经理要提出什么样的要求。

(二)点评专家

曹济 北京随济科技公司首席顾问/国际软件标杆组织技术顾问/欧洲软件度量论坛(2006)
组委会成员/信息产业部系统集成项目经理委员会成员/IEEE/PMI/IFPUG/ISBSG 会员

为上百家的国内外 IT 组织提供过 IT 项目管理、软件项目管理、基础项目管理、项目量化管


理、软件估算和软件度量、软件质量管理、软件测试管理等方面的公开培训课程与企业内训
服务。为十多家软件公司提供 CMM/CMMI 培训咨询服务、软件标杆管理体系培训咨询服
务、项目管理体系培训咨询服务

曹济点评:

您好,王芬,看来甲方也烦恼啊。

避免这样的情况可以采用两种途径,第一种是请监理公司,由监理公司对实施中的项目进行
管理。第二种就是从甲方自己的角度制定项目管理体系和相应的办法。

我们在项目管理中也会有“斗智斗勇”的提法。通常来讲甲方在项目中还是非常强势的,因为
国内现在都是买方市场嘛!所以甲方的位置通常不会这么被动。甲方为了争取项目的主动权
和控制权,也需要相应的制度与方法辅以支持,否则就只能是采用“不验收”这个杀手锏了,
而这种方法往往两败俱伤,对于甲方反倒伤害更深。

例如采用制度化的方法就要求在甲乙双方建立统一的项目管理委员会组织,项目经理定期要
向委员会报告,项目中的问题自然不会被掩盖了。如果没有这样的机制,则甲方很可能只能
通过项目经理接触乙方的高层。遇到一个责任心不强的项目经理,那就麻烦喽!

所以可以对人员提出具体要求,例如责任心、主动性等。但更有效的方式是甲方除了合同约
束之外,可以建立相应的项目管理机制对乙方以及项目经理进行约束(要强调的是约束往往
是双向的),以保证项目最终的成功。

(三)项目管理者联盟网友点评

分析 1:软件为管理服务 作者:张翼

甲方希望按照企业的实际要求开发软件,乙方希望在已有的产品基础上经过配置、剪裁

第 290 页 共 756 页
第 3 章 范围管理

而形成系统,这种现象在企业信息化的项目中普遍存在。推荐江苏威特集团王甲佳先生在第
二届中国企业信息化用户论坛上的演讲《再说企业信息化的主动权》,附后。
已有的产品技术架构可能比较合理,具有开发成本低,稳定性高、实施周期短等优点,
在实际业务与产品功能相近的情况下,建议采用这种开发思路。
但企业在发展过程中,会根据自身的特点,形成一套合适的管理思想和方法,他们对信
息化的要求往往不是现成的软件所能满足的,这种现象已经逐渐凸现出来,近两年来也开始
得到开发商和企业的重视。
具有企业特色的管理思想和方法是不容忽视的,它们可能是企业核心竞争力的组成部
分,在企业信息化的建设中,我的意见是,与其低价购买不适用的软件,不如增加投入,定
制符合需求的专用软件系统,这样才有可能实现促进企业管理水平提升的目标。

本案例的对策:

1、根据合同的约束,要求乙方项目经理按照公司的实际要求开发软件系统。乙方项目
经理与开发团队关系不够紧密,管不住人,是他的管理能力问题,可以向开发商反映,要求
加强管理。有可能的话,公司应该派一名控制力强的人员作为甲方项目经理,主导项目的开
发。
2、如果因为要满足需求而延长项目开发周期,应说服公司的管理层,需求满足程度与
开发周期,对于公司来讲,当然要取前者。
3、如果乙方项目经理不能按照要求改变开发思路,则要求乙方更换项目经理。
4、如果乙方坚持现有的思路,我认为宁可赔款中止合同,也没有必要去开发一个不合
用的软件,这方面的教训很多。
总之,软件是为管理服务的,如果无法满足管理的需要,即使软件开发成功了,项目也
是失败的。

附:《再说企业信息化的主动权》江苏威特集团有限公司 CIO 王甲佳 项目管理者联盟文章,深入探讨。

一、什么是主动权?
● 主动权首先必须是自己能控制的; 项目管理者联盟文章,深入探讨。

我们的论坛是用户论坛(注:第二届中国企业信息化用户论坛)
展现了一种来自用户的声音
很可能就此从卖方走向买方
● 在合理分配资源的情况下实现战略目的;
分包、外包将控制在一个相对专业的范围之内,也就会实现对需求分析、系统规划、技
术实现等方面的专业分工。逐步淡化软件公司提供的“一揽子解决方案” 项目管理者联盟,项目管理问题。

● 主动权来自多重挤压下的旺盛需求
商业包装使人们对管理软件的认识处于朦胧与不对称状态
用户的旺盛需求得不到满足形成了对主动权的渴求

二、主动权的尴尬?
还是要拿自己公司的事情做例子
刚刚过去的 3 月份,我们有一个强烈的需求——泛 CRM 项目。其中的境遇让人感慨万
千。
● 需求方的信息化战略与战术“十二字”方针

第 291 页 共 756 页
第 3 章 范围管理

▲ “大市场”就是以满足市场需求为最高追求,我们就是要通过信息化手段把它细化,
透析出具体需求,形成订单,以客户为载体来满足市场的需求甚至引导需求;

▲ “小生产”则是把自己的生产功能精致化,通过很好的秩序控制在产能最大化和
客户需求满足最大化之间形成平衡,这个方面是信息化有很大作为的领域,也是传统 ERP
最具有价值的 MRP 部分!
▲ “广协作”主要是从供应链的角度来认识的,从原料供应商、辅料供应商、工装
工艺合作方等等伙伴那里取得资源来满足客户需求,信息化在这个层次的功用主要是为了让
过程信息得到有秩序的交换,为多方所共享,以提升我们供应链整体的运作效率;
▲ “深情报”是上述三个层面有效运行的成果,也是指导三个层面高效运行的灵魂。
是一个在企业文化上协同、业务逻辑上严谨、资源结构合理、合作伙伴信任基础上的神经枢
纽。
我们期望形成一个覆盖企业经营性活动与非经营性活动的资源管理与控制体系,让信息系统
与企业实际完全贴合而且与时俱进!
● 我们定义 CRM 是满足客户需求全过程的控制与管理。
在这样的情况下就形成市场、销售、客户、订单、生产过程、商务过程等为管控对象的管理
信息化。 http://bbs.mypm.net

● 供给方的管理软件提供方案
3 月中旬我们接洽数十家软件公司,同许多专业人士进行交流,就我们所需要的软件结
构来说,满足度一般要 60%以下,现实需求满足度 50%以下,但是能提供出我们公司的要求
的软件还是比较困难的,尤其要求一种平台化的软件结构是很不容易。选择成熟软件公司,
他们软件刚性较强平台性较差,平台软件公司则是相反,他们缺乏成熟的行业经验。
根据实际情况最后还是要在软件公司里面选择具有一定平台化特性的管理软件,一方面
满足现实需求,另一方面又可以对后续的维护提供及时便后的支持,同时便于进行边规划边
实施的操作,尤其有利于将来 MRP 范畴,SCM 范畴以及 BI 范畴的信息化项目实施。 本文转自项目管理者联盟

大部分管理软件公司希望在他们已经进入市场的多种软件中选择。然后提供较高成本的
二次开发,以满足对当前的泛 CRM 需求。也有公司愿意提供完全定制服务。也有个别“领袖
公司”对我们的需求提出了质疑,认为非常不专业,基本概念都搞不清楚,还做什么需求规
划。 本文转自项目管理者联盟

● 双方差异所在:
(1)软件公司希望在他们的 ERP、CRM、OA、SCM 等软件群组里面选择功能模块;希望
在他们的软件逻辑里面进行需求定义。
(2)企业希望从实际需求出发,在一定的基础数据前提下实现客户导向战略,同时进
行战术的协同。至于软件到底是什么名称,什么范畴并不特别关心。

在软件公司面前,企业用户的信息化主动权受到了极大的挑战!

三、主动权的回归? 本文转自项目管理者联盟

● 回归要义之一:
企业成长特性和优秀的同时又很幼稚的成功特质不容漠视。
信息化是优化企业生态的崭新载体和因子,不是生态链条的羁绊。 项目管理者联盟,项目管理问题。

● 回归要义之二:
客户导向流程与功能导向流程的本质区别就是现代企业和传统企业的本质区别。对软件

第 292 页 共 756 页
第 3 章 范围管理

公司也一样。 项目管理者联盟,项目管理问题。

● 回归要义之三:
信息技术将回归到它固有的势力范围,从前台走向后台。对企业业务的把握是一切竞争
力体系的核心。
信息化革命才有刚刚淅沥的春雨。

信息化的主动权
是企业的生命线

分析 2:补充一些 作者:一孑本文转自项目管理者联盟

项目过程应该有监控和验收的环节,建议应该加强这两个环节(应该以甲方为主导,或第三
方机构),项目经理的意图肯定代表着乙方的一些想法,建议应该明确你们的目标,不要给
对方太多幻想。
项目经理代表的是乙方,但这个项目,乙方不应该由这么一个项目经理负责,应该尝试的与
乙方面对面的沟通,解决这个问题。项目经理的好坏不是甲方来评价,甲方只需要评价当前
的成果就够了。如果是店大欺客,那也就另当别论了。
合同很重要,应该仔细研究一下。

分析 3:瓶颈问题 作者:于先生

软件公司为减少成本及周期而在现有产品基础上修整来完成项目,往往通过关系作用使项目
勉强混过,这种投机行为是当今软件项目普遍问题,也从而导致软件应用缺陷。 本文转自项目管理者联盟

通常解决这种问题应该有几个原则:一、以客户为中心 二、以需求分析为基础 三、以解决


方案为依据 四、以应用为验证。
这个案例问题出在一和三上,开发必须以需求为中心,项目经理过于盲目自信而忽视真正需
求导致项目遇到瓶颈,要解决问题必须回归到解决方案,并且要根据试运行时用户需要修改,
不合适的管理者立即撤掉。

分析 4:以产品满足项目,以需求适应解决方案的项目 作者:daijiangbao

这是典型的以产品满足项目、以需求满足解决方案,本末颠倒的做法,需要让开发商改正过
来,开发商能完成产品,但是不可能就说项目管理就好,技术不能代替管理。
客户方的需求,例如招标文件、合同都是对开发商要在一定条件下满足的,双方对这些关键
的具有法律意义的文本没有得到充分的重视,到最后只能是双输的结果。
不会开会,不会沟通。
另外,对于甲乙双方的这种开发,主导的是开发方的项目经理,开发方的项目经理有义务满
足用户的需求,但是一定不能把主导方的地位颠倒了,否则必定出大乱。
对 PMBOK 来说,只有采购一章是写给甲方的(客户,对本项目而言),其他各章节都是针对
乙方(开发方)来写的,且切不可把关系颠倒了

分析 5:确定自己明白的就要坚持,否则不要干涉 作者:陈晨

第 293 页 共 756 页
第 3 章 范围管理

很多情况是用户方出人配合开发方进行开发,用户方是业务专家而不是开发专家,
软件部分交给项目经理去做,用户方需要做的就是,协助明确需求,准确地描述工作流程和
期望结果。而不要去考虑软件实现方法,最好也不要去指责对方人员。
需求确认时候逐句逐字读明白了认为正确了没有歧义了在签字。 项目管理者联盟文章,深入探讨。

做了该做的就等着收获吧。
项目完不成,或者有其他问题,有合同呢。

分析 6:明确交付成果,严格验收 作者:黄飞生 (保留 SZFISION@YAHOO.COM.CN)


http://blog.mypm.net

1 一定要拿到强势的主动权,让厂方明确是你方说了算。
2 双方细化标准,明确交付成果,严格验。.
3 管理问题要求厂方高层拿出具体措施限期解决.甚至需面对面沟通。

分析 7:非正规建议,仅供参考 作者:中国武则天

1.按照合同规范要求开发商;
2.挖取该公司项目开发组的主要人力,组件自有的开发和维护团队(等项目逐步完善后再做
打算);

分析 8:过程监理,做好验收 作者:ymy

1、用户方应该派出业务方面的专家,协助开发方进行需求整理,对整理出的需求规格说明
书进行评审、确认,以次作为验收的标准;
2、具体的开发工作交给开发方处理,至于开发方的团队管理,也应是其内部问题,用户不
应做干涉。如果,因开发方的管理,造成进度延迟、产品质量问题,那就需要与开发方高层
领导沟通解决,不是找项目经理;
3、用户在产品开发过程中,可以聘请第三方监理,帮助管理。如无第三方监理,至少应该
有自己的项目跟进人员,随时了解项目进展情况,召集协调会议,不一定只针对项目组进行
协调,必要时可以进行高层领导之间的沟通。
4、系统上线前,用户应派出业务专家和一线操作人员进行需求确认测试,检验需求实现情
况,做好验收。

分析 9:提什么要求并不重要 作者:王海飞

向项目经理提什么要求并不重要(兵无常势,水无常形,不同的项目执行起来会有不同的要
求),重要的是让对方派什么样的项目经理。另外,贵公司自己也有问题,在项目实施前为
什么不明确项目范围和验收标准?这是你们两家都存在的一个问题。

第 294 页 共 756 页
第 3 章 范围管理

3.4 *软件开发项目范围、成本管理问题分析

(一)案例:软件开发项目范围、成本管理问题分析

姓 名: zhangmin
单 位: 北京东方飞扬软件技术有限责任公司
邮 件: zhangmin@flyingsoft.cn

案例正文:

某公司签订了某省档案局一个项目,主要是为该用户开发一套档案管理系统和门户网站,该
公司为了拿到该项目,在价格上作了大量的让步,而公司没有对项目的范围进行确定,也没
有对项目的成本进行估算,就与用户签订了合同。在项目启动后,由于对项目的范围没有确
定,导致项目的需求总是在变化,项目周期一再延期,用户也不满意,公司项目小组也很累,
成本也很难控制!

这样的项目如何进行项目管理呢?

是不是所有的项目都可以管理好呢? 项目管理者联盟,项目管理问题。

(二)项目管理者联盟专家点评 http://blog.mypm.net

专家介绍:孙晓玫 计算机软件高级工程师、PMP、计算机系统集成高级项目经理。1982 年
1 月毕业于北京科技大学计算机应用专业,曾赴日本研修系统工程。先后在国内多家大型计
算机公司(上市企业)工作。历任开发部经理、开发中心总经理、项目管理部部长、专业公
司总经理、股份有限公司副总裁等职。具有 20 多年计算机应用系统的设计开发与组织实施
经验,参与并组织过数十项应用系统开发及工程实施。涉及领域包括:银行、商业、社会保
险、智能卡应用、电子商务、电子政务等。对于项目管理有非常丰富的实践经验。 项目管理者联盟,项目管理问题。

孙晓玫点评:

此类案例在 IT 行业来说是非常普遍的现象,尤其是一些中小型企业面临着巨大的市场竞争
压力,为了能够争取到一些项目定单,不得不压价签约。如果企业内部在项目管理方面缺乏
相应有效的管理控制手段的话,必然为后面的项目实施蕴藏了诸多项目风险。我想对此案例
从三个层面进行分析:

1. 如何避免再次出现此类项目:

出现案例所描述的情况关键是企业内部在项目签订合同之前少了必要的可行性分析研究及
评审控制环节,市场销售人员可能迫于业绩的压力为拿单而拿单,没有与售前工程师或项目
实施团队沟通,从项目范围、成本、进度、企业的有效资源等方面进行认真评估与风险分析。
当然企业为了战略发展的需要,不惜血本要签这样的合同则另当别论。为了避免再次出现此

第 295 页 共 756 页
第 3 章 范围管理

类项目,建议企业在下列方面进行适当调整与加强: http://bbs.mypm.net

销售人员在提出投标或立项意向的时候,应认真分析招标说明书中有关技术需求的描述或对
用户需求进行必要的调研,评估项目的范围,必要时可申请售前工程师或其他技术人员给予
配合建立健全合同评审流程,要求有经验的技术人员参与合同评审,以保证从技术和实施成
本方面进行严格评估

在对部门及员工进行业绩考核时不要仅考虑营业额,要综合考虑相关项目实施成本的因素,
以强化大家的成本意识

2. 已经签订此类合同后如何应对项目风险:
http://bbs.mypm.net

如果项目经理已经不幸被授权承接这类范围不清又缺乏成本评估的任务时,建议:

① 不要马上低头忙于组织实施,而是和负责客户关系的销售人员(客户经理)密切配合,
立即组织与客户的沟通,进行需求调研和范围分析工作,评估项目成本和风险。提交相关分
析报告给项目关键的干系人,特别是要提交所在企业的主管领导进行决策,因为很多风险不
是项目经理本人的能力及权力能够应对的;

② 对于客户方尚不能清楚描述项目需求的时候(在电子政务类项目中这样的现象很普遍),
项目经理应在项目设计与实施过程中组织力量强化与客户的沟通,逐步启发与引导客户对项
目范围的定位,尽量选用原型法、阶段交付或渐进交付(迭代法)等项目生命周期模型来规
避项目的实施风险。并与客户经理配合尽早让客户在明确的项目需求说明书上签字;

③ 说服客户,共同约定范围变更控制审核流程。对于客户每次提出需求的调整与变更,特
别是比较大的变更都不要仓促答应,而是先将其文字化请客户确认(如果客户能够提交书面
申请最好),针对此变更进行分析,包括:该变更所带来的技术和功能影响、成本和进度影
响、对系统资源需求的影响等。将分析报告提交甲乙双方与项目相关的重要决策人进行评审
确认,只有得到批准后再组织实施。不少客户看到这些有理有据的分析后就会主动放弃或缩
小变更。对每次变更及调整都要做好需求跟踪记录,这也是事后与客户共同分析项目进度拖
延与成本增加的重要依据,还可据此而争取客户适当追加项目的投资。 本文转自项目管理者联盟

3. 当前如何进行补救:
项目管理者联盟,项目管理问题。

至于该项目已经处于目前被动局面怎么办?我建议如可能的话先将项目暂停。并且:
项目管理者联盟文章,深入探讨。

① 首先与客户对话,进一步明确项目的实现目标及详细需求;

② 项目经理组织梳理已经实现的功能与性能,判断与客户目标的偏差,评估为此还需要多
少时间与成本,认真分析不同解决方案的利弊,研究下一步的执行策略,并得到所在企业主
管领导的进一步授权(审核批准);
本文转自项目管理者联盟

第 296 页 共 756 页
第 3 章 范围管理

③ 尽快组织甲乙双方坐下来进行项目的审查会议,认真、客观地分析项目启动以来的情况,
争取双方能够在相互理解和达成共识情况下继续后续工作。 项目管理者联盟,项目管理问题。

对于该项目的前景分析可能有以下几类:

① 将尚未实现的功能性能划分轻重缓急,客户同意在较少的投入下尽快将该项目结项,这
是双方损失相对较少的结局;

② 客户同意为了需求的变动和扩充而为该项目追加部分投入,或以下一个项目的承诺作为
补偿,这可能是企业最希望得到的结果;
③ 由于已经签订了合同,所以不得不无偿地、硬着头皮干下去来满足客户的全部要求,这
个结局对企业来说是最痛苦的。当然后面要在严格的项目管理下进行,以使损失得到控制。
但愿能够好好总结该项目的经验教训,包括开发成果,在后续其他项目中得到回报。 http://blog.mypm.net

是不是所有的项目都可以管理好呢?

首先认清“管理好”的含义是什么?如果意味着项目成功的话,我个人认为不是。因为项目的
成功与否涉及多方面的因素,而项目管理不是万能的。作为项目经理,充分利用科学的项目
管理手段可以提高项目成功的概率,降低项目的风险,但是如果项目自身存在较大的先天不
足的问题,如此案例,则项目仅在启动以后的开发实施期间进行管理很难保证解决所有的问
题。因此要重视项目启动时的筛选与评审。当然严格说这个环节也属于项目管理的范畴。

(三)项目管理者联盟网友评论 http://blog.mypm.net

分析 1:题 目:三步走,帮你解决 作 者:罗晶 (国际化公司 luojingjing88@163.com)

第一,分析 Business.
不知道公司为什么要做这个项目.
项目的目地都不知道.所以第一要了解我们做项目的目的.可能是为了挣钱,也可能是为了其
它,找出原因.这对于以后人员管理、沟通管理都是很主要。
第二,马上确定范围
必须确定你要交付的是什么产品.才能有努力的方向。
第三,建立变更控制体制
管理就是控制.没有什么好说的.

分析 2:题 目:项目成败的评判标准 作 者:lintao (CATTSoft forestlin@pku.org.cn)

项目成败除了要有严格的管理制度、出色的项目经理外,公司高层对项目的关注程度是至关
重要的。说到本案例,既然公司能够不惜代价签下这单,一定有公司高层的想法,也许有其
它的战略意图,不足为外人道也(比如进入公司的空白领域、抢夺市场分额、打压竞争对手
等等;如果是糊涂蛋老板,我就没话说了);说明公司高管对这个项目还是十分重视的,虽
然在项目运作的过程中遇到了种种困难,在这个前提下要及时跟高管交换意见,在取得高层

第 297 页 共 756 页
第 3 章 范围管理

对这个项目的意见后再动作才是明智之举。 本文转自项目管理者联盟

分析 3:题 目:行动流程 作 者:陈志强 (联强国际 yeslb@hotmail.com)

一 现有工作全部暂停,与客户方共同协商,确定双方各自选定项目管理人员,客户方必须有一
个可以协调各方面关系的人作为联络窗口,最好这个人比较 POWER,说话管用 项目管理者联盟,项目管理问题。

二 以最快的时间来确定客户需求方向,并且这个方向一旦确立之后就不再变更,如果将来客
户坚持还要在此基础上做任何修改,所引起的一切后果均由客户方来承担(如工期再次延误
等), http://blog.mypm.net

三 按确定好的需求方向做出成本预算
四 网站应该比较快可以搭起来,以最快的速度,哪怕加班加点也要先把门户网站给做好,至少
先保证客户方能看到一部分成果
五 开发工作按照确定好的需求方向来有序进行,中途除非有特殊情况,否则不再接受无止境
的修改意见,并且所有的修改请求都必须归口到客户方项目联络人,由他汇总后统一提出,不
接受其他任何人的独立修改请求.
分析 4:题 目:一点看法 作 者:张慧勇 (青牛项目管理部 zhuiyong@sohu.com)

从项目营销来看,充分对项目进行可行性研究,从成本、利润上考虑。 项目管理者联盟,项目管理问题。

从项目执行来看,对项目范围控制不当,未能在项目需求阶段和客户达成需求共识,可能也
未采用合适的原型设计。
从团队管理上来看,由于项目范围未控制住,工期一拖再拖,项目组成员变的疲惫这是难免
的。
解决办法,目前阶段,应和客户进行沟通,再次确定项目范围,确定项目边界,对客户提出
来的新需求与客户确认,得到客户的认可(对客户的需求也要控制),做出明确计划,鼓励
项目组成员,控制需求范围,项目进度。

分析 5:题 目:看什么人,什么公司来做项目 作 者:周波 (深圳市 X 数码技术有限公


司 xymyhome@126.com)

我曾经有同样的经历。合同签订前的界面界定很重要,但有的公司为了拿到单,往往没有重
视甚至故意去模糊项目界面。并且项目经理是在合同签订后任命的,更给项目管理增加了难
度。这种项目,项目经理的水平当然是关键,但项目承建单位对项目的态度、高层对项目的
支持左右了项目经理能力的发挥。本例这种情况往往发生在公司的高层对项目不重视。如果
你是该公司的一名项目经理,那么写简历应该是一种可以考虑的选择。
http://bbs.mypm.net

分析 6:题 目:同意各位的意见 作 者:马骁 (施耐德电气 xiao-kevin.ma@hotmail.com)

对于范围定义不够清楚的项目一开始就应采用 CPPC、CPIF、CPFF 合同来规避卖方风险。

如果已经签订的固定价格合同,就只能同客户加强沟通,尽快定义项目范围,重新估算成本
和时间。如果此时发现预算超额,没有利润可言,也要取得客户谅解,让客户从“双赢”的角
度理解,没有利润的项目质量很难保证,从而能够让客户同意根据新的结果追加预算,或签

第 298 页 共 756 页
第 3 章 范围管理

订新合同。

分析 7:题 目:项目启动规划是失败的! 作 者:蓝剑 (** cosmo0912@sina.com)

在与用户签订合同的基础上,
1、积极主动与客户加强沟通,明确业主的需求;
2、确定项目的范围,制订详细的范围说明书;
3、由于项目已经延期,应加强对项目进度的监控,确定关键和非关键工作路径,改为并行
工作,以压缩进度,进行资源合理配置,同时有效控制项目风险;
4、范围明确,成本也就很好控制; 项目管理者联盟,项目管理问题。

5、如果业主的需求超出合同的范围,应追加项目合同费用;
6、项目进行到这样,与业主的沟通非常重要。

分析 8:题 目:沟通与交流,重新取得利益平衡 作 者:乔国杰 (中兴软件技


术 chiao2006@163.com)

首先得承认这个项目是失败的,然后在些基础上采取补救措施,以重新达到双方利益的平
衡。
双方都应该明白,在当前的情况下,单方面获利是不太可能了,只有当达到一个平衡点的时
候,才能再做出一个最优的方案,相对来说。这也是项目动作最基础的出发点。
外部是这样,公司内部也一样,市场与研发也要取得平衡。
本文转自项目管理者联盟

分析 9:题 目:抓紧 作 者:李 (路安特 dr-leefirst@hotmail.com)

1.首先进行风险分析。
2.确定明确的范围。
3.核算出实际的成本和时间。
4.与利害关系者协商。
项目就是独特的,项目管理必须适应这种独特性,把项目管理好!
项目管理者联盟文章,深入探讨。

分析 10:题 目:首先要做的事 作 者:luoyun (xx luoyun@bonc.com.cn)

对该项目,首先要做的是和客户一起,把已经完成的部分进行总结,自己公司要把已经付出
的成本进行计算。在此基础上和用户确定未来需求,制定新的计划,要充分考虑已付出的成
本,以及前期遇到的问题,防止范围无限蔓延。

分析 11:题 目:合同类型 作 者:HSP (secret hsp2010@126.com)

出现这种情况在中国应该是很正常的,目前要确定所签合同的类型,如果是 CPPC、CPIF、
CPFF 合同那就不用怕;如果是 FPPIF、FFP 合同,那就要亡羊补牢了,尽快草拟项目的范围
清单和客户协商确认,并提示客户会尽量满足更改的要求,但可能会影响交期!

第 299 页 共 756 页
第 3 章 范围管理

分析 12:题 目:太简单了 作 者:任鹰 (暂无 renren923@sohu.com) 项目管理者联盟文章,深入探讨。

最简单的办法,亡羊补牢
既然已经造成这种局面,双方就诚心、诚信、平等地面对面地谈
(1)确定详细的范围,确定后续变更范围的处理方法; 本文转自项目管理者联盟

(2)确定所有的工期,按照工期投入资源;
(3)经常沟通,最大限度的了解业主的意图,最大限度的让项目组的人了解项目的要求。
和人打交道是最难地。

分析 13:题 目:是,所有的项目都是可以管理好的 作 者:daijiangbao (深圳市大视野企


业管理顾问有限公司 daijiangbao@hotmail.com)
所有的项目都是可以管理好的,关键是要按照项目成功的法则去管理,不要把不正确的、不
合适的管理理所当然的认为是正确的管理,对于软件开发项目,不能全部照搬软件工程的模
式来管理,这是本质性的问题。软件工程的理念和项目管理的本质是不同的,要认真区别、
有机结合对待。

3.5 *如何走出企业信息系统建设项目范围管理的困境?

案例提供者:项目管理者联盟 项目管理者联盟文章,深入探讨。

★ 案例正文:

小李是国内某知名IT企业的项目经理,负责西南某省的一个企业管理信息系统建设项目
的管理。在该项目合同中,简单地列出了几条项目承建方应完成的工作,据此小李自己制订
了项目的范围说明书。

甲方的有关工作由其信息中心组织和领导,信息中心主任兼任该项目的甲方经理。可是
在项目实施过程中,有时是甲方的财务部直接向小李提出变更要求,有时是甲方的销售部直
接向小李提出变更要求,而且有时这些要求是相互矛盾的。面对这些变更要求,小李试图用
范围说明书来说服甲方,甲方却动辄引用合同的相应条款作为依据,而这些条款要么太粗、
不够明确,要么小李跟他们有不同的理解。因此小李对这些变更要求不能简单地接受或拒绝
而左右为难,他感到很沮丧。如果不改变这种状况,项目完成看来要遥遥无期。 项目管理者联盟文章,深入探讨。

问题:
1、该问题产生的原因是什么?如何解决?
2、如果你是小李,你怎样在合同谈判、计划和执行阶段分别进行范围管理?

点评本案例>>

★ 项目管理者联盟专家点评:

第 300 页 共 756 页
第 3 章 范围管理

专家介绍:郭远刚 美国项目管理协会(PMI)认证项目管理师(PMP) 武汉科技大学管理学


院项目管理硕士(MPM)项目管理培训师、公用事业信息化顾问。曾负责大型自来水公司、
电力公司、燃气公司综合管理信息系统的研究与建设,主持多个小区智能化项目,参与“城
镇供水营业收费管理系统通用标准”编制,博燃网燃气信息化专家顾问,中国土木工程协会
城市燃气分会信息化委员会委员,2007 年度博燃风云十大焦点人物,先后在核心期刊发表
文章 30 余篇。对于 PMP 考试和 PM 教学有较为深入的研究,负责项目管理硕士专业课教学
多年,经验丰富。特长:在自来水、燃气、电力、IT 领域采用理论与实践相结合的解决办
法为公司、组织的项目管理以及信息化的战略、规划、实施与优化提供解决方案。

专家点评:

1、该问题产生的原因可能是:项目管理环境和流程不科学,没有很好的利用项目范围
说明书的作用,工作说明书甲方需求表达不明确,范围定义根本就不清楚,缺乏科学的项目
管理手段。

我们看一下信息系统项目的特点之一:整个系统实施的周期长、对业务的依赖性强,特
别是一些跨业务的项目,要完全把企业的全业务流程稳定下来,并通过系统实现,是需要较
长的时间来巩固的。因此在这么一个客观条件下,常常出现一些需求不稳定、需求变更,项
目范围失控的现象,如果在此问题上没有一个“度”的控制,那么项目的范围将失去可控性,
随之而来的是项目的风险和成本无法控制,更严重的是导致项目的滞后和失败。

所以,出现案例中的问题,就要加强甲乙双方的项目管理体系建设,进行科学的项目管
理。同时重视工作说明书和项目范围说明书的作用,因为范围管理是项目管理的基础,也是
项目管理工作的重点和难点。含糊的需求和频繁变更的范围会让项目的甲乙双方吃尽苦头,
特别是信息系统项目,客户的需求调研一定要耗时长一些,分阶段要求用户签字认可,因为
一旦出现大的变更,风险就太大了。在项目管理过程中,项目范围说明书是项目范围的重要
保证,在项目实施过程中,项目组成员以及相关的重要干系人一定要不时地拿出项目范围说
明书来看一看,以保证项目在正确的、经核实的范围内进行。同时,范围说明书一定要经过
客户的签字认可,范围说明书的内容一定要清晰明了,特别是对项目目标的定义,项目的约
束和假设等等。如果有项目管理办公室的话,最好是把项目范围说明书的纲要贴在大家都能
看到的地方,或者每个项目成员分发一份经过签字认可的项目范围说明手册。

甲方项目经理工作和沟通能力欠缺,没有规范好项目过程中一些工作和变更流程,与项

第 301 页 共 756 页
第 3 章 范围管理

目经理本身的能力有很大的关系,如果该项目经理一直从事着技术工作的话,这个项目更加
危险,建议去参与项目管理的培训与学习,熟悉项目管理的方式方法。乙方项目经理(也就
是小李)要主动沟通,在不断提高自己项目管理水平的同时,邀请甲方项目管理人员面对面
地进行一系列的正式沟通,明确双方的范围和责任,确保项目正常完成,收到应有的效果。

2、假如小李是在一个很好的项目管理环境下来执行这个项目。在合同谈判阶段,根据
PMI 的思想,双方只是明确各方应该承担的责任和义务,明确工作说明书的要求,对项目的
范围只是一个粗略的概要说明,这些一般是由合同管理人员和部门去协调,小李也最好参与
进去。作为项目经理,小李应该把重点放在计划阶段对范围的定义上,根据合同的要求,组
织项目团队成员认真做好需求调研工作,全力整理出一份详细的项目范围说明书,并且要得
到用户的确认,签字盖章。在执行阶段,小李只要依照已经定义好的范围说明书来执行就可
以了,根据变更流程来管理变更,执行范围变更即可,当然在国内实施项目的过程中不会这
么的顺利,根据项目独特性的特点,小李应该适当考虑一下他所处项目的项目管理环境。在
计划阶段小李应尽量做到:
①弄清楚调研的目的。对用户:让用户认为调研者已经非常了解或者有足够能力了
解企业现有业务流程;对自己:调研获得信息足够让团队成员能够很好的开展工作。

②整理出的需求一定要得到用户确认,这样在变更的时候会占有一定的主动。

③把握好项目范围的“度”,将如何定义才“合适”呢?这个问题在项目实施双方衡量的标
准是不一致的,或许我们暂且用“多”和“少”这两个相反的字眼来反映业主方和实施方对项目
范围的衡量标准。当然了,在实际的项目管理当中,我们并不能那么简单就把这个因素用这
两个简单而相反的字眼来概括,因为项目范围本身涉及到不同利益双方之间的关系,而且还
涉及到业主本身复杂的业务逻辑,在项目开始时描述项目的需求范围时对项目范围边界的定
义上就存在着一定的模糊性和不确定性。很多时候都是一些定性的要求、而不是定量的,例
如“界面友好,可操作性强,提高用户满意度”等。类似这些模糊的需求就是导致后续项目扯
皮的根源,这些都将成为隐藏的风险,值得小李高度重视。项目范围的明确定义,有经验的
项目经理及系统分析员将起到至关重要的作用。

④保证项目一开始就有很明确地项目范围界定,有一套完善的变更控制管理流程,不能
任由用户怎么说,就怎么做,也就是说一开始游戏规则一定要定好,才能保证整个项目不会
成了一个烂摊子。

★ 项目管理者联盟网友评论:

分析 1:流程有问题 (zhengshenghua) 本文转自项目管理者联盟

1、合同中的项目范围(我们项目一般叫需求规格说明书)没定义完整、清晰及可管理,
可能是一句话包含了一大块功能,如果这样显然会在实施过程中处于被动。

2、工作流程有问题,客户必须有项目经理,所有变更需求均得由甲方的项目经理提交
给我们,而不是谁都直接提过来,导致根本无法执行需求变更流程。 项目管理者联盟文章,深入探讨。

第 302 页 共 756 页
第 3 章 范围管理

分析2:需要清晰的范围界定 (张轶伟) http://bbs.mypm.net

1.范围的确定不够清晰明确。建议在借鉴成熟的范围定义条件下同项目关系人增加沟通
以得到完整,清晰的范围定义。同时分析了解项目关系人,任何可以影响到项目的人、该项
目会影响的人都应事先做出分析,比如考虑到系统与销售部相关,可以在项目开始前通过客
户的项目经理了解销售部意见。 项目管理者联盟文章,深入探讨。

本文转自项目管理者联盟

2.对于工作流程,对于客户中其他部门提出的意见要统一与客户的项目经理讨论解决,
或者请其将多方召集起来一起解决,这样大家自然会对有冲突的要求做出判断。毕竟是客户
要求,只是未通过项目经理提出,那么我们就将其纠正回去就是。

分析3:职权问题 (赖仕权)

项目到底对谁负责最初都没有明确,导致后面执行中被多人指挥,造成项目执行没有统
一,引起困惑。现在最重要的是找到最先提出与之合作的经理,交换双方意见,对他们所提
的意见和改进变更进行整理,找出其共同点和差异处。

分析4:重视沟通(徐康 )

首先,在项目的开始,项目的发起人和项目的干系人没有搞清楚,使之在项目开始之前,
没有充分考虑到涉及到的重要人员。导致现在的情况。
另外,我个人认为在项目的进程中,要在规定的时间,比如一周或半个月同客户一
起研究讨论项目的进度,双方的领导一定要参加,并就项目进行中的问题一一说明,并做好
记录。

分析5:项目范围界定不清晰(许四胜)
项目管理者联盟,项目管理问题。

项目范围界定没有明确具体,造成不同人员有不同理解(当然也可说沟通不充分)。

然而现实环境经常是不能一次界定出明确的项目范围,所以项目前期的沟通很重要,需
要项目干系人一起磋商项目的具体需求、范围。

分析6:请让项目经理参与到售前中来(cgq1022 )

此案例内容存在于目前国内绝大部门 IT 项目中,个人认为:

1、项目经理在项目启动前需要参与到售前的谈判中,把握项目需求和项目范围。

2、项目经理制定完项目范围说明书后,在公司销售、市场都参与的情况下,组织甲方
召开会议,确定项目最终的、详细的项目范围说明书,并要求甲方指定甲方唯一接口人。

第 303 页 共 756 页
第 3 章 范围管理

分析7:细化需求,走程序变更(周波)

1.最终用户能用合同的相应条款作为依据提出变更,说明用户的要求有合理的方面。用
户的要求没有包含在范围说明书中,是范围说明书编写时没有与最终用户沟通细化。

2.用户需求相互矛盾,应由用户方项目经理解决。 项目管理者联盟,项目管理问题。

3.范围说明书用户签字了吗?

4.组织用户方与项目负责人开会,重新细化需求,并签字确认.由用户方项目经理提出变更,
小李经理需提出变更带来的影响.最后确认是否变更?如何变更. http://blog.mypm.net

分析8:评论(许)

项目启动时没有细致的划定项目范畴,没有明确规定项目参与人员的职责和交流渠道。
尽量理解客户需求变更的深层含义,是需求制定有偏差,还是客户内部的势力权
衡? 本文转自项目管理者联盟

项目管理者联盟文章,深入探讨。

知己知彼,在自己能力范围内调整计划。把活做细,标准化,规范化,避免同样问题再
次出现。

分析9:沟通第一,权衡利(郑维亮) http://blog.mypm.net

在项目实施过程中,甲方有财务部和销售部直接向小李提出变更,甚至会互相矛盾,这
说明甲方的意见都不统一,应该找甲方的项目经理沟通,让他来解决问题。 本文转自项目管理者联盟

对于范围管理,在项目实施之前应该将范围说明书尽量细化,在实施过程中,也应该就
变更带来的影响和甲方项目经理沟通,权衡利弊。 http://bbs.mypm.net

http://bbs.mypm.net

分析10:沟通紊乱(dajundalao )

1、小李自己制订了范围说明书,有没有与甲方取得共识、获得甲方批准?这一环节缺
乏沟通。 http://bbs.mypm.net

2、既然有项目经理,甲方应该由项目经理与小李交涉,小李可以建议。没有规矩、不
讲程序,这个活当然没法干。因而这一环节既是甲方缺乏沟通,又是小李缺乏沟通。甚至于
连与甲方间的沟通程序都没有定,实施中不乱套才是怪事呢。

3、变更的原因没有弄明白。如果是 IT 项目本身的问题,那客户的合理要求必须满足,
项目应在范围内追求满意度。这一得靠分析,二得靠沟通。

综合上述三点,小李应该加强沟通,解决眼前的困境,相信项目会成功的。

第 304 页 共 756 页
第 3 章 范围管理

分析11:补救措施(秦伟)
http://bbs.mypm.net

问题 1:项目边界的不确定

从案例中可以看出,该项目的范围说明书没有得到甲方的确认。这样是很容易在变更中
发生超出项目边界的情况。
本文转自项目管理者联盟

解决方案:
http://bbs.mypm.net

暂停项目的实施,和甲方重新坐下来,确认项目的边界
问题 2:甲方项目关键人的缺失

因为甲方的项目经理是由甲方的一位领导兼任,由于没有专职的人员负责收集甲方的需
求,造成需求提出的不统一,以至于小李无所适从。

解决方案: 本文转自项目管理者联盟

建议甲方确定一位专职的人员,用以收集需求

问题 3:项目关键节点(里程碑)没有确定

项目没有定义关键节点,那么,也就缺少在关键节点,甲方对乙方的工作的认可,甚至
可以进行否认,因为,小李没有拿到相应节点的甲方签字。

解决方案:

迅速的对计划进行调整,同时增加相应的节点,某一项工作完成后,与甲方的项目经理
进行确认,并对生效点进行签字认可。
项目管理者联盟文章,深入探讨。

问题 4:需求变更的无序
http://blog.mypm.net

由于合同条款太粗,同时,由于需求的不统一,导致小李无法对需求进行统一的管理,
并造成混乱

解决方案:

1。和甲方一起重新确定变更流程,并对其签字生效。 项目管理者联盟文章,深入探讨。

2。和甲方(前面提到的甲方项目关键人)一起识别变更,确认优先级别,并记录在案

3。根据变更的优先级别,并在项目组承受能力范围内,给予解决,对于超出预算的,

第 305 页 共 756 页
第 3 章 范围管理

应该坚决的否决。毕竟,没有接受,就无法拒绝。

4。和甲方一起,识别出否决的需求,同时包括甲方还未提出的需求,建议甲方启动该
项目的 2 期,并给出甲方该项目的 2 期实施方案。
综上所述:一个 IT 项目的实施成功与否,最终决定于甲方项目经理的参与程度。

1。合同的签订

在总合同的基础上,应该添加其他的合同附件,包括项目组成员、技术标准、实施方案、
验收方案、付款条件等

2。制订可实施的计划,同时给出关键节点的期限,并进行签字生效。
http://blog.mypm.net

3。在每个关键节点(里程碑),与甲方一起进行签字生效,以避免不必要的麻烦。

分析12:如何走出企业信息系统建设项目范围管理的困境?(程成 )

1、关于项目组织架构设置与职责。
本文转自项目管理者联盟

这直接涉及小李如何确定项目范围问题。尤其对于信息化项目,本身就是无终极目标或
清晰接顶界定,应更为小心。在组织架构与职责未明晰前提下,很难开展工作。

2、在合同中应附录建设总体计划。

此类项目,往往在签定合同前需要协商的。因此,将建设总体计划作为附件,会有力于
工作推进的。哪怕做贡献,也有出处。

3、提交阶段工作报告。其重要性不言而喻,磨刀不误砍柴工。

供参考。

分析13:沟通严重不足!(陈罡)

1、项目范围说明书确定后需要甲方的签字确认,否则你制作的范围说明书只能是一厢
情愿!

2、项目可以变更,但一定要走流程,应该由甲方的项目经理来给你协商变更事宜吧,
其他人可以拒绝变更!
3、对于变更,尽量同甲方协商,那些是可以变更的,那些是暂时不可以变更的(可
以放在二期)
,并且一定要先说明变更会引发的问题,看引发的新问题客户能否接受!

个人认为主要是沟通上面出了问题!

第 306 页 共 756 页
第 3 章 范围管理

一定要加强沟通!

另外制定合同时,能说清楚的最好用合同逐条列清楚,不能为了急于签合同而不考虑项
目后期的制作和验收!

3.6 如何控制项目的范围?

如何控制项目的范围?

[姓 名] 周波 [单 位] 不公布 [邮 件] xymyhome@126.com
[所属行业] IT 软件 [所属主题] 项目范围管理 [发布时间] 2006-11-13

【案例正文】
某公司与某省厅签定了该省十几个县的应用软件与相关系统集成的的合同。合同规
定以招标技术说明书的最佳方案验收。而招标技术说明书是从另一公司的模式抄写
的,详细到实现某些功能的方式。

该公司系统能实现其绝大部分功能,但部分方法与技术说明书有区别。该公司投标
书基本照抄招标技术说明书。且某些功能合同设备清单中没有实现该功能的设备。

该公司请我做该项目的项目经理,请问各位高手,我用什么方法控制项目的范围才
能成功实施该项目呢?

【相关分析】

·可以这样来做(2006-11-21) [作 者] daijiangbao [公 司] 深圳市大视野企业管理顾问有限公司

1、与客户沟通,分析出客户真正要的是什么,找出客户要求的内容和能提供功能的差异,让客户指
出这些差异的重要性排序。
2、针对客户提出这些差异的重要性,制定 4-5 个方案,针对不同的方案要说明每一种方案的优点和
缺点,制定每一个方案的计划,使每一个方案都是可实施的,都是最优方案,尤其是每一个方案都需
要制定出价格、工期等,引导、领导、操纵客户找到自己的最佳方案。
3、引导客户按照你能提供的最佳方案签订合同或补充协议,要注意,如果客户一定要一些特别的功
能,那就把这个方案的这个解决问题的价格抬起来,可以用这种方法打消客户不实际的想法,如果客
户一定要,也不会在这点造成利润损失。因此提供的各种组合方案应该能实现双赢,关键是看项目经
理的沟通能力,见人说人话,见鬼说鬼话的能力了。

第 307 页 共 756 页
第 3 章 范围管理

4、不要相信客户的口头诺言,一定要把这些方案不断反复与客户磋商,再不断反复平衡、组合,最
终落实在书面协议上,最好是中标以后就做这些事,把所有的风险一次性都解决在还没有发生影响的
情况下,在签订合同中加个附件,说明设计更改就可以了,这种情况不是变更,如果签订了合同再做
这个事也是可以,这才是变更,关键是签订合同之后的第一件事就是发起这个变更,之所以一定要把
这些事情上升到法律的地步,就是要建立起客户的责任,没有客户的责任你怎么做都是失败。
5、要注意一定要与招标中心取得联系,让招标中心也有备案,如果瞒天过海,在后面项目付款上会
有很大的问题。
6、要注意以下几点:
(1)、要一次性将这些风险,特别是技术实现风险一次性解决完,不能在后续的
过程中再采取变更的方式,这样对客户的感情和责任打击很大;
7、 (2)、要学习一些女性心理学,女性在婚前、婚后对老公的做法上可能相同,但是心理上是完全
不同的,在招标项目上一纸婚约是中标通知书,不是合同,在中标以后如果不能化被动为主动,完成
从奴隶到将军的转变,将会在根本上导致项目的失败,因为项目是乙方来做,项目管理是乙方的工作,
客户是被领导者。
8、 (3)、要懂得招标法上双方平等的含义及表达,害怕这样对待客户会导致客户在中标后与别的公
司签合同,鸡飞蛋打,尤其是 it 企业的低级项目经理,眼中只有可怜一点的技术,90%都没有研究透
招投标法,这个问题在上面是有法律依据的。
9、 (4)、国内招投标的不成熟,招投标的方案是实现原理,在很大程度上不具备可实施性,这是两
回事,差别很大,按照用户的要求去做就死定了,这之间的风险一定要有很好的意识,招标法上也有
10%的风险储备金,所以可以找到风险,轻易就把这个 10%给吃回来,哪怕价格战打的再激烈,也
可以保证最少 10%的利润,不会引起任何的问题。
10、如果客户要求的东西,在解决方案上价格超出了 10%,可以把设备的档次换下来,采用其他的
方式,客户另外追加投资等方式来解决,只要客户同意,招标中心只关心价格,招标文件、投标文件
都是合同的参考,远远不能等同于合同的法律地位,不要害怕招标文件中的严厉要求,那是对招标阶
段的要求,对后来的事情只有参考的依据,客户不是法律。
11、不要害怕客户不签合同,关键是客户不得不签,不要怕客户拖,客户越拖越被动,你也就主动了,
客户的拖拉真是你希望的。
12、在解决上述问题的基础上同步解决所谓的项目范围问题,项目管理是目标管理,项目的范围有不
同的层次,是项目目标的不断分解得到的,不是从技术眼光看到的支离破碎的一点工作,所以要对项
目的范围有正确的认识,不要为概念而装腔作势。
13、象这样的案例,我可以做到把一个消防系统最后变成只提供两个小灭火器的地步,与客户谈了 8
个月的合同,把项目毛利润从 5%提升到 30%,客户非常满意,我的项目是失败的吗?比起抢银行如
何?这些可都是国内的案例了。对软件开发来说,风险更大,利润就更大了,我就不在这里说了。
一流的项目管理要有世界一流的项目管理理论、世界一流的项目管理方法论和世界一流的项目管理实
践,这些我都具备,我当然有资格说是世界一流的,不必客气。

·communication (2006-11-19) [作 者] 章国新 [公 司] Qimonda IT (Suzhou)

I believe you have to communicate with each stakeholder to understand their needs.

·变风险为机遇(2006-11-16) [作 者] 杰罗 [公 司] 无

第 308 页 共 756 页
第 3 章 范围管理

一切以时间、地点和条件为转移。不要管理论是什么样子的,起作用的就是有效的。
注意细节。仅仅从本案例的文字上得到的信息来分析本案例的合同环境是不够的,很多项目实施的条
件在文字和合同之外。
分析案例,仅仅是个大体的方向,具体的实施方案还要深入探讨和调查有关情况。
简要分析:
1、“省厅负责签定了该省十几个县的应用软件与相关系统集成的的合同。”
注意合同主体,并分析利益关系,抓住合同主体去进行工作,兼顾利益关系方。管理上的协调点。
2、“合同规定以招标技术说明书的最佳方案验收”
最佳方案的说法很含糊,什么样才算最佳?没有客观标准。需要注意,要适当明确。前提是,合同规
定如何付款,据此进行下一步工作。在验收前解决,要讲究方式和策略。
3、“招标技术说明书是从另一公司的模式抄写的,详细到实现某些功能的方式”
说明什么问题?一、主管人员不熟悉该项目。二、实现功能的方式不重要,重要的是要实现功能。三、
机会来了。还不明白吗?(不是让你骗主管人员)
4、“该公司系统能实现其绝大部分功能,但部分方法与技术说明书有区别”
上边说了,方法不是问题。区分好那些功能不能实现,主要的还是次要的,常用的还是不常用的,追
加投资的大小等等,根据不同情况解决。
5、“该公司投标书基本照抄招标技术说明书。且某些功能合同设备清单中没有实现该功能的设备”
一、该公司为了中标。二、估计该公司不是公开竞标得到的本项目。三、机会又来了。
建议如下:
1、协调好关系
2、按照实现完整的功能去准备,但不要在未沟通好前去实施清单中没有的设备。
3、抓好项目回款。
4、在项目中期进行变更。(不会不明白吧?处好关系,做好准备,掌握住主动权,不变是不行的。)
5、有理有据,冠冕堂皇的变。(好让对方交差)
6、多与承接本项目的公司人员沟通(不是技术方面)
7、采用双赢的方法处理任何问题,一切以利益来衡量。
8、不要搞什么不实用的项目范围说明书,变更合同的责任太大,政府官员一般谁都不想承担责任,
而且还要归档。除非你的方案缩短工期、降低费用,给他带来政绩。

·答复:于先生(2006-11-16) [作 者] daijiangbao [公 司] 深圳市大视野企业管理顾问有限公司

谢谢挑战,我这两天比较忙,我绝对会给你一个答复,这样的项目我是完成了多个,从项目的成功能
说明我做的成功。
本人之所以谈到 pmbok,不是死扣理论,而是告诉大家要灵活的运用理论,用理论指导事件,用实践
来验证理论,还原项目管理的面目,让项目管理确实能够指导实践

至于做广告,不必这样说了,如同项目是做的,不是说的,更不是吹的,项目管理不要弄成摆设。
等等。。。

·请教daijiangbao (2006-11-16) [作 者] 于先生 [公 司] 南方数码

第 309 页 共 756 页
第 3 章 范围管理

daijiangbao ,以上你对项目风险和项目范围的阐述很精简,但都是出在 pmbok 的理论内容。而谁都


知道,能作企业管理培训的不一定能成为企业家。理论上没有定义的不表示不存在,就如你所说的不
能死肯理论,把理论用灵活才能用得好。对于这个案例,我也遇到过,不知具体如何作更好。你能否
将目前的风险及未知风险列举出来,如何来化解,纳入到工作范围后如何完成一个成功的项目给出个
详细的解决方法。pmbok 只是不错的理论,但对于项目来说具有针对性。不然很多人会误会你的言词
只是在给一个刚起步的小公司招揽客户的把戏罢了。 请赐教,不胜感谢。

·如何按制项目的范围(2006-11-15) [作 者] 王泰 [公 司] hatl

对于项目范围而言,非常重要的来源是标书的约定,但在项目实施过程中,标书约定的范围并非是铁
打不动的,任何项目都有可能在实施过程中与标书产生一定的偏离,此时对于项目经理来说,项目变
更控制就尤其重要了。
对于此案例,项目经理首先要本着实事求是并对用户高度负责的态度,仔细分析标书约定内容,充分
与用户沟通并提供强说服力的理论依据,走项目变更(一般项目合同中都会有变更流程控制的相关约
定)。
当然项目变更引起的合同价格变更等事项,应由商务人员与用户协商解决。

·项目范围的界定(2006-11-15) [作 者] 王大勇 [公 司] 武汉

项目范围的界定是个比较复杂的问题,它会随着项目的不断深入而凸显出来,这就要求项目承建方在
项目实施初期先做好充分的预见,将此类事项考虑到项目实施过程中来。在与建设方签订合同与提供
实施方案的时候,务必阐明项目实施的范围,并尽量详细说明自己的职责,描述清楚目建设完工后所
呈现的场景。

·赞成daijiangbao先生的观点,但是?(2006-11-14) [作 者] xing jianming [公 司] 重庆城市


建设投资公司

daijiangbao 先生:
我很赞成你在 11 月 14 日回帖的观点,特别是你对项目风险和项目渐进明细性质的论述很是精辟.在项
目管理中,确实有些风险可以翻译成机遇.对项目管理者来说,就是要善于把握住这些机遇.将被动的
项目状态改变成为主动的项目状态.周波先生的项目确实有风险并且已经发生了.这些我们的看法都
是一致的.但是,应该如何来解决和应对发生的风险.这才是此案例提交人的需求.如果我们将这个案
例分析视为一个项目,那么解决方案才是此项目的交付成果.从你的帖子中可以看出,你确实是一个项
目管理的能手.特别是你提到的:---"把这些风险积极化解掉",---"对本案来说,不是因为合同都已经
签了就不能做改变,也不是说合同签了就已经进入到实施阶段,这里有很多的技巧和做法,拿周波来
说,现在就可以主动发起风险分析而导致主动发起变更,变被动为主动",---这些都抓住了解决问题
的关键.但你不觉得"提交描述此技术风险需求的项目范围说明书"是此阶段划解风险,变被动为主动
的最佳方法吗?也许 daijiangbao 先生还有更好的方法,望其赐教.谢谢.

第 310 页 共 756 页
第 3 章 范围管理

·项目的风险(2006-11-14) [作 者] daijiangbao [公 司] 深圳市大视野企业管理顾问有限公


周波先生:
项目的失败不会是在最后才失败,对这个项目来说,既然都分析出来有这么大的风险,为什么不去把
这些风险积极化解掉,好让风险造成的负面影响尽可能减少,同时高风险不是一定表示失败,风险的
另一方面在商业上就是利润,看你对风险的态度和做法了,正确或者失败的态度及做法的最终结果,
才是真正的成功或失败,不在于现在就谈论成功或失败。
项目工作不是去探险,何况真正有经验的探险者是把风险工作放在最前来应对准备的。
如果一定要谈工作范围,把现在的风险应对工作首先纳入工作范围中,然后调整出来项目正确的工作
范围再去谈工作范围。你的这个项目成功与否在此,项目能否获得利润,或者是高额利润也决定于此,
不要把 pmbok 给读死了,我说的这些你应该在 pmbok 中能验证的。
呵呵,都是在深圳,可以随时联系我,我可以给你们提供世界一流的项目管理服务,能不能有这个能
力、是否是吹牛可以沟通谈,我的联系电话:13686855982(深圳),email/msn:
daijiangbao@hotmail.com,欢迎来联系,这样的项目见的很多,如何让你成功我可以提供帮助。

xing jianming 先生:


没有哪个项目是天生完美的,完美的东西去做事也就不是项目了,失去了项目的唯一性原则。
项目不论进入到什么阶段,风险工作都是始终的,不是因为都已经开始实施了,就只要干活就行,实
际上实施阶段才是风险影响量逐渐增大的过程,这个时候再考虑风险的应对,往往付出的代价更大,
但是这种的代价付出,基本上都表现的是风险的负面影响,有可能是双方都不能承受风险造成的后果
而双方都失败,风险管理在任何阶段都需要得到很好的管理。
对本案来说,不是因为合同都已经签了就不能做改变,也不是说合同签了就已经进入到实施阶段,这
里有很多的技巧和做法,拿周波来说,现在就可以主动发起风险分析而导致主动发起变更,变被动为
主动,不要认为变更都是被动的,都是由客户发起的,pmbok 中没有这样的定义。
例如:本案中说道的“最佳方案”是什么东西?做到什么程度是最佳,能不能达到,达不到采取什么
备选方案,如果你就按照客户的要求去做,试图让客户满意从而显得项目成功,那么我可以告诉你,
这样项目绝对失败,你也绝对做不到让客户满意,你们公司也不会满意,这样做软件开发失败的项目
比比皆是,把国内、国外的应用软件开发项目一棍子扫过去,90%的失败都是这样造成的,再多加你
这个项目的失败也不足为奇,能够象我这样说的走出死亡之旅的项目不多,就姑且别说项目利润了。
xing jianming 先生似乎是建筑行业的(也许),在招投标结束后,签订合同就进入实施阶段是绝大
多数都这样做的,但是丝毫也不能回避在实施过程中的风险造成的变更,并不是因为 IT 软件开发行
业有这个特点,而是任何项目都具有这个特点,传统的建筑等这些行业也没有例外,我帮助发改局做
事,非常清楚这些,所以我说这话是有根据的,不是空穴来风,当然,政府行业对这个事情也是十分
痛苦的。
是项目就遵从一定的规律,不区分什么行业,否则也就不会有 pmbok 这个跨所有行业都通行的做法了。

·项目管理者的责任(2006-11-13) [作 者] xing jianming [公 司] 重庆城市建设投资公司

daijiangbao 先生:周波的案例已进入项目实施阶段了,你还在追究它的可行性.他的项目有缺陷,但

第 311 页 共 756 页
第 3 章 范围管理

对于项目管理者来说,就好象一个婴儿的父母.特别是对先天有缺陷的婴儿,更应该精心照顾.帮助其
弥补先天之不足,让其长大成人.

·必定失败?(2006-11-13) [作 者] 周波 [公 司] 深圳市亚奥数码技术有限公司

daijiangbao 先生:你的意思是这个项目必定失败吗?

·还谈不上控制项目范围(2006-11-13) [作 者] daijiangbao [公 司] 深圳市大视野企业管理


顾问有限公司

可行性都还过不了,谈什么范围,太肤浅了。

·提交项目范围说明书(2006-11-13) [作 者] xing jianming [公 司] 重庆城市建设投资公司

周波同学:
看了你的案例,我觉得在现实的项目管理中很有特点.从你的案例可以看出:业主在进行项目招标过
程中,只提出了业主的项目需求,没有编制项目技术标准.他们是利用投标单位的技术资源,通过招
标活动来获取现成的项目技术标准.因为这中事情我以前也做过,我以前在楼宇自控的弱电项目招标
中,由于我对这项技术了解还不深只好利用人家的资源.但是这种不花钱的蛋糕也不是那么好吃的.投
标人在没有获得项目之前,也不会很乐意的把所有的核心技术全部暴露给你.换位思维,你也会如
此.如果完全照抄别人的技术说明书作为本项目的技术标准,势必存在一些不足.所以你只有将各家
技术之长来编制本项目的技术方案.再交专家评审和优化后,才能作为本项目的技术标准.
案例中说的最佳方案.如果真是最佳方案,那就是已经过专家评审和优化的方案,就不会存在你后面
提到的问题.我去年搞的重庆洲际酒店项目的灯光控制项目与此相似.如有兴趣,以后找时间再聊.关
于你提到如何控制该项目范围的问题.因为你没有参与这个项目的合同授予过程.你现在是项目实施
阶段的项目经理.你有责任会同质量工程师一起,详细了解该项目的技术标准.如确实存在你所说的
合同设备与功能需求不符合的现象,你就拟定一份含有描述此技术需求的项目范围说明书,提交业主
审查批准.这样你的项目范围就可以得到新的界定.

第 312 页 共 756 页
第 4 章 沟通管理

第4章 沟通管理

4.1 项目沟通管理案例分析

项目沟通管理案例分析

[姓 名] luolinqiu [单 位] dianxing [邮 件] rolling609119@sohu.com


[所属行业] 综合应用 [所属主题] 项目沟通管理 [发布时间] 2006-9-18

【案例正文】
凯茜·布福德(Cathy Buford)是一个项目团队的设计领导,该团队为一个有迫切需求的客户设计
一项庞大而技术复杂的项目。乔·杰克逊(Joe Jackson)是一个分派到她的设计团队里的工程师。

一天, 乔走进凯茜的办公室,大约是上午九点半,她正埋头工作。“嗨,凯茜,”乔说,“今晚去
观看联赛比赛吗?你知道,我今年志愿参加。”“噢,乔,我实在太忙了。”接着,乔就在凯茜的
办公室里坐下来,说道:“我听说你儿子是个非常出色的球员。”凯茜将一些文件移动了一下,试
图集中精力工作。她答道:“啊?我猜是这样的。我工作太忙了。”乔说:“是的,我也一样。我
必须抛开工作,休息一会儿。”

凯茜说:“既然你在这儿,我想你可以比较一下,数据输入是用条形码呢,还是用可视识别技术?
可能是……”乔打断她的话,说:“外边乌云密集,我希望今晚的比赛不会被雨浇散了。”凯茜接
着说:“这些技术的一些好处是……”

她接着说了几分钟。又问:“那么,你怎样认为?”乔回答道:“噢,不,它们不适用。相信我。
除了客户是一个水平较低的家伙外,这还将增加项目的成本。”凯茜坚持道:“但是,如果我们能
向客户展示它能使他省钱并能减少输入错误,他可能会支付实施这些技术所需的额外成本。”乔
惊叫起来:“省钱!怎样省钱?通过解雇工人吗?我们这个国家已经大幅度裁员了。而且政府和
政治家们对此没任何反应。你选举谁都没关系,他们都是一路货色。”“顺便说一下,我仍需要你
对进展报告的资料,”凯茜提醒他,“明天我要把它寄给客户。你知道,我大约需要 8 到 10 页。
我们需要一份很厚的报告向客户说明我们有多忙。”“什么?没人告诉我。”

乔说。“几个星期以前,我给项目团队发了一份电子邮件,告诉大家在下个星期五以前我需要每
个人的数据资料。而且,你可能要用到这些你为明天下午的项目情况评审会议准备的材料。”凯
茜说。“我明天必须讲演吗?这对我来说还是个新闻。”乔告诉她。“这在上周分发的日程表上有。”

凯茜说。“我没有时间与篮球队的所有成员保持联系,”乔自言自语道,“好吧,我不得不看一眼
这些东西了。我用我 6 个月以前用过的幻灯片,没有人知道它们的区别。那些会议只是一种浪费

第 313 页 共 756 页
第 4 章 沟通管理

时间的方式,没有人关心它们,人人都认为这只不过是每周浪费 2 个小时。”“不管怎样,你能把
你对进展报告的资料在今天下班以前以电子邮件的方式发给我吗?”凯茜问。

“为了这场比赛,我不得不早一点离开。”“什么比赛?”“难道你没有听到我说的话吗?联赛。”“或
许你现在该开始做这件事情了。”凯茜建议道。“我必须先去告诉吉姆有关今晚的这场比赛,”乔
说。“然后我再详细写几段。难道你不能在明天我讲述时做记录吗?那将给你提供你做报告所需
的一切。”

“不能等到那时,报告必须明天发出,我今晚要在很晚才能把它搞出来。”“那么,你不去观看这
项比赛了?”“一定把你的输入数据通过电子邮件发给我。”“我不是被雇来当打字员的,”乔声明
道。“我手写更快一些,你可以让别人打印。而且你可能想对它进行编辑,上次给客户的报告你
像与我提供的资料数据完全不同。看起来是你又重写了一遍。”凯茜重新回到办公桌并打算继续
工作。

问题

1. 交流中的问题有哪些?
2. 凯茜应该怎么做?
3. 你认为乔要做什么?
4. 凯茜和乔怎样处理这种情况会更好?

为防止出现凯茜和乔之间的交流问题,应该怎么做?

【相关分析】

·处境问题(2008-06-14) [作 者] chow king lam [公 司] beria consultants limited

这是个很处境性的问题,凸出了的是项目成员间的沟通不足也不畅.要是项目实行了这么一段不短的时
间还有这类的问题,我觉得一开始就没有好好的建立团队精神.

·授权(2007-11-12) [作 者] xincui [公 司] NOTTINGHAM

授权问题在这个案例里比较重要。
一方面,授权可以调动员工的积极性,乔因为凯茜的不信任,丧失了部分工作的动力,如果他的工作
能够最终被肯定,他就能更努力地完成自己的任务。
另一方面,授权又能让经理有时间来处理其它领导方面的问题,譬如沟通、项目跟踪等。这样就解决
了前面提到的分工不均及沟通和跟踪等问题。

·严重缺乏沟通(2007-10-31) [作 者] 陈欢 [公 司] 汉隆

第 314 页 共 756 页
第 4 章 沟通管理

这个交流,最大的问题就是没有有效的沟通.

凯茜作为项目经理,在这段描述中可以看到比较多的问题:
1) 调整沟通态度待调整.
当项目组成员主动来沟通时,项目经理如果手中的时不是很急迫,可以放下手头的工作,目光移向组
员,与之沟通,解决成员的实际问题.
若手中的工作很急迫,可以让该成员简要叙述他的问题,判断问题的重要性,如继续解决,则马上解决;
若不急,则告诉该组员,目前手头工作急迫,稍后(大约的时间)再继续详细沟通.
如果可以的话,可以跟项目组成员约定,每天的某一时间段,预留给大家,欢迎大家来讨论工作\其它的
问题.

2) 项目未与组员做详细沟通
“我明天必须讲演吗?这对我来说还是个新闻。”乔告诉她。
整个项目的目的和大家的责任,最好在项目开始前就跟组员做正面沟通,让大家能理解该项目,并承担
自己的责任.

3) 对项目没有总体规划
根据实际工作的需要,对整个项目做好时间安排,并列出项目进度表. 将报告需要的数据\内容等,分
配给各负责的组员,并确定提交时间,安排在写总体报告前,或自己提前完成,这样凯茜就不必在第二
天就要提交报告时,才发现数据不全.

4) 项目经理未做项目跟进工作
凯茜只忙与自己的手头工作,却未对各组员做更多沟通,不了解各成员在各自负责的工作中,到底做到
什么程度.

5) 放权,信任下属
乔声明道:"...而且你可能想对它进行编辑,上次给客户的报告你像与我提供的资料数据完全不同。
看起来是你又重写了一遍。"
项目经理的不信任,严重导致乔工作不积极.

6) 项目规划中,工作责任分配不均.
这可能是上面的原因造成的,凯茜忙得不得空闲,乔却只考虑联赛.

7) 缺乏与客户实际的沟通
工作已开始了 3 个星期,对用户的需求还不太清晰,只知道"可能"会用..

乔:
1) 可与项目经理电话预约时间讨论
2) 凯茜未用自己提交的数据时,可以与她沟通,了解未使用自己提供数据的原因,从而改进自己的工

·沟通中的问题(2007-10-26) [作 者] 农建有 [公 司] 广西工学院

第 315 页 共 756 页
第 4 章 沟通管理

凯茜:眼里没有员工,只有工作.
乔在工作时说跟工作无关的事情是他的不是.
这两个问题都归结于工作的态度问题,一个过于热情,一个有点冷淡.而他们两个都没有想过要解决这
个问题,以致一个要工作一个要看球赛.他们的问题是没有把自己的意思真正的表明,让对方听到自己
说话,只要他们每个人说一句话也许就可以解决了.
凯茜说:乔,请在工作之余跟我说这个,好吗?谢谢!
乔应该说:嗨,凯茜,请给我一分钟说点别的事情,可以吗?就一分钟!

·项目经理不仅要关心项目,更要关心你的成员(2007-10-23) [作 者] hjh [公 司] 力鼎

1、凯茜的问题:做为项目经理任务分配不是发了邮件就一切 OK 了,你需要确定,最好是通过电话
或当面说明的方式,从对方去得到肯定的回答,最好在提交的前一天再次提醒对方,记住,他的工作
不完成,受影响的是整个团队,并不仅仅是他自己;另外凯茜应对乔关心的问题给出回应与关注,关
心别人才能让别人也关注到你。
2、乔的问题:对任何问题都是一种无所谓的态度,对问题总是看问题的负面结果,不会积极主动地
解决问题,项目是项目经理一个人的与自己无人。
3、对于乔的问题,项目经理凯茜应该多与他沟通,在他负责的具体工作上要更多地花心思,特别是
进度跟踪,另外要以积极的态度引导对方,改变对方这种消极的工作态度,这样的态度会影响整个团
队的士气。

·沟通中存在的问题(2007-10-15) [作 者] 陈晓琳 [公 司] 自由职业

1、沟通时机不对,在没有梳理双方的情绪的情况下沟通,导致牛头不对马嘴,缺乏沟通技巧
2、沟通态度不对,没有换位思考
3、没有详细的沟通计划,沟通目的不明确,对话主题游离
4、项目经历在项目执行上只布置任务,而忽视任务跟踪,对项目 team 各环节、各成员工作进度以及
工作状态等缺乏了解
5、适度容忍原则,对下属在工作中谈论私事这一情节需要指出

·凯西不像一个项目管理者(2007-10-01) [作 者] 黄立克 [公 司] 华为技术有限公司

从整个交谈过程众可以看出,凯西多次在谈项目中非常微小的细节的工作,比如采用什么方式实现扫
描的问题,还有要向客户推荐什么方案,这个项目都已经确定下来,需求已经明确,为什么还要去修
改,说明前期工作做到不到位,不明确,多处说明凯西非常适合做一个项目中每个技术的开发人员,
乔对领导给的任务和计划,更本都没有了解和完成,沟通问题很大,责任两个人都有,但是主要还是
凯西没有管理好,没有跟踪好,没有进行风险识别,工作到眼前了才催。很失败

·浅析(2007-07-03) [作 者] 朱行军 [公 司] 连云港帝豪实业发展有限公司

第 316 页 共 756 页
第 4 章 沟通管理

1、凯茜作为一名领导在项目团队成员乔来后,工作中应抽出一点时间接待乔,先谈论联赛的事情,
作为一种休息。
2、再明确工作时间和私人时间。
3、接着了解工作情况,明确工作要求,分析职责。
4、一个要工作结果,一个要看联赛,真是“牛头不对马嘴”,两人都存在沟通困难。

·充分理解沟通(2007-05-10) [作 者] 刘峰 [公 司] 北大附中教育技术有限公司

二者都存在着一些问题。凯茜作为一个项目经理,可以看得出,她没有制定一个详细的沟通计划,另
外,在沟通方面缺乏技巧,在项目组成员的主动沟通欲望下,即使不是工作上的交流,也应该及时给
与回应,聆听对方的全部信息,不要轻易打断,然后再通过一定技巧,交流实际工作。乔不应该在工
作时间谈论非工作事情,这是对辛劳工作的人的一种不尊重。
凯茜应该在乔谈论的话题之下,谈论一下球赛,然后再找合适的机会,运用一定的沟通技巧,谈回工
作。根据项目规划制定沟通计划,选择和规定合适的沟通方式,在不同的时期规定项目组成员任务,
避免任务传达不到位或不清晰。
乔在工作时间谈论工作之外的事情,尽管凯茜和他谈论工作,他也无心应对,表明他根本还没有进入
工作状态,另外乔应该去理解凯茜的希望表达的内容,主动聆听,并给出意见。这从另一个侧面显示
出凯茜的项目计划和沟通计划是有漏洞和不足的。

·注意对方关心的是什么?(2007-03-21) [作 者] 龙七 [公 司] AMDOCS

交流中要注意多听少说,同时注意对方关心什么?对方的重点你应该洞察.当然这是对方主动和你交
流,如果你要主动和别人交流,那么如何让对方了解你的重点,就是一个比较困难的课题.
凯茜应该学会如何聆听,通过聆听了解对方的意图.当然她是工作狂,这个不在这个案例讨论.
乔既然是上司,有些时候可以直接对下属说明自己的意图,虽然可能不是工作上的事.
凯茜和乔他们能直接说出自己想做什么,需要对方支持,这样就不会你说你的,我说我的.
交流的主题是人,那么交流就要以人为本,了解人的性情,才能更好的交流!

·注意对方关心的是什么?(2007-03-21) [作 者] 龙七 [公 司] AMDOCS

交流中要注意多听少说,同时注意对方关心什么?对方的重点你应该洞察.当然这是对方主动和你交
流,如果你要主动和别人交流,那么如何让对方了解你的重点,就是一个比较困难的课题.
凯茜应该学会如何聆听,通过聆听了解对方的意图.当然她是工作狂,这个不在这个案例讨论.
乔既然是上司,有些时候可以直接对下属说明自己的意图,虽然可能不是工作上的事.
凯茜和乔他们能直接说出自己想做什么,需要对方支持,这样就不会你说你的,我说我的.
交流的主题是人,那么交流就要以人为本,了解人的性情,才能更好的交流!

·Team contract and communication skills(2007-02-08) [作 者] HSP [公 司] secret

第 317 页 共 756 页
第 4 章 沟通管理

I think that it's very important for project manager to make a team contract with project
menmbers before starting a project,this contract may include following: code of
conduct,participation,communication,problem solving and meeting guidelines.
In addition , the communication skills is very crucial for PM to complete the project
successfully.

·注意文化环境(2007-01-05) [作 者] Seno Chiu [公 司] unknown

大家都提到乔不应该在工作时间讨论与工作无关的事情。 我认为不尽然。跟欧美人打交道比较多的
人应该比较清楚,他们有良好的社会保障体系,他们觉得工作只是生活的一部分,工作环境一般都比
较宽松而且人性化,很少有人会像中国人这么在工作中担当苦行僧,也时常在工作时间讨论与工作无
关的事情。凯茜作为项目经理,只能将悠闲控制在可接受的范围内,无法试图杜绝。所以她其实可以
抽几分钟与乔讨论球赛,然后切入正题沟通项目事务。 同意楼上意见,凯茜应加强任务跟踪,而不
是仅仅分配任务,并对乔这样懒散的人加强督导。

·分析(2006-12-18) [作 者] 王颖 [公 司] 不妨边

交谈中明显乔的心思不在工作上,凯茜也没指出来,更没试图说服乔。两人的沟通很失败,谈话结束
后也没有得出结论。
2.凯茜应从乔的兴趣出发,聊球赛,最后转换向要求乔做的任务。这是一个说话的技巧。
3.看得出来,乔是一个比较懒散的人,工作任务给他后,更要督促,监督他去做。
4.凯茜要学会倾听,该严厉时要严厉点。
、凯茜应该怎么做?
休息一下,放松一下,甚至可以一起看看球赛。
沟通时,把话题引入到关注的焦点上
关心一下项目组内的员工状态
详细的进度计划安排,并确保每个人都知道。
3、在工作任务不明确时,应该积极沟通。
完成进度报告。
不应该在工作时间谈论太多的休闲的事情。

·说话要有矢有的(2006-12-04) [作 者] 张卫东 [公 司] 北京大学软件与微电子学院

1.交谈中明显乔的心思不在工作上,凯茜也没指出来,更没试图说服乔。两人的沟通很失败,谈话结
束后也没有得出结论。
2.凯茜应从乔的兴趣出发,聊球赛,最后转换向要求乔做的任务。这是一个说话的技巧。
3.看得出来,乔是一个比较懒散的人,工作任务给他后,更要督促,监督他去做。

第 318 页 共 756 页
第 4 章 沟通管理

4.凯茜要学会倾听,该严厉时要严厉点。

·沟通(2006-11-30) [作 者] 谢仁禄 [公 司] 无

沟通计划的质量如何,计划的执行情况如何,采取什么方式与队员沟通,项目经理应该好好反思。
乔在工作时间无心工作,他应该认识到自已的不对。有时侯换位思考也是解决冲突的一种方式。

·边听边做(2006-11-07) [作 者] xiaohu [公 司] shanxishenlongnengyuanjiaohuagongsi

有些时候光会听也办不了事,还要看你怎么去听怎么去做

·摆正位置(2006-11-07) [作 者] 杰罗 [公 司] 无

摆正位置
明确职责

·学会聆听(2006-11-07) [作 者] 邵兵 [公 司] 齐齐哈尔

凯茜应该聆听部属的话,并从中发现一些问题。

·项目沟通管理案例分析(2006-11-07) [作 者] michael fu [公 司] 电厂

1、小组沟通一直存在问题,项目经理有不可推卸的责任,这么重要的通知,凯茜只是用电子邮件进
行知会,并且没进行反馈跟踪。
2、项目经理的工作不是只是布置任务就不管了,还要落实任务的执行及跟踪执行情况。
3、沟通技巧欠缺,在对话中明显可以看出乔·杰克逊对今晚的比赛很重视,凯茜应该说祝你今晚的
比赛顺利,但我们先来讨论一下我们的项目的问题。
4、乔·杰克逊工作态度也存在问题,在工作时间无心工作,一心只想着晚上的比赛。

·沟通环境与沟通技巧(2006-11-06) [作 者] Liber [公 司] 宁波

1、首先是环境,两个人的交谈氛围决定这样的沟通时失败的。

第 319 页 共 756 页
第 4 章 沟通管理

其次是沟通中的相互尊重,大家交谈“牛头不对马嘴”
2、凯茜应该怎么做?
休息一下,放松一下,甚至可以一起看看球赛。
沟通时,把话题引入到关注的焦点上
关心一下项目组内的员工状态
详细的进度计划安排,并确保每个人都知道。
3、在工作任务不明确时,应该积极沟通。
完成进度报告。
不应该在工作时间谈论太多的休闲的事情。
4、凯茜倾听完乔对比赛的谈论,并适当的给予评论。
然后将话题带到项目上来。
乔应该首先明确项目任务,工作完成后谈论一下业余的安排。
沟通时相互尊重对方,发现各自话题的闪光点。

·没有建立一个良好的沟通环境(2006-10-26) [作 者] 陈建成 [公 司] 东软信息学院

在不恰当的时间、不恰当的地点谈论不恰当的事情。

·problem(2006-10-20) [作 者] 章国新 [公 司] Qimonda IT (Suzhou)

proglem is not solved

·解决问题是关键(2006-10-20) [作 者] 刘宇 [公 司] 大连市项目管理研究会

1、沟通的目的是解决问题,但在本文当中,问题似乎并没有解决。两个人一直是在各说各的,到最
后没有一个人有作出明确答复。
2、凯茜不应该让乔在上班时间跟她谈论非工作以外的事情,但是需要多注意一下乔的工作状态--
他已经出现抱怨态度。另外凯茜的进度计划制定并不很完善。
3、乔需要按时完成他那份工作,以免拖后进度。而且要端整工作态度。

·discuss it next time(2006-10-19) [作 者] 陈锋 [公 司] SEVEX

so,the girl shall have given up this talk and discuss with the boy sometime

·沟通(2006-10-19) [作 者] 陈锋 [公 司] SEVEX

第 320 页 共 756 页
第 4 章 沟通管理

沟通是很重要,但要讲求效果,乔明显不在状态,无心工作,这时不可能作教深入的沟通

·沟通主题(2006-10-19) [作 者] junhoo [公 司] sino

没有找到沟通的主题!
项目经理应该把很大部分的精力放到与项目成员的沟通上去!信息的实时和畅通是项目成功很关键的
因素!

·沟通的目的是什么?(2006-10-16) [作 者] 姜世伟 [公 司] 站物

有效的沟通是有目的的沟通。当沟通成为一种自言自语时,沟通已变味,而变成了一种倾述。

·牛头不对马嘴(2006-10-08) [作 者] Louise [公 司] XX公司

看完这篇案例,最先想起了一句俗语“牛头不对马嘴”

这样的沟通没有任何意义,反而会带来更多的潜在后患....

·沟通的最好方法(2006-10-05) [作 者] 王丰江 [公 司] 北京华深

沟通的最好方法是语言、谅解、支持、鼓励!!

·提供项目进展报告(2006-10-05) [作 者] 王丰江 [公 司] 北京华深

1. 凯茜应该怎么做?
1. 有时间可以休息一下
2. 项目进展报告可提供
3. 做个产品技术报告给客户,说明产品给客户带来什么使用结果.

2. 你认为乔要做什么?
1. 需要提供项目进展报告

·ee(2006-10-03) [作 者] yangjin1234 [公 司] dd

第 321 页 共 756 页
第 4 章 沟通管理

聆听是艺术,领会是关键

·ff(2006-10-03) [作 者] yangjin1234 [公 司] dd

产生共同语言才好

·浅析(2006-09-30) [作 者] 马渊鸿 [公 司] 安徽方正

2. 凯茜应该怎么做?
1. 有时间可以休息一下
2. 项目进展报告可提供
3. 做个产品技术报告给客户,说明产品给客户带来什么使用结果.

3. 你认为乔要做什么?
1. 需要提供项目进展报告
2. 去看场球赛

4. 凯茜和乔怎样处理这种情况会更好?
1. 完成各自想做的事情,然后把精力放在工作上.
2. 完成工作后,处理自己的事

5.为防止出现凯茜和乔之间的交流问题,应该怎么做?
1. 明确工作时间和私人时间.
2. 明确各自的工作职责
3. 明确客户需求,做个新老产品功能比较,成本比较

·ok(2006-09-30) [作 者] 袁骥 [公 司] 伟擎厦门管理咨询有限公司

管理者要擅于倾听!

·ok(2006-09-30) [作 者] 袁骥 [公 司] 伟擎厦门管理咨询有限公司

沟通成问题!

·细化讨论,请联系我!(2006-09-27) [作 者] 罗杰 [公 司] tpbirds

第 322 页 共 756 页
第 4 章 沟通管理

由于时间问题需要细化讨论的 PM 或学者,请联系本人。
rodge_pe@163.com webmaster@yrgk.com
谢谢!

·信息的敝塞意味着失败(2006-09-27) [作 者] 罗杰 [公 司] tpbirds

1.没有了解互相的身份,职位关系不明确。
2.两个人的沟通态度。
3.缺乏有效的沟通计划和管理规划
4.信息传递敝塞
5.培训体制不完善
上午九点半乔在茜办公室(上班时间提出看比赛的事),避而不关心茜所提的工作,缺乏工作责任心
和激情;
在交谈中看不出谁是经理,而且“比翼双飞”,应以同里心的态度积极的聆听对方的问题,并有效的
解决;
没有预先规划要沟通所要处理的问题;
信息传递上存在堵塞和滞留现象;
员工素质和企业文化须要进一步体高

·沟而不通,不如不沟(2006-09-22) [作 者] daijiangbao [公 司] 深圳市大视野项目管理有限


公司

无意义的说话,不叫沟通,沟通不是说话,说话也不是沟通

·聆听是艺术,领会是关键(2006-09-20) [作 者] yuan yipin [公 司] cosmic

1.分析:基本同意楼上同仁的意见.
补充一点,会谈的双方都没有能在对方的说明中,领会对方的意图,只从自己的立场和角度去考虑问
题.导致整个会谈在对立的气氛之中持续.
2.凯茜应该首先把握谈话对方的实际处境,在理解的前提下,给与合理的指示,最好能够为整个会谈的
成功,铺垫下良好的会谈气氛.
3.乔应该在适当时机给与准确地判断材料.比如我必须几点离开,[数据输入是用条形码呢,还是用可
视识别技术]的不适用的技术上的理由.
4.分析:
为了使得整个会谈紧张更加顺利
(1)“我听说你儿子是个非常出色的球员。” - 乔

第 323 页 共 756 页
第 4 章 沟通管理

凯茜:作为礼貌至少应该谢谢.然后转入正题.这样也可以使整个会谈在更和谐的气氛进行.
(2)“外边乌云密集,我希望今晚的比赛不会被雨浇散了。”乔
凯茜:在谈话过程中,首先应该注意到,以上说谈到的比赛对于乔很重要.在这里应该体谅到乔的时间
也很紧迫.
鉴于以上,应该首先判断和询问乔的最佳离开时间.以便于布置以下任务.
乔:应该在这时,准确地提出我需要在下午几点离开,我还有多少时间去准备材料,给与凯茜判断的材
料.
等....

·沟通与权责(2006-09-20) [作 者] chiao [公 司] 成都

两方面的问题:一是没有进行有效的沟通,谈话没有关注到一个问题上,都没有仔细聆听他人想表达
的意思;二是不明白他们间的职位关系,没有明确的定位。

·聆听是一种艺术(2006-09-19) [作 者] hanfo [公 司] china tietong

聆听是一种艺术
他们两人沟通的主要问题就是都没有掌握这种艺术。

·沟通障碍!(2006-09-19) [作 者] lydia [公 司] neau

如果讨论的话题都不一致的话,
还怎么谈沟通,
这是沟通最大的障碍!

还是互相了解,
产生共同语言才好!

·沟通方式,沟通时间和沟通时机(2006-09-18) [作 者] 游永明 [公 司] 广东省计算中心

这是发生在大约上午九点半,乔和凯茜在凯茜办公室的对话。交流中问题在于双方都想要对方谈论自
己关心的事情,而没有倾听对方的诉说;沟通目标不明确;另外就是沟通渠道的不畅通,日程安排并
不是每个人都知晓。
凯茜关心的是项目内容,那么在与组员沟通的时候就应该停下来仔细沟通。同时,应该和乔声明交谈
的目的:讨论技术接口,讨论会议报告,讨论日程安排等;对于乔想表达的事情,可以认真的告诉他
在午饭的时间来聊,毕竟现在是上午 9 点半。
对于乔,他的目的是想叫凯茜去看联赛,因为自己参加,同时知道凯茜的儿子也参加。是一个很好的

第 324 页 共 756 页
第 4 章 沟通管理

休息,同时也是一个和团队领导沟通的时机,同时也争取能够早点下班。
解决办法就是从事情发生时间和地点看,应该是乔进去谈工作,约凯茜中午再谈参加联赛的事情。同
时还应该将工作安排明确的通知到人,从工具或者制度上加强。

4.2 新上任项目经理遇到的难题

新上任项目经理遇到的难题

[姓 名] lxj [单 位] 不公开 [邮 件] littlesaitsword@sina.com.cn


[所属行业] 综合应用 [所属主题] 项目沟通管理 [发布时间] 2006-3-27

【案例正文】
本人是一个新上任的项目经理,领导了三四个人,项目里有一个技术很强的工程师与我私人关
系还可以,可是这位工程师对项目的整体规划、项目进度不敏感。另外一个比较聪明的年轻人,
你说什么他反对什么,说得都是理论上的。好像挺对,操作起来挺难,有时开个会一个问题与
他争论半天,原因简单就是让他出个文档之类,他说没必要。

可是我不想与他长谈,怕挫伤他的积极性,以后我说什么他做什么,这样也不好。我的想法是
大家共同出主意,共同为项目负责,这真的很难吗?

有时候也挺郁闷,我是项目经理,我对项目时间、质量负有责任,却连一个分配文档的权利都
没有,是不是项目经理做的很失败?有没有什么办法可以解决问题?

【相关分析】

·沟通、还是沟通(2008-01-22) [作 者] 周预 [公 司] 湘潭

这个案例牵涉两个主要问题:
1、项目经理的选拔、任命、责权利。首先自问:我适合做项目经理不,愿意做项目经理不,为什么
被选中做这个项目的经理?我有哪些责权利,国内项目经理往往无权无利,恰恰是项目失败后的一个
替罪羊。请问:在项目章程、任命文件、公司制度明确了你的责权利吗?你的强项、权威在哪里?技
术、管理、法定?

第 325 页 共 756 页
第 4 章 沟通管理

2、项目人力资源管理。项目团队需要各种性格、各种角色搭配组合时间好事,对你的建议时时
刻刻点头 yes 的时候,项目出问题也就不远了,作为项目经理你应该加强自身的修养,客观看待别人
的意见,放弃既定假设,尤其是人格假设。

3、沟通管理,多与每一个员工正式的或非正式的沟通,了解他们的想法,毕竟这个项目人并不
多。对于那个年轻聪明的员工尤其需要沟通,引导他提出建设性的意见,请大家讨论,不能简单否定
他的意见!必要时动用自己的法定权威作出仲裁,问题是你好像没有底气,“。。。。是理论上的。
好像挺对,操作起来挺难”,你没办法说服他,就连一个文档的事情!呵呵,还是你偏心,本身就不
是别人的工作?

·個人的看法(2007-12-01) [作 者] 唐世橋 [公 司] 常熟燁輝(中國)科技材料有限公司

1.豐富自己的經驗,樹立威信.
2.鍛鍊下屬的執行能力,若執行力不夠,工作就比較難進展.
3.公事公辦,不服從上級命令,可請其另謀高就.
4.領導就是領導!

·你一定要树立你的威信(2007-11-04) [作 者] sanyiecao [公 司] tielu

我觉得你要的工程师和那个年轻人好好的沟通一下。但方式应有所不同。与工程师要以倾谈和讲理为
主。让他深入的了解项目的整体规划、项目进度的重要性。对待那个年轻人,要以命令为主。以便树
立起你的威信。但也可加一些鼓励和赞扬的话。

·一点看法(2007-10-31) [作 者] 陈欢 [公 司] 汉隆

可以让技术很强的工程师按照整个项目的进度安排,做一份他个人工作的项目进度表(最好几个成员
都做),给予他思考的空间,当他个人的进度表符合项目安排后,给以高度赞赏。一般对于自己作出
的东西,自己都比较重视。以后可以对照他的时间安排,跟进项目。
对于比较聪明的年轻人,开会时不要与他纠缠,让他有什么意见,可以会后单独沟通。
若他不按要求出文档,可以明确的告诉他,这是他的工作职责,明确告诉他,项目组什么时候要文档,
以及不出的后果(耽误整个项目的工期等),等他自己写了文档,就知道文档的重要性了。
工作的时候,最好还是公私分明,对事不对人。

·项目经理的管理要有理更有力(2007-10-19) [作 者] 林溪 [公 司] 保定天威

这样的问题在第一次带团队的时候遇到过,当时处理的很直接,结果导致成功的项目+失败的团队. 现
在再面对这样的问题,我的处理方法如下,有幸和大家一起探讨.

首先在项目组会议上明确确立各个岗位的职责,赏罚分明.

对于技术核心人员,多用心琢磨他们的思维方式,尽可能将项目的进度和整体规划大概念分解成

第 326 页 共 756 页
第 4 章 沟通管理

具体的工作环节,更方便技术人员的理解和配合.

对于那个气盛的小年轻,不需要发生正面冲突,在项目会议上交办一项他反对力度最大的工作给
他,要求分阶段进行进度汇报.同时私下里与有经验的同事沟通,共同对他的进度和方向进行监督和把
控.通常,第一次的进度汇报里,他的态度就会发生明显转变.换句话说,用事实一次打服他.

·能用则用,不能用提前换(2007-10-18) [作 者] 王金龙 [公 司] 廊坊市华夏房地产开发有限


公司

我以前也遇到过这样的人,我们是很好的朋友。这样的人思维敏捷,能言善辩,思想偏执,认死理,
而知识面又很广,所以最好不要和他辩论,越辩论越让自己气愤,得不偿失。这种人如果真有高手用
好了也能发挥很大的作用,但高人必定不多,如果用项目的制度和责任制还用不了,那就不要用了,
很影响团队的士气和项目经理的威信,孔子说过:君子敏于事而讷于言,还是用君子吧。

·制度、决策、计划由项目经理决定(2007-10-09) [作 者] vegita [公 司] 项目管理

项目管理首先它是一系列的管理活动,那么作为团队的管理者的项目经理必须要有管理的职能。要发
挥好管理职能的话必须建立项目经理在团队中的威信,社会上的事情当然是以理服人,但是有时候是
公说公有理婆说婆有理,而做决定的只能是一个人,项目经理在团队成员意见有分歧的时候应该果断
的决策并稍微独裁一点。
如果,团队成员抵触的话,可以考虑更换成员,毕竟团队建设也是项目经理的职责和权利,有能力的
组员满地都是,能干的项目经理可不多啊!
项目进展的过程中,团队合作和谐与否是关键的影响因素,自身能力强不懂得合作服从的人不适合在
项目团队中生存!

·131321(2007-09-18) [作 者] 松 [公 司] 天啊

李强是 A 公司的项目经理,其管理风格非常严厉。他要求团队成员严格遵循他的指示,强调使用正式
和非正式的控制方法,两年前在他被任命为项目经理时,很多人感到不满。在他任项目经理的前半年
中,14 个工地管理、工程和技术人员中有 8 个相继转到公司别的项目组或离开公司,而正当 A 公司
老板想调走李强的时候,紧张的局势得到了缓解,项目组中留下来的人及李强任命的人都接受了他的
领导方式。

在李强任期中,他成功地将项目建设成本减少了 10%,其进度也达到了项目管理分部主管、客户和建
筑师的要求,他对项目的管理紧张而有效,后来被另外一家公司相中,随后就跳了过去。

A 公司老板准备在项目组中提拔一个项目经理,但他发现没有人是李强的助手或可替代的人,后来,
老板安排首席测量员陈刚来担任项目经理。

第 327 页 共 756 页
第 4 章 沟通管理

·其实管理就 4 个字(2007-09-14) [作 者] 刘志立 [公 司] 安徽华恒建设工程项目管理公司

其实管理就 4 个字“知人善用”主要看你的管理思路和管理手段。

·从自身找原因(2007-08-29) [作 者] tjh [公 司] cxgs

1 你是一个内向的人,偏软.
2 先从自身找原因,加强自身修养,加强自己的岗位修养,
3 用个人的魅力去感染周围的人,
4 做几件漂亮事,让周围的人佩服你,
5 当断则断,工作要有魄力,
这样就好领导了

·总有第一次(2007-08-26) [作 者] lwghui [公 司] sddsasdadsadsa

我赞成以项目的目标为重点,为导向。所有过程条件和操作方式都是为了达成这个目标的。这样在每
一个细节上都要明确目标(子目标),然后归结到最终目标。如果经常用项目目标来引导你做的事情,
那么你就不会有那么多顾忌了。目标的执行力度也很重要,项目经理是项目中具有决策权的人物,必
须使用这个权力,否则项目缺少向心力推进难度太大。

·项目目标的实现(2007-08-26) [作 者] lwghui [公 司] sddsasdadsadsa

我赞成以项目的目标为重点,为导向。所有过程条件和操作方式都是为了达成这个目标的。这样在每
一个细节上都要明确目标(子目标),然后归结到最终目标。如果经常用项目目标来引导你做的事情,
那么你就不会有那么多顾忌了。目标的执行力度也很重要,项目经理是项目中具有决策权的人物,必
须使用这个权力,否则项目缺少向心力推进难度太大。

·有责无权的项目经理(2007-08-18) [作 者] qingjiaheng [公 司] yanz air conditioning

我觉得,只要按照项目经理的特点去做,加上智慧就应该好解决问题:
1. 侵犯性;
2. 结果性;
3. 灵活性。
解决问题无外乎几种可能:
1. 通过和他面对面摊开来谈以求解决问题;
2. 解决不了问题,通过更换项目人员解决问题;
3. 无法说服,也无法更换人员,就自己辞职,《论语》有云:陈力就列,不能者止。

第 328 页 共 756 页
第 4 章 沟通管理

·应该找那年轻人谈(2007-07-20) [作 者] charline [公 司] itt

我认为应该找那年轻人谈谈:
1.了解他的动机,看看他究竟要什么,有料就放他去做,做不定就叫他打包袱,不可能一直放置不理.
2.如果他本人都不认为你是他的头,那你就不是他的头!
一个团队可以存有不同的声音,但一定有一定的目标,为了达成目标
首先是大家对工作分配的认同,对你的认同!

·怀柔政策(2007-07-16) [作 者] 彭佳 [公 司] 地质大学

第一次带团队,只有两种结果; 成功的项目+失败的团队;失败的项目+失败的团队。要想做到成功的
项目+成功的团队,除非有天赋,否则,不可能。
这句话好精辟,第一次带团队肯定是失败的。但同时第一次带团队肯定是成功的,。因为在其中我可
以找到自己的定位和做事方法。从此就知道如何带项目,如何让项目达到期望的价值。

·怀柔政策对初次当项目经理的人基本上不合适(2007-05-30) [作 者] 杨耀敏 [公 司] 待定

你这其实只能算作一个 team leader,与项目管理差距还很大。

大部分项目经理都经历过你这样的阶段,你这样的描述让我一下子就想起自己 3 年前第一次带团队的
经历,可以谈谈我当时的一些做法。

首先,得到上层的信任是做好这个工作的最关键因素,只有信任了,才会得到比较大的授权,同时,
对于下属的直接或间接的不满不会影响上层对你的看法。

其次,对上级态度要强硬,因为没有经验基础,要给上层一个初生牛犊不怕虎的印象,可能你要做得
很多事情都没有规划好,对上层不强硬容易导致跟着上层领导转,既不利于具体的工作,也不利于树
立个人威信。

第三,敢于承担责任,同时乐于将成果记载在属下身上,确保工作中的刚性性格。

第四,对待下属,要比对上级更强硬的态度。因为你没有经验,属下很容易跟你嘻嘻哈哈,因为团队
规模小,属下有意无意不承认你这个项目经理角色,因为技术层面上你不一定面面俱到,又导致团队
的权威建立在技术能力之上。弄不好哪天你说话还不如那个能力很强的工程师有效。

据我了解,大部分的人第一次带团队,只有两种结果; 成功的项目+失败的团队;失败的项目+失败的
团队。要想做到成功的项目+成功的团队,除非有天赋,否则,不可能。

·项目的目标(2007-05-21) [作 者] 邓杨敏 [公 司] 东软股份有限公司

第 329 页 共 756 页
第 4 章 沟通管理

其实,项目的目标太重要了,过程的所有条件和操作方式,都是为了达成这个目标的,那么我们在每
一个细节上都要明确目标(子目标),然后归结到最终目标。
1、您讲的这几个问题,说明你的目标感不明确,如果你时时用这个目标来引导你做的事情,那么你
就不会有那么多顾忌了。
2、目标的执行力度
这点很重要,项目经理是项目中具有决策权的人物,那么必须使用这个权力,否则,项目必然缺少向
心力,项目的推进难度太大。

·让适合的人做适合的事(2007-05-05) [作 者] 冯国华 [公 司] 友达光电(苏州)有限公司

对于技术强的工程师,可以定义一些管理系统,定期提醒项目计划以及项目进展状况.没有看到很多技
术很强又对项目计划很敏感的人.
对于聪明的年轻人,可以搭配一位文档管理能力交强的工程师协助整理文档,文档整理是体现
Performance 的一种方法.后续让其看到文档管理的重要性,等这位年轻人认识这点以后,再配合适当
的指导,或许可以改变原来的想法.
找个优秀的人难,找个完美的人简直是不可能.因此,在管理中,个人认为尽量找出胜任工作的优势个
人特质,减小其弱势个人特质对工作的影响.

·新上任项目经理遇到的难题(2007-04-25) [作 者] willliam zhou [公 司] tju

1.应该有计划有方案,不要抓不住重点 2,要注重项目的人力资源管理,对于不同的对象使用不同的
管理手段。
3,要注意自己的沟通技巧。首先要确定项目章程,给大家讲清楚项目的各种规章制度以及各个小组
成员的职责;

·沟通技巧(2007-03-18) [作 者] HSP [公 司] secret

对于这种情况:
1,要有一个明确的项目职责清单,作为项目成员的绩效考核。
2,要注重项目的人力资源管理,对于不同的对象使用不同的管理手段。
3,要注意自己的沟通技巧。

本网站案例栏目中,案例及案例分析为项目管理者联盟网站版权所有,如需转载或引用,请务必注明:
“案例摘自项目管理者联盟(www.mypm.net)”。如需用于商业用途,必须得到项目管理者联盟授权,
可发邮件至

·不可避免(2007-02-26) [作 者] jennifer [公 司] grainger

第 330 页 共 756 页
第 4 章 沟通管理

对于项目管理中这种问题确实屡见不鲜,项目经理目前的权限大都小于其所承担的职责,关键是将必
要的事情向项目成员强调一下,不必要的文档减少一些,慢慢解决问题。
重要的是自己不要气馁,其实成员不合作,很多程度上是公司整体制度的问题,千万不要灰心,认为
自己失败,慢慢来

·团队合作(2007-02-26) [作 者] wishmadison [公 司] 中国

对于老工程师, 可能与他过去的工作经验或习惯专注于技术有关, 需要一定的时间去磨合,在平时的


工作中, 可以经常提醒他; 对于那个年轻人, 可以采取团队讨论, 如果团队多数通过, 那就得执行,
团队利益大于个人利益!

·有点阴损(2007-02-08) [作 者] 小老虎 [公 司] Null

简单来说,我觉得这件事情上可以考虑下 X 理论

对于第一个资深工程师,我觉得很正常,这种人要在团队里保留的,如果他对进度,规划,都很精通,
要你做什么?他直接作项目经理不就好了,我觉得主要以笼络为主,同时另一方面你自己要盯紧分派
给他的事情的进度。

对于第二个小伙子,我觉得你要以打压为主,他目前的状态就是为了反对而反对。结果要么就是磨平
了他的棱角,要么就是他走人,不能手软,从操作层面上,你可以拿一些不太好操作,上面不是太重
视,他又爱要抬杠和纸上谈兵的工作,让他一个一个人去操作去。然后再狐假虎威的说上面 XX 总很
重视,你要好好做啊,然后看着他出漏子失败。然后你就可以用胜利者当面指点他工作的疏漏和不足,
一方面降低他在其它团队同事前的 reputation,这样来两次吃到苦头应该会好一些。

·我的建议(2007-02-06) [作 者] zhangmin [公 司] 北京东方飞扬软件技术有限责任公司

这种情况在很多项目小组中是经常遇到的。
1、首先要确定项目章程,给大家讲清楚项目的各种规章制度以及各个小组成员的职责;
2、经常给大家进行沟通,从正反两面讲解为什么要这样做的原因;
3、最好是拉一个公司中对此项目感兴趣的高层领导加入项目小组,让大家对此项目引起重视;
4、对于个别存心过意不去的小组成员,坚决清除

·新上任项目经理遇到的难题(2007-02-05) [作 者] 罗伟 [公 司] 西筑公司

作为项目经理,你本人具有性格上的缺陷,对于老工程师,你应该鼓励他在做好技术工作的同时,积
极地参与一下项目的整体规划与运作,而对于小伙子,一方面要容忍他的血气方刚,但要有效的引导

第 331 页 共 756 页
第 4 章 沟通管理

他为项目的整体性服务,至于他连个文档度不愿意出,这就需要你在制度上做出保障你的权威。

·管理(2007-02-05) [作 者] 肖西峰 [公 司] 中国石油工程设计有限公司

借这个案例,我给大家讲一讲管理,

管理是什么? 很多人明白又疑惑。每个人也有每个人的答案,但统一的认识是,“管理是针对人的
措施,是提高绩效的一系列方法”。

管理是针对人的,不单是针对物的,人是多样的,有人技术专长,有人敢说敢做,有人懂管理却没有
经验,也有人纸上谈兵。所以,了解人是项目经理第一位的工作,针对人的特点安排合适的工作和制
定合适的工作方法是第二位的。很多教科书上的方法和工具,有时管用,有时就不管用,原因是不适
合你的项目。所以,根据项目需要制订项目策划和计划是项目经理的能力体现。

只有一群人被系统地安排了工作,合理地分工和接口,组织绩效才可能得到保障。

上述案例中,专家可以负责技术,项目经理要了解其对技术的管理特点,如专家习惯于在方案阶段精
雕细琢,在你的策划中就要在这方面给予考虑;如果你时间紧迫,你就要先向专家解释清楚,取得专
家的理解,并尽可能让专家提前介入,让专家成为制定技术方案的一分子是有效的。适应专家的习惯
是必要的。

通常,对待聪明人是比较麻烦的,但是,如果这个人是富有激情和热情的,就不怕了,这样的人有学
习精神,一旦知道自己哪个地方不对了,他愿意承认,而且会改正,所以,采用引导的方法是有效的。
不妨让年轻人自己讲一讲如何操作自己的理论,从他自己操作中找破绽,需要项目经理有丰富的经验。
对于项目来说,没有文控,是不可能的,你可以问他,业主打电话要一个项目文件,怎么办?给业主
发了一百封信,如何找到某一封?

项目管理不要固守方法,适用于你的项目的,才是好方法,也就是说,适用于你的项目成员的才是好
的。

·新上任项目经理遇到的难题(2007-02-05) [作 者] gemini [公 司] 隐藏

根据个人经验: 1、如果是新任项目经理,最好不要很快换小组人员。会引起更多麻烦,除非你确认
有最好的人选 2、在专家面前当领导,在领导面前作专家。

·新上任项目经理遇到的难题(2007-02-03) [作 者] 陈政 [公 司] 浙大网新科技

从矛盾的几个突出问题看,应该主要是以下几个环节没有到位:
1、项目经理的授权不足

第 332 页 共 756 页
第 4 章 沟通管理

案例中的尴尬在实际中也经常发生。多数情况下,是因为该公司的项目管理尚未提升到企业管理的核
心层面得到应有的重视,项目部的成立大多是在弱矩阵背景下的产物。被任命的项目经理由于授权不
足,其对项目成员的考核不足以影响其奖惩和绩效,因此在工作开展过程中,管理的力度和效果受到
削弱。

2、项目的愿景及策划没有到位
项目愿景没有得到项目组成员及利益干系人的一致认可,项目的策划对项目执行策略、沟通机制及责
任体系等的不明晰,往往造成项目成员的行动及步调不统一,或表现为团队合作意识淡漠。案例中技
术高手和年轻人的表现是项目愿景及策划沟通不到位时的表现。

3、应多了解项目组成员是否面临工作外的困难,一方面改进工作沟通效率,另一方面提高自身的人
格魅力及素质。

·案例分析(2006-12-05) [作 者] 王峥 [公 司] 南开大学

首先说那个老工程师,他的优势是技术很强,弱势是对项目的整体规划,项目的进度不敏感。你也许
对他的缺点很不满意,但是话说回来,如果他技术又强,对项目整体把握又强,还要你这个项目经理
干什么呢?负责对项目整体把握,对项目整体规划的应该是项目经理才对啊,至于工程师,他只负责
他需要负责的技术部分就可以了。你应该多督促一下他,多给他一些指派或建议。
年轻人肯定是血气方刚,初生牛犊不怕虎,这是优点也是缺点,其实他有的时候说出来的话,会是很
正确的,又是别人不敢说的。要多利用这一点。有的时候,对他所说的一些无关紧要的话,可以装做
没听见,不要影响你的决断和工作情绪。

·沟通的重要性(2006-11-30) [作 者] 王颖 [公 司] 央视市场研究

有了困难不要紧,主要是要想办法解决,我认为这个经理在与本部门沟通上显得能力不够,对于不同
的人应该才却不同的沟通方法。对于技术强的工程师,要让他看到自己的弱点,这样才可以调动他发
现自身的不足,从而会发现自己在项目组里的问题。对于聪明的年轻人,要然他看到经理的作用,看
请他在项目组的地位和作用,一定要和他进行长期沟通。

·也来说说(2006-11-20) [作 者] 潘琦 [公 司] 巨峰视通(北京)科技发展有限公司

如果这个的技术能力不错,可以告诉他文档的编制也是系统工程的一部分,甚至比技术部分还要总要,
如果这样都无法调动他对文档的积极性,可以考虑你走还是他走了。

·个人意见(2006-11-13) [作 者] 丁波 [公 司] 未知

第 333 页 共 756 页
第 4 章 沟通管理

两个建议:
1.如果不打算用;建议尽快 fire,因为不是你走就是他走,既然你是项目经理,那就行使你的职能,
保证项目的正常运行,保证团队的目标,所以直接 fire 或者调离团队

2.打算用:就从心里接受这种人的存在,你将很快发现他的很多意见都是在促进项目的发展和实施;
因为如果你无法从心里接受这种员工,那他的意见就是再好你也不会考虑和接受

·震荡期的团队(2006-06-12) [作 者] 武毅 [公 司] ICBC

看来你的团队进入了震荡期,面临组织/人员结构的变化,必须让你的团队形成共识。

·人,是最主要的因素(2006-05-22) [作 者] 张辉 [公 司] 升德升(连云港)电子有限公司

任何项目,离不开人.所以,项目经理,就是要把自己的团队带动起来,向一个目标努力.如果发现那个
人真的不是因为工作原因和自己作对,那么,可以根据公司人事规章制造来处理这个人.但是作为一个
新项目经理,千万要多听听项目成员的意见,特别是经验丰富的成员,他们不经意的的言语之间可能就
是使项目通向成功的钥匙.尊重别人,别人才会尊重你!

·换位思考(2006-05-19) [作 者] saiker [公 司] M

这个人,用得好,对项目成功有很大作用。因此,需极力和其沟通好。他唱反调,主要由于心高气傲,
想更加突出他在项目作用。想体现他的思想。因此,建议不要再他面前提如何做才是好,而是把他看
作项目管理的策划人。请他提出管理意见。然后请他负责监督执行并完成目标。
另外,他反对一般来说也有 1 半有理的。大多跟他过去的经验有关。你能分析出他的经验和现在项目
的不同也对项目有帮助。总来说,你在他心目中,友谊大于权威。

·自身及整体利益(2006-05-18) [作 者] 鲁树林 [公 司] 中誉汽车有限公司

你只是管理者,当成为领导者的时候,自然就解决了.
在项目间又是决策者,执行在管理中是非常重要的.当遇到执行不力的时候,可以当机立断.你的目标
是项目圆满完成.

·培养自己和团队的风格(2006-05-17) [作 者] Lucy [公 司] 一家科技公司

项目经理带领一个团队,既要充分尊重每个成员,也要根据他们各自的特点来安排工作。如果你不能
决定你的成员人选,就想办法培养自己的管理方式和团队风格。新上任的项目经理要得到大家认可,

第 334 页 共 756 页
第 4 章 沟通管理

至少需要 1-2 个项目的磨合,多做些功课,搞好人际关系,并调整自己的心态。

·我是新手(2006-05-15) [作 者] 乱世佳人 [公 司] 保密

我一般是搞定多数人,和大家协调,看是不是有必要交,然后大家再统一作业,然后再告诉那个少数
人,不是我逼她,而是项目需要,再说其他人也都做了,都交出活了,他就不得不服从了:)

·沟通(2006-05-13) [作 者] 车山根 [公 司] 九江学院

项目经理应付注意:
1)项目经理的沟通能力最为主要,因为一个项目经理主要是指导这个团队带动起来,使团队的力量
发挥到最大,使团队里面的摩擦系数减到最小。
2)项目经理还应有一个能力,那就是,拆分工作任务和合成工作任务。有效的使每个成员的工作能
力发挥出来。
3)项目经理还必须果断,在做不出结论的情况下,你就应该有这个责任下结论。

·要做事,先做人(2006-05-12) [作 者] 张勇 [公 司] Meta4-group(上海)信息技术有限公司

我遇到过一个项目经理,总是喜欢用命令的方式和项目成员说话,特别喜欢摆架子。结果时间不长,
大家都对他颇有意见,甚至发展到吵架的地步。长此以往,大家相互之间都有戒心,做事情当然都不
上心了。
所以阿,要做事,先做人。做人就是说,要尊重你周围的人,特别是你的下属。知识分子最爱的就是
面子,我也是这种人,如果领导对我好言几句,立马精神抖擞,卖命干活去了。相反如果处在一个异
常压抑的环境,领导只是喜欢发号施令,显示自己的权威,而不是处处为项目考虑,那么项目成员和
项目经理之间往往是貌合神离,长此下去,项目经理和成员都将疲惫不堪。
所以,劝君花点时间听听项目成员的意见,说不定那个文档还真的没有必要写呢。对于文档,Just
Enough.
另外,没有几个项目的磨练,你很难和项目成员进行很好的沟通。所以,一步步走吧

·球队的问题(2006-05-09) [作 者] 张强 [公 司] 国务院机关事务管理局

如果一个球员踢不好球,是球员的问题,如果一个球队踢不好球,就是教练的问题了.
你遇到的是综合因素导致的问题,建议你先使用统一战线的策略,再慢慢扩大,加强团结

·沟通、协调,重视管理艺术(2006-05-05) [作 者] 刘杰 [公 司] 杰瑞集团房地产开发公司

第 335 页 共 756 页
第 4 章 沟通管理

出现此类问题,首先要检查自己,然后再分析项目成员,及时沟通、协调管理,制定项目的游戏规则,
出现问题严惩不待,树立自己的权威,为项目的下一步操作打好基础。

·向上汇报,开除!(2006-04-30) [作 者] wang [公 司] beijing BI

不要对阻碍团队的家伙心慈手软。

·水平问题(2006-04-27) [作 者] 陈功 [公 司] 南铁安装公司

我看首先是你的问题,你是第一次当项目经理,也许你目前的能力无法降伏他,其次是他的责任,要
不水平自我评价比你高,要不关系学比你好,国有企业都如此,也不比太在意,能团结大多数就是成
功的,这可能也是中国特色的吧

·再议项目经理遇到难题(2006-04-26) [作 者] 冯仲康 [公 司] 四川电力基建单位

国营企业项目部班子中如果有一位成员与项目经理关系不好,但其背景很硬,而其能力也不行,在管
理过程中常自以为是,请问对于这种人如何处理。当然沟通与协调在理论上都知道,但好像在这样的
企业效果不好明显哈。

·他不会写(2006-04-25) [作 者] 丘铨茂 [公 司] 学校

我觉得他是不善于写文档,对写文档反感而已,别想的太复杂了,呵呵

·有没有用(2006-04-21) [作 者] 小鱼 [公 司] 中国十九冶

关键是你觉得他有没有用,如果没有用,那还跟他罗嗦什么?如果有用,虽然比较难用一点,但作为项目
经理就是要想办法把他用起来啊,人的表现都不是无缘无故的,总有他的原因和需要,搞清楚他到底有
什么目的,就好办了,说到管理就两个字,恩还是威,那就要看情况了

·新项目经理的难题(2006-04-20) [作 者] 李政 [公 司] 福州一化化学品股份有限公司

这不是你的错,而是分管项目人力资源的项目经理的问题.现在的项目大多都是许多部门或者许多人
员一起参与的,单独一个人进行的项目是太少了.因此,团队精神就显得十分重要了,团队里有个别钉
子就算很聪明就要坚决把它剔除.如果你这位问题成员不是个性使然,那么他就不适合做你这个项目.
"好像挺对,操作起来挺难"说明了问题

第 336 页 共 756 页
第 4 章 沟通管理

·新项目经理的难题(2006-04-18) [作 者] 甄立波 [公 司] perlos

可以先了解他反对你的原因 如果是为了标新立异 就要正确引导 如果故意和你过不去 一定要封杀


否则这种状况可能蔓延

·新项目经理的难题(2006-04-18) [作 者] 刘笑 [公 司] 理工学院

沟通 很重要啊

·一点看法(2006-04-16) [作 者] 任 [公 司] 西昌学院

其实对于新上任的领导,你在试图了解和安排你的下属,下属也在试探你,案例中提到的那位年轻人
之所以会有这样的表现,分析可有如下原因:
1、他认为自己的才能不应该只是做文档,希望引起大家的注意;
2、他也遇到了难题,借此发泄;
3、他在试探领导的能力和魄力;
4、性格如此,故意和你为难;
遇到这样的情况,可以通过与他较为密切的同事了解他,平时的工作中多观察他,找到原因的关键所
在,采取不同的措施。

·一点粗浅的意见(2006-04-10) [作 者] 李欣 [公 司] 北京嘉乐斯乐科技开发有限公司

你的团队需要一个润滑角色,能润滑成员个性间的、工作方法的、目标敏感度等差异,现在就应该物
色这样一个人。

对于故意和你过不去的,要用些管理手腕,适当的给他下个决议,只要结果。经理还是要先树立威信。

·难题?(2006-04-08) [作 者] 周林麟 [公 司] 深圳某通信公司

初做项目经理的人,多会遇到类似的问题。
1、任何项目管理都不能离开企业的管理环境,项目经理一方面要达成项目目标,另一方面要建设项
目团队,其实更多的是如何让团队成员以同一个项目目标去努力。在人力资源本来就欠缺的公司,再
完善的奖惩体系现实中都是解决不了冲突问题的。在项目管理环境、文化并不健全的企业中,更多的
是借助于人格魅力和友谊来组织团队的。
2、项目经理的沟通方式是至关重要的方面。
3、项目启动后,逐步加强管理规则的执行。

第 337 页 共 756 页
第 4 章 沟通管理

·新上任项目经理遇到的难题(2006-04-07) [作 者] liliehua [公 司] INOAC HUAXIANG

看了您的案例,感觉到你的自信心还不够.作为项目经理,不要求你是全才,如对技术上的问题很清楚.
重要的是沟通和协调功能,我建议:
1.多倾听,多沟通:与团对人员或之外的人交流,得出合适的判断,是否有必要这么做?答案是交流出来
的,判断就要靠你自己了;
2.注意沟通技巧,不要轻易否定"小聪明"的建议,让他提建议,甚至让他去实施他的方案(如果资源及
进度许可);
3.一旦形成决定,注意项目经理的权威性;
沟通,真的太重要了!只要他们不是有意和你搞鬼,应该可以解决!

·因势利导 量力而行(2006-04-07) [作 者] fdc [公 司] fdc

沟通很重要,更重要的是了解团队里每个人的想法。另外是规则的制定,是否是公司的标准还你自己
的标准,在没有树立起来威信前,不要把自己的东西太多强加给别人。另个你的背景怎么样,这么说
不想说明什么,但是你想改变什么原来的东西,背景很重要,没人支持你硬上你会死的很难看。
不知道说的对不对,真诚希望你们的团队能成功,关键是做事要务实,说起来简单做起来不容易。

·人尽其才,物尽其用(2006-04-05) [作 者] jiankaixuan [公 司] yanjiusuo

作为独立个体的人都各有不同,团体每个人都有其个性,我认为作为项目经理最重要的是扬长避短,根
据团员的不同特点总结其长处,并使其在工作中能够得到充分发挥.

·新上任项目经理遇到的难题(2006-04-04) [作 者] 刘雪山 [公 司] 北京市骏程利达科技有限


责任公司

其实更多的还是要与其沟通,说明厉害关系,实在不行换人。
我的看法是,有事情大家沟通,哪怕争吵都没有关系,关键是要解决问题。

·个人价值问题(2006-04-04) [作 者] GARY [公 司] FANGHUA

在项目管理过程中,最重要得是协调,配合~在项目开始之初就该明确项目得性质,以及成员在里面
得角色~应该让他们知道(哪怕是假装得)这个项目是需要他的努力,才能成功,团队和项目都离不
开他~在肯定他的价值的前提下,让他觉得,这个项目是属于每个成员的,对大家来说都是一个好的
机会

第 338 页 共 756 页
第 4 章 沟通管理

·新上任项目经理遇到的难题(2006-04-02) [作 者] 刘海 [公 司] 广东省广州市

有时候也挺郁闷,我是项目经理,我对项目时间、质量负有责任,却连一个分配文档的权利都没有,
是不是项目经理做的很失败?有没有什么办法可以解决问题?

·找找自己的原因(2006-04-02) [作 者] 龚悦悦 [公 司] 不公开

从你的文字上来看,你对你的团队成员并不是很满意。有没有想过是自己的问题?
从来没有十全十美的团队,一旦你要带项目,你会发现:天哪,怎么这样的人都有。本来充满信心,
但低落的士气,各持已见,对自己的不认同让每一个新任项目经理充满了沮丧,楼主应该就是这样的
情况了,呵呵。

项目管理知识体系给我最深刻的感觉就是可以因时、因地、因不同的流程而艺术性的组合它是最完美,
最有意思的工作。

我怀疑楼主有以下几个问题在项目管理中没做好,请参考:
1。是否和所有团队成员取得就项目目标的一致认同。
2。是否将自己的定位很准确,其实自己什么也不是,就只是个打杂的,通常我觉得项目经理就是个
打杂的,呵呵。
3。是否很明确的告诉所有团队成员,你是为他们服务的,你服务的目的是完成项目目标。以其说是
管理,不如说是你希望运用一定的科学管理方法更好的为项目服务,更好的为团队成员服务。(我猜
你没有)
4。对项目的规模,工作范围的把握是否准确,你所定义的工作从公司实际经验、行业经验、项目管
理知识体系和商业逻辑方面是否是经得起推敲。通常项目经理为了搞一个更系统化的管理工作,有可
能会将团队成员带到一个费时费力不讨好的密密麻麻的文档工作中。
5。OK,如果楼主已经很谨慎的处理好了我所说的前四条,接下来才是领导力与卓越的沟通技巧的展
现了。你是个新手,让你有效沟通和一开始就具备足够的人够魅力说实话非常难。但任何一个优秀经
理的产生就是在一次次的沟通沮丧中培养起自己对语言组织的信念。所以,你目前这个情况我并不看
好你能沟通好,但是不要放弃,就当做是练习好了。你只要心里想、其实你就是一个打杂的(呵呵,
第二次说了),这样的沟通效果可能会比现在好吧。

·最基本的问题(2006-04-01) [作 者] 千红奎 [公 司] 网蚁网络

这种应该是最最基本的项目管理问题了.私下认为,过了沟通关,团队和谐关,方能迎接带领团队做新
的发展.

·制定"游戏"规则(2006-04-01) [作 者] 樊俊 [公 司] 上海托新

第 339 页 共 756 页
第 4 章 沟通管理

任何事都要有游戏规则,项目组内也需要有一定的"规矩".
无论如何要让组员都接受这个规则:知道每个人应该做什么,什么事是应该按照要求完成的,什么事是
可以大家讨论甚至自己决定的.
项目肯定是你负责的.发扬民主,提高大家的积极性和参与度没有错,但是也有个度的问题,大家考虑
问题的角度不同,有时会很难协调,但最后总的把握还是要靠你的.
什么事都不要让它陷入无休止的争论中,该做决定时就要做出决定,否则反而降低你的威信!

当然对于乘心捣乱的,直接踢出去就是了:P

·明确任务,确定资源(2006-03-31) [作 者] 梁俊峰 [公 司] 朝林集团

这样的问题,估计任何一个项目经理都会遇到.
我认为:
1,项目组首先要将资源分配合理.做为项目经理,你必须知道那个人要做什么工作.总的计划你心中,
你必须明白,每个人必须完成那些工作.比如你所说的技术强的工程师对整体规划、项目进度不敏感,
没关系。整体规划、项目进度不让他把握就可以了。你根据整体规划、项目进度给他制订相应的工作
计划,只要让他按期完成你所要求的成果就可以了。
2、做为项目经理,必须要明白,那些工作可以让步,那些工作不可以让步;让步的工作,让到什么
程度。如你案例中所说的年轻人。如果在确信自己的计划没有问题时,就需要考虑能否让步,可以让
到什么程度。如果不可以让步的话,只能动用项目经理的权威,强行分配任务。如果分配的任务,不
能被接受,只能够选择让其走人。项目不能因为有人不理解,而被耽误。

·利用团队的力量应对个别人(2006-03-28) [作 者] 牛永芬 [公 司] 北大计算所

很赞同张吉旺和王勇的观点

个人觉得,对于项目中存在的反调,应当尽可能地倾听.因为项目经理应该做到善用比自己水平高的
人, 有的时候观点越相左, 越能帮自己尽早纠正错误.

但是, 如果你对自己的观点有足够的信心,就需要让大家包括"顶牛"者都认识到他的固执和不合作给
团队目标造成的负面影响. 多数人在本质上都是群居动物,都有归属于某个团体的愿望,不愿意被大
家视为异类.所以很多时候大家的力量比项目经理个人的权力还要好使.而且你越忽视"顶牛"对自己
权威的损害,别人就越会体会你的包容和公正,体会你为大家共同目标所做的努力

很个别有想法实在不合作的,只有考虑 fire 了

·管理的艺术(2006-03-28) [作 者] 张俊 [公 司] 北京派得伟业信息技术有限公司

兼听则明,自信、有魄力!就可以解决你目前的困境!

第 340 页 共 756 页
第 4 章 沟通管理

·项目经理的心胸(2006-03-28) [作 者] 王勇 [公 司] 远达网络

在看到 lxj 提供的案例后,我发现他提的问题也是我自己曾经遇到过的。

项目小组里面有的人几乎每件事情都与你唱反调,你说的,他基本上都不会完全同意。

3 楼的张吉旺提供的案例分析-经验体会,已经比较全面的分析了各种情况和解决的办法。

我想我遇到过 3 种人里面的两种: 第一种聪明的人和第二种较真的人。

第一种聪明的人,在工作上面比较大拿,对专业技术有自己的看法。一般对项目经理提出来的建议,
不太认同,希望采用自己的方法。这时候,项目经理,尤其是从工程师岗位提拔上来的项目经理,经
常会有心理不平衡的想法。似乎觉得,我是项目经理,我应该有让你怎么做的权利。如果这种心态不
能调整好,常常会出现冲突或者聪明的员工收到打击,积极性受挫。

对于这种情况,我认为,项目经理首先要调整自己的心态,即项目经理的专长是整体管理和协调,确
保整个项目的顺利完成,而不一定要规定某项工作的具体做法。工作的具体做法是工程师的工作,不
是项目经理的工作。(当然,这种观点,在有的公司里面,如果老板也不认可话,就自己心里面知道
就可以了,没有必要说出来)。 如果工程师可以有更好的想法,为什么不同意? 当然,让工程师充
分发挥积极性,决不是放手不管。工程师看问题的角度,一般而言,不像项目经理这样全面。所以,
作为项目经理一定要规定明确的工作目标。只有完成这个目标,才能算作工作完成。 即:项目经理
负责画好框框,里面的东西工程师可以自由发挥。
以我自己为例,曾经让一个工程师放手去做,但是最后的工作实现情况与整体目标存在一些差异。

第二种人,较真的人。或者说光说不练的人。对于这种人,我的领导曾经告诉我一个方法。 立军令
状,最好书面形式。当然,在你事先预料到他搞不定的情况下,把事情交给他的话,一定要做好充分
的风险分析,备份方案。

最后,我认为,项目经理这一职位,工作目标是管事。但是工作是通过管人来实现的。 管人比管事
要难多了,需要不断的提高自己的沟通和协调能力。

最近,我在看一本书《政治是如何玩的--硬球》,这里也向大家推荐一下。这本书讲的是美国政界
的游戏故事。有人的地方就有政治,这本书用通俗的方法教会我们如何玩政治。如果大家有兴趣的话,
可以看看。

·制订计划与规范(2006-03-28) [作 者] 郑承满 [公 司] 中国建设银行厦门开发中心

1.制订计划
2.制订规范
开会,开会,开会,这两者让大家都要同意,按计划与规范执行,结合考核来管理。
你这个项目很小,应该是比较容易规范各种行为的。

第 341 页 共 756 页
第 4 章 沟通管理

注意组织对你的授权。

·HUMEN MANAGEMENT(2006-03-27) [作 者] naqz [公 司] 一家上市IT公司

如何管理这种唱反调的人,办法很多了;项目的成功与否是要靠团队而不是靠个人的单打独斗;同你持
不同意见的下属,要了解他为什么怎么做,是对你个人有意见的话,那就需要你用领导的胸怀宽容他,
感化他,并能平等的同他谈问题的根节;如果是他认为他的能力强,那可以叫他拿出一套实施的方案大
家论证,如果真的很好,可行并又能节约时间/成本,何乐不为啊!项目经理应该更多的使用专家权和参
照权,这样会有积极的效果,惩治权如果有的话,在使用的时候也要慎之又慎,那是一把双刃剑;就你所
描述的,估计这两种情况比较大,可能也会有其它的原因,但不要认为这就是项目经理的失败,其实有
的时候不同的看法和意见可能是你解决问题良好的补充.

·经验体会(2006-03-27) [作 者] 張 吉旺 [公 司] DreamArts

遇到这种情况,一般有这么几种情况。
第一,你的属下的确很聪明,也很有能力,但是不服管教。这种情况下比较难处理,除非你能做出一
些事情让他信服。如果不能,只能和他讲道理,一个项目每个人都会承担一定责任,作为项目成员也
不例外。如果你分给他的部分他不想按照你的做法来,但是又不影响大局,你可以下放,但是声明在
先,要对这一部分负责,除了问题这是他的责任不是你的。项目经理按常理应该在很多方面要强于属
下,但是也没有非得说经理就不能领导比自己强的。项目经理要体现的是很强的沟通能力,和协调能
力。不一定非要有多么强的技术水平。
第二,这种人纯属较真型的,只说不做。理论头头是道,做起来啥都不行。纸上谈兵!对付这样的下
属,很简单。不会游泳非得成能说能游过黄河。那么给他一个展示的机会,俗话说知难而退,如果他
还有点自知之明,应该会比较紧张,因为这是公司项目,相信他不会不顾及自己的工作机会,而胡来!
如果他没有意识到,那么姑且让他继续,但是作为项目经理,你应该做好备用方案,以防出现差错!
如果他做成了,那么他在这个过程中得到了锻炼,说明他的想法还是可取的。如果你还是不满意,那
么把他做的东西,在项目组内检验一下,出现问题相信他不会不承认。如果他没做到,那你更好做了,
找个时间好好跟他谈一下。说,我不是不想给你机会,只是现在项目不允许出现任何闪失,也不是我
不相信你,只是现在项目时间不允许,我们是一个团队,这本身就是互相学习的过程,我知道每个人
都有自己的长处和短处,这也是为什么项目不用一个人做 4 个月,而是用四个人做一个月的一个重要
原因。大家可以互相监督互相促进,共同出主意。希望我们以后能好好合作,等到项目做完的时候,
相信你已经不是现在的你了。好好加油!
第三,这种人就不想在这里混了,瞎搅局!明了这种企图之后,毫不手软,如果你有辞掉它的权利,
告诉他赶紧走人,我们公司不需要这种不负责任的人,说好明天 10 点之前离开公司,不允许拖到 10
点半,赶紧收拾自己的办公桌!如果没有这种权利,告诉自己的上司,相信他也会同意你的建议!

以上是自己的一点想法,不知道会不会有帮助!加油!!!!

·这样的办法是否可行(2006-03-27) [作 者] gdz [公 司] dfdfdfdfd

第 342 页 共 756 页
第 4 章 沟通管理

是否可以扣工资或奖金,甚至警告要他辞职

4.3 *项目沟通管理与会议管理问题

(一)案例正文

某个系统集成公司的项目经理。他身边的员工始终在抱怨公司的工作氛围不好,沟通不足。
老张非常希望能够通过自己的努力还改善这一状况,因此他要求项目组成员无论如何每周必
须按时参加例会并发言,但对例会具体应如何进行,他却不知如何规定。很快项目组成员就
开始抱怨例会目的不明,时间太长,效率太低,缺乏效果等等,而且由于在例会上意见相左,
很多组员开始相互争吵,甚至影响到了人际关系的融洽。为此,他非常苦恼。

请问产生问题的可能原因是什么?应该怎样提高项目例会的效率?你认为除了项目例会之
外,他还可以采取哪些措施来改善团队氛围,促进沟通?

(二)专家点评

周小桥 PMP,项目管理者联盟高级顾问,实战派项目管理专家。中国职业技能鉴定中心(项
目管理)专业委员会专家委员,清华大学国际工程项目管理研究院特聘教授,美国刘易斯学
院认证教授。美国西雅图城市大学 MBA,剑桥大学认证国际培训师(CTA),项目管理专
业人员(PMP),ISO9000/ISO 14000 质量/环境管理体系注册审核员。

周小桥点评:

项目会议是项目经理沟通项目信息、跟踪项目进展、制定项目计划、形成项目决策、解决项
目冲突、确保项目按计划顺利进行的有效手段。通过举行项目会议,项目经理可以与组织外
部的客户、供应商、分承包商、政府机构以及组织内部的发起人、项目组成员、相关职能部
门经理等项目利益相关者进行充分地、面对面地沟通,一方面可以帮助项目经理全面了解项
目的进度、成本、质量、工作任务的完成状况,以及人员表现,客户满意度,项目执行过程
中暴露的问题和出现的冲突,另一方面也有助于项目经理集思广益,博采众长,充分听取各
方面意见,从而为提升项目团队士气、进行项目决策、解决项目冲突奠定坚实的基础。
那么,项目需要举行什么样的会议,何时开,谁召集,谁参加,为何要召开这样的会议呢?
现总结于下表:

序 会议 频率 召集 参与人 作用
号 名称 人
1 项目 一次 项目 项目当事人双方领导,行业 鼓舞士气,统一思想,明
启动 性 发起 或政府机构领导,发起人, 确项目要求与目标,明确

第 343 页 共 756 页
第 4 章 沟通管理

动员 人 各职能部门经理,项目经理 分工,为执行项目造势
大会 以及项目小组成员
2 项目 每周 项目 项目组成员 项目组自己监控项目计
例会 一次 经理 划执行状况的有效手段。
检查项目计划完成情况,
发现偏差,并制定和落实
纠偏措施
3 项目 每月 项目 发起人,部门经理,项目组 发起人监控项目执行状
评审 或每 经理 关键人员 况的有效手段。总结上阶
会议 季度 段的工作,布置下阶段的
任务,解决发生的问题和
处理出现的冲突
4 项目 随时 项目 当事人 解决问题,处理冲突
临时 经理
会议
5 项目 项目 项目 发起人,老总,各部门经理, 总结经验,检讨教训,论
总结 结束 发起 项目组全体成员 功行赏
大会 后一 人
次性
项目 项目 第三 相关专家 是一种学习和反馈的过
后评 运行 方 程。对已经完成的项目进
价会 一段 行分析、总结和评价,审
议 时间 查与项目相关的政治、经
后一 济、社会文化等目标实现
次性 情况,从而增强决策者和
执行者的责任感,为未来
的投资决策服务

在实际的项目管理实践中,许多项目经理发现召集项目会议、主持项目会议并不是一件容易
的事情。开会的时候有的人迟到,有的人早退,有的人缺席,有的人事不关己、高高挂起,
有的人牢骚满腹、唱反调、出难题,有的人抱怨会议太多、时间太长、效率太低、解决不了
问题等等,甚至出现因意见相左而相互争吵、相互埋怨、推委扯皮的现象,不仅解决不了问
题,反而影响到原本和谐的人际关系,还破坏了团队的士气。出现这些情况的原因是多方面
的,比如开会之前没有确定会议日程、议题、目标,没有安排适当的时间、适当的地点、适
当的人员参加会议,事先没有就项目的目标与相关方面进行沟通、达成共识;开会之中没有
营造良好的氛围,没有控制会议进程,偏离会议主题,没有鼓励大家参与,忽视他人的意见,
拖延时间;会议之后没有形成明确的结论或决议,没有及时发放会议记要等等。这里,给项
目经理提供一些开好项目会议、提高会议效率的建议:
http://bbs.mypm.net

1) 开会之前确定会议日程、议题、参加人、地点等等,并且提前通知与会者。目的是便于
参与者安排自己的工作,有准备、按时参加会议,同时保证会议有的放矢,提高会议的效率;
2) 控制会议规模,仅邀请必须人员参加。不要允许无关人员参与会议,人多,嘴杂,嘴杂

第 344 页 共 756 页
第 4 章 沟通管理

往往很难达成共识; 项目管理者联盟,项目管理问题。

3) 按时开会,按时结束。事先制定防止开会迟到、早退的规章制度,尽可能按会议议程展
开讨论,控制会议进程,千万不要拖拉;
4) 坚持会议主题。开什么会,讨论和解决什么问题,与会议议题不相关的问题,不要在会
上讨论;
5) 充分听取不同的观点和意见。会议、会议,就是说开会的时候要“议”,要议论,就要允
许不同的声音、不同的观点出现,项目经理应鼓励与会者开诚布公,坦诚地表达出自己的意
见,这样的意见即便得不到采纳和使用,也应得到尊重和包容;
6) 形成决议或结论。每次会议都应该有明确的结论,形成达成一致的决议,然后按决议去
执行和落实,为了能达成共识,项目经理最好在会前与各方进行个别交流与沟通,会上可以
有不同的声音、不同的意见,会议一旦形成决议,就只能出现一种声音,并且坚定地执行会
议决议;
7) 作记录并迅速下发。会议记要的发放时间最好不要超过 24 小时。

除了项目会议,项目经理还可以定期组织郊游、体育比赛、文化娱乐等团队建设活动,也可
以集中项目组一起办公、一起培训、一起讨论等,还可以利用队员过生日、项目里程碑实现
之日等特殊时机安排生日晚会、工作晚餐、聚会等节目,目的是给项目组创造接触、交流、
沟通的机会,让他们彼此认识、熟悉、产生信任感,让他们明确项目目标、清楚自己的角色
和职责、理解项目计划,让他们提出自己的意见、参与项目管理,让他们感到被关怀、被重
视、被认可,形成上下同欲、万众一心之局面,从而确保项目目标的实现。

(三)项目管理者联盟网友分析

分析 1、题目:老张,你准备好了吗 作者:梁桢

首先,例会是否能解决“工作氛围不好,沟通不足”的局面我感觉怀疑。也许茶话会也许比例
会更能让项目成员放松,增加沟通机会。所以老张最好能私下了解下工作气氛不好的原因(个
人想法、公司政策等)。

其次,从例会的内容来看似乎事前都没有准备,从例会的结果来看似乎没有人主持,所以会
效率低下,所以会控制不住局面有人吵架。是否该提前 1 天将例会的内容通知每个人,例
会当天每个人都有机会发言,从而大家提出解决方案。
管理一个团队需要有“怀柔”,也需要“大棒”。应人而异,应地制宜,应势利导。

分析 2、题目:对症下药,多管齐下 作者:姜世伟

案例中,项目的员工抱怨工作氛围不好,沟通不足,老张想通过采取例会这一个的措施来解
决此问题。然而由于例会缺乏目的和有效的组织,使原本为了解决工作氛围和沟通的例会反
而加剧了这一问题,可谓是火上加油,雪上加霜。其实针对工作氛围和沟通不足这一问题,
可以通过私下交流和项目活动等各种形式丰富多样的方式来解决。目标是唯一的,途径是多
样的,正所谓条条大路通罗马。

分析 3、题目:老张,想好了再去做 作者:Bob

第 345 页 共 756 页
第 4 章 沟通管理

从项目的角度来看老张对待例会问题上,是很失败的。项目本身就是从计划到监控和管理。
从老张的角度来讲,我有以下建议:
1.老张先要知道员工所抱怨的的问题出在那,再去想办法将这个问题改善。
2.招开例会要有检讨项目的进度。
3.不允计项目成员在会议中推拖责任更不允许争吵。

分析 4、题目:找到根本原因,方能对症下药。 作者:孙泓

首先,老张要明确员工为什么要抱怨公司的工作氛围不好,沟通不足。工作氛围不好在哪里,
沟通不足是员工与上司还是员工之间沟通不足等等。找到原因,方能对症下药,当然例会
制度是个好方法来解决沟通问题,但例会不是万能灵药,特别是目的不明确,为沟通而沟通,
冗长拖沓的例会更是只能起到事与愿违的效果。一个周例会未必要所有项目成员全部参加,
只需要与本周任务相关人员参加即可,且时间在半小时左右为宜,主题一定要明确,对于组
员的争吵,要行使决定权,给予一个公正的裁断。除了例会以外,还可以私下与组员个别沟
通,了解情况,这样也许能够了解到组员更真实的想法。

分析 5、题目:我的一点经验 作者:许利东

曾经有过一个项目,个人认为例会制度执行得较成功的,在这讲一下供参考:
根据项目管理需要我们设置了每月一次和每周一次两种例会,月例会定位为计划协调会,参
加人员包括项目总的技术负责人和各分系统的技术负责人,单位行政主管领导、有关部门的
领导,会议由项目总的技术负责人汇报项目进展情况及存在问题,主要协调解决计划、资源
保障、人力安排等方面的问题。重大问题由单位行政主管领导协调决策,因为相关部门都到
了,会上提的问题,基本上都能很好的得以解决。同时,这样的会其实也是一种计划的检查
和汇报,对进度管理是很好的。另外,每周由项目总技术负责人召集全体项目人员开一次周
技术协调会,每个分系统会汇报各自的进展情况及存在问题,项目负责人主持详细的讨论和
决策。这样项目负责人对技术措施的落实情况也很把握。这种的例会体系还有助于质量、经
费管理人员了解情况,控制项目质量和经费开支。当然,在例会中要有人记录和整理各项问
题及讨论的解决办法,以便会后进一步落实和下次的检查。

分析 6、题目:个人意见 作者:王海飞

每周安排例会以增加相互的沟通,这是一种很好的方式。但是如果形式过分单一和固定,那
么时间长了势必造成厌烦。因此我觉得:
1、明确例会的目的,每次例会要达到一个什么目标,是要增加相互沟通,还是信息交流,
或者是解决问题。
2、变换例会的形式,根据例会要达到的目标来采用相应的形式。比如:此次本周例会主要
是增加相互的沟通,促进人与人之间的关系,那么大家下班后搞次聚餐,效果肯定不错:);
3、增加会议的控制力度。避免偏移会议目标太远。

分析 7、题目:认清问题后再解决问题 作者:赵昊彤

这种情况先得弄清楚是大部分员工都认为工作氛围不好,还是个别员工,并且大家认识的原
因是否一致。

第 346 页 共 756 页
第 4 章 沟通管理

我觉得解决这个问题首先不是依靠所谓的项目例会,项目例会是为了项目成员交流项目进展
情况,布置新的任务来召开的,不适合解决个别人的思想问题。
我认为这种情况出现后,应该先通过个别交流,争取把这种情绪控制住,别大规模散播开,
然后在分析原因,对证下药。

分析 8、题目:team or group 作者:meconsea

需要的是一个和谐、团结、战斗力强的 team,而不是一个松散的 group。


在保证公司利益的前提下为团队谋取利益,致力于在团队中起到核心作用。
我估计你们团队的效率也是相当低下的,要提高工作的主动性和调整工作态度。可以用一定
的规章制度来执行。注意物极必反。例会是用来讨论问题和解决问题的。如果利用例会来融
洽关系和沟通就错了。融洽关系和加强沟通是从平时作起的。在公司是同事,出去公司门是
朋友,要做到这一点。
一个绝招:请你们团队吃个饭,注意最后不要开发票,这样你可以获得人心,即使不是在工
作也是在平时多了些朋友。如果请客再不给你面子,你的问题了。

分析 9、题目:定义环境和沟通问题 作者:tao weijia

可能,项目组人员有心理话要说却不知道怎么和管理层讲,只能说工作环境不好, 沟通不
好之类的话。说明管理者没有经常与组人员沟通了解组人员的环境,和个人问题。

一个好的项目经理会很好的调动人员的情绪。例会只能解决一部分问题。大部分是觉得的工
作细节问题。对于组员讲的“环境和沟通问题”没有太大帮助。
也可能,组员对于项目实施的一些方法和制度不满意,这属于项目前期的工作没有做好,如
果是开发队伍之间的信息输入输出不一致发生的问题,那么开发团队之间的信息控制是否在
流程上要留意下。所有例会上必须要明确的解决目标难题。不然,例会开的象茶话会,茶话
会搞得象项目会。

分析 10、题目:例会和非正式会议 作者:张毅君

原因可能有很多种,领导缺乏领导力,中间有员工煽动情绪,客户刁蛮。
1. 设定例会前要制定好完整的议程,因为例会是重复性的,所以制定一个框架就好了。这
样不用每次例会都去想一个目标。时间要控制好,讨论如果偏离议题太远要及时纠正。 本文转自项目管理者联盟

2. 例会的频率不能太密或太疏,一般一周一次是采用的比较多的。
3. 员工对于公司工作氛围的抱怨不是例会就可以解决的。一般这种问题是通过一些非正式
的会议或单独沟通来协调的。比如说饭桌上的会议,或者在一些非正式的场合和员工单独交
流交流。

4.4 *项目中多种沟通不良的情况如何解决

案例提供者:项目管理者联盟会员 zjh

第 347 页 共 756 页
第 4 章 沟通管理

★ 案例正文:

案例背景:

项目经理当初匆忙中途接手项目后,和项目团队进行问题分析和启动,其中由于:(1)
项目职责前期还不是很清晰;
(2)前期项目问题分析没有深入到根源,发现细节性问题很多
且时间非常急迫等原因,在以下 4 点情况下,直接进入实施阶段:

(1)工作任务分解很粗,在分解过程中也发觉团队成员无法分解出来;
(2)项目管理流程及制度等没有进行确定;
(3)项目团队人员已经被他人分配出去现场;
(4)当然,项目经理也没有意识到项目管理特别是内部沟通工作的重要性(大部分时
间是远程实施)——重点放在梳理外部沟通,以扭转以前的不好影响。
本文转自项目管理者联盟

在项目实施过程中,存在很多问题,表面呈现最严重的是沟通方面,举例:

问题 1、信息失真: 项目管理者联盟,项目管理问题。

(1)现场施工的员工说任务已经完成,但实际上当其他员工到现场去进行客户培训时,
发现远远还没有完成,例如,应用只安装了几台,客户基本没有将系统用起来,系统上存在
BUG 等很多细节问题。 项目管理者联盟文章,深入探讨。

(2)口头沟通,发现代码里面有部分没有改动,前期通过口头已经进行过说明;

问题 2、进度失控:
本文转自项目管理者联盟

部份工作进度已经不完成的情况下,没有及时反馈问题,在周报里面较粗的体现一下但
被忽略等; 项目管理者联盟,项目管理问题。

问题 3、任务遗失:

例1,员工电话汇报较为重要问题内容,但是由于手头工作缘故,一时没有注意,后期
客户直接对该问题没有处理很大意见;

例2,口头分配的任务遗失;
问题 4、口径不一:

一件事情,信息内部没有共享,团队成员对外沟通传达的错误信息;

问题 5、重复劳动:

同一个接口测试文档,两个员工每人都分别写测试并都提交了一份接口文档给客户;

第 348 页 共 756 页
第 4 章 沟通管理

问题 6、及时反馈:

丽水局方反馈我们实施人员没有及时反馈前期提交的遗留问题。

请教专家:

(1)项目中出现的沟通问题如何避免,特别是信息失真情况? 项目管理者联盟文章,深入探讨。

(2)如何确保良好的沟通?如何建立良好沟通体系?
(3)系列问题的根源是什么?

点评本案例>> http://blog.mypm.net

★ 项目管理者联盟专家点评:

专家介绍:

蔚林巍 项目管理者联盟高级顾问,清华大学经济管理学院项目管理专业教授。

蔚教授另外还担任美国 PMI、INFORM(项目管理、管理科学与运筹学会)会员、清华
大学经济管理学院经贸委 MBA 项目主任、中国企业创业研究中心研究员、中国技术经济研
究会项目评价与可行性分会理事。1994 年在加拿大滑铁卢大学管理科学系高级访问学者;
2000 年在美国华盛顿大学奥林(OLIN)商学院访问教授。2001 年曾分别应美国 PMI、印度
项目管理协会的邀请赴美国纳什维尔和印度新德里参加国际项目管理大会,做项目管理的专
题发言。蔚教授还是《PMBOK 知识体系》中文版的审定者、
《PMP 考题》中文版的审定者。

专家点评:

沟通对于管理的重要性以及如何进行有效地沟通已有大量的出版物对其进行了长篇论
述,然而,大量的问题项目和项目失败仍被归咎于项目沟通问题。这一点也表明,许多管理

第 349 页 共 756 页
第 4 章 沟通管理

者对入如何有效地沟通仍不得要领。比如连我自己,阅读了基本关于沟通的书籍之后,仍一
头雾水。撇开那些高论,我个人的看法是,达成有效地沟通,首先是简化沟通的复杂性。

即首先将因人、因事、因文化、环境、情境等等而异的沟通问题统一化起来,建立一个
公开的沟通制度、策略和计划覆盖所有问题。 这当然不是百分之百的最佳做法,而是最适
当、可行的做法。 试想一下,在中国传统管理文化氛围里,要应对“我知道你不知道我知道
的”人际关系策略,难道能够找出更适当、具可操作性的沟通策略吗?

讨论管理问题,往往是从科学和艺术两个角度出发。 作为一个管理研究学者我只能从
科学层面谈问题。从艺术角度讨论问题,我是没有资格的,我即不是沟通大师也不是管理大
师。但我相信,沟通艺术问题,太过于复杂,只有靠个人的感悟和天才。

我的建议是对于一位管理者,作为一个权变计划或策略,除了公开的管理和沟通制度、
策略和计划之外,还需要有一个个人的(非公开的)沟通策略和计划,来应对那些公开的管
理制度无法解决的诸如项目信息失真、沟通体系不畅等问题,这里就涉及到对管理和沟通艺
术拿捏了,也超出我的知识范围了。

仅谈一点艺术层次的问题,比如现在老外讨论中国的管理问题,都十分强调“关系”在中
国文化中的重要性。我们不得不承认,许多“沟通”问题是需要在解决了“关系”问题之后才能
够得以解决的。 团队、客户之间“关系”好了,目标认同问题和一致性问题也解决了, 沟通
障碍也迎刃而解。

★ 项目管理者联盟网友评论: 项目管理者联盟文章,深入探讨。

分析1:communication(albertsu) http://bbs.mypm.net

从文章就可以大致猜测作者的能力,公司的流程很差。

细节!魔鬼存在于细节之中。沟通是项目经理最重要的个人素质之一。能够灵活采用不
同沟通方式,经理的成熟,经验就起了作用。

问题的根源是项目经理缺乏沟通能力和经验。东西太多了。只举个具体例子说明一下。

WBS 粗糙,可能你营造的会议环境,不利于人们放开来说话,搞成一言堂。不少国人
都有一种特性,当面无话,背后鬼话。为了打破这种不好的文化,经理要主动问话,“某某,
您是 XX 方面的权威,您在 XX 很有能力,请说说您的看法。”“为了项目不失败,请说说您
的观点,还有什么要补充的吗?”当面沟通最重要的是让双方互相了解所想表达的东西。沟
通能力强的人,能了解到对方有没有明白自己的话。但人经常会健忘的,所以,口头沟通必
须以书面记录为补充,并发给相关人员。
碰到这么多问题,难道斑竹没有自我检讨的能力吗?

第 350 页 共 756 页
第 4 章 沟通管理

到网上寻求现成答案。建议你去培训一下自己的沟通能力,并对项目团队做个沟通培训。
再学学 ISO9000。

我们即使给出了解答,也只是印象很浅、短暂的,最好的课程是自己总结出来的。 本文转自项目管理者

联盟

分析2:沟通与记录(宁馨紫菊) http://blog.mypm.net

本文转自项目管理者联盟 楼主提出的问题,我有下面的一点看法,个人意见,愿意交流。

首先,楼主是中途接手,那么发现工作任务分解很粗,管理流程制度没明确等问题,就
应该及时在项目团队里提出来,及时的针对一开始就发现的问题进行解决,这样才保证后面
的错误越来越多,越来越大,导致无法挽回,任务失败。

再次,如果有团队人员已经派往现场,那么要及时跟踪现场情况,要求现场人员做好现
场情况记录。

往下:在实施过程中,很明显,没有将任何一项工作做好记录,一切都是口头,当然事
后查无对证,大家互相推卸责任,说谎话。

楼主应该对项目的及时跟踪,问题跟踪,事件记录以及有效沟通上多做努力。

分析3:项目中多种沟通不良的情况如何解决(郭先生)
http://bbs.mypm.net

1 对项目的进展要实行有效的控制,根据各项目的具体情况制定一套项目文档,如:项
目任务书,项目的约束文档,项目进度情况表等等。俗话说:磨刀不误砍柴工

2 对于人与人之间的沟通是每个项目经理头疼的事情,但个人认为:沟通的前提是真诚,
沟通的动力是激励,沟通的保障是约束 ...

3 从案例表面看问题的根源是缺乏沟通,但实际是项目经理对项目的控制力不够。项目
启动时没有的深入分析,缺少项目的计划,执行过程中项目组成员缺乏沟通,对项目没有形
成有效的控制,收尾时发现诸多问题。 本文转自项目管理者联盟

分析4:项目中多种沟通不良的情况如何解决(乐祥文)

1.任务分解,责任划分明确,以书面形式发放给项目组内部和客户,让每一个人都明确自己
的职责以及配合人员的职责。

2.定期举行项目例会,总结项目进度,对故意隐瞒错误的严惩不怠,同时及时对项目的风险
进行评估,调节项目分配或者寻求更加充足的资源。

分析5:计划粗糙,缺少沟通(李智攀)

第 351 页 共 756 页
第 4 章 沟通管理

看整个项目,管理漏洞多;组织结构不合理;资源紧张或利用不合理;责任分工不明确;
任务分解粗糙,没有定义实施过程中的里程碑目标;项目经理没有做好协调沟通工作,疲于
应付所谓的外部沟通。

对于项目经理,没有做好前期的准备工作,没有制定详细的范围说明书,任务细分,明
确责任;没有周密的工作计划,带领一堆伞兵。还错误的把重点放在外部沟通,相反的却远
程管理项目团队,根本不重视内部的监督与组织协调工作。 http://bbs.mypm.net

对于信息失真,是因为员工的责任心欠缺,没有凝聚力,人心涣散,没有动力,没有激
情做项目,大家感觉很多事情凑合一下,应付一下就行了,反正也没关系。这是项目经理的
责任,一个合格的项目经理,应该在接手项目一开始就组织全体人员开会,大家一起讨论,
提出想法,并倾听这些意见来制定合理的计划日程,明确分工、责任,并鼓舞,激励大家,
让人们不是消极被动而是积极主动的执行任务。
http://blog.mypm.net

良好的沟通,项目经理还要定期召开阶段总结报告会议,以了解项目的进展情况,进度
是否按照预期计划进行并做出相应的调整,并对此阶段出现的问题,弄清楚原因,问题出自
哪里,出自谁。指出以后要注意的地方,充分调动现有的资源。同时,项目中的每一个环节
变动,都在记录并编入文档以备查询。

分析6:仓促接手,贸然踩油门---沟通能力乏善可陈(陈万春) http://bbs.mypm.net

我是做工程项目的,一点意见,仅供参考(希望讲的不是外行话)
: 项目管理者联盟,项目管理问题。

(1) 中途接手的项目,是一个烫手山芋——接手者第一步做的是尽可能的了解全部情
况,而不是贸然踩油门冲刺,头疼医头, 脚痛医脚——“项目前期工作”很不到位,感觉就
像大象进了瓷器店——感觉接手者操作项目的方向感有严重偏差,不适合做项目经理;

(2)接手者没有项目经理应该具有的基本沟通能力---有人讲“项目执行的过程就是项目
沟通的过程”,在这个案例中得到验证;

沟通需要项目的实际历练!这也是工程项目的项目经理一般要十年以上有效现场工作经
验的一个基点。

有些巨型工程项目的团队中,配置有专职的 coordinator!

分析7:项目经理疲于应付(zjh)

没有全面细致的计划及实施方案,仅有里程碑式的粗略计划,不足以指导项目执行和控
制,对项目的进度情况难以判断。计划不细致,不全面,资源难以落实,成本不易控制,沟
通也只能停留在表面问题上,更多的是发现问题时才知道沟通什么,往往会使项目经理疲于
应付。

第 352 页 共 756 页
第 4 章 沟通管理

网上的这段话,比较深刻的描述了项目的状况

对于本项目我们内部也进行了总结,主要对问题有以下认知:

对于信息失真问题:

(1) 新方向、新业务、新领域情况下,信息失真一般都会存在,很多细节问题都会存
在无法避免,除非做到专家级别能够综合分析、预见几乎所有问题;

(2) 只要存在沟通,就有可能会出现信息失真;
(3) 解决:我们一定要把问题定位到位,分析出问题出在那个环节,从而知道下
一步该怎么办:是出在需求?设计?开发?等这是关键。问题需要转换成问题出在哪里,信
息失真在那里; 项目管理者联盟,项目管理问题。

http://bbs.mypm.net

(4) 避免:比较难避免,但可以减少影响程度,特别是对于新方向、新业务、新领域
情况下,建议将“信息失真”作为一个风险,对关键任务进行重点预防。

对于信息沟通交流: http://bbs.mypm.net

首先,从理论层面进行分析; 项目管理者联盟,项目管理问题。

其次,沟通要注意两大基本原则:
如何确保沟通中信息完整?

1、信息发送者需要保证已经被信息接收者接受并理解;
2、信息接收需要反馈已经接收到信息并正确理解。

第三,更进一步:最根本的问题是规范问题。

对于在项目中经常遇到的问题,需要及早制定规矩,共同执行
越早越好,多迟都不晚;

4.5 中途接手项目的人员沟通问题

中途接手项目的人员沟通问题

[姓 名] zuiyuu [单 位] DLHA [邮 件] suiyong0263@gmail.com


[所属行业] IT 软件 [所属主题] 项目沟通管理 [发布时间] 2008-7-11

第 353 页 共 756 页
第 4 章 沟通管理

【相关分析】

·中途接手项目的人员沟通问题:二次分组(2008-08-19) [作 者] suntsang [公 司] xc tech

基于对本例得分析可以得出以下结论:
1、“该项目在整体运作及人员构成上都比较稳定”,这个是项目的论断,说明无论项目管理方式如
何,它是有效的;
2、“开发方式属于英雄式”,让人感觉到一丝酸味,呵呵
3、“对于需要团队开发的工作不能融合其中”这个显然前后矛盾。

但毕竟一个项目的项目经理是主导,新的开发要开始了,怎么解决这个问题,人员不能替换,其余人
员积极性不高。

其实很简单啊,为了保证原开发部分的良好状态,就保持他的组长位置好了,对与新的部分再建立一
个小组即可,还可以借新组的建立,重新安排人员,并且鼓励士气。

·组长是人才(2008-08-09) [作 者] 谭以坚 [公 司] 广西南宁市宾阳县卫生局

使组长更换个人英雄主义思想方法:
1、再沟通(最好);
2、在项目组内更换岗位,甚至更换多个岗位;
3、充当项目经理副手,体会团队精神;
4、组长亲自起草某个阶段团队开发绩效报告,清楚结症在哪里?
组长的工作作风比提出加薪等等问题好解决。换人前要考虑成本及人员思想波动。组长带走几个哥们,
项目经理也要下岗了。

·发挥人之所长,工作分配得当(2008-08-03) [作 者] 李有贵 [公 司] TCDRI(天津水泥设计


院)

我也谈谈我的看法:
首先,要把团队合作的理念灌输到这样的队员身上或者有些难度,项目经理的任务之一就是协调,充
分发挥每个人的优势。试着挖掘他身上的优点,把一些适合他的工作分配给他。
再次,他的工作不可能他一个人就能完成,中间可能会需要其他人的帮助,这就是一个团队融合和协
调的过程。
在平常的工作中,在团队中灌输团队协作的思想。平时在一起的时间多一些,大家的感情也会深一些,
合作的氛围也就会多一些。当然,这是一个长期的过程,能不能建设一个高效的团队就看项目经理的
本事了,祝您成功!

·从小事着手 进而得到理解和信任(2008-07-30) [作 者] 陈尚义 [公 司] 甘肃省投资公司

第 354 页 共 756 页
第 4 章 沟通管理

管理是从人的思维的基本面进行考虑,不要急于处理存在的惯性现状,必须逐步让大家理解和支持你
的管理模式.

·谢谢D友张翼(2008-07-26) [作 者] dajundalao [公 司] 暂时保密

由于我用的是化名,同时被张翼先生称为 D 人,因而张先生就是我的 D 友。
也许是我在国有企业待的太久了,对这些现象见怪不怪,只是对做事的英雄们惋惜--这种现象在国
企都是让人寒心而悲壮的。当然,如果团队全是年轻人,大家还是大多会惺惺相惜的,结局可能会好
点;如果年龄差异、业务层次也差异的话,我说的结局就是一定的。
但无论怎样,我们都希望把事做好,把项目做好。我们也殷切期望这位项目经理把项目做成功,毕竟
我们这么多人关注他、祝福他!

·沟通,顽强的沟通!(2008-07-25) [作 者] 王金龙 [公 司] 保密

作为案例,我们就按题目给出的条件解题。既然不能更换人员,而这位个人英雄主义色彩浓厚的组长
的做法有不利于项目的实施,那么唯一的途径就是改变这位组长的思路,要想改变组长的固有行事模
式,唯一的途径只有沟通,沟通、沟通、顽强的沟通!如果这也不行,那只有把他放弃!

·任务+资源=分配(2008-07-23) [作 者] aoxingtx [公 司] 澳星通信

作为一个项目经理,应该首先要了解什么是项目,什么是项目管理.
项目经理是由公司任命的,条件是在本公司工作有一定的时间,并对
本公司的产品和要进行的项目有一定的了解.不需要项目经理证.这是进行小项目的实施.一般情况
下,公司任项目经理不会请外面的新人.
当然,作为项目经理与下属沟通是一个很重要的事情.也是项目成败的一个关键因素.这个人在长期的
工作中,形成了一种定向思维,需要在一天,两天的时间来改变是比较困难.那么最关键的问题是如何
来改变他这种思维方式,需要项目经理动脑筋.
可以让他慢慢的脱离原来的岗位,并进行系统的培训,让他了解所在岗位的重要性.让他了解也是一个
重要岗位.
我估计这个人根本不了解什么叫项目,以及项目实施的过程.
如果通过培训没有什么改变的话 换人.

·产除异己,确立威信.(2008-07-23) [作 者] 林万山 [公 司] 广州市安途货运有限公司

1.利用资源,扶植亲信.
完成第 1 点后,2.利用政治手段,赶走不利于团队建设的组长
3.建立清一色嫡系.提高他们积极性,将责任分派到位.
4.有必要的话,找好替罪羊,为自己留条路

第 355 页 共 756 页
第 4 章 沟通管理

·重在了解,不能无敌放矢(2008-07-23) [作 者] JIANBENGUO [公 司] 河南石油安装工程有限


公司

本案突出一点是新进一公司。没有调查就没有发言权。要解决问题,首要是了解产生根源。了解公司
的领导作风、组织运作程序、方法特征,是自己决策所必须考虑的因素之一。
本案既是长期项目,决定其工作非紧迫性。允许多种方案尝试。
既然人员不随意换,并非不能换;取决项目经理的决心和能力,以及可替代资源情况。
沟通是相互了解过程,也是获取授权和合理授权的前提,而协调仅限于排导。前者做好了,就具有权
威性基础,剩下的就是自己如何运用问题。
管好项目的核心在于抓好组织,发挥团队作用。

·D人所见略同(2008-07-21) [作 者] 张翼 [公 司] 上海健生实业股份有限公司

粗糙了!才看到 dajundalao《配置以组长为骨干的团队》的分析,dajundalao 也是以 D 开头的,可


谓是 D 人所见略同。
但不同意 dajundalao“保一个组长、得罪一批组员而受到较多的非议”的结论。
应该从项目管理和软件工程的角度对项目组其他成员进行培训,这样他们可以通过这个项目学到规范
的、非常丰富的、写程序之外的、软件项目研发必须的知识,而不是仅仅在项目中做一些下手活。这
个项目做下来,甚至有可能这些人的收获比项目组长还要大。

·手术师的工作模式(2008-07-21) [作 者] 张翼 [公 司] 上海健生实业股份有限公司

这种情况对于从技术成长起来的管理人员,是经常会出现的,而且都要经过这个槛。
建议还是采用 Brooks《人月神话》提到的“手术师的工作模式”,笔者就在不同的场合中几次采用
过这样的工作模式,效果还不错。
在目前的情况下,要改变项目组长的工作方式,显然不是朝夕之间的事,而他对项目的技术方向和开
发进度又起到决定性的作用。
因此,唯一正确的方法,就是为这位牛人专门设计项目管理流程,即采用“手术师的工作模式”。
具体做法是:
1、根据项目组其他成员的特点进行分工,分别承担项目文档、进度回馈、质量控制、风险分析等工
作,加强对各个分工岗位的能力和管理培训,让他们把项目管理和研发流程中需要做的工作做好;
2、在技术上,可以让项目组长做专题剖析,从而对项目的技术内容进行间接的监控。
这样做的好处在《人月神话》中有详细的分析。
小团队的开发模式,本人曾在坛子中发过一个帖子,可作参考:
http://www.mypm.net/bbs/article.asp?titleid=29571&ntypeid=5005
《只有一个程序员的项目开发》

·一些建议(2008-07-21) [作 者] 一孑 [公 司] 一孑工作室

1、既然是半路接手的项目,势必在团队磨合的时候你没有参与,尽快补上这个阶段,就是 PM 和团队

第 356 页 共 756 页
第 4 章 沟通管理

的磨合,一定要好,无论从工作关系还是私交(尤其是这种英雄式开发的团队更为重要)一定都要磨
合好。在没有磨合好之前,可能你不具备话语权,所以,一定要慎重。
2、任何一种工作模式都是由于一种原因造成,并且形成了工作习惯,找到这个原因,看是否可以解
决,分析这种工作方式是个人利益和团队利益的对比。看是否可以提出一个好的工作方式以取代原有
工作模式,切记,一定是可以消除原有的弊病,并且适合当前的开发。
3、与组长沟通,尽可能让其做一些管理工作,让其自身感受管理的迫切性,他的技术强,让其做技
术管理,并承担风险,这样做两个目的,一是让其尽可能的转变自己的思维,从技术思维转变成为管
理思维,二是让其承担不转变带来的风险。但你要做一个保姆,让其做管理工作的目的不是让其管理,
而是让其转变,你一定发挥管理的职能,不要适得其反。这样做是有风险的。
4、为什么不能调换人?原因何在,找到它,并去解决,任何一个团队不可能出现人员固定不变的局
面,举个不恰当的例子,如果核心人员发生了不可抗拒的风险,最终还是要换人,只是被动的,所以,
找到原因解决它,不能让其成为你工作的障碍。也就是确保换人对项目是利大于弊。
5、沟通,了解所有人的想法。做为具体工作的人员来讲,工作不积极的主要原因是从上来的,你必
须要打通这个环节。要去做符合团队利益的事情。
6、要知道你自己的职责与权利,然后去做你可以做的事情,不能做的事情上报,寻求更多的资源予
以解决,并作出你认为合理的风险评估报告。最终的目的是获取更多的资源,帮助你完成项目的管理
工作。

·先进行角色转换沟通(2008-07-21) [作 者] xieshiling [公 司] 济南科技有限公司

针对这种情况,讲大道理估计是没有用了,试试这种办法不知道可否?
1、让原来的人员直接负责,你当甩手掌柜,风险你来承担,出现问题了,一块来分析,规避的方法,
可能能够找到共同的地方,然后引导他按照你的思路来走;
2、是否可以引入其他人员,原来的继续,时时准备好应急措施,慢慢进行调整。

·配置以组长为骨干的团队(2008-07-16) [作 者] dajundalao [公 司] 暂时保密

作为中途接手项目的项目经理,中途换将是大忌,而且往往因为时间的限制而使项目中途换人而致使
项目最终失败。因而,由于使项目成功是你第一目的,因而,你要有充分的耐心,把项目的担子压给
英雄主义倾向的组长,以此来重新进行工作分解,并说服其他组员以他的工作为中心开展工作。
接下来要解决的是你自己的意识。你必须充分发掘组长的潜能和优势,一般有个性和较独特路子的人
都有能力和创造力,能保证项目的成功。因而在给予他充分信任的基础上,做好你的监控与管理,确
保你能充分把握局势。
然后是你要花大力气与其他成员沟通,说服他们以组长的工作为中心开展配套的各项工作。至于组长
自己不善于沟通的问题,由你来做好协调与沟通,确保项目的协调运转。对于其他非骨干成员有情绪
的,必须坚决处理,确保整个团队有效协调运转。
最后要说的是,你要有较高的管理能力和沟通协调能力才能玩转这个项目,否则你会输掉这个项目。
这种项目你的结局是悲剧性的:如果成功了,你会因为要使项目成功而保一个组长、得罪一批组员而
受到较多的非议,但你不这样做项目成功可能性太小;如果项目失败了,你将承担这个苦果,而你的
前任早就逃避了责任,而与你一起承担责任的可能只有你和组长及其他有团队精神的组员,而指责你

第 357 页 共 756 页
第 4 章 沟通管理

的人可能会包括你的上司、团队的组员和其他利益相关者。总之,你要做好里外不是人的准备!

·适应新的环境,慢慢改善!(2008-07-16) [作 者] albertsu [公 司] 大众电脑苏州

我注意到了几个问题点:
1,作为新的项目经理加入团队;
2,长期的研发项目;
3,组长个人英雄主义的工作方式,你跟他沟通陷入僵局;
4,团队成员积极性不高;
5,项目新开始的部分很难控制?

1.作为新的项目经理,手段可以多,但身段一定要软,贴近团队成员。
2.研发就不可能是闭门造车,所以,与多个部门的协调沟通,有效信息传达必不可少。个人英雄主义
不可取。
3,项目顺利完成为第一目标,其次是以组长的个人英雄主义为主还是以团队为主。国内教育培养出
来的员工,大多数缺乏团队意识。这是客观的。通过主观的多次沟通不能达到要求,那么就换别的途
径。不妨从客观要求入手,试着改变组长的工作习惯。让时间紧迫,这时组长无法全部完成所有工作,
那可以建议组长分摊很多事情给其他成员,并给组长作如何授权的培训。如果需要创新,头脑风暴,
就有必要引入其他人参与讨论。
4,先确保团队成员能有效参与项目运作,能提升他们个人能力经验。那么,提高他们的积极性不是
难事。
5,项目很难控制?我不晓得。

·确定流程、重视沟通(2008-07-16) [作 者] 瞿晓华 [公 司] 广东同望

在本案例中注意到以下几点:
1、项目经理是新进公司;
2、接手了一个长期项目;
3、项目组长英雄主义作为,影响了项目进度;
4、团队人员出现了积极性不高。
现在我们来理下思维:
1、由于项目经理新进公司,必然在人事和业务方面认识上存在偏差,此时切忌急于表现,首先要对
公司的结构、人事安排有充分了解,对上对下都进行沟通;
2、公司安排长期项目给该项目经理,还是存在考察的成分,毕竟可以进行长期观察项目经理,并对
项目发展影响不大,所以项目经理如何自处,这里也不用多说了;
3、对于组长的英雄主义,其实在好多团队中都有可能出现,毕竟人的性格不同,而且也不排除对项
目经理存在排挤心理,所以处理这种刺头,首先不要放弃沟通,在言语和行为上对他要有足够的尊重,
毕竟是老员工,另外也不能放任他,建立项目经理的一套工作流程,当然是行之有效的,对其进行制
度上的规范和促进。
4、团队人员出现的问题,不能完全归咎于组长,团队的核心是项目经理,如果把队员的问题归咎于

第 358 页 共 756 页
第 4 章 沟通管理

组长,那是不负责任的看法。项目经理应该多与组员沟通,了解他们的想法,听取他们对于新制定工
作流程的看法,从而来更好的执行流程。
如何管理好项目,这个帽子扣的太大,案例中也提出了项目发展是基本稳定的,所以现在急需解决的
还是人事问题。

·融入团体,有效沟通,逐步改进(2008-07-15) [作 者] aaron [公 司] 公司

首先了解项目运作的情况:项目组人员,关系人的沟通,管理方式;项目组目前的人员架构,项目的开发
方法; 其次要解决好和项目组长的沟通,了解其优秀的一面,去除其个人英雄组义的一面,由于多次沟
通无效,可以先按他的方式工作,后续逐步改进; 再次就是形成一个统一的开发计划,以此来规范项目
组长的行为,使之朝团队合作方面发展; 最后,一切都没法更改可通过公司去协调他的工作.

·融入团队(2008-07-15) [作 者] twz [公 司] 铁路运输

1.由于项目经理是新进入公司的,与原项目团队的磨合应该是不足的。项目经理应该尽快融入该项
目团队,尤其是与组长多沟通,多了解组长对项目的看法;
2.项目经理与组长间在开发方式上产生了冲突,项目经理要仔细思考自己的方式是不是存在问题?
组长采取他所认可的方式有何原因、背景?建议找组长出去喝茶聊天,加强沟通,采取双方都都接受
而又不影响项目进度的方案;
3.项目经理的主要工作在于沟通,在这方面一定要加强,要争取让项目团队从心底认可项目经理。

·了解情况,因地制宜,有效沟通(2008-07-15) [作 者] 杨海燕 [公 司] 铁路运输部门

1、了解情况。
对于中途接手的项目,其动作方式、人员构成、团队思维、沟通方式等都已有定型或初型,所以项目
经理应首先充分的收集了解掌握项目的各项信息,在此基础上结合项目管理模式和方法,充分分析此
项目,找出优劣,提出改进方案方法。
2、因地制宜。
新改进方案方法(例如要改变组长工作方式的方案)的提出,应充分考虑到本项目、人员、组长等特
点,最好在与人员特别是组长通过非正式沟通,广泛收集信息后提出。
3、有效沟通。
a、对于本案例(有主要成员还处在非团队状态下),首先,经理要认真分析,制定沟通管理计划,
结合人力资源管理和团队建设等方面知识,通过设立作战室、统一标志等努力营造团队氛围;在此基
础上按照项目管理--沟通和团队建设等知识方法进行有效管理。
b、注意沟通的方式和原则。牢记沟通的黄金定律:用别人喜欢被对待的方式来对待他们,求同存异,
努力营造双赢局面。
c、非正式的沟通更有利于关系的融洽,采取对方能接受的沟通风格。

·中途接手项目的人员沟通问题(2008-07-14) [作 者] 曾鑫 [公 司] 亿泰科技

第 359 页 共 756 页
第 4 章 沟通管理

让组长提出开发模式,再对其不妥的地方进行沟通协商,争取达到大家都认可的方案。

·建立有效的沟通(2008-07-14) [作 者] Ting [公 司] 上海公司

他的具体工作方式是什么样的?能描述一下吗?对他的方式要系统分析一下。
我觉得对于这个项目组长的工作方式不能全盘否定。从他的开发方式中抽取合理的部分,首先肯定他
的成绩,然后在给予建议,慢慢形成制度和习惯。比如:引进 CVS,辅助协同开发。
其实开发方式是小问题,工作态度、内心的想法是比较重要的问题。你多次沟通,没有摸清他的内心
想法吗?你也要注意沟通的有效性。
你认为这种工作方式影响了人员积极性,不能融合于团队开发工作中。 项目组成员除了技能外,更
重要的是品德。还是摸清根源,再找其他项目组员谈谈,了解一下对这个组长的情况,对症下药!

4.6 如何推倒项目组内的“部门墙”?

如何推倒项目组内的“部门墙”?

[姓 名] 项目管理者联盟 [单 位] 项目管理者联盟 [邮 件] member@mypm.net


[所属行业] 综合应用 [所属主题] 项目沟通管理 [发布时间] 2008-6-3

【案例正文】
项目经理张松最近因为项目工作,需要与相关的 9 个部门沟通,得到了几个部门的大力配合,
但也体会到“部门墙”的根深蒂固。

他这次感受到的主要有三种形式:

1、表面上积极,实际上得过且过。在预约中,A 部门积极相应,在沟通时,他们也承诺积
极配合,但是谈到具体实质工作时,特别是需要其部门做出些改变或工作时,他们就会找到
各种听起来合理的理由。这类部门是在不影响自己利益的前提下还算配合,但是要想让他为
了公司利益而多承担一点工作或自残一点,是很难办到的。在沟通中,项目组与 A 部门接洽
感觉是满意的,A 部门表现和承诺的都比较积极,但是后来项目组提出了改善方案,对公司
整体明显有利,会大幅降低公司工作量,但会少许增加 A 部门工作量,A 部门对此也是非常
清楚的,但 A 部门轮番找各种理由排斥。这种情况的主要原因是完全以部门利益出发。

2、能推就推,能拖就拖。很多部门会以各种理由推托沟通,从内心就不愿了解更不愿配合
部门外的非常规工作。项目组一周时间邀请 B 部门经理 9 次,但均遭到各种理由的婉言谢绝,
结果一周后,他又出差了。项目组没办法,就要求与其召开电话会议,其没有办法,最终接
受。但是效果难以达到预期目的。

第 360 页 共 756 页
第 4 章 沟通管理

3、在沟通前就已经有了自己的立场,不予配合。很多部门在你还没开口前就把你定位为给
其布置任务、寻找其工作漏洞的角色,所以一开始就抱着如何逃脱责任的心态。在再三邀请
下,终于约定了 C 部门,在开始沟通时,虽然项目组首先明确了沟通目的和前提,但是 C
部门似乎一点没有理解,完全是从自己逃脱责任的角度出发。例如,项目组问其能否从财务
的角度考虑分公司总经理应该关注哪些工作,“我们只管提供数据,分公司总经理应该做什
么,那是你们的事情”。表面上大家似乎都没有什么错误,但是这种软性的不配合总让张松
感觉劲用在了棉花上,影响项目的进度。

项目组只是一个松散的临时机构,作为项目经理张松并没有太多的权力去制约他们。请问,
面对这些部门的不配合,张松该如何去做?

【相关分析】

·错误命题(2008-08-14) [作 者] 四季风 [公 司] 兴库建设投资有限公司

第一、部门墙的存在说明各部门并没有认可你这个项目经理。项目经理也是代表项目部利益去沟通的,
部门代表部门利益是合理的;项目经理的首要职责是把利益相关者整合起来,绝对不是要其他人服从
你的利益选择;面对压力选择推到部门墙的提法,反映项目经理仅仅是技术人才,其管理、领导才干
还需要得到更多的锻炼。
第二、上司的缺位反映公司核心领导对部门与部之间的观望。或许是检验你处理实际问题的能力,或
许是对你的磨练,也可能是你平时过于骄傲。总之领导没有指点,也没有干预,值得项目经理本人深
思,领导肯定是对此格外关注的!
第三、请尊重差异,请学习社会心理学、大众心理学、组织行为学,并将这些在实践中演练体会,必
将对你大有帮助!

·笨办法(2008-07-21) [作 者] xieshiling [公 司] 济南科技有限公司

1、找到需要配合的部门的利益点,如果有,放大到极致,并提供给他们相应的项目的一切信息;他
们自己也进入分析中,希望获取对方的更多信息;
2、开好协商会议,并商定是否可以把项目进展情况,通报到项目的所谓人员,所谓的邮件满天飞,
并且邮件抄送到能够管理他们的人员,这个方式,需要事先在协商会议上得到承诺,并有会议记录;
通过隐形的力量来推动;
3、最笨的办法是,和上级求助,并提出你的分析情况,上级如何行动是上级自己考虑的事情了。

·掌控关键点(2008-07-08) [作 者] lydia [公 司] neau

首先,张松被授权是问题的关键。从这个案例中,可以看出张松并没有完全得到相应的权限,工作起
来自然会受阻;
其次,要明确项目经理的重要角色,并不是一味地寻找 9 个部门,应当明确各个协调部门的对口负责
人,并授权之;
再次,沟通不是嘴上说,要辅之于实际行动,无效沟通只是浪费时间而已,加强关键环节沟通的有效

第 361 页 共 756 页
第 4 章 沟通管理

性。

·假命题、错误命题,为什么还有这么多人去捧臭脚?(2008-06-30) [作 者] daijiangbao [公 司] 深圳
市大视野-超越项目混沌

这类《推倒”部门墙“》的假命题、错误命题,都是项目管理的表面现象,怎么还有不少人往里面滑?
顺着错误的方向爬,怎么还都说的一套套的,这是个值得思考的问题

·明确责权利,资源整合,大力沟通,全力执行(2008-06-23) [作 者] 李大为 [公 司] 广东移动

这种部门间沟通的 CASE,稀松平常,张松现在只是和三个部门沟通就碰到这样的问题,接下来可能还
要和剩下的六个部门沟通,那他岂不更头痛。其实,我们需要在沟通中把握好以下四个点:
一、明确责权利,也就是说分析项目的职责、权限和利益,看看这个项目和 9 部门之间存在这三种关
系的哪些方面,最好可以列出具体的明细表。
二、资源整合,项目要开展,少不了的就是各种资源,如何在项目开展初期就能够整合优化现有的资
源,这对项目的成功是非常重要的。
三、大力沟通,这主要是得益于我们很多人的懒惰心理,大家都觉得事不关己,所以我们就要催,不
遗余力的催,首先要做的就是让他知道整个事情,再接着让他反馈信息,最后他会自觉的执行。
四、全力执行,责权利明确,又有资源支持,而且沟通无障碍,那接着全力执行就 OK 了。

·推倒个屁,能推倒还要你项目经理干什么?(2008-06-20) [作 者] daijiangbao [公 司] 深圳
市大视野-超越项目混沌

这是本身就合情合理的事情,项目经理如何让各个相关部门参与到项目中是关键,这才是项目经理该
干的事,看你项目经理的本事了。这才是项目管理的难点和魅力所在。
小心这个墙推不倒,就是推倒了也是砸自己的脚,不要推。

·个人建议(2008-06-16) [作 者] 纪文宝 [公 司] 西北工业大学

首先,A部门在改善方案中表现说明了变化的问题.少许增加 A 部门工作量的评级标准是项目经理的
评价,因此建议他应该深入了解一下深层次的原因.任何变动相对于不同人的感触是不一样的,乃至
是否增加相关的成本以及对未来的影响,这都需要项目经理注意.项目经理想获得职能部门的支持或
者资源就应该首先考虑一下职能部门的利益以及影响,采取相关措施--增加成本等.
其次,B部门推托沟通,从内心就不愿了解更不愿配合部门外的非常规工作.建议项目经理绕过
该职能部门相关的职能.如果这样部门多了,就一定要寻求企业高层级别的支持.如果仅仅是一两个
部门出现这种情况,建议寻求 out sources.
第三,C部门已经有了自己的立场,不予配合.这个问题属于项目前期工作问题,准备阶段工作没有
做好.项目经理要么绕过该部门,要么就寻求更高级别的支持.

第 362 页 共 756 页
第 4 章 沟通管理

·多管齐下(2008-06-16) [作 者] 陈罡 [公 司] 北京

说实在的,这种情况在很多公司都存在,很多人都不愿意把麻烦留给自己,总喜欢踢皮球,这种情况
在所难免!(哈哈,有时间我也这样的)

个人建议:
1、加强沟通(很多问题都是因为缺少沟通)
2、需要高层领导的支持(最好能一起开会明确问题)
3、每个部门的考核都和该项目的执行情况挂钩(每个人都利益相关,能不努力么?)

·如何推倒项目组内的“部门墙”(2008-06-15) [作 者] ghs [公 司] 爱家

这一类的人比较难对付,表面很配合,实际不配合,又不能拿上级领导来协调,领导也没法。
上策:找出对他们部门有利的一面,慢慢切入。
中策:跟他们部门领导搞好私人关系,凭个人魅力来影响他们,感化他们。
下策:先晾一边,等其它部门工作差不多,再找他们。
下下策:换部门经理,或者合并到其它部门。

·一个菩萨一个庙(2008-06-14) [作 者] chow king lam [公 司] beria consultants limited

该叩头的叩头(服从有关规定),该供祭品的供祭品(打好关系),要是始终不行,就只好往大庙烧香(向
上级反映).

·注重沟通(2008-06-13) [作 者] wangjinju [公 司] 宁波

1.从公司全局的利益出发,把该项目存在的问题,需要解决的问题,包括与 9 个部门的协调,向上级
主管领导汇报,得到领导的支持。
2.建议开总体协调会议,准备各项资料齐全,以主管领导主持召开部门协调会,明确各部门的分工、
职责以及配合事项。
3.强调以公司利益为重,部门利益服从公司利益。

·完善项目管理(2008-06-06) [作 者] zhuangqm [公 司] sdrcu

1.把该项目存在的问题,主要是项目部门协调难的问题,向上层领导汇报,得到上层领导的支持。
2.由上层领导出面召开部门协调会,明确各部门的分工、职责以及配合事项。
3.强调以整体利益为重,部门利益服从整体利益。

第 363 页 共 756 页
第 4 章 沟通管理

·要学会用正确的方法沟通(2008-06-04) [作 者] 张茂峰 [公 司] 深圳市中海工程顾问有限公


这种情况我经常会遇到。所以我很明白张松的感受。下面我就谈谈个人看法。
首先,在项目启动会时公司高层要在场,要明确各个部门配合的工作职责和分工界面。让他们知道在
项目过程中他们要配合做哪些事情。最好是能够让他们指定某个人参与配合。
第二,项目部最好指定对应的接口人。有到是阎王好说话,小鬼难缠。搞好群众关系(哪怕在这方面
投入点经费也没关系)。正常情况下各配合部门不会为难你们。就怕他们拖。本来要 2 天完成,他们
拖个两三天,那你也没办法。所以要搞好下面的工作。
第三,工作要透明化。你要将每天的工作情况 CC 给各配合部门,让他们知道项目目前的进展,明白
他们需要配合的工作什么时候开始准备,什么时候要做。
第四,我最不赞同的就是无休止的开会,好象开始成了唯一沟通的方法似的。现在的沟通方法很多,
我建议正常情况下还是邮件+电话的方式。这样既有效率又不占用别人太多时间。每天公布项目进展,
各部门配合事项等等。节约别人的时间也是节约自己的时间。
第五,当项目发生一些列变更时,也就这种情况下,各部门推委的情况比较多。我觉的有必要开次项
目会议请公司高层和各配合部门参加。坦白解释项目变更的原因、解决方案及各部门需要配合的工作
和要求。并在会议上解决。个人觉的这种情况不需要腋着也不需要藏着,把他摆在台面上让领导知道
并分工解决。这样各配合部门有问题他们也会在台面上提出来。有高层领导在肯定能够解决。不要什
么事情都自己来是搞不定的,高层资源也要合理运用。
第六,有时候制定方案还是要根据实际情况来指定。不是纸面上的最优方案就是最时候你们的方案。
要根据公司的实际情况来制定。在项目过程中相对资源也是很丰富的。各部门需要你们帮忙做一些事
情,只要不耽误工期就要多帮忙,首先要建立一个良好的形象。
第七,还有一种情况,就是需要别的部门配合,但是这项工作风险比较大,一不小心会对公司产生很
大的经济损失。这样的情况下,配合部门会因为担心责任而推委。这是项目经理应该即使了解情况,
调动手上的技术力量,帮助他们。这样才能把事情做好。
沟通是一件很简单但有很难的事情,需要项目经理有着明锐的观察力和无比的智慧来发现问题和解决
问题。

·自身问题太多,不要一味指责别人(2008-06-03) [作 者] teresa [公 司] 广州

疑问:
1、项目是否召开启动会议,邀请各部门相关负责人及总经理参加,是否得到高层对项目的承诺支持?
有时候,上方宝剑还是有用的,剩下的就是 PM 不懈的努力和沟通,首先就是要明确彼此的职责和范
围。

2、对于各部门需要负责的部分是否有明确的范围和职责?
不要模棱两可划定彼此的工作范围,每个部门都有自己的事情,期望别人来配合,就需要明确的划分,
而不是人家主动去替你想问题,如果没有这部分,人家当然是越少作越好,毕竟不是自己的本分工作。

3、是否果过多会议,不一定要人家参加,指定人员或者将各类进展和通知抄送负责人及高层?

第 364 页 共 756 页
第 4 章 沟通管理

没有明确主题的会议,或者太多可去可不去的会议,其他部门经理也许判断没有必要参加,这种情况
PM 需要判断,不要什么会议都邀请别人,一定确认非常有必要再邀请别人参加,如果人家没空,是
否可以约定指定相关人员参加,然后就需要商讨的内容约定一个时间由哪个部门回复。

4、项目经理的沟通方式和路径不通畅?
涉及多部门,PM 用在沟通的时间一定会很多,需要讲究方式和方法,而且在出现问题时,需要先反
思下自己哪里地方没做好,没有做到,自己能够过做什么才能让别的部门很好配合,而不是站在自己
的角度去指责其他部门。固然项目是公司的,但是毕竟 PM 全权负责,他需要想办法让项目顺利进行,
发现问题解决问题,自己的能力解决不了就上报,请求上司介入协调。

4.7 项目中多种沟通不良的情况如何解决

项目中多种沟通不良的情况如何解决

[姓 名] zjh [单 位] 电信 [邮 件] zjh1979@gmail.com
[所属行业] IT 软件 [所属主题] 项目沟通管理 [发布时间] 2008-3-14

【案例正文】
案例背景:项目经理当初匆忙中途接手后,和项目团队进行问题分析和启动,其中由于:
(1)项目职责前期还不是很清晰,
(2)前期项目问题分析没有深入到根源,发现细节性问题很多且时间非常急迫等原因

在以下 4 点情况下,直接进入实施阶段:
(1)工作任务分解很粗,在分解过程中也发觉团队成员无法分解出来;
(2)项目管理流程及制度等没有进行确定;
(3)项目团队人员已经被他人分配出去现场;
(4)当然,项目经理也没有意识到项目管理特别是内部沟通工作的重要性(大部分时间是远程
实施)---重点放在梳理外部沟通,以扭转以前的不好影响。

在项目实施过程中,存在很多问题,表面层现最严重的是沟通方面,举例:
问题 1、信息失真:
(1)现场施工的员工说任务已经完成,但实际上当其他员工到现场去进行客户培训时,发现远
远还没有完成,例如,应用只安装了几台,客户基本没有将系统用起来,系统上存在 BUG 等很
多细节问题。
(2)口头沟通,发现代码里面有部分没有改动,前期通过口头已经进行过说明;
问题 2、进度失控:部份工作进度已经不完成的情况下,没有及时反馈问题,在周报里面较粗

第 365 页 共 756 页
第 4 章 沟通管理

的体现一下但被忽略等;
问题 3、任务遗失:
例 1,员工电话汇报较为重要问题内容,但是由于手头工作缘故,一时没有注意,后期客户直
接对该问题没有处理很大意见;
例 2,口头分配的任务遗失;
问题 4、口径不一:一件事情,信息内部没有共享,团队成员对外沟通传达的错误信息;
问题 5、重复劳动:同一个接口测试文档,两个员工每人都分别写测试并都提交了一份接口文
档给客户;
问题 6、及时反馈:丽水局方反馈我们实施人员没有及时反馈前期提交的遗留问题。

请教专家:
(1)项目中出现的沟通问题如何避免,特别是信息失真情况?
(2)如何确保良好的沟通?如何建立良好沟通体系?
(3)系列问题的根源是什么?

【相关分析】

·原因很多,感觉需要抓住一点(2008-07-21) [作 者] xieshiling [公 司] 济南科技有限公司

造成的原因很多,但是如何开展,只能是先立规矩,立规矩是否能够得到执行呢?也难!个人认为首
先的办法是找到最容易处理的突破口来推进,让大家认识到这样做有好处,能够得到团队的认同,在
开好会,让大家统一行动。

·多沟通、勤思考(2008-05-13) [作 者] 苏志敏 [公 司] 时代

其实很多项目都存在上述问题,用户有想法、领导有想法、职员有想法,这些问题都丢给了项目经理,
他是无法逃避的,只有做好多方面的沟通,尽量满足项目的主要需求。
项目管理靠制度,即使制度不合理也比没有制度强。
现在做项目口头指令太多,会造成下面的职员无所适从,反而有借口不做。多思考多检查,确定当前
的首要问题,首先确保解决主要问题。

·沟通效率低下(2008-04-18) [作 者] sandiego [公 司] doeuniversal

由于案例所给是中途接管的项目,情况比从头介入的情况复杂。
个人认为可以通过以下步骤逐步改善:
1、理清思路,明确目前的工作重点。
2、在明确重点前提下,集中有限资源解决关键问题,树立团队威信,增强凝聚力。对于中途接管的
项目,很多成员会因为空降或其他原因产生不服,只有真正能解决问题,有所作为,才能服众。
3、根据案例中所提及的问题,大部分都是由于沟通手段或记录随意性太大所导致,可以通过采用信
息管理系统的方式,要求团队成员及时通过平台记录问题、汇报问题、反馈问题的解决状态。

第 366 页 共 756 页
第 4 章 沟通管理

4、在保证能解决实际问题的基础上,逐渐解决内部消耗,慢慢固化工作流程、沟通级别方式和规范,
最终形成有效的经验为下一项目借鉴。

·项目经理疲于应付(2008-03-27) [作 者] zjh [公 司] 电信

没有全面细致的计划及实施方案,仅有里程碑式的粗略计划,不足以指导项目执行和控制,对项目的
进度情况难以判断。计划不细致,不全面,资源难以落实,成本不易控制,沟通也只能停留在表面问
题上,更多的是发现问题时才知道沟通什么,往往会使项目经理疲于应付。
==网上的这段话,比较深刻的描述了项目的状况

对于本项目我们内部也进行了总结,主要对问题有以下认知:
对于信息失真问题:
(1) 新方向、新业务、新领域情况下,信息失真一般都会存在,很多细节问题都会存在无法避免,
除非做到专家级别能够综合分析、预见几乎所有问题;
(2) 只要存在沟通,就有可能会出现信息失真;
(3) 解决:我们一定要把问题定位到位,分析出问题出在那个环节,从而知道下一步该怎么办:是
出在需求?设计?开发?等这是关键。问题需要转换成问题出在哪里,信息失真在那里;
(4) 避免:比较难避免,但可以减少影响程度,特别是对于新方向、新业务、新领域情况下,建议
将“信息失真”作为一个风险,对关键任务进行重点预防。

对于信息沟通交流:
首先,从理论层面进行分析---沟通模型(图片没法传);
其次,沟通要注意两大基本原则:
如何确保沟通中信息完整?
1、信息发送者需要保证已经被信息接收者接受并理解;
2、信息接收需要反馈已经接收到信息并正确理解。
第三,更进一步:最根本的问题是规范问题。
对于在项目中经常遇到的问题,需要及早制定规矩,共同执行
越早越好;
多迟都不晚;
全员通告。

·仓促接手,贸然踩油门---沟通能力乏善可陈(2008-03-26) [作 者] 陈万春 [公 司] PETL

我是做工程项目的,一点意见,仅供参考(希望讲的不是外行话):
(1) 中途接手的项目,是一个烫手山芋---接手者第一步做的是尽可能的了解全部情况,而不是贸然
踩油门冲刺,头疼医头, 脚痛医脚---“项目前期工作”很不到位,感觉就像大象进了瓷器店-----感觉接
手者操作项目的方向感有严重偏差,不适合做项目经理;

(2)接手者没有项目经理应该具有的基本沟通能力---有人讲“项目执行的过程就是项目沟通的
过程”,在这个案例中得到验证;

第 367 页 共 756 页
第 4 章 沟通管理

沟通需要项目的实际历练!这也是工程项目的项目经理,一般要十年以上有效现场工作经验的一
个基点。

有些巨型工程项目的团队中,配置有专职的 coordinator!

·communication(2008-03-25) [作 者] albertsu [公 司] FIC(Su)

我仍然坚持我的观点。
楼主需要提高自身的沟通技能,和整个团队的沟通技能。

以下是我的浅见,供参考。
1. 贵公司您的上司对人的培养在流程有漏洞。
可能您是做了一个案子,做的不错,然后被安排到这个新案子的。但他没有了解到您的沟通能力,或
者没有其他人选就安排您顶替。我觉得比较好的流程是,他手上有关于你的比较科学的测评,再决定
1.招空降兵,2.您一边管理,他也抽空多管一些,3 一边培训,一边让您去担当经理。

2.按结构来说,您的应该属于矩阵型的组织结构。这个带来了协调上的问题和冲突。
(3)项目团队人员已经被他人分配出去现场;
这个是资源上的冲突。作为项目经理要处理这种冲突带来的风险。

3.沟通中有常见的很多错误,流程中也常有的。
比如
(1)项目职责前期还不是很清晰,
(2)前期项目问题分析没有深入到根源,发现细节性问题很多且时间非常急迫等原因

可能有几个方面改善:
由于您的工作伙伴提高专业能力,或者请专家开会;
尽力创造一个适合各位发挥的氛围;
采用特别的方法和工具;
提升工作伙伴的沟通能力;
会议时间紧迫,预先准备议题,只讨论重要问题,细节性问题做记录,会后补充并以文件形式发送。

(1)工作任务分解很粗,在分解过程中也发觉团队成员无法分解出来;
(2)项目管理流程及制度等没有进行确定;
当面沟通时,低效沟通的工作伙伴往往
1.带着感情色彩,2.不会换位思考,3.不能用对方的话表达,
4.不注意用眼睛去观察,用感情去沟通,5 不能跟上节奏,6.缺乏尊重,7.不重视自己的肢体,语言
表达能力。
这是一些人在工作中做的不好的地方。

4.(1)现场施工的员工说任务已经完成,但实际上当其他员工到现场去进行客户培训时,发现远远

第 368 页 共 756 页
第 4 章 沟通管理

还没有完成,例如,应用只安装了几台,客户基本没有将系统用起来,系统上存在 BUG 等很多细节问


题。

原因是不少国人的教育,文化背景,不重视沟通。光做不说,做完就行。我发现,这种常人的习惯其
实根植于公司的企业文化。
日本人说的好,“不去现场就没有话语权”。为了破除不好的习俗,看您的能力了。目前,我的探索
也就到此为止。我还要不断加强自己能力。因为我们公司也碰到这种情况。

5.这个论坛有很多关于沟通的精彩的帖子和教程。
以它为自己的 benchmarking,学学。我最近采用换位思考的方法,从正反两方学习经验和方法。学
习需要时间的积累。多了就是经验了。

欢迎参与探讨。

·项目沟通与冲突管理(2008-03-21) [作 者] Kevin [公 司] 长江大学

一、项目沟通:
遵循原则:准确、及时、有效。
1、沟通方式:
正式沟通与非正式沟通,上行沟通与下行沟通,单向沟通与双向沟通,书面沟通与口头沟通,语言沟
通与体语沟通。
不同的沟通有不同的效果,而且应该针对各种情况来实施。
2、常用沟通方法的特征
(1)、会议沟通:可以解决复杂问题,澄清谣言,传达重要信息。
(2)、E-mail 沟通:简单问题小范围的沟通,传达非重要信息,澄清谣言。
(3)、口头沟通:彼此之间有误会时,办公距离较较近时。
(4)、电话沟通:办公距离彼此之间较远。
3、沟通模式
(1)、链式沟通模式:相当于纵向沟通。适用于规模较大,实行分层授权控制的项目信息传送及沟
通。
(2)、轮式沟通模式:加强控制、争取时间、抢速度的一种有效方法和沟通模式。
(3)、环式沟通模式:可以提高团队成员的士气。
(4)、Y 式沟通模式:这种模式层次较多,容易造成信息失真。
(5)、全通式沟通模式:一个开发式的系统。是每个成员之间都有一定的联系,彼此十分了解,民
主气氛浓厚,合作精神很强的组织一般采取这种模式。
二、项目沟通计划编制
1、沟通需求分析
2、信息发送
3、工作汇报方式
4、管理收尾

第 369 页 共 756 页
第 4 章 沟通管理

三、有效沟通的方法和途径
1、沟通要有明确目的
2、提高沟通的心理水平
3、善于聆听
4、避免无休止的争论
5、保持畅通的沟通渠道
6、使用高效的现代化工具
四、项目冲突
管理的三个阶段
首先是诊断,其次是处理,再次是项目冲突处理结果
处理方法
1、回避或撤退
2、竞争与哦消除
3、调停或消除
4、妥协
5、合作、正视和解决问题

以上是从比较有影响力的人士借鉴来的,敬请借鉴。

·觉得很形象(2008-03-20) [作 者] 王话 [公 司] 河北大学

看到过好多类似的情况,只是似乎还没看到过专家解决的方案,期待告高人。。

·重复劳动(2008-03-20) [作 者] 李先生 [公 司] 深圳

原因:1:分工不明确;2:接口太长(交叉东西多);
动作:细化分工,实施项目管理工具;

·计划粗糙,缺少沟通(2008-03-19) [作 者] 李智攀 [公 司] 上海交通大学

看整个项目,管理漏洞多;组织结构不合理;资源紧张或利用不合理;责任分工不明确;任务分解粗
糙,没有定义实施过程中的里程碑目标;项目经理没有做好协调沟通工作,疲于应付所谓的外部沟通.

对于项目经理,没有做好前期的准备工作,没有制定详细的范围说明书,任务细分,明确责任;没有
周密的工作计划,带领一堆伞兵。还错误的把重点放在外部沟通,相反的却远程管理项目团队,根本
不重视内部的监督与组织协调工作。

第 370 页 共 756 页
第 4 章 沟通管理

对于信息失真,是因为员工的责任心欠缺,没有凝聚力,人心涣散,没有动力,没有激情做项目,大
家感觉很多事情凑合一下,应付一下就行了,反正也没关系。这是项目经理的责任,一个合格的项目
经理,应该在接手项目一开始就组织全体人员开会,大家一起讨论,提出想法,并倾听这些意见来制
定合理的计划日程,明确分工、责任,并鼓舞,激励大家,让人们不是消极被动而是积极主动的执行
任务。

良好的沟通,项目经理还要定期召开阶段总结报告会议,以了解项目的进展情况,进度是否按照预期
计划进行并做出相应的调整,并对此阶段出现的问题,弄清楚原因,问题出自哪里,出自谁。指出以
后要注意的地方,充分调动现有的资源。同时,项目中的每一个环节变动,都在记录并编入文档以备
查询。

·项目中多种沟通不良的情况如何解决(2008-03-19) [作 者] 乐祥文 [公 司] IAT上海

1.任务分解,责任划分明确,以书面形式发放给项目组内部和客户,让每一个人都明确自己的职责以及
配合人员的职责.
2.定期举行项目例会,总结项目进度,对故意隐瞒错误的严惩不怠,同时及时对项目的风险进行评估,
调节项目分配或者寻求更加充足的资源.

·项目中多种沟通不良的情况如何解决(2008-03-15) [作 者] 郭先生 [公 司] 石家庄泰顺电子

1 对项目的进展要实行有效的控制,根据各项目的具体情况制定一套项目文档,如:项目任务书,项
目的约束文档,项目进度情况表等等。俗话说:磨刀不误砍柴工
2 对于人与人之间的沟通是每个项目经理头疼的事情,但个人认为:沟通的前提是真诚,沟通的动力
是激励,沟通的保障是约束 ... ,
3 从案例表面看问题的根源是缺乏沟通,但实际是项目经理对项目的控制力不够。项目启动时没有的
深入分析,缺少项目的计划,执行过程中项目组成员缺乏沟通,对项目没有形成有效的控制,收尾时
诸多发现问题。

·细节是魔鬼!(2008-03-14) [作 者] zjh [公 司] 电信

非常感谢各位专家的分析,特别是 albertsu。

严格来说,在这之前我并没有担任过项目经理这一角色。但在接下项目的背景之前是由于公司内部的
项目管理学习气氛下积累并自学了项目管理方面的诸多内容。

在项目过后,我们项目组内部,公司内部都曾经对项目进行分析,但显然还是没有将“问题的根源是
项目经理缺乏沟通能力和经验”这个原因分析出来。

个人认为到目前为止,包括我自己的总结分析及团队的总结分析等较多对案例分析里面,albertsu

第 371 页 共 756 页
第 4 章 沟通管理

的分析的问题原因是最深入的然,还请专家继续深入分析。

在接下来我将会将自我分析及内部分析贴出来,虽然可能没有专家们分析的到位。

·沟通与记录(2008-03-14) [作 者] 宁馨紫菊 [公 司] 帅达科技

楼主提出的问题,我有下面的一点看法,个人意见,愿意交流。
首先,楼主是中途接手,那么发现工作任务分解很粗,管理流程制度没明确等问题,就应该及时在项
目团队里提出来,及时的针对一开始就发现的问题进行解决,这样才保证后面的错误越来越多,越来
越大,导致无法挽回,任务失败。
再次,如果有团队人员已经派往现场,那么要及时跟踪现场情况,要求现场人员做好现场情况记录。
往下:在实施过程中,很明显,没有将任何一项工作做好记录,一切都是口头,当然事后查无对证,
大家互相推卸责任,说谎话。
楼主应该对项目的及时跟踪,问题跟踪,事件记录以及有效沟通上多做努力。

·communication(2008-03-14) [作 者] albertsu [公 司] FIC苏州

先扔个砖,等玉砸过来。
从文章就可以大致猜测作者的能力,公司的流程很差。

细节。魔鬼存在于细节之中。沟通是项目经理最重要的个人素质之一。能够灵活采用不同沟通方式,
经理的成熟,经验就起了作用。

问题的根源是项目经理缺乏沟通能力和经验。

东西太多了。只举个具体例子说明一下。
WBS 粗糙,可能你营造的会议环境,不利于人们放开来说话,搞成一言堂。不少国人都有一种特性,
当面无话,背后鬼话。为了打破这种不好的文化,经理要主动问话,“某某,您是 XX 方面的权威,
您在 XX 很有能力,请说说您的看法。”“为了项目不失败,请说说您的观点,还有什么要补充的吗?”
当面沟通最重要的是让双方互相了解所想表达的东西。沟通能力强的人,能了解到对方有没有明白自
己的话。但人经常会健忘的,所以,口头沟通必须以书面记录为补充,并发给相关人员。

碰到这么多问题,难道斑竹没有自我检讨的能力吗?
到网上寻求现成答案。建议你去培训一下自己的沟通能力,并对项目团队做个沟通培训。再学学
ISO9000。
我们即使给出了,只是印象很浅,短暂的,最好的课程是自己总结出来的。

第 372 页 共 756 页
第 4 章 沟通管理

4.8 如何和刁钻的客户进行沟通?

如何和刁钻的客户进行沟通?

paques environment
[姓 名] 韩良 [单 位] [邮 件] hanliang1978@163.com
company
工程设计
[所属行业] [所属主题] 项目沟通管理 [发布时间] 2008-3-3
安装

【案例正文】
本周我的绩效访谈,经理问了我这样一个问题:如何和刁钻的客户进行沟通?我的回答是:
一、如果是为了贪图小利,可以满足他们的要求,毕竟我们有了好的沟通效果才有更高的获
益。二、如果是因为我们的技术不能过关,不能满足业主严格的要求,妥协或者认输不失为
一种良策。

我想到的情况可能太窄,大家怎么想,怎样处理呢?

·刁钻的客户是最稳定的客户(2008-08-12) [作 者] dajundalao [公 司] 暂时保密

刁钻的客户一般是有品位的客户,如果你做得足够好,他们是你公司和你的业务的广泛宣传者,
也是你最踏实的客户。
刁钻的客户一般不“移情别恋”,他们之所以刁钻,都是追求品质的完美,同时,他们也会因此形成
对某一产品或服务的依赖。
跟刁钻的客户沟通,最好的办法是先倾听他的见解或要求,根据他的见解或要求来替他选择合适
风格的产品或服务,让他满意。

·区别对待(2008-08-11) [作 者] 四季风 [公 司] 兴库建设投资有限公司

首先研究他刁钻的是核心利益问题还是一般利益问题;其次看这个客户是核心客户还是一般客户;
最后看问题发生的责任主要在自己方还是客户方。
如果是前者,那么最好建设性沟通,攻心为上。采取认真倾听其意见,共同探讨解决办法,迅速
建立协商一致的行动方案。
如果是后者,那么原则上不对抗,攻城为上。采取语言行贿等方式拉拢、说服、取悦他,逐渐改
变他的心态和做法。

·取证 分析 对症下药(2008-08-05) [作 者] 如月 [公 司] 保密

第 373 页 共 756 页
第 4 章 沟通管理

注意沟通过程----分析原因----衡量结果-----对症下药

·个人看法(2008-07-21) [作 者] xieshiling [公 司] 济南科技有限公司

1、首先弄明白刁钻的原因是什么,一般客户刁钻,有的是个性如此,有的是为了利益,利益有个
人的还是集体的之分;
2、为了弄明白原因,需要分析刁钻的人的个人特性有哪些?是豪爽的,还是其他类型的,对承担
的风险意识如何?等等
3、只有知道原因是什么,才能对症下药,一般我们会判断为给利益就 OK 了,给利益,可能还要
分析对方承担的风险是什么,是否有化解的办法,如果对方非常精明,估计给利益一般是不会响
应的;
4、选择合适的机会非常重要,现在都开始讲直接的方式,有些管用,有些是无效的,只会让对方
提高警惕,敬而远之。
如何处理,还是取决于知己知彼,才能知道最快的处理办法,思路也是从知彼开始。

·如何和刁钻客户进行沟通(2008-07-17) [作 者] nicky [公 司] Bluescope

我觉得:首先,要分析客户的动机,是工作态度问题还是其它利益关系问题,如果是前者,就要
从客户利益出发,切实配合好客户和引导客户的合理需求;如果是后者,先要分析该项目的相关
方利害矛盾,有效整合外部资源进行处理。

·简单回复如何和刁钻的客户进行沟通?(2008-05-14) [作 者] 蒋天舒 [公 司] 网龙(上海)


公司

这个事情我是这样看的。
首先,要判断这个客户是不是你的重点客户;
其次,衡量一下这个客户投入与产出是多少;
再次,作足客户的功课,寻找其薄弱环节,进行攻克;
最后,总结客户的特点永记在心。

·如何和刁钻的客户进行沟通?(2008-04-21) [作 者] 王元涛 [公 司] 济宁正通建设工程有


限公司(山东)

面对刁钻的客户,可以先揣摩一下他的心理。这个人那么多事儿到底图的什么?首先满足于他最
期盼的内容,其他的部分如果你有能力满足则满足,如不现实最好及时回决,当然也要广泛让他
清楚你已经满足他很多了。

·软中带硬、不亢不卑(2008-03-05) [作 者] 周预 [公 司] 湘潭

第 374 页 共 756 页
第 4 章 沟通管理

沟通和交流理论上、原则上是平等,但中国总体市场环境是买方市场,在这种情况下,客户无疑
处于有利位置,作为项目经理总体原则是:软中带硬、不亢不卑。
重要的是做好干系人分析:客户需求和影响力分析,需求包括项目本身的、可以明说的;也有潜
在的、擦边球的;甚至有违法乱纪的、上不了台面的。然后进行影响力分析,决策者、重要影响
者、影响一般者、影响可以忽略者等。综合平衡。呵呵,不要一概而论哦,不要自作主张轻易承
诺,最好能与公司高层沟通。力争做到:最少的代价最大效益。
其次要针对具体事情做好原因分析:自己的原因还是客户原因,明白事情缘由。对于自己的原因,
要提前预防自身缺陷,在谈判过程中处于有利位置。同时在合同中应详尽明确有关范围、进度、
质量、成本、变更安排,从法律上预防、减少此类风险。
再次,沟通再沟通,注意沟通技巧,了解动机。

4.9 如何协调各部门让其更好的服务于项目组

如何协调各部门让其更好的服务于项目组

[姓 名] 徐伟 [单 位] 国电南瑞科技股份有限公司 [邮 件] mxwxw@163.com
[所属行业] IT 软件 [所属主题] 项目沟通管理 [发布时间] 2008-2-21

【案例正文】
在我负责的泰国工程项目中,我担任了项目经理的角色。作为公司上下领导都非常重视的一
个国际项目,自然是只允许成功,不能失败。各个部门的负责人也都积极表示尽最大的努力
配合,但是底下的人当中总是有不和谐的声音出现,或者表现出不配合,或者表现出很忙抽
不出时间。很多时候我都努力的去协调、去沟通,但是发现效果并不是很好。

到底是不是我的方式方法不够好呢?还是我缺乏协调的技巧和手段?

·如何协调各部门让其更好的服务于项目组(2008-04-30) [作 者] pinter [公 司] 友达光电(苏州)有限


公司

1.目标明确.对事情表现出来不积极的部门,他们明确自己的目标么?建议先和他们沟通一下他们的
目标和你的期望,做到目标一致
2.明确完成目标的进度,定期对进度进行确认
3.指定项目进程阶段的奖惩办法.

第 375 页 共 756 页
第 4 章 沟通管理

·如何协调各部门让其更好的服务于项目组(2008-03-03) [作 者] 张力 [公 司] 深圳市金钢建设监理
有限公司

没有啥好办法,必须知道这个项目对相关人员会带来啥好处与坏处,然后,平时多交流感情。

·用心(2008-02-27) [作 者] gaozhen [公 司] shandongjingjixueyuan

认真做事只能把事做对,用心做事才能把事做好。项目组所有成员都在用心,就不会不成功。
关键是如何让项目组成员都在用心?
真诚沟通:紧盯目标,不计小节,真诚待人,放下架子。
提出愿景:让员工明确具体目标以及收益(精神和物质) 。
明确任务:我们要做什么,每个人要做哪些具体工作,什么标准,要弄清楚。

祝你成功!

·沟通+激励(2008-02-27) [作 者] 殷克俊 [公 司] 江苏惠通集团

我认为主要是
1、沟通的问题
2、对项目成员多多激励,让其自己主动溶入项目工作中

·我的观点(2008-02-26) [作 者] 罗俊峰 [公 司] 青岛康居博信建筑技术开发有限公司

这种现象在国内常见,没有这种现象才奇怪.
建议分析一下找各种理由推脱的真实原因,找到原因后,才能对症下药.

·沟通(2008-02-23) [作 者] 王祥 [公 司] 石油化工建设公司

实际上,大的公司,尤其是国企,这种情况比较常见,主要的问题倒不是太忙或者什么,类似的
事情,对一个项目来说是大事 ,急得不得了,机关部门的人员可能是天天看到,不觉得有什么,
或者都是急事 ,拖了几天也对自己没什么大影响,麻木了。对这种情况,讲道理是没有用的,到
领导那里去说,恐怕有时候还起反作用,那种做法只有大项目经理,也就是有级别的项目经理才
好使得。倒不如,花点费用,请客吃饭,或者搞点小东西,融洽一下关系。同时对这些办事人员,
项目经理也放下架子,适当时候搞搞关系。总是有效果的。

·注意沟通技巧(2008-02-22) [作 者] Barry.Ma [公 司] 北京公司

相信你是非常优秀的,但是在与各个部门以及员工的沟通中,要做到沟->通!也就是说你的表达对
方是否清楚明白!不一定是做了交流,别人就明白了的!

第 376 页 共 756 页
第 4 章 沟通管理

·回复:(2008-02-21) [作 者] 王海飞 [公 司] 闲赋在家

根据你的描述,只能判断出:
不是方式方法不对就是你的沟通技巧不高,要不然就是做人不厚道,呵呵.

4.10 如何做好“拍脑袋”项目的需求分析

如何做好“拍脑袋”项目的需求分析

[姓 名] 肖威清 [单 位] 安徽爱普科技有限公司 [邮 件] itpmp@126.com


[所属行业] IT 软件 [所属主题] 项目沟通管理 [发布时间] 2007-12-5

【案例正文】
某一政府项目,属于领导“拍脑袋”型项目。由于该项目较小,领导交其下面工作人员办理,
并委托我公司承担该项目的建设,但政府方面相关人员对项目只是有一个总体的设想,虽经
多次沟通,我们仍无法得到具体的需求,他们仅是一直强调要用过以后才能提出问题。

对此类项目,如何才能获取客户的具体需求?

【相关分析】

·“拍脑袋”也是因为有需求(2008-07-23) [作 者] 吕建光 [公 司] 北京昂展置业有限公司

政府业绩需求、办事人的个人需求、社会需求、建设公司的利益需求,利益平衡吗。政府明确不了需
求是因为不专业?不好说?不能说?为政府干事需求就是要你自己琢磨,否则就别想把事做成。

·这是发挥才干显身手的好地方(2008-07-21) [作 者] 四季风 [公 司] 兴库建设投资有限公司

正因为项目干系人均只有大概映像,作为政府的代建类公司恰好大有作为!建议:
一、原则上“到位不越位,用权不越权、出场不炫耀、做事不争功”做好只有你们能做好的,弥补干系
人缺陷的。
二、做业务上“先处理干系人好心情再说事情、先顺通情绪再顺理智”就非常好办,不要要求政府等什
么都懂。
三、理论上把干系人看作同自己一样的平常人,正是缺点让他们一个个显得可爱,互相包容、互相支
持工作最好。

第 377 页 共 756 页
第 4 章 沟通管理

四、请先克服写此案例的基本观念,本人曾经有此类念头,现后悔莫及。

·用自己的经验引导客户提需求(2008-06-03) [作 者] 陈敏 [公 司] 南京天成金盾科技发展有限公司

在政府的信息化过程中,很多业务部门对需求的概念并不明确,提不出实质性的需求或者提出的需求
用软件在目前阶段无法做到,软件公司必须依靠自己的经验给客户正确的引导,才能让项目正常进行,
这种一拍脑袋就定事情的做法实在是太普遍了!

·引导(2008-02-20) [作 者] liuxueqing [公 司] morse

用你的经验,做一份规划方案,据此引导对方确认需求
做个多项选择题,由他定义
按照你的思路操作不是更容易
只等着赚取你的利润就行了

·一语中的(2008-01-21) [作 者] 逍遥游 [公 司] 天地之间

“你提方案,我拍板,你执行----其余的不要来烦我”--一语中的
前期的需求还是要明确的,领导定基调,我们做具体干系人调研。
1.根据基本范围和组织结构图,确定干系人清单
2.基于关键干系人,访谈了解需求
3.如果干系人众多,基于访谈需求,再设计个调研问卷
这样你的需求就明确了,并且对方会觉得你做事有章法,没有破绽。
再然后,你需求清晰了,做什么方案就是你的拿手好戏了。

·做选择题--业主都喜欢做选择题---好---完全同意王金龙的意见!(2008-01-14) [作 者] 陈万
春 [公 司] PETL

最明确的决策方式,就是做选择题!

不得不提及的是,政府工作人员是不可能喜欢做这种具体问答题和论述题的,也不屑于----所以他们
一直强调要用过以后才能提出问题。

余下的就是被委托的开发商的责任了!开发商有合约责任根据政府的大体设想,拟定几个具体的方案,
帮助业主决定用哪种。

成熟的公司和项目经理,自然会明白且会帮助业主明白她到底要什么-----这个过程中,项目经理们
会得到自己想要的东西的,如项目利润。

我曾经做的一个山东济南项目,业主主动提及“你提方案,我拍板,你执行----其余的不要来烦我”。

第 378 页 共 756 页
第 4 章 沟通管理

·先培训出需求在进行互动(2008-01-08) [作 者] 王祥 [公 司] 石油化工建设公司

个人认为 lion 讲的有道理,先对客户进行一定的培训引导,提供较普遍接受的方案,可以使多个方


案进行选择评判,然后进可以走进下一步了。

·不能很好的获得客户需求(2007-12-20) [作 者] 孙杰胜 [公 司] 天津华苑产业园区方卫

这种情况在绝大部分的“中国式”项目中存在,并且客户很难按照项目管理的思想配合项目实施。其
实项目经理的还有一个很重要的任务——帮助客户了解甚至掌握项目管理知识。

·很多情况下用户都提不出需求(2007-12-20) [作 者] 狼图腾 [公 司] founder

在很多情况下,用户都不知道自己的需求,即使知道需求也是一个概括,在这种情况下就要看项目负
责人怎样去引导用户了。

·引导(2007-12-20) [作 者] lion [公 司] 南京GDK

根据公司以往的案例,整理可选的需求让客户选择,项目不大要注意控制范围,尽量缩小范围。

·客户的想法就是需求(2007-12-18) [作 者] daijiangbao [公 司] 深圳市大视野企业管理顾


问有限公司

客户的总体设想就是需求,按照这个往下走就是了,关键是你怎么组织。

·综合分析(2007-12-17) [作 者] 于学勇 [公 司] 河南信阳明港某某单位

需求分析对于做项目的人来说,主要是明确做什么、怎样做、做到什么程度;化解不明的风险;
对于发起人来说,选择所需的;
既然情况是这样的,就可以根据以前做过的类似的项目让发起人选择一部分,如果不能明确的,就不
妨连“机会成本”一起算上,因为这种风险本来就来自发起人,他理所当然的应该承当一部分。

·需求递进(2007-12-14) [作 者] shi [公 司] s

做这种项目的战略: 走一步,说一步.特别要重视范围管理.

第 379 页 共 756 页
第 4 章 沟通管理

·建议(2007-12-12) [作 者] 张观石 [公 司] test

建议使用渐进模型生命周期
还要确定政府方面有专人参与这个项目。
把需求本身当成一个项目来做。

·让他们做选择题(2007-12-06) [作 者] 王金龙 [公 司] 保密

其实我们每个人都一样,都喜欢做选择题而不喜欢做问答题和论述题,所以论述题分多。
这些政府相关人员也是一样,他们的水平可想而知,能说出个大概的需求设想就不错了。而对于被委
托的开发商而言,靠的就应该是在项目开发上的专业水平,所以可以根据政府的大体设想,拟定几个
具体的方案,给他们解释一下,让他们选,这样他们就会觉得轻松了,也就会选了,不过在过程当中
他们渐渐的经过学习观察,肯定还会提出不少变更,要做好心理准备。
作为专业的开放公司,不但要明确理解客户的需求,还应该帮助客户明确需求。

·渐进明细(2007-12-06) [作 者] dajundalao [公 司] 暂时保密

按照国际惯例,这显然是一个前期规划性项目,只有一个概念性的东西,此时需要乙方有较高的水平,
通过乙方从前期调研到可行性研究到立项到项目组织到施工到投入运营全过程负责,由于只有大致概
念和方向,因而需要乙方及时与甲方沟通确定下一步工作,整个项目在渐进过程中具体实施,到项目组
织阶段基本上能够有一个明细,有的可能在实施过程中才有一个明细,此时才知道,甲方需要的是个什
么项目而乙方应该做的是一个什么项目.
这类项目做起来难度较大,因而利润相对丰厚,而从本案例来看,有政府背景支持,应该利润不是问题.
如何把这个项目做好让领导有面子才是问题.祝你们好运!

·需求 原型 不断循环(2007-12-05) [作 者] 朱清波 [公 司] 武汉华中科技大学

现明确项目本身的特点,包括立项的情由和干系人特点等。
”拍脑袋“ 体现了项目本身的重要性。 因此在承担此项目前应该衡量自己的能力和项目本身所带给
您的压力(各方面的)。

现在很多用户本身不喜欢去做需求,他们只有大致的想法。而项目需求又是直接决定产品属性,项目
经理必须做好需求分析。

鉴于项目特性,初期选择原型的开发方法,之后再根据具体情况选择不同的开发方法。(动态调整比
生吃某一中开发方法要好)

其理由是:

第 380 页 共 756 页
第 4 章 沟通管理

1。初期项目需求不定,项目团队分析人员需要不断和用户等沟通,并开发原型,以验证客户的想法。
2。拍脑袋的事情,需要逐级化解风险。
3。让用户承担部分责任。

4.11 老板不信任怎么办?

老板不信任怎么办?

[姓 名] 李先生 [单 位] 深圳某公司 [邮 件] conor@126.com


[所属行业] IT 软件 [所属主题] 项目沟通管理 [发布时间] 2007-11-21

【案例正文】

A 是多年的项目经理(PMP),在目前的公司工作了 2 年多,现已是部门经理,
带了多个成功的 IT 项目,团队氛围很好,客户对他也非常认可……
但是老板不够信任他,表现在:
1.不时跨级指挥,而且不通知 A,除非 A 主动询问;
2.不按照 A 的工作绩效评估,总在找些无关紧要的问题来质疑 A ;
3.在提到项目管理之于企业执行力的时候说“客户才不管你是不是 PMP”;
4.从职位上,A 有任命项目经理的权限,但是不然,A 的意见仅仅是参考,有一次
A 任命了一个项目经理,老板非常生气,A 也很难受,说“既然你把这个权限给我,我
当然要履行,要么不要我在这个位置”,老板说“我有这个考虑”。
A 目前和公司的团队相处很好,在团队中也很有威信,甚至副总也很赞赏,但是老
板这样的信任度,让他很难受。
请问,如果你是 A,你该怎么做呢?

·中国式的项目管理和信任(2008-07-22) [作 者] xieshiling [公 司] 济南科技有限公司

1、在国内,个人感觉,信任,特别是上级的信任是第一位的,如果没有信任,你还担任一个重要
的岗位领导角色,说明你在某些方面还是能够信任的。否则,只能是让你另谋发展了;
2、信任的取得,是通过一些事情或者一些行为来表现的,不是口头的;特别是授权方面,不要认
为上级给你授权,你就认为你有权利了。事实不是这样的。因为这是国内,还无法做到两者是一
致的。
3、针对案例中的越级指挥和自己任命的人选给否决了,这是非常正常的现象;首先这是上级的问
题,做事的问题,不是你的信任问题,上级的做事方式如此。1:认同上级可能越级指挥,原因是

第 381 页 共 756 页
第 4 章 沟通管理

你在某些方面存在弱点,不足以让上级放心,自己需要反思;2,上级这样做,你很尴尬,解决之
道是巧妙的沟通,不能直接说,此种方式不对,应该通过安慰下级的方式来处理,可能最难受的
是下级,因为存在两个领导,通过安慰下级的方式,让下级及时向你汇报,解决了这个问题后,
你才能掌握主动权。如果下级不向你汇报,估计不是信任的问题,是个人的能力需要提升的问题。
关于你任命人员的问题,缺少沟通,最好的做法是,你暗示提名,上级任命是最好的,达到你任
命的目的,毕竟国内的现实如此,你的功劳是上级的,你只有苦劳的命。如果你能经常如此后,
估计上级就能够授权,你去宣布了。这时候才能谈到你具有相应的权利。

·做下去(2008-06-05) [作 者] wangjinju [公 司] 宁波

我想 A 就按自已的思识做,不过以公司大局利益为前提,可以说有些需跟老板做对的,但从公司
大局的角度出发的,我想以后老板也会慢慢理解的。

·老板不信任怎么办?(2008-04-20) [作 者] 王元涛 [公 司] 济宁正通建设工程有限公司(山东)

我感觉这种事情与 A 作对的是分管的副总还差不多,或许他会嫉妒你的能力。但是怎么会是老板
不信任呢?你工作能力出色最放心你的应该是老板才对。
不过,既然这样了。我估计有两方面原因:其一是你要反思一下自己的工作表达方式,是否因为
太过张扬而导致老板嫉妒或担心你以后强大了会单干拉走他的客户?其二 老板本身敏感多疑或
曾经有件事情造成你们的误会?
我认为还是沟通出现问题。作为下属,你应该主动坦诚和老板谈谈,找个茶馆请他座座和盘托出
你的想法,交流下应该有帮助。
当然还有很大的可能是,老板本身素质就不高。他想怎么做就怎么做,也并非对你不信任,对谁
都一样。如果真是这样的话,既然跟他干,也就只能来包容他了。

·沟通才能解决问题(2008-04-18) [作 者] 谭小平 [公 司] Cattsoft

首先可以肯定的是 A 是个有管理能力的人。
1、从这个案例建议 A 留下来,利用有效的沟通方式和老板沟通,以被动变主动。
2、在工作绩效评估上,老板可能还没有意识到绩效评估的重要性,A 需要从绩效评估给日常工作
及公司带来的效果和老板进行沟通,争取得到老板的认同,使得该项目工作能够在公司顺利展天。
3、从老板角度看,是不是 PMP 不是很重要,重要的是你要把工作做好,给公司带来利益。
4、对于权限问题,A 可以推荐或是任命之前和老板商量。做老板的都会有这样一种意识:公司是
我的。需要员工做事上明白这一点。
5、经常换位思考一上工作上发生的一些问题。

·办法(2008-01-17) [作 者] 郭林海 [公 司] 东软

两种选择
1、走人,另谋高就;
2、留下,与老板沟通,让他指出你的问题,以退为进,有助于你明确后续的工作方法;

第 382 页 共 756 页
第 4 章 沟通管理

·老板不信任(2007-12-18) [作 者] limoshuai [公 司] 海弯

1、拍拍屁股走人,另谋高就。
2、得过且过,混一天算一天。
3、认真的工作,以实际表现来取得老板的信任。
三者选其一,看你自己的性格了,性格决定一切。

·沟通第一(2007-12-04) [作 者] 超 [公 司] 许昌

首先可以肯定的是 a 的能力
其次是老板对 a 工作能力的肯定(已经任命 a 为部门经理,但如果老板是被迫的除外)
我认为应从以下方面分析
1 、与老板制定(协商)a 作为部门经理的权力(包括人事、财务等)。从而对 a 的权力加以界定,
不同的老板对此有不同的要求和忍耐力,不能仅从项目管理知识的课本上规定的权力想当然。在
大型跨国公司都有一套明文规定,如 HP 公司对部门经理的财务签字权限都有规定。着也能从侧面
了解老板的管理风格(粗放型、精细型管理)。
2、 制定一套与老板沟通和向老板汇报的计划。这包括需要汇报的方面,频率、幅度(对量度的
把握),不同的老板是对此有不同的要求。
3、如能在非正式场合同老板进行一次沟通,也许能起到意想不到的效果,在沟通时要善于换位思
考。

·工作风格分析及有效的沟通(2007-12-04) [作 者] 王炜 [公 司] 沈阳某汽车有限公司

每一个人都有不同的工作风格,对于自己的老板也需要进行分析,确定它的工作风格,按照案例
老板的表现,他应不是一个善于放权、而希望下属事事汇报并对其表示尊重。为此,作为下属,
如果你不想放弃该工作,便需要对以往沟通的方式进行调整,确定老板期望的下属的工作方式,
并对自己的言行进行调整。

·沟通,还是沟通(2007-12-03) [作 者] 林敏 [公 司] 同济大学

1.首先,当然是要加强和老板的沟通。可以私下找老板多谈谈,但尽量不要正面冲突吧。争取能
了解到老板为什么一直不信任自己,甚至无视自己的工作能力。说不定老板一直因某事对 A 有成
见或是误会,才会处处针对他。只有了解问题的原因,才能着手去解决。
2.和老板沟通后,如果 A 发现确实是自己过去因某事和老板不愉快过,建议和老板开诚布公,化
解心结。
3.沟通过或者根本无法沟通的,可以考虑是不是老板的性格比较令人不愉快。(如果能和别人正

第 383 页 共 756 页
第 4 章 沟通管理

常沟通并且气氛处得不错的话,那说明沟通能力是没问题的了)。如果真的那么不愉快,直接走
人吧。。

·沟通很重要(2007-11-30) [作 者] 卓宇 [公 司] 杭州某公司

我没有 A 的水平,但是我也遇到过与 A 相似的事情。虽然目前以离开原公司,但是这个问题一直


是我的心病,也是我以后工作道路上的警戒。

首先,A 应该好好反思,寻找老板会跨级指挥的真正原因。
从案例上看,A 的能力是得到老板认可的,否则不会将这么重要的职位和职权任命给 A。排出这个
原因,到底是老板的性格决定了他的不信任,还是 A 的行事方式并不得到老板认同,这个就需要 A
慎重分析。
其次,A 要多于老板沟通,及时向老板汇报情况,让老板觉得你对他的重视。老板总是有自己的想
法的,自己的公司自己当然要多操心,相信 A 在项目经理职位上并不会碰到这个问题,但是现在
是部门经理,一个部门的兴衰直接会影响整个公司的运作,老板自然要多操心。多沟通多汇报,
让老板认可你的工作,认可你带领的团队对公司来说是足够优秀的,老板也会放心,从而慢慢放
手。有部分老板施加压力,不是因为他们不信任,而是因为他们觉得你有更大的弹性提高空间。
如果这样老板仍然小心眼,或者 A 仍然无法忍受老板的做法,那么 A 就选择跳槽吧。有能力到哪
里都是会受到重视的,而伯乐和千里马也是需要磨合的。

·反思自己,争取信任(2007-11-30) [作 者] 孙灵芝 [公 司] 山东大学

看来 A 的项目管理能力值得肯定,想一想是不是在什么时候留给老板不可靠的印象了

·不要为"信任"折磨自己(2007-11-29) [作 者] 车贵普 [公 司] 山东创业房地产开发有限公


非常理解 A 的处境,作为项目经理工作干的再好,也要得到周围的每一个人的承认和支持,更应该得
到老板的信任和支持.因为我们中国的项目管理环境还处在一个初级阶段,企业的老板们项目管理
还没有一个真正的认识,还需要我们这些项目经理用实际行动来改变我们项目管理环境.我建议 A;
1.要想在公司继续干下去,就不要过多的计较老板的信任与否,要多向老板请示汇报,找机会与老
板彻底的沟通一次.
2.如果实在不想再工公司干了,换个单位也不是个坏事.
3.不管那种选择,都彻底的反思一下自己的所作所为.否则,你可能还是得不到老板的信任.

·不防换位思考一下,可以帮你作出决定(2007-11-28) [作 者] snock [公 司] 广州某软件公


第 384 页 共 756 页
第 4 章 沟通管理

1.A 不防换位思考一下,如果你是老板的话,在什么样的情况下你会跳过"优秀的项目经理"而去直
接指挥下面的人呢?
2.A 可以从自身方面多找一下原因,也许会在某些方面真的还有改进和提升的空间.
3.如果通过上面的两点都找不到原因,那我觉得 A 应该果断地离开这个老板.

·分析与办法(2007-11-27) [作 者] 孟广燕 [公 司] 青岛有线电视网络有限公司

现在的问题是老板让 a 当了部门经理了,应该证明 a 是有能力的,但是问题出在两个方面:


1、a 与老板沟通不够;
2、老板喜欢细节管理。
在这种情况下,a 是有压力的,这正是老板的目的所在,也是 a 证明自己能力的大好机会。a 应该
更加努力的工作,注意以下问题:
想办法加强与老板的沟通。

·彻底的信任太难了!(2007-11-27) [作 者] 王金龙 [公 司] 保密

要想然别人彻底的信任你太难了,除非是你至亲的人,换位思考,你能彻底的相信别人吗?你彩
票中了头彩,1000 多万,你会拜托别人帮你领奖吗?我觉得除了亲人你很难找到这样的人。
不一定要求别人完全的信任,只要别人相信我们就足够了,首先自己要是一个诚实的人,不诚实
的人根本就没资格这样要求。
老板这样做我想有两种可能:
1.性格和水平,可能不太懂领导的艺术,性格不够大气;
2.戒备心理太强,或许是因为 A 太优秀,平常又不太注意收敛,下面的人笼络的挺好,和副总管
关系还挺好,这样分析一下,老板能不防着点吗?万一哪天你们搞一下政变,老板岂不亏了。

·沟通(2007-11-26) [作 者] 吕美群 [公 司] 上海大盛模具有限公司

从案例上来看,我觉得老板其实还是信任 A 的,只是因为:
1)A 缺少与老板的沟通
2)此公司可能为小公司且还是私人企业,且老板原为技术人员出身,对技术和项目管理有自己的理

其实我觉得 A 应该多和老板沟通自己的想法,这样会显得很尊重老板从而的到老板的支持(因为我
觉得老板特别是中国的老板一般都喜欢别人向自己汇报,特别是小企业).

·快乐的工作(2007-11-24) [作 者] 张春林 [公 司] 通宜创新机构(重庆)

1、老板既然不适应 A,那么建议 A 迎合老板。

第 385 页 共 756 页
第 4 章 沟通管理

2、如果觉得实在无法忍受,那么建议自己干或着找别家公司。

·听之任之(2007-11-22) [作 者] 亭长 [公 司] 北京易事通科技有限公司

很不幸,我的老板也是这种类型人,我经手的很多项目他都插手,我也习惯了,团队成员也习惯
了,我们都觉的自然,他说他的,我们还是按照项目计划做。只是不当面反驳而已。说实在每接
一个新项目他不插手还有点不习惯呢!呵呵!放开些,不要在乎“信任”与否,老板最终看的还
是给他带来了多少的利润。

·深刻检讨自己的不足(2007-11-22) [作 者] 陈中民 [公 司] Canon

应该说老板还是信任 A 的,问题是 A 怎样认识自己的工作和老板的做法.


首先 A 应该从以下几个方面有一个清楚的了解
1、企业的规模
2、企业文化
3、企业的组织结构
4、老板的工作方式
5、项目经理和部门经理的职责
当一个企业的规模达到一定程度时,企业的文化、制度、组织结构都是比较规范的,老板一般也
不会过多的参与具体的工作,一是没有时间,二是没有精力,三是制度不允许。
从这几个方面来看,此公司是一个比较小的单位,老板本身可能就是从一个开发人员做过来的,
他当然希望了解更多的关于项目开发上的一些事情,这是一个职业习惯,不是信任不信任的问题。
因此,A 应该加强与老板的交流,取得他的理解;定时向老板汇报工作,取得他对工作的支持。而
不是一味地抱怨。

·管理风格的问题(2007-11-21) [作 者] dajundalao [公 司] 暂时保密

从案例来看,老板是一个独裁风格的管理者。对于独裁风格的管理者,A 先生应该履行多请示、多
汇报、多征求老板的意见,而不是要太过于关注自己的权力。而作为一把手的老板应该对资源有
绝对的控制权,否则如果老板说了不算(在资源问题上和战略问题上而不是具体决策上和管理问
题上)那才有问题呢!A 先生可能因有丰富的管理经验而在老板面前表现出了绝对的强势,这是独
裁型老板所不能容忍的,所以才会有无关紧要的问题质疑和考虑不让 A 先生在其位置上的言语。
另外,如果团队和谐,说明员工至少目前认可了老板的独裁管理风格。A 先生应该自我做出适应,
否则对于 A 先生来说比较危险。
再有,这个老板应该加强学习以寻求自我突破,否则一言堂的组织会给他带来悲剧性的结果。

·突破(2007-11-21) [作 者] 诚 [公 司] n/a

第 386 页 共 756 页
第 4 章 沟通管理

首先,非常羡慕你能和自己的团队相处得这么融洽。

我觉得你对“信任”依赖过高,老板不信任你又怎样呢?还是要工作,还是要从他手里拿票子的
嘛。人的心理往往具有趋向性,好的越来越好,坏的越来越坏。还有一个补偿心理,信任从老板
那里得不到,就从副总和同事那里得到。

要突破现有的困境,唯一的办法是改变现有你的看法。另外要想想怎么从技术管理向人员管理转
变。

4.12 遇到逃避责任问题该如何处理

遇到逃避责任问题该如何处理

[姓 名] 肖茂堂 [单 位] 不公开 [邮 件] heroxmt@163.com


[所属行业] 能源煤电油 [所属主题] 项目沟通管理 [发布时间] 2006-9-4

【案例正文】
我正在做的一个海外工程,由公司主管海外市场的分公司负责,国内和现场各设一个项目部,
国内提供后备支持。根据公司财务规定,凡是一定数额的都必须经过分公司或公司总部批准。

在最近的一次公关费用支出过程中,现场按照规定向分公司递交了申请,但是分公司认为该比
费用比较着急,如果走正常程序可能会需要较长时间,于是建议现场利用项目经理的权限,将
该笔费用分为三笔,这样每笔就可以控制在项目经理的权限之内。而现场项目经理认为该笔费
用为攻关费,一笔尚且好说,如果短期之内连续支付几笔,就很难说清楚了。

这个问题的关键时国内外都不想承担责任,结果导致互相扯皮浪费了好多时间,严重影响了现
场工作计划的实施。从这个问题看来,国内外项目部之间明确责、权关系,而且要加强沟通,
不能因为因为内部沟通错节而影响工程,这对本来就存在很多不确定因素的海外工程来说尤为
重要,请大家谈谈看法吧!

【相关分析】

第 387 页 共 756 页
第 4 章 沟通管理

·特事特办(2008-02-23) [作 者] 王祥 [公 司] 石油化工建设公司

根据公司规定掌握谁有审批权,确有必要的话通过电话沟通,传真或邮件 确认,先把事情办了,再
补办正式手续。应该没有问题。

·当断则断(2007-11-05) [作 者] 赵昊 [公 司] 中电

现在的当务之急,是帮助楼主解决问题,不是去讨论其公司的财务和文化存在的纰漏。
当前最重要的问题是:我们如何去解决这个财务问题,如果公关费用,确实是必要,最好的解决方案
是如何支付。
作为一个财务经理,他应该很清楚,能够通过这批款项的最终的决定权在哪个上级领导手中,直接和
该领导取得联系,解决问题,得到书面的答复,采取行动解决。在解决问题之后,再向公司建议,采
用后备金体系或者是明确项目必要的务支付的决定权。

·这个不是责任问题(2007-05-29) [作 者] 杨耀敏 [公 司] 华为北京分公司

关于该笔费用的开支,应该列在准备金支出这一块。作为一个工程的两个项目,准备金的开支应该列
在工程开支之中,而不能作为搁置在项目费用之中。所以,对于 PM 而言,应该提前意识到这种问题。

另外,从公司的角度来看,没有什么事情一定要马上办,也没有什么事情可以拖的,关键看效果,
尤其花费了费用的时候。

·权限和制度(2007-04-06) [作 者] 任鹰 [公 司] 暂无

在工程管理中,经常会遇到此类情况。我觉得要从以下几方面考虑:
1、完善规章制度
规章制度不但用于约束相关人员,更重要的是为所有人员提供了工作的分工、界线或要求。规章制度
尽可能的考虑比较多的方面。
2、灵活变通的工作程序
一般情况下,工作就是按部就班的进行,但遇到紧急情况时,如果要经过繁琐的申请、批示程序,就
可能误事。因此,在当今讯息如此发达的情况下,完全可以利用电话、网络进行紧急联系,必要时,
口头请示上级,没有扯皮可言。

·明确界定两个项目部的职责(2007-04-04) [作 者] Yangyong [公 司] 汽车饰件系统有限公司

通过案例可以看出,两个项目部几乎是平行运作的;这种结构在出现交叉问题的时候,双方都过多的
考虑了各自子项目的成本。因此建议在项目初期确定隶属关系,明确一个最终负责的项目团队。
另,项目费用的发生应该是有计划的;若案例发生的问题时计划外的则建议公司考虑此类公关问题的
简化流程。

·成本计划(2007-03-18) [作 者] HSP [公 司] secret

第 388 页 共 756 页
第 4 章 沟通管理

我觉得以下几点可以考虑:

1,这批公关费用是否在项目的成本计划内,如果是项目经理就可以动用,如果不是项目是否有应急
储备?

2,国内外两个项目部项目经理的领导与被领到关系是否明确?

3,在原则问题上一定要遵守海外当地习俗及本公司的相关规定!

4,不要做一些没有经过批准或自作主张的变更!

·站位(2007-03-05) [作 者] 木头 [公 司] 燃气

..........................................................确定好自己的位置,你的第一定位
永远是要为自己的企业争取最大利益.不是单纯的为项目进度.

·逃避责任如何处理(2006-11-24) [作 者] tigerdeng [公 司] FIBERHOME

公司不应该设置两个平行的项目部,公司设置时要划分职责,海外项目部要求有一定的决断权,古人有
云:将在外君命有所不授,当两个项目部不能决断时,应通过上级领导或例外程序解决,毕竟市场是第
一位的,外部问题就是风险

·置身事外(2006-11-20) [作 者] 潘琦 [公 司] 北京市门吉利磁电工程研究所

不要认为自己的权力有多大,公司永远把利益放在第一位,员工第二,在公司做事就是有功人人抢,
有过人人推。
像你说的这件事情,报告打上去,等待领导批示和发放资金,作为当事人的你需要不停的请示和了解
资金到什么部门了,你只需等待或者做其他事情。

·项目经理就是为做项目设立的职务(2006-11-13) [作 者] 姚凯 [公 司] 北京工业大学

其实这样的事在项目的运作过程中经常会遇到,只不过有的事情可以控制,而有些事情超出了自己能
控制的能力的范围之外,我的意见是不要管会不会得罪人,先把项目拿下再说。
项目经理是要为项目付出一切的,只要项目遇到阻力,超出自己控制范围之外的,甚至超出公司规定
之外的,完全没有必要受规章制度的限制。制度是死的,人是活的。可以和能拍板的,了解情况的上
司汇报情况,他会为利益着想,然后用自己的人际关系或者职权为项目的顺利实施做保障。
如果你直接给财务总监打电话也可以,但是可能会因为你的决定得罪一些人,但是回头想想在做公关

第 389 页 共 756 页
第 4 章 沟通管理

的时候陌生人都能让你攻下,还怕那些自己认识甚至熟悉的同事吗?如果是得罪了上司那更好办了,
这样的领导很明显不会为大局考虑,他们考虑的只是你的行为有没有破坏他的制度和他办事的规则。
因此可以说这样的领导不是合格的领导。
总言之,超出自己能力范围之外的突发情况,犹豫是万万不可的。不要受制度的制约,要一切的了项
目着想,想尽一切办法完成。不要怕会得罪人。成功的拿下一个项目那你就是好样的,但是如果拿不
下来,那么我想你不是一个合格的项目经理。权衡一下,得罪人还是拿下项目,我想你也明白应该选
择哪一个。

·关键是企业文化(2006-11-10) [作 者] 廖学峰 [公 司] 江西科泰华软件有限公司

各个上层,谁都不想担责任,说明公司在制度上还是有问题

·关键是企业文化(2006-11-10) [作 者] 廖学峰 [公 司] 江西科泰华软件有限公司

各个上层,谁都不想担责任,说明公司在制度上还是有问题

·关键是企业文化(2006-11-10) [作 者] 廖学峰 [公 司] 江西科泰华软件有限公司

各个上层,谁都不想担责任,说明公司在制度上还是有问题

·凭什么分公司认为该比费用比较着急?(2006-11-07) [作 者] 杰罗 [公 司] 无

但是分公司认为该比费用比较着急文字

有意思,为什么是分公司认为呢?
项目经理呢的判断呢?

如果真的急用两项工作同时做:
1、被公关方的工作
2、公司的工作
3、应有特事特办的渠道

·风险与沟通(2006-11-06) [作 者] Liber [公 司] 宁波

个人认为这种不确定性风险产生的资金,在项目初期要给予充分的考虑,给出应对方案,可以避免由
于事情的突然发生影响项目进度。对于项目经理来说,在阅读材料时注意到,在最近的一次公关费用

第 390 页 共 756 页
第 4 章 沟通管理

支出过程中,现场按照规定向分公司递交了申请,在最近的一次公关费用支出过程中,现场按照规定
向分公司递交了申请,我认为如果是项目支出可以向项目经理提出申请,由其协调沟通分公司及总部
进行安排。
另外针对现在的制度和突发情况,项目经理应该发挥其沟通技巧,首先安排工作人员工作的继续推进,
不产生进度影响;另外积极与高层沟通,说明情况,保障进度的进行。

·遇到逃避责任问题该如何处理(2006-10-24) [作 者] 张力 [公 司] 深圳市金钢建设监理有限
公司

这个问题明显是分公司领导该担当责任,如果没有书面证据。势必对具体经办人处事能力的评价产生
不利评价。然而,现实之中又是国人的惯用方法。没有纠偏手段了,唯建议多留日志。平时多沟通创
造良好工作环境,有条件是尽力对既有管理程序作完善更新。

·应急储备金(2006-10-20) [作 者] Alan [公 司] 上海

项目经理手中的应急储备金是否足够? 超过的部分应从高层得到支持,而不应该是平级之间的沟通协
调。

·典型的责权不明确(2006-10-20) [作 者] 刘宇 [公 司] 大连市项目管理研究会

项目部只能有一个,设两个项目部本身就是错误的,容易造成责权不明确以及处理问题相互扯皮的情
况。

·项目经理有责任处理(2006-10-19) [作 者] 陈锋 [公 司] SEVEX

项目经理有责任处理在项目推进过程中的任何有影响工作的突发事件!不能因为承担责任问题把这个
事情托的时间过长让项目停止不前,采取措施如向有关人员说明情况或分散资金都是办法,事后在作
详尽处理,但是不能让项目停止不前.

·直接打电话给能拍板的人(2006-10-19) [作 者] 于佳 [公 司]

不确定性风险产生的资金,就是管理储备,不属于项目经理可调动的范围。项目经理应直接打电
话给能拍板的公司主要领导,由领导批准,直接调拨这部分资金进行使用,然后再后补公司的流程手
续。

·费用性质的原因,不可预见备用金制度(2006-10-15) [作 者] 方源 [公 司] 中国恩菲工程技

第 391 页 共 756 页
第 4 章 沟通管理

术有限公司

这似乎不是逃避责任的问题,而是公关费用的特殊性而引起的。海外项目应当建立不可预见备用金制
度,以区别于正常资金使用程序的方式提取和销帐。如果不是公关费用,而是其他能够提供依据(发
票)的费用,能够说清楚,就不会有现在的情况。所以特别是公关费用这种不可预见的费用,有了相
应的制度,才能发挥其时效。

·两个方面浅析(2006-10-08) [作 者] Louise [公 司] XX公司

这种问题应该说是比较常见的项目运作中出现的矛盾和问题,个人认为可以从两个方面进行分析和处
理:

1、项目经理具有决定权,需要比较强势的项目经理出来主持大局,充分的调动一切资源,利用一切
平台为项目的顺利进展披荆斩棘;
2、风险意识要具备,这是制度上的保障,以后可以设立风险储备金或者管理储备金来做为持续发展
的思路。

·三个方面(2006-10-08) [作 者] 谢明柱 [公 司] 中国天辰化学工程公司

人员素质、职位危机感、内部管理机制

·关键是企业文化。(2006-10-05) [作 者] 王丰江 [公 司] 北京华深

关键是企业文化。

·关键是企业文化。(2006-10-05) [作 者] 王丰江 [公 司] 北京华深

关键是企业文化。

·企业核心竞争力!(2006-10-03) [作 者] 罗杰 [公 司] tpbirds

提高客户的满意度,提高员工的素质,发扬企业文化,这是管理的先驱也是重要的基础,如果企业在
没有以这方面为导向,企业的带来的利润也不会让投资者们满意。

·遇到逃避责任问题该如何处理(2006-10-03) [作 者] badragon [公 司] 位无无我无

第 392 页 共 756 页
第 4 章 沟通管理

我觉得企业文化很重要,这是回避矛盾解决矛盾的基础

·1(2006-09-30) [作 者] 袁骥 [公 司] 伟擎厦门管理咨询有限公司

揪出来开公审大会!

·不是简单的责任问题(2006-09-22) [作 者] 林相谦 [公 司] 瀚亚建筑设计咨询

个人认为,各方都没有责任.

但是问题出在哪里呢?
是项目的不确定因素.

作为财务,按照公司规章办事,很正确.
现场项目经理充分利用职权为现场争取,也很好,
但是他也不能超越公司职权,只能在权力允许范围内帮忙.

公关人员也没有责任,但是公关的成败又是有一定时效的.

为什么不建议财务那边设立备用金制度呢?
如果每比支出都需要先申请了才用,那项目部就没有灵活性了.
有了备用金,项目部门可以边申请边使用,按时核算就好了.

同时项目部门也应该进行费用预估,难道项目部没有规划吗?
你要是将下一阶段的工作规划及费用需求预先呈报公司,
财务就会有比较充足的时间安排资金,这样不是更好吗?

·一切为项目(2006-09-20) [作 者] 于先生 [公 司] 南方数码

任何制度制定的最终目的都是为了盈利,而制度是死的人是活的。当一个关键的盈利机会受到制度的
限制时,必然需要一个可以把握全局权衡得失的人。这个人不是高层领导和普通管理者,而是整个项
目的负责人项目经理。项目经理最重要的职责是保障项目完成,过程中必然会遇到与制度冲突与人冲
突的情况,项目经理必须具备未知风险的遇见能力同时权衡多方面最终作出对“盈利”有益的决定。

·区分对待(2006-09-15) [作 者] giant [公 司] 上海某研究所

对待这件事情,我认为要分两个方面来谈

第 393 页 共 756 页
第 4 章 沟通管理

1)针对这事情本身,一定要按程序走,在程序走不通,想越程序时,一定要把握分寸,有些领导比
较注意事情的结果。
2)针对你们公司在制定这些规章制度时,一定要考虑,如果发生这些事情该怎么办的问题?应该提
请项目管理办公室修改制度。
另外还涉及到,贵公司采用什么样的方法来对底下的项目经理进行考核。如果给项目经理财务权的话,
这些也就不成问题。
项目经理应该一切为项目。不需要成为一个“好人”。文字

·项目经理应该勇于承担责任、但是要处理好方法(2006-09-13) [作 者] 游永明 [公 司] 广东
省计算中心

虽然项目是以完成为目的,但是公司的规章制度是必须遵守,这一点是原则问题。但是需要将制
度灵活应用,其实很多公司流程缓慢是一个多级授权的问题,必须有这样的一个“特事特办”的渠道,
否则就只能看机会的流逝。
因为一些变通可以顺一时之需,但是却埋下了后续的祸根,是要不得的。失去原则性立场,及时
打了一场胜仗却输了整场战争。
我比较认同就是电话直接联系主管人员,包括老总等寻求支援,走特办的之路。厚黑学之类的东
西不是普遍适用的,因为对公司有利不是你认为有利就有利的,切记!请示以后才有理。

·运用中国人的智慧(2006-09-12) [作 者] naqz [公 司] 软件公司

公司的制度要遵守,但作为一个项目经理应该对有些未发生的事件有预见力,通过风险分析把这些预
见到的事情提出,得到公司高层的授权和认可,这样 才能在发生事件的时候能得到公司高层的支持;
最好能拥有风险储备金,以应对这些事情的发生;或采用一些变通的办法来处理这些利弊权衡的事件

·处理不了,就辞职吧(2006-09-10) [作 者] 吴国栋 [公 司] 北京邮电设计院浙江分院

项目管理,是对项目内外资源的优化组合,对人力资源,物力资源,信息资源的综合利用,在分配,确保
项目顺利实施,按期提交项目交付物,连这一点都处理不了,那你辞职吧.

·当断就断!(2006-09-09) [作 者] 奥林匹克 [公 司] 中铁七局集团有限公司

项目经理应该在处理问题时坚决果断,只要对公司有利--项目经理就要敢于拍板,如果怕承担责任
--那就不胜任项目经理。

·特殊情况(2006-09-06) [作 者] chiao [公 司] 成都

第 394 页 共 756 页
第 4 章 沟通管理

出现这种情况,应该走正常的程序。现场的项目经理要与分公司的领导汇报,由于这种情况比较紧急,
所以分公司领导应及时向高层汇报说明情况,高层肯定会根据情况做出判断。
特事特办,然后是必须走公司规定的流程。

·个人看法(2006-09-05) [作 者] 中国武则天 [公 司] 电信公司

个人经验,请参考:
1 如果这笔费用着急使用,可以直接以电话或者电邮的形式直接与总裁或财务总监沟通,确定此笔经
费的需求,并要求总裁与公司财务总监尽快安排此事将经费按时划帐到位;期间申请人多做事情的跟
进;
2,为了避免同样类似情况发生,可向直接向主管申请安排国内专人负责此项目的财务或者其他方面的
后备支持工作。专人跟进,可以减少大量的时间和精力;

·一点经验(2006-09-05) [作 者] 陈华 [公 司] 123

这种情况我也遇到过.如果想一切按照程序来做,往往会错过决策的最佳时机.但如果不按程序来做,
往往会得罪很多人.我门以前的做法是用电话先沟通,尽快取得国内的支持,告之紧急程度,同时现场
按照需要推进.现在想起来,对一些作好事先的沟通最重要,否则在出事情以后,旧会出现扯皮现象

4.13 如何处理授权和监督?

如何处理授权和监督?

[姓 名] 宋喆 [单 位] 不公开 [邮 件] jingwas@hotmail.com
[所属行业] 综合应用 [所属主题] 项目进度管理 [发布时间] 2005-9-26

【案例正文】

曹昕新近被任命为 A 部门的中层领导,管理着 20 多个下属。他是个工作上非常尽职尽责的


人,决心认认真真地把新的职责履行好。
一天,曹昕让主管调研的邵岩了解和研究一下 B 国石油资源及石油领域对外合作的情况,并
整理成一份资料供上级部门决策参考。没有规矩,不成方圆;没有时限,就易拖延。这是曹
昕信奉的做事原则。他要求邵岩 10 天内完成上面的工作。
曹昕知道邵岩能力比较强,应该会很好地完成这项工作,但作为主管,为了保证工作质量和

第 395 页 共 756 页
第 4 章 沟通管理

时效,及时进行监督检察还是很必要的。不然,怎么能保证别人能像自己一样对工作尽心尽
责呢?于是,第二天,曹昕把邵岩叫到办公室,问道:“交给你的工作进展得怎么样了?” 邵
岩回答说:“正在努力进行中,已经有了具体工作思路和方法了。” 曹昕点头说好。第四天,
曹昕又把邵岩叫到办公室,问道“交给你的工作完成得怎么样了?” 邵岩回答说:“正在努力
进行中,已经有些眉目了。” 曹昕点头说好。第六天,曹昕又把邵岩叫到了办公室问了同样
的问题,邵岩回答说:“正在努力进行中,有信心按时完成任务。” 曹昕点头说好。之后,曹
昕隔一两天就会问起邵岩工作的进度。邵岩心里想:“既然头儿把这活儿交给我,我一定要
尽力在规定时间里完成,可曹昕为什么三番五次追问我进展情况呢?是工作很急吗?可既然
他让我 10 天内完成任务,而不是必须第二天就交稿,说明这活儿不那么急啊,但为什么他
又好像那么着急的样子呢?”
第九天,邵岩把仔细搜集整理好的一份 B 国石油资源及对外合作情况报告交给了曹昕,曹昕
终于露出了笑容,一项工作终于在规定时间内完成了。而邵岩心里却好像有那么一点说不出
的味道… …

·方式有待商榷,但是做法是对的(2006-04-27) [作 者] 安乃红 [公 司] AMDOCS-LONGSHINE

一项任务如何监督做的如何了?是每一个项目管理人员关心的问题。现在项目管理提供了很好的
思路,那就是设立合理的里程碑,有利于工作者的工作,更有利于管理这的监督。案例中的管理
者的做法可能让大多数人感觉不爽,但是他的思路是对的。但是有更好的做法,那就是任务下达
后,制定计划时就应改设立合理的里程碑,这样就不会让下级感觉不好了。

·如何处理授权和监督?(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

一个员工如果弄不清楚他是在为谁打工,他就不会有正确的做事动机和沟通态度。

·如何处理授权和监督?(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

作为上司,应该相信自己的部下能很好的完成任务,虽然曹很关心工作进度,看起来象是良好的
上司对部下的人文关怀,可是过度的关心会引起部下的怀疑——部下会怀疑上司是否在怀疑自己
的工作能力或者是工作的态度。

·如何处理授权和监督?(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

授权后就应该充分相信下属,要么就不授权

·guandian(2006-01-15) [作 者] 李冯 [公 司] BJG

"作为一个主管﹐有必要知道事情的进展状况﹐以免出现意外﹔
作为一个员工﹐有必要向主管汇报进展状况。"

我也同意这个观点

第 396 页 共 756 页
第 4 章 沟通管理

·guandian(2006-01-15) [作 者] 李冯 [公 司] BJG

1:首先,邵岩在汇报工作方面存在问题,没有明确的说能够按期完成
2:可能曹对邵并不了解

·向下沟通要区分沟通对象(2005-12-20) [作 者] 陈跃武 [公 司] 艾伯资讯(深圳)有限公


前面大家都从沟通的角度来看待这个问题,我也发表一下个人的看法,在项目管理中沟通管理是
很重要,也是最灵活的。就针对向下沟通来我个人认为是最难的一部分,但要做好这部分沟通,
首先就的对下属有充分的了解,了解他们的技术能力、工作习惯和风格以及性格,以此来区分他
们,并采取不同的沟通方式。案理中的邵岩能力比较强,但应该是个需要别人特别信任自己而又
不是很善于沟通的人员,就应该采取非正式的沟通方式,比如在吃饭或其它闲聊的过程中进行等。

·计划和控制的问题(2005-11-01) [作 者] 江留华 [公 司] 上海京海投资管理有限公司

我认为曹昕布置任务有问题导致下属不理解
1.布置了目标和总的时间限制,没有提出节点/控制性计划,不如分为 3 个步骤,一是基本思路,二是
框架结构,三是完整报告,并且赋予一定的时间要求.
2.邵岩也没有纠正曹昕的错误,提交一份哪怕是口头的报告,并将采用的步骤告诉上级.
3.曹昕尽管前面有不足,对控制的要求还是比较合理的,但由于没有计划的盲目控制,导致下属有
不知所措的感觉和不信任感,是思路性错误加方法性错位产生的必然结果.

·沟通需要诚信,也需要要技巧(2005-10-01) [作 者] 牛小林 [公 司] 有空就来

没有要求下属制定可行的计划,没有设立里程碑,没有制定阶段性可提交成果的明确定义,所以
造成了管理的混乱,和下属的埋怨,正所谓:

上情不能下达,则民惑
下情不能上达,则君疑

我认为在给绍发布任务得时候,应该注意一下几点:

1。强调项目的重要性。

2。规定项目汇报的时间点。

第 397 页 共 756 页
第 4 章 沟通管理

3。强调每次汇报需要看到的内容。

4。明确阶段成果的提交和评审要点。

5。在以上规则的基础上强调执行和落实,沟通才能真正的落到实处。

·也谈沟~态度是基础(2005-09-30) [作 者] 天羽 [公 司] 林源教育咨询

看了大家的分析都在围绕着沟通这个环节,我也来谈谈我对沟通的看法,简单的讲沟通就是说话,
说对方能够听得懂的话,说能让对方信服的话,说出来的话能给对方一种有效的信息...这才是沟
通的目的。而沟通是否有效,还要看对方的反馈,对方是否也和你一样。
从这个案例我感觉到邵作为一个能力强的员工,并不擅长沟通,也不懂得有效的沟通。领导问话,
只用一句简单的不能再简单的话来回答,而且话语中流露出来的都是有关自己能力强的信息,表
明邵的态度是有问题的,至少他没有弄清楚你是在为谁工作。
这是一个不能在俗的话题了。一个员工如果弄不清楚他是在为谁打工,他就不会有正确的做事动
机和沟通态度。如果邵明白他是在为曹打工,他就知道对待曹的关心要给予积极的回报,就会在
连续几天的问话之后认真的领会领导意图,或者用另外一种方式让领导安心。

总之,态度是沟通的基础,而技巧知识一种方法而已。

·项目沟通的方式(2005-09-29) [作 者] 赵伟强 [公 司] 上海复旦聚升信息科技有限公司

从本案例中看出,领导和下属中存在的问题是沟通方式的技巧。
虽然邵岩完成了报告,但是他心里有一个解不开的疙瘩,领导的关心也太多了,这种关心也可能
给邵岩造成一种工作的压力,有时候也会出现相反的结果。沟通方式的技巧,是一个领导必须注
意的问题。

·沟通需要诚信,也需要要技巧(2005-09-29) [作 者] 牛小林 [公 司] 北京直真节点技术开


发有限公司

没有要求下属制定可行的计划,没有设立里程碑,没有制定阶段性可提交成果的明确定义,所以
造成了管理的混乱,和下属的埋怨,正所谓:

上情不能下达,则民惑
下情不能上达,则君疑

·缺乏有效沟通的技巧(2005-09-28) [作 者] 银勇平 [公 司] 中南林学院

第 398 页 共 756 页
第 4 章 沟通管理

在授权前,根据下属是否有能力和责任心把下属分成四类,一般是对即有责任心和有能力的下属
授权。授权后就应该充分相信下属,要么就不授权。授权后就要注意对项目进展进行有效的沟通
与监督,来保证项目按时符合要求完成。但沟通要注意方法和技巧。很明显,曹跟邵缺乏有效的
沟通,每次只是问邵工作的进展如何,回答是“正在努力进行中,。。。。。。”
其实完全可以换一种方式来交流,如询问工作是否有困难,吃中餐一起交流工作经验中。这样,
即可以消除邵的埋怨的心理,有可以促使工作顺利完成。

·沟通是双向的(2005-09-28) [作 者] david [公 司] MITAC

作为一个主管﹐有必要知道事情的进展状况﹐以免出现意外﹔
作为一个员工﹐有必要向主管汇报进展状况。

·沟通是双向的(2005-09-28) [作 者] david [公 司] MITAC

作为一个主管﹐有必要知道事情的进展状况﹐以免出现意外﹔
作为一个员工﹐有必要向主管汇报进展状况。

·如何处理授权和监督(2005-09-28) [作 者] lionking [公 司] XXX

公开授权,并减少干预

·工作的主动性(2005-09-28) [作 者] 许华 [公 司] 江苏神羊投资集团有限公司

个人认为曹的授权给绍的任务已经非常清楚,曹因为是新官上任所以在所难免会显得工作很主动,
但是作为一名优秀的职工,绍他不但会按时按质的完成任务,而且在工作的同时应该要学会主动
上报工作的进度,以便上级第一时间处理可能出现的问题。所以在这里我认为,从另一方面来讲
等待上级来询问工作的员工并不是一个真正优秀的员工。

·良好的沟通从信任开始(2005-09-27) [作 者] 李福田 [公 司] 交通银行桂林分行

作为上司,应该相信自己的部下能很好的完成任务,虽然曹很关心工作进度,看起来象是良好的
上司对部下的人文关怀,可是过度的关心会引起部下的怀疑——部下会怀疑上司是否在怀疑自己
的工作能力或者是工作的态度。

·授权需要默契(2005-09-26) [作 者] 天羽 [公 司] 林源教育咨询

第 399 页 共 756 页
第 4 章 沟通管理

本案可以简单陈述为:邵的工作在曹的频繁检查督促下如期圆满完成。曹很满意,邵却没有同样
的感觉。

我们看到曹和邵在本案中是新-新关系,曹也关注到了这一点,在授权之后进行了检查,对来自邵
的不明确、不具体的回馈更采取了密集检查的方式,最终确保任务的有效达成,应该说他的做法
是正确的,只是结果难免让人叹息。曹在本案中一直在做的“事中”、“事后”控制,唯独没有
做好“事前”,没有让邵先作出一个简明的工作计划或是相互沟通完成任务的思路,直接在下达
任务后又没有明确检查计划的情况下开始“事中”和“事后”控制,这在新-新关系的上下级合作
中是最大的风险来源。

简单来看这是个三段论(事前/事中/事后)没有处理妥当的问题,实际问题却是认知层面上的。

这里我想阐明一个观点就是:管理以人为本。
是不是会有人笑我说这句话。的确这几个字都被用烂了,因为很多人没有认真的领悟其中的思想
和做事做人的方法。所以我想在这里陈述一下我的认知:以人为本,就是把别人当作人而且是别
人来看待,看到别人的优点与不足,理解别人和自己的不同,并以此做为认知基础,在管理中发
挥别人的最大效用。

现在,仔细看一下这个案例中,其中有三个层次的东西需要我们关注:
a. 基本要素:{ 曹| 邵直接上级,新上任,新职务,责任心很强,中层 }
b. 曹在布置任务的时候也是很合理的(任务描述清晰,选定能力强的邵去完成,约定了时限)
c. 曹主动检查邵的工作的起因是:曹期待别人也以同样的责任心来对待工作

个人以为曹的问题在 C 层面。我们说授权在前和监督在后,授权是在共识的基础上的资源管理权
的下放,检查则是在共识的基础上对过程产品的验证过程。“共识”就是一种工作上的“默契”。
所谓默契,就是很多事情都不需要去解释,也不需要去说明,不是很熟悉却是很信任,不是很清
楚却说的很明白......怎么才能在新-新关系中达到默契呢,那就是在承认别人和自己不同之后,
在“事前”和别人约定工作方法、规则等等

·项目沟通管理(2005-09-26) [作 者] 黄晓华 [公 司] 广东华联软件有限公司

从上面的案例中我个人看出一些问题:
设想曹昕是项目管理者,邵岩是项目成员。曹昕作为项目管理员,项目开始时应明确项目的目标,
完成的时间,充分授权邵岩来完成,并鼓励邵岩要有充足信心,以及项目完成情况要及时汇报曹
昕。这样曹昕也好监督或监管。我相信这样下来,后面的事情就可能不会发现,邵岩也不会有想
法或矛盾!而且以后更有信心做好其它工作!

·沟通方式需恰当(2005-09-26) [作 者] derikwoo [公 司] pps

第 400 页 共 756 页
第 4 章 沟通管理

从上面的案例我们可以看出一些问题:
首先,作为领导的曹昕,对给邵岩的调查任务的了解和估计不充分,在完成过程中邵岩有“不是
那么急”的想法,就证明曹指定的进度计划有问题,达到必要的完成时间,但是挑战性不足,导
致工作没有发挥最大工作效率。
其次,曹对工作的控制手段不合理,如果工作开始初,就将定期报告固定下来,或换一种轻松的
气分询问的话,可能邵就不会有后来的顾虑

4.14 如何统一不同部门对问题的认识?

如何统一不同部门对问题的认识?

[姓 名] 杨新华 [单 位] 不公开 [邮 件] yang_xinhua@yahoo.com


[所属行业] IT 软件 [所属主题] 项目沟通管理 [发布时间] 2005-10-28

【案例正文】
我们的项目是一个产品开发的项目,涉及硬件和软件,我是软件的负责人。现在项
目进入了关键的阶段。但是产品中出现了一个重大的问题。软件认为是硬件的问题,
而硬件认为是软件的问题。要彻底证明自己的东西没有问题是非常难的,只能从问
题的现象来分析。但是各有各的分析方法,谁也说服不了对方和老板。从我个人来
看,问题已经偏离了正确的解决方向。请教,我该如何处理比较好。

【相关分析】

·重要的是解决问题(2008-05-23) [作 者] 王玉娜 [公 司] 上海天马微电子有限公司

分析问题,明确责任,固然重要。可是大家是一个团队,当前最重要的是解决问题。建议请求专家援

·项目的前期工作重要性!(2008-02-11) [作 者] 董新山 [公 司] 佛山市顺德区雅富电子有限公司

在项目的前期时,对项目的工作与职则!项目的问题出现冲突时的相应一些措施制定!

·好问题(2007-11-16) [作 者] 郭林海 [公 司] 东软

第 401 页 共 756 页
第 4 章 沟通管理

这种事情在 IT 公司里是普遍存在的问题,可以采用同行评审的方法解决,即符合项目管理流程,又能够
解决问题(同行评审的目的就是解决项目的问题,采取对事不对人,一些大家信服的专家共同评判的方
式)

·化对立为统一(2007-10-24) [作 者] 李薇 [公 司] A

部门之间由于利益冲突造成的对立处处可见。如何化对立为统一是关键。
感觉你们公司缺乏一个对软件和硬件都有专长的核心人物,这个人物会在两者之间的沟通上起着关键
作用。
可以考虑将两个部门合并,部门主管可以从原来的软件或硬件部门主管中选择,这可能会造成另一位
落选者离开公司。但从长远来看,统一更有利于公司的发展。

·如何统一不同部门对问题的认识?(2007-08-30) [作 者] tjh [公 司] cxgs

当人进入死胡同的时候,很难找到出路;
编过程序的人应该知道一个词语叫“死循环”,解决办法只有终止它,然后才能再去想办法解决它;解
决其它问题也是如此,需要先停止它,通过其它的方面来解决此问题可能让人“得来全不费功夫”,请
第三方的专家不失为一个好的选择;
但这个第三方的专家要得到争论各方的认可的权威;否则也是无法说服大家,或者说给出的解释也是
让部分人员会怀疑的!

·内部分组 对立检验(2007-08-26) [作 者] lwghui [公 司] sddsasdadsadsa

有时也会遇到类似的事情。开会讨论也许是解决问题的方法之一,但是得注意无须追究责任,而是强
调目的是解决问题,强调沟通尊重,并指定专人解决问题。项目经理是解决问题的关键,应制定试验
或测试方案负责问题的解决。

·查明原因 分清责任范围(2007-08-26) [作 者] lwghui [公 司] sddsasdadsadsa

有时也会遇到类似的事情。开会讨论也许是解决问题的方法之一,但是得注意无须追究责任,而是强
调目的是解决问题,强调沟通尊重,并指定专人解决问题。项目经理是解决问题的关键,应制定试验
或测试方案负责问题的解决。

·营造一种解决问题的氛围(2007-05-07) [作 者] 姚振华 [公 司] 中兴

我想,这个应该与项目运作氛围有关系的问题。其实好多项目都会出现这个问题。
1.问题已经发生,无论如何,领导最想看到的是一条有用的解决途径,这个时候,争执过程,领导一
般不会说服某一方的。所以,此时,谁先退一步,反而是最具有优势,如果都不退,显然不是解决问

第 402 页 共 756 页
第 4 章 沟通管理

题的态度,领导最后只能各打 50 板,然后再安排你们不断的排查。
2.如果你能首先退一步,然后进行彻查,我相信还是能找到蛛丝马迹,如果真是你们的问题,勇于承
认,领导也不会追究的,如果不是你们的问题,会给对方更多的打击。退一步,给了你无限的运作空
间。
3.如果能结合这个问题,向对方表明,你作为负责人,你的态度就是一种仔细做事的态度,我想,后
续项目的运作,也会是一种良性运作。

4.请第三方并不是好选择。首先这是一个投钱的工程,其次,这也不是解决问题的方法,如果大家都
这样想,我回头立马成立无数咨询公司,呵呵。

·分工(2007-03-05) [作 者] 木头 [公 司] 燃气

............................................................产生这种情况的一个原因是双
方的界限分工不明确.或者是这个故障原因根本就没有查清楚.

·如何统一不同部门对问题的认识?(2006-12-24) [作 者] 刘用 [公 司] 广东省建筑集团公司

我同意天羽的做法,其实,这是很妙的一招,往往有的时候是没有办法区分清楚到底是谁的问题,也
许判断谁对谁错的代价大过解决这个问题,如果硬件或者软件都退让一步,问题说不定就解决了
换言之,一个问题可以有多种解决办法,现在我感觉你们陷入了分清责任而多于解决问题,出于部门
的利益,或许这个问题都不愿意退让,所以考虑外请一个专家,给以个裁决,然后大家分头行动,说
不定问题就解决了。

·如何统一不同部门对问题的认识?(2006-12-24) [作 者] 刘用 [公 司] 广东省建筑集团公司

作为软件也好,硬件也好,是整个项目的分项目,分项目之间的交接界面,集成的配合任务应该有整个
项目的负责人来计划\安排\控制和协调,在这一方面没有完成,作为项目的经理是不合格的.其次项目
的实施控制工作不力,对偏差的控制已经超出了正常的范围.总之,项目管理者负主要责任责,当然软
件部门和硬件部门也应该摒弃部门利益,公共来找到问题的症结所在,这才是解决问题的作法,是整个
项目的目标管理的要求.

·如何统一不同部门对问题的认识?(2006-12-24) [作 者] 刘用 [公 司] 广东省建筑集团公司

当人进入死胡同的时候,很难找到出路;
编过程序的人应该知道一个词语叫“死循环”,解决办法只有终止它,然后才能再去想办法解决它;
解决其它问题也是如此,需要先停止它,通过其它的方面来解决此问题可能让人“得来全不费功夫”,

第 403 页 共 756 页
第 4 章 沟通管理

请第三方的专家不失为一个好的选择;
但这个第三方的专家要得到争论各方的认可的权威;否则也是无法说服大家,或者说给出的解释也是
让部分人员会怀疑的!

·放弃专业身份,用知识解决问题(2006-11-29) [作 者] 相乡 [公 司] 南京

这种情况是经常遇到的,软硬件之间,硬件和结构之间,有时候,不仅仅是要找出问题在哪里,真的问题
的原因找到了,可能还存在一个多种解决方案解决的问题,是硬件改呢还是软件改的,这些都离不开协
作阿。
当然主要还是查找问题的原因。
相信凡是这样的问题,往往是用多种方法已经查找而原因未果的顽症,而且一般与软硬件都有关系,
而且往往不仅在这个项目中出现,在以后的项目中也还会出现。所以,如果你想做一个优秀工程师的
话,想办法找出原因吧,管他是软件还是硬件呢,只要你会的,你懂的,尽情地发挥吧。这可也是个
人成长的好机会呢。
作为管理者,就是鼓励大家协作想办法,尽情发挥聪明才智。当然千万不要在问题查清楚之前打板子,
在查找出问题后也不要轻易打板子,否则打得多了,大家就会因为怕板子而拘谨。再说了,研发过程
不就是问题堆积出来的嘛,多大点事呢~~~~~

·放弃专业身份,用知识解决问题(2006-11-29) [作 者] 相乡 [公 司] 南京

这种情况是经常遇到的,软硬件之间,硬件和结构之间,有时候,不仅仅是要找出问题在哪里,真的问题
的原因找到了,可能还存在一个多种解决方案解决的问题,是硬件改呢还是软件改的,这些都离不开协
作阿。
当然主要还是查找问题的原因。
相信凡是这样的问题,往往是用多种方法已经查找而原因未果的顽症,而且一般与软硬件都有关系,
而且往往不仅在这个项目中出现,在以后的项目中也还会出现。所以,如果你想做一个优秀工程师的
话,想办法找出原因吧,管他是软件还是硬件呢,只要你会的,你懂的,尽情地发挥吧。这可也是个
人成长的好机会呢。
作为管理者,就是鼓励大家协作想办法,尽情发挥聪明才智。当然千万不要在问题查清楚之前打板子,
在查找出问题后也不要轻易打板子,否则打得多了,大家就会因为怕板子而拘谨。再说了,研发过程
不就是问题堆积出来的嘛,多大点事呢~~~~~

·加强合作(2006-02-02) [作 者] johnson [公 司] 保密

一个项目质量的最终评价,由项目中质量最差的部分确定。无论是软件问题,或是硬件问题,只要有
问题,最终的评价都会受到影响。请求上级出面协调,也是解决问题的方法之一。

·ding(2006-01-15) [作 者] 李冯 [公 司] BJG

第 404 页 共 756 页
第 4 章 沟通管理

武晓燕的故事讲得好

·组织公司内部专家以紧急任务处理(2006-01-06) [作 者] yuqi [公 司] 创维

我从产品角度发表一点个人看法,
对产品而言,适时投放市场的时机最重要,如果该问题影响产品发布,且该产品对于公司来说很重要,
目前需要的是上级领导介入,指定公司内部此方面的专家,作为工作任务进行攻关,且该问题任务的优
先级就要设置的高,如果公司内的专家都解决不了,就要考虑修改产品的规划了.如果不影响产品发
布,可以考了修改规格,在原定计划时间内先发布产品.

·出了问题应该先找问题原因所在(2005-12-23) [作 者] duanlj [公 司] NBW

出了问题应该先找问题原因所在,涉及软件和硬件,就应该从两方面去找原因,而不是凭着猜测推卸
责任。

这个问题在一个项目里最容易犯了,我以前也碰到过。应该坐下分析问题,找出最可行的解决方案,
互相指责只能是浪费时间,扩大问题影响

·这样的项目团队还干不干事了(2005-12-15) [作 者] 武晓燕 [公 司] 一家软件公司做项目实


施工作

看了上面的问题,感觉
这是个什么项目团队,项目成员不积极解决或承担问题,而是推卸责任,问题发生肯定有根源,这样
的团队估计前期合作都不怎样,不看了,不管了
给大家讲个故事吧
一个公司年终总结
销售部说:今年的销售业绩不好,原因是对手层出新产品,但开发部却未能及时开发出新产品
开发部说:本来已经很少的开发经费,今年被财务部削减的可怜
财务部说:公司的财务很紧张,但是采购部的采购源材料的价格却很高
采购部却说:以前从俄罗斯采购源材料 是 1000 元/吨,今年由于自然灾害俄罗斯的源材料涨价所以
采购价格增高

听听,都有理由原来最终原因是俄罗斯国家的问题,公司各部门都没有问题。
哈哈

·团队之间的责任问题,需要艺术性的沟通(2005-11-23) [作 者] 拉尔夫 [公 司] 互联科技

第 405 页 共 756 页
第 4 章 沟通管理

此类问题很容易产生问题。一个产品由几个组独立完成各自部分。出现问题谁都是推卸责任。毕竟在
饭碗重要,各组采取这样的态度是人之常理。但是必须用智慧的能力完成这个问题。下面是鄙人的捉
见。
1、 软件项目组经理认识到问题所在,这个时一个好前提。但是问题所在是潜意识里存在一条:谁出
问题,老板就要打谁的板子,但是忽略了项目组之间因为相互干系的内容存在,必定存在这种系统之
间不配和的问题。也就是项目的 wbs 图上少了项目内容。即项目成立当初就要对这个有足够的风险评
估和意识。
2、老板真的因为谁出了问题就要打谁的板子了吗?也未必。
建议:双方项目经理可以通过私下沟通形成共识,在正确引导项目组成员和老板形成正确意识,纠正
项目中错误的意思,以共同完成项。

关键是软件项目的项目经理,必须积极和硬件组项目经理沟通,道明事理,即使对方一是不能理解,
也要耐心的游说对方。然后共同和老板沟通,纠正项目过程中的错误意识,达到共同完成项目的目的。

·出现这种扯皮的情况 主要原因就是一开始计划的时候对产品质量的没定义完整
(2005-11-21) [作 者] 赵宏伟 [公 司] 东信北邮

既然已经存在了这样的问题,首先就要先解决问题,而不是相互推诿相互扯皮,责任在哪一方是需要
后续分析的,现在关键是要把产品可交付成果提交出去。
现在处在关键阶段,就是解决问题,软件测试找原因,硬件测试也要找原因,其中测试就是最好的方
法!
这个“原因”不是为了给自己找原因找托词,目的是为了把这个项目的可交付成果提交出来!

计算机系统集成的项目硬件主要可能出采购设备选型上,硬件开发的接口规范是不是提供很完整全
面?
软件对接口的使用是不是按照接口规范进行?

·关键是进行查验(2005-11-20) [作 者] 王生 [公 司] 广州智能化有限公司

现在关键是制定出查找问题的方法:检查硬件的方法和检查软件的方法;而不是争论问题出在哪?

·项目管理体系不完善(2005-11-18) [作 者] 李刚 [公 司] 海达公司

看了您的困惑我曾经也深有体会,当产品进行连调时出现意想不到的问题。
这是在产品集成开发管理的环节上没有严格控制,在问题出现后也没有相应的错误分析计划来进行偏
差纠正,可以从项目的策划和设计书里先明确项目的目标和范围,在细化项目的组成部分,从整体的
角度分析产品应该达到的预期目的,开始建立里程碑管理的文档,确定软件应达到的程度,和硬件的
支持能力,协同分析。

第 406 页 共 756 页
第 4 章 沟通管理

·严格按照流程检查(2005-11-17) [作 者] 高明亮 [公 司] 北京博瑞巨龙

自测法
1、首先双方查看设计是否有漏洞
2、各方查看自己详细实现找原因,而且各方的内部人员要交换查看详细实现的方法,找漏洞。
3、测试要记录测试错误几率,查找几率,找规律,为分析错误提供帮助。
求助法:
1、找相关专家,分析,会诊。
2、双方联合分析查找原因。

·目的(2005-11-14) [作 者] monk [公 司] 华润涂料

目的是解决问题,何不饶开这个话题呢?!

·团队意识(2005-11-14) [作 者] 王海飞 [公 司] utstarcom通讯有限公司

楼主说的问题其实是一种现象,而真正的问题是:缺乏团队意识,没有团队概念。个人认为:首先向
两个部门明确表示我们是为了解决问题而来的,不是为了处罚谁而来的,让大家卸掉包袱;然后召集
两个部门的主要负责人和相应专家成立一个问题解决小组,共同制定一个问题解决思路;接下来就是
执行(建议采用 PDCA 方式)。

·管理不利(2005-11-14) [作 者] Wenyi [公 司] a Chinese in Canada

真正的问题不在你们部门之间, 问题的关键是没有强有力的领导, 唯一的解决之道是公司文化的重


新审视和价值观的调整, 从根本上解决问题而非此问题本身。

本人学识短浅,如有冒犯之处,请原谅!

·加大逃避责任的风险(2005-11-12) [作 者] 许野平 [公 司] 济南黑格软件有限公司

一、问题条件
1.产品中出现了一个重大的问题。
2.软件认为是硬件的问题,而硬件认为是软件的问题。
3.要彻底证明自己的东西没有问题是非常难的,只能从问题的现象来分析。
4.但是各有各的分析方法,谁也说服不了对方和老板。

第 407 页 共 756 页
第 4 章 沟通管理

二、问题分析

双方都试图推卸责任。即使出现了问题为什么大家还愿意推卸责任呢?原因是在公司现有管理制度下
任何一方不会因为推卸责任承担更多的责任,最后让公司老板当冤大头。

三、解决方案

办法很简单,让双方各自检查自己的问题。还检查不出问题来,那就的立下军令状,委托第三方检查。
如果被第三方查出问题,要对责任一方进行超大力度的处罚,一定让逃避责任一方吃不了兜着走!

·查找原因,解决问题(2005-11-10) [作 者] lemme Wang [公 司] 不提供

这样的事情我也遇到过,我们开发的软件在公司的电脑上运行很快,一到客户那里运行就很慢,为这
个问题开过很多会,讨论、争论,有说软件问题、有说客户网络问题、环境问题等等。但我们在争论
时没有去追究谁的责任,整个过程都是很和谐,这是归于团队的沟通建设:强调和谐、包容、沟通、
尊重、求同存异,强调解决问题为目的,指定人手专项解决此问题,列出 CheckList,类似鱼刺图的
方式来查找问题,最终还是查到了原因,并将问题解决了。不过,在解决问题前,一定要让有关人员
知道,此问题并非一朝一夕就能解决,但也不要因为一朝一夕不能解决就拖,总之要提上日程,随时
跟进,以便会诊,这样有关人员也就会知道在解决问题,各同事也在努力,并付出了努力,只要付出
了,问心无愧即可。

·查找原因,解决问题(2005-11-10) [作 者] lemme Wang [公 司] 不提供

这样的事情我也遇到过,我们开发的软件在公司的电脑上运行很快,一到客户那里运行就很慢,为这
个问题开过很多会,讨论、争论,有说软件问题、有说客户网络问题、环境问题等等。但我们在争论
时没有去追究谁的责任,整个过程都是很和谐,这是归于团队的沟通建设:强调和谐、包容、沟通、
尊重、求同存异,强调解决问题为目的,指定人手专项解决此问题,列出 CheckList,类似鱼刺图的
方式来查找问题,最终还是查到了原因,并将问题解决了。不过,在解决问题前,一定要让有关人员
知道,此问题并非一朝一夕就能解决,但也不要因为一朝一夕不能解决就拖,总之要提上日程,随时
跟进,以便会诊,这样有关人员也就会知道在解决问题,各同事也在努力,并付出了努力,只要付出
了,问心无愧即可。

·查找原因,解决问题(2005-11-10) [作 者] lemme Wang [公 司] 不提供

这样的事情我也遇到过,我们开发的软件在公司的电脑上运行很快,一到客户那里运行就很慢,为这
个问题开过很多会,讨论、争论,有说软件问题、有说客户网络问题、环境问题等等。但我们在争论
时没有去追究谁的责任,整个过程都是很和谐,这是归于团队的沟通建设:强调和谐、包容、沟通、
尊重、求同存异,强调解决问题为目的,指定人手专项解决此问题,列出 CheckList,类似鱼刺图的

第 408 页 共 756 页
第 4 章 沟通管理

方式来查找问题,最终还是查到了原因,并将问题解决了。不过,在解决问题前,一定要让有关人员
知道,此问题并非一朝一夕就能解决,但也不要因为一朝一夕不能解决就拖,总之要提上日程,随时
跟进,以便会诊,这样有关人员也就会知道在解决问题,各同事也在努力,并付出了努力,只要付出
了,问心无愧即可。

·关键是解决问题(2005-11-08) [作 者] sun zhaopu [公 司] 阿尔卡特

对于项目经理而言,关键是解决问题。应该先搁置对问题责任的争论和承担。应该成立一个联合工作
小组,联合制定试验或测试方案,直接向老板或项目经理汇报,负责问题的解决。至于问题的责任承
当问题,事后再论吧

·静下心来解决问题吧!别推责任。(2005-11-07) [作 者] 陈晨 [公 司] 河北保定智能电脑有
限公司

在自己的范围内首先要严格证明问题不是出自于软件部分。其次
分析硬件的设计,和验证,有证据证明出自于硬件也可。找到对方的明确的问题原因并提出证据。以
适当的方法追究责任。
没有人关心什么问题除了开发人员。他们都看整个的产品。
软件硬件都有一个接口点。根据要求进行接口点数据的检测。如果都符合前期的设计,并且仍然存在
问题,那么问题就是设计时期的问题。向上分析吧。请专家来,也要了解所有的设计否则也不能很好
的解决问题。静下心来一起慢慢分析。

·超出死胡同,(2005-11-07) [作 者] 褚四斌 [公 司] 中国广东

当人进入死胡同的时候,很难找到出路;
编过程序的人应该知道一个词语叫“死循环”,解决办法只有终止它,然后才能再去想办法解决它;
解决其它问题也是如此,需要先停止它,通过其它的方面来解决此问题可能让人“得来全不费功夫”,
请第三方的专家不失为一个好的选择;
但这个第三方的专家要得到争论各方的认可的权威;否则也是无法说服大家,或者说给出的解释也是
让部分人员会怀疑的!

·扭曲(2005-11-06) [作 者] 天羽 [公 司] 林源教育咨询

这个案例的起因是技术冲突,但是现在已经演变成面子问题了。无论这个案例最后采用什么方法解决,
我们都看到了一个不愿看到,但是却经常看到的场面:扭曲的心态。
这里说这个词语,没有褒贬之意,更没有厌世疾俗的意思,只是感叹高层管理者的无能和优柔寡断,
导致了技术问题冲突升级为复杂的情感类问题的解决。

第 409 页 共 756 页
第 4 章 沟通管理

·ww(2005-11-05) [作 者] wxq_ww [公 司] zte

哥们,还是先搞好内部团结,有问 ww 题一块解决..

·只赏不罚 自我揭短(2005-11-04) [作 者] 王兴阳 [公 司] 西安

如果只是为了解决问题而不是研究责任,可以实行只赏不罚的形式,将软件分为两组,其中一组只能
提支持自己的观点,另一组只能提反对自己的观点.
对于硬件也是如此.
这样就有助于问题的解决,而且相互交流,发现自己的缺点,积累经验,同时免去了第三方在知识上
的不足,而且节约成本.

·问题从根源找起!(2005-11-04) [作 者] 韦少才 [公 司] 桂林空军学院 7053

每个项目在开发规划时都制定了项目的工作计划,并确定了每个阶段的里程碑。既然现在出现了问题,
而又没有人承担责任那就查阅以前的计划书,看看自己管理的子项目是否一直都是严格按照计划书的
要求来完成的,是否有严重的出入。如果这时还不能解决问题,那么应该不是在项目规划/分析阶段
时出问题就是在在项目工作中项目经理不能及时的发现问题,从而使问题积累到现在这种地步。

·跳出盒子(2005-11-04) [作 者] 天羽 [公 司] 林源教育咨询

引进第三方评审是讲究技巧的,我前面的建议中说得很简单,这里在提几句。找旁人来评审并非要给
个论断或是决定,而是利用第三方的角色优势来调和内部气氛,“退一步海阔天空”,以此来促进问
题的解决。

我们的工作中经常会遇到这类的情况,第三方介入就是给大家一个再次重申内部已经耳熟能详的理由
或借口的机会,然后由专家给出一个硬性方案,此后的所有的矛头就会指向外来的专家,软硬件部门
就会心照不宣的开始合作了...“外来的”的作用就是调和并公然树敌,引发内部的再次合作。

对比很多的案例,我们知道内耗是就大的消耗。最最现实的例子就是抗日战争。

·推进问题的解决,关注重点(2005-11-03) [作 者] 倪勇飙 [公 司] 卡迪数据

有没有界定 SOW,如果没有,查阅需求,还没有,就要求大家坐下来开会,同时自己要站对角色,一
对一,和你的老板一起打太极拳式的和客户以及其他相关人员把问题解决,但记住千万不能针对人

第 410 页 共 756 页
第 4 章 沟通管理

·推进问题的解决(2005-11-02) [作 者] 贺晓宁 [公 司] 中科院软件所

引入第三方评审,不失为一种好方法,但是我觉得这种方法需要很多的资源,可能造成进度的滞后,
为了解决问题第三方的评审需要从头了解项目的开发
作为子项目负责人(软件部分),我觉得应该首先进行软件方面的分析调查,提出客观的分析结果,
并不是为了逃避责任或者去承担责任,而是利用自己的资源推动问题的解决

·整个项目的管理者/项目经理的问题(2005-11-01) [作 者] 江留华 [公 司] 上海京海投资管


理有限公司

作为软件也好,硬件也好,是整个项目的分项目,分项目之间的交接界面,集成的配合任务应该有整个
项目的负责人来计划\安排\控制和协调,在这一方面没有完成,作为项目的经理是不合格的.其次项目
的实施控制工作不力,对偏差的控制已经超出了正常的范围.总之,项目管理者负主要责任责,当然软
件部门和硬件部门也应该摒弃部门利益,公共来找到问题的症结所在,这才是解决问题的作法,是整个
项目的目标管理的要求.

·主动些,积极些(2005-11-01) [作 者] 梁桢 [公 司] 上海广平信息系统工程有限公司

首先,不管是软件部门或者是硬件部门都不愿花费大量时间用在寻找问题上,都寄希望对方能发现问
题。所以各自若都采取这样消极的方式只能拖延实际问题的解决。

其次,在希望对方能找出自身问题的同时,又不能确信自身是没有隐患的。若对方经过核查确定没有
问题的情况下,本身会存在很大的危机(技术、管理、人事等方方面),处于被动地位,更会担负起
拖延项目进度的责任。

所以 2 个部门最好的方法是各自寻找问题,确保自身不存在致命的错误。

做为部门领导应该有对问题拖延导致后果的认识,更应该做好团队内部团结和协调工作。

而整个项目的负责人应该积极处理 2 个不同团队对问题推诿情况的协调。

做为楼主应该主动且小范围的开始寻找问题可能出现的环节,工作的停滞情款分析时首先被“开刀”
的就是你哦。

·形成正确的工作态度和团队氛围,做好管理衔接和技术衔接(2005-11-01) [作 者]
globemobile [公 司] globemobile

“问题已经偏离了正确的解决方向”,是的,现在硬件和软件都害怕承担责任。所以,先要明确:首

第 411 页 共 756 页
第 4 章 沟通管理

要的任务是解决问题、而不是追究责任找哪个部分的错误。这样有助于形成正确的工作态度和团队氛
围。

此外,在管理中,还应该再下功夫,做好两部分的管理衔接;在技术上,还应该再下功夫,做好两部
分的技术衔接。

·如何统一不同部门对问题的认识(2005-10-31) [作 者] 黄雷 [公 司] 湖北工业大学

我想部门不统一应该是由于上一级的领导工作没有作好

·这是个什么样的问题(2005-10-31) [作 者] 孙先平 [公 司] UT斯达康中国有限公司

需要在项目团队中明确(brainstroming):
1\这是一个问题吗?
2\这是一个怎么的问题?
3\这个问题如果是我的问题,那可能的原因是什么?
4\产生原因的可能解决方法是什么?有没有测试或解决办法?
5\如果我们都没有问题,那怎么还有问题?
6\如果我们没有能力解决这个问题,那么建议公司,就这个问题,另外成立个项目组来解决这个问题!

·另辟蹊径(2005-10-31) [作 者] 牛小林 [公 司] 有空就来

我同意天羽的做法,其实,这是很妙的一招,往往有的时候是没有办法区分清楚到底是谁的问题,也
许判断谁对谁错的代价大过解决这个问题,如果硬件或者软件都退让一步,问题说不定就解决了
换言之,一个问题可以有多种解决办法,现在我感觉你们陷入了分清责任而多于解决问题,出于部门
的利益,或许这个问题都不愿意退让,所以考虑外请一个专家,给以个裁决,然后大家分头行动,说
不定问题就解决了。
外来的和尚好念经,好!!!

·不统一认识影响问题的解决(2005-10-31) [作 者] 杨新华 [公 司] UTStarcom

现在的问题是,这是一个很难解决的技术问题,第三方的专家很难找到。而不统一对问题的认识已经
严重影响了问题的分析解决,把问题的分析引入了错误的方向。

·不统一认识影响问题的解决(2005-10-31) [作 者] 杨新华 [公 司] UTStarcom

第 412 页 共 756 页
第 4 章 沟通管理

现在的问题是,这是一个很难解决的技术问题,第三方的专家很难找到。而不统一对问题的认识已经
严重影响了问题的分析解决,把问题的分析引入了错误的方向。

·我赞成天羽的观点(2005-10-30) [作 者] 牧野李 [公 司] 河南通信

在你们内部无法解决问题时,第三方专家评审也许是最重要的

·外来的...好!(2005-10-29) [作 者] 天羽 [公 司] 林源教育咨询

俗话说:外来的和尚好念经。

我建议你们做一个专家评审,通过第三方评审来验证系统的问题,责成有关方面改进。

·力量要用到一起(2005-10-29) [作 者] 刘志刚 [公 司] 天津光电集团

对于产品的开发,主要靠的是大家的共同努力和较强的技术力量才能实现。你们现在的问题已经从开
发的角度偏离到谁有没有问题的角度了。其实说开了,大家一起负责的项目,早日开发出产品才是正
确的道路,又何必在现在这个时候讨论是谁的问题呢?如果真要讨论等产品开发出来之后的总结会上
又大家说话的时间。恐怕到那个时候大家已经没有心情去讨论这个问题是软件还是硬件的问题了。

·没有解决不了的问题(2005-10-29) [作 者] 孙先平 [公 司] UT斯达康中国有限公司

没有解决不了的问题,况且只是个技术问题!这么说,并不是大话。因为管理中最难搞的是人的问题,
所以如果技术问题没有能够解决(只是双方都死皮赖脸的不承认错误而已),那就变成一个管理问题,
是“人”的问题了。
关起门来,就事论事,软件组,如果是软件方面的问题,那有可能是那些地方存在问题;硬件组,如
果是硬件方面的问题,那有可能是那些地方存的问题。让双方冷静下来,想想如果是自己的问题,那
会是怎么的问题?
也许两个组都会告诉你,不可能是他们的问题。那就是一个没有办法解决的技术问题,提升问题
解决的层次吧!这两个问题,目前项目中的技术力量无法解决。

·系统观点,专家评审,满意原则(2005-10-29) [作 者] fortruthh [公 司] EMR

软硬件组关于问题的定位争论是行业内普遍存在的现象,‘说服对方’往往是双方解决问题的出发
点,同时也恰恰是抱怨对方和被对方抱怨的焦点。我的观点非常明确:“系统观点,专家评审,满意
原则”:

第 413 页 共 756 页
第 4 章 沟通管理

1、系统观点:软件、硬件是个系统,出现问题需要系统分析、定位和在系统的层面上解决,这是根
本观点。一个项目经理,无论是由软件人员还是和硬件人员担任,需要树立此观点,同时传递给软硬
件组成员。这是意识层面的原则;
2、专家评审:有矛盾是必然的,需要一个体系而不是个人来保证问题的解决。组织内建立固定分级
分层的评审体系非常必要,评审原则、评审人员、评审方式确定后,对问题的分析定位以及决策就有
法可依,这是组织层面的对策;
3、满意原则:这种说法不一定全对,而且可能遭砖头。我的理解是在问题明确定位(问题定位是大
是大非原则,即不是你对,就是我对)后,如何确定解决方案的过程中,同样容易出现争执,如软件
更改还是硬件更改,怎样才是最佳解决方案?此时就要遵循满意原则,因为说到底它是一个决策。文

·这个时候自己要尽可能拿出能说服对方认可的东西(2005-10-28) [作 者] 任密林 [公 司]
EPSON

这个时候我想大家应该本着解决问题的态度,实事求是进行客观的分析,多沟通。在不能认定问题出
在哪个组的时候,我想最主要还是从自己组入手寻求能够说服对方,让对方认可你的客观事实,包括
演示给对方作为上层软件部分的调试过程。不清楚您说的具体是什么项目,比如象单片机系统的软硬
件开发的话,我想只要逐步跟踪调试一定回找到问题是所在的。

·查找问题根源(2005-10-28) [作 者] bluesnow [公 司] 上海

你说的这个问题,在涉及到软硬件产品的研发中很常见,我也是做软件的。既然碰到了问题,那就表
示该项目确实存在着不足,主要矛盾,并不是要说服对方,是对方的问题。 我觉得应该要大家一起
来解决问题,找到问题的根源,可以通过多种方式来实现,如软硬件组进行讨论,联合实验调试,来
确诊问题的所在,找到问题后,解决就很容易了。

4.15 如何协调这样的关系?

如何协调这样的关系?

[姓 名] derikwoo [单 位] 不公开 [邮 件] derikwoo@hotmail.com


[所属行业] 综合应用 [所属主题] 项目沟通管理 [发布时间] 2005-9-5

第 414 页 共 756 页
第 4 章 沟通管理

【案例正文】
现在的一个项目正在实施,我是做技术开发的;项目经理是上面亲点的,做事很自我,听不
进别人的建议。我多次和他发生争执,但因为上面的关系,不但没有提醒他,反而让他很得
势,眼看项目已经开始恶化,如果这样下去项目一定会失败。请问这样的关系怎么协调?我
应该怎么做?如何和上面反映这些现实情况,目前阶段我怎么和项目经理相处?

【相关分析】

·凝聚力(2008-04-28) [作 者] 连甲虎 [公 司] 力帆汽车

我认为,做为一个醒目只能有一个项目经理。也就是说项目的最高领导人只能有一个,不能谁说了都
算。而且建议管理人员莱担任此任。
一个优秀的管理者会让整个团队充满活力,会让每个人都充分发挥他的能力。

·各自为政,不行吗?(2008-03-07) [作 者] 莫学赶 [公 司] 浙江邮海电子有限公司

你们是不是因为性格不合,或者是处事方式方法不同,还是关系到自身利益问题?

听你一面之词,好像他这位仁兄很主观,总认为自己一切都是对的,别人对自己必须绝对服从。他是
不是一个彻头彻尾的权力崇拜者。他这样搞,很不聪明。你们不可以各自为政吗?你管技术,他管行
政和协调。凭什么要绝对服从?你有你的专业强项,他也有他的强项,他也有你专业领域的盲点,反
之你也是,不能说服就各管各的。军队里都还有军事首长和政委呢,至少《亮剑》里就是。

同时,鉴于项目恶化的现状,应请示更高一级领导的意思,必须客观的呈现真实现状,让他们来决定
项目发展的大方向和策略。协调你和他之间的关系,如果你们自己不能自行解决,那就请你们的直接
领导解决吧,你们之间不至于是有个人恩怨吧?

·认同差异,主动沟通(2008-01-09) [作 者] 江西早 [公 司] 兴库建设投资有限公司

首先端正心态。建议尊重项目经理管理的条件下,积极发挥技术干部的作用。技术干部通常在能够认
识到技术的不足和管理的特殊时,会得道多助的快速发展!
其次承认差距。即使两个技术干部,对同一个技术问题也会有不同的看法,何况技术干部与管理干部
呢?承认差距,主动站在管理干部的立场上思考和分析,会获得意外的进步,更会赢得管理干部的支
持和尊重。
最后主动沟通。和上司处理好个人关系,是技术干部个人职业生涯规划的重要战略目标。积极学习个
性与沟通的技能,注重沟通实践提高,很快项目经理与你之间,可能就形成相见恨晚的互补关系也可
能啊!

第 415 页 共 756 页
第 4 章 沟通管理

·做人做事(2007-12-05) [作 者] 吴涛 [公 司] 黎明

再见 再见 不能说服只能说再见 再见再见再见

·主动进行沟通(2007-11-17) [作 者] 李先生 [公 司] 北京城建

1、首先要把自己的工作做好,不能由于对项目经理有意见而影响自己的工作。
2、要主动和项目经理进行沟通,如果自上而下行不通的话自下而上也是比较好的办法。

·沟通(2007-11-04) [作 者] sanyiecao [公 司] tielu

既然他是项目经理,自然也不希望项目失败或不能如期完工。可从这方面入手,对他晓之以理。让他
知道目前的情况如果在持续下去,项目很可能会失败或不能如期完工。并让他知道原因和你的解决之
道。

·傻(2007-10-12) [作 者] 李佳席 [公 司] 上海盛世彩虹信息咨询有限公司

再见 再见 只能说再见再见 再见 只能说再见再见 再见 只能说再见再见 再见 只能说再见再见 再


见 只能说再见再见 再见 只能说再见

·沟通从心开始(2007-09-27) [作 者] 崔吉宏 [公 司] 中原油田

我认为这不单单是项目经理为人的问题。做为项目成员,我们有时候也要摆正自己的位置。一个良好
的团队不能在项目运作中,出现对人而不是对事。

·41231(2007-09-18) [作 者] 松 [公 司] 天啊

李强是 A 公司的项目经理,其管理风格非常严厉。他要求团队成员严格遵循他的指示,强调使用正式
和非正式的控制方法,两年前在他被任命为项目经理时,很多人感到不满。在他任项目经理的前半年
中,14 个工地管理、工程和技术人员中有 8 个相继转到公司别的项目组或离开公司,而正当 A 公司
老板想调走李强的时候,紧张的局势得到了缓解,项目组中留下来的人及李强任命的人都接受了他的
领导方式。

在李强任期中,他成功地将项目建设成本减少了 10%,其进度也达到了项目管理分部主管、客户和建
筑师的要求,他对项目的管理紧张而有效,后来被另外一家公司相中,随后就跳了过去。

A 公司老板准备在项目组中提拔一个项目经理,但他发现没有人是李强的助手或可替代的人,后来,
老板安排首席测量员陈刚来担任项目经理。

第 416 页 共 756 页
第 4 章 沟通管理

·如何协调这样的关系?(2007-08-30) [作 者] tjh [公 司] cxgs

首先让 PM 了解下面程序员的想法,如果只是你一个人与他有意见,那么要反醒一下自己,如果是大多
数人都与他意见不和,恭喜,你们已经找到解决办法.

·做事与做人的道理(2007-08-28) [作 者] 董新山 [公 司] 荣文灯饰(东莞)有限公司

管理是怎样做人!不要自认自己是做技术开发,要把自己的工作做好就是了!项目经理是项目的领导
者及协调者,首先,把目前的项目进展状况的报告交给项目经理看,并在报告中阐述自己的看法!再
次,要认识到项目是团对共同的事情,不项目经理一的事情!用数据说话跟上级领导进行沟通与协调!

·My Opinion(2007-08-28) [作 者] 林先生 [公 司] ABC

please change communication method and just provide suggestions, not quarrel.

·My Opinion(2007-08-28) [作 者] 林先生 [公 司] ABC

please change communication method and just provide suggestions, not quarrel.

·My Opinion(2007-08-28) [作 者] 林先生 [公 司] ABC

please change communication method and just provide suggestions, not quarrel.

·建议(2007-03-05) [作 者] 木头 [公 司] 燃气

............................................................适当的建议,担不是争吵,毕竟
权力和职位在限制你的能力发挥.所以建议在建议方式上有所改变,委婉一些,当他遇到困难的时候,
也许还会想起你,重新考虑

·my viewpoints (2007-02-01) [作 者] HSP [公 司] secret

1,You scarce some communication skills;


2,Adjusting your attitude toward this PM;
3, You can report the current problem you meted to your PM and your GM at one time;
4,You must understand that the PM consider all the status for his project, and you maybe

第 417 页 共 756 页
第 4 章 沟通管理

think about your technology only .

5, You must know clearly your responsibility.

·如何协调(2006-11-26) [作 者] tigerdeng [公 司] FIBERHOME

项目恶化对你见得是坏事,因为任何一个公司作项目的目的是调动资源完成项目,项目失败再有关系
的上级也保不了项目经理,作为项目中的技术负责人应努力沟通,配合项目经理,有很多问题只是认识
问题,应加强沟通,很多问题可通过协调解决

·我也遇到类似的问题(2006-11-10) [作 者] 王海艳 [公 司] formtek

我也遇到类似的问题,那时年轻,脾气暴躁,不懂沟通技巧,结果很糟糕。
内行人最讨厌外行人指导。
他是上面派下来的。说白了就是监工,就是看着你们的。
而他本人又自挖,自大。你的目标是把这个项目做好。无论遇到什么样的困难。既然他是那样自我,
自大的人,就多拍他的马屁,奉承他几句,明明他不懂,说他专业。
对上层不好直接说这个经理的坏话,遇到分歧,一定从有利于公司的角度讲话。
别急,慢慢来。

·如何协调这样的关系?(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

让项目恶化下去并不一定是坏事,等项目彻底失败了,或者这个项目经理多失败几个项目,问题不就
解决了吗?这个办法有些极端,但有时只有这样做才能解决问题!

·如何协调这样的关系?(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

首先让 PM 了解下面程序员的想法,如果只是你一个人与他有意见,那么要反醒一下自己,如果是大多
数人都与他意见不和,恭喜,你们已经找到解决办法.

·如何协调这样的关系?(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

一个项目都是我们成长中的一个经历,我们都经历的是这些因为某些原因可能会失败的项目时的态度
就是放之任之,那我们对的起自己吗,

·如何协调这样的关系?(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

第 418 页 共 756 页
第 4 章 沟通管理

一个项目中,项目经理与技术专家发生认识上的矛盾是很常见的,但是很多事情,双方可能只是认识
上的不同,不一定就是谁对谁错。这种情况下需要一定的妥协,这是一个团队精神的问题。另外作为
项目经理很多时候是从一个项目的总体考虑事情,而开发人员很多时候只是从局部去看问题。

·如何协调这样的关系?(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

与项目组其他成员沟通,他们是否认同你对项目的判断.整个项目组人员可以开会以汇报项目情况的
方式提供建议.不过要摆正自己的位置和心态,你只能提供建议,没有决定权.也要注意自己说话的
语气.

·guandian(2006-01-15) [作 者] 李冯 [公 司] BJG

"(1)从楼主的文字看,对项目经理的意见已经很大了,已经对其性格进行批判,因此我认为这种情
况下的对具体事情下结论可能是不客观的。
(2)一个项目中,项目经理与技术专家发生认识上的矛盾是很常见的,但是很多事情,双方可能只
是认识上的不同,不一定就是谁对谁错。这种情况下需要一定的妥协,这是一个团队精神的问题。另
外作为项目经理很多时候是从一个项目的总体考虑事情,而开发人员很多时候只是从局部去看问题。
(3)做为项目中技术人员,可以对项目实施发布意见,但是有一点是必须要注意的,就是发表意见
的方式不要蔑视项目经理的管理权威,如果这样可能永远是双输,你的好的想法和意见不能得以实现、
项目本身进展不好,更有可能导致项目经理觉得你不可用的想法。
(4)很多时候技术人员和项目经理对项目成功和失败的理解是有偏差的,技术人员可能觉得技术落
后就是失败,而项目经理的对是否失败的判断就是是否按时保证质量完成项目要求。
(5)如果你的经验(我指在整个项目操作上,而不是技术开发上)真的有很多对方比你的经理强,
那么可用系统的阐述一下问题,最好写个 email,来全面阐述你的理由和看法,但是要只针对事情,
有条理有依据的发表意见,这个 email 也可用同时抄送给你的项目经理的上级。只要你的目的是为这
个项目好,那么矛盾都是可以解决的。"

同意这个观点

·guandian (2006-01-15) [作 者] 李冯 [公 司] BJG

"纯技术人员有一个问题,就是单纯地从技术角度出发,而不管实际情况。当然不是说这样不对。(实
际上这是对工作负责的一种表现)但是否可以换一个角度看问题。比如很多时候因为时间、人员、资
金的问题,不可能将问题解决得那么完美,有时候甚至是需要掩盖问题。这个时候技术人员就必须配
合项目管理人员。还有一个问题,技术人员总是喜欢提出问题,而不提解决方法,这对管理人员来说
是一个麻烦。因为他毕竟不是技术大拿,如果技术人员在提出问题的时候,可以提出几个解决问题的
方法供管理人员选择,不论对你们的关系,还是实际问题的解决都有好处。最后要说明是。的确是有
一些项目管理人员很不地道,如果真是这种情况,最好的方法是离开这个项目。这个项目的失败是必

第 419 页 共 756 页
第 4 章 沟通管理

然的。单靠技术人员的个人能力是无法挽回的。"

同意

·站在公司的角度沟通(2005-10-24) [作 者] 陈志刚 [公 司] HEQIYUAN

建议你分析发生争执的焦点在哪里?你要诚恳地和项目经理交流,并进行换位思考,双方站在公司的
角度进行有效的沟通,相信争执会得到解决。

·re:如何协调这样的关系?(2005-10-17) [作 者] Hans Ye [公 司] 上海

不明白楼主问的问题
有什么事情需要你协调,协调是你份内的工作吗?作为一个技术人员在项目组里面承担的角色贵公司
没有定义吗?
如果项目组里的每一个成员都跳出来协调相互关系的话,项目经理就有事情做了,他的价值这时候就
体现出来了,首先要让团队成员目标趋同……
现在很多项目就是官不象官,兵不象兵。连士兵都做不好,还要做什么将军。我觉得楼主的问题首先
就是一个职业素质问题,典型的愤青:项目开始的时候,觉得自己什么事情都关心,项目出了问题就
说自己是技术人员,啥事都不管,如果我是你的项目经理第一个就解决你的思想问题,解决不了的话
就把你请出我的团队。

·从多个调度看问题(2005-10-17) [作 者] 边强 [公 司] 北京中科院软件中心

纯技术人员有一个问题,就是单纯地从技术角度出发,而不管实际情况。当然不是说这样不对。(实
际上这是对工作负责的一种表现)但是否可以换一个角度看问题。比如很多时候因为时间、人员、资
金的问题,不可能将问题解决得那么完美,有时候甚至是需要掩盖问题。这个时候技术人员就必须配
合项目管理人员。还有一个问题,技术人员总是喜欢提出问题,而不提解决方法,这对管理人员来说
是一个麻烦。因为他毕竟不是技术大拿,如果技术人员在提出问题的时候,可以提出几个解决问题的
方法供管理人员选择,不论对你们的关系,还是实际问题的解决都有好处。最后要说明是。的确是有
一些项目管理人员很不地道,如果真是这种情况,最好的方法是离开这个项目。这个项目的失败是必
然的。单靠技术人员的个人能力是无法挽回的。

·如何协调这样的关系?,(2005-10-11) [作 者] zhansir [公 司] kunmingligongdaxue

提供一个参考,你可以在一个公共场合说一个错误的东西,然后肯定有人说这是错的,你就可以根据
这个来分析项目的沟通,应该可以解决的。

第 420 页 共 756 页
第 4 章 沟通管理

·团队需要一定妥协(2005-09-20) [作 者] 苗凯 [公 司] 北京九州信诺科技有限公司

(1)从楼主的文字看,对项目经理的意见已经很大了,已经对其性格进行批判,因此我认为这种情
况下的对具体事情下结论可能是不客观的。
(2)一个项目中,项目经理与技术专家发生认识上的矛盾是很常见的,但是很多事情,双方可能只
是认识上的不同,不一定就是谁对谁错。这种情况下需要一定的妥协,这是一个团队精神的问题。另
外作为项目经理很多时候是从一个项目的总体考虑事情,而开发人员很多时候只是从局部去看问题。
(3)做为项目中技术人员,可以对项目实施发布意见,但是有一点是必须要注意的,就是发表意见
的方式不要蔑视项目经理的管理权威,如果这样可能永远是双输,你的好的想法和意见不能得以实现、
项目本身进展不好,更有可能导致项目经理觉得你不可用的想法。
(4)很多时候技术人员和项目经理对项目成功和失败的理解是有偏差的,技术人员可能觉得技术落
后就是失败,而项目经理的对是否失败的判断就是是否按时保证质量完成项目要求。
(5)如果你的经验(我指在整个项目操作上,而不是技术开发上)真的有很多对方比你的经理强,
那么可用系统的阐述一下问题,最好写个 email,来全面阐述你的理由和看法,但是要只针对事情,
有条理有依据的发表意见,这个 email 也可用同时抄送给你的项目经理的上级。只要你的目的是为这
个项目好,那么矛盾都是可以解决的。

·reply as below(2005-09-19) [作 者] 许德平 [公 司] 保密

这是个典型的项目沟通问题, 我个人认为如何排除敌对情绪十分关键, 项目的失败对大家都不好,


从描述中发现作者对项目经理十分不满, why?可能有两种方法解决:
1)。面对面陈述利害关系, 用道理而非争执说服别人。
2)。利用团队影响来决策,
必要时听听其他专家的建议,(高层, 技术高手,等)

·如何协调这样的关系?(2005-09-17) [作 者] 刘忠娟 [公 司] 北京奇正软件有限公司

与项目组其他成员沟通,他们是否认同你对项目的判断.整个项目组人员可以开会以汇报项目情况的
方式提供建议.不过要摆正自己的位置和心态,你只能提供建议,没有决定权.也要注意自己说话的
语气.

·如何协调这样的关系?(2005-09-15) [作 者] 华易 [公 司] 同济大学经济与管理学院管理

上帝自从发明货币后,没有解决不了的问题哦,把项目的利益和经理的利益说清楚,相信他不会对钱
过不去!

·结构矛盾(2005-09-14) [作 者] jeff [公 司] 独立顾问

第 421 页 共 756 页
第 4 章 沟通管理

这个案例是典型的结构矛盾
从工作流程上讲你们的工作会相互依赖的比较强烈,依赖越强烈,矛盾越深。结构矛盾如果不改变结
构永远无法解决,就像公司中的部门矛盾一样。
你的角度:控制到失去控制的过程,技术角度到管理角度的过程。
他的角度:控制到被反抗的过程。
如果他也发帖的话,他会这样发:
我刚刚接管一个项目,里面有一个所谓的技术高手,反对我的安排,不服气,很牛,我应该如何处理?

·如何协调这样的关系?(2005-09-12) [作 者] 童康 [公 司] 私人承包商

我发现很多现场的技术负责人都与项目经理搞不好关系
对不起我以前也是从事技术管理的,终究一个原因是技术人员看问题比较片面
我建议你客观的从自身先找一下原因,工程施工的好坏是有很多的原因的

·宁静以致远(2005-09-10) [作 者] 刘海涛 [公 司] 中国工商银行湖北省分行营业部

你说的这种情况在许多项目中都存在,而且也是造成许多项目失败的主要原因之一。项目管理中最难
以掌握的不是工具,而是人。对此种情况提供以下建议:
1、首先检查你自己,尽可能客观、全面的看待此件事,把全部经过冷静地反思一下,看自己是否在
看问题的角度、提建议的方式以及个性上存在一定的问题(可以和项目组中比较要好同事交流以下),
如果有,则尽可能找出来,改变一下方式再尝试与项目经理沟通(从你的表述中感觉你对项目经理是
上面亲点的很有想法,不必要)。
2、如果排除了你自己本身的原因,那接下来就必须尽可能小心了。首先要分析一下企业的环境和氛
围、分析一下企业对这个项目的态度、分析一下项目经理与上面的关系、分析一下自己改变目前状况
的可能性,再采取切实可行的办法(不少帖子已经说了一些办法,关键要把握好时机)。毕竟现实是
复杂的,我不希望你“壮志未酬身先去”(虽然孔子说过“道之所在,纵千万人反对,吾往矣”),
来日方长,有这种经历也是一种磨练,对成长有好处。
实际人没有人可以帮你,我们只能简单的分析一下,怎么做还得靠你自己。

·越级通报不是坏事(2005-09-10) [作 者] 天羽 [公 司] 林源教育咨询

项目管理的组织结构不是企业里的常设机构,是企业为了完成某件事情而让他存在的一种形式,所以
有关项目经理的种种问题,你都可以越级汇报。

人是活的,规矩是死的,管理就是应变,千万不要被所谓的金科玉律捆绑住自己的行为。

公司的项目肯定都是利润的来源,破坏利润的行为,都是可以越级揭示出来的,千万不要去考虑沟通
秩序,要“仗义执言”,要“勇担风险”,这样上级才能意识到问题的重要性,才能真正看到项目经

第 422 页 共 756 页
第 4 章 沟通管理

理的问题,项目组内部项目经理 PM 和技术主管 TS 之间有责任的分工,原则上你要服从 PM 的领导,


但是你的责任会更大,因为你的范畴决定了项目的产品的质量和生命期。

如果你觉得越级汇报有麻烦,或是你的性格不适应这样的方式,建议你找到人力资源部寻求帮助,毕
竟他们的手里掌握着项目经理的“未来”。

相信我,我在企业里做了很久了,带领各种项目、部门也很多了,作“丈夫”受夹板气也很久了,只
想告诉大家一句名言:做事之前不要怕、之后不要悔。因为你的心里装着的是你们的项目、你们项目
组的产品、你们项目组的心血。

·分析相互关系(2005-09-09) [作 者] 向 [公 司] 重庆通盛

我认为,有以下几点需要关注:
1、项目经理关注的是全面,即实现项目整体目标,而你也许仅关注了技术性能,忽视了其他因素,
需换位思考。
2、工作中的执行力 不管什么原因,上级指示必须执行,意见可以提出。
3、加强沟通技巧,陈述采取你的办法将会为项目带来的好处,不仅是技术性能。

·如何协调这样的关系?(2005-09-08) [作 者] zhansir [公 司] kunmingligongdaxue

我也同意越级汇报是很危险的,同时你应当注意你说话所代表的身份。本来项目管理 80-90%的时
间是用来沟通,看来你的上司是比较差的一种,但是你们是一个团队,应该以集体为重。

·分析所处环境、公司性质(2005-09-08) [作 者] 陆斌 [公 司] 房地产开发公司

就此种情况,首先本人要认清自己所处的地位,环境,对待国企和私企应有不同的应对措施。在沟通
的目的、方式上也与所处公司的性质有极大的关系。

·从项目出发(2005-09-07) [作 者] 彭国荣 [公 司] 北京普天银河通科技有限公司

项目经理考虑的问题是从整个项目角度来把握的,即项目的全局。而技术人员往往只是片面的去看一
个问题,以偏概全,这往往是许多做技术工作的人容易忽视的地方。

·沟通很重要(2005-09-07) [作 者] caoyue [公 司] 不公开

我认为首先你做的事是公事,因而沟通时应讲究策略,最好是在沟通会议提出你的方案见解,确实是好

第 423 页 共 756 页
第 4 章 沟通管理

的建议,相信会并取得大家的支持,这样项目经理也认为你是为项目着想.

·保持良好心态(2005-09-07) [作 者] 梁桢 [公 司] 上海广平信息系统工程有限公司

首先,项目经理对项目本身负责,项目成功与否在于项目经理的领导。作对项目成员对自身工作内容
负责,提交完整的“可交付物”,根据项目经理的要求工作,并非指导项目经理如何做事。

其次,如果对项目存在问题可以在周期性项目例会上提出,会议纪要会记录项目成员对于问题的建议。
日后项目对于问题的追述会有据可查。

最后,一个成熟的项目成员会时刻关注项目的进程,对于项目经理发现而多次未及时处理的问题可以
想部门经理回报,由部门经理在公司行政例会上指出确保项目的成功。

保持良好心态面对工作。

·加强项目成员与经理之间的沟通(2005-09-06) [作 者] 严俊 [公 司] 南京林业大学

建议单独和项目经理聊聊,加强彼此之间的沟通和理解,在关系进一步改善后,涉及项目的发展问题,
应将这样做所带来的后果以一种敬意的方式告诉他,并将现在的项目进展情况如实向他汇报,希望他
能够作出相应的调整.

·监控不利(2005-09-06) [作 者] derikwoo [公 司] PPS

公司没有专门的监察部门,上面的经理定期查看项目经理的报告,给于了他足够的信任,所以进度完
全是他在控制,而且在技术曾面上分析,项目的运做显然有缺陷,但是他还是坚持继续

·学会合作(2005-09-06) [作 者] chenrulin [公 司] Null

几点意见:
1)既然项目经理是你的领导,就应该多听听他的意见.
2)或许你是专家,但要注意提出问题的方式,用对方能够接受的方式去提出.
3)有时候,推一步海阔天空. 你做一个小让步,或许对方会给你一个更大的让步.
4)对于你目前的情况,最可行的是和你的项目经理有一次成功的沟通. 只有努力和他达成公识,才有
可能花解出现的项目风险.
5)放下自己的架子,虚心一点.

·不能坐视不理(2005-09-06) [作 者] stephnys [公 司] XXX

第 424 页 共 756 页
第 4 章 沟通管理

首先我觉得楼主态度十分负责,相信是一个真正热心做事的人!值得大力提倡和鼓励!!!

然后我们来看看如何处理你提出的项目风险的问题. 如果这位项目经理听不进去你的建议又不能给
你任何理由,那么我想问一下:监管项目的部门或者主管是谁? 项目管理办公室吗?还是说高级主管?
有没有项目周期性的评审会议? 你可以在评审会议上提出客观的分析来说明问题和风险,注意不要有
人身攻击,要有理有据,而非个人臆测.

·把自己变成最好的执行者(2005-09-06) [作 者] 曹垣亮 [公 司] 北京普天银河通科技公司

态度决定所有。
执行是项目最好的保障。
项目没有结束,你如何说项目不行呢?由于职位的差异,信息是不称的。

·技术为辅,管理为主(2005-09-06) [作 者] 宋宾 [公 司] TCL速必达信息管理部

项目技术人员在项目的整体运作中始终扮演的是一个执行角色。在国内很多情况下技术人员是不参与
某些与项目技术无关的会议的。但是这样做的缺点就在于管理者有时是无视技术人员的意见的。

项目经理是一个项目的负责人,在整个项目中处于绝对上层。所以,技术人员是无权干扰或是试图改
变项目经理的决策的。至于冲突可以完全避免,当这种情况发生时,你可以向你的项目经理提出保留
意见。这样在后继的过程中就可以做到权责分明,你也不用担心什么了。但是我建议你还是要配合项
目经理的安排。

同意楼下说的,越级汇报是项目管理的大忌。文字

·摆正身份,力求改进(2005-09-06) [作 者] 赵昊彤 [公 司] 不公开

你不是项目的负责人,你对项目负责人的决策和工作方式有意见的时候,可以提出你的看法作为建议,
但是你无权直接干扰项目经理的决策,因此,我认为你和项目经理吵架的方式是错误的。
也许你的看法是正确的,但是你要摆正自己的身份,不能认为你自己正确就想项目经理一定采纳你的
建议。
另外,不要越级汇报,如果项目经理不采纳你的意见,那你就先保留吧,越级汇报是管理的大忌。

·不说(2005-09-06) [作 者] kaney [公 司] 不说

其实前面几位的观点,我个人是不敢苟同的,特别是第一位,说什么"让项目恶化下去并不一定是坏事,
等项目彻底失败了,或者这个项目经理多失败几个项目,问题不就解决了吗?这个办法有些极端,但

第 425 页 共 756 页
第 4 章 沟通管理

有时只有这样做才能解决问题!
"
我个人认为,说这些话,是对自己的极不负责的说法.
一个项目都是我们成长中的一个经历,我们都经历的是这些因为某些原因可能会失败的项目时的态度
就是放之任之,那我们对的起自己吗,
我的个人看法是,负责,负起责任来,首先让 PM 了解下面程序员的想法,如果只是你一个人与他有意
见,那么要反醒一下自己,如果是大多数人都与他意见不和,恭喜,你们已经找到解决办法.
实在不行,还可以越级给上级汇报一下情况,当然这个是万不得已为之的办法,总之一句话,做对自己,
对项目负责的事!!

·把自己变成执行者!(2005-09-06) [作 者] 王平 [公 司] 北京城建

把自己变成执行者!我们不是项目的负责人,对项目负责的是项目经理!确实,很多老板宁可用一些
无能的亲信来负责项目,这个亲信本身是无用之辈,这造成了有才能的人对项目经理的错误指挥不满,
这样的事到处都是。

把自已变成执行者,项目经理让怎么做就怎么做!让项目恶化下去并不一定是坏事,等项目彻底失败
了,或者这个项目经理多失败几个项目,问题不就解决了吗?这个办法有些极端,但有时只有这样做
才能解决问题!

这样的公司多数为爆发户或者个体户出身,没有什么体制和流程可言,讲究用人唯亲的原则,让这些
企业和老板多多经历一下失败,对中国民营企业的成长在好处的!聪明的企业和老板经历几次失败会
肯定会调整策略的。什么时候变成用人唯才了,那才能从根本上解决你所碰到的这个问题!

·发挥大家的力量(2005-09-05) [作 者] 旷超 [公 司] 湖南长沙黄花国际机场信息管理部

这种情况大家都会遇到,你应拿出书面分析报告提供大家参考评议,发挥团队的力量提出好的解决办
法.

·另外(2005-09-05) [作 者] 牧野李 [公 司] 河南通信

如果你对项目经理分给你的任务包计划和控制不满意(这应该是项目小组的职责吧),在具体工作包
层次上你是专家,项目经理在技术上可能不如你,你要和工作包小组长沟通,然后让他和项目经理沟
通。

·一点小建议(2005-09-05) [作 者] 牧野李 [公 司] 河南通信

第 426 页 共 756 页
第 4 章 沟通管理

上面这位仁兄,我不了解你的具体情况,但是我说一下,当然也可能有不对的地方。你是做技术开发
的,然而整个项目目标是以公司战略为发展方向的;项目经理只是实施和控制者,你说你的项目经理
很自我,不善于沟通;我要说的是你曾经为项目整体考虑过么?如果有,你以为你有项目实施和控制
得更好方法么?你能写出报告来么?如果你可以做到这些,你可以向董事会以及项目高层管理者递交
你的报告,让专家做分析,我想作为公司高层应该为项目成功与否负责的。

4.16 好团队突然空降一上司,如何相处?

好团队突然空降一上司,如何相处?

[姓 名] miral_ad [单 位] 不公开 [邮 件] mazhk@xinhuanet.com


[所属行业] 综合应用 [所属主题] 项目沟通管理 [发布时间] 2005-8-1

【案例正文】
我所在的部门一年前成立,当时只有几个人,部门 Manager 四处揽活,我们几个拼命干活,
成绩也很明显。到了今年,部门已经到 40 个人了,我也带了 12 人的团队。Manager 以往只
负责对外联络,我这一块的具体项目都是我自己在把握,最多就是向他报告一下状态,申
请些资源。

最近,突然招了一个 Engineering Manager,在部门 Manager 之下,我要向他直接汇报。此人


总是自以为是,说话咄咄逼人,一幅我是 Manager 就得听我的样子。

想想辛辛苦苦建好了自己的一个团队,自己的活动空间一下被别人压缩了,实在不甘,请
问该如何应对?

·好团队突然空降一上司,如何相处(2008-07-14) [作 者] darry [公 司] hn6j

自己做好自己的事情,主动沟通,能够相互之间化解最好,实在不行,井水不犯河水.再不行就是忍,"忍
无可忍无须再忍"

·好团队突然空降一上司,如何相处?(2008-07-01) [作 者] 我就是我 [公 司] 企业

你要做的首先是:让事实证明非你不行.做不到这点就忍忍吧,谦虚点,多学点东东.

·why is there a new boss?(2008-05-11) [作 者] chow king lam [公 司] beria consultants limited

第 427 页 共 756 页
第 4 章 沟通管理

Maybe you should take a few minutes to think it over, is it because the top management has something to
tell you?

·好团队突然空降一上司,如何相处?(2008-04-03) [作 者] captainhua [公 司] 惠州

观察 从描述上看,楼主也是习惯一人之下,万人之上的角色,突然增加一个报告对象,难免心里有疙
瘩,这是人之常情.
本着对工作负责的态度,工作做好是判断对错的唯一标准.如果他能指挥楼主搞定问题,不服高人有
罪,得有容人之量,何况是高人....
如果他搞不定,慢慢地大家都不会服他,他也不会有成就感,自己会走的
因此,请耐心观察一段时间,再作出判断吧.

·求助(2008-03-23) [作 者] 张茂有 [公 司] 销售

我在单位就遇到这样的一件事情,我也不知道应该怎么样做才最合适!

·好事(2008-03-07) [作 者] gaozhen [公 司] shandongjingjixueyuan

这是一件好事,为什么呢?
我觉得这是一个锻炼自己,提高自己的好机会。出现问题,解决问题可以使人进步。感谢那些不
愉快的事和让你不愉快的人,他们带给你的进步比你的朋友多很多。
相信自己可以和他沟通好,努力去做,不要有情绪。
看目标,莫看脚下!

·沟通是桥梁(2008-02-26) [作 者] 李东 [公 司] 项目管理者联盟

有效的沟通才是最好的方法。对他的尊重就是服从!给他的表现就是沟通!

·空降上司(2008-02-22) [作 者] zhaog [公 司] 日电系统集成

1、对于这种老板要经常进行沟通。
2、在项目实施中听取一下他的看法,因为不同的人对问题的看法和解决方法也不同。对几种解决
方法路径也未尝不可。

·站在新领导的位置想一向(2008-01-01) [作 者] 江西早 [公 司] 兴库建设投资有限公司

冲突的焦点应该主要归到:部门业绩成长,管理改进的习惯性不适应性上。

第 428 页 共 756 页
第 4 章 沟通管理

通篇叙述中清楚的感到,楼主对新领导的不接受(无功也受禄!),但是没有明确看出新经理不
适合领导岗位。
建议:一、在高速发展的企业团队中的每一个人,都要加速跟上组织发展,管理改进的需要。
二、多发现新经理之所以成为新经理的原因,当然新经理也需要信任、爱、支持。
三、支持领导成为啦啦队长,而决不是期望领导成为过去的业务人员(过去看惯了业务人员,可
能看见非业务人员不顺眼)。

·做人做事(2007-12-05) [作 者] 吴涛 [公 司] 黎明

谁是领导就听谁的吧 既然招他来他就有他的技术

·打打太极。。心态最重要。(2007-12-03) [作 者] 木木 [公 司] ShanghaiToJU

1.多和新来的 EM 沟通。实在不容易沟通就多观察他吧,或者打打太极。。说不定你会发现他虽然
做人比较高调,但在项目管理确实有其过人之处,而那方面能力又正是你所缺乏的。取长补短。
2.保持平和的心态。继续做好份内的事情。只是形式上要多些流程而已,并不会影响太多你和团
队之间的合作。
3.看能否直接和部门经历沟通下(如果和他关系不是太僵),至少表达一下自己的意思。

·从容面对(2007-11-30) [作 者] snock [公 司] 广州某软件公司

1.既然他是你的上司,你就应该向他汇报;
2.既然领导把他招进来,肯定有其过人之处,你不防主动沟通,发现他的优点,多向别人学习;

·服从!沟通!(2007-11-09) [作 者] 李东 [公 司] 项目管理者联盟

我想,对于这种情况,很多人都遇到过。
送给楼主两句话:对他的尊重就是服从!给他的表现就是沟通!

·首先要调整你自己的心态(2007-11-04) [作 者] sanyiecao [公 司] tielu

首先要调整你自己的心态,要知道向他汇报是你应该做的,只不过你以前的领导没让你做罢了。
在此之上,可以让你的新领导知道你以前的成绩,让他了解你的能力。等他知道这些后,或许会
适当放权。

·要注意你自己的发展(2007-10-30) [作 者] 马勇 [公 司] 中国水电八局

第 429 页 共 756 页
第 4 章 沟通管理

你的 Manager 招了个 Engineering Manager,


首先要明确 Engineering Manager 是不是只管你的团队,

如果是,说明你平常的工作有部分没作到位,让你的 Manager 没得到足够的信息;


如果不是,那你没必要太要强,多和他沟通沟通,他不了解你的能力,也须要支持和属下信服,表现
就会有些强态,加强沟通后会好些;

·理顺管理流程(2007-09-05) [作 者] 毛知新 [公 司] 湖南大学

对该案例
1、公司应给 Engineering Manager 一个正确的定位和职责说明。
2、加强与 Engineering Manager 的沟通,想办法让他尽量少干预你的工作。
3、退一步说,既然他要干预,你就把问题督推给他,让他去解决棘手的问题,让他知难而退。

·个人事业发展和部门发展(2007-05-07) [作 者] 姚振华 [公 司] 中兴

在这个案例中,我觉得主要强调个人的发展。
1.在你与部门经理的奋斗经历中,还没有表现到他可以信任你来担任这个经理的职责,所以,在
以后的工作中,要善于沟通和捕捉一些这方面的信息。
2.这个新经理,他的资历及能力,应该是部门经理觉得还不错的。
3.这个新经理的表现,属于正常表现,他如果想尽快的熟悉项目请宽,只有从你这里来得到最全
面的,他并不了解你,他只是按照架构来操作的,如果你想让他尊重你,只能是通过不断的接触,
给他留下较深刻的印象,不然,他肯定认为你不服他,或者有意为难他,对于第二种可能,他可
定有能力将你踢出。

4.如果你想得到更好的发展,你要给部门经理讲你的情况,提出你的发展想法,让他给你指名道
路,我想会有个你较为满意的答案。

·给他找点事(2007-01-21) [作 者] 草席 [公 司] RA

没错,他是老板你就得听他的。老板嘛!多数都是笨蛋,所以一定不要被他牵制。给他找点事情
做,向他请教一些问题,不要让太闲。否则他会让你不闲! 千万不要有负面情绪,而且一定不要
越级汇报。和老板打交道也是一门艺术。

·团队突然空降一上司,如何相处?(2007-01-15) [作 者] pitolan [公 司] 苏州博亚

团队突然空降一上司,如何相处?

第 430 页 共 756 页
第 4 章 沟通管理

先要了解为什么会来呢?这个上司。
既然你是一个项目经理,也经过了困难的考验,那么就拿出你的专业知识和智慧,把目前你觉得
难堪的处境转化成对你有利、对公司有利、对你的团队有利的积极状态。除非,你没有这种勇气。
当然,最坏的情况是,“空降兵”并不如你但却受领导赏识(有些人就是会做人),那就毫不犹
豫的离开。
只要你有能力,你不会有什么损失,相反,损失的是你的部门经理,你的公司。

·好团队突然空降一上司,如何相处?(2006-12-24) [作 者] 刘用 [公 司] 广东省建筑集团
公司

和上级的沟通的确需要技巧,况且是新到的,他不了解你们的工作情况,如果不做好沟通工作甚
至会让他有种不被尊重的感觉,做为项目负责人,你应该做好他和团队的桥梁,主动的沟通,让
他更了解团队和工作情况,同时参与到你们的工作中来,必要是可以要求你的部门经理一起协调
沟通。

·好团队突然空降一上司,如何相处?(2006-12-24) [作 者] 刘用 [公 司] 广东省建筑集团
公司

新领导不熟悉目前的环境,总有点颐指气使,觉得下面人办事不力,没有拿出最好的 programme.
你此时就要多汇报、多请示,告诉他工作的细节及进展,一方面满足他的虚荣心,另一方面也要
让他了解你们工作的不容易。最好是能够让他亲身参与你们的计划与活动,这样既可以增强互相
之间的了解,同时也让他除了对计划书之外对项目有更感性的认识.

·好团队突然空降一上司,如何相处?(2006-12-24) [作 者] 刘用 [公 司] 广东省建筑集团
公司

这种情况刚开始的确让人很难接受,如果公司领导和部门经理处理得比较好(如,空降兵来之前
他们与你进行了充分的沟通,或者至少你有知情,说明调整的目的和意义等等),也许更好接受。
对于楼主说的问题,应该更多的是对‘空降兵’本人的工作态度和方式的问题,(个人觉得,更
像是楼主自己对一种预期的失落感)。这两个问题,其实都是需要沟通,多一些时间,更多的交
流,与上司一道做好团队的工作,才是最好的选择!要是选择消极或者不合作态度,甚至放弃,
个人觉得不可取!

·好团队突然空降一上司,如何相处?(2006-12-24) [作 者] 刘用 [公 司] 广东省建筑集团
公司

既然你是一个项目经理,也经过了困难的考验,那么就拿出你的专业知识和智慧,把目前你觉得

第 431 页 共 756 页
第 4 章 沟通管理

难堪的处境转化成对你有利、对公司有利、对你的团队有利的积极状态。除非,你没有这种勇气。
当然,最坏的情况是,“空降兵”并不如你但却受领导赏识(有些人就是会做人),那就毫不犹
豫的离开。
只要你有能力,你不会有什么损失,相反,损失的是你的部门经理,你的公司。

·分析(2006-12-18) [作 者] 王颖 [公 司] 不妨边

既然你是一个项目经理,也经过了困难的考验,那么就拿出你的专业知识和智慧,把目前你觉得
难堪的处境转化成对你有利、对公司有利、对你的团队有利的积极状态。除非,你没有这种勇气。
当然,最坏的情况是,“空降兵”并不如你但却受领导赏识(有些人就是会做人),那就毫不犹
豫的离开。
如果你继续沉迷于项目组本身的管理,或是技术型项目经理的话,你就不会困惑于此,因为设置
一个 EngineeringMgr 的目的就是部门经理的助理,应该是个独立的经理人,光杆司令,对吧,这
就是 PMO 的前身,主要职责就是帮助 Dept.Mgr 收集项目信息、督促项目进度等等内容,你们之间
没有冲突,你依旧是项目组的最高领导,他只是 Dept.Mgr 的助手。但是如果你希望成为管理型的
项目经理,那么情形就变了,因为你的沟通渠道中多了一个和你同样类型的人,这就意味着你的
Dept.Mgr 对解决他和你们 N 个项目组之间的沟通问题有了困惑,或许没有时间,或许是他自己也
不擅长人数增多后的沟通技巧,于是就有了现在的情况。

·建议(2006-03-13) [作 者] 郭彩云 [公 司] SNPC

个人认为也许你的 MANAGER 在公司的发展上有了新的想法和思路,也许引进人才可以改变一下格


局,便于以后更好的发展,而作为你,因为他的出现使得工作上有了新的变化,所以不适应,需
要调整心态,加强上下级之间的沟通,面对空降兵要用平和的心态对待,也许不是他自以为是,
只是你觉得他的态度自己接受不了!人在矮檐下,要懂得低头,等自己上了一个新台阶,就一切
OK 了

·分析原因,调整心态(2005-10-20) [作 者] kangjianguo [公 司] sunco

首先必须充分认识部门 Manager 安排此空降兵的目的,了解此时出现此空降兵的原因,楼上好多


位都进行了分析,有值得借鉴的地方,但关键要根据情况结合实际自己判断。
企业发展壮大,在元老级创业人员不好管理,或不便管理的情况下,调整管理架构时一种通常做
法,关键如何能适应这种调整。建议:1、沟通,和新来的上司沟通,但还要同部门 Manager 多沟
通。2、反思,反思一下是什麽原因使部门 Manager 宁可选择相信空降兵而不选择相信你。3、制
定策略,控制局面,必要时可以重新确定你的事业目标。

·我觉得还是来分析一下空降兵到来的真正原因(2005-10-13) [作 者] 陈晨 [公 司] 电脑公

第 432 页 共 756 页
第 4 章 沟通管理

好好想一下真正来空降兵的原因,否则发展将会终止,合作也将会受到冲击。也许你让部门经理
受到工作上的压力或者精神上的压力。要想继续发展需要打破当前的组织关系,并改善你同部门
经理的关系。否则你的发展只能够停留在这里。而公司的发展也将由于某种原因陷入比较混乱的
局面。并打破现在的和谐

·自我管理(2005-09-28) [作 者] Andy [公 司] NOKIA

前面诸君的分析个个精辟,个人见解是:要管理好团队,先要懂得自我管理,客观的认识自己。
我是开国元老,立下汗马功劳,为什么会空降上司?原因可能有二:
一,经理非伯乐未能识得我这老骥亦是千里马
二,我的能力还不够
或许大多数人愿意相信原因一,因此以非平常的心态来“接纳”这位空降兵。这或许就是你有今
天的烦恼的原因吧。

·加强沟通(2005-09-27) [作 者] 黄晓华 [公 司] 广东华联软件有限公司

我个人认为:
1、加强与“空降上司”有效沟通。
2、相互学习交流,成为工作中合作伙伴。
3、相互尊重,相互信任。

·变与不变(2005-09-22) [作 者] 梅为群 [公 司] 华润涂料

随遇而安,你能来他也能来.只是您早上车一年.车上加了个位置您不知道而已.自然您不知道为什
么了.
车子始终都没变过,是什么在变呢?

·心态和沟通(2005-09-19) [作 者] Hamish [公 司] junction

大家分析得很精辟,真是受益匪浅。我也简单的说些我的个人看法:
“空降兵”的来临初期很大程度上都会对原来的管理者带来一定的迷惑,但如果沟通得当,合作
一样会很愉快。我想这个时候"空降兵"必须要做出比较大的努力才行,原来的管理者也需要调整
好自己的心态配合部门的工作。而且要求分工明确,各人有各人的责任田。
再者,“空降兵”的形式也未必就不是好事,当然要求这个“空降兵”必须有真才实学才是。如
果从老员工中选拔,而这几个老员工都实力相当,Manager 也确实难办。即使选拔了其中一个,其
他老员工也未必能服气,也势必会影响心态。到那个时候将更难处理了。
总之,工作中的心态以及工作过程中的沟通是非常重要。

第 433 页 共 756 页
第 4 章 沟通管理

·个人建议,仅供参考。(2005-09-16) [作 者] 弋瓯 [公 司] Austar

根据你的讲述情况,有些细节还是不清楚,比如:你感到新来的上司“咄咄逼人”是你的心理感
受,还是你觉得他的能力强从而使你受到了威胁?
所以,首先是你的大脑应平静下来,仔细的思考目前的处境,而不是“愤愤不平”的一肚子怨气,
反而使你的手脚忙乱,应对不暇。
既然你是一个项目经理,也经过了困难的考验,那么就拿出你的专业知识和智慧,把目前你觉得
难堪的处境转化成对你有利、对公司有利、对你的团队有利的积极状态。除非,你没有这种勇气。
当然,最坏的情况是,“空降兵”并不如你但却受领导赏识(有些人就是会做人),那就毫不犹
豫的离开。
只要你有能力,你不会有什么损失,相反,损失的是你的部门经理,你的公司。

·亚文化(2005-09-14) [作 者] jeff [公 司] 独立顾问

大家分析的都很中肯,心态问题,可能不容易接受。

如果你站在公司的角度,你就会发现你正是一个亚文化的核心。亚文化让很多公司倒闭至少产生
重大损失。如何解决亚文化问题,如何解决老员工问题,所有的企业都在思索,所有的企业都没
有好的答案。

·成长之苦(2005-09-11) [作 者] 天羽 [公 司] 林源教育

看了你的案例,想起了自己的成长过程,这是一个技术型领导者在企业成长过程中必然要走过的
艰苦的历程。相信你一旦痛过,也就成长了。

一年前你们处在创业期,一切都是自力更生,Dept.Mgr 基本上全部心力都扑在市场,应该说是典
型的领导销售的模式,在你们的共同努力下,你们成长了,从几个人到了 40 个人,你也带了 12
个人的团队,可是你们没有在成长的同时,加强管理方面的培训,以至于你说“你的项目组由你
把我,最多只是向他汇报一下状态”,明白了吧,问题就出在这里,就管理技术层面会涉及到沟
通管理、心态调整等等,但我在这里想说的是,这是一个管理者成长之苦。

如果你继续沉迷于项目组本身的管理,或是技术型项目经理的话,你就不会困惑于此,因为设置
一个 EngineeringMgr 的目的就是部门经理的助理,应该是个独立的经理人,光杆司令,对吧,这
就是 PMO 的前身,主要职责就是帮助 Dept.Mgr 收集项目信息、督促项目进度等等内容,你们之间
没有冲突,你依旧是项目组的最高领导,他只是 Dept.Mgr 的助手。但是如果你希望成为管理型的
项目经理,那么情形就变了,因为你的沟通渠道中多了一个和你同样类型的人,这就意味着你的
Dept.Mgr 对解决他和你们 N 个项目组之间的沟通问题有了困惑,或许没有时间,或许是他自己也
不擅长人数增多后的沟通技巧,于是就有了现在的情况。

第 434 页 共 756 页
第 4 章 沟通管理

处理办法:
1. 如果你想走技术路线,那么不必担心,新来的这个职位的人从运营管理角度上讲,是不会深入
到项目组内部细节层面的,你依旧是 PM。要做的只是和他制定一个你们之间的沟通计划和文档模
板,这样就没有问题了。
2. 如果你想走管理路线,在采取上述办法时,主动进攻,采用项目简报的方式,将项目情况定期
用 Email 通报 Dept.Mgr,一来保证你的项目信息在传话过程中保真,二来重构你和 Dept.Mgr 间有
效沟通渠道。削减中间人的作用。

记住:
a. 这里没有 Dept.Mgr 对你不信任的问题,也不要对自己的沟通失去信心,这些都是成长过程中
的必然经历。
b. 企业增加一个冗余岗位,必然是为了解决一个临时出现的问题。

·一点看法(2005-09-08) [作 者] macw.. [公 司] HH

从案例描述的情形看,大致可以得出这样一个印象:Manager 下面人员在增多,管理精力不够,这
个时候如何下面有多名虎将和老部下,提拔谁都不好,搞不好就伤筋动骨,内部不团结,把技术
骨干提拔上去也不一定能管理好,其他人不一定服,从管理者的角度讲,不愿意出现这样的局面。
俗话说外来的和尚好念经,此时空降一个副手是合乎情理的。至于‘你’感到别扭,估计是一种
失落感和挫折感,但如果换位思考一下,站在 Manager 的角度看一下这个部门,你会做何选择呢?
是不是‘你’已经够强到能服众,又已经培养好合适的接班人接你的一摊工作呢? 如果一个管理
者长时间没有培养出一名合适的接替者的话,是没有资格被提拔的。

仅仅是浅见,供讨论。

·一点看法(2005-09-08) [作 者] macw.. [公 司] HH

从案例描述的情形看,大致可以得出这样一个印象:Manager 下面人员在增多,管理精力不够,这
个时候如何下面有多名虎将和老部下,提拔谁都不好,搞不好就伤筋动骨,内部不团结,把技术
骨干提拔上去也不一定能管理好,其他人不一定服,从管理者的角度讲,不愿意出现这样的局面。
俗话说外来的和尚好念经,此时空降一个副手是合乎情理的。至于‘你’感到别扭,估计是一种
失落感和挫折感,但如果换位思考一下,站在 Manager 的角度看一下这个部门,你会做何选择呢?
是不是‘你’已经够强到能服众,又已经培养好合适的接班人接你的一摊工作呢? 如果一个管理
者长时间没有培养出一名合适的接替者的话,是没有资格被提拔的。

仅仅是浅见,供讨论。

·关键是心态和沟通(2005-09-07) [作 者] 李治 [公 司] 亿阳集团

第 435 页 共 756 页
第 4 章 沟通管理

1、这个问题,其实我一年前也遇到过。坚持了一年,最后选择了自己的离开为结果。
2、现在,跳开看看,感觉主要原因是自己和原来的领导沟通不够,老是自己认为领导对自己非常
了解什么也不用说。另外,在行业经验上空降兵的确在某个层面上比我们这样的“老人”强,或
是他们的某项优势是公司急需的。
3、加强沟通是最关键的,其次向每个空降兵学习,最后争取一些机会空间开创自己的业务线。
4、可以离开,但是要合适

·为什么不甘心?(2005-09-06) [作 者] Eric 宋 [公 司] TCL速必达信息管理部

文字有什么不甘心的?

大家都是想把项目搞好。我们的心态是不是应该放端正呢?为什么上级会招来一个空降兵?是因
为对你的工作不满意?还是对整个部门今后的发展做出一个长远规划?

做技术出身的人是有一些咄咄逼人,但是如果你的技术强过他,他恐怕也牛不起来了吧。项目经
理本身的角色就注定是个绝对强势,所以不要觉得不甘心。大家一起把项目做好才是最重要的。

天底下牛人还多着呢?你都能不甘心?

·调整心态(2005-09-04) [作 者] 李名 [公 司] 柳州机械

这种空降兵的事情经常发生,对此既成事实你只有采取积极的方法对待。搞好与新上司的关系,
分析他的心理。新领导建立威信,寻求承认的行为可以理解,关键是多多沟通,帮助其尽快进入
角色。加强配合,必要时放弃以前的工作方式和思路,没准对自己、团队和项目有帮助。

·人人相轻(2005-09-04) [作 者] david [公 司] MITAC

個人認為﹕
雖然是一個空降上司﹐還是要象對待以前的上司一樣﹐這樣才能更好地把工作展開。
不要認為他是一個 Engineer Manager 而心有不滿﹐我覺得下面的一篇文章有值得借鑒的地方﹐雖
然我有一點不贊同作者的語氣﹐畢竟我們自己可以去分辨
Subject: FW: 一人事經理眼中的中國人劣根性
亲爱的朋友:
您好!
我在一个生物技术企业工作了四年,之前是做市场的,最近一年被老板调到了人力资源部当经理。
一年的人事工作经历使我对人性有了更深入的认识,对中国人(包括自己在内)的坏毛病有颇多
感慨和无奈。之所以放大说是中国人的劣根性,是因为我相信我下面说的很多特性在国人身上是
普遍存在的,发生的几率要高于那些比我们好的国家。我是一个中国人,并不想贬低自己的民族,

第 436 页 共 756 页
第 4 章 沟通管理

但我认为我们民族经过这一百年来的动荡,特别是十年文革,教育的确是被歪曲和延误了,国民
整体素质处于一个很低的水平。我在下面所发表的言论,既是在揭中国人的伤疤,也是在揭自己
的伤疤,但我相信一个人或者一个民族,只有勇于正视自己的缺点和毛病,才有改进和强大的机
会。

一、人人相轻
中国人不是文人相轻,而是人人相轻,只要想轻视别人,总有相轻的理由。比如北京人
轻视外地人,上海人轻视外地人,城里人轻视农村人,南方人轻视北方人,有钱人轻视穷人,开
车的轻视走路的,走路的轻视扫路的,吃饭的轻视做饭的……就是不会相互尊重。在企业里面,
就表现为硕士轻视本科,本科轻视大专,大专轻视中专,名校轻视非名校(靠!中国有什么名校?),
干部轻视职员,职员轻视工人。更搞笑的是学理科的轻视学文科的,学文科的轻视学理科的,市
场部的轻视技术部的,技术部的轻视市场部的。这不是随口乱掰,我就常听到“他们技术部的水
平不行,解决不了什么质量问题”、“他们市场部的人员素质太低了,基本的产品知识都不具
备”……这样的废话加屁话。都是一个公司的,别人不行要伸手帮忙,站在那里说风凉话能解决
什么问题呢?
说句老实话,在一个公司里面,都是出来打工的,谁比谁高多少呢?何况大家捧着的是一个
饭碗。都是中国人,美国人把咱大使馆说炸就炸了,日本人就是不还钓鱼岛,连香港人都说咱们
是“大圈仔”,我们还有什么理由去轻视自己的同胞?一个缺乏同情心的民族绝对不会是一个伟
大的民族。我每次看见那些吃饱了腆着肚子趾高气昂地骂服务生的人,以及我们公司那些拿着几
千块 rmb(折合几百美金)的伪白领,以为自己忽然中产了,整个一不知道天高地厚的傻样,就觉
得这个国家没什么希望。
我记得以前读书的时候,每次大考,统计总分要精确到小数点后两位,然后依分数排名,
根据排名自己挑座位,于是坐前面的就轻视坐后面的,老师还要说“你们坐前面的不要到后面去
玩啊!” ,估计中国人爱轻视别人的坏毛病就是那时候养成的。

·摆正心态,换位思考,积极配合,干好本职(2005-09-03) [作 者] 孟子之后 [公 司] 北京
中关村软件园发展有限责任公司

本人不久前面临了这样问题,时隔 6 个月又要面临这一问题。刚听到这一消息时,也是心理不快。
静下来考虑一下公司的安排,感觉尽管有不合理之处,似乎也道道。所以,首先要摆正心态,既
然是事实,就要积极处置。同时,换位思考有利于理解和沟通。加强配合,必要时放弃以前的工
作方式和思路,没准对自己、团队和项目有帮助。当然,空降兵即时能力再强,如果水土不服,
对他来说也未必是好事,对团队和项目是否有利,那是领导的事,至于是否公平,也不用去想,
得你应得的回报,干你应干的工作。总之,此时阿 Q 一点好。

·从工程部架构上,看项目团队的平衡(2005-09-03) [作 者] 刘军益 [公 司] 博华监理公司

实际上,好团队突然空降一上司,这在工程管理里面是很正常,换句话说工程部管理架构发生了改
变,作为项目经理,或团队领导首先是维护好团队的平衡,进而维护整个项目管理环境的平衡是很

第 437 页 共 756 页
第 4 章 沟通管理

重要,而这要求必须进行有效的沟通,明确自身在工程部的位置、工作边界的问题.作为项目经理,
应该对这一特点是很敏感的,不应去计较纯感性上的东西,要善于利用周围的资源为我所用。

·是情况而定,最综利于你个人的发展(2005-09-02) [作 者] 侯成君 [公 司] Shanghai SEME


Co., Ltd.

我觉得你要分析一下目前的工作情况,以及原来 MANAGER 的态度,


还有刚来的仁兄是何方神圣,综合比较,你处在的位置,对你开展工作是否有利.
我想你应该明白怎么做.

·Manager的信任(2005-09-02) [作 者] 舒劲松 [公 司] 中体同方体育科技有限公司经营管


理部

我认为:Engineering Manager 是在您和 Manager 之间的岗位,而且您过去最多就是向 Manager 报


告一下状态,申请些资源,如此可能导致 Manager 无法掌控各个项目的实际情况,从而产生某些
不信任的感觉;安排 Engineering Manager,主要是收集信息,发布 Manager 的指令;因此,我认
为您最重要的是加强与 Manager 的沟通,使 Manager 确实全面了解您负责的项目的全面情况,方
式可以是定期报告加随时当面汇报,您需要 Manager 的信任,可 Manager 也想得到您的忠诚;只
要重获 Manager 的信任,Engineering Manager 的角色就变得可有可无,您的活动空间也不会被压
缩;您的活动空间的大小本质上取决与 Manager 对您信任度的深浅;Engineering Manager 是特殊
时期的产物,不合作的态度估计于事无补,因此在向 Engineering Manager 报告的同时,再向
Manager 报告一次,这即表明了您的态度,也可使您真实了解 Manager 的想法,避免在今后成为
Engineering Manager 的替罪羊

·同感(2005-09-01) [作 者] oak [公 司] 自在人生

这个情况,在一年以前我也碰到过。今天看了各位的深入分析,很是受益,要是当时能够看到这
些分析,也许我将做出另外的选择。
这里我谈谈个人的想法:这种情况刚开始的确让人很难接受,如果公司领导和部门经理处理得比
较好(如,空降兵来之前他们与你进行了充分的沟通,或者至少你有知情,说明调整的目的和意
义等等),也许更好接受。对于楼主说的问题,应该更多的是对‘空降兵’本人的工作态度和方
式的问题,(个人觉得,更像是楼主自己对一种预期的失落感)。这两个问题,其实都是需要沟
通,多一些时间,更多的交流,与上司一道做好团队的工作,才是最好的选择!要是选择消极或
者不合作态度,甚至放弃,个人觉得不可取!

·虚心承认 机会不如别人好(2005-09-01) [作 者] 成李民 [公 司] 海口旅游投资控股集团


公司

第 438 页 共 756 页
第 4 章 沟通管理

团队的核心是公司总裁,部门的核心是项目总监或项目部经理,这是常识.但项目总监为什么会
是别人,原因有:1、总裁多年前就认识他;2、虽然年龄比我小,学历相当,综合素质不如我,
但比我多了那么一点项目管理经验,我必须虚心承认,并服从他;3、他的机遇比我好。认命吧,
好好工作,机会总会降临的

·管理体制的变化(2005-08-31) [作 者] 一孑 [公 司] yijie.net

不知道 Engineering Manager 是谁招来的,但我想你们公司的管理体制要发生一些变化。毕竟一


个部门从几个人的小团队扩大成为 40 人的团队,先前的管理模式已经无法适应 40 个人的团队,
猜测以前更多的可能是人情化管理。公司还是期望正规化管理的。
Engineering Manager 的到来未必会有很大的管理效益,但有一点,至少会让大家明白以前的管理
模式已经行不同了,需要是正规化的管理了。也许你们未必完全赞同新的管理模式,但已经开始
向这方面转变了。
仅仅是猜测,仅供参考!

·先从自己着手.(2005-08-30) [作 者] chenrulin [公 司] namtek

几个看法:
1)你需要明白你们经理为什么需要招个 ENGINEER MANAGER?
2)他的职责是什么?他来了后你的职责又是什么?
3)你可能需要调整一下自己的心理. 毕竟看来他是你的领导了. 有些事情需要从长远来看.
4)有些事情可以表现的你在多听他的意见. 让他满足一下. 有时忍耐一下, 对于以后你需要申请
资源会更方便点.

·如何让领导同你站在一条阵线上来?(2005-08-25) [作 者] 周兰 [公 司] 工商银行

看了各位的分析,都很精辟,下面我根据自己的经历给你几条具体的建议:
1、新领导不熟悉目前的环境,总有点颐指气使,觉得下面人办事不力,没有拿出最好的 programme.
你此时就要多汇报、多请示,告诉他工作的细节及进展,一方面满足他的虚荣心,另一方面也要
让他了解你们工作的不容易。最好是能够让他亲身参与你们的计划与活动,这样既可以增强互相
之间的了解,同时也让他除了对计划书之外对项目有更感性的认识;
2、初跟这样的领导难免心情烦躁,苦恼之余,休息休息,看散文,听音乐,散步,如何懂得心理
调节也是项目经理的必修课之一。
3、最后有份责任心,多点宽容心,相信你能够应付得很好。

·协调沟通(2005-08-23) [作 者] derikwoo [公 司] 上海百事可乐饮料有限公司

第 439 页 共 756 页
第 4 章 沟通管理

和上级的沟通的确需要技巧,况且是新到的,他不了解你们的工作情况,如果不做好沟通工作甚
至会让他有种不被尊重的感觉,做为项目负责人,你应该做好他和团队的桥梁,主动的沟通,让
他更了解团队和工作情况,同时参与到你们的工作中来,必要是可以要求你的部门经理一起协调
沟通。

·摆正心态,与人为伍(2005-08-18) [作 者] 曹楠 [公 司] 中国网通北京市分公司

首先明确一下我们的目的,要想在此团队继续职业生涯,恢复以前良好的工作态度,最重要的莫
非与信任领导开始良好的沟通了。
分析一下对方,调整一下自己是最好的解决方案。
俗话说:“新官上任三把火。”每一个新上任的领导,尤其是从其他的部门调过来的,因为对于
原有的部门成员、部门责任都不甚了解,就会害怕成员的否认,遂想方设法竭力表现自己,镇住
原有职员,尤其是小领导们,防止你的气焰压过他。
此时,他最需要的其实就是友善的关爱,因为刚刚来到新的环境,谁都希望有人来为他讲解之前
发生的事情,所谓受恩于人,必当相报。这时你去做他的“知心哥哥”,他不仅会觉得你是热心
人,好相处,而且对于他的咄咄逼人你不与介意,就会更喜欢你了。
试着与他合心相处一下,人之初性本善的。

·好团队突然空降一上司,如何相处(2005-08-18) [作 者] 刘民松 [公 司] 山海天城建开发


有限公司

第一:你是团队的创始人,如果你做的对,团队的人会支持你
第二:摆正自己的心态,不要把自己的喜好影响你和上级的工作关系
第三:一般的管理流程不允许越级上报,但你可以越级申诉
第四:如果你的业务比他强,你可以没问题找问题多要求开会,并请 Manager 参加要求确定,这
样 Manager 能够了解部门实际的工作状况和你个人的能力
第五:这是对你沟通能力的挑战,使你学习沟通技巧的机会,你应该以这种心态去和 Engineering
Manager 相处。

·这是好事情(2005-08-17) [作 者] 曹垣亮 [公 司] 北京普天银河通科技公司

办公室经济的一种。
你需要的是心态,前面几位分析的很深的。
好不好,我们是职业的 PM,是由上司来讲的,不是你讲好就好的。你上司讲你好,就是你自己认
为不好,也是好的。

·向空降師學習(2005-08-16) [作 者] 姚斌 [公 司] 優可集團

第 440 页 共 756 页
第 4 章 沟通管理

大家都分析得很精彩。這里我講一下我的一些經歷。
我所在的公司是一個台資企業﹐由于觀念上的原因﹐我們部門經常有空降的現象。
對于空降兵而言﹐他有專業上和管理上的優勢﹐但他也有對目前公司不是很了解的弱點。
那么﹐做為你現在這一個位置﹐應該是向空降師學習﹐學其所長﹐補你所短。與他密切合作﹐取
得他的信任﹐并讓他對你有"依賴性"。等到空降師走的時候﹐那么這個團隊的接任者﹐我想就會
是你了。
因為你十分了解團隊的情況﹐加上又有了較強的管理經驗﹐所以以公司發展來看﹐公司是不用再
請空降了。
到那時﹐你一定可以大展拳腳了。

·continue building team (2005-08-15) [作 者] Jonathan [公 司] 不公开

其实这种情况在很多公司都有,我建议如下:
1、调整心态。既然是空降兵,那么他自然有能耐,不妨在一旁看看他的动作,也许对你有很多的
提高呢?
2、持续建设团队。这个世界,什么都可以复制,公司的核心竞争力也不例外,但是一支好的团队
却不可能复制。相信如果你的团队建设得很好的话,你的成员都会支持你的。

·互相理解(2005-08-15) [作 者] kongfazhou [公 司] 广梅汕铁路信息中心

突然来了个上司当然心理上难于接受,但环境总是要变的,所以只有自己适应环境了。
不过我觉的新来的 Engineering Manager 做事确实有问题,刚来应该是不动声色,好好观察掌握
团队情况后,在慢慢调整。

·跟你的新的领导好好合作(2005-08-12) [作 者] 杨明山 [公 司] 深圳市银波达通讯技术有


限公司

从你的讲述来看,我认为:
1,在你的新的经理来以前,你们 40 个人应该分几个人带领的。
2,从管理学角度讲,一个领导最多管理不超过 8 个人,正如你说的在你的新领导来以前,你的领
导很忙,不可能照顾好这个日益壮大的团队,因此非常需要一个专业的管理人员,毕竟一个人的
精力有限。
3,如果从你们目前的团队中(也就是你们几个中层领导)培养的话,那么将打破你们团队目前的
平衡,你们以前的几个没有升迁的中层领导不服从从你们几个中升迁的新任领导(你们的上司),
最终导致人才的流失,和谐的团队将不复存在,这是公司不愿意看见的结果,所以采用“空降”
的方式来解决该问题。
4,你目前应该好好的配合你的新领导的工作。你的新领导需要建立他的威信,可能他的方式不合
你的工作习惯,目前做好你的本职工作,毕竟新的领导班子需要磨合。相信随着你们进一步合作,

第 441 页 共 756 页
第 4 章 沟通管理

你们目前的分歧会消除的。
5,最后祝你工作开心。

·管理层次太多(2005-08-09) [作 者] 吴建光 [公 司] 联想移动通信科技有限公司研发中心

已经有部门经理->组长(或项目经理)->组员,三级体系,如果再多一级管理层,对 40 人左右的
团队就不是很合适了。

·这是一个团队建设的问题(2005-08-04) [作 者] 王栋 [公 司] 用友软件

你的问题是一个团队建设的问题。对于一个新的团队或者团队中进来新成员来说,在一定时间会
有一个沟通和工作效率下降的过程,等过了这段时间后,团队才真正进入一个上升期。

我觉得在这个沟通和效率下降的阶段你可以做好两件事情,一是增加沟通的时间,二是耐心等待,
给自己和他人一个相互了解的过程,并在心里要支持他。

希望你能放松心态,从困惑中尽快走出来。

·不如给双方一段相互了解,认识对方的时间和机会(2005-08-03) [作 者] 周永丽 [公 司]
软件外包

实际上 梁桢 已经分析的很精辟了。我这里在描述一下我个人的的想法,以供参考。

领导们用人,更宁远考虑内部培养,在不得已的状况下,才会考虑从外部引入‘空降兵’。实际
引入‘空降兵’的风险很高,很容易出现作者所描述的现象。

作者某种程度上的心理难以接受,也是完全可以理解的。建议,不如给双方一段相互了解,认识
对方的时间和机会。

·三方界定工作权限(2005-08-01) [作 者] 梁桢 [公 司] 上海广平信息系统工程有限公司

其实“空降兵”一词早就存在,对于如何处理“空降兵”和团队之间的关系是个事先需要彼此约
定的事情。

首先,对于 PM 来说对项目负责,对内合理协调成员之间、团队和客户之间、团队与公司之间的关
系等等诸如此类工作。对于“空降兵”的出现应该在其正式到职前和公司约定各自的工作范围,
避免工作上的重叠和工作权限的界定。

第 442 页 共 756 页
第 4 章 沟通管理

其次,对于公司来说部门领导又要接生意,又要从行政上管理 40 人的团队的确会存在精力不够的
情况,所以再选拔一名管理 PM 的人来说无论从行政上还是从工作效率上都可以给部门经理一个从
繁琐中解脱出来的。从管理角度的确是该聘用一个人。

最后,“空降兵”自身的确需要和团队前期合作有良好的沟通,确切的说其本身还不是行政意义
上的部门经理,更多的是助理的角色,帮助部门经理处理、过滤工作上繁琐的事,并对经理负责
的职位,所以语气和工作方式需要注意,“狐假虎威”的情况不能出现,PM 若都不合作的话,可
能会另外再来一个“空降兵”。自然原来的就真的“空降”咯

4.17 项目经理感觉疲于奔命!请赐教

项目经理感觉疲于奔命!请赐教

[姓 名] yuwen [单 位] 不公开 [邮 件] yuwen-juliette@sohu.com


[所属行业] IT 软件 [所属主题] 项目沟通管理 [发布时间] 2005-4-18

【案例正文】
公司研发,检测,认证,制造分别在 3 个国家 4 个城市,每进行一个项目都需要各地之间频
繁的沟通以便能及时协调,避免项目出现偏差。因此,项目经理感觉疲于奔命。加上语言问
题,有时需要反复确认一个问题才能通过。可否考虑在各地各安排一个项目总监,直接与总
部沟通所有项目内容?这样会不会削弱项目经理的管理力度?请赐教

【相关分析】

·应安排项目总监(2007-09-05) [作 者] 毛知新 [公 司] 湖南大学

对案例中提到的问题:
1、对在不同地方的不同项目不能由一人统一管理,应安排项目总监以协助管理。
2、一个人要管理在三个地方的项目本来就不太现实,也没办法管好。
3、通过加强与项目总监的沟通和监督是可以把项目做好也管好的。

·网络给我们带来了无比的方便与快捷(2007-08-29) [作 者] tjh [公 司] cxgs

在当今社会,网络给我们带来了无比的方便与快捷。在大项目或者跨国项目中,如果不使用它,务必

第 443 页 共 756 页
第 4 章 沟通管理

会给项目增加很大的成本和浪费很多的时间。因此,在这些项目中,必须要掌握采用最先进的手段和
措施,才能最有效的对项目实施管理,这样才是非常明智的。现代的远程通讯手段很多,像可视电话、
E-mail、Netmeeting 等等,也可以为远程通讯寻找代理商

·guanli(2005-06-01) [作 者] 程宝祥 [公 司] 西安理工大学

管理的本质是协调而不是事事都亲自到,做好集成管理就行了,小事上要安派人去做。

·沟通计划,执行,控制,反馈,修正!(2005-05-10) [作 者] 赵宏伟 [公 司] 东信北邮

沟通的方式选择,途经多路,而且要高效!

首先都是从计划开始,
计划中对沟通的相关内容都要做一个较详尽的分析和确定内容,
对执行具有指导作用
然后就是沟通的执行,比较灵活的方式,平等的沟通,激烈的脑力风暴
再次 对沟通效果进行评估和控制,做出相应的调整,找到一种适合不同国家不同语言不同思维方式
的较好的沟通渠道,并形成制度化,
最后总结 每次沟通的教训和经验

·沟通与记录(2005-05-03) [作 者] 袁月建 [公 司] 日設融合科技発展(北京)有限公司

沟通固然重要。如何提高沟通的效率,是我们现在所必须面临的问题。对问题一定要落实到个人。只
要这样,才能提高问题的认识。提高解决问题的效率。
电视会议也好。网络会议以及电话会议都是不错的办法。但是,无论什么样的方法。目的就只有一个,
提高工作项目质量。提高工作效率。
1:确定会议方式。
把问题方式确定好以后,我们才可以制定解决问题的办法。比如:电视会议,我们可以采用面对面的
沟通和交流。那么就没有必要把问题描述那么清楚。知道,什么样的问题即可。电话会议,就不一样
了,因为看不到,就必须把问题记录清楚。最好的方式就是在解决问题以前,让对方也把问题了解一
点。并且在记录的时候,问题的多或者少的一方都要注意同样的问题最好不要多次重复出现。
2:如何沟通
会议方式确定了。那么接下来我们就可以研究如何沟通了。最好的方式就是在沟通之前,彼此让对方
了解问题,才有助于提高解决的效率。一定要有很好的记录,经对方的确认后才可以。
3:注意时刻提醒自己。
既然问题就是沟通,那么问题沟通完以后就不是完了。而是让大家都彼此都知道。以后在相同的问题
上,看看记录上是否已经解决。没有解决是不是有类似的。等等。
希望以上几点对大家有点小小的帮助。

·目标、进度、资源、沟通是关键(2005-05-03) [作 者] 郑承满 [公 司] 中国建设银行厦门开


发中心

第 444 页 共 756 页
第 4 章 沟通管理

1、统一目标,统一项目的立项流程,每个项目的目标要清晰,并且每一个项目过程中的提交件要定
义明确,组织架构上要进行明确,不应该基于项目经理的管理力度来考虑组织架构,而应该基于项目
的完成,更好的完成作为考虑点。

2、安排好计划是关键,这种项目中重点关注进度计划、资源计划、沟通计划,并贯穿质量控制的整
个过程。

3、进度计划,要注意 milestone,并且每一个过程都要考虑关键路径,过程中要的质量 checkpoint


点,要注意,不要以为安排入计划中的内容都能自动完成,特别是异地的项目,项目组外的项目。

4、资源计划,要注意过程的衔接,要不研发出来了,检测滞后,没有办法及时完成,因没有检测需
要的资源
5、沟通计划,要注意每个月,每周,每个关键里程碑,关键提交件之间的沟通,这样才能让所有项
目组的成员都明确项目的目标,项目的关键点,必不可少,可以采用电话会议,视屏会议等形式,同
时,核心小组的成员应该一个月一次集中在一起进行沟通。
6、各地应有项目管理人员,最少应有项目助理的角色,协助 pm 做好项目的管理与沟通工作。

·灵活机动、授权充分--项目成功运做之道(2005-05-02) [作 者] 张彤 [公 司] 北京北大金秋
新技术有限公司

如果您的项目不够大,您应该将所有项目成员集中起来,最好建立一个“作战室”,这样看起来好象
是加大了您项目的成本,实际上它可能是您最节约成本的方法;如果您的项目很大而且很复杂,那么
前面各位同仁的建议都是很好的主意,请您择优并结合您组织的特点选用。设立分项目经理并不会削
弱项目经理的权限,当然您要注意不要让您的上级任命分项目经理,任命分项目经理应该是项目经理
您自己的权限。

·非常感谢各位所给的建议。(2005-04-25) [作 者] yuwen [公 司] tcl

非常感谢各位所给的建议。

·这个情况和本公司非常类似(2005-04-21) [作 者] Alan Zoo [公 司] MiTAC

这个情况和本公司非常类似,本公司的解决方法如下:
1>.将项目按照研发、测试、认证和制造分为 4 个子项目。每个子项目安排一个子项目经理。这个子
项目经理可以是专职,也可以是其中的某个项目成员。本公司测试和制造子项目经理是专职的,由该
职能部门提供;研发和认证子项目经理是研发和认证团队中参与项目的人员兼任。
2>.这样,就按照 Program-Project 的模式进行项目管理。效果不错,而且还培养了大量的项目管理
人才,同时为各个职能部门导入了项目管理的观念

第 445 页 共 756 页
第 4 章 沟通管理

·合理组织信息流,优化沟通链!(2005-04-20) [作 者] Manovo [公 司] 江苏徐州

项目的决策和计划依赖于项目的信息沟通。良好的沟通有利于提高项目的决策水平和决策效率,建立
和改善人际关系,为项目经理的成功提供重要的手段。在这个项目中,主要在沟通链和沟通手段两个
方面存在问题,我们的突破口就从这两个方面寻找。
一、沟通链
在这个项目中,它有一个显著的特点就是“1:4”,即一个项目经理负责在 3 个国家 4 个城市的检测,
认证,制造项目,这无疑给项目经理在这几个项目中的协调带与沟通来了很大的困难。我认为可以从
两个方面寻找突破,一是将项目分为检测,认证,制造三个子项目,分别设置三个子项目的经理,全
面负责子项目中的一切事务,项目经理负责从整体、宏观的角度对整个项目进行协调管理,这样减少
了项目经理的管理跨度,简化了项目沟通的链条,使项目的信息流有序的运动;二是按照地域设置四
个子项目,其他如上所示。
二、沟通手段
在当今社会,网络给我们带来了无比的方便与快捷。在大项目或者跨国项目中,如果不使用它,务必
会给项目增加很大的成本和浪费很多的时间。因此,在这些项目中,必须要掌握采用最先进的手段和
措施,才能最有效的对项目实施管理,这样才是非常明智的。现代的远程通讯手段很多,像可视电话、
E-mail、Netmeeting 等等,也可以为远程通讯寻找代理商,如上海电信的 VEIM 多方视频会议系统
(http://www.veim.com)

一点浅薄的建议,请批评指正!不胜感激!

·合理组织信息流,优化沟通链!(2005-04-20) [作 者] Manovo [公 司] 江苏徐州

项目的决策和计划依赖于项目的信息沟通。良好的沟通有利于提高项目的决策水平和决策效率,建立
和改善人际关系,为项目经理的成功提供重要的手段。在这个项目中,主要在沟通链和沟通手段两个
方面存在问题,我们的突破口就从这两个方面寻找。
一、沟通链
在这个项目中,它有一个显著的特点就是“1:4”,即一个项目经理负责在 3 个国家 4 个城市的检测,
认证,制造项目,这无疑给项目经理在这几个项目中的协调带与沟通来了很大的困难。我认为可以从
两个方面寻找突破,一是将项目分为检测,认证,制造三个子项目,分别设置三个子项目的经理,全
面负责子项目中的一切事务,项目经理负责从整体、宏观的角度对整个项目进行协调管理,这样减少
了项目经理的管理跨度,简化了项目沟通的链条,使项目的信息流有序的运动;二是按照地域设置四
个子项目,其他如上所示。
二、沟通手段
在当今社会,网络给我们带来了无比的方便与快捷。在大项目或者跨国项目中,如果不使用它,务必
会给项目增加很大的成本和浪费很多的时间。因此,在这些项目中,必须要掌握采用最先进的手段和
措施,才能最有效的对项目实施管理,这样才是非常明智的。现代的远程通讯手段很多,像可视电话、
E-mail、Netmeeting 等等,也可以为远程通讯寻找代理商,如上海电信的 VEIM 多方视频会议系统
(http://www.veim.com)

第 446 页 共 756 页
第 4 章 沟通管理

一点浅薄的建议,请批评指正!不胜感激!

·控制沟通渠道,提高沟通效率和效果(2005-04-20) [作 者] 吴吉义 [公 司] 浙江远文信息技


术有限公司

沟通渠道公式:N(N—1)/2 表明项目中沟通渠道将随着项目团队规模的扩大而快速增加。如果公司
研发,检测,认证,制造分别在 3 个国家 4 个城市就要注意控制沟通渠道了,否则很可能由于团队规
模过大和跨地区原因造成沟通上的混乱。
建议如下:
各地各安排一个项目沟通总监 PCO,主要职责为本地团队内部思路的统一,综合协调,并作为对外沟
通的唯一通道,全力负责与其他地区团队项目沟通总监的沟通。目的是控制了沟通渠道的数量,保证
沟通有序性。由于每次沟通都事先在本地区内形成统一思路,避免了有什么事找谁找谁,一个事情打
5-6 个电话的情形,有利于提高沟通效率和效果。当然如果有必要,可借助视频会议等途径,控制差
旅等成本。

·各司其职,沟通畅快(2005-04-19) [作 者] 梁桢 [公 司] 上海广平信息系统工程有限公司

在项目分配上,由于时间、区域、工作方式的差异可能引起项目管理的沟通及时性和充分性的问题。
项目中的研发、检测、认证、制造 4 部分的工作分配应该避免交叉和重复。

在项目管理上,有必要在各地区设立子系统项目经理,但还是需要有个中的项目经理来协调不同子系
统间的问题,确保子系统间沟通的及时,并有子系统项目经理及时分配工作给相关人员。本案列采用
强矩阵式的管理方式应该比职能式管理方式好。

在项目沟通上,需要定期召开会议,召开方式可以利用多种通讯方式:视频会议、网络电话、MSN,
根据实际情况选择方式。会议的结束必须要有个方面确认的会议纪要,可以建立 B/S 结构的项目管理
沟通平台,各子系统及时登陆工作进度。在工作时也需确保不同子系统间联系的畅通。

在项目成本上,尽量避免实际的出差,构架现代的通讯网络可以降低长期的通讯成本。

·补充(2005-04-18) [作 者] 任志强 [公 司] 上海

1\通对你的情况进一步分析.
建议:
A1 项目前期应进行培训
A2 每一个地方,根据其任务制订标准说明文件,做为沟通的基础.这需要你的经验积累.
A3 每次明确沟通的范围\时间.充分利用 MAIL,电话\视频;
A4 将沟通反馈的结果及时的传达给这三个地方的负责人员.

第 447 页 共 756 页
第 4 章 沟通管理

·两案并举:WWW.VEIM.COM+沟通控制(2005-04-18) [作 者] 任志强 [公 司] 上海

(1)这个网站是上海电信的 VEIM 多方视频会议系统。


很容易构建项目中的沟通体系。
你可以为项目团队分配号码,通过宽带+PC 或机顶盒的形式
就可以实现。
(2)针对你所述的三个环节。为了减少你的劳累,你应建立相应的标准。做到各分支能自查,并将
结果即时反馈。你应对信息进行分类汇总,制成类似手册的东东。

·可考虑视频会议形式(2005-04-18) [作 者] kevin7389 [公 司] 石化工程公司

各地可指定负责人,不一定叫项目总监,对项目经理负责,不会削弱项目经理的管理力度,但尽可能
请公司上层书面任命,你可以推荐人选;管于联络可考虑视频会议形式,能大大减少出差,降低成本,
节省时间。总之还要靠项目管理制度的有效实施来保证,这是个机会,别放弃!经验会很宝贵!

4.18 项目进行中出现无法解决问题如何进行

项目进行中出现无法解决问题如何进行

[姓 名] 楼洪伟 [单 位] 暂不公布 [邮 件] pro@autoon.cn


[所属行业] IT 软件 [所属主题] 项目进度管理 [发布时间] 2005-4-13

【案例正文】
我从电气自动化转到电子设计,负责一种产品的开发,下面有两个工程师,前期,项目基本按照进
度要求进行,可是最近一个月,进度非常不理想,关键的技术问题总是得不到解决影响进度,自己
对技术不精通,不知如何去把握,请赐教

【相关分析】

·你的问题不是很明确!(2005-06-09) [作 者] 李勇 [公 司] 暂时关闭

首先项目经理要明确职责:
项目经理要对项目的进度负责,而技术人员是不对进度负责的。

第 448 页 共 756 页
第 4 章 沟通管理

从你的问题我看不出是技术难点导致进度问题还是管理产生的问题。如果是技术难点这是项目经理应
该协助解决的,譬如寻找这方面的专家。如果是人员问题,那就是管理有问题,应该着手于管理,如
寻求上层领导或技术人员的直接领导。
从项目经理的要求方面,一个合格的项目经理在技术上的要求是能够与技术人员进行技术交流,但可
以不是专家。如果有问题项目经理如果不是技术专家,就必须能够聘请到第三方的专家帮助自己。呵
呵!项目经理的另外一个职责是能够准确寻找到自己需要的资源!

·项目进行中出现无法解决问题如何进行(2005-05-11) [作 者] 李洪亮 [公 司] 中太数据

找到问题根源,确定问题影响,提交上层;然后发动群众,发动领导,发动一切可动员的力量,找到双方可接
受的方法解决即可.

·团结,再分析(2005-05-10) [作 者] 梁莅 [公 司] 无

你是项目的经理,管理的是一个团队.
当项目出现问题的时候,不是靠一个人去解决的.你要发挥团队的力量.认真的去分析问题出现的原因
和解决的方法.
让团队的力量凝聚起来,这是你的工作之一.

·沟通最重要!(2005-05-10) [作 者] 赵宏伟 [公 司] 东信北邮

作为项目管理人员,并不一定是技术高手! 而是沟通协调的高手!

·技术可以从多方获取!(2005-05-03) [作 者] 韦少才 [公 司] 桂林空军学院 7053

如果遇到技术问题,建议先把项目停一停。项目经理努力考虑一下问题的关键症结!

自己的下属是否也不懂这方面的技术,如果不懂,能不能在短期内补充好这方面的技术(时间允
许的情况下);如果不可以,能否需要邀请专家的帮助;如果这个也不能实施,是否要停止项目的运
作。

·停止是为了更好地前进(2005-05-02) [作 者] 张彤 [公 司] 北京北大金秋新技术有限公司

首先建议您将您的项目暂时停止下来,冷静地分析项目进展困难的原因,发动项目组的全体成员并在
组织内和组织外寻找相关的专家参与,针对您的项目中存在的问题展开几次“头脑风暴”会议,问题
可能来自于多个方面,比如:目前在世界范围内在技术上没有突破?项目成员的技术水平有限?技术
方案有问题?预算不足?等等不一而足,针对不同问题发现多个解决问题的方案,然后优选适合您的
项目的解决办法,退却不是解决问题的办法。

·先分析原因,再寻找解决办法(2005-04-23) [作 者] 郑兵 [公 司] 浙大兰德数据应用部

第 449 页 共 756 页
第 4 章 沟通管理

1、首先得弄清不能解决的原因是什么。是由于在做技术方案时没有考虑到,还是技术方案本身有问
题,还是由于本身难度大,需要很长时间才能解决的。方法就是与项目组成员沟通,如果他们也无法
把握,那么得寻找其它的资源了。
2、在已经出现问题的情况下,不懂是什么原因,要及时审查你的技术方案和计划,避免此类事情重
复发生。

·There should be a technology manager!(2005-04-22) [作 者] jianChen [公 司] 咨询顾


问公司

Actually, there should be a technology manager with you on the project. you can ask the high
level for one!

good luck !

·There should be a technology manager!(2005-04-22) [作 者] jianChen [公 司] 咨询顾


问公司

Actually, there should be a technology manager with you on the project. you can ask the high
level for one!

good luck !

·沟通是解决一切问题的良药(2005-04-20) [作 者] 吴吉义 [公 司] 浙江远文信息技术有限公


项目管理强调沟通的重要性,那是因为通过沟通总是可以解决问题的。
针对案例中提供的材料做出如下分析:
[1]可行性分析阶段工作要加强,特别是技术上的可行性分析。因为就电子信息行业而言,技术问题
常常导致很多风险。
[2]通过沟通向项目成员了解问题的关键点和技术瓶颈所在,当然需要利用有效的沟通技巧和手段。
[3]必要是向高层清晰而诚实地通报项目状态。一起解决影响进度冲突的关键问题。
[4]通过不断学习和经验积累,努力成为技术专家。

·千万不要催促技术人员,采取多方案并行原则(2005-04-18) [作 者] forestlyl [公 司] 北京
IT

第 450 页 共 756 页
第 4 章 沟通管理

其实这种问题常有发生,技术上的事情一开始谁都不可能想全面了,往往在中后期才发现整体架构或
技术路线有问题,这时最首要的一点就是:千万不要催促技术人员,欲速则不达。

你应该先冷静下来,技术上的事情从来都不可能只有一种可实现的方案,应该会有多中方案来解决当
前困难,所以你要做的只是协调其他资深技术人员帮你的项目把把脉,验证一下当前技术的可行性,
如果可行,就加派资源进行攻关,如果方案不行的话就果断换掉,这肯定会暂时延误工期,或者更严
重的整个架构都得动,但你应该有这个心理准备。

总之,不能等着奇迹出现,多条路走一走,就象消遥子的玲珑棋局,这么多高手都解不了,但凭着虚
竹的一招‘置之死地而后生’的打法不也解决了吗,所以你要告诉自己肯定能解决,先把进度放在一
边。

·项目经理不是技术专家(2005-04-16) [作 者] GaoDapeng [公 司] 北京南天软件有限公司

1、明白项目经理的真正含义:不是技术专家也不是管理专家,是界与这两者之间的;
2、学会沟通,满足或了解不同技术人员的想法和期望,冷静的倾听他们的想法,尽可能往一个目标
努力,如果实在不行尽量求大同存小异,保证项目往前进行!
3、向公司申请相关技术专家评审相关技术方案,不要怕公司说你管理不好项目,要知道项目经理不
是技术专家,你的责任是尽早发现问题,协调各方解决问题,让项目按时、按量完成,保证各项目干
系人的期望!

·要冷静(2005-04-16) [作 者] 理想 [公 司] 长春工程学院

你不知的是如何去把握,那么把握的是什么?我也觉得不是把握技术,而是把握人!技术问题应该找
专家来解决,你的任务就是去找那个能解决问题的专家,至于怎么找,就要结合自己的实际情况解决。
这也正是考验一个项目经理的时候。项目经理应该有一个好的心理素质,遇到事情首先不能急,情绪
不稳定不利于项目的实施,要冷静下来,找到问题所在,想办法去处理,就像医生给病人看病一样。
最后,希望你能过了这个坎,圆满完成项目。

·关键路线的问题(2005-04-16) [作 者] 孙鹏 [公 司] 同济大学

既然是关键技术问题,是否负责的是本部门中的一流技术能手?对于这种关键路线上的事情应该加大
力气加强人手把技术攻克下来,项目经理也不一定什么都要懂,但必须把适当的人用到适当的位置上

·问!(2005-04-15) [作 者] easywork [公 司] hp

建议当前采取的办法是:“问”。

第 451 页 共 756 页
第 4 章 沟通管理

你目前只是笼统地说是技术问题,由于认为自己在电子设计方面不是内行,你就不敢去刨根到底地去
问。你的手下一告诉你是技术问题,你就停止不前。

只要你逻辑思维是清晰的,你就应该有足够的信心搞清楚问题出在哪里?当你能具体详细地向大家描
述清楚技术问题到底是什么的时候,你也就快有解决的方法了。

作为一个经理,平时就要注意建立自己各方面的资源。朋友中有各类高手,包括各类技术高手。

所以建议的答案是“问”。

一问你的手下,搞清技术症结。不明白的要不耻下问。
二问其他技术专家,你们三个人的团体,经验和技能毕竟是有限的。

·问!(2005-04-15) [作 者] easywork [公 司] hp

建议当前采取的办法是:“问”。

你目前只是笼统地说是技术问题,由于认为自己在电子设计方面不是内行,你就不敢去刨根到底地去
问。你的手下一告诉你是技术问题,你就停止不前。

只要你逻辑思维是清晰的,你就应该有足够的信心搞清楚问题出在哪里?当你能具体详细地向大家描
述清楚技术问题到底是什么的时候,你也就快有解决的方法了。

作为一个经理,平时就要注意建立自己各方面的资源。朋友中有各类高手,包括各类技术高手。

所以建议的答案是“问”。

一问你的手下,搞清技术症结。不明白的要不耻下问。
二问其他技术专家,你们三个人的团体,经验和技能毕竟是有限的。

·为什么进度会慢下来?(2005-04-15) [作 者] 马渊鸿 [公 司] 安徽网龙

你仔细考虑过为什么进度会慢下来吗?问题到底出在哪里?如果真的是技术问题不能很快解决,就应
该请外援了!否则你的项目在规定的时间内就无法完成,影响整个项目进度!

·冷静的对待(2005-04-15) [作 者] 梁桢 [公 司] 上海广平信息系统工程有限公司

作为项目经理首先需要对项目做可行性分析,风险分析,对于核心问题没有预计到和选择合适团队成

第 452 页 共 756 页
第 4 章 沟通管理

员应该说对于项目的准备很不充分。

其次,当问题出现问题时项目经理需要保持冷静的头脑,切忌乱了掌法导致项目成员急躁。

再次,对于目前的技术问题需要及时和公司领导沟通,增加技术支持尽量保持项目进度,同时也需要
和用户沟通交待遇到的问题,希望给予时间的支持。

最后,希望你能够顺利度过这个关口。

·项目中难以解决的问题(2005-04-14) [作 者] steven zhang [公 司] Interactive Tech


Holdings Limited

项目经理不是技术经理,面对技术上的难题,你可以求助公司的技术经理或者技术专家,如果技术经
理/专家对你的求助不予理睬,你需要及时向上级请求协调。如果技术难题已经严重阻碍项目的预定
进度,你需要及时估算,或者请求技术专家估计解决问题的时限并及时调整自己的进度估算。如果解
决技术难题的时间超过了项目本身的意义,你应该考虑是否将项目进行下去。
你的题目是‘无法解决的问题’,既然根本‘无法’解决,何必再进行项目呢?

·以身做责,从项目本身入手,作好协调(2005-04-14) [作 者] 刘杰 [公 司] 山东科技大学土
建学院

做为一个项目经理,应该从自己的角度出发,从项目的最基本的地方入手,本案中的技术问题,应该
和相关的人员联系好,作好自己的协调工作,作好进度管理,按照项目的计划进度进行操作,作好目
标管理 ,充分发挥项目经理的作用。

·协调推进(2005-04-14) [作 者] yuwen [公 司] tcl

如果是全力投入而不能及,则应考虑增加人力物力上的支持和帮助。项目经理毕竟不是工程师,你要
做的是协调推进,所以技术上薄弱也不要急,有人不薄弱就好。

·责任心是很重要的(2005-04-14) [作 者] yuwen [公 司] tcl

在一个项目运作中,各方面是合作配合的关系,有责任心是很重要的,而不是这是别人负责的项目,
我可以不使劲。所以工程师那边是否由于任务太重而有所懈怠,你还是应该好好了解一下。

·面向项目目标,建立问题解决机制(2005-04-14) [作 者] Ryanwu [公 司] Pansky

第 453 页 共 756 页
第 4 章 沟通管理

1、项目经理的职责是计划、组织、控制项目的执行,以实现项目的目标。项目经理不是技术经理,
他应该始终关注影响项目目标实现的各种风险,采取措施解决影响项目目标实现的一切问题。
2、针对该项目出现的问题,项目经理应该考虑并评估:
(1)该问题是否在技术上真的无法解决?
(2)如果该问题无法解决,是否导致项目目标无法实现?
(3)如果该问题能够解决,需要怎样的条件?
(4)为解决该问题所作的各类投入,是否会影响项目目标的实现?[如进度、成本、市场发布等]
3、为做出正确的评估,项目经理可以:
项目组内部对该技术问题的解决难度,解决方案达成一致。项目经理需要召集项目组的技术人员共同
讨论,达成共识,并制定出行动计划,包括:
A、限定项目组内部解决该问题的工期;
B、向公司申请技术专家以诊断、解决该问题
C、调整项目实施进度计划,并评估由此带来的影响[工期、成本等],并向公司汇报;
4、如果在限定时间内项目组及公司技术专家仍然没有解决该问题,可以会同公司技术专家写出“问
题报告”,向公司管理部门提出解决方案[包括技术变更、项目停止等],并阐述各类解决方案给项目、
公司带来的影响,获取公司管理部门的支持。
5、在公司管理部门批准相关解决方案后,调整项目实施进度计划,依据新的方案实施项目。
总之,在项目实施过程中出现的问题,项目经理应该建立问题解决机制,对如何解决出现的问题有明
确的行动计划。如果该计划会影响项目目标实现,应该及时让项目干系人知晓,以保证项目实施过程
的有序、可控、可预见。

文字

·关键技术是致命的(2005-04-14) [作 者] 小飞熊(flybear) [公 司] no

建议认真论证关键技术的风险。如存在致命难题,怕已经远远超出进度控制的范围,而进入风险处理
的范围了。须知,有的技术问题在现有条件下是不能解决的(向内/外广泛求助能提高更解决的可能
性,但绝非所有问题均可解决)。

4.19 项目管理以外的困惑

项目管理以外的困惑

第 454 页 共 756 页
第 4 章 沟通管理

[姓 名] 涂斌 [单 位] 西门子移动 [邮 件] tu_bin@vip.163.com
[所属行业] 通信与网络 [所属主题] 项目沟通管理 [发布时间] 2003-8-16

【案例正文】
小 A 在一家公司的分公司担任项目经理好几年了。他能力较强,所负责过的几个项目都很出
色,和他合作过的项目组成员都愿意再到他的项目组来。但他的直接经理 B 确是一个很嫉才的
人,很怕小 A 超过自己,但隐藏很好,平时总是笑嘻嘻的,周围接触不深的同事都觉得他是
一个很和气、好相处的人。但 B 在小 A 加薪晋级和培训福利等方面,偷偷地做手脚,不申报
或压制(B 没有决定权,但必须通过他)。平时为了给小 A 多加派工作,B 还作了许多承诺,
但没有一个实现的。小 A 在一个偶然的机会发现了真相和 B 的为人,本想向上反映。但由于
最近分公司老总人事调动频繁,他们都只关心自己的职位变动,根本不会理会此事。

小 A 很困惑,觉得自己在该公司发展没有前途,他该怎么办?

【相关分析】

·取决于上级能力(2003-12-12) [作 者] 周志坚 [公 司] yct

A 要升职肯定绕不过上级 B。根据 B 的能力选择你的决策和行动。如果 B 有能力,有前途,A 就要


与 B 沟通,向 B 表明自己只是一心为他卖命,并用实际行动帮助 B 提升。如果 B 是垃圾的话,尽快
干掉他,当然要有策略,尽量少伤害别人利益。

·公司管理理念(2003-11-14) [作 者] 闫振海 [公 司] 泛友科技

1、公司管理机制不健全;
2、缺乏良好的人才机制;
3、人力资源系统的级效考核措施不透明;

·是该好好沟通了(2003-10-14) [作 者] rluo [公 司] rluo

与人交往,最怕自以为是,其后果要么败走麦城,
要么浪费资源,前功尽弃。我觉得 A 不妨多从几个
角度想想,尤其是 B 的立场。多方打听看看,最好
与 B 坦诚的谈一次。如 B 确是嫉贤妒能之人,则开掉
他,怎么开就不多说了,甭客气就行!开不掉的话
自己走人,另择高枝(说明资源已经用尽了)。
是该好好沟通了
r_luo_hua@tom.com

·是该好好沟通了(2003-10-14) [作 者] 罗建华 [公 司] 广州市

第 455 页 共 756 页
第 4 章 沟通管理

与人交往,最怕自以为是,其后果要么败走麦城,
要么浪费资源,前功尽弃。我觉得 A 不妨多从几个
角度想想,尤其是 B 的立场。多方打听看看,最好
与 B 坦诚的谈一次。如 B 确是嫉贤妒能之人,则开掉
他,怎么开就不多说了,甭客气就行!开不掉的话
自己走人,另择高枝(说明资源已经用尽了)。

·发展优先(2003-10-06) [作 者] 彭军 [公 司] 经营部

人的发展、特别是创业初期与其有一位好的上司密不可分。此案例中 A 的上司 B 已明显成为其发展


的障碍,建议 A 直接向公司高层领导反映,同时以自己的实际工作能力向其证实。如果高层也同 B
一样,即使再有发展前途的公司,你也应果断离开。相信“天生我才必有用”,因为你已没有在此公司
发展的空间。

·要懂得委曲求全(2003-09-01) [作 者] richar [公 司] chief war room

适当的时候要把自己的想法和意见与上司交流。
很少听说把上司干掉,自己升级的,最后是让上司升级,你就接他的位置。

·耐得住寂寞(2003-09-01) [作 者] 张清俭 [公 司] 大连

人事的变动是暂时的现象,凭其才能,必将会超越 B,B 的压制是不会有效果的,A 要耐得住寂寞。

·耐得住寂寞(2003-09-01) [作 者] 张清俭 [公 司] 大连

人事的变动是暂时的现象,凭其才能,必将会超越 B,B 的压制是不会有效果的,A 要耐得住寂寞。

·把握有利一面(2003-08-21) [作 者] w [公 司] sssdfds

同意观点,不过坚持的同时。防止固执,不要盲目的固执在一个已经对自己都不很利的形势下,还委
屈求全;对自己,要有信心,无论何时!都要相信自己很有用。一句话:坚持下去,对自己有信心,
不过不要太过于固执。

·坚持到底(2003-08-19) [作 者] Rocky [公 司] digitalchina

我曾经遇到过这种事,当时我的想法也是"天生我才必有用!"等这类想法。但等我真的离开公司之后,

第 456 页 共 756 页
第 4 章 沟通管理

我发现我的想法是错误。
其实自已应该好好的想一想,自已当初为什么来这家公司,工作了这么长的时间,无论是技术或是业
务还是企业文化,都已于公司融合。如果只是因为这点小事而退缩,你自已觉得对得起自已吗。即使
到了另一家公司,可能也会出现这样的事情,那你岂不是又要换一家公司了吗,这样不知你还要换多
少家.....?
我的建议是,只要觉得公司有发展,可以继续留下去,
方法:要先更可能的了解 B 的想法,把他搞定,要让 B 知道你是在帮他;如果要是搞不定 B 的化,那
就只有忍,等机会,把 B 搞 下去。

·沉默是金(2003-08-19) [作 者] 邵冬燕 [公 司] 產品企划部

B 類型的人屬心胸狹窄﹐好強心極強﹐另嫉妒心占據了整個心態。和此類人相處的確危險極大﹐但能
更好的去鍛煉一個處事社交人的能力。我個人認為假如你的身邊也有著這么樣的人存在的話.你不防
用心和他相處一段時間看是否有改善的機會,總之多一個朋友比多一個敵人要好吧!當然他要是真的
很過份你也不必對他仁慈吧!你認為呢?

·直接与B的上级沟通(2003-08-18) [作 者] falion [公 司] Lenovo

B 已成为 A 工作上的障碍,与己与私,A 必须与 B 的上级沟通,客观地陈述事实,若 B 的上级与 B 想


法一致,只有离开。

·据理力争!(2003-08-18) [作 者] 马渊鸿 [公 司] 安徽山立

与 B 深入的谈一次,如果不能改变现状,那就等分公司老部人事调动完毕后,与老总再谈一次,如果
在没有结果,我个人的意见就是:天生我才必有用!

4.20 如何与上司沟通?

如何与上司沟通?

[姓 名] 孟晓林 [单 位] 网络业务部 [邮 件] meng@chinadu.org


[所属行业] 综合应用 [所属主题] 项目沟通管理 [发布时间] 2003-7-24

第 457 页 共 756 页
第 4 章 沟通管理

【案例正文】
某公司最近走马换将,原来的总经理自己去创业了,公司原来的副总经理接替了原总经理的职
务。但是这个副总以前来自政府机关,其下属的几个人,包括总办主任,顾问也来自政府部门,
对于商业流程,商业规则可以说一点都不了解,只是要求别人符合他们的规定, 要渠道、用
户遵守他们指定的规则。

在原总经理在位时,开展了一个项目,包括对公司网络结构的重新规划,以及网站重新建
设,宣传资料的建立等部分。现在所有的部分都进入尾声,但是由于原总经理的突然离职,而
现任总经理在运营该项目时一直表示反对,造成所有的进度都被强行停止。同时,因运营本项
目造成的到期费用也不再支付。

另外需要说明的是,部分需要支付的到期费用,是某项目经理用很低的价格拉自己的朋友
来做的。这些公司做的工作均得到了原总经理的认可,其作出的规划和产品也绝对是超值的。

如果各位是负责这个项目的项目经理,各位会如何与现 GM 进行沟通,以便坚持把这个项
目完成?

【相关分析】

·无论如何,要保证自己的利益(2003-12-09) [作 者] xuaround [公 司] 软件公司

自己的利益高于一切。

·保护好自己,再力争取主动来展开项目(2003-10-15) [作 者] 拉尔夫 [公 司] 毅力

1、新任总经理需要牺牲一部分利益,这是明显的,而且不可扭转。
2、保护好自己,分清责任和权利。项目的外界条件必定会发生变化,必将导致项目不能完成。将问
题提交给总经理,需要变更确认,同时你必须开出你的条件。项目经理是有说话权利的。权力和责任
是统一的,没有权利和责任分割的道理。在必须负责的面前,新任总经理必定会有所顾及,而不会肆
无忌弹。
3、项目的成功,必须得到高层领导的支持,没有这样支持的项目很难成功。不要忘了,项目需要各
个层次的人员共同协作完成的。

·再和领导商量一次,然后与你以前的合作伙伴进行沟通,(2003-09-28) [作 者] 至尊月 [公 司] 项目
管理部

再和领导商量一次,然后与你以前的合作伙伴进行沟通,寻求理解。

“良将择贤主”,“士为知己者死”,跟着这个人,肯定不会开心,工作也将很难做好,不如离
去。

第 458 页 共 756 页
第 4 章 沟通管理

·(2003-08-31) [作 者] [公 司]

很明显了那位技术人员获得了总经理的认可有更大的问题在后面.那就是总经理还在继续那个项目,只
是让副总经理暂时过渡一下罢了

·多谢各位了!(2003-08-05) [作 者] 孟晓林 [公 司] 网络业务部

该项目经理与其带领的整个 TEAM(除一名技术人员外),全体离职,多谢各位朋友的指点和帮助!

·如何走好?(2003-08-04) [作 者] 杨超 [公 司] 市场部

从描述中可以看出:该项目经理不被信任。如果怎样都无法改变上司的态度,那么该项目经理肯定是
走为上了!如何走却值得好好想一想,问题的关键是自己的朋友还陷在该项目中。如果有合同,那一
切都好办,如果没有合同,我想该项目经理能做的最大努力是把问题上报,如果上报也不管用,那就
是该公司也有问题了!和朋友都认倒霉,趁早走吧!

·别犹豫,快走!(2003-08-04) [作 者] 裴志宇 [公 司] 普天万向物流技术股份有限公司研究


以我个人的经历和经验来看,一般在这种情况之下,最好是做好最坏的打算,赶快撤退。并非是不负
责任,而是领导一旦定了做事的调子,你想要叫他更改,太困难了,即使他的思路或方法不对,他也
只会在实在走不下去的时候,用一种不明显的方法来改正,而且你提意见的人一定会被他支开的,否
则岂不是显得你比他有水平,你想他会让这样的情况出现吗?!不过我也同意各位的观点,一定要先
尽人力,起码要对得起朋友!

·给他点颜色(2003-08-02) [作 者] 影子 [公 司] 有色 23 冶 2 公司

说完了动听的话,我认为可以用比较强硬的口气和总经理说明利害关系,人总是这样的,来点强的,
说不定。。。。。那要看项目经理怎么处理了

·我的看法(2003-07-30) [作 者] 翟先生 [公 司] 电子政务研发中心

这种状况一般很难协调,很明显该经理要建立自己的“小集体”,我碰到过这种情况,基本上很难协
调,因为本身领导已经不信任这些原来员工,我觉得出了换一个环境没有更好的方法。

还有一个途径不知道可不可行:找原来的公司经理探讨此事,让他们给出一些意见,往往有一些事情,
下面的人可能看不清楚事情背后的情况。

第 459 页 共 756 页
第 4 章 沟通管理

至于合同,实在不行,只有公事公办了~

·早点走好(2003-07-30) [作 者] lzj [公 司] volcano

其实到这一步,呆在这里纯粹是浪费时间,要改变上层是很难,而且上层的意思很明显了。
赶紧给自己找条出路最好,或者自己选择混下去。

·如何沟通(2003-07-30) [作 者] 崔学奕 [公 司] jmg printing

这是明摆的事实,GM 的意思是这件事绝对没有再进行的必要性,故项目经理也没有必要再去说服。
可利用合同解决余下的问题。

·简单分析一下(2003-07-29) [作 者] 李亮群 [公 司] 东北财经大学

遇到这种事情确实很棘手,打对于一个项目经理应该保持冷静。
首先,要沟通,直接找这位总经理谈话,分析利弊,来说明项目到目前情况下,如果中止的话会对公
司造成什么样的损失,相信他还不至于冥顽不化的。如果不行;
其次,找公司的上级领导说明问题(公司是有上级的吧?!);
最后,只能用合同保护自己了.

·安定人心(2003-07-28) [作 者] 段路生 [公 司] 广州南方电信系统软件有限公司

由于现任领导班子才走马上任不久,稳定公司原有员工,把由于公司领导的变动给公司带来的动荡影
响降低到最低程度,是领导不可忽视的一个重要问题。所以项目经理可以突出此厉害关系,来建议总
经理把前任遗留下来的工作收尾,即是对项目经理的解脱,同时也可以向其他同事表明一种态度,可
以让大家安心工作。
由于一个说不过去的理由而暂停项目,从而引起相关项目人员集体辞职的念头,我想,总经理应该会
权衡的。

·分析一下总经理的出发点(2003-07-28) [作 者] 郭志新 [公 司] 苏迅公司

补充一句,分析一下总经理的出发点,与总经理沟能一下,可能比较好。

·一点看法(2003-07-27) [作 者] 努诺 [公 司] STHB

第 460 页 共 756 页
第 4 章 沟通管理

饶福华先生的观点很好,做个比较详细的报告,对项目的运作情况、价值进行介绍,阐明完成项目所
带来的利益和好处(尤其是与现任总经理切身利益有关的)以及中断项目所带来的损失,让总经理自
己权衡。能否成功就看报告的效果了!如果不行的话,再怎么促膝长谈也没有多大的作用。

·同意(2003-07-26) [作 者] 郭志新 [公 司] 苏州迅达电梯有限公司

项目成功的基础是有一个良好的 TEAM,如果公司不能正面支持项目经理,在保证合作方的基本权利
的基础上,走了也罢。

·如何与上级沟通(2003-07-25) [作 者] 饶福华 [公 司] LBS

先写一份比较详细的项目报告,主要说明项目的价值所在(应包含潜在的价值)和项目的花费,证明
项目却是超值;还需要说明项目的现状,如果中断,现在的这个项目如何结束;还有就是说明项目现
在中止,对公司有什么影响(也需要包含潜在的影响),权衡利弊,我想作为总经理,肯定不用你教。

如果总经理不理会,有可能是没有理解,再找机会和他当面谈谈,陈明利弊,语气一定要动听,如果
你能把他说动了,就成功了一半。说明时,要把握一点,那就是:这个项目对他有什么好处。一定要
动脑筋想一下。

如果还不行,那就说明再次说明现状,问他如何收尾?
如果他不管,我也没有办法了,只有等机会让他明白这个项目的重要性了。千万不能走,因为你的朋
友还在里面陷着,不能自己开溜。

·合同呢?(2003-07-25) [作 者] 田京平 [公 司] UNIHUB PMO

如果有合同约束,事情还好办一些。否则很麻烦的:(

·补充两句!(2003-07-25) [作 者] 孟晓林 [公 司] 网络业务部

该项目经理已经将本项目的价值和潜在价值对现任总经理进行了分析,但现总经理的态度是,当该项
目经理一提及项目相关问题时,就采取拖延的办法,总说再等等,领导们在讨论下,同时不断通过财
务人员对该部门经理已往的帐目进行核查,并对该项目经理手下的一名技术人员进行多次升职加薪,
使目前该技术人员目空一切,对项目组其他人员指东喝西,对该项目经理也有同样表现,取而代之的
意图昭然若街。

同时,该项目经理无法与该技术人员沟通,不管是工作上谈话,私人的宴请,还是半工作半玩笑的说
明,该技术人员全部推脱或者充耳不闻。

第 461 页 共 756 页
第 4 章 沟通管理

该项目经理就此与项目组其他人员沟通,了解到项目组其他人员已决定集体辞职,并试图劝说该项目
经理一同离开。该项目经理是不是真的就非走不可了?!

4.21 该如何与客户沟通?

该如何与客户沟通?

[姓 名] 严照宇 [单 位] PMU [邮 件] yzy@scbg.org.cn


[所属行业] IT 软件 [所属主题] 项目沟通管理 [发布时间] 2003-7-9

【案例正文】
Z 是一家规模不大的软件公司,2 个月前 Z 公司参加一个大型企业的信息化建设项目的招标,
在给客户的项目建议书中 Z 公司提及了一些比较超前的功能(当然实现起来相当困难),结果 Z
公司顺利中标。<BR>

由于 Z 公司人手不足,于是临时请来 A 担任此项目的项目经理。A 接手此项目后,很快发


现了项目中存在的技术难题,在签订合同的过程也就这个问题对客户作了说明,客户勉强接受
并签订了合同,合同中未再包含项目建议书中无法实现的功能。

需求调研阶段,客户越来越强调项目建议书中所描述的无法实现的功能,并提出当初之所以选
择 Z 公司,就是因为 Z 公司的项目建议书中描绘的这些功能是其它公司不能提供的。A 也尝试
去完成这些功能,但经过多方论证,这些功能在目前的条件下是很难成功的。

对这些功能的讨论已经持续 1 个多月了,还没有任何实质性的进展,A 很郁闷,他应该怎么做


啊?

【相关分析】

·与顾客协商一起解决目前的问题(2007-11-04) [作 者] sanyiecao [公 司] tielu

告诉顾客你也想实现顾客的需要,也进行尝试了,但实在无法做到。你也很无奈和惋惜。把你的的努
力告诉顾客,尽量得到他的谅解。实在不行可减少一些原订费用。

·协商解决的层次向上推移(2003-09-29) [作 者] fjun [公 司] it

第 462 页 共 756 页
第 4 章 沟通管理

同意杨超的建议,在此基础上如果未取得突破,项目经理可向本公司上层经理汇报后,由他与甲方高
层经理进行沟通和协调,将处理问题的层次向上推移,即由更高决策者以拍板决定结果,这样可保证
项目继续进行,而不是目前的停滞和由此带来的不信任。项目经理在此必须提供详细的现场调研报告
以保证决策层谈判的可能性。
另作为教训,在此后的工程中应注意以下几点:
1.商务人员在主持签订合同前的谈判和交流工作时,尤其是大型信息化项目必须保证有技术人员(有
丰富技术和管理经验)参与,该人必须全程参与并由高层准确说明其责、权、得,并就技术实现和周
期等给予商务人员必须的说明和要求。在甲方人员专业性不强的领域提供更多的技术说明和风险说
明。最好的结果是该人员最终转变为该项目实施的项目经理或主要成员,这对于项目的启动和延续提
供更多的便利和高效率。
2.本案例中甲方始终坚持认为必须实现相关功能,作为项目经理在此应该清楚:不能让工程僵持下去,
必须说明和决定结果。认真分析业务需求中与超前功能的实际关联有多大,由于超前功能由 Z 公司
提出,而 Z 公司在商务谈判阶段一般来说对业务需求了解不多,如果经调研后可提出详细及有说服
力的报告,向甲方讲明与实际目标不符或无实现意义,双方在此基础上经更多的沟通,同时有统一的
基本点:即以实现大的目标和里程碑点是可以说明甲方放弃上述要求的。

·慎重妥善处理(2003-08-27) [作 者] 桑林刚 [公 司] 株洲电力机车

一个项目的执行不仅对项目自身进展情况有影响,更重要的是对后续项目的影响。因此本案例要采用
妥善慎重解决办法。

1.从技术实现方面加以说明,任何超前的功能在意味先进的同时,具有技术实现风险的存在。
2.从项目执行方面加以说明,质量与交货期对客户来说,通常是重要的。超前功能的添加除对质量方
面影响外,对完成时间也会造成大的影响。
3.从合同文本加以解释。

以诚相待,相信自己,相信客户。

·了解整体情况,把握真正需求(2003-08-22) [作 者] 糜佳 [公 司] computer

1 了解同行业是否能做到? 在大家目前都不能做到的情况下,要让客户了解选择你们的优势在那边,
以及你们有愿意解决问题的诚意,可以联合其他部门沟通,与她们对客户签署备忘录之类的东西来达
成一个不是正规的协议,你们公司优先为他们解决这些问题,价格从优。
2 了解客户的真正需求,而且合同中也并未包括那些难实施的项目,他现在提出的目的是什么,自己
公司的老板对这个项目的变化有何看法,大家能接受的底线在那里?
3 用其他功能模块说服客户

·建议(2003-08-20) [作 者] 刘刚 [公 司] 康普科技

1、明确现阶段同行是否无法实现;
2、寻找损失最小,又不影响公司的解决方案;

第 463 页 共 756 页
第 4 章 沟通管理

3、可考虑,与甲方协商(商务努力会实现),按论证现阶段最好的方案实施,以后随时升级、更新和
解决问题,此建议视软件或其他行业而定,或签协议具体实施,OK!

·1:1:1(2003-08-18) [作 者] sam [公 司] ABC

作为项目经理,很重要的一点就是沟通,包括客户和公司。
首先,A 应当把客户的意见(难度很大的功能需求)提交给公司,并给出自己明确的建议(如不能实现)。
如自己的技术能力不够,可召开项目组会议,让项目组成员提出建议,将会议纪要提交公司。要求公
司给出明确的应对方案。
其次,根据公司的决定,与客户探讨项目实施的可能性。如果客户坚持,则需引入销售人员与客户进
行沟通。A 则继续关注原项目的进行,保证项目进度。
三,销售部门与客户沟通的结果可能会对项目实施产生影响,故 A 要保持与销售部门的沟通,并对可
能的谈判结果对项目的影响给出评估及项目变更计划。

重要的是,作为项目经理,应保证项目范围的明确性,客户超出原项目范围的需求应及时反馈给公司,
根据决定再作出项目变更计划。没有必要就不明确的需求问题和客户长时间争论,如果因此破坏了客
户关系,那么项目的失败指日可待。

·关键看清本质(2003-08-15) [作 者] huangbo [公 司] chief war room

他们真的是要你的无法实现的技术吗?
那他们招标时怎么就不看清楚呢,不问你们实现没有,具体做过哪些成功的案例?我想他们不过是在
事后增加点砝码而已,你要了解他们领导及技术人员是如何想的,就有好对策了。

·搞清楚关键人物(2003-08-04) [作 者] 杨超 [公 司] 市场部

客户坚持要的功能内容,也许只是客户中领导的意志。我想 A 要想办法搞清楚究竟是客户中的哪些人
在坚持要这些超前的功能?然后有针对性的对这些人做技术说明工作,我认为其中最重要的是能得到
业主技术主管的认同,由他在业主内部做点工作,比 A 自己做要管用的多!

·对问题进行多方评估(2003-07-29) [作 者] 王洪刚 [公 司] 山东中鲁通信

在以上说明中,标书是 Z 公司制作的,A 只是在中标后又 Z 公司请来做项目经理,出现问题后,A 应


首先与 Z 公司进行有效的沟通,第一明确所谓功能目前不能实现,是 Z 公司不能实现,还是整个行业
目前均不能实现,二是确定公司的定位,是否追求创新,三是与用户坦诚的进行正式的沟通,向用户
说明难在何处,所需费用多少,求得用户的正式认可。

第 464 页 共 756 页
第 4 章 沟通管理

·规范合同的执行,减少风险(2003-07-15) [作 者] 郭志新 [公 司] 苏州迅达电梯有限公司

本案例说明,项目投标时必须根据公司能力,实事求事。在合同签约前,应与客户就所涉及技术条件
及风险进行逐一评估,在合同签定后,应认真履行。

项目经理 A 应就技术问题,根据合同要求,与客户达成统一认识,并取在其它方面取得客户的支持。

·调整心态,尽人事而听天命(2003-07-15) [作 者] 赵凌 [公 司] 杭州恒生电子股份有限公司

作为项目经理遇到这种事情非常正常的,作为前期对客户的承诺,首先应该尽最大的努力去实现,例
如:向公司求援,要求公司增加相应的投入等。
如果尽了最大的努力也无法实现,那么向客户提出来,越快越好,和客户沟通提出更改需求或者采用
替代方案。其中最重要的一点要让客户明白,你已经就此问题作了最大的努力。
A 君大不必郁闷,因为问题的起因在于标书,而自己也作了最大的努力去纠正这种问题。接下来的事
情就听天命了

·公司的责任没有必要让个人来承担!(2003-07-15) [作 者] 孟晓林 [公 司] 北京

如果说“这些功能在目前的条件下是很难成功的”那么不妨找专家来对这个‘很难成功’进行界定,
之后 A 可以根据专家所提出的技术解决方案尝试与 Z 公司沟通。

或者说 Z 公司可以提出折中方案,既对合同中不包含的无法实现功能但在标书中提到的功能与用户另
行签署协议,表明 Z 公司在功能可以实现的情况下为用户提供该服务。

目前的问题在法律上不涉及过多的问题,毕竟‘合同中未再包含项目建议书中无法实现的功能’,虽
然用户现在表示‘当初之所以选择 Z 公司,就是因为 Z 公司的项目建议书中描绘的这些功能是其它公
司不能提供的’,但 Z 公司也曾经对用户进行过说明,并且用户‘勉强接受’。作为 A 而言对于本事
件只有功劳的,不必郁闷:)

·重新分析(2003-07-12) [作 者] 张清俭 [公 司] 大连

1、重新对项目进行分析,到底有多少技术问题无法完成。
2、这些技术对客户有何意义。
3、客户需要的信息化功能无法完成,和客户协商变更项目范围。
4、无法沟通,解除合约,赔偿损失,保证公司的信誉。

·说服客户接受项目事实!(2003-07-11) [作 者] 彭桃平 [公 司] 古越龙山

第 465 页 共 756 页
第 4 章 沟通管理

首先一点:当初投标时就应该充分向招标方说明实现所提及功能的困难和存在的风险;第二点,在签
订合同时,如果前面没有说明,那此时也应该提醒业主项目存在的风险,并制订好项目责任书、技术
说明书等,进一步确认项目风险的存在。
事已发生,现在项目也已经开始了一个月,作为项目业主,我想也不愿意更换项目公司;而项目公司,
既然当初抱着中标的态度参与投标,肯定也不希望放弃项目。项目经理现在最重要的就是需要与业主
沟通,极力说明该项目超前功能的风险,尽量劝告业主放弃该功能的追求,同时和技术部门联系,讨
论一个可以尽量接近超前功能的技术来代替难以实现的投标内容,各作让步,相信项目应该可以进行
下去!

·协商解决(2003-07-11) [作 者] 安乃红 [公 司] 北京朗新

我认为这是项目的前期失误,但是作为项目经理这时候就要协调公司内部和客户,重新确定需求和项
目的功能要求,因为现在两家都已投入了不少人力、物力,重新来过的话,公司要赔偿客户损失,客
户要浪费不少资金,那么为何不在现有条件、环境下达成一直,完成项目呢。当然,这件事做起来很
难,不过只要考虑相互的利益,对项目的状况进行准确分析,对客户动之以请,晓之以理。我想项目
会有转机的。

·谁之过?(2003-07-11) [作 者] 陈利仓 [公 司] 北京金利合软件

1、标书有问题:包括一些比较超前的功能(没有考虑实现起来的难度)。
2、项目经理有问题:在签订合同的过程只客户作了说明超前的功能实现难度,没有把风险和责任明
确。

我建议:项目经理积极与用户沟通,说服用户放弃该功能或换底难度的来代替,一直讨论很难有结果。

·项目经理的责任(2003-07-10) [作 者] 田京平 [公 司] UNIHUB PMO

项目经理的职责里面有很重要的一点就是--不要做额外的工作!
如果合同是明晰的,那么按照合同执行就是了;对于合同之外用户的要求可以通过新立项、补充协议
等方式解决;对于功能的要求就需要和用户进行很好的沟通。为了避免这种情况的发生(目前这种情
况屡见不鲜),在项目启动的时候,应该与用户签订工作说明书,工作界面说明等文档,以明确项目
的工作范围。这样,后面的工作就好作多了。文字

·实事求是!(2003-07-10) [作 者] 马渊鸿 [公 司] 市场

我个人认为项目经理中标之前做的标书就有问题,不能为了出新,就不实事求是,标书虽然很新颖,
但是实施起来就没有办法了,结果给自己下了一个套,所以做任何项目要实事求是!

第 466 页 共 756 页
第 4 章 沟通管理

建议:
1。这个功能显然在现阶段是非常的超前的,这点要仔细的告诉用户,并且告诉用户,这个功能即使
实现对用户现阶段也没有太多的用处。
2。告诉用户实施这个功能现阶段几乎是不可能实现的,充分沟通,尽可能让用户理解。
3。解除合约,赔偿损失,保证公司的信誉。

第 467 页 共 756 页
第 5 章 进度管理

第5章 进度管理

5.1 客户为什么迟迟不肯验收?

客户为什么迟迟不肯验收?

[姓 名] Ting [单 位] 上海公司 [邮 件] yiyizq@163.com


[所属行业] IT 软件 [所属主题] 项目沟通管理 [发布时间] 2008-8-20

【案例正文】
一个很小的项目,做得比较顺利,提前完成并上线。这个小项目是附属于前期公司给该客户做的一
个大项目而形成的。总共用了 2 个月的开发时间,现在上线已经三个月了,客户就卡住一个小问题,
说此问题查清后再验收。这个小问题根源就是开发期间有段代码有些小问题,没有解决彻底,大多
数情况下此问题是不会出现的,只有在特殊的操作下才会出现,原来基本上是一月出现一次,客户
方也一直无法找到规律,总是不能重现此 Bug。每次发生这个问题我们的开发人员都积极协助查了
多次,一直没能彻底查清(这种偶发性的问题是非常难查的)。

直到 8 月初,客户终于发现了可以重现 Bug 并告知我们。我们迅速又将错误做了排查,重新做了程


序改动,改正了这个 Bug(在测试环境中,未正式上线)。因为遇到奥运会,客户方不同意部署到生
产环境中,因此验收的问题又再次被搁置。近期又打听到奥运会之后还有残奥会。这期间客户方基
本上不允许更改系统的。晕倒,难道我们这个小问题要到残奥会后才上线?

之前一直和客户沟通,讲明这个问题属于一般性问题,不会对系统造成任何大的影响,此问题应该
放在维护期解决。但客户方老总一直咬定这个问题查清后再验收。不明白为什么这么小的合同额,
客户为什么这么顶真,而且对于其他问题我们处理都是非常及时的,现在整个合同除了这个问题外,
客户也真的找不到其他任何问题了。

我们之前为客户做的大项目早已经验收,和对方主管验收老总交流过一次,他也主要讲了这个大项
目存在的问题,而对我们这个小项目的评价是比较稳定。这么拖下去,真得不知如何给公司交待了!

想请各位帮着出谋划策,这个问题真得有些令人伤脑筋,签个字都不肯!也就几万元!对方客户是
金融行业的大客户。也有些伤心,为什么这么认真负责,还是得不到认可?

第 468 页 共 756 页
第 5 章 进度管理

5.2 *客户要求压缩进度,项目经理怎么办?

(一)案例正文 本文转自项目管理者联盟

一个新产品开发项目,在进行图纸设计时,客户提出新的进度要求,在原计划为 5 个月完
成的项目中,要求将项目提前 1 个月完成。公司高层结合客户需求,同时也看到了产品提
前上市将会很好地支撑公司业绩。因此要求项目经理根据客户要求调整进度。

而公司目前设计人员不会增加,除了项目提前完成能提前拿到项目奖金外,也不会提供任何
加班费用。项目经理意识到这意味着将出现严重超负荷加班,可在弱矩陈的组织里,项目经
理与团队只有硬着头皮无耐地低效率地加班以赶进度。

大家给个建议吧,作为项目经理如何面对这种问题?

(二)专家点评

点评专家:曹济 北京随济科技公司首席顾问/国际软件标杆组织技术顾问/欧洲软件度量论
坛(2006)组委会成员/信息产业部系统集成项目经理委员会成员/IEEE/PMI/IFPUG/ISBSG 会

项目管理者联盟文章,深入探讨。

为上百家的国内外 IT 组织提供过 IT 项目管理、软件项目管理、基础项目管理、项目量化管


理、软件估算和软件度量、软件质量管理、软件测试管理等方面的公开培训课程与企业内训
服务。为十多家软件公司提供 CMM/CMMI 培训咨询服务、软件标杆管理体系培训咨询服务、
项目管理体系培训咨询服务

曹济点评:

首先感谢 Tony 分享自己的案例,大家对于案例也都提出了各自的建议。因为每个人所处的


项目环境(例如客户的特点、公司组织结构类型、团队人员组成等)都不相同,而每个人做
案例分析讨论时又不可避免受到自己潜意识的影响,我们容易将自己遇到过的一些类似的情
形与案例加以比对分析,所以首先确认的是没有所谓的“正确答案”。

我们可以从两个层面来看待 Tony 提出的问题(正好对应问题的两部分描述)。第一个层面


是公司层面,而第二个层面是项目层面。一个项目存在首先要满足它的商业价值,项目对于
客户的商业价值在于客户希望项目及早上市,而项目对于公司的商业价值则在于项目及早完
成,收回项目款。这是我们看到的项目商业价值。如果单纯从这个角度分析我们容易得出结
论:根据客户更新后的要求重新制定计划并实施。

但是可能会有意外,例如项目可能最终仍然还是六个月才完成,或者像很多情形要八个月甚
至九个月最后才完成。出现这样的情况客户事后会怎么说?“对不起,这个是我们自己的错,
我们不应该给你们提不现实的要求打乱你们原来的计划”,会吗?应该不会。所以重要的是
在事先与客户一起分析可能出现的各种后果,到医院做手术家属都要签字说明自己了解手术

第 469 页 共 756 页
第 5 章 进度管理

的可能后果,为什么?客户来做决定,而不是开发商自己来做决定。所以首先要解决的问题
是把对应的后果向客户讲清楚。讲清楚之后两种情况:第一种情况客户仍然坚持,那么客户
要承担相应的风险;第二种情况客户说好吧,我们还是照原来的做法。所以要从项目层面给
出足够的支持信息来辅助客户作商业决策。 http://blog.mypm.net

当然第二个层面谈到如何在资源有限的情况完成挑战性强的任务,这个涉及到一个人员管理
与激励的大问题,大家有兴趣我们可以再继续讨论。

(三)项目管理者联盟网友评论
本文转自项目管理者联盟

分析 1: 题目:Strive best efforts based on the Truth 项目管理者联盟会员:


HSP

I agree with Mr,Chen very much. 项目管理者联盟文章,深入探讨。

In addition, PM should fight for himself and stand up to top management.

分析 2: 题目:只能迎接挑战 项目管理者联盟会员:步硕 项目管理者联盟

重新调整计划、制定方案,按客户进度要求完成项目是项目经理必须接受的现实。 项目管理者联盟文章,深入探讨。

没有不可能,团队潜力的挖掘是考察项目经理领导能力的一个重要方面。
分析关键路线,全面调动可利用资源对缩短项目周期会有帮助。
http://blog.mypm.net

分析 3: 题目:中国人的应对方式 项目管理者联盟会员:吴飞

理论我不会讲。咱属于初级境界的,毕竟从事项目管理工作才 7 年。一句话就是激发员工的
热情。根本不用啥加班费。。。咱这么说,把小头目找来,问最多可以提前几天?答曰不能提
前。。。告诉他们老板要提前 60 天,让他们回去再想想。。。答曰真的只能提前 25 天。和老板
说,只能 25 天,要 30 天可以,给下面的人多发 5 天的工资,否则项目容易失控。得到 5
天工资后告诉工人,老板比大家承受更大的辛苦,一定要提前 30 天完成。希望大家理解。
然后对表现优异的员工予以奖励。最后将所有人的加班费发给表现最好的 3-5 名员工。搞定,
收工。
http://bbs.mypm.net

分析 4: 题目:我的建议 项目管理者联盟会员:zhangmin

我觉得要从三个方面去做工作:
http://bbs.mypm.net

1.尽可能的说服用户不要压缩进度,要举事实,讲道理,让用户觉得盲目压缩进度的坏处等;
2.从公司追加资源;
3.搞好项目内部的工作,激励团队,发挥项目经理的人格魅力.

分析 5: 题目:顾客满意是我们不懈的追求 项目管理者联盟会员:cectanjing

站在顾客满意是我们不懈的追求的立场上,还是应该压缩进度,追赶进度。只有对项目进行
挖潜,同时向公司高层申请追加人力资源或激励措施,否则项目很难完成。

第 470 页 共 756 页
第 5 章 进度管理

分析 6: 题目:激发潜能,适时反馈 项目管理者联盟会员:Jack Pan http://bbs.mypm.net

本着客户至上为事业基础,项目经理不仅要规划各部门工作进度,更要把握各部门人员心态
调整。

首先,客户要求压缩进度自然有客户的理由,把客户的最终目的化为项目各部门共同努力的
目标,激发相关人员的积极性和责任心; 本文转自项目管理者联盟

2.项目重点的计划统筹安排,确定任务时间,责任人及不可达成事项; http://bbs.mypm.net

3.将项目完成进度状态适时反馈给客户。
分析 7: 题目:Strive best efforts based on the Truth 项目管理者联盟会员:chen peng

1. Study reliability and feasibility based on the truth.

2. Adjust your plan after discussion with your team. Build trust in your team.

3. Catch main functionanity of product and negotiate with customer


and supermanagement.

4. If there is risk of failure, say so. Let customer know that


and supermanagement know that. http://bbs.mypm.net

Every thing based on truth and best efforts.

分析 8: 题目:尽可能的寻求资源 项目管理者联盟会员:Isabel

既然是从高层管理下来的指示,可以先从管理层要资源。

直接先和各部门的boss谈好项目的priority,然后尽可能多的争取资源。不见得一定要增加人
手,至少优先级高了项目会顺利很多。同时和客户保持良好的沟通,提高客户的确认效率。
基本上,客户的需求是最大的。

分析 9: 题目:积极应对,迂回处理 项目管理者联盟会员:李俊

从实际出发,先分解任务到各个研发单元,详细的与各任务组分析完成任务的充分必要条件,
需要上级协调的要立即上报并详细解释其重要性,为提高效率则需要延长劳动时间,如无加班
可能则需剑走偏锋"正兵阻敌,奇兵取胜",引入外面的智力来完成任务.用完成任务的奖金来支
付费用.

分析 10: 题目:客户需求----项目存在的意义 项目管理者联盟会员:旭飞 项目管理者联盟,项目管理问题。

第 471 页 共 756 页
第 5 章 进度管理

作为项目工作人员,应时刻保持清醒的认识:客户的需求,是立项的根本,是项目工作人员
存在的价值体现。因此,在本例中,对于客户要求压缩进度的需求,在经过评估后,确认此
需求能够给客户创造价值,那么,作为项目经理,应该接受这个现实,并鼓励自已和激励下
属承担面对现实所需要付出的努力,哪怕这个努力并没有额外的回报。所以,心态调整是首
要问题。 http://bbs.mypm.net

接下来的工作,则需要与团队沟通,对整个工作进行重新规划,对比原有工作进度,进行时
间、内容上的压缩,并再一次理清工作重点,最终与团队形成新的项目执行方案,并对比原
有方案,分析其中利弊,评估新方案的可行性。在可行与不可行选择之间,应以客观的态度
进行,最后与公司上层就此问题沟通,取得上层认可与理解,但是最重要的一点,你仍然得
完成这个项目。 项目管理者联盟,项目管理问题。

http://bbs.mypm.net

对于弱矩阵问题,及其带来的负面效应,唯一的办法,就是沟通与激励,这也是考验项目经
理的领导能力及团队的向心力的时候。

分析 11: 题目:项目风险应对了吗? 项目管理者联盟会员:赵昶 http://bbs.mypm.net

1)当加班成为工作常态时,对项目、团队和公司所带来的负面影响是巨大的:效率降低、
项目成员的抵触情绪以及离职等,而正面的影响基本为零。 项目管理者联盟,项目管理问题。

2)假设原计划的 5 个月是比较合理的,在人员和成本不增加的情况下,能折衷的只有质量
或者范围,需要认真分析,然后提交客户批准。如果都行不通,那项目经理应该及时向公司
管理层发出项目失败的预警,由管理层来决定风险应对方案。

作为项目经理,要坚持的是实事求是,切忌自欺欺人。

分析 12: 题目:不要让项目成员为了加班费而加班 项目管理者联盟会员:karibu

我们公司是有加班费的。但我的感觉,只要一个项目里出现了加班费用,这个项目的总工期
肯定会延长,而不是缩短。具体原因不用我分析了,你自己可以体会。

项目奖金当然是一个激励方式,但不知你们公司传统上奖金的力度如何,贯彻怎样?

我没干过开发项目。但我感觉开发项目是项目组成员扬名立万的大好时机。这时应用一些
cracking, fast tracking 之类的 managing 技巧固然重要,但更重要的是这时的 PM 应挺身而出,
担当起 leading 的职责。越是弱矩阵中,leading 的功能越重要。要建立起一个伟大的 vision,
让项目组成员看到成功后的美好前景。说穿了,这和作传销差不多。或同亚辛之类的精神领
袖一样,激发大家的狂热与冲动。

分析 13: 题目:合理运用,把握时机 项目管理者联盟会员:大兵

时间的压缩能够让公司业绩提升,对于公司任何人来说都是高兴的,但是作为项目经理一定要

第 472 页 共 756 页
第 5 章 进度管理

分析清楚这其中的利害关系,项目失败是项目经理的失职,成功刚是公司的利益,所以接下来
要对此状况进行现实的分析,能不能进行下去或者说会对质量产生什么样的影响,存在什么样
的困难一定要让公司高层明白,了解。对于国内现状看,加班这是常事,但是目的只有一个,要让
项目组员工都能够为你卖命,不然就没戏了。

分析 14: 题目:合理分析,找出其中的可行性 项目管理者联盟会员:pan pan


项目管理者联盟,项目管理问题。

作为一个项目经理,首先应该按照公司的要求,在现有基础上进行分析.有无实现公司目标的
可能性,主要的困难在哪里,这些困难能不能在现有基础上提前予以解决.

如果在现有基础上不能完成,那么需要公司提供什么样的支持才能顺利完成公司的目标.作为
一个项目经理,就应该为整个项目的成败负责,要理性地去做事,如果实在不行的话,就应该及
早向公司提出.当然这里要首先排除那种没经过努力就放弃的想法.
分析 15: 题目:客户要求压缩进度,项目经理怎么办? 项目管理者联盟会员:ly
dia http://bbs.mypm.net

由计划的 5 个月提前一个月来完成项目,真的是有些困难。但是,可以通过赶工或快速跟进
来压缩时间~就是加班不给加班费的例子在现实中也很常见~弱矩阵里需要做好项目联络
员和协调员的工作,适当的给予团队激励措施,你会觉得人绝对是伟大而神奇的~
项目管理者联盟,项目管理问题。

分析 16: 题目:画饼 项目管理者联盟会员:xing jianming

根据你提出的案例,确实有点为难你了.没办法,你要知道这就是中国特色.我看最好的办法
就是你要作好你的团队成员的沟通工作,先画些饼以提高团队成员的信心.鼓动他们完成项
目工作.待工作有了一些起色,看准领导高兴之时,你再去圆你的饼.使你在项目完成之时将
画饼变成现实.使你不会失信于你的团队. http://bbs.mypm.net

分析 17: 题目:学会真实的回报 项目管理者联盟会员:梁桢

项目的时间缩减了 80%的时间,项目人员没有增加,且不谈奖金之类的奖励已经成为不可
完成的任务。即使项目变成强矩阵的方式和一定量的奖励,按期完成工作量也未必能完全确
保质量。商机的把握不但有时间上的准确,同时也需要质量做为基础。

所以如果公司看好这个项目可能带来的前景应该为此配备相关人员提高工作效率,做为项目
经理必须和公司阐明自己的观点,因为项目经理对项目负责,项目的失败就是自己的失职。
项目经理有权利也有义务向公司阐明项目情况,以便公司做出正确的决策。在没有任何支持
的情况下,团结团队成员尽力做好当前工作,务必要扎实。

第 473 页 共 756 页
第 5 章 进度管理

5.3 客户需求变更导致延期怎么办?

客户需求变更导致延期怎么办?

[姓 名] zmf12 [单 位] 北京某公司 [邮 件] xx@163.com


[所属行业] IT 软件 [所属主题] 项目进度管理 [发布时间] 2007-10-30

【案例正文】

公司接手的一个中型 MIS 项目,在该项目进行期间,客户不断的更改需求,


公司负责人考虑到与客户的关系,要求项目经理服从客户的要求。结果,虽然项目经理
对项目其它方面的控制都没有问题,但由于客户需求的频繁变更,项目最终还是被延期
了 3 个月,质量也不尽如人意。
问:如此情况,项目经理该对项目结果承担什么责任?如果你是项目经理,遇到这种
情况你该怎么办?

【相关分析】

·需求确定和沟通(2007-11-09) [作 者] 章毅 [公 司] 银海软件

1.作为项目经理应该确定好需求范围,如果客户对本身需求比较模糊,应该主动引导客户,尽可能多
的获得需求。需求确定后应该找客户确认签字。
2.如果客户提出要更改需求,要考虑工程延期和质量问题,需求更改会直接导致质量降低,因为需求
变更的控制是在比较难。如答应要更改,更改所产生的负面影响要给客户确认。
3.上级领导强制要项目服从客户需求变更,要和领导多沟通,也要说明项目情况和如果项目出现问题
自己的权责要明确,要上上级确认。

·客户需求变更导致延期怎么办?(2007-11-09) [作 者] 吴言 [公 司] 工程建筑装饰

分析如下:针对此案例,我认为:做为此项目负责的项目经理,在与客户的沟通中存在问题。应该利用自己
的专业知识说服客户相信原计划的正确性,并尽量让客户明白频繁变更导致的后果。因项目最终的延
期,我认为项目经理负责有沟通不利的责任,至少承担一半因延期产生的损失。

·客户需求变更导致延期怎么(2007-11-08) [作 者] yt [公 司] ztzgs

业主提出变更要求,项目经理应及时组织项目相关人员在规定期限内提出变更确认和变更工程价款的
报告.由于业主的原因项目经理可以提出费用索赔和工期索赔.
但对于工程质量问题或没有达到业主的要求项目经理承担相应责任.

第 474 页 共 756 页
第 5 章 进度管理

在施工过程中应加强质量控制.
项目经理在施工过程中即没有履行变更索赔程序又没有加强现场的质量控制造成的后果应由项目经
理承担全部责任.

·工作程序可调整(2007-11-08) [作 者] 刘悦 [公 司] 郑州歌亿房地产开发有限公司

1.借鉴建筑行业的经验,可以在具体实施一个项目之前,增加需求分析阶段。在这个阶段解决客户与
需求有关的问题,通过充分沟通,将客户的需求最大限度的描述清楚,并要求客户给予书面确认。
2.依据客户确认的需求,制定严格的进度计划,并要求客户给予书面确认,一旦发生需求变更,可以
通过分析进度计划确定工期的顺延。
3.制定严格的变更管理流程,客户的需求变更应通过项目经理签发,项目经理在签发变更前应向客户
提供工期和费用的增加额,这样可以给客户提供更准确的决策依据,也可以降低变更的随意性。

·做好需求建议是关键(2007-11-07) [作 者] shuyusun [公 司] 天津

客户不断提出需求变更,那就有一个问题,客户为什么要不断提出变更?可见客户自己对项目并不是
很理解,在项目的进行中有了想法,就要求项目团队加进去,所以,问题的本原在于,从一开始就要
了解客户的需要是什么?他们会有那些潜在的需要?这项工作从一开始做好,并得到客户的确认,对
后续的工作会有好处。
在这个案例中,我感觉因为双方已经有了一定的了解,所以,放松了对需求的明确,这也是造成工作
被动的原因,所以还是应该严格遵守项目管理的基本程序。
如果企业在做类似的项目时,对项目可能达到的结果等种种细节提前告知客户,多从客户的角度想想
客户到底需要什么,做好一个需求建议,相信问题会较圆满解决。

·有的放矢(2007-11-07) [作 者] 陈中民 [公 司] Canon

在任何软件项目的开发过程中,需求的变更都是不可避免,重要的是采取什么样的办法使变更对项目
的纳期和质量的影响将到最低,尽可能地使客户满意,但是也不能一味迁就客户。对某个人的责任也
不能一味地追究,这是没有意义的,再说也不可能是某一个人的责任。
对需求变更应该做到:事前要明确定义,事中要严格执行,事后总结经验教训
事前也就是项目开始前要明确项目的范围,制定变更管理策略(如:采用瀑布模型的开发方法还是迭
代模型的开发方法),制定严格的用户参与的变更管理流程。对项目的目标有严重影响的变更事前要
都用户说明可能的处理方法,如:拒绝或接受变更,但是必须增加资源(成本、时间等等),让用户
提前有心理准备,当然,在项目的执行过程中,用户可能不认帐,那就要动用公司的各种资源解决问
题。
事中要严格按照变更管理流程处理变更。首先要分析变更对项目的影响,提交公司领导与用户,记录
变更;充分地与用户沟通,让用户知道变更对项目可能产生的影响;最后讨论解决办法。
若变更是可有不可有的拒绝接受,若变更是非常重要的则提请公司增加资源(人员、资金,),也可
以变更交货期。
事后总结变更对项目的最终影响,让用户了解产生这样的结果的前因后果。

第 475 页 共 756 页
第 5 章 进度管理

总之,在处理变更时,不要自乱阵脚,做到有的放矢,这样既能保证质量,有能让用户满意。

·客户需求变更导致延期怎么办?(2007-11-07) [作 者] liuwei [公 司] 珠海市安克电子技术


有限公司

其实我国目前 IT 行业所能做出的软件百分之八九十存在的或多或少的问题,这些问题产生的原因主
要是需求分析不明确以及软件开发人员的能力问题所造成,从这两点可以看出公司的管理方面也有着
很多的问题.客户提出需求能不能增加都不知道如何回答,或者有些项目经理根本找不到问题的源头
在哪里,这些都是企业内部培训的漏洞.大多数的企业老总把员工招来经过简单的培训就直接上岗工
作,这样虽然节约了培训的成本,却在以后的工作中工作效率始终不高,效益也得不到最大的体现.优
秀的公司都是被野蛮客户锻造出来的,既然我们已经遇到和发现了如此多的问题,那就要找到问题的
根源所在,不断的提高自我的同时其实客户也同样在提高.

·项目的范围没有界定清楚(2007-11-06) [作 者] 王金龙 [公 司] 保密

项目的特点之一就是逐步完善,但是逐步完善并不等于变更项目范围,项目管理的前期工作之一就是
要进行项目范围的界定,如果说范围没有界定清楚,而且在合同中也没有明确的规定,那么客户的要
求就无法拒绝,客户可以认为是项目逐步完善的过程。
如果说项目的范围开始时已界定清楚,合同也明文规定,那么客户再进行其他的需求或者变更需求,
我们可以认为客户违约,如果考虑关系问题,尽量满足,那么项目的延期就不能怪项目经理了。企业
和项目经理在进行项目前期运作时,应该考虑项目潜在的风险,尽量走正规的管理路线,不要太过迁
就客户,而且有责任提前帮助客户明确需求。

·变更措施(2007-11-06) [作 者] mashuqi [公 司] 北京

项目的频繁变更,需要注意不要偏离项目的目标。同时对于变更必须要随时文件备案,对于变更也要
做好风险计划。

·客户需求变更导致延期怎么办(2007-11-05) [作 者] ZPM [公 司] 北京秉泰健管科技公司

针对具体情况可能要采用的办法:
1,分批分次提交版本,每个版本中完成部分需求
2,把客户的需求及需求的变量情况写到书面上,并让客户领导知道,万一项目延期可以有证据说明延
期有可能与需求变更有关.但是,客户做需求变量前尽量和用户多讨论讨论,让客户考虑好再变更.
3,如果项目的需求一直在增加,可以和销售人员一起和客户沟通,能否先完成第一期的需求,先把产品
或者项目上线运行,其他的需求可以放到二期中.

第 476 页 共 756 页
第 5 章 进度管理

在本案例中可能适合用第 2 种办法,如果项目经理能让客户方领导知道延期是与需求的变更有关,则
我认为公司的领导会给项目经理一个合理的评价的.

5.4 如何推进项目的验收工作

如何推进项目的验收工作

[姓 名] 陆莎 [单 位] 广州京华网络 [邮 件] iamsafe@126.com
[所属行业] 信息技术 [所属主题] 项目进度管理 [发布时间] 2007-7-30

【案例正文】
客户背景:政府单位,客户内部的关系错综复杂,每个部门都各自为战,没有一个部门可以
做为领头羊的。

项目背景:我们项目的目的是要推广到此单位的各个部门,并且各个部门都要使用起来,只
有推广成功了,才可以验收。

现在的问题是:项目的工作都已经完成了,但是验收却迟迟无法进行,原因是各个部门都没
有使用,也没有部门肯验收,导致目前项目大大延期。

各位,是不是有什么好办法可以推进项目的验收工作呢?

【相关分析】

·对政府项目的思考(2007-09-13) [作 者] max meng [公 司] FNS Pty Ltd.

政府的项目,关键在于政府方的项目负责人。如果该项目负责人很强势,只要他认可,验收基本没有
问题,如果他还不认可,那毕竟也是项目经理自己能做好的事。

最困难的是甲方的项目负责人不得势,如将被降职、调离、不被重用等,那项目得验收是困难的。
遇到此时,最关键的是要找到甲方新的强势负责人,这人可能是原来负责人的领导,也可能是与原来
负责人较劲的平级同事,确定能将项目往前推的新的强势负责人以后,项目经理要与新负责人确定后
续工作的流程和要求,在他的支持下,最终才能 CLOSE 这个项目。

第 477 页 共 756 页
第 5 章 进度管理

·推进项目验收浅谈(2007-08-22) [作 者] fenny_liao [公 司] 厦门亿力吉奥

本人多年的经验,相信对您的项目验收能起一定作用。
1、首先,PM 应该清楚验收是项目工作的一部份,只要验收完成,才算项目工作完成,因此 PM 在
制定计划时应该把试运行及验收的计划部份排项目计划表中,便于执行、跟踪,而不是做完开发工作
就意味着项目工作完成。
2、项目开发工作完成后,PM 自以为项目工作已经完成,没有意识到后期工作也是项目工作的关键
点。项目组跟客户接触最频繁的阶段就是前期跟后期阶段,因此在前期调研工作时,作为 PM 就应该
做好客户关系,特别是项目总负责人(最好是较有权威领导,或领导指派某一具体人员负责整个项目
的协调工作),跟各部门参与调研的人也要保持与良好的关系。在研发阶段,虽说客户的接触较少,
但做为 PM 还是要保持同客户的沟通,要定时拜访客户,为项目试运行准备打好基础。
3、针对“客户内部的关系错综复杂,每个部门都各自为战”的情况,做为 PM 在项目前期开展时就应
该意识到,然后根据第 2 点的方案逐步规避风险。
4、在项目研发进入测试阶段时,做为 PM 就应该加强同客户的联系,沟通,做好项目试运行计划,
并同客户项目负责人进行协商,确定试试运行方案(明确参与试运行的人员、各自负责的模块,试运
行)。
5、试运行前最好组织一次大型的培训(最好有环境能让参与培训人员现场操作,才有培训效果),由
领导主持布置工作,强调系统的重要性及各部门必须积极参与,试运行的工作比较好开展。
(由于是
政府部门,可以搞一些优秀学员的名额,提高参与的积极性)。
试运行培训工作不可忽视,不但可以加强项目组与客户之间的交流,也可以加强客户内部之间的交流。
6、对于试运行培训客户提出的需求,及试运行期间反馈的意见,一定要及时解决并加强与客户的沟
通,但 PM 要切记,控制好项目的范围,这个时候最容易把项目范围扩大。

试运行工作若能很好开展,相信项目验收不成问题。

·这里讨论更应该是实际操作,非理论知识!(2007-08-07) [作 者] teresa [公 司] 广州

题目是“如何推进项目的验收工作”,需要具体实际的操作!非理论知识阐述,请精准了解“如何”两字!

还有,每个人都是有空的时间过来分析,请针对题目发表自己的观点即可,不用对别人的分析过
多言语,毕竟是案例分析,不是案例辩论!

这类如何题目,分析者据自己的项目经验给出处理提点,是切题的,是否对错,旁观者自会是状
况吸收对自己有益的观点,所以发表自己的观点即可,既要辩驳,也请给出应对的处理!

一点意见,毕竟时间宝贵!

·项目事实上就是没有完成(2007-08-02) [作 者] 梁桢 [公 司] 百瑞杰信息咨询

看来 LZ 是第一次接触政府部门的项目。

在政府内部推广应用首先需要领导接受,其次通过通过领导以行政方式让各部门接受,做为项目

第 478 页 共 756 页
第 5 章 进度管理

实施单位需要在行政命令下将项目能给各部门带来的作用细细阐明。也就是说先狐假虎威,然后晓之
以理动之以情。

单纯的希望各部门主动接受该项目是单纯的想法,毕竟新项目将改变其原有工作方式,如果不能
让使用者主管上不反对就能相对较顺利的推行,相反使用者主管上反对就会对项目的推动起到反作
用。

一味的以为将所有文档都准备齐全就能通过项目审批,绝对是错误的方式。项目成功实施另一个
标准是甲方会使用该系统,所以 LZ 的项目并没有完成。

项目经理应该预见到,而不该埋怨甲方不配合,也许是自己工作没有做的充分,如何协调政府内
部领导和使用者关系也是重要的工作。

·简单问题复杂化了,复杂问题简单化了(2007-08-02) [作 者] daijiangbao [公 司] 深圳市大视野企业


管理顾问有限公司

我看了大家的分析,认为如下:
1、验收问题实际是前面问题、风险没有处理好,最终表现为风险的爆发量,这个问题的解决是要付
出代价的,不是那么容易的,所以不能就表面现象去解释本质,也不能就表面现象解决问题而获得问
题的实质解决。
2、按照合同办事无疑是对的,如此也可以算验收,但是不能是真正的验收,真正的验收是能够把相
应的项目款收回来,如果粗暴的用合同来彻底约束客户,客户表面上也能在一张擦屁股纸上签一个什
么东西,但是不会给你付款的,只要不付款,所谓的验收也就是擦屁股纸一张而已,在这种情况下,
客户(实际上绝大多数人都不明白谁是真正的客户)可以有各种理由来拖着不付款,漫漫长路去讨债
吧,也可以有说理的地方去说,结果如何只有经历过这些的才清楚。

·如何推进项目的验收工作(2007-08-01) [作 者] 李有贵 [公 司] 天津大学

正如文章所说,主要问题是项目验收问题。原因是甲方不验收,我支持“遵守合同规定”的观点,合
同中是否有相关条款说如果在得到通知後甲方不验收则默认为通过验收?
在等到验收通知期一过,则通知政府项目负责人合同条款的生效。当然之前跟其负责人说明其情况。
如果是在默认验收通过的情况下,接下来面临的一个问题是:项目款是否能如期结清。并且考虑到长
期合作问题。在此就得通过沟通,说白点就是饭局之类的类解决。

·PM做的不到位(2007-07-31) [作 者] teresa [公 司] 广州

以前做过不少政府的项目,也是多部门使用,多少有一点经验可谈:

1、对方的负责人?
这样的项目,政府那边应该也有人具体负责,不会让你一对多部门的。项目实施中,你们还会不断联

第 479 页 共 756 页
第 5 章 进度管理

系那边的人,获取资料,汇报工作进展等等,这总该有吧。如果没有,PM 就失职了,客户没有项目
负责人,你找谁获取信息,确认需求?就我的了解,政府部门一定有领导负责此项目的,至少出现现
在的情况,感觉 PM 没有良好推动这个人,沟通交流不够,不能把握客户。

2、试运行?
这样的客户,一定要存在试运行,以我的项目经历,试运行这条都是写在合同中的,什么时候开始试
运行,试运行的时间,一定期限内不反馈意见,视为通过试运行,开始正式验收。当然对于政府单位,
也许此条在实际中会有灵活做法,不过合同中写明,多少有约束。

项目作完,一定要去客户现场,进行试运行演示大会,让相关部门参加,这标志项目工作告一段落(对
于项目而言,也需要清晰的阶段结束),开始试运行,表明此期间需要收集试运行的反馈,会及时修
正,试运行时间过后,会开始验收,然后进入维护期等等。

这个部分 PM 的沟通很重要,软硬兼施,需要推动客户项目负责人去做,其实在政府部门,是看政绩
的,这项工作的完结,开个演示大会也是在展示成果,那边的领导其实是愿意作的。

不过和客户项目负责人的关系需要良好,项目实施中,需要不断和客户联络,实施汇报进展,让客户
了解。

3、此时才可谈验收?
试运行中,发现的问题需要积极反应,记录所有问题,尽快修正,并及时回馈客户。试运行完成后,
将所有问题及回复发一份给客户,积极准备正式验收,提请正式验收,配合客户的要求。

这个正式验收,在政府单位,应该是个隆重的大会,邀请各方领导,如果项目意义大,可引导客户负
责人搞成项目鉴定,邀请行业专家参与,为下一步报奖做准备,基本和正式验收也差不多程序,只是
多了外部测试机构的测试,和专家介入。对于关注政绩的政府部门,只要你良好引导,领导一定会积
极配合的。

其实一个项目不同的人来作,很不同,至少我觉得这个案例的 PM 问题不少,不是做完技术工作,项
目就完成,也不能教条按照 PMBOK 去做,很多还是适应实际形势而为。

·PM做的不到位(2007-07-31) [作 者] teresa [公 司] 广州

以前做过不少政府的项目,也是多部门使用,多少有一点经验可谈:

1、对方的负责人?
这样的项目,政府那边应该也有人具体负责,不会让你一对多部门的。项目实施中,你们还会不断联
系那边的人,获取资料,汇报工作进展等等,这总该有吧。如果没有,PM 就失职了,客户没有项目
负责人,你找谁获取信息,确认需求?就我的了解,政府部门一定有领导负责此项目的,至少出现现
在的情况,感觉 PM 没有良好推动这个人,沟通交流不够,不能把握客户。

第 480 页 共 756 页
第 5 章 进度管理

2、试运行?
这样的客户,一定要存在试运行,以我的项目经历,试运行这条都是写在合同中的,什么时候开始试
运行,试运行的时间,一定期限内不反馈意见,视为通过试运行,开始正式验收。当然对于政府单位,
也许此条在实际中会有灵活做法,不过合同中写明,多少有约束。

项目作完,一定要去客户现场,进行试运行演示大会,让相关部门参加,这标志项目工作告一段落(对
于项目而言,也需要清晰的阶段结束),开始试运行,表明此期间需要收集试运行的反馈,会及时修
正,试运行时间过后,会开始验收,然后进入维护期等等。

这个部分 PM 的沟通很重要,软硬兼施,需要推动客户项目负责人去做,其实在政府部门,是看政绩
的,这项工作的完结,开个演示大会也是在展示成果,那边的领导其实是愿意作的。

不过和客户项目负责人的关系需要良好,项目实施中,需要不断和客户联络,实施汇报进展,让客户
了解。

3、此时才可谈验收?
试运行中,发现的问题需要积极反应,记录所有问题,尽快修正,并及时回馈客户。试运行完成后,
将所有问题及回复发一份给客户,积极准备正式验收,提请正式验收,配合客户的要求。

这个正式验收,在政府单位,应该是个隆重的大会,邀请各方领导,如果项目意义大,可引导客户负
责人搞成项目鉴定,邀请行业专家参与,为下一步报奖做准备,基本和正式验收也差不多程序,只是
多了外部测试机构的测试,和专家介入。对于关注政绩的政府部门,只要你良好引导,领导一定会积
极配合的。

其实一个项目不同的人来作,很不同,至少我觉得这个案例的 PM 问题不少,不是做完技术工作,项
目就完成,也不能教条按照 PMBOK 去做,很多还是适应实际形势而为。

·我感觉奥还说了与没有说是一样的(2007-07-30) [作 者] daijiangbao [公 司] 深圳市大视


野企业管理顾问有限公司

这种情况不是政府项目特有的,不必抱怨政府,关键是在于照猫画虎描出来的项目管理显得不管用。
实际上很多人都通过了 pmp 考试,但是确没有真正领会 pmbok 中对这种问题的说明何解释,关键的一
点是:当项目干系人的责任没有尽到后,项目将会非常困难,这个话的意思是这样的,原话可以在
pmbok 中准确解释,如果需要,我可以找到说明在××页××行。
对照 pmbok,你应该明白现在这种情况的的原因,找到原因之后,你才能够有所做为、有所不作为。
不能想当然的认为把东西作出来,试运行也可以了,客户就应该验收、付款,没有这样的事,国内没
有,国外也没有,这种情况不是中国特色,也不是中国政府的特色。

·我(2007-07-30) [作 者] 奥还 [公 司] 111

第 481 页 共 756 页
第 5 章 进度管理

我感觉你这个项目不知道是怎么实施完成的,存在那么多的问题,我先说一下我自己的处理方法:1)
联系政府部门这个项目的总负责人,记住不是部门的负责人,必须是部门负责人的上司,因为上级说
话好使。
2)把你的文档,详细设计,测试计划,交给甲方项目负责人。
2)工作已经完工了,但是必须要做试运行,没有直接验收的,这个你要做一个详细的试运行计划,
包括反馈信息等,交给项目总负责人确认,包括各个部门的实际运行状态,先试运行,不要说验收,
而且要试运行的客户反馈结果。由他下达给各个部门。
3)试运行的时间可以根据实际情况定为一个月,2 个月等。试运行完毕,你可以根据反馈作修改,
这些需要交给甲方总负责确认。包括有什么问题,都要让他知道,在试运行。
4)如果没有什么问题了,就可以做验收了。

5.5 项目组经常拖延进度的问题

项目组经常拖延进度的问题

[姓 名] 申力行 [单 位] 保密 [邮 件] shenqj@tom.com
[所属行业] IT 软件 [所属主题] 项目进度管理 [发布时间] 2006-2-20

第 482 页 共 756 页
第 5 章 进度管理

【案例正文】
我们公司是一个做电力 MIS 系统的软件公司,规模比较小,只有 30 来个人,公司有自主开发
的也算比较成熟的 MIS 软件系统。

客户是全国各市县电业局,我们公司采用的是项目承包给制度,也就是合同签下来后,公司
领导根据该项目需求核定工作量,比如工作量是 10 人月,也就是相当于 5 人做 2 个月或者 2
人做 5 个月等等,然后规定 1 万元 1 人月,也就是说这个项目承包给项目组 10 万元,等验收
的时候,用这 10 万元减去该项目组所有花费的成本就是该项目组的项目奖金。项目经理有绝
对的权利,可以对该项目组成员每月进行考核,体现在工资上面,另外可以根据项目进展情
况,增加或者减少项目组成员,还有分配项目组成员奖金的权利。

这种制度应用以来,项目组积极性很高,也大大的节约了成本,项目奖金也可观,但是这也
引起了一个问题出来,比如项目核定工作量是 10 人月,项目经理为了节约承包或者说自己赚
钱,就一个人做,做 7、8 个月才验收,或者开始 2 个人后来一个人做 5 个月才验收,本来公
司跟客户签合同要求 4 个月验收,拖延工期对客户关系和公司工程回款产生很大的影响。

这种方式成本是节约了,但进度受到了极大的影响,前段时间,我建议公司采用挣值法管理
项目,但只对成本,好像对项目进度没什么效果,请问有什么办法解决吗?能有什么办法鼓
励大家做到提前或者按时项目验收,怎么惩罚拖延验收的行为,即使拖延了,也采用什么办
法尽量拖延时间短一点呢?进度管理用什么方法管理好呢?

【相关分析】

·建立好业绩考评制度(2006-05-30) [作 者] 制造太阳海 [公 司] 开发部

这个案例是由于业绩考评制度存在一定的问题所造成的,对于项目团队的任何一个人,需求进行激励机
制,以提高人员的积极性从而提高工作效率,采用业绩考评制度,将团队成员的工资与业绩挂钩是一种
很好的激励制度,但,该公司的业绩制度存在一些致命的弱点,一,项目经理的独权,这是很不合理的,任何
一个团队,项目经理不能有权力拖延项目的进度而减少人员,从而提高自己的收益,因此,在这一点上,业
绩制度应该加上项目质量跟奖金挂钩,就算你一个人完成一年,只要你这样影响项目质量,那么仍然不
能有奖金;二,项目经理的考评应该跟其它成员分开,并加上管理绩效;三,项目经理调配资源应该在公司
有相应的制度进行考核,确定团队资源是否应该调进调出;

·项目管理不能通过经济杠杆(2006-04-27) [作 者] 安乃红 [公 司] AMDOCS-LONGSHINE

严格的讲,项目经理是不能决定他的项目组成员的收入的,项目组成员的收入要通过绩效来确定的。
这个案例的情况也许在小公司能发挥他的积极的一面,但是要从长久的良性的一面看,不利于公司的

第 483 页 共 756 页
第 5 章 进度管理

发展,这个就是案例中的公司要决定得了。如果要公司发展好,就要严格的走项目管理,如果只是为
了转目前的钱,那就用现在的考核制度。但是你说的问题就必然存在了

·进行时间和成本的平衡(2006-03-15) [作 者] 银勇平 [公 司] 中南林学院

首先,要对项目概念有正确的理解。项目是提供独特产品或服务的一次性活动,必须在一定的时间、
成本约束下,按客户的要求完成项目。在必要的时候可以进行时间-成本平衡,如当项目时间紧迫,
可考虑增加赶工成本。对于公司的这种特殊情况,在项目承包之前留一定的风险储备金,如 10 万元
留 1 万元,当项目提前完成,把风险储备金再转给承包者,如拖延多少天,将按比例扣除。

·项目进度的管理(2006-03-13) [作 者] 董昕宇 [公 司] 北京德彼克

公司与项目经理应在之前达成进度上的一致,奖励标准"进度+成本+质量"

·经理人与技术员的区别(2006-03-07) [作 者] linfeng [公 司] 机械制造

项目经理不能参与到项目细节方面的设计。
只能起到监督及推动项目的执行进程。如果项目经理自己来做项目,那就不能称之为经理人,而是技
术人员或高级工程师,公司的高层应该有这样一个清晰的概念。
当然经理人可以对项目技术方面给予支持,但不是自己做,经理人的时间要用在协调各个方面的配合,
包括客户、上层及技术人员之间的沟通与协调,在技术人员有困难的时候寻求最佳的解决方案。
经理人的待遇当然不能等同于技术员。

·监督(2006-03-02) [作 者] 张毅君 [公 司] Global Technology Center

1. 缺乏对项目经理的监督。
2. 也许是公司下达项目需求不明确,项目经理并未清晰工期对公司的影响。

·项目的控制---进度和回款(2006-02-27) [作 者] 陈克鑫 [公 司] 索尼

项目的执行离不开控制。

质量、成本和进度是控制的关键,这将会影响公司的信用、利润和回款。

虽然给予项目经理足够的项目运作的权利,但通过在工程进度和回款方面给予项目经理合理的奖惩,
将会使项目进展的更有效率。

·合同化管理项目经理(2006-02-27) [作 者] 郭玉刚 [公 司] 山东博大

第 484 页 共 756 页
第 5 章 进度管理

本工程相当于对工程分包,就工程造价来说已经是定额,就项目经理来说剩下的可变利润空间就是成
本,包括工程进度和工程造价,这就需要对项目经理进行监督。
最佳办法就是 1、合同约束,2、专门的工程质量验收部门,3、诚信

·项目经理绝对权力的控制(2006-02-26) [作 者] 欧元锋 [公 司] TCL王牌电器(惠州)有限公


读“项目经理有绝对的权利,可以对该项目组成员每月进行考核,体现在工资上面,另外可以根据项
目进展情况,增加或者减少项目组成员,还有分配项目组成员奖金的权利”,和“但是这也引起了一
个问题出来,比如项目核定工作量是 10 人月,项目经理为了节约承包或者说自己赚钱,就一个人做,
做 7、8 个月才验收,或者开始 2 个人后来一个人做 5 个月才验收,本来公司跟客户签合同要求 4 个
月验收,拖延工期对客户关系和公司工程回款产生很大的影响”,在这样的一种情况下,就必需对项
目经理的权力做相应的约束,比如约定项目成员退出该项目,则需要征得老板的最终同意(因为人员
的减少有可能影响交货期)。

·报酬±奖金(2006-02-26) [作 者] 林型瑶 [公 司] 西南交通大学

这种问题的发生,往往是在对项目经理的制度约束上存在问题.对逾期和提前的项目工作组(不管一人
还是多人),应该有相应的惩罚和奖励制度.即"报酬±奖金"

·目标与激励的问题(2006-02-25) [作 者] 曹垣亮 [公 司] 北京普天银河通科技公司

这是一个平衡的问题.也是一个管理的难题.
这种现象的出现,一是公司高层需要就事论事,对事不对人的进行沟通处理,但是就案例中说明的情
况,经理可能就有一些需要完善的地方.二是工程师如果不做事也有基本的收入,可能就是公司的问题
了.

·指标单一是最大的问题(2006-02-22) [作 者] 天羽 [公 司] 林源教育咨询

成本控制是正确的,但是权下放的项目要有利润指标,这样就会在进度上有所作为了。单纯的成本控
制,对可以用人月横竖对倒的项目而言,肯定会诱使项目经理前松后紧的安排人力资源,最终是引发
潜在成本的激增,换句话说如果这样的 MIS 产品是用于内部的,可能就要拖延一段时间,这段时间的
战略实施成本其实是有公司的管理成本在里面的,但对项目组而言是不计算在内的。引入利润指标的
目的就是告知项目经理,压低成本并不能使他的利润最大化,相对短的时间内赢得公司承诺的有限的
利润才是他们的目标。这样就会在一定程度上解决拖期的问题。
另外工期指标也可以适度的采用,就是每提前一个时间单位,利润幅度增加一个点.......

第 485 页 共 756 页
第 5 章 进度管理

·jijihhihi(2006-02-21) [作 者] 黎箫 [公 司] 南京工业大学

·奖惩并进(2006-02-20) [作 者] 王淼 [公 司] 保密

可以将奖金与项目回款挂钩。同时在规定奖励的同时应该考虑同样力度的惩罚措施。

5.6 在甲方处开发,如何控制进度

在甲方处开发,如何控制进度

[姓 名] 阿呆 [单 位] 暂不公布 [邮 件] juandoo@126.com
[所属行业] IT 软件 [所属主题] 项目进度管理 [发布时间] 2004-7-27

【案例正文】
项目的开发选择在甲方处完成,这是合同约定好的

有几个问题:

1)甲方的一些别的系统的维护会让我们代劳;
2)甲方会议过多,一个小问题要经过几次协商才能定性;大的问题就更加不要说了;
3)长期出差在外,项目开发人员的效率会下降;

这样一来的话,项目的进度就很难把握;项目的成本会相应的提高;

如果碰到这样的问题,项目管理者应该着重注意什么?请大家不吝给出高见。

:)

【相关分析】

·掘见!(2004-08-06) [作 者] 马渊鸿 [公 司] 安徽电力恒卓

第 486 页 共 756 页
第 5 章 进度管理

1. 在项目实施初期明确约定系统维护的范围以及内容,超出此约定范围的系统维护要收取相应的费
用。这点对于进住甲方的项目实施方来说,尽可能避免不必要的时间浪费。
2。针对第二个问题,张成鹏先生所说的甲方成立项目管理委员会,由甲方一把手负责,这样就避免
了在项目问题协商过程中,甲方人员的相互扯皮的问题。

·掘见!(2004-08-06) [作 者] 马渊鸿 [公 司] 安徽电力恒卓

1. 在项目实施初期明确约定系统维护的范围以及内容,超出此约定范围的系统维护要收取相应的费
用。这点对于进住甲方的项目实施方来说,尽可能避免不必要的时间浪费。
2。针对第二个问题,张成鹏先生所说的甲方成立项目管理委员会,由甲方一把手负责,这样就避免
了在项目问题协商过程中,甲方人员的相互扯皮的问题。

·现场开发项目管理(2004-07-30) [作 者] 张成鹏 [公 司] 甘肃森智信息产业有限责任公司

就软件开发项目而言,在现场开发主要存在以下几点风险:
1.需求变更频繁
2.甲方过多干预项目实施
3.项目组人力资源管理
相对应的,正如第一为发言的朋友提到的“以夷制夷,一鼓作气”八个字,作为项目经理应该化阻力为
动力,正因为需求变更频繁,才说明甲方对于本项目的重视程度较高,我们可以从变更中很好的找到
甲方最终的需求,但要注意的是首先按照合同界定的范围,引导用户提出确实可行的需求,并建立良
好的需求变更渠道。就甲方过多干预项目实施这一条,项目经理可以在项目初期和甲方负责人进行协
商,成立项目管理委员会,由甲方主管领导担任组长,各相关部门负责人作为成员,前期多召开项目
协调会,使甲方单位的人员明白该项目的实施内容和我方的工作范围,并形成纸制的内容下发到甲方
各个部门,使甲方人员养成用纸制文件交流的习惯,便于将来进行审计。最后,项目经理必须在项目
实施过程中多多运用人力资源管理来确保项目小组成员的积极性。

·现场开发八个字(2004-07-29) [作 者] pear_bai [公 司] 某公司

以夷制夷,一鼓作气!

·现场开发项目管理(2004-07-28) [作 者] 王雪男 [公 司] 暂时不公开

甲方处开发项目,还会发生下面几个问题:
1. 用户需求可能会持续增加。用户从对产品陌生到熟悉,很可能会不断产生新的想法,导致需求扩
大。
2. 如果涉及多个部门,可能导致扯皮现象。
3. 用户过于依赖项目组,拖延项目组在现场时间,不愿验收。

现场开发项目首先要做好准备工作。项目经理要首先建立好项目进行的组织架构,包括己方和对
方。特别是要缕清对方的组织结构,工作方式,以及主要负责人;其次要初步收集需求,这个阶段开

第 487 页 共 756 页
第 5 章 进度管理

发人员最好不要进入现场。对于需求初步搜集主要是要明确系统的范围,这一点是要严格界定,防止
需求扩大;接下来要设计好灵活的系统架构,并且可以针对已经明确的需求在家里做好原型,然后再
安排开发人员进入现场。这一个阶段尽量安排好开发人员熟悉系统开发当中使用的技术,编制好开发
规范。
当系统原型开发完毕,进入现场开发阶段。项目经理要进一步明确项目人员组成,特别包括对方成员。
项目经理可以通过例会,阶段验收等手段控制项目节奏,安排好项目组各个成员的时间。一个明确清
晰的时间表,可以帮助回绝一部分额外的维护工作。最好将对方人员的工作节奏也控制起来,如果不
能可以考虑单个开发人员多个任务并行的方式。在这个阶段最好让客户养成签字确认的习惯。
反复提醒用户项目初期界定的系统范围,项目开发接近尾声的时候可以根据情况逐渐减少开发人员数
量来降低成本。在系统功能完成时应果断撤离。

以上是我做现场项目时的一点经验,仅供参考。

·现场开发(2004-07-28) [作 者] 许永安 [公 司] 杭州某信息技术有限公司

现场开发现场,用户各部门人员往往随时会把新的需求告诉项目组,并要求项目组马上改。
最关键在项目初期就限定项目的范围,客户方选定客户方的项目经理,客户各部门有先需求先通过客
户方的项目经理,由客户方项目经理统一与我方项目经理沟通,避免客户给部门人员不断骚扰我方的
开发人员。

5.7 软件项目延期,怎么办?

软件项目延期,怎么办?

[姓 名] 易风 [单 位] 项目管理者联盟(PMU) [邮 件] yifeng@mypm.net
[所属行业] IT 软件 [所属主题] 项目进度管理 [发布时间] 2003-1-10

【案例正文】
中源公司是一家专门从事系统集成和应用软件开发的公司,公司目前有员工 50 多人,公司有
销售部、软件开发部、系统网络部等业务部门,其中销售部主要负责进行公司服务和产品的销
售工作,他们会将公司现有的产品推销给客户,同时也会根据客户的具体需要,承接应用软件
的研发项目,然后将此项目移交给软件开发部,进行软件的研发工作。软件开发部共有开发人
员有 18 人,主要是进行软件产品的研发,及客户应用软件的开发。

第 488 页 共 756 页
第 5 章 进度管理

经过近半年的跟踪后,今年元旦,销售部门与某银行签订了一个银行前置机的软件系统的项目,
合同规定,5 月 1 日之前系统必需完成,并且进行试运行。在合同鉴定后,销售部门将此合同
移交给了软件开发部,进行项目的实施。

王伟被指定为这个项目的项目经理,王伟做过 5 年的金融系统的应用软件研发工作,有较丰富
的经验,可以作系统分析员,系统设计,但作为项目经理还是第一次。另外项目组还有另外 4
名成员, 1 个系统分析员(含项目经理),2 个有 1 年工作经验的程序员,1 个技术专家(不
太熟悉业务)
。项目组的成员均全程参加项目。

在被指定负责这个项目后,王伟制定了项目的进度计划,简单描述如下为:
1) 1 月 10 日~2 月 1 日需求分析
2) 2 月 1 日~2 月 25 日系统设计,包括概要设计和详细设计
3) 2 月 26 日~4 月 1 日编码
4) 4 月 2 日~4 月 30 日系统测试
5) 5 月 1 日试运行

但在 2 月 17 日王伟检查工作时发现详细设计刚刚开始,2 月 25 日肯定完不成系统设计,
您建议王伟应该如何做?他在项目的管理中有问题吗?

【相关分析】

·PDCA?(2008-01-30) [作 者] 周预 [公 司] 湘潭

首先可以肯定王位在项目中存在问题:
1、项目疏于控制,为什么直到 2 月 17 日才发现项目不能按进度进行?项目问题发现越早越利于改进,
越晚发现风险越大。
2、项目进度计划过粗,只是按软件开发阶段制定了计划,这样的计划不便于估算、控制,应该按照
工作包制定更为详细的计划,而且每个工作包应该不小于一个工作日,不大于 80 个工作小时为宜。
3、项目组成员是否有必要全程参与项目。程序员能不能承担系统分析工作,如不能,则 1 月 10 日之
前,他们将不必要全程参与,明显人力资源计划是否合理。
4、各阶段项目工作量估算是否合理,是不是本身就是一个无法完成的进度计划,也就是说项目进度
计划不合理,是不可能完成的。
5、是否参与了项目的前期方案建议书工作,如果没有参与,那么项目需求分析从头开始。当然这是
公司运作问题。

建议:
1、加强项目监控意识和力度,尽早发现项目风险。
2、进行项目计划变更,有必要的话对后阶段的工作重新计划,可以考虑下列几个风险应对方案:a)

第 489 页 共 756 页
第 5 章 进度管理

争取公司支持,增派有同类项目经验的开发工程师追赶进度;b)说服项目组成员加班追赶进度,由
于里程碑计划过粗,这种方案不一定可行;c)增加测试工程师,边开发边单元测试和部分集成测试,
明显的本案例中,程序员还要自己承担测试工作,这样有程序员可以专注于编码工作,压缩后期编码
时间、系统测试时间。
3、加强沟通,尤其是客户方的沟通,争取客户方的理解。

·项目计划与过程控制(2008-01-16) [作 者] 李永新 [公 司] SAP company

从这个案例中可以看出,王伟的项目计划太过于粗略,没有按照 WBS 计划工具来指定明细方案;再


者就是他的项目的过程控制不够力度,没有及时发现问题.以下是我的一些建议:
1、项目计划的制订一方面是为了有效的控制开发进度,另一方面也是对于项目跟踪设置里程碑;因
此对于每个项目的计划如果可以的话,可以考虑再细化一下,初步看了一下该案例的计划,感觉过于
简单了,每个阶段的时间点之间间隔过长了,这不便于过程控制,在一个大的计划的同时可以考虑再
对计划进行分解,能够明确到每一周甚至每一天当然是最好不过的了。这样可以及时发现问题,并解
决问题;
2、每个项目经理可以在项目的里程碑阶段里设几个时间点,便于跟踪该里程碑的进展及完成情况,
可以有效的、及时的发现问题并解决,防止到了其计划完成时间时才发现任务无法完成而延误了计划;
3、另一方面,看了这个案例,感觉该公司的销售接单方面有点不是很规范,在销售和客户确定单子
的同时应在这个时候与项目经理确认其客户要求的时间是否合理,或则说是否能够完成这个任务。如
果说客户定的时间本来就不合理而销售人员又答应了客户的要求,就会给开发人员造成时间紧迫的问
题,而往往这样就很有可能到项目快结束的时候发现该项目根本无法按照客户要求时间完成,这样不
但对开发人员造成压力,同时也给客户一种公司没有按照合同完成任务的感觉。

·过程控制的重要性(2007-12-18) [作 者] 蒋灵洁 [公 司] sunyard

该项目是 1 月 10 日开始的,那么怎么会在 2 月 17 日才发现详细设计刚刚开始呢?难道前期每个阶段


都没有进行控制?其概要设计没有按时完成并进行评审吗?这是一个很典型的疏于控制的现象。
那么我们现在一个一个来分析一下:
1、先要分析其项目开始时开发计划制定的是否合理?如果说本来就不合理而导致后期出现这样的问
题,那么就应该再对计划进行评审,合理有效的计划是项目进行的前提条件;
2、如果说前提计划是通过评审确定,合理有效的,那么 2 月 17 日详细设计刚开始,是什么原因造成
的?前期进度是否按照计划完成的呢?这个是首先要进行分析的,找出出现这个问题的原因所在;
3、找出问题后就要重视问题,后期应该避免这样的情况再次出现;其问题就在于项目开始 1 个月了,
过程控制并没有做好,导致 1 个月以后才发现项目没有按照计划完成;计划制定都有阶段性,最起码
的要求就是项目经理应该对其阶段过程进行跟踪控制;
4、分析问题后必要需要解决问题,那么如何解决目前出现的问题呢?我们先来看一看 2 月 17 日以后
剩下的时间:对于详细设计的时间需要进行评估,评估出详细设计可以在什么时候完成并评审完成,
然后再对后期计划进行有效、合理的修改。如超出了客户要求的时间的话,那么项目经理就应该考虑
是再对计划进行压缩,还是需要销售人员与客户沟通,看是否可以在时间上再次商谈。当然与客户商

第 490 页 共 756 页
第 5 章 进度管理

量商谈时间是实在没有办法的情况下采取的方法。
除了针对上面问题提出的几点意见外,对于这个项目经理也提一些个人的意见:
1、项目计划的制订一方面是为了有效的控制开发进度,另一方面也是对于项目跟踪设置里程碑;因
此对于每个项目的计划如果可以的话,可以考虑再细化一下,初步看了一下该案例的计划,感觉过于
简单了,每个阶段的时间点之间间隔过长了,这不便于过程控制,在一个大的计划的同时可以考虑再
对计划进行分解,能够明确到每一周甚至每一天当然是最好不过的了。这样可以及时发现问题,并解
决问题;
2、每个项目经理可以在项目的里程碑阶段里设几个时间点,便于跟踪该里程碑的进展及完成情况,
可以有效的、及时的发现问题并解决,防止到了其计划完成时间时才发现任务无法完成而延误了计划;
3、另一方面,看了这个案例,感觉该公司的销售接单方面有点不是很规范,在销售和客户确定单子
的同时应在这个时候与项目经理确认其客户要求的时间是否合理,或则说是否能够完成这个任务。如
果说客户定的时间本来就不合理而销售人员又答应了客户的要求,就会给开发人员造成时间紧迫的问
题,而往往这样就很有可能到项目快结束的时候发现该项目根本无法按照客户要求时间完成,这样不
但对开发人员造成压力,同时也给客户一种公司没有按照合同完成任务的感觉。

·疏于"控制"(2007-11-29) [作 者] snock [公 司] 广州某软件公司

1.怎么会在 2 月 17 日检查工作时才发现详细设计开始呢.难道概要设计结束时没有进行评审吗?

2.项目管理中的"控制"是伴随着"执行"中的"里程碑"而存在的.每一个里程碑到来时,我们应该
对项目进行评审,通过评审对项目进行控制.具我自己的经验,一般项目的一个里程碑控制在 2 周内.

·计划缺乏科学依据(2007-11-22) [作 者] 亭长 [公 司] 北京易事通科技有限公司

这个项目时间的确定是根据啥来制定的?我个人认为,项目计划不仅是项目时间上的阶段划分,以及
阶段交付件,要结合项目本身的难以度,项目可调动的资源,以及项目可能存在的风险来制定。我通
常的做法是在项目的需求调研,规格设计阶段花费的时间比实际开发的时间要多的多。

·搞清原因 对症下药(2007-08-26) [作 者] lwghui [公 司] sddsasdadsadsa

需要反思拖延原因,如果属于己方问题则需要马上调整;如果是客户方面原因,则要整与对方进行有
理有据协调同时协商处理的解决办法。总之目的只有一个就是保证项目按时完成。

·需要反思拖延原因(2007-08-26) [作 者] lwghui [公 司] sddsasdadsadsa

需要反思拖延原因,如果属于己方问题则需要马上调整;如果是客户方面原因,则要整与对方进行有
理有据协调同时协商处理的解决办法。总之目的只有一个就是保证项目按时完成。

·找出原因,妥善解决(2007-05-30) [作 者] 冯云显 [公 司] 四川长虹技术中心

第 491 页 共 756 页
第 5 章 进度管理

我认为主要从以下几个方面考虑问题:
1、项目计划的制定
2、监督与控制
3、风险管理
题目给出的信息太少,无法找到具体症结。
解决办法也要多管齐下:
1、与客户沟通,争取延期
2、与领导沟通,争取资源
3、项目内部加强激励、考核
4、加班是必要的

·项目在 2.1 完成需求分析(2005-09-14) [作 者] forgiveme [公 司] moto ltd.

项目在 2.1 完成需求分析,在设置检查点的时候,在此是否应该考虑有个点;在项目计划中应该对项


目的关键路径进行设置,并依据此路径设置必要检查点。
问题既然已经发生,5.1 已成为必定的时间,那么,首先必须对原因进行分析,在之基础之上再进行
重新构建,我会考虑对项目范围作些调整,也会作些相应的加班

·否有例会(2005-09-14) [作 者] forgiveme [公 司] moto ltd.

延期前:
1、5 月 1 日这个日期是如何定下的?定期 Deadline 之前是否考虑了公司的研发资源/力量?
2、项目开始前是否做过风险分析?进度是否是该项目的风险?
3、项目是否有例会?例会的频度是否与项目的周期相匹配?例会的议程是否包含对目前项目面临的
问题/风险的跟踪?
4、项目组的组成:项目经理同时又是系统分析员。项目经理应该懂业务,最好不要当系统分析员,
不然会陷入技术细节纠缠不清。
5、项目计划是怎么做出来的?是否经过工作量的详细估计?是谁估计的?应该由具体执行人员估计,
再加上技术专家的意见。
6、是否识别出了关键路径?是否对关键任务进行了重点监控?
7、项目的人力资源是如何获取的?是否与该项目的难度、进度相匹配?资源的数量是如何确定的?
是根据工作量确定的吗?

·这个“需求建议书”不清晰(2005-06-01) [作 者] 张彤 [公 司] 北京北大金秋新技术有限公

这个“需求建议书”不清晰,问题太大,给大家的信息太少,太空洞。

第 492 页 共 756 页
第 5 章 进度管理

·计划调整是必须的(2003-12-10) [作 者] 寇震 [公 司] 中铁十八局集团

软件开发计划包含了需求分析,这是造成开发计划不准确的最大风险来源,我们的开发计划必须是根
据需求分析后,进行工作分解得到的,而我们通常都不能这么做。我认为需求分析后,再次进行计划
调整变更,确定项目的最终时间表,并和领导、客户沟通是最可靠的。

·常见现象(2003-11-19) [作 者] 李子军 [公 司] 北京诺德信科技开发有限公司

虽然王伟第一次做项目经理,但仅从本文描述来看,并不能完全断定王伟的管理有问题:
1、阶段性的时间延迟是常有的事,资深的项目经理也不能完全控制每个阶段一定遵循预定时间
2、对于需求不明确、业务背景复杂的项目,适当延长需求分析的时间,有利于保证后期设计的准确
性和减少需求变更的幅度和次数
3、需求分析是与客户共同开展的,你所做的工作、所花费的时间,客户是有目共睹的,是能够容忍

4、延误的时间只有从后面几个阶段中挤出来,例如编码和测试同步进行等
5、万不得已,由于客户原因导致项目延期,适当延长工期,是必不可少的,总比开发成果与客户预
期相悖要好

·我的小小看法(2003-08-07) [作 者] 吴君杰 [公 司] 管理部门

要是我是负责这个项目的开发。不该太急应该不会延期。在开发中一边开发一边测试。在上面的开发
计划中可以看到测试时间可以挤一点过来当然也要加点班。

·案例很典型(2003-04-23) [作 者] 邓志国 [公 司] 温州科赛

问题:
1。计划没有依据。完全根据客户的要求来划分计划。比如用户要求在 5 个月内完成。那么需求 30%
就是 1。5 个月。没有根据实际情况来定计划。计划应该是在所有任务进行细化的情况下做出来的。
2。检查工作周期太长,发现问题已无法挽救,造成比较大的损失。
解决办法:
1。首先通知客户、领导项目的情况。做好延期准备。
2。慎重考虑是否增加人手,一般情况下不要。
3。适当加班(过多则导致工作效率下降)

·我这么处理(2003-04-22) [作 者] javadog [公 司] beijing

如果我是王伟,遇到这种情况,那么我需要做的事情有如下:

第 493 页 共 756 页
第 5 章 进度管理

1。迅速反思一下拖延的原因,如果属于我们方面的问题,则需要根据具体情况马上调整;如果属于
客户方面拖延,则要整理双方通话记录,以备在后面的双方调节中做到有理有据。
2。马上同本方主管联系,让主管预先知道这种情况,同时协商处理的解决办法(当然,主要靠自己
的处理能力)
3。同客户协商,如果是己方的责任,需要把问题出处告诉对方,取得对方的谅解,表示自己会近全
力把项目在 deadline 前完成;如果是对方的责任,则委婉的表达对方的拖延会对项目造成影响,指
出如果对方晚达成协议的话,压缩开发和测试时间,受害更多的是客户自己。
4。向项目组内员工说明情况,召开会议,把不同的意见和想法充分统一起来,同时加大管理机制,
必要时,采取加班制度,保证项目的顺利开发。

·技术心理问题(2003-04-11) [作 者] aoing [公 司] tele

这是技术人员向管理人员管转变时经常会发生的问题,问题的根源可能是过多的关注技术,没有明确
项目经理应该做的主要工作。这是技术人员的病根。

·项目组织和开发流程的问题(2003-03-12) [作 者] 刘志军 [公 司] 风林火山

项目在 1 个系统分析员(含项目经理),2 个有 1 年工作经验的程序员,1 个技术专家(不太熟悉业


务)的情况下,工期只有半年,如果使用瀑布式开发流程肯定会碰到这种进度问题。
此时应当采用敏捷方式的开发过程,前期系统分析员和技术专家尽早确定大体需求方案和整体设计方
案,接下来采用迭代式开发,一周一次迭代,每次完成部分功能,方便进度跟踪和控制。可以参考
XP 的规则。
另外看需求是否经常修改,如果是这样的话,采用 XP 的流程会更快一点。.

·这样如何(2003-02-14) [作 者] 姜延峰 [公 司] 信息管理中心

1。争取延长时间
2。争取 3。1 完成详细设计。
3。压缩编码时间。并加强单元模块测试。

·faint,系统有问题,写了两遍还没贴上去(2003-02-14) [作 者] 王春龙 [公 司] QA

不写了,随便说两句。
1,根据该公司的做事方法与人力,不太可能有严重的判断错误。
2,该项目规模实在不大,问题出在过度设计上。
3,如此小的项目应尽快进入编码。
4,两个新人和一个技术专家在编码和测试以外的环节纯粹是浪费成本。

第 494 页 共 756 页
第 5 章 进度管理

·同情王春龙——遭遇一样(2003-02-14) [作 者] Zhang Xiaohang [公 司] 凌云逻辑

简述:
1 计划欠周详,需求分析与系统设计合并;测试不需要这么长。
2 人员分配,系统分析员负责整体,专家负责可行性,程序员辅助。自己协调检查沟通,为成员服务。
3 制定补救计划,合理分配时间。(时间应该够)
4 与市场部沟通,实情相告,但不必通知客户,因为时间还早。

·同情王春龙——遭遇一样(2003-02-14) [作 者] Zhang Xiaohang [公 司] 凌云逻辑

简述:
1 计划欠周详,需求分析与系统设计合并;测试不需要这么长。
2 人员分配,系统分析员负责整体,专家负责可行性,程序员辅助。自己协调检查沟通,为成员服务。
3 制定补救计划,合理分配时间。(时间应该够)
4 与市场部沟通,实情相告,但不必通知客户,因为时间还早。

·应该建立完整的项目跟踪系统(2003-01-23) [作 者] thizhi [公 司] .

有计划却没有控制计划的具体方式,可不是笑话。这公司居然混了 50 多人还那么多部门,开玩笑吧。
“王伟做过 5 年的金融系统的应用软件研发工作”?
我认为这个项目不够真实,应该弄一些比较真实的案例来进行分析。

·快速软件开发的几点意见(1)(2003-01-15) [作 者] 刘存洋 [公 司] 大连华信

1 作为一位有 5 年金融方面的开发者,我认为王伟对改项目工作量的估算,偏差不会很大,20 人月
左右。但也不排除是迫于上级领导或其他部门的压力,才制定了这份过于乐观的进度计划。这其中可
能会存在很多种情况,只是我们现在对该项目组所发生的具体问题不是很清楚。只能用各种存在的假
设加以分析。
2 该项目的进度计划之所以不能按期完成,是项目管理者缺少,对项目进行中所存在的风险的评估。
导致项目计划的可行性和质量有所下降,在这时需要对计划进行及时的调整。
待续

·软件项目延期,怎么办 (2003-01-12) [作 者] 张学海 [公 司] 神州数码

我先做一个事后诸葛亮,看看延期前发生了什么?
延期前:
1、5 月 1 日这个日期是如何定下的?定期 Deadline 之前是否考虑了公司的研发资源/力量?

第 495 页 共 756 页
第 5 章 进度管理

2、项目开始前是否做过风险分析?进度是否是该项目的风险?
3、项目是否有例会?例会的频度是否与项目的周期相匹配?例会的议程是否包含对目前项目面临的
问题/风险的跟踪?
4、项目组的组成:项目经理同时又是系统分析员。项目经理应该懂业务,最好不要当系统分析员,
不然会陷入技术细节纠缠不清。
5、项目计划是怎么做出来的?是否经过工作量的详细估计?是谁估计的?应该由具体执行人员估计,
再加上技术专家的意见。
6、是否识别出了关键路径?是否对关键任务进行了重点监控?
7、项目的人力资源是如何获取的?是否与该项目的难度、进度相匹配?资源的数量是如何确定的?
是根据工作量确定的吗?

通过上面的问题,我觉得我们可以看出为什么会造成目前延期的情况。

延期后:
1、重新进行工作量估计,在保证 5 月 1 日的前提下,调整内部阶段点。既然详细设计已经延期,就
干脆再把该阶段放宽一点,写得详细一点,减少编码阶段的困难与周期。
2、要有周例会,进行风险管理。对有延期风险的模块至少应半周一汇报,甚至做非正式的日报。关
键要汇报问题和风险。
3、要注意“问题升级”,PM 协调不了的问题不要拖,及时向上司汇报。
4、谨慎地增加资源:并不是加人就管用,不然就不会有《人月神话》这本书了。在目前阶段(详细
设计),还是可以考虑加人的。关键是加什么样的人,一定要是“熟练工”。
5、传统方法:对关键任务进行分解,是否可以并行执行?
6、加强时间管理,有效利用时间。
7、用企业文化/政策协助项目管理:是否可以要求加班或搞封闭式开发?
8、如实在保证不了进度,就要和客户协商了。注意:千万不要用牺牲质量来满足进度,要有一个平
衡点。要看到公司的长期利益。

·项目经理失职(2003-01-11) [作 者] piggy [公 司] 上海

5 个人的一个小团队,到了 2 月 17 号才发现详细设计刚刚开始,王伟平时在干什么?作为项目经理
我认为他严重失职。
从案例上看这份进度计划太粗,5 个人的团队,5 个月的工期,计划应该可以做得很详细,一旦详细
需求分析结束,关于需求的、技术的很多风险应该就能标识出来,同时根据团队人员的技术情况,应
该可以基本判断出项目实施的可能性,会存在哪些问题,而不用等到事到临头才发现。

·项目管理者论坛网友集体分析(2003-01-10) [作 者] 集体(兰燕子等) [公 司] 项目管理者联


盟(PMU)

兰燕子:

第 496 页 共 756 页
第 5 章 进度管理

为什么 2 月 17 日才发现需求分析延误了?既然事情已经发生了,那么首先应该找出原因,再做风险
分析。
如果你的计划只是根据以往的经验而定,那么以后的阶段还会发生类似的问题,如果不及时调整计划,
以后的风险就比较大。
如果你的计划是经过详细的工作分解结构,进行时间和费用估算而得到的,那么原因可能是范围变更
(需求变化)或资源不够。如果这样,则根据现状调整计划,目前有一个“Deadline”,那你得想办
法缩短工期。

failwolf :
首先你的项目开发计划中就应该安排断点检查的,不是等到你高兴的时候在来检查项目进度计划。每
个计划都可以分成很多的断点检查,以及检查指标,包括 KPI 考核。
现在这个样子呢,除了加快工作进度(加班或者加人,也可以处罚调整人),还有和客户协商,争取
最小的延长期,然后开始严格控制项目,并且评估项目成员的工作,控制他们拖拉。

CXH :
我想作为项目经理,首先应回想一下在项目开始实施时是如何做的计划,估计没有进行详细的工作分
析和风险分析,这样的计划必定是会出问题的。建议在这个时间结点,重新进行计划工作和风险分析,
由于 5 月 1 日的时间不可改变,就应考虑新资源和新技术的应用。

Billzhu:
项目在 2.1 完成需求分析,在设置检查点的时候,在此是否应该考虑有个点;在项目计划中应该对项
目的关键路径进行设置,并依据此路径设置必要检查点。
问题既然已经发生,5.1 已成为必定的时间,那么,首先必须对原因进行分析,在之基础之上再进行
重新构建,我会考虑对项目范围作些调整,也会作些相应的加班。

沧海浪子:
我们这里流行一句话:“后墙不倒”,即无论项目怎么变化,“5 月 1 日试运行”作为“Deadline”
是不能变的!我认为这是客户的最终需求,其他的里程碑应该可以调节的。好在详细设计刚开始, 项
目经理应重新调整一下计划进度。当然对内加班,对外和客户更好地交流,取得客户的理解是免不了
的。
重新调整的计划进度当然是建立在充分详细的工作分析和风险分析的基础上,避免以后再有类似问题
出现,同时也应避免无谓的串联作业,尽量缩短时间以达到最终目标--5 月 1 日定版。

Stone:
出现这个问题有两种可能,一个是计划的问题;另一种是计划的实施的问题。
计划要做到前紧后松,我的经验是在 100 的时间里完成 80%的任务。记住一点,任何在完成 100%之前,
这个项目就没有完工。
项目太大,离 Dead Line 的时间太长,一定要恰当的把项目分成几个里程碑,两个里程碑之间留大约
30%的缓冲时间。每一个里程碑要对应一个工件,这个工件就是可检查的产品。如期完成每一里程碑
的时候,可以给工作人员一些激励。任何人都喜欢有成就感!!
如果延期了,一定要找出原因和补救的方法,同时要给出相应的警告信息!最后一点,项目延期不是

第 497 页 共 756 页
第 5 章 进度管理

开发人员的错,是项目经理的错!

5.8 不能保证按时完成?

不能保证按时完成?

[姓 名] 郭勤斯 [单 位] 网政软件公司 [邮 件] qinsi@163.com


[所属行业] IT 软件 [所属主题] 项目进度管理 [发布时间] 2003-6-30

【案例正文】
A 是某项目的项目经理, B 是关键技术负责人;现在有个项目,系统大致的需求已经完成,
需要和客户签订合同, A 想先估算项目开发的时间,而客户更加要求本年度就要完成。而且,
这个工期在签合同的时候也是需要说明的。

A 就和 B 商量确定最后限期,但是 B 说,他不知道具体的时间,即使定了时间也不能按时
完成,他的理由是:第一,需求不够明确;第二,需求的变更不能预见;第三,技术的风险不
能估算;他说第一要所有 user case 做完了,客户认可了;第二,做完技术试验,之后才可
以确定工期。

但是,合同要先签订啊,那么,A 该怎么办?请各位指点一下。

【相关分析】

·软件双点估算、风险评估、沟通。。。。(2003-09-29) [作 者] 周勇 [公 司] 武汉亨威科技

1、根据目前总体需求进行“双点估算”,估算是一个渐进明细的过程,在签订合同时跟客户双方沟通
清楚。
2、对于技术人员提出的前面两条,我不敢苟同,不可能每个项目都能够很明确、没有需求变更,那
还要 RUP、XP 干吗?只要是进行了很好的项目管理,这些问题都是能够很好的克服的。这一点也必
须和 B 沟通好。
3、同样,既然想赚钱,风险固然存在,我估计这个技术负责人本身对技术就拿不准,风险肯定是可
以估算的。如果说风险过大,完全就没有必要签这个合同。

4、合同可以签,但是项目计划与估算、风险估算、总体需求的确定这些前期的工作一定要做好。

·B的看法没错(2003-09-24) [作 者] salemy [公 司] STA

第 498 页 共 756 页
第 5 章 进度管理

B 的看法没错
A 应该做的是:
在预计能签下该合同的前提下,投入时间和精力做:
1、明确具体需求
2、和客户说明,具体需求不可变更,并在签合同的时候需要说明
3、同时等待 B 的技术实验结果。

·a的问题大一些(2003-08-19) [作 者] 徐远飞 [公 司] 软件

1、可行性分析中居然没有技术可行性分析,如果技术达不到怎么办?
2、b 是技术负责人,就得相信 b 的话!换 b 是一种不负责的想法,技术不行不是理由,航天飞机都
有人能做出来,但中国有几个 B 能达到那种高度?
3、因该给时间让 B 确认一下核心技术能否达到,搞定核心技术,定出时间不是问题
4、有效的激励机制,你说能达到也这些报酬,说不能达到也这么多报酬,说能达到到时不能达到反
倒要负责,能看到风险却没有相对的收益来平衡,显然不行。

·沟通(2003-08-02) [作 者] 马力 [公 司] 项目组

1 项目经理首先和技术人员进行沟通,了解相关技术问题,不必要过细。
2 同 b 进行沟通,无法取得共识就只有调整 team 了。

·加强内部沟通,降低合同风险(2003-07-26) [作 者] 郭志新 [公 司] 苏州迅达电梯有限公司

A 首先应了解该项目的一些技术细节,来衡量 B 对项目的态度是积极的还是消极的。
在此基础上与项目组成员进行良好的沟通。决定如何通过制定理合理的,对用户更具约束力的合同,
降低合同执行的风险。

·建议(2003-07-15) [作 者] 田京平 [公 司] UNIHUB PMO

1、与用户沟通:在明确需求的前提下签约
2、与 B 沟通:根据现在掌握的需求已经经验估算工期,并考虑风险问题及应急计划

·碰到这样的技术负责人头大:((2003-07-15) [作 者] 孟晓林 [公 司] 网络业务部

1、A 需要和用户沟通,让用户了解完成任务的具体时间与用户提供需求的多少和明确程度有关,要
用户抓紧时间准备相关资料;
2、A 与 B 沟通,请 B 列出所需 A 或者用户提供那些资料、数据才可帮助其最快制定相关计划。如果
此时 B 有推脱等言语可考虑换掉 B;
3、A 与用户沟通,将工期等问题不在合同中说明,改为采用附件或补充文件形式,本附件和补充文

第 499 页 共 756 页
第 5 章 进度管理

件根据工程进度情况随时修改和补充;
4、A 与 B 再次沟通,希望 B 可以谅解,并支持,将起所需要的数据尽量多的提供给 A,以便实现用户
的需求。

·全面评估,各个击破(2003-07-15) [作 者] 安乃红 [公 司] an

既然有很多问题是大家担心的,但是没有合同一切又都没有保障.我认为现在最重要的是签订合同,
不过不能草率签订,要考虑周全后在签,合同中要包含现在能考虑到的可能影响工期的所有因素和解
决这些因素的方法。比如:就需求不明确的因素,我可以在合同中明确规定客户在一定的期限内明确
需求,否则工期影响的责任要客户来承担,在明确需求后如果变更需求需要有需求变更的流程来完善
需求,避免需求再次变更。

·善于沟通(2003-07-12) [作 者] 张清俭 [公 司] 大连

1、必须要明确需求
2、和客户沟通确定完工日期并作为约束条件
3、和 B 协商,不同意、不配合则换人

·沟通良好!(2003-07-11) [作 者] 彭桃平 [公 司] 古越龙山

两点:一、建议撤换技术负责人。总觉得 B 是无理取闹,作为技术人员,可以不去计划技术实施进度,
但是作为负责人,每一项计划它都应该有个进度计划;我怀疑 B 有私人恩怨了!二、沟通好客户。极
力想业主说明项目存在的众多不确定因素,并准备好一份充足完善的项目进度计划,尽量把不确定因
素突出,然后说服客户将工期进行宽限!

·兄弟,上!(2003-07-09) [作 者] 颜天飞 [公 司] SIEMENS

A 不是一个合格的项目经理!建议:
1、先把合同签了再说,毕竟指标象一把明晃晃的剑悬在头上;
2、请 B 撮一顿,述述苦,联络一下兄弟感情,请他无论如何帮兄弟个忙,工期肯定赶得出,技术人
员都这德性,肯定有很多余量,我也是技术出身;
3、抓紧时间专研点技术,不要求精,但一定要宽。否则被别人卖了还在帮人家数钱。

·存在的问题和建议(2003-07-09) [作 者] 闻志国 [公 司] 深圳XX通讯

1.项目经理怎么到快签合同才和项目实现的技术人员商量工期,不沟通能不能实现还是个问题,实现

第 500 页 共 756 页
第 5 章 进度管理

的成本和工期也是需要考虑的因素。
2.技术负责人冠冕堂皇不负责任的说法,也许从纯技术的角度听起来好像是有道理的,但决不是一个
合格企业员工。知道需求不明确还不主动要求参与和用户沟通;需求变更可和用户沟通,在商务上有
相应的措施,避免承担非自己过失造成的变更风险。风险可以评估,只是评估的准确性是由能力,方
法所决定的。不缺的技术问题,通过谈判和引导用户使用自己技术有优势的方面考虑,另外非做不可
逆应该尽快去做,而不是我反正做不了这么轻松推卸责任。

现在的主要措施:1 积极与用户沟通或交际手段来让用户改变一些决定。
2 不明确的需求,需继续有相应人员(技术,商务等)与用户讨论确认,并有相应的合同条款约束。
3 参考项目管理经验,通过管理能力降低风险。这可能大家比我熟悉多了。
4 对项目存在的风险进行评估,并制定相应的应对策略,同时也是作为是否签订合同的一个参考。

·项目TEAM构成有问题(基于存在类似项目)。(2003-07-06) [作 者] gxq [公 司] xxxx

项目经理 A 可以不懂技术,但是必须知道有哪些工作需要做,也就是说项目经理 A 要制定出 WBS,然


后由 B 确定(估计)完成个具体任务需要的时间,SCEDULE 自然就出来了。
假设 A 不能做 WBS,他特长在于与客户沟通,那么 B(如果能力达到)就要自己出 SCHEDULE,现在项
目不能正常进行,可以说 A,或 B 中有人不合格,或者说项目组成有问题。
对于 B 提出的理由 1,那么在做具体任务之前,必须要客户提供详细要求,客户不能提供的,B 要负责
出标准给客户确认,发挥主动以推动项目进展;
对于 2,客户要求可能更改,如果客户更改要求并且影响到项目交期,那么你就 BASE ON 目前状况提
供新的 SCHEDULE,只要你的 SCHEDULE 合理(即使超出时限),客户基本不会反对。

·不能保证按时完成?(2003-07-05) [作 者] 付夏荣 [公 司] 江西财经大学

我的分析如下:
首先,毫无疑问项目经理 a 和关键技术负责人 b 之间存在着沟通困难的问题。这也是一个典型的项目
经理与专业技术人员之间的问题,项目经理不太懂技术,而技术人员则不了解项目经理的问题,技术
人员只关心他的技术问题而不会顾及到项目经理是要对整个的项目负责,这也就是之所以存在项目经
理的必要性。项目经理就是要让项目所有的人协调起来。项目经理 a 必须与关键技术负责人进行更深
的沟通。不可能有不能沟通的人的,只要用心去沟通。
其次,项目经理可以借助一些以前有过的类似项目的工期当参考,再结合本项目的特点而估计一个项
目工期出来。再参考 wbs 每一个分项的工期,从而得到一个总工期。
而 b 则也存在着问题,作为一个技术人员对其所负责的系统要多少时间都不知道,这是不可原谅的,
他的理由也没有说服力啊。
项目本就存在着不可预见的变更性。风险虽然不能估算,但我只需要风险在某一个范围之内就可以了。
客户认可以后,时间就已经去掉了好多,不值得的。

·不能保证按时完成?(2003-07-04) [作 者] 冰点凤凰 [公 司] 广州某投资公司

第 501 页 共 756 页
第 5 章 进度管理

1、在需求方面进行进一步分析,A 首先要看是否在需求方面与客户沟通不够,将从客户方所得的需
求与已有的相类似的 case 作比较,得出自已的观点,再与 B 进行沟通找到可能不确定因素有哪些,
一一列出,并对这些因素估计一个可能发生的概率。
2、按各种事情发生概率可能会影响到的时间做一个估计,并以难易的可能为参数对估计的时间做一
个修正。
3、将三方比较的结果与客户沟通,争取合同签定的时间与估计的相符。
4、在合同条款上对不同需求变更可能导致工期的顺延加以规定,以使项目承担方有更多的主动权。

·补充(2003-07-04) [作 者] 冰点凤凰 [公 司] 广州

如果经沟通客户坚决不让步,在工期严格限定的情况下,而 B 就毫无办法时,只好考虑招聘或寻取外
援,将工作的一部分分包给外单位。

·分析其中人员的原因(2003-07-03) [作 者] 冯烽 [公 司] 北京泰通公司

首先,他们与客户的沟通有问题,交流的不够充分,A 应组织相关人员特别是 B 与客户进行充分的交


流,直到能确定客户需求或者基本上确定以后,考虑该项目的周期及合同中其他需要确定的内容;
二:项目经理有问题。客户需求沟通还没充分,就到了要签合同了,他的管理有问题;如果说 B 的沟
通能力及对技术没有把握,则 A 从人员的选择上出现了问题,他就不应该让 B 出任技术负责人;
三:B 有较大问题。作为技术负责人,不了解客户需求并不能确定项目周期有多方原因,我认为比较
主要的有三:不擅长沟通、不了解客户所在行业和技术不过关,按理,他可以开了。我的看法如何,
请与我探讨,E-MAIL:fengfeng@tide21.com

·不能保证按时完成?(2003-07-02) [作 者] 宣云干 [公 司] 项目管理部

我的分析意见如下:
1、A 首先要分析一下自己的工作,看是否需求分析不够明确,把自己的工作做到位。
2、在合同中将需求更改约束条件订的详细一些。
3、让技术人员参与到前期需求分析中
4、多和 B 沟通,充分调动公司的可用资源,包括人力、物力、财力

·就目前情况估计后签单(2003-07-01) [作 者] 赵国梁 [公 司] 广州菲奈特融通公司

1。首先和 B 做进一步的沟通,先就目前的情况做一个估计。
2。请多几个经验丰富的技术人员对目前的情况做评估。
3。综合评估后的意见,按照评估时间的 1.5 倍来计算。
4。在合同中将需求部分的内容限制的更严格一些。

第 502 页 共 756 页
第 5 章 进度管理

·不能保证按时完成?(2003-06-30) [作 者] 张海 [公 司] 南通埃梯梯电子工业有限公司

我的分析意见如下:
1,先收集一下类似的已完成的项目的开发工期为T,并评估本项目与先前项目的难易度的对比,大
致得出一个参数(系数)为C,则新项目工期Tnew=C*T,基数即可确认。
2,也可以用WBS表中各项任务所需时间为参考,对其进行代数求和和多方面的评估,综合得出一
个较准的时间;
3,使用三点法的手段,若能得到多方面人员的讨论数据,我觉得德尔菲法也很适用;
4,另外还有一个较野蛮的方法,那就是对那个技术人员施强压,让他自动的报出工期,但此法会影
响团队合作和长远利益。
你们认为呢?我希望能有些兄弟给我些回应,OK?

·按照现有需求进行估算(2003-06-30) [作 者] 至尊月 [公 司] 项目管理部

第一:积极进行项目时间的估算。要求技术人员安装现有的需求进行一个估算,并将估算的时间×130
%左右,这样做比较有可行度。
第二:提高项目开发速度。要求客户进行密切的配合,最好有人员长期跟踪到项目中,这样可以节省
项目接受的时间。也可以最早发现问题,争取在需求分析阶段将所以的需求确定。要求公司给项目组
提供更多的资源,以争取尽早完成任务。
第三:注意沟通技巧。在项目开发过程中,做好各方面的沟通,可能会得到更好的结果。沟通过程一
定要不辞辛苦。

·A、B的沟通有问题!(2003-06-30) [作 者] 马风民 [公 司] 信息应用部

A 这一方前期是否让技术负责人充分的参与项目前期谈判?
再次 B 的能力有问题,作为技术负责人,连项目时间估算都搞不定的话,做什么技术负责人?
这样,项目的风险会很大的。
A 要做的事情;
一要和客户充分沟通,关键是要技术负责人和客户充分沟通。尽量大的获取项目信息。
二要对项目技术负责人进行充分的评估(胜任力评估)
三是在技术负责人评估的基础上采取措施(当然前提是他能胜任)

第 503 页 共 756 页
第 6 章 控制管理

第6章 控制管理

6.1 *面对客户的需求变更,接受还是拒绝?

案例提供者:项目管理者联盟会员 ycui
项目管理者联盟,项目管理问题。

★ 案例正文:

在某公司的项目管理课堂上,小李,小王等人正在七嘴八舌地议论纷纷。原来,大家正
在讨论小王的公司最近遇到的两个颇为有趣的项目。 项目管理者联盟,项目管理问题。

据小王介绍,这两个项目分别由两个项目经理来担任。其中,项目经理A属于“谦虚”型,
对于客户提出的问题,无论大小都给与解决,客户对此非常满意,然而,项目进度却拖得比
较长,而且,客户总想把所有的问题都改完再说,项目已经一再延期。

相比之下,项目经理B显得稍有些“盛气凌人”,对于客户提出的问题,大多都不予理睬,
客户对此不是很满意,不过,该项目的进度控制得比较好,基本能够按期完成项目。 http://blog.mypm.net

http://blog.mypm.net

话刚一说完,小李就抢着说:“A比较像我,一般在和我的一些战略客户打交道的时候,
我基本是有求必应,与客户的关系处得如鱼得水,这样做肯定不会错。就像前天我连合同都
写错了,找到客户,人家二话没说就同意改了。你说如果是B的话可能吗?”

“对项目经理来说,成本、质量和时间是最为重要的三要素。与客户
小王对此不以为然,
的关系当然很重要,但也要全盘考虑项目的各要素。对于用户的要求,应该在有限的范围内
给与解决,但不可以做出太大的牺牲。一味的迁就用户将会使整个项目失败。” 项目管理者联盟文章,深入探讨。

小林接着小王的话说:“当前,国内的项目一般情况下是由销售处出面签单,再由项目经
理接手后续的工作,因此客户关系多在事前已经搞定。发生新的情况后,可以由公司的公关
部出面与客户进行协调,项目经理可以在此过程中坚持一下原则,与公司的公关部一个红脸,
一个白脸,唱出一出好戏。”
http://bbs.mypm.net

小赵反驳道:“不管怎样,客户才是第一位的。客户可以给你带来收入,也可以给你带来
更多的客户和工作,有什么道理不多配合一下他们呢?说实话我对B的做法蛮欣赏的,可惜
行不通。因为客户是上帝,如果照B的做法,后果会造成做一次项目丢掉一个客户,太不划
算了。”

问题:
1、如果你的项目遇到需求变更问题,你会采用哪种方式去应对?
2、分析这两种应对需求变更方式的优缺点。

第 504 页 共 756 页
第 6 章 控制管理

点评本案例>>

★ 项目管理者联盟专家点评: 项目管理者联盟文章,深入探讨。

http://bbs.mypm.net

专家介绍:潘东 上海交通大学计算机软件专业博士,现任神州数码通用技术公司(DGT)
COO,主管公司的运营和交付。原任神州数码融信软件公司的副总裁,主管公司的项目交
付,具有丰富的项目管理经验。在神州数码任职期间建立了本部的三层结构的项目管理体系,
并负责通过了 ISO9000:2000 版认证和 CMM2 评估。在神州数码内部研发项目 Smart Banking
整合项目中担当骨干,全面整合了神州集成金融领域的多个软件产品。在中国建设银行
ES/9000 项目中任前端项目经理,负责前置系统开发和 300 个网点的切换、上线。
专家点评:

这个问题是项目管理过程中的一个经典问题。

应该采用哪种方式去应而对?跟大家的观点一样,很难简单做出二选一回答;至于原因,
其实大家在讨论中都已经回答了。
本文转自项目管理者联盟

这里想就案例中讨论中间有几个关键点与大家分享一下自己一些体会和经验,特别是变
更管理的要点。因个人水平有限,也希望听到大家意见和指正。主要有三点:

第一:所谓客户提出的“问题”到底是什么?

第二:如何“管理”这些问题? http://blog.mypm.net

第 505 页 共 756 页
第 6 章 控制管理

第三:如何与管理时保证良好客户关系?

从案例中的提供信息来看,这里的谈到的“问题”大概指“变更”。项目中常见的变更有两
种,“范围变更”和“需求变更”。

范围变更可以通过事前<工作说明书中>中的明确定义进行界定,判断和管理都相对简
单。对于工作范围中没有定义的内容,项目经理就可以明确拒绝(但怎么说“不”非常有讲
究!),并可以转化成为商务问题由销售出面解决。

而需求变更不但数量大,且界定和管理都要复杂的多。软件项目中,例如界面风格的改
变,数据库字段的变化等,都涉及极大的工作量,而且在需求分析阶段很难保证一次正确。
我所在的公司中,这类变更也是让项目经理最头疼的。
http://bbs.mypm.net

因为范围变更相对容易,接重点谈谈如何管理“需求变更”。先要扭转一个观念:管理变
更的目的绝对不是不让客户变更,更不是扳着面孔一口回绝,而是要让变更受控,让变更有
秩序的进行。

为此,一个比较有效的方法是在项目开始前就制定变更管理流程,并与客户达成一致。

变更管理流程可以根据项目的具体情况设计,但个人认为有四个关键控制点一定不能放
松,那就是:授权,审核,评估,确认。

• 授权:只有经过授权的客户接口人才能提交变更单,只有经过授权的项目接口人才能
接受变更单。这样做一来可以保证变更都被有效记录,二来可以避免客户内部尚未达成一致
的变更被提出来。

• 审核:项目经理要对书面的变更分析,分出轻重缓急,并与客户沟通。哪些应该回绝,
哪些可以推迟,哪些可以接受。经过项目经理过滤之后,变更的数量应该可以大大减少。
• 评估:请技术人员对于变更的涉及的范围,引发的工作量和风险,以及对进度的影响进
行客观的量化评估。切忌不可夸大,否则会丧失客户的信任,造成额外的困难。

• 确认:将评估的结果与客户一起进行讨论,与客户一起决策。告诉客户“我可以改,
但对项目的影响是…”,客户也是讲道理的,大多数情况会达成一致。即使有时客户一时难
以接受,但讨论的焦点也会集中到客观的评估结果上来,而不是涉及项目经理的性格、甚至
对客户尊重不尊重的这类问题。

上述方法是变更管理的基本要点。但如果只能执行管理流程,对项目经理来说那才仅仅
是及格。优秀的项目经理,还能够在这个过程中保持甚至加深与客户的关系!

如何做到这点呢?理解客户!仔细思考就会发现,客户需求的表面之下,往往隐含着真
正的“需要”。举个生活中的例子,买衣服时对颜色、款式和面料等会有多方面的需求;而这
之下隐含的需要却可能是为了“御寒”,可能是为了“漂亮”,还可能是为了“体面”。如果能够

第 506 页 共 756 页
第 6 章 控制管理

弄清客户的需要,往往能够提供服务时能起到事半功倍的效果。
http://bbs.mypm.net

这里,我想用所在公司内部的一个最佳实践案例说明:

小 H 貌不惊人,甚至一着急还会有点口吃。刚刚被提拔负责一家银行的报表系统开发。
本来进度已经非常紧张,但客户负责人突然要求增加十几张报表,并要求一周内必须完成。
一个开发组长为此与客户发生了激烈的争执,双方都非常生气。

小 H 知道后,直接找到了该客户。

首先,他对下属的行为进行了道歉。之后,问了一个非常关键的问题:“为什么这几张
报表这么急?”。听到小 H 这样问,客户情绪已经缓和了许多。于是介绍说,这是行长会议
的决定,为满足新的监管要求必须限期完成。他本人已经向行长作出了承诺,压力也很大。

小 H 说:“你的难处就是我的难处!保证在本周内完成这些报表!”。听到小 H 这样说,
客户已经变得有点感激了。没等小 H 开口,便说:“这事最急,其他可以先放放”。

经过两个人的沟通,一起修改了项目计划:立刻开始新报表的开发,同时将 10 张报表
移到二期开发。而此后小 H 便与客户成为了好朋友,持续从客户那里拿到项目,项目规模
也越来越大。每次客户的签约时的条件之一就是小 H 必须是项目经理,直到几年后小 H 被
提升为公司的一名高级项目经理。

项目中的倾听和理解是多么最重要!而真诚的沟通,更是远比那些所谓“红脸”“白脸”的
技巧来得重要.

★ 项目管理者联盟网友评论:

分析 1:善待别人,就是善待自己(陈中民)

客户就是上帝,是上帝你就要善待。不管是战略客户;还是战术客户;不管是大客户,
还是小客户,一个项目的成功,给公司带来的不仅是现实的收益(例如:金钱和后续新的项
目)也会带来形象收益(例如:广告效应、成功案例的宣传等)

但是对于个案,要区别对待,有时在同一个项目中,两种方式也会兼而有之。对于进度
松、易于和客户交流的项目,在成本不发生大的出入、现行技术可以实现的情况下,应尽量
满足用户的需求。反之,则尽可能拒绝变更要求。任何变更都要从事实分析入手,分析可能
带来的风险,如:进度、成本、质量;纳入风险级别控制中,然后再做出决定。 本文转自项目管理者联盟

当然,项目经理的性格大致也决定了他做事的风格,但各有优缺点。

项目经理 A 所采取方式的优点是:与客户的关系非常融洽,利于项目的执行,提供某
种方便,也会给公司带来潜在的收益。缺点是:由于频繁的变更(有可能是无谓的变更)导

第 507 页 共 756 页
第 6 章 控制管理

致进度、质量、成本出现不必要的风险,进而影响开发人员的士气,导致项目失败,如果到
了这一地步,就有些不值得了。
http://blog.mypm.net

项目经理B所采取方式的优缺点恰恰相反。因此,单纯哪种方式都不是最优处理方法,
而结合使用,才可以规避各自的缺点,发扬各自的优点。

分析 2:寻求纳什均衡点(刘宇凌)

面对选择,面对抉择,往往没有最佳答案或非此即彼。但是可以无限接近最优抉择,在
数学上,这是个极限问题。也就是寻找纳什均衡点。

短短片言字句,达抛砖引玉足以。

分析 3:项目范围管理(Kevin)

在这的各位项目管理者、项目管理师想必都很清楚。项目管理当中至关重要的三要素:
成本、质量、进度。

而在实际中,很多企业设计很成功、非常有创意的特色项目却难以在有效的质量、成本、
进度控制之下按时完成。

就我个人以有限的经历和理论基础给予解答:

1、在项目整个过程中,除上述三要素外,其关键基础作用的应该是市场调查和需求分
析。 http://blog.mypm.net

2、项目管理当中的九项关键内容之一:范围管理也扮演着十分重要的角色。

3、对于每个项目经理来说,wbs 应该是经常用到的。并且 wbs 将工作进行分解,对项


目的质量、成本特别是进度起着至关重要的作用。 http://bbs.mypm.net

下面就此案例给出个人分析:

首先:很多企业和客户在项目成交方面存在很多纠纷,特别是修改起来十分消耗成本的
项目产品如软件产品;还有难以明确定义界限的如服务类。在市场调查和需求分析阶段,企
业公司应当在产品规格、性能、功能等方面和客户之间应该有明确的定义界限划分。
比如:在软件产品上,很多时候用户对产品功能的初期期望要求并不高,因为顾客
也没有一个很清楚的定义。当产品出来时,顾客随着时间的延长会对产品功能的要求慢慢提
高,对初期的功能和性能已经不满。这时候可能会要求公司对产品进行改造。而很多时候,
顾客甚至会有点“得寸进尺”,每改一步他都会进行更高的要求。

对于这个我想问题务必处在项目的第一二阶段。在需求调查时企业明确了项目的价值和

第 508 页 共 756 页
第 6 章 控制管理

风险;在总体和概念设计时应该和顾客在合同当中对产品的功能和性能应该有明确的定义。
其次:在项目九项内容中范围管理也起着十分重要的角色。范围管理直接影响着最终产品,
范围在合同中的明确定义很大程度上减少了顾客和企业在最终产品上的纠纷。因此,在项目
设计过程中,对项目的范围在合同中应该有明确的说明。项目结束后,对顾客的较小要求,
在成本控制范围内可以给予解决。当然对于超支的完全可以给予委婉的拒绝,毕竟在合同之
中已经明确声明。

第三:就是 wbs 工作分解。项目的总工作分解可以对项目的进度进行有效的控制。 本文转自项目管理

者联盟

在每个小工作阶段设立里程碑。不仅可以给项目成员以激进的作用,还可以对每个小工
作的完成质量进行有效管理。对每个项目经理来说应该具备的。

就以上所述问题,我个人认为应该以合同为基础,再在此之上给予合理科学的解决。当
然适当的委婉拒绝是理所当然。
http://blog.mypm.net

分析 4:规则的定义(陈中民)

市场调查是计划,需求分析是计划,WBS也是计划,但是计划总是没有变化快。引起
变化的因素有很多,如:新技术的出现,政策的改变,新业务的出现,需求调查不可能面面
俱到。都不可避免地引起变更。

但是,若建立了一套行之有效的管理规则,行为规范,大家都来遵守,那不是什么变更
都好解决了吗。

分析 5:面对客户的需求变更,接受还是拒绝?(老杨)

我想,首先要把工作做在前面,防止事故的最好方法是预防而不是补救,因此要在项目
前期尽量把用户的需求了解清楚,同时要特别注意要引导用户的需求到我们的方案中来,与
销售部门的同事保持良性的沟通关系,从而尽量避免项目实施后进行变更。 http://blog.mypm.net

如果用户对于正在进行中的项目提出意见和建议,也是非常正常的事情,因为很多用户
都是见到系统原型后才有灵感的,因此,尽早地让用户见到原型,例如参观其他项目或者先
开发出具备初步功能的演示系统,则对于早日明确需求,少走弯路是非常重要的。

对于用户提出的需求,我们不应该简单地答应或者拒绝,这里面有一个需求识别的过程,
要系统评估需求变化导致的成本增加和质量改进,最终进行决策,并可以把决策的理由与用
户及时沟通,也许用户了解后会替你想出解决办法,例如有的项目用户会主动提出增加费用
和把新的需求放到二期工程中等,毕竟项目开始后大家都是一条船上的人,只要说明道理,
以诚相待,问题总会解决。 本文转自项目管理者联盟

如果一味满足用户的要求,不做识别评估,最终将导致项目的成本和进度失去控制,这

第 509 页 共 756 页
第 6 章 控制管理

种情况下质量很难做好,更何况用户的需求本身就是多变化和不确定的,因此,完全满足用
户的需求是不可能实现的,到头来项目没做好,再好的关系也没有了基础。

反过来,如果拒绝用户的要求,一定要有理有利有节,做好沟通工作,项目管理就是要
通过协调好各方面利益和力量来解决问题,用户作为项目的主导, 把他们排除在项目实施
过程之外是非常不明智的,对于最终项目的验收,使用和用户关系都非常不利。

总之,让用户在你的积极引导下参与,认真对待和评估需求变更,通过沟通协调来达成
一致解决问题,这样才能保证项目顺利完成。
分析 6:都有问题(daijiangbao) http://blog.mypm.net

合同实际上就是甲乙双方定的游戏规则,当游戏规则在符合法律和道义的前提下,一方
提出变通执行,另一方当然就要在不损害自身利益的情况下配合或接受;客户的需求在项目
执行中变更是正常的,无论是项目的渐进明细的规则还是“计划没有变化快”的事实,变更是
一定的,不变是教条的。面对这种情况,适应并解决客户的需求,实际上就是使客户满意,
这是所有服务(包括技术或管理服务在内)待业的宗旨,这不言而喻。
http://blog.mypm.net

项目经理 A 理解了这一真谛。尽管有人会说项目进度长了,项目成本增加了,但项目
的范围或质量要求也变更了,评价项目成功或失败的标准随之改变了,因而,客户满意了那
么这个项目就成功了——当然那些需求变更对应的是费用变更,客户花钱是得到一个自己满
意的项目,从这一点说,A 赢得了客户,把项目经营成功了。同时,A 通过优质的为客户服
务的行为,会赢得一大批潜在的客户,这些无形资产会给 A 所在的企业带来眼下和潜在的
效益。
项目经理 B 没有摆正自己乙方的位置,行话说就是不明白自己是服务方,从字面上看,他
严格按合同执行成了纸上的“赢家”,但客户会有很多办法挑出 B 的不足之处,尽管他控制好
了进度,可能会完成项目,但可以想见,一旦他的管理或服务有一点小小的瑕疵,则客户或
其他项目干第人会以此大做文章,项目成功的可能性阻力较大。退一步说,就算项目基本保
证进度完成了,这也是一个客户不大满意的项目,其后的服务和质量保证将面临诸多的难题,
潜在成本会增加。因而,B 的这种做法一是坑了客户,另一方面则是给自己制造了隐患,给
企业制造了潜在的风险甚至危机。

如果此公司想要长期做,那么用 A 的做法;如果此公司想打一枪换个地方,做两年拉
倒,就用 B 的短命方式吧,这样做企业能死的快些。 http://bbs.mypm.net

分析 7:不能绝对拒绝更不能绝对接受(龙七)

面对需求变更,要区别对待,不能绝对拒绝更不能绝对接受。拒绝伤害利益双方的感情,
接受导致项目延误,无法完成。从项目自身而言,不要变更是最好,这样能按时完成项目,
但是这是不可能的,那么引导客户对需求变更做处理,那是最好结果! http://bbs.mypm.net

分析 8:顾客就是上帝? (daijiangbao)

第 510 页 共 756 页
第 6 章 控制管理

dajundalao 说道:如果此公司想要长期做,那么用 A 的做法;如果此公司想打一枪换个


地方,做两年拉倒,就用 B 的短命方式吧,这样做企业能死的快些。

这是与实际情况不相符的,实际的情况可能是,用 A 的做法该公司死的更快,绝大多
数的公司都是这样来做的,妄想是能做大做强,可惜是死的更快,相反 B 法应该是稍微好
一些的方式,但是不清楚变更是客户给你再创造价值的机会,抓住机会让客户满意了,还能
获得更大的利润。

在项目中客户从来就不是上帝,这个观点要改正了,只有产品销售才是这个情况,不能
乱套。
http://bbs.mypm.net

分析 9:鱼和熊掌可以兼得(郭林海)

考核一个项目是多维度考虑,需要兼顾客户满意度、成本、进度;

得罪了客户,不给合同,公司无法运营;不得罪客户,任项目范围蔓延,成本增加,不
盈利,公司也无法运营;A 和 B 都是极端的做法。鱼和熊掌是否可以兼得?具体实践过程
中我们采取的方式是,针对变更制订一套完善的管理流程,客户需求提出来后,项目经理首
先判断是否在合同范围内,范围内优先处理,范围外的根据需求分析结果后进行报价,销售
与客户达成一致意见,客户在提前执行单上签字确认,承诺在后续合同中兑现,公司备案,
需求进入开发状态。这样既保证了客户的满意度同时也保证了公司的利益。

分析 10:要视情况而定,没有固定的办法!
(guob)
项目经理主要为项目负责,应该更多注重项目的进度、成本、质量,当然项目经理
也应该有客户意识,但是项目经理首先应该把握好自己角色的定位。

A 的做法,虽然暂时获得客户的满意但是却一再延误项目的进度,实际已经是不合格的
项目经理了。 项目管理者联盟文章,深入探讨。

B 更像一个强力型领导,可以说是一个合格的项目经理,但是也不能完全忽视客户的需
求。
项目管理者联盟,项目管理问题。

所以作为项目经理应该自己把主要的精力放在项目成本、进度、质量等方面,而客户需
求这方面可以交由公司的其他部门,比如销售、客户服务等,如果没有此类部门,那么可以
在自己的下属中安排这样的人去与客户对接,避免了直接“盛气凌人”与客户面对面。

此外,还需要对客户的需求进行分析与归类,合理的需求的确要满足,对于一个想成为
参天大树的企业,是不会不让鸟儿在自己身上歇息的。而当客户的需求不合理,那么就要想
办法让客户知道并理解。此外,再好地满足客户需求,也不可能满足所有客户的要求,因为
一些客户的要求还可能伤害另外客户的利益,所以项目经理应该在接受与拒绝之间做一个度
的把握,并且选择合适的沟通方法。

第 511 页 共 756 页
第 6 章 控制管理

6.2 如何控制好客户的变更需求

如何控制好客户的变更需求

中兴通讯股份有限
[姓 名] weiyunxi [单 位] [邮 件] wei.yunxi@zte.com.cn
公司
通信与网
[所属行业] [所属主题] 项目范围管理 [发布时间] 2007-1-29

【案例正文】
目前,我在负责一个海外的通信工程项目。客户在本地的电信领域是一个新的运营
商,相关的经验比较匮乏。加之我公司对本地的一些情况不是很清楚(我们曾努力
过,但需要时间),从合同签订开始,用户的需求变更非常频繁,直接带了那成本和
人力等方面的增加。在 PM 层面,我们可以制约他们的 PM。但是有时客户往往把
一些事情上升到总裁的层面,我们 PM 执行层面临来自市场的压力,往往就答应了
变更?请大家帮忙分析一下,在这种情况该如何控制用户的需求变更?

【相关分析】

·加强对变更的管理(2008-05-29) [作 者] ddeef [公 司] a

首先变更是不可避免的,有问题不能回避,只能积极的解决。
其次,要建立变更的流程,避免变更的随意性。建议流程如下:
客户员工提出-》客户负责人确认-》PM 确定处理意见-》安排开发处理-》测试-》客户确认。

再次,流程虽然建立了,但如果没有办法对流程进行自动化管理,慢慢的流程也就废掉了。建议
使用 URTracker 软件,将流程在软件中建立起来。客户有需求变更的情况时,使用软件对变更的过程
进行自动化控制和流转。这样就大大保证了流程的顺利实施,提高了沟通效率,同时可以对每个月的
变更情况进行统计分析,有利于提交项目成功的几率。

·如何控制好需求变更(2008-05-10) [作 者] zhuangqm [公 司] sdrcu

1。建议建立变更审批委员会,由双方的项目经理及领导组成;
2。必须严格按照需求变更审批流程;
3。全面评估需求变更,认真分析需求变更的原因以及带来的对项目进度、风险、质量等方面的影响;
4。如遇重大变更,需要召开专门会议研究定夺。
5。在如此多的需求变更的情况下,全面做好需求管理工作。

第 512 页 共 756 页
第 6 章 控制管理

·变更控制(2007-11-28) [作 者] 陈中民 [公 司] Canon

从案例中可以的知,在项目开始之前,开发商就知道客户是一个新的运行商,没有相关的经验,而开
发商也对本地的一些情况不熟悉,项目开始后,就导致了客户需求频繁变更,使得成本、进度、质量
受到严重的影响。
造成这种情况的很大的原因是:
1、 开发商没有进行风险分析和已知的风险应对措施
2、 没有利用自己公司的相关的开发经验,为客户提出项目范围需求建议,只是客户说什么就是什么,
没有一个严谨的范围定义过程,导致项目范围粗糙,为项目范围频繁变更流下了隐患
3、 没有定义一个适合与本项目的范围变更控制过程
客户能够把一些事情上升到总裁的层面,说明一些需求是客户必须的,只是在之前不知道罢了。若任
这种情况发展,必将导致项目的失败。因此可以采取以下措施:
1、 项目立即停止开发
2、 整理已开发的一些工作
3、 评估目前的工作状况,形成报告,列出一些可能应对以后工作的处理方法,向上级汇报
a) 终止项目,宣布项目失败
b) 继续项目的开发,但必须重新定义项目,增加投入(人员、资金等等)
4、 制定出有用户参与的范围变更控制过程
如:
用户提出变更申请λ
用户 PM 签字λ
PM 评估与交付时间确认λ
λ 分析变更对范围、进度、成本、质量的影响,相成报告
变更申请与影响报告和应对措施提交用户 PMλ
用户领导签字确认λ
变更实施λ
λ 用户变更实施确认

5、 重新做范围调查,定义项目的范围,定义项目的进度
6、 项目继续实施
7、 严格按照变更控制流程控制需求的变更

·加强沟通,与用户达成一致意见(2007-05-05) [作 者] 毛知新 [公 司] 湖南电力公司

对这样的情况在各行各业都普遍存在,应如何解决?
1、在项目开始前,应与用户充分沟通,对项目的范围有非常明确的了解和掌握。
2、在项目进行中,随时与用户沟通,让用户参与项目的进程管理。
3、对用户提出的变更,应与用户充分协商,尽量避免这种现象重复发生,应严格按照当初确定的方
案执行。
4、在项目开始时应明确,项目变更的费用核算和支付事宜。
5、在项目管理过程中应加强学习,特别对本专业的业务知识和客户关系应充分掌握,这样在项目的
管理过程中才能得心应手。

第 513 页 共 756 页
第 6 章 控制管理

·引入配置管理方法(2007-04-26) [作 者] 朱容安 [公 司] 航空公司

本案例存在的问题:
1、客户是电信领域一个新的运营商。(势必对通信工程项目的技术问题没有深层次的理解。)
2、该公司对当地的一些情况不是很清楚。(缺乏项目环境资料。)
3、客户变更非常频繁。
(随着项目的进展,作为新运营商的客户对项目的了解越来越明朗,项目需求
自然也会增加。)
4、客户将一些问题直接上升总裁到总裁的层面。(造成项目执行层工作的被动。)
针对上述原因,建议是在公司上下达成共识采用配置管理的方法对项目变更进行管理。原因如下:
配置管理可以有效保护项目人员不受反复无常的客户变更需求的干扰更好的满足技术要求,减少受理
变更的人员。

·对于需求确定来说本来就是一件很难的事情(2007-04-16) [作 者] 黄震 [公 司] BocSoft

对于需求确定来说本来就是一件很难的事情。特别是工程性项目。不知道楼主所说的项目是属于哪种,
看了全文个人认为应该属于研发性的项目,而研发性的项目需求前期确定一开始就需要有一个需求调
研和立项的过程。如果说你的公司连需求都没有调研过,没有立项过,那这个项目到底要做什么就没
有人知道了。对于写需求文档那都是在调研以及立项文档中都已经确定了的。你要写的是详细的需求
规格说明书,并不是你自己凭空可以想出来的。
你应该做好与领导的沟通,详细的确定需求再写说明书。这样就不会出现不知道写什么好了。
就你的描述,这个项目的团队也还没有形成。根本称不上是项目组。
楼主可以借这个项目提高自己这方面的能力,个人认为对你并没有什么坏处。但需要注意的是不要一
味的抱怨,应该好好思考一下你该怎么做。

·如何确定需求(2007-04-16) [作 者] 黄震 [公 司] BocSoft

对于需求确定来说本来就是一件很难的事情。特别是工程性项目。不知道楼主所说的项目是属于哪种,
看了全文个人认为应该属于研发性的项目,而研发性的项目需求前期确定一开始就需要有一个需求调
研和立项的过程。如果说你的公司连需求都没有调研过,没有立项过,那这个项目到底要做什么就没
有人知道了。对于写需求文档那都是在调研以及立项文档中都已经确定了的。你要写的是详细的需求
规格说明书,并不是你自己凭空可以想出来的。
你应该做好与领导的沟通,详细的确定需求再写说明书。这样就不会出现不知道写什么好了。
就你的描述,这个项目的团队也还没有形成。根本称不上是项目组。
楼主可以借这个项目提高自己这方面的能力,个人认为对你并没有什么坏处。但需要注意的是不要一
味的抱怨,应该好好思考一下你该怎么做。

·如何控制好客户的变更需求(2007-04-05) [作 者] 吴俊民 [公 司] 浙江建达

客户永远是上帝.我们做的项目最终目标就是满足客户的需求.

第 514 页 共 756 页
第 6 章 控制管理

在项目的计划价段,对于那些小的可能会出现的风险我们就要充分的考虑到并制定相应的策略,对于
客户所提的需求,如果偏离项目范围较远,必需要很好的和客户沟通,获得他们的配合,比如工期的延
迟,预算的追加等

·全面地了解变更需求(2007-03-24) [作 者] HSP [公 司] secret

在项目执行的过程中,客户的需求变更是不可避免的即便是有合同的约束。
对于客户提出的变更首先要研究其可行性,如果可行接着再分析对项目的多方面的影响,对于影响大
变更和管理层共同研究决定是否接受。总之,变更一定要有确认批准检验归档。

·如何控制好客户的变更需求(2007-03-21) [作 者] 胡月 [公 司] GE

客户需求在项目执行过程中出现变更是必然的,这需要我们认真分析客户需求的合理性和可行性,客
户变更的需求经分析后可能有以下几种结果:一是客户需求不可行,他完全超出了现有的条件所能达
到的目标,二是客户需求可以实现,但是将带来大量的成本的增加,三是客户需求可以实现,而且不
会带来大量的成本的增加。对于第一种情况,从市场的角度出发不能去拒绝客户的需求,但是我们可
以为客户分析其可行性,从客户的角度,找出它自身的制约条件,用户最终自己放弃其需求, 如果
是第二种情况,那末我们可以为用户提供一份详细地分析报告,言明其将带来的成本和时间的问题,
并力图寻找一种变通的方法,是双方都能接受的方式解决问题,实际上有时候客户对自己的需求并不
是特别明析,可以引导客户接受更为合理的解决方案。如果是第三种情况,当然答应也就无所谓了。

·正确对待变更(2007-03-21) [作 者] 龙七 [公 司] AMDOCS

首先变更是必然的,我们要积极面对.
其次所有的变更需要量化.记录每次变更,同时需要变更方签字.
最重要的是避免不好的变更,解决好的变更.如果我们能在用户提出变更前,为用户的实际需求提供好
的解决方案,那么我们还能接到需求吗?当然,这个需要在确定需求和项目的前期来做.后期的只能是
被动的应对了.

·老板的决定是对的(2007-01-31) [作 者] 奥林匹克 [公 司] 中铁七局集团有限公司

变更带来的不一定就是成本的增加,客观分析变更内容,站在技术的角度向客户分析利弊,如果确需
变更,即使增加了成本也要满足客户需要,这是市场的要求,我相信满意的产品会给你们带来应得的
收入,有耐心就会有收获。

·我的建议(2007-01-31) [作 者] zhangmin [公 司] 北京东方飞扬软件技术有限责任公司

第 515 页 共 756 页
第 6 章 控制管理

用户需求的变更总是不可避免的,所以我们要以这种心态去接受和控制用户的需求,而不仅仅是埋怨。
是用户,那她就肯定会提出需求,而由于用户的问题,可能会导致需求频繁的变更,针对这种情况,
我觉得要做好如下几点:
1、作为开发商,要认真钻研用户的需求,了解用户的直接需求,挖掘用户的见解需求,同时还要对
用户需求具有前瞻性;
2、对用户提出的需求,要认真进行分析,包括需求的提出背景等等,也许用户对需求的提出欠缺考
虑,所以我们要认真分析用户需求;
3、即使用户提出了需求,必须按照一般的需求管理流程进行变更控制,该签字就签字,该确认就确
认,这样就保证了即使项目延期或者失败,知道其原因。

·建议老板把自己换掉吧(2007-01-31) [作 者] 诚 [公 司] n/a

变更的流程:
1. 用户提出变更申请(表格 1-用户申请栏)
2. 用户 PM 签字(表格 1-用户 PM 审批栏)
3. PM 评估与交付时间确认( 表格 1-PM 评估/交付时间)
4. 是否对原合同内容产生变更?是否影响后续任务进展?是否需要追加人力和其他开销?(表格 2-
变更申请)
5. 用户领导签字确认(表格 2-变更申请确认)
6. 每月变更记录上报自己领导(表格 3-变更清单)

如果你觉得项目快要失败了,就建议老板把自己换掉吧(建议参考华为的项目案例)

·量化变更(2007-01-30) [作 者] 大兵 [公 司] 传世

客户的需求是永远不会满足的,可能一天一个样,为了达到控制的目的,我们可参照七步法对变更的需
求去做一个评估,将需求变更后产生的成本之类的东西进行量化,形成报告分析,提交于双方领导,达
到透明的目的,在允许情况下,才能做到让项目有条不紊进行.如果一味的妥协那只会让项目进一步恶
化!

·项目范围变更(2007-01-30) [作 者] 陆镭 [公 司] 南京中网通信有限公司

该项目的变更管理到这一步已经非常难以控制了。只有尽量争取公司上层的支持,首先向公司上层提
交一份详尽的项目阶段说明书,明确的说明项目从开始到现阶段的所有细节和提交的相关报告。说明
如果继续迁就用户对项目进行变更,只能带来更大的成本和人力的压力。项目的变更权尽量由公司上
层决定,同时要挟用户如再增加变更就要收取相关的费用。

·配合客户,掌控ECN(2007-01-30) [作 者] Jack Pan [公 司] 上海

第 516 页 共 756 页
第 6 章 控制管理

客户的每一次 ECN 都是希望确保产品趋向完美,没有哪个消费者愿意花钱买“赝品”,所以客户的


ECN,作为 PM 只能配合。
但是,频繁的 ECN 说明两个问题,客户对于市场要求项目目标不明确技术能力不到位,两一方面反映
出 PM 没能给出合理的建设性的专业意见。
PM 需要掌控客户及公司进度成本,PM 可以对客户的每一次 ECN 进行变更完成时间确认和变更成本分
析回复客户。确认哪些需要收费变更,哪些可以 free 配合客户。这样既可以维护客户关系,又不致
造成公司无谓的损失。

·变更的决策(2007-01-29) [作 者] daijiangbao [公 司] 深圳市大视野企业管理顾问有限公


客户的做法没有错,变更的批准要得到管理层的批准,项目经理没有批准变更的权力,尤其是在商业
社会中,以合同建立的双方,一般项目经理不是项目出资人,没有资格签署变更,更不应该答应变更,
这也是个资格的问题
该问题的关键是合同签署的太烂,为什么不能把所有的需求搞定再签合同?为什么不把变更的流程写
入合同?
变更管理的基础是基线,在基线的基础上再谈变更,客户需求制定的好,根本不需要变更,变更管理
不是为了变更而采取的管理,要在合同之前把准确的需求得到,用法律来维持保护基线,用法律来管
理无谓的变更。戴江保

第 517 页 共 756 页
第 7 章 成本与质量

第7章 成本与质量

7.1 项目内部成本控制问题

本人在一工程公司做销售部项目经理,对于公司所投标的每个项目采用的是销售部项目经理
负责制,而其结构属于强矩阵性结构。

现公司所参与的每个项目都需要销售部、技术部、执行部等的强力支持,而每个部门的人都
想使自己的利益最大化,所以作为销售项目经理的我总是很难把竞标价控制下来: http://bbs.mypm.net

项目经理——我:因参与每个项目需要花费太多的时间,每年能参与投标的也就几个项目,
所以我是尽量想取得该项目。

技术部项目经理:因对于每个项目参与的时间并不算太多,因此每年经过他们手上的项目可
能多达几十个,因此,他们根本不在乎该项目是否取得。他们希望将该项目的设计成本预算
做高。因为:
1、若中标后在该项目执行完毕时,实际设计费用比预算费用节省与多,则说明他们在施工
图设计中采用了许多优化设计(很多无法判断),这样他们便能得到更多的年终奖金。
2、若中标后,因该项目的预算费用较高,他们可以指定选用一些先进的设备(这种设备往
往只有仅一家生产或两三家生产)并写进技术协议(他们总能找到许多理由),这样他们便
能从厂家得到大量的回扣,可谓一举两得。

执行部项目经理:他们同技术部项目经理一样希望该项目的设备采购成本做高。因为:
1、 若中标后在该项目执行完毕时,实际执行费用比预算费用节省越多,则说明他们才设
备采购执行是很好的将成本得到控制,最终单位因多给以奖励。
2、若中标后,因该项目的预算费用较高,他们可以以较高的价格(当然肯定会低于该预算
价)分包出去,这样他们也能从分包厂家处得到大量的回扣,同样是一举两得。

本人也做过两年的项目执行工作,也通过了 PMP,因此在执行成本预算价格上能作出较为
实在的价格,并且在开评审会的时候能拿出充足的理由和信心。但因此而导致了技术部门和
执行部门私下的一下怨言。

请教作为项目经理的我应该如何控制成本才会使自己在竞标中处于有利位置?又如何来平
衡内部矛盾?

其他背景条件:
1、做成本预算时必须得到技术部和执行部的签字认可才有效;
2、因近年来国家大搞建设,再加上企业集团的支持,工程效益都还算不错,所以很多时候
竞标,就算是在价格较高的情况下也有部分项目中标,总体上来说,对于技术部和执行部来
说,因为在他们手上一直都有一二十个项目,所以根本都不愁没有中标的项目做。
3、就算规定技术部和执行部参与人员的奖金和每个项目的成功率挂钩,也是没有多大效益
的,因为他们总能说项目成功的关键在销售项目经理的外部社交能力,他们把成本预算做高

第 518 页 共 756 页
第 7 章 成本与质量

也是为了单位更多的效益(注:一般情况下成本预算按比例便得到销售价)。
4、 我公司所从事的是大型工程项目,每个项目都具有自己的独特性,在技术设计上都叫
做非标设计,因此,对于历史数据的参考价值是非常有限的。再者,我公司属于国营大企业,
虽然要求每个项目的利润水平一样,但每个项目的成本计算却比较混乱(涉及以上分析的多
方因素)。
5、 对于每个项目的外部投标价格是根据成本预算价作出的,而该投标价格的评审表必须
得各个部门参与评审讨论最终签字确认的,并非是由销售项目经理自己出做的一个价格。
6、在此讨论时,不用考虑销售项目经理的外部销售能力,只讨论内部管理

专家点评:黄绍良,项目管理者联盟 PMU 高级顾问

欢迎另一个项目经理进入现实的世界中。项目管理知识体系的成本管理知识主要是在正常情
况下一个项目经理该如何进行成本的估计及在采购过程中如何进行成本的监控,避免不必要
的浪费及损耗,在估算的成本内完成一个项目的交付。

投标是一个销售过程,目的是达到最大的销售量(成功竟投数量)和为企业带来最高的利润
指标(最高的投标价格)。虽然每一个投标过程都可以作为一个项目来处理,但投标项目的
目的是如何组合资源及以最低成本来完成标书的回应,同时以合理的投标价格击败竞争对
手,争取获得合同的机会,与一般项目的交付有很大的差异。

如这位销售部的项目经理指出,低价格并不一定是获得合同的唯一条件。如何把握投标的价
格成功获得合同,有很多客观条件和因素,更不是任何一个部门的项目经理所拥有的权力范
围,是需要各部门的项目经理互相协调,互相沟通,才能够依照每一个招标书的要求和项目
的特性来决定项目的投标价格。
本文转自项目管理者联盟

如果这位项目经理能够把自己定位于『项目销售经理』,而不是『销售项目经理』,相信他
更能把握每一个项目的销售,而不会因为 PMBoK 的知识而感觉烦恼。

成功的销售

投标是一种销售模式,如何透过投标获取合同,与其他销售手段没有任何差异,目的是成功
获得合同,交付成本需要执行部和技术部确认,是一个合理的方法和手段,避免销售部门在
销售压力下以低于成本的价格获得合同,为企业带来损失。

作为技术部门的主管或执行部门的主管,多希望提高预算或加长交付的时间,好能够在交付
的时候以低于预算或提前完成 http://blog.mypm.net

交付,但要在这些高成本上加上企业的利润要求,往往让销售部门认为缺乏竞争能力。
其实这家工程公司缺乏一个高层参与投标的机制,让销售部门的项目经理可以按个别情况让
高层做出最后的投标价格决定。过去我负责一家科技企业的欧洲专业服务部门时,每年不少
于二三百个招标书分别在二十多个国家内需要进行回应。那是我们把项目分为三等。第三等
项目是不超过五百万欧元的项目,投标价格可以由当地的销售主管决定,第二等项目是不超

第 519 页 共 756 页
第 7 章 成本与质量

过二千万欧元的项目,投标价格必须由该国家的总经理确认。一等项目是超过二千万欧元的
项目,投标价格必须经过我们欧洲分部的确认。这个机制让销售人员可以按项目的特性和当
时的实在情况建议如何才能够获得合同,让高层人员决定是否需要调整成本预算或降低利润
指标来达到最终投标的目的。

软技巧的应用 项目管理者联盟,项目管理问题。

我在另一章点评中也谈到管理软技巧,如何说服及影响其他部门经理来配合项目的目标,所
以一个销售部门的项目经理必须在投标的过程中充分与技术部门及执行部门的主管交流和
沟通,在遇到激烈竞争对手的时候,必须获得这些主管的支持及认同,才能够把投标的价格
变为一种战术的应用,以价格把对手击败。

在某种特殊情况下,如果以最低交付成本计算还是未能处于有利地位的时候,也许需要跟高
层协调,说服高层把利润指标降低,好能获取合同。但销售部门的项目经理应该紧记,这种
以价格竞争的思维只能在特殊情况下使用,在正常情况下应该以成本加利润来进行投标,以
企业的服务或技术附加值来增加投标的价格,而不是降低投标的价格。

点评总结
我们必须明确理解,项目管理中各管理模块的应用是如何合理完成交付,投标这种项目的目
标是递交标书和获取合同,项目管理知识的应用是如何组合有关技术部及执行部资源,以最
低的成本,最短的时间和最优质的技术及交付内容来完成这份投标书。并不是如何正确计算
交付成本来降低企业的最终利润。否则这个销售项目经理的位置绝对不会长久,更不要说升
职了。

会员网上评论精选: 项目管理者联盟文章,深入探讨。

评论(1)题目:无解
作者:天羽 wangtianyu999@yahoo.com.cn
http://bbs.mypm.net

你们的组织结构不是强矩阵,只是形式上的类似。
各职能部门被放在了一个项目名称下面,实际上是成本中心管理,但是按你的描述可能是在
采用利润中心的模式。这就导致部门利益高于项目,但是执行的主体又不能聚集成一个真正
的项目团队,这时作为项目经理的你,其实根本不能控制这个成本,你只能按照你的惯例或
是计算方法来报价,获取你们销售部概念下的最大利润。

竞标中的地位有两种:最低成本,最佳质量。最低成本意味着你将把所有的水分弄清楚,挤
掉,甚至还要打折,之后才能占据的;最佳质量就是公司的质量保证能力和品牌了,为此你
可以抬高价格,甚至高得离谱。
换句话说就是:在没有利润和高利润间平衡你的心理素质。恕我直言,报价只跟你有关系,
因为你预设了限制条件。

第 520 页 共 756 页
第 7 章 成本与质量

评论(2)题目:成本预设 项目管理者联盟文章,深入探讨。

作者:孙先平 ocean_sxp@21cn.com
分析一下,理一下思路:
1、竞标的价格公司是否有惯例?或历史参考数据,为了使自己处于一个更好的竞标地位,
当然内部成本能够降低会更好!根据你的情况,公司各相关部门对此类工程项目的预算是十
分清楚的,不管他们出于对自身什么样的利益考虑。想从这里挤出水份是比较困难的,他们
会有太多的理由来解释为什么要这么高的成本预算了;
2、那只能从项目本身来讲,如果项目具有特异性,你本人也有相当的经验,做出一份合理
的预算是可能的;

3、预算应当是你来做,无非与各个部门之间打打乒乓球而已;最终的结果是博弈的结
果:即相对合理,又不得罪人。
4、预算不宜做得太实,要做出相对较大的余量,也给自己一个空间。

题目:形成共同的利益
作者:孙先平 ocean_sxp@21cn.com
补充一点:
如果能够将大家共同的利益定位在共同的利益上来:技术部门不是通过吃回扣来获得收益,
而是通过项目的最终收益来获得奖励!——这只是个个假设!
就公司内部矛盾,那本来就是一场政治,本身即游离在利益与名誉之间!

评论(4)题目:团队的利益很难平衡
作者:李治学 lizx1810@163.com

其实共同利益是很难平衡的,就比如前两年人们想象的股份制企业一样,大家鼓吹的任何员
工都成了企业的主人,任何贪污回扣腐败等现象都不应该存在了,因企业的最终利益都是大
家的。其实真正的最终利润按股分摊在每个人身上也是极其有限的,所以何不趁自己的工作
方便来赚取其他额外的收入呢?这肯定比企业的年终分红大得多。

评论(5)题目:平衡利益 项目管理者联盟,项目管理问题。

作者:天羽 wangtianyu999@yahoo.com.cn http://bbs.mypm.net

就补充说明部分而言,我理解是公司的利润要求是一个一刀切的指标,而各部门成本概算各
有技巧,你兼有技术和 PMP,能够弄清楚真实的成本。但是由此招来非难……事情到了这个
时候,只能从平均利润的角度来均衡,尽管是非标设计,任何部门都会有操作的习惯,都会
有基本利润隐藏点,通常情况下,利润会隐藏在“容易项”下面,否则项目风险极大。有鉴于
此,你们销售部门可以均衡去年成本概算的水分和固定资产增加与利用率等要素,对他们今
年的利润进行均衡,可以促使部门按照长期发展的模式来进行概算,从而降低当期的成本。
这样的情况,在国营企业里,只能够用一种财务方式进行协调解决。

评论(6)题目:项目内部成本控制问题
作者:尚小鹏 shangxiaopeng@163.com
社会行为都是由人来进行的,从人的角度去解决问题往往要容易些。既然你明白其它各个部
门的想法,那么现在就不是某些技术和流程上的因素了,除了在平时和他们多多沟通和搞好

第 521 页 共 756 页
第 7 章 成本与质量

关系外,可以和他们中的有些人彻底的谈谈你的想法,那种公开式的开会类的形式是没有用
的,在整个基础上可能比较容易实现你的目的。还是沟通为本,关系其实是现有国情下的关
键。

评论(7)题目:寻找利益平衡点
作者:王海飞 whaifei@263.net 项目管理者联盟,项目管理问题。

这种现象非常普遍,也非常的正常和合情合理。每个人都会为自己部门的利益最大化而努力,
就像当年共产党与国民党一样,即斗争又合作!因此应该同各部门进行充分的沟通,寻找大
家都能接受的黄金分割点。

7.2 *赔钱的项目与企业的业绩

(一)案例正文

赔钱的项目与企业的业绩

某欧洲企业在内地的分公司在香港签了一个金额很小的系统集成项目。
项目经理初步估算毛利只有 6%(同类项目通常有 20%),而且由于合同额小,五六千块
就是一个百分点,相应的境外施工风险很多,故而不想接受这个项目。但销售硬逼着做,说
是为了有业绩,所以只好硬着头皮接下项目。

但随着项目进行,由于缺乏相应的与香港客户合作经验,人工比预期大大增加(外企的单位
人工成本非常高),项目利润一路下滑至负的百分之十几个点。
这个项目或许会按时保质完成,但该公司是注定要赔钱了。请问这种“业绩”项目该如何对
待?这个项目的项目经理究竟是成功还是失败?

(二)专家点评

点评专家 卢毅 清华大学 MBA,PMP

清华大学 MBA,PMP,现任合力金桥软件公司副总裁。卢毅先生有十多年项目管理实战经
验,亲自管理过几千万级的电信行业项目、几百万级的多个电力行业项目和众多的生产制造、
流通、物流等行业项目。历任项目经理、项目总监、项目实施部门的总经理、公司分管项目
实施的副总裁等职,在项目实施方法论、多项目管理和建立公司级项目管理体系等方面有非
常独到的见解和实战经验。

卢毅点评:

我觉得这个案例反映的是一个非常普遍的现象和一个非常值得深思的问题。下面我主要分如
下几个方面做一些点评:

(1)项目管理的表象:一般项目经理碰到了这种情况,就无所适从了,总是当心项目赔钱
了,总是当心项目绩效不好,总是认为自己作为项目经理是失败的。其实,这是一种非常普

第 522 页 共 756 页
第 7 章 成本与质量

遍的现象,我们不能根据表象去评价项目管理好坏。但无论是个人,还是组织,都很容易陷
入这种错误中,而且越陷越深,还浑然不觉。

(2)项目管理的误区:这种项目管理表象引发了一个非常值得深思的问题,就是项目管理
衡量的依据是什么?与本案例类似的项目,无论组织或项目经理本人,都不自觉地将自己的
工作成效与项目的最后利润直接挂钩,认为项目管理成功的利润就高,利润不高或赔钱了就
认定项目管理失败了。其实,已经走入了一个很普遍的误区。

(3)项目成败的标准:衡量项目管理成败的依据不是项目最后的利润情况,不是象案例中
说的赔钱的项目就是项目管理失败!项目成败的依据应该是最后项目的实际绩效与计划的时
间、质量、预算和客户满意度达成的情况。本案例主要谈到项目预算方面的问题,我认为无
论客户经理出于什么考虑,作为项目经理在做预算时不要走入误区,而应制定一个合理的预
算,最后衡量项目的成败就看与计划的出入情况。比如,客户经理签下来的项目毛利是 30
万,按合理的情况下应该有 50 万毛利的话,项目经理应该认为是在做一个 50 万的项目(千
万不要自认为在做 30 万的项目!),假定合理成本预算可以是 40 万的话,最后项目绩效
就看实际发生成本与 40 万的比较(而不是与 30 完比较!),项目是否赔钱应与 50 万比
较!

(4)项目管理的关键:以上误区之所以出现,关键是没有考虑客户经理少签 20 万(50 万
-30 万)换来的是什么!这 20 万可能换来的是销售完成了 30 万业绩(说明公司考核客户
经理制度有问题!),或建立了一个战略客户(说名用 20 万做长线投资!)。总之,大家
很容易就陷于误区,没有看到 20 万的价值。其实,问题的关键是不管客户经理签 30 万还
是 60 万,项目预算成本应该是 40 万考虑就对了(而不是去考虑 30 万还是 60 万)。

(5)可控与不可控因素分析:我认为客户经理签 30 万还是 60 万,对项目经理来说是不


可控因素,理论上说与项目管理水平无关。但案例里提到由于缺乏相应的与香港客户合作经
验,人工比预期大大增加,这是项目经理可控因素,说明项目组缺乏经验,项目管理水平有
局限。衡量项目经理管理成败和管理境界,主要看他对可控因素的处理,要是看不可控因素
就不自觉地走入了误区。

(三)项目管理者联盟网友评论

分析 1:成功与失败并不能以赚钱定认 作者:车山根

此项目经理分析能力和联系实际能力纵在一起,没有定量的分析香港市场,没有做好完善市
场调查,这样在境外工作会带来很多想不到的结果。从项目利润来看,该项目经理是失败的。
但是从长远来看,我们在这样的情况下还能按时保质完成,香港是一个舆论很宽的一个市场,
这样会给我们公司带来更多的业绩,项目经理也在这个项目上学到很多东西。这样会给下一
个项目打下很好的基础。

分析 2:赔钱的项目与企业的业绩 作者:乱世佳人

我觉得,从利润看,这个项目肯定是赔钱的,业绩也应该算失败的,但是,要看这个企业的

第 523 页 共 756 页
第 7 章 成本与质量

项目/市场愿不愿意以后进入香港市场,如果以后都不考虑香港市场,可能结论就是这样了,
但要是要进入香港市场,这个项目是不是可以作为一次经验之谈呢?

分析 3:从多个角度考虑 作者:qijun

第一进入了香港市场
第二有了项目业绩 项目管理者联盟,项目管理问题。

以上两项是很重要的,尤其是对刚进入新兴市场的时候。这是很重要的!!!
第三积累了经验
第四主要的责任,项目经理应该是比较好的完成了。
第五项目的评估不光是项目经理的问题,明知风险的情况下公司还要做,说明公司高层有其
他考虑,应该综合评价!

分析 4:新市场项目要从公司的战略高度考虑 作者:james

任何商业性公司的首要目标是盈利,而且要使利润最大化,但这并不意味着每个项目必须盈
利,盈利是有长短期之分,同样也有市场考虑,同时还要与公司的战略管理相吻合。因此新
市场项目必须从公司的战略高度来考虑。在上述的案例中中,项目经理应考虑如下问题:
1.因为是小项目,但却是新市场,公司有无进入新市场的战略计划?如根本无此计划,此种
项目得不偿失。
2.因为是新市场的项目,而且是小项目,公司有无设置止损点,利益损失是否与公司进入该
市场的战略成本相冲突?
公司有进入该市场的计划,但无止损点将严重损害公司利益。
3.因为是新市场项目,项目经理必须考虑有可能发生的例外情形,如案例中所说的人力的失
察而导致项目成本的上升,案例中这也是项目经理的明显失察之处。
4.新市场的风险评估尤其要谨慎
5.但无论如何,只要接下该项目,就必须按质完成。这是拓展新市场业务的最好实证。

分析 5:失败也英雄 作者:Ye Ming

1。各位老兄都从正常的公司运作角度来分析其工作得失。
2。有无考虑公司内部人为因素的影响,有时项目从一开始就注定是失败,原因不仅仅在于
技术或操作的因素,更多政治。
3。不论如何作为项目经理,应对项目做一个自己的评估并上报给相关利害关系人,这点对
自我保护是至少是必要的。

4。有时失败也英雄。

分析 6:一点见解除 作者:张辉

对于这个项目来说,从公司的角度上来讲,这是一个战略决策.公司要求进行这个项目,说明此
项目的重要性.因此.项目经理不得不展开工作.

第 524 页 共 756 页
第 7 章 成本与质量

对于项目经理来说,需要提高的地方是更加全面的对项目进行成本预估,当前,最大限度的降
低成本是当务之急.项目经理应该对这个项目重新进行一次成本预估.并提交一份报告.如果
最后公司赔钱了,但是在项目经理提交的报告范围内,说明这个项目经理还是成功的.

分析 7:很奇怪的谈战略 作者:daijiangbao

我觉得,不必要谈太多的战略,项目再烂项目经理也是要去做,而且一定要能去有利润,逃
避和借口都是没有意义的,也不要唉声叹气,关键是如何与别人沟通,不要天天把风险挂在
嘴上,把劣势化为优势才是关键,才是真正能锻炼项目经理的,项目不是做就可以的,也不
是做好才是有能力,关键来说,对任何企业,对任何一个项目都要挣钱,对 IT 行业来说,
越是高风险越要有高利润,没有必要谈冠冕堂皇的战略,企业的战略就是赚钱,没有商业意
识的项目经理就不是合格的项目经理

分析 8:从项目的目标出发找合适的项目 作者:严长洪

一个公司要找一个合适的目标首先就要知道自已的对方能不能提出合适的条件,并不是什么
项目多可以接下来的,还是就是这个经理已经知道这个项目的工作不好做,而且利润率也不
高,风险也比较高。根据项目管理上的内容我们知道会出现以下情况:
1.利润率不高或者是有可能会赔。
2.对象的情形我们不太清楚,香港人员他们有什么习惯。
3.一个项目是取决于这个项目的利润率。你既是有业绩但你这个公没有利润率也是不行的。
可以来个比如:“一个厂品卖出后而没有利润,业绩是产生了但是没有利润,你说这个厂可
以生存下来吗?”
4.业绩与影响力也有关:第一,业绩上去了,影响力没有产生,而利润也没有产生。第二,
业绩上去了,影响力有产生,而利润也没有产生。第三,业绩上去了,影响力没有产生,而
利润也有产生。第四,业绩上去了,影响力有产生,而利润也有产生。以这四种情况哪一个
是这个案例的呢?大家一看也知道。
5.企业的宗合管理能力和想象力:第一,经理已经知道这个项目是不可以接的,但是他还是
接下来了,这是错误一。第二,业务人员的素质比较低,只知道自已的业绩,而不考虑公司
的利润,错误二。第三,公司的高层管理人员素质较低,有一种严重的错误思想,(这个业
务接下来,找不到我的头上来的想法,不了了事的做法。)
6.管理意识不强,能过得过的心理思想。
7.最重要的也是公司的高兴之处:员工可以接受新的挑战。

分析 9:项目经理在此项目中的要求 作者:严颜朝

一、项目经理按照其初步估算---毛利只有 6%(同类项目通常有 20%),而且由于合


同额小,五六千块就是一个百分点,相应的境外施工风险很多。说明该项目是不应该接手的,
项目本身的盈亏在项目经理来说,是一个原则性的问题。 http://blog.mypm.net

二、但硬着头皮接下项目,就应该积极的进行项目的相关活动,首先要有一个全面、详尽的
项目分析和编制项目进程计划(包括项目干系人分析,并与之积极交流和沟通),这样至少
不会出现“随着项目进行,由于缺乏相应的与香港客户合作经验,人工比预期大大增加(外
企的单位人工成本非常高),项目利润一路下滑至负的百分之十几个点”的情况。

第 525 页 共 756 页
第 7 章 成本与质量

三、项目业绩的衡量不仅是一个盈亏问题,还必须着眼于项目所达到的社会效应、对项目干
系人所产生的影响---包括一个无形项目业绩的问题,这时危机管理引进项目管理中的一
个必要考虑。

分析 10:再发表一点我的观点 作者:daijiangbao

项目经理的一个重要职责是要影响公司的决策,最主要的靠的就是沟通,历来干的好不如说
的好就是这样的道理。
商场如战场,在商业社会下谈项目管理,成功不成功就是看客户满意和利润,学究一般不谈
钱的项目管理是根本不能成功的,况且成本管理本身就是项目管理的一部分。

我们见到的太多情况就是活干完了就认为是项目管理成功了,但是企业成功了吗?与客户做
到双赢了吗?你自己这样亏,客户能是满意的吗?(很奇怪吗?)高风险项目就是要转换成
高利润项目才有意义。我觉得是谈项目管理,大家都在抱怨环境,关键的是这样没有意义的,
要适应环境并利用环境,项目管理不是改造环境的工具,否则的结果是很清楚谁去修理谁了。
满嘴挂的都是风险,估计是什么事情都干不了。很奇怪的论点就是想当然的认为,现在项目
亏一点,下次项目再赚回来,我可以负责人的说,没有这样的机会,不会有下次赚回来的可
能。新时代的汤恩波思想,没有打仗,现把打败仗的后路准备好,贮备好了失败,则必定就
是去失败。

分析 11:项目经理永远不能免责!!! 作者:karibu

我也在一欧洲公司作项目经理,也做过“业绩”项目,谈谈我对这个案例的想法。
首先是项目预算的问题,既然知道在香港作项目风险很大,在作预算时应该打入足够的风险
准备金,这样毛利就不会为虚高的 6%了。 http://blog.mypm.net

签合同时我想一定先有销售的计算单了。项目经理在项目交接时应重审这个计算单,充分考
虑各种风险,为项目制定一个可行的计算单。
人工费超出预期是因为单位工时费高还是增加工时?外企的人工成本是高,但这在做预算的
时候就知道了,不是超支的理由。如果是因为超时,就是技术风险考虑不足,直接责任在工
程师,但需要负责的还是项目经理。
大多数项目超支都发生在执行阶段,但启动阶段就注定了这是一个赔钱的项目。问题是销售
掩盖了这个矛盾,项目经理的悲哀在于他往往无权选择项目。因此项目经理在接手项目时必
须及时揭露潜在问题,给管理层做好心理准备。说穿了,这是一种政治手段。 http://blog.mypm.net

“五六千块就是一个百分点”说明这个项目不大,公司完全有能力花钱买业绩,但项目经理
必须提前让管理层知道他们到底需要花多少钱来买业绩。公司老总最不喜欢的就是 suppris
e。
项目管理者联盟文章,深入探讨。

不知项目进行到什么阶段了,如果还有一段时间才结束,应尽快作出准确的 ETC,(别忘了留
出一些风险的空间),报告给公司。公司管理层自会对项目的成败作出判断的。

分析 12:平庸的项目经理 作者:张超 本文转自项目管理者联盟

首先,从同类项目通常有 20%的毛利做对比。香港企业会选择你的公司进行这个项目,而且

第 526 页 共 756 页
第 7 章 成本与质量

只给你 6%的毛利来看。这样的商业关系是不可取的。首先,对毛利的估算可以得出一、香
港企业不了解这个项目、二香港企业只希望用最少的支出完成一个项目,而不是一个起始项
目。从这一点看,这个项目本身是不可取的,就算从这次的项目合作中建立了商业关系。但
是建立在无赢利点的项目合作上形成的商业惯性将无法使商业关系得到良好的维系;
其次,按 20%的毛利进行计算的话。6%的初步估计到负百分十几个点。如果把这个项目按常
规项目计算,成本控制在 20%。也就是说没有达到亏损或很大的亏损。 项目管理者联盟文章,深入探讨。

总结:公司的决策导致了这个项目注定赔钱的结局。项目经理只是做为一个普通的组织者,
把成本控制在盈亏点。应该说,这个项目经理并不算成功,也不能说失败。只能算一个平庸
的管理人员。

分析 13:单个项目来说 项目经理就是要在成本允许 作者:赵宏伟

单个项目来说 项目经理应该在成本允许范围内 满足各个利害相关者的需求,赚钱是老板的


公司的需求,项目的可用性是满足用户的需求。
而多项目的综合管理来说,那是不可能所有的子项目都要满足所有利害相关者的需求,只能
整体来说满足各利害相关者的需求!
所以具体的问题还是要根据具体情况确定 这个项目是否还要继续的要求。

7.3 项目人员成本超支问题

(一)案例正文

我们做的是一个财务管理软件,在项目初期我们的项目经理做的售前工作,跟客户了解了大
体的需求,并且制定了项目方案,而项目方案是一个很笼统的框架性的东西,而我被指派与
客户详细的调研需求,整个项目的与客户面对面接触调研需求共 3 次,第一次我已完全理
解客户的需求和意图,而第二次并没有什么实质性的收获,因为客户给我的时间就很少,我
们只简单讨论了与客户现存系统的接口问题,第三次谈需求,客户提出了一些需求而针对他
的子系统的结构是很难实现的,当时我极力反对,但反对无效,因为我们的客户分两部分:
转包客户、最终客户。

这还是个二包项目。而这种很难实现的需求是最终客户提出而转包客户不反对反倒支持。这
样三次需求调研的结果就是得到一个业务逻辑异常复杂的业务模型。有了详细的业务模型之
后,我很快初步估算出代码最少 5 万行,并且向项目总监通报了情况,但是项目总监认为
项目不可能这么简单,也没去与客户沟通。

我只好按着这个需求继续往下进行(当我与客户做二次需求调研时,我就已经变为项目经理
的角色,当然此时我就是项目经理了,而原来的项目经理就是现在的项目总监了),当然了,
在有了详细业务模型后,我们先设计了软件原型,用了两个星期,这阶段解决了几乎所有的
界面组件(有很强的通用性)。然后再与客户讨论原型,不过客户那边的反映很迟缓,光让
他确认这个原型就浪费了二十天时间,不过这段时间我也没闲着,开始着想考虑他那个难缠

第 527 页 共 756 页
第 7 章 成本与质量

的需求是不是有什么解决方法,结果分析来分析去,最终得出结论,根本不存在什么合适的
解决方案,而这块需求倒底做不做一直困惑我很长时间,其实与客户沟通很不方便,因为我
们开发的地点与客户不在一个城市里,对于这样的问题我跟客户在 msn 上沟通过多次,客
户都不明白我要说的问题的本质是什么,他还是坚持要实现这个需求,结果为此我又努力偿
试寻找解决方案。

客户催要一个初步的软件版本,因为但是因业务逻辑的核心问题,我们无法进行业务模块的
编码,已经完成的是与业务关系不大的部分。而此时我又进一步估算,代码量应该有 8 万
行了,因为更细致的架构接口已经有了,也就是说一个完整的框架都有了,估算出的代码行
数就比较准了。

8 万行代码远远超出了原来的预算,就是去掉与客户不断的争论业务需求的时间都用来写代
码,8 万行代码也不是这个费用够用的,目前我处在骑虎难下的境地,公司要求我能拿出有
利于我们有说服力的证据来,但事实上,客户除了那个比较难缠的需求外,没有更多多余的
需求,而我也只对需求做了一些润色,我觉得这是很有必要的,去掉反倒不妥,并没有增加
多余的需求。但就是这样的需求完成他确实需要写 8 万行代码,如果去掉业务员的功能,
我想能精减个一万行代码。那还有 7 万呢啊。

公司要求我在尽可能短的时间内先完成一些基本的功能,但我不知道应该如何划分基本功
能,在我看来,这些功能都很必要嘛,可以说大部分功能都是紧扣客户需求的,只有少部分
可以暂时省掉。与其说在最短的时候内完成一个基本功能版与客户谈,还不如说在最短的时
候内完成软件第一个完整版本(只缺少很少的一点儿功能),短时间肯定没戏。完成了再跟
客户谈价钱吗?其实这个项目我们是赔大发了,继续做,公司也是支持不下去的。
这个问题难道就无解了吗?

(二)点评专家

曹济 北京随济科技公司首席顾问/国际软件标杆组织技术顾问/欧洲软件度量论坛(2006)
组委会成员/信息产业部系统集成项目经理委员会成员/IEEE/PMI/IFPUG/ISBSG 会员

为上百家的国内外 IT 组织提供过 IT 项目管理、软件项目管理、基础项目管理、项目量化管


理、软件估算和软件度量、软件质量管理、软件测试管理等方面的公开培训课程与企业内训
服务。为十多家软件公司提供 CMM/CMMI 培训咨询服务、软件标杆管理体系培训咨询服
务、项目管理体系培训咨询服务

曹济点评:

您好!首先感谢韩先生愿意贡献自己的案例供我们大家交流。其实像您谈到的这种项目情形
还是比较典型的。我们从两方面来讨论吧,首先看对眼下的情况如何应对,其次我们关心如
何在后续的项目中避免发生类似的情形

看来你们现在已经感项目会面临比较大的问题了,因为你谈到八万行的代码量已经远远超出
了你们的成本,有可能的话我们采用简单的算法看看你们大概会超出多少。因为你们的项目

第 528 页 共 756 页
第 7 章 成本与质量

特点(包括人员规模、开发周期、开发语言与开发平台等)还不了解,所以我们给一个非常
粗略的平均生产率,例如 90 行/人天,这样可以得出项目的总工作量大概接近 900 人天(8
0000/90),即 40 人月的样子,假定你公司软件开发人员的平均月工资为 4k(当然可能为
其他水平),则人员均摊费用为 4k*2.5=10k,这样项目的成本大概是 400k,不知道合同
额与这个数据相比怎么样?当然地区不一样,开发语言等等会有差异,但如果在国内的话,
应该是介于 100k 与 1500 k 之间的。

有了这个印象之后再来看如何补救,“公司要求我能拿出有利于我们有说服力的证据来”,说
明公司有希望和客户去协商的。可是问题出来了,“但事实上,客户除了那个比较难缠的需
求外,没有更多多余的需求,而我也只对需求做了一些润色,我觉得这是很有必要的,去掉
反倒不妥,并没有增加多余的需求。但就是这样的需求完成他确实需要写 8 万行代码”。

我没看明白,这个难缠的需求对应是三万行代码?根据是什么?从代码行估算的方式来讲,
一般会将代码行的尺度控制在 100 到 500 行之间的,所以先把这个问题解决了,将详细的
估算纪录提供给公司和客户去交流

然后再看下一个问题,“公司要求我在尽可能短的时间内先完成一些基本的功能,但我不知
道应该如何划分基本功能,在我看来,这些功能都很必要嘛,可以说大部分功能都是紧扣客
户需求的,只有少部分可以暂时省掉”。

在这样的情况下,通常会采用将需求分优先级的情况去实现,这样可以降低客户的不满意度。
所以公司的要求是合理的,你自己需要再征求客户意见的基础之上再结合所需的工作量以及
实现难度等因素确定需求的优先级。

现在项目面临的主要问题是前期合同签署的问题(范围界定不清,后期工作量剧增),应该
在配合公司的前提下去争取签署补充协议。而您的主要任务则是“说清楚”,为公司与客户协
商提供客观的、充分的证据,例如详细的估算数据、需求的优先级列表等。

如何在后续的项目中避免发生类似的情形?其实很多文章和书籍都谈到了这类问题,我自己
感到最重要的一点还是应该在合同签署时就要有充分的考虑,您有兴趣的话,可以去看一下
我的文章“IT 项目招投标二维分析法”(在项目管理联盟网站便可看到)。

(三)项目管理者联盟网友评论

分析 1:一点拙见 作者:于先生
1、看来应该是前期调研补充分的结果,那么现在在时间和资金紧张的情况下,可不可以只
考虑客户最急需的部分,而不是自己认为有用的部分,此后在试运行期间完善呢?
2、可以根据项目进展情况,做一份项目实施估算报告,体现出导致紧张的各方面,这样更
有说服力,并且一定要和总监与客户三方对话,因为这种情况下客户只认总监。 项目管理者联盟文章,深入探讨。

3、给出新的项目需求、实施计划及困难所在,必要时重新谈价格。

分析 2:精简需求 作者:陈晨
1、最主要的还是要有机会与最终用户沟通。了解所作项目用户最关心的是那部分。这部分
作完成后等于完成了 80%的工作。

第 529 页 共 756 页
第 7 章 成本与质量

2、确定哪些部分不用臆想出来的,把这部分仅仅做个界面,和简单的功能模拟就可以了。
3、如果希望项目成功,建议,不要仅仅看需求文档。要看用户的工作是否真的非常紧迫的
需要某些功能。如果是没有什么含糊的努力做,如果不是就可以简单带过,功能有了就可以
了。
当前最需要做的是把自己需要的工作,理顺出来,看看那些才是最重要的中心环节,这些弄
明白了,个人认为可以按步就班的开发了

分析 3:确认需求 作者:唐旭东
其实对于需求调研工作,我觉得这个是在培养客户,而不是在让客户任意发挥,因为客户不会
对自己随口说出的话负责,只是觉得有这个需要,想这么做,在这个时候:
1.我觉得关键是要引导客户,把客户引导到自己的思路上,这样才有助于项目的进展,因为客
户在自己心中不会有系统的模型;
2.其次,是要控制需求,抓主要矛盾,把主要的功能先实现,保证在主要的业务上系统能够实现,
不会出问题;
3.再次,我觉得原因在于没有完全了解客户的业务,也就是说以前没有这方面的业务经验,对
于需要调研那些方面,那些范围,没有在调研前做一个详细的分析和整理;

分析 4:软件的基本功能! 作者:赵宏伟
其实针对一个软件的基本功能完全可以和用户谈判或者讨论来决定的! 在规定好的时间内
完成相应的内容! 这样子也是一个项目执行过程中的调整! 你自认为的“在我看来,这些
功能都很必要嘛,“ 这都是你自己认为的 并不表示客户真正需求的!
所以在最短的时候内完成一个基本功能版 完全可以在自己的控制之下完成呢!

分析 5:项目执行所需要的人员成本超出了预算,而且项目已经严重泄后 作者:kitty
既然是用户型的项目,那就应该好好的利用客户。其实客户有时自己都不明白自己要做的是
什么,要实现的是哪些功能。所以在前期需求阶段要花费很多的时间与客户讨论,究竟做哪,
怎么做,然后达成一致的意见。这种意见不是口头的,而是要经过双方具体代表性的人物签
字确认的。。否则后面的变更会变得不可追溯。

分析 6:确定客户要的基本模块,并只保障之 作者:黄飞生
1 确定客户要的基本模块,并只保障之.
2 下狠心的把自己很满意的部分也按实际的客户基本需求情况进行删除.
除非充分与客户沟通,得到新的资源.没其他办法!

分析 7:重新梳理需求,评估项目和预算,适量要求追加预算 作者:游永明
通过对案例的分析,我们了解到
1、对于项目的需求比较清晰,但是核心业务了解不够,同时还存在不合理需求 本文转自项目管理者联盟

2、项目进度控制存在问题,和客户沟通因为 2 次转包存在一定的弊端,对客户的引导不够
3、对系统基本功能把握不够,其实也是对客户业务不够深入了解 http://bbs.mypm.net

4、工作量估计出现很大出入,导致预算超支
我的建议:前面有朋友提出加强和客户沟通,确定基本功能等,我再补充一下。针对客户急
需初步版本,我认为可以选取两个业务流程来重点实现,作为 demo 版本演示给客户以增

第 530 页 共 756 页
第 7 章 成本与质量

加客户信心。另外比较重要的是重新梳理需求,删除自己认为合理但是得不到客户认同的,
列出客户重点需求。根据梳理后得需求重新估计工作量,确定项目预算。最后就是针对梳理
后的需求,进行合理的调整与客户沟通增加投资的问题。适当采用需求增加导致费用增加的
方法,因为案例并没有提到客户对需求的完全确认,这是一个突破口。

让客户对你们有信心,同时你们要显示出自己的实力,最后就是双方的妥协适量增加投资预
算,达到项目的最终完成。

分析 8:好长的案例呀,累眼睛 作者:中国武则天 (电信公司 chenchen19@sohu.com)


案例太长了,大概了解了一下意思:
我的建议如下:
1.软件开发前期准备做的不到位,项目的准备成本是永远低于实际操作成本(当然在项目完
成时间内);
2.将用户需求明细在合同中;
3.项目开发的所有功能均按照合同的确定后方案执行,期间用户需求一但有变动,需让用户
直接与项目管理人沟通,并明确需求的变动不在我方。
个人建议,请参考

分析 9:分析 作者:魏云峰
个人认为问题的关键是需求控制。客户需求和技术实现方案应该作为合同附件,纳入合同中。
同时客户需求变更是难免的,应该把需求变更如何控制,提前协商好纳入合同中。
当然,如果属于先开发出成品再签合同的就郁闷了。如果盈利无望,往下做不做就看公司战
略需要了。

7.4 项目内部成本控制问题

项目内部成本控制问题

[姓 名] 李治学 [单 位] 不公开 [邮 件] lizx1810@163.com


[所属行业] 综合应用 [所属主题] 项目成本管理 [发布时间] 2005-11-28

【案例正文】
本人在一工程公司做销售部项目经理,对于公司所投标的每个项目采用的是销售部项目经理负
责制,而其结构属于强矩阵性结构。

现公司所参与的每个项目都需要销售部、技术部、执行部等的强力支持,而每个部门的人都想
使自己的利益最大化,所以作为销售项目经理的我总是很难把竞标价控制下来:

第 531 页 共 756 页
第 7 章 成本与质量

项目经理——我:因参与每个项目需要花费太多的时间,每年能参与投标的也就几个项目,所
以我是尽量想取得该项目。

技术部项目经理:因对于每个项目参与的时间并不算太多,因此每年经过他们手上的项目可能
多达几十个,因此,他们根本不在乎该项目是否取得。他们希望将该项目的设计成本预算做高。
因为:
1、若中标后在该项目执行完毕时,实际设计费用比预算费用节省与多,则说明他们在施工图
设计中采用了许多优化设计(很多无法判断),这样他们便能得到更多的年终奖金。
2、若中标后,因该项目的预算费用较高,他们可以指定选用一些先进的设备(这种设备往往
只有仅一家生产或两三家生产)并写进技术协议(他们总能找到许多理由),这样他们便能从
厂家得到大量的回扣,可谓一举两得。

执行部项目经理:他们同技术部项目经理一样希望该项目的设备采购成本做高。因为:1、 若
中标后在该项目执行完毕时,实际执行费用比预算费用节省越多,则说明他们才设备采购执行
是很好的将成本得到控制,最终单位因多给以奖励。
2、若中标后,因该项目的预算费用较高,他们可以以较高的价格(当然肯定会低于该预算价)
分包出去,这样他们也能从分包厂家处得到大量的回扣,同样是一举两得。

请教作为项目经理的我应该如何控制成本才会使自己在竞标中处于有利位置?

(条件 1、做成本预算时必须得到技术部和执行部的签字认可才有效;2、因近年来国家大搞
建设,再加上企业集团的支持,工程效益都还算不错,所以很多时候竞标,就算是在价格较高
的情况下也有部分项目中标,总体上来说,对于技术部和执行部来说,因为在他们手上一直都
有一二十个项目,所以根本都不愁没有中标的项目做。3、就算规定技术部和执行部参与人员
的奖金和每个项目的成功率挂钩,也是没有多大效益的,因为他们总能说项目成功的关键在销
售项目经理的外部社交能力,他们把成本预算做高也是为了单位更多的效益(注:一般情况下
成本预算按比例便得到销售价)。4、在此讨论时,不用考虑销售项目经理的外部销售能力,只
讨论内部管理〉〉

【相关分析】

·加强学习,做好沟通!(2008-07-19) [作 者] 付现伟 [公 司] 上海贝连科技有限公司

1、学习:做为一个好的销售人员,本人以为要做好你需要提供产品的学习工作。无论是什么样的公
司或者项目,总是要有自己的技术内容的。所以销售经理应该一些常规的技术问题、标准、规范进行
学习,只有这样才能够更好的做好成本、利润的估算。
2、沟通:将用户的需求,产品的成本和利益,公司的发展战略跟部门领导进行认真、和谐的沟通,

第 532 页 共 756 页
第 7 章 成本与质量

让大家都能够理解和明白产品的成本点、公司的战略目标,使每一个人都能够知道再大的公司也是由
小的项目、生意而组合起来的,所以大家要齐心协力一直对外。
3、总之,其中还牵涉到了具体的执行方式和方法,当然要因人而异,我想作为一个销售经理的你,
做好沟通应该是最简单不过了!

·信心和勇气(2008-06-26) [作 者] JIANBENGUO [公 司] 河南石油安装工程有限公司

本案例先暗喻本人在企业地位中下,机遇不多,胃口不大或思路独特,总想踢开头三脚,相信相关部
门同病相连有之。况且企业界历来就有薄利多销之说;再说,任何企业在力所能及情况下,均不会有
骨头不啃吧?只要自己有信心,动员相关有志者共商大计,敢于负责,自组团队。完全可以走与他人
不同的路。

·最低成本,最佳质量(2008-01-15) [作 者] choose [公 司] 111

竞标中的地位有两种:最低成本,最佳质量。最低成本意味着你将把所有的水分弄清楚,挤掉,甚至
还要打折,之后才能占据的;最佳质量就是公司的质量保证能力和品牌了,为此你可以抬高价格,甚
至高得离谱。

·项目内部成本控制问题(2007-08-30) [作 者] tjh [公 司] cxgs

也认为这属于人与人,部门与部门之间的沟通问题,同时一个企业,没必要因为矩阵式管理而显得部
门之间有隔阂,沟通好了,商量一个合理得定价,一致对外较妥!
和谐发展!

·项目经理的沟通能力(2006-04-20) [作 者] 谢峰 [公 司] UAES

这需要项目经理的沟通能力,要走上层路线!

·开会(2006-03-02) [作 者] YYC [公 司] 天下互联

开会,这样的问题一定要开会,有个能压制住这样的风气的人出来,企业要发展不能这样,整体利益
上去了局部利益才能上去,这样给自己谋求私利的人能少几个少几个,实在不行拿几个开开刀

·项目内部成本控制问题(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

我也认为这属于人与人,部门与部门之间的沟通问题,同时一个企业,没必要因为矩阵式管理而显得
部门之间有隔阂,沟通好了,商量一个合理得定价,一致对外较妥!
和谐发展!

第 533 页 共 756 页
第 7 章 成本与质量

·用系统思考来揭穿谎言(2006-02-09) [作 者] 付勒 [公 司] 深圳市兰动数码科技有限公司

“他们把成本预算做高也是为了单位更多的效益”
请你揭穿这个美丽的谎言:
1。局部利益最大化,完全不等于整体利益同样最大,这和许多人的基本想法相违背,但是这是真理。
2。局部利益或许中饱私囊,造成了企业的腐败,企业战斗力是不能建立在腐败的私利者上的。
3。成本高了,竞标的竞争力会下降,久而久之市场获利能力会出现问题。
4。成本高,会引致内部成本的浪费,久而久之也会降低利润率。
5。客户也不是傻瓜,总有一天他们会明白,会让你在其他地方付出代价。
这样思考下去,从时间的纬度展开,你会看到的是繁荣还是泥潭?你可以用系统思考图勾勒出来,让
企业高层意识到这一点,高层会佩服你的高瞻远瞩。

·缺少致衡之法(2006-02-09) [作 者] 付勒 [公 司] 深圳市兰动数码科技有限公司

这个问题是有解的,原有的不合理是结构性的,体现在这些职能经理又管技术和设备内部招标,又参
与商务,这给予了他们可乘之机,自然造成与你希望的不同。
需要在公司层面设置类似与法律部的“采购价格关”,来致衡既得利益者,约束他们不要过于贪婪,
这个“关”是独立的、公正的、不会和既得利益者穿一条裤子的。
从这一点来讲,是属于公司政治。

·为何提交的内容不见了?(2006-02-09) [作 者] 付勒 [公 司] 深圳市兰动数码科技有限公司

为何提交的内容不见了?

·解决人民内部矛盾,寻找利益平衡点(2005-12-13) [作 者] 王海飞 [公 司] utstarcom通讯有


限公司

这种现象非常普遍,也非常的正常和合情合理。每个人都会为自己部门的利益最大化而努力,就像当
年共产党与国民党一样,即斗争又合作!因此应该同各部门进行充分的沟通,寻找大家都能接受的黄
金分割点。

·项目内部成本控制问题(2005-12-12) [作 者] 尚小鹏 [公 司] 保密

社会行为都是由人来进行的,从人的角度去解决问题往往要容易些。既然你明白其它各个部门的想法,
那么现在就不是某些技术和流程上的因素了,除了在平时和他们多多沟通和搞好关系外,可以和他们
中的有些人彻底的谈谈你的想法,那种公开式的开会类的形式是没有用的,在整个基础上可能比较容
易实现你的目的。还是沟通为本,关系其实是现有国情下的关键。

第 534 页 共 756 页
第 7 章 成本与质量

·平衡利益(2005-12-03) [作 者] 天羽 [公 司] 林源教育咨询

就补充说明部分而言,我理解是公司的利润要求是一个一刀切的指标,而各部门成本概算各有技巧,
你兼有技术和 PMP,能够弄清楚真实的成本。但是由此招来非难...事情到了这个时候,只能从平均
利润的角度来均衡,尽管是非标设计,任何部门都会有操作的习惯,都会有基本利润隐藏点,通常情
况下,利润会隐藏在“容易项”下面,否则项目风险极大。有鉴于此,你们销售部门可以均衡去年成
本概算的水分和固定资产增加与利用率等要素,对他们今年的利润进行均衡,可以促使部门按照长期
发展的模式来进行概算,从而降低当期的成本。

这样的情况,在国营企业里,只能够用一种财务方式进行协调解决。

·团队的利益很难平衡(2005-12-02) [作 者] 李治学 [公 司] 中国华电

其实共同利益是很难平衡的,就比如前两年人们想象的股份制企业一样,大家鼓吹的任何员工都成了
企业的主人,任何贪污回扣腐败等现象都不应该存在了,因企业的最终利益都是大家的。其实真真的
最终利润按股分摊在每个人身上也是极其有限的,所以何不趁自己的工作方便来赚取其他额外的收入
呢?这肯定比企业的年终分红大得多多多哦。。。。。

·形成共同的利益(2005-12-02) [作 者] 孙先平 [公 司] dragon company

如果能够将大家共同的利益定位在共同的利益上来,技术部门不是通过吃回扣来获得收益.而是通过
项目的最终收益来获得奖励!---这只是个个假设!
就公司内部矛盾,那本来就是一场政治,本身即游离在利益与名誉之间!

·项目内部成本控制(2005-12-01) [作 者] 李治学 [公 司] 中国华电

我在此再做一些补充:
1、 我公司所从事的是大型工程项目,每个项目都具有自己的独特性,在技术设计上都叫做非标设计,
因此,对于历史数据的参考价值是非常有限的。再者,我公司属于国营大企业,虽然要求每个项目的
利润水平一样,但每个项目的成本计算却比较混乱(涉及以上分析的多方因素)。
2、 对于每个项目的外部投标价格是根据成本预算价作出的,而该投标价格的评审表必须得各个部门
参与评审讨论最终签字确认的,并非是由销售项目经理自己出做的一个价格。

作为我本人而言:
1、 因为我做过两三年的技术工作,针对每个项目可以通过单位内部上下做工作并协调,跟技术部门
提出许多关于技术优化减少成本或提高工程进度的创新措施(因身在国营企业里,许多技术人员为了
不承担责任和风险,在做项目设计的时候根本不会去考虑创新)
2、 本人也做过两年的项目执行工作,也通过了 PMP,因此在执行成本预算价格上能作出较为实在的

第 535 页 共 756 页
第 7 章 成本与质量

价格,并且在开评审会的时候能拿出充足的理由和信心。
但因此而导致了技术部门和执行部门私下的一下怨言,请问究竟因该如何来平衡内部矛盾?
单位里销售部作为我这样的人毕竟是少数,对于其他不是很懂技术和执行的人员究竟又该如何来控制
成本?如何来做好销售工作?
(还是讨论单位内部问题)

·成本预设(2005-12-01) [作 者] 孙先平 [公 司] INFINITE COMPANY

分析一下,理一下思路:
1、竞标的价格公司是否有惯例?或历史参考数据,为了使自己处于一个更好的竞标地位,当然内部
成本能够降低会更好!根据你的情况,公司各相关部门对此类工程项目的预算是十分清楚的,不管他
们出于篡自身什么样的利益考虑。想从这里挤出水份是比较困难的,他们会有太多的理由来解释为什
么要这么高的成本预算了;
2、那只能从项目本身来讲,如果项目具有特异性,你本人也有相当的经验,做出一份合理的预算是
可能的;
3、预算应当是你来做,无非与各个部门之间打打乒乓球而已;最终的结果是博弈的结果:即相对合
理,又不得罪人(还得靠他们做事呢,呵呵)
4、预算不宜做提太实,要做出相对较大的余量,也给自己一个空间!
。。。。。。。。。。

·无解(2005-11-28) [作 者] 天羽 [公 司] 林源教育咨询

你们的组织结构不是强矩阵,只是形式上的类似。

各职能部门被放在了一个项目名称下面,实际上是成本中心管理,但是按你的描述可能是在采用利润
中心的模式。这就导致部门利益高于项目,但是执行的主体又不能聚集成一个真正的项目团队,这时
作为项目经理的你,其实根本不能控制这个成本,你只能按照你的惯例或是计算方法来报价,获取你
们销售部概念下的最大利润。

竞标中的地位有两种:最低成本,最佳质量。最低成本意味着你将把所有的水分弄清楚,挤掉,甚至
还要打折,之后才能占据的;最佳质量就是公司的质量保证能力和品牌了,为此你可以抬高价格,甚
至高得离谱。

换句话说就是:在没有利润和高利润间平衡你的心理素质。恕我直言,报价只跟你有关系,因为你预
设了限制条件。

第 536 页 共 756 页
第 7 章 成本与质量

7.5 项目工作量估计的困惑

项目工作量估计的困惑

[姓 名] 刘湘捷 [单 位] bjrun [邮 件] lxjie@263.net


[所属行业] IT 软件 [所属主题] 项目成本管理 [发布时间] 2005-3-11

【案例正文】
按照公司项目管理办法的规定,项目工作量是在用户需求确定后,由独立于项目的
核心技术小组(公司的技术专家组成)进行估计,然后确定下来,将这个估计的值
作为项目验收的依据之一,也就是说,项目经理不能再对工作量进行调整,只能按
照这个确定的工作量完成项目才算完成任务。
我的疑问有两个:
1、在用户需求阶段估计的工作量,即使是由技术专家来估计,是否能保证估计的
准确性呢?
2、项目经理和项目组成员是不是也应参与到项目的工作量估计中,而核心技术小
组只是作为指导和监督的角色?

不知各公司是如何规定的,请大家发表高见!

【相关分析】

·工作量估算(2008-05-10) [作 者] zhuangqm [公 司] sdrcu

项目经理及部分项目组成员是肯定要参与到项目的工作量估计的;技术专家在需求确定后展开工作量
评估是无法保证准确性的。

·项目经理的职责与团队的组成!(2008-04-07) [作 者] 董新山 [公 司] 佛山市顺德区雅富电子有限公


项目经理的职责是对项目的工作量估计!项目团队不仅是技术人员组成,还有其它部门组成。共同完
成项目!

·应该理解为一种定额(2008-01-24) [作 者] dajundalao [公 司] 暂时保密

这个问题其实应该理解为专家为项目确定了定额。这个定额可能是一个较理想的水平,它是为了避免
增加成本在内的诸多资源而定的。当然,既然是估计,就存在一定的偏差,只要在偏差范围内就可以

第 537 页 共 756 页
第 7 章 成本与质量

接受。
项目经理和项目组成员自己可以估计工作量,或是根据专家估计的工作量来比对自己的估计。这样起
到约束作用,贵公司的作法是值得推广的。这个做法的潜台词是:鼓励各位自己挖潜以提高效率!
企业是为效益为中心的,效益的好坏与效率密切相关。你好好努力吧!

·专家得出的结论有用吗?(2007-12-17) [作 者] daijiangbao [公 司] 深圳市大视野企业管理顾问有限


公司

既然是专家得出的结论,就应该让专家去做,开发人员没有必要撞专家的圈套
专家是什么?实际人人是专家,大可不必把专家天天挂在嘴上,爱因斯坦不是早就说过:“专家就是
懂技术的狗”,把狗的地位提那么高,能不出问题?

·项目工作量估计的困惑(2007-08-30) [作 者] tjh [公 司] cxgs

在总体任务的基础上,按照关键路径分析法,一定能够找到比专家组分析的更加准确的工作量及完成
时间进度表。

·项目工作量估计很难(2007-03-21) [作 者] 龙七 [公 司] AMDOCS

项目工作量估计很难,这个大家都认同.但是项目工作量估计对项目的成本、工期等都比较关键。现在
项目管理对工作量和工期的考核的要求比较的高。一般要求计划工期和实际工期比较接近。必须做好
的就是让你的估计比较的准确,这样实际的工期就和考核的标准接近。

·分析(2006-12-06) [作 者] 王颖 [公 司] 不妨边

即使是在具专业、专家性质的专家,也不可能把工程量估算的特别精确。因为他们有的只是理论上的
依据。而不是实际操作的人。所以我认为应该把实际参与的人员安排在评估小组里。而且项目管理里
有任务变更一项,变更任务我认为可以同时包含变更工作量。

·项目工作量估计的困惑(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

说实在,公司下达的任务,你只能去做,公司不会考虑人力资源的问题。我以为,如果给你配备足够、
合理的资源去做一个项目,说实在,这样的项目经理太多:所有条件都配备好了,你还做不好,只能
说明你无能;如果你做好了,是应该的。

·项目工作量估计的困惑(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

第 538 页 共 756 页
第 7 章 成本与质量

在总体任务的基础上,按照关键路径分析法,一定能够找到比专家组分析的更加准确的工作量及完成
时间进度表。

·项目工作量估计的困惑(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

1、首先,什么时候是用户需求的确定?这个直接影响到工作量的确定,因为用户通常都是在改变自
己的需求的,一旦出现反复,这个工作量是很难定量的。
2、专家的评估的思想路线应该是正确的,但是,工作量的多少并不完全取决于经验和思考路线,中
间存在的不确定性也会影响到这个工作量的多少!

·工作量估计的困惑(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

由项目团队制订项目计划,工作量在计划中体现,然后 PMO 组织相关部门、专家组进行评审,对工作


量一块经过一番讨价还价后双方签字确认,作为对项目团队的一项考核依据,从公司角度看是想尽量
创造一个公正考核的机会,希望员工工作量尽量饱和,在资源调配时有相对依据。

·项目工作量估计的困惑(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

专家们估算时应该有相应的依据、假设等条件,如果依据、假设等改变的话相应工作量应该也要进行
调整,这就要看项目经理的定期汇报程度了

·项目工作量估计的困惑(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

你公司制度比较完善,的确是个好事情.但纯粹依靠专家的意见确定进度表似乎过多依赖理论.项目中
出现意外事件是很常见的事情,对于问题的发现和及时改正都需要时间,所以时间的进度不能过分紧

·项目工作量估计的困惑(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

由你们公司的专家组针对具体项目估计出一个工作量(此项目所需的多少人工作日),也就是给了你
一个在特定条件下的期限

·项目工作量估计的困惑(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

谈到工作量估计,肯定会考虑范围管理,范围确定的内容肯定会严重影响工作的进展!

第 539 页 共 756 页
第 7 章 成本与质量

不管你的公司有什么样的专家,工作量的估计必须建立在范围的明确界定和具体的 WBS 分解上!


这些所有的工作项目经理都必须参与!

·项目工作量估计的困惑(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

项目管理是一门学科, 如果项目评估极极精确, 那实施项目就只属于技术人员的事情了, 项目管理


的重要性就无法体现.

·项目工作量估计的困惑(2005-10-22) [作 者] ricky [公 司] shanghai fuzhou

1、在用户需求阶段估计的工作量,即使是由技术专家来估计,是否能保证估计的准确性呢?
个人看法:
1)技术专家来估计是可行的,但我想技术专家应该估计的是按照需求,在 WBS 基础上估计的每一个
子任务的工时,不应该是
某个工作阶段的工作量;
2)项目计划和工作量是不同的,子任务的工作量只是项目计划的参考之一;
3)子任务是一个一个相对独立的块,而项目计划是一个相互联系的网络;
2、项目经理和项目组成员是不是也应参与到项目的工作量估计中,而核心技术小组只是作为指导和
监督的角色?
1)个人认为也是必要的,技术专家在估计子任务的时候可能是按照熟练工种来估计工作量的,但是
项目成员实际的能力和水平
和专家估计的依据是有差距的,所以项目经理和项目组成员可以进一步提高子任务工作量估计的准确
性;
2)项目计划的制定应该是以项目经理为主体,在充分考虑技术专家的意见和项目相关干系人的各种
利益基础上作出来的合理的计划。

·项目工作量估算不是项目实施时间!!!(2005-09-14) [作 者] 周景伟 [公 司] qn

这里面有以下几个需要注意的:
1、整个项目的进度,活动时间安排是项目经理和项目团队制定的,“谁负责谁来制定”的原则。
2、如果作为项目工作量估算可以有公司的专门部门来评估,没有问题,但是不是确定的,只能都参
考。最后整个项目的进度计划项目经理还需要考虑各中环境、资源的因素,制定出来。
3、项目计划一定要制定,因为好的项目计划不是简单的时间排序,而是一个项目资源的整合的过程,
这里面的内容就多了。“计划能够对行动起到有效的指导,依赖于对不确定性的正确评估和预测”

·考虑全面+长期积累+范围清晰+变更管理系统(2005-05-02) [作 者] 张彤 [公 司] 北京北大
金秋新技术有限公司

第 540 页 共 756 页
第 7 章 成本与质量

您提出的问题说明贵公司关于项目成本管理的机制还不够健全,其实在《项目管理指南》有关“成本
管理--成本估算”部分对您承担的项目的成本估算的的输入、工具和输出说的很清楚,请您发挥您作
为一个项目经理应该必备的影响组织的能力去影响您的组织,去改变贵组织的业务流程,预祝您成功。

·这种做法太理想化,只能做为大概的指导(2005-04-21) [作 者] 段丽娟 [公 司] 北京能博文


科技

项目和产品很多的不同就是项目过于依赖客户,弹性大,尤其牵掣到现场实施的情况,坐在办公室里
的人那里知道具体的情况到底是什么样子的?况且你这个时间期限还是在项目刚开始就要定出来,越
是在生命周期的前端,不可预知性越大!

我个人认为:

项目的进度计划是一定要的,而且这个计划不是一成不变的,而是要根据实际情况调整的!

工作量估算也是要有的,要保证一定的科学性,需要技术专家参与评定这也是必要的,但是这个不要
做为一个衡量项目成功的标准!

·这种做法太理想化,只能做为大概的指导(2005-04-21) [作 者] 段丽娟 [公 司] 北京能博文


科技

项目和产品很多的不同就是项目过于依赖客户,弹性大,尤其牵掣到现场实施的情况,坐在办公室里
的人那里知道具体的情况到底是什么样子的?况且你这个时间期限还是在项目刚开始就要定出来,越
是在生命周期的前端,不可预知性越大!

我个人认为:

项目的进度计划是一定要的,而且这个计划不是一成不变的,而是要根据实际情况调整的!

工作量估算也是要有的,要保证一定的科学性,需要技术专家参与评定这也是必要的,但是这个不要
做为一个衡量项目成功的标准!

·项目范围管理(2005-04-16) [作 者] GaoDapeng [公 司] 北京南天软件有限公司

谈到工作量估计,肯定会考虑范围管理,范围确定的内容肯定会严重影响工作的进展!
不管你的公司有什么样的专家,工作量的估计必须建立在范围的明确界定和具体的 WBS 分解上!
这些所有的工作项目经理都必须参与!

第 541 页 共 756 页
第 7 章 成本与质量

最后的结果还需要进行评审!!

·这种做法可取,但需要补充(2005-04-11) [作 者] 徐士元 [公 司] 天财通胜

首先,我认为公司的这种做法基本上是可行的。从公司经营者的角度考虑,由专家组而不是项目经理
确定工作量,一是避免项目经理出于个人或小团体的利益虚报工作量;二是避免因项目经理个人能力
和经验不足错估工作量。由有经验的专家组集体研究,可以在很大程度上避免上述因素导致的失误。
其次,我认为这种方法有其弊端。最大的可能就是如前面各位朋友提到的那样,因为客户需求的变动
而导致原定工作量不准甚至严重不准。另外,很多需求分析阶段无法确定的因素都可能造成影响。
作为补充,我认为以下几个环节是比较有用的:
1、项目组应该先提出工作量估计和进度计划,供专家组参考;
2、专家组做出估计时,应出具书面报告,明确做出估计所依据的需求,细化各部分的工作量估计,
以及对于可能出现的变数的应对意见。
3、对于在开发过程中遇到的无法预期的变数,应由项目经理做出变动意见,召集专家组评审,及时
调整计划。

·这种做法可取,但需要补充(2005-04-11) [作 者] 徐士元 [公 司] 天财通胜

首先,我认为公司的这种做法基本上是可行的。从公司经营者的角度考虑,由专家组而不是项目经理
确定工作量,一是避免项目经理出于个人或小团体的利益虚报工作量;二是避免因项目经理个人能力
和经验不足错估工作量。由有经验的专家组集体研究,可以在很大程度上避免上述因素导致的失误。
其次,我认为这种方法有其弊端。最大的可能就是如前面各位朋友提到的那样,因为客户需求的变动
而导致原定工作量不准甚至严重不准。另外,很多需求分析阶段无法确定的因素都可能造成影响。
作为补充,我认为以下几个环节是比较有用的:
1、项目组应该先提出工作量估计和进度计划,供专家组参考;
2、专家组做出估计时,应出具书面报告,明确做出估计所依据的需求,细化各部分的工作量估计,
以及对于可能出现的变数的应对意见。
3、对于在开发过程中遇到的无法预期的变数,应由项目经理做出变动意见,召集专家组评审,及时
调整计划。

·看法:成员与专家一起进行商讨(2005-04-11) [作 者] 林辉鸣 [公 司] 广州赛意

由于具体进行工作的是项目组成员,而由专家订下的计划往往是从自己的角度出发考虑的,对于具体
到每个人的情况,不可能都考虑的到的。
项目成员和专家一起进行制定项目的进度,第一,项目成员自己需要考虑的条件有机会提出来,专家
在制定计划的时候可以切合项目成员的实际情况。第二,项目成员参与制定计划,同时也是对项目成
员一种无形的监督,督促项目成员按时完成计划。

第 542 页 共 756 页
第 7 章 成本与质量

·换位思考(2005-04-06) [作 者] 至尊月 [公 司] 项目管理部

领导都希望自己对公司的每个项目有个比较良好的了解,至少希望知道工作量大概多少。他们组织专
家评估总比拍脑袋强!
我个人认为,专家评估不能少,你们自己也可以在项目组内进行一次工作量的评估,找出和专家评估
之间的差距,根据差距再和领导或者评估小组交流。有些事不是说只能去做一次,做 2 次评估也没有
什么不可以。你要你能找出其中的差距,相信领导都不是傻子,都会想办法帮你解决你说的差距的。
我支持专家和项目成员都参与评估的办法。
如果不行,就做 2 次评估吧。总比完不成任务强!
制度是死的,人是和的,灵活运用和完善才是管理人员需要做的!

·项目工作量的估计(2005-04-03) [作 者] 楼洪伟 [公 司] 杭州奥通科技有限公司

作为项目工作量估计:
评估工作组人员组成:专家,项目经理
评估内容:项目需求即你的项目首先要有一个明确的目标,即在什么时候需要完成,根据目标时间,
我们再把项目详细分解,由专家组确定每项任务完成所需要的资源及时间。分解后,就需要你项目经
理去组织实施,平衡人力资源分配。在总体任务的基础上,按照关键路径分析法,一定能够找到比专
家组分析的更加准确的工作量及完成时间进度表。

·项目工作量的估计(2005-04-03) [作 者] 楼洪伟 [公 司] 杭州奥通科技有限公司

作为项目工作量估计:
评估工作组人员组成:专家,项目经理
评估内容:项目需求即你的项目首先要有一个明确的目标,即在什么时候需要完成,根据目标时间,
我们再把项目详细分解,由专家组确定每项任务完成所需要的资源及时间。分解后,就需要你项目经
理去组织实施,平衡人力资源分配。在总体任务的基础上,按照关键路径分析法,一定能够找到比专
家组分析的更加准确的工作量及完成时间进度表。

·项目评估的精确度, 对项目成败影响多大?(2005-03-31) [作 者] 庾光日 [公 司] -

项目管理是一门学科, 如果项目评估极极精确, 那实施项目就只属于技术人员的事情了, 项目管理


的重要性就无法体现.
项目管理的魅力就在于他的不确定性, 项目经理应该在项目实施过程中能够及时分析出潜在危险因
素, 并协调各方力量去排除. 项目评估在项目的成败虽然重要, 因为影响项目的不确定因素的存在,
所以如果一定要达到精确, 则反而会有更大的偏差...
我认为, 项目评估通过部分的技术精英组成的小组足以...
项目经理不能对工作量进行调整也是误区, 在保证在规定的时间(交货期)内, 在预定的成本(价格)

第 543 页 共 756 页
第 7 章 成本与质量

下, 完成项目, 并且获得项目验收(质量)的前提下, 获得最大的权力...

·个人看法(2005-03-31) [作 者] 马吉林 [公 司] 英科新创

1、首先,什么时候是用户需求的确定?这个直接影响到工作量的确定,因为用户通常都是在改变自
己的需求的,一旦出现反复,这个工作量是很难定量的。
2、专家的评估的思想路线应该是正确的,但是,工作量的多少并不完全取决于经验和思考路线,中
间存在的不确定性也会影响到这个工作量的多少!
3、就是你的第二条,我比较赞同。应该说,自己做的工作自己最了解工作量,当然,也不能完全排
除项目成员会故意高估工作量。让项目经理和项目成员先粗算一下自己的工作量,然后提交专家组进
行评审。同时在工作量评审报告中要注明留的工作余量是多少!这样比较合适!

·计划者与执行者之间的关系(2005-03-18) [作 者] 欧阳永辉 [公 司] 上海梅林食品有限公司

项目管理只是一种行为科学,他不可能提供一个很精确的答案,同一个项目给不同的人来作计划,作
出来得计划肯定是不一样,由专家来估计项目的资源和时间进度有一定的参考性,但是这样的计划书
必须得到项目经理和项目成员的认可,方可成为最后的验收基准,否则最多只能算是一个模版

·你们确定的工作量,就是工作的期限!(2005-03-18) [作 者] 赵宏伟 [公 司] 东信北邮

由你们公司的专家组针对具体项目估计出一个工作量(此项目所需的多少人工作日),也就是给了你
一个在特定条件下的期限!
1,任何一种估计预算总是有出入的,在项目的进行过程中肯定会有一些突发事件让调整工作量(进
度的安排),
2,或许你们公司的专家组的职责本来比较多(一职多能),除了指导监督的角色还有规划/整体安排
的职责, 针对项目的工作量(工程进度的要求),项目经理和相干系人是尽可能都参加来! 这是个
很好的建议

·换位思考(2005-03-14) [作 者] 罗建军 [公 司] 上海理想信息产业有限公司

如果大家可以进行换位思考,也许多大家的工作会有一定的帮助。

很多项目经理总是觉得自己的工作就是工作,是非常重要的。当公司上层要求做一些可能会影响项目
进度的事情时(也许项目经理这么认为,公司领导不一定这么认为),总是有抵触情绪。其实换一种角
度考虑,如果每一个人,都让自己的上级“爽”了,一方面有利于公司整体利益的提高,另一方面有
利于你的升迁。

第 544 页 共 756 页
第 7 章 成本与质量

当然,这是假设上级的决定总是对大局有利的前提下。现实情况下,人们通常都有“本位主义”。总
是从自己的角度来考虑事情。往往会局部赢了,但大局输了。你的上级,看问题的层面通常来说会比
你高一些。如果你能支持他,对公司而言是好的(也许对你的项目不利,这需要你去沟通好)。

ps:
to bomber aaa bomber2002@163.com
你说到:

“我们曾经是这样做的:由项目团队制订项目计划,工作量在计划中体现,然后 PMO 组织相关部门、


专家组进行评审,对工作量一块经过一番讨价还价后双方签字确认,作为对项目团队的一项考核依据,
从公司角度看是想尽量创造一个公正考核的机会,希望员工工作量尽量饱和,在资源调配时有相对依
据。但光从工作量角度看是否真正体现公正了呢?不一定,我认为与公司价值趋向有关,但作为一个
监控的参考指标我认为还是相当有意义的。”

我对这一块非常有兴趣。能否探讨一下?
因为,我正打算在公司内实行这个办法。
你说,“曾经是这样做的”。那现在是怎么做的呢?
为什么放弃原先的做法?原先做法有何不妥吗?
多谢!

ljjsoft@126.com

·一些偏激的意见(2005-03-13) [作 者] 王梦龙 [公 司] xx技术股份公司

第一:技术专家对工作量的估计经常是正确的,并且是经常准确的,但是,同志,用户的需求是确定
的吗?你认为用户能够对需求确定几次?我以为,用户最起码能够对已经确定的需求再次确定 3 次以
上没,即使最厉害的专家对此无法把握。因此,首先,你认为由技术专家估计精确的工作量的意义有
多大?技术专家有多大的把握能够让用户的需求冻结?项目经理的能力有多大?
第二:如果核心小组能够准确的估计工组量,还需要项目经理和项目组成员如果去的估计工作量吗?
吃撑了可以这么做。反过来,如果核心小组不能准确估计工作量,总得有人估计工作量。我的意思是
说,让能准确估计工作量的人估计工作量,让不能准确估计工作量的人滚蛋,也就是说如果项目经理
能力足够,工作量的估计就让项目经理去做。其实我以为,您提的问题肯定是涉及个人利益了。
第三:其实很简单,谁有能力就让谁做。通用的准则与规范不一定适合每个公司。常规情况下,应该
因岗定人,有时候因人定岗也不一定错。世界上例外的事情还是有些,譬如,bill gates 比 50 岁的
人更富有,这个事实必须承认。
第四:目的是什么?谁的目的是什么?大家的目的是什么?个人的目的是什么?目的是否统一才是最
关键。
第五:说实在,公司下达的任务,你只能去做,公司不会考虑人力资源的问题。我以为,如果给你配
备足够、合理的资源去做一个项目,说实在,这样的项目经理太多:所有条件都配备好了,你还做不

第 545 页 共 756 页
第 7 章 成本与质量

好,只能说明你无能;如果你做好了,是应该的。
第六:如果你认为核心小组让你不舒服,其一,你想办法进入核心小组,其二,成为核心小组的头。
到时候,认为不合理的是项目经理,而不是你,因为你已经不是项目经理了,当然,前提是你的能力
足够使你成为核心小组的头。
第七:如果我胡说,你骂我;如果我没胡说,也可以骂我。

·公司这样做的目的是什么?(2005-03-11) [作 者] bomber [公 司] aaa

曾经也做过类似的规定,不过没这么死板。

我们曾经是这样做的:由项目团队制订项目计划,工作量在计划中体现,然后 PMO 组织相关部门、专


家组进行评审,对工作量一块经过一番讨价还价后双方签字确认,作为对项目团队的一项考核依据,
从公司角度看是想尽量创造一个公正考核的机会,希望员工工作量尽量饱和,在资源调配时有相对依
据。但光从工作量角度看是否真正体现公正了呢?不一定,我认为与公司价值趋向有关,但作为一个
监控的参考指标我认为还是相当有意义的。

从项目经理角度看我倒觉得无所谓好坏,关键要搞清楚公司这样做的用意。

工作量的估算原则上由项目团队估,项目团队人员水平经验的高低,信息获取的不对称性,与专家估
算的肯定是有差距的,毕竟不是专家们自己去做,当然这也与公司的业务背景有关,有些重复性非常
强的项目,公司如果这样做我认为还是有道理的。
从广义项目概念看,若项目团队不参与工作量确定,个人认为不妥,但作为项目经理其实还是有机会
的,专家们估算时应该有相应的依据、假设等条件,如果依据、假设等改变的话相应工作量应该也要
进行调整,这就要看项目经理的定期汇报程度了,说白了就看项目经理的沟通能力了。

·一家之言(2005-03-11) [作 者] fff [公 司] dci

工作量的估计一般只能靠经验,一个开发任务我会认为三个月才能完成,没有经验的人可能会说一个
月完成。目前最好的方法是建立项目跟踪数据库,掌握的项目跟踪数据越多越精确,工作量的估计就
能越准确

·一家之言(2005-03-11) [作 者] fff [公 司] dci

工作量的估计一般只能靠经验,一个开发任务我会认为三个月才能完成,没有经验的人可能会说一个
月完成。目前最好的方法是建立项目跟踪数据库,掌握的项目跟踪数据越多越精确,工作量的估计就
能越准确

·共同参与(2005-03-11) [作 者] 梁桢 [公 司] 上海广平信息系统工程有限公司

第 546 页 共 756 页
第 7 章 成本与质量

你公司制度比较完善,的确是个好事情.但纯粹依靠专家的意见确定进度表似乎过多依赖理论.项目中
出现意外事件是很常见的事情,对于问题的发现和及时改正都需要时间,所以时间的进度不能过分紧
凑.

项目经理对项目负责,所以有必要实现同项目组成员事先制订进度表,然后作为参考给专家,这样能调
动项目成员积极参与的能动性,而不让其感觉是机器,更能培养团队的整体能力.项目经理不是工头,
需要提出自己的看法.

7.6 如何使双方的项目团队协同工作

如何使双方的项目团队协同工作

[姓 名] 缪开 [单 位] 波导公司信息工程部 [邮 件] mk@mail.nbbird.com
[所属行业] 综合应用 [所属主题] 项目成本管理 [发布时间] 2004-2-20

【案例正文】
我是一个 ERP 系统开发项目的项目经理,目前是和另一个合作伙伴一起进行这个项
目,我方主要负责系统分析,开发。对方主要负责业务需求分析,实施是双方一起
共同合作进行的。

目前项目处于业务需求阶段,但我发现对方的业务能力比我想像的要差,对 ERP 的
管理理念不清,故很难进行业务分析,所以业务分析的工作就自然落在了我方的头
上,这就出现了这样的情况,我方的项目人员日夜兼程的疯狂工作,而对方却帮不
上什么忙。团队的合作就将会出现问题。

故请大家分析,在这种情况下,项目组该如何协调工作。注:双方不在同一个地方
工作。

【相关分析】

·suopei(2007-04-29) [作 者] 119922 [公 司] 河北

一个 ERP 系统开发项目的项目经理,目前是和另一个合作伙伴一起进行这个项目,我方主要负责系
统分析,开发。对方主要负责业务需求分析,实施是双方一起共同合作进行的。

第 547 页 共 756 页
第 7 章 成本与质量

目前项目处于业务需求阶段,但我发现对方的业务能力比我想像的要差,对 ERP 的管理理念不清,


故很难进行业务分析,所以业务分析的工作就自然落在了我方的头上,这就出现了这样的情况,我方
的项目人员日夜兼程的疯狂工作,而对方却帮不

·是双方一起共同合作进行的。(2007-04-29) [作 者] 119922 [公 司] 河北

我是一个 ERP 系统开发项目的项目经理,目前是和另一个合作伙伴一起进行这个项目,我方主要负


责系统分析,开发。对方主要负责业务需求分析,实施是双方一起共同合作进行的。

目前项目处于业务需求阶段,但我发现对方的业务能力比我想像的要差,对 ERP 的管理理念不清,


故很难进行业务分析,所以业务分析的工作就自然落在了我方的头上,这就出现了这样的情况,我方
的项目人员日夜兼程的疯狂工作,而对方却帮不上什么忙。团队的合作就将会出现问题。

故请大家分析,在这种情况下,项目组该如何协调工作。

·个ERP(2007-04-29) [作 者] 119922 [公 司] 河北

一个 ERP 系统开发项目的项目经理,目前是和另一个合作伙伴一起进行一个 ERP 系统开发项目的项


目经理,目前是和另一个合作伙伴一起进行这个项目,我方主要负责系统分析,开发。对方主要负责
业务需求分析,实施是双方一起共同合作进行的。

目前项目处于业务需求阶段,但我发现对方的业务能力比我想像的要差,对 ERP 的管理理念不清,


故很难进行业务分析,所以业务分析的工作就自然落在了我方的头上,这就出现了这样的情况,我方
的项目人员日夜兼程的疯狂工作,而对方却帮不上什么忙。团队的合作就将会出现问题。

故请大家分析,在这种情况下,项目组该如何协调工项目,我方主要负责系统分析,开发。对方
主要负责业务需求一个 ERP 系统开发项目的项目经理,目前是和另一个合作伙伴一起进行这个项目,
我方主要负责系统分析,开发。对方主要负责业务需求分析,实施是双方一起共同合作进行的。

目前项目处于业务需求阶段,但我发现对方的业务能力比我想像的要差,对 ERP 的管理理念不清,


故很难进行业务分析,所以业务分析的工作就自然落在了我方的头上,这就出现了这样的情况,我方
的项目人员日夜兼程的疯狂工作,而对方却帮不上什么忙。团队的合作就将会出现问题。

故请大家分析,在这种情况下,项目组该如何协调工方一起共同合作进行的。

目前项目处于业务需求阶段,但我发现对方的业务能力比我想像的要差,对 ERP 的管理理念不清,


故很难进行业务分析,所以业务分析的工作就自然落在了我方的头上,这就出现了这样的情况,我方
的项目人员日夜兼程的疯狂工作,而对方却帮不上什么忙。团队的合作就将会出现问题。

故请大家分析,在这种情况下,项目组该如何协调工

·能力盲目(2007-04-29) [作 者] 119922 [公 司] 河北

第 548 页 共 756 页
第 7 章 成本与质量

你会出现你这种状况,我认为有以下原因:
1,合作伙伴的选择:没有充分的考察了解合作者(也可以叫供应商面的能力盲目的合作(也许合作
伙伴的选择出现是强加的);
2,合同的签订:由于涉及到具体的技术问题,既然是合作伙伴就应该在合同里写明具体的相关负责
人以及必须具有的相应的技术能力和经验;
3,项目的范围:你目前的日夜加班的情形所做的已经是超出项目范围的事,对你自身的工作来说没
有意义,没有按合同做事;
4,合同的变更控制:当发现问题的时候没有进行合理的合同变更,而是一味的做自己认为正确的事。

所以,对于这种情况,经应该重新的衡量合作伙伴,制定新的合作计划(合同)。

·个人意见(2007-02-03) [作 者] HSP [公 司] secret

你的项目会出现你这种状况,我认为有以下原因:
1,合作伙伴的选择:没有充分的考察了解合作者(也可以叫供应商)的相关反面的能力盲目的合作
(也许合作伙伴的选择出现是强加的);
2,合同的签订:由于涉及到具体的技术问题,既然是合作伙伴就应该在合同里写明具体的相关负责
人以及必须具有的相应的技术能力和经验;
3,项目的范围:你目前的日夜加班的情形所做的已经是超出项目范围的事,对你自身的工作来说没
有意义,没有按合同做事;
4,合同的变更控制:当发现问题的时候没有进行合理的合同变更,而是一味的做自己认为正确的事。

所以,对于这种情况,经应该重新的衡量合作伙伴,制定新的合作计划(合同)。

·分析(2006-12-06) [作 者] 王颖 [公 司] 不妨边

既然是合作关系,你们的责权应该在合同里表示的很清楚了。如果出现这种严重影响工作的问题,就
要那合同说事儿了。但翻看,你对夜以继日的工作,肯定也是由问题的。你们不在同一地点办公,即
使你们在辛苦对对方来讲一点意义也没有。而且对你们的工作也起不到改善的作用。想一个可以彻底
改变他们的方法,要不然就放弃合作关系。

·按合同要求,明确双方工作职责(2006-11-24) [作 者] xu [公 司] 8

首先看看项目合同内容中,双方的职责分工是否明确。如合同明确由对方负责需求分析,则要求对方
的工作质量要达到合同要求的标准,如不行,可要求对方更换项目人员,或由你们接替其部分工作,
签订补充协议,重新明确双方工作范围、工作职责。

·既然是合作伙伴,那就应该有合作合同!(2004-03-22) [作 者] 赵宏伟 [公 司] 东信北邮

第 549 页 共 756 页
第 7 章 成本与质量

这个 ERP 的项目的这种合作 更像是公司内部不同项目相干系人的不同分工而已,并不应该和公司外


部进行合作的关系,
既然是同一个项目的团队,那就应该有一个项目领导者, 对于不合格的人员进行剔除,或者合作合
同结束,都有自己一方来完成!!

这个在人力资源的召集过程中就应该好好把好人才关,把合作对象的关!!

·我是新手(2004-03-20) [作 者] 123456789 [公 司] 昆明理工大学

首先我感觉这是一个比较复杂的问题
其次,对于这样的问题,要对所做的项目重新做一次计划,根据对方开发人员的水平,他们能作什么就
让他们做什么,我想他们应该不会什么都不作把(那要他们干什么?)
还有,你们是异地工作,所以沟通一定要做好,选择相应的工具,制定相应的共同规则!

·沟通渠道(2004-03-10) [作 者] 萧郎 [公 司] 吉林大学

我认为应该建立一个良好的沟通渠道,保证双方能够在信任的基础上直接而有效的沟通.

·分析各自优势,进行有效分工(2004-03-04) [作 者] 彭桃平 [公 司] 杭州中佳实业投资有限


公司

合作项目,不能要求合作对象也能在所有的方面都和你们一样的高;为什么合作,无非就是互补才有合
作的可能.
也许当初贵公司选择他们的时候,根本就没有考虑他们的技术实力,而更多的是考虑他们的其他能力.
如此,分析好合作之初的理由,做好双方优势互补的衔接点,合理的进行分工,这样才能达到协作共进
的目的.

·免费培训ERP(2004-03-01) [作 者] 小米 [公 司] 软件系统公司

给他们洗脑,增加 ERP 理念,同时也沟通感情,免费培训他们愿意参加吗?

·要团队,也要项目.(2004-02-28) [作 者] 周刚 [公 司] 北京大兴建筑工程总公司

项目合作也形成,在对方没有完全散事时,必须对项目负责.有两种方案可参考,一.对合作伙伴进行必
要的培训,让它达到我们需要的程度,二.对项目的收益分成进行重新划分.

第 550 页 共 756 页
第 7 章 成本与质量

·认识双方的责任!(2004-02-24) [作 者] 马渊鸿 [公 司] 安徽朗天

1。负责业务的一方是否有能力处理客户业务需求分析工作,如果没有,就要和业务方谈妥,软件开
发方处理业务需求分析的工作,但利益分配要从新配置,要让业务方知识客户业务需求分析对软件开
发过程中的重要性,如果需求分析不准确或不清楚,都会给开发人员带来很大麻烦,影响项目进度!
2。加强对 ERP 业务需要分析的相关培训以及对企业内部流程的了解,做为软件开发方,也应该有业
务主动去了解企业内部情况,加强沟通和理解!

·合作关系的分析(2004-02-24) [作 者] 王飞 [公 司] basicsoft

合作伙伴总是利益共享,责任共担的。具体是谁干多干少,只要老板认为这个项目有利可图就足够了。
合作的方式也多种多样。还要看是长期还是短期的合作。如你所说,我想可能不是工作上的一种合作
关系,应该是业务上的合作关系。他们拿单,你们来做。实际,他们多在参与与客户打交道的工作。
这个我想有他们的考虑之处。对于角色的定位,我想不仅是所从事的工作及能力的问题,还有客户的
把握及长期发展的问题。这就看老板的意思了。但如果从大局来考虑,你们应该多从事与项目开发相
关的工作,而他们应该多从事与客户关系协调的工作(需求变更的协调、实施及维护等等),这样更
有利于项目的进展。因为项目已经开始了,合同应该是签了吧,任何一方的怠工都会造成违约的责任。
现在再做责任和角色重定位可能会难一些,而且意义也不会太大了,但如果遇到违反一些预定的事情
(像你说的需求设计也变成你们来做了),我想还是应该及时把信息反馈给你的更高层,让领导来协
调这些问题,毕竟作为 PM 来讲很多事是无能为力的。这种合作关系有它的价值所在,专业的销售公
司,专业的软件公司,可以形成一个简单的产业链。只是现在有些不规范而已。最后祝你们项目成功!

·合作有时不仅仅是工作能力的合作(2004-02-23) [作 者] 华琰 [公 司] 用友公司

在该合作中,对方主要负责业务需求分析,但是对方却“对 ERP 的管理理念不清,故很难进行业务分


析”,那么就合作本身而言,对方似乎没有什么作用。
但是不知道你有没有考虑过,你们为什么会选用这样一家合作伙伴?
据我所知,有很多单位,做关系很有一手,往往由他们来接项目,然后跟一家有开发能力的企业合作
完成单子。实际上就是他们接项目,拿提成。
也许你们的合作伙伴就是这样产生的。存在就是合理的,你们有这样一家合作伙伴,应该是由其道理
的。所以,也许你们只好多受累了。

·目前的状态(2004-02-23) [作 者] 缪开 [公 司] 波导公司信息工程部

职责分工是有的,对方做业务蓝图分析,我们做系统分析,代码开发,然后一起对典型企业进行实施,
但由于对方的能力问题,使我们的业务蓝图阶段无法按照进度完成,这时我方出于对项目的负责,才
不得已出手进行业务蓝图分析,才出现了案例所说的情况。

第 551 页 共 756 页
第 7 章 成本与质量

·合作的项目比较多,有些感触。(2004-02-22) [作 者] 张谨 [公 司] 某电信公司

1、在中国,全面而深入的合作有时候是奢侈的事情。企业的生存之本在于利润,利润是由项目管理
相关要素决定的,沟通是要成本的。就项目而言,越简单的生意模式越值得提倡。
2、客户关系是绝对有价值的。客户的眼睛是雪亮的(合作伙伴有业务需求分析的权利,说明了他们的
价值。项目经理的能力要求是多方面的,恐怕不是技术能力强就可以搞定一个单子的哟)
3、我不赞同“只有永恒的利益,没有永远的朋友”的说法,但是合作时确实要确认双方的高、中、
基各个层面都充分了解在一段时间内是合则两利,分则两伤的。
4、伙伴是可以培训的,但工夫要下到才行。平时工作要靠对方的基层人员去协助你。
5、异地沟通,多采用混遍方式,宁可将亲和力很好,技术一般的人派出去,也不要找一个不会笑,
不会管理的技术大师过去和伙伴交流。
6、技术层面有些方法可以加强协调,不在这里说了,可以 MSN 交流一下。

·如何使双方的项目团队协同工作(2004-02-21) [作 者] 王栋 [公 司] 安捷食品运输有限公司

这个问题简单的说,就是你们是制造的,他们是给你们找客户的,或者是了解某种市场需求的。企业
资源计划(ERP)系统是一套统筹管理企业内部所有部门的集成式信息系统。它所强调的是对供应链的
管理和整合,即不仅仅注重企业内部资源的管理,更注重由供应商、企业自身和客户所组成的供、产、
销链条上的物流、信息流和资金流的管理。
然而他们对 ERP 的管理理念不了解,这对你们的系统分析与开发不但没有帮助,甚至还会拖累你们 ,
给你们造成不必要的麻烦。这已经破坏了合作的意图,如果继续下去对你们没有任何好处。
本人认为:第一,你们必须和他们进行会谈,让他们寻找出对 ERP 了解而且能胜任原来任务的人继续
和你们合作。并且给你们外加的劳动进行补偿。因为这是公平的。但为了避免引起以后合作的不愉快,
补偿这方面可以凿情考虑。第二,如果他们还是和原来一样以逸待劳,你们辛苦的工作,他们在一边
瞎看,那你们可以根据合同进行必要的协商,或者请高级管理者进行违约处理,然后另外寻找合作伙
伴。
但这只是一般的处理方法,如果是我,我觉得这个合作伙伴已经没有合作下去的必要了。应尽快寻找
新的合作伙伴,而且要吸取原来的教训,在寻找合作伙伴前应了解他对这方面的知识是否过硬,是否
能完成 ERP 的业务分析。

·如何使双方的项目团队协同工作(2004-02-20) [作 者] 杨明常 [公 司] 东营邦润石油科技有


限责任公司

ERP 项目我知道的不多,合作伙伴的选择非常关键,合作伙伴的主要职责不知道是否明确?他是否仅
是一个联系人或协调人?但是,ERP 项目的开发主要的需求分析合作对象不是你的合伙人,而是你所
要服务的企业,他们才是你项目真正的合作伙伴,而你的合伙人只是一个联系人而已!!!

第 552 页 共 756 页
第 8 章 团队管理

第8章 团队管理

8.1 *如何组织运用项目的人力资源

导读:组织规划指确定、记录与分派项目角色、职责与请示汇报关系。角色、职责和请示汇
报关系可以分派给个人或者集体。这些个人与集体可以是项目实施组织的一部分,也可以来
自组织外部。在多数项目中,组织规划大都是作为项目早期阶段的一部分进行的。但在项目
的整个过程中都应对其结果定期检查,以保证其继续适用性。如果当初的组织规划已不再适
用,就应该及时对其进行修改。

(一)案例正文

我们公司上了一个新项目,现在常常遇到类似的问题:当去寻求项目组外其它人的意见时,
总是遭到抵触或不愿合作的情绪;请教该如何处理?

感觉到以下几点是失误之处:
1、在项目组成立时,没有包含一些经验丰富、职位又比较高的人;
2、在实施过程中,总围绕着老外的意见转;没有很关注到本厂班组长和部门经理的建议,
所以很难得到他们积极的支持。 http://blog.mypm.net

3、项目组成员之间的交流也不够,很多东西只是某个人知道,这样就存在问题:一是个人
的思路总是很受限制,阻止了专家建议的进入渠道,所以得出的方案很可能不是很合理;二
是项目不是很稳固,抗变化的能力不是很强。
4、现在,项目已将近做了一半,再让新人参与进来,很多问题他都得从头了解;所以现在
出现了很被动的局面,项目在蹒跚中行进;只要出现问题,总得找老总出面。
以上浅见,请诸位大师指正并给出高见。

(二)专家点评

赵巍 管理科学与工程硕士,PMP、神州数码(中国)有限公司金融事业本部项目总监,原
ITS 集团项目管理中心副总经理。曾负责神州数码项目的监控,管理项目监理,是执行神州
数码 IT 服务项目管理流程的责任人,发表了项目管理相关论文 10 余篇,对知识管理和项
目办公室,战略项目办公室,改变组织文化等方面有资深经验。目前主要负责神州数码金融
事业本部相关项目的管理工作。

赵巍点评:非常难能可贵,你意识到了如此多的问题的原因,说明你是一个非常注重总结经
验和分析导致问题的原因。总的感觉是你的项目缺少合适的资源,没有很好的沟通。我这里
主要谈几点感受:

1.如何解决资源不足的问题:

第 553 页 共 756 页
第 8 章 团队管理

过细的资源规划。项目组人力资源的组织和应用是项目成功非常关键的环节,众所周知,项
目的基本单位就是人,没有合适的人,就很难成功。因此项目的人力资源规划在项目中就显
得非常重要。作为项目经理,在项目初期制定项目计划的时候,必须对项目有充分的认识,
项目有哪些工作,需要什么样的资源,在项目的整个生命周期,资源是如何配置的,也就是
说要想在项目中能够有效地使用人力资源,必须进行“过细”资源计划。对于一些高端的人力
资源必须尽早锁定。

利用公司领导的职位权力获得资源。对于你认为非常重要的项目,你可以把公司的某位高层
领导作为项目领导小组的组长,通过他的“职位”权力来获得你意想不到的资源。但是这种方
式有时候要慎用。

通过交换获得资源。大家都知道,项目经理应该具备沟通的能力、谈判的能力,几乎每个项
目经理都会认为自己的项目非常紧张,需要更多的人来帮助工作。项目经理通过“物-物”交
换的方式,将自己项目组不需要而其他项目组需要的人员交换出去,把自己需要的资源交换
近来。这种方式有时会起到意想不到的效果。

通过招聘获得资源。提前预见到项目对资源的需要,提前提出资源需求,通过人力资源部获
得自己需要的资源。

2.如何改善沟通

沟通是项目和谐发展的基础,项目干系人的管理很重要的内容就是沟通管理。在神州数码强
调项目组项目启动有启动会,每天早上有晨会,每周由周例会,每月有月例会,项目阶段点
要邀请项目组、客户、相关部门召开里程碑会议。会议不在时间,关键在效率。通过有效的
会议管理和书面报告机制,让大家的利益、目标、语言趋同,以获得共同的努力。

3.用开放的思路来使用新人。

不要低估新人的力量,如果不使用新人,当你还有新项目时,也许他还是新人,你还会感觉
到资源不足。作为项目经理,培养人才和完成交付同样重要。

(三)项目管理者联盟网友分析

分析 1:一些见解 作者:陈跃武

本案例中说到“只要出现问题,总得找老总出面”,可以看出项目是可以等到领导的支持的。
现在项目也到了中期,而且也发现了存在的问题,采取一些补救的措施还是来得及的。
从总体来说,可以在老总的支持下组织一个临时委员会(委员的成员至少要包括老总、项目
经理、本厂班组长和部门经理以及其他经验丰富职位又比较高的人)来针对目前存在的问题
进行分析讨论,并最终达成共识。 本文转自项目管理者联盟

项目不稳固就需要找出根本的原因,是因为利益问题还是关键技术问题等。
新人的加入在很多大中项目的执行过程中是很正常的,这就需要项目的文档要规范化。
至于沟通,我想应该是项目经理没有主动与项目组成员进行沟通或没有去营造一种沟通的环
境,所以在这方面需要项目经理加强沟通管理。

第 554 页 共 756 页
第 8 章 团队管理

分析 2:re: 作者:aoxiang

1、只要出现问题,总得找老总出面:这看来是不正常的,这与管理学中的例外原则相悖,
正如楼上所说,建立一个临时委员会或者支持委员会,吸收相关人员参与,当然,这个组织
的成员是老总授权的。
2、再让新人参与进来,很多问题他都得从头了解:这是必然的,这个一个项目团队的建设
问题,本身就是个临时性的组织,成员的流动是正常的,可以采取规范机制如沟通方式制度
化等方式。
3、很到东西只是某个人知道:这好像很麻烦,这样的情况下,知识集中于某个人身上,增
加了对此人的依赖性,最好能让成员互相协作,分清主辅。

分析 3:需求控制怎么了 作者:WangWeiAn (NanJing DH ares_18@163。com)

在实施过程中,总围绕着老外的意见转;
这个是不正常的,可能在前期需求没有搞清楚,或后期需求控制的不是很好;这个要做到在
开始时进行需求评估、确认,需求变更也要求评估、确认、签字什么的。

分析 4:沟通 作者:yfhuang

要解决项目现在的问题,可以从以下几个方面进行努力:
1。检查与客户交流的所有文档,注意与项目成果有关的内容
2。一定有确认的,可实现的,可被验证的项目成果说明文档,如果没有,那现在就的应整
理清晰
3。以项目结果说明文档为起点对已有的项目成果进行核实,确认
4。对未完成项目成果进行计划,让老总及相关部门确认,并得到他们的承诺;同时与客户
沟通,尽可能协调一致
5。定期核实项目进展状态,并报告给相关人员(如客户、老总、项目成员),同时听取他
们的意见
6。以后每次对项目成果的变更,应有相关的证据,确保每次变更得到客户和相关部门的认
可。

分析 5:如何组织运用项目的人力资源? 作者:王海飞

第二个问题: http://blog.mypm.net

在实施过程中,总围绕着老外的意见转;没有很关注到本厂班组长和部门经理的建议,所以
很难得到他们积极的支持。
答复:这应该是项目经理的问题,首先,老外的东西或许有他的可取之处,但是既然应用在
中国,那就要符合国情,符合你们公司的实际情况,而这些却是你们厂的班组长和部门经理
所最熟悉的,他们也是项目干系人,他们的建议也是非常重要的。项目一开始就盲目的“崇
洋媚外”,势必造成得不到本土人员支持的结果。针对这个问题,个人愚见是:a、通过强权
下压,迫使组长和部门经理提供支持。这虽然能够马上对现有情况有所改观,但是属于治标
不治本的方法,弄不好还会得罪人,需要有一定的人际技巧;b、改变思路,团结本土人士、

第 555 页 共 756 页
第 8 章 团队管理

拉拢外国洋枪。但是这种方法不会起到立竿见影的效果,需要时间的验证。
第三个问题:
项目组成员之间的交流也不够,很到东西只是某个人知道,这样就存在问题:一是个人的思
路总是很受限制,阻止了专家建议的进入渠道,所以得出的方案很可能不是很合理;二是项
目不是很稳固,抗变化的能力不是很强。 http://bbs.mypm.net

答复:导致第一个问题出现原因:沟通渠道不畅、团队建设没有做好。首先,建立一个良好
的沟通渠道和交流平台,其次建立一些措施来保证渠道的畅通和平台的良性运转,我想这对
知识共享应该是有所帮助的;其次,改善队内环境,加强团队建设。至于怎样改善和加强,
还要搂主自己想办法了,因为没有任何一种管理方法是对的或者错的,关键是看要在什么样
的环境下使用。对于第二个问题,我想可能是由于项目的变更或者项目风险引起的,因此 l
z 应该在这方面下些功夫。
第四个问题:
现在,项目已将近做了一半,再让新人参与进来,很多问题他都得从头了解;所以现在出现
了很被动的局面,项目在蹒跚中行进;只要出现问题,总得找老总出面。
答复:一个项目让新人参与进来是很正常的事情,只要做好文档管理和人员的交接工作,这
不应该是个问题。另外,我觉得 LZ 千万不要经常找老总出面,这对人对己都是不利的,除
非万不得已的情况下。

分析 6:项目一开始,人为的风险因素就已经很明显了 作者:duanlj

照你所说:

1、项目组中没有对行业或者项目管理经验丰富的人,这样你要过河,你想摸石头,也不知
道该怎么摸……这两个至少的要一个。
2、如果对客户的需求或者行业不熟悉,就不能对客户进行有效的引导,这也是 1 所造成
的……我做第一个项目的时候就是完全被客户牵了鼻子,做了很多合同之外的东西(但是公
司却并不认为不值得,因为我们的表现赢得了后来的很多项目)。
3、交流是必须的,思维受限的问题经常会碰到,一个项目组除了项目经理全盘把握外,需
要专门负责解决技术问题的和协助跟踪业务的人。
4、我觉得这个不是问题,项目中人员变化是常有的,项目之间人员调动、人员流动等,只
要保持主力部队就成……新进来的人从浅入深就 OK,必要时让原有成员协助。这个有亲身
经历过,基本不会造成很大的影响。

分析 7:需要有公司级的流程规范来保证 作者:秋阳

针对楼主总结的几点失误,个人的一点见解:
1)在项目组成立时,没有包含一些经验丰富职位又比较高的人;
回复:项目组没有这样的人是很可能,但是在公司级应该有一个常设的技术委员会之类的组
织,统一解决公司范围遇到的技术问题。在关键的地方组织同行评审等来确定方案是否可行。
3)项目组成员之间的交流也不够,很到东西只是某个人知道,
答复:我觉得这个问题就是项目经理的失误,根据我在实际中的经验,从项目一开始就让大
家一起来讨论是一个较好的解决方法。任何一块技术难点都要做好备份,至少让一个人为主,

第 556 页 共 756 页
第 8 章 团队管理

另一个辅助。关于个人意见不够全面的问题,在我们公司在开发过程中会有多次同行评审,
在评审会上会许有类似经验的人过来参加。这个过程通过公司 ISO 质量体系及 CMMI 流程规
定来保证。
4)现在,项目已将近做了一半,再让新人参与进来,很多问题他都得从头了解;所以现在
出现了很被动的局面,项目在蹒跚中行进;只要出现问题,总得找老总出面。
答复:新人参加是不可避免,很多项目都不是一开始就能组织足够的人力资源,需要陆续补
充,怎么处理就要靠项目经理合理安排人员了。遇到到问题经常找老总是不可取的,当然实
在没有办法的情况下,你也要先想好处理方案再去找领导。

分析 8:如何组织运用项目的人力资源 作者:陶德鹏

针对你的四个问题我做如下描述
1) 在项目组成立时,没有包含一些经验丰富职位又比较高的人;
这个现象比较普遍,主要是项目经理如何去争取资源,主要是领导的资源,让领导支持你。
http://bbs.mypm.net

2) 在实施过程中,总围绕着老外的意见转;没有很关注到本厂班组长和部门经理的建议,
所以很难得到他们积极的支持。
项目的本土化的过程,必须得到我们自己的意见,我们有经验嘛,也就是必须关注我们有经
验人的意见和建议,多和他们沟通
3) 项目组成员之间的交流也不够,很到东西只是某个人知道,这样就存在问题:一是个人
的思路总是很受限制,阻止了专家建议的进入渠道,所以得出的方案很可能不是很合理;二
是项目不是很稳固,抗变化的能力不是很强
这个问题是项目经理的问题,项目经理要和团队的成员多沟通,使每个队员周知道大家工作
的状态(个人能力\工作进展\个人的经验\个人的意见)
4)现在,项目已将近做了一半,再让新人参与进来,很多问题他都得从头了解;所以现在
出现了很被动的局面,项目在蹒跚中行进;只要出现问题,总得找老总出面
项目实施过程中进入新人是很常见的,项目经理应该对他们进行培训,是他们知道自己要做
什么,和了解项目(加班加点地培训),出现问题是难免地,看项目经理的权利有多大了,不
要总是找领导帮忙。

分析 9:如何组织运用项目的人力资源 作者:杨延春

1) 在项目组成立时,没有包含一些经验丰富职位又比较高的人;
答:人员利用的问题,我想你的意思是如果有职位高的人的话,项目的一些进展就会更快了,
但是我还是觉得经验丰富会比较重要。而对于一个项目团队,不应该有太多经验不丰富的人
员的存在。本人感觉最好是 1:1 分配,这样节约了成本,而且如果那些新进来的没经验的
人能每人有个老师学习起来也比较快
2) 在实施过程中,总围绕着老外的意见转;没有很关注到本厂班组长和部门经理的建议,

答:这样有点象中国革命刚开始的那段时间,但是这样不好,一定要走合适自己的路线
所以很难得到他们积极的支持。
3) 项目组成员之间的交流也不够,很到东西只是某个人知道,这样就存在问题:一是个人
的思路总是很受限制,阻止了专家建议的进入渠道,所以得出的方案很可能不是很合理;二

第 557 页 共 756 页
第 8 章 团队管理

是项目不是很稳固,抗变化的能力不是很强。
答:这有很多种解释,机密信息的保护,但是一些问题还是拿出来大家讨论的好,这就要看
项目经理对这个度的把握了
4)现在,项目已将近做了一半,再让新人参与进来,很多问题他都得从头了解;所以现在
出现了很被动的局面,项目在蹒跚中行进;只要出现问题,总得找老总出面。
答:有新人进来是很正常的,如果出现被动的局面那证明你们的人员调配不够合理,新陈代
谢平衡的问题

分析 10:如何组织运用项目的人力资源 作者:余文华

个人认为,人是事业成败的关键,注重选人用人,才是项目成败的根本。提几点浅见:

1、仔细分析项目中各项工作的繁简轻重,工作内容;
2、根据分析结果严格确立人选;
3、确立人员后建立项目管理制度及岗位职务、职权、职责; http://bbs.mypm.net

4、按规范做事。

8.2 *团队中有大量合作公司人员如何管理

导读:交流问题不仅可能出现在项目小组与其他部门、人员之间,还有可能出现在项目小组
的内部。有一些项目经理没有很好的同小组成员进行交流,让他们了解大家对自己工作的期
望值。无论是对于项目经理来说还是对于小组成员来说,交流不善的情况都会让项目处于困
境。

(一)案例正文

某软件外包项目,工期 1.7 月,需要人员 19(总体 33 人月)其中,外公司有 10 人,内部


正式员工 6 人,新人 8 人。

外部员工技术和经验都不错,但他们所属的公司与本公司有竞争关系。所以参加人员不很配
合。尤其是这些人所在的公司经理和本公司的高层经理是同学朋友,在项目没开始前,已经
确定用他们的人。作为项目经理考虑到该公司无良好业绩,风险很大,不同意他们独自组成
一个组的要求,但高级经理却答应了对方的要求。结果到中期,这些人员抱怨自己分担作业
太多,(实际是按平均分配的)提出加人的要求,声称不同意就撤退,高层经理又做了让步。
外部人员自己管理进度,不服从项目经理的管理结果最后外部人员的作业没有如期完成,造
成很大范围的返工,整个项目评价很低。项目经理被责辞职。

遇到这种状况,怎样实施项目管理呢?

(二)专家点评

第 558 页 共 756 页
第 8 章 团队管理

柯仰杰 厦门信达网络科技有限公司常务副总经理、董事,西安交通大学管理学院毕业,获
管理学和工学学士。先后任兼职于北京安博成科技有限公司、华深慧正、香港 Active 系统
有限公司中国办事处等,先后担任编码人员、项目经理、技术经理等职位;在上市公司厦门
信达先后经历了项目经理、软件部经理、总经理助理、副总经理和常务副总,曾兼任中日韩
合资企业厦门掌通科技有限公司董事,有着丰富的项目管理和 IT 企业运作经验,对 IT 企业
人力资源管理、成本管理、质量管理、项目管理等有着独到的理解和丰富的实务经验。

柯仰杰点评:

这是典型的周期短风险性高的项目,从提供的材料看,其中的大部分风险来源于项目管理。
我想如果从以下几方面妥善处理,将比较大程度的降低项目失败的可能性。

第一、 通过沟通,获得高层经理的授权,降低行政干预所带来的风险。
项目经理在面对高层主管部分脱离项目管理规律、过多干预项目成员管理时,没有及时有效
的沟通,再加上人力资源支持有限,是该项目失败的部分原因。
这要求项目经理有效的和高层经理沟通,获得高层主管的授权,在尊重公司目标的前提下,
应获得用人的相对自主权,要求责权利对等,避免行政干预所带来的风险。
本文转自项目管理者联盟

第二、 规范公司开发过程,复制成熟的项目管理过程,降低项目进度的风险。
该项目的项目管理需要规范,公司的项目管理制度和规范需要改进。任何一个项目的失败绝
不是偶然的,和公司内部的管理制度,特别是项目管理制度息息相关。
项目经理可根据公司特点,剪裁并执行公司软件开发过程,复制成功的项目管理经验,通过
控制软件过程的各里程碑,及时调整进度,达到降低项目进度的风险。

第三、 加强系统架构设计和功能规划,减少软件设计的模块耦合,避免大面积返工。
大部分软件项目的分析设计都应遵循高聚合、低耦合的原则,采取内部接口和外部接口相结
合的设计思路,尽量减少功能间的关联。根据功能的重要性、是否基础模块等因素安排开发
人员。对于技术水平不了解或者技术水平不是很高的人员,可以把次要模块和次要任务分解
由其执行,避免因技术原因所带来的大面积返工。

第四、 外部人员自我评估进度,通过里程碑管理,减少技术能力误判所带来的风险。
任何技术人员的薪资和能力都不会一样的,所以平均分配任务是一种貌似合理的不合理,作
为项目经理可根据成员能力来分配任务,而不是搞任务量的平均主义。 http://blog.mypm.net

该项目中,项目经理可由外部人员自我评估开发进度,结合 WBS 分解情况,制定进度。项


目经理可在尊重开发人员自我管理进度的诉求下,通过有效的里程碑考核,化被动为主动。

第五、 加强过程控制,及时调整项目状态,减少项目进度和质量的偏离。
最不应该出现的是,项目经理不能有效的跟踪项目进展,包括进度和质量。
当项目进度或者质量发生偏差时,应及时寻求高层经理的支持,及时调整人力资源和工作任
务的分配。

(三)项目管理者联盟网友分析:

分析 1:项目管理不是万能的 作者:牛小林

第 559 页 共 756 页
第 8 章 团队管理

项目管理不是万能的,不可能解决全部的问题,为此:
1。作为本项目的项目经理,首先做到风险预警和分析,及时把问题暴露出来,让足够的高
层知道,同时声明你的解决条件,如果不能够提供条件将产生的后果。
2。把所有交流的过程用邮件或者项目会议纪要的方式保留下来。
3。对没有回复或者没有能够及时解决的问题,采取定时跟踪,通知所有相关利益者的办法
推进。
如果采用以上方法还不能够免责的话,我建议辞职。

分析 2:个人觉得对项目范围的界定做的不够充分 作者:张冰

前面的兄弟提到了项目的风险预警与消息通报机制.但是我不知道那位项目经理是否对各个
合作单位的分工,工作界限做了明确的界定.

http://blog.mypm.net

分析 3:体制不明,管理混乱 作者:戴耕

从案例来看,问题出在体制上。首先,项目部成立的时候,管理体系没有建立好:项目到底
是谁对项目负责,也就是谁是项目的管理并对项目的成败负责;其次,本公司与合作公司是
什么样的合作方式;还有,项目部、公司的权限如何设置。从案例介绍中来看,这方面的基
础工作没有做好。另外,公司高层领导的作为也直接干扰了项目经理对职务工作的正常履行。
还有,从案例介绍中,个别高层领导还有腐败之嫌。
在这种情况下,项目经理可以做的是: 本文转自项目管理者联盟

1.坚持原则
2.向本公司及合作公司高层提供风险预警报告,明确告知问题的严重性及可能产生的后果,
并提出解决方案。
3.向本公司高层陈述合作中存在的问题并提请重新考虑与合作公司的合作关系。
4.如果这样还不能引起重视,就越级向董事会反映。
如果连董事会都无能为力的话,那你就只好辞职了!

分析 4:无奈的大环境 作者:任鹰

看了这个兄弟的案例,感悟很深。
的确处于两难境地,我也曾碰到很多这样的项目案例。

两种方法:
一种:得过且过,争取将责任大的工作分给那些人。
另一种:辞职。

分析 5:任鹰说的有道理 作者:牛小林 )

其实,对于任何一个项目经理来说,这都是个陷阱工作,就好像回答一个问题:
你知道猪说:“不知道”的故事吗?一样,无论你怎么回答,都避免不了最终的结果。
要不就是大声呼喊,推卸责任,要不就是赶紧躲开,别无他法。

第 560 页 共 756 页
第 8 章 团队管理

分析 6:干系人分析 作者:李石求

也许您应当进行干系人分析,但更重要的是,您应当揣摩领导的意图,也许您本来就是个替
罪羊,但即使如此,您也应该先摸摸领导的真实意图

分析 7:官私合营的复杂组织 作者:bill

我认为项目经理可选的方法还是比较多的:
其一:如果高层经理有权有势,项目经理认为无抗衡的可能 项目管理者联盟,项目管理问题。

1 就应该积极的融入,争取高层经理的认同
2 就是在分工的时侯就可以在高层参与下签订责任状
3 如果外部小组违约自然难以获得高层的认同
其二:如果高层经理更上层的领导比较支持项目经理,自然可以借力打力,高层经理也不敢
太多偏护总之,最能与外部小组形成一个团队,否则就把他当作外包供应商,事事都小心看
护,出了事,冤有头债

分析 8:加强沟通 作者:johnson

1,加强与上级的沟通。说明不能独立成立小组的原因以及存在的风险。
2,作为项目经理,敢于说“NO"。无论对谁,必须坚持原则,否则自食恶果。(项目经理被
责辞职)

分析 9:团队中有大量合作公司人员如何管理 作者:YYC

典型的中国传统人情式经营,建议项目经理和哪个高级经理一起被辞退
第一:项目经理既然做了这工作就要负责,抵制住压力,他没有这么做,证明他着方面不合
格。一个字“辞”
第二:那为高级经理,没有从公司的角度考虑问题,不比多少还是一个字“辞” 。

8.3 *如何控制 IT 项目中的人员流动问题?

(一) 案例:如何控制 IT 项目中的人员流动问题?

案例作者:项目管理者联盟会员 sam 项目管理者联盟,项目管理问题。

我是一名从事对日外包工作的程序员,对日外包项目一般对技术熟练度要求不高,但在项目
时间上要求的比较苛刻。可是我们项目的人员流动却很频繁。如何来控制人员流动成了当务
之急。以前也有通过签合同的办法来控制,但这会使想走的人工作消极,并不能解决根本问
题。

如何控制项目中的人员流动问题?希望大家能给予一些好的建议。(本人只是个组长,没有
权力给予任何承诺。) http://blog.mypm.net

第 561 页 共 756 页
第 8 章 团队管理

http://blog.mypm.net

(二) 项目管理者联盟专家点评

专家介绍:吴永达 中国实战派著名项目管理专家,美国项目管理协会(PMI)认证 PMP,


清华大学、北京大学、人民大学客座讲师,项目管理者联盟高级顾问,神州数码教育学院项
目管理讲师,神州巨龙项目管理培训讲师,微软认证 MCSEMCDBA,信息产业部注册信息系
统工程监理师。

吴永达点评:

对于控制项目中的人员流动问题,首先我们来分析一下造成人员流动的原因,只
有先把问题找到,才能够找到解决问题的方法。通常可以采取调查、访谈等方式
进行沟通。通过分析,造成人员流动的原因可以归结为以下几种:

第一, 待遇薪酬。薪酬问题,是一般人员流动的最大原因。

第二, 成长空间。每个员工,都希望自己服务的企业有着明确的岗位职责体系,
清晰的职业成长空间,完善的人力资源培训系统。

第三, 团队氛围。工作氛围也是导致人员流动的一个很重要的因素,快乐而尊
重的工作气氛对提高员工工作积极性起着不可忽视的作用。

当然还有许多其他原因,但是笔者认为以上这些原因是最主要的,其他原因在此
不再赘述。如果企业已经出现以上提出的问题,可以采取以下一些方法解决:

第一,与同行业相比较,制定一个合理的薪酬制度。针对个人对公司所创造的贡
献给予差别化的对价报酬,才是真正合理的薪酬制度。要达到报酬合理的境界,
必须考虑三个公平,分别是外部公平、内部公平与个别公平。外部公平是指公司
员工的薪资水准需在外部市场中具一定程度之竞争力;个别公平则是员工个人的
个别表现应反映在报酬(或对价)上;而所谓的内部公平则指公司内部应有一套
公正客观以衡量薪资差异的准则。

第二, 为员工提供广阔的成长空间。社会发展速度越来越快,工作中所需的技
能和知识更新速度加快,因此培训已成为企业提高员工工作效率、增强竞争力的
必要职责。从员工的角度来看,自身的发展已经成为他们衡量自己工作生活质量
的一个重要指标。一个企业,发展的机会多,培训的机会多,就意味着晋升的机
会多。其次,也可以多组织一些会议,提升个人职业技能和管理能力。由于是 I
T 类的员工,也要培养人际关系的沟通能力。

第三, 鼓励非正式沟通,多进行拓展式训练,增加员工间的沟通机会,创造轻
松愉快的团队氛围。良好的工作氛围是自由、真诚和平等的工作氛围,就是在员
工对自身工作满意的基础上,与同事、上司之间相处融洽,互相认可,有集体认
同感、充分发挥团队合作,共同达成工作目标、在工作中共同实现人生价值的氛
围。

第 562 页 共 756 页
第 8 章 团队管理

作为一个企业,针对人员流动的问题最好是做好预防,这样的成本相对于解决问
题的成本也是比较低的。可以采取的预防措施主要有:

首先,从组织方面来说,要从制度层面确定各个部门、工作职位之间的明确分工,
如此才不会发生互相推诿、推卸责任等影响工作氛围的情况发生。从企业文化建
设着手,提高员工工作激情,营造一个相互帮助、相互理解、相互激励、相互关
心的工作氛围,从而稳定工作情绪,激发工作热情,形成一个共同的工作价值观,
进而产生合力,达成组织目标。制定合理的薪酬制度。与员工建立完善的合同约
束机制,该合同对企业商业机密的保护、技术专利的保护、核心竞争力的保护都
要体现出来,合同中对于经营活动的处理方式要尽量细化,又具可操作性,形成
实际上的约束。

其次,从项目管理层面来说,努力尝试构建学习型组织,营造宽松的工作氛围。
部门内应该建立良好的学习风气,要鼓励和带领团队成员学习先进的技术和经
验,在进行工作总结的时候应该同时进行广泛而有针对性的沟通和交流,共同分
享经验,不断总结教训。真诚、平等的内部沟通是创造和谐的工作氛围的基础。
职务只代表分工不同, 只是对事的权责划分,应该鼓励不同资历、级别的员工之
间的互相信任、互相帮助和互相尊重;每一个员工都有充分表达创意和建议的权
利,能够对任何人提出他的想法,主动地进行沟通,被沟通方也应该积极主动地
予以配合、回答或解释,提倡非正式沟通。

最后,从技术层面来说,文档管理应该遵守相关的制度。保密制度应该强调,特
别是涉及公司机密的文件,要建立档案的全宗,案卷,目录等,并且档案管理应该
做到专人管理,并且在使用后做好收集工作。还有就是重要档案的保管,文件的
销毁处理都有相关要求,应该遵循,不可以擅自单独销毁文档。另外就是做好人员
备份,本岗位的员工最少也应该知道其上下手员工(和他在工作上有联系的人的
工作)的工作流程及细则;而对于与此工作相关的其他整体流程部分,所有员工
最少应该知道大概(这应放在员工手册中)。这样一来,可以提高员工间的工作默
契同时也可以提高员工的局部素质问题,增进了员工间对工作的理解程度,从不
同员工的角度上来看,还可以跟进流程,使其更加适应部门的发展;要是有一员
工不在其岗位上,其上下手也可以顶替上来。

在软件行业里,员工一般文化水平比较高,他们有更高的发展要求,所以在这样
的团队里要多强调人的因素,注重文化的建设,让员工看到发展的希望,给他们
更多的升职空间,使团队保持稳定。

(三)项目管理者联盟网友评论:

分析 1:题 目:浅见 项目管理者联盟会员:孙业海

第 563 页 共 756 页
第 8 章 团队管理

人员不流动是不可能的,可以做的是减少人员流动比例(从公司角度讲),特别
是项目过程中流动比例(从项目来讲)。公司人员流动比例与公司文化、所处阶
段、以及公司发展战略有非常大的关系,这部分一般人是无法影响的。

项目过程中要注意几个方面:1、节源,就是人力资源进入项目组,项目经理要
有一定的影响力,不能什么人都要,特别是明显存在离开倾向的人(除非你能与
他沟通好,即使这样仍将存在相当大的风险);2、项目开展过程中的 PM 的人格
魅力,无论项目管理还是公司管理,人格魅力绝对有非常大的影响,同时注意保
持项目活力和项目成员的沟通;3、开流,一旦发现有项目成员存在离开倾向,
在影响比较小的情况下尽快让其离开。如果影响比较大,要进行沟通,并注意交
接问题。人都是感性的,善待他人,平衡好各方利益,你的风险就是最小的。

分析 2:题 目:我认为的几个原因 项目管理者联盟会员:mumu

1、在公司里面要等级分明,要有一定的工作年限积累表现!例如从福利,奖金,
培训,发展前途等方面表现出层次!但是层次不要太多,我个人认为 6 级就差不
多,第一级:刚参加工作一年内,第二级二年至五年,(在二年至五年内要因时
间的不同和工作积极性的不同在奖金上表现出来)第三级:五年至十年,这一层
次是公司的中坚力量无论是从奖金、福利、培训计划都要考虑他们的个人意见,
第四级:高级工程师这种人才是公司决策技术人员,要同他们个别的谈判,根据
需求提供待遇。第五级:公司副总,他们承受着各种压力要留住这一层次人才不
但要注重待遇,更主要的是给他们一个稳定的环境,到他们这个阶层有些人就比
较想稳定了。第六级就是老总级别,可能就是你自己了,我认为作为你要时刻认
真听取下面员工的意见,尽量的满足他们,并且要敢于用人。

2、你想想作为一名打工者,他们需要什么啊无非是金钱、前途、休息时间。金
钱要丰厚但有挑战性,增加培训计划,加快公司发展,一定要正规化,严格的双
休日。这几点都满足了鬼才愿意跳槽呢!

分析 3:题 目:如何控制项目中的人员流动问题 项目管理者联盟会员:胡


我在项目上也遇到过类似现象,从我个人观点来说,项目中人员的流失是在所难
免的,尽管我们可以使用一系列亲和力的方式去留住我们需要的人才,但是人员
流失的原因是多方面的,即使你再有人格魅力,福利再好,仍然会出现人员流失
现象,所以,最更本的还是要从项目管理上去减少或者避免人员流失给项目带来
的损失。比如:严格的文档管理,双角色等等。

分析 4:题 目:找出成员流动的原因,对症下药 项目管理者联盟会员:林起

发表一下个人的浅见:一个项目组的稳定性与多方面的因素有关,找出成员流动
的原因,对症下药是关键。

1、公司决策。

第 564 页 共 756 页
第 8 章 团队管理

公司决策层对项目出现消极决策怎么办?

项目经理需深刻理解并分析公司决策层的意图,多方沟通,积极争取资源。

2、公司待遇。

项目组成员对公司待遇和项目奖金分配产生意见怎么办?

从实际情况考虑,采用柔性的激励方式安抚成员,尽可能找出完成该项目后能够
对项目成员带来哪些即得利益和成功因素,尽可能找出该项目未完成对项目成员
带来的不利因素,尽可能说服上级领导给予该成员合理的待遇。以上都是基于该
成员确实值得你为他这样做。

3、领导人格魅力

如果项目组的上级领导缺乏人格魅力怎么办?

努力做好成员的思想工作,尽量避免成员和项目组的上级领导的直接接触。

4、项目组成立初期的项目管理方案

项目组的管理方式出现问题怎么办?

项目组成立初期项目经理考虑最多的应该是组建这个团队最适合的管理方式是
什么样的,不同的项目组有不同的管理方式。再明确并落实到组内每个成员的心
里去。如果在项目进行过程中出现管理不到位的情况,那么及时调整管理方式补
救也为时不晚。

5、项目经理的沟通技巧

项目组成员因沟通出现问题怎么办?

项目管理中的沟通管理往往取决于项目经理本人的沟通技巧,项目经理在项目过
程中需要潜移默化的教会其他成员在沟通上的技巧,自然而然整个项目组的沟通
将会更加和谐。这一点,对项目组成员的现在和将来都是受用无穷的。

6、其他

分析 5:题 目:钱不是万能的 项目管理者联盟会员:daijiangbao

用钱来作为激励的手段是非常低级的,但也是有一定效果的,最有效的激励是项
目成功的自豪感和责任感。

第 565 页 共 756 页
第 8 章 团队管理

另外人员冗余配备也不是个好办法,这样会造成项目成本的上升,进一步增大项
目管理的难度和造成一些不必要的冲突,而且如果开发人员和冗余人员都流失
了,难道还要搞第三梯队的冗余人员吗?

天下雨,娘嫁人,由不得太多的说法,关键是按照项目管理规范流程去做(当然
要结合软件工程的具体技术),人员流失了,接任者知道该如何接着做下去就可
以了,天下雨也罢,娘嫁人也罢,都无所谓。

分析 6:题 目:奖金控制。项目管理者联盟会员:shiling

项目成员流动是很正常的,是可以预见而且有预兆的。前面已经提到在文档管理
和人员冗余配置上减少人才流失引起的损失。

项目成员的薪水如果是工资+项目个人绩效提成方式,而且个人绩效提成比例越
大我想在项目结束前项目团队的稳定性就越高。

分析 7:题 目:软件开发人员和建筑民工有差别吗? 项目管理者联盟会员:d


aijiangbao

没有哪个建筑工程项目和包工头害怕干活的民工的,或者被民工要挟的。it 软
件开发为什么会这样,关键还是项目管理的能力问题。

对于建筑工程项目和为客户单独定制的软件,其组织必定都是项目型的,干完活
就解散这是天理,有活了再召集一帮人完成就是了,从本质上来说,建筑工程项
目与软件开发是一致的,尤其是软件外包,国外已经把需求等都写的非常详细,
完成了就可以了,与建筑工程没有本质的差别,这点与国内的软件开发有天壤之
别。

案例叙述也说明,对技术要求不高。之所以出现这样的问题,应该采取以下的措
施:

1、让开发人员充分的参与到软件开发的各个方面,不要按照垃圾的项目管理方
法去给开发人员分配任务,这样开发人员建立不起对项目的责任,也建立不起来
对项目的情感,随时可以撇开你而去。

2、充分重视设计、文档、评审的工作,开发人员的工作不是敲键盘,而是需要
把整个的软件开发设计工作做好,把相应的文件建立起来,按照计划去完成软件
开发,而不是把软件代码敲完保留在开发人员心中,变成以此敲诈项目和公司的
武器。另外就是重视软件开发的文档、计划、代码的评审,尤其是软件开发人员
之间的对等评审,让开发人员互相沟通,互相了解、熟悉对方的工作内容,这样
张屠户离开了,立马由王屠户接着干,甚至可以派一个新手直接来接任,不会对
项目造成什么冲击,也不会造成张屠户走了,大家都吃带毛猪了。这样做的效果
可能会是张屠户不敢随便把自己凌驾于项目之上,反而是因为建立了对项目的责
任和情感,项目完成后赶走张屠户都困难,呵呵。

第 566 页 共 756 页
第 8 章 团队管理

按照规范的项目管理做,但是要明白什么是项目管理,不要把软件工程当成是软
件项目管理,两者本质不同,目标不一致,用错了方式导致的后果不能抱怨别人。

把对外的软件外包项目真实的当成项目来做,自然就会找到这些问题的解决办
法,而且软件外包项目这样做,是具有良好基础的,并不是因为软件开发挂一个
所谓的高科技标签就失去了其本质的项目面目,软件开发越是重视所谓的技术,
以技术代替管理,越是发展不好,这是软件开发的本质问题,也是软件开发需要
真正的项目管理的根本需求。

分析 8:题 目:如何控制项目中的人员流动问题?项目管理者联盟会员:张宏

在项目分配上采用备份机制,即对同一个项目分配两个人共同熟悉项目,其中一
个人是另外一个的补充,如果一个人离开,作为备份的组员可以很快补上。

与组员多沟通,掌握他们对公司的看法和诉求,及时反映和做好疏导工作。作为
组长,任务的分配和完成固然重要,但是能够作为上下级之间的沟通渠道就更为
重要。

分析 9:题 目:注重个体发展 项目管理者联盟会员:龙七

前面这位高人的分析已经很强了,从制度和沟通基本能解决这个问题.

我给的建议是注重每个人的发展,让你的组员的价值都得到体现,这个要通过你
的努力实现,其次是要提高你的个人魅力,用你的人格魅力征服你的组员,让他们
和你一起共同奋斗!

8.4 *对项目成员能力不了解,如何进行工作任命和任务分配?

(一)案例:对项目成员能力不了解,如何进行工作任命和任务分配?

案例作者:项目管理者联盟会员 大连远东计算机系统有限公司 李宏

我在负责一个软件开发项目,我们是新组建的一个项目团队,项目经理对大部分成员的能力
情况不了解。在这个公司,对于组建项目团队,项目经理没有绝对的权利,分配到什么人就
只能用什么样的人。面对这种情况,作为项目经理,应该通过何种方式来了解自己的项目成
员,然后对每个成员进行恰当的工作任命和任务分配呢?
请大家帮助分析,给予好的建议。

(二)项目管理者联盟专家点评

专家介绍:许江林 获国内首批 PMP 资格。先后在青岛海尔集团、朗讯中国公司、惠普中国

第 567 页 共 756 页
第 8 章 团队管理

公司担任过项目评估员、项目经理和高级项目经理职务,有 10 多年的项目管理经验,长期
从事政府、电信和智能系统集成项目管理工作。 http://bbs.mypm.net

许老师担任项目管理者联盟 IT 项目管理高级讲师,曾担任 HP 商学院特聘讲师,许老师曾


编写和翻译包括《可视化项目管理》
、《怀德曼项目管理词汇手册》、
《IT 项目管理最佳历程》
等书。并在《中国计算机报》和《中国经营报》等媒体上发表过多篇项目管理文章。

许老师曾为太平洋保险集团 IT 部、方正国际、中国银行软件开发中心、北京 NTTDATA 数


据、中国电子口岸数据中心、首都机场、高阳圣思园、长城宽带、北京万维易化、宝钢集团、
灵图软件、蓝拓扑电子、山东泰华电讯等。

许江林点评:

项目团队相对职能部门而言是一种临时的团队,所以项目经理对成员技能背景的不了解也是
经常发生的事情。在矩阵型的组织结构中,项目经理没有权力自己选择所有的项目成员,但
是项目经理仍然要对项目的结果负责。在本例中,建议的方法有:

(1) 首先把项目的范围进行分解,然后根据项目的 WBS,创建项目团队的 OBS[组织分


解结构],从而明确项目中所需要的角色及其各个角色的职责。

(2) 下一步,进行项目团队内部岗位招聘,请团队成员[领导委派给的所有成员]自己选
择最合适自己的岗位。

(3) 根据每个岗位的技能要求,项目经理请其他关键关系人一起对成员进行面试[必要时
也可以增加笔试]。
项目管理者联盟,项目管理问题。

(4) 面试结果,一部分人合格,那么就可以上岗。一部分人不太合格,但是可以在短期
之内得到提高,那么就为这些人制定自学和培训计划,或者一帮一计划。还有一部分人不合
格,或者有些岗位没有找到合适的人,那么项目经理必须和项目总监提出,请求更换或增派
合适的人员。
http://bbs.mypm.net

(5) 在这个案例中,需要特别关注的有两点:
a) 项目中有潜在的问题,项目经理应该向上级提出,隐藏问题会造成更严重的后果。但是,
在提出之前,项目经理要进行详细的分析并且采取必要的措施。比如,在刚才的案例中项目
经理可以先内部招聘,找到具体的问题所在[也就是具体哪些岗位缺人]。而不是不加分析,
把问题[人员技能不了解]全盘踢给上级处理。 项目管理者联盟文章,深入探讨。

b) 对团队成员不了解,这种情况下,项目经理管理的颗粒度应该细一些,采取的领导风格
是‘多工作行为,少关系行为’。也就是对成员工作要多进行具体指导、监控和督促,不要过
多授权。不仅要管理任务的目标和结果,还要管理任务的过程和步骤。同时,项目经理还应
该主动举行一些团队建设活动,提高成员之间的了解和信任程度,从而提高团队协作的效率。
当团队成熟度提高之后,项目经理可以适当调整自己的管理风格。
项目管理者联盟文章,深入探讨。

第 568 页 共 756 页
第 8 章 团队管理

(三)项目管理者联盟网友评论:
本文转自项目管理者联盟

分析 1: 题目:面对面地下达任务 项目管理者联盟会员:龙七
http://bbs.mypm.net

首先做好充分的沟通,根据你和每个人的交流情况,初步确定他们的能力,然后,对任务进
行分解,下达任务时一定要和每一个接受任务的人面对面说清楚,并确认他自己能单独完成,
你还要根据你的判断矫正他自己的判断。 http://bbs.mypm.net

任务下完后,一定要注意进度跟踪,确定这个人的能力。
一段时间后,你对每个人的能力了解了,就可以清楚的下达任务。
同时要做好的是培训工作,对有潜力的人员一定要花力气培养,这样对工作的好处更大。 http://blog.mypm.net

分析 2: 题目:多注意项目进度 项目管理者联盟会员: wishmadison

1. 工作分解尽量详细, 目标一定要明确.
2. 开会讨论, 请项目成员提出自己的建议和希望承担哪一部分的开发任务.
3. 初步分工并再次征求项目成员的意见, 修改后正式分工.
4. 每隔一段时间都要去问一下项目成员的项目进度, 演示其初步成果, 如有问题可随时做适
度的改变.

分析 3:题目:完善人力资源管理是关键 项目管理者联盟会员:张吉旺 http://blog.mypm.net

这样的问题对于拥有比较完善的人力资源管理的企业来说其实并不是什么问题。
一个项目团队,对于项目经理来说,最需要的知道的是什么?无非是自己项目成员的比较详
尽的个人履历。比如,成员 A,为人老实,做事踏实,考虑周密,但是思想并不活跃,创新
意识不高,最近的项目经验来看,没有显赫成绩,但是并没有太多失误。那么成员 A,你就
有了比较深刻的了解,他适合什么岗位也就显而易见了。
本文转自项目管理者联盟

而这些比较详尽的个人性格信息,个人项目经验,以及领导对某员工的总体评价,个人的总
体发展情况等等,作为一个完善的人力资源系统来说都应该有详细的纪录,这样就算是人力
流动很频繁,项目交错也没有关系。因为有事实依据。
http://bbs.mypm.net

如果没有那样完善的档案信息,项目经理就要费一番精力和口舌了。有针对性地进行一对一
谈话,性格测试,项目座谈等都是比较有效的手段,另外咨询其他人的意见也许能得到更多
的相关信息。作为参考,敬请指教。
分析 4:题 目:开会是比较好的解决办法 项目管理者联盟会员:郑承满

1.将项目的目标进行讲解
2.开会让每个人谈谈对项目的看法
3.将项目的任务进行分解,让大家都进行适当的分解并提出建议,看看大家的认识与见解,
同时了解技能
4.分组开会(如果项目比较大的话),对大家有一个认识 本文转自项目管理者联盟

5.初步的分工,进行磨合

第 569 页 共 756 页
第 8 章 团队管理

6.根据需要进行调整。
其实所有的 pm 都会碰到不了解的成员的情况。

分析 5: 题目:尊重个人意愿,参考能力与过往经验 项目管理者联盟会员:王 http://blog.mypm.net

应设计一份由员工个人填写的履历表,简单明了(像民族,出生年月等无关紧要的可以不要),
重点填写近两年所从事的项目及岗位,个人对项目的认识,进入项目后本人想从事什么岗位
(可以有二到三个志愿),必须说明自己从事该岗位后拟通过哪些措施和方法,使本岗位的
工作最大限度的为项目的总体目标服务。根据每个人填写的情况,结合项目的实际情况进行
岗位安排,顺便说一句,表格填写的不认真,敷衍了事的人应降低标准安排。

分析 6:题 目:对项目成员能力不了解,如何进行工作任命和任务分配 项目管理者联盟


会员:cectanjing

对项目成员能力不了解,这是初当项目经理碰到的最大难题。我觉得还是应该磨合,不能一
棍子打死。没有哪一个人能力能上天,也没有哪一个人没有一点出息,关键是整合,集思广
益,这样才能出成果。

分析 7:题 目:工作分解 项目管理者联盟会员:徐高明


http://blog.mypm.net

我认为既然是对自己的人员没有足够的了解,这时就需要将工作分解做到尽可能好.因为好
的、详细的工作分解会使我们更加明确每个任务对能力的要求。在详细分解的基础上,项目
经理可以针对不同的任务设计不同的问题,来让员工作答,从而选出较为合适的人选,安排
合适的工作。做到人尽其责!

分析 8: 题目:高效的个人是项目成功的关键 项目管理者联盟会员:HSP http://blog.mypm.net

首先我觉得高效的个人应该是项目成功的关键,项目经理本身就有责任为项目的成功争取优
秀的资源。
对应项目的具体要求和 WBS,和目前已有的资源开一次会议,具体了解一下目前的资源是
否满足项目的需求,若不满足,一定要申请新的资源,这关系到项目的成败。
另外项目经理有责任来建设一个高效的项目团队,有责任满足成员的合理要求。
项目管理者联盟,项目管理问题。

分析 9:题 目:成果导向 项目管理者联盟会员:吴明刚


项目任务的分解,WBS,应该是以产出为导向的,而不该是以人员为导向的。在确定了 WBS 后,
应该和上级沟通,项目经理本身的职责就是争取资源和利用资源。项目经理不是领导,没有培
养员工的职责,项目经理的目标是完成项目。所以,先确定 WBS,然后让员工自己找位置,职能
欠缺的就要另外向上级争取。
本文转自项目管理者联盟

分析 10:题 目:能力矩阵 项目管理者联盟会员:诚

能力矩阵是一个可行的办法。 本文转自项目管理者联盟

第 570 页 共 756 页
第 8 章 团队管理

矩阵中,行-能力,列-人员。首要任务是,该项目需要什么能力。准备过程中,尽量把能力
具体化、分析清楚,使项目成员了解,并且支持。
从案例描述来看,人员是不定的而且不是随意支配的,因此,在选项目成员的时候,应该订
立能力组,把一些能力组合起来,满足组中的大部分项目,就可以胜任。从管理角度来看,
工作都是分配给不胜任的同志来承担的,这样成员才能有动力,组织才有人员能力发展计
划。

8.5 *在“各自为战”的公司,我该如何展开工作?

案例提供者:项目管理者联盟会员 孙佐贤(tsoyinsuen@163.com)

案例正文:

某公司是从事塑胶制造业的制造型企业,公司实力雄厚,规模较大,约有员工两千人左
右,从研发到加工生产各环节功能齐全。
http://bbs.mypm.net

本人初到该公司任职项目经理,任职之后发现公司的项目管理非常薄弱,可以说还处于
没有起步阶段,存在的问题较多,其中最严重的就是公司各部门之间缺乏必要的沟通与协作。
原来的做法是由产品开发工程师负责新项目,一个人单打独斗,其它部门如工程、品质、生
产等都不参与。如此便产生了如延期、品质不达标、移交到生产部门后投诉太多等一系列问
题。

面对问题,各部门则相互指责推诿。这种情况在一定程度上阻碍了公司的发展,因此,
公司管理层打算用现代的项目管理方法去管理新项目,以图改变这种状况。

去年公司曾聘过两个项目经理,但因阻力太大,各部门不与合作,工作未如人愿。其中
一个被老板炒鱿鱼,另一个在几个月后主动离职。

面对公司的这种情况,我又该如何打破困境,去开展项目管理工作呢?

项目管理者联盟专家点评:

专家介绍: 王景山 项目管理者联盟高级顾问

王老师有着 10 多年的欧洲海外项目管理工作经验,90 年代初归国后,曾先后任职于多


家知名家电及 IT 制造企业,分别从事新产品研发、项目管理、企业发展规划及高层管理等
工作。

王老师主持和参与过大量与欧美、中南亚公司的合作项目,包括新品研发、计算机软硬
件研制、厂房及设备改造、成套生产设备出口等项目,项目管理和企业管理实践经验丰富。

第 571 页 共 756 页
第 8 章 团队管理

王老师撰写的培训教材及各类专业书籍,如《工业企业项目管理》、
《研发项目管理》、
《项
目投资与决策》、《项目投资与管理》等,有着较高的权威性,深受广大读者喜爱。

王景山点评:

(1)永久自行车时代制造业追求的是标准化,含部门职责、程序、工艺、检验、产品
标准。案例描述的现象是上述标准化时代和企业文化的影响。 本文转自项目管理者联盟

(2)尽管市场的个性化需求、技术的高速发展和产品的频繁更新使制造业开始考虑项目
管理的方法,制造型企业中不同企业类型对项目管理的需求程度是不同的,单品种大批量的
塑料、橡胶、模具、机械加工、标准件等企业需求最弱,采用标准化的部门职责、程序、工
艺路线、检验方法、产品标准仍然是上述企业主要的管理体系和管理方法。

(3)2000 年以来,项目管理形成应用热潮,制造业也在开始应用项目管理。但是,项
目管理的教育和培训集中在企业中层学习项目管理方法,忽视了另外一个方面是企业高层对
项目管理的认识。企业应用项目管理需要首先解决:

(一)本企业是什么类型的企业?本企业在那些问题上需要项目管理?哪些问题上不需
要项目管理?

(二)本企业如何应用项目管理?是建立主导型项目管理体系(机构、职责、程序、资
源配置)?还是建立辅助型项目管理体系(辅助手册或规章程序)?还是仅仅将项目管理当
作一种工作方法,例如历史上制造业是将一些运筹方法当作工具在用。

企业高层首先需要整明白:因事(项目型业务)-设人(项目经理)-授权(职责)-运作
(程序、方法)

制造业的高层没有解决上述问题,出现了一些企业大张旗鼓的宣传项目管理、成立项目
组织,但是不知该作什么,一些企业认为不需要项目管理。一些企业设立了项目经理,而项
目经理在井田制的组织机构中“有名(称)无实(权)”,工作起来困难重重。
本文转自项目管理者联盟

我赞同上述各位提出的项目经理在目前环境下“勉强生存”的可操作方法和策略,解决的
根本出路在企业项目管理应用环境的改变,既如何改变一群人的观念和思想。
项目管理者联盟,项目管理问题。

建议看一下专栏文章中的拙作《制造业如何应用项目管理》和《制造业项目管理应用范
例》

项目管理者联盟网友评论:

题 目:自己的几点看法 作 者:王建军

1、你要先搞好与各部门经理之间的人际关系,再告诉他们公司的问题,从而得出他们
对公司及项目管理工作的看法。想把自己的东西让别人接受,首先要看清对方的意向。

第 572 页 共 756 页
第 8 章 团队管理

2、对你的老大要明说公司的问题和你工作上所碰到的问题,看能不能说服他给你一些
特权,去想办法解决问题。

3、多去现场走走看看,和当管人员多沟通,多听听他们的看法,这样你就可以知道每
个部门希望要的管理方法,只能做参考。准确的方法要看你对各个部门问题分析和解决方案。

4、在原来管理方案上加上自己的提议,建议给公司的决策层,看是否能让他们同意你
的看法,是否可以试一下,虽然有些哆嗦,但是你要知道,决策层同意了,你的工作日后就
好做了。不要自己独行,项目管理工作是要靠整个公司各个部门的配合才能做好的。

5、招开项目管理工作方案修改会议,会议开始,你要先把前一阵子你去各个部门所听
的、所看的先重新介绍一下,再把方案讲给他们听。他们有意见一定要等你讲完再让他们提
问,方案讲完后你现在做的事就是听就可以了。
题 目:不要轻易否定别人 作 者:daijiangbao

新人乍到,不要否定别人。该公司已经发展到一定规模,必定有其成功之道,这个成功
之道就是项目管理成功之道,你需要沿着这个成功之道再接着走下去就是了。
http://bbs.mypm.net

不要认为项目管理是改天换地的什么玩意,也不是说非得按照 pmbok 的方式才叫项目


管理,避免犯教条主义。

要主动去适应环境而不是要求环境来适应你,否则你就是第三个离职的项目经理,不论
是被撵走还是自己走,都是一回事,要能领会项目管理的精髓,而不是装腔作势的按照项目
管理理论描一遍。
项目管理者联盟,项目管理问题。

题 目:三点意见 作 者:wangf

出现当前的状况,以及各部门的人员相互推诿等现象,肯定每一个部门的人员都有很多
的看法和意见。建议如下:

1、和各部门主管以及骨干员工进行深入交谈和沟通,了解他们对于当前公司研发、生
产状况的看法以及改善的意见。

2、将这些意见整理后,按照适当的方案组合形成一个针对具体问题的改善报告,提交
公司管理层;在这个过程中提出的问题要关键而具体,提出的意见要切实可行,建议不要动
不动就“重组”或者有针对性的指责某一个部门,只要是站在公司的立场,老板和员工都会支
持的。

3、每周改进一点点,持续改进,当看到一定的效果后,再向老板提出大的变革意见,
会较容易采纳。

第 573 页 共 756 页
第 8 章 团队管理

题 目:认清楚自己在公司的实际定位,提升自己的专业能力 作 者:谢小雄

作为你目前的实际情况,我个人认为首先自己要摆正自己在公司的地位,这个地位要通
过和老总及各职能部门的经理进行多方位沟通后自己给予的定位。以此为自己开展工作时的
最低底线,和各部门经理搞好人际关系。 http://bbs.mypm.net

处理问题时多进行换位思考,并一定要保持好平和的心态,要以实际的情况下争取
BOSS 的最大支持。

另外在制造业里面存在一个很现实的情况就是,如果项目经理拥有较强的技术背景的
话,会对工作开展有很大的好处。所以要注意尽量提升自己的技术力量,多和研发和工程人
员进行交流。这样对你处理项目推进过程中出现的一系列的问题会有意想不到的效果,特别
是对项目的风险控制是有很好的帮助的。

题 目:把握重点 作 者:li

既然高层认识到问题的所在,又有前车之鉴,你需要让他们看到你的解决方案是实际可
行的重点还是在各部门的协调和威信的树立上,这个过程还需要放慢。
题 目:多做沟通 作 者:龙七

1、对老板一定要做到及时汇报,确认你的做法你的老板支持你。如有不妥请及时和老
板沟通调整。

2、和你平级的同事多做沟通,让他们了解你的能力,同时掌握与他们沟通和协作的方
式方法。
3、了解你的下属,学会从聆听中掌握一些你很难看到的问题,也许这就是你工作的重
点。

4、对业务和内部工作流程一定要彻底了解,这是你工作的平台,你不了解他的架构和
一些潜规则,对你的工作可能会增加很多困难,你可以在你的前任身上学习到很多值得借鉴
的东西。

5、从中国国情出发,请制定计划,但是不要急于实现你的目标,要慢慢来,慢工出细
活吗。

题 目:实践出真知 作 者:suntsang 项目管理者联盟文章,深入探讨。

前面各位提到了很多方法,在此不在累絮,简单一提: http://blog.mypm.net

1、争取 BOSS 支持

2、摆脱项目监管及互相推托的角色定位

第 574 页 共 756 页
第 8 章 团队管理

3、要让你的伙伴认可你

建议向 BOSS 申请,去其它部门蹲点一段时间,调查以前项目再这些部门实施具体碰到


哪些问题,再去寻找解决的方案,“实践出真知”,要让别人也知道你的困难在哪里,毕竟是
团队合作,不是单打独斗,同事是伙伴而不是对手,只是你要让你的伙伴认可,另外沟通也
不仅是口头或文字的交换。

题 目:开场新局面,还得从现实出发 作 者:lik_leon

要靠一个人的力量在短期改变一个长期形成的工作环境,几乎不大可能,并且这种改变
行为还不是由上而下,万众一心的,难度可想而知。所以从心理上未必要背着这么一个任务
包袱去做,否则行为目标就可能会偏离现实,倒是可以带着一个或许会有额外收获的心情去
做。

把项目经理角色转换成职能经理,将项目管理方法根据实际情况,拆散来运用,把方法
中最能改善工作成效的先用,同时一定要有策略的让领导了解并体会到专业的项目管理方法
给企业带来了什么具体的好处。国内很多领导他是不会去关心你用什么高明的方法做事的,
他要看结果,当你的结果让他满心欢喜的时候他会让你放手做事。
项目管理者联盟文章,深入探讨。

所以在我看来,你这个项目经理得有战术战略的去做:
战略: 改变领导的观点,要能让他主动提出“我要让你在公司进行一场项目管理的革命”

战术: 善用并灵活运用项目管理方法,做好当前的每一件事。
项目管理者联盟文章,深入探讨。

8.6 *项目团队如何拥有高的协调性

案例提供者:项目管理者联盟会员 Kevin

★ 案例正文:

案例正文:

徐家龙最近被公司任命为项目经理,负责一个重要但不紧急的项目实施。公司项目管理
部为其配备了 7 位项目成员。这些项目成员来自不同部门,大家都不太熟悉。徐家龙召集大
家开启动会时,说了很多谦虚的话,也请大家一起为做好项目出主意,一起来承担责任。会
议开的比较沉闷。

项目开始以后,项目成员一有问题就去找项目经理,请徐家龙给出意见。徐家龙为了树

第 575 页 共 756 页
第 8 章 团队管理

立自己的权威,表现自己的能力,总是身体力行。其实有些问题项目成员之间就可以相互帮
助,但是他们怕自己的弱点被别人发现,作为以后攻击的借口。所以他们一有问题就找经理,
其实徐家龙的做法也不全对,成员发现了也不吭声,因为他们认为我是按你说的做的,有问
题你经理负责。

团队成员之间一团和气,“找徐经理去”、“我们听你的”成为了该项目团队的口头禅。但随
着时间的推移,这个貌似祥和和团结的团队在进度上很快出现了问题。该项目由“重要但不
紧急的项目”变成了“重要而且紧急的项目”。项目管理部意识到问题的严重性,另派高级项目
经理来指导该项目的实施。
项目管理者联盟文章,深入探讨。

请问: 该项目问题出在哪里? 徐家龙应该怎么做? 谢谢!


http://bbs.mypm.net

点评本案例>>

★ 项目管理者联盟专家点评:

专家介绍:

朱瑾鹏 大唐软件公司大区项目总监

2000 年-2007 年中就职于大唐软件公司作为大区项目总监,曾负责内蒙、天津、浙江、


湖北、北方电信等多省项目管理工作。

06 年成功管理中国网通第一个省级全专业网络告警管理系统建设工作,这是超大规模
本地网全专业整体网络监控系统在中国网通领域的首个省级系统。该项目业绩 06 年 12 月被
人民邮电报头版报道。

05 年升任大区项目总监,期间成功推广浙江综合告警项目,该项目是中国电信第一个
省级综合告警建设项目。03-04 年兼任水利部灌溉水利信息化全国示范项目吉林前郭灌区水
利信息化项目经理;有效的推动了我国水利灌溉事业的信息化水平,该项目获得 1 项发明专
利及多项实用新型专利。 本文转自项目管理者联盟

第 576 页 共 756 页
第 8 章 团队管理

03 年兼任中国电信北方电信 9 省交换网管系统工程 5 省总项目经理,项目进度远领先


于其他友商承建的其余 4 省,用户满意度第一。 http://blog.mypm.net

02 年兼任杭州电信电话网管、业务开通项目经理。01-02 年任青海电信电话网管项目
经理,是中国电信西部十一省综合电话网管系统首获验收项目。

2007 年中-至今 07 年接任 Teradata 公司内蒙移动经营分析项目经理,该项目为内蒙移动


业务发展指标从全国落后到全国领先贡献了极大的价值,该项目投资规模累计过亿。

2007 年 11 月升任 Teradata 公司大区项目总监,管理区域内数据仓库项目群。

2008 年获“中国卓越项目管理者”称号。
项目管理者联盟文章,深入探讨。

专家点评:

各位网友谈了很多,结合大家的评论我从某个角度来分析一下.

解决这个问题方法很多,例如对于项目来讲,要有明确的分工协作关系,要首先明确项
目的组织架构并动态维护。本案例因为成员来自于各个部门,那么代表了不同的专业分工,
是很容易根据他们各自的来源来划定每块职责具体的归属人,就是对于每个岗位每件任务很
容易找到一个“Owner”(负主要责任人),就不至于项目中都压在项目经理身上的情形。由
于项目间由会有很多的互相协助,成员为了其他人帮助自己完成任务,就会尽力的配合其他
人,作为一种工作交换,长久就会形成一种互助的气氛,对于跨角色的任务也会发扬团队精
神去努力协作。项目经理还要多运用软技巧,例如多创造内部交流互助的方式来强化大家相
互了解与协作,营造良好的项目团队气氛等等。
本文转自项目管理者联盟

在这样具体的分工架构下,项目经理应将自身定位为教练员、指导员、调度员,通过良
好的引导规划项目工作,将团队引入成功,而不是势必躬亲。

这个问题发生的根源主要在于项目经理越位,他做了太多本该成员做的事情才导致文中
的后果。这是新任项目经理比较常犯的问题,且多发生于中小型项目中。徐文龙类似的问题
不仅仅出现在案例所描述的场景中,即便是成员全部来自于一个部门的项目,犯类似错误的
也是屡见不鲜。

项目经理为了种种原因亲自去做组员的事,这既打击了组员的积极性,又培养了组员的
惰性,毕竟项目是一个团队,项目经理能力再强也无法替代所有人的工作。项目经理更多时
候的心态应该是一名教练员去指导员工,而不是亲自上场踢球,要致力于创造一个良好的项
目环境让大家在各自的范围分工协作。

有人会问,如果有时候项目经理不仅仅做项目管理方面的工作,怎么办?的确,尤其在
一些小型项目中,项目经理本身的计划、控制、协调等等本职工作并不能占据 100%的工作
量,出于资源、成本等因素还会兼作其他事情,此时,项目经理很容易混淆二者的区别,这

第 577 页 共 756 页
第 8 章 团队管理

也是为什么在小型项目中常发生类似问题的原因之一。项目经理要分清,此时只不过是在项
目管理的这个人身上兼有项目经理的角色加项目成员的角色而已,而不代表项目管理就要去
做项目成员的事,项目经理不能混淆概念,一定要理清角色。所以为了避免常犯案例中的问
题,项目经理要以两个角色身份来区分自己具体的工作,对于兼作队员的那块分工就要和大
家等同起来,按照同样的标准来要求,项目管理那块呢就要按项目管理的来要求。为了清晰
区分,一个方法就是明确项目组织架构图,图中可以设立两个岗位,分别归属于项目经理,
但角色不同。并且要牢记各自的工作输出和资源分片,从技术人员升任项目经理的初期,项
目经理往往出于习惯钻入原来的技术细节,这容易顾此失彼,新任项目经理尤其要牢记这一
点。多名网友的评论也都提到了分工与架构问题.

最后再提醒一点,新任项目经理往往急于建功,有冲劲是好事情,但威信和业绩是逐步
建立起来的,任何硬撑面子往往会适得其反,更加失去威信,将项目拖入死亡。让每个项目
成员在岗位分工上发挥自身的作用,将项目整体引入成功,带领项目团队作战体现领导力,
不断的将项目引入成功,这才是建立威信的根本之路。

★ 项目管理者联盟网友评论:

分析 1:职责、团队、方法论 高喜阳

一个成功的团队是指由不同技能、才华、工作风格和知识体系的成员组成的士气高涨的
团队。项目经理的职责就是将这些人组成团队并激励他们。
项目经理的技能应包括技术技能和管理技能,坚实的技术基础能够在技术方面对团
队起指导作用,管理技能有助于沟通和解决问题。管理技能不仅限于技术方面,还包括解决
问题的能力,估算能力,编制计划的能力,人际和沟通能力。
项目管理者联盟,项目管理问题。

所以本案例出现的问题本质是项目经理对自己的职责没有很好的认识,因此在管理团队
的方法上也就走了偏路。

问题从项目组成员形成了一个习惯(有事找徐...),失去了团队的协作意义,使团队的
实际能力得不到体现,到最后使得项目进度出现严重延迟。 项目管理者联盟,项目管理问题。

分析 2:只竖向沟通而不横向沟通显然不行 李云

作为项目经理,你应该先要引导成员相互横向沟通,无法解决的问题再竖向沟通或开会
协商。这就好比民主集中制,要民主,也要有人说了算。案例中项目经理都是自己拿主意,
但他不可能在每方面都擅长,长此以往,团队形成一种风气,压力全转移到项目经理处,项
目的风险也会越来越大。 http://blog.mypm.net

http://blog.mypm.net

分析 3:项目经理的定位 金锐

我们先澄清一个概念:什么是项目经理。项目经理就是项目中的总经理,总经理的职责

第 578 页 共 756 页
第 8 章 团队管理

是决策、领导。而不是关注所有的事情。 http://blog.mypm.net

本案例中的项目经理犯的错误在我们身边屡见不鲜,其根源最主要在于:

1)项目经理定位不准
2)团队无明确的沟通计划

分析 4:职责的划分 冯琳

首先,项目经理对自己应发挥的作用理解错了,经理的作用应该是组织,协调和监督,
并不是执行具体的事务,是他自己怂恿了属下的行为。 http://blog.mypm.net

http://bbs.mypm.net

第二,在项目实施中应划分职责,确定对应承担的责任,案例中的项目经理显然没有考
虑到这点。

分析 5:项目规划的重要性 汪偉

这个案例说明了项目规划没有做好。 http://blog.mypm.net

出现的问题如下:
1. 项目经理及成员职责没有明确定义。

2. 项目团队的建设及磨合有点问题。对于这种成员彼此都不熟悉的团队,项目经理要创
造机会让成员互相了解,多沟通。 http://blog.mypm.net

3. 项目的沟通计划没有做好。能在项目成员间流动的信息和解决的问题要发挥项目成员
积极性和职责自己解决,解决不了才需要项目经理出面。

分析 6:项目团队如何拥有高的协调性 惠慧 本文转自项目管理者联盟

项目经理和下属都存在问题:

一、作为项目经理,一般要处理好重大而紧急的事件,把握好大方向决策权。时常要激
励下属认真负责工作。

可以采取一些措施来做:

1、开会的会议纪录不一定由秘书做,到会议结束时由项目经理随意指定某人完成。估
计到会的人都会认真听。

2、建立团队协作,充分授权,对分派下去的任务要限期追踪进展情况。

第 579 页 共 756 页
第 8 章 团队管理

二、对于下属而言,要配合项目经理工作,拿出多种备选方案。加强平级间的合作。
项目管理者联盟文章,深入探讨。

分析 7:目标明确、充分授权、团队协作 王超

1、在启动会上没有明确项目的目标以及项目组成员的职责。
2、在项目进行到适当的时候,项目经理没有授权。 http://bbs.mypm.net

3、项目成员之间没有很好的团队协作意识,项目经理也没有能够及时调整调动成员的
主动性。

分析 8:项目经理定位 代燕梅

本项目中出现的问题归根结底原因有以下几点:
1、沟通问题。

既然项目成员之间不太熟悉,项目经理就应当组织大家进行沟通,相互了解,并且对项
目实施的具体情况进行交流,那样才能好好协作,培养良好的团队合作精神。

2、授权问题。

本例中徐家龙什么事都身体力行,这样就导致了什么事情都由项目经理负责的局面,项
目经理应该懂得怎样将权利分发给下级,让下级也分担一定的工作责任,提高工作的积极
性。 http://bbs.mypm.net

3、WBS

本例中徐家龙没有解决好工作任务分解的问题。项目经理应该在项目实施过程中,了解
每个成员擅长做什么并将工作任务落实到每一个人。 本文转自项目管理者联盟

分析 9:项目管理计划 朱行军

项目管理计划中的人力资源管理计划存在问题:

1、项目团队组建以后项目团队的建设没有做好。
2、项目关系人管理工作没有到位。
3、沟通管理存在问题

分析 10:协作与责任 种云峰

1、个人不是全能的,作为项目经理不可能在任何一个方面都是强者。因此,问题尽可
能的在项目组成员间解决,对于一时无法解决的问题,可提交项目经理解决或开会讨论。

2、目标明确,责任到人,才能避免团队中人与人之间的的推诿。

第 580 页 共 756 页
第 8 章 团队管理

3、加强团队建设,协调团队成员关系。
本文转自项目管理者联盟

4、加强项目进度管理。
分析 11:不懂管理的人干了管理工作 dajundalao

管理者的任务是让别人去干你要干的活,没有管理能力的人才自己老是去事无巨细地干
活。

项目的管理是讲究分工协作的,而不是如保险或推销什么的行业,个人英雄大行其道,如
何去管理,是项目经理的事,如何让人去干活,也是项目经理的事。当别人都闲着而项目经理
忙的不可开交,问题一定是项目经理的。 本文转自项目管理者联盟

协调工作是项目经理定性并把握的,沟通工作也是项目经理的事,干活是项目团队的事,
项目经理安排好就行了。至于团队成员之间的横向协调,项目经理界定好就行,没有固定的模
式,它总是在具体的环境中来定的。

分析 12:授权与集权的博弈 珊珊
http://blog.mypm.net

项目经理不是全才,一个好的项目经理可能在项目执行的任何一个专业领域都不如团队
成员,但其之所以可以成为项目经理,是因为具备敏锐的判断力,能够把握正确的方向、能
够调动各种资源(包括自己团队的成员)。因此项目经理如果想管理好项目就应该对项目组
成员充分授权,不能事事都亲力亲为,同时对于重大事项,如涉及费用工期影响的事件,则
视情况而作出决策。

8.7 进度控制中“人”的问题该怎么解决?

进度控制中“人”的问题该怎么解决?

[姓 名] 孙钰 [单 位] 不公开 [邮 件] lbsy923@126.com
[所属行业] 农林畜牧 [所属主题] 项目进度管理 [发布时间] 2006-11-6

【案例正文】
最近在工程管理中遇到以下几个问题:
1、设计承包商图纸供应跟不上进度;
2、生产承包商的资金长期不足,现场项目经理权力有限,技术人员短缺,整体生产进度缓慢;
3、施工承包商过分依赖建设单位,许多问题不能主动去沟通、协调、解决;

第 581 页 共 756 页
第 8 章 团队管理

4、监理不能积极作好事前控制工作、为建设单位进行协调、监管出谋划策。
以目前情况看,在建设单位资金充足的情况下,我认为应该是相应的“人”的问题,包括项目
经理、组织人员及其意识的问题,大家请发表一下自己的看法吧。应该怎么理解和解决这些
问题?

【相关分析】

·管理不能是无序的、自发的,要靠人力推动!(2008-04-02) [作 者] 张海泉 [公 司] 不显示

1. 对于设计供图跟不上进度的情况,应分析起原因。可能是设计投入不足,也可能是业主、设计和
施工几方沟通不足,导致设计对进度没有充分了解而使得供图滞后于现场进度。如果是设计投入不足
的问题,应加强交涉,要求起增加设计人员,并定期检查设计人员到位情况;如果是因沟通不够,应
加强沟通,比如定期召开设计协调会等,对下阶段设计供图计划提出明确要求。
2.生产承包商存在的问题,首先要求给予现场项目经理应有的权限,或者直接要求更换有相关权限的
人担任项目经理。如生产承包商实在不能满足资金、人员等要求,应考虑更换。
3. 施工单位依赖建设单位的问题普遍存在,主要是责任、权力划分要明确。

·明确目标、加强沟通、主动执行计划(2006-11-29) [作 者] 谢仁禄 [公 司] 无

1、项目目标是否明确,如果已经明确,应尽快制定一个沟通计划,加强与各的沟通协调;如果不明
确,需尽快编制项目的总进度计划,包括设计进度、工程发包/分包、材料设备选型/采购、劳动力组
织、施工技术方案、现场施工组织等,对整个项目重新进行统筹安排。
2、项目需有一个能统揽全局的“项目经理”,如果业主直接参与管理,业主的项目负责人应该承担此
重任,如果业主不具有这种能力,应尽快授权给现场总监理工程师承担此重任。如果现有总监能力不
够,应更换总监。
3、加强沟通,明确各方想法,对症下药。采取相应激励措施,形成制度,调动各方积极性。事实证
明只有各方主动工作,计划才有执行力,项目才有可能按计划推进,光靠某一方来推,其它各方消极
不动,项目将停滞不前。

·不知道对不对(2006-11-20) [作 者] 潘琦 [公 司] 北京市门吉利磁电工程研究所

1。在选择生产商的时候不能被公司的表面蒙蔽,如果有条件可以私下和生产商的员工聊聊,或者在
参观后的半个月来个突然参观。
2。如果自称大公司的话,那公司员工的私车拥有量会有一个比例的(比如 30%),国内公司的项目
经理的权力可以说是没有的,因为国内公司的老板不会把权力给自己的员工,因此选择生产商最好是
国外的公司。
3。给施工承包商一定的压力,而且这种压力要不时的给予。
4。还是老问题,国内的不知名的监理公司就是为了走程序和政策上需要才走进工程的,很少有负责
任的,这个问题就得业主和承包商要严格的按照合同去做了,一切以合同为主。

·进度控制中“人”的问题该怎么解决?,(2006-11-13) [作 者] 黄雀 [公 司] 广东

第 582 页 共 756 页
第 8 章 团队管理

用人不疑,疑人不用。

·管理的艺术(2006-11-12) [作 者] 陈圣文 [公 司] 今日园丁科技文化有限公司

所以说管理是一门艺术,不可能任何问题都有一个明确的解决方法。像孙钰提到的这个案例,存在着
多重问题,想一时解决是不可能的。“许多问题不能主动去沟通”,作为一个管理者,平时就要培养领
导对你的信任感才可以的。只有得到领导的信任才可以调动领导这个资源。有了领导这个资源,在项
目中就会顺手的多。

·协调是最好的解药(2006-11-12) [作 者] xiaohu [公 司]
shanxishenlongnengyuanjiaohuagongsi

做好各方面的协调工作,你现在面临的问题,你可以思考西气东输,西电东送这些项目的精典思路。
有时候人力资源同样可以西借东用的

·问题的解决(2006-11-08) [作 者] 张慧勇 [公 司] 赛迪监理

看了你的问题,我觉得可能你完全处于被动当中,甚至感觉很无奈,我认为,既然有这么多问题,应
该项目项目各方聚在一起(项目中能说了算的头头),把问题逐个的明确,并拟定成文,明确各方权
力和义务,各方遵守,并严厉执行,作为项目经理的你更责无旁贷,积极主动的解决,并加大力度,
解决到底。

·进度控制中“人”的问题该怎么解决?(2006-11-08) [作 者] lydia [公 司] neau

无论是什么情况下
与人打交道的事情都会很复杂.

进度控制中有"赶工"和"快速跟进"

要对具体问题进行具体分析.
明确目标,
权衡利弊,
不要抱怨~
要努力改进才好!

·对症下药(2006-11-07) [作 者] 杰罗 [公 司] 无

第 583 页 共 756 页
第 8 章 团队管理

anbh 地分析很好
资金充足的情况下,应加大协调力度,建立共同目标,每一阶段的计划和每一个控制手段都要与合作
方的利益挂钩。特别重要的是,一定要找到一位协调高手和强有力的管理者统筹管理。
1、重新审核计划
2、检查资源配备是否满足计划要求
3、建立工程协调例会,一周或三天,必须是负责人(能调动资源的人)参加。
4、加强跟踪控制,根据进度完成情况奖罚。
5、考虑设计现场办公。
6、施工单位一定要专款专用,可考虑建立专用账户。
7、与施工单位老总加大协调沟通力度
8、根据利益共享原则,监理单位、施工单位采取积极的和有效措施为建设单位产生的效益,建设单
位拿出一部分奖励。
9、抓关键人物,抓典型。监理单位的总监水平非常重要,如工作不力,考虑换人。
必须注意的是,你看到的原因未必是真正的原因,包括合作方反映的。因此,多调查,特别是合作方
中的小角色和不满现状人员往往透露有价值的信息。
总而言之,必须对症下药,才能有效。

·实际中的通病(2006-11-07) [作 者] 饶崇辉 [公 司] DETE

1、你的问题是项目管理中的共性问题,作为投资方的管理,这几个问题是你对现状的抱怨。首先要
先解决你自己的问题,进度目标是否明确可行,线路和关系是否妥当,有没有设立适当的激励机制和
手段,重要的是对参建各方的要求和给报酬是否适当。
2、如果上述问题都解决了,那就需要更细致的管理,将项目进程中的每一个具体问题都列举出来,
将分析解决分给项目管理的每一位同志,由简入繁;
3、更重要的你要保持高度的热情和信心,把自己的积极情绪传染给周边的同志和相关各方;

·快速跟进的风险(2006-11-07) [作 者] xing jianming [公 司] 重庆城市建设投资公司

孙钰你好:
看了你的案例就知道,你是按照快速跟进组织项目.任何快速跟进的组织方法都是有风险的.在你决定
采用这种方法组织项目的同时,你应该对此产生的风险进行评估.确定你对此风险的承受度和相应的
风险储备.现在看来你项目中的主要问题就是发生了快速跟进的风险.如果现在风险的影响在你的承
受范围内,那你就不必惊慌,尽量降低风险的影响,将工作节奏调整到正常的状态上来.
要满足这点,你必须找到风险发生的原因.有时侯也不完全是设计院的原因,你要检查一下你的功能需
求是否提交完善.设计的技术标准是否有缺陷.这些都会影响设计单位的工作滞后.
你在案例中所指的人,实际上都是你的合同相关单位,他们与你是买卖双方的共赢关系.在这个案例
中,主要问题还在业主方面,因为造成这种状态是由于业主快速跟进的组织风险所引起的.如果你是
该项目的业主方项目经理,你不但要尽快的调整好项目状态,同时还要做好合同相关单位的沟通工作,
避免索赔事件发生.

第 584 页 共 756 页
第 8 章 团队管理

·奖罚重要(2006-11-06) [作 者] anbh [公 司] beijing

既然建设单位资金充足,那么事情就很好解决:
1、根据项目的进展设定目标,对设计单位、施工、监理单位等进行奖罚,重点是奖,主要对各承包
单位的一把手。力度尽量大些。
2、如果这些分保单位的上级还可以合作的话,可以定期与上层进行沟通。保证各分包单位的上级对
项目支持,包括人员、资金和政治上的支持。
3、进行必要的惩罚,对现场不力的分包单位一把手清除出现场。首先要沟通,迫不得已才这样做。
应该做时就尽快做。
4、根据项目的进度进行付款,对分包单位进行成本核算。如果项目足够大,应要求分包单位在现场
设立银行帐户,保证专款专用。
5、业主要放下业主高高再上的心理去工作。项目经理没有权力,那么就抓住他们的上级领导。业主
既要当好爷爷,必要时也要当好孙子。
6、沟通、沟通、再沟通、
7、在此种情况下,建设单位要有专业人才进行项目的组织。技术和管理上的专业。

·进度控制中“人”的问题该怎么解决(2006-11-06) [作 者] 汪成 [公 司] 五洲工程设计研究

这种现象在工程实施过程中经常遇见,你不妨先组织各方项目经理和总监召开一次协调会,把利害关
系说清楚,强调并让大家充分意识到合同的严肃性,让大家都当面说,不要背靠背。并形成记录。如
果效果不好,可以分别找各单位的负责人,充分分析工程的现状及存在的问题,要求适当调整人员甚
至组织结构,以适应工程建设的要求。一般来说这样基本可以解决了,当然可能有更深的问题,这种
情况也曾见过,那就只能置之死地而后生了。

8.8 项目中“额外”的事

项目中“额外”的事

[姓 名] Ting [单 位] 上海公司 [邮 件] yiyizq@163.com


[所属行业] IT 软件 [所属主题] 项目团队管理 [发布时间] 2008-7-25

【案例正文】
所谓额外,是项目初期指未分配给自己,分给其他项目成员的事;这些额外的事,
通常也是比较复杂、费神、甚至劳累的工作!指定负责该项工作的人员中途离职,

第 585 页 共 756 页
第 8 章 团队管理

或者能力有限或者推诿拖延,导致工作质量不佳,处于“半完成”状态。比如:复杂
报表开发,系统数据的导入,超出原计划项目范围的工作等。通常项目成员都不愿
意承担这种工作,而只愿守在自己的职责范围内,管好自己的一亩三分地。

根据以往的项目经历,的确存在认真有责任心的、能力较强的成员付出较多,而一
些善于捣浆糊的成员则会把困难任务推出去,自己偷懒;这也使得原本付出较多的
成员心里不平衡,而不愿意接这些烫手山芋。心态是我干了这些事会引来更多的麻
烦,不愿意“多事”。

这种项目状况该如何处理?

【相关分析】

·个人见解(2008-08-08) [作 者] 尹兴富 [公 司] 云天化

对于这种情况我个人认为公司领导应该尽量安排别的人选专门负责,最好不要把这种烂摊子给之前为
涉及到此工作的而又正在负责其他工作的员工,因为倘若把这个任务分给其他有具体工作的员工,一
来会让员工本身的工作强度增大,其次,会让员工觉得这是一个烂摊子,工作不好做,最终只会让员
工的进去心受阻,最好的办法是另聘新人,或是从其他项目进行调任

·同意[至尊月]和[小马哥]所说的,PM也是项目成员之一,所有成员都在为项目服务(2008-07-31) [作 者]
高喜阳 [公 司] 北漂

一个项目团队要想把项目做好:
一、项目组成员之间的协同
二、项目任务分解及分配
三、PM 对项目成员技能了解成度
四、团队成员的责任心

以上四点任何一点有问题,案例的情况都会出现。

要想避免案例中的情况出现,最主要是处理好[二]和[三];
对于[一]和[四]不是 PM 可左右的,所以做为 PM 不能因为项目任务的分配或员成任务完成有问题,将
更多的事情原因归为已,但是对于 PM 而言,通过几个项目的运作,要对所掌握的项目组成员有所了
解。。。。。

·表现奖励(2008-07-30) [作 者] 李阳 [公 司] 暂时还没有

这样的事情我也回碰到,你是高层员,他们的表现都会在你的眼中,你可以根据你的见解想你的上级
讲说,向那些工作付出多的,表现好的给予奖励这样应该回是那些捣浆糊有点上进心

第 586 页 共 756 页
第 8 章 团队管理

·支持小马哥(2008-07-30) [作 者] 至尊月 [公 司] 软件部

小马哥说的很有道理,额外和意外差不多,很难让人接受,根源就是要根据成员的特点分配工作,这
样才能做的更好

·认真反思,激励解决。(2008-07-30) [作 者] 小马哥 [公 司] 保密

(1)出现这种情况时,作为项目经理应该认真反思了,是不是对每个项目成员的能力、特点评估不
足,没有量才而用?
(2)项目工作的连续性对于项目的成功非常重要,要在分配工作之前,认真分析每个人的特点,根
据各人的能力和积极性来安排工作,并对过程进行动态监控,及时消除导致中间撂挑子的诱因,维持
项目团队的稳定。
(3)对于那些已经发生的此类事件,要制定相应的激励措施,来鼓励合适的人来承担这些“额外”的
工作,对这些“临危授命”的人加大奖励,从而在项目部或公司形成一种不怕困难、勇于解决问题的风
气。

·传输快乐工作的观念(2008-07-30) [作 者] 至尊月 [公 司] 项目管理部

其一:个人认为,我们在工作过程中,不应有这种“额外工作”的想法,每个人在公司里拿工资,都
有工作的义务,没有说哪个工作归哪个所有的问题,只是分工不同。所以工作分配过程中,PM 应该
做及时调整,但不是给另外员工“额外工作”,而是将工作转移到适合于此工作的员工而已。所以关
于额外工作一说,只能说明 PM 在工作分配时不当,而且未对其错误计划进行修订造成的。
其二:PM 在给每人分配任务时,应考虑使每人在完成工作的过程中,都会有相应的成长,只有让每
个员工都感觉到自己的成长,才能让项目团队中的所有成员都积极努力的工作。如果大家都觉得自己
多干活是为自己着想,那额外工作便不是额外工作,而是能力提升的经验。有了这样的团队,就不可
能会有额外工作一说。

·答复“自我牺牲,树立榜样”(2008-07-29) [作 者] Ting [公 司] 上海公司

这种说法没有可操作性!
项目经理不可能有时间、有精力去解决非常复杂的编码问题!

·提前防范和适当解决(2008-07-29) [作 者] YHY [公 司] 铁路部门

1、案例出现此情况,说明前期计划、任务分解分布、成员技能估计、责任分配矩阵制定不合理或有
不充分的地方,因此,首先要对成员能力、任务分布、计划等进行重新查验、分析和调整。
2、各项目中出现能干就多干的情况也较普遍,这可通过合理的绩效考核、奖金分配、多劳多得等激
励措施,来平衡和激发员工的积极主动性。
3、即使采用以上方法措施,任何项目都不可能做到完全“一碗水端平”,多少存在一些平衡因素和

第 587 页 共 756 页
第 8 章 团队管理

心里,这就需要通过正式、非正式沟通、经理首先以身作责等,形成良好的团队氛围,强化团队集体
目标,从长远上解决此事。

·定人、定责、定进度(2008-07-29) [作 者] twz [公 司] 铁路运输

1.出现这种问题,说明项目经理没有把合适人的放到合适的位置上去。在分配任务时,一定要充分考
虑到个体差异,最好在分配任务前能征求一下团队成员的意见。
2.能力较强的成员付出较多,这是一种普遍现象。问题是他们的付出是否得到过适当的回报?比如晋
升机会、资金以及其它待遇等。
3.分配任务实际上就是和团队成员形成了一种契约关系。分配给自己的任务,能做就把它做好,不能
做及早提出来。而出现案例中的问题,说明团队成员间的沟通是存在一些问题的。
4.过程监控、跟踪不到位。分配任务后,项目经理应经常了解项目的进展情况,并及时调整相应的计
划。

·自我牺牲,树立榜样(2008-07-28) [作 者] chow king lam [公 司] beria consultants limited

作为领军人物,遇到这种情形恐怕就只有以“我不入地狱,谁入?”的心态来承担额外的工作,然后
看看成员中有谁不忍心的,分担一些过去。经过患难与共的日子,建立更坚实的队伍,对未来的工作
将更有把握。

·付出终归有回报(2008-07-28) [作 者] 邢建明 [公 司] 重庆城市建设投资公司

案例所提及的事情是现在的团队成员中的一种普遍现象。美国员工他们注重自己的工作范围。超越工
作范围的事不愿多做一点,自己工作范围内的事情认真地做。中国员工存大致存在两种状态,一是不
愿付出,二是有目的的付出,真正无目的付出的人很少。我作为项目管理的一位老者,把我的经验告
诉大家,搞项目管理的人不要怕付出,你真诚的付出终归可以得到回报。只是汇报的形式不同,通常
付出可以得到三(jing)的回报,这就是:经济;经验;精神。只要你真心的付出,你至少可以得到
三者之一的回报。

·回复肖勇(2008-07-28) [作 者] Ting [公 司] 上海公司

这些事也不能叫琐事。琐事是容易完成的,只是工作量的问题。这些事都是有些难度的,而且发生在
资源比较紧张的情况下。

·项目中“额外”的事(2008-07-28) [作 者] 肖勇 [公 司] 湖南开远信息技术有限公司

第 588 页 共 756 页
第 8 章 团队管理

在分配任务时,这些事情就必须考虑到,如果是有过项目经历的项目经理更清楚,这些也不叫额外的
事,只是琐事多,就事情本身来说,难度不大,这个时候,可以考虑,对这些任务做一个分解,每人
做一点,或者说,也可以指定项目中任务轻的人来完成,同时在项目会议上可以指出,再教育大家一
些努力

·所有的付出都将得到回报!(2008-07-25) [作 者] 王金龙 [公 司] 保密

我们都知道:伟人们之所以伟大,正是因为他们完成了普通人难以完成或不愿完成的事情,我们也许
有时会嫉妒那些比我们有成就的人,也曾感叹过世事的不平,之所以如此,正是因为我们忽略了他们
在许多事情上比我们多付出的心血!
在工作当中中,肯定有一些比较棘手、麻烦,所谓“额外”的事情存在,而在一个团队中,也必须有
某些人愿意多付出并且有能力处理这些额外的事情的人,这些人就是我们常说的所谓能力高的人,可
以想象,如果提升的话,不提升这些人提升那些人呢?
所谓“举秋毫不为多力,见日月不为目明”,只做平常的事情,只能是个平常人,只做份内的事情,
只能说明是个本分人,但并能不能成为优异的人,那些“额外”事情必将有人完成。

8.9 无技术背景的 PM 如何凝聚团队力量?

无技术背景的 PM 如何凝聚团队力量?

[姓 名] shore [单 位] 跨国民企 [邮 件] progress@ry165.com


[所属行业] IT 软件 [所属主题] 项目团队管理 [发布时间] 2008-4-14

【案例正文】
本人基本没有软件项目背景,只有项目管理经验。现在在一家大型跨国民企任重大
软件项目专职 PM,工作任务是从筹备阶段介入,完成项目成功交付并保证客户满
意度。目前正在交付第二个重大项目。

因本人不懂技术,而项目组里的工程师都很强,他们不仅技术好,而且都做过小项
目的项目经理,这就导致了项目组成立后,大家都不是很信服我,从而使得团队凝
聚力不强,项目推动力很弱。目前,我的做法是跟着大家一起起早贪黑,拉近距离,
产生信任,从而凝聚大家。这样做虽然起到一定的作用,但非常累不说,对我的项
目管理水平也并没有带来很好的提高。

请问:怎样做才能既轻松调动大家积极性、增加团队凝聚力,又能在实战中提高自

第 589 页 共 756 页
第 8 章 团队管理

己的项目管理水平?

【相关分析】

·把握好每次机会(2008-08-05) [作 者] 徐康 [公 司] 上海互联网软件有限公司

作为一个没有技术基础的人去管理一个技术团队,从某方面来讲的确很难,但是我自己感觉在一个团
队中,针对一个项目是否能成功,技术占的份额还是很小的,所以,现在主要的问题是要在团队中树
立自己的威望,一味的配合他们做事是不对的,对自己今后的项目的发展只能带来更大的阻力,所以
我的看法是抓住每次机会去展现出自己的能力和魅力,让你的客户服你,更让你的团队服你。

从另方面讲,你可以不懂技术,但是软件项目管理的知识还是可以学习的,我感觉项目管理和其
他的管理者都是有很多的相似的的,所以抽时间赶紧充电。

同时,在项目中找一个大多数佩服的一个人,而这个人是你在一定的时间内可以很好相处的人,
当然这个人的技术不需要是一流的,但是决不能很差,否则没有意义,主要是在技术方面可以帮你参
谋。

最后说一点就是,在很多时候会遇到这样的情况,但是我想我们大家要调整一下管理的流程,找
到适合我们的管理机制,这是我们大家共同提倡创新的,难度更大。

·处乱不惊(2008-07-01) [作 者] 沃双喜 [公 司] 保密

充分利用你得管理和方法方面的经验。每个人都有长处,关键在于如何利用长处,另外,思维的框架
始终要保持清晰,这样才能不乱阵脚。把握好心态,展现你优秀的一面,同时也要给机会让别人展现
他们优秀的一面

·优秀的项目经理(2008-06-06) [作 者] zhuangqm [公 司] sdrcu

目前 PM 具备了管理能力,但还需要领导能力,这点十分重要。至于技术方面的知识,需要和团队成
员多多交流即可。优秀的项目经理需要的是领导能力、管理能力、沟通能力以及项目管理知识等。

·从全局考虑(2008-06-01) [作 者] 连甲虎 [公 司] 力帆汽车

建议从全局考虑,认真听别人的意见,组织团队成员一起交流。在关键的时候展现自己的长处。管理
模式都是大同小异,提拔一名助手,帮你分析技术方面的重要节点,你来统筹全局

·真的无技术背景?(2008-05-25) [作 者] chow king lam [公 司] beria consultants limited

管理软件项目可以不懂技术,有点不可思议.我觉得你成功的首要条件是你的队伍中所有人都没有当
(或晋升)项目经理的雄心.

第 590 页 共 756 页
第 8 章 团队管理

·尊重他人,控制风险(2008-05-23) [作 者] Steve [公 司] 上海

作为不懂具体业务的 IT 项目经理,要管理项目是比较困难的。如果充分信任和尊重下面的技术人员,
他们也会理解和尊重你。但是需要控制好风险,对项目进行很好的监控。

·别拿鸡蛋碰石头(2008-05-23) [作 者] 胡安保 [公 司] 上海佳律

技术人员解决技术问题,管理人员解决管理问题。案例中的主人公发现了管理上的问题,却用错了解
决的方法。主人公要想让下属服从,应该在关键时刻示之以威,树立威信。同时要善于发现下属的困
难,主动帮助他们。最后,要确保整个项目顺利运作,不出重大事故,做到了这一点,无论你在项目
中发挥的作用如何,你已经是一名成功的项目经理。

·技术协同,共同努力!(2008-05-21) [作 者] 陈罡 [公 司] 北京

建议针对该项目设立一个技术经理的岗位,招一技术高人协同你一起带领团队,这样您可以发挥管理
特长,技术人员协同你解决技术问题。

·无技术背景管理项目(2008-05-20) [作 者] 朱行军 [公 司] 保密

既然你有管理经验那么你就应该利用管理的方法去管理你的团队,“劳心者治人,劳力者治于人”,
你可以根据 WBS,只抓里程碑或关键点的事件,或者提拔一个技术高的人协助你。

·你面试的时候是怎么跟老板说的(2008-05-20) [作 者] 张宏 [公 司] 无

你面试的时候是怎么跟老板说的,现在就怎么做。

·无技术背景的PM如何凝聚团队力量(2008-04-29) [作 者] 江海云 [公 司] Flextronics

你必须得有一技之长让别人信服。当然,不必拘泥于技术方面。你可在团队管理方面,亦可在语言沟
通方面。另外,有足够时间和精力的话,建议你也学学相关的技术基本知识。如此以来,一方面,你
可更快融入到你的团队中去,另一方面,也不至于因为对技术一无所知而在应付客户时频显尴尬。

·自身定位要准(2008-04-23) [作 者] fancy [公 司] 辉大信息科技公司

您好!

第 591 页 共 756 页
第 8 章 团队管理

在你说的这个团队里面,技术人员的技术能力很强,而你做的项目管理,依我来看,不仅仅是技术在
其中发挥作重要的作用,而更重要的是如何发挥自身的项目管理的特长,而不简单的去跟随他们做事,
你要定好自己的位置。这个才是关键,现代企业,管理依然是十分重要的一个方面。就看你如何给自
己定位,如何充分发挥自身的专业优势了。

·无技术管理技术(2008-04-20) [作 者] miaoleming [公 司] 苏州

无技术怎么管理,只有跳了,还有什么办法呢

·使出你的降龙十八掌(2008-04-18) [作 者] 李云 [公 司] 深圳市技术中心

很简单,你技术不如他们,而老板却安排你去管理这个重大的项目,他一定是看重了你的某些长处,你
要在关键时候把它 show 出来,以提高你的影响力.例如我公司一哥们,也是做 PM 而不懂技术,研发团队
里开始没人服他,直到有一天,公司来一日本客户,在旁人都一筹莫展的时候,他用非常流利的日语和
客户有说有笑,一下子他在大家心目的地位就提起来了!连领导也不敢小看他。我相信你是有能力之
人,不过你现在做的是拿自己的短处和别人的长处比,所以你还没有收到什么效果。希望你能成功。

8.10 项目经理真的很轻松吗?

项目经理真的很轻松吗?

[姓 名] 孟晓林 [单 位] 网络业务部 [邮 件] meng@chinadu.org


[所属行业] IT 软件 [所属主题] 项目团队管理 [发布时间] 2007-11-27

【案例正文】
A、B、C 为同一项目小组成员,其中 A 为项目经理,主要负责与用户的沟通及项
目分解;B 负责项目中的技术实现,C 负责项目文档的收集和整理。

C 的工作虽然简单但是格外繁重,因而多次向 A 提出增派人员的要求,A 也认为 C


的工作量过大,需要增派人手,因就此事多次与上级领导沟通。但每当上级领导就
此事询问 B 情况时,B 总是说 C 的工作不算很多,而且 A 的工作比较轻松,让 A
帮助一下 C 就可以了,不需要增派人手。因此,领导不同意 A 关于增加项目组成人

第 592 页 共 756 页
第 8 章 团队管理

员的建议。

A 在了解完情况后与 B 进行沟通,B 的理由是 A 的工作确实不多,总是给这个人提


点意见,给那个人提点意见,但是 A 从来不自己做事情,所以 B 认为 A 有时间来
帮助 C 完成工作。A 试图从岗位责任、项目分工等方面对 B 的这个误解进行解释,
又试图利用换位思维的方法向 B 说明真实情况,但 B 依旧坚持自己的看法,认为 A
给自己的工作太少……

请问:如果你是 A,你会利用什么样的方法来解决这个问题呢?

【相关分析】

·项目管理知识普及(2008-05-31) [作 者] 孟孟 [公 司] 新浪

作为项目经理,应该让项目组成员了解组中每个成员的工作状况,在有可能的情况下可以换位一下,
这样可以增加对其他人员的工作认同。
另外,也是非常重要的,就是加强对组成员的项目管理知识培训。不论是开发工程师,还是文案人员,
或是其他职位,都需要基本的项目管理知识。从大方面来说,对他们的职业生涯有帮助,小方面来说,
可以自行管理现有的工作,也能够使他们有作项目管理的意识,从而理解项目经理的处境。

·领导力 影响力(2008-03-07) [作 者] gaozhen [公 司] shandongjingjixueyuan

领导就是带领一帮人一起做成一件事,做好领导不是一件简单的事,所以出现了上面的情况。
如何做好领导呢?
领导:领,导。领好,导好。
做领导,不要只看到风光,还意味者责任的承担。私下认为领导要有强烈的责任意识,要勇于承担责
任。
领导要和自己的手下处理理好关系,厚道做人,科学做事应该是领导的品格。
要多做事,先把自己领导好,再去领导别人。
如此,领导的影响力应该不小了,离成功也不远了。

·分工不明,领导不像领导!(2008-02-21) [作 者] 李允鲁 [公 司] 华能

首先,工作分工要明确。即然是明确了 c 的工作,那么就要根据 c 的工作来制定合理的人力资源的分


配。你不可能要求说:“老板在打高尔夫,让他帮文秘做点工作吧!”
其次,在现在的企业制度里,下级不越级汇报,那么上级也不应该直接越过其他的领导去了解工作情
况,调查除外!否则项目经理的威信何在?!

·项目经理的责任在于统筹规划和指导意见(2008-02-21) [作 者] 范兰旺 [公 司] 广东外语外贸大学

第 593 页 共 756 页
第 8 章 团队管理

首先表明一下基本观点:b 的思想和做法不可取。b 作为项目小组的成员要服从项目经理的安排。更


重要的是思想上的一致,虽然有时候你更觉得自己有道理。

再者是项目经理 a 的问题。首先肯定 a 要做到尽责的项目经理话工作不轻松。项目小组成员分工


明确确实可以分清楚责任和提高效率。自己作为项目经理应该对各项工作都由比较深刻的了解,帮助
成员解决问题。c 的问题是否是添加一个员工就可以解决的呢?或许添加多了一个人可能导致整个项
目组的冗员。这是应该考虑。

·项目经理的素质(2008-02-20) [作 者] liuxueqing [公 司] morse

作为项目经理,个人素质很重要,必须有足够的领导才能,才能带领组员顺利完成项目
沟通固然重要,作为经理必须实时了解每位组员的工作状况,处理事情要有自己的主见
合理安排各人的工作量以及协调沟通

·沟通、分工(2008-02-18) [作 者] 许四胜 [公 司] 北京无限立通通讯技术有限责任公司

项目经理应该与成员多进行沟通,计划任务、工作量等需要公开,让所有相关人员都清楚,知道自己
的工作计划,了解别人的工作。

另外,分工不同,工作内容不同,只是层面的不同导致对同一任务的不同理解,这需要彼此交流与理
解。

不同的工作岗位对工作有不同理解,如果依据个人的观念而否定项目经理的要求,项目想不失败都难

·沟通、认识(2008-02-17) [作 者] 王祥 [公 司] 石油化工建设公司

前面提到的沟通非常有道理,c 和 a 对 c 的工作任务繁重是有共识的。从 b 的反馈信息来看,他认为


其他二人的工作量都不大,这就反映出他对其他二人工作职责任务并不一定很清楚。作为一个项目,
在项目的大目标已经明确的前提下,首先要进行目标分解,并落实到人,此外还要工作流程的明确,
我想大家都了解流程后,对其他人的工作量总会有个大概的认识。 同时,组织既然任命项目经理作
为负责人和协调人,就要进行充分授权,避免其他因素对工作的影响。看到一些项目,项目经理好像
对人员和资源没有调动的权利,这对项目的政令畅通是不利的。

·项目经理真的很轻松吗?(2008-02-15) [作 者] 吴军 [公 司] 管道局

A、B、C 三个人都有各自的分工,各自工作有不同的侧重。如果我是 A,我还是会要求给 C 增加一个


助手,在最大限度减少成本支出的前提下,保证工作可以有条不紊的进行。

第 594 页 共 756 页
第 8 章 团队管理

·团队成员间的有效沟通是项目成败的关键(2008-02-15) [作 者] 岱庄矿 [公 司] 煤矿

本案例主要是项目团队缺乏有效沟通造成的,其次是受个人知识范围所限,知识面窄造成,A 做为项
目经理有直接责任。
首先,做为项目团队的主要责任人,应经常召集三人小组互相通报情况,相互间了解工作进度及各自
的工作量;其次,A 应主动向团队成员通报自己所担负的工作计划、任务及负担的责任,争取支持,
搞好相互间的协作;三,在团员相互间充分了解的基础上形成一致意见,及时向上级领导汇报情况,
争取支持;四是与客户加强沟通,侧面反映项目组遇到的困难,利于问题的解决;五是加强团队成员
的知识培训,在增强专业知识能力的同时,增强管理知识的学习。

·交流(2007-12-14) [作 者] 21 [公 司] 3123

交流最重要

·协调与沟通(2007-12-13) [作 者] limoshuai [公 司] 海弯

首先来说 A 没有做好本项目小组的内部协调沟通工作。本部门的内部都做不好如果去对公司领导和客
户的沟通呢。
再来说,A 没有搞好具体工作的分配,三个人每人具体分配所负责的工作。

·实现是建立业务详细而明确的基础之上(2007-12-01) [作 者] 亭长 [公 司] 北京易事通科技
有限公司

项目经理在做计划的时候尽量细些。由于项目经理承担整个项目计划、控制、协调、沟通所做的事情
比较多而繁杂。有些工作很难以工作量来衡量。所以在做计划的 时候明确任务以及要达成的结果,
而 C 工作事项目能否顺利进行的关键,没有详细而准确的客户需求、以及相关业务、技术文档资料,
B 的工作很难开展。试想一个需求都不是很明确的功能,怎能谈的上实现,而实际上 B 的工作是很简
单的。在做计划的应该适当让 B 参与 C 的部分工作。

·管理工作者的工作安排(2007-11-30) [作 者] 卓宇 [公 司] 杭州某公司

在项目中,通常会把主要工作量关注到实际的实现工作中,忽视管理成本。
B 明显是技术人员出生,并从未担任过项目管理的相关工作,因此,B 并不了解作为项目经理,在项
目管理上所花费的工作量。这种情况下,A 很难用言语让自己的观点得到 B 的认同。所以,在与 B 沟
通前,A 至少应做好计划中的管理计划,将所有的管理工作列入项目计划中,并在项目周会上说明管
理、技术实现、文档收集和整理 3 部分工作所花费的工作量及进度情况,让 B 清楚地了解到除了技术
实现外的其他工作量。

第 595 页 共 756 页
第 8 章 团队管理

当然,我并不认为通过这种方式能够让 B 认同项目经理的工作,但是至少 B 会了解到除了技术,原来


其他工作也是需要花费大量的工作量的。
另一方面,有详细的数据支持,领导自然会同意给 C 增加人手,该项目的问题可以得到解决。
项目完成后,可以安排 B 参加项目经理培训,作为资深的技术人员,无论是否会往管理路线发展,参
加项目经理培训,了解熟悉项目经理的工作职责、工作内容都是有必要的。通过这样的培训和一些案
例分析,相信 B 的资质不至于到不能理解的地步,以后的项目中也不会再出现这样的想法了。

·分析与办法(2007-11-27) [作 者] 孟广燕 [公 司] 青岛有线电视网络有限公司

项目经理给下属的感觉是工作任务不多,可能来自两个方面:
1、项目经理不太参与具体工作,对别人指手画脚太多;
2、项目成员的资历太老,不服气经理,希望项目经理多干点。
办法:
1、项目经理应该注意多起带头作用,用模范党员的要求干好工作。
2、与资历较老的员工多沟通。非正式沟通。

8.11 如何分配项目奖金

如何分配项目奖金

[姓 名] 孤独剑 [单 位] 不公开 [邮 件] wangxujun59@sina.com


[所属行业] IT 软件 [所属主题] 项目团队管理 [发布时间] 2006-10-30

【案例正文】
我们公司是一家 IT 企业,我是软件部的项目经理。每做一个项目,项目组提成整个
项目有效金额的 3%至 5%。项目提前一个月完工,提成 4%,提前两个月完工,提
成 5%。这些资金由项目经理来分配,同时公司也规定,项目经理首先可以提成整
个项目资金的 40%至 50%(我一般只提成 40%)。剩下的和项目组成员一起分配。
我一起想建立一个公平,有激励意义的分配制度,但一起没有好的分配方案。

我首先把自己分配办法写在这里,请大家指导好的地方和不足的地方,更欢迎各位
提出自己更好的根本办法出来。

优秀主工程师多提成 10%;

第 596 页 共 756 页
第 8 章 团队管理

主工程师确定办法:如果项目中没有难的模块需求开发,则不设置主工程师;如果
有难的模块需要开发,则设置主工程师。主工程师采用竞争制。项目经理公开项目
模块需求,工程师写出模块设计方案,谁的方案最优,谁做主工程师。

优秀主工程师标准:

1)、准时,保质完成工作。既模块开发工作在要求的工期内,按照需求准时完成,
并移植到正式环境。移植到正式环境的必须是测试员测试通过的。如果主工程师延
期完成,拖延一天减少 1%的提成。
2)、剩下的金额按工作日分配。

补充:

1)我们同时可能有几个项目进行,项目成员可能同时在几个项目组。
2)、项目有段时间工作量多,有的时候少,这是软件开发的特点决定的,如需求调
研的时候,或试运行阶段。

·客观考评(2008-05-31) [作 者] ggk [公 司] 房地产

从工作承担重要程度及比例、计划达成率、工作完成质量、执行过程中的综合表现等方面制定客
观的考评办法,进行评分,依据考评得分进行数学权重计算奖金分配比例。

·fdss(2008-05-23) [作 者] 王玉娜 [公 司] 上海天马微电子有限公司

根据项目计划展开,制定项目内容和项目任务,即难度和时间和所需资源,制定判定标准,大家
竞争上岗。奖金=工作量*工作难度*完成时间

·多设置分配项目(2008-02-29) [作 者] wangjinju [公 司] 宁波

对奖金的分配以系数形式,比如;有加班加点的,工作的难易程度,工作的完成程度

·集权(2008-02-16) [作 者] 丁鼎干 [公 司] 杭州安费诺飞凤通信部品有限公司

由项目经理在公司允许的制度下面分配,项目经理根据项目团队成员的平时表现进行评价的基础

·按绩效分配(2008-01-22) [作 者] 李永新 [公 司] SAP company

项目奖金除项目经理外,其余成员应该按照绩效来分配,绩效的评定可以通过工作的劳动成果来
核实!

第 597 页 共 756 页
第 8 章 团队管理

·如何分配项目奖金 (2007-08-29) [作 者] tjh [公 司] cxgs

按照工作量和工作质量进行奖金的分配是较为合理的。
在项目的开始阶段,就要明确每个模块的大约的工作量(当然按照一定的标准进行核定),然后
按照均衡的原则分配给开发人员,难度较大的模块必然其工作量就会偏大,因此不考虑这样的问
题。
工作的完成必须是经过测试人员测试的程序,以后一旦模块出现问题就可以按照一定的标准来评
定工作的质量。
以上的方法可能更加稳妥一些。

·项目奖金的分配(2007-07-11) [作 者] 毛毛 [公 司] 科瑞康

●项目奖金的计算方案:
§项目总奖金(实际奖金)=P*项目立项预算奖金
§项目经理奖金=M*项目总奖金
§项目成员奖金总额=(1-M)项目总奖金
§项目成员个人奖金=Z*项目成员奖金总额
→P:项目团队绩效综合考核系数
→M:项目管理层奖金系数(M<1),为项目管理层奖金占项目总奖金的百分比。由公司管理层根
据项目实际情况确定。
→Z:项目个人奖金考核系数,∑Z=1(项目成员人数 Z 和),
●项目奖金的发放
§在项目通过验收后一个月内发放

·如何分配项目奖金(2007-06-09) [作 者] xxkywjhg [公 司] 新乡开元计算机有限公司

软件部的项目经理。每做一个项目,项目组提成整个项目有效金额的 3%至 5%。项目提前一个月完


工,提成 4%,提前两个月完工,提成 5%。这些资金由项目经理来分配如何分配项目奖金如何分配
项目奖金如何分配项目奖金如何分配项目奖金如何分配项目奖金

·参考绩效,综合评价(2007-05-15) [作 者] slm [公 司] 上海海达

每个人都有一个经历,那么根据其自身的经历,考虑可能适任得岗位,同时进行全程跟踪。
全程跟踪的目的除了根据不同情况进行分配岗位外,同时也可以解决项目奖金分配问题,同时可
以掌控整个项目过程,知道目前所在情况,潜在问题,随时调整进度。

·如何分配项目奖金(2007-05-15) [作 者] liuhongbin [公 司] seasun

第 598 页 共 756 页
第 8 章 团队管理

按照工作量和工作质量进行奖金的分配是较为合理的。
在项目的开始阶段,就要明确每个模块的大约的工作量(当然按照一定的标准进行核定),然后
按照均衡的原则分配给开发人员,难度较大的模块必然其工作量就会偏大,因此不考虑这样的问
题。
工作的完成必须是经过测试人员测试的程序,以后一旦模块出现问题就可以按照一定的标准来评
定工作的质量。
以上的方法可能更加稳妥一些。

·如何分配项目奖金(2007-03-01) [作 者] 胡月 [公 司] Siemens

我觉得再分配项目奖金方面要从两方面考虑:1、应该重点奖励功臣,因为他们是项目成功的关键,
使项目组的中流砥柱。奖金的多少直接反映着对他付出的承认。2、另一方面,也不伤害大多数人
的自尊心,使大家感觉大家是一个整体,项目的成功包含着项目组每一个成员的心血与汗水。

·如何分配项目奖金(2006-12-24) [作 者] 刘用 [公 司] 广东省建筑集团公司

分配任务前一定要了解自己的下属,合理分工!不同的工作要因人而异!工作的态度一定要认真.
应该开展依次轻松的团队活动(如组织郊游)。在一种轻松和谐的气氛下,组织团队成员畅谈对
以前版本的看法。你要仔细地去感觉成员们对次的反映。然后充分总结出以前版本的成绩和对新
版本的贡献。同时分析以前版本的不足之处,要让团队成员大家想法,如何对不足之处进行改进,
整合可用的部分作为新版本的可用资源。这样,你在不知不觉之中获得了你的专家权力,增强了
团队的凝聚力。同时也给你的新项目提供了廉价资源。节省了时间,降低了成本。我不是做 IT 的。
本意见是从项目管理的角度提出。妥否,字自己权衡。

·当自己吃肉时,别忘给别人喝点汤(2006-12-02) [作 者] 刘明 [公 司] 北方重工

提到分配问题时,我想起一个故事。相传中国近代上海滩,有一个黑社会老大叫黄金荣,他有一
个小弟叫杜月笙。有一次年末,黄给小弟们分钱,当杜分到后,连声谢都不说,撒腿就跑。黄很
奇怪,就派小弟跟踪看个究竟。原来,杜拿到钱就跑,急着给他的小弟发钱去了。黄感叹道:不
出几年,这上海滩就是他的天下了。不出所料,几年后,杜月笙做了上海滩的第一把交椅。
我有所悟,在有肉吃时,别忘给自己干活的人喝汤!

·奖金分配系数(2006-11-26) [作 者] karik [公 司] 暂不显示

如果可以引入系数概念,也许可以形成一个数学模型。

第 599 页 共 756 页
第 8 章 团队管理

举例:一般工程师,系数为 1,主工程师,系数为 1.5;

工作量系数:事先估算的工作量按基数比例确定系数,如总工作量 10 万行源代码系数为 1,某模


块预计源代码 3 万行,工作量系数为 0.3;

工作完成系数:到预计时间到达 100%,系数为 1,完成 30%,系数为 0.3

弊端:系数的概念或许好理解,但是怎么确定这个系数值,怎么考核,考核工作的工作量怎么确
定,怎么获得成员认可并推广,都是问题。

只是一种思路。

·平均分配(2006-11-24) [作 者] xu [公 司] 8

我认为其余奖金可平均分配,因为在很难分清谁的作用大的时候,平均分配可能是最好的分配方
法,虽然这可能不是最公平的方法。但不会造成项目组的不稳定。对项目的管理起到正面的作用。
因为每个人对项目贡献的大小,可能是因为其工作岗位决定的。

·人均分配(2006-11-20) [作 者] 潘琦 [公 司] 北京市门吉利磁电工程研究所

你作为一个项目经理,那你一定要有个人凝聚力,一个项目组就是一个团体,人人平等,在奖金
分配问题上应该征求大家的意见,最好是人均分配(不是主张大锅饭)

·ABC分配(2006-11-17) [作 者] 姚金胜 [公 司] 江苏省计算技术研究所

1、作为软件部项目经理,不可能只做一个项目,可能是以后更多的项目,对于你的团队要分核心
人员,一般人员,按照重要程度 ABC 分类。
2、重要的核心人员 A 类,在层次上要分配多一下。A 类有多人的话,可根据 IT 技术的重要程度、
对他人的指导作用和项目贡献分配系统
3、BC 类人员,主要可从工作量等角度分配,以激励对本项目的贡献

·固定加浮动奖励(2006-11-14) [作 者] sparrow [公 司] 航天部

一下是我对你案例的建议,不过需要你在项目过程中有详细的纪录:

你可以拿出奖金的一部分,比如说一半,按人头均分,余下的作为浮动奖励,通过浮动评分进行

第 600 页 共 756 页
第 8 章 团队管理

奖励。浮动评分可以这样进行:

例如:模块框架有谁制定得 10 分,技术难关有谁解决得 5 分,里程碑延迟扣 1 分,等等。打个比


方,最后这个团队的得分是 100 分,就把那一半剩余的奖金分成 100 份,按每个人的分评分,这
样相对量化一些。

·对IT项目不能按照工作量来分配奖金(2006-11-10) [作 者] 刘华 [公 司] 项目部

楼上的讲“看了你的案例,我认为IT项目再这方面的管理比我们工程项目好做的多.”“IT
项目的工作包更好用时间来定量”。
我不这么认为啊,建筑的可以用资源和人力来顶替,比如今天少建了一层楼,明天多叫 100 个民
工来就能赶上进度。
而我们的项目,比如微波天线一个指标的增益不够,这时候你就是叫多少人来也没有用啊,在比
如,你需要的一个进口关键器件突然告诉你停产了或者禁运了,你怎么办?
关于分配项目奖金,我认为不能评工作量来分配,尤其是有难度的 IT 项目,对于关键专题的解决
者,他的工作日可能只有 2、3 天,可是如果换了一个人可能 2、3 个月也不能解决,大家都等着
啊。我认为作为项目经理,在分配奖金的时候,应该结合工作关键程度和工作量来考虑。所谓“千
军易得,一将难求啊”!,当然如果您的项目在业界难度一般,随便找一些中等技术人员来都能解
决的话,你的分配方法也是很科学的。

·分配奖金(2006-11-08) [作 者] 张慧勇 [公 司] 青牛软件

同意邵兵的看法,难得糊涂啊。呵呵~~

·分配奖金!(2006-11-08) [作 者] lydia [公 司] neau

分配奖金是激励的一种措施,
不要把性质弄错了!

·情感投入(2006-11-06) [作 者] 邵兵 [公 司] 齐齐哈尔

L.斯达西.亚当斯在 1965 年提出的确定奖筹公平与否的关系式(O1/I1=O2/I2)我想您一定知道。您


在对团队进行效绩考核的时候,考虑到大家的内心感受了吗?您与团队成员的沟通做得好吗?世
界上没有一台绝对准确的天平,如果团队成员都能成为朋友,谁还会计较正常分配制度下的一点
漏洞呢?
仅供参考。

第 601 页 共 756 页
第 8 章 团队管理

·如何分配项目奖金(2006-11-03) [作 者] 桂君 [公 司] 合肥市伟联科技有限公司

可以建立一个责任分配表,并与绩效考核结合,实行公平公正
建议将其划分成两个部分:基本的和奖励浮动部分
基本的部分可以在公平公正以及绩效考核的基础上来分配
而奖励浮动部分可以分配给对项目有突出贡献者,能力较强者,完成工作质量突出者等(关键是
如何划分奖励指标,不能太多,又要能够起到激励和提高项目水平的作用)

·项目团队的激励和量化分配(2006-10-31) [作 者] 宋学军 [公 司] 北京海创恒信科技有限


公司

很赞同两位的分析,特别是 xingzhou 的精彩分析。一个项目团队的工作态度很重要,大部分的公


司都选择了奖励和惩罚制度,对于团队成员进行激励。但这不是激励团队成员的唯一方法,这个
不能在这个案例中分析。
既然是软件项目,那么 WBS 就显的尤为重要,只有把整个项目细化了你才能作出正确的责任和奖
励。既然分了模块就有轻重和时间的约束,整个量化的过程实际上在软件项目中是很困难的。可
能一个很小的模块,但是它能牵一动全身,所以这个量化的标准你要把握好,不然会对团队成员
造成不良的思想动态。
既然有多个项目在同时进行你更要把握好你分给团队成员的任务量,你更要了解他所接手的其他
项目中他所处的角色,要及时的和其他项目的项目经理进行沟通。
只是一点小小的看法,供大家一起交流。

8.12 团队中有大量合作公司人员如何管理

团队中有大量合作公司人员如何管理

[姓 名] zhangzijiang [单 位] 不公布 [邮 件] zhangzijiang007@hotmail.com


项目团队
[所属行业] IT 软件 [所属主题] [发布时间] 2005-12-26
管理

【案例正文】
某外包项目,工期 1.7 月,需要人员 19(总体 33 人月)其中,外公司有 10 人,内部
正式员工 6 人,新人 8 人。
外部员工技术和经验都不错,但他们所属的公司与本公司有竞争关系。所以参加人
员不很配合。尤其是这些人所在的公司经理和本公司的高层经理是同学朋友,在项

第 602 页 共 756 页
第 8 章 团队管理

目没开始前,已经确定用他们的人。作为项目经理考虑到该公司无良好业绩,风险
很大,不同意他们独自组成一个组的要求,但高级经理却答应了对方的要求。结果
到中期,这些人员抱怨自己分担作业太多,
(实际是按平均分配的)提出加人的要求,
声称不同意就撤退,高层经理又做了让步。外部人员自己管理进度,不服从项目经
理的管理结果最后外部人员的作业没有如期完成,造成很大范围的返工,整个项目
评价很低。项目经理被责辞职。

遇到这种状况,怎样实施人员管理呢?

【相关分析】

·团队中有大量合作公司人员如何管理(2007-08-31) [作 者] tjh [公 司] cxgs

项目经理在项目组成立时就应该向高层要求得到足够的授权

·责任矩阵和沟通协调(2007-04-27) [作 者] 姚振华 [公 司] 中兴

作为项目经理,在这种情况下,一般会受到比较大的打击。
个人觉得,在上任前,需要首先谈到两点:
1.外部公司的技术员工,参与到这个项目中来,他们是如何定位的,他们需要完成哪些责任,我方应
提供哪些,同时需要明确,财务支付的操作流程。
2.在了解上述情况后,与你的高层经理协商,提出自己的想法和一些风险观点,让他明白你的处境,
这样以后会好沟通一些。

在做好以上两点后,在项目中,需要随时监控你的计划,及时调整。

·用数字说话(2007-03-21) [作 者] 龙七 [公 司] AMDOCS

和项目的方方面面沟通是必须,也是 pm 的日常工作之一。
了解项目的全部信息也是项目经理的工作,虽然需要花很多的时间,但是这个工作非常有好处。至少
可以预防一些不该发生的事。
人员管理确实不好管,需要很多的技能。但是一个好的做法是量化每个人的工作,这样的分析报告可
以说明每个人的工作量和工作效率。在这个报表面前,我想没有几个人可以狡辩。

·团队中有大量合作公司人员如何管理(2006-11-06) [作 者] cao xi [公 司] RA

1。和那名高级经理沟通,指出目前你发现的问题和解决方法:做好沟通,得到支持。
2。作为项目经理,首先应该有足够的风险意识。可以同意将他们作为独立的一个外包公司来对待。
但是让他们指定一个项目经理,负责协调他们自己的人员和进度。然后以书面的形式规定他们要完成

第 603 页 共 756 页
第 8 章 团队管理

的任务,进度,到某个阶段要进行检查的内容,到期限的交付物和延误进度的惩罚。要对方项目经理
签字。要经常和此项目经理进行沟通。

·团队中有大量合作公司人员如何管理(2006-03-02) [作 者] YYC [公 司] 不方便说

典型的中国传统人情式经营,建议项目经理和哪个高级经理一起被辞退
第一:项目经理既然做了这工作就要负责,抵制住压力,他没有这么做,证明他着方面不合格。一个
字“辞”

第二:那为高级经理,没有从公司的角度考虑问题,不比多少还是一个字“辞”

·竞争合作伙伴(2006-02-16) [作 者] meconsea [公 司] 山东和华中税

只是一个陷阱而已!

存在竞争关系的很大程度上不可能成为合作伙伴的。

·项目经理在项目组成立时就应该向高层要求得到足够的授权(2006-02-16) [作 者] 张青
山 [公 司] 浙江西安交大龙山软件有限公司

项目经理在项目组成立时就应该向高层要求得到足够的授权

·团队中有大量合作公司人员如何管理(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

只要大家专注于工作,不成问题.

·加强沟通(2006-02-02) [作 者] johnson [公 司] 保密

1,加强与上级的沟通。说明不能独立成立小组的原因以及存在的风险。
2,作为项目经理,敢于说“NO"。无论对谁,必须坚持原则,否则自食恶果。(项目经理被责辞职)

·官私合营的复杂组织(2006-01-21) [作 者] bill [公 司] 肯康服务有限公司

我认为项目经理可选的方法还是比较多的
其一: 如果高层经理有权有势,项目经理认为无抗衡的可能
1 就应该积极的融入,争取高层经理的认同

第 604 页 共 756 页
第 8 章 团队管理

2 就是在分工的时侯就可以在高层参与下签订责任状
3 如果外部小组违约自然难以获得高层的认同
其二:
如果高层经理更上层的领导比较支持项目经理,自然可以借力打力,高层经理也不敢太多偏护

总之,最能与外部小组形成一个团队,否则就把他当作外包供应商,事事都小心看护,出了事,冤
有头债

·干系人分析(2006-01-15) [作 者] 李石求 [公 司] 北京齿轮总厂

也许您应当进行干系人分析,但更重要的是,您应当揣摩领导的意图,也许您本来就是个替罪羊,但
即使如此,您也应该先摸摸领导的真实意图

·问题(2006-01-13) [作 者] 李立 [公 司] ngd

在意识到存在风险的时候,没有对其进行分析,找出解决方法.

·和高层经理沟通(2006-01-04) [作 者] 秦轶 [公 司] 中国网通集团研究院

建议和高层经理进行多方位的沟通,了解高层经理在本项目的深层目的。
用经典的话,就是进行干系人分析。

·任鹰说的有道理(2005-12-31) [作 者] 牛小林 [公 司] 有空就来

其实,对于任何一个项目经理来说,这都是个陷阱工作,就好像回答一个问题:

你知道猪说:“不知道”的故事吗?一样,无论你怎么回答,都避免不了最终的结果。

要不就是大声呼喊,推卸责任,要不就是赶紧躲开,别无他法。

·职能组织和项目组织(2005-12-30) [作 者] 贺晓宁 [公 司] 中科院软件所

按照这位兄弟的描述,两家公司合作,其实就是职能组织的一个变种,一味的使用项目组织去管理必
然出现的结果。

·无奈的大环境(2005-12-29) [作 者] 任鹰 [公 司] 暂无

第 605 页 共 756 页
第 8 章 团队管理

看了这个兄弟的案例,感悟很深。
的确处于两难境地,我也曾碰到很多这样的项目案例。
两种方法:
一种:得过且过,争取将责任大的工作分给那些人。
另一种:辞职。

·体制不明,管理混乱(2005-12-28) [作 者] 戴耕 [公 司] 房地产营销策划公司

从案例来看,问题出在体制上。首先,项目部成立的时候,管理体系没有建立好:项目到底是谁对项
目负责,也就是谁是项目的管理并对项目的成败负责;其次,本公司与合作公司是什么样的合作方式;
还有,项目部、公司的权限如何设置。从案例介绍中来看,这方面的基础工作没有做好。另外,公司
高层领导的作为也直接干扰了项目经理对职务工作的正常履行。还有,从案例介绍中,个别高层领导
还有腐败之嫌。
在这种情况下,项目经理可以做的是:
1.坚持原则
2.向本公司及合作公司高层提供风险预警报告,明确告知问题的严重性及可能产生的后果,并提出解
决方案。
3.向本公司高层陈述合作中存在的问题并提请重新考虑与合作公司的合作关系。
4.如果这样还不能引起重视,就越级向董事会反映。
如果连董事会都无能为力的话,那你就只好辞职了!

·个人觉得对项目范围的界定做的

·项目管理不是万能的(2005-12-27) [作 者] 牛小林 [公 司] 有空就来

项目管理不是万能的,不可能解决全部的问题,为此:
1。作为本项目的项目经理,首先做到风险预警和分析,及时把问题暴露出来,让足够的高
层知道,同时声明你的解决条件,如果不能够提供条件将产生的后果。
2。把所有交流的过程用邮件或者项目会议纪要的方式保留下来。
3。对没有回复或者没有能够及时解决的问题,采取定时跟踪,通知所有相关利益者的办法
推进。

如果采用以上方法还不能够免责的话,我建议辞职。

·项目管理不是万能的(2005-12-27) [作 者] 牛小林 [公 司] 北京直真节点通信技术开发有限


公司

项目管理不是万能的,不可能解决全部的问题,为此:
1。作为本项目的项目经理,首先做到风险预警和分析,及时把问题暴露出来,让足够的高
层知道,同时声明你的解决条件,如果不能够提供条件将产生的后果。

第 606 页 共 756 页
第 8 章 团队管理

2。把所有交流的过程用邮件或者项目会议纪要的方式保留下来。
3。对没有回复或者没有能够及时解决的问题,采取定时跟踪,通知所有相关利益这个的办
法推进。

如果采用以上方法还不能够免责的话,我建议辞职。

不够充分(2005-12-27) [作 者] 张冰 [公 司] 北京北方数惠系统技术有限公司客户支持部

前面的兄弟提到了项目的风险预警与消息通报机制.但是我不知道那位项目经理是否对各个合作单位
的分工,工作界限做了明确的界定.

8.13 特殊的项目组成员如何管理?

特殊的项目组成员如何管理?

[姓 名] 薛先生 [单 位] 不公开 [邮 件] train98@21cn.com


[所属行业] 综合应用 [所属主题] 项目团队管理 [发布时间] 2005-11-14

【案例正文】
我所在部门是软件开发部,主要进行应用软件系统的开发和实施。公司为完成一个
交通行业的总体解决方案,需要进行前期的调研工作,为此成立了一个项目组。我
是一名普通员工,担任了这个项目组的项目经理。而在此项目组中还有三位成员:
一个是我所在部门的部门经理,一个是我所在部门的部门副经理,还有一个是普通
员工。这也就是说:另外的三个项目组成员有两个是我的顶头上司。为了能够完成
好这个项目,我该如何做?

·明确项目经理该做什么(2008-02-26) [作 者] 申恩慧 [公 司] IT

首先明确项目的本质一个调研性质的项目,将项目所需要做的工作内容细分,了解老板这样安排
的意图,比如你的经理和部门经理安排在此类项目中必不可少,原因是他们比你更有经验,他们
会提出更具体的解决方案给你,而你需要做的就是把工作划分,制定出项目里程碑,每一项任务
由谁做更合适,然后执行下去。
你担心的也许是他们都是我的领导我该怎么去管理他们,其实你的思想是错误的,项目经理只是
把控整个项目的进度保证项目顺利的完成,不存在管理的问题,在工作过程中你可以多听取他们

第 607 页 共 756 页
第 8 章 团队管理

的意见,以表示充分对他们的尊重,用感激的心情来和两位经理一起做事,当然人际是复杂的,
要做好还要看自己的修炼。。多多努力哦。。。完成了你又进步了一大截了。。。

·按项目运作(2008-01-24) [作 者] dajundalao [公 司] 暂时保密

目前你的项目在前期调研阶段,因而需要做可行性调研、投资分析等,以给领导一个的总体决策。
目前给你的资源已经富余,由于你只是一个普通员工,你所缺的不仅仅是资源,还有经验。给你
两个上司主要是为你经验筹备的,也许,这是领导给你锻炼的机会,好好把握。
为了完成好这个项目,你最好按项目的方式运作,先进行工作分解,明确分工,之后开展具体的
工作。进行工作分解前先听取上司的建议和意见,这是给你指路和分享经验的机会,好好把握吧。
你应该扎实地干具体的工作,尽快熟悉流程掌握关键点,从而积累经验,为日后类似的工作做好
铺垫。
另外,初做容易出错或考虑不周,这不要紧,不要垂头丧气,有两位上司为你保驾护航,这对你
来说,是一个迅速成长的绝妙机会。祝你好运!

·特殊的项目组成员如何管理? (2006-12-23) [作 者] xiaoping [公 司] 昆明理工大学

扬长避短,集思广益,加强沟通,沟通、协调、合作,
我遵循项目管理做好我的本职工作
第一:和我的项目使用方用户沟通,制定项目计划,在此过程中我时刻和我的部门经理联系,项
目计划由我的部门经理参于这样项目整体把握不错,而且我们部门经理给我提了很多见意性的主
意.
第二:和用户沟通一些软件功能性的修改,我要和让产品经理沟通,通过与用户产品经理沟通达
到功能修改
第三:用户这的一些关系处理,市场部的大区经理一直在做,有时我也和大区经理一起参加一些
客户请餐或和客户一起K歌.
第四:项目的一些琐事及杂事和一些文档资料整理全是我和另二名普通员工一起做的.我只是比
其他二名员工在项目中沟通各个关系.
其实我这个项目运作的好,是我们公司的人为文化,大家都很宽松乐意助人,当然自己也要努力
完成这个项目.

·正常履行职责(2006-11-30) [作 者] 王颖 [公 司] 央视市场研究

不要因为项目组里有特殊成员而影响了你的正常工作,单位既然让你来担任项目经理,证明你有
这个能力,不用因为有 顶头上司而使你变得不知所措,只要你可以很好的与组员进行沟通,正当
行使你的权利,我向大家会对你的工作做出肯定的。

·接受挑战,展现自我!(2006-04-27) [作 者] 安乃红 [公 司] AMDOCS-LONGSHINE

也许看起来很难,但是只要你做了足够的准备,我相信,你能成功。你担心的问题就是你要面对
的风险,那就把这个风险弄清楚,分类对待,尽力避免风险的发生。你的准备要包括你的项目的

第 608 页 共 756 页
第 8 章 团队管理

相关只是,还要有项目管理的相关知识,最重要的是你的心理准备好了没有?

·特殊的项目组成员如何管理?(2006-03-24) [作 者] 冯科能 [公 司] 中国发达水利工程有


限公司

沟通、协调、合作!

·特殊的项目组成员如何管理?(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

一般而言,部门经理的沟通能力强,部门副经理的技术能力强。而你是一名普通员工,在某些方
面一定有不如部门经理们的。

·特殊的项目组成员如何管理?(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

部门经理一般是某一方面的专才,或者说在某一方面比较擅长;而项目经理就要考虑一些比较全
才的人选,不仅懂技术,而且擅长沟通协调,

·特殊的项目组成员如何管理?(2006-02-11) [作 者] 刘海 [公 司] 广东省广州市

首先要弄清楚部门经理、部门副经理的为人怎样?

·珍惜机会(2006-01-15) [作 者] 李石求 [公 司] 北京齿轮总厂

1:项目制的作用之一为为员工提供了一个培训和锻炼的机会
2:您可以通过此机会,想您的上司学习,当然,细节工作得您多跑跑腿,因为您的上司在您的项
目组中无非就是个顾问的角色,当然,也可能可以利用您上司的关系资源

·难点在项目之外(2005-12-23) [作 者] 老七 [公 司] 信息化集成商

你这个项目组具有的特殊性,我想之所以成立这样的项目组有两方面的原因:
1、你们公司的气氛比较融洽,有良好的沟通机制
2、你在工作中很突出,有机会向管理人员发展

至于如何做好这个项目的工作,有几点意见(本人考虑不是很周详):
1、项目工作的难点在于组内关系协调,这个问题是在项目管理知识范畴之外的东西,这是锻炼人

第 609 页 共 756 页
第 8 章 团队管理

际能力的好机会。
2、如果是首次做这种大规模项目管理,你所要展示的能力是执行规范化流程的能力,做事有板有
眼、一丝不苟。
3、大部分具体的工作要由你自己来完成,或者指导员工完成。

另外,我对你这个案例很感兴趣,现在项目开展一个月了,你是如何开展工作的?怎样分配项目

组成员的职责,怎样来召开例会?望有机会多交流!文字

·也并不是说只有另外一个普通员工可以干活(2005-12-23) [作 者] duanlj [公 司] 不透露

两位领导之所以参与这个项目组,证明有些问题需要他们去解决,不管是对公司领导还是对外,
协调的工作多为他们做,协调方面需要你做的,你有了设想后需要回报给他们取得同意。

需求调研的细节工作还是得你和另外那个同事做,还有你的先定出一个可行性工作计划

·你能行(2005-12-20) [作 者] 张小洁 [公 司] 江苏新城集团

这是公司给您的一次机会,扬长避短,集思广益.利用经理的睿智和员工的实战,别忘了加上你
的果感,将这个项目出色的完成.

·相信自己(2005-12-16) [作 者] 阿虎 [公 司] 广州市依万达电子科技有限公司

绝大部分公司对项目经理的“责”定得很明确,而“权”、“利”是模糊不清的。你的项目成员
比较特殊,我觉得重点还是在沟通上面,做好部门经理、部门副经理的沟通工作,让他们明白在
这个项目中的职责。能做到部门经理、部门副经理层次的人都是明大理是非的之人,不用担心,
相信自己的能力,把项目当做一件普通的工作来完成就行。

·掌握相关知识,问题迎刃而解(2005-12-14) [作 者] 赵新 [公 司] 工程公司

看一看项目经理的责、权、利就知道如何处理了。

·你的问题是什么?(2005-12-13) [作 者] 温垚 [公 司] 上海

你的问题是什么?仅仅是项目人员特殊?还是项目人员特殊,引起项目分工不容易实现?还是管
理过程无法完全实现?或者是实际项目资源(人力)不能完全被使用?自己先想想,当前遇到的

第 610 页 共 756 页
第 8 章 团队管理

问题,否则有些空泛了。

·明确项目目标,确定各自角色,积极有效沟通(2005-12-13) [作 者] 周全 [公 司] IBM

作为项目经理,建议你用系统化的思考和计划来考虑所面临的问题:
1.你管理的项目的目标是什么?基线是什么?(项目范围,时间,成本)
2.要实现上面的目标,需要什么样的角色(职责定位)?
3.这些角色由谁来担当(可能一个人要担当几个角色)?部门经理在其中担任什么角色?副经理又
担任什么角色? 这一步如果各方能够达成一致意见,你下面的工作就好开展了
4.与项目组成员多进行有效的沟通---注意“有效”两字,你要考虑两位经理的性格/面子等等因
素,采用恰当的方式多与他们进行正式和非正式的沟通(这是体现你人际交往功力的地方)
5.遇到矛盾和冲突时,多结合项目目标来考虑,这样容易达成一致。

·尊老爱幼,然后,该怎么做就怎么做。(2005-12-12) [作 者] 司 [公 司] 北京某软件公司

尊老爱幼,然后,该怎么做就怎么做。

·找准定位(2005-12-12) [作 者] 刘小龙 [公 司] 不公开

首先你要给出自己定好位,找准自己在项目组成员中的位置.从职务上来说,给了你一个项目经理
的位置,实际上,你是否有能力完成好整个项目?当然,这种能力是多方面的,不仅体现在技术上,更
体现在沟通等这些非技术的因素.你的项目组员中有你的两个上级,你如果利用得当,可成为你的
良师及好的搭档,如果处理得不好,则会成为你的障碍.

·这样的项目组成和我所处的角色一样(2005-12-11) [作 者] 武晓燕 [公 司] 一家软件公司


做项目实施工作

我是在 2005 年元旦员工大会上,由公司在会上宣布任命项目经理的,主要负责我们公司的一个项目


实施,我的部门经理及研发部的产品经理和市场部的大区经理还有二名和我一样的普通员工都是
我的项目成员,其实我只是一名普通的员工,这样命名我的职责我很高兴公司对我的培养但是我从
来没做过项目怕做不好,不过我们公司有个和协宽松的工作气氛,大家都很帮助我,公司任命我做
项目经理主要是我这个做事比较灵活沟通能力也可以,以前公司中和各部门相处都挺好.
就这样我负责这个项目实施,我主要是做以下的工作
我遵循项目管理做好我的本职工作
第一:和我的项目使用方用户沟通,制定项目计划,在此过程中我时刻和我的部门经理联系,项
目计划由我的部门经理参于这样项目整体把握不错,而且我们部门经理给我提了很多见意性的主
意.

第 611 页 共 756 页
第 8 章 团队管理

第二:和用户沟通一些软件功能性的修改,我要和让产品经理沟通,通过与用户产品经理沟通达
到功能修改
第三:用户这的一些关系处理,市场部的大区经理一直在做,有时我也和大区经理一起参加一些
客户请餐或和客户一起K歌.
第四:项目的一些琐事及杂事和一些文档资料整理全是我和另二名普通员工一起做的.我只是比
其他二名员工在项目中沟通各个关系.
其实我这个项目运作的好,是我们公司的人为文化,大家都很宽松乐意助人,当然自己也要努力
完成这个项目.
不要想太多了,记住我们都是为这个项目在努力,所以一个好的部门经理做你的项目成员是非常
好的.不要把项目中的关系想的太复杂了.祝福你成功

·分工负责(2005-11-27) [作 者] czg [公 司] HEQIYUAN

1.根据每个人的具体情况,四名项目组成员分工负责;
2.认真听取他们的意见,如你感到他们的意见不正确,加强沟通,多与他们交流,取得一致看法;
3.为了共同的目标努力干吧!

·从另一方面考虑(2005-11-24) [作 者] 常川 [公 司] 暂不公开

别忘了给自己的前途着想一下,如果另外两个领导能提拔你,那这个项目是你大展宏图的时机,
做好你的项目管理,留住领导的面子,向他们展示您的管理才能,这是一个提升的好机会!当然,
若属于权力交叉,完了!撤吧!

·首先共同点,协同作战(2005-11-23) [作 者] lukynfj [公 司] 上海某环境工程技术有限


公司

首先要弄清楚部门经理、部门副经理的为人怎样?是不想承担责任只想捞功的还是实实在在做事
情的?对于实实在在做事情的,则很好办,根据他们的不同长处分配不同的任务;对于不想承担
责任只想捞功的,则只有你费力了,不过这样下来,你这个项目经理也很难做的;

·在现在的国内的软件企业的项目中这种搭配很不好(2005-11-21) [作 者] 赵宏伟 [公 司]
东信北邮

1,项目经理的权力肯定不会很大
2,在项目中的各种计划决定 多少会受部门经理的影响
3,项目的实施过程中权责不是很明确
4,由项目经理带头的项目团队建设很难开展

第 612 页 共 756 页
第 8 章 团队管理

5,不知道谁为这位项目经理授权,是为了锻炼你,还是要有一种权衡,权力斗争的结果
6,利益相关者有其团队内部的冲突会更多,需要更灵活的沟通

·项目组里自然PM最大(2005-11-19) [作 者] 孟晓林 [公 司] BIZSKY项目部

有点不明白,为什么会把部门经理和副经理放到项目组中.但是我认为,一个项目当中既然设立了
项目经理,那么项目经理就应该有自己绝对的权利范围.对待这样既是领导有是下属这个比较尴尬
的局面,我想多做沟通应该是第一位置的.另外,对于这两个人员被安排到项目组中所处的角色一
定要明确,该做的事情是什么在做 WBS 的时候就要确立清楚,到时候对事不对人就好了.

·项目的意义(2005-11-18) [作 者] 李刚 [公 司] 海达公司

成为项目经理是一件令人感到愉快的事正确的组织和管理自己的团队是你展示项目管理能力的最
好反映;
至于团队的成员在贵公司的身份地位对于整个项目的成功策划与实施可能有一定的影响,但你是
团队的管理者就不要考虑的太多。
项目管理中的沟通管理是很重要的一部分,你作为一名技术骨干肯定要发挥技术上的强式,引导
整个团队向良性的方向发展。

·量才适用(2005-11-18) [作 者] 喻国军 [公 司] 研发

首先祝贺你,有部门经理和副经理这样的牛人在项目组。
一般而言,部门经理的沟通能力强,部门副经理的技术能力强。而你是一名普通员工,在某些方
面一定有不如部门经理们的。
首先,你对项目进行一总体分析,得到一项目任务清单。项目中,一定有某些场合要与项目业主
方高层人物沟通的,也有一些项目范围,合同条款的明确,这样的工作,可以安排给部门经理,
让他着重来控制项目的需求,限制需求无限扩大。要知,一个稳定明确变化不多的需求是软件系
统成功的一半。在他的沟通过程中,你也可学着点怎么做事。
项目中也会有一些技术要求很高,难道大的部分,这些工作可以安排给部门副经理,一些成员的
技术培训也可让他来做。
作为项目经理,充分利用成员的才能,为项目服务,最终达到项目目标。

·在你项目组的成员都是你的下属(2005-11-17) [作 者] 至尊月 [公 司] 项目管理部

不要想其他的问题,在你项目组的成员都是你的下属,其他的时候他们是你的上级,在安排工作
的时候,不要考虑不属于你的工作,该如何就如何!
其实领导在组内也有好处,省得很多汇报,也比较容易沟通,出了问题,也会有人给你提醒,这

第 613 页 共 756 页
第 8 章 团队管理

可是个不同寻常的机会呀!
千万记住要做好自己的活,有领导在,你如果做不好的话,会死的很难看的。

·克尽职守,与人为善(2005-11-17) [作 者] 曹楠 [公 司] 中国网通北京市分公司

项目组成立后作者处于两个角色,一个是所处部门,担任的是职员的角色;另一个是项目组,为
领导角色。
我个人认为你应该以公司安排为原则,属于部门的事情就要服从领导,做称职的下属;属于项目
组的事情就要有自己的表率能力,不能因客观级别的高低而附和两位领导,做到克尽职守。最忌
讳的是惧怕两位领导因为命令他们在项目组里做事情而把一切重担交由另外一个同事,这样不但
不会引起两位领导的好感,而且还会得到同事的歧视。项目组是独立的,区分开其与部门的关系。
真正的领导是有气量的,不会因为你在项目组里做他们的领导,而心怀怨言的。
大家都是为了公司的利益而工作。任何一个组织,无论身为领导还是职员都要与人为善,不因职
位尊卑而转移。

·菩提本无树(2005-11-17) [作 者] 天羽 [公 司] 林源教育咨询

这样的项目组形式非常利于沟通,项目变成了部门的项目了,项目组成员都与项目和部门的利益
密切相关。

现在你要做的就是一板一眼的履行项目经理的职责就好了。

有的时候人不需要想得太多,简单的想具体的作,遇到实际问题后在寻求答案。不可以事前想得
太过复杂,那样的话简单的事情都会被搅得复杂了。

·项目经理的人选(2005-11-16) [作 者] 王生 [公 司] 广州智能化有限公司

部门经理一般是某一方面的专才,或者说在某一方面比较擅长;而项目经理就要考虑一些比较全
才的人选,不仅懂技术,而且擅长沟通协调,从某种程度上说,项目经理 75%以上的时间都是用
来去和项目组内外的人去沟通、去交流,技术上不用太过于出类拔萃,重要的是整合团队的能力!

·你为什么会成为项目经理(2005-11-15) [作 者] 一孑 [公 司] 一孑工作室

你为什么会成为项目经理,是因为你有技术上的优势,还是其他?是谁来任命你成为项目经理。
项目组是向谁汇报?是否会出现权利交叉?
建议更要加强你们之间的沟通,可能你的工作会主要以项目具体细节工作为主,决策事情还是由
部门经理控制,但你应该有你所突出的优势,建议还是调整好自己的心态,发挥你应有的能力做

第 614 页 共 756 页
第 8 章 团队管理

好当前的工作。也许这是一个好机会。

·决策时多尊重两位部门经理的意见(2005-11-15) [作 者] globemobile [公 司]
globemobile

决策时多尊重两位部门经理的意见。

·我看人的问题是最大的问题(2005-11-14) [作 者] aoxiang [公 司] 山东

我觉得人力资源是个大问题,中国的项目,很多都败在人的问题上了,正如楼上的所说,如果是
部门经理故意如此安排,还好一些,如果上司安排,那简直就更麻烦了,这个团队几乎就是个摆
设,部门经理根本不能起到促进作用,反而也许会起到反作用。

·项目经理的定义(2005-11-14) [作 者] 孙先平 [公 司] Infinite company

这有点让人看不懂,为什么不让部门经理兼任项目经理呢?必然有些考虑:
1、两位部门经理可能有其它的事情需要做;
2、两位经理主要是进行一些技术把关,因为调研这种事情需要与用户反复进行沟通和开会什么的,
整理资料等
所以我觉得你这个项目经理更多的事情是要做些协调和辅助性的工作!你需要对一些事情负起责
来,同时又要不断地提醒自己,有四只眼睛盯着你,你在做决策时需要更多地征求两们领导的意
见!
更多的时候,你可能需要跟另一个普通的员工一起整理资料、干些杂活!
这其实是个很好的机会!

·在中国这是一个问题(2005-11-14) [作 者] 王海飞 [公 司] utstarcom通讯有限公司

楼主的确痛苦,因为在中国这种现象的确是个问题。我感到疑惑的是,为什么要如此来搭配项目
组的成员?是谁安排的?如果是你们部门经理为了锻炼你的项目管理能力和增加你的项目管理经
验,那么楼主所说的问题应该不是问题;如果是你们更高级别的经理安排的,那么这的确很辣手。
呵呵!

·人力资源方面比较容易,主要看其他方面的管理(2005-11-14) [作 者] globemobile [公
司] globemobile

第 615 页 共 756 页
第 8 章 团队管理

如果仅仅是前面所讲的这些情况,没有其它因素,这样的项目组在人力资源方面还是比较容易管
理的。
部门经理和部门副经理应该懂得管理、会按照管理要求做,而另一个员工在这种项目组里也容易
自律。
所以,主要看你怎么管理项目的其他方面了。

8.14 怎样建立虚拟团队?

怎样建立虚拟团队?

[姓 名] 不公开 [单 位] 不公开 [邮 件] aaajkhkjha@hotmail.com


[所属行业] 综合应用 [所属主题] 项目团队管理 [发布时间] 2005-6-27

【案例正文】
我是某省移动通信公司的项目经理,怎样组建我的虚拟项目团队?(虚拟项目组)
大家知道移动通信正在朝大力发展数据业务的目标前进,并且逐步重视集团客户的
力量。为了达到此目标,我们针对集团客户专门有我这样的项目经理(产品经理)

针对集团客户的行业情况,提出整体解决方案,集团用户使用我们提供的产品。针
对这个工作,单凭我一个人的力量是不行的(产品经理),需要各部门协同作战,但
各部门有相对独立,不可能随时听你调遣,如果组建一个项目组,能在项目立案后
能够迅速组织实施,完成后马上又能各回各位,这是最好的。故想用“虚拟项目组”
的解决方案,但是本人在这方面没有经验,希望各位朋友不吝赐教。主要是运作形
式,组织构架,成员指责方面的说明,或者成功案例,或者教案,或者经验?谢谢

最好是一些章程,规范给我参考

【相关分析】

·虚拟项目运行平台(2005-09-11) [作 者] 刘卫平 [公 司] 上海友胜计算机技术有限公司杭州技术开发


中心

个人认为:虚拟组织由独立产权的的单位组成,因此其运行必须建立在以下平台之上:
1、契约网络
2、数据、信息、知识网络
3、物流网络

第 616 页 共 756 页
第 8 章 团队管理

·真实的想法(2005-09-11) [作 者] 天羽 [公 司] 林源教育

我认真的学习了 PMI 的 PMBOK2004,然而我却一直不认为有什么“虚拟团队”的东西。

虚拟是什么,是网络上抛出来的词汇,既然是虚拟的,它凭什么为你的客户的投资负责呢?虚拟
的团队又怎么能够产生实实在在的服务呢!

建议按照项目管理的思路和方法,组建一个有“利益”连接的团队,客观的分析好这个利益链上
的每个人的松散度、执行力和价值贡献,然后公开给他们的回报,这样就可以了。

有时想想,管理就是这么简单。

·一点拙见(2005-09-05) [作 者] derikwoo [公 司] pps

首先,要得到上层领导的充分授权,这样才有可能顺利的开展工作。
其次,要和各部门的负责人沟通,取得部门经理的信任,并在他们的协助下选择部门最合适的人选,
并确保避免团队成员面临多头管理的压力,排除干扰。
第三,分别和各部门经理及团队成员面谈减去成员的心理负担,并明确各自的工作范围和责任
第四,集中各成员座谈,建立沟通机制,贯彻项目的目的。
最后,把工作系统化,建立适当的激励机制,带动成员的积极性。

·随便说说的几点建议(2005-09-04) [作 者] 韦少才 [公 司] 桂林空军学院 7053

建立虚拟团队,首要的任务是做好各部门经理级人员的沟通,因为虚拟团队的成员是从各部
门里临时抽调的,沟通不好就会影响团队以后的工作进度;其次的任务是让你的上级下发给
你足够大的权利,以方便你在某些时候可以很好的调动公司的各部门员工,提高项目的工作
效能;剩下的一点是,做为虚拟团队的主管你必须要会调动团队成员的工作积极性,不能让虚
拟团队因为是临时组合,没有工作磨合而显得没有向心力. [size=2]

·3 点意见(2005-07-22) [作 者] wood.lee [公 司] nts

1,很多同行都谈道了沟通,但沟通只是个过程,我们需要的是沟通后,相关人员能采取的行动。所
以,如何确保沟通后,项目成员能积极,及时,高效的开展工作,必须有相应的督促机制。
2,项目成员此时属于不同的部门,他们的考核由其只能经理进行。如果项目经理对之没有考核的权
力,那么,难以保证成员的工作符合项目需求。
3,应从结合你的项目和公司的实际情况,对虚拟团队建立相关的约束和激励制度,能让项目成员有
压力时也有动力和期望。让成员协调好项目工作和职能部门的工作。

·项目经理的授权、沟通计划很重要(2005-07-13) [作 者] bolar [公 司] 北京

这是矩阵型组织结构的特点,要保证项目顺利执行

第 617 页 共 756 页
第 8 章 团队管理

1、要有上级领导的充分授权,保证你有权利支配项目组的成员,特别是在与职能部门发生冲突时应
该如何解决问题。

2、要分析你的项目组成员的利益关系,要是项目的绩效与项目组成员的奖励挂钩。

3、做好沟通计划:项目组内部的沟通、与上级领导的沟通、与其他职能部门的沟通。

·先妥决沟通问题,再解决任务协同,然后再细化。(2005-07-13) [作 者] 许海民 [公 司] 北
京梦龙科技有限公司

我是以软件应用为基础谈论此事的,因为我公司是作项目管理软件的,也是我的建议离不开软件的应
用,也是我对一些客户的应用有所心得:
1、采用即时通讯系统建立起互联互通,确实信息从一个统一的出口到达虚拟团队,也为其提供一个
快捷的沟通工具。(要有组织机构的最好)
2、通过网络计划技术明确任务及分工,以及组织与团队之间工作的协同性。主要是将各项目的工作
建立关联,作一个网络进度计划图,可以很明确的表示项目的工作任务,然后将任务分发给参与人员,
他们定期上报进度,使每个成员也能了解自己在总体进度中的作用,自己工作最晚何时开始或何时完
成。(有一套控制方法,很难三言两语表述)。

·根据各位分析,我采取的行动,请大家支招。(2005-07-13) [作 者] 冬雨 [公 司] 移动通信

写之前还要感谢张彤,确实在理论学习上还要加强。pmbok 虽然不长,但实际内容却非常丰富。在理
论上还要上高度,才能游刃有余与实际工作中。当然我不是西方管理学理论的膜拜者,我认为只有吸
取其中与实际相符合的知识学习,并在实践中加入自己的理解,才能真正掌握项目管理的真谛。因为
项目管理本来就是实践性科学,在西方发达国家的理论有其实际的实践阵地,但不一定符合中国情况,
有其我看到的案例全都是西方案例,真的希望有一批中国项目管理的有识之士,能够将中国项目管理
自己的案例通过总结分析,变成中国项目管理体系知识。如果加入计算机开发中类似 GNU 规范,就可
集众之所长,拓展我们的应用范围。

·非常感谢各位的建议(2005-07-13) [作 者] 冬雨 [公 司] 移动通信

小弟看了各位的分析及心得,受到一些启发。
1、这个虚拟团队组织构架是矩阵式管理模式,当然这种模式的理论效应大家都明白,但是碰到实际
问题怎样处理可能有所不同。(感谢 ghliu )
2、这个项目就必须得到高层的授权,并得到其他部门的认同和支持。这样调动其他部门的专家、资
源来共同编制合理、可行的计划,并与各部门一道执行这个计划。获得主管领导的支持,以便使得项

第 618 页 共 756 页
第 8 章 团队管理

目处于优于日常工作的地位;同时,要与各部门负责人通气,保证项目组成员不会面对多头领导的难
题。这是我目前需要做的。协调好各部门的部门经理,让其推荐专人,或者你指定专人(需要部门经理
同意)(感谢 ghliu 、maple9 、gogogo11 )
3、在建立虚拟项目组、人员构成时需要注意的一些问题。对于一个大的项目,通常是在项目实施前
召集各相关部门负责人开工程协调会,并由他们各抒己见,谈自己的观点和问题,然后就是执行。作
为工程主管,职责就是协调各部门共同协作,面对的就是各部门主管,这个层面要多联系,这有点像
金字塔。(感谢牧野李、Rachel Pan PwC )
3、虚拟项目组运作过程中沟通是非常重要的,有效率的沟通是项目进展的核心手段。(感谢王志飞)
4、要使虚拟团队高效运作,还必须建立制度及有效沟通技术。(感谢王坚)
请大家继续各抒己见。下面我将根据大火的建议简略介绍我将采取的行动,请大家关注。

·用web技术打建虚拟团队(2005-07-11) [作 者] 王坚 [公 司] 武汉环大科技开发有限公司

公司章程制度是公司机密,我不能提供给你,下面我仅从技术角度教你怎样搭建一个虚拟团队。

第一:首先要建立一个文档管理制度,确定工作目录,确定每个文档的检索目录和模板,通过制度章
程确定下来。然后发给虚拟团队每人一份进行学习研讨。让每个人知道自己的文档放在哪里,到哪里
找文档,文档该怎么写,该怎么看。
第二:通过 CLEARCASE ,CVS 等版本管理工具,进行权限锁定、web 发布,让团队成员在任何地方都
可以提交和所取所需文档进行并行开发。
第三:建立工作流管理规范,请参见本人的原创文章。通过 cvstrac,clearquest 进行工作流管理。

第四:虚拟团队最需要的是沟通,当工作流工作到下一个工作流时(例如提交工作,分配测试)要及
时通知对方。可以通过 BQQ,qq 等聊天工具,为了任务及时到达对方,你可以象我一样开发任务单通
知系统。通过 cvstrac,clearquest 的触发器在任务状态发生变化时触发通知系统,使任务及时达到
对方。

第五:同时建立语音网关系统,对于重难点,除了靠书面模板通知对方外,还要通过语音进行商量,
甚至进行视频会议。可以使用 netmeeting 目录服务器 ILS 来实现。最好每天留半个小时进行总结和
沟通。

以上系统能够通过 internet 实现虚拟团队的沟通、交流、管理。

·怎样建立虚拟团队?(2005-07-02) [作 者] 丁亮 [公 司] 四川网通

王先生对虚拟团队的介绍可说十分全面,运营商正是由于这种团队构成造成的项目进度缓慢.由于团
队成员间互相隶属与不同部门,往往由于缺乏有效的沟通手段造成项目进度的停滞.

在内部团队的管理上,运营商中的项目经理应更注重在协调保持内部信息的通畅上.团队会议是必不

第 619 页 共 756 页
第 8 章 团队管理

可少的,这有助于成员之间对整体项目的了解并清晰自己的责任.

可以试着向上级提出把项目资金独立化,对成员进行独立考核,以激励成员.呵呵,俺这边人比较多,一
个人同时有多个项目的情况基本没有.
这种团队的管理在运营商很普遍,希望同行的兄弟能多提供点好的办法.

·虚拟团队的管理(2005-07-01) [作 者] 王志飞 [公 司] 北京

公司内部组织机构的划分以员工工作性质、业务特长为标准:相同业务内容的人员被划分到同一个部
门,方便企业的管理。但是在以项目型管理为特点的企业里,这种组织结构受到了考验。在这样的行
业里,企业通常会遇到的一个问题是:如果一个项目过程涉及企业的多个部门,涉及企业多个部门的
不同级别的工作人员,甚至是涉及跨地区的不同部门的不同人员,企业该如何协同这些人的行动?

凡是公司承接的单项业务一般具有持续周期较长、金额较大、涉及公司部门较多、过程较复杂等特点,
这样的过程就通常属于项目型管理。系统集成行业就是具备典型的项目型销售特点的行业。

其实,所有涉及到相同项目的人员,我们都可以把他们看作是一个团队。但是这是一种临时性的团队。
这种团队具有以下特点:团队相对不稳定,成员随项目的进展而随时增加和缩少;所涉及人员对于项
目的参与程度不同;成员之间的关系也相对松散,以致在大多数时候,在团队成员甚至在公司管理者
眼里,并没有把它视作一个“团队”。我们可以称之为“虚拟团队”。虚拟团队既然不同于实体团队,
那么它也就具有自己的特点。虚拟团队在管理上经常出现以下几个问题。

沟通过度与沟通不足

对于一个真正的团队,经常性的“团队会议”是必不可少的。而对于以项目为中心的“虚拟团队”来
讲,每个成员涉及到项目的时间、深入程度均不同,参与的时间、频度不同,对于项目进展信息的需
求程度也就不同。频繁的“团队会议”会造成大量的时间的浪费,这就是沟通过度。而恰恰相反的是,
如果团队没有及时地进行有效地沟通,成员之间的配合就会出现问题。这又导致了沟通不足。

团队成员的行政隶属与项目隶属

每一个团队成员首先属于公司某一具体部门,在业务上受该部门的领导,这是行政隶属。其次,每一
个成员又在项目上受到项目经理的指导,这是项目隶属。这种双头领导的现象必然在一定程度上导致
管理效率的降低。

团队成员的多重项目隶属

在这种松散的团队组织结构下,“团队”成员通常要同时参与数个项目,换言之同时属于数个虚拟团
队。这就是虚拟团队成员的多重隶属,也可以称做多重项目隶属。多重隶属的问题在于项目之间的矛
盾性。

第 620 页 共 756 页
第 8 章 团队管理

·一点看法啊(2005-06-29) [作 者] 牧野李 [公 司] 河南通信

我是通信公司工程部门的,我们在对待这些问题时,对于一个大的项目,通常是在项目实施前召集各
相关部门负责人开工程协调会,并由他们各抒己见,谈自己的观点和问题,然后就是执行。作为工程
主管,职责就是协调各部门共同协作,面对的就是各部门主管,这个层面要多联系,这有点像金字塔。
具体的各部门相关项目成员就简单了,我也遇到过这种情况:项目成员有时在思想上和项目组有距离,
这个问题最好有他们部门负责人处理,你面对的是他们的上层。当然,如果你能处理好那就更好。

·分析之一--人员构成(2005-06-27) [作 者] Rachel Pan [公 司] PwC

1. 人员构成:
所谓虚拟项目组,在公司中应该是一种比较理想的状态--即希望项目实施后各项目成员立即返回原
来岗位,要知道项目期间的原有工作还是要继续的,尤其对于计费/数据部门的人员,不可能完全抽
身出来。所以要使项目顺利展开,成立项目组是必需的,并且要获得主管领导的支持,以便使得项目
处于优于日常工作的地位;同时,要与各部门负责人通气,保证项目组成员不会面对多头领导的难题。
这其中,与计费/数据部门的沟通是尤为重要的,毕竟,要开发和实现新的产品,技术支持必不可少。

·学习(2005-06-27) [作 者] 张彤 [公 司] 北京北大金秋新技术有限公司

建议您学习《项目管理知识体系指南》一书,它回体统地知道您开始您的项目管理生涯。

8.15 当团队成员都迷上了网络

当团队成员都迷上了网络

[姓 名] 宋学军 [单 位] 暂不公布 [邮 件] sxj236@163.com


[所属行业] 综合应用 [所属主题] 项目团队管理 [发布时间] 2005-3-15

【案例正文】
朋友的公司是做 IT 的,现在规模有了一定的发展,要我帮他规划公司的管理,在他
公司一段时间(我本身有有工作要做,隔几天才去一次)发现了一些问题:
现在公司都是在局域网上办公,先不说什么病毒啊、黑客啊,那还可以买一些安全
产品加以防范,但可怕的是,原来员工的工作热情很高,有事的时候大家很忙,没
事的时候大家聊聊天,也能互相沟通,增加感情、交流信息,但是现在办公室里很

第 621 页 共 756 页
第 8 章 团队管理

安静,大家每人一台机器不知道在干什么,好象都很忙,后来我发觉了,大家事实
上是在网上消磨时间,有的在聊天,有的在炒股,有的在玩游戏,后来发展成在网
上瞎逛,或者玩游戏上瘾,我倒不反对员工在网上看看新闻,查查资料,忙里偷闲
也可以娱乐娱乐,但是这样就太过分了,公司开会的时候我指出了这个问题,大家
也说会改正,但是好象上网、玩游戏这东西也上瘾,而且由于工作毕竟是有压力的,
不管是销售还是技术必须费尽心思去做,每个人的工作日程有很大一部分是需要自
己来安排的,现在是公司安排的事情还是去干,闲的时候就上网玩游戏,不会去想
自己还可以做些有意义的事,现在的聊天也变成了上网心得、游戏攻略的交流。
现在都讲目标管理,只要他们完成任务,该干什么就让他们干什么。这个我也知道,
但是实际操作中有难度,我是以人本为主的管理方式,而且我认为现代社会目标的
完成并不是靠一个人的努力就够了,是需要团队管理,作为一个中等公司,团队的
组成事实上跟项目有关,某个项目由某些人组成,这样事实上公司就是一个团队,
而员工目标的完成跟公司的实力等相关,目标管理就会陷入员工抱怨公司支持不够
的误区,公司的总结大会就会变成牢骚大会,有人提出要开人,毕竟这些员工都是
或者曾经是优秀的员工,开人是对双方都不利的局面,说起来很好笑,现在我和朋
友在办公室到处走走,员工会很紧张,我相信他们也知道自己不对,但大部分人的
意志不足以抵抗悠闲的诱惑,就象电视一样,呵呵,我要老说呢,好象我这公司很
抠,哎!小孩子不懂事,不知道我说他们是为他们好,年纪轻轻的,不好好做点事
会后悔,当然他们这样对公司也是很大的危害,在此象大家请教有没有技术的办法
或者管理的办法解决这个问题。也希望跟有同样问题的朋友共同讨论。

【相关分析】

·当团队成员都迷上了网络(2007-08-24) [作 者] 卢亚军 [公 司] 富士康科技集团

一般做法是利用技術手段來管控,比如關閉 MSN / QQ / 網絡電話 / 遊戲的端口,限制大部分與公司無


關的網站,對大部分人限制上網時間,等等啦,這樣即使他想上網,也上不了,慢慢也就沒有人利用上班時
間上網了

·很简单的一个战略管理案例(2005-05-23) [作 者] 陈皓 [公 司] 桂林电子工业学院

您作为一个咨询师或策划师,应该与你的朋友即 BOSS 尽快思考及制定公司的战略规划,明确公司的战


略目标,同时制定公司、部门的长期目标、中期目标、近期目标;然后,引导员工把自已的工作目标
调整到与公司的目标一致,增加员工的紧迫感,然后,再结合前面其它仁兄的建议,公司的面貌应该
会有所改进的。

·员工的有效管理(2005-05-02) [作 者] 韦少才 [公 司] 桂林空军学院 7053

员工的管理在每一个企业中都是一件很重要的事情,管理得好,企业的绩效会达到事半功倍的可能,
但是如果处理不好则会对公司造成不好的影响,甚至是公司的业绩。

第 622 页 共 756 页
第 8 章 团队管理

但是又该怎样去管理呢?
第一:应该设立一套奖惩机制,好的,对公司有贡献的员工给予相当的肯定,并给予一定的奖励。不
仅在奖金上,精神的奖励才是最重要的。谁都希望自己的工作能够被肯定;当然光有好的奖励还不够,
在必要时,对员工实行惩罚。但也不能瞎罚,这要有一个事先做好的制度,而且制度不要都以公司的
利益为重,还要考虑到员工的积极性,两者并重。

第二:经理主管每天都要求自己的下属员工,以自己的工作范围向自己(经理主管)报告,这样
的话经理主管不仅能够很好的了解员工工作的进度,也能够进早的发现工作中出现的问题把损失减小
到最低。限定员工完成任务的最大期限,如果他在这个期限里提前完成工作,而另一个工作任务还没
有下达给他时,我想让他上网玩一些游戏也未尝不可。这样反而能够激发员工的积极性。

第三:要明确员工的工作任务,因人分配不同的工作。适当的给每位员工分配一些富于挑战性的
工作,并暗示他们这些对他们有很大的意义。

第四:公司可以不定期的给员工培训,让他们觉得自己在公司还有很大的价值,个人还有很大的
潜力可以开发。从而更好的工作。

除此之外,公司可以适当的开展一些活动,让员工参与近来。这样即丰富了公司的文化气息,也
能够让员工们能够很好的沟通,让员工在意识上逐渐达成一致。也可以让员工理解上层领导的意图,
从而为公司里上下的沟通做好基础。

·从多方面找原因(2005-04-16) [作 者] 孙鹏 [公 司] 同济大学

首先他们是否有事可作,而且作的事情他们必须要负责任,如果他们完不成任务要受到处罚,他们也
不会成天上网了;退一步讲,公司里上网的风气也不好,可以进行无记名的批评,让那些上网的人知
道上级的不满,可能会有所收敛。还有走动式管理,不过这种管理方法冒着巨大的道德风险,所以一
般不要使用

·三点可能(2005-04-14) [作 者] yuwen [公 司] tcl

1,人浮于事。
2,绩效不实。
3,领导不力。

·这个可是深有体会哦(2005-04-10) [作 者] 林辉鸣 [公 司] 广州赛意

最近两个项目都是在客户那里工作的。前者呢,可以上网,工作时间也可以上网,而且也没有项目经
理来管你。后者呢,绝对的和外界绝缘。
结果:
前者,一个不大不小的项目拖了一年多,我亲眼看到一些同事,上班时间大部分时间是在聊天,计划

第 623 页 共 756 页
第 8 章 团队管理

的进度一拖再拖,这些同事都变成老油条了。
后者,也是一个不小项目,仅仅在 3 个月内就完成需求调查到开发测试到转产上线,项目组内的成员
每天都可以保持积极的心态做事。
光看结果,别的我也不想说了

·当团队成员都迷上了网络(2005-04-06) [作 者] 至尊月 [公 司] 项目管理部

团队成员迷上网络之前的原因就不做分析了,但有一点是可以肯定的,那就是你们现在的工作没有完
全的饱和,让他们有了空闲的时间。对这个问题,你需要想想办法让大家的空闲时间减少才是关键,
不要总从别人如何如何来看待问题,大量的空闲时间员工不会自己利用的时候,管理人员应该负责将
他们组织起来利用起来,利用的形式有很多,可以组织员工进行交流--业务、技术、休闲娱乐,或
者组织个人的讲座,让那些有一技之长的人都讲讲他们的特长--使员工觉得我在这个公司是非常有
意义的,提高员工的价值观。以上 2 点都需要管理人员在每次组织交流之后给出肯定的评价。只有让
员工觉得自己的价值不仅仅是在完成任务上,才会让他们对其他的事情有更多的积极性,才能让他们
从网络上解脱出来。
个人观点,有意向可以 QQ 48995392 或者 msn raofuhua1@163.com 交流

·强权管理与人性管理(2005-04-05) [作 者] 郭文博 [公 司] 上海华之樱信息系统有限公司

看了各位前辈的诸多发言,我发现大家觉得还是利用“人性管理”来调动所谓的“工作积极性”和
“团队向心力”较“规则化的制度”来得更为重要。但是小弟在这却要提出相反的论断(望有识之士
指正)。
首先我想来说说这种情况的危害:
所谓“千里之堤,毁于蚁穴”。一些看似微小的东西,其实是一个十分严重的为题。前面大家都提到
了,所谓“目标管理”--即以实现既定目标为首要原则。这的确是一种比较“务实”的作风。但是我
们要考虑的是--作为管理人员有明确的目标,以及相应的 catch 机制。但是不是所有的员工都具备这
种能力的。而且可以这么说,具有以上情况的员工更本不具备(或者还没有觉悟)这种能力。换句话
说,在空闲时养成的不良习惯存在影响正常工作的“隐患”(隐患一词其实比较暧昧)我相信任何的
项目管理者都不希望这种问题的存在,因为多一种情况,就必须在计划时多一种 catch。而且人性化
的管理只适用于小范围的情况,其作致命的缺点在于管理对象与管理者的比率超过一定的范围以后,
管理者无法了解每一个管理对象的情况这样势必导致评判的失误,这种失误更会影响“工作积极性”
和“团队向心力”。
(对于员工工资的高低比打不打游戏要重要的多)人性化管理的弱点也正是在此,
评判事务带主观色彩,缺乏公平性。
其次说一说“强权管理”
首先要说明的是我所谓的“强权”并非指“一言堂”或者“强压政策”。“强”指的是“执行标准”
的态度要肯定,不能有法不依。“权”指的是“标准化管理”。中国人有时的“聪明”程度远远超过
你的想象。他们为了“歇闲”所“发明”的策略实在让人瞠目结舌。所以唯有完整的“规范”才能真
正地“统一”。当然如果你的公司的既定目标就是一个 10 几 20 人地公司的话道也无所谓,但是如果
你是向往更大更高的境界的话希望能从现在开始就采用这种方式。“强”的方式由许多,主要是以惩

第 624 页 共 756 页
第 8 章 团队管理

罚为主,唯有惩罚才能让人警醒。(这个我就不多说了,大家可以尽量的发挥)至于“权”就不那么
简单了,这需要很长时间的积累。我来日本以前认为中国和日本的差距在 10~15 年左右,但是我现在
所看到的改变了我原来的想法。不夸张的说但就“标准化”的意识上中国至少落后 30 年。中国的传
统文化中的一些东西太过强调主观意味,对于标准化的实施是一种阻碍。(我们有崇洋的意思,我只
是一个没有被仇恨蒙蔽双眼的冷静的中国人)这些都是题外话。言归正传,标准化实施的基础就是数
据的积累,没有实际数据的积累和分析,不可能得出各项“标准”。而这种积累本身就要花费许多的
时间,可能需要几年,甚至几十年。所以开始的时候比较困难,但我们可以借鉴一些先进的理论和实
践经验。关键是要有实施的觉心,必胜的信心。

·以人为本(2005-04-04) [作 者] 桂君 [公 司] 合肥市伟联科技有限公司

其实这种情况在很多公司都会出现,不光是公司,在很多事业单位和政府机关这种情况也非常普遍,
早成很大的资源浪费。我以前在工作中也出现过这种情况,上半年工作比较充实,每天都有事情做,
也就是偶尔上上网抽空的时候玩点游戏。也没影响工作,全当是休息了。到了下半年,负责的项目基
本上都完成了,闲暇时间就多了起来,突然才发现每天无所事事,只好上网聊天,玩游戏打发时间。
好在我个人自制力还算好,知道这样下去总不是个事,后来我也就慢慢改变了方式,网还是上,只不
过我大多数时候在浏览相关技术资料,利用这段时间来充实自己。我个人认为上网是一把双刃剑,全
在用的人自己掌控。大多数人在这个时候心里都清楚这样做是不对的,但是却不能自制。所以需要约
束他,现在都追求人性化管理,管理二字是可以分开来说的,管是约束、管制,只是起到一个规范的
作用,理才是管理的核心所在,如何理顺人心、关系,让一个团队的成员发挥最大效能同时能够感受
到价值所在。我们可以用多种方法,针对不同类型的员工,采取不同的方式来进行管理。比如我们可
以在空闲的时候鼓励他们多多钻研技术或业务,并配以相应的绩效管理措施,并且可以利用员工的不
同心理采取由点带面的方法来调动他们;这样即提高了大家的业务水平,而且又不过分压制,慢慢就
会转变过来的。

·当团队成员都迷上了网络(2005-04-02) [作 者] 理想 [公 司] 长春工程学院

我肯定地说,玩游戏上瘾。尤其是在没有约束条件的情况下,游戏更甚。如果想从根本上解决这一问
题,还是从主观及客观两方面抓起。主观方面,经常性的对员工进行人生观、价值观的教育。定期请
一些成功人士和员工一起参加讨论之类比较见效,是对员工的一种激励!让员工对游戏有个根本的认
识,玩游戏实现的是游戏公司的理想,对自己的奋斗目标没有任何帮助。客观方面,制订相关制度。
但要注意,制度要合理,否则会让员工产生抵触情绪,产生反效果。

对于公司本身来说,只有先稳定,才会有发展。制定一个长期规划,让员工每天都有一定的任务,只
要他完成了自己的任务,就没必要过问他的休闲时间,因为员工也有娱乐的需要。

如果经过一段时间发现情况没有改善,我觉得需要进行一定的人员调整。可以辞退某个经常上网,对
工作热情不足的员工。虽然这样不太人性化,但公司在前面已经给过大家机会了。员工看到辞退的情
况,肯定会有所改善,毕竟丢饭碗是一件大事。

第 625 页 共 756 页
第 8 章 团队管理

·这是一个绩效管理的问题(2005-04-01) [作 者] forestlyl [公 司] 北京上地

员工完成任务是好是坏你根本没有一个很好的评估,没有一套好的绩效评估体系,就会让员工感觉不
到自己工作的价值。造成这种结果的原因有二:
1、任务管理有问题:任务分配不合理,或者没有统一任务管理的机制,只是有活了经理交待一句或
开个会,而对任务的完成过程缺乏跟踪。这样团队成员看不到一个明确的工作目标,以及目标实现的
一个过程,自然也就感觉不到自己的价值。基本上很多公司都是这样,大家都觉得自己在混日子。
2、没有为员工规划职业生涯的机制:现在人员流动大,职位不稳定,很多人从来都不会从公司的整
体利益来考虑问题,因为公司也从来不会真正地为员工的利益考虑一样。你只是把员工当作工作的机
器,那员工怎么可能踏踏实实地为你买命呢?工作任务永远不可能饱满,你们在工作之余,你除了不
让员工做 XX,你还应该做什么,你可以建立一个好的培训体系,来增强员工的业务能力,技术水平,
英语水平,沟通能力,等等,我相信不会有人对一个提高自己能力的学习机会无动于衷的。当然这只
是一种方案。另外你还可以组织一些活动来丰富公司的文化,你组织一次网络游戏比赛又未尝不可呢。
不用担心员工会玩物丧志,只有他们能感觉到公司很重视他们,真正能体会到你所说的以人为本,那
么工作效率的提高就指日可待了。哪怕员工每天只有 5 个小时在工作,但他的效率可能是以前的 2
倍。
我觉得你员工在人力资源方面想办法,而不是项目管理。

·实施目标管理(2005-03-31) [作 者] 徐泉来 [公 司] 澳柯玛集团

员工在工作闲散或者缺乏目标时,工作上的开小差是普遍的正常的。这时,一定要让员工明确自己的
工作目标。实施目标管理不失为一个好的办法。
项目管理型组织是实施目标管理较为理想的组织。公司在做项目的时候,一定要使成员明确自己的职
责,确责任分配矩阵,根据项目计划将员工的工作包含进项目计划中,鼓励员工尽最大努力完成自己
负责的工作,并加强工作考评,使员工的工作绩效根薪资挂钩。在此基础上,如果员工提前完成了自
己的工作,我觉得做一些休闲性的事情也不要横加指责。关键在于,工作分配要合理,不要让员工有
太多的时间从事对公司无益的事。只要公司总体目标实现了,就不要过多干涉他们,因为 IT 业工作
状况毕竟不象生产性工作。

·当团队成员都迷上了网络(2005-03-26) [作 者] Alam [公 司] 澳門紡織集團

我个人人为,管理主要还是要基于人性化的管理.如果出台强制性的措施去限制员工的话,可能会造成
逆反心理,这样一来整个公司死气沉沉的,反而工作效率会更加底下.象严格目标管理和计划管理,工
作绩效与薪酬挂钩,奖惩分明等做法对于大规模的企业而言比较容一,然而对于一些小的员工在
40-60 左右的公司而言就比较困难了,应为比较难的去统计员工的绩效之类的指标.
遇到这样的情况是考察一个项目经理在人际关系上处理能力的时候,对于这样的情况我比较同意楼上
yeahi 的意见.例如:在午休或其它空闲时间与他们共同参与某个游戏,体现出出谋策划的热情。在临
近上岗前,你可先行终止本游戏,并自言自语,好了上班了,抽时间与你们再切磋。

第 626 页 共 756 页
第 8 章 团队管理

但同时,一定要有严格的制度的支持就是工作时间一律不允许游戏和聊天.已经发现严惩不待;
这样即可以加强团对的凝聚力又可以建立项目经理自己的威信.
有句话怎么说来的"工作娱乐两不误".......

·什么是人性管理(2005-03-21) [作 者] 赵世鹏 [公 司] 北京慧点

你的初衷是好的,可是好的初衷没有配合好的制度和管理方法。
团队是由人组成的,人性化管理也是重要的,但是,人性管理不等于放任管理,在管理角度首先我们
要对你团队中的人员逐一分析,然后逐一解决,首先你要将团队中的人员分为四种类型的人员,a 有
能力有意愿、b 有能力没有意愿、c 没有能力有意愿、d 没能力没有意愿,然后对号入座,在针对他
们的情况逐一分析,让 a 承担更大的责任,可以将你的工作下放给他由他负责处理,对于 b 你需要经
常督促他,对于 c 你需要经常鼓励他,对于 d 则比较费心,如果你认为他还是可以的话,你需要不断
的督促和鼓励,建议你不要留着。经过上述方法初步策略调整后,你就无需去担心他们上网了等等,
然后针对上述策略出台一定的奖励惩罚制度,这样一来可以因地制宜,不是一竿子打死。这才是人性
话管理。

·目前此公司的制度很不完善(2005-03-18) [作 者] 赵宏伟 [公 司] 东信北邮

首先是制度不完善,考勤,员工的行为准则,没有相关的奖惩机制,不会只有把人开了这么一种惩罚
机制,可以从奖金,补贴经济的手段,(需要一定的制度来维护)
其次,针对具体的上网,可以从网络技术手段,对上网进行监控,和做出相应限制,把网上聊天的功
能屏蔽掉等!
再次,可能目前此公司的还是“学生企业“,员工都是刚刚走出校门的,所谓的以人为本,其实是在
没有规矩下面进行,很危险!

·问题何在?(2005-03-17) [作 者] 小飞熊(flybear) [公 司] no

从案例的论述中看,有以下几个事实大概是基本确定的:
(1)原来员工的工作热情很高,有事的时候大家很忙,没事的时候大家聊聊天。但是现在。大家每
人一台机器,结果在聊天玩游戏
(2)公司开会时指出了这个问题,大家也说会改正,结果照旧
(3)现在是公司安排的事情还是去干,闲的时候就上网玩游,不会去想自己还可以做些有意义的事
下面先谈谈我的一点看法:
问题的关键,出在绩效管理上。如果只是一小部分人出现这个情况,把问题归结到个人自控能力弱上
还说得过去。大部分人出这个情况为什么?可能体现两方面的原因:
(1)员工干多干少一个样,甚至多干的成绩看不见,倒是有些“辛辛苦苦”却效率低下的人“脱颖
而出”。
(2)给人安排的工作量本身就不饱满,致使员工本来就经常处于无事可做的情况下。再加上面一条,

第 627 页 共 756 页
第 8 章 团队管理

即奖惩制度的实施没有有力的绩效考核制度做保障。员工自然不乐意担任更多工作。
(3)文中“小孩子不懂事,不知道我说他们是为他们好,年纪轻轻,不好好做点事会后悔,当然他
们这样对公司也是很大的危害”一段话,表面上很客气。实际上呢?
下面说说我的建议:
(1)从技术角度讲,限制玩游戏是可以做到的。具体手段就不说了,相信“管头管脚”的方法公司
总能想出来。
(2)如果公司管理者不从自己管理的角度找原因,上面方法短时间内治标,长时间如此而不改变公
司自己的体制,甚至会雪上加霜(很遗憾,估计大部分公司只会把问题指向员工,而不是自己的管理。
所以估计这几句话白说了。)
(3)最后,公司高层的任务,其实很简单!就是管好经理!

·当团队成员都迷上了网络(2005-03-16) [作 者] yuyan [公 司] UCCT

我最近也遇到类似的情况。公司机构由于在不同的地方,日常交流主要通过 MSN 进行。当然,公司也


还有别的交流平台(如 OA 系统、邮件系统、公司网站等)。但 MSN 这种交流方式的优点是及时、便
捷、成本低。因此一直沿用。只是前些日子,发现一些员工上班时间利用 MSN 与朋友聊天,甚至传布
小道消息、发牢骚等等,更有甚者,迷恋网络恋爱、网络游戏。公司即刻下令禁止上班时间上网聊天、
游戏,也取消了 MSN 这种交流方式。影响不言而喻。沟通成本增加并不说,效率也降低。问题也没有
得到根本的解决。也不乏阳奉阴违者。
我想针对此种情况,严格管理是必须的:
1、严格工作纪律,抓典型,严惩不待;
2、严格目标管理和计划管理,工作绩效与薪酬挂钩,奖惩分明;
3、制定培训计划,对工作量不饱和的员工实施培训,并将培训考核纳入工作绩效考核的范畴;
4、固定学习交流时间,让团队成员轮流担任授课者,必定促使其在工余时间加强学习;
5、如果仍然有人无所事事,那就要考虑裁人了。

·当团队成员都迷上了网络(2005-03-16) [作 者] 潘谦 [公 司] NEC中科院上海软件开发中心

1)当一个公司从初期到开始做大,肯定要有一定的管理的。
如果做到 40 人以上,一定要制定公司内部的网络使用规定,
我原来的公司也是在员工养成习惯,结果在给客户做维护的时候,
忙着自己下载东西,玩游戏,在客户那边影响很不好。
后来因为这点才开始下定决心整顿的。设定专门的工作时间段,工作时间段内是完全严禁玩游戏。设
定专门的惩罚措施是完全必要的。

2)设定目标管理是有必要的,
具体来说,最好在每个人在上级的帮助下设定自己的提高的目标。

第 628 页 共 756 页
第 8 章 团队管理

设定好员工在这一年要达到的水平,要承担那些责任,
员工自己希望在那边有所提高,受到什么样的培训。
根据员工的期望和项目的实际情况,设定组织的培训计划。
最好是相互培训和设定专门的技术调查人员。

在项目组中培养相互学习的风气,让员工定期发表自己的学习成果。
这样也可以避免员工在空余时间都忙碌在上网聊天和游戏中。

PS:最好能把员工的学习情况和给别人做的教育作为评价升级的一个项目中。

·增加你与团队的凝聚力(2005-03-16) [作 者] yeahi [公 司] 苏州网路神电子商务技术有限


责任公司

可通过增加你与团队的凝聚力的途径解决。
措施个例:
在午休或其它空闲时间与他们共同参与某个游戏,体现出出谋策划的热情。在临近上岗前,你可先行
终止本游戏,并自言自语,好了上班了,抽时间与你们再切磋。
同时,与个别部门领导私下谈心,表彰其近期的工作进展,在话题比较和谐的情况下,希望他带头起
好典范作用,尤其是工作时间不能打游戏。一个好的工作氛围,养成也不容易。
.......等

8.16 个人习惯导致团队工作的困难

个人习惯导致团队工作的困难

[姓 名] 熊浩 [单 位] 暂时不公布 [邮 件] xiong_h@163.com
[所属行业] 综合应用 [所属主题] 项目团队管理 [发布时间] 2005-2-21

【案例正文】
我的团队内部有这样一个程序员,喜欢晚上回家工作,白天睡觉。由此造成其他和
他配合的项目成员不得不去适应它的习惯,而这种问题已经拖垮好几个测试人员。
为此跟他沟通过 n 次,每次都不以为然。虽然人力资源部有相关的考勤制度,不过
扣罚都不是很多,他也并不在乎。遇到这种问题,大家是怎么处理的?

第 629 页 共 756 页
第 8 章 团队管理

【相关分析】

·重视团队运做对于项目成功的重要性(2005-06-01) [作 者] 张彤 [公 司] 北京北大金秋新技术有限公

项目过程是一个团队运做的过程。从实战的角度来看,如果出现这样的问题,就应该考虑项目团队的
重新组建问题。不能因为一个老鼠害了一锅汤呀。

·不能迁就(2005-05-02) [作 者] 韦少才 [公 司] 桂林空军学院 7053

我认为在一个公司中人员的工作要服从一定的时间安排,不能因为个人的喜好而独断独行.否则会造成
不必要的麻烦,案例中的员工沟通就是一个不小的问题.所以我觉得应该找一个适当的时间和他好好的
谈谈,找出真正的原因,并力劝他改正.或者让其在一定的时间里(每天或每星期)和其他员工进行工作进
展的有效沟通(当然是认为他还是这个项目里别人无法取代的情况下).如果还不行,那么最好还是另选
他人为好,否则影响到项目的进展将会造成更大的损失!

·其是方法很多的,呵呵。(2005-03-16) [作 者] 潘谦 [公 司] NEC中科院上海软件开发中心

我都觉得这是一个项目经理很容易碰到的问题,应该能提出很多的方案。

1)很容易想到的解决方法就是提高他的职位,让他担负起一定的责任。个人觉得这是有一定条
件的,不是肯定能解决问题的,就是这个人其实有着很强的责任感。

2)如果他的工作时间就是晚上,并不是不想和别人交流,让他做相对独立的工作,就让他做晚
班,白天不上班,测试人员正常上班。
但是必须他和测试人员有一定时间的交流。这个时间段双方都上班。
例如 测试人员 9:00-18:00
他 17:00-3:00

3)如果这个人天生就是交流能力非常差,让他负责相对独立并且培养他自己测试也可以,可以
明确的告诉他没有其他人愿意给他做测试。

4)总之,人员备份是必须的。从新招一个相同类型但是愿意和别人交流的人是必须的。这样也
可以让该员工有一定的竞争压力。

5)让他调入测试部,和测试人员一起做事情一段时间。让他感受一下测试人员的苦头。

·适当提高他的职位可能会有意外效果(2005-03-10) [作 者] 于洪志 [公 司] 吉林省建行信息技术部

如果他个人对项目来说不可或缺,那么试着适当提高它的职位可能会受到意想不到的效果

第 630 页 共 756 页
第 8 章 团队管理

·强制!(2005-03-09) [作 者] mudan [公 司] 北京广联达软件

如果你想回家做!不拦着!但必须在工作时间与其他员工配合!否则换岗位!
当然要有良好的沟通!

·不要个人英雄主义(2005-03-08) [作 者] 李剑雪 [公 司] 世纪金骆驼

一个团队中绝对不能有个人英雄主义存在。
现在的项目不是一个人可以完成的,不论他的能力有多强。个人英雄主义会给团队带来不良的习惯。
先谈心,找到原因,协商解决,如还不行,那只好给他换岗位了。

·对于这种个人习惯!在有前提下能踢出团队就把其踢出去!(2005-03-08) [作 者] 赵宏伟 [公
司] 东信北邮

现在无论做什么项目和事情! 都是需要合作的,不可能单单 1,2 个人完成,也不能依靠 1,2 个特别人身


上!

在尽可能的情况下,做到每项工作都有人员备份!
作为团队的一个成员,在团队共同目标的前提下,尊重个人的需求!
如果个人的需求和团队的目标不一致,那就要对这个人尽心沟通,处理, 最坏就是把这个人踢出这个
团队!

·对于这种个人习惯!在有前提下能踢出团队就把其踢出去!(2005-03-08) [作 者] 赵宏伟 [公
司] 东信北邮

现在无论做什么项目和事情! 都是需要合作的,不可能单单 1,2 个人完成,也不能依靠 1,2 个特别人身


上!

在尽可能的情况下,做到每项工作都有人员备份!
作为团队的一个成员,在团队共同目标的前提下,尊重个人的需求!
如果个人的需求和团队的目标不一致,那就要对这个人尽心沟通,处理, 最坏就是把这个人踢出这个
团队!

·个人习惯导致团队工作的困难(2005-03-08) [作 者] STEVE WANG [公 司] Huayuan

个人认为,这不仅是一个项目管理的问题,还涉及公司的管理。
当项目组建立时,项目成员不一定是项目经理能够确定的。往往在公司没有相关资源的情况下,项目
经理想更换成员往往是受到很大限制的。所以,要从整个公司的角度,对于关键成员要做好备份,这

第 631 页 共 756 页
第 8 章 团队管理

个备份不是说要有一个员工完全和另一个员工一样。其实可以采用 3 个人的方式,各自左各自的项目,
但是 3 个人的工作内容有很大相通之处。3 个人同时出问题的可能性较小,当一个有问题的时候,在
其他工作没有效果的情况下,不妨把他晾一晾,让他反思反思,另外 2 人可以分时参与项目,尽可能
保证项目顺利进行。这样比单纯做思想工作的效果可能要好点。反思之后没有改观,那么基本上,一
个不愿意和他人合作,继续在公司,对项目或公司来讲,不会有太大贡献的。可能他自己准备单干。

·这样的人适合单独布置任务(2005-03-07) [作 者] 秋千 [公 司] 北京能博文科技

这人如果对公司的制度没有存在不满或者对你安排的事情没有存在不满的话,那他就是这习惯,可以
给他布置单独的任务。

但如果他心里有不满或者不服气的地方,你最好找机会了解清楚,以便更好的协调。

我觉得一个项目组,认识沟通和技术沟通同样重要。

·个人习惯导致团队工作的困难(2005-03-05) [作 者] 张力 [公 司] 深圳市金钢建设监理有限
公司

作为一个好的项目经理,我建议你首先考虑一下,毛病出在那里。或许这个工作人员对组织设计有意
见。我认为不必正式谈话,利用业余时间比较好,找到他的思想问题后一切都好解决哦

·个人习惯导致团队工作的困难(2005-03-05) [作 者] 张力 [公 司] 深圳市金钢建设监理有限
公司

作为一个好的项目经理,我建议你首先考虑一下,毛病出在那里。或许这个工作人员对组织设计有意
见。我认为不必正式谈话,利用业余时间比较好,找到他的思想问题后一切都好解决哦

·个人习惯导致团队工作的困难(2005-03-05) [作 者] 张力 [公 司] 深圳市金钢建设监理有限
公司

作为一个好的项目经理,我建议你首先考虑一下,毛病出在那里。或许这个工作人员对组织设计有意
见。我认为不必正式谈话,利用业余时间比较好,找到他的思想问题后一切都好解决哦

·个人习惯导致团队工作的困难(2005-03-05) [作 者] 张力 [公 司] 深圳市金钢建设监理有限
公司

第 632 页 共 756 页
第 8 章 团队管理

作为一个好的项目经理,我建议你首先考虑一下,毛病出在那里。或许这个工作人员对组织设计有意
见。我认为不必正式谈话,利用业余时间比较好,找到他的思想问题后一切都好解决哦

·寻求理解和解决办法(2005-03-02) [作 者] 小飞熊(flybear) [公 司] no

程序开发,尤其是当国内的程序开发具有比单纯的“编码”工作更艰巨任务的时,高水平员工的创造
性具有非常重要作用。因此,如果这位程序员具有这么高超的技术水平,不妨尽量给他创造更好的弹
性工作时间。但仅仅如此还是不够的,因为团队工作不允许因为一个人而影响整个团队的工作。建议
的处理方式如下:
(1)如果此员工确有很好的技术水平和设计能力,首先建议予以充分重视并对其能力和贡献给以肯
定;
(2)其次,应当指出工作是团队的,因此他也应当尽量照顾团队中其他成员的工作习惯。可以大家
商量个解决办法,如定期让他与测试人员一同工作,增强文档等。
(3)对于该员工,可能还存在技术和方法上提高的可能。一旦提高,即很有可能使其具有更高的工
作效率,从而间接地部分或全部改变其工作方式。
(4)如果该员工过于以自我为中心,在不得已的情况下大概只好忍痛割爱了。

·个人习惯托跨项目组(2005-03-02) [作 者] 宋学军 [公 司] 北京市乾通电信系统开发公司

这是一个典型的案例,因为一个人的工作习惯搞垮了整个项目组,做为项目经理首先要对其做良好有
效的沟通,不能直接就让人事部门的人去找他谈话,这样只会增加他的抵制程序。
其次要对整个项目的计划做好监控,现在是因为他一个人的工作习惯托跨了正个项目组,要让全体成
员都知道项目执行的状况。
如果他的能力真的很强,没有人可以代替,那就赶快寻找接班人,不能因为他一人而托跨了正个项目
组。

·计划与监控(2005-03-01) [作 者] 欧阳永辉 [公 司] 上海梅林食品有限公司

你们的团队至少存在两个问题:
1)沟通上的问题,沟通时要注重换位思考,一方面要坚持原则,另一方面要了解对方的需求。
2)计划和监控方面的问题,一份良好的计划应该在时间进度方面要有相当强的逻辑性,我想白天晚
上工作并不重要,也不一定影响到项目,重要的是他能不能在相应的时间节点上能完成相应的工作。

·两手准备(2005-02-28) [作 者] 陈华强 [公 司] 暂不公布

一是尽量与其沟通,进一步探讨改进的必要性,同时做好其它同事的安抚工作;这是不得已的下策;
二是培养、寻找接班人,一可让其有危机感,或可改变,二可在必要时替代其。

第 633 页 共 756 页
第 8 章 团队管理

·个人习惯导致团队工作的困难(2005-02-26) [作 者] 陶涛 [公 司] nokia

考虑到其在项目中的核心成员角色,沟通是必要的;往往这样的员工恃才傲物,可以让他仍然承担技
术负责;使之承担一定的管理责任;可能会有所改观;另外抓紧备份人员的培养;这有这样才能真正
使整个团队的管理走入正轨;当然在备份人员培养后,该员工仍然改观甚微,只有请其另觅高就了

·个人习惯导致团队工作的困难(2005-02-26) [作 者] 李棣 [公 司] 中北大学

文字
这位员工显然比较有个性,不知道在工作中是否比较有天分。
做开发的工作是需要个性的,往往恃才傲物。
如果他属于上述,则应慎重。
没办法,还得沟通,往往这样的人比较虚荣一点点,可以当众夸赞他的才气,至少可以让他听得进你
的建议。
给他适应期,让他部分负责项目,若他能力许可,甚至给他项目核心部分。明确提出目标,期限。让
事实来决定应该由谁做出改变。
若不属上列。呵呵,没办法,铁血一点好了

·开除(2005-02-26) [作 者] 许小彪 [公 司] 深圳大光集团

象这样没有集体意识和团队精神的人,应该马上让他走!

·赶走(2005-02-25) [作 者] 江松霖 [公 司] bjleadr group

一个人弄得整个团队不能正常工作,不赶走还有什么法子,项目是团体性的工作,要充分合作,他有
什么了不起的呢。当初未什么选他呢,或者换个工作给他,让他做晚上该做,白天不用做的事情。

·个人习惯导致团队工作的困难(2005-02-24) [作 者] 薛多志 [公 司] 新疆虹联信息技术有限


责任公司

建议一:让其感觉是善意的沟通,说明项目目的和项目组的工作流程,并了解原因。将由于个人导致
的结果(现在和将来)明确告知。最后明确告诉其正确的做法。双方限定一致的改正期限,再观其效!
如期限后不改正,除必须项目组人员外,上交公司,驱逐出局!
建议二:必须此人在项目组内,通过上层领导进行压力改正。
建议三:直接找人替代他的工作内容。他——出局。

第 634 页 共 756 页
第 8 章 团队管理

·个人习惯导致团队工作的困难(2005-02-23) [作 者] zhouhuafeng [公 司] 卓达房地产公司

同意 zhaosp 的意见,作为一个项目领导,就应该先沟通协调,如其没有效果,必须加大力度,进行
监督管制。不能因为一个人而影响整个团队。

·个人习惯导致团队工作的困难(2005-02-23) [作 者] zhouhuafeng [公 司] 卓达房地产公司

同意 zhaosp 的意见,作为一个项目领导,就应该先沟通协调,如其没有效果,必须加大力度,进行
监督管制。不能因为一个人而影响整个团队。

·也许你需要专业的团队管理咨询(2005-02-22) [作 者] Fortune.Yan [公 司] TITSCL

看来是你的团队有不小的问题,你必须想办法增加团队成员之间的交流和沟通,让他们感受到感受到
团队成员之间,不仅仅是同事,他们还要有共同的价值,使命,友谊,他们之间也会有互相需要。他
们之间需要建立更多的感情。而这一切不是一次两次的谈话所能解决的。要让他们能够站在他人的立
场上思考自己的行为,理解别人的需要和看法。也许你需要专业的团队管理咨询,如果有一些共同的
团队活动,野外训练营之类的或许会有些作用!总之要让他们有机会要取得别人的合作,有时间和机
能够在一畅所欲言。从而增强他们的团队归属感!使他们愿意为了共同的使命,互相协作,携手共进。

·个人习惯导致团队工作的困难(2005-02-22) [作 者] zhaosp [公 司] 北京

看来管理上就存在问题,这样的员工责任心就很差,而且属于那种天塌下来都和他没有关系的那种,既
然他不懂的怎么为人处世,作为他的领导和管理者,就有责任和义务帮助他.首先要和他进行一次较为
深层次的沟通,在沟通的时候,先让他自己表达一下的愿望或他的想法,以便为后续沟通进行铺垫,然
后,慢慢的引导将话题转为为责任心上(责任心表现在对公司,对自己对同事负责),如果在这个方面上
能够达成共识,然后,在引导为让他换位思考,让他为别人想想,如果也能达成共识,你作为领导就应该
鼓励他,并表示相信他能够做好.如果不能-那就开掉吧,总不能让一块臭肉,坏一锅汤.

·项目是团队工作,不能放纵个人行为(2005-02-22) [作 者] 卫学军 [公 司] 广州立信公司

项目对团队性的要求很强,如果项目中存在这样的个人自由主义,不仅难以和他人一起工作,而
且会动摇军心,不加以制止,会让团队从内部分崩离析。对这种人如果劝说无效,就将其从项目组除
名吧。

·重组团队不可能(2005-02-22) [作 者] 熊浩 [公 司] IT企业

第 635 页 共 756 页
第 8 章 团队管理

我来之前就是项目的核心团队成员,项目的核心技术是他掌握的,暂时无人代替

·项目事实需要明确各工作要求(2005-02-22) [作 者] 梁桢 [公 司] 上海广平信息系统工程有
限公司

首先,项目的完成需要团队的全体合作,以我为中心的工作方式是非常忌讳的,会导致工作流程的中
断和延迟。

其次,作为项目管理者需要运用行政和奖惩多种方式调动团队成员的工作积极性,需要建立项目实施
规则。

再次,项目成员的选择需要在项目前期进行,对于选择这样的成员加入,项目管理者需要自我反省。

最后,希望你的项目按时顺利完工

·就事而论(2005-02-22) [作 者] 徐 [公 司] 管理控制部

您的团队是否离了他就不可呢?您没有替代的人选么?如果您有的话象个性这么强烈的队员让他去
搞研究好了。如果没有,而且您的团队成员又对他的工作认可,那您可以让整个团队都遵循这个习惯,
如果团队都不认可那您必须选择一个了,重组团队还是。。。总之如果这样拖下去对项目团队的融合
非常不好,而且会影响您工作的开展。

·个人习惯导致团队工作的困难(2005-02-21) [作 者] 徐兵 [公 司] 深圳市智高点商务策划公

我认为对于这样的人员,应该采取强+硬的方式.
强:可以临时找一个程序人员(能力相当,甚至是差一点,只要能胜任这项工作)代替这名人员的工作任
务.利用强势手段,使得这名人员知道面临的竞争问题,从而调动其积极性和团队意识;
硬:对其采取强硬手段,加大处罚力度.如果还是不改正,就开除.一个团队里坚决不能有这样无组织无
纪律的人员,更何况还影响了工作和大局.

以上纯属个人意见,希望大家指正.
www.intelnet.com

第 636 页 共 756 页
第 8 章 团队管理

8.17 被踢来踢去的皮球,他该咋办?

被踢来踢去的皮球,他该咋办?

[姓 名] 海纳碧丽 [单 位] DD [邮 件] dwjl@tom.com
[所属行业] 综合应用 [所属主题] 项目团队管理 [发布时间] 2003-5-20

【案例正文】
售前部的大王(大王暂时充当前期项目协调员的角色)周三又接到 B 地客户打来的
电话,客户最后通牒项目建议书如周五前还不能提交则后果自负。大王再次开始走
售前支持流程,请相关部门协助。不想,大王被踢皮球的遭遇就开始了。

首先大王按售前支持照流程找到方案准备部,请他们写,但该部张经理马上抱怨说
另一个大项目下周就要投标了,老总还亲自过问了这事,这几天全部门的人还搭上
技术部加班加点的干,哪有空写。其实大王前一周就向他们说过写项目建议书了,
但当时张经理说不着急,缓一缓。原计划这周写的,哪想又赶上了投标。

大王只好直接找技术部。项目的最终实施是技术部负责,现在技术部正做着同类项
目在 A 地区的开发。技术部杨经理说这事合同还没签呢,应该是方案准备部的事,
况且现在也没空写。

他说的也对,这事并不是技术部负责的。见大王一脸无奈的样子,杨经理指给大王
一条路,原先在项目组的小林现在有空,看看他是否愿意帮忙。

大王心里一喜,赶紧去找。听明来意后,小林说了两点:
1、项目组除了他现在还没人写过这份东西,由于他已不在项目组,有必要从项目组
中找人来学着写一写,否则以后有事还要找到他头上。
2、写这份建议书涉及到 B 地区的许多资料,他一直没接触过,如看过资料后再写
要花至少一周时间。本周肯定完成不了。

皮球被踢来踢去,大王该怎么办?

【相关分析】

·其它部门的责任哪去了(2003-11-24) [作 者] phil fu [公 司] Elec&Eletek

我感觉此事是职责不分.让此公开化,并让老总知道倒底是怎么回事

第 637 页 共 756 页
第 8 章 团队管理

以老总的威信来影响他人配合

让相关的部门了解不这样的后果,当然,如果客户可以商量,则更应该加紧时间.

·只有一个办法(2003-11-06) [作 者] 金俊杰 [公 司] 兖矿集团

大王作为售前部协调员如果不能协调好的话最好换个部门或辞职.
此问题最好的解决办法是要求上级来协调.协调的目标人是小林.
可采用一些手段,比如上司的命令.如上司不做,只能靠自己去协调小林加班做.

·大王应该怎么做(2003-10-15) [作 者] 拉尔夫 [公 司] 毅力

大王错了,没有正确估计到风险,没有做好相关控制。
大王找相关部门联系是对的,根据公司的支持流程也是对的。但是该流程俨然已经不知走一次了。大
王应该在前几次估计到进度和风险,并且这次必须请求直接领导进行部门协调,甚至公司大会协调。
大王必须明确告知项目相关干系人,项目的紧急程度和风险。另外可以到用户那里争取延迟时间。

·不负责任的项目主导人(2003-09-28) [作 者] 闫振海 [公 司] 泛友科技

沟通不足,没有协调好公司软资源之间的关系,同时该工作人员缺乏基本的敬业精神,从本例中可以
看到该工作人员在前期的过程中一味的期瞒客户,对客户的需求没有采取进一步的措施;在这种情况
之下,其他部门没有足够的心理准备接受这样的工作,并不能说在推卸责任,这本就不是他们短期计
划中的事情,结果依然

·项目反映的问题说明公司本身在项目管理机制上存在的缺陷(2003-08-12) [作 者] 钱芳 [公 司] 沈阳
华晨

通过‘大王“的遭遇可以发现公司内在项目管理机制中存在的问题:
1、项目的组织建立之初并未明确项目协调员在项目中的位置及作用,也未明确参与项目的各子项目
经理/项目支持部门的责任,至使‘大王”到处碰钉子;
2、公司的组织流程不完善(“售后支持流程’),反映到”大王“无法按照规范化的流程去定义责任部门,
而是别人认为是哪个部门的工作,他便去找哪个部门,造成了工作的被动性;
3、大王个人人际关系及个人魅力不强,不胜任项目组织协调工作;
4、公司未能建立一个实施项目管理的良好氛围,连部门经理对项目也采取踢皮球的态度;

·协调(2003-08-01) [作 者] 王少飞 [公 司] 商务中心

找总经理要求协调,召集方案部、技术部坐在一起,根据实际情况
来安排;因为都是公司的事,如果耽误了,对公司和个人都不好

第 638 页 共 756 页
第 8 章 团队管理

·唉,怎么都是这样啊(2003-07-15) [作 者] 田京平 [公 司] UNIHUB PMO

1、公司流程、制度不严谨
2、大王的工作责任心不强,早干什么去了?未雨绸缪啊!
3、个人关系不太好,关键时刻没有人帮忙啊,呵呵

·解决问题要彻底(2003-07-03) [作 者] 廖清平 [公 司] 恒基(中国)

一、问题
1、公司内部的操作流程有问题或不清楚。
2、大王的责权不对等,她/他的上司应给她/他“安排”、“要求”的权力,而不是去求人办事。
3、大王自己应负一定的责任,她/他对操作程序的理解不够深透,沟通缺乏技巧,办事没有魄力,遇
到自己无法解决的问题未及时反映,寻求帮助。
4、各部门的协作性差,对多项目管理缺乏统筹安排、前瞻性差、责任性差、遇事推诿。
二、解决办法
1、争取客户延长时限。
2、组织小林等赶写建议书。
3、改编公司的操作流程,组织学习操作流程,整顿公司职员的办事作风,争取下不为例。
给大王放权。

·我的一点看法(2003-06-12) [作 者] wangxuxi [公 司] 温州环球

在本安例中,我认为有两个值得关注的点:一、项目管理实施的环境条件;二、项目管理、实施本身。
作为本案例中出现的每个人,他们首先在项目管理、实施过程中走了弯路。
大王来说,他成了个被人踢的皮球。自己受点气也就不题了,但是项目能否实施现在成了个大问题。
而方案准备部部长,他成功的将大王踢远了一点,但是这并不能解决问题,没准大王会和他的顶头上
司会一起来找他要他完成大王的事,这非解决之道。技术部部长并没有帮助大王解决问题,他引大王
上的是更加非程序化的道路。公司的工作要依据一定的程序进行,工作才不会混乱,他引导大王去找
小林,其实是饶过公司的部分程序工作,这对项目的管理实施本身有不可预见的风险。找到小林,再
度增加了一个问题:如何赏罚、监控小林的工作,通过什么样的渠道帮助小林的工作。小林所面临的
问题就是项目在非程序化状态下所面临的风险的总成。
另外一方面,公司的决策者负担着项目管理实施环境营建的职则。项目的实行,不能脱离他的实施环
境。公司所面临的是什么样的一个实施环境呢?1、因相互间踢皮球,引起的客源损失的风险;
2、项目有被部门间踢皮球的风险;
3、因相互间踢皮球,引起的同事关系的紧张;
4、是否允许公司在运行过程中,个人随意的绕过公司的工作流程工作。
5、怎样合理分配工作内容责任、权益
6、怎样可以避免类似大王的事件再度发生而影响公司的发展,7、7、借助改进此弊端,促进公司的

第 639 页 共 756 页
第 8 章 团队管理

发展。
管理体系的构件我认为是为了在部门实施项目的过程中有一个通行的标准。这种标准经过公司全体人
员的努力,他会构建一个非常好的工作环境。使得责任明确,权益清晰,团结合作,共同进退。这是
领导者应该做的事情!也是只有领导者能做的事情!
其实,大王没有将他的项目以书面的形式交付到方案准备部,问题的隐患便已经埋下了。事态的进一
步发展,更加暴露出了公司体系中的问题,并进一步影响到项目管理的实施。
现在,能解决眼前难题的只有公司决策者。这是最好的路子。
但是我还想说的是:大王所经历的事,对与公司来说,是一种内耗。他如同我们在生产产品时的产品
损耗一样。产品损耗,我们可以计算出来,并且摆在眼前;而这种损耗, 无声无息,消耗的是公司
发展的时机,公司进步的人的动力!

·沟通与实施(2003-05-30) [作 者] huanfang [公 司] shenzhenrongxing

造成现有的这种不良状态,主要是协调员沟通不力;方案准备组对项目的计划和实施不当;以及公司内
部人力资源优化欠缺等原因所致
作为项目售前支持协调员,按支持流程办事是不可少的,更重要的是与客户和公司内职能部门的沟通
方法,手段的问题。在项目的整个流程中要始终明确各阶段目标的实施情况,决不能有任何大意。
至于问题的解决办法,我比较认同张岩所列举的第 1 和第 2 条方法。

·problem is first(2003-05-29) [作 者] Zhang Xiaohang [公 司] 凌云逻辑

我赞成张岩的看法和主张,解决问题是首要的, 俗话说车到山前比有路,方法大家已经说了很多,
可以算是群策群力了。

改变工作习惯,包括同事对大王的习惯印象是一件长期、需要耐心的工作,大王要抛弃自己是皮球的
意识,把工作有序、准时的完成是以后工作的目标,如果项目中十有八九都这样,大王要好好检讨、
改善自我。把皮球变成公司的柱石。

·需要裁判(2003-05-27) [作 者] 龚喜杰 [公 司] aerostrong

在这个案例中,出现了我们常看到的公司部门或责任人之间的扯皮现象。
公司层面的存在的问题:
职责不清;
口头承诺多书面文档少,又流于形式;
缺乏对项目部门和职能部门间的协调和项目之间的协调(这也是近来项目管理办公室受重视的原因之
一);
大王的问题:
风险预见不足;

第 640 页 共 756 页
第 8 章 团队管理

平时人际关系开发不够;
显然,大王是扯皮结果的承担人。为了不出现这样的情况,寻找“裁判”解决问题是大王目前最好的
办法,也是最有效的办法。至于沟通的方法,很多网友都已经给出了很好的建议,不在赘述。

希望大王能顺利解决问题,并认真总结吸取经验教训。

·还是协调不够(2003-05-27) [作 者] airon [公 司] airon

我觉得还是协调不够。
关键是务部门关系太死,太管理化
有必要叫相关部门加班到天亮应该能完成吧。

·沟通协调(2003-05-27) [作 者] 至尊月 [公 司] 项目管理部

我赞成张岩的说法,尽量做好沟通,这样才可以使客户,领导,和同事之间的矛盾减少到最小。

·他该咋办(2003-05-24) [作 者] tong [公 司] General-tech

因大王充当前期项目协调员的角色,应当将情况汇报给上级领导,让领导层了解情况,从而可指明方向
和确定方案准备部交出方案.
采取预防措施是要求公司明确规定协调员,方案准备部,技术部的职责,同时要求公司推进改革力度,
实施绩效管理体系.

·由老总亲自拍板决定(2003-05-23) [作 者] Ken [公 司] HongYe

制作这份方案不是小林份内的事,虽然可以出于友谊帮忙,但由于小林来说没有责权关系,加上他自
身还有工作,他不一定会认真的加班赶工,很有可能粗制滥造。作为这件事情的直接责任人,对大王
来说风险太大。
我认为大王应该直接与老总交流,主要有以下三点:
1、方案的延迟与方案准备部的工作方式有直接关系。(大王没有必要替别人定罪,让老总了解真实
情况对公司有利。)
2、方案的延迟很有可能导致客户放弃该项目,说明利害关系,并将当前了解到的其他部门以及小林
等相关人员目前的工作情况向老总汇报。
3、提供以下三个解决方法,请老总选择:I 放弃该项目;II 请方案准备部的人抽出人手加班赶工;
III 请老总安排技术部和小林制作方案,并应明确责任;

从这个案例我认为有三个教训:

第 641 页 共 756 页
第 8 章 团队管理

1、工作任务的委托应有书面形式的材料,口头交流有时很难引起重视,并有可能发生扯皮现象;
2、方案准备部的工作方式存在严重的问题,应该改进;
3、项目部在小林离开后,培养新人的力度不够,应该吸取教训。

·这个是跨部门协调问题(2003-05-22) [作 者] ziye [公 司] volcano

其实对于这种跨部门协调然后又不太合作的问题,大王一个人是没有办法解决,最好是先得到老总的
授权或让老总出面来解决

·先解决问题,客户是最重要的(2003-05-22) [作 者] 张清俭 [公 司] 大连

1、大王和客户沟通,项目建议书的完成时间可能会出现变更,请客户谅解,同时告诉客户自己的纠
正措施。
2、请小林帮忙,加班完成项目建议书。
3、问题的出现是由于方案准备部的工作安排失误造成的,大王应该和张经理会谈,让他认识到问题
的严重性并避免以后发生类似的事情。
4、感谢杨经理和小林。
5、请小林对项目组成员进行培训。
6、对这件事的教训进行总结并在项目组会议上讨论,主要的、能够进行决策的人要参加会议。
这是大王短期内要做的事情,过后,大王要从各个方面进行分析,包括自己存在的问题。
另外,我不同意应付客户,这是对项目不负责任的表现,是违反职业道德的。

·我很赞成授权一说!(2003-05-22) [作 者] 彭桃平 [公 司] 浙江古越龙山绍兴酒股份有限公


我很支持 barrett 的观点,作为一个项目管理者,虽然不要完全主管这个项目的全过程,但是作为项


目前期的主管,就必须有一定的权利来实现管理职责,项目前期,项目方案的设计不可能是大王的职
责,只能是技术部门的责任,而大王要动用技术部门力量,没有授权,就不可能想指挥自己的小兵一
样那么得心应手,一定的权利加上大王良好的沟通能力,相信一定会解决好困难,过了这关,大王还
必须制订好合理的进度计划,不要再出现“要如厕了才开始建厕所”的烦恼!

·解决问题(2003-05-22) [作 者] 光光 [公 司] mshome

本人认为,碰到这个问题分两步走。
首先把客户对付过去。很显然张经理手上的 case 相当重要,这时候向他要人,几乎不太现实,那么
只有求助小林,不过注意沟通技巧。对于 B 区的情况,大王相对比较清楚,可以大王自己和小林参考
A 区的建议书一起赶,另外马上和客户进一步沟通,要求时间宽限,注意技巧。

第 642 页 共 756 页
第 8 章 团队管理

其次,一定要吸取教训:
1、大王本人对于在一周前就已经开始计划了,但要督促实施,而不能因为张经理说不急就任由拖延,
此大王一过。
2、大王提出要求,张经理没有理由就拖延任务,张经理一过。张经理在前一周对于一周以后的工作
没有前瞻性,此一过。
3、小林已离开项目组,那么项目组应该马上安排人员接手小林的工作,吸收小林的经验,至少应该
有小林以前的建议书档案,可以借鉴。
最后总结情况上级领导应该了解,并找相关人员谈话。下不为例。

·非常时期,(2003-05-22) [作 者] 黄鹤 [公 司] hb

此事大王责任重大,是他自己造就了这一切,:
1、计划落实不到位,属于失职,造成今天如此被动的局面
2、工作流程不清,责任不明,这工作该是谁的,就是谁的,岂容到处“推销”!
3、大王已经给了别人一个习惯,把自己当球踢,原因就是工作力度不够,平时工作责任不明!这种
习惯一定要改,因为人们之所以爱踢皮球而不爱踢石块,原因就是秋踢的舒服啊,石块踢了不舒服,
指头受不了,搞不好还得起泡,下次肯定长记性,自然也就不踢了。
4、自己没有判断力,东风来东风倒!要想得到小林的帮助,要么有上级的调派,要么只能是友谊赞
助,否则小林没法帮,因为他已经不在原部门了。再说,此刻情况紧急,风险这么大,这种只有苦劳
没有功劳的事,谁都会掂量掂量。
但事已至此,救火要紧,可眼下情况以非常紧急,大王得考虑这事他能不能扛得住,扛不住,就找你
的上级,不要碍于开口,觉得这样老大对你印象会不好,其实,走到这一步,作为老大肯定会帮你的,
再说,老大的出现,事情会容易的多!这么大的资源为什么不用呢?不过,在去老大之前,一定要想
好几个解决方案,供老大决定,记住:老大们总是爱做选择题,不爱做难题!
此外,我还觉得公司的管理有问题,像这样的工作,无缘无故说缓就缓,毫无依据。

另:我建议,如果这事是真实的话,此事结束后能否将此过程和结果,再给大家反馈一下,不要石沉
大海,放空枪,我们想看看子弹距离靶心还有多远!这样可能对大家更有帮助!

·任务分配不明确的问题(2003-05-21) [作 者] 罗磊 [公 司] 华立科技

我认为是一个任务分配不明确的问题,既然大王是负责项目协调工作,那么他有必要将任务落实,明确
最后期限,并要相关负责人签字认可,如果他这么做了,肯定不会出现这种情况

·我认为还是个授权的问题(2003-05-21) [作 者] barrett [公 司] IT

作为协调员却完全没有调动资源的能力,真是可悲,建议找更层次的经理来处理,有多少权力负多少
责任办多少事,这本来就很正常嘛,大王有什么错,不过“其实大王前一周就向他们说过写项目建议

第 643 页 共 756 页
第 8 章 团队管理

书了“,如果是书面的正式文件就更好办了。

·如果只是协调员(2003-05-21) [作 者] 项目管理 [公 司] 无

从该案例来看
1.如果大王觉得找高层解决不合适
2.如果公司确实没有适当的资源
3.如果大王确实具备该行业的售前经验(从语气上猜测可能是 IT 行业)
4.如果大王能调度的资源实在有限,手中的牌不多。

大王换个角色吧,换成临时方案经理,拉着小林一块儿把这个方案赶完就 OK 了。然后总结教训,不要
下次犯同样的问题。

·办法总比困难多(2003-05-21) [作 者] 张岩 [公 司] 政府部门

从这个案例中,按照项目管理所涉及的主要因素,本人认为至少含有项目的范围管理\时间管理\人力
资源管理以及沟通管理,在这个意义上说,大王必须综合考虑以上这些因素,才能按时保值保量地完成
任务.作为项目的售前协调人员,对以上这些因素以及自己公司的这些情况包括工作效率\人员的使用
\公司的重大决策和战略等必须了如指掌,才能更好地工作.
从这个案例看,大王作为项目售前协调员没有按照客户的要求的时间,有计划地去实施这个项目,即使
有计划,也没有按照计划去具体实施,从而导致客户下达了最后通牒,使工作变的非常被动.

目前解决的办法:
1\坚持说服张经理的部门去写,因为他们应该是最有能力去完成这个工作的,也应该是能完成这个工
作最好的部门,但这需要说话的技巧和策略.
2\抓紧时间收集资料,让小林写,并要求张经理的部门出人学习和协助,因为小林比较熟悉该项目,还
有时间,张经理部门有资料,技术部有经验,都可以协助.同时,抓紧时间向客户保证并再延长时间,以
使项目完成.
3=采取张冠李戴的办法,可以将原来 A 地区的同样的项目建议书加以改进,给客户,这个办法主要是拖
延时间,先拿一个去应付客户,以征求意见的方式给客户,同时这边继续进行工作,拿出一个更加细致
的更好地项目建议书给客户.

·一个公关问题(2003-05-20) [作 者] fatbig [公 司] MyHome

[每个人都会认为自己的工作最重要,但是每个人都需要别人的合作。我希望得到大家的支持。],大
王应该这样说,在一个为此项目举行的项目资源协调会上。

第 644 页 共 756 页
第 8 章 团队管理

这个协调会能否召集起来和能否得到相应的资源,实在是衡量你的公关协调能力的好机会。

如果你的表现能够让与会者眼睛一亮的话,相信如果解决了这个问题之后,还有更好的机会等着你。

记住一定要请到能够拍板的人与会。

·大王并非是“无辜”的(2003-05-20) [作 者] hnbl [公 司] dd

这个问题我想应该在绝大多数的组织中都存在,是具有共性的。分析此类问题,不能单纯的说职责不
明确或直接说流程上是谁负责就 找谁,“应该”的东西和“实际”的情况往往是不一致的,否则,
这样的组织中管理者也太清闲了。

此案例中,我想大王也并非是“无辜”的,他也应负有部分责任。身在此组织中,他应该对部门、人
员的办事风格有所了解,应预计得到某些部门(比如说方案准备部)的办事效率,从而应提早动手准
备,而不用搞的如此紧张被动。当然,这其中沟通是至关重要的,方案准备部可能也会找出千般理由
来拖延,这就看大王说话的技巧了,比如说:“老总要先看一下项目建议书”。

如问题僵持不下,可以找他们共同的上级来协调,

·计划好才不会焦急,沟通好才没有盲目!(2003-05-20) [作 者] 彭桃平 [公 司] 浙江古越龙


山绍兴酒股份有限公司投资发展部

作为一个项目前期管理人员,缺乏紧凑的计划才会造成焦急;项目管理,本质上就是一个未来的有效
计划,尤其是项目前期管理,因为涉及太多的未知因数而带来太多的变数,作为管理者就应该加强对
项目前期所发生的事件进行跟踪并及时处理。大王的怠慢直接导致了客户的时限要求;同时,没有很
好的与相关部门沟通,也直接导致相关责任的推卸现象。做一个项目,要设计好组织结构、进度计划,
并且还要即使同客户联系,保证项目信息、要求的现在进行时!

第 645 页 共 756 页
第 9 章 人力资源管理

第9章 人力资源管理

9.1 *三只老鼠的“偷油”项目失败折射出的企业绩效管理问题

(一)案例:三只老鼠的“偷油”项目失败折射出的企业绩效管理问题

姓 名: 廖华清
单 位: 科健
邮 件: kinssenger@163.com

案例正文:

三只老鼠一起去偷油喝,找到了一个油瓶。三只老鼠商量,一只踩着一只的肩膀,轮流上去
喝油。于是三只老鼠开始叠罗汉,当最后一只老鼠刚刚爬到另外两只的肩膀上,不知道什么
原因,油瓶倒了,最后,惊动了人,三只老鼠逃跑了。回到老鼠窝,大家开会讨论失败的原
因。最上面的老鼠说,我没有喝到油,推倒了油瓶是因为下面第二只老鼠抖动了一下,所以
我推倒了油瓶,第二只老鼠说,我是抖了一下,但我感觉到第三只老鼠也抽搐了一下,我才
抖动了一下。第三只老鼠说:“对,对,我因为听见门外有猫的叫声,所以抖了一下。

“哦,原来如此呀!”

企业里很多人也具有老鼠的心态。请听一次企业的季度总结会议:
本文转自项目管理者联盟

营销部门经理 A 说:“最近销售做的不好,我们有一定责任,但是最主要的责任不在我们,
竞争对手纷纷推出新产品,比我们的产品要好,所以我们很不好做,研发部门要认真总结。”

研发部门经理 B 说:“我们最近推出的新产品是少,但是我们也有困难呀,我们的预算很少,
就是少的可怜的预算,也被财务削减了!”

财务经理 C 说:“是,我是削减了你的预算,但是你要知道,公司的成本在上升,我们当然

没有多少钱。

这时,采购经理 D 跳起来:“我们的采购成本是上升了 10%,为什么,你们知道吗?俄罗斯


的一个生产铬的矿山爆炸了,导致不锈钢价格上升。”

A、B、C:“哦,原来如此呀,这样说,我们大家都没有多少责任了,哈哈哈哈!” 人力资源
经理 F 说:“这样说来,我只好去考核俄罗斯的矿山了!!”

面对企业这种常见情况,大家有什么好的解决方案吗?

(二)项目管理者联盟专家点评

第 646 页 共 756 页
第 9 章 人力资源管理

专家介绍: 常耀俊 联想大中华区项目管理总监,PMP。

常耀俊点评:

老鼠的偷油这个案例可以从几个角度来剖析。如果把这件事当成一个项目,那么它是一个失
败的项目,油没偷成,浪费了半天功夫不说,精神和士气上也受到了打击。 项目管理者联盟,项目管理问题。

项目管理者联盟,项目管理问题。

对于这个失败项目,我们第一个可以总结出的结论是:做任何事情要重规划而不是重总结,
只有规划好,把该考虑的问题全都考虑好,才可以最大限度的避免问题的发生,美国项目管
理协会出版 PMBOK 这样一个项目管理的知识体系,也告诉我们做好一个项目应该按照 5
个过程(启动、计划、实施、控制、收尾)和 9 个知识领域(范围、进度、成本、质量、H
R、沟通、风险、采购、综合)去规划和实施。很显然,偷油这个项目没有按照这样一个思
想和要求去做,首先规划做得不到位,尤其是风险规划,对偷油过程中可能碰到的各种意外
和风险没有有效去识别和做好相应的应对计划,导致在具体实施偷油的过程中一个意外情况
的出现就把整个项目搞砸了;另外,沟通计划做的也不好,没有明确主要干系人在不能进行
语言沟通的特殊环境下,应该通过什么样的方式去相互传递信息,导致最底下的老鼠一个抽
搐就让上面老鼠抖动最终把偷油老鼠也给掀下来了;最后一点,选人和用人这些相关人力资
源规划上也有问题,为何不让心里素质好一些的老鼠担当罗汉阵的第一阶梯呢?好了不想一
一列举了,我想说的是,如果所有这些意料中的风险都能在具体实施这件事情之前去科学规
划、评估和做好防范措施,也许就没有这样一个偷油不成反蚀把米的结果了。因此,优秀的
项目团队,在实施项目的过程中,首先要考虑和做的应该是如何通过科学和严密的规划去规
避项目的失败,而不是出了问题后如何总结经验和教训。

第二个可以总结的是,假如该项目的规划也做了,该想的都想到了,该落实的也都落实到位
了,项目还是失败了,那就真的需要大家坐下来好好的总结一下经验教训了。总结经验教训
的主要的目的不是要惩治什么人,而是要总结规律来避免以后犯同样的错误。总结经验教训
找出导致项目失败的原因,其实就是我们平常说的项目或者团队业绩考核问题。其实业绩考
核不光是针对失败项目和成员的考核,对成功的项目也同样需要进行业绩考核,只是失败项
目的业绩考核比成功项目业绩考核更难,更容易形成案例中相互推诿和扯皮的问题,推诿和
扯皮不足为奇,关键是大家为什么敢这样,很简单,因为你的考核目标和 KPI 不是量化的。
大家都对目标的 SMART 原则很熟吧,假如在项目启动时,将参与关键干系人在项目中需要
承担的任务和达成目标用 SMART 来量化,我想出现推诿的机率会大大减少。我们就拿该案
例来说吧,某企业在某个业绩单元没有达成计划的业务目标,大家开总结会,销售认为是由
于研发没有拿出新产品造成的,研发埋怨财务预算费用不充足导致新产品上市推迟,财务认
为之所以削减财务预算是由于采购成本上升,采购反击是由于俄罗斯的一个生产铬的矿山爆
炸不锈钢价格上升才导致采购成本上升,因此人力资源经理才开玩笑的说如此说来我们只有
去找俄罗斯矿山主了。如果我们在计划之初就有一个按价值链分解和量化的业绩考核指标体
系,这事就简单多了: 项目管理者联盟,项目管理问题。

第 647 页 共 756 页
第 9 章 人力资源管理

http://blog.mypm.net

对于销售部来说,新老产品计划达成的销售指标是多少?分解到各具体产品上的销售指标又
是多少?那么实际中这些指标又有哪些达成了?哪些没有达成?没有达成是新产品吗?如
果不是,那么销售部抱怨新产品未按计划上市影响销售指标的论点就不成立了,销售指标达
不成完全是销售自己的责任。退一步,分析以后发现真是未上市的新产品影响了销售业绩,
那好我们再看研发部的实际研发成果,计划研制多少新产品?都是何时上市?这些指标哪些
达成了?哪些没有达成?没有达成的新产品研发计划是否与削减研发费用有必然关系?如
果没有关系,那就是研发部自己的责任了,如果确实是研发资源投入影响了新产品的研发计
划,那我们再分析财务部的考核指标和实际业绩,分析削减研发费用和采购上升有无必然关
系,如果没有关系,费用投入不足就可能是财务部自己对资金管理不善造成的了,板子打在
财务身上。如果确实是由于采购成本上升导致的,而矿山爆炸又属于突发事件,那么只能说
明整个公司层面对风险缺乏有效的预防和应对机制,公司应该从这件事情上总结经验和教
训,在公司层面上建立起有效的风险应对机制,如建立风险管理储备和应急储备。因此,我
要说的是,业绩考核是建立在公平、公正、量化和透明基础上的,如果没有这样一个业绩体
系,业绩考核就形同虚设,就会出现案例中的现象,有了业绩大家都去争,出了问题大家都
互相推诿,不承担责任。
http://blog.mypm.net

最后一点,对于案例出现这种现象,其实不同公司的团队和员工会有不同的反应,一种反应
是,问题发生后,大家不是相互的推诿扯皮,而是积极采取应急和应对措施尽量减少风险造
成的损失;另外一种,就是本文案例中出现的这种相互推托责任的情况了。不用说,采取积
极补位和应对措施的企业具有一种积极向上、团结互助、业绩导向的企业文化,在这种文化
氛围里,如果有人推委责任立即就会被大家视为不良行为受到谴责,这种人要么离开公司,
要么立即纠正自己的言行;反之,在一个大家都不愿意承担责任、非业绩导向文化的公司里,
勇于承担责任的人反倒会被孤立和打击。最后一点,我想说明的是,在好的业绩体系、再量
化的业绩指标也代替不了良好的公司文化,一个积极向上、业绩导向的公司文化才是杜绝推
委扯皮的良药。

(三)项目管理者联盟网友评论

分析 1:题目:责任要明确 作者:张华 (中国石化宁波工程有限公司 zhhlucky@gmail.c


om)

三只老鼠相互推诿的原因在于他们之间的关系过于紧密,相互之间无法形成独立的责任标

第 648 页 共 756 页
第 9 章 人力资源管理

准,因此,一旦有事,很容易就推诿到别的部门。
绩效的管理考核应该尽量量化并且明确责任,清晰各相关部门或人员的责任。

分析 2:题目:以动制动 作者:xin (湖南 xinxinhaha259@163.com)

市场瞬息万变,企业不管是面对内部竞争还是外部环境的变化都需要有未雨绸缪的准备,当产
生问题时我们应该积极应对,而不是互相推卸责任,大家应该互相信任体谅才是正确的做法.
市场销售出了问题,跟新产品的研发有一定的联系,但是如何在不利条件下保持企业正常运
作。在问题出现之前是否就应该考虑到?
项目管理者联盟,项目管理问题。

另一方面,新产品的研发与资金投入也未必成正比关系,一个泉思文涌的诗人就算喝酒也能写
出好诗,而一个莽汉天天大鱼大肉也未必能想到什么,所以研发应该更加注重人才的培养。 项目管理者联盟文章,深

入探讨。

财务方面应该要有预算,根据对公司实际情况的分析来合理运作,这样在出现财务危机时才能
应对自如。

采购部应该掌握最新的原料信息,与供应商建立长久的合作计划,同时发掘新的合作伙伴.
另外我认为企业对于部门应该多予以奖励,不要只看见老鼠没喝到油,而忘记了第三只老鼠也
许救了三只老鼠的命.增加各部门的交流,也许下次第二只老鼠会告诉第三只老鼠:有我在上
面盯着,你就不用害怕了。这样第一只老鼠喝油,第二只老鼠把风,第三只老鼠全心支撑,何患
无油?

分析 3:题 目:消息不等于信息 作 者:ForestLin (CATTSoft forestlin@pku.org.cn)

任务失败无论何种主观解释都不能原谅,一定要对相关责任人进行处罚。

通过这个案例,能看出每个单元都把与自己相关单元的简单消息(或者信号)当成对自己有
直接关联的信息,体现出各单元没有有效的交流渠道,同时在这之上的层面也没有一个情报
部门对所有与之相关的消息收集、整理、分析、评估;最终导致了以讹传讹,一点点的不利
消息就夸大为影响成败的关键因素。

作为公司,应该建立完整有效的情报体系,并给各部门间提供有效的沟通渠道,这样对避免
类似失败会有帮助。

分析 4:题 目:三只老鼠折射企业的绩效管理问题 作 者:林立 (华创(北京)科技有限


公司 sinoboy2004@yahoo.com.cn)

这个案例反映了项目管理中项目立项和计划的两方面的重要性,首先,项目经理在做项目计
划时就没有明确各项目成员的责任,这是造成最后相互推诿责任的主要原因。另外,项目经
理在项目立项时对风险的评估不足也导致了项目无法正常完成。

分析 5:题 目:加强项目中的横向管理 作 者:dannyxia (深圳 xiaqhua@163.com)

第 649 页 共 756 页
第 9 章 人力资源管理

看完案例,第一个想到的就是项目横向的管理比较弱,也就是各部门的工作相对都很独立,
彼此信息不公开,缺乏有效的沟通。项目经理没有采取措施把各部门工作串连起来。所以导
致最后项目的失败。追究责任的时候就都开始找借口,互相推诿。当项目比较复杂,需要多
个部门协同作战时,矩阵管理是必要的,同时项目经理要做好与职能部门经理的沟通工作。

分析 6:题 目:三只老鼠折射企业的绩效管理问题 作 者:liuhongbin (seasun lhb1206


@163.com)

问题的实质是相互的推委,例如销售的问题主要原因是没有新的产品吗?开发的原因是单纯
的没有资金吗?等等,其实问题的存在是各个部门在寻找推脱责任的理由。

因此,我以为首先要分析产生问题的原因,而不是找推脱责任的理由。
再者,我们需要针对问题找出解决方案,可以开跨部门的分析会议,我们的主要目的是为了
解决问题,而不是惩罚某个人或某个部门。 项目管理者联盟,项目管理问题。

第三,根据分析的结论指定每个部门的行动计划,并组织实施以实现我们共同的目标。

分析 7:题 目:一定要罚,一个都不能少 作 者:Danny (InsIT Pegasus_cc@163.com)

遇到问题向别处推脱是一种心态,这种心态在项目出现问题时非常普遍。
员工说项目经理的工作不得力,监管不好,没有安排好计划。项目经理说出现意外,客户修
改了需求。公司高层说天气不好,供应商不好,政府行政拖时间等等。
总之人们经常说项目缺乏时间人员金钱,但从来不缺少失败的理由。

解决方案:首先是最上面的老鼠要被罚,它是主要做事的,其他人都是为了配合它,失败的
主要责任由它负。第三只老鼠和第二只老鼠一样受罚,它们没有很好的完成配合工作,导致
项目失败。 http://blog.mypm.net

做项目要看结果,不管是什么借口,失败就是失败。再华丽的借口也无法掩饰失败的结果。

其中罚的最重的应该是最上面的老鼠,在未明情况下放弃项目,也未对下面出现的情况进行
沟通,导致了整个项目的最终失败。

9.2 矩阵项目组织中的人力问题

矩阵项目组织中的人力问题

[姓 名] 周君 [单 位] 中央财经大学 [邮 件] cufezhoujun@sina.com
[所属行业] 综合应用 [所属主题] 项目沟通管理 [发布时间] 2007-9-5

第 650 页 共 756 页
第 9 章 人力资源管理

【案例正文】
背景:
<FONT&NBSP;FACE=VERDANA>Multi Project 公司是一家拥有 400 名员工,经营良好的咨询
公司。它同时为多个客户进行许多项目。这家公司有良好的信誉,有近 30%的业务来自于老客
户。考虑到将来的业务,它瞄准了成长中的公司,并且也有很大的收获。由于业务的扩大,一
些事情变得很紧迫,员工要尽力完成工作,让老客户满意,还要满足新客户的要求。
<FONT&NBSP;FACE=VERDANA>Multi Project 公司一直在雇用人员,事实上,在过去两年里,
员工已从 300 人增加到 400 人。
<FONT&NBSP;FACE=VERDANA>Multi Project 公司采用矩阵型组织结构,有了新项目后,就
任命一位项目经理。根据项目规模,一个项目经理可能同时有好几个项目。项目价值从2万~
100万美元,期限一般为一个月至两年。绝大多数项目期限是6个月,价值约60万~80
万美元。公司提供一系列咨询服务,包括市场研究、设计生产制造系统、招聘人员等。客户是
一些大、中型组织,包括银行、生产企业和政府机构。
一天,<FONT&NBSP;FACE=VERDANA>Multi Project 公司接到Growin 公司的电话,同意进
行Multi Project 公司近6个月前提出的一个项目。这个消息很是令Multi Project 公司的股东
们感到意外,他们本以为这个项目已经没希望了。另外,他们也非常希望能给Growin 这个迅
速状大的公司进行第一个项目。Multi Project 公司很有可能将来为Growin 公司做几个大项目。
杰夫·阿姆斯特朗(Jeff Armstrong)被任命为项目经理,负责Growin 公司的项目.他于一年前
加入Multi Project 公司,一直急于管理一个有意义的项目 。Growin 公司项目的计划报告是由
他来完成的。
泰勒·博尼拉(Tyler Bonilla)是一个高级系统工程师,已经在Multi Project 公司工作了 8 年。
他很有名气,那些曾经服务过的老客户通常都要求在他们的项目中要有他参与。尽管非常忙,
但他还是干得很起劲。他目前正专职为一家老客户 Goodold 公司的项目工作。Goodold 说,他
们不选择另一家咨询公司,而是与Multi Project 公司合作的原因之一就是因为泰勒在他们项目
中的出色工作。
詹妮弗·弗尔南德斯(Jennifer Fernandez)是系统工程经理,在Multi Project 公司已经工作了
15 年了。她是泰勒的直接领导,但由于泰勒工作任务繁重,经常出差,除了每月的员工会议,
他很少见詹妮弗。
负责 Goodold 公司项目的经理是朱丽·卡普里奥罗(Julie Capriolo),她在Multi Project 公司工
作 2 年了。泰勒被分配到她的项目中专职工作。这个项目时间很紧,每天都要加班。朱丽工作
压力很大,幸好她有一个不错的项目团队,泰勒更是得力的助手。她曾听一位与杰夫工作过的
朋友说泰勒很爱面子,会不惜一切使自己出色。朱丽对此并末在意,因为她与杰夫有各自的项
目,很少打交道。
在杰夫被任命为 Growin 公司项目的项目经理当天,他在走廊碰见了泰勒。他告诉泰勒:
“我们争取到了 Growin 公司的项目!”
“很好。”泰勒回应道。
杰夫接着说:“你也知道,他们之所以把这个项目给了我们而不是其他咨询公司,一个主要原
因是我们允诺要由你负责这个项目的系统工作。泰勒,当我们提出计划报告时,他们对你印象
很深。你认为什么时候可以开始在这个项目中工作?”
“很不巧,我帮不上忙。我在 Goodold 项目中脱不开身。事情确实很忙。我还得在这个项目中

第 651 页 共 756 页
第 9 章 人力资源管理

再工作 4 个月。“泰勒说。
“不行!”杰夫嚷道:“Growin 公司的这个项目对我——我是说对我们——太重要了,我要做好
这个项目。”

“那么你最好去找詹妮弗。”
杰夫到了詹妮弗的办公室。詹妮弗正忙着,但他打断了她:“我要让泰勒参加我的 Growin 项
目,他想参加,但说我应与你谈一谈。”
詹妮弗说:“不可能,以后的 4 个月时间他已经被分配在朱丽的 Goodold 项目中工作。”

“朱丽?她是谁?我不管,我要找她解决这个事情。你最好给她的项目分配其他人员。”
杰夫边说边冲出办公室,找朱丽去了。
詹妮弗喊道:“这由我决定,不是你或朱丽说了算!”但这时杰夫已不见了,没听到她的话。
朱丽正在会谈室里与她的项目团队开会。杰夫敲开了门,问:
“这里是有位叫朱丽的人吗?”
“我是朱丽。”她回答。

“我要尽快与你谈一谈,非常重要,噢,顺便抱歉打扰。”泰勒也正在开会,杰夫看到他,
说:“嗨,泰勒,等我与朱丽谈完后,就找你,老兄。”说完便关上门回去了。朱丽对此很是
恼火。
散会后,朱丽打电话给杰夫:“我是朱丽,你这么着急与我谈什么?”

“要把泰勒调到我的项目中来。他也愿意,我已经与詹妮弗谈过了。”杰夫说。
“不可能,他对 Goodold 项目很重要。“朱丽拒绝道。
“实在抱歉,
但如果 Growin 的项目成功了,我们就能从那儿获得更多的业务,
绝对要比 Goodold
公司的多。“
“已经六点多了,我需要离开一个星期。我一回来就会与詹尼弗读者讨论这个事。”朱丽打断
了他的话。
“好吧,随便你。”杰夫答道。

第 652 页 共 756 页
第 9 章 人力资源管理

第二天,杰夫召集詹妮弗和泰勒开会,他首先宣布:
“这次会议是要确定泰勒尽快开始参加 Growin 项目工人的时间,以及你(看着詹妮弗)什么
时候能派人接替他在那个叫什么名字的项目中的工作。”

詹妮弗说:“我认为朱丽应该参加这次讨论。”
“她来不了,显然她正出差一个星期,而我们需要马上开始着手工艺 Growin 的项目。我们要
准备好下周与他们的会议。没错吧,泰勒?”
“嗯,既然你问起来,我就说明吧,我对 Goodold 项目的工作已感到厌倦,我学不到任何新东
西。我是说, Goodold 项目工作没错,但我想变一变。”泰勒回答道。
詹妮弗感到很惊讶:“你从来没向我提起过这些,泰勒。”

杰夫说:“好了,我认为这个问题已解决好了。詹妮弗,你给 Goodold 项目分配一位销感


兴趣的人员。朱丽回来后,跟她说一声。同时,我和我的伙伴泰勒要做许多事情。安排好下周
与 Growin 公司的会议。“

问题:
1.杰夫急于 Growin 项目开工的原因是什么?
2.为什么泰勒这么抢手?
3.杰夫处理这个情况时,错在哪里?
4.詹妮弗怎样解决这一情况?
5.这个案例所表明的矩阵型组织有哪些优点?
6.这个案例所表明的矩阵型组织有哪些缺点?

【相关分析】

·PMO的重要性(2007-11-28) [作 者] snock [公 司] 广州某软件公司

矩阵项目组织有很多的优点,在资源可以被充分利用的情况下,资源冲突也就会经常发生,此时沟通协
调变得尤其重要.

成立独立于部门和项目外的 PMO 组织(项目管理办公室)也许是管理资源的较好方法.这个组织通

第 653 页 共 756 页
第 9 章 人力资源管理

常由具有决策力的高层,技术主管人员和项目主管人员共同参加.对于项目的进行充分的了解下对资
源进行合理的分配.

案例中的项目经理杰夫在组建项目团队的过程中,未与相关部门进行充分的沟通,他的工作方法
更象是"个人行为.

·矩阵项目组织(2007-10-11) [作 者] 张建新 [公 司] 东华科技

矩阵项目组织对于任何一个新项目来说都是必须的,因为一个公司要同时和长期运做项目,无论项目
是简单还是复杂,大合同还是小合同。都会以矩阵组织来成立组建项目团队。
其实,很明显,项目的任何资源都是公司的,项目经理取得资源必须得到资源拥有者--老板的同意和
支持。如果自己很急,私下组建团队后再找部门主管单挑,发生冲突是不可避免的。有经验的项目经
理是善于提前沟通的。
再者,就是非 XX 不可时,应向相关部门主管的上级--老板来协调,何必一意孤行呢!

·矩阵带来的沟通不足(2007-09-28) [作 者] 龙七 [公 司] AMDOCS

案例确实很复杂,但是总体就是一个人力资源问题,但是问题的症结在于通等部门之间需要协调人员。
问题是没有解决好以下问题:
1、杰夫没有及时和詹妮弗做好沟通。就这个项目的主要性和他需要的资源问题没有和詹妮弗做一下
好的沟通,这样导致詹妮弗对此事没有准备,不能很好的做事及时地解决。
2、詹妮弗和泰勒没有做好沟通。一方面泰勒没有告诉詹妮弗关于自己发展想法;另一方面詹妮弗没
有替下属的考虑未来发展问题。
3、詹妮弗没有做人才储备,对泰勒这么重要的人没有做好接替的准备工作。那么她的项目如果缺少
泰勒就是收到很大影响。
我认为即时在矩阵管理中也需要类似 pmo 的协调部门,这个统计部门之间要通过 pmo 来实现沟通和
协调比较好!

·矩阵项目组织中的人力问题(2007-09-18) [作 者] suntsang [公 司] XC S&T DEV

矩阵项目组织的优势主要在于提高人员利用率,但在多头工作环境之下建议从如下两方面把控:
1、矩阵项目组织不可避免资源争取,这个时候就需要一个强有力的裁判者来均衡和优化,具体的规
则可能是效率优先也可能是业务优先,但这个裁判者是利用一系列成本计算最后通过实权人物辅助实
行还是又实权人员决策为主,会给公司内部的资源配给及竞争机制带来完全不同的影响。
2、由于资源的多头使用,资源使用计划需要更加详细和精确,人和物都是需要细化的,即便物的替
代相对容易,但考虑到公司的实力不可能无限大,所以共享机制还是要制度化。

·建立项目组织和公司组织的结合最关键(2007-09-11) [作 者] daijiangbao [公 司] 深圳市大视野企业


管理顾问有限公司

矩阵结构的复杂在于沟通,沟通不能离开项目的组织,项目的组织又不可能离开公司的组织,所以要

第 654 页 共 756 页
第 9 章 人力资源管理

理顺项目组织,还不能脱离公司组织,这样才能知道谁该给谁报告,谁有权做什么决策,才清楚如何
见人说人话,见鬼说鬼话,这是矩阵组织成功的关键

·沟通合作(2007-09-11) [作 者] hjh [公 司] 力鼎

矩阵式组织间的资源矛盾是其主要的特点,是一个无法回避的问题.如何有效地解决这方面的问题,关
键在于项目经理间的通力合作.每个项目经理都想干好自己的项目,但你也要想到,公司并非只有你这
一个项目,对其它项目的支持也就是对公司的支持,因此,在项目之间的合作上,要有长远的考虑,今天
可能是别的项目经理在求你,明天可能就会有你求别人的时候,采用这种换位思考的态度,通过协商来
解决问题不是很好吗?有的问题不一定组织出面解决就是一个最好的办法,强势也只能解决一时的问
题.
另外一方面企业也应重视对人才的培养,对关键岗位的人才要制定人才储备计划,这样在公司的成长
过程中,不至因关键人员的矛盾而影响项目.

·矩阵型组织中的矛盾(2007-09-07) [作 者] quing [公 司] 电力公司

在矩阵型组织中,来自各个职能部门的人员在可以为某一个具体项目专职工作,也可以同时在其它多
个项目中兼职工作。通过在项目间共享人员的工作时间,可以充分利用资源,降低公司及每个项目的
成本。就如同该案例中泰勒·博尼拉这个高级系统工程师,可能就要同时参加几个项目。
但是也正是多个项目共享了可能关键的人力资源,同时新项目的建立与旧项目的持续进行,也将加剧
这种矛盾,加之项目分大小、轻重、缓急,可能某个项目正在实施,遇到了新的又比较紧急的大项目,
人力资源需求发生偏向,可能影响相关的项目,这就是矩阵型组织的缺点。
当公司接到新项目后,项目副总裁将为项目委派一位项目经理。一个项目经理可以同时管理几个小项
目,但大型的项目就要有专职的项目经理来负责。接下来项目经理就要与有关职能经理协商,从各个
部门中为项目分配工作人员。这些人员根据实际需要为项目工作一定时间,其中部分人员专职为项目
工作,其他人员只为项目某一部分工作,甚至只在项目中出现一两次,这要根据项目何时需要他们的
技术以及项目预算允许他们工作时间长短而定。如果项目人员未被利用的时间累计很多,那么,即使
每个项目在预计的时间内完成,公司也可能亏损。因此在其他项目即将结束的同时,公司应不断获得
新的项目,以便使员工有较高的实际工作时间率。从行政关系上来说,项目经理与部门经理处于同一
地位,同时均领导着项目成员,这样便出现了“多头领导”现象,必然导致在涉及到项目优先次序,
资源配备(包括人员、资金、时间等)等问题上造成冲突。
要解决这一问题,首先从企业内部应明确项目经理与职能经理的职责,保证在项目经理与职能经理间
适当的权利平衡。
在矩阵型组织中,项目经理是公司与客户之间的媒介,项目经理的职责是确定做什么(工作内容、何
时完成、进度计划)、多少费用(预算)等问题,以实现项目目标、使客户满意。他应作好工作结构
分析(WBS),确定那些工作由公司内部完成,那些工作由承包商完成。同时组建项目团队,制定进
度计划及预算,为公司相关部门划分具体工作任务、工作界面和预算,并监控项目有关部门执行情况,
确保项目目标完成。

第 655 页 共 756 页
第 9 章 人力资源管理

而部门经理的职责是决定如何完成好项目经理分配给本部门的任务,并确定每项任务由谁负责。组织
结构中每个职能经理要在技术上指导和领导项目中的本部门工作人员。同时他有责任确保该部门承担
的所有任务都能在给定的预算范围内,按照项目的质量及技术要求准时完成。部门经理一定要对他部
门内人员的工作任务保持监控,并根据各个项目情况的变化――如进度拖延或客户要求作出变化等,
进行重新配置。如果项目进度落后,无法按客户要求日期完成,使项目陷入困境,部门经理可以同项
目经理协商,从正常工作的一些项目中调派人员补充到这些项目中去。
其次,要明确团队成员汇报关系,以及对什么职责和任务进行汇报。矩阵型组织结构中的项目团队成
员有两层汇报关系:临时性的项目经理(业务上)及相对永久性的部门经理(行政上),一般说来,
这些人员对他们所在的部门有较牢固的忠诚,但项目团队也需要他们的忠诚奉献。
最后,当两者之间的冲突难以解决时,就必须有更高层的管理人员出面解决。这里更高层的管理人员,
作为项目经理的汇报对象,也是职能经理的行政领导,在矩阵组织中的角色十分重要。例如他可以解
决组织内两三个项目间在先后次序上的冲突,并对冲突进行仲裁。

·资源储备,职场道德(2007-09-07) [作 者] baoyi [公 司] 群創光電PM

另一方面也反映了詹妮弗可能对于本部门的人力储备有所欠缺;
很惊讶杰夫能作为项目的主管,在本文中表现的态度近乎粗鲁和野蛮.

·利益,资源,沟通(2007-09-07) [作 者] baoyi [公 司] 群創光電PM

1.Growin 项目符合公司的发展利益;对自己也是难得的表现机会。
2.能力及执行力的优秀。
3.未将自己摆放在一个平等的位置,从全局考量与别人沟通。
4.A-确认两个项目的优先等级(可以向高层寻求答案)。
B-(Growin 项目优先)与杰夫面谈,告知其,从公司利益出发,会对人员进行调整,以配合杰夫工
作,但需要给与泰勒交接工作的安排。另一方面,建议其用积极客观的态度于朱丽就此次人员异动进
行对话沟通。
C-联络朱丽,告知其基于公司利益,会同意 Growin 项目对泰勒的需求,同时安排合适的人选协助
Goodold 项目,在泰勒离开时顺利完成交接,请其做好准备工作。
D- 与泰勒会面,肯定其在工作上的突出表现,并表示考虑公司利益及其个人发展意愿,会安排项目
人员异动,请其做好交接工作;另外,告知其在公开表达意愿时务必实现与自己讨论,作为主管会在
为其在合理的范围内获取最大的利益。否则会对相关人员造成困扰。
5.优势,职能主管的存在对于项目资源的冲突有调整作用。
6.劣势,项目主管对于项目资源的主导权无法完全掌控,存在风险。

·项目资源(2007-09-07) [作 者] sunny [公 司] 123

项目经理在项目开始请应该做好资源分配工作,并且对项目关键资源做好风险管控.

第 656 页 共 756 页
第 9 章 人力资源管理

·协同(2007-09-07) [作 者] 乔 [公 司] No

简单的看了一下,主要的问题还是管理资源的问题,如何有效的使用现有资源,达到分配的均衡。同
时也要了解到人员当前工作的情况,如离职走人等情况。
当前文中所说的管理不能很好的解决跨部门的协同问题。

第 657 页 共 756 页
第 10 章 风险管理

第10章 风险管理

10.1 *谁是这起房地产事故的主要责任人

(一)案例:谁是这起房地产事故的主要责任人?

姓 名: mumu
单 位: 山东 XXX 房地产公司
邮 件: lgm2975625@163.com 项目管理者联盟文章,深入探讨。

案例正文:

某市房地产公司,华总是公司老总,于总是公司常务副总。两位总有分工,项目合同和付款
方面由华总负责签字,现场质量由于总负责监管。

项目启动当天,在地质勘察上,出了点小问题,即勘察得不准确,由于两位老总都收了红包,
所以当时谁都没吱声,项目继续,问题被搁置。

然后进入了工程降水阶段,工程降水方案及施工队伍也都是两位老总的关系并且都拿了红
包,还是那样分工:华总负责合同签字,于总负责质量。后来因为降水出了问题,项目周围
的房屋开始不均匀沉降,导致房屋开裂,这时居民都去找具体负责质量的于总,想要讨个说
法。于总认为合同不是他签的,出了问题找不上他,反正都是华总签的字,所以他就一直拖
着。

过了一段时间,居民们一看公司没实施任何针对措施,就采取了过激的行动,将工程大门口
堵住,并且打伤了工程管理人员。

最后的协商的结果是公司负责帮居民把房子修好,还得赔付一定的费用。这样一来,算上赔
偿,工期耽误等等,公司至少损失上千万。

大家讨论一下:谁是这起房地产事故的主要责任人,问题的根源在哪里?

(二)项目管理者联盟专家点评

专家介绍: 侯岚 项目管理者联盟高级顾问,PMP,硕士,高级工程师,中国地质大学特聘
教授,德创赛思工程项目管理有限公司总经理。 本文转自项目管理者联盟

项目管理者联盟文章,深入探讨。

先后在中国、英国和澳大利亚从事机械设计、工艺管理、生产管理和海外营销;回国后先后
担任国际贸易公司总经理和房地产公司总经理,亲历立项论证、融资、项目公司组建、征地、
拆迁、工程勘查、建设规划、工程设计,合同分包招标、工程施工、房地产销售等全过程,

第 658 页 共 756 页
第 10 章 风险管理

具广泛的跨专业项目管理和房地产企业经营管理经验。2002 年开始专业从事项目管理咨询
和培训。

侯岚点评:
从本案例分析,我个人认为,对本项目事故的主要责任人,可以有以下两个层面的认识:
第一:于总作为施工现场负责人,对一个不恰当的承包商,实施了不恰当、不负责任的施工
组织和质量管理,直接导致了事故;而华总是该公司项目老总、于总的上级,同时也是负责
合同、财务支付的分管领导,决定了对承包商和承包条件的选择,从根本上导致了事故;因
此,从管理层面看,事故的主要责任人是华总。 本文转自项目管理者联盟

第二:通过深层次的分析,我们可以发现,指责华总是事故的主要责任人,也依然是头疼医
头,脚疼医脚。导致事故的真正原因,其实是该公司项目决策机制的设计缺陷。
项目决策机制是由项目发起人确定的,通常内容应包括:项目决策过程中的决策人、决策组
织、决策方法、决策程序、决策权限和决策过程监控等。从本案例看,项目负责人的分工,
应该是互相合作、共同参与、彼此制约的,如果大家在各自权限范围内充分负责,做好项目
并不困难。但实际上项目决策机制的设计出了问题,两个利欲熏心的人大权独揽,小权也独
揽,彼此画地为牢,坐地分赃,当然导致项目低效率或者无效率。所以,从企业运营和法人
治理的层面分析,事故的主要责任人是项目发起人。 本文转自项目管理者联盟

(三)项目管理者联盟网友评论

分析 1:题目 各方都应承担一定责任 作者 陈中民

对于房地产项目,地质勘察出问题,后果是很严重的。从案例看来,于总负责项目的质量,
华总负责项目的整体验收。因此,于总负主要责任,华总负连带责任。作为合同的甲方,有
权要求施工单位保证项目的质量,出现质量问题,也要承担监管不力的责任。

分析 2 :题目 各领各的责任 作者 龙七

一个事故肯定涉及很多方面,同时也会涉及各方面的很多人员。那么出现问题,就要依据权
利和责任统一的原则,对有权利决定重要事件的人,依据他的权利追究他的责任。不管你是
否签字或者直接负责,至少应该有监督不力,或者收到利益不说话,遂大流的错误。这样才
能避免以后再次发生这样的事情! 项目管理者联盟文章,深入探讨。

分析 3 :题目 责任主要由房地产公司承担 作者 冯波

因为该项目由房地产公司承担,在实施过程中其公司将部分工作进行分化,根据专业的性质
不同,存在多个队伍在项目实施过程中承担不同的任务,而针对整个项目而言,房地产公司
是唯一的项目法人,出现了该情况,房地产公司于总应承担主要责任。 http://blog.mypm.net

分析 4 :题目 责任由几家单位共同承担 作者 whf

第 659 页 共 756 页
第 10 章 风险管理

作为甲方的老总有权要求施工单位在保证质量的前提下施工,作为施工单位在没有考虑到降
水对周围建筑物的影响要承担责任。而作为甲方没有尽到监管义务,也应承担相应责任。

分析 5 :题目 谁该为这件事故负责 作者 胡月

公司的损失首先是一个集体行为,说明公司的体制存在严重问题,内部监控不到位,导致仅
仅两个人接受贿赂就导致公司蒙受如此大的损失,公司的董事会应该重视此事,严格内部监
控制度,不让公司利益受损。同时这两个人已经犯了商业贿赂的受贿罪,并导致了严重后果,
所以要承担相应的法律责任,而不仅仅是行政处分。

分析 6 :题目 责任与制度 作者 尊者
华总负主要责任。
两人的角色类似于项目经理与 QA 的关系,一个项目在运行的时候,没有关注到过程的质量
问题,当出现问题时,却找不到过程中问题的所在,只好返工。于总负没有履行、不作为的
责任,华总选择了一个错误的实施方向。一个失败的项目经理和一个不负责任的 QA。没有
更高的部门或组织对他们的行为进行监督。董事会也负有责任。

分析 7 :题目 公司内部该如何追究负责 作者 潘李伟 项目管理者联盟文章,深入探讨。

我认为这个案例似乎在问公司内部的责任应该如何承担,华总作为公司老总,自然负主要责
任,于总作为质量负责人,没有控制好质量,同时出现问题不解决,应该担负一线责任,同
时公司应该由于此人的不作为而解聘此人。

分析 8 :题目 责任不一 作者 冯琳

对于公司内部来说,因为于总负责的是具体事务,因此应该负主要责任,华总负领导责任。
而对于外部来说,住户针对的是整个公司,承担责任的是整个公司,具体由公司法人处理。

分析 9 :题目 都要负责 作者 daijiangbao

于总没有将出现的风险及时告诉华总,所以要负责任。华总没有选好人员,是项目的出资人,
要付最终责任。也就是说,于总付主要责任,华总付最终责任。

10.2 *项目管理不力,技术负责人如何开展工作

案例提供者:项目管理者联盟会员 唐满(tangman007@163.com)

★ 案例正文:

我公司的第一个工程项目是一个高速公路的路基项目,路线长度 10.3km,工程造价 1 个
亿,合同工期 14 个月。项目从 2006 年 10 月开始进场,2007 年 4 月正式动工,截止到 2007 年
8 月底,工期已近 5 个月,完成的工程产值却不到 10%。

第 660 页 共 756 页
第 10 章 风险管理

工程进度上不去,主观上项目管理不到位,领导班子管理水平不高,项目人员积极性不强,
项目管理理念不成熟,造成了人浮于事,工作效率低下的现象;客观上征地拆迁影响很大,
工作面一直打不开,严重影响施工组织安排。

我做为项目部的技术负责人,项目部领导班子成员,对这种情况是看在眼里急在心里,曾
多次向项目经理及公司领导反映这里的情况,并提交了建议方案。

公司是一个民营企业,由于我是从 2007 年 6 月才进入这个公司,而项目经理却和老板有


五六年的合作基础,项目也是一直沿着这个管理模式往下走,因此我的建议基本上没起到作
用。

请教各位,像这样的项目,像我这个位置,该如何开展工作?
项目管理者联盟文章,深入探讨。

★ 项目管理者联盟专家点评:

专家介绍:王文周 项目管理者联盟高级顾问 北京师范大学经济学学士,中科院研


究生院科学哲学专业硕士,中科院项目管理在读博士,师从我国著名管理工程领域专家,中
国统筹法优选法与经济数学学会理事长徐伟宣教授。国际项目管理协会(IPMA)认证的项目
经理、认证的 IPMP 培训师,IPMP-B 级培训讲师与报告辅导教师。北京基业长青管理咨询公
司培训师、咨询师。多年来一直在项目管理的教学与咨询一线从事项目管理的实践。

专家点评:

各位联盟朋友的分析都各有特色,角度新颖,分析透彻,看后很受启发。我不是工程管
理出身,这方面做点评有续貂之嫌,不妥之处,请大家多包涵,欢迎批评指正。

首先,我们从案例提供的信息可以分析出如下背景信息

1、公司第一个工程项目,也是一个处在困境中的项目;

2、作者是项目动工后两个月进入该项目,是项目技术负责人;

3、作者理解工程进度严重滞后的原因是项目管理不到位,同时客观上拆迁征地复杂;

第 661 页 共 756 页
第 10 章 风险管理

4、公司是民营企业,关系有些复杂,作者的建议未被采纳。
本文转自项目管理者联盟

对于工程项目管理问题,我想我们可以遵循如下分析思路进行分析:

1、首先,我们说工程项目都有两大过程,一个过程是从项目立项、设计、采购、施工、
验收的工程活动过程;另一个同步的过程是项目管理过程,从项目启动阶段、计划、控制、
实施到收尾。这两个过程是统一的。我们分析项目出现的问题,可以对照这两大过程,从工
程活动中找原因,从项目管理中找原因。有些工程项目是复杂的,造成工程进度滞后的原因
有很多,当我们以这样两个维度看问题时,有些情况就清楚多了。 本文转自项目管理者联盟

2、当然,我们分析问题时,还需要增加一个分析维度,那就是跳出项目本身,而是从
组织、系统的角度来看这个问题;我们的组织、系统是否建立了相对成熟的项目支持系统呢,
包括资源、流程、规则、组织等。有了这个维度的分析,许多现实情况背后原因就清楚了,
如项目执行好坏取决于项目经理的能力,而不是项目团队的能力,更不是企业的能力等。我
们说国际一流的工程公司能够做到铁打的营盘、流水的兵就是因为他们有一套完备实用的项
目管理体系。

3、国际有研究表明,在决定项目管理成功的要素中,我们从技术角度看待的工具、方
法(hard skill)只占项目成功的 40%多,而沟通、协调、冲突管理、队伍建设、项目文化建
设等行为能力(soft skill),占 50%多。造成项目处在困境的原因多种多样,基于现象进行原
因分析很重要,面对现实,着手解决矛盾,力图摆脱困境更有现实意义。这样的项目是立即
中止,进行止损;还是继续增加投入,取得业主理解,力求打平。作为技术型专业人士可以
给出更有参考价值的意见。当然,这赖于领导的决策。结合上述背景信息和我们的分析依据,
我们可以有如下参考建议: 项目管理者联盟,项目管理问题。

项目管理者联盟,项目管理问题。

1、正如作者在后文所表现出的一个成熟的心态,这点很重要。进入一个项目管理体系
相对完备的组织固然很好,但通过我们的努力,逐渐提升项目管理的成熟度,价值也很大。
特别是公司第一个工程项目,出现些问题是正常的,重要的是总结经验教训,特别是最佳实
践的梳理。

2、在系统分析项目问题时,要特别重视项目前期的分析,项目管理重在头尾,项目前
期工作做的透彻,项目执行也顺畅。如果项目前期就埋下了很大隐患,过程中问题虽作了解
决和弥补,但效果终要打折扣。

3、从技术负责向管理的转型,要重视项目管理中 soft-skill 部分,重视上下的沟通和协


调。特别和项目经理的沟通和协调,这点是技术背景型的管理人员要注意的。
项目管理者联盟文章,深入探讨。

4、企业都是利润为导向的,这点在民企表现的更充分,相信有才干的人也更会脱颖而
出。
http://blog.mypm.net

5、建议从公司层面加强系统项目管理的学习和培训,形成对项目共同的理解和工作语

第 662 页 共 756 页
第 10 章 风险管理

言,乃至项目文化,当然公司领导层的充分参与无疑对项目文化的形成是最重要的。

★ 项目管理者联盟网友评论:

分析 1:关键是沟通,了解背景才有发言权 许肃 ( xfrank@gmail.com) 项目管理者联盟文章,深入探讨。

首先,关键是要和当事人——项目经理正面沟通,征求他的意见。在没有了解当事人的
意见之前,自己的看法有时是片面的。许多当时人(主管人员)都有许多不为人知的难处(有
些也许还是老板的原因)
,多听多了解背景,才有发言权。

其次,在了解背景以后,再根据情况而定。如果对方真心希望获得帮助,你就可以发表
一些自己的见解,最好要有针对性和可行性,但一定不要用批评的口吻。
项目管理者联盟,项目管理问题。

最后,要成为核心队员。这样对重要事件就有参与权,话语权,乃至决定权。
分析 2:管理自我,挑战项目 pulison (pulison@sina.com)

很高兴,能听到这样的项目技术负责人对自身项目的发展有这么负责的态度,项目的成
功与否离不开一个项目的群体,当然也需要项目经理的管理决策能力。

项目管理不到位的原因不知道有没有考虑过?可能有如下原因:

第一:沿用以前的管理经验(经验过时),对新项目没有新的认识;

第二:项目经理不敢创新,怕会失败,怕导致责任难以承担,所以任由事态按原来的管
理模式发展;

第三:项目经理自身没有能力去变,他根本不知道如何去管理高速公路路基项目,不是
他不变,是他不知道怎么变。
项目管理者联盟文章,深入探讨。

以上原因可能都有之,所以沿用以前的管理模式,对于项目技术负责人,我想你首先要
立足本职工作,将自身的技术管理工作做好。但作为项目组成员,对项目的成败也有相应的
责任,从自身的职业发展角度来看也不能使项目失败。
http://blog.mypm.net

你可采取如下措施:

第一:你应多和项目经理进行沟通,了解项目的真实情况,如原来的工期确定有误,他
们知道但没告诉你等。

第二:你对项目应进行深入了解,对周围社会环境和项目组成员的状态(如工资收入、
奖励措施、技术水平等)进行了解,征地拆迁工作往往不是一个公司说了算,涉及到政府管
理、资金到位、被征地对象的合作程度,这就要客观分析,采取有针对性的措施。

第 663 页 共 756 页
第 10 章 风险管理

第三:内部管理,效率低下的原因你是否分析过?是项目经理的管理能力问题,还是老
板的管理态度问题?这涉及到用工制度的革新问题,技术人员的个人发展问题,还有就是工
人的工资收入水平认可度等等。你可以去深入了解该公司的组织结构、奖惩情况,是否能如
你所提的建议方案去解决,是需要短期还是长期的解决,这涉及到一个公司的管理制度。

第四:你自身的发展问题,对于项目的发展受公司的管理制度的制约,你是否有能力来
管理好该项目,提的建议是否经过深思熟虑能够确保成功的?你如果有兴趣做项目管理的
头,那你就以你自身的项目为例,进行书面的项目管理计划,提交你们的老板,和他们深入
探讨,如果认可你的观点,你可以协助项目经理共同管理该项目,相信私人老板不会反对。

分析 3:找好平衡点 anbh (abh1221@126。com)

1、对这种项目,根本就不存在所谓的项目管理理念,老板和项目经理的思想是如何在
减少投入,多赚钱的情况下去完成工程。他们不会有正规的项目风险、项目费用的技术上的
分析,所以以正常的项目管理的理念去理解他们是不能够的。(不知对老板和项目经理的分
析对不对?)我认为,首先要分析他们到底想要做什么,尤其要明白老板对项目的目标是什
么?这样才能对症下药。

2、进入公司一年应该说已经不短了。应该对最具体的问题去分析解决,而不能只是笼
统的给出问题和建议,这是领导能不能接受的关键。 项目管理者联盟文章,深入探讨。

3、如果应该做的都做了,项目还是如此,或者不能适应公司的目标和理念,只能
提前找下家了。

分析 4:方法总比问题多! zgl (zgl76814@yahoo。com。cn)


http://blog.mypm.net

1、我认为我们首先要清楚的认识到:是要公司来适应你还是你去适应公司!我想大家
的回答是肯定的,是要我们去适应公司。每个公司都有他自己特色的管理体制和流程,你不
管他是好的还是坏的,如果你要在该公司发展,你就要去适应它;

2、要进行自身的角色定位,正所谓一个萝卜一个坑,每个公司或者项目部都设有相应
的岗位,并明确该岗位的工作内容、流程等,我想大家都应该明白这一点,为的就是分工明
确,避免打乱战;在其位,谋其职,忠其事!每个人所站的角度不同,处理事情会有千变万
化!
本文转自项目管理者联盟

3、我想你上面提到的都是一些比较笼统的问题,每个项目或多或少都会碰到一些,问
题是你能否对症下药,提出针对性的问题,并针对性的提出解决问题的方法,你是该项目的
技术人,是项目管理的核心成员,如果你提出的问题确实能够解决该项目的问题,使之加快
进度,降低成本,我想,没有一个公司会不听,因为赚的钱公司是大头,你说有那个公司不
愿意多赚钱吗?

4、造成人浮于事的原因我认为也是多方面的,你作为项目的技术负责人,从上面来看,
有没做到表率作用,我前段时间看的一本书叫《输赢》,里面有一点我是非常认同的,讲的

第 664 页 共 756 页
第 10 章 风险管理

就是我们把过多的精力都放在了内耗上;

5、如果你做了你应该做的事情,公司还是无动于衷,我想你就马上可以辞职了,道不
同不相为谋!

分析 5:建议不成就走人 杜征均 (dajundalao@126。com)

就目前来说,这样的项目在国内相当普遍。老板取得项目是靠拉关系来的,用人也是任
人为亲,重要的位置及有实权的位置都是亲戚或心腹在把守,如你那样的位置只是有相应的
经济待遇,事要由你办,但你说了不算没有决策权,造成如你一样的业务骨干员工在那里面
基本上没有忠诚感。老板习惯撑不下去就换个人来缓解一下所在项目的矛盾,从来不会从根
上也就是他自己本身去解决问题,管理毫无有效性可言(主要靠个人责任心、与管事人之间
的面子及关系)。他们以为换一个有能力的你应能起死回生,但不会去碰实质性的问题,即
使是明摆着的问题。他们宁愿花许多冤枉钱去疏通关系,让业主认可他的滥工程,也不会花
大力气去提高自己的能力和水平,他们有一种定向思维就是工程和生存凭的是关系而不是能
力,这也是这种企业最终会穷途末路的原因。

基于你所在企业的状况,建议你先书面向老板和项目经理建议,建议不成就走人。建议
的动因是对老板和项目经理抱一线希望,希望他们能够重视问题、解决问题,确保项目成功;
建议不成就走人说的是结果:如果他们根本就不听建议,那么你对这个公司就只剩下绝望了
——在一个没有管理效力的单位里,项目成功率较低得只能让你绝望。

对这个项目要开处方的话,首先是换项目经理,他的管理不力、安排不周导致了如今的
结果;其次是加强业务流程的管理以改变效率低下的现状;第三是加大经济激励措施以确保
提高积极性和效率;四是业余加强培训以提高管理观念;五是加强班子管理理念和管理水平
的培训学习;六是加强工作的计划性。 项目管理者联盟文章,深入探讨。

分析 6:辞职吧 作 者:史鹏飞 (aad-113@163。com)

没啥好说的,无力回天。当然在一个公司里,就得以公司的形象和信誉为重,不过自己
的形象和信誉一样重要。 http://bbs.mypm.net

主观客观条件下,我个人觉得我是做不到的,我也不想让自己在复杂化的情况下受拖累,
对公司、对自己都是个交待。希望公司能够请到合适的人。况且,你并非项目经理,也没有
自主权,技术负责人对于公司来说,恐怕就是一个高级工人。

再一点,项目是否如期完工,和公司战略发展有着相关的利益联系。如果拖是好事的话,
为什么和尚不急道士急呢,难得糊涂嘛。如果你真想在专业技术领域内做出成绩,还是换个
地方吧。
分析 7:战胜自己,提高自己 作 者:唐满 (tangman007@163。com)

我很赞同史兄的观点,也曾想过跳槽。但是仔细想想:又有哪个项目能够一帆风顺?又

第 665 页 共 756 页
第 10 章 风险管理

有哪个项目在实施过程中没有困难? http://bbs.mypm.net

如果能够将这些困难一一克服那么对自身也是一个很好的锻炼。

10.3 *如何有效规避工程项目投标风险?

案例提供者:项目管理者联盟会员 zhangxu

★ 案例正文:

管理项目难,承接项目更难。一个工程项目,往往参与竟标的单位却很多,少则 3 家,
多则几十家,就我所看到的最多有 150 多家。这样即使通过层层筛选,最终也还要剩下 3-8
家。于是最终的这几家都回去做方案、做标书、做预算,一做就是几天、十几天。

参与一个项目的投标,从购买招标文件到编制预算、施工组织设计、制作标书和装订,
在时间上少则十几天,多则几个月,经济上的花费更是从数千元到数万元不等,而一旦投标
失败,就意味着全部的投入都打了水漂。

这样的风险处处存在,几乎每家参与投标的企业都经历过。因此,工程项目投标风险是
一个普遍的问题。这不同于已接项目怎么做好的问题。虽然这里面涉及了关系、权钱交易、
投入等众多问题,但用最少的投入去获得最佳的效果,仍然是我们追求的目标。

欢迎大家就如何规避工程项目投标风险问题发表自己的看法。
项目管理者联盟文章,深入探讨。

点评本案例>>
http://bbs.mypm.net

★ 项目管理者联盟专家点评:

专家介绍:沈健 项目管理者联盟高级顾问 工程项目管理专家,美国管理技术大学项目管


理硕士,教授级高级工程师,高级经济师,国家首批高级项目管理师,国家一级项目经理,
国家一级注册建造师(建筑装修/机电),国家注册咨询师。国家级评标专家,国家级施工组
织设计编委。

沈老师曾在多家建设、设计与装饰单位担任高层职位,目前是北京兴健工程项目管理有
限公司董事长兼总经理,在工程、地产领域有着 25 年的项目管理经验和企业管理经验。

第 666 页 共 756 页
第 10 章 风险管理

专家点评:

投标风险分析:

◆关系
本文转自项目管理者联盟

目前的中国的市场经济还处在一个发展的初级阶段,我个人认为市场经济包括两大因
素,一是关系经济,另一是信用经济。“关系经济”和“信用经济”又存在着互补的关系。没有
信用也建立不起关系。没有任何关系的投标往往会打水漂,成为别人的陪标对象。
http://blog.mypm.net

政府也在努力的改变这一不公平的现象,比如采取交易中心抽取社会评标专家等。但也
只能治标不治本,由于存在各个环节存在的一些漏洞,还是不能有效的规避关系这个风险。
本文转自项目管理者联盟

◆报价的合理性

报价是投标风险的一个重要部分,报价过高或过低都不能被业主接受。只有既满足业主
要求,同时又能最大化的满足招标文件的评分办法。这样的经济报价才能获得授标的可能性。
ν
◆采用投标报价方法规避投标价格风险

当前很多地方都在推行工程量清单报价模式。在此模式下,对于固定单价合同方式,在
仔细核对工程数量和项目,对于数量增加(或甲供清单量比图纸量小)的项目报偏高价格,
对于数量会减少(或甲供清单量比图纸量大)的项目报偏低价格。不平衡点不超过常规报格
的百分之十。对于大型项目,早期能收钱的项目可报偏高价格。通过类似此等手段,总体价
格水平比正常报价略低百分三至五的中标机会相对会高一些。但总的结算水平会达到正常的
报价水平。
ν
◆技术方案的可行性

任何通用的技术方案不会在评标时获得高分,只有针对性较强的技术方案才能获得高
分。 项目管理者联盟文章,深入探讨。

提醒注意的是,技术方案针对性在强,也千万不能忽视了技术方案编制要求的规定(比如文
字大小、页边距、页眉页脚等等)。应为不符合编制要求将导致整个投标为废标,那所有的

第 667 页 共 756 页
第 10 章 风险管理

努力将付之东流。
◆企业是否具备实施能力 http://bbs.mypm.net

投标前往往会有资格预审的环节,作为投标企业不仅要衡量自身能否胜任项目要求,同
时还要在资格文件中体现出企业比其他竞标人更能胜任项目的内容。

在资格方面需要投标企业不能光做一时的功夫,需要每个企业常年的积累才能树立的良
好形象。

◆业主的信誉

投标时需要考虑业主的信誉的程度。业主信誉差那投标等于是往火坑里跳,除非你有钱
愿意花经历时间与业主去扯皮。
ν
◆付款办法

付款办法中规定了付款的比例、时间及付款的形式,需要投标人仔细衡量垫资的可能性
以及出现垫资情况的额度及时间。在与企业流动资金运作进行权衡后决定是否进行投标。
ν 本文转自项目管理者联盟

◆签署盖章等细节是否完整
项目管理者联盟文章,深入探讨。

在投标文件完成制作后,要仔细检查密封盖章签字的要求。仅仅因为漏签等原因造成废
标就太不值当了。
◆提高中标机会,降低投标风险

项目投标前首先要对项目建设单位进行考察,项目建设单位是否在项目资金实力,如建
设单位根本没有实力去建设这个项目,这样的标就没有必要去投。

对于参与投标的项目,必须组织一个健全的投标班组。通过对招标文件的要求,评标方
式,做出最大限度符合招标文件要求的技术标、商务标和资格标。并严格检查投标文件是否
会被废标的情况。通过对项目投标阶段的严格管理会减少投标的风险。

在北京很多通过标办招标的项目还是比较的公平公正的。我也参加过很多大型的工程评
标。只要你的企业有实力,投标文件做得好,还是有机会能中标的。

★ 项目管理者联盟网友评论:

分析 1:就项目的性质而定 dajundalao 项目管理者联盟文章,深入探讨。

这个问题太大,需要据项目的性质而定。如果除去文中所说的那些因素,可从以下来分
析--如果你是 PMP,那么我就在此献丑了: http://bbs.mypm.net

第 668 页 共 756 页
第 10 章 风险管理

1、如果是 PMC,即让你投管理标,业主除了出钱,所有风险全部都转嫁到你单位。那
么从规则上是允许你单位加入风险因素来考虑的,在我国国内这种模式刚刚起步,绝大多数
企业还不具备这个实力。这种模式利润丰厚,但也是把双刃剑。

2、如果是业主让你参与共管,即 PMT 或 IPMT,风险存在是业主与你单位共同承担(实


际上是业主承担),你单位风险较小,你单位只有把工程项目分解,进行 EPC 或设计、PC,
或业主自己采购然后进行 DB 分包等,此时把风险传递下去,你单位所承担的风险理所当然
就小了。

3、如果你单位不具备上述实力,而最多能参与到 PC 一级的承包,那么 PC 一级的风险


主要是不可预见风险,以及采购材料设备价格风险、材料质量风险和施工工期风险。由于一
般你单位所参与的项目为你们所熟练的项目,因而可排除施工成本风险和施工质量风险,因
为业主或管理目的在于要你单位优化组织,完成施工项目。但这又面临业主的严格要求、同
行的公平竞争和地方小队伍不具备实力的恶性竞争等。国内中海油 PC 承包方式运用得比较
好(保持了施工方的微利),给中海油省了不少钱,但不规范的竞争让施工方吃尽了苦头,
也增长了见识。

4、如果你单位只具备施工项目的能力,那么这个层次竞争对手太多,既有来自高端的,
又有来自同一层次的,还有地方小队伍不具备实力的恶性竞争。此时你单位面临的是与其他
一类的或不入流的队伍一样,把求生存放在第一位,只能是去避免大风险消化小风险了,同
时利用国内预结算的空子求得利润空间,或进行再分包、或选择从纸上具备实力而实际上根
本不具备实力的小队伍来施工,但此时你单位风险隐患较大,需要加强管理。一如中石油独
山子石化恶性压价,迫使施工方再分包或选择不大具备实力的地方队伍而寻求风险转嫁和利
润空间,终成 2006 年的人间惨剧(数十人死于大罐中)。

5、如果你单位是民营或是集体的小队伍,则最好选择几个固定的大队伍,紧跟他们发
展关系,形成有良好信誉的固定分包伙伴,则肯定有人家的肉吃就有你单位的汤喝,风险也
小得多。若属于吃了上顿没有下顿的,则就另论风险了,因为能不能生存已经是你单位最大
的风险了。
也不知以上的回答你满意否,若不满意,请来信交流。

分析2:风险与收益并存 登高望远 本文转自项目管理者联盟

投标单位必须对招标项目有充分的了解,当然不计成本的拿项目除外。个人认为投标风
险有几种: 项目管理者联盟文章,深入探讨。

1.对项目进展不了解,包括项目的前期手续办理进度、场地条件等;
2.对招标文件中的技术、质量要求不明确;
3.合同条件中的承包方责任理解不准确;
4.潜在的不确定因素。

分析3:行业门槛,如此而已 陈万春

第 669 页 共 756 页
第 10 章 风险管理

这是一个最基本的行业门槛问题,是业内参与者的必备预算之一! 没有一个公司投标能
100%成功中标;承担不起这种风险的参与者,只能接受淘汰命运。这是最基本的逻辑!

分析4: Bidding Risk of oversea projecr kevin

笔者参与了多个海外项目的投标, 在这种大型的国际项目招标中的确存在着大量的风
险因素,业主在招标过程中有时有意提高承包商的投标风险,例如加大投标保函风险等,其
目的主要如下: http://blog.mypm.net

1、 通过提高投标风险的门槛, 将一些实力较差的承包商拒之门外;
2、 在已经选定潜在承包商的情况下, 通过引入更多的竞标商 , 加大与真正潜在承包
商谈判的筹码;

分析5:充分为客户考虑,从投标开始 李允鲁

其实我觉得这个投标的问题不是“招标项目更适合小公司”这样看的。前段时间刚刚负责
过一个小项目的招标。虽然说是一个小公司中标了,但是我也看到了所谓的大公司的问题:

大公司投标往往从自身的角度看问题,选材,技术施工也往往是把自己最好的一面给彰
显出来,这个过程中就把客户的需求给忽略了。而且在报价的问题上也没有足够的重视,存
在着重复报价的问题。结果一个客户需要一个 30 万左右的运动场在大公司的报价文件里成
了一个 60 万左右的项目,这是无论如何也不能中标的。这在项目管理中也是一个平衡各种
目标的原则。 http://blog.mypm.net

关系固然重要,但是根据客户的需求,制定适合客户需要的方案,能够站在客户的角度
来思考项目是很重要的。这也可以为以后的项目实施做好准备。

分析6:投标风险无处不在! 朱兵 本文转自项目管理者联盟

既然是投标,投标企业就应该重视。如果想拿下项目,那必然是花了心血的。当然了成
本当然是存在的,但是不能叫投标风险,投标只是企业为继续发展所必须进行的,没有新的
项目怎么发展企业。我不赞同发贴人的风险的观点。

分析7:招投标项目没有那么大的学究味 daijiangbao

对于招投标项目,大家认为是公平的,这实际上是不对的,这个世界上根本不存在公平,
有公平的世界是理想的,在理想中幻想现实是不正确的。
就招投标项目来说,客户在控制,投标商也在控制,客户绝对不会在没有一个有偏向性
的投标商之前去贸然招标。

从这个意义上来说,投标商越是能在招标之前控制住客户,越是能最终中标成功,绝对
的说把标书写好就能中标,那是书本上的说法,实际上几乎没有。招标公告一发出,其背后

第 670 页 共 756 页
第 10 章 风险管理

隐含的意义基本上是:我已经把中标商选定了,欢迎大家来凑热闹。当然也不排除可能发生
出乎客户意料之外、不能控制的事情。

在招标之前,基本上客户已经被某一个投标商搞定了,别人一般很难再插手进入,招标
只是一个形式,不是提供公平竞争机会的时机,在这种情况下的招标,客户会暗中帮助她的
意中人,这样就会对其它人员造成一些壁垒。

就如同现在年轻人一样,在对外正式宣布谈恋爱时,其实早就暗送秋波、暗中来往,对
外宣称谈恋爱,不过是些遮人耳目的幌子,绝对不是对外宣称公平竞争机会的到来,这时其
它投标商要横刀立马,夺人之爱,是要费很大功夫的,当然也不排除能夺下来,但是项目招
投标,绝对不是理论上的公平,这个世界如果公平就没有意义了。

分析8:打有准备的仗 毛知新

这种现象现在在哪个行业都开始出现,在工程项目中尤为明显. http://blog.mypm.net

1、首先应对招标的项目有充分的了解,特别对与项目招标相关人员有详细的了解。
2、对自己的势力有准确的定位,不要什么项目都去参与,有针对性地去参与招标。
3、现在的招标主要在人际关系,当然产品也要过得去。
总之,在参与招标过程中应做到知己知彼,才能百战百胜。
本文转自项目管理者联盟

分析9:关于工程项目的投标风险问题 沈莉

为了取得招标的成功,前期的调查是非常重要的,应该在平时就有一些针对客户的开发
措施,了解一般客户的编号和对项目的要求;在标书制作上应该就有一些不同的模块的范本,
这样可以节约大量的标书制作时间,节省的时间可以很大限度的用来开发针对客户特性的独
特一面的制作,这样赢取得比例会不会更大一些?

分析 10:投标风险很简单 showrouter

其实很简单。以 it 类集成项目为例,投标之前,衡量一下自己有可能中标吗?衡量的条
件:
1、关系到位吗?
2、自身的条件做得出来吗?
3、垫资垫得出吗?
4、客户的信用度怎么样?签完合同付得出钱吗?
其中最重要是第一点,如果第一点没戏的话,其他点统统不用考虑,直接放弃该项目。
http://bbs.mypm.net

本文转自项目管理者联盟 分析 11:项目投标 mark

项目投标其实涉及到很多不为外人所知的秘密因素,这点我相信搞经营的人都清楚,把
投标作为一个项目来管理,关键还是项目操作,至于做方案、做标书,这点每个公司其实都
有一些很完善的项目技术方案和标书版本,对项目技术层次的理解和分析应该相差不远,关

第 671 页 共 756 页
第 10 章 风险管理

键是报价,很多时候项目决定因素就是报价,根据项目招标文件进行报价是否合理,以及是
否能在众多投标单位当中成功中标,每个公司可能都有自己的一套办法。
http://blog.mypm.net

分析 12:投标风险 林先生

这样问题的产生一是由于业主为了选择更好的性价比的供应商,降低建设成本的需要,
也是市场竞争的必然。就我的经验而言,大多数业主不会选择价格最低的供应商,当然更不
会选择价格最高的施工方,而是选择合适的承包商。具体怎样能竞到标,的确需要多动脑筋
去迎合业主的需求,这才是投标的关键。作为一个成功的投标者,首先要有好的业绩与口碑
是必需的,特别对一些重大的有影响的工程。
本文转自项目管理者联盟

分析 13:简单来说 daijiangbao

把招投标过程当作一个项目来看,不是仅仅把标书写的好就可以中标,而是在招投标之
前就有许多的工作要做,主要是让客户对方案和公司认可并获得支持,客户也不希望出现意
外,不希望出现突然不熟悉的面孔来给他们做服务,所以这个阶段的工作还是在于前期的规
划,这个过程少不了关系、权钱交易等,这些权力和政治斗争不要从负面的眼光来看,但是
不要沉湎于其中的政治和权力斗争,项目管理从来就没有回避这些问题,从项目管理环境那
些章节就非常清楚,不要有天下舍我其谁,怀才不遇的感觉和理念,所以要真正理解项目管
理,就一定要把项目管理环境正确、积极的理解清楚,不要只是看后面的九大知识体系,认
为九大知识体系才是项目管理,那就彻底错了,项目管理环境章节、内容不多,但是不把这
些基础打好,后面的什么过程、体系都是没有基础的,实际项目管理的应用和 pmp 纸面考
试是有差距的。

另外,项目接下来,只想着把项目做好就可以,认为没有什么风险了,那就大错了,一
般是这时的风险都没有处理好,等到项目后期风险积累的能量爆发,就会把项目搞的一塌糊
涂,把项目搞好和让客户接受项目这是两码事,千万不要认为项目做好了客户就要接受,这
之间不是必然的联系。

好的项目经理就是从项目的概念开始就一直管理着项目,一直掌控着项目的大局,而不
是项目中标以后,认为埋头干活才是项目,这样培养不出合格的项目经理,也就是干活的小
监工而已。

10.4 派克电信公司项目风险管理案例分析

派克电信公司项目风险管理案例分析

[姓 名] 项目管理者联盟 [单 位] 项目管理者联盟 [邮 件] member@mypm.net


[所属行业] IT 软件 [所属主题] 项目风险管理 [发布时间] 2008-5-20

第 672 页 共 756 页
第 10 章 风险管理

【案例正文】
背景:电信工业的迅速成长使派克的高级管理层明白,在所有开发项目中必须进行
风险管理。如果派克在将一个新产品推向市场的过程中迟了一步,那么它将损失很
多市场份额。此外,如果派克被认为在新产品开发方面落在学习曲线的后面,那么
它将可能失去与其他公司合伙的有价值的机会。

派克面对的另一个问题是大量的金钱正在投入到研发部门。普通公司要在研发方面
投入利润的 8%~10%,而在电信工业,这个数字可能高达 15%~18%。但是,派克
目前在研发上要投入 20%,并且只有很少一部分项目能从概念阶段到达商业化阶段,
而只有在商业化阶段,派克才可能期望使其耗费的成本得到补偿。管理层将之所以
出现以上问题归结为缺乏有效的风险管理。

会议

项目经理:我花费了大量的时间努力比较风险管理方面的最佳惯例。我吃惊地发现,
许多公司跟我们一样,几乎没有风险管理方面的知识。从其他公司所发现的有限的
结果中,我已经能够开发一个为我们所用的风险管理模板了。

发起人:我已经读了你的报告并看了你的模板。你在模板中有一些文字和措词,我
们不会将其用在派克上。难道我们必须改变项目管理的方式来使用这些模板吗?你
希望我们对现有的项目管理方法进行重大改变吗?

项目经理:我一直希望,我们能以模板现有的形式来使用这些模板。如果其他公司
正在使用这些模板,那么我们也应该这样做。这些模板与其他公司使用的模板具有
相同的概率分布。我认为这些事实证实了模板的有效性。

发起人:难道不能按照我们的项目管理方法和我们生命周期阶段定做这些模板吗?
这些模板可能已经经过了检验,但不是被派克检验过。概率分布也是基于其他什么
人的历史,而不是我们的历史。在你的报告中,我没有看到关于概率的验证。我的
最后一个问题是,模板是以历史为基础的。我所理解的是风险管理应朝前看,是努
力预计将来可能会发生什么事件。我没有在你的模板中看到这些。

项目经理:我明白你的担心,但是我不认为它们是个问题。我可能更愿意使用下一
个项目作为使用这些模板的“突破”。它将为我们验证模板打下一个好的基础。

发起人:我需要考虑你的要求。在没有对我们的职员进行风险管理培训的情况下,
我不能确定我们能够使用这些模板。

问题:

第 673 页 共 756 页
第 10 章 风险管理

1、模板可以从一个公司转移到另一个公司使用吗?或者,模板是应该定做,还是照
抄?
2、一个公司的概率分布可以适用于另一个公司吗?如果不能,那么我们如何建立概
率分布呢?
3、你怎样验证一种风险管理模板?
4、风险管理模板应该朝前看吗?
5、没有一些形式的专门培训,职员能够开始使用风险管理模板吗?

【相关分析】

·风险管理(2008-06-02) [作 者] 周波 [公 司] 深圳市天维尔通讯技术有限公司

完全美国式的问题。
1、 每一个项目都是独特的,包括组织过程资产。每个公司都应该去寻找合适自己的项目管理模式,
我想这是我们这些项目管理人员的责任之一。
如果模板可以照抄,那当年红军就用不着长征了。
2、 这里的概率公布,应该主要是指在可行性分析阶段,对项目时间的估算,成功的概率,包括投资
回报等方面进行的一个计算。从案例中背景可知,时间是派克公司成功的关键,因此 PERT 法可以在
这里尝试使用。
3、 任何一种模板,都是根据历史的数据而制定的,也只有适合自身发展,才是有用的。实践是检验
真理的唯一标准。
4、 不谋万世者,不足谋一时。风险管理是面向未来的不确定事件而制定的管理方案,更何况是在电
信工业这种日新月异的行业,不面向未来,只能是死路一条。
5、 任何一种新技术,都应该先培训。不进行培训,员工都不理解你要做的目的,又怎么朝你的目标
努力呢?

10.5 项目经理应该负什么责任?

项目经理应该负什么责任?

[姓 名] 姬中柱 [单 位] 不公开 [邮 件] qianshaoh@china.com


[所属行业] IT 软件 [所属主题] 项目风险管理 [发布时间] 2008-1-15

【案例正文】
一个政府便民系统项目,项目得到政府领导的明确指示,由于合同约定的时间很短,

第 674 页 共 756 页
第 10 章 风险管理

项目组成员除项目经理外只有两名程序员,所以该项目没有进行系统的设计,只是
把原有的程序改了一下,也没有进行系统的测试(项目组不包括测试人员)
。项目进
行中有些小的变更,在合同范围内都顺利的通过了验收。尾款对方虽然拖了一下,
但最后还是付了。

在这个项目中,项目经理负责售后所有的事务,包括文档编写,需求调研,任务分
配,功能验收、客户培训,收款等。在收款工作完成半年后,系统却出现了重大的
Bug。

请问:在这个项目中,项目经理有过错吗?他应该负什么责任?

【相关分析】

·项目经理负主要责任(2008-08-13) [作 者] 四季风 [公 司] 兴库建设投资有限公司

首先政府领导人不懂但是项目经理应该懂。如果是自己懂但确没有去考虑或考虑后没有找到一个好方
法来解决,项目经理应当为自己的过失买单。
其次对系统却出现了重大的 Bug,承包人的项目经理应当对自己承担的项目负主要责任,这是企业必
须承担的社会责任。

·态度、信誉(2008-04-10) [作 者] 种云峰 [公 司] 深圳矽感科技

1、没有做系统分析,只是对原有程序的修改。这是项目经理第一个错误,也是实际中经常出现的错
误。对于新的需求就要按照流程重新制定计划,而项目经理在此没有做分析,直接上修改,为项目的
失败流下了隐患。
2、做项目结束的不是存在钱付了没有,而是是否正常运行,通过非正常方式进行的验收,一定会出
现问题,害了自己也害了公司,还有那在政府工作的。、

·项目经理应该负什么责任?(2008-04-08) [作 者] suainwang [公 司] foxconn

我认为项目经理不够主动与积极沟通而导致项目系统的重大 Bug,这具体表现在以下:
1.由于项目的时间短,项目经理应充分考虑由于时间短带来的项目风险,他应及时主动的与管理层取得
联系,说明时间短带来的风险以及如何积极应对风险。比如要求增加人员,考虑让项目成员加班,并
行进行一些工作等等。
2.可能由于时间短,项目经理没有分析所有干系人的需求,没有制定详细的项目范围说明书以及给项
目发起人确认项目的工作内容,导致在项目执行的时候项目经理省略了系统测试这么重要的工作包。
为系统的质量留下了隐患。
3.公司的质量控制部门未对项目的质量政策执行情况进行严格审查.

·项目经理的责任(2008-04-03) [作 者] 汪偉 [公 司] 英志集團

第 675 页 共 756 页
第 10 章 风险管理

这个案子是一个是否坚持原则的问题。有时项目经理碰到了问题,将明显导致项目的失败,但是却必
须上马。可以坚持原则不做,但是公司领导不允许,你不做会请别人做,结果仍然会失败,你有可能
因不听从安排被解雇或因坚持原则得到好评。
也可以硬着头皮上,结果失败,项目经理必须担负主要责任。这种情况下,项目经理必须充分与各利
益相关者沟通,让风险暴露出来,让领导来决策,但结果只要失败,项目经理的责任是难免的。有时
候真的很冤。没办法。

·有错,但是不是全责(2008-04-02) [作 者] nieligong [公 司] cup

项目经理的错误在于擅自做决定,因为客户的时间约束,而擅自将工作范围(工作包)缩减,同时并未严格
执行公司或者项目的质量策略.
而他遇到的诸如时间约束,团队人员少等问题,都需要通过分析,提出具体困难.不做沟通这是他的不对.
但他不能付全责,首先公司的质量控制部门未对项目的质量政策执行情况进行严格审查,其次客户对项
目进行时间的强行规定的同时,未进行制定详细的工作说明

·项目经理应该负什么责任?(2008-04-01) [作 者] 王宏强 [公 司] 大恒图像

分三种情况:
1。在公司设定需求时,只是要求能够通过验收,全款拿到,项目经理已经上报了可能的风险和问题
后,仍然上级领导没有听从,那么项目经理应该不承担责任。
2。在公司设定需求时,要求按照正常项目进行,项目经理考虑项目流程应该按照小项目进行,但是
流程没有得到上级的同意甚至没有通知上级,那么项目经理应该承担责任。
3。在公司设定需求时,要求按照正常项目进行,项目经理考虑项目流程应该按照小项目进行,但是
流程得到上级的同意,但是项目经理没有严格执行,目经理应该承担责任。

·项目经理的责任(2008-03-23) [作 者] 张茂有 [公 司] 销售

在一个项目的启始时,项目经理就一直参与其中;我认为项目经理应该全权负责整个项目的过程.

·职责矩阵(2008-03-14) [作 者] albertsu [公 司] FIC

HOHO。
不知道政府是怎么样的招标形式来做的。
你中标了,就要做好。
无论花 5 万还是 500 万,买的车都不希望有质量问题。政府也这样。
出问题,合同上有没有说好让你负责到底?严重 BUG,做项目经理,谁想拿自己的信誉开玩笑?问题
的根本,在于职责矩阵中没有测试人员。

第 676 页 共 756 页
第 10 章 风险管理

其实,在投标的时候,就可以决定做不做。看你们公司老板的态度了,老板慈善,便民服务嘛,赔钱
也做。钱不多,说明理由,拒绝好了。你和客户是互利关系,不时互推责任的。

·项目经理责任(2008-02-25) [作 者] 申恩慧 [公 司] IT

项目经理这样的做法虽然在情理之中,但是还缺少一点就是:
(1)在开发项目之前要对系统做一个粗略的设计,至少保证系统有一定的空间。
(2)在规定时间内完成了项目后没有对之前的缺失做一个补偿,而是任由错误的发生。

·项目经理应该负什么责任?,(2008-02-24) [作 者] 肖鑫 [公 司] 河南天一

这个问题让我很吃惊,在我的印象中,项目验收完毕,拿到款就是成功啦。汗。

·项目经理的责任(2008-01-24) [作 者] 姬中柱 [公 司] 不公开

这是 2 年前的一个项目,谢谢各位参与。
项目经理是合同签定后进场的。因为当时项目是承包制的,项目时间短,金额少,对项目经理的压力
很大。为了在合同约定的时间完成,让公司领导与客户方满意,根本没有安排设计与测试时间,对应
的风险预案准备不足,没有保证质量。这都是项目经理的责任。
现在想来,项目承包也可能是原因之一,因为项目经理要证明自己称职,就要顺利完成项目,而当时
完成项目的标志,是收回尾款。只不过可能当时大家都觉得这是个小项目,领导不太在意,压力都落
在了项目经理身上,不干?走人。
不知道大家对项目完成的标志是怎么看的?让所有干系人满意?这是个很难达到的目标。我认为是能
让大多数干系人满意,在保证质量的前提下,完成约定的内容,成功通过验收。就代表了项目的成功。
这个项目,是个失败的项目,项目经理负主要责任,但是,不在其中,不知其味。个中原因,他应该
也很清楚了。

·项目经理应该说“不”(2008-01-24) [作 者] 老杨 [公 司] 产品开发和系统集成

如果这个项目经理认为这个项目没有预期的风险,那么是他风险意识太差,肯定要承担责任。
如果认识到了这些风险,但还是抱着侥幸的心理硬扛着上了,出现问题更要他承担责任,一味地迁就
客户和领导的一时喜好,不敢对不合理的计划说“不”的项目经理非常可怕。

·项目经理应该负什么责任? (2008-01-24) [作 者] 韩伟 [公 司] 旭电

第 677 页 共 756 页
第 10 章 风险管理

项目的风险范围计划,风险管控没有做好。当然这和项目经理以及团队(虽然只有一个队员)的能力
有关系的。

·项目经理的责任(2008-01-22) [作 者] 杨俊君 [公 司] 上海亚士漆

在这个项目中项目经理是要负责的,整个项目从开始接手就存在问题和隐患,在项目执行的过程中也
忽略了很多的管理环节,在后期也少了一项很重要的测试环节,所以项目的失败是肯定的,项目经理
也应承担响应的管理责任,在现有的很多项目中都存在有这样的问题,项目提出者在项目不具备条件
的时候盲目上马,而项目经理又是被很多因素制约下接受项目的管理,所以在项目的运做中就埋下了
很多隐患和风险,项目经理自然就成了牺牲者。

·在电子政务建设中推进项目化管理迫在眉睫(2008-01-21) [作 者] 周预 [公 司] 湘潭

项目失败了,追究责任是为了找一个开脱,那么无疑项目经理是一个很好的替罪羊。但这样做往往忽
视了寻找根本原因,在本案例中,根本原因是没有按照项目管理的基本原理来管理该项目,该项目作
得不足之处至少有:
1、项目的可行性分析。没有进行可行性研究,而是凭政府领导的长官意志,拍脑袋盲目确定完工日
期,有形象工程之嫌,这是项目预埋了一个定时炸弹。
2、项目风险管理。项目经理在接受一个先天缺陷的项目,而不进行风险分析并制定风险应对计划,
使自己处于一个不利地位又显得咎由自处。本案例中,项目经理应同客户、公司上级或高层分析项目
风险,提前指出项目质量和项目进度的矛盾,形成备忘录,已备项目回溯和合同纠纷,至少给甲乙双
方大哥预防针吧!
3、项目质量管理。系统设计、测试、回归测试没有进行,难以发现隐藏的 bug。至少在系统完成验
收后,有必要进行一些测试。
4、项目范围管理。项目的完成不是以验收通过为标准,那是合同收尾,项目完成因该是是否达到完
成项目的工作范围为标准,无疑该项目工作范围应包括测试和回归测试。
纵观项目,项目经理应负主要责任,接手这样一个项目,首先进行可行性分析,对于预设完工日期的
工程,应分析这样做的风险,争取甲方理解和乙方领导的支持,在项目合同收尾验收后,按照范围管
理制要求完成相应工作,而不是通过验收后万事大吉,同时在项目过程中,注重质量管理,并平衡质
量进度成本矛盾。而政府项目也应严格按照项目管理之要求开展。

·体制不健全产下的怪胎(2008-01-20) [作 者] dajundalao [公 司] 暂时保密

这个案例明显是体制不健全下的产物。聪明的政客和法学家把项目法的紧箍咒套牢了项目经理们,但
相应的配套约束机制却并不健全,项目经理常常面临是降低标准或寻求如偷工减料的其他办法来弥补
官员们拍脑门及吃拿卡要形成的巨额成本。许多项目,一进入使用环节,在有限的几年保质期内没有
事就过关了,国内没有一个象样的永久型质量标准下的预算和造价体系来监控,所以一般验收时都是
优质工程,使用不了多久就问题一大堆,甚至出现重大质量问题。当然,最后的责任承担者就落在项

第 678 页 共 756 页
第 10 章 风险管理

目经理的头上,法律规定他们是“责任终身制”,但法律并没有规定要对那些始作佣者进行如何的惩
罚。“一查到底”还是近几年来提的口号,没有法律依据。
本案中的项目经理当然有过错,但如果他按照 PMI 的思维来做这个项目,或稍微高瞻远瞩点,就可以
避免这些责任:一是前期应把这个项目进行可行性分析,就业主限定的如此背景下的项目进行 SWOT
分析,告诉可能存在的隐患,此时要促成领导就其 Idea 签字认可,从而减少自己的责任,同时证明
自己是按业主的要求来进行的项目,其结果只能是这种后果;二是售后体系他应当建立起来或是敦促
其上级建立起来,其后投入使用后运行中的质量问题交由售后部门解决,从而避免直接责任(这种做
法看来有些损,但国内外的工程或产品都是这样操作的,多一个扯皮的环节就减少了几分自己的直接
责任。比如房地产行业,再比如制造行业。具体点说如你买了某房地产商的房子,你装修前他们已经
通过佥程序转到了物业公司手里,你装修或入住时发现质量问题,你只能一次次地找,但谁都说不是
自己的责任,你要告状都麻烦;又如你买了某品牌的电饭锅,如果不好用或坏了,厂家的售后部门给
你修理,更换部件;再比如手机,你买后用了几天发现自动等质量问题,其售后给你修理或更换部件)。
言归正传,本案例的背后问题是:政府官员代表直接用户搞项目(审批这个项目的权力部门一般都放
行,因为这是上级领导亲自定的),但这明显是一个拍脑门的政绩工程,官员不是最后的使用方,老
百姓才是最后的使用方,出了质量问题他们当然要找出责任者,但由于政府官员的身份特殊,老百姓
不敢说政府的不是,当然把责任往项目的执行者身上推,而事实上是,项目的执行方他们能驳倒官员
们改变急功近利的政绩取向吗?当然不能。此时,项目经理只能是老鼠进风箱,两头受气,出了力还
讨不了好。
在为这个项目经理叫屈和深表同情的同时,我们但愿项目的动作和监管越来越规范,越来越合理,那
样,项目经理才有肥沃的土壤生长。

·项目经理应该负什么责任?(2008-01-17) [作 者] wildhorse [公 司] 外企

这个案例涉及到以下几个问题:
1.该项目经理是否应该负责?
答案是肯定的,项目经理应该对项目的结果负责任。
2.该项目经理在项目管理中存在哪些问题?
项目在半年后出现了重大 bug,说明系统出现了很严重的隐含的质量问题。追究其原因,主要是没有
进行系统基本的设计,没有遵循基本的软件开发流程开发,没有进行测试造成的。项目经理只讲进度
而忽略质量导致了项目最终的失败。所以成功的项目的标志是生产出令客户满意的高质量的产品,而
不是仅仅在进度上满足客户的需求。

·项目经理应该负什么责任?(2008-01-17) [作 者] 高明 [公 司] TBJ。co

项目案例非常典型,相信在国内类似的项目非常多,虽然项目能够顺利结束,由于在许多工作上项目
经理都是亲力亲为,项目经理也得到了公司和客户的肯定,但是问题一般都是被埋藏起来,在客户使
用起系统来之后,各种问题都相序暴露出来,导致项目不多维护修改问题,甚至有可能需要多次返工,
项目成本大增。

第 679 页 共 756 页
第 10 章 风险管理

10.6 关于工程项目的投标风险问题

关于工程项目的投标风险问题

guangdong
[姓 名] zhangxu [单 位] [邮 件] lexus999@21cn.com
jianzhuang
工程设计安
[所属行业] [所属主题] 项目风险管理 [发布时间] 2007-8-27

【案例正文】
大家都知道,一个工程项目,往往参与竟标的单位都很多,至少也有 3 家,多的几
十家,就我看到的最多有 150 多家。即使通过层层筛选,最终也都还有 3-8 家。

这样最终的每家都回去做方案、做标书、做预算。一搞就是几天、十几天。参与一
个项目的投标,从购买招标文件、到编制预算、施工组织设计、制作标书和装订,
时间上少的要十几天,多的有几个月;经济上的花费更是从数千元到数万元,而一
旦投标不成功,就意味着全部的投入都打了水漂了。

这样的风险处处存在,而且几乎每家都有。因此,关于工程项目的投标风险问题,
是一个普遍的问题。这不同于项目已经接下来了,只剩下怎么把项目搞好的问题。
也不同于只知道项目搞好不容易,却不知道项目承接更难的问题。

虽然这里面涉及了关系、权钱交易、投入的问题,但用最佳的投入、获得最好的效
果,仍然是追求的目标。

欢迎大家就这点提出自己的看法。这个问题解决了,你也可以做老板了。

【相关分析】

·风险分析(2008-01-25) [作 者] yyz [公 司] 北京石化

国内项目:
1 对业主了解
2 对投标项目很熟悉,最好做过或作过类似的项目
3 相当的与业主决策层的关系
4 第三条对独资企业稍可例外
5 挖出业主招标文件所设陷阱

第 680 页 共 756 页
第 10 章 风险管理

6 通过风险分析方法,采取规避,转嫁或风险承担方式处理
7 有些风险处理较困难,如汇率,物价上涨等只能靠经验在报价中埋伏一定费用处理
8 其它很多,就不说了

·就项目的性质而定(2007-10-08) [作 者] dajundalao [公 司] 暂时保密

这个问题太大,需要据项目的性质而定。如果除去文中所说的那些因素,可从以下来分析--如果你
是 PMP,那么我就在此献丑了:
1、如果是 PMC,即让你投管理标,业主除了出钱,所有风险全部转嫁到你单位,其它的管理、EPC
都是你单位,那么从规则上是允许你单位加入风险因素来考虑,在我国国内这种模式刚刚起步,绝大
多数企业还不具备这个实力。这种模式风险利润丰厚但也是把双刃剑。
2、如果是业主让你参与共管,即 PMT 或 IPMT,风险存在业主与你单位共担(实际上业主担)
,你
单位风险较小,你单位只有把工程项目分解,进行 EPC 或设计、PC,或业主自己采购然后进行 DB
分包等,此时把风险传递下去,你单位所承担的风险当然就小了。
3、如果你单位不具备上述实力,而最多能参与到 PC 一级的承包,那么 PC 一级的风险主要是不可预
见风险,以及采购材料设备价格风险、材料质量风险和施工工期风险。由于一般你单位所参与的项目
为你们所熟练的项目,因而可排除施工成本风险和施工质量风险,因为业主或管理目的在于要你单位
优化组织,完成施工项目。但这又面临业主的严格要求、同行的公平竞争和地方小队伍不具备实力的
恶性竞争等。这在国内中海油运用 PC 承包运用得好(保持了施工方的微利),给中海油省了不少钱,
但不规范的竞争让施工方吃尽了苦头,也增长了见识。
4、如果你单位只具备施工项目的能力,那么这个层次竞争对手太多,既有来自高端的,又有来自同
一层次的,还有地方小队伍不具备实力的恶性竞争。此时你单位面临的是与其他一类的或不入流的队
伍一样把求生存放在第一位,只能是避免大风险消化小风险,并利用车国内预结算的空子求得利润空
间,或进行再分包、或选择从纸上具备实力而实际上根本不具备实力的小队伍来施工,但此时你单位
风险隐患较大,需要加强管理。一如中石油独山子石化恶性压价,迫使施工方再分包或选择不大具备
实力的地方队伍而寻求风险转嫁或利润空间,终成 2006 年的人间惨剧(数十人死于大罐中)。
5、如果你单位是民营或是集体的小队伍,则最好选择几个固定的大队伍,紧跟他们发展关系,形成
有良好信誉的固定分包伙伴,则肯定有人家的肉吃就有你单位的汤喝,风险也小得多。若属于吃了上
顿没有下顿的,则就另惶论风险了,因为能不能生存已经是你单位最大的风险了。
也不知以上的回答你满意否,若不满意,请来信交流。

·风险与收益并存(2007-09-29) [作 者] 登高望远 [公 司] SHK

投标单位必须对招标项目有充分的了解,当然不计成本的拿项目除外。
个人认为投标风险有几种:
1.对项目进展不了解,包括项目的前期手续办理进度、场地条件等
2.对招标文件中的技术、质量要求不明确
3.合同条件中的承包方责任理解不准确
4.潜在的不确定因素

·行业门槛,如此而已(2007-09-27) [作 者] 陈万春 [公 司] PETL

第 681 页 共 756 页
第 10 章 风险管理

这是一个最基本的行业门槛问题,是业内参与者的必备预算之一!

没有一个公司投标能 100%成功中标;承担不起这种风险的参与者,只能接受淘汰命运.

这是最基本的逻辑!

·Bidding Risk of oversea projecr(2007-09-23) [作 者] kevin [公 司] guandaoju

笔者参与了多个海外项目的投标, 在这种大型的国际项目招标中的确存在着大量的风险因素, 业主
在招标过程中有时有意提高承包商的投标风险, 例如加大投标保函风险等, 其目的主要如下:
1、 通过提高投标风险的门槛, 将一些实力较差的承包商拒之门外;
2、 在已经选定潜在承包商的情况下, 通过引入更多的竞标商 , 加大与真正潜在承包商谈判的筹
码;

·投标只是形式(2007-09-13) [作 者] 吴先生 [公 司] 东莞某外资公司

在中国,没一个项目真正的较量是在投标前,就是可户内部立项的时候。到招标阶段,谁中标基本就
内定了。

·充分为客户考虑,从投标开始(2007-09-05) [作 者] 李允鲁 [公 司] 华能

其实我觉得这个投标的问题不是“招标项目更适合小公司”这样看的。前段时间刚刚负责过一个小项
目的招标。虽然说是一个小公司中标了,但是我也看到了所谓的大公司的问题:
大公司投标往往从自身的角度看问题,选材,技术施工也往往是把自己最好的一面给彰显出来,这个
过程中就把客户的需求给忽略了。而且在报价的问题上也没有足够的重视,存在着重复报价的问题。
结果一个客户需要一个 30 万左右的运动场在大公司的报价文件里成了一个 60 万左右的项目,这是无
论如何也不能中标的。这在项目管理中也是一个平衡各种目标的原则。
关系固然重要,但是根据客户的需求,制定适合客户需要的方案,能够站在客户的角度来思考项目是
很重要的。这也可以为以后的项目实施做好准备。

·投标风险无处不在!(2007-09-05) [作 者] 朱兵 [公 司] 中国核工业华兴建设有限公司

既然是投标,每个投标企业就应该重视。如果想拿下项目,那必然是花了心血的。当然了成本当然是
存在的,但是不能叫投标风险,投标只是企业为继续发展所必须进行的,没有新的项目怎么发展企业。
我不赞同发贴人的风险的观点。

·实际上,招投标项目没有那么大的学究味(2007-09-04) [作 者] daijiangbao [公 司] 深圳市


大视野企业管理顾问有限公司

第 682 页 共 756 页
第 10 章 风险管理

对于招投标项目,大家认为是公平的,这实际上是不对的,这个世界上根本不存在公平,有公平的世
界是理想的,在理想中幻想现实是不正确的。
就招投标项目来说,客户在控制,投标商也在控制,客户绝对不会在没有一个有偏向性的投标商之前
去贸然招标。
从这个意义上来说,投标商越是能在招标之前控制住客户,越是能最终中标成功,绝对的说把标书写
好就能中标,那是书本上的说法,实际上几乎没有。招标公告一发出,其背后隐含的意义基本上是:
我已经把中标商选定了,欢迎大家来凑热闹。当然也不排除可能发生出乎客户意料之外、不能控制的
事情。
在招标之前,基本上客户已经被某一个投标商搞定了,别人一般很难再插手进入,招标只是一个形式,
不是提供公平竞争机会的时机,在这种情况下的招标,客户会暗中帮助她的意中人,这样就会对其它
人员造成一些壁垒。
就如同现在年轻人一样,在对外正式宣布谈恋爱时,其实早就暗送秋波、暗中来往、同居、怀孕,甚
至是孩子都已经生下来了,对外宣称谈恋爱,不过是些遮人耳目的幌子,绝对不是对外宣称公平竞争
机会的到来,这时其它投标商要横刀立马,夺人之爱,是要费很大功夫的,当然也不排除能夺下来,
但是项目招投标,绝对不是理论上的公平,这个世界如果公平就没有意义了。

·打有准备的仗(2007-09-04) [作 者] 毛知新 [公 司] 湖南大学

这种现象现在在哪个行业都开始出现,在工程项目很明显.
1、首先应对招标的项目有充分的了解,特别对与项目招标相关人员有详细的了解。
2、对自己的势力有准确的定位,不要什么项目都去参与,有针对性地去参与招标。
3、现在的招标主要在人际关系,当然产品也要过得去。
总之,在参与招标过程中应做到知己知彼,才能百战百胜。

·关于工程项目的投标风险问题(2007-09-03) [作 者] 沈莉 [公 司] 青海大学

为了取得招标的成功,前期的调查实非常重要的,应该在平时就有一些针对客户的开发措施,了解一
般客户的编号和对项目的要求;在标书制作上应该就有一些不同的模块的范本,这样可以节约大量的
标书制作时间,节省的时间可以很大限度的用来开发针对客户特性的独特一面的制作,这样赢取得比
例会不会根大一些?

·招标项目更适合小公司(2007-09-01) [作 者] daijiangbao [公 司] 深圳市大视野企业管理


顾问有限公司

由于项目管理水平不高,实际情况情况是大公司可能会得到项目,但是失败的更多,大公司比小公司
失败的更多。
在实际的项目招标中,往往大公司牛鼻哄哄的,报价高,反而容易被淘汰,而小公司可能报价低也容
易淘汰,这些相对来说,中小规模的公司反而好一些,生存的反而好一些。

第 683 页 共 756 页
第 10 章 风险管理

就招标的这种方式,很难培养出一个公司能够在一个行业沉淀下来,所以中国的这些公司这种方式难
以长大。
尤其是软件企业来说,在国内招标笼罩的项目方式就很难培养大的软件公司,根本就长不大,还没有
长大就灭亡,所以在中国在呼吁什么把软件公司做大,呵呵,基本上没有环境,因为对客户做服务,
中小规模的最合适,这是自然淘汰,关键是通过每个项目多获得高利润来把公司做强,不要想把公司
做大了再做强,这种想法也就是妄想而已了。

·心声(2007-09-01) [作 者] 李飚 [公 司] 格力电器

这个案例的内容,道出了许多规模不大的单位的心声,对于一个小公司来说,却实经不起这样的折腾,
而目前的形势却是公开竞标等,都要求看实力与规模,所以这个问题成为了小企业单位头痛的问题之
一.

·工程项目的投资风险可以用软件评估出来(2007-08-31) [作 者] 赵鹏 [公 司] 中船电气管理
咨询部

我们公司主要就是做针对项目管理,风险投资,成本控制的软件公司,这套项目管理思想,已经在国
外运用了 20 多年,它有一套很成熟的管理思路,希望大家可以借鉴一下,有什么问题希望大家给我
们公司来电话,我们尽量帮助大家解决一些问题。

·关于工程项目的投标风险问题(2007-08-31) [作 者] tjh [公 司] cxgs

具体怎样能竟到标,的确需要多动脑筋去迎合业主的需求,这才是投标的关键。做为一个成功的投标
者,首先要有好的业绩与口啤是必需的,特别对一些重大的有影响的工程。

·投标风险很简单(2007-08-30) [作 者] showrouter [公 司] 上海某科技发展有限公司

其实很简单。以 it 类集成项目为例,投标之前,衡量一下自己有可能中标吗?衡量的条件:
1、关系到位吗?
2、自身的条件做得出来吗?
3、垫资垫得出吗?
4、客户的信用度怎么样?签完合同付得出钱吗?
暂时想到这几点,仅供参考。
其中最重要是第一点,如果第一点没戏的话,其他点统统不用考虑,直接放弃该项目。

·合同中没有规定单价,如何进行额外工作的索赔计算?(2007-08-30) [作 者] 肖茂堂 [公 司]
国电华北电力设计院有限公司

第 684 页 共 756 页
第 10 章 风险管理

案例:
我们正在实施的一个项目,采用的合同范本是『CONDITION OF CONTRACT FOR PLANT AND DESIGN-BUILT』
(1999 版)招标文件中有一个附件『BREAKDOWN OF CONTRACT PRICE』,要求递交一个有关工程因素
的费用分解表,包括现场人员(主要人员和其它人员)的月度人工成本、可补偿的费用支出。该附件
的目的是用来计算额外工作的费用补偿。我们在投标时,由于某种原因没有提交该表格。在工程实施
过程中,因业主的原因使得我们的工期受到延误,为此我们想提出索赔申诉,可是在计算索赔费用时
却找不到计算依据。
问题:
在合同中没有规定单价的前提下,我们有无权利进行索赔?如果有,如何对相关费用的单价进行取
值?期待各位前辈们的指点!

·项目投标(2007-08-30) [作 者] mark [公 司] 新广国际

项目投标其实涉及到很多不为外人所知的秘密因素,这点我相信搞经营的人都清楚,把投标作为一个
项目来管理,关键还是项目操作,至于做方案、做标书,这点每个公司其实都有一些很完善的项目技
术方案和标书版本,对项目技术层次的理解和分析应该相差不远,关键是报价,很多时候项目决定因
素就是报价,根据项目招标文件进行报价是否合理,以及是否能在众多投标单位当中成功中标,每个
公司可能都有自己的一套办法,不知各位高手是否可以指点一二。

·关于工程项目的投标风险问题(2007-08-29) [作 者] 卢亚军 [公 司] 富士康科技集团

站在客户的角度来考虑问题,分析客户最需要和最关心什么,中标的可能性才高,而且失败了也不能认
为是打水漂,要分析客户没有接受或选择其它公司方案的原因.知己知比 才能百战百胜.

·投标风险(2007-08-28) [作 者] 林先生 [公 司] ABC

这样的问题的产生一是由于业主为了选择更好的性价表的供应商,降低建设成本的需要,也是市场竟
争的必然。就我的经验而言,大多数业主不会选择价格最低的供应商,当然更不会选择价格最高的施
工方,而是选择合适的承包商。具体怎样能竟到标,的确需要多动脑筋去迎合业主的需求,这才是投
标的关键。做为一个成功的投标者,首先要有好的业绩与口啤是必需的,特别对一些重大的有影响的
工程。

·如文章(2007-08-27) [作 者] apm [公 司] UNN

知己知比 百战百胜

·简单来说(2007-08-27) [作 者] daijiangbao [公 司] 深圳市大视野企业管理顾问有限公司

第 685 页 共 756 页
第 10 章 风险管理

把招投标过程当作一个项目来看,不是仅仅把标书写的好就可以中标了,而是在招投标之前就有许多
的工作要做,主要是让客户对方案和公司认可并获得支持,客户也不希望出现意外,不希望出现突然
不熟悉的面孔来给他们做服务,所以这个阶段的工作还是在前期的规划,这个过程少不了关系、权钱
交易等,这些权力和政治斗争不要从负面的眼光来看,但是不要沉湎于其中的政治和权力斗争,项目
管理从来就没有回避这些问题,从项目管理环境那些章节就非常清楚,不要有天下舍我其谁,怀才不
遇的感觉和理念,所以要真正理解项目管理,就一定要把项目管理环境正确、积极的理解清楚,不要
只是看后面的九大知识体系,认为九大知识体系才是项目管理,那就彻底错了,项目管理环境章节、
内容不多,但是不把这些基础打好,后面的什么过程、体系都是没有基础的,实际项目管理的应用和
pmp 纸面考试是有差距的。
另外,项目接下来,只想着把项目做好就可以,认为没有什么风险了,那就大错了,一般是这时的风
险都没有处理好,等到项目后期风险积累的能量爆发,就会把项目搞的一塌糊涂,把项目搞好和让客
户接受项目这是两码事,千万不要认为项目做好了客户就要接受,这之间不是必然的联系。
好的项目经理就是从项目的概念就一直管理项目,一直掌控项目的大局,不是项目中标以后,认为撅
屁股干活才是项目,这样培养不出合格的项目经理,项目经理也就是干活的小监工而已,也成不了老
板。

10.7 合作开发项目陷入困境

合作开发项目陷入困境

[姓 名] 黄晓华 [单 位] 广东华联软件有限公司 [邮 件] hxh_sky@163.com


[所属行业] IT 软件 [所属主题] 项目风险管理 [发布时间] 2007-8-20

【案例正文】
A 公司招标开发适用于自己公司的项目管理系统,由于此行业相关系统领域仍然是
一块处女地,B 公司积极的与 A 公司合作,双方决定合作开发系统,由 A 公司提供
行业环境的经验和管理方法,B 公司进行需求分析和开发工作,并签订了合作开发
技术合同,双方各拥有产品 50%知识产权。

但是在开发过程中,A 公司逐渐对 B 公司开发工作的拖沓作风尤其是其项目经理小


王的个人工作作风很不满意,原本计划 7 个月内开发出原形系统,然后花 5 个月由
A 公司在项目现场进行试用,而实际情况是开发工作已经接近 1 年才勉强拿出原形
系统。好不容易进入试用阶段。此时 B 公司的资金投入已经远远的超过了合同带来
的收入,故希望 A 公司能更改合同金额,而 A 公司认为 B 公司不但没有按时完成
合同规定的工作内容,而且拖沓的作分十分不值得合作,故拒绝建议。

第 686 页 共 756 页
第 10 章 风险管理

B 公司从此开始消极对待该项目后面的工作,双方进入僵局。但是事情发生了变化,
A 公司准备对该系统的后续系统再次进行开发招标,B 公司在这方面有前期系统开
发的天然优势,同时希望能积极获得此单平衡前期系统的经济损失,于是由你替代
了项目经理小王,并希望借此重新打开局面。A 公司愿意继续与你在前期系统上合
作,但是坚持合同不能更改且后续系统需要招标,并且要求你在很短的时间内完成
前期系统的大量存在问题的修补工作,但是你却发现手上的资源远远不够完成这些
工作。

问题 1:前期系统的开发工作中 B 公司项目经理存在哪些问题?
问题 2:你现在应该做什么?
问题 3:如果决定改善与 A 公司的关系并满足其要求,如何面对资源不足的情况?

【相关分析】

·做好项目干系人管理(2007-10-18) [作 者] SturdyLu [公 司] 上海财经大学

问题 1:前期系统的开发工作中 B 公司项目经理存在哪些问题?
a,进度管理,进度拖延
b,沟通问题,绩效信息不透明,没有做好相关项目干系人的期望和沟通工作,
c,没有做好变更管理

问题 2:你现在应该做什么?
a,系统继续进行下去的可行性分析
b,与相关项目干系人沟通,确定当前他们的期望
c,对原来系统的绩效进行分析,分析原来存在的问题
d,深入了解当前 A 公司的需求期望,判断是否可以先满足其中的部分要求,也要做当前的工作范围
中是否有些内容要取消
e,分析项目后续工作的 B 公司优势以及经济可行性

问题 3:如果决定改善与 A 公司的关系并满足其要求,如何面对资源不足的情况?
a,首先需要确定的是,不是满足用户的所有需求,有些需求本身是不可以实现的(对于一个已经开
发了一年的项目来说,应该可以做一定程度的判断)
b,深入了解当前 A 公司的需求期望,判断是否可以先满足其中的部分要求,也要做当前的工作范围
中是否有些内容要取消,
c,重新进行范围确定,并更新后续的进度计划、风险计划、沟通计划
d,资源不足的情况下,需要判断任务(需求)的优先级,并与 A 公司商谈,做计划的调整,一定要
做到计划具有可执行性。
e,相关计划取得相关项目干系人的确定

第 687 页 共 756 页
第 10 章 风险管理

·合约管理(2007-09-29) [作 者] 登高望远 [公 司] SHK

从案例的简单描述中,不能充分了解原项目经理小王的项目管理环境,草率的对其个人的业绩下结论
是不合适的。
A 公司与 B 公司的合约是开发某行业的管理系统,双方都没有相关经验,可能导致 B 公司对项目开
发的风险没有充分的了解,比如:1.项目开发的工作量 2.需要的周期 3.需要投入的资源等。还有双方
合作开发,由 A 公司提供行业环境的经验和管理方法,B 公司进行需求分析和开发工作,在合作过
程中,A 公司是否能提供明确的需求,也是决定项目开发成败的重要因素。
从 B 公司角度来看,如果此项目在知识产权和经济收益方面有足够的吸引力,案例出现的问题在一
年内都没有很好的解决是不大可能出现的。恐怕小王早就被炒了。
从项目的合约管理角度来说,B 公司和项目经理小王在面对成本超支,项目亏损时,采取了消极态度
而不是在初期积极应对,争取合同变更,只能导致项目的失败和公司更大的损失。

·合作开发项目陷入困境(2007-08-30) [作 者] tjh [公 司] cxgs

1\尽量提高二期的利润空间
2\建立项目领导小组和变更规则
3\大力促使甲方参与项目,甚至直接要求甲方项目人员全职到项目组中承担工作

·根据案例进行的相关分析及自己的看法(2007-08-27) [作 者] 林伟 [公 司] 厦门福建电子口岸股份有
限公司

问题 2:你现在应该做什么?
首先了解查看系统的相关资料,找项目小组成员了解目前系统的情况,老板对该项目的态度,及
公司目前的资源可调配情况,再找客户了解当前的使用情况,存在的问题, 给出相关的补救方案,
如通过了解收集现有存在的大部分问题,将问题根据客户的迫切需求进行分析,列出轻重缓急,而后
于 A 公司相关负责人进行协商,将问题分阶段进行修改,并给出修改的时间进度。重要部分马上修
改,不是当务之急修改部分,与客户协商是否可以放在二期工程一起进行实施。
公关方面可以让公司高层出面协助解决。

问题 3:如果决定改善与 A 公司的关系并满足其要求,如何面对资源不足的情况?
对于资源不足方面,将系统架构做出来,对功能进行模块化设计,做出 WBS ,具体分析需要多
少的人手,要根据目前公司的情况进行分析,在规定的时间内有多少的资源可分配,若按赶工的方式
在规定的时间能完成多少工作量,而后考虑那些工作可以进行外包或者招人。

·根据案例进行的相关分析及自己的看法(2007-08-27) [作 者] 林伟 [公 司] 厦门福建电子口岸股份有
限公司

问题 1:前期系统的开发工作中 B 公司项目经理存在哪些问题?

从案例的分析来看项目经理小王代表 B 公司参与此项目,作为项目负责人不够称职,自身的素质

第 688 页 共 756 页
第 10 章 风险管理

有待提高。
1、首先从案例分析原计划 7 个月开发出系统原形却延迟到快 1 年才开发出来,表明开发进度严重落
后,说明项目存在以下问题
(1)、项目需求调研不明确、与客户没有进行充分的沟通( 即项目范围不明确 )
(2)、没有做好该项目的整体进度规划,包括调研进度和开发进度、测试进度计划
(3)、没有做好成本的控制,对于资源的调配不当
(4)、B 公司在项目管理方面,没有相关的监督措施,以致于 A 公司在对小王的工作作风不满的情况
下没有及时采取任何措施与补救的方法。

2、以上问题可能由以下几个原因造成:
(1)、是项目经理自身的原因
(如没有责任心、相关的工作没有做好,与客户的沟通存在问题,需要领导出面协调的事情没有报)
(2)、是 B 公司内部管理问题或内部资源不足。
(3)、A 公司有关人员不配合调研,使得调研不明确

如果是自己运作该项目如何操作呢? (自己的看法,欢迎大家讨论)
了解并根据现有情况制作初步的进度安排计划表,而后和 A 公司相关的负责人进行沟通交流(开会)
明确责任,最终确定以下几个方面的事宜
• 业务需求调研方面的具体时间进程及安排
• A 公司各部门需要进行调研配合的人员名单及联系方式
• 与各相关人员的沟通方式
• 初步确定会涉及的文档,请各部门进行前期的准备。
• 再根据客户需求和公司现况申请调配相关人员。若资源不足的情况下,可以和 B 公司领导商量是否
能够进行人员调剂,公司内部经过协商调剂后还无法安原计划完成原形系统的开发,可以公司领导或
项目经理与 A 公司将情况阐述清楚后进行协商解决。
• 明确双方的一些责任,比如,如果是因为 A 公司方面的问题造成调研的进度落后或是需求调研不明
确,那应是 A 公司的责任。

·补充(2007-08-24) [作 者] nihuai [公 司] emsssoftware

如果如问题中的第三条,需要继续笑脸合作,作为项目经理能够做的有以下 3 条:
1\尽量提高二期的利润空间
2\建立项目领导小组和变更规则
3\大力促使甲方参与项目,甚至直接要求甲方项目人员全职到项目组中承担工作

·同意daijiangbao的观点(2007-08-24) [作 者] nihuai [公 司] emsssoftware

这个项目的二次招标是另外一个项目了,之前的项目双方是有风险准备的,因为"进入新领域"就意味

第 689 页 共 756 页
第 10 章 风险管理

着高风险,项目延期和原型不符,这些因素可以宣布这一个项目的失败,那么责任是否是小王呢?作为
项目经理应该负上延期导致成本超出的责任,而且这还必须建立小王在没有及时发现并汇报问题的基
础上,但是不能承担项目失败的全部责任,文中说到,甲乙双方都是项目的所有者,小王是双方认可的
项目经理,那么项目进展不顺畅时,小王如果直接向领导小组汇报了问题提出变更,而领导小组对变更
认可,而后面甲方再度认为不满则可以视为甲乙方的合作失败.这样乙方完全没有必要无偿去做下面
的项目了.我是接手这个项目的项目经理的话,立马会掉头说:"先把屁股擦干净来再上餐桌,我只答应
和你们吃饭没道理还要我来给你们擦屁股吧!"

·对项目经理来说,你在为谁工作?(2007-08-23) [作 者] daijiangbao [公 司] 深圳市大视野


企业管理顾问有限公司

对一个项目来说,项目经理是需要认真考虑的一个问题是:我在为谁工作?
最简单的来说,就是开发方(乙方)谁给项目经理发工资?难道是合同的甲方(用户方)吗?从等价
交换的角度来看,项目经理的老板给项目经理发薪水,项目经理就是在为自己的老板工作,项目经理
的工作首先就是要满足自己的老板需求,你给狗扔一块肉,狗都不会咬你,对你感激不尽,这点浅显
的道理连狗都知道,怎么到了软件开发行业,项目经理的智慧连狗都不如了。
如果哪个老板喜欢把哪个项目做的亏损一塌糊涂,亏损的越大越喜欢,那我上面说的就不成立的,可
以去问问你的老板,他是否愿意这样。
在商业环境下,项目的成功不是让合同的对方满意就行,关键搞清楚谁是真正重要的干系人,你该怎
么满足真正干系人的需求,平衡其他不同干系人的利益,远比简单看到的客户满意重要的多,而宁愿
让自己赔的一塌糊涂也要满足甲方的要求,是很实在的愚蠢想法,倒是不清楚为什么还有这么多的人
推崇这种想法。
对这个案例来说,可能大家追究的是 B 公司项目经理的拖沓工作作风,这只是表面现象,反过来说,
项目经理小王勤快了,项目就不延误?我想做过项目的,应该清楚这之间有多少直接的关联关系,远
的不说,就案例的叙述,项目面临着资源短缺的问题,可能也是造成项目延误的一个原因,这个也可
以归结到其个人工作作风拖沓来吗?太牵强附会了。
投入的做项目,就会对项目产生一种情感,总想做成功,但是越做亏损越大的项目还是理智一些对待,
不应该感情用事,也不该总想象着美好的未来,要能看到现实。
项目本身就是买卖,项目不是研究机构的玩具,是实实在在的商业交易,商业交易中最基本的一点是:
“不做亏本的生意”,让甲方客户满意是应该的,但是商业中的基本原则不该摒弃,否则的结果是让
甲方客户不会满意(这个一点都不奇怪),让自己的老板更不会满意,这是软件开发事实中应该看到
的结果。
对于后续的项目来说,前面都已经亏大了,这次也不会有好的结果,所以没有必要进入,只有让客户
跟着一起失败,项目才能成功。
另外就是,不清楚为什么对软件开发的招投标都非常恐惧,实际上软件开发的招投标是从法律上对开
发方的保护,开发方应该最受欢迎才对,但关键的一点是无论是软件工程还是 cmm,cmmi 都对软件开
发的招投标避开的,含糊不清的,因此用这些学究派的理论是无法解决在商业社会招投标项目中的问
题的。
项目经理要能从更高的层次来看待招投标软件开发项目,要在法律的框架下,才能获得正确的解决方
法,这些就不是软件开发技术能解决的。

第 690 页 共 756 页
第 10 章 风险管理

·再说一点问题(2007-08-22) [作 者] teresa [公 司] 广州

项目经理存在的问题:
进度:“原计划 7 个月内开发出原形系统,而实际情况是开发工作已经接近 1 年才勉强拿出原形系
统。”严重拖延。
质量:拖延近 5 个月才勉强拿出原形系统,并存在大量问题。在需求分析和开发工作环节上质量控制
不到位。
成本:进度严重拖延,质量差,造成成本支出大,已经使公司的资金投入已经远远的超过了合同带来
的收入。
风险:由于此行业领域的管理信息系统是处女地,其中需求和技术的风险很大,在风险识别分析和应
对措施明显不力。

沟通:由于初次涉及此类领域,双方缺乏经验,需要良好的沟通协调,来达到对项目的共识。但是此
项目问题重重,项目经理首当其冲。

·案例(2007-08-22) [作 者] teresa [公 司] 广州

1、在此合作项目,B 公司负责需求分析和开发工作,项目经理主要存在的以下问题:
进度:原计划 7 个月内开发出原形系统,而实际情况是开发工作已经接近 1 年才勉强拿出原形系统。
严重拖延。
质量:拖延近 5 个月才勉强拿出原形系统,并存在大量问题。在需求分析和开发工作环节上质量控制
不到位。
成本:进度严重拖延,质量差,造成成本支出大,已经使公司的资金投入已经远远的超过了合同带来
的收入。
风险:由于此行业领域的管理信息系统是处女地,其中需求和技术的风险很大,在风险识别分析和应
对措施明显不力。

2、所作:
正面解决,积极沟通,对内寻求高层支持,对外寻求客户的合作,项目管理的规范化。
首先和项目团队一起找出前期问题,分析原因,就出现的问题所作的调整措施;核算前期的成本花费;
找出与计划目标的差距,对后续工作全面估算,做出合理的进度和成本估算;就项目合作的前景和收
益进行预估;形成文档,发送给 A 公司相关负责人,表达合作的诚意,期望双赢的态度(最好开一个
双方相关责任人参加的沟通协调会议),希望 A 公司就将来的收益考虑能够考虑合同金额,接下合作
的可行时间和做法。
公司内部,将发送给 A 公司的文档同时抄送公司高层,表达团队的信心,争取高层支持;项目团队内
部,就前期失误和不当之处进行分析总结,解决问题,吸取成员有益意见,奖惩分明。
项目管理,严格按照规范执行(没有就制定一套项目级的流程),保证有效的监控:定期汇报项目信
息,抄送项目主要干系人,做到信息透明;按计划定期检查项目成果,有序开展质量保证活动。定期
检查项目风险,每次项目例会最好作为例行核查下风险变化,主动应对风险。

第 691 页 共 756 页
第 10 章 风险管理

3、资源不足的问题:
公司内部:如果决定改善和 A 公司的关系,就意味 B 公司接受 A 公司的继续合作意愿,这时候,需要
和公司高层据理力争,进行有力的说服(见 2 部分),给公司高层信心,争取对项目的支持,获取必
要的资源。如果公司资源实在紧张,就要求精兵和奖励制度,通过加班,来尽可能满足 A 公司要求。
公司外部:拿着 2 部分形成的分析文档,向 A 公司诚恳阐述可能的工作量,双方历史原因,公司成本
花费一览表及未来的估算,在双赢的基础上希望大家合理面对现有问题:考虑适当延长项目解决问题
的时间(增加项目时间),或者能够委派人员进项目组(增加资源)。

·合作开发项目陷入困境(2007-08-21) [作 者] 方井柱 [公 司] 麦格纳斯泰尔汽车技术(上海)


有限公司

1.前期系统的开发工作中 B 公司项目经理存在哪些问题?
作为一个项目经理,他所要做的是要保证该项目能够最终满足客户的要求,那么就要从时间、成本、
以及质量上进行控制,很显然,B 公司的项目经理在这三个方面都没有做好;

2.你现在应该做什么?
显然,这是一个非常棘手的问题,一方面客户已经对我们的公司失去了原有的信任,另一方面,我们
在该项目上已经存在了亏本的现象,如果我接受了该项目,从公司利益出发,首先要做的就要进行成
本核算,并和工程部、财务部进行沟通,以制定合理的价格战略,保证公司在继续做下去的情况下,
保持不亏本;
同时,由于我公司对该项目天然的优势,我会组织工程部,对目前的项目情况进行分析,找出该项目
实际的状态,明确与实际目标之间的差距,并定义下一步的计划,并将此汇报给 A 公司;
在两者度做好工作以后,对自己的内部团队进行整合,坚决去除那些工作不认真的员工,同时制定周
例会的机制,以保证项目进展的透明性,随时和 A 公司进行正面的沟通,寻求 A 公司在项目进展过程
中的支持;

3. 如果决定改善与 A 公司的关系并满足其要求,如何面对资源不足的情况?
资源不足是上个项目遗留下来的问题,但是为了寻求足够的资源支持后续的开发,我会要求 A 公司在
后续的开发中,能够给予足够的信息和人力支持,从某种程度上讲,这也大大节省了公司的成本。

·失败都已经是定局,何必再扩大损失?(2007-08-21) [作 者] daijiangbao [公 司] 深圳市大


视野企业管理顾问有限公司

当 B 公司的投入已经超过合同预期带来的收入时,就应该中断项目,没有必要这样亏本讨好客户,更
没有必要再花多余的成本亏空讨好客户。
项目的成功固然要让客户满意,但是商业社会里,不顾忌项目的效益而一味去满足客户是愚蠢的,这
样做一个项目亏一个项目,远不如把钱放在银行里生崽保险,更不是因为是什么高科技、软件的名义
就必须做,就必须亏才是应该的、合理的,如果不能从商业的角度来看项目管理,本身就是失败的项
目管理,不要指望这次失败了,下次能够成功,把这次的失败能够补回来,也绝对不是所谓的“失败

第 692 页 共 756 页
第 10 章 风险管理

是成功之母”来安慰自己,如果不能按照成功的项目管理去做,再失败 100 次,第 101 次也照样还是


失败,不会得到成功,没有必要有这样的妄想,有多少的软件公司都是在这样的妄想中走向了失败,
最终连妄想的机会都没有了。
至于后续项目的招标,那是另外的项目,可以与这个无关。
需要做的事就是总结经验教训,用在下一个项目中,对这一失败的项目做什么都是没有必要的。
正是因为项目都受到资源短缺的制约,才会显得项目管理的价值,才显得项目管理的意义,有充足的
资源来做事,基本上就不需要项目管理,反过来,资源短缺历来不是项目管理失败的关键因素,有多
种的方式来解决。

10.8 版本控制的难题

版本控制的难题

[姓 名] Elvis Win [单 位] 不公开 [邮 件] randomwin@yahoo.com


[所属行业] IT 软件 [所属主题] 项目风险管理 [发布时间] 2006-7-10

【案例正文】
最近遇到了一个版本控制的难题,导致多次上线后系统大面积瘫痪。正在进行的项目是一个
二期开发项目,一期、二期在一个同一个环境,目前项目内的工作内容有:对于一期中 Bug
的修改、更新和对于二期内容的开发。其中:一期内容和二期内容有很强的关联性;一期内
容的 Debug 结果要求用户方面测试,测试后及时更新上线;二期开发内容要求分阶段上线。
所以结果导致:有时一期 Debug 结果上线后,影响二期开发、已上线内容;有时二期开发内
容上线后,影响一期内容,或一期 Debug 上线内容。

最常见的头疼问题比如:功能 A 是一期 Debug 结果、两个月前开发完成,近日用户测试完


成,A 功能完成后,Debug 开发进程继续。功能 B 是二期功能,一个月前开发完成,二期开
发进程继续。在 A 功能开发完,但未上线的时候,对于 A 功能相关的类进行了更新。

昨天,用户要求对于 A、B 功能进行上线,但不能有其他内容上线。结果:A 功能上线后,


由于修改了某二期内容(已上线)的公用函数,导致原二期系统瘫痪;B 功能上线后,加入
了 B 功能之后开发的代码内容,但是由于 DB 更新没有进行,导致系统报错。

抽象化一下就是:N 久以前,项目组开发了若干个功能(比如 20 个,其中有复杂的公用类


和接口),之后继续进行开发(此时有严格的版本管理),之后,用户要求对于其中的 1,2,
6,8,19 号功能上线,结果上线系统瘫痪,但开发,测试环境的测试过程,是最新的结果,
包括所有功能,没有任何报错。

第 693 页 共 756 页
第 10 章 风险管理

帮忙给个方法吧。

【相关分析】

·一点建议(2007-09-20) [作 者] 一孑 [公 司] 一孑工作室

这个问题应该是比较常见的,在项目开发的过程中,如果项目周期过长,就有有可能出现这样的问题。
首先,版本控制管理工具是一定要有的。
其次,这种问题应该加强整个项目的架构设计,这个很关键,尤其要通过技术线明确接口调用关系,
集成关系等等。如果前期并没有一个良好的架构,那现在应该明确系统内部之间的调用关系,非常重
要。如有必要,可能需要重新考虑系统的底层设计。
再次,应该划分为三个小组,公用组件模块开发小组,一期小组,二期小组,后两个小组与公用组件
小组沟通,由公用开发小组控制项目的相关接口关系,并提供接口发布。理论上在工作安排上,一期
与二期之间不应有关系,如发生关系,此任务应分配到第一小组完成。
最后,一定要加强项目内部管理,明确工作流程,责任明确到人,决不可忽视。

·版本控制的难题(2007-08-30) [作 者] tjh [公 司] cxgs

楼主的项目问题在于将开发管理和产品管理分离开来,或者说没有严格进行产品管理导致

·利用版本控制工作,作好计划(2007-06-02) [作 者] 王廷军 [公 司] 新锐科技发展有限责任公司

根据我以前给华为做项目的经验提供如下:看能否对你有所以帮助。
1、将开发环境和测试环境建立成和生产环境一致(包括后台)。
2、利用版本控制软件,将代码管理起来,如 Vss 等即简单有好用。一旦升级出现问题,可以将最新
版本和最近一次的版本进行比较找出问题的所在。
3、对每次修改的内容点进行严格的 UAT 测试。
4、上线前(包括部分)
,对需要更新的内容整理出清单。包括后台升级的脚本。制定上线计划和恢复
计划,一旦上线出现问题作好应急方案。
5、上线时间点的选择,应该选择在业务不是繁忙的时间点如:下班后或上班前一小时。
做好以上几点,及时有问题也可以做到及时处理。

·最近遇到了一个版本控制的难题,导致多次上线后系统大面积瘫痪。正在进行的项目是一个二期开发项
目,一期、二期在一个同一个环境,目前项目内的工作内容有:对于一期中Bug的修改、更新和对于二期
内容的开发。其中:一期内容和二期内容有很强的关联性;一期内容的Debug结果要求用户方面测试,
测试后及时更新上线;二期开发内容要求分阶段上线。所以结果导致:有时一期Debug结果上线后,影
响二期开发、已上线内容;有时二期开发内容上线后,影响一期内容,或一期Debug上线内容。
(2007-04-29) [作 者] 119922 [公 司] 河北

第 694 页 共 756 页
第 10 章 风险管理

最近遇到了一个版本控制的难题,导致多次上线后系统大面积瘫痪。正在进行的项目是一个二期开发
项目,一期、二期在一个同一个环境,目前项目内的工作内容有:对于一期中 Bug 的修改、更新和
对于二期内容的开发。其中:一期内容和二期内容有很强的关联性;一期内容的 Debug 结果要求用
户方面测试,测试后及时更新上线;二期开发内容要求分阶段上线。所以结果导致:有时一期 Debug
结果上线后,影响二期开发、已上线内容;有时二期开发内容上线后,影响一期内容,或一期 Debug
上线内容。

最常见的头疼问题比如:功能 A 是一期 Debug 结果、两个月前开发完成,近日用户测试完成,A


功能完成后,Debug 开发进程继续。功能 B 是二期功能,一个月前开发完成,二期开发进程继续。在
A 功能开发完,但未上线的时候,对于 A 功能相关的类进行了更新。

昨天,用户要求对于 A、B 功能进行上线,但不能有其他内容上线。结果:A 功能上线后,由于


修改了某二期内容(已上线)的公用函数,导致原二期系统瘫痪;B 功能上线后,加入了 B 功能之后
开发的代码内容,但是由于 DB 更新没有进行,导致系统报错。

抽象化一下就是:N 久以前,项目组开发了若干个功能(比如 20 个,其中有复杂的公用类和接


口),之后继续进行开发(此时有严格的版本管理),之后,用户要求对于其中的 1,2,6,8,19
号功能上线,结果上线系统瘫痪,但开发,测试环境的测试过程,是最新的结果,包括所有功能,没
有任何报错。

·文件的变更控制(2007-02-25) [作 者] HSP [公 司] secret

项目按照原计划开发出了相应的功能模块后,由于各功能模块之间有一定的相互关系,此时经过
Debug 后或者依据客户的要求所作的个别功能模块的改善,一定要考虑到此改善对相关模块的影响并
记录在案,若是影响过大还可采取其他的替代方案,总之,有关改善的文件一定要有明确的记录此改
善的原因影响及效果。

·工程范围问题(2006-11-08) [作 者] 聂建伟 [公 司] 中海油天津渤海石油

若两个工程是事先大家考虑成熟经过风险分析过得。
在实际工作中:若影响不大,可两个经理
若相互牵连,可只设一个经理统管两个小项目。
有没有完备得调试计划,与相互安排,必要时须两个项目协调同时考虑。这需要上层领导涉及了。

·管理流程与执行!(2006-10-05) [作 者] 王丰江 [公 司] 北京华深

加强管理流程的确定!同时在执行过程中进行流程修改!直道完善!

第 695 页 共 756 页
第 10 章 风险管理

·应该加强产品管理(2006-07-14) [作 者] 游永明 [公 司] 广东省计算中心

(刚才按错了,重发)
案例的项目问题在于将开发管理和产品管理分离开来,或者说没有严格进行产品管理导致。
一般来讲开发人员手头会同时拥有两个版本的开发权限, 一个称为 trunk 分支,又叫做功能变化分
支, 一个称为 bugfix 分支, 简单理解, trunk 会有功能的增加, bugfix 没有功能的增加。
案例提到的一期和二期就是 bugfix 分支和 trunk 分支的关系,虽然案例中提到严格的版本管理,我
分析应该仅仅是指开发库的管理,没有涉及产品库。其实我们知道版本库应该包括两个:开发库和产
品库。
案例应该加强的是产品库管理。一期的 bugfix 正常发布,但是二期的发布应该是对一期 bugfix 发布
的一个 merge 才正确。公共库还是统一维护,并且整个作为一条产品线来维护才对。

·应该加强产品管理(2006-07-14) [作 者] 游永明 [公 司] 广东省计算中心

楼主的项目问题在于将开发管理和产品管理分离开来,或者说没有严格进行产品管理导致。

·版本控制的难题(2006-07-13) [作 者] arkingchen [公 司] tn

对公用函数库进行版本区分
一期和二期使用不同版本的公用函数

10.9 如何权衡不同的方案

如何权衡不同的方案

[姓 名] 易风 [单 位] 项目管理者联盟 [邮 件] yifeng@mypm.net
[所属行业] IT 软件 [所属主题] 项目风险管理 [发布时间] 2003-4-26

【案例正文】
白先生是某游戏软件公司总经理,由于目前游戏软件市场竞争激烈,公司的销售受
到了一定的影响,白先生正在考虑实施其他一些方案来提高利润率。现在有四个方
案供选择。

第 696 页 共 756 页
第 10 章 风险管理

1. 集中精力强化目前公司软件开发队伍的力量。该方案需要增加 20%的研究和开
发预算,并将其中的一半用做奖金或其他激励措施,设计和开发人员的积极性将会
大大提高,出来的产品很可能会有缴强的市场竞争力,而且,增加的预算也可以用
来雇佣四位新的高水平设计开发人员。

2. 转向教育软件的开发。教育软件市场与游戏软件市场有完全不同的竞争格局。
教育软件开发的专业性较强,一些很小的公司都能在市场上生存,大多数教育软件
都通过中等规模公司和大型公司分销,也有通过邮购或网上购物将产品送到最终消
费者手里。根据估计,从一无所有到形成教育软件开发能力需要两年时间,约 400
万元投资。

3. 收购一个现有的教育软件公司。目前考虑的目标是一家由三个印度软件程序员
创立的教育软件开发公司,该公司年销售收入 520 万元,其中约 100 万元来自出口
业务,利润率为 20%-25%,高于一般软件企业 18%左右的利润率。而且该公司有很
优秀且廉价的软件设计师。

4. 与现有产业中的某大公司结成战略联盟,该方案将可使公司接触到最先进的技
术,并受益于其强大的分销渠道,但这样也容易使自己失去经营自主权,也不可能
肯定公司董事会对这样的风险抱什么态度。

白先生应该从那些方面来分析这些项目的风险,如何来选择上马哪个项目呢?

【相关分析】

·战略选择(2007-04-27) [作 者] 姚振华 [公 司] 中兴

这个案例确实是一个公司的战略问题,而不能用简单的项目方案选择能分析。项目选择的方法还是可
以提供相应的参考给董事局。

首先要考虑战略方向

其次是考虑机会成本和收益率

从上面的信息,是无法进行一些具体分析的。

·菜鸟(2003-12-12) [作 者] xuaround [公 司] 中铁十八局集团

先需要明白企业董事局对企业短期和长期的期望是什么,企业目前是想发展还是为了渡过难关,明白
了这些,才能提供企业发展方向的思考啊

·JIANYI(2003-08-29) [作 者] 郑云峰 [公 司] AAA

第 697 页 共 756 页
第 10 章 风险管理

这应该算是一个公司的战略发展问题了,首先要明确公司的发展方向,公司现在所在行业以及打算进
入行业的发展趋势、竞争情况,然后根据实际做出决定。我本人倾向于从前三种方案中选择一个,对
于合并,结果很可能是失去主动权。

·JIANYI(2003-08-29) [作 者] 郑云峰 [公 司] AAA

这应该算是一个公司的战略发展问题了,首先要明确公司的发展方向,公司现在所在行业以及打算进
入行业的发展趋势、竞争情况,然后根据实际做出决定。我本人倾向于从前三种方案中选择一个,对
于战略联盟,结果很可能是失去主动权。

·坚守阵地(2003-07-01) [作 者] 廖清平 [公 司] 恒基(中国)

首先必须清楚以下问题:
一、公司的经营方针、目标。
二、有市场就有竞争,有竞争就有风险。
三、盲目做大,不一定能做强。况且进入一个相对的新领域要两年后才能见效果,市场变化本身就很
难预测,风险加大!
四、游戏软件开发的利润率低,必定有人退出;教育软件利润率高,必定有更多人进入;与其随波逐
流,不如坚信“七十二行,行行出状元”。
本人的意见按可选性排序为:
1——3——4——2

·主要是看公司需要明星还是现金牛!(2003-05-13) [作 者] 李俊山 [公 司] UFSOFT

这个案例不错,呵呵,感觉就像是在说我,我这段时间一直在和一家软件公司在联合研发一个无纸化
考试平台,我在这个项目中具体有又重角色,既是用友方的项目经理,又是对方的项目经理!
像这样的项目越是在这样非常时期,越能考验一个项目经理乃至公司高层的战略眼光和水准。
像波士顿矩阵图想必大家都很清楚了,其实道理也很简单,那就是要看你想把你的方案转化成什么,
是明星还是现金牛,还是问题孩子甚至问题孩子,只要你考虑明白了这些,那么我想具体选择哪个方
案,不言而喻了!
chinaerp@china.com

·要在战略管理的框架下解决(2003-05-03) [作 者] 健坤 [公 司] 北京

同意楼上“项目管理”的发言。
案例给出了一些简单的信息,对于需要做出的复杂决策是远远不够的,否则咨询公司就很难活下去了。
企业现在面临的是市场的重新定位,任何一个企业都不可能在所有的领域进行竞争,如何在获得企业
竞争优势的基础上限制企业的竞争范围,这是一个需要在战略管理的框架下解决的问题。
首先需要确定企业的愿景,回答好“我们到底想要成为什么”的问题,这是最难的一部分,需要分析

第 698 页 共 756 页
第 10 章 风险管理

企业核心意识形态、核心价值观、核心目标、预计前景以及形成对前景的有效、详细的描述。
其次是进行企业的内部和外部的分析,方法很多,主要集中在各方面的优势和劣势上。
接下来就可以制定企业的长期目标,进而形成企业的战略。当然还有对战略的执行、评价、控制以及
相应的调整。
理论上我想应该是按照上面的步骤进行的。也可以将制定战略的过程当成一个项目来做,项目管理的
一些基本方法也是很有益的。
具体说到案例中的 4 个选择方案,应该说都是很具体的战术,考虑到不同的风险和环境,每一种都有
可能发生,如果有了较为长远的战略目标作为指导应该更好选择一些。

·如何权衡不同的方案(2003-04-30) [作 者] 项目管理 [公 司] 无

我觉得这已经不是一个简单的项目管理了,而是涉及到公司战略的问题。应该从战略分析的角度入手
考虑,可以使用诸如 SWOT 方法,五力模型包括波士顿模型进行分析。采用专业的战略分析方法,是
最有效屏敝风险的手段。
从我的观点来看,越是选择进入新的行业,进入新市场,这样的行为一定要谨慎,考虑得一定要全面。
而且我不认为这是规避风险,是增加风险。
到于 PM 能起到什么作用,我觉得如果把这次公司战略选择当作一个项目,运用项目管理的方法也能
起到积极的作用。
如果是我,我会先选择和游戏软件相关的游戏行业拓展与加深,如网络游戏等领域。其次才会考虑进
入全新领域。

·有竞争就有风险(2003-04-26) [作 者] 张清俭 [公 司] 大连

根据 PMBOK 的要求,需要编制风险列表,归纳出列表中风险的来源,从而制定风险应对计划.
方案 1:增加了投资,可以强化团队的力量,但市场的竞争一样存在,有竞争就有风险,1 方案只是强化
了自身的力量,采用的风险应对方式是接受风险.
方案 2 和 3 是从游戏软件转向教育软件.转向教育软件,风险应对方式是规避.这也是一种策略,摩托罗
拉不是从电视转向无线通讯产品而获得成功了吗?教育软件的市场准入的门槛很低,也就决定了会有
许多公司参与进来.方案 2 的项目历时长,两年后才能够开发出软件,市场的机会可能会失去,这也是
风险,我选择方案 3,他的风险是能否成功收购和收购后企业文化的融合.
4 的方案风险很明显,失去经营自主权并且董事会还不一定同意.

第 699 页 共 756 页
第 11 章 采购管理

第11章 采购管理

11.1 *供应链成本削减项目陷入僵局

案例提供者:项目管理者联盟会员 张星(zwx520@hotmail.com)

★ 案例正文:

本人所在企业是一家大型家电制造企业,因其流程漫长、供应链烦琐,致使成本较高。
为降低成本,企业特成立一个供应链成本削减项目组,预计在现有成本基础上下降 10%(约
几个亿)。

项目一经确立,便投入大量的人力和精力去实施。由于领导的重视,实施力度很大,调
动各部门第一负责人召了开启动会,并要求每周对执行情况进行汇报,项目进行的轰轰烈烈。

起初效果很明显,各部门都排查了一下以往成本和费用不合理的地方,列出了许多可以
降成本的小项目,一些明显不合理的成本很快就都降了下来。

项目当初定的目标是要在三年之内降几个亿,刚开始一个多月就降了五六千万,效果不
错。可再往下,大家都不知道该怎么干、还要从那里降了。项目陷入了僵局,变成了例行工
作。

领导很着急:这样下去成本肯定下降不了 10%;各项目负责人也很着急:想干,但如
何能保证自己干的事就是项目需要做的事呢,我们到底该干哪些事呢?

项目走到这里,基本已经停滞,或者说离失败差不远了。我根据项目管理的流程来总结
出以下三点:

1、目标不清晰:降低成本 10%,这几个亿如何去实现?怎么分解目标? 项目管理者联盟,项目管理问题。

2、WBS 不明确:项目开始时就要分解好,哪些可行哪些不可行,如何去做等; 本文转自项目管理者联盟

3、供应链成本研究不透,到底那些成本可降?

但现在仔细分析以上三点,没有哪一点是一开始就可以分析清楚的,包括项目执行到现
在也没拉出一个供应链成本的总架构。

请各位有相关经验的项目经理对此项目进行剖析,最重要的是希望您能给点补救措施和
建议。

第 700 页 共 756 页
第 11 章 采购管理

★ 项目管理者联盟专家点评: 项目管理者联盟文章,深入探讨。

专家介绍:卢毅 项目管理者联盟高级顾问 清华大学 MBA,PMP,中国著名的项目管


理实战派培训师和组织级项目管理体系咨询专家,北京商略达项目管理研究中心首席专家,
清华大学特聘教授。美国项目管理协会会员,PMI 认证项目管理专家。历任项目经理、项目
总监、项目实施部门总经理、公司分管项目实施的副总裁等职。亲自管理过数量众多各行业
项目,累计实际参与、管理、负责和监控的实施项目达 60 多个。项目涉及行业包括 IT、电
信、电力、金融、政府、房地产、建筑、制造、流通、物流等多个行业。在项目化经营管理、
组织级项目管理体系规划、项目实施方法论和多项目管理等方面有非常独到的见解和实战经
验。

项目管理者联盟,项目管理问题。

专家点评:

本案例其实需要做两个方面的分析,首先需要分析项目为什么会到这样的状况,其次需
要帮助该项目经理在此状况下给出下一步的行动建议。

下面我分别做一些评述:

先分析该项目为什么会到这样的状况。从该案例的过程介绍看,在中国的项目管理现实
环境下,该项目走到现在是一种必然,原因主要有如下几点:

(1)案例企业为降低成本,成立了一个供应链成本削减项目组,这种做法是非常可取
的。类似这种企业变革,属于典型的项目,采用项目管理模式,确实非常有道理。问题的关
键是,该企业变革没有按项目管理方式做:从案例过程看,不是项目管理的模式,而是传统
的管理方式。

(2)要想成功地做好项目,是需要进行前期策划和可行性论证的,不要匆忙启动一个
项目。在我主讲的《项目管理中国实战潜规则》课程里,我反复强调“项目管理一定要赢在
起点!”,该项目显然没有经过认真细致的前期策划,也没有就在现有成本基础上下降 10%
(约几个亿)是否可行,就比较草率地确立了项目。如果项目在前期就输了,后果就会相当
严重,最后能成功的可能性就非常小了。

第 701 页 共 756 页
第 11 章 采购管理

(3)“项目确立后,不是要急急忙忙制定计划!“这是我强调的另一个观点。如果项目
策划的好还好说一些,如果像案例项目那样没有做细致的前期策划和可行性研究,这种情况
下的项目在中国是比较多见的,这主要是很多企业的项目管理体系没有或很不完善造成的。
我最近一直在讲如何科学合理地构建项目管理体系,也一直在给几家企业做项目管理体系建
设咨询,感觉一些企业明显没有项目确立前的策划和可行性分析管理,上项目比较随意,项
目的目标也不清晰,能否实现也不清楚,往往是走一步看一步。这种情况下,项目确立后,
项目经理拿到项目,不是急着做计划,而是要补做项目策划和可行性分析,和项目干系人沟
通目标是否能实现,这一点比计划重要百倍。

(4)然后,其它的诸如科学的制定计划、严格按计划去执行、对阶段目标进行控制和
验证等项目管理过程和方式,对保证一个项目成功也同样非常重要,我就不展开细说了。
项目管理者联盟,项目管理问题。

现在该案例的项目经理着急的不是前面的分析(虽然这非常重要!),而是想知道在此状
况下在下一步该如何做,我提出几点建议如下(对应前面分析的几点)

本文转自项目管理者联盟

(1)马上组织论证该项目是否还有必要继续。这一点非常重要,项目在执行中,可能
会出现各种情况,我们需要随时分析项目继续执行的条件是否还存在!举个例子说明,把某
一个大项目的销售理解为一个竞标项目的话,你随时需要自己是否已经出局(项目失败)

如果出局,项目当然越早结束越好!如果你分析的结论是出局,项目就应该在此 Game over。

(2)如果论证后认为项目还有必要继续,建议你按我前面分析的思路,重新策划和论
证一下你在目前情况下项目下一阶段,修正本项目后面的目标。记住,一定要赢在起点!

(3)然后就是马上要对供应链进行分析,有必要的话可以考虑请行业业人员和专业咨
询公司做支持,请他们提供行业数据,对你做好项目目标非常重要。我在项目管理培训课上
经常讲到,项目管理是非常好的思维工具和方法,但一定要和行业结合,才能发挥出项目管
理的价值!本案例的“行业知识“就是供应链知识,作为项目经理和项目团队,要完成好供应
链成本削减项目,必须靠自己或外力深刻理解行业知识,否则项目很难成功。

(4)其它关于科学的制定计划、严格按计划去执行、对阶段目标进行控制和验证等我
就不多说了,期望该案例的项目经理能很快行动起来,不要一直看项目过去如何如何,关键
是你现在应该如何!祝你好运!
项目管理者联盟文章,深入探讨。

★ 项目管理者联盟网友评论:

分析 1:一个供应链降成本的项目 刘庆涛 ( liuqingtao2003@tom。com) 项目管理者联盟文

对于国有企业,有很多不透明的东西。首先老总要有全力以赴变革的决心,成本降低是一
个漫长的过程,这是必备的条件。如果具备了此条件,所做的变革成本之路才能进行下去。

1、首先要进行成本分解,成本分解的 WBS 结构,要搞清楚所有的成本都发生在哪些


事项上,每一事项上的成本是多少,也许有些工艺无法分解,可以有一个大概的数据。

第 702 页 共 756 页
第 11 章 采购管理

2、与同行业去横向比较,找出本公司哪些环节成本高,哪些成本低,找出成本优势与
劣势。从原材料采购到加工制作与销售每一个环节都不能放过,找出劣势所在,是工艺效率
低还是管效率低,是否可以考虑把自己劣势外委加工,走专业化道路,做自己擅长的事情。

分析 2:考察市场,落实计划 连甲虎 ( lianjiahu111@163。com)

降低成本是企业长挂在嘴边的问题。需要考虑几点问题:

1、哪些流程可以省略,那些可以简化。 http://bbs.mypm.net

2、通过市场考察,与相关行业比较制定符合实际的降成本计划。

3、制定降成本的近期计划和长远目标,把复杂的问题分阶段解决并对工作做出总结。

分析 3:项目目标一定要务实 王金龙 ( lws1978@126。com)

首先应该分析成本降低 10%是否有根据,是跟社会平均成本相比还是高于这个标准。
对于制造业来说,盲目的通过降低成本来追求利润是不合适的,在如今这个竞争日益激烈的
社会,应该从价值工程的角度分析产品可以从那些方面降低投入。

此外降低成本的初级阶段可能就是贵公司项目组开始做的事情,降低成本就是杜绝浪
费,提高劳动生产率,减少不必要的流程,当然这种工作在单前的技术水平以及管理水平下
也很会达到极限,所以在一段工作之后会觉得步履维艰,做这种工作利用项目管理的基本方
法 wbs(工作分解结构)以及流程图、鱼骨图等方法进行更加精细的分析是必不可少的。

分析 4:项目的实施需要计划 赵永强 ( ronchar_sao@hotmail。com)

目前降的几千万是一些不合理的问题解决,所以感觉一下子出了很大的成就。
项目管理者联盟,项目管理问题。

实际在刚开始作项目时,应该有一个分析(包括头脑风暴),哪些完全可以拿掉,哪些可
以部分降,哪些可以通过改变运作模式的方式降低。。
。。。再做项目时,10%是一个目标,一
个 target,如何实现需要系统的分析与协作。同时也可以把一个项目分解为几个子项目。在
调研分析的基础上进行细化。

分析 5:一个供应链降成本的项目 pengbo (院 pens111@163。com)


1、对于给定的 10%目标,有没有经过合理的论证呢?

2、有没有一个对项目本身研究很透彻的人。

3、对于现阶段,可以请专业的资讯专家进行资讯。

分析 6:一个供应链降成本的项目 易明 (yiming208@gmail。com) http://blog.mypm.net

第 703 页 共 756 页
第 11 章 采购管理

从你的描述来看,对于项目管理前期所存在的问题已经有比较明确的认识,归结一下瓶
颈在三部分:

1、缺乏理论指导,没有合适的供应链理论能够指导你进行成本降解。可以查找一下相
关的资料。

2、没有能够对整个流程存在清醒认识的人才。可以发掘一下,说不定在项目中就能找
到。 本文转自项目管理者联盟

3、可以运用合适的流程管理工具,我用过的是 ARIS,不过只用来描述流程,至于成本
分析和调整还没有使用过,你可以请教相关的专家。

分析 7:一个供应链降成本的项目 朱万海 ( zhuwanhai@163。com)

对于此,我个人想法主要有以下几点:

1、 弄清目标的具体情况, 比如是怎么得出能够降低 10%的成本的?是通过参照同行


业的标准还是经过对本企业的过去经验、资料而得出的数字?是否可行、可实现?需要哪些
部门或者其他辅助来实现?

2、 制定一个滚动波计划, 通过分阶段计划来实现目标,以及根据实际情况修改相应的
实施方案(如短,中,长计划);

3、 监视实施的结果,对比结果与计划, 找出偏差原因以及采取相应措施进行处理;

4、 切实了解供应链业务,找出相应的着眼点,如可以采用新的业务管理系统。

5、 精简机制,减少不必要的流程,并加以记录以及加以详细分析,最好能采用实际的
数据来加以证实精简后的效率。
分析 8:建立企业运作的流程是建立 WBS 的一种形式 daijiangbao ( daijiangbao@hotmail。
com)

在 pmbok2004 版,首次把企业的流程看成是企业的资产,这是一个很大的进步,但是
没有很明确的说明企业流程是如何来建立。

实际上,要想把企业的流程建立好,需要将企业所做的工作,从头到尾按照时间顺序的
排列,划分适当的阶段,在每个阶段涉及到不同地点的公司、部门、人员的什么人、做什么
工作以及如何做、为何做、花费的时间等一系列工作,把这些内容层层分解,自然就会得到
整个工作的流程,针对每一项工作可以知道实际的成本及应该合理的成本,这些成本的差异
就是能降低的成本,这个工作没有做,降低成本就是一个空话,也只能是浮在表面上,就一
些暴露出来的问题解决一部分。

第 704 页 共 756 页
第 11 章 采购管理

在这个工作分析过程中,就可以发现流程中很多的不合理地方,需要把流程全部都梳理
清楚,把不合理的流程加以改正,把中断的流程接起来,在这个基础上来完成降低成本的工
作就有基础了。

这个降低成本的工作,关键还在于 WBS 的建立,而且一定要到一定的层次,魅力在细


节,把这些工作做扎实,降低成本就是顺理成章的事。

可以就一些问题再深入探讨。 http://bbs.mypm.net

分析 9:关注每个项目的流程是否合理,规范流程,降低成本
章毅 ( one_zhang@hotmail。com)

前期你是减少了明显不合理的费用,这只是表面的成本

目前建议你调查项目的流程,从流程中去规范项目,从而降低成本,项目流程清楚了,
供应成本也就清楚了。

第 705 页 共 756 页
第 12 章 多项目管理

第12章 多项目管理

12.1 项目执行过程中强矩阵管理问题

导读:矩阵管理模式也并非只有一种形式,按照矩阵主管的职责不同,矩阵管理模式可以分
为强矩阵和弱矩阵。强矩阵具有许多项目单列式组织的特点,即矩阵主管有相当大的权限,
包括用人权和财务权;比如一些 IT 企业专门成立的项目研发小组,就属于强矩阵的管理模
式。在实行强矩阵管理的时候,项目经理与部门经理对资源的调用与管理是如何细分的?

(一)案例内容:

我们是一家软件公司,公司以前是集团性质,在前几年从集团公司分离出来,以作产品开发
与项目为主,目前公司发展还不错,正在建设的项目五个左右,已经立项的十个左右,已验
收项目并需要继续支持和维护的有二十个左右。

公司试行强矩阵管理,专职的项目经理一个人带几个项目,职能部门也有除了本职工作外担
任项目经理的。公司没有大步伐的扩充,资源问题成了项目经理、部门经理在项目实施过程
中最大的问题,从而又引发出执行流程与职责定位的问题……

项目经理每个人都身兼数职,对项目进度难以控制;多数项目在并行时,资源的调配是由各
个职能部门的经理安排的,职能部门经理对质量监督,项目经理要做进度控制,可是却没有
分配资源的权利。

我的问题是:在实行强矩阵管理的时候,项目经理与部门经理对资源的调用与管理是如何细
分的?

(二)项目管理联盟网友评论:

分析 1:题目:项目执行过程中强矩阵管理问题 项目管理者联盟会员:WDJ

首先明确部门经理和项目经理职责,其次,部门经理需要下放部分资源分配权,同时施行项目
责任制,再者,部门经理的绩效考核主要依据在各项目经理之间的资源协调能力,项目质量监
管能力,项目经理的绩效考核主要依据项目完成质量和数量.

分析 2、题目:实行多项目管理 项目管理者联盟会员:银勇平

项目经理面对的问题应属于多项目管理的问题。要彻底解决这种局面,还是要从公司着手,
在公司内部要实行多项目管理的方法,例如设立项目资源部经理,公司人力资源统一由资源
部经理统一分配,项目所需要的人员要从公共资源库中挑选,再分配到项目中来。由于公司
人员短缺的实际情况,短期的解决方法就是把同一个项目经理负责的项目合并为一个大项

第 706 页 共 756 页
第 12 章 多项目管理

目,每个项目为大项目中的一个子项目,为每个子项目设立优先级,优先级高的有获得资源
的优先权。

分析 3、题目:只是个人一点微薄的意见 项目管理者联盟会员 项目管理者联盟,项目管理问题。

http://bbs.mypm.net

我个人认为,贵公司似乎并不缺少技术型人才,但是确确实实的缺少管理型,领导型人才。
技术型人才的特点是比较自大(我个人也是)且自我感觉良好。当然这也取决于个人的素质。
通过一段时间对于我身边一部分经济或者管理型人才的了解后,我认为,技术型人才对于技
术的了解当然是可以肯定的,但是对于市场,对于经济,对于企业发展的长远战略,对于企
业的规范化管理,认识得远远不够。这就相当于一个专家级问题去询问一个小学生一样。当
然比喻并不恰当,但事实上说明了一个问题,那就是隔行如隔山。
解决的方法,我觉得可以这样尝试一下,请一个专门负责项目进度的经理,不一定要懂技术,
但是要尽职尽责的,由他来负责所有项目的进度,严格按照 schedule 进行。并且在工作中
协调资源的调配。具体的项目由专门的项目经理负责。当然,我认为根据公司的发展状况给
项目制定优先级别也有利于短期的发展。尽量使所有管理人员所涉及的管理方面没有重叠,
这样可以做到责任明确化,调配合理化。这只是我个人的意见,希望大家多多批评和指点

分析 4、题目:我们单位的做法 项目管理者联盟会员:leslielu

我们的做法是这样的,在跨职能部门的项目中,必须每个职能部门要制定负责人跟进特定的
项目。他要对项目经理负责,如果他没有办法协调自己部门的资源满足项目的要求,会由项
目经理提交到职能经理那里。通常情况下,因为这种跨职能部门的项目后面都有一个更大的
老总负责,所以职能部门还是尽量优先项目上的资源的。毕竟我们公司不是所有的工作全是
项目,日常工作一般会为项目让资源,但是结果是谁摊上项目,谁加班。虽然项目经理不直
接考核项目成员,但是职能经理很在乎自己的部门是否在项目中成为拖后腿的部门,所以效
率还是不错。
总的说来,应该有更大的压力在职能经理哪里,项目就可以得到资源。不知道说清楚没有。

分析 5、 题目:项目经理对项目付全责,职能经理付责资源调度 项目管理者联盟会员:
郑承满

在实行强矩阵管理的时候,项目经理的权限应该是比较大的,部门经理更多的是服务的角色,
占有服务的资源,在一个资源池中,项目经理提出资源要求后部门经理派出,项目经理用完
了就归还,项目经理要对项目的进度,成本,质量等付全部责任,解决项目经理无谓占有资
源等问题。

分析 6、题目:坚持流程,坚持职责,坚持绩效 项目管理者联盟会员:杨锋雷 http://bbs.mypm.net

在强矩阵管理模式的组织中,往往各组织在形式上建立了项目经理、软件开发组的岗位和职
责。在执行过程中,也有意识的强调各岗位的分工,但是总是被“资源约束”而不断的打破“职
责的清规戒律”。 项目管理者联盟,项目管理问题。

建议:
1)坚持流程:通过项目管理部(PM)、技术部(技术人员)两个部门从组织上强调流程,

第 707 页 共 756 页
第 12 章 多项目管理

并通过两个组织间的“资源申请”和“资源评价”系统保持流程;
2)坚持职责:在流程过程中,坚持各组织的职责,并可以通过各组织相适应的“考核指标”
引导组织实现自身职责;
3)坚持绩效:绩效应用是流程、职责执行的”保证“,必须坚持。
”说来容易,做来难“,只要有必胜的信念,我们总会有成功的机会的

(三)项目者联盟专家点评

黄绍良,昆山泓森信息科技管理顾问有限公司执行总裁,美国 PMI 资格管理委员会大型项


目管理专业资格认证委员,中国管理科学研究院理事,中国科学院研究生院教授,北航软件
学院特聘教授,南开大学软件学院兼职教授,澳洲墨尔本大学计算机系学士,加拿大约克大
学工商管理硕士;国际项目管理协会,澳大利亚项目管理学会,美国项目管理学会等专业组
织的认证会员,是英国皇家计算机协会,澳大利亚计算机协会,欧盟资讯协会等组织的会员。

家黄绍良点评:

我国大部分企业在推动项目管理的过程中,从没有考虑为项目管理建立一个高效的管理环
境。导致管理流程脱节,带来运营上的瓶颈,更缺乏一套争议提升的流程。所谓“巧妇难为
无米之炊”,项目经理无法发挥科技管理的最终效益,让企业管理成本增加。

在 80 年代中期,我曾经负责美国一家保险公司科技部门的项目管理推广,在最初的一年,
部门高层积极参与,建立一定的管理机制,指派专人负责执行及监控,经历三年的努力才把
管理规范完成,让各人明白本身在部门中的职责及在项目中的角色。资源的职责与角色是成
功推动项目管理的一个关键因素,管理层及部门经理必须明确知道资源如何利用,在那个时
间段负责那个项目的工作。

在强矩阵管理模式下,一个人会参与一个或多个不同的项目,扮演不同的角色,项目经理对
资源的调用及管理只局限在已经组合的成员中。组员本身的不同角色已经成为组员的时间冲
突,最有效的解决办法是高层的决定或项目经理依靠本身的管理及协调能力。

很多时候,资源的冲突主要是项目基线的建设缺乏规范,组员的工作在开始时不明确,项目
经理未能有效管理项目的进度,项目中任何工作上的延误直接影响其他项目的启动和进度。
所以要解决项目经理与部门经理间对资源调配及管理的问题,企业必须建立项目基线的建设
机制,巩固项目经理本身对项目实施的进度管理方法。

所谓项目基线的建设机制包括明确的项目生命周期和合适的开发体系应用,在开发过程中各
阶段的工作量及资源需求(技术、工作范围、责任等)必须明确及合理,这些都应该是立项
的先决条件。
企业高层在确认项目的工作量,时间线,资源需求后,必须按实际的情况在适当的时间段提
供项目经理所需的资源,但往往我们在实施过程中,调派到项目组中的资源多未能符合项目
立项时所要求的数量和技术能力,所以项目经理必须在获得资源后,重新调整项目计划及工
作分派计划,尽量利用已分派的资源考虑项目如何才能够完成交付。建立项目的第一份风险

第 708 页 共 756 页
第 12 章 多项目管理

评估和应变方案。
本文转自项目管理者联盟

重建后的项目计划必须让企业高层确认,有关风险评估及应变方案必须向企业高层汇报。纵
然企业高层否决重建的项目计划,仍然要求项目经理按原计划完成交付,但风险评估将可以
保障项目经理在项目真的受到延误时,让企业高层知道:“我已经告诉了你结果会如何”的一
个引子。 项目管理者联盟,项目管理问题。

但这个机制并不说明项目经理便可以让项目延误,当发现某组员的工作可能受到延误,不能
如期在指定时间释放该组员时,应尽快与该组员的部门经理及等待接收该组员的项目经理进
行沟通,提出有关风险,让其他项目组能够尽早建立应变措施,调整工作计划,或另找其他
资源代替。尽量降低项目组与部门间,或项目组与项目组间的争议。

在实施过程中,项目经理必须不断对计划及工作进行评估,尽量利用项目管理五大变数(范
围,质量,成本,时间,资源)的调整方法对项目进度定期监控,定期进行调整,定期修改
风险评估及应变方案,记录调整后的结果对企业高层进行汇报,保证资源在指定的时间内完
成所交付的工作,在指定的使用期到达时解散资源,让资源投入其他项目,尽量让项目能够
如期完成。

项目经理及部门经理本身职权在企业中有一定的约束,很多时候不一定能够面对上司的压
力,同时应付交付的压力,所以企业必须为项目管理提供一个适合的环境,建立有关的机制
及流程。而项目经理在项目过程中必须让企业高层明白当问题发生时,项目经理所采用的措
施如何降低企业的损失。这个管理环境的建设可以让企业高层明确理解项目管理的真正价
值,慢慢巩固项目经理的职权和提升项目经理的能力。 项目管理者联盟文章,深入探讨。

――黄绍良

第 709 页 共 756 页
第 13 章 项目经理核心能力

第13章 项目经理核心能力

13.1 *项目经理应该为这些问题负责吗?

(一)案例正文

陈伟明是公司的项目经理,在项目 A 筹备阶段就作为项目经理助理参与该项目,项目正式
实施后被公司任命为项目经理。但使陈感到恼火的是:其他职能部门的经理虽然为该项目安
排了时间和人手,但他们更热衷于其他项目。同时陈还被告之不要干涉部门经理对资源的调
度和费用的预算。

半年之后,陈借向公司管理层汇报项目进度的机会向管理层说明了由于职能经理不合作而造
成的项目严重拖期情况,这次汇报引起了公司管理层的注意,他们投入了更多的资源来使项
目回到正常轨道上来,陈伟明不得不花费很多时间来准备文案、报告和投影以及各种各样的
会议。

公司管理层还为陈指定了一个项目经理助理,该助理认为应该通过计算机程序把各种问题程
序化,于是公司又投入了 12 个人来开发这个程序,在花费了巨额资金之后,陈发现这个程
序并不能实现其目标,他向一个软件供应商进行了咨询,得知若要完成该程序,还需要多花
费数倍的资金和两个月的时间,无奈之下,陈只好放弃了该程序。

这个时候项目的情况已经很困难了,项目滞后了 9 个月,但还没有成型的单元完成,客户
对项目拖期问题非常关注,陈不得不花大量时间向客户解释存在的问题和补救计划。

三个月之后,项目仍然没有大的进展,客户开始不耐烦了,尽管陈进行了大量的解释和说明,
但客户仍然不能接受严重拖期,于是指派了一个代表到项目现场监督工作。客户代表要求找
出问题并持续更新,继而试图参与进来解决问题,陈和客户代表在一些问题上产生了激烈的
冲突,导致两人关系恶化。

公司管理层最后撤换了陈伟明,项目 A 在超期一年之后,以预计费用的 140%最终完成。


陈伟明在项目 A 中遇到了很多项目经理都曾经遇到的困难,请你谈谈为什么他被撤换下来,
他应该为这些问题负责吗?

(二)专家点评

王树文 毕业于中南大学,获硕士学位,现就职于广州华南资讯科技有限公司(上市公司),
从事过多个大型项目的开发和管理工作,目前任广州华南资讯科技有限公司软件质量保障总
监,兼任公司 SEPG 执行主席和软件测试部经理。

王树文点评:

第 710 页 共 756 页
第 13 章 项目经理核心能力

问题一:我想陈被撤换下来的主要原因有如下四个方面:
1、 原因之一:项目前期在其他职能部门经理不太配合的情况下,陈不是采用主动、积极的
方式和他们沟通,而是回避问题并在项目进行了半年后才向公司管理层汇报。
2、 原因之二:公司管理层为陈投入了巨额资金开发问题程序化系统但没有成功,陈放弃了
该程序。这件事陈有两处做得不对:(1)在准备投入资金开发问题程序化系统时没有组织
周密的评估(包括必要性评估、价值评估、资金投入评估和风险评估等),导致该工作出现
了严重问题;(2)在投入了巨额资金但没有实现其目标时,陈没有进行周密的分析和请示
公司管理层,而自己决定放弃该程序,导致公司之前的投入白费。
3、在项目严重滞后,客户不得不派人监督项目的情况时,陈并没有采取积极的改进措施(包
括项目组自身工作的改进、请求公司其他资源支持等),而更多地是向客户做解释;
4、 陈和客户代表在一些问题上产生了激烈的冲突,说明陈没有采用有效的方法处理好与客
户的关系。

问题二:陈需要为这些问题负责。因为他是项目经理,而项目经理应该是项目的第一责任人。

(三)项目管理联腽网站评论

分析 1:项目经理的失败 作者:tyminlau

总的来说,项目经理应该为上述问题负责.陈伟明的失败主要有以下的问题:
1.项目进行初期未制定严格的项目计划,造成项目在运作的过程中更改较多,比较随意,对项
目运行中的困难估计不足. 项目管理者联盟文章,深入探讨。

2.该公司的整个运营链不流畅,有十分严重的部门墙存在.而其作为项目经理,和各职能部门
的协调沟通不够,造成公司资源(人力,资金等)的严重浪费.
3.对整个项目的风险防范估计不足,缺乏必要的可行性研究.

分析 2:同意 作者:秦轶 http://blog.mypm.net

从案例的描述信息来看,我同意主要的责任在项目经理。 项目管理者联盟,项目管理问题。

从某种意义上说,项目经理一旦接受了项目,就得承担项目的后果。
在这个案例,虽然存在一些问题,如职能部门的阻力,但这些都是常规性问题。
因此,我认为是项目经理缺乏沟通能力,表现在:
(1)不能与职能部门有效沟通
(2)未充分分析项目的组织环境,未能有效利用高层的支持
(3)将沟通寄托在程序系统上,而不是人

分析 3:项目经理的责任 作者:王海飞

1、但使陈感到恼火的是:其他职能部门的经理虽然为该项目安排了时间和人手,但他们更
热衷于其他项目。同时陈还被告之不要干涉部门经理对资源的调度和费用的预算。此项目得
不到重视, 缺乏沟通——项目得不到重视是公司的问题,但是缺乏沟通、不向上层及时反
映情况,而是默默承受,这就是项目经理的问题了。一个典型的在沉默中灭亡的例子; http://bbs.mypm.net

2、半年之后,陈借向公司管理层汇报项目进度的机会想管理层说明了由于职能经理不合作

第 711 页 共 756 页
第 13 章 项目经理核心能力

而造成的项目严重拖期情况。延误时机;既然发现了问题还不及时解决,半年之后?时间太
长。同时也可以想象在这半年时间里,项目经理工作做得是怎么样了?
3、又投入了 12 个人来开发这个程序,在花费了巨额资金之后,陈发现这个程序并不能实
现其目标,他向一个软件供应商进行了咨询,得知若要完成该程序,还需要多花费数倍的资
金和两个月的时间。
目标不明确是主要原因,事先计划作的肯定很烂。 http://blog.mypm.net

4、三个月之后,项目仍然没有大的进展
补救计划作的很烂,而且缺乏监控,出现了恶果后才发现问题,说明了其项目监控做的之差
此项目的责任如果不归于项目经理,天理难容!!!

分析 4:一个错误 作者:天羽

任命他就是一个错误的开始(恕我直言) 本文转自项目管理者联盟

从文章内容来看,他除了写好报告,就没有别的本事了。一个最开始自己就发现的问题,半
年后才让管理层注视起来,说明作为项目经理的他已经开始走向失败了。他没有承担起“直
言敢谏”的责任。
之后,他又听从于助理的创意,盲从于依靠工具来解救已经下滑的项目,这是又一个乱决策
的责任应该由他来承担。
最后,不检讨自己的责任和失误,和客户代表激烈对抗,已经失去了原谅的机会。
这样的人,以后就不要让他在公司里混下去了。

分析 5:浅析两点:个人与公司 作者:杨文卿

在此项目中,在项目质量、费用控制、时间进度上,陈经理与公司都负有一定的责任:
1、首先,项目的目标并没有得到项目各执行部门的一致关注。
主要原因是公司对该项目的重视程度不足,不然不会有“不要干涉部门经理对资源的调度和
费用的预算。”陈经理的个人负有项目进度执行与总结的职责,但没有实现这一职能;缺乏
有效的沟通手段,严重影响项目的进度。
2、没有经过分析与评审的扩充资金是项目执行中的一种严重浪费。
无论是任何一种项目,在论证初期都应该进行详细的调研与方案的确定,包括各项资源与管
理、监控手段。如果匆忙上马,都将会导致项目质量、费用、时间等方面的严重浪费。
3、项目进度的严重拖期、与客户间不能良好的沟通并解决对以后业务的发展、公司的信誉
都产生严重的影响。 项目管理者联盟文章,深入探讨。

项目拖期 9 个月后,客户已经产生了不满并严重关注进程,甚至派人到现场监督;陈经理
与客户代表的争吵致使矛盾升级,这对于一个项目经理而言都是严重的过失,结果将会是该
公司永久失去这个客户。 http://blog.mypm.net

在项目延期 1 年的过程中,我们可以回顾所有环节所产生的问题:项目执行方案不明确、
项目目标没有得到公司的重视,资源调配权没有交给项目经理,公司对项目进程缺乏有效的
监控手段,项目的执行过程扩大了资金费用,与客户的沟通存在严重的问题......

第 712 页 共 756 页
第 13 章 项目经理核心能力

应该说:陈经理在这个项目中应该承担项目管理责任、费用超支责任、项目拖期责任甚至说
还可能存在的项目质量责任,应该被撤换;公司承担项目调研不充分、没有统一项目目标、
项目缺少监控、盲目扩充资金、没有及时调整项目管理人员的责任。
仅是个人的观点。

分析 6:项目经理就是不要让问题留在自己手里 作者:牛小林 项目管理者联盟文章,深入探讨。

同意大家的分析,其实,我认为项目经理的一个基本素质,可以从另外一个角度来分析,那
就是尽量做到:即使是项目出现了很大的问题,但是跟你个人无关,要做到这一点,需要:
1。充分的沟通,让所有干系人都明白项目的重要性,项目拖延的严重后果。
2。明确项目组成员在项目组内部的职责和使命。
3。在充分沟通的前提下,制定切实可行的项目计划,必须要落实到人,到时间,一定要制
定明确的阶段性可提交成果的标准以及评审标准。
4。通过充分沟通,建立有效的项目汇报及沟通制度,定期向公司高层递送项目存在的问题
和解决情况,以及需要公司层面帮助解决的问题,以及各个问题不能及时解决的后果。
5。根据项目的周期和特性,制定项目跟踪和监控的时间粒度,对项目进行有效的监控,当
项目进度发生偏差时,在可控的范围内及时将你认为不可控制的风险,汇报给高层,并敦促
高层解决问题。

如果你做到了以上几点,我想即使项目有问题,也不是你的问题了,换言之,如果项目出现
的问题,都是你提前预警了,并且提出了解决办法,但是即使上升到总经理那里也没有办法,
你是不会承担任何责任的,但是,如果出现的问题,你没有及时通知高层,或者没有及时采
取必要的措施,那一定是你的责任。
项目管理者联盟,项目管理问题。

分析 7:项目经理的责任 作者:孤独剑

作为一名项目经理应该对自己可利用的资源,包括会受到那些人的支持和阻碍. 项目管理者联盟文章,深入探讨。

陈所范错误:
一、不善于沟通。从陈被告之不要干涉部门经理对资源的调度和费用的预算和和客户代表在
一些问题上产生了激烈的冲突,导致两人关系恶化两件事上可见一斑。
二、没有威信,缺乏组织领导能力。为什么分配给陈的人手不愿做陈的项目,说明他没有威
信,缺乏组织领导能力。
三、没有项目管理意识。作为一名项目经理在做项目之前肯定要对项目进行统一规划,以便
控制项目的进度。虽然文中没有谈到陈有无做计划,但从当助理推荐开发计算程序把问题程
序化时,陈等到程序无法进行下去才去向有关公司咨询就说明他做事没有详细的计划。如果
他是在开发程序之前就已经做了咨询肯定就不会对程序进行开发,也就节约了资金。

分析 8:到底什么是项目管理 作者:lingjie http://blog.mypm.net

http://blog.mypm.net

对于项目经理是否有项目管理的经验这一点来说,每个公司都会存在把没有项目管理经验的
技术人员拉到项目经理的位置。这是客观存在的问题,因为对于公司来说不可能在每个项目
中都配备一个项目管理高手。对于被提为项目经理的技术人员这其实是一个很好的锻炼机
会。但是做好项目管理并不是管着下面的人做就可以的。

第 713 页 共 756 页
第 13 章 项目经理核心能力

在这个案例中,陈并不具备项目管理的能力,并不是说他没有管理过项目就没有这样的能力,
只是在整个项目中他的表现体现出来的:
http://blog.mypm.net

1、其他职能部门的经理虽然为该项目安排了时间和人手,但他们更热衷于其他项目。同时
陈还被告之不要干涉部门经理对资源的调度和费用的预算。在这样的情况下,陈应该学会沟
通,对于项目经理来说的确不能去干涉其他部门的资源调度,但是项目经理要做到的并不是
去干涉,而是去协调。使其他部门的资源更好的为自己的项目组所用。

2、在出现上面问题的情况下,陈没有及时的向上层领导反映,半年一次的汇报对于一个项
目来说时间间隔过于长了,项目经理应该让上层领导时刻了解项目的进展情况,对于项目情
况的汇报应每周提交相关的项目状态报告。有的公司会配备高级经理监管项目,那项目经理
就应该每周提交项目状态给高级经理,如果说项目经理的汇报途径是公司领导,那么就应该
提交给公司领导,这样才能让领导详细的了解这个项目的情况。

3、陈这个项目经理太依赖与助理,公司配备的助理是协助项目经理管理项目的,他提出的
意见项目经理应该有选择的接纳,怎么能在没有风险、成本等预估的情况下就采用了助理的
意见呢?这就是项目经理的失职。项目经理在项目过程中需要对项目有全面的管理,全面的
计划中要涉及项目管理的 9 大方面的规划。虽然文中没有提到该项目经理是否有制订计划,
但综观全文,个人觉得该项目经理就算有制订计划,也不是全面的计划。

4、在沟通方面陈是做的最糟糕的,在这个环节是最失败的。沟通也是一种学问,要是连起
码的沟通都无法做到,动不动就与其他部门或则是客户代表发生冲突,那这个人就不是一个
好的项目经理。
撤换陈是正确的做法。陈应该自己反省一下。
http://blog.mypm.net

对于公司的管理层来说,也存在了对项目关注不够的问题,但是对于项目经理来说不能过多
的要求公司领导主动的来关注你的仙姑,而是要你自己主动的去让领导关注。

分析 9:观点 作者:李冯

"在此项目中,在项目质量、费用控制、时间进度上,陈经理与公司都负有一定的责任:
http://blog.mypm.net

1、首先,项目的目标并没有得到项目各执行部门的一致关注。
主要原因是公司对该项目的重视程度不足,不然不会有“不要干涉部门经理对资源的调度和
费用的预算。”陈经理的个人负有项目进度执行与总结的职责,但没有实现这一职能;缺乏
有效的沟通手段,严重影响项目的进度。

2、没有经过分析与评审的扩充资金是项目执行中的一种严重浪费。
无论是任何一种项目,在论证初期都应该进行详细的调研与方案的确定,包括各项资源与管
理、监控手段。如果匆忙上马,都将会导致项目质量、费用、时间等方面的严重浪费。

3、项目进度的严重拖期、与客户间不能良好的沟通并解决对以后业务的发展、公司的信誉
都产生严重的影响。

第 714 页 共 756 页
第 13 章 项目经理核心能力

项目拖期 9 个月后,客户已经产生了不满并严重关注进程,甚至派人到现场监督;陈经理与
客户代表的争吵致使矛盾升级,这对于一个项目经理而言都是严重的过失,结果将会是该公
司永久失去这个客户。
http://blog.mypm.net

在项目延期 1 年的过程中,我们可以回顾所有环节所产生的问题:项目执行方案不明确、项
目目标没有得到公司的重视,资源调配权没有交给项目经理,公司对项目进程缺乏有效的监
控手段,项目的执行过程扩大了资金费用,与客户的沟通存在严重的问题......

应该说:陈经理在这个项目中应该承担项目管理责任、费用超支责任、项目拖期责任甚至说
还可能存在的项目质量责任,应该被撤换;公司承担项目调研不充分、没有统一项目目标、
项目缺少监控、盲目扩充资金、没有及时调整项目管理人员的责任。"
我同意您的观点

分析 10:沟通出现问题 作者:许春飞

个人觉得项目出现问题在于沟通问题: 本文转自项目管理者联盟

1、没有及时向上级管理者汇报项目的问题,并获得上机管理者的支持;
2、没有增强团队的凝聚力,内部不团结。
3、项目经理的经验没有达到管理这个项目的程度。
4、项目管理团队在新增项目上没有进行充分的变更管理;
5、没有和客户保持紧密的联系,没有发挥客户的积极作用;
6、项目经理缺乏扭转乾坤的能力。
我觉得项目经理应该为项目失败负责,他没有正确的完成项目的有效计划、跟踪、控制及外
围沟通;在需求变更方面做的太差。

分析 11:发现问题就要及时的解决 作者:姜世伟

在本案例中项目经理的败笔有三:
第一:缺乏有效的沟通,没有发挥项目资源的最大效用。
作为一个项目经理,首先要明确你这个项目所拥有的资源,并努力发挥资源的最大效用。在本
案例中项目经理由于没能与职能部门 的经理进行很好的沟通而导致人力资源的效用没能完
全的发挥。
第二:盲目的引进新的管理工具,没有做好可行性分析。
当公司派来的助理经理说需要开发一个程序时,陈立即就同意了,当发现问题时,才向软件
供应商咨询,而此时大量的时间和资源成本都已经形成了。
第三:缺乏与客户合作的能力,不能刚柔相济。
在项目出现了诸多问题时,客户派来代表参与项目,陈却与代表发生了激烈的冲突,导致了
两人关系恶化。其结果只能是公司对项目组更加的不信任。

分析 12:从公司、客户和职能部门的角度来分析 作者:王勇

第 715 页 共 756 页
第 13 章 项目经理核心能力

这个项目经理应该承担责任。
现我从公司管理层,客户,职能部门的角度来分析此问题。
首先,从公司管理层的角度来看此问题。
陈伟明是公司的项目经理,在项目 A 筹备阶段就作为项目经理助理参与该项目,项目正式实
施后被公司任命为项目经理。以及后面的公司指定项目助理;投入 12 人来开发程序解决问
题;等等细节可以看出公司对陈伟明比较重视,也可以说是培养他。

可惜的是他没有抓住机会并出现了一下问题:

a.沟通协调不强,在项目中遇到了资源问题不能自行解决。(但使陈感到恼火的是:其他职
能部门的经理虽然为该项目安排了时间和人手,但他们更热衷于其他项目。同时陈还被告之
不要干涉部门经理对资源的调度和费用的预算。)[/i]
b.判断不果断,居然发现了问题,拖上半年才汇报。[i]半年之后,陈借向公司管理层汇报
项目进度的机会想管理层说明了由于职能经理不合作而造成的项目严重拖期情况
c.决策不够谨慎。尽管有通过创新解决问题的愿望,但是在具体执行的时候,选择了错误的
时间,和错误的方式。 本文转自项目管理者联盟

d.不能勇于承担责任。出现问题的时候责怪职能部门,埋怨项目助理以及客户。
e.在和客户争执是不能妥善处理,使得矛盾更加激化。导致客户意见很大并投诉 项目管理者联盟,项目管理问题。

综上所述,陈伟明不适合该项目经理的职位,建议换人。

其次,从客户的角度来分析问题。

1.该单位不能够满足我方的项目进度要求,该项目经理的能力是否有问题?
2.在该项目不能按照计划完成时,我方派人督促,该项目经理不尊重我方代表建议,是否沟
通能力不行。
考虑到上面两点,为了保证我方的利益不受到进一步的损失以及项目完成,我方应该尽快向
施工方提出更换项目经理的要求。
最后,从职能部门角度来分析问题。
1.我们手上一大堆项目要做,要安排人员和时间。这些项目那些重要那些不重要,从领导的
态度里面就可以看出来。
陈伟明没有办法让领导重视这个项目,光和我们嚷嚷要安排了时间和人手。不忙的时候可以
满足他,如果遇到项目优先级冲突的时候,那只有丢卒保车了。
2.陈伟明用公司高层压人。项目急,陈伟明不早点说,现在却通过领导压人。以后还怎么合
作。
上面是我从公司、客户和职能部们这三个角度对楼主提出的问题作出的分析。

分析 13:项目经理应该对项目全权负责 作者:guoweizhu

作为项目经理,应该对项目全权负责。
1。总的来说,陈在项目的风险管理和成本管理上做的不够。作为项目经理在做一新项目启
动阶段要做好三件事:项目建议书(技术可行性分析),项目投资申请报告(经济可行性分
析),项目计划。显然陈在项目之初,这三方面做的不够,或者说其公司的项目管理体制/
程序不完善。

第 716 页 共 756 页
第 13 章 项目经理核心能力

2。一开始就应该做好项目计划,并不断更新,而且每周进行项目例会跟踪项目进度,在项
目的每个关键时间接点(Milestone)做项目评审(有 Top Management 参与),从 Q(质量)
C(成本)D(进度)三个方面进行审核。这样其他职能部门经理也好对部门员工做好统筹安
排,如果职能部门经理不配合,在评审会议上就及时提出,不至于影响项目进度。

3。成本管理对于项目管理来说很重要,因为作为老板或客户关心的就是利润。在项目投资
申请报告得到管理层批准后,在项目实施时,不断对每个阶段成本进行记录跟踪,额外投资
或成本超标至一定程度必须要进行充分的分析,严格的审核。这样就不会出现助理花巨额资
金开发程序又未成。
4。从某种角度来看,项目经理也是客户代表,显然陈在一开始就忽略了客户的利益。另外,
项目经理在对客户谈判时,又代表的是公司,与客户关系恶化当然不应该。
以上是我个人从事三年项目管理以来的一点拙见,说起来简单,实施的时候肯定有很多阻力。

分析 14:项目经理应负绝大部分责任 作者:Henry

值得注意的是陈伟明在此项目进行中间角色进行过转换,由一开始的项目经理助理(筹备阶
段)变为项目经理(正式实施阶段)。但他事实上没有完成这个角色的转换,从整个过程来
看,他只应该是一名合适的项目经理助理。

1.他对项目正式实施前没有明确的计划(包括团队组建、实施计划、项目目标/范围、成本控
制),缺乏与项目干系人的共同沟通交流,导致初期公司高层/各部门经理没有形成统一的认
识,明确目标;在发现资源支持问题后,没有及时暴露该风险,导致项目在这种情况下运行
了半年之久,好的开始等于成功的一半,这样的开始导致项目比较被动。

2.缺乏对项目的整体把握/控制能力,在项目滞后的情况下,仍然花费巨大的人力/财力 /时
间去做一件不是必须解决的工作—项目问题程序化。本末倒置,超出了项目范围。没有及时
将已经偏离正常运行轨道的项目运转拉入正轨。
本文转自项目管理者联盟

3.在项目滞后 1 年多,客户实施干预时,他仍旧花了大量的时间进行解释和说明,这是一种
治标不治本的做法,纸里包不住火,必然使得矛盾激化。从此案例未看出,项目经理与客户
建立沟通交流体系。

13.2 *公司拖欠项目提成问题

(一)案例正文

公司拖欠项目提成,员工工作效率降低

我们公司是专业的网站项目建设公司,薪酬制度是按照低薪+项目提成的形式。最近一段时
间,公司因尝试转型而导致业务量减少,一时间资金周转有困难,结果造成部分员工的项目
提成无法按时发放,甚至拖欠几个月的时间。可以想象,员工们的工作积极性肯定会受到很
大打击的,工作效率也大打折扣了。

第 717 页 共 756 页
第 13 章 项目经理核心能力

作为项目管理,保证项目按时、保质完成是公司赋予我的职责,我必须保证完成,但面对成
员这样低落的情绪,有什么办法可以让他们重新回到正轨上来呢?我知道公司可能在一段时
间内都是处于资金紧张的处境的了,可如此下去员工的低情绪造成的低效率,只会形成恶性
循环,有什么办法可以解决呢?

(二)专家点评

点评专家 卢毅 清华大学 MBA,PMP 清华大学 MBA,PMP,现任合力金桥软件公司副


总裁。卢毅先生有十多年项目管理实战经验,亲自管理过几千万级的电信行业项目、几百万
级的多个电力行业项目和众多的生产制造、流通、物流等行业项目。历任项目经理、项目总
监、项目实施部门的总经理、公司分管项目实施的副总裁等职,在项目实施方法论、多项目
管理和建立公司级项目管理体系等方面有非常独到的见解和实战经验。

卢毅点评:

这个案例里边的项目经理,可以说确实比较难办了。保证项目按时、保质完成是项目经理的
义务,但给项目组成员按约定给付报酬的权力却没有赋予项目经理。这个案例反映了中国项
目经理普遍的权利义务不对等的现实,也有一些客观现实的因素。本案例信息太少,不是特
别好发表评论,我仅提供一些解决问题的思路:

(1)项目角度:公司虽然资金紧张,但如果需要持续发展,更需要确保现有项目的按时按
质完成,可以考虑让领导为单个项目核算(设立专项资金),尤其是一些要重点考虑的项目。
由于转型,一些不重要和赢利不大的属于原来业务领域的项目可以考虑一些舍弃。

(2)人员角度:业务量减少,资金周转有问题,说明人员可能有些过剩(案例信息不充分,
很有可能),可以考虑优先保证一些骨干员工的方法。其他富余人员可以结清财务以后待业
或离开。看目前全部人员留下来,包袱会越来越重。

(3)前景判断:如果大家认为转型前景乐观,可以劝大家先暂时牺牲个人利益,与公司共
度难关,更需要唤起大家的工作情绪,共同迎接未来。如果大家认为转型前景不乐观,选择
离开又何尝不是一种解脱。

(三)项目管理者联盟网友评论

分析 1:这是一个比较现实的困难 作者:陈军辉

首先你们的公司在制定分配制度的时候是为了鼓励员工,同时也为了分散风险,当公司出现
财务短期周转失灵时员工应支持公司,作为项目经理应首先做好职员的思想工作,让大家知
道现在公司所处的环境,但要协调上级尽快解决并给予承诺并阶段性兑现承诺

分析 2:这是很多小型公司常见的现象 作者:zhou

第 718 页 共 756 页
第 13 章 项目经理核心能力

目前状态:
1、公司前期是做网站项目建设的,应该还会有一部份新的客户源,也就有它的利润所在;
同时也有一部份的旧客户需要一定的维护,也就要有它的责任所在。
2、公司因尝试转型,应该是有很好的理想发展方向,前期急需各种资源的投入。

我觉得:
1、项目管理者可以招开全员动员大会。主要目的是,将公司的员工进行分工,可分成二部
份,一部份(可较少)主要负责公司原有的业务;另一部份主要负责公司新的业务。我建议,
可以先让员工自我定位,然后再项目管理者对(少量)人员的变动。
2、管理者还需要对这二部份人都分别进行思想上的沟通。
3、薪酬制度也需要分别对待。
4、项目管理者从负责公司原有业务的员工中,选出一位负责人来管理旧业务;然后将大部
分的资源和精力投入新的业务开展中,因为一个项目的前期,作为项目管理者应该多投入精
力。 项目管理者联盟文章,深入探讨。

项目管理者联盟文章,深入探讨。

分析 3:项目风险 作者:孙先平

仅从项目的角度来看,这可以被认为是个项目的巨大风险:
项目经理既要考虑到项目成员的利益保障,又要考虑到作为一个项目经理,一个项目的成功
运作.
从项目成员的利益上来讲,项目经理应当为成员争取这样利益;从项目的运作上来讲,要注
意团队氛围对成员心态和工作的影响.

分析 4:沟通最重要 作者:SP

我认为出现这种情况,沟通是最重要的。 项目管理者联盟,项目管理问题。

首先要和下属沟通,尽量让他们理解公司的困难,激励他们努力为公司渡过难关。同时也要
和领导沟通,不能忽视了项目成员的利益,毕竟没有得到应得的收益,激励起来的工作激情
也很难持久!

分析 5:沟通是第一位的 作者:汤江南

作为项目经理,遇到这种情况的确是非常恼火的。你应该首先在公司领导面前提出直接和员
工沟通的建议,尤其是公司高层领导,他们的姿态比你的姿态重要。楼上的朋友们的建议非
常中肯,的确应该多沟通。
其次,你要调整一下进度、计划。获得领导对这个项目的认可。
第三,调整一下自己的情绪,不要让员工经常聚集在一起讨论这样的事,让他们忙起来。
最后,我建议你评估一下公司领导的人品,如果领导是一个守信的人,你可以和员工下一些
保证,如果领导平时就不守信,你也趁早别干了。

分析 6:尽快发现问题 作者:梁桢

首先,笔者也知道如此下去会导致“恶性循环”,对于公司管理层来说不解决资金问题绝对会
影响正常运作。

第 719 页 共 756 页
第 13 章 项目经理核心能力

其次,作为项目管理者来说如何确保团队的团结,如何共渡难关是个很关键的问题。我个人
观点是这完全靠个人魅力,而不是公司政策、薪酬体系,奖惩机制可以做到的。
再次,尽快业务量的下降的原因,可能是技术含量不够,可能是商务缺陷,可能是市场定位
错误。从项目管理者来说更应该关注技术和项目实施过程中客户的感受,以便获取现有客户
的二次开发合同。 http://bbs.mypm.net

最后,建议尽快解决历史遗留问题;正确对待当前在执行的项目不产生新的拖欠问题。对于
业务量不多的情况也许公司该调整市场策略。 项目管理者联盟文章,深入探讨。

分析 7:尽快找一个合适的解决方案 作者:严长洪

第一:你必须先做员工的思想工作,还有就是旧客户中的资料。
第二:拉拢新客户的关系,服务好旧客户的产品。
第三:尽快的找到一个合适的方法,使员工的利气树立起来:1。你可以给公司员工说明现
在公司的壮况,现在所处在的环境。2。还可以进一步的说,只要员工现在可以共度难关的,
到时公司给一定的利润给他,古人说的好:远水救不了近火。现在就是这个情况。
第四:不要让大量的员工有许多的空时间,要让员工有事可做。
第五:这点也是最重要的,利用这个机会发现问题,找出问题,整顿问题。反思一下,自已
这次的事情是错在哪里?我记得领导教训下有这么一句:“事情做错了不要紧关键是要知道
自已错在哪里?”
第六:使用其它的办法看下可不可以找到其它的方法:怎样才可以利用资金,使用这个局面
缓解一下。

分析 8:人员分析 作者:车山根

在这种情况下,沟通是很起作用的。
怎么沟通呢?
一:自己是项目管理人员要主动找领导讨论,得出有什么地方可以给员工补充这方面的不足,
要单独找员工让他们感到你和他们是一样的,让他们知道他们是公司的一部分,情感和理由
并在。
二:员工内部的沟通,不能让他们有太多的时间在一起聊天,因为这样很容易才生共鸣。可
以给他们去找业务,这样又可能提高业绩,也可以让他们接触自己同事的机会大大减小,但
员工业务的薪水这方面公司不能拖欠。

分析 9:正视问题,提出具体解决措施 作者:fuju

这个问题,直接会造成项目团队的信任危机,而信任,是项目团队内部协作的基础,也是公司
(项目所依附的组织)正常运做的基础.作为项目经理,应该和整个团队在利益和立场上保持
一致,并由项目经理出面要求公司针对上述问题提出具体的解决措施,以保持项目经理的权
威性,维护好团队内部的协作基础-信任关系,只有这样才能保证整个团队在项目经理的领导
下,实现项目目标。需要明确的是,沟通不是目的,只是方法,只有拿出切实可行的措施来,才能
保证沟通的成功,毕竟社会是现实的.
一句话,要把矛盾转化为团队的外部矛盾,尤其是不能内部消化的矛盾.为项目经理的抉择留
有最大限度的余地。

第 720 页 共 756 页
第 13 章 项目经理核心能力

项目团队作为一种临时性的组织,保障其成员的正当权益,作为团队的 LEADER,项目经理是
有义不容辞的责任. 项目管理者联盟,项目管理问题。

分析 10:综合一下,我也受益非浅 作者:韩宏元

一,成员的利益要照顾到
二,与成员在感情上不能产生被排斥的状态
三,项目经理不是万能的--帮助领导层损害成员利润
四,重在上下沟通,项目经理扮演的是中间人的角色
五,项目经理应该起到团结部下的作用,当团队的外界环境很恶劣的时候,仍然能维持团队
的正常工作,但肯定要有承诺保障
六,毕竟公司是个大环境,大环境不好,团队的工作肯定受影响的,所以项目经理应该让高
层认识到问题的严重性。
七,不如项目经理不要计较个人利益,自己出点儿血让成员感受到他们头的关怀,从感情上
也会支持你把工作完成好,日后公司度过难关后,你也会有很大的收获。未必吃亏,看好了,
是未必!(操作的好,还可以增加不少个人魅力,操作不好人家会认为你故意收买人心,公
司高层要是小肚鸡肠还可能认为你趁机培植自己的人)

分析 11:回复 作者:bomber

仔细分析这类情况在项目中是经常发生的,提成只是一方面的因素,导致士气不高的因素还
很多。
首先项目经理在与高层沟通后还有继续做下去的信心时提供几点供参考。
1、并不是每个成员都是为了提成而参加项目的。
2、除了提成外项目成功后公司能提供什么非物质奖励?嘉奖、提职、培训等等?
3、除了公司内部收益外项目成功后团队成员能有什么非物质性的收获?项目的经历、经验、
新技术的掌握队成员今后跳槽有无帮助?
4、诼个分析沟通后项目经理该清楚各成员的初步心态了,鼓励为主,碰到实在不想干的,
叫他自己提出来离开项目组,告诉他们:想做的就好好做、不想做的就走人。
5、项目建设中很重要的一点就是项目经理要去发现、引导:项目干系人的共同兴趣、共同
利益!
祝你早日走出困境!

13.3 *项目经理对技术是外行,如何掌控?

(一)案例正文

项目经理 A,在公司有一定的亲和力,被领导和同事看成比较有能力的人,负责实施过很多
的项目,有不错的项目经验:近期被安排一个软件项目,但是 A 对软件开发不懂,甚至开
发流程都不了解,他该如何行使项目经理的职责,把这个软件项目执行好呢?关键的问题是

第 721 页 共 756 页
第 13 章 项目经理核心能力

他不懂技术。
问题:

他该如何领导项目团队?如何掌握项目进度?如何针对项目中的技术问题做指导?在与用
户沟通的过程中,如何让用户对自己的位置表示认可?

点评专家:黄绍良 MBA, MACS, PMP, RPM, CPM, MCEPIS;毕业于澳洲墨尔本大学


计算机系学士,后在加拿大约克大学获得 工商管理硕士。曾任职多家信息科技公司, 包括
国卫保险、美国友邦数据中心、迪吉多、天腾计算机、澳大利亚新西兰银行集团、优利系统、
惠普、加拿大贝尔电话公司、满地可银行等跨国企业。分别在澳洲,德国,英国,新加坡,
马来西亚,香港,台湾,中国,美国, 加拿大等地担任高层职位。

黄先生有丰富的组织,管理,营销,业务支援,软件开发, 科技策略,咨询顾问等经验。
更有超过二十年的国际项目管理经验,在国内曾经负责的项目包括中国民航管理局计算机中
心,国航票务系统,邮电局储蓄系统、和香港证卷交易所的期货交易和结算系统。

(二)专家点评

黄绍良点评:项目经理最大的挑战并不是曾经做过那些项目,最大的挑战是如何管理一个从
没有做过的项目,这是项目管理能力的最大考验。但这并不代表被分派去负责一个技术性相
当高,而项目经理对这方面的技术却一点都不懂的项目。任何领导都知道这个任命下达后对
项目本身会带来多大的风险!

当一个项目经理被调派去管理一个技术性相当高的项目的时候,而本身对这项目的技术一点
都不懂,这种情况通常有两个原因,其一是领导想考验项目经理能力的极限,准备在项目完
成后授以更高的职务并赋以重任;另一个原因是单位领导正在找借口让这项目经理自动选择
离职,或在项目失败后有一个“替罪羔羊”。不管是那一种原因,这名项目经理必须小心处理
这个任务,更需知道如何保护自己。这时候,“项目管理知识”和“软能力”将是这名项目经理
唯一的依靠。

项目启动阶段
项目经理在这种情况下必须在第一时间找一名可以信赖和依靠的技术总监负责技术方面的
审定工作及对项目组成员执行技术指导。在项目启动后,项目经理将透过这名技术总监建立
项目的开发流程,并从技术总监口中理解开发流程中每一个阶段的工作内容和技术需求。

技术总监亦需为项目经理建立项目的 WBS,最终交付,及明确的项目范围,否则将严重影
响项目进度监控的能力。
如何选择项目组成员,谁比较合适?如果可以提供所需的技术人员技能需求,让领导为项目
调派所需的成员,那么在确认工作人员名单及理解各组员的技术能力后,便可以开始建立项
目基线。

第 722 页 共 756 页
第 13 章 项目经理核心能力

在建立项目基线的时候,项目经理宜采用“从下至上”的工作量评估方式,同时让技术总监进
行评审。避免技术人员提供不合理的工作量及工期。完成这些工作后便可以制定项目计划及
时间表。

工作分派 项目管理者联盟文章,深入探讨。

在进行工作分派的时候,项目经理必须能够把技术总监对各流程及内容的说明明确地传达给
技术人员,以保证技术人员能够按照技术总监的思维执行技术实现代工作。亦可在工作分派
过程中委托技术总监对各组员的工作进行说明(但必须保证自己在场,以理解各组员的责任
及交付,并保证自己能够知道谁负责那部分的技术工作。

如果单位本身没有一套项目管理体系,那么项目失败的风险将会大幅度提升。如果单位已经
有一套完整的项目管理模式,那么进度监控,范围变动,风险管理及成本管理将会受到原有
规范的控制。否则将需要有足够的时间建立一套所需的管理模式,但项目经理本身必须知道
自己需要管理什么,更需要知道在项目实施过程中需要那些信息,并让项目组员依时提供所
需的信息进行状态分析。

会议记要
比较重要的一环便是保证任何会议必须提供会议记要,不管项目经理本身是否参加该会议,
但可以从会议记要中理解各组成员及项目过程中所涉及并曾经讨论过的问题。这是项目经理
学习的部分内容。

在这种项目实施过程中,项目经理更宜多聆听,记录及事后多进行学习,研究和分析。最理
想到导师将是你的技术总监。如果你不能够相信你的技术总监,那么这个项目将失控,注定
失败。所以在启动前必须有一个可以信赖及依靠的技术总监。万一在启动前没有一个可以信
赖的技术总监,那么我将建议开始找寻新出路。因为这个项目的成功因素并不是项目管理的
知识,成功与否完全取决于单位本身是否有一个成熟的项目管理环境,和项目经理本身用人
的能力,组织资源的能力,协调能力,说服别人(包括领导,同事,属下,最终用户)的能
力和本身的领导力。

(三)项目管理者联盟网友评论

分析 1:我的意见 作 者:Alan
建议找一个团队中较为资深的程序员,做为开发经理,负责开发流程方面的设计、及对客户
需要的引导,直至形成最终的双方认可的质量标准
您的问题已经覆盖了项目管理的大多数内容了,简单的说,作为非应用领域的专家,只能去
用好人,当然,在启动的时候要有良好的沟通管理计划,什么事情汇报到什么人,减少在技
术方面与程序员的直接沟通。

分析 2:向毛泽东学习 作 者:daijiangbao
pmbok 不容易看透该问题,建议去深入研究中国版的 pmbok-毛泽东选集,尤其是第一
卷。
毛泽东戎马一生,确是个连枪都不会打的人,也就是说不懂一点技术的项目经理,但没有人
说毛泽东的项目不成功。

第 723 页 共 756 页
第 13 章 项目经理核心能力

至于为什么毛泽东思想就是项目管理,从 pmbok 的观点认真看明白了就清楚了。


另外就是,软件工程不是软件项目,有极大的本质差别,尤其不能选择时髦的垃圾-采用迭
代的方式进行开发,是完全有悖于 pmbok 和毛泽东思想的。

分析 3:我的建议 作 者:储知君
跨行业主持项目虽然是非常困难的事情,可是这也是成为优秀项目经理的必经之路!
首先,在开始项目之前,要了解项目小组中的技术专家;了解内容很多,比如他们最擅长的
技术,他们各自的个性和工作态度,他们的喜好等,总之要尽快将手下的技术方面的干将摸
透;
其次,在知己知彼的前提下,采用相应的方法以收其心,彼之所欲,我先予之;不愁此猛将
不为己出力,有技术专家忠心效力,还愁自己不懂技术吗?
其实说到底,就是要知人善任,懂得沟通,懂得如何激励手下能人倾力而为!

分析 4:需求支持 作 者:chiao
对目前的软件环境来说,技术外行做项目经理很难。但不是不可能。首先得有强有力的支持,
高层的。如何让下面的也证实项目经理的存在呢,对开发流程不能不熟悉,这个是最起码的
要求。
然后要有好的开发经理或是系统工程师的支持,项目基本上可以运转起来。
其次就是项目经理要做好整个项目间的沟通交流等。

分析 5:信心和学习 作 者:相乡
本来不敢说什么的,因为我也是非技术人员做项目管理。
不过,还是说几句个人的感受吧,供借鉴。
前面几个都提到了知人善任,这个当然很重要。案例中的这个项目经理当事人和安排他的领
导应该也会考虑到此事。
我觉得,首先要有一种信心,因为即便是技术人员,他也很难在所有的模块都很精通,所以
相信自己不比其他的项目经理欠缺太多。因为项目经理的技术水平不够的失败项目案例目前
还很少。
其次是不断学习,努力去学习,你会学到越来越多的项目管理者所需要的管理知识。把握好
各阶段的报告文档,文档我们应该还是看得懂的吧,这很有助于控制质量和自身提高。

因为没有了技术思维的羁绊,也许你的项目经理更出色。
其次是不断学习,努力去学习,你会学到越来越多的项目管理者所需要的技术专业知识(不
是管理知识)
努力吧,领导也许正在锻炼你从而以后委以重任呢。

分析 6:用人 作 者:车山根
项目经理的主要是沟通,用什么和别人沟通是你现在的战略。
分析自己的优势和劣势。
用自己的长处去和别人沟通,在各个部门以及各个技术人员之间让他们主动沟通,你就是他
们之间的催化剂。
在技术这一关,你要用自己的时间学习流程,因为这样你才有更多的问题和技术人员交谈。

第 724 页 共 756 页
第 13 章 项目经理核心能力

在人际关系上面,你一定要和技术骨干做成好朋友,用他们的技术来补充自己的不足。 http://blog.mypm.net

最后,一定要有信心。

分析 7:非常好的案例,但是…… 作 者:daijiangbao
对软件开发来说,项目经理不是技术经理,懂不懂技术不是项目成功的关键。
一个重要的问题是,象这样的开发是纯粹的软件项目,连软件开发技术人员的技术能力也不
是本质、关键性的因素,不能完全用软件工程的方式来做,国内、国外的软件开发,尤其是
应用开发,走软件工程的路,几乎都走上的是一条死亡之旅。这是个世界性的问题。
对技术人员来说,常常抱怨的是所谓的需求不明确的问题,因为用户的要求,原没有达到可
以编写程序的程度。
但是用户的理解,不需要到这样非常底层的地步,实现技术是最底层的事,不该是用户高层
次的指导,所以用低层次的技术眼光来看待高层次的用户指导,自然就会得出所谓需求不明
确的荒诞说法,越是强调技术,越是把技术工作做不好,因为狗眼太低。
另外就是软件开发的流程,在国内基本上就没有所谓的流程管理,流程管理的困难又划分为
阶段内的流程管理,但是大家可以从面向对象的所谓标兵-rational rup 过程来看到的项
目管理是什么,纯粹是撞碎了项目管理的阶段划分,整个是一团乱泥,还谈什么流程管理?
这种开发拿去软件工程也许无所谓,但是软件项目就彻底的失去了阶段控制,项目能成功才
真是见了鬼了,但是绝大部分人确相信,软件项目就得是这样的见鬼开发,不见着鬼反而是
不正常的,从死亡之旅中回来的项目经理,有项目成功的成就感吗? 本文转自项目管理者联盟

所以对本案例,项目经理不懂技术完全应该得到鼓励,但是技术人员懂技术、但几乎不懂真
正的开发技术将是最大的问题,这个问题对软件开发的危害比项目经理不懂技术更糟糕的
多,因为这是根本不对。

分析 8:根据自己的经验总结 作 者:张平
1、 弄清楚各个项目干系人对该项目的期望,确定沟通计划;
2、在组建项目组时注意关键技术职位(如 SA)的人员任命,尽量用足够了解的人,以降
低项目风险;
3、扬长避短,尽量发挥自己在沟通需求上的优势,以得到项目组的 buy-in;
4、项目进度方面:结合客户需求,项目组共同设定 milestone,跟得紧一点,采取集中 b
uffer time 的方式,让每一个小的 WBS on schedule, 大的 schedule 就不会偏离太大;
5、学习开发流程,毕竟这是一个很基本的东西

分析 9:PM 到底要做什么? 作 者:杨梦云


这个案例比较好,个人以自己经验来做一个分析
1、首先作者分析了相关人士状态:不熟悉软件开发及软件工作流程,为人亲和,领导力强
楼主没有分析该人士的工作年限及以前工作经验?这点是分析该人士是否能驾御该工作的
关键分析点
2、就前面朋友分析,本人比较赞同 daijiangbao
首先我们还无法清晰确认楼主所提的是否是纯软件开发。还是其他类的软件(因为有很多领
域的软件开发只是项目工程里的一个子节,而非全部)
3、我们这样来分析,个人提几套解决方案:
首先我提出几个分析要点,其实也上几位朋友没有重点提到的(!= 不等于逻辑符号)
想法!=产品

第 725 页 共 756 页
第 13 章 项目经理核心能力

产品!=商品
点子!=解决方案

项目管理!=软件管理
只是提出了一种软件项目思维方式,而不是提出了一套所有解决商业项目方案

1)纯软件环境的项目经理,个人还是推荐为软件人士担任,这是必要的
比如制作 erp,制作 cms,制作 windows 等纯软件等
以上软件属于硬性单纯性软件开发,不包含其他大含量工程,主要以软件人士为主导

2)如果是复合型项目,如
商业游戏
互联网项目 本文转自项目管理者联盟

flash 项目
其他复合性项目
教育教学软件
以上项目特征是 不是以软件开发为首要,而是一个复合性质工程,如商业游戏,包含了商
业软件,商业美术,商业策划,商业音乐 商业测试 等五个比较独立但又复合管理的环节
以上项目特征补充:每个环节都包含大含量工作内容及工作流程,且管理为独立即复合。不
以软件人士为主导,软件经理与美术经理是并行工作的职位,而非驾御 http://blog.mypm.net

这是偶对带有软件项目开发的项目类的大类分类,本人主要从事商业游戏/教育软件/互联网
it/动画 等项目工程制作及管理
复合型商业项目经理,其对能力要求比纯软件管理更加复合及更加 功能要求多。自然前提
他需要懂一些软件工程管理的基础知识及软件开发流程及方式(这是必要的)。
西方认为项目经理 90%在用于沟通,而国内是道德+人治国,所以 60%项目经理应该是在做事,
40%在协调。
分析这个问题首先要抛弃主观意识,即只要是带有软件的必然为软件人士来管理。这是错误
的。其次,我们要抛弃纯西方理论,而应该考虑国情及国内项目的常规管理方式(项目管理
首要是管人,而非管事,如果看过 目标管理 能本管理 管理规则 这一套依据德鲁克及国内
人对项目管理经验书的人应该对这个有清晰认识)。
复合型可以增加一个技术总监职位,即使项目经理自身就是软件人才,也有必要,其工作职
能为辅助于项目经理进行软件部分管理,因为 复合型项目 30%管理软件,70%管理其他分类
部门,可见软件在其中只占了一定的作用,而非全部,各主要部门缺一不可。
自然技术总监职位可以与主程并列,或者是 CTO 直接担任
纯型软件项目,则不需要为项目单独设置技术总监,管理人士自身就必须是 软件开发人士
担任(建议长期性人士)。
这是我做各种大型复合型项目积累的唯一经验看法。

复合型项目经理能力(skill)
1、项目管理 http://blog.mypm.net

2、商务/渠道/公关/媒体运作 经验(至少都熟悉)
3、企业管理(含企业运作,企业行政管理)
所以说复合型项目经理能力要比纯软件经理要强很多,就在这里,也是必要

第 726 页 共 756 页
第 13 章 项目经理核心能力

首先不要把希望寄托于 boss 和行政经理,他们各尽其职,人月这本书也提到 把适合的人放


在适合的位置
复合项目经理就是战前指挥元帅
纯项目经理不过是战斗里的将军,还非元帅
至于为什么,长期从事复合项目管理的人深刻思考一下,就会发现你是辅助皇帝的元帅,而
非辅助元帅的将军

分析 10:抓大放小,关注重点 作 者:王汉林
1、关注重点里程碑达成,同时根据项目特点,将部分权力下放给项目组的技术负责人,由
他负责项目整体技术实施。
2、与客户、项目组人员密切沟通,随时了解项目进展和问题,组织人员及时解决问题。
3、不懂技术不要紧,重要的是能找到懂技术的资源来帮助自己。

分析 11:资源整合 作 者:王文晋

1、善于留意周边关系资源和项目团队人员专长
2、善于安排和“求助”他人为自己出谋划策,有时候“装傻”也是获得帮助的一种手段
3、善于用“宏观”的思想和别人探讨问题,使他人在意识上接受和配合你的“领导”
4、善于交付“具体实务权利”,当“甩手”掌柜 http://blog.mypm.net

分析 12:项目经理不能是天使,也不能是魔鬼。 作 者:small potato


应该遵循中庸之道。项目必须严格的按照计划来执行。想成为一个完美的项目经理,应该相
应的具备的权利包括有:
1、技术权威:技术上的 NO.1 ,虽然项目经理不一样要非常精通技术。但是对于负责 IT 项
目的经理,至少是 IT 的从业人员。一些概念性的知识必须知道才行。可以不知道如何写 Ja
va 的类,但是如果连什么是 Java, ODBC...都不知道就有些让人笑话了。感觉会是外行领导
内行。所以如果是一个软件项目,项目经理最好也做过程序开发人员;如果是系统集成项目,
项目经理最好也做过系统集成项目。 本文转自项目管理者联盟

2、钱袋权威:可以决定项目成员的收入分配;目前大部分的项目经理都不是职能经理,不具
备分配员工资源的权利,所以有时候会和职能经理发生在人员资源分配问题上的争论。
3、行政权威:有上下级的职位区别;
4、领导权威:个人魅力
5、官僚权威:熟悉公司的流程;熟悉官僚的制度,但不要做官僚;尽量帮助团队减少为了
应付官僚制度而付出的额外的工作。

分析 13:项目经理对技术是外行,如何掌控? 作 者:桂君
外行领导内行是个不容忽视的问题,作为一个项目经理,了解和熟悉该项目所必须的技术也
是有利于项目的进行,也有利于和项目组成员进行沟通。
但作为一个项目经理不可能只做一个项目,在不同的项目中所涉及的技术也是有所不同,我
们也不能做到可以掌握这么多技术,毕竟人精力是有限的。
针对这样的情况,因为该项目经理有丰富的项目经验,对项目管理已经驾轻就熟,在该项目
中可以考虑为他配备一名经验丰富切实力过硬的技术工程师作为其副手,总体负责项目的技
术方面的问题,其直接向项目经理负责,然后有项目经理负责整个项目的管理和运作,包括

第 727 页 共 756 页
第 13 章 项目经理核心能力

与各方的沟通等工作。关键是要做好与该技术工程师的沟通工作,给予一定范围的授权和充
分的信任。共同确保项目的完成

分析 14:清晰定位,开拓资源、保证项目实施 作 者:廖学峰
这种情况经常看到,但听说 IBM 的 CEO 郭士纳以前也只是卖糖水的,但他完成了 IBM 的成功
转型,所以我的想法是:
1、项目经理不一定是项目组中技术最好的人,但一定要是沟通能力最强的人,只有沟通能
力强才能明确项目的内在需求、当前问题、成员状态。 项目管理者联盟文章,深入探讨。

2、项目经理必须和最高层保持一致,确保得到明确的支持,这样才能把握项目的各类资源。
3、项目经理要具有远大的眼光,看到项目的前景,并具备良好的社会资源,保障项目组出
现问题或难题能够通过项目经理的资源快速解决

分析 15:如何掌控外行项目 作 者:blueboyfly
针对 IT 行业的项目管理,如果是外行,确实会遇到一些困难,但也并不是无从下手我建议
如下:
1、针对 IT 项目,外行人员应对其过程和框架有一定的了解,所以应进行一次培训。不能认
为 IBM 的 CEO 老郭搞定企业,你项目经理也可以搞定项目。管理层次越高,对技术的掌握要
求就越低,但不要忘记项目经理的层次要低于 CEO,对专业一点都不了解,会使你底气不足。
http://bbs.mypm.net

2、应和技术骨干进行交谈,制定出详细的计划。最好是可以找一位技术专家作为你的助理。
3、项目经理最重要的进行沟通和进度控制,求同存异,带领大家完成项目。
4、一个外行被领导任命为管理软件开发的项目经理,说明领导对你的信任,也就说明你可
以从领导那里获得更多的资源。项目经理 A 应充分利用这一点,获得领导的更大的支持。当
然,在解决技术方面问题时,要多听取大家的意见,形成决议后就立即执行。

13.4 *我一个朋友的项目困惑

(一)案例正文

目前国内游艇企业多为民营或合股中小型企业,属于小批量、多采购、劳动密集型产业。其
组织结构和运行机制远不能和大型正规企业相比。现行项目管理知识在这些企业中很难操
作。

小陈现就职于一家游艇制造企业,今年年初就曾因为看不惯管理层的做法想离开,但经过老
板的一番“说教”,最终还是决定留下来,并被承诺委任为一大项目的项目经理。小陈自己也
想通过努力来证明自己的实力,并对此很有信心。

第二天,小陈就按所学项目知识,要求企业领导层提供项目委任书和项目团队成员的名单。
然而领导的一句话着实让人晕倒:“项目委任书由你来写,然后我牵个字就行了;至于所谓
的项目团队名单,你也是知道的,我们公司规模小,不可能给你安排专门的团队成员,何况

第 728 页 共 756 页
第 13 章 项目经理核心能力

公司还有其他项目要做啊,因而今后所有该项目的任务和协调工作都由你来做,但你调不动
下面的工人时可以再来找我”。真是出师不利,着实给小陈浇了一瓢冷水。(值得说明的是:
小陈写的那份委任书,至今还放在抽屉里,领导也没有要过。 )

没过多久,小陈就发现实际中至少存在以下几个大的问题:
(1)采购不及时,采购人员不愿提供采购信息,导致无法进行成本控制。分析原因主要表
现在:公司每月库存计算一次,结算期间甚至在平时,仓库人员也不清楚货物余量;还有领
料人员经常领用本属于该项目的货物用于其他项目;采购人员因为怕麻烦,不愿提供采购商
品的价格等信息。
(2)因为没有专门的项目成员,所有工作都由小陈一人完成。这些工作包括:领导层的沟
通协调、项目中的技术问题、工艺图纸和文件、每天员工工时统计、时不时的项目进度报告
等等。幸好小陈借用 Project 能很快完成进度报告,不然不被这些事累病才怪。作为一个项
目经理,小陈需要完成这么多工作吗?
(3)由于多个项目的进行,公司资金严重不足,投入多产出少。小陈所在项目属于大型项
目、开发型产品,但没有定单。因而小陈负责的项目首当其冲的被迫停工,现在已停工两个
月了。可以想象,小陈今年的项目奖金受到很大的影响。
如果你是知情者,你将怎样帮助小陈度过难关呢?

(二)专家点评

点评专家:郭富才 深圳汉捷研发管理咨询公司咨询项目总监,资深顾问,中国首批 IPMP


C 级认证获得者,美国 PDMA 协会会员。专著《用 Project2002 管理项目实务》由机械工
业出版社出版,在《IT 经理世界》、新浪科技网站等发表《让研发人员找准市场需求》、
《实施集成产品开发、提升新烟管理》等文章十余篇。在中兴通讯股份有限公司总部技术中
心工作期间,组织建立了公司产品开发管理模式——产品经营团队,并组织在六大事业部推
广,取得了良好的效果。作为咨询项目经理,服务过的客户包括中国粮油(集团)公司、新
郑烟草(集团)公司、北京四方继保股份公司、杭州士兰微电子股份公司等十余家,擅长企
业产品研发管理体系设计,包括产品市场管理、产品研发项目管理、企业研发组织设计,以
及现场实战的指导工作。

郭富才点评:

这个案例非常典型,说它典型是因为,在许多中国中小民营企业发展过程中经常遇到这类问
题,而且这些问题一直困扰着企业的发展。我先对这个案例中反映的问题进行一一分析,然
后再给出总体的评价和解决方案,供小陈参考。

一、问题分析

1、企业领导说:“项目委任书由你来写,然后我牵个字就行了;至于所谓的项目团队名单,
你也是知道的,我们公司规模小,不可能给你安排专门的团队成员,何况公司还有其他项目
要做啊,因而今后所有该项目的任务和协调工作都由你来做,但你调不动下面的工人时可以
再来找我”。
点评:这位领导在某种程度上是一位有丰富经验的领导,说他/她有丰富的经验,是因为他/

第 729 页 共 756 页
第 13 章 项目经理核心能力

她的朴素想法是依靠大量的实践总结出来的,和项目管理的思路是吻合的。这些朴素的想法
或做法,如果企业有总结成功经验并共享的机制,使这些朴素的想法或做法在实际工作中得
到总结并普遍运用,那确实可以促使一个企业管理方面持续提升,但遗憾的是中国许多企业
并没有总结成功经验和失败教训机制。

在一个企业中,开发项目的任务书一般是由未来的项目经理撰写的。所谓任务书,通常来说
是由上级下达给下级的指令。产品开发任务书中一般包括产品概况、里程碑计划、核心成员
分工、资金计划、细分市场财务分析、风险分析等方面。理论上讲任务书应该由上级来撰写,
但在企业实际操作中这一点是和理论不吻合的。这是因为,在一个企业中颁布项目任务书的
领导一般来说是公司的高层领导,高层领导对未来的产品各项数据指标并不清楚,而且不需
要也不会有时间在开发之初就需要高层领导对这些指标搞清楚。所以实际操作往往是未来的
项目经理会先进行市场调查,在对市场分析的基础上,撰写项目任务书,并将初稿和高层领
导进行沟通,双方在沟通的基础上达成一致,然后由高层领导签署正式的任务书。
项目管理者联盟,项目管理问题。

关于项目组员,一般来说企业中的项目团队成员不是专职的,除非一些大项目的核心成员是
专职的。项目成员一般来说是身兼数个项目,这位领导说的“不可能给你安排专门的团队成
员”在某种程度上是有一定道理的。虽然项目组成员身兼数个项目,但不否定矩阵式管理的
有效性,不否定要成立项目团队,不否定明确项目经理对项目组员的任务指派。在企业中,
由职能部门经理和项目组员自己共同对多个项目的任务分配进行统一,保证项目群时间上不
冲突,而项目经理向职能部门提出项目所需要的角色及技能要求、时间要求,职能部门领导
要对项目提供人力资源保证并做出承诺。在项目实施过程中,职能部门领导和项目经理共同
对项目组员进行管理,项目经理偏重业务管理,如项目任务分配与项目考核,职能部门领导
偏重日常管理,如日常考核与技能培训、职业规划等。

2、采购不及时,采购人员不愿提供采购信息,导致无法进行成本控制。分析原因主要表现
在:公司每月库存计算一次,结算期间甚至在平时,仓库人员也不清楚货物余量;还有领料
人员经常领用本属于该项目的货物用于其他项目;采购人员因为怕麻烦,不愿提供采购商品
的价格等信息。
在中国的企业中,采购人员与研发人员之间的矛盾简直是不可调和的,研发人员埋怨采购周
期长,影响项目周期,而且研发人员得不到采购信息;采购人员埋怨研发人员提出采购需求
时间太晚,而且有标准件不用,非标加工的部件多。

问题的根源在于各自对职责部门领导负责,而不是对项目本身负责,就是说两个没有结成一
个利益共同体,这个利益共同体就是指项目团队。如果大家是一个项目团队中共同的成员,
共同要对项目成功和收益负责,有共同的项目经理,那么他们之间的协调和沟通就顺畅得多,
相互之间的配合也会顺畅得多。

目前中国的许多企业是按职能进行管理的,也就是说员工对各自的职能领导负责,跨部门的
横向沟通及配合由于部门壁垒墙较厚而不顺畅。为此建议企业要逐渐引入项目管理机制,从
系统上来改变这种状况,而不是头痛医头脚痛医脚的做法。

3、因为没有专门的项目成员,所有工作都由小陈一人完成。这些工作包括:领导层的沟通
协调、项目中的技术问题、工艺图纸和文件、每天员工工时统计、时不时的项目进度报告等

第 730 页 共 756 页
第 13 章 项目经理核心能力

等。幸好小陈借用 Project 能很快完成进度报告,不然不被这些事累病才怪。作为一个项目


经理,小陈需要完成这么多工作吗?

有分工有协助,这样效率才会高,这是在十九世纪都已经证明过的理论,遗憾的是我国许多
中小企业还处在经验管理阶段,没有意识到这个问题。小陈作为企业中的项目经理,一般来
说公司所支付的工资会高于一般的操作员,如果整天被一些琐事缠身,如员工工时统计、编
写进度报告等,无论对企业还是对个人来说都是一种损失,因为这些事情,一个操作员就可
以做了。公司的人员梯队建设上要考虑分不同层次,有专业的技术人员、管理人员、操作员
等,进行专业分工,通过项目团队的工作方式进行配合。 项目管理者联盟,项目管理问题。

4、由于多个项目的进行,公司资金严重不足,投入多产出少。小陈所在项目属于大型项目、
开发型产品,但没有定单。因而小陈负责的项目首当其冲的被迫停工,现在已停工两个月了。
可以想象,小陈今年的项目奖金受到很大的影响。
这个项目从诞生之初就带着先天不足,可能在项目启动阶段没有经过严格的决策评审,这种
大型产品开发项目,即使是作为公司的战略类项目,也是要有至少一两家比较明确的客户需
求才能通过决策评审。我们知道产品开发是一项投资行为,决策评审就是为了保证我们的投
资得到回报。 项目管理者联盟,项目管理问题。

在项目的计划阶段,要做好资金计划,所谓资金计划,就是项目未来各周期需要投入的资金,
项目把资金需求信息通过计划的形式报给财务部门,财务部门通过相应的融资渠道准备项目
资金。如果没有相应的资金计划,用钱的时候才提申请,会出现资金断链,项目被迫终止的
现象,形成“滥尾项目”,这是也许多“滥尾楼”形成的重要原因之一。

二、整体分析

小陈在这个项目中遇到的种种困惑和困难,不是小陈引入了项目管理的方法并试图用项目管
理的方法造成的,而是没有真正按照项目管理的方法实施项目。 http://bbs.mypm.net

项目管理的方法不是只适合于大中型企业,是适合于所有类型、所有规模的企业。因为项目
管理是提供给人们一种做事的方法。

我们曾给一个公司引入项目管理,当时这个公司的技术中心也就只有 30 多个人员,没有引
入项目管理之前,按职能管理的方式运作三个项目,项目组员和领导就感觉到手忙脚乱的。
通过引入项目管理机制,首先系统化地建立项目管理的机制和工具,并通过培训让员工掌握
这套工作方法。现在这个公司技术中心人员没有增加,同时在运作 7 个项目,技术中心的
职员和领导接受我们访谈时,明确表示:如果没有项目管理的方式,同时运作 7 个项目,
不知技术中心会乱成什么样子,现在项目目标明确了,组员的任务也明确了,7 个项目都在
有条不紊地实施;而且技术中心领导感觉投入的精力也少了,但得到的项目信息比原来还多,
在关键点决策上就又能对项目进行指示,顺多了。 http://blog.mypm.net

我们要引入项目管理方法,是一种管理模式的变革,这种管理变革需要公司一把手支持,如
果仅是由下层工作人员发起的,80%以达不到预期的效果,而且推动困难。日前,小陈正
是面临这种局面。

三、整体建议

第 731 页 共 756 页
第 13 章 项目经理核心能力

一个公司引入项目管理模式,应该系统化地进行实施,所谓系统化,就是从以下方面来着手
建设相关的管理方式,这包括:流程、组织、激励机制、IT 工具。
所谓流程,就是产品开发项目是分阶段,每个阶段的活动及内容要识别出来,并在关键点上
设置相应的业务决策评审点与技术评审点,保证投资的正确性和产品质量。
所谓组织,就是指采用矩阵管理方式组成项目团队,明确项目团队成员角色与职责,明确分
工与配合的接口关系。

所谓激励机制,是指项目经理对项目团队成员的考核机制,以及考核结果在企业的运用。
所谓 IT 工具,是指为了保证项目高效率实施,使用 IT 工具来辅助管理。
只有从以上方面来着手建设,系统实施项目管理方式,我想小陈的问题才能解决,否则,如
果关注局部,头痛医头,脚痛医脚,即使针对一两个问题解决了,又会带来新的问题。

(三)项目管理者联盟网友评论

分析 1:没有最好,只有更好 作 者:相乡
我对游艇的行业不是很熟悉,但是针对文中提到的问题发表一下个人浅见。 项目管理者联盟,项目管理问题。

目前国内的企业,真正的管理正规的企业并不多,大多数企业都会有各种各样的问题,文中
的小陈有这种困惑也算正常,而关键是自己在这种环境中如何能克服一些困难,不断提升能
力。有问题的地方,有障碍,同时也有机会,如果小陈能在这种情况下带出一个漂亮的项目,
就说明他能力有了很大的提高,加薪升职也是顺其自然的事情。
实际中的项目管理,不一定完全按照项目管理的知识去操作,对于案例中的情况,有几点要
把握好。
1、 首先是目标,要向领导问清楚,如果像文中提到的情况,连领导也不能很明确地提出
目标,那么只能靠自己判断领导交待给你的任务的风险,并尽量确定自己近期的工作目标并
与领导沟通。一方面让自己很清楚自己在做的事情,另一方面也让领导知道自己在做的事情,
从而帮助领导在整体项目策划中的方案调整。
2、 第二是团队要相对确定,这个需要领导的支持,在领导没有认识到这个问题的重要性,
以“规模小”“还有其他项目要做”等理由搪塞的时候,要和领导将清楚团队稳定的重要性,也
从公司的角度,协助领导在现有人力的条件下调配好资源。总之,如果具体的事情没有将责
任落实到个人,那么事情的质量和进度将很难控制,一方面项目经理会很辛苦,另一方面,
员工也会因为不能充分发挥个人能力和不能得以提高而郁闷,团队的战斗力的能力也不好提
高。
3、 关于采购方面的问题,如果感觉直接找领导反映这些问题不利于大家的合作,可以提
出为了规范项目管理过程而对采购部分做一些流程上的规定,可以拿流程与规定去寻求兄弟
部门的协助。
4、 如果考虑到奖金的分配,奖金不应当完全按照所作项目的收益,因为项目都会有风险,
有的风险是由于公司决策或者市场而根本不是项目成员造成的。所以,当接手一个新开发项
目的时候,如果公司没有相关的规定,应该与领导沟通好此事。而且作为项目经理,应该和
项目成员讲清楚奖金分配,这是一件大家都关注的事情,也会起到激励的作用。 http://bbs.mypm.net

总之能感觉到这个公司在很多方面还不够规范,领导也缺乏一些魄力和格局,但是,任何一
个已经存在的商业实体,都要按照市场、经济、管理规律去运营,“麻雀虽小,五脏俱全”,

第 732 页 共 756 页
第 13 章 项目经理核心能力

大家在当前的基础上,踏踏实实去完善,这也将可以成长为一只健康充满活力的麻雀,没有
最好,只有更好,一点点进步,也难说会有一天,成长为苍鹰呢!

分析 2:别拿项目管理这个鸡毛当令箭 作 者:daijiangbao
1、项目任命书由项目经理起草,领导任命签字,没有错,是该这样做。
2、领导说的话确实没有错,项目经理是需要按照领导说的话去完成目。
3、不要认为任命个项目经理就是大权到手,别人就必须给你一切的配合,项目经理把这个
鸡毛当令箭到处乱舞,死期就不远了,任命项目经理不是授权,是给项目经理一个组建项目
组织和沟通平台的权力,不要断章取义不求甚解的理解 pmbok。
4、项目经理要能做出计划,在资源短缺的情况下要更好的规划资源,取得领导的支持才可
以,资源短缺不是项目成功失败的必要条件,资源充分的情况下去做事,不具备项目管理的
意义。
5、项目经理不是仅领者几个小偻偻去干活,连项目干系人都没有搞清楚,有什么资格郁闷?
采购部门是重要的干系人,为什么没有发挥他们的作用?

6、项目进行取舍把小陈的项目取消完全应该,不取消作出来的也是垃圾,不会有市场和订
单,小陈就是在为项目奖金来活着吗?有没有责任感?

分析 3:be constructive ok? 作 者:mark


我觉得光是批评和训斥小陈毫无用处,这些言辞相信他已经在他平庸的老板那里听得够多
了。
我认为:
1、必须进行市场调查:项目没订单或潜在订单和客户,还有什么必要搞
2、没有项目委任书不是关键;关键是你的项目在老板心目中的地位->必须说服老板起草
项目委任书。
3、在组织形式上,鉴于“小公司”,“不只一个项目”,可以考虑组成弱矩阵式组织形式

分析 4:另外的想法 作 者:一孑
很怀疑这是你们领导有意安排,前面已经提到,小陈准备辞职,而且是因为对管理层的做法
有意见。这里面有很重要的问题没提,老板如何说服小陈留下来,并去承接这个项目。
也许这仅仅是老板管理的一个策略而已,有时间建议和老板好好沟通一下。
不过对于小陈来讲,有两个建议:
1、项目管理是为项目服务的,所以,不要对工作有所怨言,应该尽量想办法去解决,到不
得已的时候,这个项目所有的工作都会由项目经理来完成也是正常的。
2、在项目启动之处就应该考虑到现在的一些风险,并应该可以及时提出一些策略或者解决
的办法,甚至是提前预知责任的划分,可行性一定要分析,但要知道,并不是一定具备可行
性的项目才可以启动(只是大家的目标不同罢了),在项目遇到的问题的时候,应该还是站
在项目的角度来考虑得失,而不应该马上跳出来计较个人的得失,换个角度,你个人的利益
也应该和项目绑定在一起,故这些风险你应该在项目之初就要有所准备。

分析 5:项目管理的环境 作 者:Chen Yongjun


就本案例来看个人看法是在该企业缺少项目管理的环境,小陈要想度过难关,我建议如下:
1.首先,企业高层要有项目管理意识,如果老板在这方面不具备老板对项目的支持与对项目

第 733 页 共 756 页
第 13 章 项目经理核心能力

的干预都会存在问题;
2.其次,项目经理要明白该项目的成功率与风险,当项目经理要执行一个项目的时要考虑该
项目存在的风险(包括关键干系人),在本案例中尤其突出; 项目管理者联盟文章,深入探讨。

3.最后,建议建立一个稳定的项目团队对完成项目目标至关重要,从老板的意识来看,PM
得与他的老板好好沟通,若做不到考虑你的工作环境。

分析 6:别拿项目经理这个权力太当一回事 作 者:daijiangbao
1、小陈需要到什么权力才可以做项目?连总经理都不是能把所有的人员搞定,给小陈要赋
予一个比总经理都高的权力吗? 项目管理者联盟文章,深入探讨。

2、就算是给小陈赋予副总经理的权力,别人就会去听他的?凭什么去听小陈的?对项目经
理的授权,项目就脱离了现实的环境?pmbok 是这样理解的吗?是这样说的吗?
3、老板平庸?我看这个老板很不错,老板的管理知识,包括项目管理知识远高于小陈,否
则小陈怎么不是老板?领导不必按照 pmbok 来当领导,但不是不懂项目管理,不要把项目
管理神秘化、高雅化。想想 MBA 在中国的命运,PMP 也是否会沦落成第二个 MBA 的命运?
4、在中国从来不缺少项目管理,本身项目管理也不是项目成功的重要成分,最多是锦上添
花的意义,难道是有了现在的项目管理才能做事,没有项目管理就不可以做事?中国几千年
的灿烂文明,哪一个不是项目?哪一个是工厂流水线上生产出来的?
5、小陈看不惯领导想离开,说是在的,真的离开了也无所谓,天不会塌下来,只是小陈要
郁闷到什么时候?郁闷之极了,蓝天可以熔化他,江河可以接纳他,中国历来这样的知识分
子多了,为什么受伤的总是知识分子?怀才不遇?究竟明白项目管理没有?项目管理是容纳
知识分子郁闷的最后圣地吗?

分析 7:努力就是一种回报 作 者:陈秋
目前国内的企业,真正的管理正规的企业并不多,大多数企业都会有各种各样的问题,有问
题的地方,有障碍,同时也有机会。 项目管理者联盟,项目管理问题。

实际中的项目管理,不一定完全按照项目管理的知识去操作,对于案例中的情况,有几点要
把握好。
1、 首先是目标要明确,知道自己应该干什么,需要哪些人协助,可能会遇到哪些问题.
2、 第二是争取各部门的协助和分担,因为有分部门职能,做事许多时候是要别人提供更多的
帮助,这需要你的技术技巧和沟通技巧,多一个人帮你,你的压力就会减轻一分。
3、 对于项目执行过程中遇到的较重要的问题时,要想办法攻关,包括采购的较大支持及相关
信息问题.还要及时反馈信息给你的领导或上级知晓。
4、 而奖金问题只是一种激励手段,是要各自根据不同的环境去灵活运用的。
总之尽你所能去做好每一件事,不管项目成不成功你都有很好的收获,这当然是你的处事手
段和经验了.

分析 8:项目经理应该做的事情 作 者:刘宇 本文转自项目管理者联盟

项目经理,顾名思义,项目的领导人。对于你朋友小陈遇到的这些问题,在很多中小型企业
都会遇到,其中也不排除大型国有企业。 项目管理者联盟文章,深入探讨。

我国的现代项目管理起步比较晚,因此很多领导人对与项目管理都没有很多的了解,大部分
人还停留在传统的项目管理阶段,仅以为只要项目成功就可以,不必要理会使不使用项目管
理。然而恰恰因为这个观念存在,所以造成不能有效的利用资源,并且浪费时间经费。小陈
的情况就是一个很好的案例:项目停滞不前,前期所做的努力都浪费了。

第 734 页 共 756 页
第 13 章 项目经理核心能力

传统的项目管理大都采取的是职能式管理,基本上由上头下命令,底下猛加班,项目抓两头,
中间不监督,责权不明确,事故大家摊的情况。尤其是中小企业,认为自身企业比较小,项
目管理不适用。上个项目完成了有钱赚就行,就算没完成,只要赔得起就无所谓。殊不知一
个企业的发展本来就是靠项目,而很多项目完不成或者耗费很多资源完成,那还有什么发
展?
现代项目管理,对于国内大多数企业来说都是个新概念。就如同90年代刚推行质量体系认
证一样,现在推行项目管理也遇到这样的问题--不适用。可是真的不适用吗?不见得,我
个人以为应该是不会用,不懂得如何去用。学过的过分强调理论,没学过的过分强调经验,
二者不能够有效的结合,结果造成现在的局面。 项目管理者联盟文章,深入探讨。

针对小陈的问题,我个人认为应该采取下列方式改进:
第一,对与项目本身,要做充分的项目可行性分析调研以及评估与论证。如果项目是赚钱的,
老板就没理由砍掉这个项目。 本文转自项目管理者联盟

第二,采购管理是项目管理的一个部分。在项目工作分解之后,应该把责任矩阵表列出来,
那么各个部门包括采购部需要担负的责任就会清清楚楚。再根据责任矩阵建立一套奖惩制
度,责权分明,一切按规矩办事,还能有人说出什么来?
第三,作为项目经理,主要负责沟通、协调、监督、管理等工作。而工时统计、制作工艺图
纸和文件、技术问题等都应该有各个专业部门负责。项目经理应该合理安排优化资源,千万
不要把什么事情都揽到自己身上,否则项目经理如何对项目进行管理? http://bbs.mypm.net

第四,应该对项目的风险做出充分的预估,然后针对不同情况做不同处理。项目管理本身就
是变化着的管理,只要计划做得好,虽然出现偏差,那也可以按计划进行调整。 http://bbs.mypm.net

第五,要活学活用,全面应用,全员参与。无论考过 PMP 还是通过 IPMP,理论得以加强,


但是一定要会在管理中用活项目管理工具和技术。对于不懂项目管理的老板,应该经常介绍
项目管理的好处,如果老板懂项目管理而且知识丰富,就多向老板请教,这样有利于在实际
操作过程中建立一个强大的支持。
总之,项目管理是一门博大精深的学科,项目管理专家实在不断的实践过程中磨练出来的。
遇到问题不要先抱怨,要先考虑自己这边具备怎样的条件,学会变化的管理,用以应对项目
过程中出现的问题。

分析 9:大项目还是小白鼠项目? 作 者:flan xu http://blog.mypm.net

很欣赏刘宇非常针对性的项目分析。
我们换个重点分析:
这个项目该不该做成? 做成什么样? 分几个阶段做?
项目经理的目标是把项目做成。而完成项目的资源几乎都是从企业中获取的。如诺企业不能
为项目提供充分的资金人力和设备,那么项目也根本不可能完成。
既然企业立了这个项目,他是有他用意的。或许他真的是个高利润伴随高风险的项目。那么
小公司能够用高的投入来承担高风险吗?很有可能把这个项目定义成小白鼠项目了。
好,既然企业为了自身的发展不能提供充足的资源。那么我们得和领导重新审视项目的目标。
首先对本项目进行理想的 人力符合分析 费用分析
第二, 和企业领导和其他项目经理讨论 能否提供这些人力和费用。
第三, 修改项目目标 包括范围 工期 http://blog.mypm.net

第四 风险分析 因为是通过抽调方式来提供人力资源的,项目本身就存在了很大的风险。其
他项目的进度都会成为这个项目的风险因素。

第 735 页 共 756 页
第 13 章 项目经理核心能力

回头看看 既然项目组只能用抽调人力的方式去从事本项目(其实已经证明这个项目的优先
级是最低的,只不过冠名为大项目)。
此项目 如果不先论证和根据资源计划好 一定在执行过程中会面对非常大的冲突和风险。
本文转自项目管理者联盟

分析 10:进一步说明 作 者:daijiangbao (深圳市大视野项目管理有限公司 daijiang


bao@hotmail.com)
1、 项目管理博大精深,是因为其背后支撑的是古今中外人类用项目建造的辉煌历史,大
事小事都是一样的道理,涵盖了所有的行业,并不因为是游艇制造或者是软件开发亦或是建
筑行业有什么区别,这些人类项目的成功经验都直接或间接隐藏在 pmbok 中的一些描述
中,尤其是在 pmbok 的前面部分,篇幅不多,但是从项目成功的角度来看却是寓意深刻,
是需要很好挖掘的,可惜的是尤其是中国的 pmp 考试带来的一些问题,大家把重点的关注
目光都放在了 9 大知识体系,因此造成在实际项目中,都觉得只要把这些知识体系运用好
就可以了,这是非常片面的表现,pmbok 不是一本项目管理的简单说明,无论是国内的项
目成功经验还是 MBA 中的经典案例,都可以从 pmbok 中得到说明验证。在中国来说,不
是没有项目管理,应该是世界领先的项目管理,不要崇洋迷外,妄自菲薄。毛泽东早就嗤之
以鼻的洋奴哲学、爬行主义现在当道,已经是一个严重的问题。 http://bbs.mypm.net

2、 项目管理所占的重要性,可以从 pmbok 中 96、2000、2004 版本中的描述可以知道,


查看项目管理与其它管理、其它学科的关系的演变说明,你就可以明白这点,项目管理的图
示面积是大大缩小了,没有项目管理也照样可以完成项目,有了项目管理是可以起到锦上添
花的效果,远没有达到媒体宣传的那样重要性,否则连解释人类的项目历史都成问题,所以
不要把项目管理太过于大话,不要对项目管理太当作一回事,否则倒霉、郁闷的还是项目经
理,IT 行业需要项目管理,是因为 IT 行业的发展有悖项目的成功方式方法,但是现在又用
不正确的眼光来看待项目管理。
3、 对于项目经理的权力也应该有清楚的认识,在 2004 版中,我好像就没有找到对项目
经理的任命和授权的论述,可见这个问题在全球范围也会引起很大的混乱,美国的项目管理
不是就代表着全球的项目管理,就是在 96、2000 版的 pmbok 也是将项目经理的任命和
授权分开讲的,两者之间可以有关系,也可以没有关系,但是现在大家掉入的误区就是任命
项目经理就一定要得到整个项目的最大权力,千斤重担挑于一肩,这完全是对 pmbok 的误
解、不求甚解造成的,pmbok 不是可以当作小说来读的,尤其是眼中只有技术的技术人员,
更是不能用肤浅的技术眼光来看待 pmbok,也就是说,技术人员不能是合格的项目经理,
这是天生的,但是可以在后天的项目实际中逐渐锻炼,但主要的一点在通往项目管理的道路
上,不要涉及很深的技术,所以不要把项目经理太当一回事。

4、 在本案例中,可能涉及到项目管理、项目经理、技术、资源缺乏、领导支持等这些因素,
这些因素中领导支持占的比重是很大的,其它因素加起来起的作用还不到这条的一半,因此
领导对小陈的说法是绝对正确的,应该按照领导的说法去做,其它因素占的比例很小,不能
说领导不懂项目管理,中国没有项目管理,甚至没有现代项目管理,要明确管理的目标是什
么,而不是装腔作势的什么管理。
5、 技术、资源缺乏从来就在项目管理中就不占主要因素,这点要明白,在技术缺乏的时代
尚且如此,在现在技术不缺乏的年代更是这样,否则你不能理解中国的小米加步枪如何打败
美国的飞机大炮,911 以后美国连拉登都搞不定的事实,如果把知识、技术和知识分子结合
起来,你也就不能从项目管理的角度理解为什么中国会有针对知识分子的文化大革命,而且
中国的历史上这样的事情也不是一次,项目管理一定是要服从于政治和权力斗争需要的,这

第 736 页 共 756 页
第 13 章 项目经理核心能力

点是在 pmbok 中有一定的论述的,不要把项目管理搞成中看不中用、银样蜡枪头的东西。 项目管

理者联盟,项目管理问题。

6、 实际上项目管理不是只能管理那些鸡毛蒜皮的小项目,可以试举一两例:(1)、在处理
台湾反分裂的斗争中,是否明确了中国统一后的模型是怎么样的?中国现在不是统一的?为
什么 05 年中国的统一法改为反分裂法?满世界都在叫嚷、笑掉牙的统一是正确的吗?这个
项目的关键在什么地方,如何解读中国大陆的正确对台政策,陈水扁一伙台独闹剧对这个项
目的的成功有什么积极的帮助,在似乎战争一触即发的情况下,如何理解美国人所说的大陆
和台湾没有战争,但不排除与日本有一战,从项目管理的角度上都可以完全解读出来。
(2)、
中国建设和谐社会,有无将这个项目的项目经理和项目管理团队、尤其是客户搞明白,如何
来进行这个项目,主要的因素要抓什么,从什么地方入手,这些问题如何来做,项目管理都
是有很明白的说明的。
7、 中国根本不缺乏现代项目管理,这一点也是要明确的,拿我现在所从事的深圳市××区
政府投资项目管理来看,整个项目就是 pmbok 的全部范例,很完整但是不完美,所以需要
用现代项目管理来锦上添花,再用信息化来实现项目管理,而不是用项目管理来进行一场对
政府的革命和改造。
8、 本人从事项目管理多年,pmp 证号可以在 pmi 查到,不是冒牌货。 项目管理者联盟文章,深入探讨。

分析 11:可行性分析 作 者:储知君 (沪东中华造船集团有限公司 henry_chu@citiz.net) 本

文转自项目管理者联盟

该项目其实存在先天不足的缺陷:
该项目在立项时至少未作项目成本及项目人力资源可行性分析;基于以上可行性分析工作的
缺失,直接造成项目进行过程中人员不能完全到位,资金链也出现断裂现象,直接导致项目
的最终失败; http://blog.mypm.net

鉴于以上原因,我建议作为项目经理应该在项目中断期间,针对项目的目前状况至少做一下
两项工作: http://bbs.mypm.net

1 对项目剩余工作重新作 WBS 分析,然后根据公司实际人员配备情况,排定人力资源到位


时间进度表;以此作为向公司管理层要求人力资源到位的依据;
2 对项目剩余工作的所需投入成本进行详细核算,并对项目成功后的市场盈利情况进行分
析,以确认该项目是否在经济效益上可行,如有盈利潜力,可以具体的数据分析,重新提请
公司高层考虑重启该项目;
http://blog.mypm.net

分 析 12 : 怎 么 做 职 业 项 目 经 理 作 者 : xingzhou ( 重 庆 城 市 建 设 投 资 公 司
xingzhou540608@sina.com)
看了段柯的案例,我不得不说一说你这位朋友小陈了.我道要问一问,他是职业项目经理人吗.
你不要认为老板一番说教,你就自持高傲.我不是自己把自己看得很低级,实际上是职业经理
人的工作性质所决定.你知道PMP吗?可能大家只知道它是 project managemet professional
的缩写,叫做项目管理专业人员.并不知道代表这类人工作特性的中文拼音缩写,那就是:
pai ma pi(拍马屁).这三个字在这里并不是指我们项目经理就是天生的奴颜媚骨,而是指项目
经理的工作就是替他人做事委身于项目发起人.用行业的话说叫做:"竖向沟通,获得领导
支持".虽然要好听一点,但也可叫做"拍马屁".既PMP.所以做一个职业项目管理者
一定要意识到这一点.
你在案例中说道:小陈就按所学项目知识,要求企业领导层提供项目委任书和项目团队成员

第 737 页 共 756 页
第 13 章 项目经理核心能力

的名单。"要求领导提供委任书和团队人员名单"这是项目管理的知识吗?望认真领会PM
BOK的精神.关于案例中领导对你的回答:“项目委任书由你来写,然后我牵个字就行了;
至于所谓的项目团队名单,你也是知道的,我们公司规模小,不可能给你安排专门的团队成
员,何况公司还有其他项目要做啊,因而今后所有该项目的任务和协调工作都由你来做,但
你调不动下面的工人时可以再来找我”.我认为没错.很说明问题.第一,老板只能说做什
么,怎么做则是项目经理的事情.他叫你写委任书就是问你自己完成这个项目要什么权利和
资源.第二,老板的回答已很明确地说明了公司的组织情况和资源状况,并且根据这些情况
明确规定了本项目的组织采用矩阵型组织.也明确了小陈项目协调员的角色.
遗憾的是你连项目协调员的职责都没有尽到.从你的案例中可以看出,你不是在按照项目管
理的方法在管理你的项目,你说了一大堆你做的事情,可都没有按照项目管理的程序做.就
连那份明确你工作权限的委任书都还在你自己抽屉里,等着老板来找你要(我不明白你们谁
是老板).更别说你的组织结构,项目计划,成本基准和责任矩阵.特别是责任矩阵,它是
矩阵型项目组织中不可缺少的工具.你在案例中提到的问题大多数都是由于缺乏这一工具,
你无权管理职能部门,又没有批准的职责矩阵来约束职能部门.你怎么能够实现项目目标.
实际上这个项目你也不必为难,因为这个项目老板只给了你一个项目协调员的角色,暂时停
工只是老板为解决资源冲突的一个战略性调整过程.你现在要做的首先是利用这个调整过成
为你的项目补课,按照项目管理的方法,完成上面说到的一些基础工作.另外着重编制这个
项目的产品说明书和质量标准,以恢复老板对项目的看法和信心.获取项目的优先权.

分析 13:问题的诊断 作 者:赵另起
从此案例不难看出存在不少的问题,现在就让我们来看看有极大问题:
1、从没有离开公司来看,公司的现状我想小陈是很清楚的,不是吗?小陈有表现自己的欲
望也是可以理解的,但是还没有真正的理解项目经理是干什么的?没有发现或者是没有理解
组织内的问题所在,如果是知道我想所谓的采购问题、资源不够、权力不够就可以较好的解
决; http://blog.mypm.net

2、项目可行性研究是不是没有对财务评估,财务可行性怎样?也许是公司的管理跟不上或
者资源不够造成项目开发期不够?
3、我们说在项目的开发周期过程中最重要的是领导的支持,如果一个项目有领导的支持项
目就相当于成功了一半,可小陈并没有很好的理解运用这一点,要利用项目委任书的效力来
调动资源,而且要有财务的权力和人事的权力,这样就可以较好的调动资源,
4、项目的组织框架没有领导的支持,也是行不通的!
从案例中看主要问题有这些,当然还需要具体问题具体分析。

分析 14:问题分析 作 者:blueboyfly (ALSTOM blueboyfly@163.com) http://blog.mypm.net

各位专家对该案例的分析比较到位,我谈一下自己的看法:
1、PMBOK 是非常好的理论体系,但是在实际的项目管理中不能生搬硬套。我们应该做的
是运用其思想精髓。
2、在项目经理授权的问题上,不要过于拘泥于流程。既然老板讲了,就应该按照老板的要
求去办,所谓的项目授权书和项目团队名单就应自己拟好,老板签字,OK!老板可没有许多时
间做这些具体的事!
3、成本和采购管理的问题,在老板的支持下,和采购部进行有效的沟通,否则无法完成。
4、最为重要的是要搞清楚项目经理的角色,即定位问题。不同的公司,项目组织矩阵是不

第 738 页 共 756 页
第 13 章 项目经理核心能力

同的。小陈的项目经理角色的定位很清楚,是 Weak Matrix,所以实际上你的角色是 Coordi


nator.因此,小陈的主要的工作是沟通,协调和汇报。小陈一定要搞清楚,你的老板才是真
正的项目经理。

分析 15:看看吧 作 者:163yxy
我有个朋友,是做技术的,非常棒,后来在企业一直担任项目经理的角色,但在资质就位的
时候,企业未将他申报为项目经理,因为报上去的都是领导,这些只吃喝玩乐的寄生虫,实
际上这种情况在绝大多数企业都存在,真正的具体工作都是技术人员去做,寄生虫们只需要
挂个名,因为中国没有一定的制度来强制规定项目经理必须到施工现场,在向建造师过渡时
期,寄生虫大多数都通过考核认定顺利转为建造师,悲哀,因为高级职称只要企业内部盖个
章办个证就可以了,实在凑不满工作年限的,也只要考两门,更可气的是,这种考核认定的
办法还搞了两次,美其名日,有些人因出差出国在外错过了第一次认定工作,我的这位朋友
在繁重的工作之余,一次性通过了四门考试,顺利的拿到了资格证,可建设部的《建造师注
册管理办法》迟迟没有出台,至今无法注册,相反,那些不需考试的寄生虫全部注册完毕(通
过建设部认定),并拿到了年十几万的高薪,而其它的一些资格的注册均已出台并完成了注
册,究其原因,是因为其它的一此资格均为技术资格,而建造师是管理为主的资格,更重要
的是与企业资质挂钩,保住了寄生虫资质就已经保住了企业的资质,所以建设部才不愿意早
早的让这些刚考上的且真正有真才实学的进来分一杯羹,人事部不是要考试吗,我让你考,
考上了我也不让你注册,反正我的人数已经够了,我才不着急呢。我的这位朋友现在很无奈,
辛苦考来的资格却无法注册,就算将来注册了,依中国的管理制度,也无法维护自已的权益,
因为在竣工验收的时候,根本没有法律规定一定需要建造师在施工资料上签字才能验收,建
造师只能是用来保企业资质和投标时有用,这样算来原来的寄生虫的数量已经足够了,因为
即使你企业有 100 个工地也只要几个建造师就够了,因为只要在投标时挂个名就可以了,中
标之后根本没有人也没有法律管你去不去施工现场,所以中国的建造师现在就已经多了,悲
哀啊中国,悲哀之后,痛定思痛,我认为建设部只有做到以下几点才能公平公正:
一、通过考核认定取得建造师资格的人员,不得进行企业变更注册,肉要烂就烂在锅里算了,
给其它的真正考试通过的人一条活路;
二、考两门的建造师可边执业,但不得进行企业变更注册,只有同时再完成其它两门的考试,
方可以进行企业变更注册;
三、尽快出台《建造师注册管理规定》尽快让考试通过的人注册;
四、出台相应的法规,确保建造师必须到现场执业,所有施工资料必须由建造师签字盖章才
能交工验收,只有这样才能扩大建造师的需求量,才能保证建造师的工资水平,建造师才能
很在乎自已的资质,不会在施工资料上乱签字,工程质量才能得到真正的保证。

分析 16:我来说说 作 者:Kevin
在案例中小陈出现这些问题都是初涉项目管理者经常会碰到的问题,PMBOK 是一个非常好的
管理知识体系,能够有效指导我们工作,但是也不能硬生照搬,一定要加以理解。一个好的
项目经理是带出来的,而不是学出来,一个好的项目经理是做出来的,而不是看书就能看出
来的。 项目管理者联盟,项目管理问题。

在此案例中,我们可以看出小陈具有很强烈的表现欲望,当老板委任他为一大项目的项目经
理,为了通过努力体现自己的价值,在得意忘形中忽略一下工作:
既然被委任为一个大项目的项目经理,没有对项目可行性分析,如公司策略分析,市场分析
等等。从老板这样一句话“项目委任书由你来写,然后我牵个字就行了;至于所谓的项目团

第 739 页 共 756 页
第 13 章 项目经理核心能力

队名单,你也是知道的,我们公司规模小,不可能给你安排专门的团队成员,何况公司还有
其他项目要做啊,因而今后所有该项目的任务和协调工作都由你来做,但你调不动下面的工
人时可以再来找我”,我们可以分析出来情况:一是作为公司高级领导层的老板,从项目立
项开始就对该项目不重视,不能够得到老板的积极支持,使项目失去了成功的有效动力。二
是小陈所处的公司的组织结构是一个弱矩阵的组织结构,没有专门的团队成员,没有足够的
权利调动下面的工人,光杆司令(本来目前也是这样)。三是明确自己的工作责任。
当然了,目前的问题都发生了,所以先说了一大堆的屁话。面对这些问题我自己提出以下解
决方案:
1、对于采购管理中的成本和控制问题,采取双向沟通,向老板或采购部门经理反映采购部
目前存在的问题,以及这些问题所会带来的恶果,最好获得老板的支持和一定的权利。 http://bbs.mypm.net

2、明确向老板说明目前项目的状况,要时不时在进度报告中体现目前项目的存在问题,以
及潜在的风险,以引起老板的重视。
3、这点属于先天不足了,只能是沟通、再沟通,以获取重新启动项目。

13.5 被认为在偷懒的项目经理

被认为在偷懒的项目经理

[姓 名] 孟晓林 [单 位] 网络业务部 [邮 件] meng@chinadu.org


[所属行业] IT 软件 [所属主题] 项目团队管理 [发布时间] 2003-8-8

【案例正文】
A、B、C 为同一项目小组成员,其中 A 为项目经理主要负责与用户的沟通及项目
分解、B 负责项目中的技术实现,C 负责项目文档的收集和整理。

C 的工作虽然简单但是格外繁重,因而多次向 A 提出可以增派人员,A 已认为 C


的工作量过大,需要增派人手,因就此事多次与上级领导沟通。但每当上级领导就
此事询问 B 情况时,B 总是说 C 的工作不算很多,而且 A 的工作比较轻松,让 A 帮
助下 C 就可以了,不需要增派人员。因而领导不同意 A 关于增加项目组成人员的建
议。

A 在了解完情况后与 B 进行沟通,B 的理由是 A 的工作确实不多,总是给这个人


点意见,给那个人点意见,但是 A 自己从来不自己做事情。所以 B 认为 A 有时间来
帮助 C 完成工作。A 试图从岗位责任、项目分工等方面对 B 的这个误解进行解释,
又试图利用换位思维的方法象 B 说明真实情况,但 B 依旧坚持自己的看法,认为 A
给自己的工作太少……

第 740 页 共 756 页
第 13 章 项目经理核心能力

请问,如果你是 A 你会利用什么样的方法来想 B 解说呢?

【相关分析】

·同意阿建的看法(2008-08-21) [作 者] yds [公 司] pti

同意阿建的看法,首先。第一点,C 组是否有在科学的,认真的情况下工作。
第二点,B 组技术部,纵然他们要找人帮忙,也不到技术人员,困些 B 组大可不用去反映这个问题。
专心做好事是最主要的。
第三点,A 组是项目经理可根据自己掌握的实际情况安排工作。认为行的就要行动。

·西游记(2008-08-21) [作 者] 李海翔 [公 司] 东软集团股份有限公司大连分公司

典型的取经的案例:
A 类似于孙悟空、B 就是猪八戒了、C 是沙僧。
B 老是爱打些小报告,呵呵!
解决的方法,前边的人都已经说了很多很多了!

·项目经理应有专权(2008-08-20) [作 者] 董董 [公 司] 富士康

A 是项目经理的话 B 就无权越级向上级部门汇报,上级部门领导应相信 A,就不应该跳过 A 直接与


B 交谈,B 只是项目组成员无权指责 A,A 负责整个项目 A 做的事情没必要向 B 说明,C 只是负责
收集和整理文档,这部分并不难只不过有些烦,如果 C 做不好只能说他能力有问题,A 选择做事情
的人选错了

·被认为在偷懒的项目经理(2008-08-19) [作 者] 朱行军 [公 司] 保密

提一点不成熟的看法:
这是中国特色的项目经理部。
项目章程是如何规定项目经理的责权利,A 既然是项目经理那么项目经理的职责是什么?B、C 只是
项目项目部的成员,各自负责完成自己的工作,项目部的成员 B 无权考核项目经理的工作多少。
上级领导的做法欠妥,首先是征求项目经理的意见,如果不相信 A,则应该亲自考察项目部各个人的
工作情况。
针对这个问题,建议:项目经理首先应该与上级领导沟通,取得上级领导的认同,然后召开项目部会
议,听取各个人的工作情况汇报,现成一致意见。

·深入交流,寻找症结,达成一致(2005-02-24) [作 者] 小飞熊(flybear) [公 司] no

B 在这个案例中的作用显然是至关重要的。那么关键在于 A 和 B 取得一致地意见,而不是简单地把
自己的想法强加给 B(即使 A 的想法和观点是正确地)。

第 741 页 共 756 页
第 13 章 项目经理核心能力

站在 B 的角度上看,A 应当首先分析 B 为什么会得出与他不同的观点。这可能有以下原因:


(1)A 没有把自己和 C 的困难充分的告诉 B
(2)B 对 A 的工作不了解,对 C 的工作也缺乏更多认识
(3)C 的工作方法、能力等方面可能存在一些可以改进的地方
(4)C 的工作安排由于计划在执行中的变动而发生变换,或开始安排就不完全恰当且尚未作出调整
(5)C 对问题作出了过于严重的判断与汇报
(6)B 看到了 A 没有看到的更深层次的问题
(7)B 由于以往经验等,做出了错误的判断
显然,除了上述所列原因,还可能有更多导致 A、B 产生不一致判断的问题。那么,A 应当如何处理
这个问题呢?
既然 B 作出他的决定的原因可能很多,那么 A 就不应当简单地认为自己是绝对正确的和 B 是无知而
错误的这么武断的决定。实际上,A 应当对 B 反对 A 观点的原因与 B 进行更直接的交流。从而澄清
问题的症结所在:
(1)A 应当首先向 B 说明自己目前存在的疑惑和困难
(2)然后,征求 B 的观点和意见
(3)如果是由于 B 对 A 的职责的理解存在误解,那么应当通过 C 的工作安排和自己的工作安排与责
任,具体地告知 B 他的想法可能由于实际的资源限制而难以完全实现,并希望 B 帮助你摆脱现在的
困境
(4)如果发现是 C 的工作等方面存在问题,则应当非常感谢 B 的反对意见,并真诚地向 B 请教如何
帮助 C 解决问题
(5)如果是存在其他 B 认为可以解决的问题,则不妨请 B 谈出他的观点
(6)如果交流的结果是 B 由于对某些具体情况不了解而作出了错误的判断,那么不妨由 A 和 B 一起
向领导作一次交流,并表明你们已经达成一致。这样,B 就不会由于下不来台而坚持他原来的观点,
而会形成 A、B 齐心协力完成任务的和谐局面。

·我的想法。(2005-01-15) [作 者] 阿建 [公 司] 汕头信息部

首先。第一点,C 组是否有在科学的,认真的情况下工作。
第二点,B 组技术部,纵然他们要找人帮忙,也不到技术人员,困些 B 组大可不用去反映这个问题。
专心做好事是最主要的。
第三点,A 组是项目经理可根据自己掌握的实际情况安排工作。认为行的就要行动。不然给人的感觉
是无能。没有一点自尊。

·搞定B或者老板,否则就老老实实帮C干点儿活(2003-11-28) [作 者] 老梨 [公 司] My Company

120 人的项目,一个项目经理,但肯定有个项目管理的 Team,看 A 能不能找项目中其他有用的人帮你


说说话。 B 应该是一个关键人物,否则老板也不会去参考他的意见,这其实是一个冲突管理,看 A
怎么搞定了。无论是根据 PMBOK 原理还是项目经验,想要双赢得解决问题(前提是 A 好像没有能力去
强制解决),国人喜欢斗,但大都重关系重利益,所以对 B 下点儿功夫,应该没什么解决不了的事体

第 742 页 共 756 页
第 13 章 项目经理核心能力

(前提是老板那里搞不定)

·ziye的看法是对的(2003-10-08) [作 者] jason shi [公 司] hr

我不同意将项目经理看成是音乐指挥家的说法,尤其是在一些不太大的项目中。相反,项目不大的时
候,我到认为项目经理确实更像麦当劳的店长。现在,很多人认为现在项目分工很细,这是正确的,
但这并不代表每个项目成员必须专注于一个特定的分工(包括项目经理自己),项目中的每一个人都
有自身的主要任务,但并不是说每个人只需要完成这个主要任务,否则就谈不上团队了。当资源分配
不合理时,项目经理就需要进行资源平衡,在不影响各自的主要任务的同时,完全可以帮助其他负担
过重的成员。
项目经理只有是在进行较大的项目时,才更像指挥家,因为他的首要任务是进行项目的管理,在项目
较大的时候,他需要花费绝大部分时间在管理上,因此无暇负责一些具体工作。但这并不等同于项目
经理完全不用负责具体工作的说法。

·项目经理就好像一个乐队的指挥家,不是开McDonald。(2003-09-28) [作 者] 周勇 [公 司] 武
汉亨威科技

这个项目中所出现的问题:
1、项目经理就好像一个乐队的指挥家。不知那位仁兄说开 McDonald 的例子。我想喷饭:)。
2、职责部分,沟通不畅。B 根本就没有资格去说 A 没有事做,也没有资格说 C 的工作负担不重。
3、项目经理 A 处理的手段不对。如果说 C 的工作负担很重,那首先就要对 C 的工作量做一个评估,
根据评估打报告给领导。

4、××××这个项目定义有问题。这个项目经理只做主要负责与用户的沟通及项目分解,^_^,对一
个 120 个人的项目组来说,我还是有点不理解。××××。

·让你和同事一起成长(2003-09-15) [作 者] yan_W [公 司] mtl-Canada

首先,有 B 这种同事,A 是非常幸运的,


作为拥有一个项目达到 120 个人尺寸的公司,
可以假设这公司对项目管理是非常的成熟,
公司主动的对人员的增减,是对公司现在和未来经营的考量,
在这里 A 已了解项目需增人手,只剩对 B 的解析,
前面有几位兄台都提到沟通,在这里我想强调的是,
一个项目(120 人我估计最少两年吧,这项目),象一个大家庭,
项目经理是带着团队,相互扶持的往前走,
A 有必要消除 B 的误会,这也是极好的和队员的沟通的机会,

第 743 页 共 756 页
第 13 章 项目经理核心能力

对 B 的疑问及建议一一解释,
要分享 B 真正的想法,和其对项目及其它的看法,
可能的话,
把 A 的工作日程告诉 B,
'...包括我,在接着的半年,我们 team 每个人都会很忙...
接着文档部分的工作,按我们计划,会成倍的增长,必需加人手...'
大概用时一个半,

·让你和同事一起成长(2003-09-15) [作 者] yan_W [公 司] mtl-Canada

首先,有 B 这种同事,A 是非常幸运的,


作为拥有一个项目达到 120 个人尺寸的公司,
可以假设这公司对项目管理是非常的成熟,
公司主动的对人员的增减,是对公司现在和未来经营的考量,
在这里 A 已了解项目需增人手,只剩对 B 的解析,
前面有几位兄台都提到沟通,在这里我想强调的是,
一个项目(120 人我估计最少两年吧,这项目),象一个大家庭,
项目经理是带着团队,相互扶持的往前走,
A 有必要消除 B 的误会,这也是极好的和队员的沟通的机会,
对 B 的疑问及建议一一解释,
要分享 B 真正的想法,和其对项目及其它的看法,
可能的话,
把 A 的工作日程告诉 B,
'...包括我,在接着的半年,我们 team 每个人都会很忙...
接着文档部分的工作,按我们计划,会成倍的增长,必需加人手...'
大概用时一个半,

·先沟通(2003-09-13) [作 者] 孙鸿磊 [公 司] 广州市帕里森机电设备有限公司

作为一个 120 人的项目组的经理,A 要处理的事情应该非常之多,当然,要他做好每个人的思想工作


是比较难的。但是我觉得在中国,作为项目经理有一个最重要的沟通 A 没有做好,就是与领导之间的
沟通。咱们国家很少有领导完全放手给项目经理完全负责制的,通常都会插手。但是如果项目经理关
系处理得当,有时可以把负面影响转变为正面。
具体这个问题,A 或许应该先自我检讨一下,与领导之间的沟通是否有什么问题。其次,在 B 的方面,
其实对待做技术的人用“尊重“一般都比较有效,建立良好的个人关系,从各个方面去关心你的组员,
尤其是关键人物。
只是一点拙见。

第 744 页 共 756 页
第 13 章 项目经理核心能力

·你的项目WBS有问题(2003-09-09) [作 者] 赵祥龙 [公 司] 博大投资

从本案例看,项目团队成员对各自工作任务的抱怨说明原来的项目 WBS 没有考虑到这个项目在文档管


理方面的问题,在这上面作一些调整是非常必要的。
其次才是沟通问题!

·看项目管理的人数(2003-09-04) [作 者] richard [公 司] chief war room

作为一个小的 team,我认为大家互相帮忙是应该的事。
作为一个大的 team,项目经理最主要的是做最重要最紧急的事,其他事他可以不管,因为他要看大方
向大目标,不要被琐碎的事(特别是不重要又不紧急的事)给挡住,原文没把它说清楚,后来的注释
(项目有 120 人之多)我上次没看到(I am sorry)。
B 的想法是错误的,居然要项目经理去帮他,你要知道这个项目有 120 人,如果项目经理人人都帮忙,
他不累死才怪。

·浅识拙见:项目管理不同于开麦档劳(2003-09-03) [作 者] 周长征 [公 司] 电信公司

你看麦当劳,一个工作人员看到旁边的队伍人多时,会说:后面的人请到这里来。麦当劳的店长在繁
忙人手不够时会主动扫地,因为他们规定是每半小时打扫一次。不然,一个公司养这么多人干嘛,吃
闲饭吗?
------老兄的观点不敢苟同!项目组是一个整体,哪个环节不协调了都会影响整个项目组的绩效。打
个比喻:项目组好比一个木桶,项目组成员就如组成木桶的一块木板,如果其中一块木板比其它的木
板要短,如此整个木桶盛的水也不会多!所以项目组成员相互帮助是必要的!但项目组的成员绝对不
能象麦当劳那样的“店长在繁忙人手不够时会主动扫地”地相互帮忙,原因如下:
1、当前大社会生产的背景下,各项工作进行了细致的划分,以满足社会生产的需要,所有的社会成
员的工作被分的很细致、很专业,这就决定了大部分的工作都要专业的知识做支撑。古人说“隔行如
隔山”,一点都不为过,所以,在专业的开发领域里,各个成员最好是各司其责,对其他人的帮助应
主要以帮助其改进工作方法、提高工作效率为主,而不是参与被帮助对象的具体工作。首先,你可能
对被帮助对象的工作并不熟悉,为了帮其工作你要进行相应学习,被帮助对象可能要反过来帮你学习
了,反而进一步降低了工作效率,而你还有自己的工作要做,不可能长期投入到被帮助对象的工作中,
被帮助对象对你的帮助可能没有什么大的收益。其次,如果你在帮助别人的过程中由于对新工作不熟
悉犯了错误,反而会对项目的进展产生更大的影响,可能对项目的成本和质量也产生较大的影响。
2、项目管理一般是在众多成员参与的比较大的、复杂的产品或服务开发中为了保证开发的进度和质
量,同时兼顾开发、生产成本才使用的。为了保证能够达到“保证开发的进度和质量,同时兼顾开发、
生产成本才”的目的,就要对项目组的各个成员的工作做出明确的分工,并明确其责任!很多低质量
或失败的项目就是因为责任不明确导致各项目组成员不能协调工作,大大影响了项目的质量或导致项
目完全失败。如果项目组成员之间相互进行实际业务层面的“帮忙”会导致责任不清,影响项目组的
凝聚力!

第 745 页 共 756 页
第 13 章 项目经理核心能力

3、“麦当劳的店长在繁忙人手不够时会主动扫地,因为他们规定是每半小时打扫一次”。----不可
否认麦当劳餐厅里卧虎藏龙,有一批高素质的人才,但扫地相对来说是最简单、最基本的社会工作之
一,大家在家每天都要扫地,不具备项目管理业务中专业化的特点,店长在作好餐厅管理工作的前提
下主动帮助店员扫地也无可厚非!但如果他没有做好自己的管理工作就去扫地,即使地扫的再多他也
不是好店长,可能由于他的管理不善导致其它问题!(不过吃了这么多次麦当劳和肯德基,很多时候
做食品的员工忙不过来的时候都发现其它员工在鼓励他们“加油”,而没有一个人--包括店长--去帮
他们做汉堡或炸鸡翅!)。而在项目管理过程中,项目经理的主要职责就是对项目进行统一规划,根
据项目发展情况在进度、质量、成本三方面之间权衡,做出最佳的选择,协调项目组所有成员按照计
划协调地工作,项目经理甚至可以在技术方面一无是处!如果项目经理过多地投入到细致的业务中去,
就会减少其思考时间,影响其做出正确的选择,将对整个项目产生较大的影响!

-----浅识拙见,欢迎大家讨论!

·首先应考虑内部调整,而不是向外求援(2003-09-03) [作 者] xxanadu [公 司] PS

既然整个项目组有 120 人之多,项目经理 A 又确认 C 的工作确实繁重, 那么 A 应该首先考虑在项目组


内部进行工作调整,平衡工作量。

对于 B,他的问题可能是做技术的人可能都有的通病,认为沟通不是什么真正的工作, 而且确实不
知道 A 每天在做些什么! A 应该加强与 B 的交流, 甚至应该加强一下私人关系, 否则总有类似的
人向领导说反话的话,A 的工作会受到很大干扰。

·要互相帮忙才像一个团队(2003-09-01) [作 者] huangbo [公 司] chief war room

你看麦当劳,一个工作人员看到旁边的队伍人多时,会说:后面的人请到这里来。麦当劳的店长在繁
忙人手不够时会主动扫地,因为他们规定是每半小时打扫一次。不然,一个公司养这么多人干嘛,吃
闲饭吗?

·建立项目管理流程,提高项目管理水平(2003-08-24) [作 者] 周长征 [公 司] 电信公司

看了这个案例后感觉整个项目并不是按照真正的项目运做,本项目的项目经理并不是真正意义上的项
目经理,称其为和用户的接口人可能更确切一些,因为他主要负责与用户的沟通及项目分解,项目前
期完成项目分解后在后期的项目运做过程中其主要职责就是和用户沟通了。之所以任命其为项目经理
不排除公司为了方便其和用户沟通及提高和用户的接口级别。之所以这么说,主要是因为以下几点:
1、项目分工很明确的,但并不合理。项目经理不应该主要负责与用户的沟通及项目分解,而应该对
整个项目的进度、产品或服务的质量、项目成本负责。项目经理所有的工作都应向着一个目标努力,
那就是高效率、高质量、低成本地完成项目用户所要的产品或服务。所以项目经理应该有对整个项目
整体把握的权力,而不只是限于“主要负责与用户的沟通及项目分解”。

第 746 页 共 756 页
第 13 章 项目经理核心能力

2、公司没有建立其真正的项目运做模式。强项目管理型的公司里,老板下面就是一个个项目组,负
责各个方面产品或服务的开发,项目经理直接向老板负责,项目经理对整个项目有绝对的控制权,不
过此类公司少之又少。更多的公司是弱项目管理型的公司。弱项目管理型公司一般也有独立的项目部
负责所有项目运做的管理,并且在某个项目组成立后项目经理对项目部负责,同时公司对项目的管理
也完全通过项目经理进行。而在本案例中“上级领导就此事询问 B 情况”,这是明显的对项目经理不
信任,严重削弱了项目经理的权威,使得项目经理对整个项目的控制力大大减弱,完全打乱了项目组
的人力资源管理和沟通管理,导致项目组分工的混乱。
3、项目经理项目管理不当。项目管理中共有九大管理领域,其中很重要的两个管理领域就是沟通管
理和人力资源管理,其中沟通管理尤为重要!项目运做过程中,项目经理的用户是个很广的范围,可
以说所有与项目有关的人员都是项目经理的用户,包括最终用户、上级领导和项目组成员。项目经理
应该充分和各个方面的用户进行沟通,以便得到所有用户的支持,用户对项目经理进行支持的过程中
就由单纯的用户转化为在做用户的同时也成为了项目经理的资源了!如果本案例中的项目经理充分和
项目组内部的成员进行了充分的沟通,他就可以自己判断 C 是否真的因为文档太多而忙不过来,还是
因为 C 的方法不当、工作效率低导致“忙不过来”。针对自己了解到的 C 的工作状况决定是向上级申
请人力资源还是帮助 C 改进工作方法、提高效率解决 C 忙不过来的问题,毕竟加人要加成本的,项目
经理要对项目成本负责。如果该项目经理和项目成员进行了充分沟通了,项目组成员对整个项目的进
展都比较了解,可以自觉按照计划完成自己的工作,同时也可以了解到项目经理并不是在玩,就可能
避免“每当上级领导就此事询问 B 情况时,B 总是说 C 的工作不算很多,而且 A 的工作比较轻松,让
A 帮助下 C 就可以了,不需要增派人员”的情况。如果该项目经理充分和上级进行了沟通的话上级了
解到其人力资源需求后肯定不会去找 B 了解相关情况。
因此,该项目要顺利地完成,应做如下调整:1、公司要建立起一套正规的项目管理流程。项目管理
是一门博大精深的科学,但要靠制度保证其运做的合理性和通畅;规定项目经理相关权利和责任,明
确公司项目管理制度,在项目经理不渎职的情况下,避免上级顺便干预项目内部事物。2、提高项目
经理各方面素质,确保项目经理满足项目管理要求。

暂说这么多,一家之言。

·好象我没说清楚:)(2003-08-20) [作 者] 孟晓林 [公 司] 网络业务部

ABC 只是这个项目中的三个人员而已,整个项目组成员有 120 人左右,而不是只有 ABC 三个:)

·项目经理应该有权威(2003-08-20) [作 者] 胡勤 [公 司] HEPEC

项目经理应该有权威,如果没有这一点,工作就无法进行;
如果没有权威,要想方法树立,比如,跟 B 谈一谈,他无权干涉和公开评价项目经理的工作。如果无
效,要坚决撤换,而且越快越好!

否则,会影响到一批人,严重危害工作!

第 747 页 共 756 页
第 13 章 项目经理核心能力

·Let's go through the workload of C(2003-08-18) [作 者] Sam [公 司] ABC

看了大家的贴子,很有启发哦!
好象还没有人提到要看看 C 的工作到底有多繁重。让我们看一下。
A 可以帮 C 列一下工作内容,可以进行优先排序、归类等。如项目小应该不会有太多必要的文档。如
确实很多,很繁重,可以拿出来与上级甚至 B 沟通,找到解决办法。
要相信,你的上级领导绝对不希望由于 A 必须分担 C 的工作而影响 A 在项目上的管理。

·理解、沟通!(2003-08-18) [作 者] 马渊鸿 [公 司] 安徽山立

我个人看法:
第一:做为领导下属提出申请增加人员,不应该只问问 B 就可以了,而也应该问问 C,了解一下 C 现
在真正的工作量,充分全面了解以后,才下结论。
第二:做为一个项目经理人,有权力申请加入新的人员,如果是独立核算的项目的话,做为项目经理
会考虑整个项目的运作成本的。
第三:A、B、C 应该相互理解与充分沟通,毕竟做为一个项目团队,理解和沟通很重要,没有这个基
础,我想项目也不会做的很顺利的!

·这么小的团队要多少条条框框(2003-08-15) [作 者] richard [公 司] no

一个就 3 人的项目团队,还要这么多条条框框做什么,大家都得做事,没必要分得十分清楚,能分得
很清楚吗?

·成本控制&资源分配(2003-08-14) [作 者] 刘锡兵 [公 司] Application Solutions

现在我们换个角度来看。如果改项目在公司是独立核算的,项目经理就不得不控制成本——在固定成
本的基础上如何分配资源,或如何优化资源来降低成本。所以,项目经理首先要考虑好分配多少资源
在管理上,多少资源在技术上,多少资源在文档上,多少资源在品保上(显然该项目忽略了这重要的
一项)。在资源分配上,经营的(不是管理的)原则是给多少钱做多少事,否则怎么盈的利润——这
一企业生存的根本。如给你 10 大洋写 1 页文档,你就没有必要去写 10 页,那可要 100 大洋的成本。

A 如果认为资源分配合理,A 就可用事实去说服 B 和上级,达成项目目标共识(这是十分重要的)。


否则,A 就应该重新分配资源。

·如何处理对自己不服气的合作者的关系(2003-08-14) [作 者] 薛文杰 [公 司] BANK-OF-CHINA

第 748 页 共 756 页
第 13 章 项目经理核心能力

A 作为项目经理有权对人员安排提出建议,B 只需作好自己的工作。A 应与 B 进行认真沟通,充分肯


定 B 所做的工作,使他明白项目的成功离不开大家的紧密合作,并向他解释为 C 增加助手的重要性。
按计划顺利完成工作对大家都有好处。

·这就是有中国特色的项目管理(2003-08-13) [作 者] 田京平 [公 司] UNIHUB PMO

A 不必说服 B,只要说服老板。
各人分工不同,PM 需要做具体工作(如文档类)这只是中国特色而已。
用数据说话:任务分解、工时统计...把相关数据给老板看,一幕了然阿。不能因为 PM 的工作看起来
轻松,就要帮助做别的工作。

·纸上谈兵!!(2003-08-12) [作 者] wh [公 司] earth

策略——先仰后抑
首先,肯定 B 的讲求效力,注重资源的充分利用的这一运作项目的核心目的。当然要言之有据,最好
举 B 平常在这方面公认的示例,要赞扬的 B 都不好意思为最佳。
然后,把 c 的困难摆出来,并真诚告诉 B 的对分担 c 的、甚至是 B 的工作的意愿。接下来可以提出几
个当分担 c 的工作与你承担的工作可能发生的冲突以及冲突后的严重后果的问题(最好用反问提出让
B 来解决)。
最后从整个项目小组的利益分析:你去分担工作只能是权宜之计,并不是解决 c 的问题的根本之道(你
的结论已经隐含,切记不要在提,给别人个台阶下)。
注意交流时机、场合。
如果你的风格是民主式管理,相信你会有收获;若是权威式那就更简单,这就不用我了....:)

·理解团队(2003-08-12) [作 者] 韩云鹏 [公 司] 深圳OAKING

目前出现的问题主要有:
1。沟通不畅
不论项目大小,都需要有分工,通过沟通,知道自己与他人都在做什么,并且相互要理解,现在 B
对 A 明显信任不足,觉得 A 不干活。
2。协作精神有问题
如果只有三个人的项目,应该不是大项目,那么,在 A 有时间,C 比较忙的时候,A 可以考虑帮助 C
完成一些工作。因为大家是一个团队,有着共同的目标。不应该总是申请资源

另外,还有。。。。

第 749 页 共 756 页
第 13 章 项目经理核心能力

·一点浅见,与大家分享!(2003-08-11) [作 者] shengliu [公 司] nstars

我觉着出现这个问题的根本的原因,是这个项目组的责权不相适应。对于一个项目来说,为项目最终
负责的人是项目经理,那,也应该赋予项目经理最大的权利。否则,项目经理有名无实,又如何能承
担项目失败的责任之重?不管 A 的工作是否轻松,这无关紧要,因为最重要的是 A 可以很好的管理好
这个项目。而且,也不是说 A 想申请人员,就答应他的要求。要具体情况具体分析。但是,这种分析,
是不应该仅仅简单的问 B 就可以的,因为 B 根本就没有这个资格,B 只要处理好他自己的事情就行了。
所以,碰到这种情况,我觉着这样解决比较好:首先,是 A 应该与上级进行充分的沟通,让上级及时
了解项目的进展情况,让上级明白在项目中 A 做了很多的工作,而且是非常重要的工作;其次是,在
充分了解 C 的实际情况的基础上,若确实需要添加人,则将理由简明、清楚的说明给上级,让上级明
白你不是随便就提出这个申请的;再次,就是,若申请人员成功,则无疑中给这个项目增加了成本,
则这个项目的赢利情况就会下降,相应的项目成功完成后的项目奖金就会受一些影响。最后,一定要
让上级明白,你是这个项目的负责人。这一点非常重要。最后,祝 A 好运!

·看项目规模大小(2003-08-08) [作 者] ziye [公 司] volcano

如果这个项目就 3 个人,b 说的就是对的。项目组达到 10 个人以上才能有专职的管理人员。

第 750 页 共 756 页
第 14 章 项目管理组织

第14章 项目管理组织

14.1 *项目管理部在公司的定位

(一)案例:项目管理部在公司的定位

姓 名: 余锡锋
单 位: kedacom
邮 件: yuxifengmailbox@sohu.com
http://bbs.mypm.net

案例正文:

小 A 是项目管理部的经理,由于公司部门设置的问题,项目管理部既要对项目总监负责,
又要对总经理负责,还要监控各项目组,同时项目组又直接归属项目总监或总经理管辖。这
样项目经理只需要听从项目总监或总经理的话,没把项目管理部当一回事。结果项目管理部
就形同虚设,以至于让高层领导认为项目管理部是一个多余的机构。
本文转自项目管理者联盟

小 A 为了让公司认为自己的部门是有用途的,就开始编制项目管理规范,但由于部门内的
人员都是没多少项目管理经验的人,所以写出来的东西不是太实用。导致执行起来异常的困
难,项目管理规范成为了没有任何用途的规定。
项目管理者联盟,项目管理问题。

现在小 A 非常郁闷:不知道在这种配置下,自己应该做些什么?(这种部门配置不会改变)

(二)项目管理者联盟专家点评

专家介绍:乔东 项目管理者联盟高级顾问,金融 IT 系统项目管理专家

毕业于清华大学计算机科学与技术系,在大型国有商业银行中有多年金融 IT 服务经验,先
后从事过软件开发、项目管理、信息规划等工作,参与、主持过多个大型银行应用系统的建
设工作。在 IT 服务供应商中,作为行业应用顾问,主要负责产品设计、售前解决方案的工
作。2001 年得到 PMP 认证后,将项目管理作为一个重要的发展领域,重点为企业提供项目
管理专业培训、项目管理制度咨询等服务内容,积累了丰富的实际经验。经过多年来的学习
与实践,形成了以企业管理、项目管理、信息工程、软件工程为核心的知识结构。目前的重
点研究方向是“企业级项目管理体系建设”。

乔东点评: 首先要谈一下对 PMO 的理解。目前大家交流中谈到的 PMO,其实是有两种情


况:一种是项目 PMO,主要是单项目管理,当然项目规模会很大,还可能有很多的子项目,
但它是存在于项目生命周期之内的;另一种是企业 PMO,是企业中的一个职能部门,负责
管理企业中此起彼伏的各种各样的项目。在这个案例中所谈到的项目管理部,应该是企业
PMO。

第 751 页 共 756 页
第 14 章 项目管理组织

PMO 作为一种较为新型的职能部门,在企业中的职责定位问题,确实给大家带来了很多困
惑。解决这个问题是有方法的,就是组织设计,流程、角色、职责都是其中必不可少的要素,
可以通过这种方法来设计 PMO 在企业中与其他相关各方(包括总经理、总监)的关系。目
前存在一种思路,就是预先定义 PMO 应该做什么,然后放到企业中再磨合与其他部门的关
系。不过在这个案例中,我认为更应该采取另一种思路,考虑在企业现有的工作流程中,有
哪些工作需要 PMO 来做,用这种思路建立起来的 PMO 更容易被大家接受,对现有的组织
结构冲击最小。

在这个案例中,好像项目已经是该公司中一种很重要的运作方式了。如果是这样,那么 PMO
可以有很大的发挥空间。通常我会将企业中的项目管理分成三级:

●对单个项目的管理,无论项目规模大小,即使大到要在内部建立项目级的 PMO,也都是属
于单项目管理(Project Management)
,项目经理是责任人; 本文转自项目管理者联盟

●处在项目之外的,对各个项目进行监控,在多个项目之间协调范围、进度、资源,这是属
于多项目管理(Program Management),如果案例中这个公司的不同项目间需要这样的协调
和监督,那么这些肯定是 PMO 要负责解决的问题;
http://blog.mypm.net

●如果企业中将项目作为一种生产的组织方式,主要的生产过程都是通过项目的形式完成
的,那么这时 PMO 还可以负责对企业中的项目管理体系进行建设,就像工厂里要设计和维
护生产线一样,例如制定相应的项目管理规范、培养项目管理队伍、维护企业中的资源池、
建立企业级的项目管理信息系统等等,这种 PMO 我更愿意称之为企业级的 PMO,它作为
一个企业中的职能部门,即使当企业中没有项目时,也是有事情要做的。在有的企业中,这
种企业级的 PMO 甚至具有更大的权威,在企业经营管理的决策中要发挥很大的作用。
¬
在这个案例中,很显然小 A 没有找好自己的定位,他的困惑是“自己应该做什么”,各个项
目会向总经理、总监报告,似乎 PMO 已经没有存在的必要了。不过,这种情况也只能说明
在单项目管理中,不需要 PMO 的介入,但并不能说明在多项目管理、企业级项目管理中不
需要 PMO,只是小 A 没有去发掘。 http://blog.mypm.net

从另外一个方面来讲,也反映出了小 A 的管理经验不足。一个很好的 PMP 可以成为一个优


秀的项目经理,管理好单个项目,也可能能够管理好多个项目,但是未必能够做好企业级的
项目管理。这是因为,企业级的项目管理,需要从企业管理角度看项目,需要具有企业管理
的知识和经验,这往往是一般的 PMP 所不具备的,这也是现在不少企业级 PMO 不能取得
最终成功的深层原因。在我的经验中,要做好企业级 PMO 的管理,需要具备的知识结构要
有企业管理所需的财务管理、人力资源管理、营销管理、产品管理、运营管理等一系列知识
和经验,然后再加上对项目管理的精通,将项目管理的优点融入到企业管理的方方面面,使
项目管理体系与企业的经营管理有机地融为一体,不仅能够很好地服务于各个项目,更能够
为老板们提供真材实料的支持,这才是一个成功的企业级 PMO 的管理者。

明确了 PMO 的定位,拥有了具备适应知识结构的管理人员,剩下的就是沟通技巧的问题了,

第 752 页 共 756 页
第 14 章 项目管理组织

一定要学会“销售”自己的观点,成熟的经理人都应该具备这种技能。 http://bbs.mypm.net

当然,上述这一切都是建立在企业需要 PMO 的前提之上的。

(三)项目管理者联盟网友评论 http://bbs.mypm.net

题 目:做出工作才能说明问题 作 者:龙七

这种情况需要领导的重视,同时需要做很多准备工作。让项目管理部的作用体现出来,不要
等待领导和项目经理的观念转变,而要通过实实在在的工作让大家认可!
项目管理部发布任何制度时要做好充分的调研,做到能结合实际,具备可操作性和价值。

题 目:踏踏实实工作 作 者:一孑

从其他方面谈一下: http://bbs.mypm.net

1、项目管理部最初肯定有职能划分,但随着公司的运营,项目管理部的职能已经发生了变
化,或者说是已经弱化。这其中多半是由于项目管理部自身的原因造成,故建议当前你可以
从项目管理部做出的贡献入手,而不是公司所期望的角度入手,无论是什么,只要有价值必
定会被公司认可。
2、从目前来看,项目管理部具备更多的是服务型职能,不要考虑当前项目管理部所具备的
权力,应更多的考虑项目管理部可为项目或项目组提供什么样的服务,以帮助他们完成项目。
只有得到别人的认可,才可明确自身的价值。
3、规范是帮助管理的,如果无法帮助管理,规范很难得到推行,更何况当前项目管理部还
缺少真正有经验的人员,所以,应该从实际可行的地方入手,或者说规范可以不用制定的那
么全面,哪怕是一个点,只要可以帮助管理就可以。
公司认为项目管理部是否有用并不是很关键,关键是你自己是否认为项目管理部可有可无,
并且从更高的角度你是否可以说服自己,证明项目管理部是有价值的。 本文转自项目管理者联盟

题 目:准确定位,专业管理 作 者:林林

公司将各项目组直接归属项目总监或总经理管辖,导致项目经理只听从项目总监或总经理的
话,不把项目管理部当回事。这是本案例问题的关键。
为此项目管理部有必要对自己进行准确的定位。我认为可以定位为:协调公司资源在各项目
的分配,对各项目进行监督评价和提供专业管理咨询辅导的机构。 项目管理者联盟,项目管理问题。

http://bbs.mypm.net

题 目:对项目管理部职责的补充 作 者:邓俊

项目管理部的职责,主要有: http://bbs.mypm.net

1、项目管理规范的制定
2、项目情况的监督与汇报 项目管理者联盟,项目管理问题。

3、各项目组之间的协调

第 753 页 共 756 页
第 14 章 项目管理组织

但似乎还有更重要的职责我们没有提到:
1、理解并贯彻公司长期和短期的方针与政策,用以指导公司所有项目的开展。
2、组织公司项目经理的沟通交流与培训工作,同时注意培养项目经理的后备人选。

从以上的职责我们可以看出,这些职责其实已经有机构在执行了,项目管理部的存在确实存
在很大的挑战,他不属于填补空缺,而是一种整合。
项目管理规范的制定与项目情况的监督与汇报有质量保证部门完成;
各项目之间的协调有经理完成;
理解并贯彻公司长期和短期的方针与政策,用以来指导公司所有项目的开展工作有董事会完
成;
组织公司项目经理的沟通交流与培训工作有人力资源部完成;
所以,在本案例的情况下,项目管理部要证明自己有存在的价值和意义,这样才能在公司有
立足之点。
我个人认为承认项目管理部是一个必然趋势,就象现在的质量保证部门一样,当初也被认为
是一个可有可无的部门,现在不也得到了大家的认可。正如大家所认同的,一开始的工作肯
定是非常艰难的,而且需要你坚持不懈的工作,受委屈是难免的事情,好事多磨,加油干吧!!

题 目:职责的划分 作 者:任鹰

我认为,本案例要解决的最为重要的问题是:如何界定项目部的职责、权利及项目部能够给
项目组做些什么?
对于总经理或项目总监来讲,他们自然会关心各个项目的运作情况,因为项目对于企业来讲
至关重要,是企业生存和发展的基础和前提条件,他们的关心并不为过。项目部应该反思自
己的工作。 本文转自项目管理者联盟

(1)应该同总经理沟通明确项目部的责权利,并下发各个项目组和各个部门。这是项目部
展开工作的基础和依据。 项目管理者联盟,项目管理问题。

(2)项目部应从工程的实际出发,制定适用于工程的规范、标准,并深入到工程现场,解
决现场的困难和问题,赢得项目组的认可。
(3)项目部应充分和各项目组沟通,获取各个项目组的所有信息,然后定期向总经理、总
监汇报,提供给他们需要的信息,建立起项目部的威信。

题 目:项目管理部应做好公司领导和项目组之间的协调和联动工作 作 者:Aaron
首先项目管理部要明确自己的定位,当初成立本部门的目的是什么?项目管理部要从具体的
项目组工作中跳出来,要从众项目组全局出发,把握整体项目的进展,指导各项目组之间沟
通、协调、合作。达到各项目组之间资源的共享,组织好项目组的工作和生活,使得项目成
员身心愉快的投入到项目建设中。并从全局角度监控各个项目的进展和质量。项目管理部要
向领导汇报总体项目的进展和存在的问题,以及需要公司领导出面协调的难题。让公司领导
在大局中能够清晰的了解到项目的总体状况。这些才是项目管理部应该做的事情。

题 目:自己没有起到作用,不应该埋怨别人 作 者:daijiangbao http://blog.mypm.net

要针对每个项目建立基于项目的组织结构,定义基于项目的报告级别关系,获得各方面的一

第 754 页 共 756 页
第 14 章 项目管理组织

致认可,是解决这个问题的关键。总体说来还是沟通问题,成立项目管理部门而没有融入到
项目中,只能是浮在表面的管理。

题 目:项目管理部的作用? 作 者:teresa

公司部门设置里既然有项目管理部的存在,自有它的部门说明及职责所在吧。该做什么?起
什么作用?

项目管理部可有可无,是不是没有发挥出应有的作用。对于规范,竟然看到,小 A 自己编
制一个规范,还是不懂的人写出来的,有些惊奇!公司设置项目管理部门,连项目管理规范
都没有,如何管理?什么人组成项目管理部门,没有门槛吗?难道只是低级的收集项目一些
数据,向领导汇报而已?那就没有必要成立一个部门了!

项目管理部门和项目组隶属项目总监或总经理,没什么不妥,项目管理部门只是监控项目,
对收集到的数据做分析,提醒项目组,并向领导汇报,一个监控部门而已。组织项目的阶段
及里程碑评审,其实这是项目管理部门的一个重要工作,不知道能否做到?

没有话语权,没有经验,做起来没人搭理很正常。大概估计,公司的项目管理应该属于低级
阶段,一切还得从头做,编制规范,需要向上陈述规范管理的必要,争取领导支持,向下阐
述规范管理的好处,希望项目组配合,当然这个配合需要挟天子而令诸侯,最好能够挂钩到
项目绩效考核中。如果没有绩效考核,就向上提出对所有完成项目做评估,由项目管理部和
项目总监共同完成,评估完成后将结果抄送所有领导。

还有规范的编写,需要和了解公司项目的人聊天讨论,制定出初稿,再找相关人士确定,然
后以公司之名在公司开始试行,根据反馈不断修改,直至正式确定。执行力度,需要借助领
导之力。

很多时候,可能都不如意,但是每一步都要细致准备和积极推进。无序的状态,谁也不愿意
看到!不要责怪外部环境,想想自己做了多少?

第 755 页 共 756 页

You might also like