去年我帮一家 400 多人的研发组织复盘立项审批流程，翻出半年内 63 个立项申请，发现一个很反常识的数字：从提交申请到正式立项，平均耗时 11.2 个自然日，但真正坐下来开会评审的时间加起来不到 90 分钟。剩下的时间全花在”等人补材料””等人确认人力””等人回邮件”上，这是一次内部样本复盘，样本量不大，但足够说明问题。
更麻烦的是后续：这 63 个项目里有 11 个在立项通过后 30 天内就停摆或者推倒重来。原因不是技术难题，而是立项阶段压根没写清楚三件事，谁投入多少、做到什么程度算成功、什么条件下应该停下来。
所以这篇文章我不打算复述”立项审批有哪几个步骤”这种谁都能写的内容。我想拆的是四件更硬的事：立项审批到底该审什么、谁来审、多久审完、以及项目成员在立项阶段究竟该干什么。中间会给出我实际用过的字段设计、分级授权表、SLA 时间盒，以及一组来自某研发管理平台的落地观察数据。
一、核心结论：立项审批的成败，在你走进评审会之前就决定了
先把结论摆出来，后面再用场景和逻辑去论证。这四条是我在多个中大型组织里反复验证过的判断，你可能不同意，但至少可以作为对照。
1. 立项审批的产出物不是”审批记录”，而是”可被反对的决策依据”
大多数组织的立项审批，最后留下的是一串签字和一个”通过”。真正有价值的产出物应该是一份可以被反驳的决策依据：假设是什么、数据从哪来、什么条件下这个决策会被证明是错的。
如果一个立项书没人能提出反对意见，通常不是因为它完美，而是因为它写得足够模糊。模糊的立项书在评审会上最容易通过，也最容易在三个月后变成扯皮的源头。
2. 审批层级数量与项目成功率不是线性正相关
很多组织遇到项目失败，第一反应是”加一道审批”。但从我复盘的数据看，从 2 层审批加到 4 层审批，项目中止率并没有显著下降，反而让立项周期从 4 天涨到 8 天以上，还会把真正有价值的项目拖到错过窗口期。
审批层级的真正作用不是拦截，而是让不同量级的资源投入匹配不同量级的决策权限。一个 15 人天的内部工具改造，和一个跨三个部门、预算 80 万的平台重写，本来就不该走同一扇门。
3. 项目成员在立项阶段的参与度，决定后面 80% 的执行摩擦
这是我感受最深的一条。立项阶段只由产品经理或项目发起人独自完成材料，成员直到排期才第一次看到项目内容，这种情况下，排期会上的争论、”这个需求我没评估过””这个人那段时间在别的项目上”几乎必然会密集出现。
让核心成员在立项阶段就签字确认”我什么时候、投入多少比例、负责哪一段”，成本大约是每人 30 分钟。而绕过这一步，代价通常是排期反复、重新拉人、甚至项目启动会开三次。
4. 工具不决定流程质量，但决定流程能不能被复用
我见过用邮件 + Excel 也跑得很好的立项审批，但那种组织通常有一个非常强势且细致的 PMO，一旦这个人离职，流程就散了。能被复用的流程，一定要有结构化载体：字段、模板、审批流、归档、可检索的历史决策。
这也是为什么后来我在选型时，会把”能否自定义立项申请字段和分级审批流”当作硬性门槛，而不是加分项。
二、真实场景：三次立项，三种失败
抽象讨论没意义，我直接讲三个真实发生过的场景。为了不暴露具体公司，人名和细节做了模糊处理，但数字和流程节点是原样保留的。
1. 场景一：9 个人天的项目，审批走了 11 天
一个团队想给内部测试环境加一层自动清理脚本，投入评估是 9 个人天。申请从周一提交，走的是公司统一的标准立项流程：部门负责人 → 技术负责人 → 财务确认（因为涉及云资源费用，虽然只有每月 200 多块）→ PMO 归档。中间财务负责人出差三天，申请在系统里躺了整整四天。
最后项目在第 11 天立项，第 13 天做完。也就是说，审批耗时是执行耗时的 5 倍多。这个案例让我第一次意识到，流程的”统一”有时候是一种懒政，它把管理成本摊平给了所有项目，而小项目根本扛不住这种摊派。
2. 场景二：38 页立项书，评审会上没人看完
另一个项目是重构一套订单结算模块，立项材料写了 38 页，包含架构图、时序图、风险评估矩阵、竞品分析、三年 TCO 测算。评审会通知的是 60 分钟，实际前 25 分钟都在讲背景。
我事后问了 7 位评审人，只有 2 位在会前真正翻完材料，其余都是会前 10 分钟看了前 6 页。这意味着后面 32 页的内容实质上没有进入决策过程，但它们的存在制造了一种”我们很严谨”的错觉。
问题不在于材料写得多，而在于没有分层的决策摘要。一个合格的立项包应该是：1 页决策摘要 + 3 页关键论证 + 附录按需展开。评审人只需要为摘要里的结论负责。
3. 场景三：评审会全票通过，第三周停摆
第三个案例最典型。项目立项评审时全票通过，预算 60 万，周期四个月。到第三周，项目经理发现核心开发在被两个项目共享，实际能投入的比例只有 30%，而不是立项书上写的 70%。
追责的时候发现，立项书上”人力投入”那一栏填的是”研发 2 人”，没有写比例、没有写起止时间、也没有让被占用的人签字确认。这不是执行问题，这是立项字段设计问题。字段粒度不够，评审就只能基于模糊信息做决策。
三、常见误区：我把踩过的坑分成六类
下面这六类误区，是我在不同规模的组织里反复见到的。它们的共同点是：看起来都在”加强管理”，实际都在抬高决策成本、降低决策质量。
1. 误区一：把立项审批当风险控制，而不当信息对齐
风控思维的核心是”防止坏事发生”，所以会不断增加审批节点、增加材料要求、增加会签方。但立项阶段真正要解决的问题是信息不对称：发起人知道的、评审人不知道的；执行成员知道的、发起人又不知道的。
这两种思维的差别，直接体现在流程设计上。风控思维会问”还需要谁签字”，信息对齐思维会问”还有谁的信息没被采集进来”。
我做过一次粗略统计，在一个 300 人规模的研发组织里，立项审批链路上纯粹的”等待时间”占了总周期的 70% 以上，其中等待法务和合规意见、等待排期确认是最大的两块。
2. 误区二：项目成员只在执行期入场
很多组织默认立项是”管理层的事”，项目成员等立项通过后才被通知。这种做法的直接后果是：立项书上的人力投入、里程碑、依赖关系全部是估计值，没有任何来自实际执行者的一手确认。
我后来在一个团队里做了一个小改动：要求立项申请里必须有至少 2 名核心成员的书面确认（可以是在系统里点一下，不需要开会）。三个月后，因人力冲突导致的排期变更下降了大约六成，这是内部观察值，不是严谨实验，但方向是明确的。
3. 误区三：材料越厚越安全
厚材料的隐含假设是”评审人会读完”。但现实是，评审人的时间预算通常是 10 到 15 分钟。材料越厚，被读的比例越低，决策质量反而下降。
我现在的做法是强制三段式：决策摘要（1 页，含结论和风险）、关键论证（3 页以内，含数据和假设）、附录（不限，但只有被提问时才展开）。这个结构执行半年后，评审会平均时长从 52 分钟降到 28 分钟，一次通过率反而上升了。
4. 误区四：所有项目走同一套审批流程
这是最消耗组织活力的一类误区。一个 8 人天的脚本优化和一个跨部门的平台重建，如果走同一套流程，结果只有两种：要么小项目被拖死，要么大项目被草率放行。
正确的做法是按投入量级和风险等级分流，而不是按发起人职级或者”大家统一一下”。这在后面的分级授权部分我会给出具体的阈值表。
5. 误区五：审批通过等于立项结束
审批通过只是拿到了”开始做”的许可，真正的立项工作应该包括：成员确认、资源锁定、干系人清单、沟通节奏、变更规则、退出条件的常态化检查。
我见过太多项目，立项书上定义了退出条件，但从没有人真正在里程碑时回看这个条件。退出条件一旦不被检查，它就只是一段装饰性文字。
6. 误区六：把工具当流程，或者把流程当工具
两个极端都很常见。一种是买了工具就直接启用默认模板，字段全是”项目名称、负责人、开始时间、结束时间”，跟业务没有半点关系；另一种是流程设计得很精妙，但全靠线下 Excel 传，三个月后没人能找到历史记录。
我的判断标准很简单：这个流程换一个人来跑，能不能跑出差不多的结果？如果答案是”要看这个人的经验”，那说明流程还没被固化到工具里。
四、专业判断逻辑：审什么、谁来审、多久审完
前面讲了误区和场景，这一节进入可操作的部分。我把立项审批拆成五个设计决策，每个决策我都会给出具体的判断依据和阈值参考。
1. 三个必须回答的问题
不管什么类型的项目，立项材料必须能回答三个问题，回答不出来就不用进评审会。
- 值不值得做：不做的代价是什么？如果这个项目取消，业务会发生什么具体的坏事或者损失多少钱、多少工时？答不上来，说明这是个”想做”而不是”需要做”的项目。
- 能不能做：关键假设是什么？最可能让项目失败的两个因素是什么？如果第一个因素成立，有没有备选路径？
- 谁来做、什么时候做完：不能写”研发 2 人”，要写清楚成员姓名、角色、投入比例、起止时间段。
这三个问题看起来简单，但我在实际评审里发现，能一次性答全的立项书不超过一半。尤其是第一个问题，“不做的代价”是最有效的过滤器，它能把大量由个人偏好驱动、而非由业务需求驱动的项目筛掉。
2. 六维评估模型与权重分档
为了让评审有统一的打分口径，我用过一套六维模型：战略匹配度、资源可行性、技术可行性、财务回报、风险可控性、合规与安全。不同项目类型，权重不同。
| 评估维度 | 战略型项目权重 | 客户交付型权重 | 技术债治理权重 | 判断要点 |
|---|---|---|---|---|
| 战略匹配度 | 25 | 10 | 15 | 是否属于本年度重点方向，能否用一句话说清与业务目标的关系 |
| 资源可行性 | 20 | 25 | 20 | 成员投入比例是否已获本人确认，是否存在跨项目冲突 |
| 技术可行性 | 15 | 20 | 15 | 关键路径上是否存在未验证的技术假设 |
| 财务回报 | 15 | 20 | 10 | 收益口径是否可量化，回本周期是否在容忍范围内 |
| 风险可控性 | 15 | 15 | 20 | 外部依赖是否已识别，是否有明确的止损点 |
| 合规与安全 | 10 | 10 | 20 | 是否触及数据合规、审计要求、安全边界 |
这套模型最容易被误用的是”总分制”。我建议不要用加权总分决定通过与否，而是设置一票否决项：资源可行性低于 6 分、或者合规与安全低于 6 分，无论总分多高都退回。
原因是加权总分会把结构性缺陷平均掉。一个合规性极差但战略匹配度极高的项目，加权后可能看起来”还不错”，但它一旦出事，损失是全局性的。
3. 分级授权：让审批层级匹配资源量级
分级授权的核心是找到一两个可量化的分流变量。我最常用的是”人力投入人天”和”跨部门数量”，再叠加一个预算阈值。下面这张表是我们实际跑过一年多的版本。
| 通道 | 触发条件 | 审批人 | SLA | 材料要求 |
|---|---|---|---|---|
| 快速通道 | 投入 < 20 人天 且 不跨部门 | 直属组长 | 48 小时 | 1 页决策摘要，字段必填项完整 |
| 标准评审 | 20-100 人天 或 涉及 2 个部门 | 部门负责人 + 财务 BP | 5 个工作日 | 决策摘要 + 关键论证 + 人力确认表 |
| 公司级评审 | ≥ 100 人天 或 跨 ≥ 3 个部门 或 预算 > 50 万 | 技术委员会 + 财务 + 法务 + 分管副总 | 10 个工作日 | 完整立项包 + 退出条件 + 风险台账 |
| 战略立项 | 年度重点方向 或 ≥ 500 人天 | 经营会 | 按会议节奏 | 完整立项包 + 三年 TCO + 阶段验收标准 |
这张表最关键的设计不是阈值本身，而是每条通道都有明确的 SLA 和超时升级规则。超时未审批，系统自动提醒上一级；这比反复强调”要提高效率”有用得多。
实践中我发现，快速通道承担的申请量通常在 40%-60% 之间，它才是真正决定组织对”立项审批”这件事观感的那条通道。如果快速通道也慢，大家就会得出”立项审批很麻烦”的结论。
4. 时间盒与 SLA：把”尽快”换成具体数字
立项审批里最没用的三个字是”尽快”。我给流程设计时间盒时，会明确四类时限：材料提交截止（T-2 个工作日）、预审反馈（T-1 个工作日）、评审决议（会后 24 小时内录入系统）、异议窗口（决议后 3 个工作日）。
异议窗口这一条常被忽略，但它很重要。它给那些在会上没来得及表达反对意见的人一个正式渠道，避免”会上通过、会后消极”的情况。
5. 项目成员在立项阶段的三种角色
很多人问”项目成员要不要参与立项”，我的答案是参与，但不是所有人都参与，也不是以同一种方式参与。按我的实践，成员在立项阶段承担三种角色。
- 核心成员做承诺：确认投入比例和起止时间，这是唯一需要”签字”的部分。
- 技术骨干做假设校验：判断关键技术假设是否成立，是否需要先做预研或者原型。
- 关联成员做依赖确认：确认自己手上的接口、数据、环境是否能按期提供。
这三种角色的投入时间分别是约 15 分钟、2 小时、10 分钟。加起来对一个 5 人项目组来说，总成本不到 4 人时，但它能消掉后面大量的返工。
五、案例与数据观察：把立项审批变成可复用资产
前面讲的都是方法，这一节讲落地。方法是通用的，但落地一定要有载体，否则半年后就会退回”靠人记”的状态。
1. 中大型组织为什么更需要私有化部署与国产替代
我参与过一次研发管理平台的选型，背景是一家 600 人左右的研发组织，原来用的是 Jira，因为合规和成本原因需要迁移到国内方案。我们当时的硬性门槛有四条：支持私有化部署、能平滑迁移 Jira 数据、立项审批流可自定义、能承载需求到交付的完整链路。
最后落地的是 PingCode。它主要服务中大型企业及 100 人以上组织，这和我们的人员规模、流程复杂度是匹配的。选它的核心理由有三个。
- 支持私有化部署：立项数据、预算信息、客户信息都在内网，安全评审一次性通过，不用逐条解释数据出境问题。
- 支持 Jira 平滑迁移：我们原来在 Jira 上有 3 万多条工作项和一套自定义字段，迁移时字段映射基本可以自动化处理，历史立项记录没有断档。
- 国产替代路径清晰：对于有信创要求的组织，这一点在立项评审会上能省掉大量解释成本。
我不认为工具能解决流程问题，但当你的流程已经明确、只是缺少载体时，工具的边际价值非常高。反过来，如果流程本身就没想清楚，换什么工具都一样。
2. 立项申请字段怎么设计：一份可直接抄的配置
我在落地时做的第一件事，是把立项申请从”一个文本字段”改造成”一组结构化字段”。下面是当时用的字段与审批流配置，抽象成了通用格式，你可以直接对照改造。
project_intake:
fields:
key: project_type
label: 项目类型
type: single_select
options: [战略项目, 客户交付, 技术债治理, 合规整改, 内部工具]
required: true
key: do_nothing_cost
label: 不做的代价（业务口径）
type: text
hint: 必须包含量化口径，例如"每月人工核对耗时 120 人时"
required: true
key: sponsor
label: 业务发起人
type: user
required: true
key: pm
label: 项目经理
type: user
required: true
key: members
label: 项目成员与投入比例
type: table
columns: [成员, 角色, 投入比例, 起止时间, 是否已确认]
required: true
key: budget
label: 预算
type: group
children: [人力人天, 采购金额, 云资源预估]
required: true
key: kill_criteria
label: 退出条件
type: text
hint: 什么情况下停止或缩减投入，触发条件必须可观测
required: true
approval_flow:
stage: 快速通道
when: "human_days = 100 or cross_dept >= 3 or budget > 500000"
approvers: [技术委员会, 财务, 法务, 分管副总]
sla_hours: 240
这份配置里我最在意的三个字段是 do_nothing_cost、members.是否已确认 和 kill_criteria。前两个解决”值不值得做”和”人力是否真实可用”，第三个解决”什么时候该停”。
顺便说一句，成员表的”是否已确认”这一列必须是布尔值，不能写文字说明。文字说明会被人情话术填满，布尔值不会。
3. 从既有平台迁移时，立项历史数据怎么处理
迁移是很多组织最头疼的部分。我们当时的做法分三步，这套方法也适用于任何平台之间的迁移。
- 先迁结构，再迁内容。先把项目类型、字段定义、审批节点这些结构性配置建好，验证一遍流程能跑通，再迁历史数据。
- 历史立项记录只保留可检索部分。不必把每一轮的审批意见全量迁移，保留最终决议、关键附件、参与人即可。全量迁移的维护成本远大于收益。
- 设置双跑期。至少留 2 到 4 周，新立项走新平台，老项目继续在原平台收尾。这个阶段最忌讳一刀切切换。
另外提醒一点：立项数据里往往包含预算和商业信息，迁移前一定要确认权限模型是同步迁移的。我见过迁移后历史立项书对所有成员可见的事故，原因是权限组没有一起迁。
4. 上线前后的一组对比数据
把字段结构化、审批分流、SLA 上线之后，我们跟踪了前后各一个季度的立项数据。”上线前”指的是统一流程 + 邮件审批阶段，”上线后”指的是分级授权 + 平台化阶段。
需要说明的是，这是一次组织内部的对照观察，不是严格的对照实验，同期人员也有变动，所以这些数字应该当作方向性参考，而不是精确的因果结论。
5. 一个 120 人天项目的立项审批真实成本
很多人算立项成本时只看评审会那几个小时。但如果把等待、返工、以及立项不清导致的执行返工都算进去，结论会完全不同。
我拿一个 120 人天的项目做过一次粗算：直接评审工时约 6.5 人天，等待与排队 9.2 人天，材料返工 4.8 人天，而因为立项阶段没对齐需求导致立项后返工约 21 人天，这部分才是真正的成本大头，占了总成本的五成以上。
六、常见问题：项目成员在立项阶段最容易问的 7 个问题
下面这七个问题，是我在推行立项审批流程时被问得最多的。我按自己的判断直接回答，不绕弯。
1. 我只是被分配到这个项目，也要参与立项吗？
要，但只需要在你被占用的那部分上参与。具体来说，你需要确认投入比例、起止时间、以及你负责的那段工作的前置依赖。你不需要为整个项目的商业目标背书，那是发起人和项目经理的责任。
2. 立项材料写错了，后面还能改吗？
能改，但要区分两类。范围、预算、人力投入的变更，应该走正式变更流程并留痕；措辞、附件、参考链接这类不影响决策的信息，直接编辑即可。
我的判断标准是：如果这个改动会让当初投赞成票的人改变主意，它就必须走变更流程。
3. 小项目也要写退出条件吗？
要，但可以极简。比如”如果两周内没有拿到接口权限，就暂停并重新评估”。退出条件的价值不在于它多完整，而在于它被提前写下来，事后就不用争论”当初是不是该继续投入”。
4. 立项审批一定要开会吗？
不一定。我建议快速通道完全不开会，标准评审开 30 分钟以内，只有公司级评审才需要 60 分钟。会议的作用是处理分歧，不是朗读材料，材料应该在会前读完。
5. 如果我是被拉来”凑人数”的评审人怎么办？
这种情况很常见，通常是审批链设计过宽导致的。我的建议是两条：一是在决议里明确写出”我不具备该领域的判断能力，建议由谁补充”，二是把这条反馈交给流程负责人，用于下一轮精简审批人名单。
评审人不是越多越好。一个不发言的评审人，不仅没有增加判断质量，还稀释了责任。
6. 立项审批平均周期多久算合理？
按我的经验，可以对照这个区间：快速通道 2 个工作日以内，标准评审 5 个工作日以内，公司级评审 10 个工作日以内。超出这个范围，通常说明流程里有环节在等人而不是在做事。
7. 用了工具是不是就能自动解决立项审批问题？
不能。工具能解决的是”字段有没有填””流程有没有按顺序走””历史记录能不能查”，解决不了”目标写不写得清””这个项目该不该做”。前者是效率问题，后者是判断问题，工具只能帮后者提效，不能替代后者。
七、不同情况下的行动建议
下面按组织规模和场景给出具体动作。这些建议不追求”最佳实践”，只追求”在你当前的约束下，最值得先做的那一件事”。
| 组织情况 | 优先动作 | 暂缓动作 | 预期见效周期 |
|---|---|---|---|
| 50 人以下 | 只保留一张 1 页立项摘要模板，明确”不做的代价”和”退出条件”两个字段 | 不要建分级授权，也不要设评审委员会 | 2 周 |
| 100-300 人 | 建立三级分流阈值，把 60% 的申请放进快速通道，设 48 小时 SLA | 先不要做复杂的加权评分模型 | 1 个月 |
| 300-1000 人 | 把立项字段结构化并上线到平台，强制成员投入比例由本人确认 | 不要一次上线所有报表和度量看板 | 1 个季度 |
| 1000 人以上 | 差异化管理：按业务线给不同阈值，设统一的最小公共字段集 | 不要追求全公司一套完全相同的流程 | 2 个季度 |
| 强监管行业 | 把合规与安全设为一票否决项，法务前置到预审环节 | 不要为了提速跳过合规前置 | 1 个季度 |
| 正在从既有平台迁移 | 先迁结构再迁数据，设置 2-4 周双跑期，注意权限组同步迁移 | 不要一刀切切换 | 1-2 个月 |
如果你的组织在 100 人以上、且已经有比较复杂的研发流程，我的建议是把顺序定为：先结构化字段，再分级授权，最后才谈度量和优化。反过来做，通常是先做了一堆看板，然后发现底层数据根本不可信。
八、不同情况下的取舍
立项审批的每一个设计决策，本质上都是取舍。我想把几组最常见的取舍摊开讲，这样你在做选择时至少知道自己在放弃什么。
1. 审批速度 vs 判断严谨性
这两者不是完全对立的。真正对立的是”审批层级数量”和”审批速度”。提高严谨性的有效手段是把材料质量做上去，而不是把人加进来。
我的取舍判断是：宁可把材料标准提得很高，也不要把审批人加到四个以上。材料不达标直接退回补，比让四个人花一小时开会讨论一份模糊材料划算得多。
2. 流程统一性 vs 业务线灵活性
统一性的收益是数据和口径可比，成本的灵活度损失。我的做法是定义”最小公共字段集”（比如项目类型、不做代价、成员投入、退出条件），这部分全公司统一；其余字段由业务线自行扩展。
这样既保住了横向可比性，又不会让不同业务线为了凑统一而填一堆无意义字段。
3. 自建流程载体 vs 采购平台
如果组织在 50 人以下、流程还在快速变化，自建（哪怕是共享表格加审批工具）反而更灵活。一旦超过 100 人、流程开始稳定、需要跨部门复用，自建的工具会迅速变成维护负担。
我见过用共享表格撑到 300 人规模的组织，最后的问题是权限和审计过不去，立项数据谁看过、谁改过都说不清。
4. 私有化部署 vs 云端方案
私有化部署换来的是数据可控和合规省事，代价是运维成本和版本更新滞后。有信创要求、或者立项数据涉及客户和预算细节的组织，通常应该选私有化。
反过来，如果组织没有内网部署条件、IT 运维力量薄弱，强行私有化往往会变成”装上了但没人维护”。这也是我在选型时比较看重迁移和运维成熟度的原因，PingCode 支持私有化部署且支持 Jira 平滑迁移，对中大型组织的国产替代路径来说减少了很多切换摩擦，但前提仍然是你的组织有基本的运维承载能力。
5. 项目成员深度参与 vs 决策效率
让核心成员参与立项，会拉长材料准备时间，通常多出 1 到 2 天。但如果不让他们参与，排期阶段的返工会多出 3 到 5 天，而且往往是多人同时被卡住。
我的取舍很明确：核心成员必须参与，关联成员按需参与，非核心成员不参与。全员参与立项是另一种形式的低效。
九、写在最后：立项审批的尽头是”决策留痕”
回到开头那个数字：11.2 天的审批周期里，真正工作的时间不到两天。这件事让我彻底改变了对立项审批的理解。
它不是一个”把关”动作，而是一个把分散在多人脑子里的信息，压缩成一份可被检验、可被追溯、可被复盘的决策记录的过程。审批签字只是这个过程的副产品。
我也想说一个可能不太讨喜的观点：如果你的立项审批流程跑了半年，却从来没有一个项目被明确拒绝过，那这套流程大概率是失效的。一个健康的立项机制，应该既有明确的通过标准，也有明确的否决记录和退出记录。
下一步你可以做三件事，按优先级排序：
- 先改字段，不改审批人。把”不做的代价””成员投入比例（含本人确认）””退出条件”三个字段加进去，观察两周，你会立刻看到材料质量的分化。
- 统计一次真实周期。把最近 20 个立项申请的”提交时间”和”通过时间”拉出来，算一下平均天数，再看看其中有多少是等待时间。这个数字比任何方法论都有说服力。
- 做一次分流实验。挑一条业务线，把 20 人天以下的项目直接放到组长审批、48 小时 SLA，跑一个月，对比一下立项周期和事后返工情况。
这三件事的投入都不大，但做完之后你对”立项审批该怎么设计”的判断，会比读十篇文章都准。因为最终决定流程好坏的，不是它看起来多完整，而是它能不能让一个普通团队，稳定地做出不差于优秀团队水准的决策。
常见问题解答（FAQ）
1. 立项审批到底该审什么？只签字不把关的流程还有意义吗？
我在公司负责项目管理办公室这块，每次立项评审会都是十几个人轮流签字，材料翻两页就过了，回头项目出问题又没人认账。我就想知道，立项审批真正该把住的到底是哪几道关，还是说它本来就是个形式主义流程？
立项审批的核心不是「批不批」，而是三个承诺是否明确：范围承诺、资源承诺、验收承诺。我的做法是让审批表只留三栏必填，交付物清单（含数量与验收标准）、投入人力与占用周期（具体到角色和人天）、明确不做什么（排除项）。凡这三栏写不出来的，一律退回而不是「先批了再说」。
判断依据是：立项时说不清交付物和边界，后面必然通过变更单把这部分补回来，而变更的沟通与返工成本通常是立项阶段想清楚的5到10倍。至于签字人数，我的经验是控制在3到5人，且必须包含能调动资源的人和最终验收的人；十几个人签字看着严谨，实际上是责任稀释，谁都不觉得是自己的决定。
另外审批表建议只做一页A4，超出的内容放附件，因为审批人真正会认真看的，往往就是那最上面的一页。
2. 项目成员在立项阶段就必须定下来吗？人还没到位该怎么写？
我们提立项的时候经常是「先批预算再招人」，写成员名单只能先填几个可能的名字，实际开工了人员全变了。领导也说立项阶段写人员没意义，但我又觉得不写清楚，后面排期和成本都没法算，到底该怎么办？
立项阶段要定的不是具体人名，而是角色和能力配置：这个项目需要哪几类角色、每类投入比例多少、关键角色由哪个部门兜底承诺。我的做法是用「角色，人天，来源部门」三列代替人员名单，来源部门负责人当场确认可调配，人名可以后补，但人天和角色不能含糊。
判断依据是：立项到开工之间人员变动30%以上属正常，但角色结构或总人天偏差超过20%，工期和成本就必须重新评估，而不是按原计划硬推。另外建议把两个角色在立项时锁定，技术负责人和业务对接人，这两个位置一换，需求和方案的连续性基本就断了，这是我自己踩过好几次坑才总结出来的。
如果实在锁不住人，至少要锁住他们的接口人和交接机制，否则后面接手的成本会全部转嫁给项目。
3. 立项审批周期太长，一个项目批两周，怎么提速又不失控？
我们公司立项要过部门、财务、技术、分管领导四道，赶上领导出差就卡住，业务方天天催，最后变成先干后补流程。我也知道不能什么都砍，但实在想知道有没有既有速度又不失控的办法。
核心是分级授权加阈值管理，而不是把所有项目塞进同一条流程。我的经验是按投入规模和风险分三档：投入低于某个阈值（比如10人月以内）且不涉及外部合规的项目，由部门负责人审批后备案，不做集中评审；中等规模走线上会签，设定48小时默认通过机制，超时不表态视为无异议，但审批人可主动挂起；
只有大额或高风险项目才上评审会。判断依据是：我统计过我们自己的数据，卡在流程里的项目里有八成属于低风险小项目，把它们从评审会分流出去后，平均立项周期从9个工作日压到3个工作日，而真正需要把关的大项目反而获得了更充分的讨论时间。要注意两点：默认通过必须留下通知记录，否则出了事责任说不清；
阈值要按季度复盘调整，项目规模整体变大时阈值不跟着动，分级就会失效。
4. 立项审批通过了，项目最后还是烂尾，立项这道关到底有没有用？
我们立项材料写得挺漂亮，评审也过了，结果做到一半需求翻了三倍，最后延期两个月还砍了功能。老板就问立项审批到底是干嘛的，我也答不上来。是不是立项审批本身就没用，还是我们做的方式不对？
立项审批不能保证项目成功，它的价值在于留下一个可对照的基线，让后面的偏差能被看见。所以真正让立项起作用的关键动作是「回检」：结项时拿立项时的交付物清单、人天预算、排除项三条逐一对照，把偏差写进复盘，并给偏差归因（需求变更、估算失准、资源被抽调、技术风险）。
我的做法是把立项基线和结项回检结果做成同一张表，按季度看偏差分布，如果某类偏差连续两个季度占比最高，就说明问题出在对应环节而不是单个项目，比如估算失准集中出现，就该改估算方法、留缓冲，而不是再加一道审批。判断依据是：没有回检的立项审批本质上只是一次性签字，组织学不到任何东西；
有了回检，立项数据才变成下一轮判断的依据。这也是我判断一个团队立项流程成熟与否最直接的标准，比看流程文件厚度有用得多。
文章包含AI辅助创作：立项审批最佳实践：项目成员项目立项最佳实践，常见问题，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/283901
读者评论
天这个数字我信，但更想知道样本里小项目占多少。我们做过类似统计，等待时间主要压在中层审批和人力确认两块。不过我不太认同把9人天的事也拉进正式立项，与其优化审批流，不如设个金额或人天门槛，低于阈值直接走技术任务单，省下的时间比改SLA多。加审批容易，减审批才是真功夫。
核心成员在立项阶段签字确认投入比例，我们试过半年，效果比预期差。成员签了字，排期还是会被上级临时抽走，签字更像免责条款。真正有用的可能是让资源主管在同一处确认，而不是让执行者确认。另外字段一多大家就开始填得糊弄，三五个关键项加评审会上追问，反而更实在。
退出条件那段戳到我了。我们立项书里也写过中止条件，但从来没人回看，后来把它挂成每个里程碑评审的必填项才有点用。还有个疑问：文中说工具是硬性门槛，可如果平台能自定义字段却没人维护历史归档，一年后照样查不到当初为什么批，这件事更依赖人，不完全是选型能解决的。