为何会陷入“烂尾循环”

      作为管理者，对跨部门协作一定不陌生。

      回到科学管理之父泰勒当初的逻辑：当初因为工作效率问题，才有了专业化分工，才有了“部门”的存在。然而，怎么也没想到，“部门”有了，分工也专业了，但却又遇到了“跨部门协作”困难的问题。

      比如，某个跨部门协作项目刚刚启动时，启动大会往往热热闹闹，大领导来站台，强调项目的意义，强调各部分要团队协作，然后大家当场表态：一定全力支持项目，一定会配合其他部门的工作。

      然后呢？还不到一个月的时候，作为项目主导部门的你，会发现以下问题：

•       项目进度停滞；

•       交付内容缩水；

•       总有意外变量；

•       项目节点总会出现“烂尾”；

•       每次的项目阶段复盘会，几乎变成了大型吵架与推诿现场；

      当初的表态不见了，当初的承诺没有了。这到底是为什么？当我就这个问题在企业进行调研时，得到的回答是：

•       “沟通不够顺畅”；

•       “协作配合不够”；

•       “各部门目标的优先级冲突”；

•       “某某部门总这样，就是不愿意合作”；

•       “没办法，我们部门也有很多事要做”;

      这些看似合理的原因，其实只是表象。真正的问题只有一个：

      说一千，道一万，不能带来结果的跨部门协作，都是耍流氓。

      没有人，愿意对跨部门协作的最终结果负责。

协作有了，结果没了

      一提到跨部门合作，很多管理者立马想到的是：

•       建微信群/飞书群/钉钉群等；

•       每周例会/节点会/项目会等；

•       沟通流程/分工/机制等；

•       甘特图/任务分解表等；

      这些当然都很重要，但它们解决的往往只是跨部门协作中的“信息传递”和“任务分配”问题，并不能给你直接带来交付结果。

      如果每个部门都把重点放在怎么协作上，即便有共同利益，彼此没有什么KPI冲突，只要没有人对最终的结果负责，那么再顺畅的协作，依然会“烂尾而终”。

      而常见的跨部门协作项目“烂尾”，往往有3个常见的陷阱：

      1、分工到人，但责任分散：每个人只负责自己的部分，没人对整体项目成败负责。项目失败了，大家都能自证清白；

      2、过程有监督，但结果没人验收：跨部门之间的项目周报、例会不断，但没人真正站出来对最终成果说“这符合/不符合项目目标”；

      3、优先级总是会被部门本职工作“冲垮”：既然是跨部门协作，有的部门担当主力，有的部门自认为自己是配角，对于那些“配角”部门，他们天然认为自己是“配合”，一旦遇到本职工作冲突，或主动、或被动，都会将时间和资源转移到本职工作上，这不亚于对跨部门协作项目的“资源抽逃”；

      为什么会这样？有一个核心症结，一直在困扰跨部门协作项目，那就是责任的“稀释效应”。

      在心理学上，“责任分散效应”指的是：当一件事由多人共同负责时，每个人都觉得别人也会出手，于是没人真的出手。

      在跨部门协作项目中，这种效应被快速放大。比如：

•       A部门觉得这是B部门的专业领域，而B部门觉得项目发起人（A部门）要负责；

•      项目发起人觉得业务部门应该主导，而业务部门觉得支持部门没全力配合好，部门之间来回推诿；

•      最后大家都觉得自己只是“配合者”，都不是“结果负责人”，有的会联合起来，把责任人指向上级；

     这种责任稀释效应，一旦没有构建有效的机制去对冲，就会成为跨部门协作项目的“隐形杀手”。

     那么，优秀企业是如何做的？

他山之石：

优秀公司的最佳实践

      案例1：腾讯的跨部门“产品Owner制”

      腾讯内部的跨部门项目，通常会指定一个唯一的产品Owner。

      这个Owner不一定是最高职位的人，但必须是对最终结果负全责的人。

      举个例子，腾讯在开发某业务平台时，涉及产品、技术、运营、法务、市场等多个部门。在项目初期，跨部门之间就明确：

•       产品经理A是唯一Owner；

•       所有跨部门决策，Owner有最后拍板权；

•       各部门KPI中绑定对该项目的支持指标；

•       项目验收时，先评估Owner是否达成目标，再分解到各部门绩效等。

      在这种机制下，即使部门之间有冲突，也会因为Owner的“单点责任”而推动决策落地。

      最终，正式这种高效的跨部门协作方式，才保证了该业务平台的顺利上线和达标。

      案例2：特斯拉的跨部门集成模式

      众所周知，特斯拉在跨部门协作项目中向来是高效著称，一是因为马斯克倡导的“简单直接高效”的企业文化在起作用，二是因为特斯拉以结果为导向的工作机制贯穿到业务价值链全程，流程和机制保障了跨部门协作的效果。

      尤其在特斯拉新车型研发中，跨部门协作是常态，包括设计、工程、制造、供应链、品控、市场等部门都必须同步推进。而马斯克在跨部门项目协作上有一个铁律：“每个关键里程碑，必须有一个单点负责人，名字一定要写在进度表第一行”。

      在《埃隆·马斯克传》那本书中，提到了一个案例：当时在处于Model 3的生产爬坡期，供应链和制造环节多次发生冲突。马斯克直接把负责电池模组产线的工程师调到总装厂，与制造负责人并列驻场，并赋予其直接决策权。这样一来，任何跨部门的问题可以在现场当天解决，而不是等一周的会议。

      结果是：Model 3的产能在关键阶段完成了“三倍提速”，这背后靠的不是开更多的会，而是明确单点结果责任人，让跨部门协作指向真正的责任和结果。

如何让跨部门项目不“烂尾”？

      在访谈过很多优秀企业的跨部门协作项目最佳实践后，为大家总结了跨部门项目协作“四步法”，专门解决跨部门项目所出现的“烂尾”问题：

      第1步：明确“单点结果责任人”比如：

•       项目立项时，必须明确唯一的结果负责人（Owner），名字写在立项文件第一行（这一点，非常马斯克）；

   

•       Owner对项目整体成败负责，不允许只对“自己部门的部分”负责（指向结果）；

   

•       Owner必须有跨部门协调和决策权等。

      第2步：结果先行，过程跟随 比如：

•       项目计划表里，先定义清晰的最终交付结果（可以衡量、可以验收）；

   

•       再去拆分各部门的过程任务，而不是先分任务、再想结果；

   

•       所有部门的工作，都要能映射到最终结果上等。

      第3步：绑定绩效与资源 比如：

•       把跨部门项目的关键成果，直接绑定到参与部门和关键人员的绩效考核里（说明一点：不能每件事都这样做）；

   

•       对于关键里程碑的达成，资源优先倾斜——人、时间、预算要都要硬性保障；

   

•       不能出现“部门优先级冲突”就任由项目延误等情况的发生。

      第4步：里程碑验收+追责机制 比如：

•       设定清晰的阶段性验收节点，不仅看进度，还要看质量；

   

•       如果结果偏离目标，要有追责机制，而不是“大家都尽力了”；

   

•       Owner必须在每个阶段复盘问题，并提出修正计划等。

      当然，除了这些之外，来自管理层（特别是高层）的支持至关重要。这包括：

•       关键时刻，高层必须站出来为项目背书，明确它的战略地位和优先级；

   

•       遇到跨部门冲突时，高层要快速裁决，避免低效拉扯；

   

•       高层要对Owner进行直接管理，确保责任到底、结果导向等等。

      如果只是“口头支持”，一到关键时刻，永远都是让各部门自己协调，那样的话，跨部门项目的“烂尾”风险就大大提升了。关键时刻，高管也得靠谱，也要负责，这件事也非常重要。

      千万不要开会开得好、目标对其对得好、例会记录的好、流程和规则定的好，可就是跨部门协作的结果不好，那真的不是我们想要的。

      毕竟，跨部门协作最终想要的，是好结果。

（全文完）