×

扫描二维码登录本站

标签: 暂无标签
  项目经理虽被“贵”称为经理,但是却不具有部门经理的实际权力,或者叫行政管理权,也叫硬权力,比如人事任免、奖惩等。
  没有硬权力,却要带领项目团队完成具有挑战性的项目目标,如何服众?这就需要项目经理的软权力或者软实力了。
  软实力,除了我们常说的沟通能力、协调能力、人际交往能力、解决问题的能力、归纳总结能力外,我们还可以从一些日常细节入手,努力成为团队的榜样,提高自己的软实力和影响力。
  1.例会照例开
  项目经理经常组织内部或者和客户的项目例会,如果三天打鱼两天晒网,那么你的例会将会失去公信力,人们就会怀疑今天的会是否会开,它的优先级也会越来越低。如果主持人都不重视,怎么能让你的团队重视你的会议呢?
  如果由于出差或者与其它会议冲突,也不要轻易取消例会,建议改期进行,需要提前通知大家,并且说明原因,表达歉意。
  如果确实近期没有话题,或者可以更新的内容很好,那么拽不要轻易取消会议,可以适当缩短会员时间,甚至和团队成员闲聊一会,对团队的建设也是不无裨益的,甚至有意向不到的收获。
  2.提前五分钟
  出席会议时,提前五分钟到场。如果是自己主持的会议,至少提前十分钟到场。开会从来不迟到,体现了对别人的尊重,也会大大提高你的声誉和信任度。
  除了会议外,这条规格同样适用于约会,比如出差时约定什么时候从宾馆出发,什么时候和客户见面等。尤其是和老板一起出差,如果你迟到哪怕5分钟,他们嘴里不说,心里也会非常不悦。
  3.一分钟找到
  这是对文件管理的要求,自己的文件(包含电子文件和书面文件)能在1分钟之内找到;如果别人找你的文件,应该在三分钟之内可以找到。
  文件及文件夹的管理,每个人都有自己的方法,除公司统一要求外,可以按照自己喜欢的方式去管理,判断是否有效的标准就是,是否能在一分钟之内找到你想要的文件,如果让别人找,应该在三分钟之内。
  要达到这个目标,直观、明了、统一的文件夹结构就非常重要,如果没有办法形成公司级别的标准,至少也要在项目组成员之间对项目文件夹的结构达成共识,形成固定、统一的文件夹结构,而且不要随便更改。
  另外,对文件的命名也要形成统一的规则,能达到“望文生义”,也就是不打开文件通过文件的名字就可以知道文件的大体内容和版本信息。避免使用诸如“11111.doc”,”wryoytiun.xls”,”Report.doc”这类名字。
  4.邮件有标题
  在发送邮件时,一定要加上简明、贴切的标题。这样才方便接收者在不打开邮件的情况下,快速识别你邮件的主要内容,以决定邮件的优先级,对于老板来说尤其是这样,他们每天可能收到几百封邮件,不可能每封邮件都马上阅读,甚至有些邮件根本就不读。
  邮件不加标题,会给人一种粗浅的印象,对项目经理的形象和会有很大的伤害。
  5.慎用感叹号
  相信所有的邮件系统里都有设置发送优先级的设置,对方收到后,邮件前面就有一个红色的“!”标识,以说明此邮件很重要。
  曾经合作过的一位同事,我收到她的邮件,差不多有三分之一带感叹号,见多了也就见惯不怪了,所以她的邮件并不会获得高优先级,这就是“狼来了”的案例。
  发邮件过多地使用感叹号,不仅得不到高优先级,而且会给人一种压迫感和缺少计划性的印象。为什么你的事情总是最重要的呢?!如果计划做得好,怎么老是有紧急的事情呢?!
  6.办公室里多走动
  相信大家一定看到过或经历过,两位在一个办公室的同事,近在咫尺互相打电话,在听筒外可以互相听到彼此的声音。为什么不站起来,走过去交流呢?不仅有利于身体放松,而且沟通的效果会好于打电话。
  即使不在同一楼层的同事,如果时间允许,也应该尽量多地互相走动,进行面对面的交流,这样会拉近彼此的距离,而不会给人一种被项目经理遥控的感觉。
  7.干点粗活
  无论我们的产品有多高科技,在项目开展的过程中总会有一些粗活、累活甚至脏活。比如搬样件、帖标签、修理试验车等。
  尽管这些活不属于项目经理的工作范畴,但是我们如果能够适当地分担或参与,亲自体验一下一线员工的辛苦,对自己也是一个锻炼,同时会让团队成员感受到同甘共苦的团队精神。
  反过来,如果项目经理对这些工作不闻不问,甚至不屑一顾,就容易脱离群众,给人以高高在上的印象。
  上述这些都是些日常工作中的小事,需要放在心里,持之以恒地做下去,以至形成习惯,成为自己的一部分。那么,你就会发现,你的软实力就会不断上升,而这种实力会变成你的个人魅力,从你的每个毛孔里散发出来,这就是重复的力量!





上一篇:成功的项目=成功的产品+成功的项目管理
下一篇:新人报道
aura5566

写了 24 篇文章,拥有财富 203,被 4 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

Powered by ITIL  © 2001-2025
返回顶部