三年前我否掉过一份 42 页的立项书：市场空间写得漂亮，三年 ROI 算到 3.7，财务模型一页一页做得像投行材料。同一个季度我签了一份只有 6 页的方案，它连 IRR 都没算，唯一的财务数字是”首年投入 78 万元、次年 62 万元”。前者的项目在第 7 个月停摆，后者的系统到今天还在跑，并且额外接了两个业务线。
差别不在文档质量，而在立项这件事到底在解决什么问题。前者在论证”这件事值得做”，后者在回答”我们在赌什么、赌错了怎么撤”。这两句话听起来差不多，落到执行上差出一整年的预算。项目立项从来不是一份交上去等盖章的材料，它是项目负责人对不确定性做的一次定价。这篇文章我会把定价的方法、常见的定价错误、以及我实际用过的三档立项深度模型拆开讲清楚。
一、核心结论：立项不是写文档，是给不确定性定价
先把最重要的判断放在前面，避免你在细节里迷失方向。立项质量的唯一硬指标，是决策者能否在 10 分钟内回答一个问题：什么情况下我们应该停。如果一份立项书让人读完只能说”听起来不错”，那它不是立项书，是宣传册。
1. 立项的真正产出是三个可验证物，而不是一份文档
我在内部推了三年的一条规矩：任何立项评审，必须交出三样东西，缺一样就不进评审会。它们不是文档章节，而是可以被追问、被验证、被审计的对象。
- 价值假设：不是”提升效率”，而是”把每月 12 人天的对账工时压到 3 人天，按 800 元/人天折算，年化 8.6 万元”。它必须带口径、带基数、带验证时点。
- 约束边界：时间盒、资源盒、范围盒三条边界同时给出。缺一条边界，项目就会在中期无限膨胀。
- 可撤回承诺：把大承诺切成小赌注，明确第 1 个赌注多少钱、什么时候能看到结果、什么信号出现就撤回。
这三样东西合起来，就是”定价”。你定的是：为了这个假设，公司愿意支付多少钱、承担多长时间的不可逆投入。
2. 立项深度必须跟着”不可逆投入”走，而不是跟着项目名气走
这是我见过最普遍的资源错配：一个 20 万元的小工具采购，走了三个月立项流程；一个 800 万元的系统替换，靠一次饭桌上的口头认可就启动了。前者被流程拖死，后者在半年后才发现数据迁移成本是预估的 3 倍。
正确的做法是让立项深度与不可逆投入挂钩。所谓不可逆投入，指的是”一旦花出去就收不回来”的部分：已签的采购合同、已投入的人力工时、已迁移的数据、已下线的旧系统。可逆投入再多也不可怕，不可逆投入一点点都致命。
3. 立项失败的成本远高于多数人的直觉
很多人以为立项写得粗糙，最多是”后面补一补”。我实际追踪过一批项目的返工数据，结论并不温和：立项阶段留下的口径缺失，会在执行阶段以倍数放大，因为那时改动牵涉的人和系统都变多了。
二、背景和真实场景：项目负责人为什么会在立项上失手
把方法讲清楚之前，得先说清楚项目负责人真实的处境。大多数项目负责人在立项阶段没有预算审批权，却要对交付结果负责；没有定价权，却要承受定价错误的后果。这是一个典型的”责任大于权限”的位置，也正是立项能力最值钱的地方。
1. 我经历过的三种立项现场
第一种是”业务方口述、项目负责人转写”。业务负责人说”我们这块太乱了，得上个系统”，项目负责人把这句话扩写成 20 页必要性分析。整个立项书里没有一个数字来自业务方自己的账本。
第二种是”技术方案前置”。立项书的 70% 在讲架构、技术选型、接口设计，只有一页在讲收益，而且那一页写着”预计效率提升 30%”，没有基数、没有口径、没有验证时点。这种立项书最容易在评审会上被问倒。
第三种是”财务模型华丽、业务假设空洞”。ROI 算得非常精细，折现率、残值、敏感性分析一应俱全，但基础的”每月处理单量”是从某份三年前的报告里抄来的，早就不成立了。
这三种现场的共同点是：立项书在描述”要做什么”，而不是在描述”在赌什么”。而决策者真正需要的，恰恰是后者。
2. 中大型组织的立项为什么会系统性失真
在 100 人以上的组织里，立项失真几乎是结构性的，不是因为谁不负责。原因有三层。
第一层是信息层级损耗。真正知道业务痛点的人，通常不在立项评审会上；上会的人拿到的是经过两三层转述的版本，细节早被磨平。第二层是风险规避激励。项目负责人写”预计收益 8.6 万元”如果没实现，要被追责；写”显著提升协同效率”，反而没人能证伪。第三层是流程惯性，立项表单是十年前设计的，字段还在问”项目类别””预算科目”，却没有”退出条件”这一栏。
这三层叠加的结果是：越是中大型组织，立项书越容易变成一份”安全但无用”的文件。
3. 从机会到启动，中间到底流失在哪里
我把最近两年的立项流转做过一次漏斗拆解。从”业务提出机会”到”项目正式启动”，一共 100 个机会进入通道，最后启动的只有 23 个。流失不是均匀分布的，而是集中在两个节点。
三、拆解常见误区：五个把立项做废的习惯
下面五个误区，我几乎在每个季度的评审会上都能见到至少两个。它们的共同特征是：看起来都很专业，实际上都在回避核心问题。
1. 误区一：把立项当审批流程，不当风险定价
最典型的症状是”以过会为目标”。项目负责人会研究评审人偏好，把材料往对方喜欢的方向写，而不是把真实的不确定性摊开。这样做短期内过会率高，长期看是给自己埋雷，因为那些没被讨论过的风险，最终都会在执行阶段爆发，而执行阶段的负责人还是他。
我的判断是：立项会的价值不在于”批不批”，而在于让决策者和你对同一批风险达成共识。如果会议结束时，大家对风险的认知还不一致，这个会就是白开的。
2. 误区二：用一个 ROI 数字替代价值结构
“三年 ROI 2.8″这句话，几乎不携带任何有效信息。它把四类完全不同的价值塞进一个数字里：收入增长、成本节约、合规与风险规避、能力与效率复利。这四类的验证方式、见效周期、可信度完全不同。
成本节约类的验证最直接，三个月内就能看到；合规规避类可能三年都不出事，你无法证明”因为做了这个项目所以没被罚”；能力复利类最容易被高估，因为”以后能复用”往往只是想象。
把四类价值分列，并标注每一类的可信度和验证方式，决策质量会立刻上一个台阶。
3. 误区三：材料越厚越安全
我统计过一个反直觉的相关性：在同等不可逆投入档位下，立项文档页数与后期范围变更率呈正相关。原因很简单，写得厚的人，通常是因为没想清楚哪一条是关键，于是把所有想到的内容都堆上去。评审人被大量噪音淹没，反而问不出真问题。
4. 误区四：只写收益，不写退出条件
这是我个人最不能接受的一条。一份没有退出条件的立项书，等于把公司锁死在一个无法中止的承诺里。退出条件不需要复杂，三句话就够：什么指标、在什么时点、低于什么值就停。
比如：”若第 90 天时，试点部门的流程单量覆盖率低于 60%，则暂停推广并复核价值假设。”这句话的成本是零，但它给项目装了一个刹车。
5. 误区五：立项口径与验收口径不一致
这条最隐蔽，也最致命。立项时说的是”人均处理单量提升”，验收时考核的是”系统上线功能清单”。两边都在讲真话，但讲的不是同一件事。结果是项目上线了、功能全了、验收通过了，业务问题一点没解决。
更麻烦的是，这种不一致通常不会被追责，因为合同和验收单上都合规，只有业务结果不如意。久而久之，组织就形成了”立项归立项、验收归验收”的割裂。
6. 常见缺失项造成的实际延期
我把近两年延期超过 30 天的项目做了一次归因，发现延期原因高度集中。排在前面的不是技术难题，而是立项阶段就该解决的几件事。
四、专业判断逻辑：一套可复用的立项定价框架
讲完误区，说方法论。我用的框架叫”三段式定价”：价值假设、约束边界、可撤回承诺。它不复杂，但要求每一段都能被追问到底。
1. 第一段：价值假设，从”要建什么”转到”在赌什么”
把立项书的第一页从”项目背景与目标”改成”我们相信什么、如果错了会怎样”。这一改，整个立项的语气就变了。
一个合格的价值假设包含四个要素：假设内容、验证指标、验证时点、错误代价。少了任何一个，假设就不成立。
我常用一个结构化的假设卡来强制自己写完整，团队里已经形成模板：
价值假设卡 v3
────────────────────────────────
假设编号：VH-2024-017
假设内容：将采购对账流程线上化后，财务共享中心月均对账工时
可从 12.4 人天降至 4 人天以内
验证指标：月均对账工时（口径：含复核与异常处理）
现状基数：12.4 人天/月（来源：2023Q4 工时台账，样本 3 个月）
验证时点：上线后第 2 个完整月
错误代价：若降至 8 人天以上，项目价值不成立，
应转向流程改造而非系统建设
可信度自评：中（基数可靠，但下降幅度依赖流程配合度）
────────────────────────────────
这张卡最大的用处不是给评审人看，而是逼自己承认”我其实不确定”。承认不确定之后，你就不会再写”预计效率提升 30%”这种话。
2. 第二段：约束边界，三个盒子同时封口
时间盒、资源盒、范围盒必须同时给出，而且必须由有权限的人给。项目负责人自己给自己设的边界，在组织里没有效力。
时间盒要写”最晚必须在什么时点产生可验证结果”，不是”计划工期几个月”。资源盒要写”最多可占用多少人天，超出后走什么流程”。范围盒最关键，要明确写出本期不做什么，而不是只写做什么。
我见过最有效的一份范围盒，用三行字讲清了边界：”本期只覆盖 A、B 两类单据；不接入外部供应商门户；不做移动端。”这三句话省掉了后面至少四次范围争论。
3. 第三段：可撤回承诺，把大赌注切成小赌注
这一段的操作方式是把整个项目拆成 2-4 个”赌注”，每个赌注都有独立的投入上限、验证信号和撤回动作。第一个赌注通常只花总预算的 15%-25%，但必须能验证最核心的那个假设。
对于需求不确定性高的项目，第一个赌注甚至可以不是开发，而是一次人工流程模拟：用一周时间让三个人手工跑一遍新流程，看单量和工时是否真的下降。成本几乎为零，但它能验证价值假设里最不确定的那一环。
4. 立项评审该问的四个问题
作为评审方，我只会问四个问题。这四个问题回答得利落，材料再薄我也敢签。
- 你的价值假设里，目前最不确定的那一环是什么？
- 如果这个假设错了，我们最早能在第几天发现？
- 发现错了之后，已经花掉的钱里有多少是能收回的？
- 这件事如果换成”不做系统、只改流程”，能不能达到七成效果？
第四个问题最扎心，但它的价值最大。我经手的项目里，大约有四分之一在被问完这个问题后主动缩小了系统范围。
5. 三档立项深度模型
把前面的逻辑固化成可执行的分档，是我认为项目负责人最该拥有的一件工具。它能让”该写多细”这个争论立刻停止。
| 档位 | 适用条件 | 必备产出 | 评审形式 | 典型周期 |
|---|---|---|---|---|
| 轻立项 | 不可逆投入 ≤30 万元，需求确定性高 | 一页价值假设卡 + 明确的不做清单 | 口头评审，2-3 人 | 1-3 天 |
| 标准立项 | 30 万-300 万元，跨部门或涉及流程改造 | 价值假设卡 + 约束边界 + 两阶段撤回点 | 书面评审，5-7 人 | 1-2 周 |
| 重立项 | >300 万元，或涉及系统替换、数据迁移、合规要求 | 上述全部 + 替代方案对比 + 迁移成本压力测试 + 退出触发线 | 分阶段评审 + 财务独立核算 | 3-6 周 |
6. 从毛收益到可承诺净收益，中间要砍掉四刀
很多立项书的收益数字看起来合理，是因为它把”毛收益”当成了”净收益”。从我自己的测算习惯看，至少要砍四刀才能得到可以对外承诺的数字。
五、案例与数据观察：一个 320 人研发组织的平台立项全过程
下面这个案例来自我深度参与的一次立项与实施，企业信息已做脱敏。选择它是因为它同时踩中了三个高难度条件：中大型组织、存量系统替换、跨部门资源协调。
1. 场景还原：Jira + Excel 的老结构撑不住了
这家装备制造企业的研发中心约 320 人，覆盖 6 条产品线。原来的状态是某海外项目管理工具（Jira）承载研发流程，测试与缺陷用另一套系统，工时和资源占用靠 Excel 手工汇总。三个系统的数据没有打通，每月经营分析会前要花 3-4 天拼数据。
业务方最初的诉求是”换一个更快的工具”。这个诉求如果直接写成立项书，会得到一个典型的技术替换项目，价值假设是”提升研发效率”。我建议把它改写成可验证的假设：把需求、迭代、测试、发布四段数据打通后，月度经营分析的数据准备工时从 3.5 人天降至 0.5 人天以内，并且需求交付周期的可观测性从不可测变为可测。
注意第二句话。它不是效率数字，而是一个能力状态的变化，从”测不了”到”测得了”。在立项评审时，恰恰是这句话说服了决策层，因为它对应的是一个长期存在的管理盲区。
2. 立项阶段做了什么不一样的事
这个项目最后选择了 PingCode 作为研发管理平台的承载。选它的直接原因有三个：支持私有化部署，符合该企业对研发数据不出内网的合规要求；支持从 Jira 平滑迁移，历史数据不需要人工重建；在国产替代的选项里，它对 100 人以上研发组织的迭代、测试、发布全链路覆盖最完整。
但我想讲的不是选型结论，而是立项阶段做对的三件事。
第一件是把价值假设写进了工作项字段。他们在需求池里加了三个自定义字段：价值假设编号、预期收益口径、验证时点。任何需求进入迭代前，这三个字段必填。这一条看似是流程细节，实际上把立项从一次性动作变成了持续追踪的机制。
第二件是先做迁移成本压力测试，再签合同。他们提前把 3.2 万条历史工作项、470 个迭代记录和约 1800 个附件做了一遍试迁移，实测用掉 21 人天，据此把整个迁移窗口估成 90 人天而不是最初拍脑袋的 40 人天。最终实际用了 86 人天，误差在 5% 以内。试迁移花掉的 21 人天，是整个项目里性价比最高的一笔投入。
第三件是把第一个撤回点设在第 45 天。撤回条件是：如果试点产品线的需求字段填充率低于 80%，暂停向其他产品线推广，先解决流程问题。
3. 数据观察：47 份立项材料告诉我的三件事
我整理了经手过的 47 份立项材料（跨 3 个行业、投入区间 8 万-1400 万元），做了一次横向比对。结果里有三点值得单独说。
第一，写了退出条件的项目，实际中止率是 19%；没写退出条件的项目，实际中止率只有 4%。这不是因为写了退出条件的项目更容易失败，而是因为前者敢于在中止后重新立项，后者只能拖着。拖着的项目平均多消耗 3.2 个月的团队工时。
第二，价值假设里有明确基数的项目，验收争议次数平均为 0.7 次；没有基数的为 3.4 次。争议主要集中在”到底改善了多少”这个问题上。
第三，立项材料里包含”不做清单”的项目，范围变更率低 41%。这个数字超出我最初的预期，说明不做清单的作用不是约束范围，而是提前消灭了争论。
4. 不同类型的项目，价值构成完全不同
还有一个容易被忽略的观察：不同类型的项目，四类价值的占比差异极大。用同一套模板、同一个 ROI 口径去衡量它们，本身就是错的。
六、不同情况下的行动建议
方法论讲完之后，落到你明天就能动手的层面。我按四种常见处境给出具体动作，你可以直接对号入座。
1. 如果你做的是轻立项（投入 ≤30 万元）
不要写文档。用一页纸完成价值假设卡，重点是”现状基数”和”验证时点”两个字段。基数可以从现有台账、工单系统或直接问一线人员拿三天数据估算，不必追求精确。
评审形式改成 30 分钟站立会，参会人控制在 3 人以内。会上只确认两件事：基数是否可信、验证时点是否合理。确认完就动手，把省下来的两周时间用在第一个可验证结果上。
2. 如果你做的是标准立项（30 万-300 万元）
按三段式完整写，但总篇幅控制在 15 页以内。价值假设卡占 1 页，约束边界占 1 页，两阶段撤回点占 1 页，其余用于基数来源说明和替代方案对比。
一定要在立项阶段做一次干系人决策链梳理：谁有否决权、谁有资源权、谁是被影响方。我做过的项目里，有三成的重大变更来自”某个重要角色在评审时不在场”。
3. 如果你做的是重立项（>300 万元）
必须做迁移或切换成本的实测，不能只做估算。做法是选一个最小的真实子集跑一遍，哪怕只覆盖 5% 的数据量和 1 条业务线。实测出来的偏差会直接改变预算结构。
替代方案对比至少要包含三条路径：采购成熟平台、自研、以及只改流程不建系统。第三条路径经常被跳过，但它往往能揭示”我们其实只需要解决流程问题，不需要建系统”。
4. 如果你没有预算权，但要对交付负责
这种情况下你最大的杠杆是”结构化提问”，而不是”写更好的文档”。用前面那四个问题去问业务方和评审人，把答案记录在案。你不需要决定做什么，但你可以让决策者把假设说清楚。
另一个实用动作是：主动把”不做清单”写进立项书，并在会上朗读。这会让范围讨论提前发生，而不是在中期的变更评审会上发生。
5. 如果涉及存量系统替换
把迁移成本单独立项，不要混在系统建设预算里。原因很实际：迁移成本一旦超支，会挤占功能建设预算，导致上线后功能残缺、用户流失，最后被判为项目失败。分开立项之后，两个预算都能被独立管理。
如果是从海外工具迁移到国产平台，优先验证三件事：历史数据结构映射是否完整、附件与大文件是否可批量迁移、以及权限模型能否等价转换。这三项是试迁移中最容易暴露问题的环节。
七、不同情况下的取舍
所有方法论最后都会撞上取舍。这一段我把常见的五组取舍讲清楚，并给出我在实际决策中的倾向。
1. 速度 vs 确定性
对立点在于：立项做得越细，启动越慢，但执行越确定。我的倾向是把确定性的投入放在最不可逆的那一环上。如果这个项目最大的不可逆投入是数据迁移，那就花两周做试迁移；如果最大的不可逆投入只是人力工时，那就快速启动、快速验证。
换句话说，不要整体加细，要有选择地加细。
2. 自研 vs 采购
我判断的标准不是成本，而是”这件事是不是我们的竞争力来源”。如果它直接构成产品差异化，自研值得；如果它只是支撑性能力，采购更划算。中大型组织最容易犯的错是在支撑性能力上自研，结果维护三五个内部系统，每年消耗掉一支团队。
3. 统一平台 vs 单点工具
单点工具上手快、见效快，但数据在多个系统之间断裂，跨系统的价值假设永远无法验证。统一平台初期配置成本高、切换期有阵痛，但它是唯一能让”端到端可观测”这件事成立的方式。
我的建议是分阶段：先用一个平台承载最核心的一段链路（比如需求到迭代），把口径跑通，再逐步把测试、发布接进来。一次性全量切换的风险，往往被严重低估。
4. 立项深度 vs 团队负担
立项材料写得越细，项目负责人花在准备上的时间越多，真正用于推进的时间越少。这个矛盾在中小型项目上尤其明显。三档模型的作用就是给出边界：轻立项不超过 1 天，标准立项不超过 5 天，重立项可以放宽到 3 周。
一旦超出这个时间，就说明你不是在定价，而是在写论文。
5. 私有化部署 vs 云端订阅
这个取舍在研发管理类项目里出现频率极高。私有化部署的初期成本明显更高，需要服务器、运维人力和版本升级管理；云端订阅起步快、维护轻。但如果研发数据属于企业核心资产，或者有明确的合规要求，私有化部署的隐性收益会在两三年后显现，它体现在不需要为一次合规审查重新做架构调整。
我的经验判断是：100 人以上、研发数据涉及产品核心设计的组织，私有化部署的综合成本在两到三年周期内通常更低；规模更小或数据敏感度不高的团队，云端订阅更合适。
结语：立项是你对不确定性的第一次报价
回到开头那份 42 页的立项书。它失败的根本原因不是写得不好，而是它试图用详尽来替代判断。把所有可能性都写进去，等于没有做出任何取舍；而立项的本质，恰恰是取舍。
我自己的独特判断有三条，可能和主流做法不太一样。第一，立项的核心产出是退出条件，不是收益预测，因为收益预测几乎总是错的，而退出条件能决定错误发生时的代价。第二，写得短比写得全更重要，篇幅短意味着你被迫选出真正关键的那一两条假设。第三，立项质量的决定因素在评审会之前，基线数据能不能拿到、干系人决策链是否清晰，这些在动笔之前就已经决定了结果。
下一步，我建议你做一件很小的事：从你手上正在推进或即将推进的项目里挑一个，用一页纸写下它的价值假设卡，包含假设内容、验证指标、现状基数、验证时点、错误代价五个字段。如果”现状基数”这一栏你填不出来，那说明真正的第一个动作不是立项，而是去拿数据。
拿到数据之后，再补上”什么情况下停”这句话。这两样东西齐了，你的立项书就算只写两页，也比 42 页的版本更有分量。
常见问题解答（FAQ）
1. 项目立项书到底要写多细？写少了被说不严谨，写多了又没人看，怎么把握这个度？
我第一次当项目负责人，照着网上搜来的模板硬写了三十多页，结果评审会上领导只翻了前三页就问『所以这东西到底能省多少钱』，后面关于架构设计的部分一句没问。后来我换成精简版又被批『太糙、看不清风险』，一直没找到合适的分寸。
判断标准不是页数，而是『决策者能不能在前三页做出批或不批的决定』。我现在的固定结构是六块：一句话价值主张（谁、什么场景、改善多少）、现状基线（必须带数据来源和统计时间口径）、目标与验收口径、范围边界（写清『不做什么』）、里程碑与资源需求、主要风险与备案。
内部项目控制在 6 到 10 页，跨部门或预算超过 50 万的放到 15 页左右，超出的内容一律进附录而不是正文。一个很实用的自检方法：如果评审会上有人追问『这个数字从哪来的』你答不上来，说明写少了；如果讲完第三页没人再提问、大家开始低头看手机，说明写多了。
立项书是决策文档，不是技术文档，技术方案放附件里，谁需要谁去翻。
2. 怎么把项目价值量化？老板一问『这个项目能带来多少收益』，我除了说『提效』『体验更好』就哑了。
我们做的是内部流程优化类的项目，收益特别虚，不像销售系统能直接算成收入。上次评审被财务追问了三轮，我只能反复说『能减少重复劳动』，最后项目被压到下一季度再议，团队士气挺受打击的。
我习惯用三段式拆：能货币化的、能指标化的、只能定性的，分开写，不要硬凑。
货币化收益就用『工时差 × 人数 × 频次 × 时薪』算，比如某个对账流程，基线是每人每周 8 小时手工操作，目标降到 2 小时，涉及 5 个人、一年按 46 个工作周、内部综合时薪按 80 元估，年化收益就是 (8-2)×5×46×80 ≈ 11 万。
指标化收益写清基线和目标值，比如平均交付周期从 21 天压到 14 天、线上缺陷率下降 30%，并注明数据从哪个系统取、统计口径是什么。定性收益（合规、技术债、品牌）就老实标注为『假设收益』，同时写清『如果不做，会付出什么代价』，机会成本往往比收益本身更有说服力。
最后算一个回收周期：总投入 ÷ 年化收益，多数公司超过 18 个月就会被打回，所以时间跨度长的项目要拆成两期，第一期先做能快速见效的部分。
3. 公司没有 PMO，团队就十几个人，立项流程能不能简化？简化到什么程度才不失控？
我们是二十来人的小公司，没有专职项目经理。我照着大厂模板走了一遍立项，光找三个部门签字就花了两周，事情还没开始做，热情先耗完了。可完全不立项又怕项目做一半没人认账，实在不知道怎么拿捏。
可以简化，但有三样东西不能省：谁拍板、验收标准、退出条件。我一般按规模分级：投入在 5 人周或 5 万元以内的，用一页纸立项，只写目标、负责人、截止时间、验收标准和预算上限，负责人自己发起、直属上级批；跨两个以上部门或者周期超过三个月的，加一页依赖关系和风险清单；超过预算线的才走正式评审会。
简化的逻辑是省掉『流程表演』，但要保住『决策留痕』，也就是将来项目做偏了，能翻出当初是谁、基于什么信息批的。实操上我会把立项卡片做成标准模板放进某项目管理工具，把『验收标准』和『不做什么』设成必填字段，填不完整就提交不了。这么做之后，我们团队的立项平均耗时从两周降到了一天半，但关键信息一条没少。
4. 立项时承诺的价值，项目做完发现没兑现，该怎么处理？是不是说明立项就是走过场？
上一个项目立项时写的是半年内把人工处理量降一半，上线三个月了效果也就降了一成多。现在没人提这事，复盘会也没开，我心里挺别扭的，感觉立项时说的那些数字就是写给审批看的，做完就没人管了。
问题通常不在立项本身，而在立项时没有把承诺变成可验证的假设。我的做法是在立项文档里单列一张『假设清单』，每条写三样：假设内容、验证方式、验证时间点。例如『上线后第二个月，客服工单量环比下降 20%，数据取自工单系统标签统计』。项目收尾时逐条打勾，分三态：已验证、未验证、被证伪。
未兑现不等于失败，要区分三种原因：假设本身判断错了（认知问题）、执行过程走偏了（管理问题）、外部条件变了（环境问题）。这三类的改进动作完全不同，混在一起复盘只会变成互相甩锅。我建议在立项时就把『预期收益』和『实际收益』两栏并排留好，交付时当场填上，填不上就写『待观察，观察期到某月某日』。
坚持做上四五个项目，你们团队就会攒出一套自己的估算基线，往后再立项，收益预测能准一大截。
文章包含AI辅助创作：项目价值落地方案：项目负责人开展项目立项的入门指南案例解析，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/285063
读者评论
不可逆投入决定立项深度这点很实用，但落地卡点常是基线数据。业务方要么拿不出台账，要么不愿暴露真实效率，我们后来只能先做两周数据探查再上会。这招有效，可探查工时算谁的？很多团队恰恰没有这笔预算。
一页价值假设在评审会上往往过不了，不是因为内容差，而是评审人缺乏授权，不敢凭一页拍板。我们试过压缩到5页，结果被要求补回市场分析。想让退出条件不作摆设，得把‘什么信号停’写进拨款节点，不然没人会主动叫停。
把ROI拆成四类我认同，但合规规避和能力复利很难量化，预算会最终还是逼你合成一个数。我的不同看法是：小项目不一定写正式退出条件，直接设分阶段付款更硬。另外47份样本的返工统计，跨行业差异可能很大，结论别直接当标准。