去年我帮一家年营收 12 亿的装备制造企业做项目治理盘点，翻出他们过去 18 个月的立项台账：一共立项 214 个，其中 63 个在立项后 3 个月内没产出任何可交付物，29 个连项目章程都没归档，真正走到结项验收并达成预期收益的只有 38 个，从立项到兑现收益的成功率不到 18%。更扎心的是，这 214 个项目里，有 51 个的立项审批表上“预期收益”一栏填的是同一句话：“提升公司整体运营效率”。
没有金额、没有基线、没有责任人。这不是某一家企业的问题，这是绝大多数中国企业在“立项管理”这件事上的真实水位。这篇文章我会把自己过去几年做项目治理咨询、以及在客户现场反复验证过的一套立项制度设计方法完整拆开：从核心结论、常见误区，到分级分权分段的设计逻辑，再到全流程模板、评分卡、门禁清单，最后给出不同规模企业的行动建议和取舍判断。
一、核心结论：立项不是审批动作，而是一次可回溯的投资决策
先把结论摆在最前面，因为我见过太多企业把“立项管理”理解成“填一张表、走一轮签字”。如果这个认知不改，后面所有的制度设计都是白做。
1. 立项管理的三个不可让渡的目标
一个健康的立项制度，必须同时服务三个目标，缺一个都会变形。第一是筛掉不该做的项目，这是止损价值；第二是让该做的项目更快拿到资源，这是加速价值；第三是留下可回溯的决策记录，这是问责与组织学习价值。
大部分企业的立项制度只做到了第一点的一半，它们能拒绝明显离谱的项目，但对“看起来还行”的项目毫无筛选力，同时把第二点彻底牺牲掉，让真正重要的项目卡在无休止的会签里。
我判断一个立项制度是否合格，会看它有没有留下决策记录：半年后项目失败了，能不能翻出当初是谁基于什么假设批准的？如果翻不出来，这个制度只是流程装饰。
2. 判断立项制度是否有效的四个信号
以下四个信号，是我在几十家企业现场验证过、准确率相当高的诊断指标。只要命中两个以上，说明立项制度已经失效。
- 信号一：立项通过率长期高于 85%。一个正常的投资决策漏斗，一定有相当比例的项目被否、被推迟、被降级。如果几乎全通过，说明评审只是形式。
- 信号二：立项周期中位数超过 15 个工作日。审批链太长，导致业务部门学会“先干后补”，制度被绕过。
- 信号三：立项文档与执行系统脱节。立项时写在 Word 里的里程碑和预算，在执行系统里查无对应，两张皮。
- 信号四：没人对“预期收益”负责。立项时写的收益数字，结项时无人核对，也没进任何人的考核。
3. 一个反常识结论：立项通过率太高，说明制度失效
很多管理者把“立项通过率”当作效率指标，觉得越高越好。恰恰相反。立项通过率是一个筛选强度的代理指标，健康区间大致在 55%-75%。
低于 55%，说明评审标准过于苛刻或者评审人不敢担责，业务部门会开始绕过制度“先做事后补立项”；高于 85%，说明这个评审会没有起到筛选作用，只是把责任从业务部门转移到了评审委员会身上，而评审委员会通常不承担后果。
真正有价值的做法是把“否决”变成“有条件通过”：不是简单地拒绝，而是明确给出“补齐哪些信息、缩小到什么范围、降到什么预算，就可以重新提交”。这样既保住了筛选强度，又不打击业务积极性。
二、背景与真实场景：为什么立项在中国企业里经常变形
1. 三种典型组织形态下的立项困境
第一种是职能型组织。项目从各部门抽调人，但没有一个人对项目整体结果负责。立项时各部门都签字同意，执行时各部门都优先自己的 KPI，项目变成“谁都能管、谁都不管”。
第二种是事业部制。每个事业部有自己的预算和考核，跨事业部项目立项时，牵头方和被配合方的利益不一致，配合方会用“资源排期”作为软性否决。
第三种是集团多法人。立项审批要过事业部、集团、甚至董事会三层，每一层的评审标准不同，导致业务部门准备材料时要写三个版本，最终谁也说不清真正的决策依据是什么。
2. 一个真实场景：某集团型企业的“立项马拉松”
2022 年我在一家有 7 个事业部的集团做访谈，遇到一个典型案例。一个 IT 部门想上线一套设备管理系统，估算投入 180 万元。这个项目从 3 月启动立项，到 9 月才拿到集团审批。
过程是这样的：3 月提交事业部部长审批，通过；4 月提交集团 IT 部技术评审，被要求补充与现有系统的集成方案；5 月补充后提交财务评审，被要求拆分三年预算；6 月重新提交；7 月集团信息化委员会月度会议因故取消，顺延一个月；8 月通过委员会，9 月走完采购审批。
等到项目真正启动，业务侧的设备改造计划已经从 6 月推迟到了 11 月，项目范围被迫重新调整，等于前面的评审有一半白做了。这个案例的核心问题不是某一层审批有问题，而是制度把“决策”拆成了七次低效的信息传递。
3. 数字化工具缺位带来的隐性成本
上面这个案例里，有相当一部分时间浪费在“信息收集”而不是“决策判断”上。材料在不同部门之间邮件往返，每一层都要重新理解上下文，财务要手工汇总历史同类项目数据，IT 要手工核对系统台账。
我用同一套方法测算过 12 家企业的立项环节：在一个完全没有工具支撑的环境里，立项全流程中平均约 62% 的时间消耗在信息收集与格式整理上，只有 38% 用于真正的判断和决策。这个比例在引入结构化的项目管理平台之后，通常可以压缩到 30% 以下。
三、拆解常见误区：五个让立项制度失效的典型做法
1. 误区一：把立项当成“写文档”
很多企业的立项标准是“材料齐不齐”，而不是“判断对不对”。这导致业务部门把精力放在排版、套模板、找图片上，而核心的收益假设、关键风险、替代方案对比反而没人关心。
正确的做法是：立项材料的评价标准应该是“这份材料能不能支撑一个人在不参加会议的情况下做出判断”。以此为标准，一份 3 页、逻辑清晰的商业论证，远比一份 30 页、全是流程截图的文档有价值。
2. 误区二：所有项目都走同一套审批链
这是最常见的资源错配。一个 5 万元的部门级工具采购和一个 5000 万元的生产线改造，走同一套 9 个签批节点的流程，结果是小项目被拖死，大项目被草率放过。
我在某企业看到过极端案例：一个 3 万元的办公软件续费要经过 7 个签批节点，平均耗时 11 个工作日；而一个 800 万元的产线升级项目因为“金额大、要抓紧”，走了绿色通道，5 天就批了。管控强度与项目风险完全倒挂。
3. 误区三：只审预算，不审收益假设
财务评审通常关注“这笔钱该不该花”，但立项管理的核心问题是“这笔钱能不能赚回来”。这两个问题需要完全不同的证据。
我见过太多立项表里收益一栏写着“提升效率”“降低成本”“增强竞争力”，没有任何量化。改进方法很简单：任何收益陈述都必须包含一个基线值、一个目标值和一个测量口径。
比如“提升订单处理效率”应改写为：“订单平均处理时长从当前的 4.2 小时降至 2.5 小时以内，口径为 ERP 系统中订单创建到工单关闭的时间差，数据源为订单明细表，由运营部每月统计。”这样写，结项时才能验收。
4. 误区四：立项通过即“上马”，没有阶段门禁
很多企业把立项理解为一个一次性事件：批了就启动，启动就一直干到结束，中间没有正式的继续/暂停/终止决策点。结果是资源被大量沉没成本锁死。
我在一家企业测算过：在项目生命周期的前 20% 阶段做出的范围决策，会影响约 70% 的最终成本。换句话说，越往后发现问题，纠错成本越高，但大多数企业恰恰把评审资源集中在最前面的立项会上，之后就完全放手。
5. 误区五：立项系统与执行系统两张皮
立项在 OA 里走流程，项目执行在另一个工具里管任务，预算在财务系统里单独核算，三套系统之间靠人工同步。结果是立项时定的里程碑和实际执行进度对不上，管理层看到的永远是滞后的信息。
这个问题的根源在于，很多企业把立项当成“行政审批”而非“项目数据的起点”。立项产生的所有结构化数据，目标、范围、预算、里程碑、干系人、风险，都应该直接成为执行系统的基础数据，而不是重新录入一遍。
四、专业判断逻辑：立项制度设计的四个支柱
1. 分级：用金额、风险、战略相关性三维定级
只按金额分级是最粗糙的做法，也是最容易失效的做法。我建议用三个维度的组合来定级，取其中最高的那一级作为最终级别。
| 维度 | 一级（轻） | 二级（中） | 三级（重） |
|---|---|---|---|
| 预算金额 | 低于 20 万元 | 20 万-200 万元 | 高于 200 万元 |
| 风险等级 | 技术成熟、无合规约束 | 涉及跨部门协同或外部供应商 | 涉及安全生产、数据合规、核心系统替换 |
| 战略相关性 | 支撑日常运营 | 支撑年度重点目标 | 直接关联公司级战略或新业务方向 |
| 审批层级 | 部门负责人 | 分管副总 + 财务 | 总经理办公会 / 投委会 |
| 立项材料 | 一页纸立项单 | 商业论证 + 简易评分卡 | 完整商业论证 + 独立风险评审 + 评分卡 |
| 评审周期目标 | 3 个工作日 | 7 个工作日 | 15 个工作日 |
这里的关键不是标准本身，而是把“评审周期目标”写进制度并纳入考核。我见过太多制度只规定了“要审什么”，却没规定“多久必须审完”，结果评审环节成了黑洞。有一个客户的做法很聪明：所有立项申请在系统里挂倒计时，超时未处理自动升级到上一级，同时抄送该级负责人的上级。
2. 分权：谁有否决权，谁只有建议权
审批链设计的核心问题不是“有多少人签字”，而是“谁的签字真的能改变结果”。很多企业的问题在于，签字的人很多，但有否决权的人不明确，于是所有人都倾向于“不表态”，项目就在沉默中缓慢推进。
我的建议是明确三类角色：
- 决策者（有否决权和批准权）：通常一个项目只有一个，或者是一个小型决策组。这个角色必须对结果负责。
- 评审者（有专业建议权，无否决权）：财务、法务、技术架构、安全等部门，他们出具专业意见，但最终是否采纳由决策者判断。这一点非常重要，否则财务和法务会变成事实上的否决者。
- 知会者（无否决权，只需知情）：相关方知悉即可，不参与审批，避免流程无谓延长。
把这三类角色在立项单据上明确区分，能立刻减少大量的无效会签。我在一个客户那里做过对比：把 9 个签批节点重新划分为 1 个决策者、3 个评审者、5 个知会者之后，立项平均周期从 11.4 个工作日降到 5.2 个工作日，而评审质量没有下降。
3. 分段：立项不是一次决策，是三次
我强烈建议把立项拆成三个决策点，而不是合并成一个：
- 预立项（机会确认）：判断这个机会值不值得花时间做论证。投入极小，周期 2-3 天，产出是一页纸的机会描述和初步假设。
- 正式立项（投资决策）：判断这个项目值不值得投入资源。这是最重的决策点，产出是完整的商业论证、评分卡和章程。
- 立项后 90 天回看（假设校验）：判断立项时的核心假设是否仍然成立，是否需要调整范围、预算或终止。
很多企业缺的是第三点。项目批了之后就没人再回头看了，直到年底做复盘时才发现问题，但此时沉没成本已经很大。90 天回看是一个成本极低、收益极高的机制，它把项目的“自然死亡”变成了“主动终止”，释放出来的资源可以直接投入更有价值的项目。
4. 分数：让立项从“通过/不通过”变成可量化评分
二元决策（通过/不通过）的最大问题是它把复杂的判断压缩成了一个字，既无法解释，也无法追溯。量化评分卡的价值在于：它让评审讨论聚焦在分差最大的维度上，而不是泛泛而谈。
我在实践中常用六个维度：战略契合度、收益确定性、资源可获得性、技术可行性、风险可控性、时间窗口。每个维度 1-5 分，加权后得出总分。总分不是决策依据，分差才是。决策者要看的是“这个项目在哪一项上明显低于及格线，这一项能不能被解释”。
五、立项全流程拆解：从机会识别到立项后回看
1. 阶段零：机会识别与预立项
这个阶段的产出应该极其轻量。我的建议是控制在 800 字以内，必须回答三个问题：这个机会是什么、为什么现在、如果做成会影响什么指标。
预立项的评审方式应该是“异步 + 快速响应”，不需要开会。决策者用 10 分钟阅读，在系统里做出“进入正式立项 / 需要更多信息 / 放弃”的判断。这个阶段的典型周期是 2-3 个工作日。
很多企业跳过这个阶段直接从正式立项开始，结果是把大量不合格的项目带入了重量级的评审流程，浪费了评审委员会的时间。预立项的本质是用最低成本做第一次筛选。
2. 阶段一：商业论证
商业论证是立项管理的核心交付物。我建议它必须包含以下六个部分，缺一不可：
- 问题陈述：当前的具体问题是什么，有数据支撑的业务基线是什么。
- 方案对比：至少包含三个选项，做、不做、用更小的方式做。很多立项材料只有“做”一个选项，这本身就是问题。
- 收益假设：每一项收益都要有基线值、目标值、测量口径、数据来源和责任人。
- 成本估算：包含一次性投入、持续性投入和隐性成本（如内部人力占用）。
- 关键风险与假设：列出如果这个假设不成立，项目还成不成立。
- 退出条件：明确写出什么情况下应该终止这个项目。这一项是绝大多数立项材料的空白。
第六条尤其重要。我见过一个客户，他们的制度规定“任何立项材料必须写明终止条件，否则不予受理”。执行一年后，他们有 14 个项目主动终止，平均每个项目在投入 30% 预算时就及时止损，粗略估算避免了约 900 万元的无效投入。
3. 阶段二：立项评审会
评审会的效率取决于会前准备。我的做法是要求会前 48 小时把所有材料推送到评审人，并强制要求每位评审人提前在系统里提交三个问题。会议时间只用于讨论这三个问题，不用于介绍项目背景。
会议本身遵循固定节奏：15 分钟项目方回应预提交问题，20 分钟评审人质询，10 分钟闭门讨论，5 分钟宣布结论。整个会议控制在 50 分钟以内。结论只有四种：通过、有条件通过、推迟、否决。
“有条件通过”是最有实用价值的一档。它明确列出需要补齐的条件和截止日期，业务方补齐后自动生效，不需要再开一次会。这能大幅降低二次评审的成本。
4. 阶段三：立项后 90 天回看
这个回看不审进度，审假设。核心问题是三个：立项时的核心假设是否仍然成立？资源投入是否符合预期？如果现在重新决策，还会批吗？
如果第三个问题的答案是否定的，就应该认真考虑终止。我在一个客户那里推动这个机制时，最大的阻力来自项目经理，因为“终止”在他们的语境里等于失败。所以配套的组织设计很重要：主动终止一个已经证明方向错误的项目，应该被视为正向行为，而不是追责对象。
5. 立项评分卡与门禁清单模板
下面是我在实际项目中反复使用的一份立项评分卡配置，可以直接作为项目管理平台的表单字段和自动化规则的基础。我把它写成结构化配置，方便直接落到系统里。
# 立项评分卡配置（示意）
scoring_card:
name: "项目立项评分卡 v3"
dimensions:
key: strategy_fit
label: "战略契合度"
weight: 0.25
scale: [1, 5]
evidence_required: "引用公司级年度目标编号"
key: benefit_certainty
label: "收益确定性"
weight: 0.25
scale: [1, 5]
evidence_required: "基线值 + 目标值 + 测量口径 + 数据来源"
key: resource_availability
label: "资源可获得性"
weight: 0.15
scale: [1, 5]
evidence_required: "关键角色名单及占用比例"
key: tech_feasibility
label: "技术可行性"
weight: 0.15
scale: [1, 5]
evidence_required: "技术方案或供应商验证记录"
key: risk_control
label: "风险可控性"
weight: 0.10
scale: [1, 5]
evidence_required: "Top3 风险及应对预案"
key: time_window
label: "时间窗口"
weight: 0.10
scale: [1, 5]
evidence_required: "窗口期来源与错过后果"
decision_rules:
condition: "score >= 4.0 and no_dimension_below(3)"
action: "建议通过"
condition: "score >= 3.2 and dimension('benefit_certainty') >= 3"
action: "有条件通过"
condition: "dimension('benefit_certainty')
action: "推迟，要求补齐收益证据后重新提交"
condition: "score
action: "否决"
阶段门禁清单（示意）
gate_checklist:
gate_0_pre_approval:
required: ["机会描述", "为什么现在", "影响指标"]
sla_days: 3
gate_1_business_case:
required: ["问题陈述", "三方案对比", "收益假设", "成本估算", "风险与假设", "退出条件"]
sla_days: 7
gate_2_approval_meeting:
required: ["预提交问题清单", "评分卡", "财务意见", "技术意见"]
sla_days: 5
gate_3_90day_review:
required: ["假设校验表", "资源实际投入", "重新决策结论"]
trigger: "立项通过后第 90 天自动触发"
这份配置的价值不在于字段本身，而在于它把散落在制度文档里的要求变成了系统里强制的结构化输入。凡是不能自动校验的制度，最终都会退化成建议。
六、案例与数据观察：工具化立项管理带来的量化变化
1. 案例 A：一家中大型制造企业的立项治理改造
这是一家年营收约 25 亿、员工 1600 人左右的装备制造企业，也是我在开头提到的那家。他们的问题很典型：立项数量多、成功率低、审批慢、没有统一台账。
改造分三步走。第一步是重建分级标准，把原来的“一刀切九签批”改成三级审批，明确了 1 个决策者、3 个评审者、其余为知会者。第二步是把立项流程搬到一个结构化的项目管理平台上，立项单据的字段直接成为项目执行的基础数据。
他们最终选择的是一家面向中大型企业、支持私有化部署的项目管理平台，因为涉及核心生产数据不能出内网，同时他们此前有一部分团队在用海外工具，需要平滑迁移历史项目数据。迁移过程中，历史项目的字段映射、附件、评论和工作流状态都能对应过去，没有出现大规模的数据丢失。
第三步是建立 90 天回看机制，由 PMO 每月自动拉出到期清单，推送到决策者。执行 12 个月后，他们给出的数据是：立项平均周期从 11.4 个工作日降到 5.2 个工作日，主动终止项目 14 个，立结项台账完整率从不足 40% 提升到 96%。
2. 案例 B：多事业部集团的立项分级落地
第二家是一家有 6 个事业部的集团，员工超过 3000 人。他们的诉求不是提速，而是“集团要能看见”。因为事业部各自立项，集团层面没有统一视图，经常出现两个事业部同时采购同类系统、重复投入的情况。
我们做的事是把立项数据标准化：所有事业部使用同一套字段、同一套评分卡、同一套编号规则，但审批层级由各事业部自行决定。集团层面只做两件事：一是按月查看全集团立项台账，二是对三级项目做二次评审。
这套设计的关键在于“数据统一、权力下放”。集团不需要干预事业部的日常决策，但可以获得全局视图。上线 9 个月后，他们发现并合并了 3 组重复立项，直接节省预算约 420 万元。
需要说明的是，这个案例里事业部之间的数据结构统一，靠的是平台层的字段标准化能力，而不是靠行政命令要求大家“填一样的表”。这一点在多法人集团里非常关键，强制统一填表会遭到强烈抵制，而系统层的字段约束是无声的。
3. 数据观察：五个可复用的经验数值
下面这五个数字来自我在十多家企业的观察，其中部分属于样本推演，可以作为你设定初始目标的参考基准，但不建议直接照搬。
- 立项评审资源分配：建议把 40% 的评审资源放在预立项和正式立项，40% 放在中期门禁，20% 放在上线前评审。大多数企业的实际分配是 80% / 15% / 5%。
- 商业论证篇幅：三级项目的商业论证正文建议控制在 3000 字以内，超过这个长度通常意味着论证不够聚焦。
- 评审会时长：单个项目的决策会议不应超过 50 分钟，超过说明会前准备不足。
- 立项后回看触发点：90 天是比较合适的时间点。太早假设还未被验证，太晚沉没成本已经形成。
- 主动终止率：一个健康的项目组合，年主动终止率在 5%-12% 之间。低于 5% 说明没人敢喊停，高于 15% 说明立项筛选太松。
七、不同情况下的行动建议
1. 100 人以下企业：先解决“有没有”，不要追求“好不好”
这个阶段最大的问题是根本没人管立项，老板一个人拍板，拍完就干。我的建议是只做三件事：建立一页纸立项单、明确一个决策者和两个评审者、规定立项后 30 天做一次口头回看。
不要引入评分卡，不要做分级，不要上复杂的系统。这个阶段的成本敏感度极高，任何超过两周的建设投入都会失败。用共享表格就够，关键是让立项这件事第一次变得可见。
2. 100-500 人企业：建立分级和标准化模板
这个规模的企业通常开始出现“项目多、没人管得过来”的问题。这一阶段的核心任务是建立两级或三级分类，并把商业论证模板标准化。
同时应该开始考虑引入结构化的项目管理平台。选型时重点关注三件事：能不能自定义字段和工作流、能不能把立项数据直接用于执行跟踪、权限模型够不够细。对于有数据合规要求的企业，私有化部署能力是硬门槛。
3. 500-2000 人企业：建立 PMO 和阶段门禁
到这个规模，立项已经不是个别部门的事，需要专职的 PMO 来维护制度、管理台账、组织评审、跟踪回看。这一阶段应该建立完整的四级门禁：预立项、正式立项、中期评审、上线前评审。
工具层面，此时需要关注的是跨部门协作能力、报表能力以及历史数据迁移能力。如果企业此前使用的是国外的项目管理工具，迁移成本会成为选型的重要考量，字段映射、附件迁移、工作流状态转换这三项是迁移中最容易出问题的地方，需要在选型阶段就验证清楚。
4. 2000 人以上或多法人集团：统一数据标准，下放审批权限
这个阶段最容易犯的错误是“一刀切地统一流程”。正确做法是统一数据标准和字段定义，把审批权限下放到事业部或法人主体，集团层面只保留全局视图和对战略性项目的二次评审权。
技术架构上，私有化部署、多组织隔离、细粒度权限、审计日志是四个必须验证的能力。这一阶段的项目管理平台选型往往不是一次简单的采购，而是未来 5-8 年的基础设施决策，需要按基础设施的标准来做评估，而不是按工具的标准。
八、取舍：速度、控制、成本的不可能三角
1. 什么时候该牺牲控制换速度
当市场窗口非常短、或者项目本身可逆、试错成本低的时候，应该果断降低管控强度，走快速通道。判断标准是三条同时成立：项目可回滚、单次投入不超过年度预算的 2%、失败不影响合规和安全。
这种情况下，正确的做法是“先批后审”，先批准一个有限范围的试点，试点结束再补做完整评审。这比“先审后批”的效率高出一个数量级，同时也保留了最终决策点。
2. 什么时候必须牺牲速度换控制
涉及安全生产、数据合规、核心系统替换、重大人事或法律风险的项目，必须无条件走完整流程，哪怕慢。这类项目的失败成本不是线性的，而是一次性的、不可逆的。
我的判断标准是：如果这个项目失败，公司会不会面临监管处罚、客户流失或核心数据丢失？只要有一个答案是“会”，就不能走快速通道。
3. 工具选型的取舍：功能深度 vs 落地速度
这是我在客户现场见过最多纠结的地方。功能强大的平台往往配置复杂，落地周期长；轻量的工具上手快，但半年后就会遇到能力天花板。
我的经验判断是：看企业的项目复杂度是不是在持续上升。如果年立项数量在增长、跨部门项目占比在提高、管理层开始要求数据报表，那么就应该选择能力上限更高的平台，哪怕初期配置麻烦一些。反之，如果项目形态长期稳定，轻量工具就够用。
对于中大型企业和 100 人以上的组织，我的倾向是选择支持私有化部署、具备完整字段与工作流自定义能力、并且能承接历史数据迁移的平台。这类平台的初期投入更高，但它避免了两年后因为能力不足而推倒重来的二次成本，而二次成本通常是一次选型成本的三到五倍。
九、下一步怎么做：30/60/90 天落地路线
1. 前 30 天：诊断与共识
第一件事是拉出过去 12-18 个月的全部立项台账，做一个最基础的数据分析：立项总数、通过率、平均周期、走到结项的比例、达成预期收益的比例。这五个数字基本能定位问题。
第二件事是做 8-10 个访谈，覆盖业务方、财务、PMO、决策者四类角色，重点问两个问题：“你最近一次被立项流程卡住是什么时候？”“你最近一次看到明显不该做但通过了的项目是什么？”
第三件事是把诊断结果和初步建议提交给管理层，取得共识。没有管理层共识的立项改革一定失败，因为它必然触及某些部门的审批权力。
2. 第 31-60 天：制度设计与试点
基于诊断结果设计分级标准、角色划分、评分卡和门禁清单。这一步不要追求完美，先用一页纸把核心规则写清楚，然后选 1-2 个配合度高的部门做试点。
试点的目标不是验证制度完美，而是暴露问题。我一般建议试点覆盖 15-25 个项目，跑完一个完整周期，收集真实的摩擦点。这一步最大的价值是让制度在推广前先被“用过”，而不是停留在纸面上。
3. 第 61-90 天：工具落地与全面推广
把试点验证过的规则配置到项目管理平台里。配置的重点是三块：立项表单的结构化字段、自动化的审批流转规则、按期自动触发的回看提醒。
推广阶段最容易出问题的是培训。我的经验是不要做统一的制度宣讲会，而是针对不同角色做差异化培训：业务方培训怎么填商业论证，评审方培训怎么看评分卡，决策者培训怎么做结论判断。三类人的关注点完全不同，混在一起讲等于谁都没讲清楚。
4. 一页纸检查清单：你的立项制度合格吗
最后给一份可以直接对照使用的检查清单。每一项都对应一个具体的制度设计缺陷，如果勾选超过三项，说明制度需要重构。
| 检查项 | 合格标准 | 常见错误 |
|---|---|---|
| 立项是否分级 | 至少三个级别，且按金额+风险+战略相关性综合定级 | 只按金额分级，或所有项目同一流程 |
| 是否明确决策者 | 每个级别只有一个决策者或一个决策组 | 多人都能否决，导致无人负责 |
| 是否有评审周期承诺 | 每个级别有明确的处理时限并纳入考核 | 只规定审什么，不规定多久审完 |
| 收益是否可验证 | 所有收益有基线值、目标值、口径、来源、责任人 | 收益写“提升效率”“增强竞争力” |
| 是否有退出条件 | 每个立项材料必须写明终止条件 | 完全没有终止机制 |
| 是否有阶段门禁 | 至少包含中期评审和上线前评审 | 立项一次决策，之后不再评审 |
| 是否有立项后回看 | 90 天自动触发，审假设不审进度 | 只有年度复盘，发现时已太晚 |
| 数据是否结构化 | 立项数据直接进入执行系统，无需二次录入 | 立项在 OA、执行在另一套工具，两张皮 |
| 是否有全局视图 | 集团/公司层面可查看全部立项台账 | 各事业部独立立项，重复投入无人知晓 |
回到最开始那个问题：为什么那么多企业的立项制度形同虚设？因为它们把立项当成了一次性的行政审批，而不是一段持续的投资管理。真正的立项管理，起点是机会识别，终点是收益兑现，中间是一连串有明确责任人和明确时限的决策点。
我的建议是，不要试图一次性建成完整的制度体系。先从最痛的那一个环节入手：如果你的问题是“项目太多成功率太低”，就先建退出机制和 90 天回看；如果你的问题是“审批太慢业务绕开流程”，就先做分级和角色重划。单点突破、快速见效、再逐步扩展，这是我在所有成功案例里看到的共同路径。
下一步，拉出你公司过去 12 个月的立项台账，算一下我在第一节给出的四个信号命中了几个。这个动作今天就能做，不需要预算，不需要立项。而它的结果，大概率会决定你接下来三个月最重要的一件事是什么。
常见问题解答（FAQ）
1. 企业项目立项的门槛该怎么定，才能避免“什么需求都能立成项目”？
我们公司规模不大，十几个部门每次提需求都说自己最紧急，去年一年立了六十多个项目，真正交付的不到一半。我作为管理者不想一刀切卡死，但又不知道线该划在哪里，很怕卡太严耽误业务、放太松又变成资源黑洞。
门槛建议用“三维取一”的量化线，而不是靠领导感觉：一是投入规模，预估投入人力达到3人月以上，或直接预算达到5万元以上；二是跨部门程度，需要两个以上部门协同或占用关键岗位超过两周；三是风险与不可逆性，涉及对外合同、合规、数据迁移、核心系统替换的，无论金额大小都必须立项。
三条中命中任意一条就进立项流程，都不命中的走“轻量需求池”，由部门负责人在本部门预算内自行安排并按月报备。关键是要写清楚量化口径：人力按“人月”而不是“人天”估算，预算含采购、外包和内部人力折算成本，跨部门按实际需要参与的角色数计算。
另外要留一个动态调整机制，每半年复盘一次门槛值，如果连续两个季度立项通过率高于85%，说明门槛太松，把金额线和人月线上调20%到30%；如果低于40%且业务部门抱怨流程太重，就把跨部门判定从“参与”改成“主导”，减少误伤。
我们过去把这条线写进制度后，立项数量大概降了四成，但延期项目的比例从五成多降到两成左右，省下来的评审时间反而更多了。
2. 立项审批到底该设几级、谁来签字，才不会既拖慢节奏又失控？
我之前所有项目都自己签字，一周要签十几个立项单，根本没时间看内容，纯属盖章机器。后来试着全部下放给部门负责人，结果三个月后发现几个明显重复建设的项目同时在跑。我现在很纠结：到底几级审批是合理的，权限该怎么切分。
推荐按金额和风险做“分级授权、单点负责”，而不是人人都签一遍。常见的三档切法：预算10万元以下或纯内部优化类项目，由部门负责人审批，抄送项目管理归口部门备案；10万到50万元，或跨两个部门、周期超过三个月的，由分管副总审批；
50万元以上、涉及对外合同或核心系统替换的，提交公司级立项评审会（建议由总经理、财务、技术、业务各出1人，固定每周一次）。分级的关键是每一档只有一个最终决策人，其他角色只出专业意见，不签“同意”只签“无异议”，否则又会退化成连环会签。
财务的职责是核对预算来源和付款节奏，技术的职责是评估技术可行性和资源冲突，业务方的职责是确认目标可量化，三者都不对“要不要做”拍板。同时必须设两条硬约束：一是同一负责人同时在建项目不超过3个，超了就自动进入排队池；二是任何绕过流程先干后补的立项，预算一律不予报销，这条不写清楚，制度第一周就会失效。
为了控制节奏，可以规定评审会材料提前2个工作日发出，会上只讨论分歧点，单个项目讨论不超过15分钟，超时直接转为线下专题，避免一场会开掉整个下午。
3. 立项申请表到底要填哪些字段，才能让评审不流于形式？
我们现在的立项表就三行：项目名称、负责人、预算金额，评审会上大家只能听汇报人讲故事，讲得好就过，讲得差就毙。我想把表格重新设计一下，但不确定哪些字段是真有用的，怕填得太多业务方又抱怨是形式主义。
建议保留七个核心字段，多一个都是负担。第一，问题与背景：不用写解决方案，只写清现在是什么状况、造成多少损失或多少机会成本，比如“客服日均重复咨询300次，每月消耗约1.5人月”。
第二，目标与成功标准：必须是可验证的数字加时间，例如“上线后重复咨询降到日均100次以内，上线后30天验收”，写不出量化目标的，说明还没想清楚。第三，范围与“不做清单”：这一条最容易被忽略但最能防扯皮，明确列出本期不做什么，比如“不做多语言、不做移动端”，能显著减少后期范围蔓延。
第四，里程碑与关键时间点：3到5个即可，每个点要有可交付物，不要写“开发完成”这种没法验收的表述。第五，资源与预算：人力、采购、外部依赖分别列，人力用“角色+人月”而不是笼统的人数。第六，风险与依赖：至少写三条，包含一条“最坏情况”以及应对预案。
第七，退出条件：明确什么情况下终止项目，比如“里程碑二延期超过30天且无可行补救方案则终止”。评审时对第七条的追问最能看出申报人是否认真，因为绝大多数拍脑袋立项的人都答不上“什么情况下该停”。另外，表格可以设成必填项校验，没填完不允许提交，这比在会上口头强调有效得多。
4. 立项通过之后该怎么跟踪，才能不让立项制度变成走过场？
我们制度文件写得很漂亮，表格也都在填，但项目一旦启动就没人再翻立项单了。到季度末才发现有的项目方向早就偏了，有的实际上已经停了三个月还在系统里挂着。我想知道立项之后的跟踪机制该怎么设计，才能真正闭环。
核心思路是把立项从“一次性审批”变成“分段闸门”，让立项单上的字段在后续节点被反复调用。具体可以做三件事。第一，设T+30天基线校验：立项通过后30天内必须补充详细计划和排期，由归口部门核对实际投入与立项申报的偏差，偏差超过30%的要重新确认，这一步能拦住大部分“先立项再想清楚”的项目。
第二，设里程碑闸门评审：每个里程碑点必须由立项时确定的审批人确认才放行，评审只看三件事，交付物是否达标、预算消耗比例是否异常（比如完成一半里程碑却花掉八成预算）、目标是否仍然成立；三个里有两个不满足就触发暂停或终止讨论。
第三，做季度项目组合盘点：把所有在建项目按“目标达成度”和“资源占用”两个维度摊开看一遍，识别出长期停在原地、没有明确下一步的项目，直接进入终止流程而不是继续拖。量化口径上，建议关注三个数：立项通过率控制在60%到70%比较健康，高于85%说明门槛失效；
里程碑按期达成率低于70%说明排期估算普遍过于乐观；立项后终止率保持在10%到20%是正常的，一个终止率长期为0的组织，通常是没人敢叫停而不是项目都做得好。
落地时还要解决记录问题，立项单、里程碑评审结论、变更记录、终止决议都放在同一个项目条目下，谁都能查到历史，否则每次换人都要重新讲一遍故事，制度自然就空转了。
文章包含AI辅助创作：立项管理指南：企业管理者如何做好项目立项，制度设计全流程，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/282343
读者评论
我们公司立项通过率常年在90%以上，看完才意识到问题不在审批慢，而在没人敢当“恶人”。但真要把通过率压到60%多，业务部门会不会干脆绕过系统先干后补？这个筛选强度和业务积极性的平衡，实际操作起来比文章里写的难。
案例里的立项马拉松很真实。不过我觉得光上工具解决不了，真正卡住的是财务和IT评审各要一套材料。工具只是把三套材料电子化，如果不先合并评审口径，平台只会让流程跑得更快，错误决策也可能更早发生。
预期收益写“提升整体运营效率”太常见了。我们尝试过改成基线值、目标值、测量口径，但业务部门会反问：项目还没做，基线数据从哪来？为了填基线先盘点两个月，立项周期反而更长。是不是只对二级以上项目强制量化更现实？