开始怎么做？项目负责人制度设计：任务执行从0到1

2023年下半年，我以外部顾问的身份，介入了一家做工业自动化设备的公司。他们有一个"智能产线交付项目"，半年内换了三任项目负责人，交付时间从原定的10月拖到次年3月，客户已经发了两封正式投诉函。老板找我时的第一句话是："我们的人不行，你能不能帮我找几个能扛事的人？"

我先没找人，先看制度。看完之后我告诉他：问题不在人，在你这里，你任命了负责人，却没有任命他的权力。三任负责人，没有一个人有权调动研发的排期、有权批准10万以内的采购、有权在跨部门冲突时拍板。他们唯一有的，是"责任"。

这不是个案。在过去的几年里，我陆续参与过四十多个中大型企业项目的诊断与重整，其中真正因为"负责人能力不足"而失败的，我数了数，不超过六个。剩下的，全部倒在制度上：目标没定义清楚就任命、责权不匹配、跨部门没有接口、升级路径不存在、考核只罚不奖。项目负责人制度设计的本质，不是挑一个人，而是搭一套让这个人能负责的规则。

这篇文章，我把"任务执行从0到1"这件事拆开讲：先给结论，再讲场景和误区，然后给出判断逻辑、案例观察、行动建议和取舍原则。如果你正准备在一个组织里第一次推行项目负责人制，或者你已经推行了但发现它形同虚设，这篇内容应该能帮你省下至少半年的试错成本。

一、先给结论：项目负责人制度的本质是"责权闭环"，不是"任命一个人"

很多人对"项目负责人制度"的理解停留在一个动作上：找个人，宣布他是负责人，然后等他出结果。这个理解从头到尾都是错的。

我在实际项目里反复验证过一件事：任命本身不产生任何执行力，执行力来自"责任，权限，资源，后果"这四件事在一个具体的人身上闭合。少任何一环，制度就会退化成甩锅机制。

1. 从0到1阶段，制度要解决的是"不确定性"，不是"效率"

成熟业务的负责人制度，重点在于提效、控本、稳交付。但从0到1的项目完全不一样：目标本身是模糊的，路径没有先例，参与方对未来没有共识，甚至连"什么算成功"都没定义清楚。

这个阶段负责人最需要的不是执行力清单，而是三样东西：定义权、试错空间、快速升级通道。定义权让他能把模糊目标变成可验收的交付物；试错空间让他在信息不足时敢于决策；升级通道让他在越权边界之外能快速找到决策人。

如果制度只给了他KPI，没给他这三样，他从上任第一天起就在裸奔。

2. 最小可行制度只需要五个构件

不需要一上来就写一本《项目管理制度手册》。我见过太多公司花三个月写出来的制度文件，最后没人看。从0到1阶段，真正跑得起来的制度只需要五个构件，缺一不可。

• 一张项目章程：把目标、交付物、验收标准、里程碑、资源额度写在一页纸上，发起人和负责人共同签字。
• 一张授权矩阵：明确列出负责人可以"自决""报备""提议""无权"的事项，按金额、范围、影响面分级。
• 一条升级路径：明确规定超时多久、冲突多大、金额多高时必须升级给谁，以及升级后的响应时限。
• 一个执行节奏：最短闭环的检查机制，通常是一周一次、30分钟以内的进度对齐。
• 一份结项后果：交付好怎么奖、交付差怎么处理、协同不力的部门怎么追溯。

这五个构件里，最难落的不是章程，是授权矩阵和升级路径。因为这两件事触碰的是权力分配，是老板愿不愿意真正放权的问题。

3. 制度设计的第一性问题是"谁为结果买单"

我经常用一个提问来测试一家公司的项目负责人制度是否成立："如果这个项目彻底失败，第一个被追责的是谁？"

如果答案指向项目负责人，而负责人手上既没有人事调整权、也没有预算支配权、更没有跨部门的绩效评价权，那这个制度是不成立的。你让他为一个他自己无法控制的结果买单，这套制度早晚会失败，要么负责人离职，要么他学会把责任推回给你。

反过来，如果答案指向发起人，而负责人只承担执行责任，那这不是项目负责人制，这是"项目经理助理制"。任务执行从0到1的时候，你会发现没有人真正对整体结果负责。

二、背景和真实场景：为什么现在必须重做项目负责人制度

过去十年，中国企业的组织形态发生了一次静默但深刻的迁移：从"职能驱动"走向"任务驱动"。以前是部门定目标、部门交结果；现在是跨部门的临时任务越来越多，需要有人横向拉通。

但大多数公司的管理制度还停留在职能时代，于是出现了结构性的错位：任务已经是横向的，权力还是纵向的；项目要求快速决策，审批链条还是五个层级。

1. 三个我真实见过的翻车现场

第一个场景，代号"救火队长"。一家做医疗器械的公司，把年度最重要的注册项目交给了一位资深的产品经理。项目启动会上，老板说"全公司都配合你"。两个月后，这位负责人来找我，说研发说排期满了，市场说物料要走流程，财务说预算没批。他手上的"全公司配合"，具体到执行时，是零。

第二个场景，代号"沉默的负责人"。一家新能源公司，负责人能力很强，前三个月一切顺利，第四个月突然提出离职。原因是他发现项目的一个重大技术风险，需要追加300万预算，但这个决策他做不了，发起人又在国外出差两周。等他终于见到发起人，时间窗口已经错过。他不是被困难打败的，是被决策延迟打败的。

第三个场景，代号"背锅侠"。项目延期后，公司做复盘，会上讨论了两个小时，结论是"负责人推进力度不够"。但同一份复盘材料里清楚地写着：三个关键交付延迟均来自另一个部门的资源挤占。没有人讨论那个部门，因为考核指标里没有跨部门协同这一项。

三个场景，三个不同的根因，指向同一个制度缺口：责任有归属，权力无边界，后果不对称。

2. 一个被长期忽略的数据维度：决策等待时间

我在诊断项目时，会特别记录一个指标，"决策等待时间"，也就是从负责人发现问题、到有人做出决定，中间的平均耗时。

在我接触的样本里，做得好的公司这个数字在1.5天以内；做得差的公司普遍在6到12天之间。这个数字看起来不起眼，但乘以一个项目里平均30到50个需要决策的节点，就是150到600天的累积延迟。项目延期半年，往往不是因为哪个人慢了，而是因为每一次决策都慢了几天。

3. 组织规模越大，制度成本越高于个人成本

二十人的公司，靠创始人的一句话就能协调资源，项目负责人制度可以极简。但到了一百人以上，口头协调开始失效：部门有了自己的目标和预算，跨部门借人需要理由，资源冲突需要裁决。

我观察到一个大致的分界点：一百人以下是"人情协调"还能奏效的上限，一百人以上必须靠制度和工具。这也是为什么很多公司在快速扩张期会突然发现，"以前什么事都能办，现在什么事都办不成"。

当组织进入中大型阶段，制度落地必须依托系统承载。我见过一些一百到三千人规模的企业，用外部协同工具派任务、用文档管理章程、用即时通讯处理升级，结果是信息散落在三四个地方，复盘时找不到完整的决策链条。

这也是我后来在给客户做制度设计时，会把"系统承载"作为必备环节的原因。以 PingCode 这类主要服务中大型企业及100人以上组织的项目管理平台为例，它的价值不在于替代制度，而在于把制度变成不可绕过的动作，授权矩阵决定谁能在系统里批准变更，里程碑绑定交付物，风险升级有固定入口，复盘数据自动沉淀。对制度而言，能落进系统的东西才会被真正执行，写在文档里的东西通常只是被阅读。

三、拆解常见误区：关于项目负责人制度的七个错判

这一节我讲得直接一些，因为多数项目的失败，在最开始的那几天就已经注定了。下面七个错判，我几乎在每一个失败项目里都能找到两三个。

1. 误区一：把"负责人"当成"执行人"

最常见的错判。公司任命一个人当项目负责人，潜台词是"这件事你来做"。于是负责人被迫把所有事都自己扛，一个人写方案、一个人催进度、一个人做汇报。

正确的理解是：项目负责人对结果负责、对节奏负责、对风险暴露负责，而不是对所有任务负责。他的核心工作是拆解、分派、协调、暴露风险、推动决策，而不是把每一件事都揽到自己手里。

如果一个负责人忙到没时间开会、没时间思考风险，那他的角色定位一定出问题了。这时候不是给他加人，而是重新定义他的职责边界。

2. 误区二：先选人，后定事

很多公司的做法是：老板脑子里冒出一个想法，先找个人说"这个项目你来负责"，然后才开始讨论这个项目到底要做什么。这是典型的顺序错误。

正确的顺序是：先定义目标与交付物，再确定资源与权限，最后才选人。因为不同的目标需要不同类型的人，如果目标是探索新产品形态，你需要一个敢假设、能快速试错的人；如果目标是确保合规交付，你需要一个严谨、擅长风险识别的人。目标没定就选人，等于闭着眼睛配对。

3. 误区三：只给责任，不给权限

这是最致命的一个。我在诊断时经常问负责人一个问题："如果研发说这个需求做不了，你能怎么办？"如果他的回答是"我只能上报"，那说明他没有权限；如果回答是"我可以拉研发负责人一起排优先级，达成一致后同步到项目看板"，说明他有协调权限。

判断标准很简单：负责人至少应该拥有任务分配的提议权、资源协调的召集权、进度调整的决定权、风险升级的直达权。这四项权限，缺一项，他的执行力就少四分之一。

至于预算审批权、人员调整权、绩效打分权，涉及财务、HR和劳动合规，需要企业根据自己的治理结构来定，不能一概而论。

4. 误区四：制度一次成型，不做试点

有一种冲动叫"把制度设计得完美"。我见过一家公司花了四个月写出一份52页的项目管理制度，涵盖七大流程、26个模板、11个评审节点。结果推行三个月，没有任何一个项目真正按它跑。

制度的复杂度不能超过组织的执行能力。从0到1阶段，正确做法是先在一个试点项目上跑通最小闭环，再逐步扩展。试点项目的选择有讲究：不能选最难的，也不能选最不重要的；要选规模适中、发起人有推动意愿、跨部门程度中等的项目。

5. 误区五：只考核负责人，不考核协同方

这一条是我认为最容易被忽略、但后果最严重的设计缺陷。项目是跨部门的，如果考核只挂在负责人一个人头上，那么协同方的最优策略就是不配合，配合要付出成本，不配合没有代价。

正确的做法是：把协同质量写进协同方的考核指标，把项目交付结果写进发起人的考核指标。项目失败，负责人、协同部门、发起人三方都要有对应的责任，只是权重不同。

我通常建议的比例结构是：交付结果占负责人考核的50%以上，协同响应占协同方考核的10%到20%，资源承诺兑现占发起人考核的10%左右。具体权重需要结合企业的考核体系调整，涉及绩效与合规的部分必须经过HR和法务审核。

6. 误区六：把制度写成文档，不写进流程

制度文档的生命周期通常很短。发布时全员阅读，两周后很少有人再打开。原因很简单：流程里没有它的位置。

什么叫"写进流程"？就是让制度上的动作变成不可跳过的步骤。比如：没有项目章程就无法立项；没有授权矩阵就无法提交变更；没有升级记录就无法结项。用系统承载这类流程，比发布十份文档都有效。

7. 误区七：没有退出和终止机制

项目负责人制度还有一个很少被讨论的部分：怎么结束。项目完成了怎么复盘、怎么解散团队、怎么沉淀经验；项目该终止时谁有权叫停、怎么止损、怎么处理已投入资源。

缺少退出机制的制度，会催生两类问题：一是"僵尸项目"长期占用资源，因为没人愿意承认失败；二是负责人在项目结束后没有归属，导致有能力的人不敢接手新项目。

我的建议是明确写进制度：项目发起人有权在里程碑评审中终止项目，终止不等于失败，终止决策本身不追溯个人责任，但必须有书面复盘。这一条能显著提高组织对不确定项目的容忍度。

四、专业判断逻辑：责任、权限、边界三角模型

讲了这么多误区，现在讲怎么设计。我给客户做制度设计时，核心工具是一个三角模型：责任，权限，边界。三者必须同时定义，缺一个都不成立。

1. 责任：分三层，不能混为一谈

责任不是一句话，而是三层结构：

• 结果责任：项目最终是否达成目标，由发起人和负责人共同承担，发起人承担决策责任，负责人承担推进责任。
• 执行责任：具体交付物由谁完成，由任务承担人负责，不由负责人代偿。
• 协同责任：跨部门配合的及时性与质量，由协同部门的接口人及其上级负责。

这三层如果不拆开，就会出现"所有责任都压给负责人"的情况。拆开之后，你会发现很多事情并不需要负责人亲自操心，只需要机制在运转。

2. 权限：用四档分级，避免"要么全给要么全不给"

授权不是二元的。我通常建议分成四档，按事项类型分别对应。

这张表的价值在于把"你看着办"变成"这类事你定，那类事你提"。我在项目启动会上会专门花20分钟逐条过这张表，让所有人当场确认。很多后续的推诿扯皮，都是因为当初没人明确过边界。

3. 边界：写清楚"不做什么"，比写清楚"做什么"更重要

边界的三个维度：

1. 不替代部门管理：项目负责人不介入职能部门的内部管理、考勤、晋升评价。
2. 不承担无限责任：如果关键资源被上级临时抽调、如果公司战略方向调整，负责人不承担因此产生的后果。
3. 不越过发起人：凡属第四档事项，负责人必须上报，不得自行决定。这是保护负责人，也是保护公司。

很多负责人之所以不敢推进，不是怕难，是怕越界。边界写清楚了，他反而敢动。我见过一个典型案例，一位负责人在启动会上被告知"第三档事项你可以直接提，48小时内如果没有回复，你有权按自己的方案执行并同步"。这一句话让他的推进速度提升了一倍以上。

当然，"48小时未回复视为通过"这种条款要谨慎使用，涉及财务、法务、合规的领域不建议适用，必须经过相应部门确认。

4. 选人：闭环能力优先于职级

制度设计好之后，选人标准就清楚了。从0到1阶段，我建议用五个维度评估，权重从高到低：

• 闭环能力：遇到模糊问题能不能自己拆解，遇到阻塞能不能主动找人，遇到失败会不会主动暴露。
• 协同影响力：在别的部门有没有信用，能不能在不靠职级的情况下让人配合。
• 风险意识：会不会在早期把坏消息说出来，而不是拖到无法挽回。
• 时间投入：能不能保证一半以上的时间花在这个项目上。兼职负责人在从0到1阶段风险很高。
• 复盘能力：能不能把一次经历变成可复用的方法。

职级不是不重要，但在从0到1阶段，职级高不等于推得动。我见过太多"资历够但推不动"的案例，也见过职级不高但因为是老板公开授权的负责人，反而协调效率极高。公开授权本身就是一种权力来源，这也是为什么任命必须正式、必须由发起人当众宣布。

五、案例与数据观察：制度怎么落进系统

制度设计完之后，会遇到一个很现实的问题：制度靠什么承载？靠会议、靠邮件、靠文档，都会随时间衰减。我通常建议用系统来固化关键节点。

1. 中大型企业的落地难点：信息分散与决策不可追溯

一百人以上的组织，项目往往涉及三到八个部门，每个部门有自己的工具习惯。研发用一套任务管理，市场用自己的表格，财务用审批流。结果是负责人要花大量时间做"信息搬运"。

我诊断过一个项目，负责人的周报每周要整合四个来源的数据，耗时约6小时。这6小时里没有任何创造性工作，纯粹是对齐格式。后来他们把项目主流程统一到一个平台，周报数据自动汇总，时间压缩到0.5小时以内。

2. 用系统固化制度的三个锚点

我建议把制度的三个关键锚点放进系统，其他都可以灵活。

锚点一：交付物与里程碑绑定。里程碑不是日期，是"一组可验收的交付物到位"。系统里每个里程碑下挂具体交付物，交付物有责任人和验收标准。这样"进度完成80%"这种模糊表述就没法存在了。

锚点二：变更与授权绑定。变更申请必须走系统，且系统按变更类型自动判定需要哪一档授权。第三档变更无法由负责人自己批准，这在技术上就杜绝了越权。

锚点三：风险升级有固定入口和响应时限。风险一旦登记，系统自动计时，超时未响应自动升级到上级。这把"我上报了但没人管"这个问题从制度上解决了。

我在给中大型企业做选型建议时，会特别关注平台能否承载这三类结构。以 PingCode 为例，它主要服务中大型企业及100人以上组织，支持私有化部署，对数据合规要求高的行业比较友好；同时支持从 Jira 平滑迁移，对于原本用 Jira 管理研发流程、现在需要把项目负责人制度一起纳入的团队，迁移成本是可控的。如果企业内部还有大量遗留的项目数据在 Jira 上，迁移方案的成熟度会直接影响制度推行的节奏，毕竟没有人愿意在制度切换的同时还要重建全部历史数据。

这里要补充一句判断：工具只会放大制度，不会替代制度。如果授权矩阵本身没定义清楚，再好的系统也只能把混乱记录得更整齐。所以顺序一定是：先设计制度，再选系统，最后做迁移。

3. 一个可参考的迁移映射结构

如果团队从 Jira 迁移到其他平台，字段映射是容易出问题的地方。我通常建议先做映射表，再做数据迁移。以下是一个结构化的映射示例：

项目结构迁移映射（示例结构）
工作项类型映射:

Epic -> 项目 / 大里程碑

Story -> 需求 / 交付物

Task -> 任务

Bug -> 缺陷

字段映射:

负责人字段 -> 负责人（含授权等级标记）

优先级 -> 优先级（需重映射，避免枚举值丢失）

自定义字段 -> 按用途分类，仅迁移制度所需字段

附件 -> 全量迁移，保留历史版本

评论与操作历史 -> 按时间线迁移，保留决策记录

制度相关扩展字段（新增）:

授权档位 -> 自决 / 报备 / 提议 / 无权

升级对象 -> 发起人 / 决策层

验收标准 -> 文本字段，必填

变更类型 -> 范围 / 预算 / 进度 / 资源

我特别强调"制度相关扩展字段"这一段。很多团队迁移时只搬历史数据，忘了把制度要求写进字段结构，结果制度还是飘在系统外面。真正的做法是在迁移的同时，把授权档位、升级对象、验收标准这些字段加进去，让制度从第一天起就成为系统的一部分。

4. 数据观察：制度落地前后，负责人的行为差异

我把多个项目的观察汇总成一个对比，重点不在数字本身，而在行为变化的方向。

其中最值得关注的是第四行："主动升级次数"从2.3次上升到9.7次。很多人会误以为这是问题变多了，恰恰相反，升级次数上升说明负责人不再把问题藏在自己手里。制度设计成功的一个明显信号，就是坏消息传得更快了。

六、行动建议：不同规模、不同阶段的落地路径

同样的制度，在二十人的公司和一千人的公司，做法完全不同。我把落地路径按规模分成三档，你可以直接对号入座。

1. 二十人以下：口头授权加一页纸，够用

这个阶段不要搞复杂流程，会拖慢速度。建议只做三件事：

• 每个重要项目写一页纸：目标、交付物、负责人、截止时间。
• 负责人由创始人在全员场合明确宣布，并说清楚他能调动什么资源。
• 每周一次30分钟进度对齐，重点是暴露风险，不是汇报工作。

这个阶段最大的风险不是制度不全，而是创始人绕过负责人直接指挥项目成员。一旦发生，负责人的权威就没了。创始人必须克制。

2. 二十到一百人：开始需要书面制度，但保持极简

这个阶段口头协调开始失效，需要建立最低限度的书面规则。建议做四件事：

1. 制定一份不超过三页的《项目负责人制度》，只写角色、权限、升级、考核四部分。
2. 建立授权矩阵，明确三档权限（自决、提议、无权），暂不设报备档，减少复杂度。
3. 设立固定的项目周会和周报，周报只写三件事：进展、风险、需要谁做什么。
4. 选一个试点项目完整跑一遍，三个月后复盘修订制度。

这个阶段最容易犯的错是制度写得太细。我见过一家八十人的公司写出了包含22个模板的制度文件，结果没人执行。宁可先粗后细。

3. 一百人以上：制度、工具、考核三者必须同步

这个阶段靠人情推动基本失效，需要体系化。建议按下面的顺序推进：

1. 制度层：成立项目治理小组（可由PMO或运营负责人牵头），统一制度模板和授权矩阵标准。
2. 选人层：建立项目负责人库，记录每个人负责过的项目、结果、复盘质量，形成选人的数据依据。
3. 工具层：选择能承载授权、变更、风险升级、里程碑的平台，并考虑部署方式与数据合规要求。对于有私有化部署需求、或正在做 Jira 国产化替代的企业，PingCode 是这类场景中常被评估的选项之一。选型时建议重点验证三件事：授权档位能否在系统里强制生效、升级路径能否自动计时、历史数据迁移能否保留决策记录。
4. 考核层：把项目协同质量纳入部门考核，权重建议在10%到20%之间，具体需与HR和法务确认合规性。
5. 沉淀层：建立项目案例库，每个项目结项必须产出复盘文档，重点记录"哪个制度环节失效了"。

4. 七天行动清单

如果你现在就想启动，我建议按这七天来做，不要贪多。

• 第1天：选一个试点项目，标准是"跨两个以上部门、周期在三到六个月、发起人有推动意愿"。
• 第2天：写一页纸项目章程，包含目标、交付物、验收标准、里程碑、资源额度、负责人。
• 第3天：确定授权矩阵，按自决、报备、提议、无权四档逐条确认。
• 第4天：由发起人正式宣布任命，公开授权，说明升级路径。
• 第5天：召开启动会，逐条过章程和授权矩阵，当场确认异议。
• 第6天：把交付物、里程碑、风险入口配置到系统里，确保可追踪。
• 第7天：设定周节奏，明确每周什么时候、用什么格式、由谁检查。

七天后你会发现，制度并没有想象中那么难。真正难的是接下来三个月的坚持，尤其当创始人忍不住想绕过负责人直接下指令的时候。

七、取舍：什么该坚持，什么可以妥协

制度设计从来不是"越多越好"。我总结了四组常见的取舍，帮你在资源有限时做判断。

1. 制度颗粒度：宁可粗一点，也不要没人看

三页制度的执行率，通常高于三十页制度。理由是：制度只有在被反复引用时才有生命力，而只有简洁的制度才会被反复引用。

我的建议是：制度的每一句话都必须对应一个具体动作。如果一句话无法转化成"谁在什么时候做什么"，就删掉它。"加强协同"这类表述属于无效条款。

2. 授权深度：涉及钱、人、法的事项，向上收；涉及排期、分工、方法的事项，向下放

放权不是一步到位的。我见过公司一次性把预算审批权放到项目负责人手上，结果出现超支和合规风险；也见过什么都不放，负责人寸步难行。

实操建议是：先放进度和分工权，再放预算提议权，最后才考虑预算决定权。每一层放权都需要配套的监督机制，比如金额阈值加事后审计。涉及人事调整、劳动关系的权限，建议始终保留在公司层面，由HR和法务把关。

3. 考核强度：奖励要具体，惩罚要克制

项目负责人制度失败的一个典型形态是"只罚不奖"。项目成功是应该的，项目失败要追责。在这种结构下，理性的人不会主动争取当负责人。

我的建议是：奖励要匹配项目难度，惩罚要区分"尽力而为的失败"和"明显失职的失败"。从0到1的项目本身就有很高失败概率，如果制度不能容忍合理失败，就不会有人愿意去探索。

另外，激励不一定是钱。我在一些公司看到很有效的做法是：项目负责人经历被记入个人成长档案，作为晋升评审的重要参考；重大项目的负责人有更高的权限授信。这些非现金激励，在很多时候比奖金更能筛选出真正想做事的人。

4. 工具投入：先验证制度，再考虑系统

这一条可能会有人不同意。我认为如果一个组织的项目负责人制度还没跑通，就急着上一套系统，最后的结果通常是"用系统记录了混乱"。

正确的顺序是：制度设计 → 试点验证 → 流程固化 → 系统选型 → 数据迁移 → 全面推广。

在系统选型时，中大型企业需要额外考虑几点：是否支持私有化部署（关系到数据合规与行业监管要求）、是否有成熟的迁移方案（关系到切换成本）、是否能把制度规则配置成硬约束（关系到制度是否真的被遵守）。像 PingCode 这类面向中大型组织、支持私有化部署与 Jira 平滑迁移的平台，在国产化替代和制度落地这两件事上是可以放在同一张评估表里的。但最终选择仍然要回到你自己的组织实际：团队的技术接受度、IT运维能力、行业合规要求，这些比功能清单更决定成败。

八、把制度做成组织能力，而不是一次性动作

回到文章开头那家工业自动化设备公司。我们后来做的事其实很简单：重新定义了项目目标，把交付物拆到可验收的粒度；确定了负责人的四档授权；把风险升级的路径写进系统并设了响应时限；把协同响应纳入部门考核。三任负责人的问题，在第四任身上没有重演。项目最终晚了六周交付，比原计划延期半年已经好了太多。

我想强调的独特观点是：项目负责人制度的成败，衡量标准不是"制度是否完整"，而是"坏消息能否被快速说出来"。

如果在一个组织里，项目负责人发现风险后第一反应是"先自己扛一扛、再看看"，说明制度失败了。如果他的第一反应是"立刻登记、按路径升级、找发起人要决策"，说明制度成功了。前者取决于人的勇气，后者取决于制度的确定性。

另一个判断标准是：一个好的项目负责人制度，应该让普通能力的人也能做出合格结果。如果一套制度只有明星员工才能跑通，那它本质上还是人治。这也是为什么我一直强调授权矩阵、升级路径、协同考核这三件事，它们的作用是把对个人的依赖，转化为对机制的依赖。

如果你看完这篇准备动手，我的建议是：不要从写制度文档开始，从选一个试点项目开始。找你的发起人，用一小时写出一页纸章程，用一小时确定授权矩阵，然后把这个项目完整跑一遍。三个月后你会得到一份真正属于你们公司的制度，不是抄来的，是从实践里长出来的。

制度设计的最后一步，永远是从一个具体项目开始的。