面对领导迟迟未下决定的事情，项目经理应该怎么快速去推动事情的进展

一、本期案例

岗位：产品经理+研发经理

行业：电信行业

案例背景： 公司有一套去年开发的微服务，我没有参与，但是派人支撑过，初步了解后发现不方便使用，最后个人开发了一套，给领导演示后比较认可，同时让各省项目经理参与演示了一遍，但领导迟迟未下决定，猜测：新搭建的功能不错，但是没有去年老架构可控。

问题：面对领导迟迟未下决定的事情，项目经理应该怎么快速去推动事情的进展?

二、嘉宾分享

01

1.png

领导对演示结果满意，却迟迟未推进，这必然是某方面或某些方面依然存在问题，使领导不能下定决心。要解决一个问题，需要先确定问题在哪。所以首先要根据项目实际情况，结合理论知识进行分析，找出领导担心的问题。

一、可能存在哪方面问题

1. 系统质量

系统效果满意，不代表对系统的质量也满意。系统能否稳定运行，是否能抗住高峰请求，这些都是需要考虑的因素。

2. 风险

任何的系统更新都存在风险，变更架构的风险更高。更新过程能否顺利，出问题时如何解决，更新完成后，数据能否平滑过度。

3. 成本

整个升级过程，需要投入多少人力，多长时间。

4. 干系人

系统升级对哪些人会造成影响，尤其是开发老系统的部门的相关领导和人员。

5. 公司战略

了解公司战略方向是否发生改变。

二、解决方法

根据上一步骤确定可能存在哪些问题后，可以逐个解决。

1. 质量方面

对系统做充分在测试，包括功能测试、性能测试等，由测试部门提供最终的测试报告。测试通过，通常情况下能解决领导对系统质量方面的担忧。

2. 风险方面

进行上线演练，确保系统能正常更新升级，必要时编写应急手册。最重要一点：如果更新中途失败，能回退到最初状态。

3. 成本方面

如果成本较高，分析各个过程，优化环节以节省成本(可以借助第三方工具)。如果成本不能降低，或降低幅度不大，则向领导说明这次更新升级的重大意义，让领导愿意投入更多的成本。

4. 干系人方面

一定不能想当然的认为，系统更新后对所有人都好。要思考下系统更新了对原系统开发部门有没有什么影响，要协调好各方面的关系，必要时可做出一定妥协。

5. 公司战略方面

通常情况下不存在这个问题。但如果公司战略方向发生变化了，那就别折腾了。除非老系统存在严重漏洞，或者新系统成本很低，并且后续能节约较大的运维成本，否则不太可能再对老系统更新。

三、结束语

遇到类似问题，不能只从系统好坏方面考虑，需要多个方面分析。领导站的高度不一样，考虑在因素也会更多，有些看似很傻在决定，有时候只是一种利益交换而已。比如干系人方面，曾经有一个项目在快收尾的时候被叫停，因为和开发原系统的部门有利益冲突，最终各方领导讨论后，终止项目。

02

2.png

首先就案例背景来谈谈个人的看法：

1、案例主人公认为微服务不方便使用，然后立马自己开发一套新产品，虽然做了演示，领导口头表示认可，但迟迟没有后文。从给出的描述上来看，我认为主人公的操作有些不符合流程，或者说主人公跳过了某些必须的环节。

任何一个项目的开始一定是要先做可行性研究、商业等前期调研工作，提供相应的分析文档给可决策的关键相关方，获取书面同意后，才有后面的一系列动作，否则所有的提前投入几乎都是沉没成本(不排除事后补流程，规避沉没成本)。案例中的主人公的操作中秋缺失了这部分

2、案例的主人公从事的是电信行业，是技术密集型产业，在国民经济中占有重要地位，意味着该行业的任何一项变革、更新，都要慎重。既要考虑技术更新带来的便捷，同时也要考虑对现有环境稳定性的冲击。

所以个人觉得主人公想推动新产品替代旧产品，应在完成新产品演示后，及时完成新旧产品差异性分析、新产品的优势报告提交给领导。综合考虑行业特殊性对信息化产品的要求，与领导就此事再次做全面的沟通汇报。

针对提出的问题，有如下几点个人看法，供参考。

1、第一个场景，你已将需要领导决策的事情的方方面面都分析好并同步提交给了领导。这个时候领导还迟迟不下决定，想要快速推动除非找到比领导跟高级别的管理人员施加影响，不然只有天天找领导沟通汇报，锲而不舍的问领导结果，当领导被问烦了自然就有结果了(结果十之八九是不好的)。

2、当你面对领导迟迟未下决定的事情，作为pm想去快速推动事情进展，能做的是把能帮助领导决策的文档、数据等尽可能全面收集整理并提交给领导。简单来说做到以下2个内容：

①、做好每个选项的详细说明，以及选项之间优劣情况分析。

②、多与领导沟通，识别领导的顾虑和担忧，针对领导的顾虑、担忧完善报告，提交给领导。剩余的操作就见前面场景的描述。

结合案例，我觉得主人公的问题不是简简单单的想问作为PM如何快速推进领导迟迟不下决定的事情。他想问的是如何影响领导尽快决定是不是用他开发的新产品来替代旧产品。基于这个认识，我认为主人公做为公司的产品经理是有责任有义务向公司领导提出自己认为更好的产品来替代已有的可能落后的产品，出发点是好的。但是提出建议时，不能仅仅是演示，同时要将新产品的基本情况和优势说明及时向领导汇报。与领导汇报沟通时，要识别出领导的顾虑和纠结点，有针对的调整方案和设计，最后整体提交给领导，让领导评估(一般不太重要的1~2天即可)。过了评估期后，增加与领导沟通的频率。明确询问领导行不行。行就考虑正式开发、实施新产品等后续的细节，不行就终止该事情，然后改干啥干啥，不用再管这个事了，毕竟你还有别的事情和项目做。

作为研发经理，在新产品并没有得到设计确认的情况下，私自开发(虽然没有使用其他资源)，是不可取的。

先斩后奏，虽是权变，但结果却不总是太好。

03

我有话说

眉间雪-嘉兴-制造业：

一个新搭建整个推动下去需要好多个过程。可以先建立个流程图，再分析是卡在了哪个环节，再分析卡在了这个环节的原因。领导一直未下决定，可能卡在了上层领导那里，又或者旧系统的既得利益者是公司的重要相关方等等。

牧云-成都-产品：

个人觉得还是从需求和沟通着手，一定要了解清楚领导考虑的维度是啥，你自己考虑的维度又是啥，好好喝个茶求同存异一下，把领导的方向视为自己的方向。