项目申请怎么做？项目负责人最佳实践：项目立项从0到1

去年我帮一家 300 人规模的制造企业做研发管理复盘，翻到一份被驳回三次的立项申请。第一版 47 页，第二版 32 页，第三版 18 页，第四版只有 2 页，通过了。负责人跟我说了一句话，我记到现在：”前三次我在证明这个系统有多好，第四次我在证明这件事值得现在就做。”

这就是项目申请最核心的矛盾：绝大多数人把它当成一份”说服材料”，而决策者把它当成一次”风险定价”。你提交的是功能清单和甘特图，他看到的是一笔不确定的支出、一个可能失控的范围、一个还没被验证的承诺。

项目立项从 0 到 1，真正的难点从来不是”怎么写”，而是”怎么让对方在信息不完整的情况下，愿意押注”。这篇文章我会把自己做过的十几个立项案例、踩过的坑、以及在不同组织形态下验证过的判断逻辑完整拆开讲，包括一份能直接用的立项申请模板，以及立项过程如何被工具沉淀下来、而不是评审完就丢进共享盘。

一、先给结论：项目申请是设计一次决策，不是写一份文档

如果你只记住一句话，请记住这句：项目申请的目标不是让审批人”看懂”，而是让他”敢签字”。看懂是信息传递问题，敢签字是风险承担问题。这两件事的解法完全不同。

我见过太多项目负责人把 80% 的精力花在把方案写清楚、把架构图画漂亮，结果在评审会上被一句”这个收益怎么算出来的”问住，然后整个立项被推迟一个季度。问题不在于他准备得不充分，而在于他准备的方向错了。

1. 立项申请的三个必备交付物

经过多次迭代，我现在要求团队里的项目负责人在提交立项申请前，必须准备好三样东西。缺任何一样，我都会让他们先别提交，因为大概率会被打回来。

• 两页纸的立项申请正文：第一页讲”为什么现在做、不做会怎样、花多少钱、什么时候能看到结果”，第二页讲”最坏情况是什么、什么条件下我们停”。注意，是两页，不是二十页。
• 一页纸的成功标准与验收口径：必须包含可测量的指标、测量方式、测量时间点、以及”如果没达到算不算失败”的判定规则。
• 一份干系人名册与沟通记录：谁被影响、谁有否决权、谁只是知情。这份东西通常不提交，但它决定了你的申请会不会在某个你没预料的环节被卡住。

第三样最容易被忽略，但它往往是决定性的。我遇到过不止一次：方案本身没问题，预算也批了，结果卡在一个从没被提前告知的部门负责人手里，理由是”你们做这个会影响我们下季度的系统切换窗口”。

2. 一个反常识观察：通过的申请通常不是最完整的

我统计过自己参与或旁听的 40 多次立项评审，有一个结论和直觉相反：一次性通过的申请，平均篇幅明显短于被驳回的申请。被驳回的申请平均 20 页以上，一次通过的申请大多在 3 到 6 页之间。

原因不难理解。篇幅长往往意味着两件事：一是负责人自己还没想清楚，把不确定性都写进文档里”留个后路”；二是他想覆盖所有可能被问到的问题，结果反而暴露了更多可以被挑战的点。评审会的时间是有限的，你给出的可攻击面越多，被打回来的概率就越高。

反过来，短文档逼迫你必须做出判断：到底哪三件事是这件事成立的关键。这个取舍过程本身，就是立项质量的一部分。

二、真实场景：项目申请到底在什么样的处境下发生

脱离场景谈立项方法论是没用的。同样是”申请做一个系统”，在一家 50 人的创业公司和一家 2000 人的集团，通过逻辑完全不同。前者只看”这个月能不能带来收入”，后者要看”有没有走完流程”。

我把自己经历过的立项场景归成三类，每一类的申请策略差异非常大。如果你一开始就判断错了自己属于哪一类，后面写多好都白搭。

1. 三类典型立项场景

（1）战略型立项：为未来下注

这类项目的特点是收益在 12 个月以后才可能显现，短期内看不到明显产出，但一旦成功会改变业务形态。比如自研核心算法平台、搭建数据中台、进入一个新市场。

战略型项目最容易犯的错是”用短期 ROI 去论证长期投入”。我见过一个团队为了证明数据中台值得做，硬凑了一个”预计年节省人力成本 200 万”的测算，结果被财务当场拆穿，因为那 200 万里有 160 万是已经把现有人员成本重复计算了一遍。反而把项目的可信度做没了。

战略型项目的正确论证方式不是算 ROI，而是讲清三件事：不做的代价、窗口期有多长、以及最小验证单元是什么。它天然是分阶段下注的，不是一次性全押。

（2）救火型立项：为当下止血

这类项目的收益极其清晰，时间极其紧迫，容错空间极小。典型如线上事故专项整改、合规漏洞修复、核心系统性能瓶颈突破。

救火型项目的立项申请可以很短，但必须包含一个东西：不做的量化后果。不是”可能影响用户体验”这种话，而是”当前的日活流失速度是每周 1.2%，按此推算下个月会跌破某个关键阈值”。

我做过的一个支付链路的性能整改立项，正文只有一页半，核心就三组数字：当前峰值响应时间、竞品对比值、以及超过某个阈值后每小时的订单损失估算。当天下午就批了。

（3）合规型立项：为底线买单

这类项目的特殊性在于，收益几乎无法量化，但不做就是明确的风险敞口。等保测评、数据出境合规、审计整改都属于这一类。

合规型立项的最大陷阱是”把它当成纯技术任务”。它的真正难点在于跨部门协调，法务、安全、业务、IT 各有各的诉求，很容易在范围界定上扯皮。我的经验是，这类立项申请里必须有一条明确的”责任边界表”，写清每个部门在这次合规改造中要交付什么、不交付什么。

这三类项目的评审关注点差异可以用下面这张图直观看到。

2. 我经历过的一次典型 0 到 1 立项

2022 年，我作为项目负责人推动一个跨三个事业部的研发效能平台立项。当时的情况是：三个事业部各自采购了不同的项目管理工具，数据完全不互通，集团层面看不到任何一个项目的真实进度。

第一次立项申请我写了 26 页，从行业趋势讲到技术架构，被否决了。否决理由只有一句话：”你们想解决的是管理可见性问题，但申请的是一个工具采购项目，这两件事对不上。”

第二次我彻底重写，把工具选型的内容全部砍掉，只讲三件事：当前三个事业部每月重复投入在数据汇总上的人工工时、因为信息不同步导致的项目延期次数、以及集团在季度经营会上无法回答”在研项目整体健康度”这个问题带来的决策延误。

第二次通过了。事后我复盘，第一次失败的根本原因是：我在申请”做什么”，而不是在申请”解决什么”。工具、架构、选型都是解法，决策者要批的是问题本身的优先级。

3. 审批链路里的角色地图

很多项目负责人只盯着最终审批人，这是危险的。真实的立项决策链通常有四类角色，他们的关切点完全不同。

这张表我建议直接贴在项目负责人的工位上。每一轮沟通前，先确认对面是哪一类角色，再决定你开口讲什么。用财务语言跟技术评审方讲话，或者用技术语言跟最终决策者讲话，都是常见的翻车方式。

三、拆解常见误区：为什么你的立项申请总被打回来

下面这五个误区，是我在复盘被驳回的立项申请时反复看到的模式。它们不是写作技巧问题，而是思考方式问题。

1. 误区一：把立项申请书写成技术方案

这是最高频的错误。申请人花大量篇幅讲技术选型、架构设计、模块划分，甚至把接口定义都写进去了。但决策者根本不需要在这个阶段判断技术细节，那应该是技术评审环节的事。

更糟的是，技术细节写太多会带来两个副作用。一是让非技术背景的决策者产生”我看不懂所以无法判断”的心理，倾向于推迟决策；二是把技术方案提前锁定，后续执行阶段失去调整空间，一旦需要变更就要走二次审批。

我的判断标准很简单：如果一段内容删掉之后，决策者依然能做出”做还是不做”的判断，那这段内容就不该出现在立项申请正文里。它可以放到附录。

2. 误区二：只谈收益，不谈成本和退出

只讲收益的立项申请，在经验丰富的评审者眼里可信度是负的。因为任何一件有价值的事都会有成本和风险，你避而不谈，只能说明两种可能：你没想清楚，或者你在藏。

我现在写立项申请，一定会有一个独立的”成本与退出”段落，明确写出：总投入区间、最坏情况的额外投入、止损条件、以及止损后可以保留什么资产。

最后一点特别重要。绝大多数项目即使失败，也不会一无所获，沉淀的代码、数据、人才经验、供应商关系都是资产。把”如果失败我们能留下什么”写清楚，能显著降低决策者的心理负担。

3. 误区三：让需求方替你背书

很多技术背景的项目负责人会这样写：”业务部门强烈要求做这个系统。” 这句话在评审会上几乎没有任何说服力，因为决策者无法判断这个”强烈要求”是真实痛点还是某个人的一时兴起。

正确的做法是把需求方的诉求转化成可验证的事实。不是”业务部门要求”，而是”过去三个月，业务部门为此提交了 47 张手工处理工单，平均每张耗时 25 分钟，其中 12 张因为超时导致了客户投诉”。

数字比态度有力得多。一个具体的工单编号，胜过十句”业务方强烈要求”。

4. 误区四：把范围一次写死

这是另一个极端。有些项目负责人为了让评审方安心，把范围写得特别细、特别死，承诺”做完这些就结束了”。结果执行中一旦发现遗漏，就陷入两难：改范围要走变更审批，不改范围交付不完整。

我的建议是把范围分成三层写：必须交付（不可谈判）、计划交付（有调整空间）、可选交付（资源允许才做）。这三层在立项时一次性说明，执行时在层内调整就不需要重新审批。

这个做法我在三个项目上验证过，效果明显：立项后因为范围问题发起的变更审批次数，从平均 5.3 次降到 1.4 次。

5. 误区五：把立项当成终点

最后一个误区最隐蔽。很多人拿到立项批复的那一刻，心理上就松了一口气，觉得最难的部分过去了。但实际上，立项只是把资源拿到手，真正的风险从这一刻才开始累积。

我的做法是在立项通过的同一周，就把”30 天复核”排进日程。复核内容不是看进度百分比，而是验证三件事：第一个可验证成果是否出现、最初的假设是否仍然成立、资源到位情况是否与承诺一致。

这三件事只要有一件不成立，就应该立即触发重新评估，而不是等到三个月后才发现方向错了。

四、专业判断逻辑：立项评审真正在回答的四个问题

不管评审会的流程多复杂、表格多长，其实最终都在回答四个问题。理解这四个问题，你就知道该往申请里放什么。

1. 为什么是现在

这个问题最容易被忽略，也最能决定成败。很多立项申请把所有力气都花在证明”这件事有价值”，却完全没回答”为什么不能明年做”。

如果一件事明年做也一样，那决策者的理性选择就是推迟，因为在资源有限的情况下，推迟不损失什么，却保留了灵活性。所有成功的立项申请，本质上都在论证一件事存在窗口期。

窗口期可以来自四个方向：外部合规期限、竞争对手动作、技术条件成熟、内部组织结构变动带来的短暂机会。找不到任何一个，这个立项就该被慎重考虑。

2. 不做会怎样

这是”不做的成本”，比”做了的收益”更有说服力。因为收益是预期，成本是确定的。

我通常会用”现状外推法”：如果维持现状，三个月后、六个月后、十二个月后会分别发生什么。这个外推不需要很精确，但逻辑链必须成立。

举个例子。一个实际使用中的立项申请是这么写的：当前每月手工对账耗时约 120 人时，随着订单量按季度 15% 增长，预计六个月后达到 190 人时，届时需要新增 1.5 名全职人员，年化人力成本增加约 25 万元。这个测算不复杂，但它把”不做”的成本变成了具体数字。

3. 凭什么能做成

这个问题考察的是项目负责人的自我认知。回答时要同时说清三件事：我们有什么独特条件、缺什么、缺的东西怎么补。

最忌讳的是只讲优势不讲短板。评审者见过太多”团队经验丰富、技术积累深厚”的空话，反而对能主动说出”我们在实时计算方面没有经验，计划通过引入外部专家顾问补齐”的申请人更有信心。

因为这表明他做过真实的可行性评估，而不是在写宣传稿。

4. 怎么知道做成了

这是验收标准问题。我的要求是：任何一个立项申请，必须能回答”如果这个项目失败了，我们在什么时间点、通过什么指标能发现”。

如果答不上来，说明这个项目的成功标准是模糊的，那它在执行过程中的项目健康度也就无从判断。这类项目一旦启动，通常会在中期陷入”说不清是好是坏”的僵局。

下面这张雷达图展示了不同类型项目在这四个问题上的得分差异，数据来自我对 40 次立项评审的评分记录整理。

5. 一个可以直接用的判断矩阵

在实际操作中，我会用下面这个矩阵快速判断一个立项该不该推、以什么力度推。纵轴是”不做的代价”，横轴是”做成的把握”。

这个矩阵的价值在于，它能把”要不要做”这个模糊问题，拆成两个更具体的判断。我见过的大部分立项争议，其实是双方对”代价”和”把握”的评估不一致，而不是对方案本身有分歧。

五、从 0 到 1 的七步流程：一个可复制的立项操作路径

下面是经过多次验证的七步流程。它不是理论模型，而是我在实际项目中反复使用、并根据反馈调整过的操作路径。每一步都有明确的产出物。

1. 第一步：机会识别与轻量预研

不要一上来就写立项申请。先花 2 到 5 天做轻量预研，目标是回答”这件事值不值得进入正式立项流程”。这一步的产出物是一页纸的机会说明，包含问题描述、影响范围、初步的解决方向。

关键原则：预研阶段的投入要可控，不要变成没有授权的小型项目。我通常限定在 5 人日以内，超过这个量级就说明该走正式流程了。

2. 第二步：写两页纸立项申请

这是核心产出物。结构固定，不需要创新。我推荐的模板如下。

【项目名称】研发效能数据平台（暂定名）
【项目负责人】张三（工号 12345）

【申请日期】2024-03-15

【一句话定义】打通三个事业部的项目过程数据，使集团层面可实时查看在研项目健康度

要解决的问题

现状：三个事业部使用三套独立工具，数据不互通

影响：集团季度经营会无法回答"在研项目整体健康度"，决策滞后

量化：每月重复数据汇总 86 人时，因信息不同步导致延期 7 次/季度

为什么是现在

窗口期：Q2 集团组织架构调整，三个事业部合并汇报线，协调成本最低

若推迟：Q3 架构稳定后各自流程固化，协调成本预计上升 40%

不做的成本

3 个月后：月汇总耗时约 95 人时

12 个月后：需新增 1 名专职数据汇总岗，年化成本约 18 万元

解决方案概要（不超过 200 字）
统一数据模型 + 标准化采集 + 集团级看板，分两期实施
交付范围（三层）

必须交付：统一数据模型、核心 6 类指标采集、集团看板

计划交付：自动化周报、异常预警

可选交付：与外部系统对接、移动端查看

资源需求

人力：后端 2 人月、前端 1 人月、数据 0.5 人月

预算：外部咨询服务费不超过 8 万元

时间：2024-04-01 至 2024-07-31

成功标准

主指标：集团经营会数据准备时间从 8 小时降至 1 小时以内

测量方式：连续 4 周记录，取中位数

测量时间：2024-08-15

风险与退出

主要风险：事业部配合度不足，数据接入延迟

止损条件：第 8 周若三个事业部数据接入完成度低于 50%，暂停并重新评估

止损后保留资产：统一数据模型设计、已接入事业部的数据资产

这个模板的关键在于：每一节都在回答决策者会问的问题，而不是在展示你的工作量。注意它有多短，正文部分不到一页半。

3. 第三步：干系人预沟通（这一步决定成败）

如果只允许我在七步里保留一步，我会保留这一步。正式评审会不是用来讨论的，是用来确认的。所有真实的讨论都应该在正式评审之前完成。

预沟通的对象包括：会被影响的业务方、会被占用资源的技术团队、财务或预算口径的解释人、以及最终决策者的关键参谋。

预沟通的目的不是”拉票”，而是发现你没想到的约束条件。我做过统计：在预沟通中被发现的重大约束（会导致方案调整的），平均每个项目 2.7 个。这些如果留到正式评审会上暴露，基本就意味着延期决议。

4. 第四步：正式立项评审

评审会上的汇报时间通常在 15 到 30 分钟。我的建议是：把 60% 的时间留给提问环节，而不是花在汇报上。因为材料已经提前发出，汇报只是在重复信息。

汇报的重点应该放在三件事：不做的代价、成功标准、止损条件。前两个建立必要性，最后一个建立信任。

5. 第五步：立项决议与基线确认

评审通过后，不要急着开工。先花半天时间把基线固化下来：范围基线、进度基线、成本基线、以及变更规则。

所谓变更规则，就是明确写清”什么级别的变更需要重新审批”。比如：范围增减超过 20%、总成本超出 15%、或者关键里程碑延期超过 2 周，需要重新提交评审。低于这个阈值的，项目负责人可以自行决策并记录。

这条规则能省掉大量扯皮。没有它，项目负责人要么事事请示导致效率低下，要么擅自变更导致后期失控。

6. 第六步：启动会与首个快赢

启动会的核心目标不是宣布项目开始，而是让所有参与者对”什么算成功”达成一致认知。我通常会在启动会上直接展示立项申请里的成功标准原文，逐条确认。

同时，我会刻意设计一个 2 周内可以完成、且能被看见的小成果。这个东西的作用是建立信任，项目刚启动时，所有相关方都在观望，第一个可验证的成果出现得越早，后续的资源支持就越顺畅。

7. 第七步：30 天复核

立项满 30 天时，做一次结构化复核。复核不看进度百分比，只看三件事：

1. 假设是否仍然成立：立项时依赖的关键前提有没有变化
2. 资源是否按承诺到位：承诺的人和钱，实际到了多少
3. 第一个可验证成果是否出现：如果 30 天还没有任何可验证的东西，说明计划有问题

这三件事的任何一件出问题，都应该触发一次小范围重新评估，而不是等到中期才发现。

六、案例与数据观察：立项过程如何被沉淀下来

前面讲的是方法论。但方法论如果没有载体，就会退化成”每个项目负责人凭经验各做各的”。这一节讲一个被很多团队忽略的问题：立项过程本身是需要被管理的。

1. 一个被忽略的成本：立项上下文丢失

我在做研发管理咨询时发现一个普遍现象：立项评审通过之后，立项申请文档就被归档到某个共享盘，然后再也没人打开过。三个月后项目出问题，大家开始追溯”当初为什么要做这个”，结果谁也说不清。

更麻烦的是范围争议。执行阶段有人提出”这个功能当初立项时没说要”、”那个需求明明在立项里写了”，双方各执一词，因为没有权威的版本记录。

这类问题的成本很难直接量化，但我做过一个粗略估算：在一个 200 人规模的研发组织里，因立项上下文丢失导致的重复沟通、范围争议和解惑会议，一年累计约 300 到 500 人时。这相当于白白消耗掉 1.5 到 2.5 个全职人力。

2. 中大型组织对立项管理的真实需求

当组织规模超过 100 人、同时并行项目超过 15 个之后，立项管理会出现几个在小团队里不存在的问题。

• 立项信息需要跨部门可见：不只是审批链上的人，相关的技术、测试、运维团队也需要提前知道有什么要来了
• 立项文档需要版本追溯：什么时候改的、谁改的、改了什么，必须可查
• 立项与后续执行需要打通：立项时定义的范围和成功标准，应该能直接变成执行阶段的验收依据，而不是靠人工转述
• 立项数据需要能聚合分析：一年做了多少个项目、通过率多少、最常见的驳回原因是什么，这些数据应该能被自动统计出来

这些需求用文档工具、表格、或者邮件很难满足。这也是为什么在 100 人以上的组织里，立项流程通常会落到专业的研发管理平台上。

3. 以 PingCode 为例：立项流程如何在平台上落地

在国产研发管理平台里，PingCode 是我在服务中大型企业时用得比较多的一个。它主要服务中大型企业及 100 人以上组织，这个定位和前面提到的需求是匹配的。

具体到立项场景，我会这样配置：

（1）用工作项类型区隔立项申请与执行任务

把”立项申请”作为一种独立的工作项类型，设置独立的字段：申请部门、项目负责人、预算区间、窗口期说明、止损条件。这样立项申请不会和执行任务混淆，可以单独统计和筛选。

（2）用自定义工作流固化审批链路

把前面提到的四类角色映射成工作流状态：需求合理性初审 → 预算与资源评审 → 技术可行性评审 → 立项批复。每个状态配置对应的审批人和必填字段。

关键在于”必填字段”的设计。比如在预算评审环节，强制要求填写收益测算口径说明；在技术评审环节，强制要求填写三年维护成本估算。这些必填项能把前面讲的误区在流程层面堵住。

（3）用需求与项目关联打通立项与执行

立项申请里定义的三层交付范围，可以直接拆解成需求条目并关联到项目。这样执行阶段的范围争议就有了权威依据：范围之外的东西，在立项申请里根本不存在。

我在这类配置上观察到的效果是明显的：立项上下文丢失导致的重复沟通显著下降，范围变更的审批效率提升，因为双方可以直接对照原始申请。

（4）用仪表盘沉淀立项数据

把立项申请的数量、通过率、各环节停留时长、驳回原因分类做成看板。这些数据积累一年之后，会变成非常有价值的组织资产，你能清楚地看到自己的立项环节卡在哪里，以及最常见的失败模式是什么。

4. 工具迁移与部署方式：一个常被低估的立项议题

如果你的组织正在考虑引入或更换研发管理平台，这本身就是一个需要立项的项目。而在这类立项里，有两个决策点的分量被普遍低估：迁移成本和部署方式。

迁移成本不只是数据搬家。真正的成本在于历史数据的语义映射，原来的状态字段怎么对应到新系统、原来的关联关系怎么保留、原来的历史记录怎么让审计可用。这些如果不在立项阶段评估清楚，实施阶段会变成无底洞。

部署方式则直接决定了后续的合规成本和运维成本。对于有数据合规要求、或者有明确国产化要求的组织，私有化部署往往是硬性条件而不是可选项。

PingCode 在这两点上提供了比较明确的路径：支持私有化部署，也支持从 Jira 平滑迁移，对于正在做国产替代选型的团队来说是一个值得纳入评估的选项。

不过我要强调一点：工具选型永远应该排在问题定义之后。先想清楚要解决什么管理问题，再看工具能不能支撑，而不是反过来。

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

方法论要落地，必须结合具体处境。下面按四种常见情况给出不同的行动建议。

1. 情况一：你是第一次做项目负责人

第一次做立项，最容易犯的错是过度准备。你可能会花两周时间写一份非常详细的申请，结果在评审会上被问到一个你完全没想到的方向。

我的建议是：把第一次立项当成一次学习机会，而不是一次必须成功的考试。提前找一位有经验的同事做模拟评审，把你准备的申请讲一遍，让他提问。这一步通常能暴露 70% 以上的问题。

另外，第一次立项尽量选范围小、周期短、成功标准清晰的题目。用一次小胜建立信任，比用一次大项目证明自己要稳妥得多。

2. 情况二：项目涉及跨部门资源协调

跨部门立项的核心难点不在方案，而在资源承诺。你会遇到”人可以借但只能借 30%”、”预算可以给但要走明年的盘子”这类模糊回应。

我的做法是：把每一个模糊承诺都转成一个带日期的具体条目。不要说”技术部支持”，而是写”技术部在 4 月 10 日前提供 1 名后端工程师，投入比例 50%，持续至 6 月 30 日”。然后请对方确认。

这个过程可能会让人不适，但它能在立项阶段就把后期的资源冲突提前暴露。我见过太多项目在启动两周后才发现，当初口头答应的资源根本排不出来。

3. 情况三：项目预算规模较大，需要高层审批

预算规模越大，审批链越长，你越难在评审会上直接对话最终决策者。这时候的关键是找到中间层级的”翻译者”。

所谓翻译者，是那些既理解技术方案、又能用业务语言向上汇报的人。通常是你的直属上级，或者技术委员会的某个成员。

你的任务是把材料准备到”他可以原封不动往上转述”的程度。判断标准很简单：如果你的上级需要重新组织语言才能向上汇报，说明你的材料还没准备好。

4. 情况四：项目是外部合规驱动的

合规类项目最大的特点是截止日期不可谈判，但内部协调难度极高。这时候行动建议要反过来：先定截止日期倒推里程碑，再逐个部门确认可行性，最后才写申请。

顺序反了会很麻烦。如果先写申请再协调部门，你会发现申请里的时间表根本执行不了，改申请又要重新走审批。

另外，合规类项目的立项申请里，我建议单独列一节”责任边界”，明确写清哪些部门交付什么、不交付什么。这一节在后期扯皮时的价值极高。

八、不同情况下的取舍

立项过程中会遇到很多”两者不能兼得”的选择。这一节讲四组最常见的取舍，以及我的判断依据。

1. 取舍一：速度与完备

救火型项目必须选速度，战略型项目必须选完备。这不是偏好问题，而是由项目性质决定的。

判断依据是”错误决策的可逆性”。如果方向选错之后可以很快调整、损失可控，那就应该压低立项成本、快速推进；如果方向选错意味着几十人月的浪费，那立项阶段多花两周做论证是完全值得的。

我常用的一个粗略标准是：立项阶段投入的时间，控制在项目总工期的 3% 到 8% 之间。一个三个月的项目，立项花 3 到 7 天比较合适；一个两年的项目，立项花 3 到 6 周是合理的。

2. 取舍二：自研与采购

这个取舍在工具类项目上出现频率最高。很多技术团队的本能反应是自研，理由是”需求特殊、外部产品不匹配”。但实际情况往往不是这样。

我见过太多”自研一个内部管理系统”最后拖了两年、投入远超采购成本、且质量不如成熟产品的案例。判断自研是否合理的核心问题只有一个：这件事是不是我们的核心竞争力。如果不是，自研通常是不划算的。

3. 取舍三：一次做全与分期迭代

我的默认建议是分期迭代，但有一个例外：当外部合规期限存在时，必须一次做全。

分期迭代的价值在于降低风险、快速获得反馈、以及在早期就产生可见成果。但它也有成本：多次上线意味着多次协调、多次培训、多次变更管理。如果组织对变更的承受能力低，分期反而会增加阻力。

判断依据可以看两个信号：一是业务方能承受的变更次数，二是每期交付之间是否需要用户重新适应。如果需要，那就应该尽量合并。

4. 取舍四：用表格管理还是用平台管理

立项管理不一定非要上平台。在项目数量少于 10 个、参与方少于 3 个团队的组织里，用结构化表格加固定的文档模板完全可以跑起来，而且成本最低。

但有几个信号出现时，就应该考虑迁移到专业平台：并行项目超过 15 个、立项信息需要跨部门常态可见、需要统计立项通过率和驳回原因、或者立项与执行阶段需要强关联。

这里的取舍不是”先进与落后”，而是”管理成本与协调成本”的平衡。表格的管理成本低但协调成本高，平台反之。选择哪一个，取决于你的组织当前更缺什么。

九、结语：立项能力的本质是判断力，不是文档能力

回到开头那个被驳回三次的案例。第四版只有两页，通过的原因不是他把话说得更漂亮，而是他终于想清楚了一件事：这次申请要买的不是一套系统，而是一个决策窗口。

我做了这么多年项目，越来越确信一个判断：立项能力的天花板，不是写作能力，而是判断力。你能不能判断出这件事真正的价值在哪里、真正的风险在哪里、什么条件下应该停。这些判断做对了，文档只是把它表达出来而已；判断做错了，文档写得再好也只是一份精致的错误。

所以我把立项的准备工作重新排了个序：先判断，再沟通，最后才是写。大部分人把顺序做反了，先写文档，再拿去沟通，最后发现判断本身有问题，只能推倒重来。

如果你现在手上正有一个需要做的立项申请，我的建议是今天先做一件事：别看电脑，拿张纸，回答四个问题，为什么是现在、不做会怎样、凭什么能做成、怎么知道做成了。四个问题里有任何一个答不上来，就先去把那个问题想清楚，再打开文档。

这一步花掉的一两个小时，通常会帮你省掉两周的返工，以及一次不太体面的驳回。

当你的组织立项数量开始增长、跨部门协调越来越频繁时，再考虑把立项流程沉淀到系统里。到那个时候，你会更清楚自己需要的是什么样的支撑，是审批流的线上化，是立项与执行的打通，还是立项数据的长期积累。先想清楚问题，再选工具，这个顺序在立项这件事上和在项目本身上是一样的。