做梦打蜘蛛是什么意思:项目管理实例（转）

项目管理实例

项目管理实例（1） － 不一样的PMO

所在公司是一家软件公司，主要为电子行业、航空航天等军工企业提供信息化产品和服务。老板受他本人在制造业工作经历的影响，把一个软件公司的组织结构设置得如同工厂，几乎每项工作都是一个部门只承担一部分，不允许参与其他工作。比如售前阶段，工作说明书是咨询部负责完成，合同签订后，转到实施部，实施部的项目经理和业务顾问到客户那里进行业务调研工作，编写出业务调研报告和业务需求说明书，通过评审后才能继续传递文档至下游，下游是设计部，负责需求分析和概要设计，再下面是开发部，负责详细设计和编码.。。。。。。老板想得挺好，可是最大的问题很快就来了，软件过程中的文档很难标准化，评审难有标准。而各个环节都希望上游的产出物一定要满足下游的输入要求才行，否则下游的部门就不接！，因此，设计部埋怨项目经理和业务顾问写的业务需求不够详细，不够准确，没法做需求分析，评审一次次通过不了，同样道理，开发部门死活不认可设计部的架构师写的需求规格和概设，认为不能指导详细设计和编码工作，而架构师又认为他们只负责需求分析和概要设计，开发部要求的那些事都应当开发人员自己完成。。。。。。项目经理除了自己要写业务需求外，整天都在协调、协调，下游环节的部门不接受上游部门的产出物，项目经理也难以判断该不该传到到下一棒，需要协调的事情特别多。何况他们的文档也常常被别人狂批，似乎自己也没协调的资格。

公司前几年合同项目不多，主要精力放在做产品上，但即使是产品开发，产品经理的业务定义同样也很难往下传递。

一个项目组由各个部门的人组成，无论是产品经理，还是项目经理每推动一步都很费劲，各个部门扯皮的现象层出不穷。就是在这种情况下，老板设想成立一个公司级的综合管理部门，将公司主要的骨干，如项目经理和产品经理集中到1个部门，进行总协调和总负责。这个部门被赋予了相当大的权利，因为老板希望找一个“强势”的人能好好替他“管一管”。本人就是在这样的背景下走马上任的。我的部门被设置为PMO，与一般公司的 PMO不同，我直接领导项目经理，而且无论何人，不管是哪一个部门，什么职位，只要担任项目经理，就都归我领导。项目经理管理和考核着不属于同一个部门的的组员，即使组员是其他部门经理，甚至是技术副总监，也仍然归项目经理领导和考核。因此，本人是一个名副其实的PMO (Officer的O,不是office的O) ，管理和掌控公司所有的项目和产品，

其实不光是我们老板，业界推行CMMI，很多公司都梦想搞“软件工厂、软件蓝领、流水作业。。。。。。从上世纪90年代年开始，我呆过的、咨询过的、售前接触过的软件企业应该不算少了，还没见哪家企业能真正做到将软件开发过程搞得跟生产制造过程一样呢！但我所在的公司就是这样一个组织结构和管理方式，这样的管理方式带来了无数的质疑和争论，可是我们现在谁都无力从更高的层面去说服老板，因为谁也不敢说换一种管理方式就一定会比现在好，因为这种方式虽说协调的事情多一些，效率低下一些，但是却保证了一个项目由多人参与才能完成，因此某个人离开对项目的影响不会太大。到底怎样才更好，也许时间可以证明一切吧。

一年半过去了，最多的时候公司同时做着近20个项目，都是百万级的纯软件项目。真把我累坏了，涌现出了各种各样的问题，有失败的教训，更多的还是成功的经验。有些项目经理是我新招的，有的是公司老员工，随着一个一个问题的解决，项目经理们乃至我本人都提升了很多很多。。。。。。更多的结论只能从实践中产生，而不应去主观推断。下一篇首先谈谈“选拔项目经理的体会”

项目管理实例（2） － 选拔项目经理

“十一”长假前，公司格外忙碌，倒都是令人高兴的事情多，两个项目验收通过了，一个项目的实施方案经过艰难的协调客户也签字认可了。回想各个项目的过程，选拔一个合适的项目经理起着至关重要的作用。甚至可以说，选对人，项目就成功了一半。

刚刚验收通过的这个项目，我恰好体会了在选拔项目经理上的失败和成功。该项目2008年初启动，客户在四川地区，4月份刚刚做了一个简单的业务调研，5月份正要去呢，赶上大地震，就一直耽搁到08年11月底才又重新启动， 原先的项目经理也走了，我只好指派了一个新招聘的项目经理。姑且称他为G君，30多岁，一家大型知名企业过来的一位项目经理，自称做过100多个项目，能说能写。符合公司选拔项目经理的基本条件：阅历够、年龄正好、知名企业背景，就下决心用了他。

项目组刚一成立，现场前的准备工作就让我对G君有些失望。比如项目启动会的PPT和项目总体计划基本照搬其他项目，搞得我很生气。项目启动会是很重要的一个活动，客户高层参加，我们应当借此在启动会上给客户灌输一下我们软件产品的理念、信息化成功的要素等等。启动会的PPT公司会有一个比较通用的，但是每个项目都会有所不同。即便他是新员工，既然做了项目经理，现在也该下功夫熟悉并理解其内容，应当讲起来特别熟练。G君倒好，结结巴巴的，对着PPT都能说错，让我一问两问，就更不知要说什么了，还好意思说PPT上的内容他也不清楚！我大光其火，决定不让他在启动会上讲演这个 PPT，实在不行，小范围跟客户讨论一下即可。如果讲演不能增添光彩，就不如不做。另外，G君显得对公司的项目流程很不适应，总在强调他以前的公司怎么做怎么做，这种表现令我更加担心，每个公司都有自己的项目流程，但大同小异啊，总之都是要执行项目合同，对于一个老手来说，熟悉一下新公司的流程有这么费劲吗？

面对我的疑问。G君以刚来公司不久，对业务不熟悉造成的，我有些反感。因为有些跟项目本身的业务领域是无关的，完全是工作经验和能力问题。也是很巧，恰好另一个项目的项目经理也是我新招来的，人家一上任，就显示出项目经验、组织能力。不过，用人不疑，我还是挺支持他的，在大会小会都强调项目经理的绝对权威，要求项目组全力配合他。

按照项目流程，G君需要带领一个调研团队去客户现场工作，然后回来写业务调研报告和实施方案，经过客户确认之后，才算是真正开始做这个项目了，售前的时候虽然也做过需求调研，形成了工作说明书，但是毕竟还比较粗。因为对他有些不放心，我给他配备了精兵强将，该项目所依托产品的产品经理，老H，40岁了，经验丰富，最好的实施工程师，小Z，还有1个也是新员工，L君，也是新招来的项目经理，只是工作经历没有G君丰富。

他们到了现场之后，就遇到了意想不到的事情，在家里精心准备了调研大纲、调研计划，没想到似乎用不上了。客户提出2008初已经做过调研，此次的重点希望放在实施方案上。公司的销售总监在客户现场也是希望尽快评审实施方案，这样公司就可以收款了。其实这本来也是好事，该项目是以公司的产品为基础做的，二次开发工作量不是很大。客户不要求再做全面的调研，那么我们重点放在客户化的需求就是了。但是G君明显就有点抓狂了，原定计划一打乱，他就不知道该怎么办才好，发来的计划根本没有可操作性。我多问两句，又紧张，只会口头再三保证没有问题，让我放心。我要求他分一下组，一组写实施方案，一组调研客户化需求。四川那么远，那么多人去一次不能只做一件事。为了尊重他，我始终没有去直接指挥其他项目成员，只是建议他让老H牵头写实施方案，协助。实施方案顺利通过了客户的评审，但项目组回来后，老H、小 Z、L君都跟我汇报，说G君没起到项目经理的作用，我分别找他们了解现场情况，大致得到的情况是：

1、没有调研到明确的客户需求，只是将以前已调研到的做了确认；

2、现场调研活动主要以老H为主要提问人，小Z为主要补充提问人。G君在现场基本插不上话；

3、现场工作过程中没有阶段性的详细计划，对于双方的工作安排以及相互配合没有很好的统一规划协调；

4、每天的调研情况没有及时讨论汇总；

5、没有对第二天工作的安排和预期；

虽然实施方案通过了，可是客户化的需求一点没了解到，还得再去一趟才行！看到这样的结果，我第一次产生了换人的念头！

项目管理实例（3）－换将

临阵换将，乃是“大忌”。尤其是公司前两年吃过这个亏，特别是项目经理一旦在客户那里亮了相，即使有千万种客观原因，总是影响很差的。 我开始反省自己的失误，当初选用G君时，我也征求过一些人的意见，包括产品经理、开发部经理、技术总监等。由于G君刚来，大家都不太了解，接触最多的其实就是本人了。当时我的印象是：他文质彬彬的，很爱学习，能写报告，也爱提建议。这些反映出他是有一定能力的，但是他也有比较大的缺陷，最要紧的是不能很快融入到公司的氛围中，和他同时来的3位同事，年龄和资历也差不多，但是人家3人很快和老同事有说有笑，打成一片。而且我感觉他虽然能写，爱写，但内容较为空泛，似乎比较急于担当重任，而没有扎下去切切实实了解公司。本来我是很犹豫的，但还是看中了他的“资历”，又觉得无人可选，只好用了他。其实项目组成立后，有将近两周的时间在公司里做准备，还没去客户现场。这段时候他已经表现出很难胜任的一面，可我当时不敢下决心，现在，他已经去过客户那里了，再换会有什么负面影响？他不行，又换谁呢？如果当初有人合适，也许我就不会用他了呀！

为了慎重，我找G君长谈了一次，请他自己总结一下他的工作，能不换还是不换把！没想到这次谈话反倒让我下了决心。因为G君认为他之所以没有有效得领导调研组，是因为他过分尊重老员工，没有要求其他人每天给他写日报，因此没有建立起权威。我反问他，写日报的目的是什么？你们4个人天天都在一起，难道你还不清楚每个人的工作情况？为什么老H把实施方案都写出来了，他为什么连依据实施方案写个PPT都不能，最后连讲解PPT推给老H, 这样又如何建立威信？

面对我有力的质问，G君也只好承认是他自己信心不足，怕出错。可是当我又问到此前他可是给我说我们的产品无非就是个项目管理工具，他接触过无数这样的产品，并且都推广实施和应用过，退一万步说，即便不如老员工熟悉本公司的产品和项目流程，作为一个项目经理，哪怕不睡觉也得尽最大努力熟悉这些，也得鼓起勇气做这个讲演。因为我知道，风险并不是很大，客户基本接受我们的方案，只是需要开个评审会而已。他如果敢上台去讲，真的有点问题，老H，小Z 他们也在现场，是可以作些纠偏的。作为一个自称做过100多个项目的项目经理，连这点形势都判断不出来？也许我有点咄咄逼人，G君有些不好意思，但还是表示以后会改进工作，会大胆一些，可是他的重点依然在要“大胆”管理上，丝毫没有认识到他自身的问题。

不过我已经开始考虑其他人选了，这才只是刚刚开始做调研，还是同一个部门的同事配合他工作，他都无法树立起威信，到了研发阶段，组员都不属于本部门，将来他怎么去领导，怎么去协调呀？而我判断就他的表现，客户也不一定对他会较深的印象，果然，当我了解到客户对调研组的印象后，最后一个顾虑也消失了，虽说做了团队介绍，但没想到在现场呆了两周后，客户居然没太搞清谁是项目经理！这是个机会，意味着我必须要在再次去之前替换好项目经理，否则以后就无法更换了。

这次我不能一错再错了。老H当然好，但是他是那么重要的一个产品经理，不能顾了项目就不顾产品。何况做产品和做项目还不一样，做项目经理需要有魄力，应该爱张罗，老H说话小声小气，又不爱管“闲事”。于是我的眼光对准了小Z,小Z虽年轻，却是公司的老实施工程师了，跟过好几拨项目经理。作为一个大专毕业生，在公司很难有做项目经理的机会，但他却一直梦想有一天做项目经理，自己在底下努力学习项目管理理论知识。小伙子言语精炼，做事有思路，胆子大，只是文字能力稍差。另有一个人，跟他们一起去的L君， L君思路清晰，理解能力很强，沟通能力也不错，缺点是稍显腼腆且也是新员工，这次调研，老H是他师傅，L君抱着学习的态度，G君又不会策划和安排L君的工作，因此没发挥出作用，但我相信他的能力，如果给他机会，是可以显示出来的。综合分析了之后，我果断决定，由小Z出任项目经理，L君配合，再次去客户现场调研需求。用小Z最大的好处是后面的实施不用操心了，用L君还要操心后面的实施。

这是一个大胆的安排，按照公司以往的规矩，宁肯用L君，也不会用小Z。经过了反复权衡，我作出了决定。幸好老板比较信任我，就这么定了。

由于把各种可能遇到的麻烦都考虑到了，接下来的事情居然很顺利，和L君两个人去了几天，就调研清楚了客户的需求，甚至连业务调研报告都在现场写得差不多。再以后，L君有了其他重任，小Z独立承担起项目经理的职责，期间也遇到很多事情，如两个月内出现3次事故（见“错误重复在犯一文），突然要求提前一个月完成任务，组织开发团队加班、最后的验收过程中又冒出客户要评审费等等一系列事情，尽管小Z的确缺乏管理经验，但是他懂得依靠大家的力量，该找我的找我，该找项目组成员的会主动跟人沟通。就这样，这个项目顺顺当当得做了下来，已经通过验收了！

项目管理实例（4） － 加人一定管用吗?

从我进入到软件行业以来，经常见到项目经理喊人手不够，无论是几年前做CMMI咨询，还是回到企业做管理，无论是当初咨询过的客户，还是眼前所供职的这家公司，似乎都是一样的，项目经理汇报工作，好多问题最后都会归结到“没人做哪，人不够啊”，都在向领导要资源，要求加人！这只怕也是做软件项目最常见的现象了，但是加人真的就一定管用吗？

公司有两个项目非常“典型”，应该能回答这个问题。   

一个项目是一个咨询项目，合同额不大，但由于是公司第一个正儿八经的咨询类项目，且又是公司正在拓展的业务领域，所以公司是高度重视的，但是这个项目的过程和结果让我们这些管理者感到很惭愧，项目过程几乎完全失控，不断得追加人，结果搞成个烂摊子，犹如楼市里的“烂尾工程”，最后临到验收了，还耗费公司一堆人熬通宵修改文档的低级错误。（见前文“项目总结－文档常见错误”》）项目搞成这样，虽然有很多客观和特殊原因，也很难说清是哪个人的责任。但是盲目答应项目负责人追加人手，没有“狠下心”来堵住这个口儿，却是其中很重要的一个因素，令本人记忆深刻。

这是一个质量管理信息系统规划的项目，输出成果就是一篇规划报告。客户是军工企业的质量保证部门，要求我们调研他们的信息化现状之后提出建设规划。

按照原先的设想，这个项目两个人半年应该就差不多，一个业务顾问可兼做项目经理，一个系统架构师负责技术部分文档编写。一开始是这样安排的，但人员刚一确定，他们就提出，质量信息化范围很大，需要多方面的人才，任务又紧，仅有两个人不够。我和其他相关领导商量，分析这个项目有一点特殊性，就是公司以前未做过质量管理信息系统的项目，多放些人也可以让更多的人学习和锻炼。不过，风险是有的，在质量管理这个业务方向上，咨询、产品、研发3条线上的人经验和相关背景虽然都有，但是各自有各自对业务的理解，谁也不能说服谁，公司没有这方面的“权威人士”，相关的产品也因此一直进展相当缓慢，我常感叹，不知“真理何时才能越辩越明”？万一做起项目来，也是这样，可怎么办哪？

事实证明，我们的忧虑不无道理，更没有想到的是，由于种种原因，后来我竟然无力掌控这个项目。

客观得说，这个项目虽然小，要求看似简单，却实在是困难很多，项目组需要投入很大的精力去学习新知识，熟悉新业务。客户那边又都是些经验丰富的人士，我们这边是一遇到压力，就心里发慌，就希望多个人来共同学习和研讨，提出的理由貌似充分无比，于是，开始加到4人，然后5人，6人，最后一直到7人。就一篇规划报告，一会儿按照这个思路写，一会儿又推翻，后面参与的人写的东西，前面的人认为不行，但是前面的人也说不出来究竟什么地方不行，最要命的是对于一个有160多页、8大部分的报告，各部分之间有关联，参与的人越多，前后矛盾的地方就越多，就越难一致起来，因为大家的理解不一样嘛，争吵、沟通、调解矛盾、互相推诿、返工重写成了该项目的主旋律，就是始终在客户那里交不了稿。本该去年年底交货，直到今年5月才勉强通过验收。这个项目论投入产出比，公司可是亏大发了。而且拖得项目组人人筋疲力尽，到了后期，当初兴致勃勃参与该项目的同事个个都恨不得离这个项目远些。

这个项目失败的教训是深刻的，我可以总结出很多很多，比如类似的项目公司就不该去做，比如商务运作应该更积极一些，比如不该请外部专家指导没啥用，反倒耽误了时间，自乱了阵脚，。。。。。。等等。在项目管理上更是漏洞百出，但是有一点，我常常反思，这样的项目，如果当初就坚持只放两个人呢？其结果不见得会比现在好，但至少不会比现在更差吧？增加了那么多人，最后实际干活的，不还主要靠这两个人吗？这两人期望靠别人不也没靠上吗？在已经很清楚无论怎样都很难高质量完成任务的前提下，多增加人手不是添乱吗？

项目管理实例（5）－2009年终盘点

　终于做完了年终总结，看着所有的项目数据，感慨万千，2009年发生了太多的事情，几乎每个项目都会有几个小故事，小磨难。尽管有诸多不如意，但是大家毕竟做了那么多事情，沉甸甸的数据证明了满满的收获。

　　我对数据做了一些分析，发现一些比较有意思的事情：

　　1、同时做两个项目的项目经理比只做一个的要做的好；

　　当然不是同时做的事情越多，就会做得越好。一定是表现突出，能力较强的人才会被委以重任。这两位项目经理，都是在做第一个项目做到一小半时，同时接下了第二个项目。但当时能接下这两个项目的并非没有其他人选，年龄、资历、经验也都差不多。我本来也是打算指派其他人的，但是这个时候老板显示出了高人一筹的用人策略。本人更多得是考虑他们工作量太大，压力太大，其他人相对空闲一些，而缺乏更高层面的思考，那就是从业务角度看，这些项目之间的相关性比较大，用同一个人，同一个团队做关联紧密的两个项目，会有很多意想不到的优势，从实际效果来看，我是很佩服老板的。

　　2、“自称”不懂技术的项目经理比熟悉技术的项目经理做的好；

　　几位“自称”不懂技术的项目经理，大部分精力都放在业务和管理上，技术实现完全信任开发经理，结果开发经理干劲十足，主动替项目经理考虑了很多问题，大家配合得也很好。我们有一位懂技术的项目经理，业务也很精通，自身能力和水平都很高，总是看不上那帮设计人员、开发人员。可惜，他的团队只能建立在公司现有的基础上，不可能为一个项目去招他眼中的“高手”，加上公司特有的项目组织结构，开发人员有自己的部门，整天跟这个项目经理吵架，闹得鸡飞狗跳的，过不上十天半个月，我们这些做领导的就得给协调一次，引出了无数的故事，唉。

　　事实上，精通技术肯定比不懂技术要好，问题的关键在于身为项目经理，不能再以技术人员的眼光去看待项目，业务、商务、技术、甚至法务上的事情都需要考虑。

　　3、研发（非现场）投入最大、现场投入也最大的项目，缺陷最多；

　　公司有个“天条”，绝对不允许在客户现场修改代码，所有的代码开发都只能在公司内网进行，出内网还要走复杂的流程。有个项目，项目经理一直声称，他们宁可在家里将工作做扎实一些，这样到了客户那里，就可以节省时间和成本。结果事与愿违，就他们项目组在客户现场的工作迟迟结束不了。

　　我想，这也只是表面现象，并不能说明什么问题，非现场和现场投入之间并不一定有什么特别的关系，问题还是在于项目经理缺少大局观，想到第一步，没想第二步。

　　4、所有项目都是进入内部研发阶段，进度控制不错，而只要有客户参与，进度就无法保证，但平时几乎所有项目经理都叫嚷“和客户打交道容易，内部协调最烦”；

　　这是一个出乎意外的事实，由于公司的矩阵式管理，由于公司以流程管理为核心，事事都要走流程，很多人都在发牢骚，教条，形式主义，等等。但数据会说话，证明就算内部管理有问题，还是项目经理们推动客户的能力更需要加强。

　　5、提前一个月给客户安装上线，最后验收仍然拖后3个月！

　　更加证明了推动客户的能力是多么欠缺！