立项管理指南：项目负责人如何做好项目立项，最佳实践全流程

两年前我接手过一个已经”立项通过”的项目：立项报告 38 页，预算 420 万，计划 6 个月交付。第 5 个月的时候，实际支出已经到 390 万，而可交付范围只剩下当初承诺的六成。复盘会上所有人都在讨论执行问题，排期太紧、人手不够、需求反复改。但我把立项那天的材料重新翻出来看了一遍，发现真正的问题在第一天就写进去了：报告里没有一个可以被证伪的假设，没有一条写清楚”什么情况下该停”，也没有任何一个人名对应到具体的资源承诺。

这件事改变了我做项目立项的方式。后来我给制造业、零售、SaaS 三类客户做过立项流程的改造，也自己带过从 0 到 1 的产品线。这篇文章不讲立项模板长什么样，而是讲一个项目负责人在立项阶段到底应该判断什么、交付什么、以及在不同约束下怎么取舍。如果你正在准备一份立项材料，或者正被要求”快点把立项过了”，下面的内容应该能帮你少走两年弯路。

一、先说结论：立项是拿假设换资源，不是拿文档换签字

我把立项的本质压缩成一句话：项目负责人用一组可验证的假设，向组织换取一段有边界的资源使用权。这句话里有三个关键词，可验证、有边界、使用权。大多数失败的立项，都是在这三个词上偷了懒。

“可验证”意味着你写下的每一个关键判断，都要能被后续事实推翻。比如”上线后客服工单量下降 30%”，这就是可验证的；”提升客户体验，增强竞争力”就不是。前者在三个月后能给出一个红或绿，后者永远只能靠感觉争论。

“有边界”意味着资源要有上限和期限。批准 300 万人天、无期限投入的项目，本质上不是立项，是把一个不确定性永久地塞进组织预算里。”使用权”则意味着资源是借给你的，不是给你的，到期要归还、要交接、要复盘。

1. 我判断一个立项是否合格，只问五个问题

不管项目大小，我现在都只问五个问题。如果一个立项材料能把这五个问题回答清楚，它的质量就已经超过我见过的大多数正式报告。

1. 这个项目对应组织哪一个具体目标？不是”战略方向”，而是能落到季度 OKR 或年度经营指标上的那一条。
2. 最小可验证的价值单元是什么？也就是花最少的钱、最短的时间，能验证核心假设的那个版本。
3. 资源清单上写了谁的名字？人天、预算、以及最关键的一项，决策权，分别归谁。
4. 最坏情况是什么，我们能不能承受？如果答案是”不能承受”，那这个项目的风险定价就是错的。
5. 什么信号出现时，我们停、缩或者转？没有退出条件的项目，等于没有刹车。

这五个问题听起来朴素，但你去看真实的立项材料，能同时答清楚的可能不到三成。最常见的缺失项是第四和第五个，因为讨论风险和退出，在立项会上是不讨喜的。

2. 漂亮的立项报告，往往是最危险的信号

这里说一个反常识的判断：当我看到一份 40 页、图表精美、逻辑闭环、几乎挑不出毛病的立项报告时，我的第一反应是警惕，而不是欣赏。因为真实的前期项目一定充满不确定性，一份没有”我不知道”的报告，通常意味着写作者把不确定性藏起来了。

我做过一个小范围的统计：在我参与评审的 60 多个立项材料里，页数在 20 页以上的项目，其后续预算偏差（实际支出相对批准预算的偏离）平均是页数 5 页以下项目的 2.3 倍。这个样本不大，也不够严谨，但方向很稳定，文档厚度和项目确定性之间，基本没有正相关，反而常常负相关。因为写厚文档需要时间，而时间本该花在找用户、问数据、试原型上。

更实际的问题是：厚文档会把讨论焦点从”这个项目该不该做”转移到”这个文档写得对不对”。评审会一旦变成文档批改会，决策质量就开始下滑。

3. 项目负责人在立项阶段真正要交付的三样东西

把立项的产出重新定义一下，我认为项目负责人在这阶段只需要交付三样东西，全部可以是一页纸：

• 假设卡：3 到 5 条核心假设，每条都写明判断标准、验证方式和验证时点。
• 资源承诺清单：人、钱、决策权，每项都有具名负责人和有效期限。
• 退出条件表：什么指标跌到什么位置就停，什么情况下降级为小范围试点。

这三样东西加起来通常不超过两页。剩下的市场分析、竞品调研、技术方案，都可以作为附件存在，但决策依据必须是这两页。我在一家零售企业推行这个做法后，立项会的平均时长从 90 分钟压缩到 35 分钟，而决定”不做”的比例从 8% 上升到 27%，后面这个数字才是真正有价值的，说明评审开始真的在筛项目，而不是盖章。

二、真实场景：我在立项上踩过的三个坑

下面这三个坑我都亲自踩过，代价分别是 4 个月、80 万和一次团队信任危机。写出来不是自我检讨，而是因为它们在项目负责人的成长路径上出现频率极高，而且往往以”正确做法”的面目出现。

1. 坑一：把”领导提的想法”当成”已经验证的需求”

当年一位业务副总在会上说”客户反映对账太麻烦”，我立刻把它当成需求写进了立项书，还配了一套看起来很完整的业务流程设计。项目做到第三个月，我们走访了 12 家客户，发现真正抱怨对账的只有 2 家，而且痛点集中在月末三天，其余时间影响很小。

问题不在于领导说错了，而在于我把一句高层观察直接翻译成了全量建设需求，跳过了”这个问题有多普遍、多痛、多大代价”的验证。高层看到的通常是信号，而不是结论。项目负责人的职责是把信号变成证据，而不是把信号当结论执行。

后来我的做法是：任何来自高层的需求，进立项材料前必须补一条”信号来源”字段，写清楚这个判断来自多少人、什么场景、多高频率。如果只能写”领导觉得”，那就先做一个为期两周的验证动作，而不是直接立项。

2. 坑二：把口头承诺当成资源锁定

立项会上，技术负责人说”我这边可以支持 3 个人，两个月”。我把它写进了资源计划，然后项目启动第二周，实际到位 1 个人，还是兼职的。因为那位技术负责人同期接了另一个更高优先级的项目，而这件事在立项会上没有任何人提。

这就是典型的资源幻觉。立项会上的资源承诺，如果没有落到具名、具时、具量的清单上，并在有权限的人那里备案，它就不是承诺，是礼貌。我后来强制要求资源清单必须写三个字段：姓名、投入比例、开始与结束日期。写不出姓名，就默认这个人不存在。

这个要求一开始让立项流程变得”麻烦”，但它把冲突从执行期提前到了立项期。冲突不会消失，只会转移，转移到立项期，成本低得多。

3. 坑三：没有退出条件，项目变成一辆没有刹车的车

第三个坑最贵。一个探索型项目，做到第 7 个月，核心假设已经被证伪了两次，但因为立项书上写的是”12 个月内完成平台上线”，团队还在按原计划推进。没有人提出停止，因为停止意味着承认前面 7 个月的投入打了水漂。

这就是沉没成本在组织层面的典型表现。如果立项时没有约定”什么情况下停”，那么项目在心理上就是不可停止的，哪怕事实已经很清楚。后来我在所有立项材料里加了一张退出条件表，明确写：如果三个月后核心指标低于 X，项目降级为为期 4 周的验证性试点；如果六个月后仍低于 X，项目关闭并输出复盘。

有意思的是，加了退出条件之后，项目被真正叫停的比例并没有上升多少，但项目组在早期调整方案的速度明显变快了。因为”停”成了一个合法选项，团队反而敢早点说真话。

三、拆解六个看起来很专业的立项误区

下面这六个误区有个共同特点：它们在表面上都显得很专业、很规范，甚至是被写进很多管理教材里的做法。但它们在中大型组织的真实环境里，往往会产生相反的效果。

1. 误区一：把立项等同于写文档

立项的核心动作是判断和承诺，文档只是载体。我见过一个团队为了立项材料做了 6 轮修改，前后花了 5 周，而这 5 周里他们没有和任何一个真实用户聊过。

更值得警惕的是，文档写作能力会变成一种隐性筛选机制，谁擅长写材料，谁更容易拿到资源。这对那些真正懂业务但不擅长表达的负责人是不公平的，对组织也是损失。我的应对方式是把立项材料的格式限制在两页以内，剩下的口头讲、当面问。

2. 误区二：ROI 算得越精细越好

很多立项书会把投资回报算到小数点后两位，看起来非常严谨。但前提假设如果本身是靠猜的，精细的计算只会产生”精度错觉”，让评审者误以为风险已经被量化了。

我在评审时更看重的是敏感度分析：如果收益只有预期的一半，这个项目还值不值得做？如果答案是”不值得”，那这个项目的安全边际就很薄，需要更短的验证周期和更明确的退出条件，而不是更精确的 ROI。

3. 误区三：要求立项阶段消除所有不确定性

有些组织的评审会不断追问”这个风险怎么解决”，直到申请人给出一个看起来确定的答案。结果是，申请人学会了用确定性的语言包装不确定性，这比坦诚承认风险危险得多。

正确的做法是区分两类不确定性：可以通过预研消除的（比如技术可行性、数据可得性），和只能通过执行暴露的（比如用户接受度、组织配合度）。前者要求立项前解决，后者要求在立项材料里写明”我们打算在什么时间、用什么方式暴露它”。

4. 误区四：立项评审变成答辩表演

当评审的焦点变成”申请人能不能扛住提问”，立项会就退化成了答辩表演。准备充分的团队拿到资源，准备不足的好项目被否掉，这是典型的评价指标错位。

我的建议是改变评审的提问方式：少问”你凭什么认为能成”，多问”如果不成，会先从哪里露出破绽”。后一个问题更难伪装，也更容易暴露材料的真实质量。

5. 误区五：只对齐高层，不对齐执行层

立项通过之后，真正干活的人往往是第一次听说这个项目。他们不理解目标来源，也不认同优先级，于是执行阶段的配合度就成了最大变量。

我在项目启动前会强制做一件事：在立项批准后的 5 个工作日内，和每一个被写进资源清单的人单独聊 15 分钟。不是分配任务，而是确认三件事，你是否知道这个项目要做到什么、你这段投入是否会和你现有工作冲突、你觉得最大的障碍是什么。这三句话能提前暴露八成的执行风险。

6. 误区六：只立不结，组织不积累立项判断力

大多数组织有立项流程，但没有结项回填。项目做完就散了，当初写的假设对不对、估算偏了多少、哪个门槛判断失误，没人系统记录。结果是同一个错误每年重复犯。

我的做法是在项目结项时强制填一张”假设回填表”，把立项时的每条假设逐条标注为已验证、已证伪或未验证，并说明原因。这些表积累两三年之后，就成了组织最值钱的资产，它可以校准未来所有项目的估算和判断。

四、专业判断逻辑：五道门槛与一套打分结构

前面讲了误区，这一节讲我实际使用的判断工具。它的核心不是打分，而是门槛，即某些条件不满足就直接不立项，无论总分多高。这一点很关键，因为很多组织的评分表是可以互相补偿的：战略价值高就能掩盖资源不足。但在真实项目里，资源不足是不会被战略价值补偿的，它只会变成延期。

1. 门槛一：战略对齐，必须能追溯到具体目标

我要求立项材料写出一句具体的话：”本项目支撑 XX 部门 20XX 年第 X 季度的 YY 指标，目标是从 A 提升到 B。”如果这句话写不出来，说明项目还停留在”感觉有价值”的阶段。

这里有个执行细节：追溯的目标必须是可量化的经营或产品指标，而不是战略口号。“提升数字化水平”不是目标，”把订单履约周期从 9 天压缩到 6 天”才是。前者无法判断项目是否成功，后者可以。

2. 门槛二：价值可验证，必须有最小验证单元

这一条要求回答：”用最小的代价，多快能验证核心假设？”对于软件类项目，答案通常是 4 到 8 周的一个可用版本；对于流程改造类项目，可能是 2 到 3 家试点门店。

我在实践中发现，能清晰描述最小验证单元的项目，其后续预算偏差平均比描述不清的项目低 20 个百分点以上。因为最小验证单元会强制项目负责人想清楚”什么才是真正需要被证明的那件事”。

3. 门槛三：资源可得，人钱权三样都要具名

资源清单必须包含三项，缺一不可：人力（姓名、比例、起止时间）、预算（金额、科目、可调整范围）、决策权（谁能在什么范围内拍板变更）。

第三项最容易被忽略，但它的缺失造成的返工最多。一个没有变更决策权的项目负责人，会在每一个小变更上等待审批，等待的时间成本往往超过变更本身。我一般要求在立项时就明确：预算 10% 以内的调整由项目负责人决定，超过 10% 走变更评审。

4. 门槛四：风险可托底，看最坏情况能不能承受

我不用”风险高低”来评判项目，而用”最坏情况是否可承受”。一个风险很高的项目，如果最坏情况只是损失 3 个人月，那它值得做；一个风险看似很低的项目，如果最坏情况是核心系统停机，那它需要更重的评审。

实操方法是做一次”失败推演”：假设项目彻底失败，损失是什么，谁来承担，会不会影响其他业务。如果失败推演的结果是”公司会受重创”，那么这个项目的立项标准应该提高一个等级，而不是简单地评为高风险。

5. 门槛五：退出可定义，写清楚停、缩、转的条件

退出条件一般写三条就够：什么情况下缩小范围、什么情况下转为试点、什么情况下直接停止。每条都要有可观测的指标和判断时点。

举个例子：某内部工具项目约定，上线 8 周后如果周活跃率低于目标用户的 40%，则停止二期投入，转为维护模式。这条约定后来真的触发了，项目转为维护，省下了大约 4 个人月的投入。如果没有这条约定，二期投入大概率会照常发生。

6. 打分结构与权重怎么定

门槛之外，我会用一张简单的打分表做排序，用于在多个候选项目之间分配有限资源。权重设置的原则是：越靠后、越难在事后补救的因素，权重越高。资源可得性和退出条件属于事后极难补救的，所以权重最高。

gate_check:
project: 智能排产系统二期

sponsor: 制造运营副总

五道门槛：任一项为 false，则不予立项

gates:

strategy_alignment: true # 对应：履约周期 9 天 -> 6 天

value_verifiable: true # 最小验证单元：1 条产线，8 周

resource_locked: true # 具名 3 人，比例 60%，6 个月

risk_containable: true # 最坏情况：延期不超 6 周，不停线

exit_defined: true # 8 周活跃率 < 40% 即转维护

打分仅用于多项目排序，权重越高越难事后补救

scoring:

resource_certainty: 0.30

exit_clarity: 0.25

value_verifiability: 0.20

strategy_alignment: 0.15

risk_containment: 0.10

outcome: approve

这个结构看起来有点像代码配置，但它其实可以直接做成一张表格。我坚持用结构化格式，是因为它强迫作者把”是/否”写清楚，而不是用”基本可行””风险可控”这类模糊表达蒙混过去。

五、案例与数据观察：一家 800 人制造企业的立项改造

下面这个案例来自我 2023 年参与的一个咨询项目，客户是华东一家约 800 人的装备制造企业，研发中心 260 人，同时并行的研发项目常年有 30 多个。他们的痛点和很多中大型组织一样：立项会开不完、资源永远不够分、项目做一半发现方向不对又不敢停。

1. 改造前的立项是什么样

改造前，他们的立项流程是：部门提报 → 研发中心汇总 → 每月一次立项评审会 → 总经理拍板。立项材料是一份统一的 Word 模板，包含背景、目标、方案、预算、计划、风险六个部分，平均篇幅 25 页左右。

问题出在三个地方：一是评审会一次要过 8 到 12 个项目，每个项目分到 15 分钟，根本讨论不深；二是材料里的目标基本是定性描述，比如”提升生产协同效率”；三是所有项目一旦批准，就默认做到完成为止，没有任何中途调整机制。结果就是资源被摊薄，每个项目都缺人，同时没有项目被叫停。

2. 我们做了三步改造

第一步是压缩材料。把 25 页模板改成两页决策摘要加附件，摘要必须包含假设卡、资源清单、退出条件三项。这一步最大的阻力来自中层管理者，他们的顾虑是”材料太薄显得不专业”。我们用了一个办法化解：先在两个部门试点三个月，用数据说话。

第二步是改评审机制。把每月一次的大型评审会拆成”预研过滤 + 决策会”两层。预研过滤由技术负责人和业务负责人两人完成，只判断”假设是否可验证、资源是否能落地”，不判断价值；决策会只讨论通过过滤的项目，每个项目 30 分钟。这样改动之后，决策会的项目数量从平均 10 个降到 3 到 4 个，讨论深度完全不同了。

第三步是引入结项回填。每个项目结项时必须提交假设回填表，逐条标注假设的验证结果。第一年积累下来的 40 多张回填表，成了他们调整立项标准的主要依据。

3. 平台工具在其中的位置

流程改造到第三个月的时候，他们遇到一个现实问题：立项材料和后续执行数据是断开的。立项时写下的假设、里程碑、资源分配，在项目执行过程中散落在邮件、微信群和各类文档里，到了结项时没人能快速还原当初的约定。

他们最终选择用 PingCode 来承接这段链路，我参与了选型讨论。原因有三个：一是这家企业的研发团队规模在 260 人左右，属于中大型组织，对权限体系、项目集管理、跨部门协同的要求比较高，而 PingCode 主要服务的就是中大型企业及 100 人以上组织，功能密度对得上；二是他们集团层面有数据不出内网的要求，PingCode 支持私有化部署，这一点是硬门槛；三是他们原来有一部分团队在用 Jira，PingCode 支持 Jira 平滑迁移，历史项目和缺陷数据可以保留，避免了”换工具等于数据归零”的风险。

在实际使用上，他们把立项摘要里的假设卡做成了项目目标，把资源清单做成了成员与工时配置，把退出条件做成了里程碑上的检查点。这样做的直接好处是：立项阶段写下的约定，在执行过程中是活的、可追踪的，而不是躺在某个文件夹里的文档。结项时，假设回填表可以直接从系统里的目标完成情况和工时数据中提取，不再依赖回忆。

这里也顺便说一句我对国产替代的看法。这两年很多中大型组织在评估工具替换，我的判断标准很简单：不是看功能列表谁更长，而是看迁移成本和数据归属。对于已经在使用海外项目管理工具、又需要满足内网部署要求的组织，能平滑迁移、又能本地部署的方案，通常是更现实的选择。至于同类产品之间的取舍，我一般建议先做一轮 2 周的实际试用，用真实项目跑一遍立项到结项的完整链路，再决定。

4. 改造一年后观察到的四个数字

下面是他们内部复盘时给出的口径，我做了脱敏处理，数值为区间化的示意值，不代表精确统计：

• 立项评审平均耗时：从 21 天降到 9 天。主要来自预研过滤层的引入，大量不合格的立项在预研阶段就被挡回去了。
• 评审一次通过率：从 34% 提升到 71%。这个数字上升不是因为标准放松，而是因为材料结构变了，决策所需信息更集中。
• 立项后 8 周内的需求变更率：从 46% 降到 19%。假设卡和最小验证单元起了主要作用，前期把方向性错误提前暴露了。
• 预算偏差率：从 +38% 收敛到 +11%。退出条件和资源锁定共同作用的结果，重要的是偏差方向变得可控了。

需要说明的是，这四个数字是流程改造、工具承接和组织配合共同作用的结果，不能单独归因于任何一项。但它们至少说明一件事：立项阶段的管理投入，是能转化为可量化收益的，而且回报周期通常在 6 到 12 个月内。

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

前面讲的是一套通用逻辑，但真实组织差异很大。同一套立项方法，放在 20 人团队和 1000 人组织里，执行方式完全不同。下面按四种常见情境给出可落地的建议。

1. 如果你是 20 人以下的小团队

小团队不需要完整的立项流程，但必须有假设卡。我建议小团队把立项压缩成 30 分钟的一次对话，产出一页纸，包含三条假设和一个验证时点。不要写市场分析，不要做三年规划，小团队最稀缺的是时间，最需要的是快速证伪。

具体的做法是：每周固定一次 30 分钟的立项对话，任何人可以提，提的人自己写假设卡。如果 30 分钟内说不清楚要验证什么，那就不立项，先去搞清楚。

2. 如果你是 100 到 500 人的中大型组织

这个规模的组织最需要的是”分层过滤”，因为项目数量和资源矛盾同时达到峰值。我的建议是必做三件事：两页限制的决策摘要、预研过滤层、结项回填机制。

在这三件事里，如果只能先做一件，我会选结项回填。因为它成本最低（一张表），但对组织判断力的积累效果最持久。很多组织卡在”每次都从头讨论”，本质原因就是没有历史数据校准直觉。

工具层面，这个规模区间的组织往往已经开始出现跨部门资源冲突和多项目并行，靠表格和文档难以支撑。把立项摘要与执行链路放在同一个平台上，是降低协调成本最直接的方式。这也是我看到不少中大型企业倾向于选择支持私有化部署的项目管理平台的原因，数据在内网、历史可追溯、迁移成本可控。

3. 如果你在强监管或合规行业

监管行业的立项不能简化到两页，因为合规材料本身是交付物的一部分。但我建议做一件事：把”决策依据”和”合规材料”分开。合规材料按监管要求完整准备，决策依据仍然压缩到两页，评审会只讨论决策依据。

另一个建议是把合规要求前置到门槛判断里。比如数据出境、个人信息处理、行业审批这类约束，必须在立项前确认清楚，而不是在执行阶段发现方案不可行。

4. 如果你是中途接盘的项目负责人

接盘项目最大的问题是当初的立项逻辑你不知道，但你要承担结果。我的做法是补做一次”事后立项”：用两页纸重新写一遍假设卡和资源清单，然后拿着它去找当初的批准人确认，如果对方点头，说明你的理解是对的；如果对方说”不完全是”，那这次对话的价值极高。

同时要立刻做一次退出条件的补签。接盘项目如果没有退出条件，你会成为唯一为沉没成本负责的人。

七、四组取舍：立项管理没有标准答案

做了这么多个项目之后，我越来越确信立项管理的关键不是找到”最佳实践”，而是理解每组权衡的两端分别在什么条件下成立。下面四组取舍是我被问得最多的。

1. 速度与严谨，怎么取舍

这个问题没有通用答案，但有一个判断依据：试错成本的高低。如果做错的代价是几千元和一个月的返工，那么速度优先；如果做错的代价是核心系统重构或者客户流失，那么严谨优先。

我的经验法则是：把项目分成”可逆决策”和”不可逆决策”两类。可逆的走轻流程，两周内必须有结论；不可逆的走重流程，但重的是验证，不是文档。很多组织搞反了，在可逆的小事上反复评审，在不可逆的大事上凭感觉拍板。

2. 详细估算与区间估算，怎么取舍

我的建议是用区间估算代替点估算，并且标注置信度。比如”预计 80 到 120 人天，其中 120 天以上的可能性约 20%”，这比”预计 95 人天”有用得多。

点估算的问题不在于不准，而在于它隐藏了波动范围，导致后续的资源规划缺少弹性。区间估算虽然看起来不够”精确”，但它给出了真实的决策空间。我给团队的要求是：任何估算都必须给出上下限，并且说明上限在什么情况下会发生。

3. 统一模板与差异化流程，怎么取舍

统一模板的好处是降低沟通成本，坏处是它会诱导所有人按同一套逻辑思考，而不同类型的项目需要的逻辑并不相同。我的做法是统一决策要素，不统一文档格式。

也就是说，不管是产品项目、技术改造还是流程优化，统一要求回答五道门槛；但材料形式可以是两页纸、流程图或者一次口头汇报。这样既保证了判断标准一致，又给了不同项目表达空间。

4. 采购成熟平台与自建工具，怎么取舍

这个取舍在立项管理场景里经常被提起，因为立项数据和执行数据需要打通。我的判断标准有三条：第一，你的核心需求是不是项目管理本身。如果不是，自建的成本会被长期低估；第二，是否有数据部署的硬约束。如果有，那么支持私有化部署的方案会成为前提条件；第三，迁移成本有多高。如果历史数据需要保留，那么是否支持从现有工具平滑迁移，往往比功能列表的差异更影响最终体验。

在现实中，我看到更多中大型组织选择采购成熟平台，然后把省下来的精力放在流程设计上。因为流程设计才是真正产生差异的地方，工具只是承载。

八、下一步：两周内可以做完的四件事

如果你读到这里，最有价值的动作不是把文章收藏起来，而是在接下来的两周里做四件具体的事。这四件事我都在不同组织里推过，最短的两周就能看到变化。

1. 第一周：把下一个立项压缩成两页

找出你手上正在准备的立项材料，不管已经写了多少页，重新写一份两页的决策摘要，只包含三部分：三条核心假设（含判断标准和验证时点）、资源清单（姓名、比例、起止时间）、退出条件（三条）。

写完之后对照一下，如果发现有些关键信息写不进去，说明这些信息本来就不是决策必需的，它们应该放在附件里。

2. 第一周：给现有项目补一次资源具名确认

挑出你正在带的项目，把资源清单拿出来，逐个确认被写进去的人是否知道自己的投入比例和时间段。我几乎可以保证，你会在这个动作里发现至少 2 到 3 个不一致的地方。

这个动作的成本是两小时，收益是避免几周的等待和返工。发现不一致之后，不要私下协调，要走一次正式的确认，把调整后的承诺记录下来。

3. 第二周：为每个在跑项目补一条退出条件

不管项目已经跑了多久，都可以补。补的方式是问三个问题：什么指标跌到什么水平我们会缩小范围？什么情况下会转为试点？什么情况下会直接停止？把答案写下来，发给项目批准人确认。

很多项目负责人担心提退出条件会被认为”没信心”。我的经验恰恰相反：主动提出退出条件的负责人，往往被认为更可靠，因为他展示了对风险的掌控感。

4. 第二周：建立一张最小的假设回填表

找一张表格工具，建立六个字段：项目名、假设内容、验证方式、验证时点、验证结果、偏差原因。然后把它加入结项流程，从下一个结项的项目开始填。

这张表的价值不会在第一个月显现，但一年之后，它会成为你做立项判断时最有说服力的依据。到那时候你会发现，很多曾经靠直觉争论的问题，已经有了答案。

回到最开始那句话：立项是拿假设换资源，而不是拿文档换签字。一个项目负责人真正的专业能力，不在于能把立项材料写得多完整，而在于能把不确定性拆解得足够清楚，让组织在信息更充分的情况下做出决策。这件事做一次不难，难的是每次都做。而只要你开始做，你就已经在大多数项目负责人之前了。