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

2024年我帮一家做 ERP 实施的公司做流程诊断，翻他们上一自然年的立项台账，看到一个很刺眼的数字：全年提交立项申请 187 个，走完审批的 171 个，最终进入交付并完成验收的只有 93 个。立项通过率 91%，交付完成率 54%。也就是说，将近一半的项目是在”批准”之后，才被发现不该做、做不了或者做了不赚钱的。问题不在执行层，而在立项审批这道闸门本身，它看起来在把关，实际上只是一台盖章机。

这个数字后来成了我讲立项制度的固定开场，因为它精准地说明了大多数实施团队的真实处境：流程齐全、表单规范、签字完整，但没有任何一个环节真正回答”这个项目该不该做”。更麻烦的是，实施团队的项目立项和研发团队完全不同，它的输入是销售承诺，它的资源是稀缺专家，它的失败成本是客户口碑。

这篇文章我会把过去几年在十几个实施型团队里踩过的坑、改过的流程、量过的数据摊开讲清楚：立项审批制度该怎么设计，什么样的分级模型能真正跑起来，哪些”看起来正确”的做法其实在悄悄毁掉整个流程。

一、核心结论：关于实施团队立项制度，我给出的六条判断

1. 立项审批是投资决策，不是合规动作

如果一个立项流程的终点是”签字齐全、归档完成”，那它本质上就是一个合规流程。合规流程回答的是”手续办没办”，投资决策回答的是”这笔钱、这批人、这个客户，值不值得投”。前者的失败最多被审计挑刺，后者的失败会消耗掉公司半年的核心交付产能。

我判断一个立项制度好不好，只看一个指标：被拒绝或被暂缓的项目占比。在健康的实施团队里，这个数字通常落在 15%-30% 之间。长期低于 5%，说明审批只是走过场，审批人根本没做判断；长期高于 40%，说明问题出在售前和交付之间的信息断层，而不是审批环节本身。

2. 审批链条的长度应该与项目风险倒挂

直觉上大家会认为，金额越大的项目越需要多人把关。但实际数据往往相反：低金额、高频次的日常项目因为审批链太长，被拖到丢单或者延期启动；而高金额项目因为审批人多、责任分散，反而没人愿意站出来说”这个项目不该接”。

我见过最极端的情况是：一个 8 万元的运维续约项目要走 7 个审批节点，平均耗时 11 天；而一个 900 万元的定制开发项目，走了同样 7 个节点，但每个节点都没人真正看内容，最终 3 天全票通过。审批链长度如果和风险不成比例，它就是在惩罚小项目、放行大风险。

3. 立项材料的价值在于”能不能被否掉”

绝大多数团队的立项材料是写给”通过”的：漂亮的客户背景、乐观的工期、模糊的风险描述。这种材料写得再厚也没有信息量。真正有价值的立项材料，应该让审批人在 5 分钟内找到至少一个可以否掉它的理由。

所以我在设计立项模板时，会强制要求填写三样东西：最可能让这个项目失败的三个原因、如果失败谁来兜底、什么条件下应该主动叫停。这三项如果填不出来，说明申请人自己都还没想清楚。

4. 分级授权是唯一能让效率和风控同时不崩的结构

统一审批链和完全放权是两个极端，都会崩。统一审批链会让 80% 的低风险项目堵在流程里，完全放权会让高风险项目无人把关。唯一可行的结构是分级授权：按金额、客户等级、技术新颖度、交付风险四个维度打分，不同分值走完全不同的审批路径。

我在项目里落地的版本是三级模型：轻量级走单人确认（通常半天内完成），标准级走三人评审（2-3 天），战略级走跨部门决策会（5 个工作日内）。这套结构上线后，整体立项平均周期下降 70% 以上，同时高风险项目的否决率反而上升了。

5. 立项制度必须包含结项回写，否则永远无法自我校准

只立项、不结项，制度就会慢慢失真。因为没有人知道当初那些”预计工期 60 天”的项目最后用了多少天，也没有人知道”毛利率 35%”的项目最后是赚是亏。没有回写，立项审批就是一次性动作，第二年还是拍脑袋。

我坚持的一个做法是：立项卡上的每一个关键假设，都要在结项时逐条打分。工期偏差、成本偏差、范围变更次数、客户满意度，这几项回写进立项台账之后，你才有依据去调整审批阈值。很多团队做到第三年才意识到这一点，前两年积累的立项数据几乎全是废数据。

6. 制度能不能活过三个月，取决于它有没有落在系统里

文档形式的制度一般活不过一个季度，因为执行依赖记忆。当项目压力上来，第一个被跳过的就是”看起来不重要”的审批环节。制度必须变成系统里的硬约束：该填的字段填不了就不能提交，该走的节点不通过就无法生成项目编号，该有的提醒到点自动触发。

这也是我后来在选型时格外看重工具承载能力的原因。对 100 人以上的中大型实施组织来说，立项审批需要一个支持自定义工作项、自定义审批流、细粒度权限并且能长期稳定运行的项目管理平台。下面几节我会结合具体实践展开。

二、背景与真实场景：实施团队的立项为什么特别难

1. 实施型项目的四个特殊属性

研发项目的立项风险主要来自技术不确定性，而实施项目的立项风险来自四个更复杂的地方，很多从研发体系搬过来的立项模板在这里会直接失效。

第一是人力密集且不可替代。一个行业解决方案的交付往往依赖 2-3 个关键专家，这些人同时能带的项目数量有硬上限。立项审批如果不做资源预占，批准得再多也交付不了。

第二是售前承诺和交付能力天然脱节。销售在客户现场为了拿下单子，容易在工期、范围、验收标准上做出超出交付能力的承诺。立项审批是唯一能在投入之前把这些承诺拉回现实的机会窗口。

第三是收入确认严重滞后。实施项目的验收周期常常是 3-12 个月，中间还有可能延期。这意味着立项时看到的毛利率，在结项前都只是账面数字，风险敞口比研发项目大得多。

第四是变更频繁且缺乏边界。客户需求在实施过程中持续变化，如果立项时没有明确范围和变更机制，项目会变成一个无底洞。我在一个项目里见过，最初 120 万的范围，经过 11 次变更后实际工作量翻了一倍多，但合同金额只加了 8%。

2. 一个典型的立项流程被拆开之后长什么样

我把见过的实施团队立项流程做了归纳，大概可以拆成八个环节。看起来不长，但每个环节之间的等待时间往往比处理时间还长。

1. 商机登记：销售在 CRM 里录入基本信息，此时只有客户和大致金额。
2. 售前评估：解决方案团队介入，判断技术可行性，经常只有一个粗略结论。
3. 立项申请提交：填写立项单，包括范围、工期、人力需求、成本预算。
4. 技术评审：技术负责人判断有没有能力做、有没有类似案例。
5. 财务评审：财务判断毛利率、回款条件、资金占用。
6. 资源确认：交付经理判断有没有人能上、什么时候能上。
7. 审批决策：部门负责人或分管领导签字。
8. 立项归档并生成项目编号。

这八步里，真正产生新信息的是第 2、4、5、6 步。如果第 1 步的商机登记质量太差，后面六步都会变成信息补录，而不是判断。这是我发现的最普遍、也最容易被忽略的问题。

3. 时间都花在哪里了

我曾经在一个 200 人规模的实施团队里做过一次完整的耗时测量，跟踪了 60 个立项申请的每个节点停留时间。结果非常反直觉：申请人自己填表的时间占比只有 12%，剩下的 88% 都消耗在等待和补充材料上。

其中最耗时的是”技术评审→财务评审→资源确认”这三段串行等待，平均占了 61% 的总时长。原因是这三个环节没有并行，而且每个环节都倾向于打回重填，而不是直接给出判断。把串行改为并行，是压缩立项周期性价比最高的一刀。

三、拆解八个常见误区

1. 把立项审批当成合规动作来做

最容易出现的信号是：立项模板里的字段越来越多，但没有人解释每个字段为什么存在。审批人看的是”是否填了”，不是”填的内容是什么”。我在一个团队里看到立项单有 43 个字段，但审批人平均停留时间是 90 秒，这意味着平均每个字段只看了 2 秒。

字段数量超过某个阈值后，反而会降低审批质量，因为审批人会用”都填了就行”的启发式来替代真实判断。我的建议是：立项单核心字段控制在 12-15 个，非核心信息放到附件，只在需要时查看。

2. 审批人越多越安全

这是最经典的误区。审批人增加到 5 个以上时，会出现典型的责任稀释：每个人都认为别人会把关。我做过一次对照，一个团队把某类项目的审批人从 3 个增加到 7 个之后，三个月内出现问题的项目反而增加了 2 个，而立项周期延长了 6.4 天。

正确的做法是每个审批人负责明确的、不重叠的判断维度。技术负责人只判断可行性，财务只判断经济性，交付经理只判断资源可得性。三个人各管一摊，比七个人每人管全部要有效得多。

3. 立项材料越厚越好

我见过 46 页的立项 PPT，但里面没有一句话提到”这个项目最大的风险是什么”。材料厚度的真实作用往往是申请人给自己找安全感，跟决策质量关系不大。

更糟的是，厚厚的材料会增加审批人的信息处理成本，导致他们只看摘要页。我现在的做法是把立项材料压成一页纸的决策看板：项目一句话、客户、金额与毛利、人力需求、关键风险三条、建议结论。附件可以提供更多细节，但决策依据就在这一页。

4. 一刀切，所有项目走同一套流程

很多团队的立项制度从设计之初就是”一套流程打天下”。结果是一个 5 万元的小项目和一个 800 万元的大项目走完全相同的七个节点，前者被流程拖死，后者因为缺乏针对性的深度审查而失控。

判断标准其实很简单：如果流程成本占项目金额的比例超过 1%，这个流程对这个项目来说就太重了。按这个口径算，5 万元项目最多只能承担 500 元的流程成本，也就是几个小时的人工，绝不可能支撑七个节点的审批。

5. 立项与预算、资源脱节

这是最隐蔽也最危险的误区。立项审批通过了，但没有对应的预算科目，也没有实际锁定人力资源。等到项目要启动时，才发现关键专家已经被别的项目占用了，或者预算根本没批下来。

我在一次诊断中发现，超过三成的项目在立项通过后 30 天内没有真正启动，原因就是资源没到位。立项审批的最终产出不应该是一个编号，而应该是”预算额度 + 人力资源 + 时间窗口”三者的同时锁定。

6. 只立不结，没有回写机制

没有结项回写，立项台账就是一堆静态的假设。三年后你依然无法回答”我们当初估计的工期，平均偏差是多少”这种最基础的问题。

我建议的强制动作是：项目结项时必须填写一份立项假设对照表，逐条比对当初承诺的工期、成本、范围、毛利与实际结果的差异，并给出偏差原因分类。这份数据积累到 50 个项目之后，你的立项评审就可以用历史分布来判断新申请的合理性，而不是靠感觉。

7. 用立项审批代替售前决策

把立项当成第一道关口，往往已经太晚了。因为到了立项阶段，销售已经向客户做出了承诺，商务谈判已经进入后期，此时拒绝项目的成本非常高，审批人很容易”先批了再说”。

真正的把关点应该前移到售前方案评审，也就是在报价和承诺工期之前，由交付方对可行性和资源可行性给出明确意见。立项审批做的是复核和资源锁定，而不是第一次判断。

8. 制度写在文档里，没落在系统里

这是导致制度失效的最后一环，也是最常见的一环。制度文档写得再清楚，只要执行依赖人的记忆和自觉，三个月后就会退化成”看情况”。系统承载的意义在于把关键约束变成不可绕过的路径：字段未填无法提交、审批未通过无法生成项目编号、资源未锁定无法进入排期。

四、专业判断逻辑：一套可落地的立项制度设计框架

1. 用四个维度给项目分级，而不是只看金额

只按合同金额分级是最省事的做法，但也是最容易出问题的做法。一个 200 万元的标准化产品实施，风险可能远低于一个 80 万元的全新行业定制项目。我建议用四个维度打分：

• 合同金额：直接影响经济风险敞口。
• 客户等级与回款条件：战略客户、账期长短、验收条款严格程度。
• 技术或行业新颖度：是否第一次做、是否有可复用资产。
• 资源占用强度：是否需要稀缺专家、是否会挤占其他项目。

四个维度各按 1-5 分打分，总分决定项目等级。我把阈值设在：总分 ≤ 8 分为轻量级，9-14 分为标准级，≥ 15 分为战略级。这套分数不是拍脑袋定的，而是根据我跟踪的项目里，实际出问题的项目分布反推出来的。

2. 不同等级对应完全不同的审批路径

分级的意义在于，让审批资源和项目风险匹配起来。轻量级项目的核心诉求是”快”，战略级项目的核心诉求是”看透”。

注意标准级和战略级的差别不只是”多几个人”。战略级必须增加两个动作：情景推演（如果关键资源延期两周，项目还能不能做）和退出条件定义（出现什么信号时应该主动终止）。这两个动作是战略级项目区别于其他项目的关键。

3. 审批人各自负责不重叠的判断维度

审批链设计中最常见的错误是让每个审批人都看全部内容，这会导致重复劳动和责任稀释。正确做法是明确分工：

• 技术负责人：只判断”我们能不能做出来”，关注技术可行性、已有案例复用率、技术风险等级。
• 财务负责人：只判断”这笔生意值不值”，关注毛利率、回款条件、资金占用周期。
• 交付经理：只判断”有没有人来做”，关注关键角色可得性、排期冲突、能力缺口。
• 决策者（战略级）：只判断”要不要投入”，关注战略价值、组合平衡、退出条件。

这个分工在系统里的落地方式，是给每个审批节点只展示它关心的字段。审批人看到的字段越聚焦，审批质量和速度都会提升。这也是我后来非常看重项目管理平台自定义能力的原因，如果系统只能显示全字段，这个分工就没法落地。

4. 立项单的”最小必要字段集”

下面是我在实际项目里反复打磨后固化下来的一套字段定义，可以直接作为配置参考：

项目名称: 字符串, 必填
客户名称: 关联客户对象, 必填

合同金额: 数值(元), 必填

预估毛利率: 百分比, 必填

项目等级: 单选(轻量级/标准级/战略级), 自动计算

关键角色需求:

角色名称: 字符串

人数: 数值

预计投入人天: 数值

期望进场时间: 日期

范围边界: 多行文本, 必填, 限500字

三个最可能的失败原因: 多行文本, 必填, 至少3条

主动叫停条件: 多行文本, 必填, 至少1条

建议结论: 单选(建议立项/建议暂缓/建议放弃)

附件: 文件, 选填

这套字段一共 12 个核心项，与前面”字段不要超过 15 个”的判断一致。关键在于”三个最可能的失败原因”和”主动叫停条件”是必填的，这两项是逼迫申请人做真实思考的开关。我见过很多团队上线这两项之后，立项申请的撤回率明显上升，这恰恰说明它起作用了。

5. 决策结果应该是四选一，不是二选一

大多数团队的审批结果只有”通过/不通过”，这是把一个连续的决策压成了二元选择。我建议改成四选一：

1. 批准立项：预算、资源、时间窗口同时锁定。
2. 有条件批准：列出必须在 N 天内补齐的条件，到期未补齐自动转为暂缓。
3. 暂缓：不否决，但明确暂缓原因和重新提交的触发条件。
4. 驳回：明确不可再提，或需重大条件变化后重新提交。

引入”有条件批准”和”暂缓”之后，我发现审批人的心理负担明显下降。因为不再是”同意或反对”的对立选择，他们更愿意真实表达顾虑。这是我观察到的一个很微妙的组织行为变化。决策选项的设计，会直接影响审批人愿不愿意说真话。

6. 时间盒与默认通过机制

审批超时是立项周期拉长的最大原因。我在制度里引入了一个硬规则：每个审批节点有明确的处理时限，超时后进入升级或默认通过路径。

具体规则是：轻量级项目节点超过 8 小时未处理，自动通过并通知上级；标准级节点超过 2 个工作日未处理，自动升级给上一级；战略级项目确实需要更多时间，但必须由决策者明确说明延期原因。这套机制上线后，标准级项目的审批按时完成率从 58% 提升到 91%。

需要强调的是，默认通过只适用于轻量级项目。高风险项目的默认通过等于放弃风控，这是不能妥协的边界。

7. 结项回写与制度校准

立项制度的最后一块拼图是回写。我设计的结项对照表包含四项核心偏差：工期偏差率、成本偏差率、范围变更次数、实际毛利率与预估毛利率之差。这四项数据积累起来之后，可以做一件很有价值的事：用历史分布来校准新项目的立项预期。

比如当立项申请写着”工期 60 天”时，系统可以自动提示”同类项目历史平均工期为 87 天”。这种基于自身数据的提示，比任何外部标准都更有说服力。这也是为什么我一直强调立项数据必须结构化存储，而不是留在文档和邮件里。

五、案例与数据观察：一个 300 人实施团队的立项流程改造

1. 改造前的状态

这是一家做行业解决方案的中间件实施公司，交付团队约 300 人，分 12 个交付小组，同时进行的项目常年维持在 45-60 个。改造前他们的立项流程是：销售提申请，技术总监、财务经理、两位交付总监、分管副总依次签字，全部走完大约 2 周。

问题非常典型：立项周期长导致项目启动滞后，同时高风险项目又没能被拦住。他们在改造前一年有 7 个项目出现严重亏损，其中 5 个在立项阶段就有人私下表达过担忧，但没有人正式提出异议。原因很简单：在串行审批链里，提出异议意味着要一个人对抗后面所有人的签字。

2. 改造做了什么

第一步是引入分级模型。我们按前面讲的四个维度给项目打分，把 60 个在跑项目重新分了级，结果是轻量级 41%，标准级 44%，战略级 15%。这个分布出乎他们意料，他们原以为大部分项目都是标准级。

第二步是把串行审批改成并行会签。技术、财务、交付三方同时收到审批任务，各自只处理自己那部分字段，互不影响。这一步是整个改造中效果最直接的。

第三步是把立项制度落到项目管理平台上。他们选择的是 PingCode，主要考虑三点：一是需要自定义的工作项类型来承载”立项申请”，并把审批状态、评分字段、关联资源都放在同一个对象上；二是需要私有化部署，因为项目信息涉及客户合同金额和报价，不适合放在公有云；三是他们原本用 Jira 管理部分研发项目，需要平滑迁移和历史数据保留。

在 PingCode 里，他们的落地方式大致是这样的：

• 工作项类型：新增”立项申请”工作项类型，与”项目”工作项通过关联字段绑定，立项通过后自动创建对应的项目对象。
• 自定义字段：把前面那 12 个核心字段做成自定义属性，其中”项目等级”用公式字段自动计算，避免人工填错。
• 审批流：按等级配置不同审批流，轻量级单节点，标准级三节点并行会签，战略级四节点加一个决策会节点。
• 自动化规则：设置超时升级、条件必须补齐提醒、立项通过后自动生成项目编号并锁定资源占用。
• 权限与视图：每个审批角色配置独立的表单视图，只展示与其判断维度相关的字段。

第四步是加了结项回写。每个项目结项时必须填写立项假设对照，系统自动计算四项偏差率并归档到立项台账。

3. 上线后的数据变化

改造上线后跟踪了 6 个月，几个关键指标的变化比较明显。立项平均周期从 14.2 天降到 3.6 天；立项阶段的驳回和暂缓比例从 4% 升到 23%；因为资源冲突导致的启动延期从每月 2.8 次降到 0.7 次；立项材料的一次通过率从 67% 提升到 88%。

需要客观说明的是，立项周期下降主要来自并行化和超时规则，驳回率上升主要来自分级后的注意力集中和”主动叫停条件”这个必填项，这些变化并不能全部归因于工具。工具的作用是让这些规则可以稳定执行，不会因为项目忙就被跳过。

另外一个值得说的观察是：改造后第 4 个月，他们第一次能够在管理会上拿出”立项预估工期与实际工期偏差分布”这张图。这是他们做实施业务十几年来第一次有这种数据。有了这份数据之后，立项评审的讨论方式发生了根本变化，从”我觉得这个工期太紧”变成了”同类项目历史平均偏差是 +42%，你这个预估需要调整”。

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

1. 50 人以下的实施团队：先做轻量分级，不要上系统

这个规模的团队，项目数量通常不超过 20 个在跑，人际沟通成本还比较低。这个阶段的核心矛盾不是流程不规范，而是没有任何结构化的立项记录。我建议先做三件事：

1. 定义三级分级标准，阈值先用简化版（只看金额和资源强度）。
2. 把立项单压缩到 8 个字段，加上”三个失败原因”。
3. 用共享表格建立立项台账，每次结项时回写偏差数据。

这个阶段不需要项目管理系统，用表格就能跑。过早引入系统反而会因为配置成本而拖延制度落地。等到立项台账积累了 50 条以上记录、团队规模超过 80 人，再考虑系统化。

2. 100-300 人的实施组织：需要系统承载，重点在并行审批

这个规模是立项制度最容易崩掉的区间：项目数量已经超过个人能记住的范围，但又没有形成成熟的管理惯例。这个阶段必须把制度落到系统里，否则执行会完全依赖个别管理者的推动。

我的建议是：

• 优先解决并行审批。这是投入产出比最高的一步，通常能压缩一半以上的审批周期。
• 开启超时升级规则。不要试图靠催办解决瓶颈，要用规则。
• 给每个审批角色配独立视图。审批人只看自己要判断的字段，其余折叠。
• 建立立项台账的结项回写机制。前 6 个月可能看不到价值，一年后会成为最核心的资产。

这个规模的团队往往已经有比较复杂的 IT 环境，如果是涉及客户合同和报价的敏感数据，私有化部署通常是刚性要求。像 PingCode 这类支持私有化部署、同时具备自定义工作项和审批流能力的项目管理平台，在这个阶段比较合适，因为它可以在同一个系统里承载立项审批、项目执行和结项归档，避免数据在多个系统之间断裂。

3. 300 人以上、多交付线的组织：需要统一标准 + 差异化执行

这个规模的组织，最大的风险是各交付线各自为政，形成多套立项标准，导致横向资源调配没有统一依据。这时候需要的是”统一框架 + 局部灵活”。

具体做法是：把分级模型、核心字段、结项回写这三样做成公司级标准，不可更改；把审批链的具体节点、时限、评审细则下放给各交付线自定。这样既保证了横向可比性，又不至于让不同业务特点的交付线被同一套流程绑死。

工具层面，这个规模通常需要考虑多项目组合视图、资源池管理、跨部门审批和权限隔离。立项审批不再是孤立流程，而是整个项目组合管理的一个入口。这也是为什么我在选型时特别关注平台能否同时覆盖立项、执行、资源和度量四个层面，而不是把立项做成一个独立的表单工具。

4. 从零开始的 90 天落地路线

如果你现在正准备搭建或重建立项制度，下面这条 90 天路线是我在多个团队验证过、比较稳妥的节奏：

1. 第 1-2 周：拉取过去 12 个月的立项和结项数据，算出通过率、交付完成率、平均审批周期三个基线数字。
2. 第 3-4 周：设计分级模型和四个维度的评分规则，做一次历史项目回测，看分数分布是否合理。
3. 第 5-6 周：定义立项单最小字段集和审批人职责分工，形成一页纸的制度说明。
4. 第 7-8 周：在系统中配置工作项、字段、审批流和超时规则，用 5 个真实项目做试运行。
5. 第 9-10 周：正式上线，同时开启结项回写，建立第一版立项台账。
6. 第 11-12 周：复盘试运行数据，调整分级阈值和审批时限，形成稳定版本。

这个节奏里最容易被省略但最重要的一步是第 2 周的基线测量。没有基线的改造无法证明效果，也无法说服团队坚持。先量清楚现状，再动手改，这是所有流程改造的铁律。

七、不同情况下的取舍

1. 效率与风控：不可能同时最大化

这是立项制度里最根本的一组取舍。审批越严格，周期越长，销售和交付的响应速度越慢；审批越宽松，风险敞口越大。我的判断是：不要试图同时优化两者，而是明确在什么项目上偏向哪一边。

具体建议是：轻量级项目明确偏向效率，允许一定比例的判断失误，因为单个项目的损失有限；战略级项目明确偏向风控，多花 3 天做情景推演是值得的。最糟糕的做法是对所有项目都取中间值，那意味着所有项目都既不够快也不够严。

2. 标准化与灵活性：标准化的是框架，灵活的是参数

我见过两种极端：一种是全公司一套流程，所有交付线怨声载道；另一种是每个交付线自定流程，总部完全无法横向比较。两种都会带来问题。

我的取舍原则是：框架必须标准化，参数可以本地化。分级模型的四个维度、立项单的核心字段、结项回写的四项偏差，这些是框架，必须统一；审批节点数量、处理时限、评审细则，这些是参数，可以按交付线特点调整。这样既保证了横向可比，又给了执行层调整空间。

3. 集中审批与分散授权：按风险而不是按职级

很多团队的默认逻辑是”越重要的事越要上级批”，结果所有项目都往上走，高层成为瓶颈。我的建议是按风险分配授权，而不是按职级。

具体来说：轻量级项目授权到交付经理，标准级授权到技术与交付负责人，只有战略级才需要上升到分管领导。这个分配的前提是分级模型准确，所以分级评分规则的设计质量，直接决定了授权体系能不能成立。

4. 系统硬约束与人的灵活性：约束流程，不约束判断

系统承载带来一个副作用：过度刚性。审批人可能会因为系统不让他做某个判断而选择”直接通过”。所以系统约束的应该是流程路径，而不是判断空间。

具体做法是：字段未填不能提交，这是硬约束；资源未锁定不能生成项目编号，这是硬约束；但审批人总是可以选择”有条件批准”并写明条件，这是灵活性。系统管流程，人管判断，两者不能错位。

5. 短期成本与长期数据资产：前6个月是纯投入

立项制度改造有一个非常明显的特点：前期只有成本，没有收益。字段要重新定义，系统要重新配置，审批人需要培训，这些都要花时间。数据资产的价值要到 6-12 个月之后才能体现。

我的建议是把这个预期提前说清楚，不要承诺”上线就见效”。同时把快速见效的部分（并行审批、超时升级）放在第一阶段，让团队在 2-4 周内就能感受到周期缩短，用这部分收益支撑后面的长期投入。

八、总结：立项制度真正的价值是让”不做”成为一个正式选项

回到开头那个数字：187 个申请、171 个通过、93 个交付完成。这家公司后来把立项驳回率从 4% 提到了 23%，第二年交付完成率提升到 71%。最重要的变化不是数字本身，而是团队开始接受一件事：在立项阶段被否掉一个项目，是一件正常且被鼓励的事，而不是需要解释的失误。

这也是我对立项制度最核心的独特判断：大多数团队的立项流程之所以失效，不是因为流程设计得不够复杂，而是因为整个组织默认”立项就是要通过”。当”通过”成为默认结果，所有审批动作都会退化成形式。真正有效的立项制度，必须在机制上让”不做”成为一个体面的、有依据的、不需要承担人际风险的选择。

要做到这一点，需要三个具体支撑：分级授权让不同风险的项目有不同的审查强度；“三个失败原因”和”主动叫停条件”这两个必填项逼迫申请人和审批人面对真实风险；决策选项从二元变成四元，让”暂缓”和”有条件批准”成为正常结论。

如果你准备动手，我建议的下一步很具体：这周先花两个小时，把过去 12 个月的立项台账拉出来，算三个数，立项通过率、交付完成率、立项到启动的平均天数。这三个数会告诉你，你的立项制度现在到底是闸门，还是盖章机。算完之后，再决定是从分级模型开始改，还是从并行审批开始改。