周期落地方案：管理层开展项目立项的制度设计案例解析

我见过最贵的一张立项审批表，是某家320人科技公司的A4流程单，七个签字栏，最长一次走了23天才签完，而那个项目本身只跑了11天就黄了。季末复盘时评审会的结论是”立项时就不该通过”。这不是审批不严，而是审批严错了地方：制度卡在了流程上，没有卡在资源承诺上。这也是我写这篇《周期落地方案：管理层开展项目立项的制度设计案例解析》的起点，一套立项制度的优劣，不看它筛掉了多少项目，而看它能不能让错误的项目尽早、低成本地退出去。

一、核心结论：立项制度的本质是”资源承诺的可撤销性设计”

先说结论。绝大多数企业把立项当成一道”准入审批”，我判断它应该是一份”可撤销的资源承诺”。这两个定位差一个字，落地效果差一个数量级。

1. 立项不是审批动作，而是资源锁定动作

审批的逻辑是”你能不能做”，资源承诺的逻辑是”我拿什么给你做、做多久、什么时候必须还回来”。前者只需要一张表和一个签字人，后者需要三个东西：明确的人力/资金额度、明确的占用周期、明确的退出触发条件。

我在做组织诊断时有个固定动作：把公司最近一个季度的立项申请表调出来，看里面有几个字段是”资源额度”和”退出条件”。如果这两类字段一个都没有，我基本可以预判这家公司的立项会退化成排队游戏，不是比谁的项目更重要，而是比谁更会写材料、谁跟领导更熟。

2. 周期落地 = 把一次性的年度承诺，切成可撤销的季度承诺

“周期落地”这四个字，很多团队理解成”按季度做计划”。我判断这是错的。周期落地的核心是把资源承诺的有效期从12个月缩短到3个月，让每一次续期都变成一次重新决策，而不是一次惯性延续。

年度立项的问题不在于它不严谨，而在于它太”一次性”。Q1通过的37个项目，到Q3可能只剩一半在跑，但预算是年初锁的、编制是年初占的，剩下那一半死项目的资源不会自动回流。组织于是陷入一种怪状态：账面上人手满满，新需求却要排4到6周。

3. 必须写进制度文件的三个数字

不管公司规模多大，我认为立项制度里必须硬性写清三个数字，缺一个制度就会漏气：

• 立项窗口频率：一年开几次立项窗口（常见是4次，季度末各两周）。窗口之外只接受”紧急通道”申请，且紧急通道要有配额上限。
• 资源承诺有效期：一次立项承诺占用多久（建议90天），到期未续期自动释放，不需要任何人签字同意。
• 反悔窗口时长：立项后多少天内可以零成本撤销（建议14到30天），撤销不追责、不计入部门失误率。

第三个数字是最容易被砍掉的，也是最重要的。没有反悔窗口的立项制度，最后一定会演变成”为了不承认错误而硬撑”，因为一旦立项即承诺，撤销就等于自我否定，理性选择就是拖着。

二、真实场景：为什么”周期落地”比”年度立项”更难推行

讲完结论，得讲讲它为什么难。年度立项虽然笨，但它是”一次性痛苦”；周期落地是”每季度都要痛一次”。管理层的心理成本完全不同。

1. 一家320人公司的年度立项崩坏全过程

这家公司做企业级SaaS，研发加产品约180人，其余是销售、交付和职能。2022年初他们做年度立项，流程是”部门提报，PMO汇总，高管评审会，预算锁定”。Q1一次性通过了37个项目，覆盖新功能、老系统重构、内部工具、合规改造四大类。

到Q3我进场做诊断时，实际情况是这样的：37个项目里真正还在推进的只有19个，8个项目”还在做但没人说得清进度”，10个项目事实上已经停了但没走任何终止流程，编制和预算还挂在上面。

（1）销售侧反馈新需求平均要等4到6周才能排进资源，因为”资源池是满的”。
（2）研发侧反馈疲于应付多个项目并行，人均同时在跑3.4个项目，上下文切换严重。
（3）PMO 反馈最尴尬：他们手里有一份37行的Excel台账，但每行状态都是”进行中”，没有一行是”已终止”。

这就是典型的”只进不出”。立项制度设计得再严密，只要没有退出机制，资源池就会从游泳池变成沼泽。

2. 周期落地撞上的三堵墙

后来我参与设计并推动他们的季度立项改造，前后三个季度，撞了三堵很硬的墙，我判断这三堵墙在所有中大型组织里都会出现。

第一堵墙是”季度重审等于否定我”的心理墙。部门负责人把”项目没被续期”理解为对自己能力的质疑，于是拼命包装数据争取续期。破解方式是把续期决策从”评价人”改成”评价条件”，用统一的续期四问，谁的项目都过同一套问题。

第二堵墙是”紧急通道被滥用”的制度墙。制度一收紧，所有人都会说自己是紧急项目。破解方式是给紧急通道设硬配额，比如每季度不超过总立项数的15%，且紧急通道项目必须在下个窗口补交完整材料。

第三堵墙是”数据不可见”的工具墙。制度要求季度重审，但如果重审材料要靠PMO手工收集两周，制度撑不过两轮。这一堵墙必须靠工具解决，我在第五节会具体讲我们的做法。

3. 一个反直觉的数据观察：立项越多，交付越差

我把这家公司8个季度的数据拉出来做了相关性分析，得到一个反直觉但很稳定的结论：季度立项数量与项目按时交付率呈明显负相关。立项数超过25个的季度，按时交付率没有一次超过60%；立项数控制在20个以内的季度，按时交付率都在75%以上。

这不是简单的”少做就好”，背后的机制是：每个项目都需要固定比例的协调成本（评审、对齐、联调、验收），当并行项目数超过某个阈值，协调成本会非线性上升。我的经验阈值是，一个研发小组（6到8人）同时承接的项目不应超过2个，超过3个就会出现明显的进度谎报。

三、拆解六个常见误区

在讲制度设计逻辑之前，我想先把踩过的坑摆出来。这六个误区我几乎在每一家做立项诊断的公司里都能碰到至少三个。

1. 把立项当成”申请预算的表单”

预算和立项是两件事。预算是钱的授权，立项是人的承诺。很多公司把两者合一，结果是”钱批了但人没到位”，或者”人到位了但钱没批”，项目卡在中间。我判断正确的做法是：预算按年、立项按季度，两者通过”资源折算表”连接，一个季度的人力承诺对应多少预算额度，写清楚换算口径。

2. 用统一模板覆盖所有规模的项目

一个3人两周的小改动和一个30人半年的平台重构，用同一套立项材料，结果一定是”小的嫌重、大的嫌轻”。小人项目为了填表耗费大量精力，大项目又因为材料模板的限制漏掉关键风险。

我在实践中坚持三级门槛：轻量级项目（预估≤20人天）只需要一页纸的问题描述和验收标准；标准级项目（20到200人天）需要资源折算和里程碑；重载级项目（>200人天或跨3个以上团队）需要完整商业论证、风险清单和退出条件。

3. 只在立项环节设卡，不设退出机制

这是最致命的误区。立项制度如果只有入口没有出口，本质上就是一个单向阀，进来的资源再也出不去。我在诊断时经常用一个指标判断：过去12个月的主动终止项目数 ÷ 立项总数。如果这个比值低于5%，制度基本是失效的，因为任何组织都不可能做到95%以上的项目一次做对。

4. 用”通过率”考核PMO

一旦PMO的KPI里出现”立项通过率”，他们就会迅速分成两类人：要么变成橡皮图章（通过率90%以上，制度形同虚设），要么变成守门员（通过率30%以下，业务侧怨声载道）。

我建议把PMO的考核指标换成”立项决策质量”，包括立项后30天内撤销率、重载项目的一次通过率、以及”立项时判断与实际结果的一致性”。这些指标衡量的是判断力，而不是控制力。

5. 立项决策依赖职级，而不是领域专家

“谁官大谁立项”是很多公司的隐性规则。管理层评审会上一把手拍板，其他人附议，看起来效率很高，实际上是让最不了解技术细节的人承担了最大的判断责任。

我判断更合理的结构是双轨决策：技术可行性由领域专家（架构师、技术负责人）判断并签署意见，商业价值由管理层判断。两者都通过才立项，任何一方否决都可以要求补充材料重审，但都不单独决定。

6. 立项后不建档、不复盘

没有台账就没有复盘。我见过太多公司，问”上个季度立了哪些项目、现在什么状态”，要靠三四个人翻微信记录和邮件才能拼出来。这种情况下，季度重审根本无从谈起。

立项台账必须是一个活的对象，而不是一份死文档。每个项目从立项那天起就带着三个字段：承诺资源、承诺周期、退出条件。这三个字段在季度重审时被重新确认或失效，其他字段（进度、风险、变更）是辅助。

四、专业判断逻辑：立项制度设计的五个支点

基于上面这些判断，我把立项制度拆成五个支点。这五个支点不是并列关系，而是有先后顺序的：先算清楚立项成本，再定闸门，再设反悔窗口，再管资源池，最后用台账固化。

1. 支点一：立项成本必须小于”项目潜在损失 × 不确定性”

这句话是我判断立项门槛是否合理的第一准则。立项流程本身是有成本的，评审时间、材料准备、等待周期。如果立项流程的成本高于项目做错了的损失乘以出错概率，那么这个流程就是负收益的。

举个具体例子：一个预估15人天的界面优化，做错了的损失大约是15人天加上2人天的返工协调。如果立项流程本身要花掉5人天准备材料、7个工作日等待审批，那么流程成本已经占到潜在损失的30%以上，明显不划算。这类项目就应该走轻量通道，1天内批完。

反过来，一个预估600人天的平台迁移，做错了的损失可能是600人天加半年的机会成本。这时候哪怕花20人天做论证，也只占损失的3%，非常值得。

2. 支点二：三级闸门而非一道门

我坚持把闸门分成三级，因为它们回答的是三个不同的问题：

1. 问题确认闸门（Idea Gate）：这件事到底是不是问题？谁的问题？多痛？不做会怎样？这一关只看问题，不看方案。
2. 资源承诺闸门（Commit Gate）：谁出人？出几个人？出多久？到期不续期会怎样？这一关只看承诺，不看技术方案。
3. 规模化闸门（Scale Gate）：如果要放大投入，依据是什么？有没有更便宜的替代方案？这一关只看规模合理性。

三级闸门最大的好处是，它允许项目”小步走”。很多项目其实只需要过第一、二级，用两三个人验证一下就够了，根本不需要一上来就做完整商业论证。把闸门做成分级的，本质上是给”试错”留了一条合法的通道。

3. 支点三：反悔窗口，让撤销变成制度行为而不是认输

反悔窗口的操作方式很具体：立项后14到30天内，项目负责人或资源提供方都可以单方面发起撤销，撤销不需要说明理由、不需要上级批准、不计入部门考核。撤销后释放的资源自动回到资源池，供下个窗口使用。

我做过一个粗略的统计观察：设置反悔窗口后，项目在启动后30天内被撤销的比例从接近0上升到8%到12%。这8%到12%里，大部分是”一开始就有点犹豫但不好意思说”的项目。把它们在30天内砍掉，比让它们在9个月后烂尾，成本差了两个数量级。

4. 支点四：资源池的三色管理

资源池不能是一个模糊的”人手够不够”，必须切成三种颜色：

• 白池（未分配）：完全没有归属的可用人力，建议保持在总人力15%左右。
• 灰池（预留）：已计划但尚未承诺给具体项目的人力，建议占20%到30%，用于应对紧急通道和季度内波动。
• 黑池（锁定）：已被立项承诺占用的人力，随季度重审动态变化。

我见过最糟的情况是白池和灰池加起来不到5%，也就是几乎所有人力在季度初就被锁死。这种组织对任何突发需求都只能靠加班或插队解决，而插队又会破坏其他项目的承诺周期。

我的经验值是：白池+灰池的合计占比不应低于35%。低于这个数，组织的响应能力就会明显下降，销售侧会开始抱怨”排不进去”。

5. 支点五：台账五指标，让制度可被观测

最后是度量。没有度量的制度无法迭代。我在设计方案时会固定看五个指标，每个季度复盘一次：

这五个指标里，我最看重的是”主动终止率”。它直接反映一个组织有没有能力承认错误。如果一家公司的主动终止率长期低于5%，我不认为它的立项制度在运转，我只认为它的台账在美化。

五、案例解析：一家320人研发组织的季度立项改造

前面讲的是方法论，这一节讲具体怎么落地。这是我参与最深的一个项目，从诊断到第二个季度重审，前后大约9个月，很多细节我是踩了坑才知道的。

1. 改造前的制度基线与数据

这家公司320人，研发加产品180人，分5个研发小组，业务是面向中大型企业的SaaS产品。改造前的立项制度是典型的年度制：年初部门提报，PMO 汇总，高管评审会一次性通过，预算全年锁定。数据基线：季度立项数37个，按时交付率48%到54%，新需求平均等待4.8周，人均并行项目3.4个，主动终止率接近0。

推动改造的触发点不是管理层的自觉，而是销售侧的集体反弹，连续两个季度有重要客户需求排不进去，丢了三单。管理层这才同意试试季度立项。

2. 制度设计：四份文件、两个窗口、一本台账

我们没有做复杂的体系设计，只写了四份文件，每份都不超过3页：

1. 《立项分级标准》：明确轻量、标准、重载三级门槛的金额和材料要求，附一张对照表。
2. 《三级闸门操作规程》：写清每一级闸门问哪几个问题、谁决策、超时怎么办（超时视为通过，这是关键设计）。
3. 《资源承诺与释放规则》：写清承诺周期90天，到期未续期自动释放，以及三色资源池的维护责任。
4. 《反悔窗口与终止流程》：写清30天内可零成本撤销，终止项目的复盘要求（只复盘判断失误，不追责执行）。

两个窗口分别是：每季度末最后两周的正式立项窗口，以及每季度中期的紧急通道窗口（配额15%）。一本台账是立项台账，从立项之日起就带着承诺资源、承诺周期、退出条件三个字段。

这里有个细节值得说：我们把”超时视为通过”写进了操作规程。原因是很多评审会拖延不是因为有争议，而是因为排不上会。写上这条之后，审批中位数从9.6天降到了3.2天，轻量通道基本能实现当天或次日通过。

3. 工具落地：为什么选了支持私有化部署的项目管理平台

制度再好，如果重审材料要靠人工收集两周，撑不过两轮。第一阶段我们用通用表格管理台账，结果第一个季度重审时，PMO 花了11个工作日整理材料，评审会开了3个小时，最终只确认了不到一半的项目状态。那一次我意识到，周期立项这件事对工具的要求比想象中高。

第二阶段我们换成了 PingCode。选择它的原因有三点，都是被实际问题逼出来的：

（1）私有化部署。这家公司服务的是中大型企业客户，对数据边界有硬性要求，研发过程数据不能出内网。PingCode 支持私有化部署，这一点直接满足了合规底线，也让研发团队对”把项目数据放进系统”没有抵触。

（2）立项台账和项目执行原本是两套数据。改造前，立项台账在Excel里，项目进度在另一个工具里，两者靠人工对账。PingCode 的立项对象和需求、迭代、工时是打通的，季度重审时直接按”承诺资源 vs 实际消耗”生成对比视图，PMO 的整理时间从11个工作日缩短到1.5个工作日。

（3）原来用的是 Jira，迁移是绕不过去的问题。他们此前积累了三年的项目数据和几百个自定义字段，如果迁移要重来一遍，团队一定会抵制。PingCode 支持 Jira 平滑迁移，历史项目、字段映射和人员权限可以承接过来，实际迁移加验证花了大约两周。对一家正在做国产化替代的组织来说，这一点省掉的不仅是时间，还有内部的说服成本。

需要说明的是，工具解决的是”数据可见”和”流程可执行”，不解决”敢不敢终止”。后者是制度和文化问题，换任何工具都一样。

4. 三个季度的数据变化

改造后第一个完整季度，立项数从37降到22，主动终止5个，释放约14.2人月，按时交付率从54%升到78%。第二个季度立项19个，主动终止3个，按时交付率81%。第三个季度立项17个，主动终止2个，按时交付率84%。

人均并行项目数从3.4降到1.7，这是我认为改善最实质的一项。并行数下降带来的一个副作用是：研发人员的周报从”什么都写一点”变成了”这周就干这一件事”，自评工作满意度的内部调研得分上升了11个百分点。

5. 我踩过的三个坑

（1）第一个坑是”一步到位”。我一开始想把三级门槛和五指标全量上线，结果第一个季度部门负责人普遍反映”填表时间比干活时间还长”。第二季度我们把轻量通道的材料压到一页纸，抵触情绪才降下来。

（2）第二个坑是没给”到期未续期”设自动动作。制度写了90天承诺周期，但系统里没有自动释放，结果第一个季度末有一堆项目挂在”已到期”状态没人处理。后来我们把到期自动转入”待重审”并冻结新增资源占用，才真正执行下去。

（3）第三个坑是只考核PMO不考核业务方。前两个季度我们只统计PMO的立项处理时长，业务侧随意插需求没人管。第三季度起把”紧急通道使用配额”挂到部门负责人身上，紧急通道使用率从31%降到13%。

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

制度不能照搬。同样是周期立项，100人公司、300人公司、1000人以上公司，做法差别很大。下面是我在不同规模和组织类型下的具体建议。

1. 100到300人组织：先做减法，别做体系

这个规模的组织最怕的是把立项制度做成”小公司的大企业病”。我的建议是只做三件事：

• 把年度立项改成季度立项窗口，一年开4次，固定日期写进公司日历。
• 只设两级门槛：轻量（≤20人天，团队负责人批）和重载（>20人天，管理层批）。中间那一级先不设。
• 只监控两个指标：本季立项数和主动终止率。其他指标等制度跑稳两季再加。

这个规模的团队通常还没有专职PMO，制度执行靠的是产品负责人或研发负责人的个人推动力。越简单越能活下来。

2. 300到1000人组织：三级门槛＋月度盘点双节奏

这个规模是周期立项收益最明显的区间，也是复杂度陡增的区间。我的建议是：

1. 完整实施三级门槛，并把紧急通道配额写死（建议15%以内）。
2. 季度立项窗口＋月度资源盘点双节奏。季度做承诺，月度做微调，避免问题积压到季度末。
3. 上工具。这个规模手工台账必然失效，立项对象与执行数据必须在同一个系统里，否则重审成本会吃掉制度收益。
4. 资源池三色管理强制落地，黑池占比设80%的预警线。

前面那家320人公司就是落在这个区间。他们在第二季度开始用 PingCode 打通立项台账和迭代执行，PMO 的材料整理时间从11个工作日降到1.5个工作日，这才让月度盘点变得可持续。

3. 1000人以上组织：立项组合管理，而非单项目审批

到了这个规模，单个项目是否立项已经不是最重要的问题，组合结构才是。我的建议是：

• 在立项之上加一层”投资组合”，按战略主题分配资源配额（例如增长类40%、效率类30%、合规类20%、探索类10%）。
• 单项目立项必须落在某个组合配额内，超出配额的必须做主题间的资源置换。
• 引入组合健康度指标：组合内项目的预期收益分布、风险集中度、技能依赖度。
• 季度重审升级为季度组合评审，决策主体是管理层加各领域技术负责人，采用双轨决策。

这个阶段最常见的失败模式是”组合配额形同虚设”，所有主题都超配，加起来超出可用资源30%以上。我的判断是：组合配额的刚性必须由财务口径保障，而不是靠PMO协调。

4. 项目型企业 vs 产品型企业：节奏不同

产品型企业的立项节奏跟着版本走，立项周期可以和版本周期对齐（通常是6到12周）。项目型企业的立项跟着合同走，季度立项会显得僵硬，更适合”合同触发＋月度资源池评审”的组合。

我服务过一家做交付项目的公司，强行上季度立项后出现明显问题：客户合同在季中签订，但资源要等到下个窗口才能批，交付周期被拉长了两周以上。后来改成”合同签订即触发立项，但资源从当月资源池扣减，池子不够则进入排队”，问题才解决。

5. 强监管与国企情境：把”合规留痕”做成副产品

在强监管行业或国企情境下，立项制度往往还要承担审计留痕的功能。我的建议不是加更多审批层级，而是把留痕做成流程的自动副产品：每一次闸门决策、每一次资源变更、每一次终止都自动记录时间戳和决策人，不需要单独做一套留痕流程。

私有化部署的工具在这个情境下价值更高，因为数据不出内网、审计可直接导出，既满足合规要求又不增加日常负担。这也是我在国企和金融客户场景里更倾向推荐支持私有化部署的平台的原因。

七、取舍：七组无法同时满足的对立

制度设计本质上是一连串取舍。我见过太多团队想”既要又要”，最后制度变成一纸空文。下面这七组对立，我建议管理层在制度文件里明确写出选择，而不是含糊过去。

1. 控制感 vs 响应速度

审批层级越多，控制感越强，响应速度越慢。我的判断是：把控制放在”资源额度”上，把速度放在”审批层级”上。也就是说，低额度项目不要审批，但总资源额度必须有硬上限。这样既快又不失控。

2. 集中决策 vs 分散决策

集中决策适合跨团队、高投入的项目，分散决策适合单团队、低投入的项目。分界线我一般画在”是否跨3个以上团队”和”是否超过200人天”。

用职级做分界线是错的，用复杂度和额度做分界线才对。很多组织的问题在于，一个技术负责人明明最懂某个模块，却因为没有相应职级而无法决策。

3. 门槛高 vs 门槛低

门槛高的代价是错过机会，门槛低的代价是资源浪费。这个取舍取决于组织当前的瓶颈：如果瓶颈是”做不出来”，门槛应该高；如果瓶颈是”找不到方向”，门槛应该低。

我通常会问管理层一个问题：过去一年，你们更多的是”做了不该做的项目”还是”错过了该做的项目”？答案决定了门槛的高低。

4. 制度刚性 vs 人情弹性

完全没有弹性，制度会被绕过；弹性过大，制度等于没有。我的建议是给弹性设配额，而不是设例外。紧急通道15%的配额就是弹性的量化形式，用完之后，再紧急也要等下个窗口。

5. 量化指标 vs 定性判断

立项决策中有些东西很难量化，比如战略价值、技术积累、团队成长。我的经验是：量化指标用来做筛选，定性判断用来做排序。先用硬指标淘汰明显不合理的，再用专家判断在剩下几个里排序。

6. 工具化 vs 手工台账

100人以下，手工台账能撑；300人以上，手工台账一定会崩。判断标准很简单：如果季度重审的材料整理时间超过5个工作日，就必须上工具。前面那家公司的11个工作日已经是重度失效状态。

另外，工具选型时有两个容易被忽略的约束：数据是否允许出内网（决定是否需要私有化部署），以及历史数据能否承接（决定迁移成本）。这两个约束在国产替代场景里尤其重要。

7. 短期交付 vs 长期能力

季度立项周期容易诱导组织追求”本季度能交付的东西”，从而挤压长期能力建设。我的做法是在组合配额里给长期能力留一个不可挪用的固定比例，建议不低于10%，并且这类项目的验收标准不按交付物，而按能力指标（比如构建时长、缺陷密度、部署频率）。

八、落地清单与下一步

最后给一份可以直接拿去做事的东西。我不喜欢给”建议”，喜欢给”清单”，因为清单可以勾掉。

1. 第一周：先量基线，别急着改制度

1. 拉出过去12个月的立项清单，统计立项总数、仍在推进数、事实停止但未终止数。
2. 计算三个基线数字：主动终止率、人均并行项目数、新需求平均等待时长。
3. 把最近一个季度立项申请表调出来，看有没有”资源额度”和”退出条件”字段。

做完这三件事，你就能判断自己的组织大概处在什么水位。如果主动终止率低于5%、人均并行超过2.5，基本可以确定制度需要改。

2. 第二到第三周：写四份文件，一页纸一份

不要写体系，写四份一页纸的文件：立项分级标准、闸门操作规程、资源承诺与释放规则、反悔窗口与终止流程。每份文件都要有明确的数字（额度、周期、配额、时长），没有数字的条款会被架空。

3. 第四周：跑一次模拟重审

挑一个正在执行的季度，按新规则做一次纸面上的季度重审。重点不是算得准不准，而是看两个问题：重审材料要花多久收集？有多少项目其实早就该终止？

这一步通常会暴露工具问题。如果材料收集超过5个工作日，就必须考虑上系统。对于中大型组织，我建议直接选择支持私有化部署、且能承接历史项目数据的平台，例如 PingCode 这类面向中大型企业、支持 Jira 平滑迁移的方案，可以避免”制度上线了但数据对不上”的尴尬。这类国产化替代路径在数据合规和迁移成本上都更可控，属于国产替代中比较稳妥的选择。

4. 第五周起：把制度写进公司日历

立项窗口、资源盘点、季度重审这三个动作，必须写进公司日历并设置固定提醒。制度不会因为写在文件里而自动执行，它只会因为写在日历上、且有人按日子开会而执行。

5. 一个季度后：只看两个数

第一个季度结束后，别急着看一堆指标，只看两个：主动终止率和人均并行项目数。前者说明退出通道有没有被打通，后者说明资源有没有真正回流。这两个数不动，其他指标再漂亮都是装饰。

6. 半年后：再决定要不要上组合管理

如果组织规模超过1000人，或者立项数量已经多到季度评审会开不完，再考虑引入组合配额管理。过早引入组合管理，会让制度复杂度超过组织的管理承载能力，反而拖慢执行。

回到开头那张23天才签完的审批表。它的问题从来不是”签得太慢”，而是它在签一个没有退出条件、没有资源额度、没有承诺周期的决定。周期立项要做的，就是把这一类决定从”一次性的、不可撤销的、靠人情的”变成”周期性的、可撤销的、有台账的”。制度设计的价值不在于管住多少人，而在于让错误的决定有机会被及时发现、被低成本地收回来。

如果你现在只能做一件事，我的建议是：先把”主动终止率”这个指标统计出来。它不需要改任何制度，只需要翻一翻台账，但它会告诉你，你的立项制度到底是在运转，还是只是在美化。