工作中,我们都有概率会碰到烂项目,有可能是别人甩锅,故意坑你;也有可能是项目确实失控了,需要外部援助,紧急救火。


但不管出于怎样的原因,接手这种项目,一定要慎之又慎。


一、无与伦比的“烂”项目


这个项目,我愿称之为“无与伦比的烂”。


我说一下当时接手该项目时的场景,大家感受一下就知道了:


有一天,我领导喊我到办公室,开门见山地告诉我,后面要交给我一个项目,这个项目,他跟事业部的负责人已经聊过一次了,只知道个大概情况,各种资料文档统统没有。


然后呢,我领导跟我又沟通了大概半个多小时,所有的信息,总结一下的话,大概有这么几条:


1. 这个项目,我们属于丙方,然后需要以乙方的身份,去甲方那边驻场开发;


2. 驻场地址xxx,驻场人员目前有ABC,由于公司业务调整,后续我需要带着DEF过去和之前的人交接;(第一次沟通的时候,DEF是谁都还没确定…)


3. 按照事业部负责人的说辞:“这个项目的功能已经开发得差不多了,派个PM过去盯着,收收尾就行了。”(功能都有什么,压根都不知道,开发得差不多了,咱也不知道差多少…...)


4. 我们跟乙方签订了一份合同,但乙方跟甲方还未签订,后续我们跟乙方的合同,有可能会重签。意思就是,前期合同签订得有些粗略,不能作为交付验收的依据…


按照事业部负责人的说法,目前签订的这份合同,如果哪天跟乙方闹掰的话,打官司的时候会有用。(一个项目,已经开发了两三个月,合同还没敲定,你们敢信?)


好了,项目的所有信息,基本上就是以上4条了,项目情况看起来比较模糊,其实一点也不清楚。


总结一下,这个项目在我接手的时候,大概有这么几方面的特征:


1. 没有任何资料;

2. 项目进度不清楚;

3. 何时交付不清楚;

4. 交付标准不清楚;

5. 甚至连资源(主要是人力资源)都不清楚。


在此,我想问一下大家,有没有人遇到过比我这还烂的项目…


接手这个项目,真的就像是开盲盒一样,啥啥都不知道,然后“背锅”与“救火”,真的是就在一念之间啊,一念天堂,一念地狱。


遇到这种情况,该怎样避免背锅呢?


项目管理有专业的方法论,正所谓理论指导实践,以下这张图,在整个项目过程中,真的给了我很大的帮助。



然后呢,我从实践的角度,做了几方面的事情,目前来看,基本上能和“背锅”两个字说拜拜了,而且接手了差不多一个月,领导也准备给我这个月的绩效打个A。


好了,今天就把这些“防背锅”小妙招,总结一下,分享给大家。


二、项目正式接手前


项目先别着急接手,正式接手之前,先把这几件事情给搞清楚、说明白了,然后再接手。


而且,也不要害怕别人会说你不服从安排什么的,咱又不是不接,接之前,有一些疑问提出来,想确认一下,这个总没毛病吧。


1. 定性


让我接手这个项目,没有问题,但得先把我接手的这个性质,咱们讲清楚、说明白。


这个时候,就得拉着PM领导、事业部领导以及技术部领导,来一个三方会谈了。(具体拉上哪些人,大家可以根据自己公司的情况决定,反正最好是拉上能够互相制约的几个人,或者是有话语权的第三方公证人)


项目本身就已经这么烂了,让我接手,是来解决问题的,不是背锅的。


而且大概估算一下,目前项目进展已经几个月了,加上前期的商务成本以及驻场的开发成本,都已经快跟合同额持平了,这个“成本管理”肯定是管不了,就算是以后项目烂尾,或者是赔钱,这个肯定不能算到我头上。


2. 定权责


正所谓,将在外,君命有所不受!


让我接手这个项目,那么驻场的这些人员,肯定都得听从我的安排。


但只有口头授权,往往是不够的。最直接有效的办法,就是把这些人的考核权,牢牢把握在自己手里。


试想,如果连考核的权利都没有,奖钱罚钱都不是你说了算,那谁会听你的。


而且,这个事情,也一定要同步到项目所有成员,我当时是这么干的:


第一步:和相关的领导们开了个会议,会上口头确认了一下这个事情;


第二步:我自己整理了一下会议纪要,把这个结论给记录了一下,往所有项目成员都在的群里面给丢了一下;


第三步:在群里@所有人,明确告知,后续现场人员的考核,由PM全权负责!


这里再多说一点,沟通管理是项目管理里的一项重要内容,其中沟通里占比最多的就是会议沟通,有很多人不喜欢记会议纪要,觉得麻烦或者没必要。但这就大错特错了,会议纪要真的是非常有必要:


  • 一方面,会议纪要是大家会议沟通那么长时间,最终达成共识的一个结论性的东西,整理成文字,还可以检验这个结论有没有偏差;


  • 另一方面,后期如果出现不认账的情况,那么会议纪要自然就成了强有力的证据;


  • 最最重要的是,作为一个整理会议纪要的人,在整理的时候,必然会带着一些主观的色彩,说白了,就是将自己认为合理的内容记上去,或者是按照自己认为合理的方式记上去。当然,跟大家的结论不能够有太多的偏差,不然肯定还得修改。


3. 找队友


正所谓,天下没有永远的敌人,也没有永远的朋友,只有永远的利益。


可以从三个不同的视角来确定,不同场景下,队友都是谁:


  • 从公司内部的视角来看:我们PM是一个资源池,服务于不同事业部的不同项目,所以我跟我领导肯定是队友;事业部的人属于对立面,我们之间肯定是要划清责任的;


  • 从整个项目的视角来看:那么我们公司的人肯定就是队友了,签合同的乙方以及甲方就是对立面;


  • 从项目交付的视角来看:和我们签订合同的乙方也有可能是队友,因为有很多时候,甲方会提出很多无理的或者是额外的需求,这个时候乙方也是想尽快交付项目,拿到钱的,所以乙方也会想办法推掉这些乱七八糟的事。


分清敌友,能够在不同场景下让各个角色之间相互制约,更好地推动项目进展。


三、项目正式接手后


项目正式接手后,才是真正的考验。


很多人面对一个项目,不知道该怎么入手,就跟我们做产品设计一样,初级的做图仔仔,很容易一头就扎到细节里面,这样的话,接下来的工作会反反复复,无穷无尽。


所以说,打蛇打七寸,项目的七寸主要在以下几个方面,把这几个方面给管理好了,那这个项目就成功一大半了。


1. 范围边界管理


我们要干哪些事情,以什么为验收标准,这个是项目开始之前,就必须要搞清楚的事情。


也不知道这个项目是咋搞的,都已经几个月了,连验收标准都不知道,现场甲方爸爸让干啥就干啥。


而且这个问题,一定不能含糊,对方如果和稀泥,那就一定要有打破砂锅问到底的精神。


就比如,我向乙方这个负责人发出的夺命5连问,我感觉都已经给他问的快怀疑人生了:



2. 干系人管理


想要顺利地推动项目进展,一定要知道各个角色都有哪些权责。


举个简单的例子:一款考勤产品,肯定是公司的老板买单,你如果一直满足员工的需求,比如搞了个方圆100公里都能够打卡的功能,那这个项目肯定会烂尾。


拿我接手的这个“烂”项目举例,最起码能够列举出这么几类干系人:


(1)公司内部干系人


决策者:事业部领导、PM领导、技术部领导。


也就是说如果后期项目烂尾了,或者是赔钱不想干了,有这三个领导拍板就行了。


当然,日常汇报,不管是有什么进展,或者有什么困难,比如资源协调什么的,干系人也是这三位。


执行者:驻场的开发,这些就不一一介绍了,全是砖,哪里需要哪里搬的那种。


(2)公司外部干系人


乙方对接人:和我们签合同的乙方的对接人,反正乙方的其他人我也从来没见过,跟乙方沟通,或者是需要乙方跟甲方出面沟通的话,找这一个就行;


甲方对接人:现场直接对接的甲方人员,说白了,就是现场找了俩人,盯着我们干活的,有啥小事,找这俩人就行,但大事,比如项目验收什么的,这俩人肯定没这个权利;


甲方决策者:项目想要验收,还得把这个人搞定。


但现实往往是,这种决策者总会提一些乱七八糟的需求,比如我在这个烂项目中遇到的,甲方决策者提的:“产品界面能不能做得简约一点,但界面展示的内容能不能丰富一点”,我当时一口老血,差点就吐在他脸上了。


最后再多说一点,毕竟我是中途接手的这个烂项目,就简单列了一下这些干系人,如果是一个新项目,或者大家想做一个专业点的干系人管理,可以参考以下这个表格:



3. 问题与风险管理


之前这个项目是一个开发人员负责的,完全没有问题与风险意识。


我还和我们PM领导讨论了一下,开发人员的思维应该是这样的:


“客户提出问题,我得想办法解决啊。如果把问题反馈给领导,领导肯定会觉得我水平不行,前期自己先想想办法,后期如果实在兜不住了,到时候再说吧…...”


但实际情况很有可能是问题与风险越积越多,项目最终就失控了。


有问题不可怕,可怕的是,领导们连有问题都不知道,还以为项目都进展得很顺利呢。就比如事业部领导刚开始跟我说的:项目都快收尾了,大概率就是听这个开发负责人汇报的片面之词。


有问题及时反馈,领导们及时了解项目现状,也会想方设法帮忙解决问题的,因为领导们也是需要向老板汇报情况的,也是希望项目早点结束,拿到款项的。


再来普及两个概念,有谁知道,“风险”跟“问题”都是什么意思么?


我来直接说答案吧:


风险:是指还未发生的,但我们可以预测到的,对应的是预案,需要避免风险的发生。


就比如这个项目的交付标准不明确,等到后期验收的时候,肯定会扯不清,这就是风险,而预案肯定就是前期想方设法跟乙方以及甲方明确交付标准。


问题:是指已经发生的,对应的是解决方案。


在这个项目当中,我遇到了一个特别“搞笑”的问题,当时笑得我都差点哭了。


我接手的时候不是说项目的功能都已经快做完了么,但实际了解了一下,他喵的,里面的核心功能还存在技术难点,也就是OCR这部分内容,现场的开发人员搞不了。


其他的增删改查的功能,做得再完美,有个毛用啊。核心功能不能用,这个项目交付个毛线。


于是,我紧急跟公司的技术领导沟通了一下,找了其他的技术资源,赶紧支撑了一波。


4. 进度管理


进度跟第一项范围边界是息息相关的,搞清楚了范围边界,才能谈进度。


对于进度管理,我是分了两个层面,一个是项目的整体进度,另一项是每周现场每位人员的进度,从宏观到微观,也就是这两张表。


第一张表:可以看到整个项目的进展情况。



第二张表:可以看到每周各个任务,以及每个人员的工作情况。



两张表结合,即可实现对于项目的管控(有兴趣的同学,可以查看这篇文章,已经讲得很清楚了)


5. 沟通管理


及时汇报,及时汇报,及时汇报,重要的事情说三遍!


汇报工作这件小事,我敢打赌,80%的PM,甚至是80%的职场人,可能都不会。


沟通管理的意义,在前面“问题与风险管理”当中,已经说过了,这里重点说一下,我在这个项目中,是怎样做好沟通管理的。


因为该项目的干系人稍微有点复杂,于是我一口气建了5个群。


(1)项目群:里面包含我们公司项目的所有成员,用于同步项目信息,以及日常的沟通交流。


(2)管理群:只有领导的群,包括前面说的,事业部领导、PM领导、以及技术部领导,有些话不方便对所有人说,这个群也是很有必要的。


(3)只有项目成员的群:同样,有些话,也不方便对领导说,所以建一个只有项目成员所在的群,说一些悄悄话,也是挺有必要的。而且这么整的话,也能让现场干活的人感觉到,你们都是一条贼船上的。


(4)所有项目成员以及乙方的群:乙方那个对接人,老是微信单独给我发信息,还经常下班给我打微信电话。然后呢,我先是正常沟通,让他在群里发信息,这样直接同步所有人,省得我再次传达了。


后来发现,并没有什么卵用,还是各种单独给我发信息,于是乎,他单独给我发,我就在群里给他回。 


建这个群的目的是如果乙方如果提出什么奇形怪状的要求,也能让我们领导知道,共同想办法对付他。


(5)有所有项目成员以及甲方的群:现场也是需要同步信息的,比如我们制定一个计划,或者确认的需求,反正就是各种结论性的东西,都往群里丢一下,省得后期不认账。


6. 要想马儿跑,就得给马儿喂草


项目进展过程中,避免不了各种突发情况,比如甲方爸爸提了一些脑残需求,导致反复更改,或者是为了赶进度免不了加班的情况。


除了权利层面的约束之外,想让大家好好干活,小恩小惠自然也是少不了的。


我从两个不同的层面,给马儿们整来了草,其中第一层面,还用了阳谋!


层面一:当然是向公司申请费用了。


把一个烂项目丢给我,我申请顿饭钱,一点都不过分吧。


其实我刚开始想的是,等项目有一定成绩了,再申请个“庆功宴”,后来想想,项目后面咋样还不好说呢,先带大家吃顿好的再说。


而且我申请的方式,让领导无法拒绝!


还记得我们建的第一个群,项目群么,我当时在群里是这样申请的:



这么一段话,往群里一发,如果领导们不批这顿饭钱的话,隐藏的后果有三个:


  • 后果1:我都拉着甲方一起加班了,如果不请他们吃顿饭,后面甲方不配合了,可不能赖我啊;


  • 后果2:现场的小伙伴们最近也都得加班,如果不请他们吃顿饭,后面这群人不配合加班了,这也不能赖我啊;


  • 后果3:我是为现场的小伙伴们申请福利了,领导们不批,那是领导们的问题了,可不能说跟着我累死累活,连一点好处都没有啊。


妥妥的阳谋,领导们不批都不行,哈哈哈!


层面二:展现自己的心意。


中午跟大家伙一起吃饭,时不时给大家整杯蜜雪冰城喝一喝,别看只是一杯几块钱的饮料,这可是我自掏腰包请大家喝的。


而且,这只是一杯饮料吗?这可是我们彼此之间,深厚的革命友谊啊。


四、结语


通过以上这些手段,反正项目现在正在逐步步入正轨,作为管理者,我把工作理顺,安排完之后,就在客户现场天天打酱油就行了,但所有人都说我工作干得不错。


最后再说一点,我们之前就总结过,作为一位PM,工作的时间长了,不可能一直是做图仔仔的,职业生涯的发展,有两个方向:


方向一:成为一名产品专家,和业务强绑定,这种方向的性质就是专一型人才,后期如果想换工作的话,只能在某个特定的业务领域内换,可选择性较小。


方向二:成为一名管理专家,这种方向的性质就是通用型人才,后期如果想换工作,选择空间就比较大,而我走的就是这个方向。


本文来自微信公众号:晓庄同学产品笔记(ID:PM-xiaozhuang),作者:晓庄