立项审批最佳实践：实施团队项目立项最佳实践，常见问题

我做过一件挺蠢的事。2021 年我接手一支 80 人的实施交付团队，上任第一周就把立项审批从“每三天一次评审会”压缩成“每周五一次集中过会”，本意是提速。三个月后团队交付毛利率掉了 6 个百分点，而我翻遍所有立项审批记录，表决栏里清一色写着“同意”。那一刻我才明白：立项审批失效，通常不是审批的人不认真，而是会上讨论的东西，和项目真正赚钱或亏钱的原因几乎不重叠。

这篇文章我想把“实施团队项目立项审批”这件事讲透。它不是流程文档里的一段描述，而是实施型组织里最贵的一道关口：一次错误的立项，意味着几十人天的人力被锁死在半年内，意味着一个本来能做三个好项目的团队被拖进一个烂项目。我会把我踩过的坑、抽样看到的数字、以及一套可落地的门禁设计写出来，包括我们后来在一家 400 人规模的实施型公司里，用 PingCode 重构立项审批的真实过程。

一、核心结论：立项审批不是“要不要做”，而是“以什么代价做、由谁承诺”

先把结论放在前面。如果你只记住这一节，后面的内容你可以当成论证过程来读。实施团队立项审批的问题，绝大多数不是“流程有没有”，而是“流程在管什么”。

1. 立项审批的产出物不是签字单，而是一份可执行的交付承诺包

我见过太多公司的立项审批产出物只有两样东西：一张 OA 审批单，一份从合同里复制过来的项目简介。这两样东西在项目启动两周后就彻底失去参考价值，因为项目真正需要的不是“这个项目要做”，而是“这个项目在什么范围、什么时间、用多少人、由谁验收、亏了算谁的”。

所以我把立项审批的交付物重新定义为一个交付承诺包。它至少包含：客户与合同关键条款摘要、可交付物清单与验收标准、资源投放计划与工期基线、成本与毛利测算模型、风险登记册与责任人。审批会审的是这五份东西，不是审“要不要接这个项目”。

2. 审批权必须跟着资源承诺权和定价权走，而不是跟着组织级别走

这是我在两段不同经历里反复验证过的一条判断。很多公司的立项审批权限表是按金额和职级排的：50 万以下总监批，50 万到 200 万副总批，200 万以上总经理批。这套逻辑在贸易型业务里成立，在实施型业务里不成立。

原因很简单：一个 300 万的私有化部署实施项目，如果它占用了你唯一的某行业专家 6 个月，它的真实成本可能高于一个 600 万但用的是标准交付资源的项目。审批权应该绑在“谁有权承诺这类资源”和“谁有权改这个报价”上，而不是绑在“谁的职级更高”上。

3. 衡量立项审批质量的指标只有三个

大部分公司考核立项审批用的是“审批通过率”和“审批时效”。这两个指标都能被轻松优化，而且优化方向恰恰是错的，通过率越高，通常说明门禁越松；时效越短，通常说明审得越浅。

我建议换成这三个：

• 立项后范围变更率：立项后因客户新增需求或内部理解偏差导致的范围变更比例，反映立项时的范围锁定质量。
• 交付毛利率达成率：结项实际毛利率 ÷ 立项预测毛利率，反映成本测算的可信度。
• 立项到启动的周期：从合同签订（或中标）到项目正式启动的天数，反映流程效率是否在拖累商机。

4. 一个反常识判断：审批通过率长期高于 90%，说明门禁已经形同虚设

健康的立项门禁应该有一定的“拦下率”。我在一家实施型公司做过统计，当他们把门禁真正立起来之后，立项审批的首次通过率从 97% 降到 72%，看起来是“效率变差了”，但同期立项后范围变更率从 57% 降到 26%。前面拦得住，后面才改得少。

二、背景与真实场景：为什么实施团队的立项审批天生更难做

研发型项目的立项，核心是判断“这件事值不值得投入研发资源”；实施型项目的立项，核心是判断“这笔钱能不能覆盖这批人的成本并且不出事”。两者看起来都是立项，实际的管理变量完全不同。

1. 实施类立项的四个特殊变量

我在做交付管理时，最深的体会是：实施项目的成本几乎全是人力，而人力是不可存储的库存。今天闲置的 5 个人天，下个月补不回来。

2. 一个真实立项场景的还原

2023 年我复盘过一个不太成功的私有化部署项目。时间线大致是这样的：

1. 第 1 天：销售在客户现场口头承诺“数据迁移这部分我们可以帮你做”。
2. 第 3 天：合同签订，技术附件里只写了“完成系统部署及数据导入”。
3. 第 5 天：立项申请提交，项目简介从合同复制，工期写“预计 3 个月”。
4. 第 6 天：审批会 40 分钟过了 12 个项目，这个项目分了 3 分钟。
5. 第 8 天：项目经理被指派，同时手上还有两个在建项目。
6. 第 22 天：客户提出历史数据有 11 种格式，需要逐类清洗。
7. 第 45 天：项目经理第一次上报风险，此时已超预算 30 人天。

这个项目最后延期 2 个月结项，毛利率从预测的 38% 变成 11%。复盘时我们发现，真正的问题不在执行阶段，而在第 5 天到第 6 天之间，立项审批既没有审查“数据迁移”这个范围边界，也没有审查项目经理是否有独占资源。

3. 三种审批形态的实际差异

我经历过的立项审批形态基本可以归为三类，它们的差别不在“严格程度”，而在“信息在什么时点被结构化”。

4. “先干后批”为什么总会发生

我统计过手上三家公司的立项台账，217 个项目里有 23% 存在“先启动后补立项”的情况。原因不是流程没有，而是流程的等待成本太高：如果走完审批要 9.6 天，而客户下周就要开启动会，交付负责人一定会选择先干。

所以整治“先干后批”，靠发文件是没用的。唯一有效的办法是把常规项目的审批压缩到 1 到 2 个工作日以内，让走流程比不走流程更快。做不到这一点，任何制度都会被执行层绕开。

三、拆解常见误区：我踩过和见过的十二个坑

这一节我按四类整理。它们在我见过的实施型公司里重复出现的概率极高，而且往往是同时存在的。

1. 流程类误区

（1）把立项审批做成“盖章大会”

一周一次、一次过 12 个项目、每个项目 3 分钟。这种会议的实质是集体免责，不是集体决策。参会的人越多，责任越分散，最后没人对“毛利预测是否可信”负责。

（2）审批流按金额一刀切

金额是最好量化的维度，所以被用得最多。但实施项目最大的风险变量是“交付复杂度”和“客户配合度”，这两个都不体现在合同金额里。我见过一个 80 万的项目因为客户方 IT 部门全程不配合，硬生生做了 14 个月。

（3）立项和启动合并成一个动作

有些团队为了省事，直接“合同签订即视为立项”。结果是立项审批失去独立判断的机会，因为资源已经承诺出去了，审批只能同意。

2. 数据类误区

（1）毛利测算用的是“标准人天成本”

按人均成本除以 21.75 天算出来的人天单价，看起来很科学。但实际项目中，真正吃人天的是高级顾问和行业专家，他们的成本可能是标准的 2 到 3 倍。用平均成本测算，等于系统性地高估毛利。

（2）工期估算没有缓冲也没有依据

“预计 3 个月”是最常见的一句话。如果追问这 3 个月怎么来的，答案通常是“和上次那个项目差不多”。而上次那个项目的客户配合度、数据质量、并发用户量可能完全不同。

（3）立项台账和实际交付数据不打通

立项时预测的工时、毛利、里程碑，和交付过程中实际发生的数据在两套系统里。这就导致无法复盘“到底是立项估错了，还是执行跑偏了”。不能归因的组织，永远优化不了立项质量。

3. 组织类误区

（1）销售与交付的对赌关系没有被显性化

销售关心签约，交付关心可完成。这个矛盾是结构性的，藏起来只会更糟。我见过最有效的做法是：立项审批会上，销售负责人必须对“客户承诺清单”签字，交付负责人必须对“可交付清单”签字，两份清单差异部分明确标注“需商务变更”。

（2）项目经理在立项阶段缺席

如果项目经理是在立项通过后才被指派，他对工期和范围的承诺就是被动的。我现在的做法是：100 万以上的项目，立项申请必须由拟任项目经理共同提交。他可以不是决策者，但必须是共同承诺者。

（3）审批角色的能力与责任不匹配

让财务审技术可行性、让技术审毛利合理性，都会导致审批变成形式。审批角色应该按“他是否具备判断该维度所需的信息”来设，而不是按部门来设。

4. 合同与范围类误区

（1）验收标准写成“系统稳定运行”

我抽样看过的立项包里，只有约 12% 写了可测量、可验证的验收标准。剩下的要么是定性描述，要么直接抄合同附件。这直接导致验收阶段扯皮，回款周期被拉长。

（2）付款节点与交付里程碑脱钩

“签约付 30%，验收付 60%，质保付 10%”是标准结构，但如果没有把“验收”拆解成可执行的小里程碑，那 60% 就压在最后一个动作上，回款风险极高。

（3）把“客户的额外要求”当成正常服务

实施团队最容易犯的错，是把客户在实施过程中的新增要求当作“顺手做一下”。这些顺手累积起来，就是项目从盈利变成亏损的全部原因。

四、专业判断逻辑：五道门禁与分层授权的组合设计

讲完误区，讲我实际使用的判断框架。它的核心不是“卡得更严”，而是“用更少的时间判断更关键的事”。

1. 五道门禁：把审批拆成五个可独立验证的问题

我把立项审批拆成五道门禁，每道门禁对应一个必须被回答的问题，且必须由具体角色回答：

1. 客户与合同门：客户是谁、预算是否已批、付款节点是否与里程碑对应、有无排他条款或特殊违约条款。责任人：销售负责人 + 商务/法务。
2. 范围与验收门：可交付物清单有几项、每项的验收标准是什么、哪些内容明确不在范围内。责任人：售前 + 拟任项目经理。
3. 资源与工期门：需要哪一类角色、各投入多少人天、这些人在项目周期内是否已被占用、工期基线的推导依据是什么。责任人：交付负责人 + 资源调度。
4. 成本与毛利门：按真实角色成本测算的人天成本、差旅与第三方采购成本、预测毛利率、毛利率下限是多少。责任人：交付负责人 + 财务。
5. 风险与合规门：前三大风险是什么、触发条件是什么、触发后谁负责、是否需要法务或信息安全介入。责任人：项目经理 + 风控。

这五道门禁的关键在于：每道门禁独立判断，前面的门禁不通过，后面的门禁不启动。这避免了在信息不全的情况下就讨论“要不要接”。

2. 分层授权矩阵：按风险等级而不是金额等级

我用的判断维度是两个：合同金额区间，和交付复杂度/风险等级。两者交叉决定审批层级。

这套矩阵的实际价值在于：它让 60% 以上的常规项目可以在 1 到 2 个工作日内完成审批，从而把“先干后批”的诱因消除掉。

3. 三个必须设置的一票否决

其余维度我可以接受带条件通过，但有三个我坚持一票否决：

• 无验收标准的项目不立项：写不出可测量的验收标准，说明范围根本没想清楚。
• 预测毛利率低于公司下限且无战略说明的不立项：战略项目可以低毛利，但必须由更高层级的人签字说明理由。
• 关键角色无法承诺独占资源的不立项：承诺不了人，就不要承诺工期。

4. 立项包的九个必备字段

这是我把立项审批搬到系统里之后定型的一套字段。它的价值在于让审批材料从“一次性文档”变成“可查询的数据”。

五、案例与数据观察：一家 400 人实施型公司如何用 PingCode 重构立项审批

前面讲的是判断逻辑，这一节讲落地。我参与过一家约 400 人的实施型软件公司的立项审批改造，他们服务的是中大型企业客户，交付方式包含标准部署、私有化部署和部分定制开发。这家公司的改造过程和结果，我觉得对 100 人以上的实施型组织都有参考价值。

1. 改造前的状态：立项信息散落在四个地方

改造前他们的立项流程是这样的：销售在群里发一句“某客户合同已签，准备立项”，商务在共享盘里放一份合同扫描件，交付负责人在 Excel 里登记项目名称和工期，项目经理的任命通过邮件确认。

这套流程带来的直接问题是：没有任何一个地方能回答“这个项目承诺了什么、用了多少人、现在到哪一步了”。每次月度经营会，交付负责人要花两三天时间手工汇总，汇总出来的数据还是三周前的。

更麻烦的是他们正在从一套国外项目管理工具迁移过来，历史项目数据分散，迁移过程中最担心的就是立项记录和工时记录断链。

2. 我们用 PingCode 做了什么

选型阶段他们对比过几类方案，最终的判断依据集中在三点：能不能支撑中大型组织的权限与流程复杂度、能不能私有化部署（他们有金融行业客户，要求数据不出内网）、能不能把历史工具的数据平滑迁过来。PingCode 在这三点上都满足，而且它本身就是面向中大型企业和 100 人以上组织的项目管理平台，所以我们把立项审批整体搬了进去。

具体做法分五步：

1. 建一个独立的工作项类型叫“立项申请”，把上面那张表的九个字段全部配成必填或条件必填。缺少验收标准的立项申请，压根提交不上去。
2. 用状态流实现五道门禁。状态依次是：待提交 → 客户与合同门 → 范围与验收门 → 资源与工期门 → 成本与毛利门 → 风险与合规门 → 已立项。每道门禁配一个明确的审批角色，上一道不通过就退回，不会流到下一道。
3. 用自动化规则设置提醒与升级。任意门禁停留超过 8 个工作小时自动提醒责任人，超过 24 小时升级给上级。这一条把平均审批时长直接压下来了。
4. 把工时和资源管理接进来。项目立项通过后，自动在资源视图中占用对应角色的人天。这样下一个项目的资源冲突检测才有数据基础。
5. 用报表做立项后复盘。每个项目结项时对比“立项预测毛利”和“结项实际毛利”，差异超过 10 个百分点的项目自动进入复盘清单。

迁移这一块比预想中顺利。他们把原来在国外工具里的项目、任务、工时数据通过 PingCode 的 Jira 迁移能力做了整体搬迁，立项记录和历史工时保持了关联，没有出现断链。对他们来说，这既是一次流程重构，也是一次国产替代，支持私有化部署这一点，直接解决了他们面对金融客户时的合规顾虑。

3. 六个月的指标变化

这里我想强调一点：审批时长从 9.6 天降到 3.1 天，不是因为审得更松，而是因为审得更早。字段前置之后，审批人拿到的是结构化数据，不需要反复追问；自动化提醒替代了人工催办；分层授权让 60% 的项目在两级以内结束。

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

同一套框架，在不同规模、不同类型的组织里落地方式差别很大。这一节我按组织规模和项目类型给出具体建议。

1. 按组织规模

（1）100 人以下：先做模板，不做系统

这个阶段人少、项目少，主要矛盾是“没有标准”。建议只做一件事：把立项包模板做出来，用共享文档或轻量工具收集，审批用固定会议。不要在这个时候上复杂系统，管理成本会超过收益。

（2）100 到 500 人：系统化门禁是性价比最高的投入

这个规模是立项审批最容易失控的区间。项目数量多到靠人记不住，但流程还没固化。建议把五道门禁做进系统，用必填字段和状态流强制规范。这是 PingCode 这类面向 100 人以上组织的项目管理平台最能发挥价值的阶段。

（3）500 人以上：分层授权 + 数据复盘双轮驱动

这个规模的组织，审批带宽本身就是稀缺资源。必须做分层授权，把 60% 以上的常规项目下沉。同时建立立项，执行的归因分析机制，每个季度复盘毛利偏差最大的十个项目。

2. 按项目类型

3. 30/60/90 天落地路线

1. 第 1-30 天：确定立项包九字段模板；选定一个 20 到 30 个项目的样本做回溯分析，算清当前的变更率和毛利偏差。
2. 第 31-60 天：把五道门禁和分层授权矩阵落到流程或系统中；试点两个交付团队，收集审批人反馈。
3. 第 61-90 天：全量推广；建立月度复盘机制；把“立项后范围变更率”和“毛利达成率”纳入交付负责人考核。

七、不同情况下的取舍

所有流程设计本质上都是取舍。这一节我把四个最典型的取舍讲清楚，方便你根据自己组织的情况做判断。

1. 审批速度 vs 风控深度

这是最常被讨论的一对矛盾。我的判断是：不要试图同时优化这两个指标，而要按项目类型分开优化。标准部署类项目，速度优先，门禁做两道就够；私有化部署和定制开发类项目，深度优先，宁可多花三天。

把资源用在高风险项目上，比在所有项目上平均用力更划算。我见过太多公司用同一套深度去审 30 万和 500 万的项目，结果是小项目被拖慢，大项目也没审透。

2. 标准化 vs 灵活性

标准化能带来数据可比性和审批效率，灵活性能让特殊项目不被误杀。我的经验是：字段标准化，判断灵活化。立项包必须提交的九个字段不能少，但每个字段的填写方式可以因项目而异；审批结论可以带条件通过，但通过必须留下书面条件。

3. 系统管控 vs 管理成本

把立项审批搬进系统，前期一定会有“变慢”的感受。字段要填、流程要走、状态要改，这些都会增加一线的操作负担。我的判断阈值是：当月均立项数量超过 8 个时，系统化的收益开始大于成本。低于这个数量，模板加会议更经济。

4. 销售承诺 vs 交付可行性

这是最难的取舍，因为它涉及组织内部的利益结构。我的处理方式是把矛盾显性化，而不是消灭它：在立项审批中引入“承诺清单双签”，销售签客户承诺，交付签可交付范围，两者的差异部分必须走商务变更流程。

矛盾不会因为你不讨论而消失，只会以项目亏损的形式在半年后爆发。

八、常见问题

1. 项目太小，也要走完整立项审批吗？

不需要。我的建议是设一条简化线，比如 30 万以下、无定制、无数据迁移的项目，只审“范围与验收”和“成本与毛利”两道门禁，其余维度默认通过。关键是简化要有明确边界，不能靠审批人临时决定。

2. 立项审批应该由谁来主导？

我倾向于由交付负责人主导，商务和财务作为强制参与方。原因是立项审批的核心是承诺交付能力，而交付能力只有交付负责人最清楚。如果由销售或商务主导，审批很容易变成对合同条款的确认而非对交付可行性的判断。

3. 立项审批做得再好，客户中途改需求怎么办？

立项审批解决的是“初始承诺的质量”，不解决“变更管理”。但两者是衔接的：立项时明确写出“排除项”，变更谈判时就有依据。我的经验是，立项包里排除项写得越具体，后续变更谈判的成功率越高。

4. 立项审批的周期压到多短才算合理？

我的建议基准是：常规项目 2 个工作日内，中复杂度项目 5 个工作日内，高复杂度项目 10 个工作日内。超过这个时长，就说明审批环节里有可以并行或被替代的动作。

5. 历史项目数据不全，还能做立项质量复盘吗？

可以，但要先做一次基线摸底。挑 20 到 30 个已完成项目，用现有数据算出范围变更率和毛利偏差，作为改进前的基线。不需要追求精确，只要能看出趋势即可。这也是为什么我建议在流程改造前先做这一步，没有基线，后面的改进无法证明。

九、总结：立项审批的真正价值在于把不确定性提前定价

回到开头那个掉 6 个点毛利的经历。我后来想明白，当时我把立项审批当成了“效率问题”，而它其实是一个“定价问题”。实施团队卖的是人的时间，而人的时间一旦承诺出去就无法回收，所以立项审批的实质是：在承诺之前，把不确定性折算成价格、工期和范围。

这个视角带来的三个独特判断，是我写这篇文章最想留下的东西。第一，立项审批的产出物是交付承诺包，不是签字单。第二，审批权应该绑定资源承诺权，而不是组织级别，这样 60% 的常规项目才能在两天内结束。第三，衡量立项审批质量的是范围变更率和毛利达成率，而不是通过率，通过率长期高于 90%，恰恰说明门禁没有在工作。

如果你的组织现在正被“先干后批”和“毛利总是算不准”困扰，我建议下一步只做三件事：先挑 20 到 30 个已完成项目做一次基线摸底，算出你现在的范围变更率和毛利偏差；然后把立项包九个字段的模板定下来，哪怕先用文档收集；最后确定分层授权的金额与复杂度矩阵，让常规项目两周内能走完。

等这三件事跑顺了，再考虑把整条门禁流程搬进系统。到那时你会发现，系统要承载的不是流程本身，而是那套已经想清楚的判断逻辑，顺序反过来做，再好的平台也只是给混乱加了一层界面。