项目管理实例—— 点评
在MSN项目管理群里,一位很资深的IT工作人员推荐她的博客,我粗看了一下确实不错,准备每篇阅读一下,当然也希望通过点评一下来提高一下自己。该文章是作者对项目管理实例进行的相关思考。
项目管理实例(1) - 不一样的PMO
http://blog.csai.cn/user2/50754/archives/2009/39793.html
http://blog.csai.cn/user2/50754/archives/2009/39793.html
项目管理实例(2) - 选拔项目经理
http://blog.csai.cn/user2/50754/archives/2009/40050.html
http://blog.csai.cn/user2/50754/archives/2009/40050.html
项目管理实例(4) - 加人一定管用吗?
http://blog.csai.cn/user2/50754/archives/2009/40345.html
http://blog.csai.cn/user2/50754/archives/2009/40345.html
项目管理实例(5)-2009年终盘点
http://blog.csai.cn/user2/50754/archives/2010/42082.html
http://blog.csai.cn/user2/50754/archives/2010/42082.html
首先是PMO的产生
所在公司是一家软件公司,主要为电子行业、航空航天等军工企业提供信息化产品和服务。
1、老板受他本人在制造业工作经历的影响,把一个软件公司的组织结构设置得如同工厂,几乎每项工作都是一个部门只承担一部分,不允许参与其他工作。
2、比如售前阶段,工作说明书是咨询部负责完成,合同签订后,转到实施部,实施部的项目经理和业务顾问到客户那里进行业务调研工作,编写出业务调研报告和业务需求说明书,通过评审后才能继续传递文档至下游,下游是设计部,负责需求分析和概要设计,再下面是开发部,负责详细设计和编码.。。。。。。
老板想得挺好,可是最大的问题很快就来了,软件过程中的文档很难标准化,评审难有标准。而各个环节都希望上游的产出物一定要满足下游的输入要求才行,否则下游的部门就不接!,因此,设计部埋怨项目经理和业务顾问写的业务需求不够详细,不够准确,没法做需求分析,评审一次次通过不了,同样道理,开发部门死活不认可设计部的架构师写的需求规格和概设,认为不能指导详细设计和编码工作,而架构师又认为他们只负责需求分析和概要设计,开发部要求的那些事都应当开发人员自己完成。。。。。。
项目经理除了自己要写业务需求外,整天都在协调、协调,下游环节的部门不接受上游部门的产出物,项目经理也难以判断该不该传到到下一棒,需要协调的事情特别多。何况他们的文档也常常被别人狂批,似乎自己也没协调的资格。
所在公司是一家软件公司,主要为电子行业、航空航天等军工企业提供信息化产品和服务。
1、老板受他本人在制造业工作经历的影响,把一个软件公司的组织结构设置得如同工厂,几乎每项工作都是一个部门只承担一部分,不允许参与其他工作。
2、比如售前阶段,工作说明书是咨询部负责完成,合同签订后,转到实施部,实施部的项目经理和业务顾问到客户那里进行业务调研工作,编写出业务调研报告和业务需求说明书,通过评审后才能继续传递文档至下游,下游是设计部,负责需求分析和概要设计,再下面是开发部,负责详细设计和编码.。。。。。。
老板想得挺好,可是最大的问题很快就来了,软件过程中的文档很难标准化,评审难有标准。而各个环节都希望上游的产出物一定要满足下游的输入要求才行,否则下游的部门就不接!,因此,设计部埋怨项目经理和业务顾问写的业务需求不够详细,不够准确,没法做需求分析,评审一次次通过不了,同样道理,开发部门死活不认可设计部的架构师写的需求规格和概设,认为不能指导详细设计和编码工作,而架构师又认为他们只负责需求分析和概要设计,开发部要求的那些事都应当开发人员自己完成。。。。。。
项目经理除了自己要写业务需求外,整天都在协调、协调,下游环节的部门不接受上游部门的产出物,项目经理也难以判断该不该传到到下一棒,需要协调的事情特别多。何况他们的文档也常常被别人狂批,似乎自己也没协调的资格。
——点评
这个是分工过于职能化的恶果,需求和文档在内部过程中已经失真了,且由于职能化的原因,内部无法达成一致,除了问题只能相互推诿扯皮,缺乏一个整体协调机关
如果采用项目组型会怎么样呢?人员无法得到充分利用,项目内部的各个环节质量取决于项目经理的素质,也会造成一定的问题
想必这也是各个公司PMO产生的主要原因之一吧。
一个项目组由各个部门的人组成,无论是产品经理,还是项目经理每推动一步都很费劲,各个部门扯皮的现象层出不穷。就是在这种情况下,老板设想成立一个公司级的综合管理部门,将公司主要的骨干,如项目经理和产品经理集中到1个部门,进行总协调和总负责。这个部门被赋予了相当大的权利,因为老板希望找一个“强势”的人能好好替他“管一管”。本人就是在这样的背景下走马上任的。我的部门被设置为PMO,与一般公司的 PMO不同,我直接领导项目经理,而且无论何人,不管是哪一个部门,什么职位,只要担任项目经理,就都归我领导。项目经理管理和考核着不属于同一个部门的的组员,即使组员是其他部门经理,甚至是技术副总监,也仍然归项目经理领导和考核。因此,本人是一个名副其实的PMO (Officer的O,不是office的O) ,管理和掌控公司所有的项目和产品,
——点评
这是一个比较强势的PMO,直接划为一个部门,项目经理比较强势,而PMO更加强势。
我预想的PMO会比较温和一些,由资深的PM和各职能部门经理组成。
制定公司软件工程和项目管理流程、制定公司文档管理制度。
对项目的软件生命周期、项目风险等进行指导
对项目经理进行考核
对软件过程进行监控和度量
制定公司软件工程和项目管理流程、制定公司文档管理制度。
对项目的软件生命周期、项目风险等进行指导
对项目经理进行考核
对软件过程进行监控和度量
对项目中遇到的问题进行评估,协作提供解决方案和再分配
关于选拔项目经理
1、没有调研到明确的客户需求,只是将以前已调研到的做了确认;
2、现场调研活动主要以老H为主要提问人,小Z为主要补充提问人。G君在现场基本插不上话;
3、现场工作过程中没有阶段性的详细计划,对于双方的工作安排以及相互配合没有很好的统一规划协调;
4、每天的调研情况没有及时讨论汇总;
5、没有对第二天工作的安排和预期;
作者认为该PM业务不熟悉、对公司项目流程不适应、项目准备不够充分等等。
其实我的想法是该PM业务不熟悉是正常的,刚工作的项目经理显然无法同有此经验的技术人员相比,项目经理也是需要通过项目不断去熟悉的,也有个熟悉的过程
该PM对公司项目流程不适应,这也很正常,一般而言从大公司出来的PM与从小公司出来的PM相比,适应性要差一点,为何,在大公司项目流程已经很规范了,他只需要follow即可,而小公司往往缺乏流程,或者需要自己去慢慢摸索和了解;最好的办法是培训。
项目准备不够充分和多方都有关系,但是自信是必须的。
作为PM也需要在不断的学习和摸索中成长,无论大公司还是小公司出来的PM到了一个新环境都会面临这个问题。
1、没有调研到明确的客户需求,只是将以前已调研到的做了确认;
2、现场调研活动主要以老H为主要提问人,小Z为主要补充提问人。G君在现场基本插不上话;
3、现场工作过程中没有阶段性的详细计划,对于双方的工作安排以及相互配合没有很好的统一规划协调;
4、每天的调研情况没有及时讨论汇总;
5、没有对第二天工作的安排和预期;
作者认为该PM业务不熟悉、对公司项目流程不适应、项目准备不够充分等等。
其实我的想法是该PM业务不熟悉是正常的,刚工作的项目经理显然无法同有此经验的技术人员相比,项目经理也是需要通过项目不断去熟悉的,也有个熟悉的过程
该PM对公司项目流程不适应,这也很正常,一般而言从大公司出来的PM与从小公司出来的PM相比,适应性要差一点,为何,在大公司项目流程已经很规范了,他只需要follow即可,而小公司往往缺乏流程,或者需要自己去慢慢摸索和了解;最好的办法是培训。
项目准备不够充分和多方都有关系,但是自信是必须的。
作为PM也需要在不断的学习和摸索中成长,无论大公司还是小公司出来的PM到了一个新环境都会面临这个问题。
关于换将
这个在缺乏流程的小公司和人员流动频繁的公司比较普遍,本人深有同感。
一个项目换了3茬需求调研的售前,换了3茬项目经理,每次去调研又都是在重复同样的问题,别说客户会反感,就连项目总监也会感觉很失望。
尤其是在解决方案中给出的10几个核心名单,在实施过程中几乎一个也没有,换成谁,都受不了这个打击。
这个在缺乏流程的小公司和人员流动频繁的公司比较普遍,本人深有同感。
一个项目换了3茬需求调研的售前,换了3茬项目经理,每次去调研又都是在重复同样的问题,别说客户会反感,就连项目总监也会感觉很失望。
尤其是在解决方案中给出的10几个核心名单,在实施过程中几乎一个也没有,换成谁,都受不了这个打击。
关于加人一定管用吗?
我的看法是在某些时候是管用的,在某些时候是添乱的,很多时候是上司强行安排的,处于无奈必须接受的,这样的加人只能让PM感受很差。
为什么要加人,在什么阶段加人,需要进行评估的,在需求阶段加了很多开发人员确实没有太大作用,可如果为了做demo,在需求阶段增加开发人员则是有用的
什么样的工作是并行的什么样的工作是串行的,什么工作是最关键的,需要甄别清楚再下结论是否需要加人
我的看法是在某些时候是管用的,在某些时候是添乱的,很多时候是上司强行安排的,处于无奈必须接受的,这样的加人只能让PM感受很差。
为什么要加人,在什么阶段加人,需要进行评估的,在需求阶段加了很多开发人员确实没有太大作用,可如果为了做demo,在需求阶段增加开发人员则是有用的
什么样的工作是并行的什么样的工作是串行的,什么工作是最关键的,需要甄别清楚再下结论是否需要加人
关于2009年终盘点
1、同时做两个项目的项目经理比只做一个的要做的好;
个人感觉可能问题出在工作较多的项目经理认为自己受到了重视,其次忙的项目经理更加需要思考,因此更能提升自己。
2、“自称”不懂技术的项目经理比熟悉技术的项目经理做的好;
不懂技术的项目经理能够把关注力集中在业务、管理和沟通上,如果太懂技术的话,不知不觉人就会沉溺其中,反而忘了主要工作。
3、研发(非现场)投入最大、现场投入也最大的项目,缺陷最多;
个人理解,现场的压力会大些,其次具备相应的软硬件环境,而且客户随时可能来抽查,所以保持高度的戒备,缺陷会少些
4、所有项目都是进入内部研发阶段,进度控制不错,而只要有客户参与,进度就无法保证,但平时几乎所有项目经理都叫嚷“和客户打交道容易,内部协调最烦”;
在现场客户会有一定的干扰作用,但却又是合情合理的,和与公司的协调,处于自身的尴尬位置是无法去挑明。
5、提前一个月给客户安装上线,最后验收仍然拖后3个月!
这个似乎是通论了,越到上线客户越会找一堆需求。
个人感觉可能问题出在工作较多的项目经理认为自己受到了重视,其次忙的项目经理更加需要思考,因此更能提升自己。
2、“自称”不懂技术的项目经理比熟悉技术的项目经理做的好;
不懂技术的项目经理能够把关注力集中在业务、管理和沟通上,如果太懂技术的话,不知不觉人就会沉溺其中,反而忘了主要工作。
3、研发(非现场)投入最大、现场投入也最大的项目,缺陷最多;
个人理解,现场的压力会大些,其次具备相应的软硬件环境,而且客户随时可能来抽查,所以保持高度的戒备,缺陷会少些
4、所有项目都是进入内部研发阶段,进度控制不错,而只要有客户参与,进度就无法保证,但平时几乎所有项目经理都叫嚷“和客户打交道容易,内部协调最烦”;
在现场客户会有一定的干扰作用,但却又是合情合理的,和与公司的协调,处于自身的尴尬位置是无法去挑明。
5、提前一个月给客户安装上线,最后验收仍然拖后3个月!
这个似乎是通论了,越到上线客户越会找一堆需求。