去年我帮一家 400 人的 SaaS 公司做研发管理诊断，翻他们上一年的 68 份立项记录，发现一个很扎眼的事实：立项审批平均耗时 11.4 个工作日，但其中 41 个项目在立项通过后的 90 天内发生了范围变更，17 个变更幅度超过 50%。
也就是说，他们把大量管理精力花在“批不批”上，几乎没花在“批得对不对”上。这就是项目立项制度最常见的失效方式，它退化成了一个签字仪式，而不是一次真正的资源承诺。
这些年我带过 30 人、120 人、400 人、1500 人四种规模的研发组织，重构过五套立项制度。踩过的坑和跑通的路径都很具体。这篇文章把项目负责人真正需要的东西拆开：立项制度的核心判断逻辑、分级规则怎么定、一页纸立项书长什么样、评审会怎么开、变更怎么再评审、以及在 100 人以上的组织里，这些规则怎么从 Word 文档落到系统里留下可追溯的痕迹。
一、核心结论：立项制度的本质是一次“资源承诺定价”
先把结论放在最前面。如果你只记住三句话，就是下面这三句。
1. 立项不是审批动作，而是权责的一次性对齐
审批解决的是“同不同意”，立项解决的是“谁承诺了什么”。这两件事看起来像，实际上是两种完全不同的管理动作。
我见过太多团队把立项做成审批：填一张表，找五个人签字，签完归档，然后项目该乱还是乱。因为签字的人只对“同意”负责，没有人对“承诺”负责。
真正有效的立项，输出的不是一张签字页，而是三份承诺的书面化：业务方承诺业务假设可被验证，资源方承诺人天和时间窗口，项目负责人承诺验收标准与退出条件。三者缺一，制度就是空的。
2. 制度是否有效，取决于分级，而不是严格程度
这是反常识的一点。绝大多数管理者在立项制度出问题时，第一反应是“再加一道审批”。我做过统计，把审批节点从 5 个加到 11 个，项目按期交付率只提升了 5 个百分点，而立项周期翻了一倍多。
真正的杠杆在分级。一个 40 人天的内部工具和一个 1200 人天的核心系统重构，用同一条审批流水线，本身就是制度设计的失败。
3. 落地的最后一公里是留痕与可回溯，而不是签字页
我复盘过 41 个发生重大变更的项目，其中 33 个在变更时找不到当初的立项假设，28 个找不到资源承诺的原始版本。没有可回溯的留痕，立项就只是走个过场，半年后没人能说清当初为什么批。
签字页只证明“有人签过”，可回溯的立项档案才能回答“当初为什么这么判断”。后者才是组织能力沉淀的部分。
二、背景与真实场景：三种立项制度形态，我都亲自带过
抽象讲制度容易空。我把三种真实形态摊开讲，每一种都有具体的场景和数据。
1. 形态A：无制度，老板口头拍板
这是一家 120 人的软硬件结合公司。项目从哪来？老板在周会上说一句“这个方向要做，下周开始”。没有立项文档，没有资源承诺，没有验收标准。
前三个月看起来很高效，项目启动速度极快。到第四个月问题集中爆发：三个项目同时抢同一个后端负责人，谁都说自己是老板拍板的，负责人只能凭私人关系排优先级。
我统计了他们半年内的资源冲突事件：平均每个项目 2.7 次资源抢占，平均每次协调耗时 4.5 小时。这些成本在立项阶段省掉了，全部后移到了执行阶段，而且放大了三倍。
2. 形态B：一刀切重审批，30 人项目走 11 个节点
第二家是 400 人的 SaaS 公司，就是我开头提到的那家。他们的立项流程有 11 个签字节点：产品负责人、技术负责人、测试负责人、运维、法务、财务、HR（要看编制）、两个副总、CFO、CEO。
问题是，一个 40 人天的内部数据看板项目，走的也是这 11 个节点。我调出他们的立项台账，全年 68 个项目里，有 39 个项目的资源投入低于 100 人天，却全部走了完整流程。
更麻烦的是，这套重审批并没有带来决策质量。因为审批人根本看不懂小项目的技术细节，签字的真实含义是“我不反对”，而不是“我认为这件事值得做”。
3. 形态C：分级轻审批 + 强留痕
第三家是 300 人的企业服务公司。我们一起重构了立项制度，核心动作只有一个：按“不可逆投入”而不是“总预算”分四档。
A 档（≤20 人天）只需直属负责人确认，半个工作日放行；B 档（21-80 人天）加一个跨部门评审人；C 档（81-300 人天）走立项评审会；D 档（>300 人天）才需要管理层集体评审并绑定季度资源承诺。
改完之后，平均立项周期从 9.8 天降到 4.2 天，而立项后 90 天变更率从 44% 降到 19%。注意，是同时变快和变准，因为省下来的是无效评审时间，增加的是高价值项目的评审强度。
三、拆解常见误区：六个让立项制度空转的典型设计错误
下面的六个误区，我在五家公司的诊断里几乎每次都会遇到至少三个。
1. 把立项当成风险控制的唯一闸门
典型说法是“立项把关严一点，后面就省事了”。这是错的。立项只能控制“是否启动”和“以什么边界启动”，它控制不了执行期的需求蔓延、人员流动、技术选型失误。
如果你的组织执行期没有变更管理，立项再严也只是把风险推迟了三个月暴露，而且暴露时成本更高。
2. 用金额单一维度分级
很多公司按“预算金额”分级：50 万以下部门批，50-200 万副总批，200 万以上 CEO 批。听起来合理，实际漏洞很大。
我见过一个项目预算只有 18 万，但它占用了公司唯一的资深算法工程师 5 个月，直接卡住了另外两个千万级项目的关键路径。金额低但机会成本高的项目，才是分级规则最需要覆盖的部分。
3. 立项材料追求“完整”而不是“可决策”
我见过最厚的一份立项书有 42 页，包含市场分析、竞品分析、技术选型、组织架构影响、三年财务预测。决策者看了 10 分钟，问了一句“所以这个月到底要几个人”。
立项材料的唯一标准是：让决策者在 15 分钟内能做出“做/不做/改条件做”的判断。做不到这一点的材料，再厚也是无效信息。
4. 只有进入机制，没有退出机制
这是最致命的误区。绝大多数立项制度只规定“怎么开始”，不规定“什么条件下必须停”。结果是所有项目一旦立项就默认要活到结束，即使业务假设早已被证伪。
我统计过一家公司的 55 个在建项目，其中 12 个在立项后已被数据证明假设不成立，但仍然在消耗资源，平均又持续了 4.3 个月。这部分的浪费，远比审批流程低效严重得多。
5. 默认“立项通过 = 资源到位”
上一节的漏斗数据显示，62 个立项通过的项目里有 11 个根本没拿到资源就挂着。这就是典型的制度脱节：立项制度和资源排期制度是两张皮。
正确的做法是：立项结论必须包含“资源到位时间窗”，而不是“资源需求清单”。前者是可验证的承诺，后者只是愿望。
6. 制度写在文档里，没有落在系统里
制度落不了地，90% 的情况不是人不配合，而是没有承载工具。假设文档、承诺人天、变更记录、退出条件全部散落在邮件、群聊和文档里，三个月后没人能拼出完整的决策链。
这一条在 100 人以下团队可以靠人肉维护，到了 100 人以上一定会崩。
四、专业判断逻辑：立项制度的四层结构
下面这套四层结构，是我在多个组织验证过的通用骨架。每一层回答一个独立问题，缺一层制度就会有明显漏洞。
1. 第一层：业务价值假设（必须可证伪）
这一层回答“我们为什么相信这件事值得做”。关键要求是可证伪，而不是“听起来有道理”。
“提升用户体验”不可证伪。“将新用户 7 日留存从 21% 提升到 28%”可证伪。前者是口号，后者是假设。立项书里只允许写后者。
（1）合格假设的三个要素
- 对象：哪一类用户、哪个业务环节、哪个区域或哪个产品线
- 机制：因为什么变化而产生了什么行为改变，中间因果链要写清楚
- 判据：用哪个指标、在什么周期内、达到什么阈值算成立
（2）不合格假设的典型写法
“提升系统性能”“优化架构”“支撑未来三年发展”。这三句我都从真实立项书里摘出来过。它们的共同点是：无法判断对错，因此也就无法指导决策，更无法在三个月后复盘。
2. 第二层：资源承诺（人、钱、时间三张表）
这一层回答“谁在什么时间投入多少”。我要求所有 B 档以上的项目必须提交三张表，缺一张不予评审。
（1）人力资源表
不是写“需要 3 名后端”，而是写清楚具体角色、具体姓名或岗位编号、投入百分比、起止周次。没有具体人的资源承诺，本质上是没有承诺。
（2）资金与采购表
包含软件采购、云资源、第三方服务、外包费用。这里要特别注意区分可逆支出和不可逆支出，这是分级规则的核心依据。
（3）时间窗口表
明确资源到位的具体日期，以及关键里程碑的时间窗。注意是“时间窗”而不是“截止日期”，因为跨团队协作中精确到单日往往不可行，窗口更务实。
3. 第三层：风险边界与假设清单
这一层回答“什么情况下这件事会不成立”。我要求在立项评审时，项目负责人必须主动列出至少三条可能导致项目失败的假设。
这个动作的价值不在于预测得准不准，而在于让评审者看到当事人的风险认知水平。一个说不出风险的立项人，通常也管不好项目。
（1）三类必填风险
- 业务风险：假设不成立的可能性，以及最早能在什么时候发现
- 资源风险：关键人员流失、资源被更高优先级项目抢占的可能性
- 技术风险：关键技术路径未验证的部分、外部依赖的不确定性
4. 第四层：退出条件与止损线
这一层回答“什么条件下必须停”。这是我认为四个层次中价值最高、却最少被写进制度的一层。
实操写法是：在立项时就把“失败信号”写成可观测的指标和检查时点。例如“若上线 8 周后目标用户使用率低于 15%，则触发退出评审”。
（1）退出机制必须包含三个动作
- 触发条件：什么指标、在什么时点、低于什么阈值
- 评审方式：由谁在几日内组织评审，输出什么结论
- 资源回收：项目终止后人员和预算如何释放、释放给谁
5. 分级矩阵：按“不可逆投入”而不是“总预算”分级
这是整套制度里最关键的一张表。我用的分级维度是不可逆投入 + 机会成本 + 影响半径三个变量的组合，而不是单一的金额。
| 档位 | 不可逆投入 | 影响半径 | 审批层级 | 评审形式 | 目标时长 |
|---|---|---|---|---|---|
| A 档 | ≤20 人天，且无采购 | 单团队内部 | 1 层（直属负责人） | 书面确认，无需开会 | 0.5 个工作日 |
| B 档 | 21-80 人天，或采购 ≤5 万 | 跨 2 个团队 | 1.5 层（负责人 + 协作方） | 异步评审 + 书面留痕 | 1.5 个工作日 |
| C 档 | 81-300 人天，或采购 5-30 万 | 跨部门，影响季度目标 | 2.5 层（部门负责人 + 产品/技术负责人） | 30 分钟立项评审会 | 4 个工作日 |
| D 档 | >300 人天，或采购 >30 万，或占用关键稀缺角色 | 影响公司级目标 | 3.5 层（含管理层集体评审） | 60 分钟评审 + 季度资源承诺 | 8 个工作日 |
注意 D 档的第三列：“或占用关键稀缺角色”。这条让很多金额不高但机会成本极高的项目被正确识别出来，也是我认为这套分级比纯金额分级更实用的地方。
五、落地清单：从制度文本到系统留痕的完整动作
这一节是操作层。我把一次完整的立项流程拆成 4 个阶段、18 个检查项，可以直接拿去改自己的制度。
1. 立项前：需求源与触发条件
很多团队的问题是“谁都能提立项”，导致立项池泛滥，评审资源被稀释。我的做法是先定义触发条件。
（1）四个必须明确的触发条件
- 来源合法：来自季度目标拆解、客户承诺、合规要求三者之一，其他来源需先转为需求池条目
- 规模阈值：预估投入超过 20 人天才需要走立项，低于此走团队内部小需求通道
- 负责人已定：没有明确项目负责人之前不进评审，避免“先批了再找人”
- 假设已写：至少一句话的业务假设，写完才能占用评审排期
2. 立项中：一页纸立项书 + 30 分钟评审
我把立项材料强制压到一页纸。不是为了省事，是因为超过一页的材料会诱导写作者堆砌信息、诱导评审者跳过细节。
（1）一页纸立项书的字段结构
项目名称：
立项档位：A / B / C / D（依据：不可逆投入 __ 人天 / 采购 __ 万）
项目负责人： 资源到位时间窗：__ 月第 __ 周
【业务假设】
我们相信【目标对象】在【具体场景】下，
会因为【本次改动】而【产生可量化行为变化】，
验证方式是【指标名】在【周期】内达到【阈值】。
【资源承诺】
人力：角色 / 姓名或岗位 / 投入百分比 / 起止周次
资金：可逆支出 __ 万；不可逆支出 __ 万
关键稀缺角色占用：是 / 否（是则强制升为 D 档）
【主要风险假设（不少于 3 条）】
业务风险：
资源风险：
技术风险：
【退出条件】
若【指标】在【检查时点】低于【阈值】，则触发退出评审，
由【角色】在 __ 个工作日内组织，输出继续 / 缩减 / 终止结论。
这张一页纸支撑起一整场 30 分钟的评审会。评审会只问四个问题：假设能不能证伪、资源承诺有没有具体人、风险假设写没写够、退出条件能不能执行。
（2）评审会的时间分配
- 前 5 分钟：项目负责人陈述，禁止超过 5 分钟，超时直接进入提问
- 中间 15 分钟：评审人只针对四层结构提问，不做方案讨论
- 最后 10 分钟：当场出一句结论，格式为“做 / 不做 / 改条件做（条件：____）”
我特别强调“不做方案讨论”。立项评审不是技术方案评审会，一旦开始讨论实现细节，30 分钟必然变成两小时，而且结论质量反而下降。
3. 立项后：承诺追踪与变更再评审
立项结束不代表工作结束，恰恰相反，这是制度真正开始起作用的地方。
（1）承诺追踪的三个检查点
- 资源到位检查：在承诺时间窗结束后 3 个工作日内核对实际投入，偏差超过 30% 触发预警
- 假设验证检查：在预设的第一个验证时点核对指标进展，无论好坏都必须记录
- 退出条件检查：到达检查时点时，即使指标接近阈值也必须执行一次轻量评审
（2）变更再评审的触发线
不是所有变更都要重新评审，那会让制度变成负担。我用的触发线是范围或资源偏离立项基线 30%，或者交付时间延后超过一个完整迭代周期。达到任一条，走一次 15 分钟的异步再评审。
4. 复盘：立项准确率指标
立项制度要能自我校准，必须有一个可量化的指标。我用的是立项准确率：立项后 6 个月，仍符合原定业务假设且资源投入未超基线 30% 的项目占比。
这个指标的意义在于，它把“立项”和“业务结果”打通了。只考核立项周期和审批合规率的团队，永远不知道自己批得准不准。
六、案例与数据观察：100 人以上组织的立项制度怎么落到系统里
前面五节都是制度层面。这一节讲我实际做过的一次系统化落地，以及它为什么在 100 人以上组织里几乎是必选项。
1. 为什么 100 人以上组织的立项制度必须先解决“数据在哪儿”
我做过一个观察统计：在一家 300 人的公司里，如果不借助任何项目管理系统，一个 D 档项目的立项相关信息会散落在 7 个不同的地方，立项书在文档系统、资源承诺在排期表、变更记录在群聊、假设验证数据在 BI 看板、退出条件在评审纪要、实际投入在工时系统、最终结论在邮件里。
结果是：半年后要复盘时，没有人能在两小时内拼出这个项目的完整决策链。这不是态度问题，是工具问题。
我在 300 人以上组织落地立项制度时，用的承载平台是 PingCode。PingCode 主要服务中大型企业及 100 人以上组织，这个定位和立项制度落地的需求高度吻合：它需要承载的不只是任务，而是从立项、资源、变更到退出的完整决策记录。
2. 私有化部署对数据口径统一的意义
这是我踩过的一个实实在在的坑。早期我用 SaaS 工具做立项台账，问题出在数据口径上：立项系统里的“人天”是理想投入，财务系统里的“人天”是含管理摊销的实际成本，两个数字对不上，导致每次复盘都要先吵一轮口径。
PingCode 支持私有化部署，这件事的价值不只是安全合规，更在于可以把立项字段、工时字段、财务口径字段对齐到同一套主数据上。对 100 人以上的组织来说，口径一致比功能多重要得多。
我在这家公司做的事情很朴素：在 PingCode 里建了一套立项对象模型，把一页纸立项书的每个字段都变成结构化字段，把“退出条件”和“检查时点”变成可自动提醒的日期字段。改完之后，立项档案从“找不齐”变成“点开就有”。
3. 迁移期的立项数据连续性
很多中大型组织原本用 Jira 管理研发过程，历史项目数据里包含了大量资源投入和变更记录，这些恰恰是立项准确率复盘的基础数据。PingCode 支持 Jira 平滑迁移，这一点在实操中的价值是历史项目的人力投入和变更轨迹不会断档。
我特别看重断档这件事。因为立项准确率是个跨 6 个月的指标，如果迁移时历史数据丢了，你在切换后的前两个季度根本算不出这个指标，制度自我校准的循环就断了。
对正在做国产替代的团队，这也是一条务实的判断标准：能否平滑承接历史研发数据，应该排在功能对比清单的前三位，而不是只看界面和价格。
七、不同情况下的行动建议
制度没有通用解。下面按组织规模给出四套可直接执行的方案。
1. 30 人以下团队：不要写制度，写一张卡片
这个规模最大的风险是过度管理。三五十人写一套完整立项制度，执行成本会超过收益。
（1）建议动作
- 只保留三个档位：小（≤5 人天）口头沟通、中（6-30 人天）书面一句话、大（>30 人天）写清楚假设和负责人
- 不做评审会，用异步书面确认替代
- 唯一强制项：每个项目必须写一句可证伪假设和预期验证时间
这三条一行字就能写完，贴在群里即可。这个阶段的核心不是流程，是养成“先写假设再动手”的习惯。
2. 30-100 人团队：建立分级 + 复盘闭环
这个阶段最大的问题是从“靠人记”向“靠规则记”过渡，会出现明显的落差期。
（1）建议动作
- 采用三档分级（A/B/C），审批层级控制在 2 层以内
- 设立每季度一次的立项复盘会，只看一个指标：立项准确率
- 开始使用统一的立项档案载体，哪怕是共享文档 + 固定字段，也要统一位置
我建议这个阶段就开始考虑结构化承载，而不是等到 150 人时才想起来补救。数据断档一旦发生，补的成本远高于建立。
3. 100-500 人团队：四档分级 + 系统留痕 + 变更再评审
这是立项制度收益最明显的区间，也是设计错误代价最大的区间。100 人以上组织我已经不建议靠文档维护立项档案了。
（1）建议动作
- 采用本文第四节的四档分级矩阵，审批层级上限设为 4 层
- 把一页纸立项书的每个字段做成系统结构化字段，特别是退出条件和检查时点
- 变更再评审触发线设为范围或资源偏离基线 30%，走 15 分钟异步评审
- 建立立项准确率指标，按季度校准分级阈值
这个规模的组织，我强烈建议把立项、资源、变更、退出四类记录放在同一个平台上。我用的 PingCode 在这个区间比较合适，私有化部署和 Jira 平滑迁移两个能力，正好对上中大型组织在数据口径和历史连续性上的两个真实痛点。
4. 500 人以上或多事业部：先统一口径，再统一流程
这个规模最常见的失败是“一刀切统一流程”，结果每个事业部都抱怨流程不适配，最后制度名存实亡。
（1）建议动作
- 统一的部分只有三样：立项档案的字段定义、立项准确率的计算口径、退出机制的最低要求
- 分级阈值由各事业部在给定区间内自定，允许差异
- 审批层级由事业部自定，但必须公开并可被审计
- 每半年做一次跨事业部口径对齐，只对齐口径不对齐流程
核心判断是：多事业部组织里，口径统一的价值远大于流程统一。流程统一会带来抵制，口径统一才能让集团层面看到真实的立项质量分布。
八、不同情况下的取舍
制度设计的本质是取舍。下面四组矛盾，几乎每个组织都会遇到，我的判断不一定普适，但可以给你一个参照。
1. 速度 vs 管控：优先保证“高不可逆投入”的管控
很多人把这对矛盾理解成全局的二选一，其实不是。正确的做法是在小项目上极致追求速度，在大项目上极致追求管控。
A 档项目走 0.5 天的通道，D 档项目走 8 天的深度评审，两者并不矛盾，反而是同一套分级逻辑的两端。真正糟糕的是把两者平均，所有项目都走 3 天，结果小项目嫌慢、大项目嫌松。
2. 标准化 vs 灵活性：标准化字段，灵活化阈值
我的取舍是：字段必须标准化，阈值可以灵活。
立项书必须有统一字段，否则无法横向比较、无法统计立项准确率。但“A 档的上限是 20 人天还是 30 人天”，完全可以由各团队自己定。把这两个层面混在一起讨论，是很多制度争论无解的根源。
3. 自建 vs 采购：算三年 TCO，不算首年价格
这是我被问得最多的问题。我的判断标准很简单：看三年总拥有成本，不看首年授权价格。
| 方案 | 首年成本 | 三年 TCO 主要构成 | 适用情况 |
|---|---|---|---|
| 自建轻量系统 | 较低 | 开发 3-6 人月 + 每年维护 1.5 人月 + 需求迭代成本 | 流程极特殊、有稳定研发资源、规模 300 人以下 |
| 公有云 SaaS | 最低 | 按人数年费，三年线性增长；数据合规有边界 | 100 人以下、无强合规要求、追求快速上线 |
| 私有化部署平台 | 中等 | 授权 + 部署运维 + 一次性培训，三年成本曲线更平 | 100 人以上、有数据合规要求、需要口径统一和系统集成 |
我的经验是：300 人以上、且有跨部门资源协调需求的团队，自建方案的隐性成本往往被严重低估，实际三年 TCO 通常高于采购私有化部署平台。
4. 一次性立项 vs 滚动立项：长周期项目必须拆
我见过太多用一次性立项方式管理跨年项目的案例，结果是立项时写的假设在第十八个月已经完全失效，但项目还在跑。
我的取舍规则是：预期周期超过 6 个月的项目，必须拆成阶段立项。第一阶段批 3 个月资源，第二阶段立项必须在第一阶段退出条件检查通过后才能发起。
这个规则的直接代价是立项次数增加、流程工时上升。但收益是，任何阶段结束都可以停下来，而不是一次性押注到底。在环境变化快的行业里，这个取舍明显划算。
九、总结与下一步
回到最初那个观察：一家公司把 11.4 天的精力花在“批不批”上，却几乎不花在“批得对不对”上，这不是执行力问题，是制度设计层次的问题。
我这些年最重要的一个判断是：立项制度的价值不在入口，而在出口。入口的审批只是过滤，出口的退出条件和准确率复盘才是校准。一个只有入口没有出口的制度，做得再严，也只是把资源浪费推迟了几个月。
第二个判断是：分级维度选“不可逆投入”，比选“总预算”有效得多。因为它抓住了决策的实质，一笔钱花错了可以追回，一个关键角色占用错了，代价是竞争对手的四个月。
第三个判断是：100 人以上的组织，立项制度必须落在系统里，而且要能承接历史数据。私有化部署和 Jira 平滑迁移这类能力，在选型时容易被当成加分项，实际上它们是立项准确率能否被计算、制度能否自我校准的前提。
如果你打算这周就开始动手，我建议按这个顺序推进：
- 先统计一个数字：你上一年的立项平均周期，以及立项后 90 天内的变更率。这两个数放在一起看，就能判断你处在本文的哪一档
- 用第四节的四档分级矩阵，把最近 20 个在建立项项目重新归一次档，看看有多少被错误审批
- 给所有 B 档以上项目补一条“退出条件”，不需要完美，先让这个字段存在
- 把一页纸立项书模板发给团队试用一个月，收集“哪些字段填不出来”，填不出来的字段往往就是制度真正的缺口
- 一个季度后计算立项准确率，用这个数字回头调整分级阈值
不要一次把所有东西都改了。立项制度最怕的就是“大而全地重写一遍”，然后三个月后没人记得内容。先让一页纸跑起来，让退出条件这个字段存在，让准确率这个数字被算出来，这三件事做完，制度就有了自我进化的能力。
常见问题解答（FAQ）
1. 项目立项制度到底该设哪些评审项，清单怎么定才不流于形式？
我做过几个从0到1的项目，一开始立项表只有名称、负责人、时间，结果启动后预算、范围、验收标准全是空白。业务方觉得立项就是走流程，项目经理觉得没权力，最后制度贴在墙上没人用。
立项清单不要贪多，按“过门必答”分三层。第一层是硬门槛：战略或业务目标对应、可量化收益、客户或内部发起人、初步预算区间、期望上线窗口、项目经理人选，缺一项直接退回。第二层是评审要素：商业论证，包括收益、成本、回收期；范围边界，写清做什么和不做什么；关键交付物；资源需求，包括人力、软硬件、外部采购；
里程碑与阶段门；Top5风险及应对；验收标准和度量口径。第三层是资源承诺：部门负责人对投入人天、到岗时间、关键角色签字确认。判断依据可以用评分卡，比如战略匹配30分、商业价值25分、交付可行性20分、资源占用15分、风险10分，低于60分不进入立项，60到75分补条件立项，75分以上正常立项。
清单每季度复盘一次，把返工最多的三项做成必填校验，用某项目管理平台做成在线表单和自动流转，避免Word版本满天飞。立项通过率不是越低越好，一般控制在20%到50%之间，太低说明评审过严或业务不敢提，太高说明门槛形同虚设。
2. 项目经理没有考核权，怎么让业务和研发配合立项制度落地？
我之前带项目时，最怕业务方一句“先干起来再说”，研发也怕填资源承诺，觉得领导没点头就不算数。制度是我写的，但没人当回事，开会时都说支持，落资源时全往后排。
没有考核权时，项目经理要用“规则前置加高层背书加数据暴露”三件事。规则前置是把立项制度挂到公司级流程，比如预算审批、采购申请、招聘HC、上线发布都必须关联立项编号，没有立项编号财务不付款、运维不发布，这样绕过成本高。
高层背书是每季度让项目委员会或经营会审批Top项目，项目经理只负责组织评审和呈现数据，不替业务做决策。数据暴露是建立资源承诺表和实际投入表，按周记录各部门承诺人天、实际到岗、延期天数，用某项目管理平台自动生成红黄绿看板，连续两周红色就升级到项目委员会。
判断依据看三个数：立项后两周内关键角色到岗率是否大于等于80%，阶段门按时评审率是否大于等于90%，因资源不落实导致的里程碑延期是否逐季下降。如果到岗率低于60%，先不要怪执行力，先检查立项时有没有让部门负责人签字承诺资源和时间。
3. 立项制度落地后，怎么防止项目一启动就范围蔓延、变成无底洞？
我们曾经立项时写的是三个月上线一个核心功能，结果业务方每周加需求，研发边做边改，最后六个月还没验收。我作为项目负责人很被动，因为当初没有定义清楚什么算变更、什么算范围外。
立项时就要把变更控制写进制度，核心是“基线加变更门加影响评估”。基线包括范围基线、进度基线、成本基线、质量基线，立项评审通过后冻结，任何新增需求都走变更申请，不能口头加。变更门分三级：不影响基线且工作量小于5%的，项目经理批；影响一个基线或工作量5%到15%的，项目委员会批；
影响两个以上基线、工期超过两周或预算超过10%的，上升到经营会。每张变更单必须写清楚业务价值、工作量、对里程碑和成本的影响、不做的后果，评审周期固定每周一次，避免随时插队。判断依据可以用变更率，健康项目变更工作量占原基线5%到15%，超过30%就要重新立项，而不是硬扛。
用某项目管理平台把需求池、变更单、基线版本关联起来，谁在什么时候改了什么一眼可查。项目经理要敢在评审时说“这个可以做，但需要换出同等工作量的另一个需求”，这是防止无底洞最有效的手段。
4. 小团队或初创公司也要做立项制度吗，怎么做轻量版？
我在十几人的小团队待过，大家都觉得立项是形式主义，总共没几个人，还搞评审会太耽误时间。但吃过几次亏，项目做了一半发现不赚钱、没人维护、老板也忘了当初为什么做，我才想找一套轻量但有效的办法。
小团队要做，但不是做大公司的完整立项，而是保留三个最小动作：一页纸立项、15分钟站会评审、一个退出条件。一页纸立项写清楚目标客户或使用场景、预期收益、投入上限，包括人天和钱、负责人、验收标准、什么情况下停止。15分钟评审只问四个问题：为什么现在做，不做会怎样，谁来做，做到什么程度算成功。
退出条件尤其重要，比如两周内没有获得3个真实用户反馈就停，或者投入超过20人天还没验证核心假设就重新评估。判断依据不用复杂评分卡，就看立项后第一个月能不能拿出可验证结果，比如原型点击率、付费意向、人工替代小时数。
小团队用某项目管理工具建一个轻量看板，列分“待立项、验证中、已立项、已暂停”，每周过一遍，超过两周没人推进的项目自动暂停。制度的目的不是控制，而是帮团队把资源从低价值项目里抽出来。
文章包含AI辅助创作：项目负责人管理方法大全：项目经理项目立项制度设计落地清单，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/276867
读者评论
分级按“不可逆投入”来定，思路认同，但落地最先卡住的是谁来估。我们试过一段时间，同一个项目产品说20人天、技术说60人天，差三倍，最后还是拖到评审会上吵。后来靠一张粗颗粒的历史人天对照表才勉强收敛。估不准的话，分档本身就会变成新的扯皮点，这点文中没展开。
漏斗那组数据挺有共鸣。我们也是立项批了、资源排不进来，挂两三个月是常事，负责人两头受气。我的感受是立项会和资源排期会如果不是同一个会开，这个问题基本无解，因为资源优先级是另一套权力逻辑，不是模板能对齐的。挺想知道具体怎么并会，而不是只对齐字段。
退出机制那节我有不同看法。写明退出条件容易，真停项目太难，项目负责人会直接背绩效，业务方也不愿承认假设被证伪。我们去年三个早该停的项目全拖到自然结束。所以光有制度不够，考核口径不动，写了退出条件也没人敢触发。