项目团队建设和管理.docx
- 文档编号:20124034
- 上传时间:2023-04-25
- 格式:DOCX
- 页数:12
- 大小:24.27KB
项目团队建设和管理.docx
《项目团队建设和管理.docx》由会员分享,可在线阅读,更多相关《项目团队建设和管理.docx(12页珍藏版)》请在冰豆网上搜索。
项目团队建设和管理
项目团队建设和管理
1如何做项目团队管理之前言
入行五年,做了一些项目,现在最大的体会发现目前整个管理信息化实施尽管每家公司都提供了很多方法去指导,提供了很多流程去约束,但效果不大。
为什么呢?
因为管理软件实施需要一个人在四个方面都必须很强才能顺利推动,这四个方面是企业业务,管理理念,软件功能,人际沟通。
实际上一个好的实施人员必须是一个能力非常强的知识复合型,精通项目管理技巧的人才。
在产品基本成熟后,一个成功的项目是靠个人能力去保障的,流程和方法论只能给有潜力的人行动启发,而不是指南。
这就是目前的现状。
而这种人才的获得是非常偶然或者是需要长时间积累的,但整个IT行业是一个年轻人的事业,大量不足30岁又没有多少行业经验的人活跃在一线,项目服务整体质量不高在所难免。
IT人注定是奔波劳碌命,一个现场赶往另一个现场的奔波中,知识的更新和积累非常缓慢,不如说是吃老本更合适,而IT公司为了应付用户需求也是招架不及,成本难以控制,更不可能在业务培训上下功夫,结果就是一大批有潜力不职业的实施人员在IT业浪费了青春。
通过高薪吸引高水平的项目管理型人才或实施人员进入IT管理软件实施工作,其实是一个伪命题。
毫无疑问当前一个具备以上技能的人员在IT业可以获得的回报是远远少于其它行业,是不可能吸引多少人才加盟的,可能每家公司都有一些高人,与其说是为利益最大化,不如说是和爱好重叠,在工作中有乐趣。
但一个公司高人是有限的,不可能让这个高人去应付所有的工作,否则这个高人只能给每个项目一点点精力,还不如一个花费大量精力在某个项目上的能力低一点的人的效果。
我们在高度竞争的情况下,不太可能引进高人去实施,成本无法承受,也不能让一个高人去面对所有的项目,让高人崩溃。
根据我的观察业内很多忙人,共同的特点是售前售后一肩挑,几乎是一个突发事件跟一个突发事件,没有喘气的机会,最终的结果只能是黯然引退。
所以解决这个矛盾必须寻求另外的出路。
我个人的建议是,公司第一要做好知识管理,并通过IT产品为核心整理自己的知识,将对企业业务和管理理念支持通过连贯的功能体现在产品中,并形成售前售后一致的标准实施和演示方案,并不断完善。
此外就是建立项目团队,通过团队能力组合去弥补个人能力不足,在团队中建立学习型文化,通过亲自示范传递很多软能力技巧,也许是目前摆脱困境的办法。
2好的项目团队构建要求
一个好的项目团队绝对不是一种性格一种单一能力的人的组合。
任何一个人想做项目经理,实际上从一开始就要考虑如何构造你的项目团队。
这些考虑包括如何建立实施能力的合集,形成共同的价值观和行为模式等方面。
项目经理在建立项目团队时容易发生两种误区,第一要求别人有团队精神;第二是指望别人有为项目目标牺牲自己时间的精神。
这样建立团队只能说是期望值过高,最终团队很难一起长期合作。
个人有没有团队精神不是关键,而是你建立的团队对不同的人是否有包容精神,发挥他们的长处,抑制他们的短处。
要做到这点就是通过合理的利益机制去保障,不要指望用什么精神力量去长期维护一个团队的斗志。
要知道很少有能在半年内结束的管理软件项目,所以也不要指望个人一开始就愿意为了项目成功去牺牲自己的利益。
个人认为建立好的团队把握住两个方面就容易,第一是团队成员价值观接近;第二是团队具有合理的利益分配机制。
一个能成功合作的团队最好的方式是选择具备同样价值观的人加入团队。
国内项目很难做好的一个重要原因就是信息化长期艰巨性和企业需要立竿见影的效益之间的矛盾。
这个时候无论个人能力多么强,恐怕都无法立即满足很多用户的期望值,因此团队必须要有长期抗战的心理准备,这个时候肯承担责任的人非常适合加入团队。
作为一个管理软件实施项目,一定要选择那些有耐心,有韧劲,有担待的人去负责项目,这样的人才能把项目做好。
因为一个人肯担责任,就会努力去解决问题,在解决问题过程中其技能一定会在很短时间内得到很大提高,这个人业务能力怎么样是可以解决的问题。
但一个人不肯承担责任,不肯努力解决问题,问题就永远停留在原处不被解决,即使开始技能不错,后来也不能适应项目需要。
很多项目往往因人而成,因人而废。
这个现实告诉我们很多时候我们必须花费足够精力去选择这样的人。
个人认为现在中国这么大,选择40~50个认同这样价值观,对待遇要求也可以接受的人员一定有,只是我们没有去发现,总是通过一大堆其它条件去选择人员有关。
例如我们总是要求一个实施人员有计算机软硬件知识,良好制造业背景,对信息化管理软件实施有深刻认识,对软件功能熟练掌握。
这些都是对人硬能力硬指标的要求,但是无法衡量一个人的软能力,而在项目实施中软能力是最重要的。
所以我们在选择成员的时候要和人力资源部门有力协调,不要选择大量硬指标的人,第一是难找,第二是不好管理,难以协调一致和产生认同感。
软能力的衡量要考虑最大方面就是价值观,而不是现成的业务技能。
根据个人观察,能够快速在项目中独立担负责任的人,从一开始他对这个行业一无所知到可以独立完成任务,在有人指点的情况下一般只需要半年,甚至更短。
所以完全不必担心这些新员工能否成长,而是应该担心新员工能否得到良好的指点。
选择好团队人员只是一个开始,一个团队一起协同工作一定是可以通过工作获得相应的回报,这个回报一定要有一个大家认可的合理分配机制。
没有这个合理的机制,团队也会因为失去激励和公平而人心涣散。
做到合理的分配机制在项目控制过程中非常难,因为国内同样规模和难度的项目,有的企业金额80万,有的企业40万,甚至有20万,软件公司为了解除现金流压力,最后都会承诺去做。
这些项目要做好都需要消耗同样的项目人力资源。
如果一个人做了一个80万的项目,一个人做40万的项目,可能工作量差不多,但项目提成收入可能差距就是一倍。
这个问题也就是存在所谓“肥单瘦单”的说法。
即使两个人做的同样是40万的项目,项目复杂程度可能差别很大,工作量差距也是好几倍,提成收入又差不多。
就算是两个项目金额复杂程度差不多,付款条件不一样也会对可预期收入产生直接影响。
根据不同公司的政策往往实施人员更乐意或者不乐意选择首期款比例高的项目。
还有一种常见情况,一个项目大家一起做才能完成,两个人在项目中花费工作量不一样,解决问题难度也不一样,这个时候如何平衡两个人的提成收入分配也很关键。
开始合作的时候大家往往比较容易齐心协力解决问题,但如果到了利益分配的时候大家觉得受到不公平待遇,估计你的团队也就开始瓦解。
解决这个问题的办法我觉得很难,从两个方面入手也许容易做一点,一是在团队内公平透明,优先奖励符合我们价值导向的人,第二是必须认识到这个是一个项目经理管理团队最需要花费精力的地方,必须保证时间去思考和解决这个问题。
我们中国人一不缺智商,二不缺情商,但比较缺钱商,孟子说:
民不患寡而患不匀,大概是我们可以参考的一个思路。
实际上我认为建立一个实施团队不要照搬那些管理理论的理想描述去做,关键就是这两个问题,有没有一致的人,有没有合理的分配机制。
3好团队的两个特征
一个好的团队一定是分工明确的团队。
很多IT管理软件项目,要么是一堆人泡现场,要么是孤胆英雄。
因为遇到事情的时候用户的感觉是没有人真的去负责,这就说明在项目中没有真正的项目经理,
这就是在一个团队中没有明确谁对项目负责,如何负责,技术问题谁负责,商务问题谁负责,管理问题谁负责,到了真有事情,每个环节都忙,但响应和处理效率并不高。
实际上用户愿意选择能够解决问题的人,而且愿意解决问题的人合作。
但这个人往往是项目经理,因为项目经理一般实战经验丰富,技能不错,而且对项目最终负责,压力最大,结果项目经理就成为这样的人。
但项目经理一般要负责多个项目,每个用户都喜欢他,他很快就在多个项目中变成每个用户都不喜欢的人,这就象一个人的情人不能太多,太多也难应付。
所以合理分工的原则是帮助项目经理充分发挥自己价值,让团队成员能力能充分体现。
一般项目经理应该强在对企业业务把握能力,能快速发现项目的价值点,进而通过良好的沟通技巧在团队内和用户处就项目目标达成一致,并形成可执行的后续计划。
这也就是所谓计划,组织,控制三步曲。
项目经理不应该让用户认为是一个技术很强的人,当然项目经理技术可以很强,否则用户会不认可实施人员的能力,反过来要求项目经理到位,而团队成员技术能力也会因为没有足够实践机会而成长缓慢。
不能成功让用户接受自己团队成员能力的项目经理,注定是疲累不堪和失败的项目经理。
此外项目经理技术性比较强,而且在管理软件实施过程中要带一些顾问的性质,这样的角色最好不要和回款直接挂钩,可以出面提醒用户按期支付款项,但不应该直接去要钱,这些工作应该通过商务经理完成。
一个人上来谈目标,下来谈收钱,会给用户一种不真实的感觉,是否你为了回款而设置比较低的目标?
所以一般在一个团队中应该有项目经理,实施经理,客户经理三种角色。
项目经理,项目经理最大的作用是控制项目边界,代表项目组和用户就项目目标达成一致,然后组织资源保障项目得以实现。
项目经理要保证为了达到预定时间内的目标,可以配置资源和时间去完成这件事情,而不是到处救火,亲自去解决问题。
实施经理主要是从技术上保障项目顺利运行的配置实现,并保证让用户可以独立应用并推广软件,在积累一定经验后可以独立完成解决方案编写和产品完整演示。
客户经理是当项目达到合同约定条件时,负责催款和回款相关的商务工作。
个人认为实施经理和项目经理最大区别不就在于一个同时只能搞定一两个项目,项目经理可以同时搞定5~6个项目。
项目中三种角色缺一不可,每个角色在自己能力范围内发挥作用,互相协调配合一致非常重要。
而且项目经理要让用户清晰知道遇到何种问题可以如何和我们项目组联系,我们会如何解决,大概需要多长的时间。
这样的团队最大的问题是是否遵守同样的行动规则,也可以理解为对外是否具有一致性。
这也是一个好团队的特征。
有的项目商务经理为了便于回款或者签单,容易过度承诺,给后期实施制造极大障碍,有的实施人员在现场发现一些新的问题,容易犯个人英雄主义,自己去承诺解决,但并不先和项目经理沟通,有的实施人员如果不是特别安排,基本上不会去主动和用户交流,有的实施人员几乎每天都和用户电话联系,有的项目经理经常和用户联系,实施人员反而不去联系,这些都是行动规则不一致的表现。
在一个团队是否遵守同样的行动规则,首先是价值观一致。
例如我们是否都认为如果用户现场出现各种问题,我们应该先全力促进解决问题,再来谈问题的责任,而不是一开始就说这不是我的错,这个不归我管?
我们是否认为为了让用户满意我们必须随时准备牺牲自己的时间和精力?
这些都是很重要的问题。
第二是养成事先沟通的习惯。
不要自己去决定所有的事情,也许你的决定没有错,比别人去做也会效果更好,但是在没有得到明确授权范围内的事情,一定要先在内部达成一致后行动,否则容易出现做了别人也不领情的情况。
很多事情也很难一开始就形成规范或者文件指导,但只要我们清楚这些事情应该先内部达成一致,总是有办法,对于一些规律性的东西就慢慢形成惯例,可以减少沟通的成本,这也就是所谓团队默契的形成。
第三是每个人的沟通频率在一个项目中各个阶段保持一致,关键沟通信息应互相清楚,不同角色沟通频率节奏要合理搭配。
第四是对项目边界和不同角色责任承诺对用户说法要一致,这个是通过内部沟通达成一致后要和用户明确的。
10.4如何看待项目经理在团队中作用
IT业流动率高,做实施的流动率相对开发可能更高一些,一个项目最怕中途换人,但这种情况在业内非常常见,用户非常担心自己的项目出现这种情况,往往要求在合同前期指定项目实施人员,这是一种无奈也无用的做法。
所以软件公司应该将自己业务上比较优秀的人提拔出来,给予项目经理的职责,培养其管理意识,而不仅仅是技术意识,给个人比较大的成长空间和较好的待遇,这样有利于核心员工的稳定,再由核心员工带领团队去做一个项目,这样项目因为人员流失造成项目中断的风险就最低。
所以对于公司而言项目经理不能是一个一般性岗位,是一个具备能力核心员工才能担任的岗位,这个岗位能让核心员工在比较长时间内稳定开展工作,并通过项目经理带领团队实施,促进团队能力提升,保持团队队伍稳定。
这对于一个项目可能是非常重要的一点。
从项目实施角度来看努力去负责一件项目是很不容易的事情,特别是这种管理软件实施,所以一个项目团队中必须有一个项目经理。
项目经理就是无论是其责任心还是职责规定都是那种寻找努力促进事情发生,从不轻易放弃的人。
项目经理是一个团队的精神领袖,他的言行直接对团队起到一种示范作用。
一般认为项目经理未必一定是一个团队的技术领袖,但实际在目前国内要想成功控制管理软件项目项目经理至少得是一个业务精通者。
一个对企业业务不熟悉,对管理软件不熟悉的人担任项目经理更大的可能是造成一场灾难,尽管也许他具备很好的项目控制能力。
总之项目经理要成为一个让用户和团队成员都信任和放心的人,这种精神领袖的地位是靠项目经理能力和个人魅力逐步得到大家认可后在一个集体中放大和加强的。
4团队建设心得和误区
4.1加强沟通保持一致
项目管理强调团队达成一致再行动,但达成一致的关键是先在内部广泛达成一致,再对外沟通。
这个原则有两点在操作中很容易出现问题的地方,第一是项目经理事无巨细都需要了解和沟通,协商成本太高,导致沟通效率很低。
内部沟通非常必要,但也没有必要事事沟通,反而打击团队成员工作积极性。
项目经理应该实现和团队成员约定不同类型事件沟通方式和频率,保护团队成员工作主动性,同时保障项目始终受控。
第二项目经理自认为能力很强,按照一些项目管理理论说法项目经理先和客户达成一致目标,然后协调资源完成目标,内部资源不听调度就非常恼火。
现在一个出色的项目经理一般都无法专心做一个项目,所以项目中主要实施工作还是要依赖其它团队成员完成,因此在一个团队中对于软件实施有不同认识和意见是很正常的,项目经理一定要先多花一些时间在内部沟通,千万不要以为内部一致性很容易达成。
我们员工更习惯的思维模式是既然你都已经决定了,我照你的做就是,还问我意见干什么?
如果员工觉得项目经理思路不对,他们可能不是优先考虑执行,而是想证明自己是对的,这也是知识型员工的特色。
所以宁可先多花一些时间告诉项目经理自己的判断,最后和用户会谈达成的结论会比较顺利地传递成为团队共同认识。
4.2参与和顾问式领导方式
很多项目管理书籍告诉我们领导有方的项目经理从来不教人如何工作,由项目成员自己决定怎样完成任务。
我个人认为项目经理工作恰恰是要给新员工示范正确的做事方式,只要条件许可,还要亲自示范,在项目需要受控的时候多一点独断专行,少一点成员自由发挥是非常重要的事情。
项目经理的示范只需要一次,通过示范让项目成员感觉到正确的做事方式可以有效达到目的,这也是项目经理建立权威的自然时机。
在中国缺少职业教育的高学历人群比比皆是,如果相信这些拥有高智商的人能够顺利完成工作就大错特错,高学历的人把很多简单的事情搞得无比复杂的情况到处都是,很多人自以为是,自作聪明,最后还是要别人去开屁股。
也许在国内项目经理不需要过于精细的管理,但在国内不能确定团队成员工作方式和能力之前,项目经理还是要多做示范,保证团队成员工作方式是按照基本的职业方式进行后才能让他们自主发挥。
4.3控制过程还是目标管理
很多管理理论总是强调不要仅仅重视结果,要注意过程,没有过程质量的保障,最终的结果输出也是偶然的,不可靠的。
这个理论一点都没错,不过问题是实际上项目经理在过程控制上花费的时间越多,花费的精力越大,项目反而越难以控制。
因为管理软件实施对人的综合能力要求太高,当一个人的能力还不能达到业务要求的标准的时候,最需要的是培训和示范,而不是责问为什么你的工作不到位?
就象本人写前八章一样,能够把这些事情正确执行方法知道的人都不多,有实际经验的人更少,对能力不足的人去控制过程,还有控制的必要吗?
这个时候最重要的是建立业务规范,在业务规范大家有能力执行的情况下,再去考察业务规范符合度,加强过程控制才有效。
我们很多软件企业不断强调自己的流程和方法论,但员工经常流失,很多新员工在现场工作的时候,什么方法论都不管用,他们充满恐惧的想:
我到底该做什么,我该什么做。
过于强调过程管理最大的一个体现就是汇报多,层次复杂,增加了很多管理活动,但又看不出这些管理活动的价值。
结果是很容易重复汇报或者多头汇报。
口头汇报完成的工作还要书面汇报,日常汇报过的工作还要专门总结汇报,现场记录的工作还要单独汇报。
经常反复汇报在项目管理的理论中也有说明:
这是打击团队士气的有效方法。
本人建议汇报突出两点,坏消息先汇报,例如不能按照计划完成的工作要汇报,需要紧急协调资源的消息要汇报,这些随时发生,随时搞清楚原因,随时汇报,随时采取行动。
第二与其反复了解进展,不如提供清晰的目标管理。
也就是说项目经理接受和交代任务的时候,一定要清楚自己任务的范围,质量要求,进度要求。
对任务理解是否达成一致的最简单方法就是请任务接受人当场复述。
任务接受人如果不清楚任务的内容,进度和质量要求,一定要问清楚才能去执行,如果不清楚怎么做,也要立即沟通请教,不能先好好好,回头告诉别人我搞不定。
本人曾经给一个员工布置一个修改方案的任务,电话里说了6点修改意见,问他清楚了吗,非常自信的回答,我知道了,放心。
本人很不放心的又问一句,给我复述一遍。
很流利的说了四条,然后问我,哎呀,还有两条呢?
所以在接受任务的时候还要一个职业习惯:
好记性不如烂笔头。
在国内目前项目实施水平现状下,个人以为目标管理,严格的目标考核机制远远比过程控制更能达到管理目的,只有当大面积的人可以按照目标完成项目的时候,过程管理才能发挥不可替代的优势。
4.4信任团队成员
项目经理一般都是业务能手,很多时候看到项目成员做一些很简单工作都做不好,马上亲自动手,先搞定问题,否则项目耽误不起,但常此以往,项目经理就是眉毛胡子一把抓,活该累死。
项目经理要信任和授权成员独立完成任务,既然都在一个团队就要用人不疑,疑人不用。
坚决大胆要求团队成员努力学习独立掌控局面,项目经理逐步演变为对目标进度的控制者。
当然这个时候项目经理要加强对员工工作的指导,但项目成员往往分布在不同的现场,项目经理要结合不同项目拜访计划的时机采用走动式管理。
在现场不断并亲自验证成员的工作方式,立即指正和改进,加以示范。
信任不是放任自流,以信任的名义对团队成员的工作放任自流是项目经理失职和偷懒。
而且项目经理要时时考虑让让用户成为团队中的一份子,从一开始就全力培训用户是减少实施成本的最有效方式。
团队成员一个比较共性的问题就是:
很多人会问没有资源没有人我怎么开展工作。
这样的团队成员可能会辜负项目经理的信任。
这是很大的一个误区,一个人有能力的表现就是能做别人认为很难做到的事情,如果事事有资源你才能把工作做好能说明什么?
这种事情谁都能做。
而实施工作就是在各种缝隙里寻求合理的答案,项目经理在信任团队成员的时候也要让团队成员建立承受压力,迎接挑战的心态,也就是所谓情商吧。
4.5建立向上的团队文化
项目经理一般都是个性很强的人,不太可能用同样的方式约束项目经理的做事方法,当然越是成功的项目经理,行事方法越具有共性。
而项目团队成员和项目经理的互相认同对一个团队成长非常重要,也是工作能否快速进展的关键。
项目经理要及时认可成员工作,随时用进展鼓舞团队士气。
对很多人而言,物质奖励的预期是很清楚的一件事情,国内的项目经理一般也没有多大空间去对项目成员工作进行物质奖励,因此在这样的边界条件下我们更要寻求利益机制以外的团队合作方式。
对成员工作表示兴趣;对成员的能力表示信任;和成员一起在工作中寻找乐趣;和成员一起建立非正式沟通方式
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 团队 建设 管理