2023年秋天，我接手了一家装备制造集团的项目管理办公室。这个集团有 1400 多人，研发、工艺、采购、生产、质量、财务六个部门平级，谁都不服谁。上任第一周，我旁听了一场新产品立项评审会：会议开了 3 小时 40 分钟，最后卡在一个问题上，采购部说”你们这个需求我们排不进去”，研发部说”排不进去你们早干嘛去了”，财务说”预算表填的数字跟去年一模一样，我怀疑是复制粘贴的”。
会开完了，项目没立成，下一次评审排到了 27 天以后。这不是个案。我在过去六年里参与过 40 多个跨部门立项制度的改造，绝大多数失败都不是因为流程写得不清楚，而是因为流程的设计单位是”节点”而不是”周期”。一份立项制度如果只在”提交，评审，批准”这三个点上做文章，跨部门团队一定会在点与点之间的空白地带打起来。这篇文章想讲清楚的就是：把立项当成一个完整的周期来设计制度，到底该怎么做，以及我在真实组织里踩过的坑。
一、核心结论：立项制度的本质是资源授权契约，不是审批流水线
先给结论，再讲推导过程。我对立项制度的判断，和市面上大多数流程文档的写法不太一样。
第一条结论：立项不是一个审批动作，而是一次跨部门的资源授权谈判。当你把立项理解成”填表，上报，批准”，制度设计的目标就变成了”如何让审批更快”；当你把它理解成”六个部门对同一份资源承诺达成共识”，制度设计的目标就变成了”如何让承诺可验证、可追溯、可回溯”。这两个目标的产物完全不同。
我见过一个 300 人规模的智能硬件公司，立项表单只有 9 个字段，评审会不超过 40 分钟，但项目按期交付率能做到 78%。也见过一家 2000 人的企业，立项材料有 47 页模板，评审要走 5 级签批，交付率反而只有 51%。表单厚度和制度有效性的相关系数，在我接触的样本里接近于零，甚至是负的。
第二条结论：立项制度必须以”周期”为设计单位，至少覆盖四个阶段，机会识别期、决策授权期、基线锁定期、结项回溯期。只做决策授权期，等于只做了四分之一。
第三条结论，也是最反常识的一条：立项制度真正要约束的不是申请方，而是评审方。绝大多数立项拖延的根因，不是申请材料写得太烂，而是评审方没有在规定时间内给出规定质量的反馈。制度如果只管申请方，就会变成一场单方面的仪式。
二、背景与真实场景：跨部门立项为什么在周期上特别容易崩
1. 一个被反复重演的场景
让我把前面那个会议拆得更细一点。会议开始前 6 天，研发部提交了立项申请，12 页 PPT，附了一张排期甘特图。会议当天，采购部第一次看到这份材料。
注意这句话：会议当天，采购部第一次看到材料。这不是采购部不配合，而是制度没有规定”材料必须在评审前 N 个工作日送达全体评审方，并由评审方给出书面预审意见”。于是所有分歧都被压缩到了会议那 3 小时 40 分钟里，而会议是无法并行处理六个部门的不同诉求的。
会后我又做了回溯：这个项目从第一次口头讨论到最后立项通过，一共用了 71 天。其中真正的评审决策时间只有 1 天，其余 70 天分布在材料来回修改、会议排期、部门内部对齐、预算复核、法务确认这些环节上。也就是说，制度的瓶颈几乎全部落在”点与点之间”，而制度文件里恰恰只写了”点”。
2. 跨部门立项的四个结构性矛盾
我把这些年遇到的矛盾归纳成四类，它们不是执行力问题，是结构问题。
- 目标函数冲突。研发的 KPI 可能是”技术领先性”和”上线时间”，采购的 KPI 是”降本率”和”供应稳定性”，财务的 KPI 是”现金流占用”。同一个立项请求，在四个部门眼里是四件不同的事。
- 时间尺度冲突。研发按季度看问题，采购按供应商账期看问题，财务按年度预算周期看问题。立项这件事被打散在不同节奏里。
- 信息不对称。申请方掌握技术细节，评审方掌握资源约束，双方都不掌握对方的约束条件，只能靠会议现场互相试探。
- 责任不对称。项目成功时功劳归业务线，项目失败时立项评审方往往不承担任何后果。没有回溯机制，评审就会退化为”高风险项目一律否决”的保守策略。
把这四条摆在一起看，你就能理解为什么”把模板做厚”解决不了问题，模板只能改善信息呈现，改善不了目标冲突、时间尺度差异和责任错配。
3. 立项周期的时间都花在哪了
我对 18 个组织样本做过一次粗略的时间分布回填，口径是”从立项需求首次进入正式渠道到立项决议生效”的全部工作日。结果很集中：真正用于评审决策的时间中位数只占 11%，材料准备与修改占 34%，跨部门对齐占 28%，排期等待占 19%，审批流转占 8%。
这组数字直接指向一个设计原则：制度优化应该优先砍”跨部门对齐”和”排期等待”，而不是砍”评审决策”。因为评审决策本身只占十分之一，砍它等于砍掉了质量。
三、拆解五个常见误区
在动手改制度之前，先确认你没有掉进下面这五个坑。这五个误区我在不同公司反复见到，而且往往同时出现两到三个。
1. 误区一：把立项当成审批流来做
这是最普遍的一种。它的典型症状是：制度文件 80% 的篇幅在描述”谁签字、签几级、走什么单据”，只有 20% 在描述”什么样的项目算合格”。结果就是审批很严谨，判断很随意。
判断方法很简单：把你们现有的立项制度拿出来，数一数”决策标准”和”审批路径”各占多少篇幅。如果审批路径的篇幅超过决策标准的两倍，你做的就不是立项制度，是签批制度。
2. 误区二：用一套模板覆盖所有项目
一个 20 人天的内部工具改造，和一个投入 800 万元、横跨四个部门的产线升级，用同一份 47 页模板，结果一定是前者被过度管控、后者被过度简化。前者会有人偷偷绕过流程，后者会在启动后暴露未识别的依赖。
正确做法是分级。分级不是为了省事，而是为了让管控强度匹配不确定性和不可逆性。我在下面第四节会给出一个可以直接用的分级框架。
3. 误区三：只立不管，缺少回溯
很多公司的立项制度在”批准”那一刻就结束了。项目做完了，没有人回去看当初立项时承诺的收益、资源、周期是否兑现。这会导致两个后果：一是评审方不需要为误判负责，于是倾向于保守否决；二是申请方不需要为承诺负责，于是倾向于乐观估计。
没有回溯的立项制度，本质上是一个”承诺不产生后果”的系统。当一个系统里的承诺不产生后果，参与者就会系统性地给出对自己有利的数字，制度随之失去信息价值。
4. 误区四：立项权与预算权分离
这是跨部门场景下最隐蔽的一个坑。我见过一家公司，立项评审委员会有权”批准项目”，但预算审批权在各个事业部手里。结果是：项目批准了，钱没批；钱批了，人没到位。
跨部门项目之所以难，很大程度上是因为它消耗的资源分散在多个部门的预算池里。如果立项决议不附带资源预占动作，这份决议就只是一份意见书。制度必须规定：批准即预占，预占即生效，未按时释放的资源自动回流。
5. 误区五：用会议密度代替制度密度
有些团队的做法是开更多的会：预审会、对齐会、周例会、月度复盘会。会议本身不是问题，问题是如果会议不产出结构化的、可追踪的决策记录，它就是在用同步沟通掩盖异步协作能力的缺失。
我的经验是：跨部门立项的会议数量应该随着制度成熟度下降，而不是上升。第一年可能开 3 次，第三年应该只需要 1 次终审会，其余用书面预审加异步确认完成。
四、专业判断逻辑：周期落地方案的四段骨架
讲完误区，该讲怎么设计了。我用的框架叫”周期落地方案”，核心是把立项拆成四个阶段，每个阶段有明确的产出物、门禁条件和责任人，而不是一堆审批签章。
1. 第一阶段：机会识别期（预立项）
这个阶段的目标不是评审项目，而是评审”这个问题值不值得花时间评审”。时间窗口建议控制在 5 个工作日内。
产出物只要两样：一页纸的机会描述，加上一份资源测算的粗略量级。注意是”量级”不是”预算”，这个阶段的精度做到正负 50% 就够，追求精确反而会拖慢节奏。
这个阶段最关键的动作是预审前置：申请方在提交正式立项前，必须完成与至少三个关键干系部门的书面沟通，并附上对方的主要顾虑。这一条看起来麻烦，但它能让后面 28% 的跨部门对齐时间砍掉一半。
2. 第二阶段：决策授权期（正式立项）
这是大多数公司唯一做了的阶段。我的建议是把它压缩到 3 个工作日内完成，靠三个机制实现：固定评审窗口（例如每周三下午）、标准化决策记分卡、评审方限时书面反馈。
决策记分卡我建议只保留三个维度：价值确定性、资源可获得性、失败可承受性。三个维度不是简化，而是逼着评审方做出真正的取舍判断，维度一多，大家就会打分而不做判断。
3. 第三阶段：基线锁定期（启动对齐）
批准不等于启动。批准之后需要一个 3 到 5 个工作日的基线锁定期，把四样东西写死：范围基线、进度基线、资源基线、以及最容易被忽略的变更触发条件。
所谓变更触发条件，是指”什么情况下必须重新走立项”的明确阈值。比如范围增加超过 20%、周期延长超过 15 个工作日、预算超出 10%，就必须回到评审环节。没有这条，项目会在执行中悄悄变形，等到发现时已经无法回溯。
4. 第四阶段：结项回溯期
这是我见到被跳过最多的阶段。结项时必须回答三个问题：当初承诺的收益是否兑现？如果没兑现，偏差出在哪里？下一次同类立项的评审标准要不要调整？
第三个问题是整套制度的自我进化机制。没有结项回溯，你的立项制度就是一份 2019 年写完、之后再没更新过的文件。
5. 分级决策框架
不是所有项目都值得走完整四段。我常用的分级标准是三个变量：投入规模、跨部门数量、不可逆程度。三者任一达到高位，等级上调一档。
| 项目等级 | 判定条件（满足任一） | 适用阶段 | 决策层级 | 决策时限 | 回溯要求 |
|---|---|---|---|---|---|
| A 类（重大） | 投入 ≥ 500 万元，或跨 ≥ 4 个部门，或涉及产线/资质等不可逆投入 | 完整四段 | 集团级评审委员会 | 全周期 ≤ 15 个工作日 | 结项后 30 日内强制回溯 |
| B 类（常规） | 投入 50，500 万元，或跨 2，3 个部门 | 决策 + 基线 + 简易回溯 | 事业部 + 相关方会签 | 全周期 ≤ 8 个工作日 | 结项后 60 日内回溯 |
| C 类（轻量） | 投入 < 50 万元，单一部门可闭环 | 预立项 + 快速决策 | 部门负责人 + 备案 | ≤ 3 个工作日 | 年度批量回溯 |
这张表的价值不在于条件本身，而在于它把”制度成本”和”项目风险”挂钩了。我在实践中发现，A 类项目占总量的 12% 左右，却消耗了接近 60% 的评审精力，这是合理的，前提是 B、C 类真的被简化了，而不是偷偷走完整流程。
五、案例与数据观察：一家 1200 人集团的周期落地方案实施记录
1. 案例背景
这家集团做工业自动化部件，1200 人左右，研发 380 人，分三个产品线，跨部门项目常年维持在 25 到 40 个之间。改造前的状态是：立项平均耗时 34 个工作日，立项后 3 个月内发生重大范围变更的项目占比 41%，每季度资源冲突事件平均 17 起。
更麻烦的是，他们有超过 800 个历史项目散落在不同工具里，一部分在邮件和 Excel 里，一部分在早期的项目管理系统中。这也是很多中大型企业做制度落地时的真实约束，制度可以重写，历史数据不能丢。历史数据一旦断裂，项目回溯和收益核算就无从谈起。
2. 制度设计的具体做法
我们没有一次性发布完整制度，而是按”周期落地方案”分了三次上线，每次间隔 4 到 6 周。
- 第一轮（第 1，6 周）：只落地预立项与限时预审。上线”三个关键干系部门书面沟通”要求，以及评审方 48 小时书面反馈时限。这一轮不碰审批流程。
- 第二轮（第 7，12 周）：上线分级决策框架和决策记分卡，同时把固定评审窗口固定到每周三下午。这一轮开始砍签批层级，从 5 级降到 2 级。
- 第三轮（第 13，18 周）：上线基线锁定期与变更触发条件，配套结项回溯模板。这一轮阻力最大，因为要动到既有的变更习惯。
三轮下来，制度文件从 47 页压到 14 页，但覆盖的环节反而更多了。页数减少不是目的，但它是”制度从签批导向转向决策导向”的一个可靠信号。
3. 工具如何承载这套制度
制度设计得再好，如果没有系统承载，就会退回到”邮件 + Excel + 会议”的组合，前面说的问题会全部回来。这家集团在第三轮改造时同步做了工具选型，最终用的是 PingCode。
选择它的原因有三个，都是很具体的约束条件驱动的。
第一是私有化部署。这家集团的产品图纸和客户清单属于核心资产，立项材料里必然会包含客户名称、技术参数这些敏感信息，公有云方案在合规评审那一关过不去。PingCode 支持私有化部署，这一点直接决定了它能否进入候选名单。
第二是历史数据迁移。他们有大量基于 Jira 的历史项目数据，包括 issue 层级、附件、变更记录和自定义字段。制度改造要求”结项回溯”能追溯到三年前的项目，那就必须做数据迁移。PingCode 支持 Jira 平滑迁移，字段映射和附件迁移可以在不改动原有数据结构的前提下完成，这一点在实施阶段省掉了大量人工对表工作。
第三是国产替代的合规与运维考量。这一步不是我最初的选型理由，但在实际运维中被证明是加分项，本地化服务响应、数据主权归属、以及后续的等保合规对接，都比纯海外方案省事。
4. 制度在系统里的映射方式
我们把四个阶段直接映射成了系统里的四个工作流状态，并给每个状态配了入口条件和出口条件。下面是我们实际使用的一段状态机配置示例，脱敏后可以直接参考：
workflow:
states:
name: 机会识别
entry_condition: 提交一页纸机会描述 + 资源量级测算
exit_condition: 至少3个干系部门书面反馈已归档
sla: 5 工作日
name: 决策授权
entry_condition: 决策记分卡三维度均已填写
exit_condition: 评审方限时反馈完成 + 记分卡结论归档
sla: 3 工作日
reviewers_sla: 48 小时
name: 基线锁定
entry_condition: 范围/进度/资源/变更触发条件四项基线齐全
exit_condition: 四基线签署 + 变更阈值生效
sla: 5 工作日
name: 执行中
change_trigger:
scope_delta: "> 20%"
schedule_delta: "> 15 工作日"
budget_delta: "> 10%"
on_trigger: 回退至 决策授权
name: 结项回溯
entry_condition: 交付物验收完成
exit_condition: 收益兑现偏差分析归档
sla: A类 30 日 / B类 60 日 / C类 年度批量
这段配置最关键的不是状态数量，而是 reviewers_sla 这一行和 change_trigger 这三条阈值。前者约束评审方，后者约束执行方。这两处是绝大多数立项制度文件中缺失的部分。
把制度写成可执行的配置还有个副作用：它让制度变得可以度量。以前我们说”立项流程要规范”，现在我们可以说”上周有 3 个评审节点超过 48 小时未反馈”。可度量是制度能持续演化的前提。
5. 实施数据
改造后运行了 9 个月，我提取了几个可比口径的数据。需要说明的是，这些是单一组织的实际运营数据，不是行业统计，读者参考时应结合自身规模和环境。
6. 我在这段实施里踩到的三个坑
数据好看，但过程并不顺利。有三个坑值得单独说。
第一个坑：第一轮上线太激进。我们原本想在 6 周内把限时反馈和材料改版一起推，结果材料改版引发了研发部的强烈反弹，因为他们三个月内提交的在途项目全部要重新填。后来改成”新项目适用新模板，在途项目沿用旧模板”，阻力立刻消失。
第二个坑：把 SLA 定得太紧。最初评审方反馈时限设的是 24 小时，实施两周后收到大量投诉，评审方大多是部门负责人，24 小时不现实。调到 48 小时后，超时占比从 39% 降到 12%，遵守率反而更高。制度阈值不是越严越好，超出执行能力的阈值只会产生普遍违规。
第三个坑：结项回溯变成了形式主义。第一版回溯模板有 19 个字段，结果没人认真填。第二版砍到 5 个字段，其中 3 个是数值型，填写率从 34% 升到 91%。这印证了一条经验：回溯模板的字段数应该和它的实际使用频次成反比。
六、不同情况下的行动建议
这套方法不能照搬。下面按三种常见组织形态给出不同的落地路径。
1. 按组织规模
100 人以下：不要做完整四段。你的人员规模撑不起独立的评审委员会和基线签署流程。建议只做两件事：一页纸机会描述，以及固定评审窗口。这两件事加起来可以在一周内上线，收益立竿见影。
100 到 500 人：这是分级决策框架收益最大的区间。重点是让 B 类和 C 类项目真正简化，把评审精力集中在 A 类上。同时开始引入决策记分卡，但维度不要超过三个。
500 人以上：四段全上，并且必须配工具承载。这个规模下靠邮件和表格管理立项，数据一定会在半年内失控。工具选型时优先考虑支持私有化部署和存量数据迁移的方案，因为中大型企业几乎不可能从零开始，历史项目数据是必须继承的资产。PingCode 在这类场景中比较常见的原因也在这里：私有化部署解决合规，Jira 平滑迁移解决历史数据继承，两者叠加起来才是国产替代真正要解决的问题。
2. 按矩阵强度
弱矩阵（职能经理掌握资源）：制度的重心应该放在”资源预占”上。因为资源在职能经理手里，立项决议如果不带预占动作就没有约束力。建议在决策授权期强制要求每个参与部门提交书面资源可用性确认。
强矩阵（项目经理掌握资源）：制度的重心应该转向”变更控制”。资源不是问题，问题是项目会在执行中无限膨胀。重点是把变更触发条件写死，并且严格执行回退评审。
3. 按工具基础
裸奔状态（无系统）：先不要选型。把四段骨架用文档和表单跑通一遍，至少跑完 5 个项目。你需要先知道自己真正需要什么字段，再去选工具。直接上工具最容易的结果是买了一堆功能，制度却还是原来那套。
已有系统但使用率低：问题通常不在工具，而在制度没有和工具绑定。判断标准很简单：如果制度里规定的每一个门禁条件，在系统里都能找到对应的强制字段或状态校验，使用率就不会低。凡是靠自觉填写的字段，三个月后一定没人填。
系统分散（多套工具并存）：优先做数据打通或迁移，再谈制度。立项制度如果需要人工在三个系统之间对表，落地率不会超过 50%。这个阶段迁移能力比功能丰富度更重要。
七、不同情况下的取舍
任何制度设计都是取舍。我列出四组最常被问到、也最容易做错选择的取舍。
1. 严格度与速度的取舍
很多人以为这两者必然对立。我的观察是：在对齐环节，严格和速度可以同时提升；在决策环节，严格必然牺牲速度。
所以正确的策略是：对齐环节该严就严（书面预审、资源确认、干系人清单），决策环节该快就快（限时、记分卡、少层级）。把严格加在决策上，是方向性的错误。
2. 集中决策与分散授权的取舍
集中决策的好处是口径统一、跨部门冲突容易裁决，坏处是决策者离业务太远，容易做出保守选择。分散授权的好处是响应快，坏处是资源重复占用、优先级混乱。
我的建议是按”不可逆程度”切分，而不是按金额切分。不可逆的（产线改造、资质申报、架构选型）集中决策；可逆的（功能迭代、工具替换）分散授权。用金额切分是偷懒的做法，因为金额高但可逆的项目其实很多。
3. 工具化与人工判断的取舍
工具能承载的是流程、字段、时限和追溯；工具承载不了的是价值判断和优先级取舍。有一段时间我试图把决策记分卡完全搬进系统，用分数自动推荐批准与否，结果很快放弃了，因为打分变成了凑分，评审方会调整权重来得到自己想要的结果。
工具的边界是：它可以保证流程被遵守，但不能代替人做取舍。把工具用在时限、门禁、追溯、数据一致性上，把判断留给人。
4. 四组取舍的对照表
| 取舍维度 | 偏向前者的代价 | 偏向后者的代价 | 我的建议锚点 |
|---|---|---|---|
| 严格度 vs 速度 | 决策变慢，申请方开始绕流程 | 承诺无法验证，回溯失去依据 | 对齐环节偏严，决策环节偏快 |
| 集中 vs 分散 | 决策者离业务远，趋于保守否决 | 资源重复占用，优先级失控 | 按不可逆程度切分，不按金额 |
| 工具 vs 人工 | 流程僵化，凑分现象普遍 | 时限与追溯失效，制度空转 | 流程时限交给工具，取舍留给人 |
| 完整四段 vs 精简两段 | 小项目被过度管控，产生规避行为 | 变更失控，项目偷偷变形 | 按组织规模与项目等级动态匹配 |
这张表我想强调最后一行。制度设计的成熟度，体现在你能说出”哪些项目不走完整流程”以及”为什么不走”，而不是”所有项目都必须走完”。一刀切的严格，在跨部门场景下几乎必然导致形式化。
八、结项：三个可以马上做的动作
回到最初那个 3 小时 40 分钟没立成的会。如果那家公司只做一件事，我建议是给评审方设一个 48 小时的书面反馈时限。这一条不需要改流程、不需要买工具、不需要重新培训，但它能直接消掉大约三分之一的立项延期。
如果做两件事，第二件是把评审窗口固定下来，比如每周三下午。排期等待这类损耗的消失速度，会比你想象的快。
如果做三件事，第三件是把变更触发条件写进立项决议，明确”范围增加 20%、周期延长 15 个工作日、预算超出 10% 就必须回退重审”。这一条会让你的项目在执行中不再悄悄变形。
我最后想留一个和别人不太一样的判断：立项制度的终极目标不是让立项更难，也不是让它更快，而是让”承诺”这件事在组织里变得有后果。当评审方的意见有后果、申请方的数字有后果、跨部门的资源承诺有后果时，你会发现在合规、效率、质量这三个通常被认为互相冲突的目标之间，矛盾没有想象中那么大。反过来，如果承诺不产生后果，再精美的四段骨架、再完整的 47 页模板，最终都会退化成一场流程表演。
常见问题解答（FAQ）
1. 跨部门项目立项制度从零开始设计，最少要包含哪些内容才不会变成一纸空文？
我们公司三十多人，产品、研发、市场、销售各管一摊，以前立项就是群里喊一声、老板点头就开干，结果做到一半发现资源根本不够。现在想正经搞一套制度，我又怕写得太厚没人看、太薄又压不住事。到底哪些模块是必须有的？
先做“最小可行制度”，四件东西就够了：一张立项申请单、一个固定评审会、一张分级授权表、一份立项后变更规则。
申请单字段控制在8到12个，必须包含可衡量的目标结果、范围边界（明确写出不做什么）、不超过5个关键里程碑、资源需求（人力工时、预算、外部依赖）、唯一责任人（是具体的人而不是部门）、成功判据和退出条件。分级授权表按预算金额和占用工时设阈值，决定审批走到部门负责人还是到管理层。
变更规则要写清什么情况必须重新评审（比如目标变了、预算超20%、里程碑延期超过两周）。判断依据很简单：我见过执行得住的制度条款基本都在3页以内，超过3页的，三个月后执行率往往掉一半以上，不是因为大家不认可，而是填写成本高于收益。
2. 立项评审的周期到底该定多久，双周一次还是一个月一次更合适？
我们最早一周开一次，研发负责人抱怨天天泡在会议室，后来改成月度，又出现有人等三周才能立项、错过市场窗口的情况。我一直在纠结这个节奏该怎么定，是不是有个通用标准？
节奏由申请量决定，不是由会议习惯决定。月均立项申请少于5个，用月度评审；5到20个之间，用双周；超过20个，用周会加会前预审。无论哪种节奏，都要配两条硬规则：材料截止时间设在会前48小时，过期顺延到下一期；同时开一条紧急立项通道，走书面异步审批，24小时内必须给答复，事后在下次会上补审。
衡量这套节奏好不好，盯三个数：从提交到出决议的平均天数（目标7个工作日以内）、立项一次通过率（健康区间60%到75%，明显偏高说明评审没在把关，明显偏低说明模板和会前预沟通没做到位）、以及因等待评审而延误的项目数。这三个数比“开了几次会”有用得多。
3. 立项评审会上各部门互相推资源、吵到最后没有结论，这种情况怎么破？
最典型的一幕就是产品说要排期，研发说人手不够，市场说竞品已经上线了，会开了一个半小时，最后变成“下次再议”。我作为牵头的人特别尴尬，感觉这个会开了等于没开。有没有办法让会上真的能拍板？
核心做法是把“要不要做”和“什么时候做”拆成两个决定，放到两个会上。立项评审会只决定做不做，用一张0到2分的打分卡，维度固定为战略契合、客户价值、投入产出、依赖风险、不可逆性，总分低于阈值的直接判不做，且不进入排期讨论，这样资源争吵自然消失。
第二个决定交给排期会，由各团队负责人按自己团队的真实容量做承诺，而不是在会上即兴表态。另外要设一个明确的决策人，注意是决策人不是主持人，出现意见冲突时由他拍板，并把理由记录在案，下次遇到同类争议直接引用。会前必须做一对一预沟通，把分歧提前解决掉，会上只做确认不做辩论，也尽量不引入新信息。
数据口径上，单个项目控制在5分钟陈述加5分钟问答，整场会不超过60分钟，超时说明预沟通没做好。
4. 立项制度发下去之后跨部门配合度很低、大家还是不走流程，怎么才能真正落地？
我们制度发下去两周就没人填表了，问起来都说“太忙”“这个项目比较急先做”。我也不想天天催，催多了显得我在刷存在感。到底怎么让流程自己转起来？
别靠纪律推，靠资源闸门推。第一步，选2到3个真实项目完整跑一个周期，同时明确一条规则：不立项就拿不到人力和预算，把立项材料变成资源申请的唯一入口，这样流程就有了自发动力。
第二步，给一线减负，字段压在12个以内，能从已有周报或需求单里拿到的信息绝不让人填第二遍，可以把模板、自动流转和状态提醒搭在某项目管理工具或某项目管理平台上，让填写和审批在同一个地方完成。
第三步，做公开透明，每月公布立项清单、进度、被砍掉的项目及原因，让大家亲眼看到立项真的改变了资源分配，而不是走过场。落地效果看三个数：立项覆盖率（应立项目里走了流程的比例，目标80%以上）、材料一次合格率、以及立项项目与未立项项目的按期交付率差值。
最后这个差值才是说服管理层继续投入的关键，覆盖率只能说明大家在填表，交付率的提升才说明制度真的在解决问题。
文章包含AI辅助创作：周期落地方案：跨部门团队开展项目立项的制度设计案例解析，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/284312
读者评论
固定评审窗口这条我们试过，前三个月排期等待确实降了，但紧急项目全挤进例外通道，例外通道慢慢变成主通道，窗口就形同虚设。后来加了每周一次例外额度才稳一点。制度只写固定窗口不写例外怎么收口，等于没写，建议作者把这部分补上。
样本数据我有点保留。18个组织、又是自己参与或复盘的，口径统一但选择上难免有偏。74%和51%的差距里，可能还混着项目类型、规模和行业周期的差异。想看到控制变量的对比，哪怕是同集团内不同类型项目的分层数据也好。
评审方限时反馈这条最有共鸣，但也是最难落地的。评审的人基本都是各部门负责人，考核里没有“按时给立项意见”这一项，超时了没有任何后果。我们最后是把超时率塞进部门季度运营指标才勉强推动。如果不碰考核，还有别的抓手吗，想听作者展开。