周期落地方案：管理层开展项目立项的最佳实践案例解析

2023 年第一季度，我陪同一家 800 人规模的智能硬件企业做年度复盘。财务口径显示，上一年度一共批了 63 个立项，实际完成交付 21 个，交付率 33%。更刺眼的是，这 21 个已交付项目里有 9 个延期超过 60 天，还有 4 个在交付后被业务方判定为”做了也没用”。而审批材料最厚、评审会开得最多的三个项目，全部进了”僵尸项目”名单。

这件事让我彻底改变了对”立项”的理解。过去我也认为立项的本质是”把关”，是把不合格的想法拦在门外。但那一年我看到的问题恰恰相反：这家企业不是立项太松，而是立项太散、太频繁、太没有退出机制。管理层把精力花在”批不批”上，却没有花在”批多少、什么时候批、批完之后什么时候该停”上。

这篇文章我想把”周期落地方案”这件事讲透。所谓周期，不是指项目本身的开发周期，而是指管理层开展立项这件事本身应该有的节拍、闸门和回检周期。我会先给结论，再拆误区，然后用一套可复用的判断逻辑和一个真实案例把它落地，最后给出不同规模组织的行动建议和取舍清单。

一、先给结论：立项的真正产物不是”批准”，而是”可撤销的资源承诺”

如果你只从这篇文章带走一句话，我希望是这句：立项的产物不是一张批文，而是一份带撤回条件的资源承诺。批文是静态的，资源承诺是动态的；批文只需要签字，资源承诺需要写清楚”在什么条件下这笔投入会被收回”。

我见过太多组织的立项会开成了”答辩会”，汇报人努力证明这件事值得做，评审人努力找漏洞，最后以”先做起来看看”收场。这个收场方式听起来很务实，实际上是管理层放弃了最重要的权力：放弃了对止损点的定义权。

1. 立项周期落地的三个核心结论

结论一：立项必须是一个固定节拍，而不是随时开闸。随时可提、随时可批的组织，在制品数量会持续膨胀，管理层的注意力被稀释，真正重要的项目拿不到资源。

结论二：立项材料的深度应由”金额 × 不可逆程度”决定，而不是由汇报对象的级别决定。一个 30 万元、可随时叫停的营销实验，不应该和一个 3000 万元、需要定制产线的系统改造用同一套模板。

结论三：没有退出条件的立项，等于没有立项。凡是没有写清楚”什么信号出现就终止”的项目，最终都会以”沉没成本”的方式被无限续命。

2. 我判断一个立项机制是否健康的四个信号

在进入具体方法之前，先给四个可以快速自检的信号。这四个信号我在六家不同规模的组织里反复验证过，准确率相当高。

• 信号一：在制品（WIP）有明确上限，并且被真正遵守。如果管理层说不出”我们同时最多跑多少个项目”，这个机制一定是失灵的。
• 信号二：立项被拒是常态。如果连续两个季度的立项通过率超过 85%，说明评审会只是橡皮图章。
• 信号三：立项材料平均不超过 5 页。超过 10 页的材料，通常意味着团队在”写材料”上投入的精力超过了”想清楚”。
• 信号四：有 30/60/90 天回检记录。而且回检记录里出现过”终止”或”缩编”的决定。

这四个信号背后其实是同一个逻辑：立项机制的健康度，取决于它对”数量”的控制力，而不是对”质量”的审查力。大部分组织只做了后者。

3. 一页纸决策的边界在哪里

我推荐一页纸，但不是无脑推荐。一页纸的价值在于强制收敛逻辑，它的失效边界也很清楚：当项目的不可逆程度足够高时，一页纸就是自欺欺人。

举个例子。一个 50 万元的渠道试点，失败了大不了换渠道，一页纸完全够用。但如果是要把核心交易系统从自建机房迁到公有云，涉及数据合规、停机窗口、回滚方案，一页纸根本承载不了风险论证。这种情况下强行一页纸，只是把风险藏进了细节里。

我的经验阈值是：不可逆投入超过年度 IT 预算的 3%，或者回滚成本超过项目总投入的 40%，就必须上完整商业论证。这个比例不需要精确，重要的是管理层要有意识地去区分”可逆的小赌注”和”不可逆的大承诺”。

二、真实场景：我在三类组织里看到的立项周期差异

接下来讲三个真实场景。这三家组织的规模、行业完全不同，但它们在立项周期上的问题有惊人的共性，也有各自独特的约束条件。我先讲场景，再讲共性。

1. 制造型企业的”季度闸门”实践

第一家是前面提到的 800 人智能硬件企业。它的特点是硬件投入不可逆，开模、认证、产线调试，一旦启动就很难中途停下。但它的立项却是”随时可提、每周均可批”。

结果就是：Q1 批了 22 个项目，Q2 又批了 18 个，到 Q3 时研发资源被拉成了一张薄饼，每个项目都只推进 30% 左右。真正的瓶颈不是研发能力，而是在制品数量。

后来我们做的第一件事不是改流程，而是做了一次”资源盘点”：把所有在跑项目按人力投入排序，发现前 12 个项目占用了 78% 的研发人力，后 31 个项目加起来只占 22%。这 31 个项目里，有 14 个已经超过 6 个月没有实质性进展。

2. 金融科技公司的”月度小步”陷阱

第二家是一家 1500 人的金融科技公司。它们的立项做得比第一家规范得多：有标准模板、有评分卡、有评审委员会。但它们的节拍是月度的。

问题出在月度节拍与季度战略节奏的错配。战略方向是季度调整的，但立项是月度放闸的，于是每个月都会有”看起来合理、但和当季重点不一致”的项目被批进来。半年下来，立项清单和战略重点的重合度只有 40%。

这家公司的教训是：立项节拍必须与战略节奏同频，否则审批越规范，偏离越系统化。

3. 百人以上组织的”滚动立项”折中方案

第三家是一家 300 人的 B 轮 SaaS 公司。它采取了折中方案：固定的月度窗口 + 常态化绿色通道。月度窗口处理常规立项，绿色通道只对两类项目开放，合规要求驱动的项目，以及金额低于年度预算 0.3% 的小额实验。

这个方案的好处是兼顾了响应速度和数量控制。但需要一个前提条件：绿色通道的项目要纳入单独立账，每季度汇总复盘，否则绿色通道会变成第二个随时开闸的口子。

三、把立项做坏的六个常见误区

讲完场景，我把六年间观察到的误区集中列一遍。这六条有一个共同点：它们看起来都是”更严谨””更负责”的做法，实际上都在削弱立项机制的有效性。

1. 把立项等同于预算审批

这是最普遍的一条。很多组织把立项会议开成了预算分账会，讨论的焦点是”这笔钱从哪个科目出”，而不是”这件事该不该在现在做”。

预算审批回答的是”钱够不够”，立项评审回答的是”该不该做、什么时候做、和现有项目冲不冲突”。前者是财务问题，后者是资源配置问题，两者不能混为一谈。

我的建议是把这两个动作在时间上分开：先做资源与优先级评审，通过后再走预算流程。顺序颠倒，会导致大量项目”因为有钱所以做”。

2. 材料越厚越安全

我在第二家金融科技公司见过一份 86 页的立项材料，里面有 31 张图表、4 个版本的市场规模测算。但整份材料里没有一个字提到”如果前 3 个月用户留存低于 20% 就停”。

厚材料的真正问题不是浪费时间，而是它用”论证的充分性”替代了”决策的可证伪性”。一份好的立项材料应该让管理层能在 10 分钟内回答三个问题：要投入什么、什么时候能看到什么信号、什么情况下停。

3. 只定义成功，不定义退出

这是我认为最致命的一条。绝大多数立项模板里都有”预期收益””关键里程碑”，但很少有”退出条件”这一栏。

结果是，项目一旦启动，延期就被解释为”探索期正常波动”，超支被解释为”范围合理调整”，需求变更被解释为”业务在演进”。没有退出条件的项目，会用无数个合理的理由活到把预算烧完的那一天。

4. 立项节拍与战略节奏脱节

战略是季度调整的，立项是月度放闸的；或者战略是年度定的，立项是随时可提的。这种错配会系统性地制造”局部合理、整体偏离”的结果。

判断方法很简单：把过去四个季度的立项清单和当季战略重点做一次重合度分析。如果重合度低于 60%，问题大概率不在项目经理身上，而在节拍设计上。

5. 用一套模板打天下

合规型项目、增长型项目、平台型项目、救火型项目，这四类项目的决策逻辑完全不同，但很多组织用同一套评审表和同一个委员会。

合规型项目几乎没有”做不做”的问题，只有”怎么做最省”的问题；增长型项目的核心是不确定性管理；平台型项目要评估复用价值和长期成本；救火型项目的关键是止损边界。用同一把尺子量四种东西，一定会量错其中三种。

6. 用立项通过率考核团队

这一条比较隐蔽。有些组织会把”立项通过率”作为项目管理部门或业务部门的绩效指标，听起来是在控制质量，实际上是在制造共谋。

一旦通过率和考核挂钩，评审会就会倾向于”给个面子先过了”。我在一家企业见过连续 8 个季度通过率都在 90% 以上，而同期项目交付率只有 38%。高通过率和低交付率同时出现，几乎必然意味着立项在放水。

7. 六个误区的量化影响排序

我把六个误区按”导致返工的立项数量”和”平均延期天数”两个维度做了粗略量化。这不是严格的统计研究，而是我在四家组织里做的回溯性归因，样本是 236 个已结项项目。

这张表的读法是：“不定义退出”是延期的头号原因，”通过率考核”虽然不是直接延期原因，但它会影响所有项目的立项质量。两者配合使用，基本可以解释大部分立项治理失败。

四、我的专业判断逻辑：四象限分类、三档材料、五个阈值

前面讲的是问题，这一节讲我实际使用的判断工具。这套工具不是从某个框架书里抄来的，而是在反复踩坑后逐步收敛成型的。它由四个部分组成：分类、分层、阈值、回检。

1. 立项四象限：先分类，再决定管理强度

我把所有立项按两个维度切分：战略相关度（高/低）和资源可释放度（高/低）。资源可释放度指的是”如果这个项目上马，能不能从现有项目里腾出对应的人力”。

• 高战略 × 高可释放：立即启动。走快速通道，材料用一页纸，两周内完成立项。
• 高战略 × 低可释放：先做减法再立项。必须同步提交”从哪些现有项目释放资源”的方案，否则不予批准。
• 低战略 × 高可释放：窗口内排队。纳入季度闸门，按常规流程评审，优先级低于第一象限。
• 低战略 × 低可释放：默认拒绝。除非有明确的合规或客户承诺约束。

这个象限最反直觉的地方在第三象限。很多组织会优先批”不占资源的小项目”，认为成本低风险小，实际上这些小项目会持续消耗管理注意力，是组织熵增的主要来源。

2. 三档材料分层：按金额和不可逆程度选择

我用的分层标准是这样的。这不是行业标准，是我在多个组织里校准过的经验值，你可以按自己的预算规模等比调整。

需要强调的是，L2 材料”不设上限”不等于”越厚越好”。我通常要求 L2 材料的正文部分控制在 8 页以内，其余内容以附件形式提供。正文是给决策者看的，附件是给执行者查的，两者不该混在一起。

3. 五个决策阈值：把主观判断变成可校验规则

阈值的作用是把”我觉得这个项目不太行”变成”这个项目触发了第 3 条规则，建议退回”。这五个阈值是我用得最频繁的：

1. 并行上限阈值：任一资源池的并行项目数不超过其可用人力的 1/3。例如 30 人可用，最多同时跑 10 个项目。
2. 单人投入阈值：核心角色（架构师、产品负责人）在单个项目上的投入不低于 30% 工时，否则不予排期。
3. 回滚成本阈值：回滚成本超过项目总投入 40% 的项目，必须提交回滚方案和时机判断标准。
4. 信号明确阈值：必须写明”在项目启动后第几周、观察到什么指标、达到什么数值”作为继续或终止的判断依据。
5. 战略重合阈值：季度立项总量中，与当季战略重点直接相关的比例不低于 65%。

这五条里，我认为第二条最容易被忽略但影响最大。一个架构师同时出现在 7 个项目的排期表里，等于他实际上不在任何一个项目里。

4. 三个退出红灯：让止损成为可执行动作

退出条件不能写成”效果不达预期则终止”这种废话。我通常要求写明三个具体的红灯信号，任一触发即启动评估：

• 红灯一：里程碑延期超过 30%。不是”有延期”，而是延期幅度超过基线的三分之一。
• 红灯二：单位成本上升超过 25%。比如单用户获取成本从 80 元涨到 100 元以上，或单模块开发人天从 15 涨到 19。
• 红灯三：关键干系人变更。项目发起人或核心业务负责人变动，触发重新立项评估，而不是自动延续。

这里的关键设计是：红灯触发的是”评估”，不是”终止”。如果是自动终止，团队会想方设法隐藏信号；如果是触发评估，团队会更愿意如实上报。这是行为设计，不是流程设计。

5. 把准入规则写成可执行的校验逻辑

规则写在文档里没人会看，写在系统里才会被执行。我在做立项流程落地时，通常会把准入规则做成表单的自动校验逻辑。下面是示意代码，用 YAML 描述规则，由项目管理平台在提交时自动校验。

intake_gate:
window: "每季度第 12-14 周开放，绿色通道全年可用"

rules:

id: R1

name: 并行上限校验

condition: "resource_pool.concurrent_projects r.allocation >= 0.30)"

on_fail: "需提交角色替换或投入度调整方案"

id: R3

name: 退出条件完整性校验

condition: "exit_conditions.length >= 3 and all(exit_conditions, c -> c.metric and c.threshold and c.checkpoint_week)"

on_fail: "禁止提交，提示需补充具体指标、阈值与检查周次"

id: R4

name: 材料分层校验

condition: |

if budget baseline_unit_cost * 1.25"

name: 关键干系人变更

condition: "sponsor_changed or business_owner_changed"

这段配置最关键的部分不是校验规则，而是最后的 post_approval 段。大部分立项系统只做了”批”这一半，没做”批完之后怎么盯”那一半。30/60/90 天的自动回检提醒，是把立项机制从”一次性审批”变成”持续治理”的关键开关。

五、案例与数据观察：从 63 个立项到 26 个交付

这一节讲完整案例。为了保护商业信息，我隐去了企业名称和部分精确数字，但改动幅度和数据趋势是真实的。这是我做得最完整的一次立项治理，也是踩坑最多的一次。

1. 案例背景与基线数据

案例主体是一家 1500 人规模的制造企业，多业务线并行，IT 与研发合计约 420 人。治理前的状态是这样的：

• 全年立项 63 个，按期交付 21 个，交付率 33%
• 平均在制品数量 28 个，峰值出现在第三季度，达到 34 个
• 平均立项审批耗时 11 天，最长的走了两轮评审会，耗时 26 天
• 立项材料平均 24 页，最厚的一份 78 页
• 没有任何 30/60/90 天回检机制，项目一旦启动就进入”黑洞”

最有意思的发现来自一次访谈。我问一位业务负责人：”你知道你负责的 6 个项目里，有 2 个已经被判定为失去业务价值了吗？”他的回答是：”知道，但没人通知我停。”这句话基本概括了所有立项治理失败的根源，缺少终止机制，而不是缺少审批机制。

2. 我们实际做了什么

我们没有推翻原有流程，而是做了五个具体改动。这些改动的顺序很重要，顺序错了会引发强烈的组织阻力。

1. 先做资源盘点，再改流程。用三周时间把所有在跑项目的人力投入摸清楚，形成一份”资源占用热力图”，让管理层自己看到后 31 个项目只占 22% 人力。
2. 设定 WIP 上限为 12。不是慢慢降，而是一次性从 28 降到 12，通过”终止 8 个、冻结 6 个、合并 4 个”三种方式实现。
3. 立项节拍从每周改为季度窗口。每季度开放 2 周受理，其余时间只保留合规类和低金额绿色通道。
4. 材料分层并强制收敛。L0 一页纸、L1 五页、L2 正文八页加附件，模板中新增”退出条件”必填栏位。
5. 上线 30/60/90 天自动回检。回检结果分为继续、缩编、暂停、终止四类，必须由发起人签字确认。

第二步是最难的。终止项目意味着承认过去的决策有问题，很多管理者会本能抗拒。我的做法是把”终止”重新定义为”释放”，并且在汇报中强调这一年因此释放出的人力可以投入到哪些新方向上。框架的转换让阻力下降了很多。

3. 治理后的数据变化

第二年，这家企业的立项数据发生了明显变化：

最后两行我认为比交付率更有价值。一个立项机制成熟的标志，不是交付率多高，而是它能不能在项目失效前主动叫停。7 个主动终止的项目，按当时的排期估算，大约节省了 1400 人天。

4. 项目管理平台在其中的支撑作用

这套机制如果靠邮件和 Excel 落地，三个月内必然崩掉。这家企业最终选择了 PingCode 作为落地平台，我参与了选型和实施过程，有几个具体点值得展开。

第一是私有化部署能力。制造企业的项目数据涉及产线、供应链、成本结构，不能出内网。PingCode 支持私有化部署，这一点在选型阶段是硬性门槛，直接排除了大部分 SaaS 方案。

第二是Jira 平滑迁移。这家企业原来用 Jira 管理研发，约有 4000 多个历史工单、200 多个自定义字段、30 多个工作流。迁移动用了两周，历史数据、附件、评论都保留了下来，没有出现大面积的字段错乱。这一点对我判断一个国产替代方案是否可靠非常关键，迁移的平滑度比功能清单更能反映产品的工程成熟度。

第三是从立项到交付的链路打通。他们把立项表单、WIP 上限校验、30/60/90 天回检都配置在同一个平台里。立项通过后自动生成项目空间和里程碑，回检提醒由系统推送，不需要人工追踪。治理后第一年，90 天回检执行率是 100%，这个数字在纯人工模式下几乎不可能实现。

第四是面向中大型组织的资源视图。PingCode 主要服务中大型企业及 100 人以上组织，它的资源池和项目组合视图能直接呈现”某个人当前在几个项目里、投入度是多少”。前面提到的”单人投入阈值”规则，就是靠这个视图自动校验的。

不过我也要说清楚它的边界。PingCode 是一套管理载体，不是管理方案本身。如果 WIP 上限没定、退出条件没写、回检机制没设计，换任何平台都不会有改善。平台的价值在于让已经想清楚的规则变得不可绕过。

5. 一个失败的反例

同一时期，我还跟进过另一家 900 人企业的类似改造，结果失败了。失败的原因很有代表性：他们直接照搬了这套方案，但没有做第一步的资源盘点。

结果就是 WIP 上限设了 15，但没人知道当前实际在跑多少个项目，也没人知道哪 15 个应该保留。三个月后，在制品数量从 31 个降到 26 个，然后又反弹回 30 个。管理层认为”这套方法不适用”，项目就此中止。

这次的教训是：资源盘点不是可选的准备工作，它是整个方案的地基。没有基线数据，任何阈值都是拍脑袋，任何治理都会在第一次阻力面前瓦解。

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

方案不能照搬。这一节我按组织规模和行业特征给出差异化建议，你可以直接对号入座。每条建议我都标注了”最小可行动作”，也就是如果只做一件事，应该做哪件。

1. 200 人以下组织：先控数量，不控流程

这个规模的组织，流程负担往往比管理收益更大。我建议只做两件事：设定并行项目上限，以及给每个项目写一句退出条件。

具体做法是：把研发和产品人力加总，除以 3，得到并行项目上限。比如 24 人可用，上限就是 8 个项目。超过 8 个，必须先停一个才能开一个。

最小可行动作：在季度会议上公开当前在跑项目数量和上限，让数量控制变成公开信息。光是这一步，很多组织就能减少 20% 以上的无效项目。

2. 200-1000 人组织：建立季度闸门和材料分层

这个规模开始出现跨部门协调成本，需要正式的节拍和分层。我建议采用季度立项窗口 + 三档材料 + L0 绿色通道的组合。

关键细节是绿色通道必须有额度限制。我的经验值是绿色通道项目占用的人力不超过总可用人力的 15%，超出后自动转入下一个窗口期。没有额度限制的绿色通道，很快会变成主通道。

最小可行动作：把立项模板里的”预期收益”部分压缩一半，腾出来的位置加一栏”退出条件”。

3. 1000 人以上或多业务线组织：需要组合管理视图

到了这个规模，单项目管理已经不够，需要项目组合层面的资源视图。核心是回答三个问题：资源投在了哪些方向、哪些项目的战略相关性在下降、哪些方向存在重复投入。

我建议每季度做一次项目组合复盘，输出三个清单：继续投、缩编观察、退出。三个清单的比例在健康状态下大约是 6:3:1。如果”退出”清单连续两个季度为空，说明复盘的严格度不够。

在工具层面，这个规模的组织通常需要支持私有化部署、能承接 Jira 迁移、并且能提供资源池和项目组合视图的平台。PingCode 在这类场景中比较常见，主要原因是它的目标客户就是 100 人以上的中大型组织，在产品设计上更贴近多业务线并行管理的需求。

最小可行动作：先建资源池视图，把所有项目的角色投入度可视化。这一步做完，很多隐藏的资源冲突会自己浮出水面。

4. 强合规行业：把合规项目和业务项目分账

金融、医疗、能源等强合规行业有个特殊问题：合规类项目几乎不可否决，但它们会挤占业务项目的资源。我的建议是把两类项目分账管理，设定各自的资源配额。

比例上，我见过比较健康的配置是合规类占 25%-35%，业务类占 65%-75%。如果合规类长期超过 40%，说明组织的合规债务积累过多，需要专门立项清理历史欠账，而不是持续挤占业务资源。

最小可行动作：在立项清单里加一列”驱动类型”（合规驱动/战略驱动/业务驱动/技术债务），并按季度统计分布。这一列加出来之后，很多组织第一次看清了自己的资源到底投在了哪里。

七、不同情况下的取舍

前面给的是建议，这一节讲取舍。任何方案都有代价，我把四个最常见的选择摆出来，并说明我在什么情况下会选哪一边。

1. 速度与严谨：什么时候可以牺牲严谨换速度

这个取舍的判断标准是不可逆程度，不是金额。可逆的小项目可以快速决策、快速上马、快速叫停，用速度换学习效率；不可逆的大项目必须慢下来，把论证做透。

我见过的最糟糕的组合是：对小项目反复论证，对大项目快速拍板。这正好把严谨用错了地方。我的原则是”小赌要多、快、可弃；大赌要少、慢、慎始”。

2. 统一模板与分层模板：标准化带来的隐性成本

统一模板的好处是数据可比、审计方便、培训成本低。代价是小项目负担过重、大项目论证不足。

我的选择是分层，但保留统一的数据字段。也就是说，L0 和 L2 的篇幅差异极大，但收集的核心字段（预算、周期、发起人、退出条件、驱动类型）完全一致。这样既能减轻小项目负担，又能保持跨项目的可比性。

3. 集中立项与分散立项：控制力与响应速度的拉锯

集中立项让管理层掌握完整视图，但响应慢，业务方容易绕过流程搞”影子项目”。分散立项响应快，但资源重复投入和方向偏离会累积。

我的倾向是“决策集中、发起分散、执行分层”：立项决策权集中在固定窗口，发起权下放到各业务线，执行管理交给项目管理办公室。这样既保证方向一致，又不至于让业务方觉得被卡脖子。

需要注意的是”影子项目”现象。如果发现业务方在用 Excel 私下维护项目清单，说明正式流程的响应速度已经低于他们的容忍阈值，应该考虑增加绿色通道额度，而不是加强管控。

4. 自建工具与采购平台：什么情况下值得自建

我的经验是：只有当年均立项超过 300 个、且有极强的定制化需求时，才考虑自建。否则采购成熟平台的总成本更低。

算一笔账：一个能支撑立项、资源池、里程碑、回检的轻量系统，自建初期的开发投入大约 4-6 人月，后续每年维护 1.5-2 人月。三年总投入约 12-16 人月。而采购成熟平台，按 500 人规模估算，三年总成本大约相当于 3-5 人月。除非自建能带来不可替代的业务价值，否则这笔账很难算平。

还有一个容易被忽略的隐性成本：自建系统的迭代速度慢。当组织调整立项规则时，采购平台通常能通过配置完成，自建系统需要重新排期开发，这个延迟会直接影响治理效果。

5. 短期可见性与长期数据资产

最后的取舍是时间维度上的。压缩立项数量能在 1-2 个季度内看到交付率提升，这是短期可见性；但真正决定长期成败的，是积累起来的项目历史数据，哪些类型的项目容易延期、哪些角色的投入度经常被高估、哪些退出信号最有效。

我建议从第一天就结构化存储立项数据，哪怕前半年用不上。当积累到 200 个以上的项目样本时，你就能做自己的归因分析，而不是依赖外部经验值。

八、下一步怎么做：30 天可执行的落地清单

最后给一份可以照着做的清单。这 30 天的安排是我在最近三次实施中验证过的节奏，每周的动作量都控制在一个人可以独立完成的范围内。

1. 第一周：盘清家底

这一周只做一件事：列出所有当前在跑的项目，逐个标注人力投入、启动时间、最近一次实质进展时间、业务负责人。

产出物是一张表。这张表不需要精确到人天，粗颗粒度也可以，但必须覆盖全部项目。如果这一周结束后你发现实际在跑项目数量比你以为的多 30% 以上，那就说明问题比想象中更严重。

2. 第二周：定阈值和分类

基于第一周的数据，计算并行上限（可用人力 ÷ 3），确定材料分层的金额门槛（按年度 IT 预算的 0.5% 和 3%），并把所有项目按四象限分类。

产出物是三份清单：立即保留、观察、建议退出。建议退出的清单不要急着执行，先做一轮沟通，看看有没有信息遗漏。

3. 第三周：改模板、上工具

把立项模板里的”退出条件”设为必填，把材料按 L0/L1/L2 分成三个版本。同时在项目管理平台里配置准入校验规则，至少实现”退出条件不填则无法提交”这一条。

如果组织已经在用 PingCode 这类支持私有化部署和 Jira 迁移的平台，这一周的配置工作量通常在两到三天内可以完成；如果还在用邮件加 Excel，建议同步启动工具评估，因为纯人工模式下这套规则很难长期维持。

4. 第四周：跑通第一个窗口期

用新规则跑一次完整的立项窗口。重点不是批了多少项目，而是观察三个现象：有多少申请因为退出条件不完整被退回、评审会时长有没有变化、WIP 上限有没有被突破。

跑完之后做一次小复盘，把不合理的阈值调一调。第一版阈值一定有偏差，重要的是建立”每季度校准一次”的习惯，而不是一次就定到最优点。

5. 三件长期要坚持的事

• 每季度做一次战略重合度分析。低于 65% 就要调整立项筛选权重，而不是批评执行团队。
• 每季度统计主动终止的项目数量。长期为零，说明回检机制名存实亡。
• 每半年回顾一次阈值。组织规模、预算水平、业务节奏都会变，阈值不能一成不变。

回到开头那家 800 人企业。63 个立项变成 26 个交付，看起来是减法，实际上是加法，加上了退出机制，加上了节拍，加上了对资源的真实认知。管理层在立项这件事上最该做的，不是判断”这件事值不值得做”，而是设计”什么情况下我们允许自己停下来”。能停下来，才敢往前冲。

如果你现在就想动手，我的建议是从第一周的那张表开始。不要先改流程，不要先买工具，先搞清楚你手上到底有多少个项目在跑。这一张表，往往比任何方法论都更有说服力。