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

去年年底做年度复盘时，我把一份两年前的项目立项书重新翻了出来。立项书里白纸黑字写着”预计每年节省人力成本 480 万元、审批周期从 5 天压缩到 1 天”。但当我真的去查这套系统上线 18 个月后的运行数据时，节省金额没人核算过，审批周期只有两条流程达标，剩下的流程因为线下签字环节没砍掉，实际还是 4 天多。

那一刻我意识到，问题不在于立项书写得好不好。问题在于这份价值承诺从评审通过的那一天起，就再也没人认领了。预算有人管，进度有人管，风险有人管，唯独最初让这个项目拿到预算的”价值”本身，处于完全无人看管的状态。

后来我又陆续拆了 11 个中大型组织的立项与验收档案，包含制造、金融、SaaS 和一家三甲医院的信息化项目。一个高度一致的规律浮出来：项目价值失效，绝大多数不是因为执行不力，而是因为立项阶段就把”价值”写成了一个无法被跟踪的名词。 这篇文章我想把立项到价值兑现的全流程讲透，并且只讲项目成员真正能上手的动作，不讲 PMO 层面的管理口号。

一、核心结论：项目价值是一条四段式账本，不是一张立项审批单

先把结论放在最前面。项目立项到价值兑现，本质是一条四段式账本：立项时的价值假设 → 启动时的价值基线 → 验收时的价值核对 → 上线后的价值复盘。这四段里，绝大多数组织只认真做了第一段，后面三段基本处于”无人认领”状态。

我见过最典型的现象是：立项评审会开三个小时，反复讨论 ROI 到底该写 12% 还是 15%；而项目验收会只开 40 分钟，确认功能是否上线、有没有严重缺陷就结束了。价值核算在整个项目生命周期里的严肃性，是断崖式下跌的。

1. 立项书里的价值是”假设”，不是”结论”

任何立项阶段的价值测算，本质上都是基于当时有限信息的假设。假设本身没问题，问题是组织把假设当成了承诺，既不做基线采集，也不做后续验证。

更麻烦的是，一旦这个数字写进了审批单、写进了年度经营目标，它就变成了”政治正确”的数字。项目组不愿意去戳破，业务部门懒得去核实，财务只能在年终时按另一个口径重新估算一遍。最后的结果是，立项时的 480 万，到了年终变成了”项目已上线，效果待观察”。

2. 价值指标必须同时满足”可观测、可归因、可复盘”

我判断一个价值指标能不能用，只看三件事：能不能被观测（有明确数据源）、能不能被归因（知道是哪个项目动作带来的）、能不能被复盘（事后有基线可对比）。三者缺一，这个指标就只是修辞，不是指标。

举一组对照。”提升客户满意度”不可观测，因为没有指定数据源和统计口径；”客服工单首次响应时长从 4 小时降到 1 小时”可观测、可归因、可复盘，虽然听起来没那么宏大，但它能在项目验收时被摆到桌面上核对。

3. 项目成员在价值链条上有四个不可替代的动作

这一点是我和很多团队争论过的地方。价值管理常被默认为 PMO 或财务的职责，但真正能让价值不飘走的，恰恰是项目成员自己。我总结出四个具体动作：

• 立项阶段：提供一线数据，纠正管理层拍出来的基线。 业务方说”现在每月处理 3000 单”，作为一线执行的你知道实际是 4200 单且旺季能到 6000 单，这个差异必须当场提出来。
• 启动阶段：把价值指标翻译成工作项字段。 “审批周期压缩 80%”要落到具体流程名、环节名、责任人，才可能被系统自动统计。
• 执行阶段：随手留存价值实现证据。 改造前的截图、改造后的耗时日志、用户从抱怨到认可的原话，这些东西事后补是补不回来的。
• 验收阶段：交付价值核对清单，而不只是功能清单。 功能清单说明”我们做了什么”，价值核对清单说明”承诺的东西有没有发生”。

4. 一条底线：没有基线的价值指标等于没有指标

这是我这几年最坚持的一条。立项时如果拿不到当前基线值，就必须把”建立基线”本身列为一个有工期、有负责人的前置任务，而不是先拍一个看起来合理的数字把它填上。

基线缺失造成的损失是隐性的。项目做完了，没人知道到底改善了多少，于是这个项目的真实价值也无法进入下一轮立项论证，组织丧失了一次学习机会。

二、背景与真实场景：价值为什么在立项后 90 天开始蒸发

要理解这个问题，得先看清它是怎么发生的。我把上面那 11 个项目按时间轴拉平，发现价值管理的热度衰减有一个相当固定的节奏。

1. 一次真实的立项复盘：480 万是怎么变成”没法算”的

回到开头那个项目。它是一家 400 人规模制造企业的”采购到付款流程数字化”项目，2022 年立项，预算 180 万，承诺年节省人力成本 480 万。

我在复盘时逐条追了它的价值假设。480 万的算法是：采购部 12 人 × 每人每天 1.5 小时手工对账 × 250 天 × 折算时薪。这个算法本身没大问题，问题在于三个隐含假设：第一，系统上线后手工对账时长降为零；第二，12 个人一个都不会减少；第三，对账之外的异常处理不会增加。

实际情况是：系统上线后手工对账时长降到每天 0.4 小时，但因为异常处理需要在系统里补录，反而多出每天 0.6 小时。12 个人一个没减，公司也确实兑现了”不因系统裁员”的承诺。最终真实的节省是”每天 0.5 小时 × 12 人”，大约 140 万，而且没有任何人被安排去核算这笔账。

这个项目不是失败的。它实际创造了价值，只是这个价值从来没有被记录、被确认、被承认过。 结果就是第二年申报新的数字化预算时，CFO 说了一句：”上一个系统做完也没看出效果。”

2. 三个场景切片：价值在不同组织里的三种死法

第一种死法是”只算不算”。立项时算得很细，执行中完全不记录，验收时凭印象说”效果不错”。这种在中小型团队最常见，因为大家默认”做了事自然会有价值”。

第二种死法是”各算各的”。财务按财务口径算，业务按业务口径算，项目组按交付口径算，三套数字在年度总结会上打架。我在一家金融机构见过这个场面，同一个项目，财务说节省 60 万，业务说提升效率 30%，项目组说按期交付、零重大缺陷，三方都觉得自己没错。

第三种死法是”算完不用”。有组织真的建立了价值台账，做了季度复审，但复审结论从不影响下一轮立项决策，也不影响项目组成员的评价。台账变成了形式上正确、实质上没人读的文档。

3. 组织层面的三个根因

踩过这些坑之后，我认为根因只有三个，而且都不是”态度问题”。

• 价值指标没有落到工作项级别。 价值写在立项书里，工作项写在任务系统里，两者之间没有映射关系，系统就永远统计不出价值数据。
• 没有指定的价值责任人。 项目经理负责交付，产品负责人负责需求，但没有人负责回答”承诺的价值兑现了吗”。
• 价值复盘的周期跟业务周期错配。 很多价值要 6 到 12 个月才能显现，而组织的复盘节奏是季度或年度，中间没有任何触点。

4. 数据观察：价值指标的被引用次数衰减曲线

我做过一个小的量化观察，样本是 6 个组织、共 34 个项目，统计方式是看项目立项文档中提到的价值指标，在项目周报、月报、评审材料里被引用的频次。

结果相当一致：立项后第一个月，平均每个项目有 18 次引用；第三个月降到 9 次；第六个月 4 次；第十二个月 1.2 次；第十八个月只剩 0.4 次。而指定了价值责任人的 9 个项目，第十二个月仍有 3.8 次引用，衰减速度慢了约三倍。

三、常见误区拆解：价值失效的五个高发位置

把 11 个组织的复盘结论合并统计后，我发现价值失效的位置高度集中。下面这五个误区，在你自己的项目里大概率能对上号。

1. 误区一：把 ROI 算成一个精确数字

我见过最离谱的一份立项书，ROI 写到了 187.3%。这个精确到小数点的数字，反而暴露了它是由一个理想模型推导出来的，而不是从真实业务里长出来的。

我的判断是：立项阶段的价值测算应该给区间，而不是给点值。 写”年节省 120 万到 180 万，取决于采购订单线上化率能否达到 70%”，比写”年节省 156 万”要诚实得多，也更有管理价值，因为它同时说明了前提条件，后续就能围绕这个前提做跟踪。

2. 误区二：把交付范围当成价值

“本期上线 8 个模块、37 个功能点、覆盖 5 个部门”，这是范围，不是价值。范围说明你交付了多少东西，价值说明这些交付改变了什么。

我见过团队在验收会上逐条念功能清单，念完之后领导问”那我们现在跟做之前比，好在哪”，全场沉默。这不是准备不足，这是从一开始就用错了衡量对象。

3. 误区三：价值指标由财务单方面定义

财务口径天然偏向成本节约和资金占用，对用户效率、组织能力、技术资产这类价值不敏感。如果立项书的价值指标全部由财务出，结果通常是”这个项目不省钱，所以优先级低”。

比较健康的做法是三层口径并行：财务给成本与资金口径，业务给效率与质量口径，技术给可维护性与风险口径。三份口径在立项会上并列呈现，而不是让其中一份覆盖另外两份。

4. 误区四：立项评审通过就等于价值锁定

这是我见过代价最大的误区。立项评审的意义是”这个假设值得投入资源去验证”，不是”这个假设已经被证实”。这两句话差别巨大，但很多组织的流程设计默认了后者。

一旦价值被”锁定”，后续所有关于价值不成立的讨论都会变成对项目本身的否定，于是没人愿意提。正确的做法是把价值验证拆成几个明确的检查点，在每个点上允许调整甚至终止。

5. 误区五：只有管理层关心价值，执行成员只是”干活”

这是最隐蔽也最贵的一个误区。执行成员是最早发现”这个价值假设不成立”的人，但如果组织没有给他们提出来的通道和激励，他们会选择沉默，把功能做完就好。

我的做法很直接：在项目周会上固定留 5 分钟，只讨论一个问题，“这周有没有发现什么，说明我们原来的价值假设可能不对？” 这个问题问出口，一线信息才开始流动。

四、专业判断逻辑：项目价值四层账本模型

讲了这么多问题，该给方法了。我用的框架叫”四层账本”，它解决的问题是：让项目价值从一句形容词，变成四个可以分别核算的账本。

1. 第一层：业务价值账（钱、时间、风险）

这一层最直接，也最容易被过度关注。它包含三类指标：成本类（人力、采购、库存、资金占用）、时间类（周期、交付时效、响应时长）、风险类（合规风险敞口、事故概率、损失上限）。

我的经验是，风险类指标最容易被漏掉，但在强监管行业里它的权重往往最高。一个把审计问题从 12 项降到 3 项的项目，账面上不省一分钱，实际价值可能远超一个节省几十万的项目。

2. 第二层：用户价值账（采纳率、留存、满意度）

这一层决定第一层能不能成立。系统再好，如果采纳率只有三成，第一层的所有测算都要打三折。

所以我坚持把采纳率作为一级指标，而不是观察指标。具体口径可以设计成”目标用户中，连续四周每周使用三次以上的比例”。这个口径比”登录过的用户数”严格得多，也真实得多。

3. 第三层：组织能力账（标准化、复用度、协作效率）

这一层最虚，但对中大型组织最重要。一个流程数字化项目可能没省多少钱，但它把五个部门各自为政的流程统一成了一套，这个统一本身就是资产。

可观测的替代指标包括：流程版本数量（从 5 套降到 1 套）、跨部门交接平均等待时长、新员工上手该流程所需天数。这些指标都能从系统日志或人事记录里取到。

4. 第四层：技术资产账（可维护性、可迁移性、合规性）

这一层属于长期账。它关注的是：这套东西三年后还能不能改、数据能不能迁走、能不能满足未来的合规要求。

我通常用三个问题来快速评估：如果要换掉它，需要多少人力天数？如果要导出全部业务数据，需要多久？如果监管要求数据必须留在自有服务器上，当前方案是否支持？ 这三个问题在立项阶段问，成本极低；在上线两年后问，代价极高。

5. 价值验证节奏：立项，30 天，90 天，验收，上线后 6 个月

四层账本要活起来，必须有节奏。我建议的验证节奏是五个触点

1. 立项时： 明确四层账本各自的指标、基线、数据源和责任口径。
2. 启动后 30 天： 确认基线是否采集完成，数据源是否可用。这一步没做，后面全是空中楼阁。
3. 启动后 90 天： 做第一次价值假设校准，允许调整指标和区间，形成正式的变更记录。
4. 项目验收： 出具价值核对清单，逐条标注”已达成 / 部分达成 / 未达成 / 尚不可评估”。
5. 上线后 6 个月： 做一次价值复盘，把结论回写到立项档案，供下一轮立项参考。

6. 四层账本的权重分配逻辑

四层账本不是平均分配的。权重取决于项目类型：流程数字化项目以业务价值为主，客户侧产品项目以用户价值为主，基础设施平台项目则以组织能力和技术资产为主。

把权重搞反，就会出现”用成本节约指标去衡量一个中台项目”这种荒唐事。中台项目的价值本来就在复用度和后续迭代速度上，硬要它当年省出多少钱，它当然不达标。

五、案例与数据观察：一家 400 人企业怎么把价值指标真正管起来

理论讲完，讲一个我实际参与过的案例。跟前面提到的那家制造企业是同一家，只不过这是它第二年重新做的一个项目。

1. 案例背景

公司规模 400 人左右，研发与 IT 合计约 130 人，属于典型的中大型组织。2023 年它启动”研发需求到交付全流程治理”项目，目标是把需求平均交付周期从 47 天压到 30 天以内，同时把需求返工率从 26% 降下来。

这次他们没有再写”预计节省 XXX 万元”，而是把价值拆成了两组可核算指标：交付周期（观测点在需求状态流转日志）和返工率（观测点在需求变更记录）。

2. 做法一：把价值指标写进工作项字段，而不是写在立项书里

这是最关键的一步。他们用的工具是 PingCode，一家主要服务中大型企业及 100 人以上组织的研发项目管理平台。选择它的直接原因就是：需要把价值指标变成工作项上的结构化字段，而不是文档里的一段话。

具体做法是在需求类型的工作项上增加了三个字段：”需求来源部门””首次承诺交付日””实际交付日”。同时在缺陷和变更工作项上增加”关联需求 ID”，用来统计返工。

这三个字段加起来，就让”平均交付周期”和”返工率”变成了系统可以自动算出来的数字。不需要任何人每月手工整理表格，看板上的数字每天都在更新。 这是我见过的最有效的一招，因为价值数据一旦需要人工整理，它就会在三个月内自然消亡。

3. 做法二：私有化部署与 Jira 平滑迁移，保住了价值基线

这家公司原来是自建 Jira 的，积累了三年的历史工作项数据。做价值追踪最大的风险是什么？是历史数据断档，如果迁移过程中丢掉历史记录，就没有基线，没有基线就没有对比，没有对比就没有价值。

他们最终选择了支持私有化部署、并支持 Jira 平滑迁移的方案。私有化部署这一点对这家制造企业是硬性要求，因为研发数据和客户项目数据不允许出内网。迁移后历史工作项的字段映射基本完整，交付周期这类指标可以回溯到 2021 年，基线直接就有了。

我的判断是：在国产替代的选型场景里，能不能把历史数据平滑带过来、能不能私有化部署，这两点的实际权重远高于功能清单上的加减法。 功能可以慢慢补，基线一旦断了，项目价值就永远缺一块证据。

4. 数据观察：18 个月的三组对比

项目从 2023 年 3 月启动，到 2024 年 9 月，我拿到了三组对比数据。

第一组是价值数据本身的可得性：价值指标录入完整率从 21% 提升到 88%，项目价值看板月活查看率从 14% 提升到 67%，验收时价值证据齐备率从 33% 提升到 91%。

第二组是业务结果：需求平均交付周期从 47 天降到 29 天，需求返工率从 26% 降到 11%，月度价值数据核对耗时从 26 小时降到 6 小时。

第三组是我觉得最值得说的：第二年申报新数字化预算时，CFO 没有再问”上个项目效果怎么样”。因为价值看板他每个月都在看。

5. 一个失败对照：同样规模、同样工具、不同结果

为了不做单案例吹捧，我再讲一个对照组。另一家约 350 人的企业，同期做了类似的流程治理项目，也上了同类工具，但一年后价值核算依然做不起来。

差别只有一处：他们只在项目层级建了一个”价值指标”看板，没有把指标拆到工作项字段。看板上的数字需要项目经理每周手工更新一次。

结果是，前六周更新得很准时，第七周开始延迟，第十周开始出现”上周数据补录”，第四个月彻底停更。这不是执行力问题，这是设计问题，任何需要人每周手工维护一次的数据看板，都活不过一个季度。

六、不同情况下的行动建议：按组织规模给出不同起手式

方法论必须落到具体动作。下面按组织规模给出四套起手式，你可以直接对照自己的情况选一套。

1. 30 人以下团队：只要一张价值卡片

这个阶段不要建体系。我建议只做一件事：每个项目立项时，填一张一页纸的价值卡片，包含三项内容，当前基线值、目标值、验证时间点。

举例：”当前版本发布平均耗时 4.5 小时，目标 1.5 小时，2025 年 6 月 30 日前验证。” 就这样，不需要 ROI 模型，不需要四层账本。

这个阶段的取舍是：宁可指标少而准，不要指标多而虚。 一个能被验证的指标，价值高于十个漂亮的指标。

2. 30 到 100 人：建立价值指标字典

这个规模开始出现”每个项目各写各的指标”的问题。解法是建一份组织级价值指标字典，把所有常用的价值指标标准化。

字典里每条指标至少包含：指标名、计算口径、数据源、采集频率、归口部门。比如”需求交付周期”要明确是从”需求创建时间”算到”上线时间”，还是算到”验收通过时间”，这两种算法在同一家公司里同时存在是常事。

根据我自己的观察，完成指标字典的组织，立项论证时间平均缩短约 40%，因为不用每次重新讨论口径。

3. 100 人以上：价值指标必须进工具、进字段、进看板

这是我在本文里最想强调的一条。100 人以上的组织，任何依赖手工维护的价值数据都不可持续。 规模越大，人工流程的衰减越快。

具体做法三步走：第一步，确定 3 到 5 个核心价值指标；第二步，把它们需要的原始数据拆成工作项上的结构化字段；第三步，用工具自带的报表能力自动生成价值看板。

在这个规模上，工具选型的重要性会显著上升。针对中大型企业、100 人以上组织的研发与项目管理场景，我通常建议重点评估三点：能不能自定义工作项字段与工作流、能不能做细粒度的权限与数据隔离、能不能支持私有化部署与历史数据平滑迁移。PingCode 在这三点上比较贴合中大型组织的需求，也是我在国产替代选型里会优先放进候选名单的一类平台。

4. 强监管或多项目并行组织：建价值台账加季度复审

如果是金融、医疗、能源这类强监管行业，或者同时跑 20 个以上项目的组织，需要在前面基础上再加两件事：一张跨项目的价值台账，和固定的季度复审会。

价值台账是一张表，每个项目一行，记录四层账本的关键指标与实际值。季度复审会只做三件事：更新台账、标记偏离超过 30% 的指标、决定是否需要调整项目方向。

关键是复审结论要真的影响决策。我见过太多做得很漂亮的台账，最后沦为汇报材料。如果复审结论不影响任何资源分配，这个会开三次就会没人认真准备。

七、不同情况下的取舍：五个必须提前想清楚的权衡

方法给了，最后讲取舍。这部分内容来自我自己踩过的坑，以及在不同组织里观察到的反复摇摆。

1. 速度 vs 严谨：立项价值论证该花多少时间

我见过两个极端。一个是花三周做立项论证，做完市场变化了；另一个是花半天写立项书，做完发现方向错了。

我的判断标准是不可逆程度。如果这个项目做错了可以快速撤回、成本可控，那就用轻量论证（半天到一天），重点是写清假设和验证点；如果做错了要重构数据库、要替换核心系统、要影响几百人的工作习惯，那就值得花三到五周做严谨论证。

换句话说：论证深度应该跟”改错的代价”成正比，而不是跟”项目预算”成正比。我见过预算不大但影响面极广的项目，被当成小项目轻率立项，最后代价惨重。

2. 统一模板 vs 差异化：标准化的边界在哪

统一定义指标是好事，统一要求所有项目用同一套指标是坏事。研发项目用”交付周期”，市场项目也用”交付周期”，这显然是荒谬的。

我的做法是统一”口径”和”字段结构”，不统一”具体指标”。也就是说，所有项目都必须填”基线值、目标值、数据源、验证时间”，但填什么指标由项目类型决定。

3. 自建 vs 采购：价值追踪能力该不该自研

经常有人问：既然只是几个字段和一张报表，为什么不自己开发？我的回答是，如果你所在的组织本来就有一支成熟的项目管理工具研发团队，且这个能力是你的核心竞争力，自研可行。

但绝大多数情况下，自研的成本被严重低估。你真正要做的不是字段，而是权限体系、工作流引擎、历史数据迁移、报表性能、移动端适配、以及未来三年的持续维护。这些加起来，通常比采购贵得多。

我的一般建议是：价值追踪是通用能力，优先采购；把自研资源留给业务差异化部分。

4. SaaS vs 私有化：数据合规与迭代速度的取舍

这个取舍在强监管行业尤其尖锐。SaaS 的迭代速度快、运维成本低，但数据在外部；私有化部署数据可控、可深度集成，但升级需要自己跟进。

我的判断依据是数据的敏感级别和合规硬约束。如果有一纸明确规定”研发数据不得出内网”，那这个取舍其实不存在，直接选支持私有化部署的方案，然后接受它的升级节奏。

需要提醒的是，选私有化方案时，一定要在合同和技术验证阶段确认三件事：版本升级的周期与方式、历史数据迁移的完整度、以及后续与外部系统集成时的接口开放程度。这三件事在采购阶段是谈判筹码，在上线两年后就变成了沉没成本。

5. 三个”宁可不做”的取舍场景

有些取舍是明确的减法。第一种，如果当前连基础的项目任务管理都还没跑顺，先不要做价值追踪体系，先把任务可视化和状态流转做扎实。

第二种，如果没有明确的业务数据源，不要强行给项目设定精确的价值指标，先立项去做数据采集能力建设，把它作为独立项目对待。

第三种，如果组织内没有任何人有权限去挑战管理层的价值假设，那就先解决这个权限问题。一个不允许被推翻的价值假设，写得再精确也没有意义。

八、总结与下一步：把立项价值变成组织的复利资产

写到这里，我想用三个可能跟你平时听到的略有不同的观点收尾。

1. 三个独特观点

第一，项目价值管理的核心矛盾不是”算不准”，而是”没人算”。 绝大多数组织的测算能力其实是够的，缺的是把测算结果持续跟踪下去的机制。所以建设的重点应该放在机制而不是模型上。

第二，价值数据的获取成本，决定价值管理能不能活下去。 一个需要每月人工整理 26 小时的价值看板，注定会被放弃；一个自动生成的看板，即使初期不被重视，也会自然而然被打开。所以不要先追求指标完美，先追求自动化。

第三，立项价值论证的真正产出，不是那个数字，而是那份”假设清单”。 把假设写清楚，项目中途被推翻时组织能学到东西；只写数字，被推翻时只会产生追责。

2. 下一步：7 天落地清单

如果你读完之后想马上做点什么，我建议按下面这七天的顺序来，每一步都很小，但顺序不能乱：

1. 第 1 天： 挑一个正在执行、且你熟悉业务的项目，把它立项书里的价值表述逐条抄出来。
2. 第 2 天： 给每条表述打三个勾，可观测、可归因、可复盘。三个勾不全的，标记为”需要重写”。
3. 第 3 天： 找出至少一个当前基线值，从系统日志、工单记录或财务报表里取，取不到的记下”数据源缺失”。
4. 第 4 天： 选 3 个指标，写成标准化表达：”当前 X，目标 Y，验证时间 Z，数据源 W”。
5. 第 5 天： 找项目管理工具的管理员，评估把这 3 个指标拆成工作项字段的可行性。
6. 第 6 天： 在下次项目周会上加一个固定环节：5 分钟讨论”这周有没有发现价值假设可能不成立的信号”。
7. 第 7 天： 把这套做法写成一页纸，作为你所在团队下次立项的默认模板。

3. 一页纸价值模板（可直接复制使用）

最后附上我自己一直在用的模板结构。它很朴素，但能覆盖四层账本的核心。

模板共分五段：业务背景与当前基线（现状数据加数据来源）、价值假设与目标区间（至少写三组指标，允许给区间）、四层账本指标清单（业务、用户、组织、技术各至少一条）、验证节奏与责任人（30 天、90 天、验收、上线后 6 个月四个触点的具体负责人）、假设失效的退出条件（什么情况下这个项目应该被重新评估或终止）。

其中第五段是很多模板没有的，也是我认为最重要的。一个事先约定好退出条件的项目，在真的需要叫停时，讨论会理性得多，因为大家都知道这不是谁的失误，而是假设本身被证伪了。

项目价值这件事，短期看是给管理层一个交代，长期看是给组织积累一份可复用的判断力。每一次立项时写下的假设、每一次执行中留下的证据、每一次验收时核对的结果，最终会沉淀成这家公司”知道什么做法有效、什么做法无效”的资产。 这才是”项目价值全流程”真正值得被认真对待的理由。