立项流程与规范：PMO项目立项制度设计关键指标

去年秋天，我陪一家 400 人规模的制造企业做 PMO 年度复盘。他们的《项目立项管理办法》写得非常漂亮：三级评审、五类附件、七项打分、九宫格立项分类。但当我拉出过去 12 个月的立项台账时，看到的却是另一幅图景，立项会一共开了 43 次，平均立项周期 21.5 个工作日，最终立项通过率 94%；而半年后回看，其中 61% 的项目拿不出可验证的收益基线，28% 的项目在启动 60 天内就发生了范围重定义，还有 7 个项目从提出到被静默中止，全程没有一次正式的终止决议。

这份制度没有失败，它只是把力气用错了地方：它把全部注意力放在”批不批”这个动作上，却几乎没有设计”用什么价格买入不确定性”这件事。这篇文章里，我想把过去几年在十几家企业做立项制度设计时反复验证过的判断讲清楚：PMO 立项制度的核心产出不是审批记录，而是一套可比较、可追溯、可复盘的立项指标。

一、先给结论：立项制度要管的不是”批不批”，而是”用什么价格买入不确定性”

大部分 PMO 在立项制度上的第一反应是”加强管控”：加评审层级、加附件清单、加打分表。但立项的本质从来不是管控动作，而是一次投资决策。既然后果是”投资”，那么真正决定制度成败的就不是审批环节的数量，而是审批所依赖的信息质量，以及审批结论的可回溯程度。

1. 立项通过率是最差的 KPI，没有之一

我在至少 8 家企业的 PMO 考核表里看到过”立项通过率”这一项，而且普遍被设定为越高越好的正向指标。这是完全反逻辑的：立项通过率高，意味着评审环节几乎没有筛除功能，那这个环节就是纯成本。真正有筛除能力的立项制度，通过率通常落在 55%-75% 这个区间。

换个角度想：如果一家公司的立项通过率长期高于 90%，只有两种解释，要么提案质量高得离谱，要么评审只是在走过场。而在我见过的所有样本里，第二种占了绝大多数。

2. 真正该被考核的是三个数

如果要给 PMO 负责人一张只有三行的考核表，我会这么写：

• 立项周期中位数：从提案提交到决策结论生成的实际工作日，不含申请人等待补充材料的时间。健康区间因规模而异，100-500 人组织通常在 5-10 个工作日。
• 立项估算偏差率：项目结项时的实际工期/成本 ÷ 立项时承诺值 − 1。这个数比通过率有价值得多，因为它直接反映立项信息质量。
• 立项后 90 天范围变更率：启动后 90 天内发生需求基线变更的项目占比。这个指标是”立项文档质量”最诚实的照妖镜。

3. 制度的成本结构：审批成本 vs 错配成本

设计立项制度，本质上是在两类成本之间找平衡点。一类是审批成本，每个项目立项都要消耗评审人时、申请人准备时、会议时间；另一类是错配成本，立项决策失误导致的人力、预算、战略机会损失。

审批成本随审批强度线性甚至超线上升，而错配成本随审批强度边际递减。当审批强度超过某个临界点后，继续加码带来的错配成本下降，已经抵不过审批成本上升。这个临界点，就是你的立项制度应该停下的地方。很多 PMO 的问题不是制度不够严，而是从来没有算过这条曲线的右半边。

二、背景与真实场景：为什么大多数 PMO 的立项制度会失效

我见过太多”制度写得比执行好”的 PMO。失效的原因往往不在制度文本本身，而在制度与组织真实运行方式之间的落差。下面四种场景，是我在过去几年里重复遇到频率最高的。

1. 场景一：从”完全没制度”到”制度过载”的钟摆效应

大多数企业立项制度的诞生，都源于一次事故：某个项目烧掉两百万后无声无息地死了，老板拍桌子说”以后所有项目都要立项”。于是 PMO 在一两个月内赶出一份覆盖所有类型的立项流程，要求全员执行。

结果通常是这样：前三个月执行得很热闹，第四个月开始有团队抱怨”填立项书比做需求还累”，第六个月开始出现”先干后立项”，第九个月制度事实上失效，只留下一个没人维护的模板和一堆格式完整但数据空洞的立项文档。

这个钟摆的根源是：制度设计时用”最坏情况”设定门槛，执行时却要面对”平均情况”的日常项目。

2. 场景二：立项书沦为八股文，字数达标但信息为零

我随机抽过一家 600 人企业的 30 份立项书，统计每个字段的”有效信息密度”。所谓有效信息，是指这个字段的填写内容能否被后续用于决策或复盘。结果很不乐观：

这张表里最刺眼的是最后一行。只有 9% 的立项书写了可以被执行的终止条件。这意味着 91% 的项目一旦启动，就只能靠人的主观判断来叫停，而组织里几乎没有人有动力主动叫停自己批过的项目。

3. 场景三：审批层级与组织规模、风险等级错配

我见过一家 150 人的公司设了四级立项审批，也见过一家 3000 人的集团对 50 万元以下项目完全免审。两种做法都可能出错，但错法不同：前者用大企业流程压垮小组织的决策速度，后者用创业公司的松散度管理集团级的资源盘子。

更隐蔽的问题在于，很多公司的审批层级是按”金额”单维度设定的。但金额只是风险的一个维度，战略关联度、技术不确定性、跨部门依赖数量，往往比金额更能预测项目失败概率。一个 20 万元但横跨 5 个部门、依赖未验证技术的项目，风险远高于一个 200 万元的单部门标准化替换项目。

4. 场景四：工具只做流转，不做数据沉淀

这是我见过最普遍、也最容易被忽视的问题。很多企业的立项流程确实搬到线上了，但工具里沉淀下来的只有”谁在什么时候点了同意”。至于这份立项书里承诺的工期、成本、收益基线，没有任何结构化的字段去承载，更谈不上和后续执行数据做比对。

结果是：立项是立项，执行是执行，复盘是复盘，三者之间没有数据链路。PMO 每年都在做立项，但从来没有积累出”我们公司的立项估算平均偏差是多少”这个数。这等于把最宝贵的管理资产，历史估算数据，年复一年地扔掉了。

三、拆解六个常见误区

下面这六个误区，我在不同企业反复见到，而且它们往往同时存在。每个误区我都会给出判断依据，而不是泛泛而谈。

1. 误区一：把立项通过率当作正向 KPI

前面已经说过，这里补充一个具体观察。我统计过三家企业的立项数据，通过率分别是 96%、89%、71%。表面上看第三家”卡得最严”，但进一步看立项后 90 天范围变更率，分别是 38%、31%、16%。

通过率和变更率之间存在明显负相关，这说明评审环节确实在起筛选作用，但前提是评审标准是”证据强度”而不是”格式完整度”。那些通过率极高却变更率也很高的组织，说明评审只是确认了文档存在，没有验证文档内容。

2. 误区二：对所有项目用同一套立项门槛

一个 3 人月的内部小工具改造，和一个跨 6 个部门的系统替换，走完全相同的立项流程，这是最常见的资源浪费。更糟的是，当小项目也要填 20 页立项书时，团队会发展出”批量应付”的策略，复制粘贴、套模板，反而污染了整个立项数据池。

分级的正确做法不是简单按金额切，而是按“决策不可逆程度”切。可逆性差、返工成本高的项目，才值得重流程；可逆性强、试错成本低的项目，应该走轻流程甚至先做后补。

3. 误区三：只审”要不要做”，不审”什么时候停”

这是我认为最严重的一个结构性缺陷。绝大多数立项评审的议程是：这个项目有没有价值、需要多少资源、什么时候能上线。几乎没有人问：如果出现什么信号，我们就在什么时候把它停掉。

结果是，项目一旦立项就获得了”默认生存权”。我追踪过一家企业的 47 个立项项目，其中 11 个在中期已经明确偏离目标，但最终只有 2 个被正式终止，其余 9 个都是”慢慢没人提了”，资源被持续消耗直到自然消亡。静默死亡比正式终止的代价更高，因为它同时消耗资源和管理注意力。

4. 误区四：财务口径与技术口径各说各话

财务部门用投资回报率、净现值、回收期；技术部门用人天、迭代数、故事点。立项会上两边各说各的，谁也无法验证对方。最终结果是评审结论里只剩一句”总体可行”。

解法不是统一成一种口径，而是建立双口径映射：技术估算的人天必须挂在一个明确的人力单价上，财务收益必须拆解到可观测的业务指标上，并标注基线值和测量方式。做不到这一点，收益承诺就是不可证伪的。

5. 误区五：立项文档只写目标，不写基线

“预计提升效率 30%”这句话，如果没有说清楚”当前效率是多少、用什么口径测量、由谁在什么时候测量”，那么它在结项时既无法被证实也无法被推翻。这类不可证伪的目标，是立项文档里最昂贵的废话。

我的判断标准很简单：如果一个收益目标无法被第三方用可获取的数据验证，它就不应该出现在立项书里。宁可不写，也不要写不可验证的数，因为后者会训练整个组织接受”目标本来就可以模糊”这个前提。

6. 误区六：工具只当流程引擎，不当数据底座

这是最容易被低估的误区。立项制度的效果，很大程度上取决于工具能否把”立项时的承诺”和”执行中的实际”放在同一个数据模型里。如果立项在 OA 里走流程、项目在执行工具里跑、工时在另一套系统里统计、收益在财务系统里核算，那么从技术上就不可能计算出估算偏差率。

四、专业判断逻辑：立项制度的四个设计轴

讲完误区，说建设性的部分。我设计或改造立项制度时，通常把它拆成四个互相独立的轴。每个轴都有自己的取值区间，组合起来就形成了适合某个组织的制度形态。

1. 轴一：分级授权轴，决定谁有权批

分级授权不要只看金额。我一般用三个维度做组合判断：项目金额区间、跨部门依赖数量、技术或业务不确定性等级。三个维度各自分档，组合后映射到审批层级。

下面这段是我在一个客户项目里实际使用过的分级规则，用配置形式表达，可以直接落到支持自定义工作流的项目管理平台里：

立项分级授权规则（示例）
————————————————–

规则名: 立项分级判定

维度:

金额区间:

A: 小于 20 万元

B: 20 万 – 100 万元

C: 100 万 – 500 万元

D: 大于 500 万元

跨部门依赖数:

L1: 1 个部门

L2: 2-3 个部门

L3: 4 个及以上部门

不确定性等级:

U1: 有成熟先例，方案明确

U2: 部分未知，已有技术验证

U3: 关键路径存在未验证假设

审批层级映射:

A + L1 + U1 → 部门负责人单签（免评审会）

A/B + L2 → PMO 负责人 + 业务负责人双签

B/C + L3 或 U3 → 立项评审会（3 人以上）

C/D + L3 + U3 → 立项评审会 + 分管高管审批

D 任意 → 投委会决议

强制附加条件:

凡 U3 项目，立项书必须包含

待验证假设清单及验证计划

明确的终止条件与检查点日期

凡 C/D 项目，立项书必须包含

收益基线的当前值、测量口径、测量责任人

这套规则的价值不在于它多精确，而在于它把”要不要评审”从人的主观判断变成了可追溯的规则判定。当所有人都能提前知道自己要走哪条路时，流程摩擦会大幅下降。

2. 轴二：证据强度轴，决定要交什么材料

我常跟 PMO 同事说一句话：立项材料的多少，不应该由项目金额决定，而应该由”估算所依赖的证据等级”决定。同样是 200 万元的项目，如果有成熟先例和完整历史数据支撑，材料可以很薄；如果是全新领域，就算只有 50 万元，也应该要求更严谨的证据。

证据强度大致分四级：

1. T 恤尺码估算：只知道大概是小、中、大。适用于可逆性极强的探索性项目，允许走轻流程，但必须注明”估算精度 ±100%”。这类项目的立项目的不是锁定资源，而是获得一个探索窗口。
2. 类比估算：参考过 1-3 个相似项目的历史数据。精度约 ±50%。需要提供类比对象名称和差异说明。
3. 参数估算：有明确的规模参数和单位成本率。精度约 ±25%。需要提供参数来源和计算过程。
4. 三点估算：乐观、最可能、悲观三值加权。精度约 ±15%。适用于关键路径清晰、有历史分布数据的项目。

我的经验是，把估算方法和精度区间强制写进立项书，比要求估算”更准”有效得多。因为它把”我不确定”变成了一件被允许甚至被鼓励的事，团队不再需要用虚假的精确度来换取审批通过。

3. 轴三：时间窗轴，决定什么时候可以立项

常见两种极端：一种是随时可立项，导致资源被零散提案持续侵蚀，无法做整体资源规划；另一种是每年只有一次立项窗口，导致业务机会错过、团队在下半年无事可做。

我推荐的组合是双轨制：战略级预算池按季度集中立项，确保资源与战略节奏对齐；运营级和改进型项目保持月度或双周滚动窗口，保证响应速度。关键是两条轨道用不同的审批层级和材料要求，不能混用。

4. 轴四：终止条件轴，决定什么时候退出

这是被最少讨论、但价值最高的一条轴。我的做法是要求每个立项项目在立项时就写清三件事：检查点日期、判定指标、判定后的动作。判定后的动作必须包含”终止”这个选项，并且明确终止由谁发起、由谁批准。

有一个反直觉的实践效果：当终止条件被提前写清楚后，项目被终止的心理成本大幅降低。因为终止不再意味着”当初批错了”，而只是”触发了一个预先约定的规则”。这一点对组织心理的影响，比流程本身更大。

五、可量化的关键指标体系：立项制度到底该埋哪些数

前面讲的是设计逻辑，这一节讲具体的指标。我把立项相关指标分成四组：效率类、质量类、治理类、收益类。每一组我都会给出定义、计算口径、健康区间和采集方式。

1. 效率类指标：衡量制度本身有多重

• 立项周期中位数：提案提交时间 → 决策结论生成时间，单位为工作日。建议同时统计 P50 和 P90，因为 P90 才反映流程卡点。
• 评审等待时长占比：周期中”等待排期”的时间 ÷ 总周期。这个比例超过 60% 说明瓶颈在会议排期，而不是信息准备。
• 材料返工次数：立项书被退回补充的平均次数。健康值 ≤ 1 次，超过 2 次说明模板或指引有严重问题。

2. 质量类指标：衡量立项信息本身有多准

• 立项估算偏差率：（实际值 − 立项承诺值）÷ 立项承诺值。建议按项目类型分层统计，不要看总数，因为不同项目类型的偏差规律差异极大。
• 估算偏差方向分布：高估与低估的比例。如果系统性低估超过 70%，说明组织存在”为了通过而压缩工期”的激励扭曲。
• 立项后 90 天范围变更率：这个指标比任何文档检查都更能反映立项质量。

3. 治理类指标：衡量制度有没有真的在做筛选

• 立项否决率与撤回率：否决是指评审结论为不通过；撤回是指提案人在评审前主动撤回。两者相加应落在合理区间，长期低于 15% 说明筛选功能失效。
• 分级授权规则覆盖率：走免评审会或轻流程的项目占比。健康值视组织规模而定，通常在 40%-70%。
• 终止条件填写合规率：立项书中包含可执行终止条件的比例。这个指标应该被设为硬性门槛，低于 90% 直接视为制度执行失败。

4. 收益类指标：衡量立项承诺有没有被兑现

• 收益基线复核率：项目结项时实际执行了收益基线测量的比例。低于 50% 说明收益论证在组织里不被当真。
• 收益目标达成率分布：不要只看平均值，要看分布。如果大量项目达成率集中在 90%-110%，反而要警惕目标设定被”反向校准”。

六、真实案例与数据观察：一家 320 人企业的立项制度改造

下面这个案例来自我 2023 年参与的一次立项制度改造，客户是一家 320 人的 B 端产品公司，研发人员约 210 人，同时并行 30 多个项目。数据经过脱敏，但比例和趋势保持真实。

1. 改造前的状态

改造前，该公司所有项目走同一套四级审批，平均立项周期 19.4 个工作日，通过率 93%。立项流程在 OA 里走，项目执行在另一套系统里管理，工时在第三套系统里记录。立项书里的工期和成本承诺，没有任何系统化字段去承接。

最直接的后果是：PMO 无法回答”我们的立项估算准不准”这个问题，因为两边的数据从来没有对齐过。他们只能靠项目经理的个人回忆来讨论偏差，而这种讨论最后总会演变成互相指责。

2. 改造的三个动作

我们做了三件事，按优先级排列：

1. 建立分级授权规则，把 68% 的项目移出评审会。金额 20 万元以下且单部门依赖的项目，改为部门负责人单签，材料压缩到一页。这一步直接释放了大量的评审产能。
2. 强制终止条件字段，并把它作为提交校验项。立项书中必须包含至少一个检查点日期、一个判定指标、一个判定后动作。不填不能提交。
3. 把立项、执行、工时、收益指标放到同一个数据底座上。这一点是关键技术动作。他们选择了 PingCode 作为载体，主要原因是需要私有化部署以满足客户对数据驻留的要求，同时希望立项时填写的工期、成本、收益基线能够作为结构化字段，直接与后续的迭代、工时、度量数据关联。

关于第三点我想多说一句。很多企业问我立项工具该怎么选，我的判断标准只有一条：这个工具能不能在同一个数据模型里，让”立项时的承诺”和”执行中的实际”发生关联。如果做不到，那么无论流程配置得多灵活，最终沉淀下来的仍然只是一堆审批记录。PingCode 在这方面的思路是把需求、项目、迭代、工时、度量放在统一的数据结构下，立项表里的承诺值可以直接引用到度量报表，这对于中大型企业持续计算估算偏差率是必要的。

另外，他们当时还有一部分历史项目在 Jira 上，需要平滑迁移，这也是选型时的一个现实约束。

3. 改造后的数据变化

最后一行值得单独说。改造后正式终止的项目增加到了 9 个，这在很多 PMO 眼里是”坏消息”。但我的判断恰恰相反：这 9 个项目里有 6 个原本会以”静默死亡”的方式继续消耗资源 3-8 个月。提前终止释放出来的人力和预算，是这次改造最实在的收益。

七、不同情况下的行动建议

立项制度没有通用最优解，只有与组织规模、业务节奏、监管要求匹配的解。下面按四种典型情况给出行动建议，每一条都尽量具体到可执行的动作。

1. 情况一：50-100 人的组织

这个阶段最忌讳照搬大企业流程。我的建议是把立项制度控制在”一页纸 + 一个决策人”：

• 立项书一页，强制包含四件事：要解决的问题、预期收益及基线、资源需求、终止条件。
• 只设两级：部门负责人 + 一位高管。不设评审会。
• 唯一必须坚持的是终止条件字段，其他都可以简化。
• 每季度做一次估算偏差复盘，哪怕只统计 5 个项目，也要开始积累数据。

2. 情况二：100-500 人的组织

这是最需要精细化设计的区间，也正是分级授权最能发挥作用的规模。建议：

• 建立三维分级规则（金额、跨部门依赖、不确定性），目标是把 50%-70% 的项目移出评审会。
• 立项材料按证据强度分档，而不是按金额分档。
• 把立项承诺值结构化落库，与执行数据打通，从第一批项目开始积累估算偏差数据。
• 开始计算前面表格里的七项指标，但只重点盯其中三项：估算偏差率、90 天范围变更率、终止条件合规率。

3. 情况三：500-2000 人的组织

这个规模的核心矛盾是”资源池化管理”和”业务响应速度”之间的张力。建议：

• 采用双轨立项窗口：战略级按季度集中立项，运营级按月度滚动。
• 建立项目组合层面的资源占用视图，避免各部门独立立项导致关键角色被重复占用。
• 引入阶段门（Stage-Gate）检查点，把立项决策从一次性判断变成多次可调整决策。
• 把立项数据与财务预算系统对接，实现收益基线的半自动核验。

4. 情况四：2000 人以上或集团型组织

这个规模下，立项制度的挑战已经从流程设计变成了治理一致性。建议：

• 总部只定义”分级规则框架 + 必备字段 + 指标口径”，具体流程交给事业部配置。
• 强制统一三项指标的统计口径，否则跨事业部无法比较，集团层面也就无法做资源调配。
• 建立立项质量审计机制，抽样复核立项书的信息有效性，而不只是格式完整度。
• 把终止决策的权限与立项权限分离，避免”自己批的自己不愿停”。

5. 情况五：强监管行业（医疗、金融、航空等）

这类行业的立项制度需要叠加合规证据链。建议：

• 立项书中的风险字段必须关联到具体的法规条款或内控要求，不能只写”存在合规风险”。
• 所有立项决策的输入材料必须版本化留存，满足可追溯性审计要求。
• 终止条件中必须包含合规类触发条件，例如”监管要求变更导致原方案不再合规”。
• 工具选型时把审计留痕能力作为硬性准入条件，而非加分项。

八、不同情况下的取舍

制度设计的本质是取舍，不是求全。这一节我把立项制度里最常见的四组取舍摆出来，并给出我的倾向和适用条件。

1. 取舍一：决策速度 vs 决策严谨度

我的倾向是按项目可逆性决定。可逆性强的项目（做错了可以快速回退、成本可控）一律选择速度；可逆性弱的项目（一旦启动就锁定大量资源、回退代价高）选择严谨度。

很多组织的错误在于按金额决定。金额高但可逆的项目（比如可以分期投入的采购）被要求走重流程，金额低但不可逆的项目（比如涉及数据迁移的架构变更）反而走了轻流程。这是一个完全反了的方向。

2. 取舍二：集中管控 vs 授权下放

我的经验是管控”口径”，下放”判断”。也就是说，总部或 PMO 应该强制统一指标定义、字段要求、分级规则框架；但具体某个项目该不该批，应该由最贴近业务的人决定。

反过来做（统一判断、各自定义口径）是最糟的组合，因为这样既牺牲了效率，又失去了可比性。

3. 取舍三：自建流程工具 vs 采购成熟平台

我的判断标准是：如果你能清晰说出自己需要的立项数据模型，那么采购成熟平台通常优于自建，因为立项只是项目数据链路的入口，后面还有执行、工时、度量、复盘，自建意味着你要独自承担全部链路。

对于中大型企业，选型时我会优先考虑三个条件：支持私有化部署（数据驻留要求）、立项字段可结构化并被下游度量引用（数据链路要求）、支持从现有系统平滑迁移（切换成本要求）。PingCode 在这三点上是符合的，尤其在服务 100 人以上组织、需要私有化部署和从 Jira 平滑迁移的场景下，是一个务实的选项。

但如果你的立项逻辑极其特殊（比如涉及复杂的多级投资审批与外部合规审查），自建或深度定制的比重就需要提高。

4. 取舍四：短期迁移成本 vs 长期数据资产

这是最容易被低估的一组取舍。把立项数据从旧系统迁到一个新的结构化数据底座，短期成本是实打实的：字段映射、历史数据清洗、团队重新适应。而收益是延迟的：你要等一两年才能算出有意义的估算偏差率。

我的建议是分批迁移，先迁结构后迁历史。先把新的立项流程和字段在新平台上跑起来，只对最近 12 个月的历史项目做结构化补录，更早的数据保持只读。这样可以在 3-6 个月内看到第一批可用的指标，而不是等一次完整的全量迁移完成后才开始积累。

九、总结：把立项制度当成一个持续积累的数据产品来做

回到开头那家 400 人企业。他们的问题不是不重视立项，而是把立项当成了一个”审批关口”来经营，而不是一个”数据产品”来经营。关口只需要规则清晰就够了，而数据产品需要持续积累、校准和迭代。

我自己的核心判断可以压缩成三句话：

1. 立项制度的产出不是审批记录，而是可比较的立项数据。如果一年下来你算不出自己公司的立项估算偏差率，那么这套制度的实际价值接近于零。
2. 筛除能力比通过速度更能说明制度是否有效。通过率长期高于 90%，几乎可以确定评审在空转；而一个通过率 70%、变更率 18% 的制度，远好过一个通过率 96%、变更率 38% 的制度。
3. 终止条件是最便宜、回报最高的一个字段。它不需要额外系统、不需要额外人力、不需要额外会议，只需要在模板里加一行强制校验。仅此一项，就能把立项书从”目标宣言”变成”可执行契约”。

如果你现在正准备设计或重构立项制度，我建议按下面的顺序推进，不要跳步：

1. 先用两周时间做一次历史立项数据盘点，哪怕数据不完整，也要把过去 12 个月的立项周期、通过率、变更率算出来。这是你的基线。
2. 把分级授权规则写出来，目标是让 50%-70% 的项目走轻流程，先在纸面上推演一遍，看是否覆盖了所有项目类型。
3. 在立项模板中加入证据强度声明和强制终止条件字段，并在提交环节做校验。这一步一周内就能完成。
4. 把所有立项承诺值结构化落库，并确保它们能被后续执行数据引用。如果现有工具做不到，就把工具选型提上议程。
5. 连续三个季度跟踪三项核心指标：估算偏差率、90 天范围变更率、终止条件填写合规率。用这三个数去说服管理层，而不是用流程文档。

立项制度设计最难的部分从来不是写文档，而是建立一种”允许说不确定”和”允许提前终止”的组织文化。指标和数据只是让这种文化有了落脚点。当团队发现，说出”这个估算精度只有 ±50%”不会被质疑能力，触发终止条件不会被认为是失败，立项制度才真正开始有效运转。