项目进行一半,有五项高风险:
业务无法参与调研。因特殊原因,前期业务不方便参与,也无配合意愿。
Sponsor、业务关键方,对于产品定位认知错误。将专业管理系统,当成OA使用。
关联系统配合意愿低,方案不确定。联动导致项目方案变更,大的改动就有三次。
干系人对于项目期望不一致、要求不一致。向上升级无法获得支持。
产品不成熟,同时乙方实施团队与产品团队运作机制存在问题。
说白了都是坑,不过又有哪个项目不是坑坑洼洼一片。能做的,只是仔细总结经验教训。为了下一个项目,提前规避,或老实填坑。
-
注重原型法,即使是静态界面也可以向业务用户演示,做到每周有成果可演示,收集差异化需求
-
测试场景,正向+逆向,以及所有对接系统
-
上线切换计划需做评审,数据如何切换,新旧系统如何交接
-
做事要足够细,到领导处不要再有任何确认、梳理的动作,提高决策质量与效率;风险点及时汇报,既然无法靠自己力量把控住,尽早爆给领导
-
产品替换频繁,一、两年即更换平台。换一个领导换一套架构,则上新系统
-
Sponsor是谁?不能是IT部门的分管领导,否则就是为了上系统而上系统
-
做项目就跟打仗一样,任何时候会蹦出一件事情,某处的干系人会突然出现、提出一个要求,成员突然退出
-
对于项目的理解、定义不准确,导致方向错误,做下去大概率是失败的。但做项目,即使大家知道是要失败,该继续的还是要继续。因为大部分项目,无论做成与否,在做的过程中成员都会认为,这项目要挂了吧
-
产品、实施方法、团队,新三角
-
方案的质量,有时即使明知是问题,但大家都在赶进度,没人搭理,或者让团队停下来处理的成本也很高,只能等问题暴露,风险发生,团队才会重视,才会去解决
-
项目组成员识别要准确,否则不在项目组很难驱动。特别涉及到数据的梳理,很难动之以利
-
当需求来自领导时,一定要慎重,特别是系统级需求,那是否换一个领导需求就变会了呢?特别来自大领导的需求,往往就会认为是刚性需求,任何要求都要满足
-
资源跟着平台走,谁对预算负责,可以负责产品选型,就会在厂家地位发生质的变化
-
做项目的最大收获,是对于“方法总比比问题多”这句鸡汤的坚定信念感。看似不可能的问题,无解到死局,到最后一定会有解决办法的。一方面是该活动拖到成为关键路径,严重影响进度时,总会有人提出合适的解决办法,可能是之前懒得说,或者倒逼出灵感,或者是领导重视、协调资源,或者是相关方不得不最终妥协、达成一致
-
向死而生,都知道上线可能失败,风险极大。流程、数据、方案,产品定位、与关联系统的数据集成,都是问题。但已经实施了这么久,最后一定要看到结果。领导也好奇,最后会是什么样?而且总有个万一,假如系统上去了没立刻死掉,赖活着,说不定可以靠运维优化救活
-
千万不要让自己手上的任务,变成关键路径。明明因各种原因,项目要延期,没及时跟领导说,结果在自己的任务变成关键路径时暴露。就变成项目的整体延迟,都是你的问题了。。。
-
做项目,沟通的重要性怎么强调都不为过,主动沟通与被动沟通同样重要。你以为没人找你,或者你找了、人家没理你,就不是你的责任了吗?最后项目延迟,怪罪的还是你。with其他项目组、系统、干系人
-
要求对方配合的东西,一定要发邮件正式声明。涉及项目进度,每天跟进,打电话追,不怕烦
-
同理,到了关键时刻,任何风险、问题,都要及时跟领导反应,找不到人打电话
-
进度delay,关键点把控力度不够,风险/问题项及时反映。
-
谁担责,谁决策
-
项目经理的关键能力-发声能力。让大家都能感受到你的存在,任何问题、风险及时爆出,若涉及到项目进度,追到他崩溃。因为只要有人没听到,就是你的责任。不仅要发声,还要确保接收方理解正确,这也是项目经理的责任
-
即是项目是直线汇报,也要告知相关方。结论,要通知到位。否则以为是为了少一事,不通知,干系人早晚会知道,并在后期跳出来,干预项目
-
先考虑是否需要咨询公司,梳理流程
-
一个系统若全包,即使有不兼容场景,倒也好办。最有意思的是把一类场景封装,移到另一个系统承载,就会出现铁路警察现象,大量精力花在边界澄清上
-
计划管控力不足,认为计划准确度低,因而意义不大,不够重视。就会导致工作节奏缺乏掌控感,清晰度不足。管控的基石,是计划
-
参与联合项目组会议,发现痛点是相通的。这是因为许多是系统问题,系统内部及系统之间
-
任何会议,必须提前十分钟准备完毕。总会有各种问题,沟通方式、人员、场地、设备、资料
-
计划,难在跟进颗粒度大小的把控。沟通群不要多,一个内部实施群,一个外部实施群
-
计划细化,实时梳理关键路径,特别涉及外围系统接口