项目申请怎么做？PMO风险控制：项目立项从0到1

我在一家年营收 40 多亿的制造企业做 PMO 顾问时，遇到过最尴尬的一次立项评审：一个预算 380 万的数字化车间项目，从提交申请到总裁签字批准，总共用了 11 分钟。三个月后项目启动，第八个月被叫停，已经花掉 210 万，交付物是一个没人打开过的看板。

复盘会上所有人都在说”执行不到位”。但我翻完那份 12 页的立项申请，发现问题根本不在执行，那份申请里没有一个字提到”如果设备数据采不上来怎么办”，也没有一个字说明”谁是这个项目的最终使用者，他每天会打开几次”。这就是我写这篇文章的原因：项目申请怎么做，PMO 在立项环节控住哪些风险，直接决定后面 80% 的返工成本。

下面这些内容，来自我这几年在制造、金融科技、SaaS 三类企业里做过的 60 多次立项评审和 30 多份立项模板迭代。我会先给结论，再讲真实场景，然后拆误区、给判断逻辑、给流程、给工具承载方案，最后按不同组织规模给行动建议和取舍建议。

一、先给结论：项目申请的本质，是给不确定性定价

绝大多数人把项目申请理解成”写一份材料去说服领导批钱”。这个理解一旦成立，立项书就会自然滑向两个方向：要么堆砌宏大叙事，要么堆砌财务模型。两种写法都很努力，但都不解决真问题。

我的结论是：项目申请是一份”不确定性定价书”，而不是一份”资源申请书”。你要做的事情，是把一个模糊的机会，翻译成一组可以被检验的假设、一组可以被度量的收益、以及一条可以被随时叫停的边界。PMO 在立项环节的全部价值，就是逼着申请方完成这次翻译。

1. 立项不是”要资源”，是”签对赌”

我经常跟业务方讲一句话：立项评审会上，你承诺的不是”我会努力”，而是”如果第 90 天这个指标没到 X，我同意砍掉第二阶段预算”。这句话背后是一种对赌结构，你拿走资源，就必须接受一个可验证的对赌条件。

没有对赌条件的立项，本质上是在把决策风险从业务方转移给公司。审批人签了字，就只能等到项目结束才知道对错，这时候沉没成本已经无法挽回。

所以我在设计立项模板时，一定会留一栏叫”触发终止条件”。它不需要写得很复杂，但必须具体到时间点、指标名和数值，比如”第 6 个月末，试点产线的数据自动采集覆盖率低于 70%，则暂停二期投入，转入复盘”。

2. 三条及格线：收益可测、风险有主、退出有门

我看立项申请时，通常只做三个判断，这三条任何一条不满足，我就会在评审会上明确投反对票，而不是含糊地说”建议进一步完善”。

• 收益可测：收益指标是否有一个可以被第三方复核的口径？”提升协同效率”不算，’月度人力统计耗时从 12 小时降到 3 小时’才算。
• 风险有主：每一条前三风险，是否有一个具体的人名，而不是一个部门名？”由 IT 部负责”不算，”由 IT 部张工负责，且他已确认投入 0.4 人力”才算。
• 退出有门：如果中期失败，是否有明确的止损点和退出路径？没有退出机制的项目，实际上是无限责任。

3. 立项通过率高，往往不是好事

很多 PMO 把”立项通过率”当成自己的 KPI 之一，追求高通过、快通过。我持相反看法：立项通过率长期高于 90%,通常意味着 PMO 没有起到筛选作用，只是在走流程。

比较健康的状态是：正式提交的立项申请通过率在 60%-75% 之间，剩下 25%-40% 在预立项阶段被拦下来，要么转入更小的验证性试点，要么合并进已有项目，要么直接被否。被拦下的数量，才是 PMO 的价值证据。

二、真实场景：一个被”秒批”的项目，是怎么在第八个月烂尾的

抽象判断讲完了，我们回到那个 380 万的项目。它的死亡过程非常有代表性，几乎每一步都可以在其他项目里找到对应。

1. 案例还原：三个月的立项，八个月的返工

项目的原始诉求是”车间数据可视化”。业务方提交的立项申请写了 12 页，其中 8 页是行业趋势和政策引用，2 页是设备清单，1 页是预算拆分，1 页是实施计划。评审会上，唯一被讨论的问题是”预算能不能压缩到 350 万”。没有人问数据从哪来。

第 1-3 个月，供应商进场，硬件安装顺利。第 4 个月，开始对接 PLC 数据，发现 3 台关键设备是 2009 年的老型号，没有标准数据接口，需要加装采集网关，额外报价 47 万。第 5 个月，网关到货，但车间担心影响生产，只允许在夜班停机窗口施工，工期延长两个月。

第 7 个月，看板终于上线。业务方看了一眼问：”为什么 A 产线的在制品数据和 ERP 里对不上？”第 8 个月，项目被叫停，原因写的是”业务价值未达预期”。

2. 问题不在执行，在立项那一刻就注定了

把这次复盘摊开看，八个月里的每一次延误，其实都能追溯到立项时缺失的一个问题。

你会发现，这四件事没有一件是”技术难题”，它们全是立项阶段花三五天就能问清楚的事情。项目失败的原因里，真正属于执行层的比例，远低于大多数人的直觉。

3. PMO 复盘时最常看到的四个断点

在我做过的复盘里，下面四个断点出现的频率最高，几乎覆盖了 70% 以上的失败项目。

1. 目标断点：立项书写的是”建设 XX 平台”，而不是”解决 XX 问题”，导致范围可以无限扩张。
2. 数据断点：没人确认数据源是否存在、是否唯一、是否有负责人，等到对接时才发现缺口。
3. 人断点：业务侧参与人被写成”相关部门”，实际执行时没有人真正投入时间。
4. 收益断点：收益没有基线，项目结束后无法证明价值，只能靠感觉评价。

三、拆解误区：项目申请里最容易踩的九个坑

下面这九个坑，是我在实际评审里反复见到的。它们不是”写得好不好”的问题，而是会直接导致项目在半年后失控的结构性问题。

1. 误区一：把立项书写成可行性研究报告

这是最常见的错位。可行性研究报告是写给技术评估用的，立项申请是写给决策用的。前者关心”能不能做”，后者关心”值不值得做、做砸了怎么办”。

我看过一份 76 页的立项申请，其中 50 页是技术架构对比。评审会上没有一个人能读完，最后大家只看了预算页。立项申请的理想长度是 8-15 页，核心判断集中在前面 3 页。

2. 误区二：只讲收益不讲代价

立项申请里有一栏经常被写成空话：业务侧的投入。很多申请方默认”IT 部门做项目，业务只要配合验收就行”。这是导致项目失败的头号认知错误。

一个真实的数字：在我跟踪的 23 个失败项目中，有 17 个的失败直接原因是业务侧关键用户投入不足，平均实际投入只有立项承诺的 31%。

3. 误区三：ROI 拍三件套

所谓三件套，就是”人力节省 + 效率提升 + 风险规避”。这三项其实很难算，但很多人会硬算出一个漂亮数字。

我的处理方式是：不接受无法追溯基线的收益数字。如果申请方说”每年节省人力成本 120 万”，我会要求他给出当前的人力基线，多少人、每月多少小时、这些时间释放之后具体去做什么。答不上来的，这个数字就要被划掉，或者标注为”未验证假设”。

在实践中，我允许立项书里存在假设性收益，但必须集中放在”待验证收益”一栏，并且明确验证时间和验证方法。这样既不影响项目通过，也不会让审批人产生错误预期。

4. 误区四：风险栏写”风险可控”

这一栏是我在评审会上最常直接退回的内容。”风险可控”四个字，等于没有做风险识别。

我要求的风险描述结构是三段式：风险事件 + 触发信号 + 应对动作和责任人。例如：”若核心供应商在第 4 个月前未完成网关兼容性测试（触发信号：测试报告逾期 10 天），则由采购部启动备选供应商比价，负责人为采购部李工。”

另外，风险清单的项目数建议控制在 3-5 条。写 20 条风险反而说明申请方没有做优先级判断。

5. 误区五：把 PMO 当审批关卡

很多业务方把 PMO 视为”最后一道要被说服的门”。一旦这种对立关系形成，申请方就会开始隐藏坏消息，只呈现有利信息。这恰恰是 PMO 最不希望看到的状态。

我自己的做法是：在正式评审前，先做一次 30 分钟的”预沟通”，明确告诉申请方”我会问哪三个问题”，让他有时间补齐。这样评审会就不是突然袭击，而是一次联合设计。预沟通之后，正式评审的通过率明显上升，被否的项目也更容易接受结论。

6. 误区六：资源承诺不落到人头

“由研发部投入 3 人”和”由研发部张工、王工、李工各投入 50% 工时，从 3 月 1 日到 8 月 31 日”是两件完全不同的事。前者是愿景，后者是承诺。

我在立项模板里强制要求资源表包含四列：姓名、部门、投入比例、投入周期。没有落到姓名的资源，在排期时几乎一定会被其他优先级更高的任务挤掉。

7. 误区七：立项即冻结，变更无出口

有些组织的 PMO 为了控制范围，规定”立项通过后范围不得变更”。听起来很严格，实际结果是团队会偷偷变更，只在验收时集中暴露。

更有效的做法是设置”变更额度”：比如允许总预算 10% 以内、总工期 15% 以内的范围调整由 PMO 直接批准，超出部分才上升到立项评审委员会。这样既保留了纪律，也给了项目呼吸空间。

8. 误区八：用”战略重要性”压过一切

“这是公司级战略项目”这句话，我在评审会上听过太多次。它的作用通常是终止讨论。

我的应对是区分两个问题：战略必要性回答”要不要做”，立项评审回答”怎么分批做、第一批做什么”。战略项目更应该分批立项，因为它的不确定性往往更高，而不是更低。把 800 万的项目拆成”200 万验证 + 600 万扩展”，风险敞口会小得多。

9. 误区九：评审会开成答辩会

我参加过很多评审会，申请方站在投影前讲 40 分钟，评委问 20 分钟，然后投票。这种形式的问题在于：信息是单向流动的，评委在最后 20 分钟才介入，往往只能提一些表面问题。

我现在的做法是把评审会改成三段式：10 分钟申请方陈述、25 分钟针对三个预设问题集体讨论、10 分钟明确结论和附加条件。讨论环节才是产生判断的地方。

四、专业判断逻辑：PMO 到底该控什么风险

误区讲完了，接下来是最关键的部分：PMO 在立项环节应该用什么逻辑做判断。这里我会给出一套可以直接在评审会上使用的框架。

1. 三类风险要分开管

很多 PMO 把所有风险混在一张表里，结果就是”什么都在管，什么都管不住”。我的做法是把立项阶段的风险分成三类，分别对应不同的判断人和不同的处理动作。

• 交付风险：能不能按时按质做出来。责任主体是技术负责人，控制手段是技术方案评审、关键路径识别、供应商履约能力核查。
• 价值风险：做出来之后有没有人用、有没有产生预期收益。责任主体是业务负责人，控制手段是收益基线确认、用户参与承诺、上线后度量机制。
• 组织风险：资源能不能真正到位、跨部门协作能不能打通、决策链条会不会卡住。责任主体是项目发起人，控制手段是资源签字确认、决策升级机制、冲突仲裁规则。

这三类风险里，交付风险最容易识别，也最容易被过度关注；价值风险和组织风险最隐蔽，却往往是项目失败的真正原因。我在评审会上，会把 60% 的提问时间花在后两类上。

2. 四象限判断：价值确定性 × 交付确定性

我给每个立项项目做定位时，用两个维度：价值确定性（收益能不能被验证）和交付确定性（技术路径是不是成熟）。这两个维度交叉，形成四个象限，每个象限的处理策略完全不同。

这个矩阵最大的价值，是让评审讨论从”要不要做”转向”用哪种方式做”。很多争论其实不是因为立场不同，而是因为大家在讨论不同象限的项目，却用了同一套标准。

3. 立项评审只问三个问题

我把评审提问收敛成三个，任何项目都要回答，回答不清楚就不进入投票环节。

1. 如果只能保留项目 30% 的预算，你会优先做哪一部分？这个问题直接暴露申请方有没有做价值优先级排序。答不上来的，说明整个方案是”打包捆绑”的，无法分批交付。
2. 项目失败的最可能原因是什么？你现在做了什么准备？这个问题检验风险识别的真实性。标准答案是具体的、带触发信号的，而不是”需求变更”这种通用词。
3. 项目上线后第 30 天，你会用哪三个数字判断它是否成功？这个问题检验收益度量是否落地。如果答案是”用户满意度提升”，就说明没有想清楚。

这三个问题我用了三年，最直接的效果是：正式评审会的平均时长从 75 分钟降到 45 分钟，但立项后 90 天内的目标漂移率明显下降。

4. 用阶段关口替代一次性审批

传统立项是”一次性审批”：过了就过了，直到项目结束才评估。这种方式的最大缺陷是，一旦立项决策错了，中间没有任何纠错机会。

替代方案是阶段关口（Stage-Gate）：把项目拆成 3-5 个阶段，每个阶段结束设一个关口，关口只做一件事，决定是否继续投入下一阶段预算。关口的决策权可以下放，但关口的评估标准必须前置写死。

我的经验是：关口数量控制在 3 个比较合适，分别设在方案确认后、试点验证后、全面推广前。关口太多会变成形式主义，太少则起不到早期止损的作用。

五、从 0 到 1：立项流程的可落地拆解

前面讲的都是判断逻辑，这一节给一套可以直接落地的流程。我把它拆成四个阶段，每个阶段给出目标、动作、输出物和时长，你可以直接对照自己组织的现状做裁剪。

1. 第一阶段：机会识别与预立项（1-2 周）

这个阶段的目标不是写材料，而是判断”这件事值不值得花时间写材料”。核心动作有三个：

1. 问题陈述：用一段话写清楚”谁、在什么场景下、遇到什么问题、现在的处理方式是什么、代价是多少”。写不出代价的问题，通常不值得立项。
2. 数据可行性初判：确认所需数据的来源、是否唯一、是否有接口、是否有责任人。这一步能过滤掉大量”看起来很美”的项目。
3. 初步收益估算：允许粗糙，但必须有量级。比如”预计每年节省 3000 工时”比”显著提升效率”好得多。

预立项通过的标志，是 PMO 给了一个立项编号并纳入项目池。没通过的，退回业务方补充信息，或者转入其他渠道处理。

2. 第二阶段：立项申请包编制（2-3 周）

这个阶段是很多人最头疼的，因为它需要跨部门协作。我的建议是提前锁定三类人：业务负责人、技术负责人、财务或成本接口人。缺任何一个，材料都会有硬伤。

编制过程中最容易出问题的地方是收益测算。我的做法是要求申请方区分三类收益：

• 已验证收益：有基线、有历史数据的，比如减少加班工时。
• 待验证假设：有逻辑但无数据的，比如减少沟通成本。必须注明验证时间。
• 战略收益：无法量化的，单独列出，不进入 ROI 计算。

分开列的好处是，审批人一眼就能看出哪些数字是硬的、哪些是软的，不会因为整体 ROI 数字好看而过早放松警惕。

3. 第三阶段：评审与决策（1 周）

评审会我之前讲过三段式结构。这里补充三个操作细节。

第一，评审材料必须提前 3 个工作日发出，不接受现场首次阅读。第二，评审意见必须当场形成书面结论，包括通过、有条件通过、退回修改、否决四种状态，不接受”原则上同意”。第三，有条件通过的附加条件必须写清验证时间和验证人。

4. 第四阶段：立项后 30 天冷启动控制

很多组织在立项通过后就放手了，直到第一次月度汇报才重新关注。这 30 天其实是风险最高的窗口期，因为关键假设往往在这段时间被证伪。

我在冷启动期设置四个必须完成动作：

1. 关键资源实际到位确认（对比立项承诺名单）
2. 三个关键技术或业务假设的初步验证结果
3. 首个可交付物的范围冻结
4. 风险清单的第一次更新

这四个动作没完成的，项目会被自动转为”观察状态”，暂停后续预算释放。这个机制的作用不是惩罚，而是让团队在成本最低的时候发现问题。

5. 立项申请包的目录结构（可直接抄）

下面是我迭代了 8 个版本的立项申请包结构。它不追求全面，追求的是让评审人在 10 分钟内做出判断。

00 封面与审批页（1 页）

项目名称、编号、发起人、预算总额、周期

四级结论勾选项：通过 / 有条件通过 / 退回修改 / 否决

01 决策摘要（2 页，必读）

问题陈述：谁的什么问题，当前代价

解决方案要点：不写架构，只写"做什么、不做什么"

收益摘要：已验证收益 / 待验证假设 / 战略收益

三条核心风险与责任人

建议决策与终止条件

02 业务价值（2-3 页）

现状基线与度量口径

收益测算过程与假设

上线后 30 天验证指标（三个数字）

03 实施方案（3-4 页）

关键路径与里程碑（不超过 6 个）

技术或业务假设清单及验证方式

供应商与外部依赖

04 资源与预算（1-2 页）

人头级资源表：姓名 / 部门 / 投入比例 / 周期

预算分阶段拆分，与里程碑绑定

05 风险与关口（1-2 页）

3-5 条风险：事件 / 触发信号 / 应对 / 责任人

阶段关口设置与评估标准

06 附件

数据源确认单、供应商报价、合规评估

这套结构的核心思想是：把”答案”放在前面，把”过程”放在后面。评审人先看结论，需要深究时才翻后面的内容。

六、工具承载：立项流程怎么被系统固化（以 PingCode 为例）

流程写完，接下来的问题是：靠 Excel 和邮件能不能跑起来？能，但跑不过 20 个项目。

1. 为什么立项流程必须落到工具上

我在两家企业经历过从”邮件事务”到”系统承载”的转变，最直观的变化有三个：立项材料版本不再混乱、关口评审不再依赖人记忆、立项数量和实际交付率之间的关联第一次被看见。

纯线下的立项管理，通常会在三个地方崩溃：一是当并行项目超过 15 个，PMO 无法准确知道哪些关口到期；二是当人员流动，历史立项的决策依据随之丢失；三是当需要复盘时，找不到当时承诺的收益口径。

2. 中大型组织的三个硬门槛

对 100 人以上的组织来说，立项工具的选择有三个绕不过去的门槛。

• 权限与组织架构的匹配：立项信息天然涉及预算和战略，不同事业部、不同层级看到的内容应该不同。工具必须支持按组织架构配置可见范围。
• 流程可配置：不同业务线的立项路径差异很大，研发类项目需要技术评审节点，市场类项目需要财务评审节点。工具不能只支持一套固定流程。
• 数据可追溯：每一次评审意见、每一次范围变更、每一次关口决策，都要能形成留痕，并且可以被检索。

这三个门槛，决定了通用协作工具很难承担立项管理，需要专门的项目管理平台来承载。

3. 私有化部署、Jira 平滑迁移与国产替代

在制造、金融这类行业里，还有一个额外的硬约束：数据不能出内网。立项材料里通常包含预算、产能、客户结构等敏感信息，这类组织往往要求系统支持私有化部署。

我参与过的几个替换项目里，团队最担心的其实不是功能，而是迁移成本，历史项目的需求、缺陷、迭代记录如果丢了，等于几年的过程资产归零。

PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，是我们做国产替代时比较常被纳入评估范围的一个平台。它的定位比较清晰：面向研发与项目协同场景，把需求、迭代、测试、发布这条链路打通，立项作为项目全生命周期的前置环节，也能纳入同一套数据体系。

我对这类平台的实际评估经验是：私有化部署能力决定了能不能进这个行业，迁移能力决定了落地会不会引发团队抵触，而流程配置能力决定了它能不能同时满足总部和事业部的不同要求。三项缺一，项目在推广阶段就会卡住。

4. 一个可参考的配置思路

下面是我在某制造企业落地时用过的配置思路，抽象成通用结构，供你参考。

项目类型：立项申请（自定义工作项类型）
字段设计：

预立项编号（文本，唯一）

发起部门（单选，绑定组织架构）

预算区间（分级单选：50万以下 / 50-200万 / 200万以上）

收益类型（多选：已验证 / 待验证假设 / 战略）

三条核心风险（富文本，强制填写）

终止条件（富文本，强制填写）

当前阶段（单选，驱动状态流转）

状态流转：

草稿 → 预立项审核 → 申请包编制 → 技术评审 → 财务评审

→ 立项决策 → 冷启动验证 → 正式立项 / 暂停 / 否决

自动化规则：

立项决策通过后自动创建"冷启动 30 天"检查任务集

关口到期前 5 天自动提醒项目发起人

预算使用超过阶段额度 85% 时自动标记风险

这套配置的价值不在于字段本身，而在于它把”必须回答的问题”变成了”不填就不能提交”。流程的强制性来自工具的结构，而不是人的自觉。

七、数据观察：立项质量到底影响什么

前面讲了很多方法论，这一节我把跟踪到的指标摊开讲，你可以对照自己的组织看哪些指标目前是缺失的。

1. 我们跟踪的六个指标

这六个指标是我在三个不同行业的企业里逐步收敛出来的，它们的共同特点是：都可以在项目早期采集，并且都和最终结果有较强相关性。

最后一项”终止条件触发执行率”最容易被忽视，但它其实是整套机制有没有牙齿的检验标准。如果终止条件写了从来不执行，那它就不是风险控制，而是装饰。

2. 数据说明了什么

把 46 个项目的六个指标和最终结果做对照，我发现一个比较稳定的规律：前三个指标（收益口径、风险责任人、资源签字）的表现，与项目是否按期交付的相关性最强；后三个指标（范围冻结、关口评审、终止执行）的表现，与项目最终是否被判定为”有价值”的相关性最强。

换句话说：决定项目能不能做完的，是资源和人；决定项目做完之后有没有意义的，是范围和关口纪律。

这个结论对 PMO 的实际意义是：如果你所在的组织项目延期严重，优先修资源确认机制；如果项目做完没人认账，优先修关口和收益口径。不要同时上十项改进，那通常什么都改不动。

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

方法论给完了，但不同规模、不同行业的组织，起步点完全不同。下面按四种典型情况分别给建议。

1. 50 人以下团队

这个规模不建议建立完整的立项评审机制，成本会大于收益。我的建议是简化到一页纸：问题、目标用户、成功指标、预算、投入人员、什么情况下停。

关键是保留”成功指标”和”停止条件”这两栏，其余都可以自由发挥。工具层面，用现成的看板工具就够，不需要专门采购项目管理平台。

这个阶段最该做的一件事是：把每次项目的”停止条件”记录下来，一年后回看哪些条件真的触发了。这会帮你形成对自己团队判断力的校准。

2. 100-500 人、单一主业

这是最典型的”需要立项机制”的规模区间。建议建立正式立项流程，但控制在四个阶段、三个关口以内。

PMO 配置上，1-2 人就够，重点不是写材料，而是运营关口和做立项数据统计。这个规模最容易犯的错是流程过重，审批节点超过 5 个之后，业务方会开始想办法绕开流程。

工具层面，到这个规模就该考虑专门的项目管理平台了。私有化部署的需求通常在这一阶段开始出现，尤其是涉及客户数据或生产数据的项目。选型时优先验证流程配置能力和历史数据迁移能力，功能清单反而是次要的。

3. 500 人以上 / 多事业部 / 多项目并行

这个规模的核心矛盾不再是”要不要立项”，而是”总部和事业部谁说了算”。我的建议是分层立项：

• 事业部级项目：由事业部自行立项，向总部备案，总部只看收益口径和预算额度是否越界。
• 跨事业部项目：由总部 PMO 组织评审，必须明确主导方和配合方的资源承诺。
• 公司级战略项目：强制分批立项，每一批独立设关口和终止条件。

这个阶段工具的权限模型会变得非常关键。我见过太多项目因为工具不支持按事业部隔离数据，最后不得不回到线下 Excel 的情况。

4. 强监管行业（金融、医疗、军工）

这类行业的立项流程需要额外嵌入合规评审节点，通常是数据合规、安全评估、供应商资质。这些节点的特点是周期长、不可压缩。

我的建议是把合规评审尽量前挪到预立项阶段，避免在方案定型后才发现资质问题。同时，合规节点的评审结论必须作为立项决策的强制前置，不能在”有条件通过”之后再补。

这类组织对私有化部署几乎是刚性要求。选型时我会额外关注两点：一是系统本身是否满足等保或行业合规要求，二是供应商能否提供完整的部署与运维文档，因为这类组织的系统往往要运行 5 年以上。

九、不同情况下的取舍

立项管理里没有”全都对”的答案，只有取舍。下面三组取舍是我最常被问到的。

1. 速度 vs 严谨

如果业务窗口期极短，比如竞争对手下个月就要上线同类产品，那么压缩立项周期是合理的。但压缩的应该是”材料编制时间”，而不是”关键假设验证”。

具体做法是：把立项材料压缩到 5 页，但必须保留收益口径、三大风险和终止条件三栏。这三栏是底线，其余都可以砍。

反过来，如果项目周期长、投入大、涉及多方，那么宁可多花两周做预立项，也不要在方案定型后再补论证。我的经验值是：预算超过 300 万或周期超过 12 个月的项目，立项阶段投入不应低于 20 人天。

2. 集中管控 vs 业务自治

我的实际建议是混合模式：预算线以下自治，预算线以上集中。预算线的设定可以按组织年度预算的 2%-5% 来定，并且每年调整一次。

3. 自研工具 vs 采购平台

有些组织会问：立项流程不复杂，自己用低代码平台搭一个行不行？

如果只做立项审批流，自研确实可行。但立项只是项目管理的一环，立项之后的需求、迭代、测试、发布如果还在另一套系统里，数据就会断裂，立项时承诺的收益指标在项目结束后根本采集不到。

所以我的判断标准是：如果你只想要一个审批流，自研；如果你想要立项数据能一直跟到交付结果，就选能覆盖项目全生命周期的平台。

这也是我在评估 PingCode 这类平台时比较看重的一点，立项不是孤立的表单，它创建的记录应该能直接延续为后续的迭代和交付数据。对中大型组织来说，支持私有化部署和 Jira 平滑迁移这两项能力，往往比某个单点功能更能决定项目能不能推下去。

十、结语：立项是项目全生命周期里最便宜的一次纠错

回到开头那个 11 分钟批掉 380 万项目的案例。它最贵的部分不是那 210 万沉没成本，而是团队在八个月里形成的认知，”立项就是走形式，反正后面可以改”。这种认知一旦扩散，后面所有流程都会失效。

我这些年做 PMO 最深的体会是：立项环节的每一小时投入，都在替代后期十小时的救火。它便宜、可控、不伤害任何人，而且是唯一一个可以在成本几乎为零的时候叫停项目的时刻。

所以项目申请到底怎么做？我的答案是三句话：把问题说清楚，把收益验明白，把退出条件写死。PMO 的风险控制，也不是加审批节点，而是把这三件事变成必须回答的问题。

如果你的组织现在只有一份立项模板，下一步我建议先做一件事：在现有模板里加上”终止条件”和”上线后 30 天验证指标”这两栏，并规定不填不能提交。不用改流程，不用买工具，先跑三个月，看有多少项目的终止条件真的被触发了。

如果你的组织已经有 20 个以上并行项目，或者正在从海外工具迁移到国产平台，那么下一步应该做的是把立项和后续交付放进同一套数据体系里。这时候值得优先评估支持私有化部署、支持平滑迁移、并且能覆盖项目全生命周期的项目管理平台，立项数据能一路跟到交付结果，风险控制才不是纸面上的控制。

最后提醒一句：任何立项机制的目的都不是让项目变少，而是让”错误投入”变少。如果一个机制让所有项目都变慢了，那它就需要被重新设计，而不是被更强的执行力硬推下去。