企业管理的108个问题 · 第92问

上一问我们聊了项目复盘（第91问），核心结论：复盘不是为了”评价过去”——而是为了”投资未来”——让错误只犯一次。

但如果要找一个”所有跨部门项目都犯过的错”——那大概率是这一个：

权责不清。

“这件事归谁管？””这个审批谁来签？””如果项目出问题了——谁负责？”

——问一个人——说不清楚——问一圈人——更乱了。

跨部门项目最常见的死法——不是”做不完”——而是”不知道该谁做”。

一、权责不清的三种”经典症状”

症状一：无人区——“有人做的事没人做”

一个任务在项目计划里写着——但没有指定具体的”责任人”——大家都觉得”应该是别人做的”——结果——谁都没做。

等到发现的时候——已经晚了——项目卡住了——然后才来问：”这个事到底归谁？”

症状二：灰色地带——“两个部门都觉得该自己管”

市场部觉得”这应该我们定”——品牌部也觉得”这应该我们定”——两个部门都觉得自己”有权”——但谁都不想做”执行”——来回扯皮——时间全浪费在”确认边界”上了。

症状三：有责无权——“一个人扛了责任——但说了不算”

这是最惨的。

项目经理被任命为”项目负责人”——但”调不动别的部门的资源”——“催不动别的部门的人”——出了问题——“你负责推动解决”——但”你没有任何实际权力”。

——这就是经典的”有责无权”困境。

二、权责不清的根源——不只”人是问题””

要想解决问题——先要搞清楚：为什么权责会不清？

根源一：组织架构的”天然冲突”

大多数公司——是按”职能”分的：市场部、销售部、技术部、产品部——这是”纵向”的架构。

但项目是”横向”的——一个项目通常需要跨多个部门协作。

当”纵向”的组织，遇到”横向”的项目——权责不清——是”天生的”，不是”谁的问题”。

根源二：没有”唯一的决策者”

跨部门项目里——经常出现”多头管理”：

• 市场总监觉得”营销方向”应该他来定
• 产品总监觉得”用户体验”应该他来定
• 两个人都”想参与决策”——但没人”为整体结果负责”

结果：要么撕——要么拖——要么”谁声音大听谁的”——但从来不是”按规则来”。

根源三：激励机制不匹配

一个残酷的事实：

每个部门的KPI——都是”向自己的部门负责”——不是”向这个项目负责”。

所以——当项目需求跟部门利益冲突时——部门负责人优先保护”自己的地盘”——而不是”项目的利益”。

“这件事不该我们部门做——太影响我们的核心工作了。”

——这句话听着耳熟吗？

三、解决权责不清的”四把刀”

第一把刀：RACI矩阵——“到底谁负责”

RACI是项目管理里最经典的”权责分配工具”。

操作方法：

列出项目里的每一项任务——然后问谁：

• 谁是R？ （谁实际操作这件事？）
• 谁是A？ （谁拍板？谁对最终结果负责？）

关键规则：

1. 一个任务——只能有”一个A” ——不能有两个人都”对这件事负责”
2. R和A可以是同一个人——但不能”没有A”
3. C和I——不能太多——太多C会导致决策太慢——太多I会导致信息过载

实操示例（一个”新产品上线”项目）：

一眼看清——每个人知道自己该做什么——也知道谁是”最终拍板”的人。

第二把刀：一份”项目宪章”——“上项目前先约法三章”

很多权责不清——是因为”项目开始前就没说清楚”。

项目宪章——就是”项目开始前”——把所有参与方拉到一起——签一份”权责约法”。

项目宪章要包含：

1. 项目目标： 这个项目要达成什么目标？
2. 项目范围： 做什么？不做什么？
3. 核心角色与职责： 谁是项目经理？谁负责哪个模块？谁是最终决策者？
4. 资源承诺： 每个部门承诺派多少人？多少时间？
5. 决策机制： 遇到分歧时——谁说了算？
6. 变更流程： 需求变化时——怎么处理？

项目宪章不是”走形式”——是”出了问题时翻出来看”的依据。

“你说市场部不负责这个？——但项目宪章里明明写着——市场部负责’用户调研’——你说不归你们管——那当初为什么签了字？”

——这就是”白纸黑字”的力量。

第三把刀：一个”唯一的项目经理”——“有责必须有权的”

跨部门项目——必须有一个”枢纽人物”。

这个人需要具备：

• 明确的项目授权——公司/CEO明确授权给他——“在项目范围内——你有权调用跨部门资源”
• 直接向高管汇报——不是”跟各部门慢慢沟通”——遇到”部门不配合”——他能直接找老板
• 背项目的”唯一结果”——项目成败——一个人扛——不是”大家一起扛”（”大家扛”=”没人扛”）

建议： 如果项目重要到”涉及多个部门”——项目经理的级别——至少不能低于”部门负责人”——或者——由一位高管直接兼任”项目Sponsor”。

第四把刀：跨部门协调会议——“定期的、结构化的对齐机制”

权责不清不是”一次就能说清楚”的——运行过程中”边界会模糊”——需要定期”重新对齐”。

跨部门项目的”标准对齐节奏”：

一个实用建议： 在项目群里——每周五下午发一条”权责确认清单”——每个部门负责人回复”确认”——确保边界没有”模糊”。

四、一个实战案例：跨部门产品上线项目

背景： 某公司要推一个”会员积分系统”——涉及产品部、技术部、市场部、客服部。

一开始——“传统权责模式”：

“大家一起做”——“分工嘛——大家自己商量”——结果：

• 产品功能设计完成了——但没人确认”积分规则”是否跟市场策略一致——因为”这该市场部定”——但市场部说”这该产品部定”——扯了2周
• 上线前——没人通知客服团队做培训——上线当天——客户的积分问题——客服不会回答——投诉飙升
• 出了问题——老板问”谁负责？”——没人能回答

后来——用RACI改造后：

改造后的效果：

• 积分规则——市场总监一锤定音——产品经理执行——不再扯皮
• 客服培训——指定了”培训主管”负责——培训完——客服总监签字确认——不再”没人管”
• 项目出了问题——CEO是最终”A”——项目经理直接找CEO决策——不再”没人拍板”

——权责从”模糊”变成”透明”——项目推进速度提升了50%。

五、最后的话

权责不清——不是”人不配合”——是”机制没到位”。

如果你指望”大家自觉配合”来做跨部门项目——那你大概率会失望。

好的机制——是”不需要自觉”——而是”按规则办事”。

RACI矩阵把”谁负责什么”写成白纸黑字——项目宪章把”出了事怎么办”提前说好——一个”有责有权”的项目经理让决策有主心骨——定期的对齐会议让边界不会模糊。

这四个机制到位了——跨部门项目——至少不会再”死”在权责不清上。 🎯

明日预告：第93问 —— 项目经理凭”空”指挥有责无权，怎么破？