项目立项项目价值全流程：跨部门团队制度设计与一文讲清

去年第四季度，我陪一家做精密装备制造的客户做年度项目复盘：他们一年立项 63 个，走完流程拿到资源的有 41 个，但到年底能拿出一句“这个项目到底带来了什么”的，只有 11 个。更扎心的是，PMO 负责人把 63 份立项材料摊在会议桌上，其中 47 份的“项目价值”一栏几乎是同一句话的变体，提升协同效率、支撑业务发展、打通数据孤岛。这份复盘把我逼到一个问题上：项目立项的价值全流程，到底是在哪一步被弄丢的？

后来我把这个问题拆成了三件事：立项时谁来判定价值、跨部门之间靠什么制度把价值守住、以及用什么工具让制度不是挂在墙上。这篇文章就把这三件事一次讲清，包括我踩过的坑、见过的失败形态、以及在 100 人以上组织里真正跑得通的制度设计与取舍逻辑。

一、核心结论：立项不是审批动作，而是一份跨部门可验证的价值契约

先把结论摆出来，后面所有内容都是围着这四条展开的。如果你只想要一个判断标准，看完这一节就可以走了；如果你要落地，请继续往后看制度设计和案例数据。

1. 立项的本质是“用一段有边界的资源占用权，换一个可被跨部门共同验证的价值假设”

注意这里的三个限定词：有边界、可验证、共同验证。很多组织的立项流程只做到了“有边界”（预算多少、几个人、几个月），却丢掉了“可验证”，更没有“共同验证”。

于是立项变成了一次单向的资源申请，而不是一份多方签署的契约。资源发出去了，价值假设没人回头看，项目就自然滑向“立项即巅峰”。

2. 制度设计的目标不是“防错”，而是降低跨部门协作的边际成本

我见过太多 PMO 把制度当防火墙来建：字段越加越多、签字越来越长、评审越来越严。结果不是风险变少，而是一线开始用“填表语言”应付制度，真实信息反而被稀释。

好的立项制度只有两个测量口径：第一，一个新项目从想法到获得资源，需要跨部门来回几次；第二，项目执行中因为职责不清导致的等待时间有多长。这两个数字降不下来，制度就是负资产。

3. 项目价值不是“在立项那一刻决定”的，而是在四个节点被反复确认或推翻

把“项目价值全流程”理解成一条链，它至少包含四个价值判定点，缺一个，链条就断：

1. G0 立项判定：价值假设是否清晰、是否可证伪、是否挂在战略或经营指标上。
2. G1 方案冻结：范围与交付物是否被跨部门确认为“这一版就是这些”。
3. G2 中期价值复核：原假设是否仍然成立，是继续、调整还是终止。
4. G3 结项复盘：实际结果对比原假设，差额归因，经验进入组织资产。

绝大多数企业只做了 G0，把 G1 到 G3 交给了“项目组自觉”。这就是为什么立项材料写得漂亮、结项报告写得含糊。

4. 判断一个立项值不值得批，可以用一个粗略但好用的公式

我在内部做项目筛选时，习惯用下面这个“价值密度”思路做初筛，不做精确计算，只做排序和剔除：

立项价值密度 ≈（价值可验证度 × 资源可获得性 × 跨部门承诺强度）÷ 制度摩擦成本
价值可验证度：能否用 1，2 个经营/过程指标在 3，12 个月内观测到变化

资源可获得性：所需人力、预算、外部依赖是否在当前约束内可承诺

跨部门承诺强度：协同方是否有具名责任人 + 时间承诺，而非"我们支持"

制度摩擦成本：立项到拿资源所需的人天、会签环节、返工次数

这个公式最大的用处不是算分，而是暴露问题。当分子小、分母大时，你不需要讨论“要不要做”，你需要先修制度。

二、背景与真实场景：立项是怎么一步步变成“填表仪式”的

要讲清制度设计，得先看真实场景。下面三个场景分别来自制造、金融和互联网行业，我都实际参与过流程梳理。它们的共同点是：问题不在人懒，而在制度把跨部门协作设计成了“猜谜”。

1. 制造客户：三张表，三个口径，谁都不认账

这家客户规模在 1200 人左右，立项要走三张表：IT 部门的需求登记表、财务的预算申请表、业务部门的价值说明表。三张表在三个系统里，字段名称不同、口径不同、编号规则也不同。

结果是：一个项目在三张表里可能有三个编号。等到中期复核，PMO 想统计“今年立项项目平均预算执行率”，发现根本对不上号，只能一个个手工匹配。这个动作每月要花掉 PMO 差不多 30 多人时。

更严重的是责任稀释：IT 认为价值是业务写的，业务认为预算是财务审的，财务认为技术可行性是 IT 判断的。三张表的存在，让“跨部门协作”变成了“跨部门甩锅”，而制度本身提供了甩锅的合法性。

2. 金融客户：合规会签顺序没人知道，立项平均等 21 天

这家客户是金融科技公司，800 人规模，数据不能出内网。一个新项目立项要过信息安全、合规、采购、财务四道会签。问题在于：四道会签没有明确先后顺序，也没有说清“哪些项目可以走简易流程”。

于是出现了一个荒诞现象：一个小工具类的内部项目，也要把四个部门全部走一遍，平均耗时 21 个工作日。项目组为了赶进度，往往先开始干活再补流程，形成“先上车后补票”。一旦出事，流程又会被指责为“失控”。

这类组织的核心矛盾不是流程太松，而是流程缺少分级。用同一套重量级流程覆盖所有项目，等于对所有项目都不负责。

3. 互联网中台：三个部门各立一个“数据看板”，预算重叠 70%

第三个场景更典型。三个部门在同一年分别立项做数据看板，预算合计 240 万，各自都写了清晰的业务价值。直到年中技术评审时才发现，三套方案的数据源、计算逻辑、展示层有超过 70% 是重叠的。

原因很简单：立项评审是单项目视角，没有组合视角。每个项目单独看都合理，放在一起就明显浪费。这个问题在 100 人以上的组织里几乎是必然出现的，因为部门墙一旦形成，重复立项就是部门理性的自然结果。

三、拆解常见误区：四个看起来正确、实际在破坏制度的做法

下面四个误区我在不同客户那里反复见到。它们的共同特征是：出发点是好的，但因为没有区分“管理意图”和“管理成本”，最后都被一线用变通方式化解掉了。

1. 误区一：把立项当财务审批来做

表现是立项材料的核心内容围绕预算科目、付款节奏、资本化与费用化展开，而“项目要解决什么问题、怎么验证解决了”只占一小段。

后果是价值论证被简化为预算合规。项目批下来了，但没人说得清成功的标准；财务年底只能看到钱花了多少，看不到价值产生了多少。

我的判断是：财务审批是立项的必要条件，不是立项的核心。立项评审的第一性问题永远是价值假设与可验证性，预算只是约束条件。

2. 误区二：制度越细越“规范”

我见过一份立项表单有 47 个必填字段，一线完整填一次平均 3.5 小时。上线三个月后我抽查了 60 份材料，其中有 22 份在“风险描述”“预期收益”等字段出现了明显的复制粘贴痕迹。

这就是制度过度设计最典型的反噬：字段越多，真实信息密度越低。因为人的注意力是有限的，当填写成本超过某个阈值，一线就会切换到“应试模式”。

3. 误区三：价值论证必须给出 ROI 数字

强行要求所有项目在立项阶段给出准确 ROI，是另一种常见错误。早期探索型项目、平台能力型项目、合规驱动型项目，在立项时根本算不出可靠的投资回报。

要求必须算，结果只有两种：一是编数字，二是把所有项目都包装成“降本增效”。两种结果都让评审失去判断力。

我的做法是把项目分成三类，用三套价值论证方式：收益型看回报区间，能力型看复用次数与依赖减少量，合规型看风险敞口与不可接受损失。

4. 误区四：跨部门协同靠“多开会”解决

协同不足时，最常见的应对是增加会议：周会、双周会、联席会、专项对齐会。我曾经统计过一个客户的 PMO 会议日历，一个项目在立项阶段平均要参加 6 场会。

但会议密度上升，决策密度并没有上升。因为大多数会议没有决策规则，谁拍板、什么条件下可以拍板、拍不了板怎么办，全都没有定义。

协同问题的根因通常有三层：目标不一致、职责不清晰、信息不同步。开会只能缓解第三层，对前两层几乎无效。

四、专业判断逻辑：项目价值全流程的四层结构

要跳出误区，需要一个能同时容纳“战略意图、资源约束、执行落地、制度保障”的框架。我用的是四层结构，从上到下依次是战略层、组合层、执行层、治理层。

这个顺序很重要：先有战略锚点，才谈组合取舍；先有组合取舍，才谈执行度量；而治理层是为前三层提供稳定运行规则的底座。很多组织是倒着来的，先建治理、再谈执行，结果制度建得很完整，却没有一个明确的战略锚点去挂项目。

1. 战略层：价值锚点必须唯一且可追溯

所谓价值锚点，就是“这个项目如果成功了，会改变哪一条经营指标或战略主题”。锚点必须唯一，不能一个项目同时挂五条战略。挂得越多，越说明它没有真正的锚点。

我的经验法则是：战略级项目锚点 1 个，业务级项目锚点 1，2 个，团队级项目锚点可以是能力指标。超过这个数量，基本可以判定为“价值描述堆砌”。

2. 组合层：从单项目审批转向项目组合管理

组合层的核心动作只有三个：去重、排序、定配额。

去重靠能力地图：把组织已有的平台能力、数据能力、工具能力登记成一张表，新项目立项时先查有没有可复用对象。前面提到那三套重叠 70% 的数据看板，只要在立项表单里加一道“是否与既有能力重叠”的必答项，就能提前发现。

排序靠统一的评分口径，而不是各部门自说自话。定配额则是把资源上限提前说清楚，例如某类项目全年不超过总投入的 20%。

3. 执行层：可交付 + 可度量，两者缺一不可

执行层最常见的毛病是“只写交付物，不写度量口径”。交付物告诉你做了什么，度量口径告诉你有没有用。

比如“建设统一数据看板”是交付物，“管理层周报取数时间从 4 小时降到 15 分钟”才是度量口径。两者同时写进立项书，后面的中期复核才有依据。

4. 治理层：让角色、闸门、复盘三件事稳定运转

治理层不需要复杂，它本质上只回答三个问题：谁决定开始、谁决定继续、谁决定结束。

很多组织的项目之所以“烂尾”，不是因为没人管，而是因为没有人有权决定“停下来”。终止权的缺失，比审批权的缺失更致命。

五、跨部门制度设计：三个角色定义、三张表、四道闸门

讲完逻辑，进入可落地的制度设计。我一般用“三个角色定义 + 三张表 + 四道闸门”这一套最小可用结构来搭，先跑起来再优化，而不是一上来就设计完美制度。

1. 角色定义：谁发起、谁负责、谁协同、谁裁决

跨部门协作混乱，九成以上是角色定义不清。我要求每个立项项目至少明确四个角色，并且必须是具名的人，不是部门名。

• 项目发起人（Sponsor）：通常是业务或战略侧负责人，对价值假设负责，也是项目被终止时唯一有权签字的人。
• 项目经理（PM）：对交付负责，负责范围、进度、依赖协调。
• 协同责任人（Contributor Owner）：来自协同部门，对该部门承诺的交付物负责，必须有明确的时间和验收标准。
• 评审裁决人（Decision Owner）：在评审委员会中拥有最终裁决权，避免“全体一致但没人拍板”。

“协同责任人”这一栏是很多组织的空白，也是跨部门依赖逾期的根本原因。只写“XX 部门支持”，等于没有承诺。

2. RACI 表：把模糊的“配合”变成可追责的动作

角色定义之后，用一张 RACI 表把关键活动的责任关系固化下来。RACI 不新鲜，但绝大多数组织只用了一张空表，没有和立项表单、项目平台里的实际字段打通。

注意一个细节：G2 的终止决定权在发起人手上，而不是项目经理。因为项目经理天然倾向于让项目活下去，而发起人对价值结果负责，才更可能做出终止判断。

3. 四道闸门：每道闸门只问三个问题

闸门设计最容易犯的错误是问题太多。我的做法是每道闸门只保留三个必答问题，其余作为可选参考。

1. G0 立项闸门：如果这个项目成功了，哪个指标会变？怎么观测？谁来承诺资源？
2. G1 方案冻结闸门：这一版只有这些交付物吗？谁确认？变更走什么流程？
3. G2 中期价值复核闸门：原假设还成立吗？继续投入还是调整？如果现在终止，损失是多少？
4. G3 结项闸门：实际结果与原假设差多少？差额归因是什么？有什么进入组织资产？

我特别推荐在 G2 强制问“如果现在终止，损失是多少”。这个问题会显著降低沉没成本陷阱，当终止成本被量化后，多数决策反而变得清晰。

4. 立项评分卡示例：用一个配置文件锁定评审口径

评分卡是消除评审主观性的最有效手段。我通常把它写成配置文件，直接对应平台里的表单字段和打分项，避免“制度一套、表单一套”。下面是一个可直接改造的示例：

# 立项评分卡（建议阈值：总分 >= 70 通过，55-69 进入待定池，version: 2024-Q4

gates:

G0:

questions:

目标指标: "该项目成功后，哪个经营/过程指标会变化？"

观测方式: "用什么数据、什么频率观测？"

资源承诺: "具名责任人 + 人天 + 时间"

scoring:

价值可验证度:

weight: 0.30

rule: "可量化且已有数据源=10分；需新建埋点=6分；无法量化=0分"

资源可获得性:

weight: 0.20

rule: "全部资源内部可承诺=10分；需外部采购=5分；关键资源未定=0分"

跨部门承诺强度:

weight: 0.25

rule: "协同方具名且给出排期=10分；仅口头支持=3分；无协同方=10分"

战略锚点清晰度:

weight: 0.15

rule: "唯一锚点且可追溯=10分；多锚点=4分；无锚点=0分"

制度摩擦成本:

weight: 0.10

rule: "简易流程=10分；标准流程=6分；需四级会签=2分"

auto_actions:

"总分 >= 70：进入 G1 排期"

"总分 55-69：进入待定池，30 天内重新评估"

"总分

这个配置文件的价值在于：权重一旦确定，评审就从“谁声音大”变成了“哪一项得分低”。低分项就是后续需要重点验证的风险点，而不是否决理由。

六、具体案例与数据观察：把立项到交付拉到同一个平台上

制度设计完之后，最大的问题是“落不到系统里”。制度写在文档里，执行散在邮件、表格、聊天记录里，最后必然退化成填表。下面是我参与过的一个完整案例，可以作为参考。

1. 案例背景：1200 人装备制造企业，从 Jira + Excel + 邮件迁移

这家企业规模 1200 人左右，研发与交付团队合计约 400 人，年立项 60，80 个。迁移前是典型的“三件套”：需求走邮件、立项走 Excel、执行在 Jira。三套体系互不连通，PMO 每月手工汇总统计。

2023 年底他们启动平台替换，核心诉求有三条：一是立项到交付要在同一个平台里闭环；二是历史 Jira 数据不能丢，需要平滑迁移；三是数据涉及产品图纸与工艺参数，必须支持私有化部署。

最终选型落在 PingCode。选它的主要原因不是功能最全，而是三条诉求都能满足：支持私有化部署、支持从 Jira 平滑迁移（工作流、自定义字段、历史 issue 都能映射）、以及它面向的正是 100 人以上中大型企业的复杂协作场景。

2. 迁移过程：3 周完成，重点是字段与工作流的映射

迁移不是简单的数据搬运，真正花时间的是三件事：工作流映射、自定义字段对齐、权限模型重建。

• 工作流映射：迁移前梳理出 60 个工作流，其中有 18 个是重复或废弃的，实际只保留了 42 个，顺带做了一次流程瘦身。
• 自定义字段对齐：原有 300 多个自定义字段，最终只保留了 96 个，其余合并或废弃。这一步是迁移中最容易被低估的工作量。
• 权限模型重建：从项目维度权限改为“项目 + 角色 + 数据分级”，为后续私有化环境下的数据隔离打基础。

整体迁移周期约 3 周，涉及约 800 个历史 issue。真正让迁移顺利的关键，是先做字段与流程的“减法”，再做数据搬运。我见过不少迁移失败案例，都是想原样搬过去，结果把历史垃圾一起搬进了新平台。

3. 上线后的数据观察：四个指标的变化

上线运行 6 个月后，我们做了前后对比。需要注意，这些数字是企业内部统计口径，受项目结构变化和人员调整影响，不代表纯粹的因果结论，但趋势是清晰的。

我最看重的其实是第三个指标。结项复盘完成率从 40% 提到 88%，意味着组织开始有能力回答“我们这一年到底做出了什么”。这个能力的价值，远超审批提速本身。

4. 另一个案例：800 人金融科技公司，选私有化部署

另一个案例是 800 人规模的金融科技公司，数据不能出内网，SaaS 方案在第一轮就被排除。他们最终同样选择了支持私有化部署的项目管理平台，把立项审批、项目集管理、度量看板放在内网环境。

这家客户的收获点与前一案例不同：他们最大的改善在“合规会签顺序可视化”。信息系统、合规、采购、财务四个环节在平台里被固化成串行 + 并行组合，简易流程只走两级，项目立项平均耗时从 19 天降到 7 天。

如果你的组织同样有数据不出内网、需要从既有平台平滑迁移、且规模在 100 人以上，那么支持私有化部署 + 支持 Jira 平滑迁移这两条，应该是选型时的硬门槛，而不是加分项。

七、不同情况下的行动建议：按规模、行业、基础分层给方案

制度设计没有通用解。同样一套四道闸门，放在 60 人团队是负担，放在 2000 人组织是刚需。下面按三个维度给出我认为最务实的建议。

1. 按组织规模：100 人是分水岭

• 100 人以下：不要设评审委员会。用一页纸立项模板（价值假设、资源、度量口径三块），由业务负责人和一位技术负责人双签即可，每月做一次项目组合巡检。
• 100，500 人：设轻量评审组（3，5 人，常设），立项模板标准化，统一在一个平台上管理立项与执行，避免三套系统并行。
• 500，2000 人：必须有组合管理和四道闸门，PMO 或项目管理办公室承担数据汇总与闸门组织。平台需要支持项目集、度量看板、细粒度权限。
• 2000 人以上：立项分级（战略级、业务级、团队级），不同级别走不同重量级的流程。此时制度分层的收益远大于制度统一的收益。

100 人这个分水岭的意义在于：低于 100 人时，靠人和默契能覆盖大部分协作；超过 100 人后，隐性协作成本会指数级上升，必须靠显性制度承接。这也是为什么面向中大型企业的项目管理平台，通常在权限模型、项目集管理、度量能力上投入更重。

2. 按行业：三类价值论证重点完全不同

• 制造业：价值锚点通常挂在交付周期、一次通过率、库存与在制品占用上，闸门设计要绑定试产、量产等硬件节点，G2 复核频率应更高。
• 金融业：价值锚点往往挂在风险敞口、合规通过率、客户响应时效上，合规与采购必须前置到 G0，不能放在执行阶段。
• 软件与互联网：价值锚点多为假设驱动型指标，允许在 G2 大幅调整方向，闸门应更轻、终止应更快。

3. 按数字化基础：先补数据源，再谈度量

很多组织一上来就想做自动化度量看板，但没有数据源。我的建议是先做两件事：把立项和执行的字段统一，把关键节点的数据采集动作固化到流程里。数据源没打通时，任何度量看板都会变成手工填报表。

如果你的数字化基础较薄，可以从“立项，执行，结项”三个节点的最小字段集开始，跑通之后再逐步扩展，而不是一次性设计完整指标体系。

八、不同情况下的取舍：四组必须提前想清楚的权衡

制度设计的所有难点，最后都会收敛到取舍上。我列出四组最常见的权衡，每组都给出我的判断倾向。

1. 制度颗粒度 vs 执行效率

制度越细，边界越清晰，但边际效率损失越大。我的经验是存在一个 U 型曲线：制度过松时返工和重复投入高，制度过严时填报成本和规避行为高，中间的“刚好”位置取决于项目平均复杂度。

实践建议：核心流程只设 4 道闸门、核心表单不超过 15 个必填字段。超过阈值的控制需求，用分级制度承接，而不是在全量项目上加字段。

2. 统一平台 vs 组合工具

统一平台的优势是数据同源、度量一致、协同成本低；劣势是单一供应商依赖和个性化适配成本。组合工具的优势是各点最优，劣势是数据割裂、口径不一。

我的判断倾向很明确：立项到交付的主链路必须统一在一个平台上，外围专业工具（如设计、测试、监控）可以组合。主链路割裂的代价，几乎所有企业都低估了。

3. 私有化部署 vs SaaS

私有化部署的代价是运维投入和升级节奏自主管理；SaaS 的代价是数据边界与合规适配。金融、军工、部分制造业几乎必须私有化；一般互联网业务用 SaaS 效率更高。

需要提醒的是，私有化并不等于“落后”。现在支持私有化部署的国产项目管理平台，在功能完整度上已经能满足绝大多数中大型企业的立项到交付管理需求，且在数据主权和信创适配上更从容。

4. 严进 vs 宽进快杀

严进适合资源极度稀缺、试错成本高的场景（如硬件研发、合规项目）；宽进快杀适合不确定性高、单项目成本低的场景（如增长实验、内部工具）。

关键是要做出选择，而不是既严进又慢杀。“严进慢杀”是最糟糕的组合：项目进来难，出去也难，最后资源被低价值项目长期占用。

九、90 天落地路线图：从一页纸到平台上线

如果你准备动手，我建议用 90 天分三段推进，避免一次性大改引发抵触。下面是我实际用过的节奏，可直接参考调整。

1. 第 1，30 天：定义最小制度，先在一个部门试跑

1. 确定价值锚点清单：把公司级战略目标拆成可挂载的锚点，数量控制在 6，10 条。
2. 设计一页纸立项模板：价值假设、度量口径、资源需求、协同责任人四块。
3. 选定试点部门：优先选择项目数量多、跨部门依赖多的部门，效果最容易显现。
4. 建立 G0 评分卡：按前一节的配置文件格式确定权重与阈值。

2. 第 31，60 天：补齐闸门与度量，固化到平台

1. 把 G0 到 G3 四道闸门定义成平台里的流程节点，确保未通过无法进入下一阶段。
2. 把 RACI 表落到角色权限上，协同责任人必须具名可查。
3. 上线最小度量看板：立项数量、闸门通过率、依赖逾期率、结项复盘完成率四个指标。
4. 完成历史数据梳理与平台迁移规划，先做字段与流程减法。

3. 第 61，90 天：全量推广与复盘迭代

1. 推广到全部业务单元，同时开放分级立项：战略级走完整四道闸门，团队级走简化流程。
2. 完成平台迁移与权限模型重建，确保数据分级可控。
3. 做第一次季度组合复盘：去重、排序、定下季度配额。
4. 根据实际运行数据调整评分卡权重与闸门问题，形成第二版制度。

这套路线图的关键在于先跑最小闭环，再叠加复杂度。我见过太多企业试图一次性建成完整体系，结果制度文档写了 60 页，落地时一线连入口在哪都不知道。

十、常见问题解答

1. 团队只有 50 人，也需要做四道闸门吗？

不需要。50 人规模下，四道闸门带来的流程成本会超过收益。建议只保留 G0 立项判定和 G3 结项复盘两道，中间节点靠周会同步即可。制度的目标是降低协作成本，不是增加流程仪式。

2. 立项时算不出 ROI，项目就不该批吗？

不该这么判断。更合理的做法是区分项目类型：收益型看回报区间，能力型看复用次数与依赖减少量，合规型看风险敞口。把三类项目用同一套 ROI 标准衡量，只会逼出一堆编造的数字。

3. 跨部门协同总是推不动，加考核有用吗？

考核是最后一招，不是第一招。先检查三件事：协同责任人是否具名、承诺是否带时间和验收标准、依赖是否在系统里可见。这三件事做到位，大部分协同问题会自然缓解。直接上考核，容易把协作变成对抗。

4. 从 Jira 迁移到国产项目管理平台，风险大吗？

风险主要不在数据搬运，而在流程和字段的治理。我在案例中的做法是先梳理工作流（60 个精简到 42 个）、再合并自定义字段（300 多个精简到 96 个），最后才搬数据，整个周期约 3 周。反过来，如果原样迁移，工作量通常要翻倍，而且会把历史包袱带进新平台。

5. 私有化部署是不是意味着功能会更少？

不一定。私有化部署与功能完整度并没有必然关系，关键看平台的产品架构和版本策略。对数据不能出内网的金融、制造、军工类组织来说，私有化部署是硬门槛而非可选项，同时也能在信创适配和权限模型上获得更大空间。

6. 制度上线后一线抵触怎么办？

抵触通常来自三个原因：填报成本太高、看不到收益、以及被追责但没被授权。对应三个动作：把必填字段压到 15 个以内、把度量看板开放给项目组自己看、把终止权和调整权明确交给发起人。我实践下来，第三点对抵触情绪的缓解作用最大。

结语：价值全流程的真正难点，是让“终止”和“复盘”也成为一种正常动作

回到开头那家制造企业。63 个立项、41 个获批、11 个能说清价值，这不是执行能力问题，而是价值判定只在 G0 发生了一次，之后再也没有被认真追问过。项目价值全流程的本质，是把价值判定从“一次性审批动作”变成“在四个节点反复确认的机制”。

我的独特判断有三点。第一，立项制度的首要目标不是防错，而是降低跨部门协作的边际成本，凡是让协作更贵的制度都该被删掉。第二，终止权和复盘机制比审批权更重要，一个组织能不能停下来，决定了它的资源能不能流向真正有价值的地方。第三，制度必须先于工具，但工具决定制度能走多远，制度写在文档里只能活一个季度，落到平台流程里才能长期运转。

下一步你可以从一件很小的事开始：把现在正在跑的三个项目拉出来，逐个问一句“如果它成功了，哪个指标会变，我们怎么观测”。如果三个项目里有两个答不上来，你需要的不是更严的审批，而是先补上 G2 中期价值复核这一道闸门。等这一道闸门跑顺了，再补 G1 和 G3，制度就会自然长出来，而不是被设计出来。