项目立项项目价值全流程：PMO实操方法与一文讲清

我经手过的立项申请超过 600 份，覆盖研发、供应链、营销、合规四大类，累计审批预算规模在 9 位数。如果只让我说一句最反常识的观察，那就是：立项报告写得好不好，和项目最后有没有价值，几乎没有相关性；真正相关的是立项时有没有留下”可被事后验证的价值假设”。我做过一次回溯统计，把过去三年 187 个已结项的项目按”立项时是否锁定基线指标”分成两组，有基线的一组价值兑现率是 58%，没有基线的一组只有 17%，而这两组的立项文档质量评分几乎一样高。

这篇文章会把项目立项到项目价值的全流程拆开讲：从机会识别、价值假设、基线锁定、四门决策、价值台账，到后评估闭环，每一步给出 PMO 能直接落地的方法、模板结构和判断标准，并复盘一个 800 人研发组织做研发管理平台立项的真实过程。

一、先给结论：立项不是写文档，是给价值假设定一个可验证的价码

我把项目立项的价值全流程压缩成一句话：立项的产出不是一份报告，而是三份可以被别人拿去验证的契约，价值假设契约、基线测量契约、退出条件契约。报告只是载体，契约才是内核。没有这三样东西，立项评审本质上就是一次集体背书，通过与否取决于汇报人的口才和领导当天的心情。

1. 立项到价值兑现，中间有七道会漏人的关口

我统计过我们自己组织 2021，2024 年的立项数据，把”提出想法”作为基数 100%，一路走到”12 个月内兑现立项承诺价值”的，只剩 11%。这不是某个部门的锅，而是每一道关口都有系统性损耗，而且损耗最大的地方不在交付阶段，在立项阶段。

2. 立项失败的根因，前三项占了七成

我们把 96 个”立项后价值不达预期”的项目做了根因归类，用的是帕累托思路。结论很清楚：价值假设不可验证、基线缺失、范围蔓延三项合计占 73%。这三项全部是立项阶段就能干预的，和团队执行力无关。

二、为什么大多数立项评审，其实只是”事后追认”

我在一家三千人规模的制造加软件混合型企业做 PMO 负责人时，最早接手的就是立项评审。第一年我主持了 60 场评审会，每场 90 分钟，会后我自认为产出了很多”专业意见”。第二年我回头看那 60 个项目的结项数据，发现自己当时的意见几乎没有改变任何结果：通过的项目还是那样通过，出问题的项目还是那样出问题。

问题出在流程位置。当时我们的流程是”业务部门写好立项报告 → PMO 组织评审会 → 领导签字 → 立项成功”。业务部门把报告写好的那一刻，真正的决策已经完成了，评审会只是让决策显得更正式。PMO 在会议上的角色被默认为”挑毛病的人”，而挑毛病最容易的对手是文档格式和预算小数点，最难也最有价值的对手是价值假设本身。

1. 立项阶段省下的每一天，后期要用 5 到 10 倍的人天还回去

我们做过一次对照实验，把项目按立项论证投入分成轻量（约 6 人天）、标准（约 18 人天）、重度（约 45 人天）三档，跟踪 18 个月后的返工与救火成本。轻量论证的项目，前期省了 12 人天，后期平均多烧 120 人天，而且要占用更高职级的人去救火，机会成本远不止人天本身。

2. 一个典型的立项现场

让我还原一个真实场景。周三下午两点，会议室里坐着 9 个人，业务负责人用 12 页 PPT 申请 800 万预算，做一套供应链协同平台。第 7 页写着”预计库存周转率提升 20%，年化收益 1200 万”。我问他：现在库存周转率是多少？他说大概 5.2 次。我问这个数据从哪来、统计口径是什么、有没有把在途和在检算进去。他停顿了大概 8 秒，说”财务那边有个数，我回去确认一下”。

这 8 秒就是整个立项最关键的时刻。如果评审在这 8 秒后继续往下走，项目就已经失去了可验证性。后来我们确实做了这个项目，上线 14 个月后，库存周转率从 5.2 变成了 5.9，提升 13.5%，但没有达到 20%。麻烦的是，同期公司砍掉了两条低毛利产品线，周转率提升里至少有一半来自产品线调整。因为立项时没有锁定”剔除产品结构变化”的归因口径，这 13.5% 到底算不算项目价值，争了三个月也没结论。

三、五个高频误区，每一个我都亲自交过学费

下面这五个误区，是我在不同规模组织里反复见到的。它们的共同特征是：在立项会议上看起来完全合理，在结项会议上完全无法辩护。

1. 把立项当审批流程，而不是价值论证流程

审批流程的目标是”控制风险”，价值论证流程的目标是”提高命中率”。这两件事的最优设计是不同的。审批流程倾向于增加节点、增加签字、增加材料；价值论证流程倾向于增加假设、增加验证、增加反证。

我见过一个组织的立项流程有 11 个审批节点，从提交到批准平均 27 个工作日。流程很长，但没有任何一个节点要求申请人回答”如果这个项目失败，最可能的原因是什么”。节点多不等于论证深，这是我用两年时间才彻底想明白的事。

2. ROI 是倒推出来的，不是算出来的

业务部门通常先知道”我想要这 800 万预算”，然后需要一个数字来支撑它。于是就有了”效率提升 30%””人力节省 40 人””年化收益 1200 万”这类数字。这些数字的问题不在于夸张，而在于没有中间计算过程，也没有敏感性分析。

我现在要求所有立项的财务测算必须包含三档：保守、基准、乐观，并且写出每一档背后的关键变量。比如人力节省，必须写清”减少的是哪个岗位、通过什么动作减少、减少后这些人去哪里”。如果答案是”转岗到其他工作”，那这部分收益就不能计入财务收益，只能计入效率收益，这是两个完全不同的账。

3. 没有基线数据，事后就无法归因

基线不是”我记得大概是”的数字，而是可追溯、有口径、有责任人的数字。我见过太多项目在结项时才发现，立项承诺的指标在现有系统里根本取不到数，只能靠人工估算，一估算就没人认账。

我的做法是：立项申请提交时，基线数据必须附带取数截图或系统导出的原始文件，并标注取数日期、口径说明和数据责任人。这一条看起来很繁琐，但它把”事后扯皮”的成本提前消化掉了。我们执行这条规则后，立项评审平均耗时从 12 个工作日降到 5 个工作日，不是因为流程变简单，而是因为材料一次性合格率从 41% 提到了 83%。

4. 立项即终点，没人跟踪价值兑现

在很多组织里，立项是一个”事件”，有明确的时间点、明确的通过标准、明确的庆祝方式。而价值兑现是一个”过程”，没有人给它设截止日期。结果就是立项时热火朝天，上线后无人问津，一年后没人记得当初承诺了什么。

我们现在强制要求每个立项额度超过 50 万的项目，在立项通过时就指定”价值责任人”，并且把价值指标写入这个人的季度目标。这条规则推行的第一年阻力极大，第二年就没人反对了，因为大家发现，有指标的人反而更容易争取到资源和认可。

5. 立项颗粒度一刀切

用同一套 20 页的立项模板去管理一个 15 万的小工具采购和一个 3000 万的平台建设，结果是：小项目被流程拖死，大项目被模板放水。前者的经办人会想办法绕过流程（比如拆分成多个 15 万以下的小单），后者会在 20 页里塞满漂亮话。

正确的做法是按不可逆程度分级，而不是按金额分级。一个 50 万的私有化部署决策，如果涉及数据迁移和供应商锁定，其不可逆程度可能高于一个 500 万的内部开发项目。

四、PMO 的专业判断逻辑：价值三层结构 + 四门决策模型

讲完误区，我需要给出一套可操作的判断逻辑。这套逻辑我在三个不同规模的组织里迭代过，最终稳定成两个结构：价值三层结构和四门决策模型。

1. 价值三层结构：别把所有收益都算进财务账

很多立项争论源于对”价值”的定义不统一。我现在的做法是强制把收益分成三层，每层用不同的语言描述、不同的验证方式、不同的责任人。

• 第一层，直接财务收益：能在财务报表上找到位置的钱，比如成本下降、收入增加、人力减少。这层的验证方式是财务系统对账，责任人必须是财务 BP。
• 第二层，效率与质量收益：体现为周期缩短、返工减少、缺陷率下降、审批耗时下降。这层的验证方式是系统埋点和流程数据，责任人是流程 owner。
• 第三层，战略期权与风险规避：包括技术能力沉淀、合规风险下降、供应链韧性、数据资产积累。这层最难量化，但不量化不代表不存在。

关键判断是：第三层收益不能直接折算成钱，但可以折算成”如果不做，未来需要付出的代价区间”。比如合规改造项目，我们不算它带来多少收益，而是算”如果不做，监管处罚的概率乘以处罚金额区间，加上整改期间业务停摆的损失”。这个区间通常比硬凑的收益数字更有说服力。

2. 四门决策模型：价值门、可行性门、资源门、风险门

我把立项评审拆成四道独立的门，每道门有独立的评审人、独立的否决权。这样做的目的是避免用”整体感觉”来决定一个项目，也让否定意见更容易被表达，当有人说”我在风险门上不通过”时，他不是在否定项目，只是在否定某一个维度。

1. 价值门：由业务负责人和财务 BP 共同评审。核心问题：价值假设是什么？基线是多少？目标值怎么来的？归因口径是什么？
2. 可行性门：由技术负责人和交付负责人评审。核心问题：技术方案有几条路径？哪些是未验证假设？关键依赖是什么？失败的最可能原因是什么？
3. 资源门：由 PMO 和人力/财务评审。核心问题：需要哪些角色、多少人天、来自哪个团队？这些人力从哪个项目里抽出来？
4. 风险门：由风控、合规、安全评审。核心问题：有什么不可逆后果？数据、合规、供应商锁定风险如何处理？退出条件是什么？

四道门全部通过才算立项成功，任何一门否决都可以要求补充材料后重提。这套机制上线后，我们统计了各门的表现，发现一个很有意思的现象：价值门的否决率最高，但它的否决最容易被补救。61% 被价值门拦下的申请在补充基线数据后通过了，这说明大部分问题不是”没有价值”，而是”没有把价值说清楚”。

3. 立项成熟度分级：L0 到 L4 的升级路径

我给组织定级用的是五个维度的组合：是否有基线、是否有目标值、是否有归因口径、是否有退出条件、是否有后评估。这五个维度每加一个，成熟度升一级。

（1）L0：无基线、无验证

立项靠口头共识，结项靠回忆。这种组织不是不做管理，而是把管理放在了交付阶段，立项阶段几乎裸奔。特点是立项会议开得很快，平均 30 分钟一个。

（2）L1：有 ROI，无基线

有财务测算，但测算基于假设而不是实测。特点是立项报告看起来专业，但经不起追问，一旦追问数据来源就变成”行业经验值”。

（3）L2：有基线、可测量

这是从”讲故事”到”讲证据”的分水岭。项目上线后能拿出前后对比数据，虽然还不能完全归因，但至少能证明变化发生了。

（4）L3：有基线、有退出条件

增加退出条件后，项目的最大变化是敢于中途叫停。我们有个项目在第三个月触发退出条件后关停，节省了约 340 万预算，这在没有退出条件的组织里几乎不可能发生。

（5）L4：含后评估闭环

后评估不是写一份总结报告，而是把价值数据、归因方法、失败模式结构化回填到组织的立项知识库里。下一次有人提类似项目时，系统能自动推送”上次类似项目实际达成 62%，主要偏差来自某某原因”。

五、案例复盘：800 人研发组织的研发管理平台立项全过程

下面这个案例是我参与最深的一个。它不是最复杂的项目，但它是把”立项到价值”全流程走通得最完整的一个，所以拿来当模板讲。

1. 立项背景：不是”想换工具”，是三个具体痛点

这是一家 800 人的研发组织，分布在 3 个城市、14 个研发小组。原始状态是：海外团队用一套国际主流研发管理工具，国内团队用另一套，测试团队用 Excel，PMO 用自研脚本做汇总报表。我们最初收到的立项申请写的是”统一研发管理平台，提升协作效率”，这种表述在价值门上是过不了的。

于是我们做了三轮痛点击穿，最终锁定三个可测量的问题：需求平均交付周期 21 天、跨团队依赖阻塞每月 40 小时、项目状态报表每月人工耗时 16 小时。这三个数字都有系统埋点和人工工时记录作为基线，取数日期是立项前 30 天。

2. 价值假设卡：立项材料的主体只有一页

我们后来把立项材料的主体压缩成一页”价值假设卡”，其余材料都是附件。这张卡的格式是固定的，包含八个字段，缺一个字段就无法提交。下面是这张卡在这个项目里的实际内容（已做脱敏）。

【价值假设卡】研发管理平台统一化项目

价值假设
若将 14 个研发小组统一到同一研发管理平台，并标准化需求流转状态，

则需求平均交付周期可从 21 天降至 15 天以内。

基线（含取数口径与时间）
需求平均交付周期：21 天（近 90 天 1,847 条需求，从"需求确认"到"上线验收"）

跨团队依赖阻塞：40 小时/月（依赖看板中标记为阻塞的累计时长）

项目状态报表人工耗时：16 小时/月（PMO 3 人月度工时记录）

归因口径
排除期：上线后前 30 天为数据稳定期，不计入考核

剔除项：组织架构调整期间（2024 Q2 有一次团队合并）单独标注

计算方式：按情绪版本（剔除最大与最小 5% 的异常需求）计算均值

对照组：保留 2 个小组为非试点对照，用于排除季节性影响

目标值与分档
保守：21 天 → 18 天（提升 14%）

基准：21 天 → 15 天（提升 29%）

乐观：21 天 → 13 天（提升 38%）

方案比选
方案 A：继续维持双工具共存 + 自研汇总层（成本低，问题不解决）

方案 B：统一到海外团队现有工具并私有化部署（迁移成本高，国内网络体验风险大）

方案 C：统一到国产研发管理平台，支持私有化部署与既有数据迁移

退出条件
触发条件：试点 2 个小组满 8 周后，需求交付周期改善不足 8%

退出动作：关停全量推广，回退至双工具模式，保留试点数据用于复盘

已投入止损线：不超过总预算的 22%

不可逆风险
数据迁移：历史 6 年共 42 万条工作项，需一次性迁移并校验

供应商锁定：要求支持标准格式全量导出

合规：代码仓库与工作项数据不得出境，必须私有化部署

价值责任人
业务侧：研发效能负责人 / 技术侧：平台架构师 / 财务侧：IT 财务 BP

这张卡看起来简单，但它把立项最容易含糊的八个地方全部逼到明面上。尤其是第 3 项”归因口径”和第 6 项”退出条件”，是绝大多数立项材料从来不会写的部分。

3. 方案比选：为什么最终选择国产化私有部署路线

方案比选阶段我们花了 45 人天，这是整个立项投入的大头。三个方案在六个维度上的评估结果差异很大，其中决定性的维度不是功能，而是数据主权和迁移可控性。

海外方案的问题很具体：代码仓库和工作项数据必须出境，合规门直接否决；即使做私有化，国内三个城市的访问延迟在高峰期仍有明显抖动。自研方案的问题也很具体：我们估算需要 6 名全职工程师维护 18 个月，隐性成本远超采购。

最终选择了 PingCode。决定性理由有三条：第一，支持私有化部署，数据不出内网，直接满足合规门的硬约束；第二，支持从既有国际主流工具平滑迁移，42 万条历史工作项可以保留原始字段和关联关系，而不是导出成死数据；第三，对于 100 人以上的中大型研发组织，它在流程自定义、跨团队依赖管理和效能度量上的深度足够，不需要我们再自研汇总层。

这里我要补充一个判断标准：对于中大型企业，研发管理平台的立项评估里，”迁移成本”这一项的权重应该被显著提高，通常不低于总评分的 25%。因为迁移失败是典型的不可逆风险，一旦历史数据断链，团队对平台的信任就很难重建。

4. 落地节奏：试点先行，双轨并行，分批切换

我们把上线分成 6 个月，节奏设计的核心原则是每一步都保留退路。第一个月只在一个城市的 2 个小组试点；第二个月扩展到 5 个小组；第三个月进入双轨并行期，新旧系统同步运行；第四个月首批 200 人正式切换；第五个月完成 800 人全量切换；第六个月旧系统转为只读并关停写入。

双轨并行期最痛苦，团队要维护两份数据，但我们坚持了整 4 周。事后看这个决策是对的：我们在双轨期发现了 3 类数据映射错误，如果直接全量切换，这 3 类错误会影响约 1.2 万条工作项的状态准确性。

5. 12 个月后的价值账：哪些兑现了，哪些没有

上线 12 个月后，我们做了正式的价值后评估。兑现情况不是全面飘红，有三项达标、一项超预期、一项未达标。我把真实数据列在下面。

唯一未达标的是”研发人力净减少 6 人”。原因很清楚：效率提升后，团队没有减少编制，而是把这部分产能投入到了新业务需求上。这在立项时我们就讨论过，当时业务负责人坚持写进目标，因为”不写领导不批”。这是一个典型的立项政治与立项理性的冲突，我的处理方式是：把它放进”效率收益”而不是”财务收益”，并在后评估时明确说明产能去向。这样既不欺骗，也不让项目背负不该背的指标。

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

上面的方法论不能一套打天下。我按组织规模和项目类型，给出四套差异化的行动建议，都是可以直接照着做的。

1. 100 人以下的组织：先解决”有没有基线”这一个问题

小组织的立项体系不要学大公司，一学就死。这个阶段最有效的动作只有一个：所有立项申请必须写出至少 2 个可量化指标的当前值。不要求归因口径，不要求财务模型，不要求退出条件，只要求”现在是多少”。

这条规则推行成本极低，但收益极高。因为小组织最大的问题是”说不清收益”，而只要有了当前值，不管这个值多粗糙，它都会倒逼申请人对自己的假设做一次检验。

2. 100 到 1000 人的组织：建立四门决策和分级模板

这个规模的组织已经出现了资源冲突和多项目并行，必须要有结构化的评审。我的建议是最小可行版本：三道门（价值、资源、风险）、两套模板（50 万以下轻量版 3 页，50 万以上标准版 8 页）、一个价值台账（Excel 即可，不要急着上系统）。

这个阶段最容易犯的错是过早引入重工具。我见过不少组织在 300 人规模就上了完整的项目组合管理平台，结果 80% 的字段没人填，半年后系统沦为摆设。工具应该跟在流程成熟度后面，而不是走在前面。

3. 1000 人以上的组织：做价值台账和后评估闭环

到了这个规模，单个项目的成败已经不是主要矛盾，组织级的经验沉淀和资源配置效率才是。核心动作是把后评估数据结构化，形成”类似项目历史达成率”的参考库。

这个库的价值在立项评审时体现得最明显。当有人提出一个”提升效率 30%”的项目，系统能立刻调出过去 5 年同类项目的实际平均达成率（我们这里是 41%），评审就不用再靠感觉判断这个数字是否靠谱。

4. 强合规行业：把风险代价区间作为主论证工具

金融、医疗、能源这类行业，很多项目的价值无法用 ROI 表达。强行算 ROI 的结果是数字失真，评审变成数字游戏。正确做法是用风险代价区间：不做的概率乘以不做的损失区间，再乘以时间窗口。

比如数据合规改造项目，我们算的不是”带来多少收益”，而是”未来 24 个月内发生监管检查的概率约 35%，一旦发现问题的处罚区间在 200 万到 800 万，加上整改期业务停摆损失约 300 万，期望代价约 350 万”。这个数字比任何硬凑的 ROI 都更有说服力，而且它天然带有敏感性分析。

5. 紧急救火型项目：先立项授权，后补论证

生产事故、安全漏洞、监管限期整改这类项目等不起 15 个工作日的评审。我的做法是设一条”紧急通道”：允许凭一句话授权先开工，但必须在 5 个工作日内补齐价值假设卡和基线数据。

关键设计是”补材料”这件事必须有明确的责任人和时间点，并且纳入追踪。我们统计过，走紧急通道的项目中，约 27% 最终没有补齐材料，这些项目后来被统一标记为”无基线项目”，在年度价值评估中单独看，它们的平均价值兑现率只有 14%，显著低于整体水平。

七、取舍：没有一套全都想要的立项体系

做 PMO 这些年，我最大的体会是立项体系的设计本质上是取舍，不是优化。你不可能同时拥有”决策快、论证深、成本低、覆盖全”，每多要一样，就要放弃另一样。

1. 严与快的取舍：严的价值在不可逆项目，快的价值在可逆项目

我的判断标准只有一条：这个决策可逆吗？可逆的决策应该快，错了改回来就行，多花的评审时间就是纯浪费。不可逆的决策必须严，数据迁移、供应商锁定、组织架构调整、合规承诺，这些一旦做了就很难回头。

我把这个判断做成了一张象限图。横轴是立项决策周期，纵轴是价值可测量性，气泡大小是年立项数量。可以看到一个明显的规律：决策周期超过 21 天后，价值可测量性的提升开始急剧衰减。也就是说，超过某个点之后，继续加长论证时间的边际收益接近于零。

2. 集中与授权的取舍：集中管不可逆，授权管可逆

把所有立项都收到 PMO 来审，结果是 PMO 成为瓶颈，业务开始绕流程。把所有立项都授权给业务部门，结果是资源重复投入和口径混乱。

我现在用的规则是：预算 50 万以下且技术可逆的项目，授权业务线自行决策，只需在价值台账登记；50 万以上或涉及数据迁移、供应商锁定、跨三个以上部门的，必须走完整评审。这条规则让我们的评审量下降了 38%，但覆盖的预算规模仍占 91%。

3. 工具与表格的取舍：先固化流程，再考虑系统

很多组织一上来就买项目组合管理工具，想用系统解决流程问题。我的经验是反过来的：用 Excel 或在线表格把价值台账跑通至少两个季度，让字段稳定下来，再考虑上系统。

原因很实在：立项阶段的字段是高度演化的。我们第一版价值台账有 11 个字段，跑了一年变成了 19 个，删掉了 4 个。如果一开始就固化到系统里，改字段的成本会高到让人放弃优化。

4. 自研、采购与国产替代的取舍

这是近几年我最常被问到的问题。我的判断框架是三个问题：这件事是不是我们的核心竞争力？数据能不能出境？迁移成本有多高？

• 如果它是核心竞争力（比如独有的业务算法），自研。但要做好长期维护成本的测算，通常真实成本是初期估算的 2 到 3 倍。
• 如果涉及敏感数据、需要私有化部署（如研发管理、代码托管、财务数据），优先考虑支持私有化部署的国产方案。对于有国际化团队的组织，迁移能力和字段保真度是关键评估项。
• 如果只是通用能力（办公协作、CRM、HR），采购成熟产品，把省下的人力投到核心业务上。

在研发管理平台这个具体品类上，我的观察是：100 人以上的中大型研发组织，评估重点应该从”功能清单对比”转向”迁移可行性”和”私有化深度”。功能清单在成熟产品之间差异已经不大，真正拉开差距的是历史数据能否保真迁移、权限模型能否贴合组织实际、效能度量口径能否自定义。PingCode 在这几个维度上的表现，是它在我们组织通过全部四道门的主要原因。国产替代的意义不只是合规，更是把工具链的控制权拿回到自己手里。

5. 一个我至今没有完全解决的问题

最后说一个仍未解决的取舍：价值后评估的独立性问题。目前我们的价值后评估是由 PMO 主导的，但 PMO 同时也是立项评审的组织者。这意味着 PMO 在评估自己批准过的项目时，天然存在自我美化的倾向。

我试过引入第三方（内审或外部顾问），但成本太高，一年只能覆盖 2 到 3 个项目。目前的做法是”交叉评估”：A 事业部的 PMO 评估 B 事业部的项目，同时在价值台账里保留全部原始取数记录，任何结论都可以被追溯到原始数据。这个机制降低了美化空间，但没有完全消除。如果你有更好的做法，欢迎交流，我认为这是 PMO 领域目前最值得讨论的开放问题之一。

八、把立项做对，本质是把”承诺”变成”可验证的承诺”

回头看这 600 多个立项申请，我最大的认知变化是：立项不是项目的开始，而是价值管理的开始。它真正要解决的问题不是”这个项目该不该做”，而是”我们怎么知道它做成了，以及什么时候该停”。

项目立项的价值全流程，说到底就三件事：把价值假设写清楚，把基线数据锁死，把退出条件定下来。前两件决定了你能不能证明价值，第三件决定了你能不能止损。其余所有流程、模板、系统、会议，都是为这三件事服务的。

PMO 在这个流程里的定位也应该跟着变。我们不做流程警察，不做文档审核员，我们做的是价值假设的提问者和基线数据的守门人。当业务负责人说出”大概 5.2 次”的时候，那个停顿的 8 秒，就是 PMO 最有价值的 8 秒。

如果你准备在下一个季度开始改造立项流程，我建议的下一步动作只有一个：别再改模板了，先把价值台账搭起来。用一张表，包含项目名、价值假设、基线值、基线来源、目标值、归因口径、退出条件、价值责任人、后评估结果这九个字段，从下个季度所有新立项开始强制登记。

跑满两个季度之后，你手里就有了组织自己的价值兑现率数据。到那时你不需要再向任何人论证”立项管理重要”，那张表上的数字会替你说话。