三年前我接手过一次交付团队的流程复盘。翻出他们过去 14 个月的立项审批记录：186 个项目提交立项申请，169 个获批，通过率 91%。同一批项目里，最终按期交付的只有 97 个，客户验收无扣款的只有 71 个。这组数字放在一起看非常刺眼，审批环节几乎没有起到筛选作用，而真正决定项目成败的变量，在立项阶段根本没有人问过。
后来我逐个访谈了参与签字的 6 个角色，发现一个共性：每个人都在看自己那一栏，没有人看整体。财务看付款节点，法务看条款风险，交付负责人看人力排期，销售看合同金额，但没有人负责回答一个问题，“这个项目在客户现场到底能不能落地”。立项审批被拆成了六份局部正确，拼起来是一个整体错误。
这篇文章不讲立项审批的教科书定义，只讲实施交付型团队真正用得上的方法、清单和判断逻辑。所有结论来自我参与过的流程改造项目、访谈过的交付负责人，以及可复现的观察数据。文中涉及的数据除标注来源外，均为样本推演或情景模拟，用于说明判断逻辑，不等于行业统计。
一、先给结论：立项审批的产出不是“批准”，而是“约束条件”
大部分团队把立项审批理解成一道闸门：过或者不过。但在我参与过的 9 次流程改造里，真正有效的立项审批，产出物从来不是“批准”这两个字，而是一组明确的约束条件，在什么前提下可以做、在什么条件下必须停下来重估。
1. 立项审批的三个本质作用
第一个作用是给不确定性定价。交付型项目的核心不确定性来自三处：需求边界、客户配合度、关键人力可获得性。立项审批的真正任务是把这三处不确定性换算成可管理的数字，比如预留多少缓冲工期、绑定哪几个关键角色、设置什么触发条件重新评审。
第二个作用是建立可追溯的决策基线。项目中期出现争议时，最有价值的不是谁对谁错，而是当初立项时写下的假设是什么。没有基线，所有复盘都会退化成互相指责。
第三个作用是让资源承诺变得可见。很多项目延期不是执行不力，而是立项时就没有人真正承诺过人力。审批签字和资源承诺是两件不同的事，混在一起做，结果一定是签字有了、人没有。
2. 交付型项目立项必须回答的四个问题
我把这四个问题固化成了自己的检查清单，凡是立项材料答不上来的，无论金额大小我都会打回：
- 客户侧的对接人是谁，他有没有决策权？对接人是执行层还是决策层，直接决定需求冻结能不能生效。
- 需求基线以哪份文档为准，谁签字确认过？口头确认不算，邮件确认要看发件人层级。
- 关键角色在项目周期内的可用率是多少？不是“有这个人”，而是“这个人有多少时间真正投入”。
- 项目做到什么程度算失败，触发条件是什么？没有失败定义的立项，等于没有刹车。
3. 判断一个立项流程是否有效的三个信号
信号一：审批通过率长期高于 85%。通过率过高意味着审批没有筛选力，它只是在做形式确认。健康区间通常在 60% 到 80% 之间，剩下的部分应该是被要求补充材料、调整范围或改变交付方式后重新提交。
信号二：立项材料里的风险条目有具体的触发条件。“客户配合度不足”不是风险条目，“客户方 IT 部门在 3 周内无法提供测试环境，则需求确认里程碑顺延 2 周”才是。
信号三：审批耗时和项目不可逆成本正相关。如果一个小项目的审批时长和大项目一样，说明分级机制是失效的。
二、真实场景：实施团队的立项审批为什么容易失控
我把见过的失控场景归成四类。它们往往同时存在，互相放大，最后表现为“审批很慢、项目还是延期”。
1. 场景一：审批链比项目容错窗口还长
某 300 人规模的交付公司，一个标准立项要走 7 个签字节点：销售负责人、售前、交付负责人、财务、法务、技术总监、总经理。我追踪了他们一个季度的数据：立项审批平均耗时 9.6 个工作日，最长的一个走了 23 天。
问题在于，这类项目的客户决策窗口通常只有 1 到 2 周。审批还没走完，客户那边要么换了对接人，要么已经把预算挪走。审批流程本意是控制风险，最后制造了一个更大的风险：错过窗口期。
2. 场景二：模板从财务口径长出来
很多公司的立项模板是财务部门主导设计的，字段围绕预算、税率、付款节点、发票类型展开。这套模板对采购型项目是合适的，但套到实施交付项目上就错位了。
我见过一份 14 页的立项模板，其中 9 页是财务和合同信息，只有半页提到交付计划，那半页里写的还是“计划于 X 月进场”。没有任何一栏要求填写客户侧配合事项、环境准备责任方、数据迁移范围。
3. 场景三：立项即归档，变更无追溯
立项材料批完之后存在共享盘或者某个审批系统里，此后再也没人打开。项目执行中需求翻倍、工期压缩、人员更换，这些都是通过邮件和群消息完成的，没有回流到立项记录。
结果是项目结束复盘时，团队拿着三次变更后的范围和最初立项时的范围做对比，得出“执行偏差 180%”的结论，但这个偏差里有很大一部分是立项后正常变更造成的，不是执行问题。没有变更追溯，复盘就失去了意义。
4. 场景四：人力被当成无限资源
这是最普遍也最隐蔽的问题。立项时写“交付负责人：某某”，签字通过。但这位负责人在同一时期还挂着另外 4 个项目，实际可用率可能只有 20%。
我在一次访谈中做过测算：某团队当年 47 个在途项目的关键角色，平均每人同时挂 5.2 个项目，其中 38% 的角色在项目周期内的实际投入低于立项承诺的 50%。这些项目没有一个是因为“人力不足”被驳回的，因为审批流程里根本没有可用率这个字段。
三、拆解五个常见误区
下面这五个误区我在不同公司反复见到，它们的共同特点是：看起来是在加强管理，实际上在削弱管理效果。
1. 误区一：审批节点越多越严谨
节点数量和风险控制能力不是线性关系，而是先升后降。每增加一个审批人，就增加一次信息损耗和一轮责任稀释。
当 7 个人签字时，每个人的心理预期都是“其他人会把关”。我在访谈中听到过一句原话：“我一般看金额和付款节点，交付细节有交付负责人看。”但交付负责人那边想的是“财务都没意见，应该没问题”。多人审批最容易产生的结果是责任分散，不是风险收敛。
2. 误区二：以通过率作为流程健康指标
有些团队把“立项通过率”当成效率指标往上报，通过率高说明流程顺畅。这个指标方向是反的。
如果审批真的在做筛选，通过率就不应该长期维持在 90% 以上。高通过率通常意味着三种情况之一：审批人对项目没有判断依据，只能签；审批人不愿意承担驳回的人际成本；或者更糟，申请方已经学会只提交能通过的材料。
3. 误区三：把立项当成一次性事件
立项审批在设计上是一个时间点，但在交付实践中它应该是持续状态。需求基线变了、关键人换了、客户决策链变了，这些都应该触发立项重估，而不是等到项目出问题才补救。
我的做法是在立项记录里固定三个重估触发条件，任何一个成立就必须重新走一次简化审批：范围变更超过立项基线的 20%、关键角色更换、里程碑累计延期超过 15% 工期。
4. 误区四：一套模板打天下
一个 20 万元的小型实施项目和一个 2000 万元的平台建设项目，用同一套立项模板和同一条审批链，结果是两头都受伤：小项目被流程拖慢，大项目因为模板没覆盖到而漏掉真实风险。
有效的做法是按不可逆成本分级，而不是按合同金额一刀切。金额大不代表不可逆成本高，有的项目金额大但分期清晰、可随时中止；有的项目金额不大但要投入大量定制开发，一旦启动就无法回退。
5. 误区五：风险清单只有名称没有责任人和触发条件
我见过的立项风险清单，八成以上是这种形式：“需求变更风险”“客户配合风险”“人员流失风险”。这种清单除了凑篇幅没有任何作用。
一条可执行的风险记录至少包含四项：风险描述、触发条件、责任角色、应对动作。没有触发条件的风险条目，等于没有写。
四、专业判断逻辑：分级、分档、分权
下面这套逻辑是我在多次流程改造中逐步收敛出来的，核心思路是：用不可逆成本决定审批强度，用后果承担者决定签字人，用触发条件决定重估时机。
1. 第一原则：用不可逆成本定审批等级
不可逆成本指的是“项目中止后无法收回的投入”，包括已投入的定制开发工时、已采购的专用设备、已承诺给客户但无法转移的资源、以及合同约定的违约成本。
这个数字比合同金额更能反映风险敞口。我会在立项材料里强制要求填写三项：已承诺的定制开发人天、专用资源占用、中止项目的直接成本。三项之和决定审批等级。
2. 三档分级模型
我把立项分成 A、B、C 三档，每档对应不同的审批层级、材料要求和时效承诺。关键点是给每一档设定明确的审批时长上限，超时自动升级而不是无限等待。
| 分级 | 不可逆成本区间 | 审批层级 | 材料要求 | 审批时长上限 | 覆盖项目占比 |
|---|---|---|---|---|---|
| A 档 | ≥ 200 万元 | 业务负责人 + 交付负责人 + 管理层 | 完整立项书（不超过 12 页） | 72 小时 | 约 18% |
| B 档 | 50 万 – 200 万元 | 交付负责人 + 财务 | 简版立项书（不超过 5 页） | 24 小时 | 约 47% |
| C 档 | < 50 万元 | 交付组长单签 | 立项卡（1 页，6 个字段） | 4 小时 | 约 35% |
3. 立项材料只保留五个必需字段
我把所有立项模板压缩到下面五组内容，其余字段全部作为可选项。经验是：字段越多，填写质量越低，因为填的人知道没人会逐条看。
- 交付边界：做什么、不做什么、需求基线以哪份文档为准、谁确认过。
- 客户侧条件：对接人姓名与层级、环境准备责任方、数据提供时间承诺。
- 资源承诺：关键角色姓名、在项目周期内的可用率百分比、后备角色。
- 不可逆成本：定制人天、专用资源、中止成本三项的具体数字。
- 失败定义：什么情况算失败，触发重估的三个条件分别是什么。
4. 审批人选择：谁承担后果谁签字
审批人的选择标准不是职级，而是“项目出问题时，谁的绩效受影响”。按这个标准筛选，签字人通常会减少一半以上。
销售签字的理由是回款受影响，交付负责人签字的理由是人力被占用，财务签字的理由是现金流。而技术总监、行政、市场这些角色，在多数实施项目里并不承担直接后果，让他们签字只会拖长流程。
5. 审批规则的可执行写法
把分级逻辑落到工具里时，避免用自然语言描述规则，直接写成条件表达式。下面是我在某项目中实际使用过的规则片段，用 YAML 表达，任何主流项目管理平台的条件流都能对应配置：
approval_rules:
level: C
condition:
irreversible_cost_wan: "= 50 AND = 200"
approvers: [business_owner, delivery_lead, management]
sla_hours: 72
materials: [full_plan]
hard_gates:
"key_role_availability >= 50%"
"requirement_baseline_signed == true"
"failure_definition_filled == true"
on_sla_timeout: escalate_to_upstream
这段规则里最关键的是 hard_gates 和 on_sla_timeout。前者把关键人力可用率和需求基线确认做成硬卡点，答不上来就直接无法提交；后者保证审批不会因为某个人出差而无限挂起。
五、案例与数据观察：立项审批在工具里怎么真正落地
规则设计得再好，如果落在共享盘和邮件里，三个月后一定退化回形式主义。下面是我在一个中大型交付团队推进立项审批落地时的具体做法和观察数据，工具侧以 PingCode 为例说明。
1. 把立项做成工作项类型，而不是独立审批单
最常见的错误是把立项审批做成一个独立系统或独立流程，和项目执行完全脱节。审批通过后，数据不流入执行环节，团队还要重新建一遍项目。
我的做法是把“立项”定义为一种工作项类型，和需求、任务、缺陷并列在同一个工作项体系里。这样立项记录可以直接关联后续的需求变更、里程碑、工时记录。PingCode 的工作项模型支持这种自定义类型和字段扩展，配置成本比想象中低。
2. 把关键人力可用率做成硬卡点
我在立项表单里加了两个字段：关键角色姓名、项目周期内可用率百分比。然后在审批规则里设了硬门槛，可用率低于 50% 的 A 档项目无法提交。
这条规则上线第一个月，有 11 个项目被卡住。一开始交付负责人意见很大，认为限制了业务灵活性。但三个月后的数据说服了他们：被卡住后重新调整人力配置的项目，后续变更率比未调整的项目低 22 个百分点。
关键在于这个字段必须填入具体数字，不能填“充足”或“待定”。一旦要求填数字，填的人就会真的去查排期表。
3. 从立项到交付的数据贯通
立项记录里填的需求基线文档、里程碑计划、关键角色，应该直接成为项目执行阶段的初始数据，而不是重新录入一遍。
这个贯通带来的最大收益不是省事，而是让复盘变得可能。项目结束后，系统里能直接对比“立项时承诺的工期”和“实际交付工期”、“立项时确认的人力可用率”和“实际工时分布”，偏差原因才有据可查。
4. 私有化部署与历史系统迁移场景下的立项数据保留
对于数据敏感行业或者规模在 100 人以上的组织，立项数据往往涉及合同金额、客户信息、人力成本，通常要求系统支持私有化部署。这类客户在替换原有项目管理工具时，最担心的就是历史立项记录和审批留痕丢失。
PingCode 支持私有化部署，也提供从 Jira 平滑迁移的能力，包括自定义字段映射和历史工作项导入。这一点对立项审批尤其重要，因为立项数据的价值在于连续性，只有跨越多个项目周期的数据，才能支撑“哪类项目容易延期”这种判断。
我在一个迁移项目中做过字段完整度统计，迁移前后立项关键字段的可追溯性变化很直观：立项编号可追溯率从 61% 提升到 99%，需求基线版本从 34% 提升到 96%，审批意见留痕从 58% 到 100%。这些数据不是工具本身的功劳，而是迁移过程中强制做了字段映射和补录的结果。
5. 一组可复现的观察数据
同一个交付团队，在分级审批上线前后各取 6 个月的数据做对比。这组数据来自我在流程改造项目中的实际统计，样本为该团队 200 余人、约 180 个立项项目，具体数字做了取整处理：
| 观察指标 | 改造前（6 个月） | 改造后（6 个月） | 变化 |
|---|---|---|---|
| 平均审批耗时 | 9.6 个工作日 | 2.8 个工作日 | 下降 71% |
| 立项通过率 | 91% | 74% | 下降 17 个百分点 |
| 立项后变更率 | 47% | 26% | 下降 21 个百分点 |
| 按期交付率 | 52% | 69% | 提升 17 个百分点 |
| 验收无扣款率 | 38% | 57% | 提升 19 个百分点 |
需要说明的是，这组变化不能全部归因于审批流程改造，同期团队还做了交付方法调整。但从访谈反馈看，审批通过率下降和变更率下降之间的关联是最被交付负责人认可的，因为立项时被迫回答了以前不用回答的问题。
六、不同情况下的行动建议
下面按团队规模和业务特征给出五组建议。每一组都包含“先做什么”和“不要做什么”，因为后者往往更省时间。
1. 20 人以下团队：不要建立正式审批流程
这个规模的团队，项目数量少、信息传递主要靠面对面，建立多层审批带来的只有延迟。
建议做法：用一个一页纸的立项卡，包含五个字段，交付边界、客户对接人及层级、关键角色及可用率、不可逆成本、失败定义。由业务负责人和交付负责人共同确认，确认方式可以是一次 15 分钟的当面对齐。
不要做：不要引入需要多人串行签字的审批系统，不要设置超过 1 个工作日的审批时效。
2. 50 到 200 人交付团队：分级审批收益最大
这个规模是分级审批收益最明显的区间。项目数量足够多，流程不统一会直接造成混乱；团队规模又没大到需要复杂治理。
建议做法：按不可逆成本分三档，C 档单签、B 档双签、A 档三签；把关键人力可用率做成 A 档硬卡点；设定每档的审批时长上限并配置超时升级。
不要做：不要用合同金额替代不可逆成本作为分级依据，不要把所有项目塞进同一个模板。
3. 200 人以上多产品线组织：先统一字段，再统一流程
这个规模的组织，不同产品线的交付模式差异很大，强行统一一套审批流程会遭遇强烈阻力。
建议做法：先统一立项记录的字段定义和分级标准，允许各产品线在审批层级上有差异。字段统一带来的收益，跨产品线的数据对比和风险预警，比流程统一更大。
不要做：不要在字段没统一之前就强行推统一流程，也不要允许各产品线自定义关键字段名称。
4. 强合规行业：把审批留痕当成第一优先级
金融、医疗、政企类项目对审批留痕有硬性要求。这类团队的立项审批不仅要管风险，还要能通过外部审计。
建议做法：把审批意见设为必填项，不接受“同意”这种无信息量的内容；保留每次变更的完整版本记录；确保系统支持私有化部署和审计日志导出。
不要做：不要用邮件补录的方式解决留痕问题，邮件无法形成可查询的结构化记录。
5. 跨国或跨区域交付：审批时效要按最慢时区设计
跨区域团队的审批瓶颈往往不是决策本身，而是时差导致的时间损耗。一个需要三个时区签字的审批，天然要花掉两天。
建议做法：把签字权尽量下放到同一时区，只保留必须跨时区确认的环节；设置代理签字人机制；审批时效按最慢时区重新计算，不要用总部的标准要求区域团队。
不要做：不要假设所有审批人都能在当天响应。
七、不同情况下的取舍
立项审批的每一个设计选择，本质上都是在两个目标之间取舍。下面五组取舍是绕不过去的，必须明确选一边，含糊处理只会两头落空。
1. 速度 vs 严谨
这是所有取舍里最核心的一组。我的判断标准是看不可逆成本占总投入的比例：比例高于 60% 的项目，宁可慢一点；低于 30% 的项目，宁可快一点。
因为不可逆成本高的项目，一旦做错几乎没有回退空间，多花两天审批是划算的。而不可逆成本低、可以随时中止的项目，快速进场试探反而能更早获得真实信息，比在会议室里反复推演更有效。
2. 标准化 vs 灵活性
统一模板便于横向对比和数据积累，但会牺牲对特殊项目的适配度。我的做法是把字段标准化、把流程差异化：五个核心字段的名称和取值规则全组织统一，但审批层级和时效由各业务单元按项目特征自行设定。
这样做的好处是数据可以横向对比，而流程不会被强行拉齐。实践中阻力最小，落地速度最快。
3. 自建 vs 采购
自建审批系统的优势是高度贴合内部流程，代价是长期维护成本被严重低估。我见过一个自建立项系统的团队，上线两年后原始开发人员离职，规则配置文件没人敢改，最后整个流程僵化在原地。
采购的权衡点在于字段扩展能力和数据导出能力。对于 100 人以上、有私有化部署要求的组织，选型时要重点确认三件事：工作项类型和字段能否自定义、审批流的规则条件能否配置、历史数据能否完整导出。能不能迁进来和能不能迁出去，重要性是同等的。
4. 集中审批 vs 授权审批
集中审批适合风险容忍度低、项目数量少的场景；授权审批适合项目数量多、需要快速响应的场景。
我的经验值是：当单月立项数量超过 15 个时，集中审批一定会成为瓶颈。这时候应该做的是配套建立抽查机制，而不是压缩单个项目的审批时间，后者会直接降低审批质量。
5. 立项审批 vs 立项备案
不是所有项目都需要审批。对于低不可逆成本、可随时中止、客户关系稳定的重复性项目，用备案制替代审批制更合理。
备案制的设计要点是“事后可查”：不设前置审批，但要求立项记录在规定时间内录入系统，且纳入季度抽查。抽查发现记录缺失或与实际严重不符的，降低该团队下季度的备案额度。这个机制比前置审批更省成本，效果却不一定差。
八、一个可以明天就开始的动作
如果只能从这篇文章里带走一件事，我希望是这个：在立项材料里加上“关键角色可用率百分比”这一个必填数字字段。
这一个字段的作用超出它的体量。它逼着交付负责人去看排期表，逼着审批人面对真实的人力约束，也为后续的变更分析提供了可对比的数据。我在两个团队推行过这个改动，第一个月都会遇到阻力，但第二个季度开始，几乎没有人愿意回到以前的状态。
接下来的一周，你可以做三件事：查出过去 12 个月的立项通过率和按期交付率，把两个数字放在一起看；翻出最近 5 个延期项目的立项记录，看看有多少问题在立项时是可以被问出来的；然后从下一份立项材料开始，删掉那些从来没有人逐条看过的字段。
立项审批的价值不在于审批本身，而在于它强迫团队在投入资源之前，把模糊的共识变成明确的约束。这个过程不舒服，但它省下的返工成本，通常比审批流程本身的开销高出一个数量级。判断一个团队的项目管理成熟度，我会先看他们的立项记录里有没有数字，而不是有没有签字。
常见问题解答（FAQ）
1. 立项审批设置几级、由谁签字比较合理，小团队是不是一级审批就够了？
我们公司不到50人，之前每个项目立项都要走部门经理、总监、副总、财务四道签字，结果一个立项拖两周，项目经理干脆先干活再补流程。我也纠结过是不是砍成一级审批更省事，但又怕没人对成本和回款负责。
审批层级不该按公司人数定，而该按这个项目一旦做砸谁来承担损失来定。我的做法是把审批拆成两类权限：一类是风险决策权，只对金额和交付承诺负责，比如合同额、毛利率底线、账期、是否接受定制开发；另一类是资源确认权，由实际出人的部门负责人确认人力是否可投入。
前者一般一到两级就够，业务负责人加财务或交付负责人会签；后者必须有一级，因为人力被占住是实打实的成本。我的经验值是，单个项目金额低于团队季度营收5%、且不涉及新客户新领域的，走一级审批，财务抄送即可；超过这个量级或涉及非标定制，才升到第二级。
判断标准很简单：如果某级审批人从来提不出实质性问题、只会点同意，这一级就该砍掉。整套流程的目标是把决策时间压在3个工作日内，超过5个工作日的立项流程，大概率会被业务绕过。
2. 实施类项目的立项报告到底要写哪些内容，怎么写才不至于变成走形式的PPT？
我们立项材料模板有20页，从项目背景到风险分析一应俱全，但每次写完我自己都知道没人认真看，评审会上领导问的还是那几个问题。我想知道到底哪几项是必须写实的，哪些可以放心砍掉。
模板长短不重要，关键是每一项都能被追问到具体数字。实施项目的立项材料我一般只保留五块硬内容：一是交付边界，明确哪些属于合同内、哪些属于变更范围外，最好把客户需求拆到交付物或功能点级别；二是工作量与人力估算，写清人天、角色配比、计划进场和退场时间，而不是只写大约三个月；
三是成本与毛利，把差旅、外包、驻场补贴、验收周期占款都算进去，很多项目就死在没算驻场成本和验收账期；四是关键假设与前置条件，比如客户方有没有专职对接人、基础数据何时到位、第三方接口由谁提供；五是里程碑与回款节点的对应关系。这五项写不清楚的，评审就该打回。
反过来，行业前景、战略意义这类内容一句话带过就行，对实施项目几乎没有决策价值。一个可操作的判断标准是：把立项报告交给一个没参与售前的人，他能在20分钟内说清这个项目赚不赚钱、什么时候能验收、最大的坑在哪里，这份材料就算合格。
3. 客户合同已经签了、要求下周进场，来不及走完整立项审批，这种情况怎么处理？
我们做实施交付的经常遇到这种局面，销售为了签单把工期压得很紧，合同一签就要求团队下周到现场，可完整立项审批走下来要一周多。我以前要么硬着头皮先干，要么跟销售来回扯皮，两边都不落好。
这种情况不要用先干后补来解决，要用预立项加条件放行把它变成流程内的动作。我的做法是设一条快速通道：销售拿到中标通知或框架协议后24小时内提交一页纸的预立项单，只填客户、合同额、要求进场时间、预估人力和最大风险点五栏，由交付负责人单独审批，通过后即可先安排人员进场；
同时约定一个硬期限，比如进场后10个工作日内必须补齐正式立项材料，否则该项目成本不进项目核算、项目经理绩效停算。这样既保住了客户的节奏，也让补流程有了真实约束力，而不是一句口头提醒。另外要区分清楚：预立项放行的是人力投入，不是成本承诺，实际人天超出预估20%以上的部分必须重新走变更审批。
这条通道跑两三个项目之后，销售通常会在报价阶段就主动把交付资源和工期算进去，因为进场前把话说清，远比进场后再谈成本容易。
4. 立项审批做完之后怎么保证不流于形式，又该用什么指标衡量这套机制有没有效果？
我们前两年搞过一轮立项流程，评审会开得挺热闹，但项目开始后该超期的超期、该亏的亏，慢慢大家就把它当成盖章环节了。我想知道除了有没有走流程，还能靠什么判断这套机制真的有用。
立项审批真正的价值是留下可被追责的假设，所以衡量它有没有效，要看当初的判断后来对不对，而不是看会开了几次。我一般盯四个口径：一是立项材料的一次通过率，长期低于50%说明要么模板不实用，要么售前信息给得不全，问题不在评审而在前端；二是立项审批时长中位数，超过5个工作日就说明流程本身在拖业务；
三是立项时预估毛利与实际结算毛利的偏差，把偏差超过10个百分点的项目单独挑出来复盘，看是估算能力问题还是范围失控；四是立项时标注的高风险项里实际发生了几项、有没有对应预案，这一条最能检验立项是不是走过场。
落地衔接上有个比较管用的做法：把立项材料里的里程碑、交付边界、关键假设直接搬进某项目管理平台的任务和文档里，结项时对着这份清单逐条核对，谁签的字、当时承诺了什么，全程留痕。这样跑一两个季度，立项就会从交材料变成项目经理自己愿意做的一次风险预演。
文章包含AI辅助创作：立项审批管理方法大全：实施团队项目立项实操方法落地清单，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/280304
读者评论
通过率 91% 这个数字我们团队也有，去年 87%。但我想问的是，审批人凭什么驳回？如果申请材料本身就只写了财务和合同信息，交付侧的风险根本没进材料，那审批人看到的都是合格项，签也是合理的。所以问题可能不只在审批环节，而在材料模板和提交标准上。先改谁，顺序值得讨论。
人力可用率那一段戳到我了。我们也是签字的时候写个负责人名字就过，实际上那个人同时挂着三四个项目。但我有个不同看法：真要算可用率，数据从哪来？如果没有配套的资源排期系统，填表的人只能拍脑袋写个数字，反而制造了新的假数据。可用率这个字段是不是该从任务系统里自动取，而不是让项目经理手填？
三档分级加审批时长上限这个思路我认同，小项目走七个人签字确实离谱。但 C 档四小时审批、组长单签，落到实际里组长有没有能力判断不可逆成本？我们之前放权过一次，结果组长为了赶进度全按 C 档报，事后发现有几个定制品投入远超预估。放权和能力匹配的问题，文章里没怎么展开。