不知不觉偶的BLOG已经写到99篇文章了。本来想遵循某猪的建议写个纪念篇的,但最近这颓废的小日子实在想不到什么可作文纪念下来。正好最近在看向往已久的《IT项目管理最佳历程》一书,诸多观点与我心有戚戚焉。索性拾起已荒废许久的“项目管理杂谈”这个系列,也聊聊自己的一些看法。
上次谈到了项目的启动,OK,那么我们现在假设PM已经得到了领导的正式授权,拉起了自己的队伍,打算抡开膀子大干一场了。接下来可不是把人呼呼啦啦全部扯到客户现场,热火朝天干上N个月就完事了。所谓谋定而后动,计划永远是任何一件事情开始前最重要的部分,同时也是诸多PM最头疼最花精力的地方。所有做过项目的人都喜欢说一句话:计划不如变化快。因此很多人也就不愿意做一个整体的计划书出来,反正也是要不断变化的,见招拆招就是了,何苦让自己提前死脑细胞呢。
其实不然,计划是什么?是我们工作的任务指导书,是资源投入的分配表,是公司专业性的脸面,是送给客户的定心丸,是甲乙双方心里的一杆秤。少了一份项目计划,姑且不论它是合理还是不合理的,都会让项目小组的成员和客户相关人士一头雾水,不知道自己该干嘛,该在什么时候干嘛,该干到什么程度算完事。上了战场四顾茫然的兵,想必这场仗也是没法打的。
都说计划难写,主要是基于一个认识,就是未来的工作里充斥了太多不可控的情况,没办法处处都在自己的掌握之中。既然预知到会出现很多变动,那这计划的可执行性就不大。如何克服这个问题,我认为作为PM要理解到这么三点:
1.计划不是意味着一成不变的。未发生的事件肯定是充满了风险和意外,那么我们就肯定会有相应的变化去应对。做整体计划的首要目的,是给项目关系人一个纲领性的文件,作为对这个项目的设想,便于大家都明了一些项目关键要素,如范围、大致时间、里程碑等等。出现了变化也不是什么大不了的事情,无非就是通过变更程序去修正原计划提高执行度而已。不管什么项目,最终的项目完成情况肯定是在最初的整体计划上打了无数个补丁的结果。变化本身并不可怕,可怕的是连变化的基础都没有。
2.计划不是由PM自己说了算的,也不是由公司某领导拍板就行。合理可遵循的计划应该是甲乙双方一致确认,同意在规定时间都能投入规定的资源,得到预想的效果。这样的计划才具备可操作性。很多公司的通病就是项目一启动,马上让PM写个计划书给领导审批,然后动身去现场。似乎自己这边拍拍胸脯就能万事皆备。但客户呢?本来就是个双方合作的工作,你说我周三来调研,周五开会讨论,周日提交方案。结果客户那边周三领导出差,周五高层视察,周日人家休息。整份计划立马变成空对空。所以拜托各位,写了自己的预期安排,一定要给客户看一看,对方根据自己的工作状况来分析一下是否可以达到这样的配合度,才好按此继续。因而再三要强调强调,计划书必须经过双方的确认签字同意才能成为正式文件。
3.PM不是神,公司领导不是神,客户从上到下也没有神仙这个职位。既然没有可洞察未来的高人,那么就不要对细节精益求精,苛求每一个任务步骤都能明确,把时间安排到分分秒秒。项目风险曲线告诉我们,最开始的时候风险总是最高的,因为整个项目都是不可掌控状态。那么一份非常详尽的计划,唯一的后果就是PM疲于奔命,成天写变更申请和计划修改。所以前面我提到的这个阶段,所写计划都是整体性计划。只是个纲领,把最主要的安排都罗列出来。至于细化的部分,拿到月计划、周计划里再根据实际情况描述不迟。一个是大局,一个是小节,并不矛盾。
最后再补充一点,其实也是我本人的缺点,就是不喜欢把计划落在纸上。很多有经验的PM或许心里对一个项目都是有数的,但写下来有两个好处:帮助自己思考和防范以后忘却。尤其是对越庞杂的项目而言,越有意义。
正好写到中午开饭,呵呵。就此收笔。希望下一篇能尽快写出来吧。


档案
日志
相册
视频



评论
想第一时间抢沙发么?