立项流程与规范：PMO项目立项最佳实践关键指标

去年我帮一家 420 人的 To B 软件公司做研发管理诊断，翻完他们一整年的立项档案后，我看到两个几乎不可能同时出现的数字：全年立项 137 个，立项评审一次通过率 91%，但当年按承诺范围和时间交付的项目只有 39 个。换句话说，立项这道关口对 91% 的申请说了”可以”，而最后真正兑现的不到三成。更扎心的是，那 137 个项目里有 23 个在启动后 60 天内被悄悄搁置，没有正式的终止记录，资源就这么一点点耗掉了。

这不是某一家公司的特殊病。过去三年我参与过二十多家中大型企业的研发管理诊断和 PMO 体系搭建，发现一个高度一致的规律：决定项目组合成败的，往往不是执行阶段的敏捷程度，而是立项阶段那两三个小时的决策质量。而绝大多数 PMO 把立项做成了”填表，盖章，归档”的行政流程，而不是一次真正的投资决策。

这篇文章我想把立项流程与规范这件事讲透，包括我实际用过的分级模型、四组十六个关键指标、真实改造数据和取舍判断。如果你正在搭 PMO，或者正被”立项流程太重业务抱怨、太轻又控不住”困住，下面的内容应该能直接拿去用。

一、先给结论：立项是投资决策关口，不是行政流程

我把话说得直白一点：立项的本质是一次有限信息下的投资决策，投出去的是人、时间和机会成本，收回来的应该是可验证的业务结果。如果你把它当成流程合规动作，那它必然会退化成材料审查；如果你把它当成投资决策，那它就必须回答几个非常硬的问题，并且允许说”不”。

1. 立项质量决定的是项目组合的天花板，而不是单个项目的成败

很多团队把立项理解为”这个项目能不能做”的技术判断，这个理解太窄了。真正在立项关口要做的判断是：在当前的资源约束下，这个项目和手上其他二十个项目相比，值不值得排在前五。

我做过一个粗略的复盘：在年立项数量 100 个以上的组织里，最终创造主要业务价值的那部分项目，通常只占立项总数的 15%，25%。也就是说，立项关口真正的工作量不在于”筛掉不行的”，而在于”把有限的资源集中到少数几个真正重要的项目上”。筛掉明显不靠谱的项目，难度其实很低；难的是承认手上有一堆”看起来还行”的项目，必须排个先后。

2. 三个必须回答的问题，答不上任何一个就不该放行

不管你的立项模板长什么样，我认为必须强制回答的只有三个问题，我把它叫做”立项三问”：

1. 值不值得做：这个项目解决什么问题，怎么衡量解决了？如果拿不出一个可以观测的指标基线（哪怕是”客服工单量从日均 380 降到 200 以下”），说明需求还没想清楚。
2. 能不能做：技术路径、依赖系统、合规边界、关键人才是否具备？特别要问一句”我们做过类似的吗”，没做过的必须提高风险等级。
3. 谁来做、什么时候停：资源从哪个团队出、出多少人天、占用多久，以及什么条件下必须终止。没有终止条件的立项，等于给了一张空白支票。

这三个问题看起来简单，但在真实评审里，第三问的”终止条件”是缺失率最高的，我统计过的样本里超过 70% 的立项书没有写明确的熔断条件。

3. 一票否决比加分项更有价值

我见过太多评分表：技术创新性 10 分、业务价值 20 分、实施难度 15 分……最后加总排序。这种打分表的问题在于，它允许”用高分项弥补致命缺陷”。一个项目业务价值拿满分，但核心依赖的第三方接口没有商务协议保障，加总之后依然是高分。

我的做法是把评分表拆成”一票否决项 + 排序项”两部分。一票否决项是布尔判断：有没有明确的目标指标、有没有资源承诺人签字、有没有识别出前三风险及应对、有没有终止条件。这四项任何一项为否，直接退回，不进排序。剩下的项目再用轻量的加权评分排序，决定优先级和排期。

二、真实场景：我见过的三种立项现场

抽象讲流程容易纸上谈兵，我讲三个我亲身参与过的现场，它们几乎覆盖了大多数 PMO 会遇到的困境。

1. 结账式立项：三小时审完十四个项目，通过率 98%

某消费电子企业的月度立项会，下午两点开始，六个评委，十四个项目。每个项目汇报八分钟，提问两分钟，中间还要换投屏、找文件。到第五个项目的时候，有评委开始回微信；到第九个，讨论已经变成”这个看着还行，下一个”。最终 14 个项目通过了 13 个，唯一被退回的那个，是因为汇报人当天请假没来。

会后我问其中一位评委：”您觉得刚才那 13 个都有必要做吗？”他愣了一下说：”其实至少有一半可以往后放，但没人愿意当那个说’不’的人，因为说了就得给理由，给理由就得罪人。”

这是我见过最普遍的立项失效模式：不是流程缺失，而是评审缺少说”不”的机制和动力。评委没有决策授权，只有”提意见”的角色，那结果必然是全部通过。

2. 作文式立项：PPT 美化度影响通过率

另一家金融科技公司，立项材料是一份 40 页的 PPT。我做过一次实验性统计：把同一份立项内容做两版材料，一版是规范的表格化文档，一版是精心设计的视觉化 PPT，分别投给两组背景相近的评委。结果 PPT 版的平均评分高出 17%，通过速度快了 2.3 天。

这不是偶然。当评审标准模糊时，评委只能依赖表达质量做判断，于是立项就变成了”作文比赛”。真正该被淘汰的是那种”内容其实很薄，但因为材料漂亮而通过”的项目，它们往往在执行阶段暴露出需求空洞、范围失控的问题。

3. 甩锅式立项：审批全票通过，资源一个没到

最典型的一次，某企业一个数据中台项目，立项书上写着”研发投入 6 人 × 3 个月”，评审会上一路绿灯。项目启动会后两周，我跟着项目经理去问资源，研发负责人的回答是：”我们排期早就排满了，当时签字是支持这个方向，没说具体出人。”

这是立项流程里最隐蔽的漏洞：审批签的是”方向”，不是”承诺”。方向认同的成本是零，资源承诺的成本是真金白银。如果立项书上的资源栏没有具体到人和时间窗口，并且由资源归属方负责人书面确认，那这个立项在资源层面就是一张空头支票。

三、常见误区拆解：为什么你的立项流程越做越重却越控不住

我在梳理立项体系时，会先做一次”误区体检”。以下六个误区，出现频率从高到低排列，前三个几乎每家企业都有。

1. 所有项目用一套流程，不分级

一个 20 人天的界面改版和一个 8000 人天的平台重构，走同一套评审流程、同一份模板、同一批评委。结果是：小项目被流程拖死，业务开始绕过流程偷偷做；大项目反而因为评审资源被小项目稀释，没有得到足够的审视。

流程设计的第一个原则是：流程成本必须与决策风险成正比。一个 20 人天的项目，评审成本一旦超过项目本身的 5%，流程就不可持续了。

2. 用”立项数量”考核 PMO 或业务部门

这个误区杀伤力极大。一旦立项数量成为 KPI，业务部门就有动力把一个项目拆成三个立项，PMO 也有动力多批少拒。我见过一家公司，某季度立项数量同比翻倍，看起来欣欣向荣，实际上总资源占用只增加了 12%，多出来的立项全是”拆分出来的小项目”。

真正应该考核的是立项项目的交付兑现率和资源利用效率，而不是立项数量。前者会促使 PMO 谨慎放行，后者只会促使它放水。

3. 只有入口没有出口，缺少熔断机制

立项流程通常写得很细，却很少写”什么情况下必须终止”。结果就是一个已经明显走不通的项目，靠”再给它一点时间”续命半年。我统计过一家企业的项目池，有 19% 的活跃项目在过去三个月内没有任何实质产出，但依然占用着正式排期。

熔断机制不需要复杂。在立项书里写清三到五条终止条件即可，比如”连续两个迭代未完成计划目标的 60%””关键依赖方在 30 天内未提供接口文档””预算消耗超过 70% 但未进入联调”。到了条件触发，由 PMO 强制发起一次复盘，而不是等项目经理主动汇报。

4. 用定性描述替代量化基线

“提升客户满意度””优化运营效率””增强系统稳定性”，这些表述在立项书里出现频率极高，但它们无法验证。落地做法是强制要求：凡是写进立项书的目标，必须包含”指标名 + 当前基线 + 目标值 + 观测方式”四要素。拿不到基线的，宁可写”本阶段目标是完成基线采集”，也不要写一个拍脑袋的数字。

5. 立项材料和结项材料不对应

我经常做的检查是：把某个项目的立项书和结项报告放在一起看，两者提到的衡量指标是否一致。结果令人失望，超过一半的项目，结项时汇报的指标和立项时承诺的指标根本不是同一套。立项说”降低人工处理时长”，结项说”完成了 12 个功能模块”。这就是典型的立项与验收脱钩，它会让立项承诺失去约束力。

6. 把需求评审、方案评审和立项评审混在一起

这三件事的决策问题完全不同：需求评审回答”要解决什么问题”，方案评审回答”用哪种方式解决”，立项评审回答”值不值得投入资源、什么时候做”。混在一起的结果是，评审会上大量时间花在讨论技术选型细节，而真正的投资判断反而没人做。

四、立项规范的专业设计逻辑：分级、分门、分权、分母

讲完误区，进入我认为最关键的部分，立项规范到底该怎么设计。我的方法论可以概括成八个字：分级、分门、分权、分母。这四个维度决定了流程的骨架，其余的模板细节都是在这个骨架上填肉。

1. 分级：按资源量级和风险等级分三类

分级不是按部门分，也不是按业务线分，而是按”投入量级 + 不确定性”这两个维度分。我用的是下面这套简化模型：

这里有一个容易被忽略的设计要点：分级阈值必须用累计口径，而不是单期口径。因为拆分立项是极常见的规避手段。如果发现某个团队连续三个月出现大量接近阈值下沿的 C 类项目，PMO 应该触发一次合并审查。

2. 分门：把立项拆成四个决策门，而不是一个签字动作

我通常把从想法到启动的路径拆成四个门，每个门只回答一个问题，只做一次决策：

1. G0 需求受理门：判断”这个问题是否真实存在、是否值得排入待评估队列”。这个门成本极低，用一张在线表单提交，PMO 每周批量筛查一次即可。
2. G1 立项决策门：判断”值不值得投入资源、什么时候做、优先级排第几”。这是唯一需要正式评审的门，也是本文讨论的核心。
3. G2 方案确认门：判断”技术路径是否可行、依赖是否可控”。这个环节由技术负责人主导，PMO 只需确认其结论已回写到立项书。
4. G3 启动就绪门：判断”人、环境、依赖是否真的到位”。这个门的通过标志不是签字，而是资源负责人确认排期、关键依赖方给出时间承诺。

把立项拆成四个门之后，最明显的变化是评审会上不再讨论技术细节了，那些内容被挪到了 G2。G1 的会议时间可以压缩 40% 以上，而决策质量反而提高，因为讨论焦点集中了。

3. 分权：谁评审、谁签字、谁承担后果

立项评审最常见的组织问题，是”评审的人不担责，担责的人不评审”。解决方案是把决策权和资源支配权绑定：A 类项目由掌握跨部门资源调配权的人拍板，B 类由部门负责人拍板，C 类由团队负责人拍板。PMO 的角色不是决策者，而是流程设计者、数据提供者和一致性守门人。

我强烈建议在立项书上设置”资源承诺人签字”这一栏，而且必须是具体的资源归属方负责人，不能由项目发起人代签。这一个动作就能消掉前面提到的”甩锅式立项”。

4. 分母：材料清单随等级变化，而不是一刀切

立项材料应该有几份、多长，取决于等级。我用的做法是：

• C 类：一页立项卡。只填六个字段，问题描述、预期指标变化、投入估算、负责人、终止条件、验收人。
• B 类：立项卡 + 一页资源与依赖清单。补充依赖系统、关键人员、里程碑。
• A 类：立项卡 + 商业论证 + 风险与依赖分析 + 资源承诺书。商业论证不超过 5 页，超过 5 页通常意味着信息冗余而非信息充分。

下面是一个 C 类立项卡的实际结构，我用 YAML 形式展示，方便直接映射到在线表单字段：

project_card:
title: "客服工单智能分类"

level: "C"

problem: "人工分类平均耗时 4.2 分钟/单，日均 380 单"

target_metric:

name: "工单平均处理时长"

baseline: "4.2 分钟"

target: "1.5 分钟以内"

measurement: "客服系统周报，连续 4 周达标"

effort_estimate:

total_person_days: 68

breakdown: {研发: 45, 测试: 12, 产品: 11}

owner: "客服技术组 – 张工"

resource_commitment: "客服技术组 Q3 排期已预留"

top_risks:

"训练样本不足，需业务侧标注 2000 条历史工单"

"与现有工单系统接口版本不兼容"

kill_criteria:

"标注样本在 2 周内未到位"

"连续两个迭代完成度低于计划的 60%"

acceptance_owner: "客服中心 – 李经理"

这份卡片的字段数量控制在 11 个以内，一个熟悉业务的人 30 分钟内可以填完。立项模板的设计标准不是”信息完备”，而是”填写成本足够低、关键信息足够硬”。凡是填起来费劲又不影响决策的字段，都应该删掉。

五、关键指标体系：我实际使用的四组十六个指标

讲指标之前先说一个判断：立项指标不要超过 16 个，且必须分成”效率、质量、结果、价值”四组。只盯效率会让流程变得敷衍，只盯结果会滞后到没法干预，只盯价值则容易陷入无法测量的争论。

下面这张表是我在多个项目中反复使用并调优过的指标集。目标值一列是给中大型组织（300 人以上、年立项 80 个以上）的参考基准，规模更小的组织应适度放宽。

1. 为什么我坚持保留”熔断及时率”这个指标

很多人觉得熔断属于执行管理，不该放在立项指标里。我的看法相反：熔断及时率恰恰是立项质量的镜像指标。一个组织如果熔断及时率长期低于 50%，说明立项时的目标设定和终止条件形同虚设，立项关口事实上已经不承担把关功能了。

这个指标还有个额外作用：它把”终止项目”从一件需要勇气的事，变成一件流程内正常的事。当终止成为可被统计的常规动作，项目经理主动上报风险的意愿会明显上升。

2. 指标看板要按”四象限”呈现，而不是一列数字

十六个指标铺在一个页面上，没人看得懂。我通常把它们压缩成四个象限的看板：横轴是”决策价值确定性”（目标指标是否清晰、基线是否可测），纵轴是”资源占用强度”（人天规模、跨部门数量）。每个在跑的项目是图上的一个点，四个象限分别对应不同的管理动作。

这个视图最有用的地方在于，它能让管理者一眼看出”高资源占用 + 低确定性”那一象限里堆了多少项目。在我的经验里，这一象限的项目通常是资源黑洞的主要来源，往往占总立项数的 20% 左右，却消耗 40% 以上的调整成本。

3. 指标权重必须随组织阶段变化

我经常被问：”这十六个指标哪个最重要？”这个问题没有统一答案，因为组织在不同阶段的瓶颈完全不同。初创期和快速扩张期，效率指标的权重应该更高；进入规模化阶段后，质量与结果指标的权重必须提上来；等到多业务线并行，价值指标才真正成为讨论焦点。

六、真实案例：一家 420 人 To B 软件公司的立项改造

前面提到的数字都来自真实诊断，这一节我把其中一家公司的完整改造过程讲清楚，包括他们踩过的坑和最后的实际数据。这家公司做企业级软件，420 人，研发约 260 人，年立项 130 个左右，是我参与最深的一个项目。

1. 改造前的状态：立项流程完整，但没有决策力

他们的立项流程文档有 23 页，包含 4 个审批节点、7 个签字栏、一份 18 页的立项报告模板。看起来很规范，但实际运行数据是这样的：

• 立项平均周期 11.1 个自然日，其中真正用于决策的时间不足 15%
• 立项评审一次通过率 88%，退回的 12% 基本都是材料格式问题
• 立项后 90 天内发生范围变更的项目占比 34%
• 全年立项 137 个，按期交付 39 个
• 有 19% 的活跃项目在过去三个月内无实质产出

我印象最深的一次访谈，一个部门负责人说：”立项报告我都是让下面的人写，我自己只看最后一页的投入和工期。反正最后都要批，何必花时间。”这句话基本概括了问题的根源：审批链上没有人真正在做投资判断，每个人都在完成一个动作。

2. 改造动作：砍掉 80% 的模板，把决策集中到一张卡上

我们没有从零设计新流程，而是做了四件事，全部围绕”降低无效成本、提高决策密度”：

1. 把 18 页立项报告压成一页立项卡，字段从 42 个删到 11 个。删掉的是”项目背景综述””行业趋势分析””技术架构概览”这类不影响决策的内容。第一次推行时遭到强烈反对，产品负责人说”这样写不够专业”，但两周后没人再提了，因为填写时间从平均 3.2 天降到 40 分钟。
2. 按投入量级分三级，C 类项目改备案制。100 人天以下的项目不再上评审会，由团队负责人审批后自动进入 PMO 台账。这一个动作把评审会的工作量减少了约 60%。
3. 新增”资源承诺人签字”和”终止条件”两个必填字段。这两个字段是硬性的，系统层面设了校验，不填无法提交。资源承诺人必须是具体的人，不能填部门名。
4. 用在线流程工具承载全流程，让立项数据自动沉淀。他们选择了 PingCode 作为研发管理平台来承载立项流程和后续的项目执行。选择它的核心原因是三个：一是支持私有化部署，这家公司的客户里有相当比例的政企客户，数据和交付环境必须在自有服务器内；二是从原有的 Jira 做平滑迁移，历史项目的字段和流程状态可以映射过去，不用手工重建台账；三是他们明确要做国产替代，需要一套在国内长期可维护、能配合等保要求的方案。PingCode 主要服务中大型企业及 100 人以上组织，这一点和他们的规模也匹配。

关于第 4 点我想多说一句。很多团队在立项改造时把注意力全放在流程设计上，忽略了承载工具。但立项数据的价值在于可追溯和可对比：如果立项卡在邮件和 Excel 里流转，你想统计”立项后 90 天范围变更率”这个指标，就得靠人工翻记录，一个月能出一份报表就算高效了。放到在线平台上之后，这个指标是自动计算的，每周一上班就能看到。

3. 改造后的实际数据

改造推行了 5 个月（含 1 个月的过渡期），第 6 个月开始采集稳定期数据，与改造前 12 个月做对比。下面是几个我最关注的指标变化：

这里有一个数字值得单独解释：立项材料一次通过率从 88% 降到 64%，这不是退步，而是进步。改造前的高通过率是因为评审只看格式，格式对了就过；改造后评审真的会问”你的目标基线从哪来””资源承诺人是谁”，不达标就退回补充。通过率下降恰恰说明关口开始起作用了。

4. 改造过程中踩的两个坑

我不想把过程说得太顺，实际推进中有两个明显的失误。

第一个是把 C 类阈值一开始设在了 50 人天，结果大量 60，90 人天的项目仍然要走评审会，业务抱怨”改了半天还是慢”。后来把阈值调到 100 人天，同时增加”同一团队季度内 C 类项目累计不得超过 200 人天”的约束，才既提速又防止了拆包。

第二个是熔断机制刚上线时，连续触发了几次终止，导致两个团队士气受挫。后来我们调整了做法：终止不等于项目失败，终止的复盘结论要归入团队的知识库，并且不纳入个人绩效的负面评价。当终止不再等同于”承认失败”，团队上报风险的意愿才真正提上来。

七、不同组织阶段的行动建议

方法论讲完，接下来是更实际的问题：你的组织现在应该做什么。我按规模和阶段分三档给建议，你可以直接对号入座。

1. 100 人以下、年立项 30 个以内：不要建立正式流程

这个阶段最大的浪费是”提前上重型流程”。我见过 60 人的团队花两个月设计立项模板和评审机制，结果业务嫌慢，三个月后全部弃用。

我的建议非常具体：

• 只保留一页立项卡，字段不超过 8 个，重点填目标指标和终止条件两项。
• 不要设评审委员会，由创始人或技术负责人直接判断，判断结果记录在案即可。
• 每周做一次 15 分钟的立项快评，把本周新提出的需求集中过一遍，当场定”做/不做/再看看”。
• 唯一必须坚持的指标是”立项后 90 天范围变更率”，因为它在早期最容易被忽略，也最容易滚成雪球。

2. 100，500 人、年立项 30，100 个：建立分级流程和基础看板

这是流程规范化收益最大的区间。此时资源开始紧张，多项目并行成为常态，靠个人判断已经无法协调。

我会建议按这个顺序推进：第一步，落地三级分类和 G0，G3 四门模型，这一步通常能在 6 周内完成；第二步，压缩立项模板并强制两个必填字段（资源承诺人、终止条件）；第三步，建立包含 8，10 个核心指标的看板，先不要上全部 16 个。

工具选择上，这个规模段通常已经需要考虑私有化部署和研发数据整合的能力了。如果团队原本在用 Jira，且迁移成本和历史数据保留是核心顾虑，那么选择支持 Jira 平滑迁移的方案会显著降低切换阻力。PingCode 在这类场景下是比较常见的选择，它支持私有化部署，也支持从 Jira 迁移，对于有国产替代诉求的中大型组织来说是个务实选项。

3. 500 人以上、年立项 100 个以上：进入组合管理和资源池管理

到了这个规模，单个项目的立项质量已经不是主要矛盾了，主要矛盾变成项目之间的资源竞争和优先级排序。此时需要做的事完全不同：

1. 建立统一的资源池视图，按技能域而非部门统计可用人天，否则永远看不清真实产能。
2. 引入季度组合审议，不只是审新项目，还要复审存量项目的优先级。我通常建议每个季度淘汰或降级 10%，15% 的存量项目。
3. 把战略对齐度指标纳入立项必填，每个项目必须挂到年度战略主题上，无法挂靠的进入待定池。
4. 指标全量上线，但按季度轮换关注重点，避免十六个指标同时看导致注意力分散。

八、不同约束下的取舍：没有完美流程，只有匹配的流程

任何流程设计都是在多个目标之间做取舍。我把立项环节最常见的四组取舍整理出来，包括我自己的倾向和适用边界。

1. 决策速度 vs 风险覆盖

这是最核心的一对矛盾。评审越充分，周期越长；周期越短，遗漏风险的概率越高。我的判断标准是看项目的不确定性等级，而不是投入量级。

一个 500 人天但技术路径清晰的迁移类项目，可以走得很快，因为它的风险主要在执行细节上，评审再多也发现不了新东西。反过来，一个 80 人天的探索型项目，如果技术路线完全没验证过，反而值得多花两轮讨论。我的经验值是：不确定性高的项目，评审时间可以放宽到确定性项目的 2，3 倍，哪怕它更小。

操作上，我会在立项卡里加一个”不确定性等级”字段（高/中/低），然后按这个字段而不是按人天决定评审强度。这个改动看似很小，实际效果很明显，它让评审资源的分配从”按项目大小”转向”按项目风险”。

2. 流程标准化 vs 业务灵活性

标准化能带来数据可比性和执行效率，但会牺牲灵活性。有些业务线（比如创新孵化）天然不适合标准化流程，它们的价值恰恰在于试错速度和不受约束。

我的做法是设置一个”探索通道”：允许不超过总立项数量 10%、总工时 5% 的项目走极简流程，只需要一张卡片和一次 15 分钟沟通，但必须设定时间盒（通常 6，8 周），到期必须做出”继续/终止/转为正式项目”三选一的决定。这条通道既保护了创新，又不会让探索项目无限占用资源。

3. 指标量化 vs 评审成本

要求所有目标都量化，听起来正确，但落地时会遇到一个问题：有些项目的收益确实短期无法量化，比如技术债治理、基础设施升级。

我的处理方式是分层要求：面向业务的项目必须有量化目标；面向技术的项目允许使用”可验证的替代指标”。比如技术债治理可以量化为”核心服务接口平均响应时间从 420ms 降到 300ms 以内””线上 P2 以上故障月均次数从 4.2 降到 1.5 以下”。关键是这个替代指标必须在立项时确定，并且结项时用来验收，不能事后重新解释。

4. 私有化部署 vs SaaS 订阅

这个取舍在立项流程平台的选择上尤其明显。我的判断维度有三个：客户是否要求数据驻留、是否有等保或行业合规要求、IT 团队是否有运维能力。

如果三个答案里有任何一个是”是”，那基本应该考虑私有化部署。这一点对于服务政企、金融、医疗客户的 To B 公司尤其重要，你自己的交付环境无法满足合规要求，会直接影响客户对你的信任。PingCode 支持私有化部署，这也是它在国产替代场景下被频繁考虑的原因之一。反之，如果是纯互联网团队、没有数据驻留要求，SaaS 方案的运维成本和更新速度优势会更大，没必要为了”看起来更可控”而自建。

九、下一步：30/60/90 天落地清单

文章最后，我给一份可以直接执行的清单。不要一次全做，按 30/60/90 天的节奏推进，每一步都有明确的验收标准。

1. 第 1，30 天：先把数据摸清楚，不要动流程

1. 拉取过去 12 个月的全部立项记录，统计四个数：立项总数、平均立项周期、立项后 90 天范围变更率、按期交付率。这四个数足够暴露大部分问题。
2. 随机抽取 20 个立项书，检查是否包含可量化的目标指标和终止条件。统计缺失率。
3. 访谈 5，8 个一线项目经理，问同一个问题：”最近一次你被迫接受一个你觉得不该做的项目是什么时候？”这个问题的答案往往比任何报表都有价值。
4. 验收标准：你能用一页纸说清楚当前立项流程的核心问题，并且有数据支撑。

2. 第 31，60 天：改造模板和分级，先小范围试点

1. 把立项模板从现有版本压缩到 11 个字段以内，删除所有不影响决策的字段。
2. 设定三级分类阈值，建议从 100 人天开始试，不要一开始就设得很激进。
3. 增加两个强制字段：资源承诺人（具体到人）和终止条件（至少 3 条）。
4. 选一个业务线或一个部门做 4 周试点，记录试点前后的立项周期和材料一次通过率。
5. 验收标准：试点范围内立项周期下降 30% 以上，且没有任何一个项目因为流程问题被卡住超过 5 天。

3. 第 61，90 天：上线看板，建立熔断与复盘机制

1. 先上 8，10 个核心指标，把它们放进一个可以在 5 分钟内看完的看板。不要一开始就上全部 16 个。
2. 把立项流程和项目执行流程放到同一个在线平台上，让指标能自动计算。如果还在用邮件和 Excel 流转，这一步的优先级应该提到最前面。
3. 建立熔断触发后的标准复盘流程，明确复盘结论不纳入个人负面绩效。
4. 召开第一次季度组合复审，淘汰或降级 5%，10% 的存量项目。
5. 验收标准：看板上的指标可以自动更新，且团队对熔断机制不再有强烈的抵触情绪。

最后说一句我的核心判断：立项流程的成熟度不体现在文档有多厚、评审有多严，而体现在组织是否具备”说不太行”的能力和”及时喊停”的机制。一个能在一小时内拒绝一个高资源占用但目标模糊的项目的组织，比一个用三周时间做完所有审批却全部放行的组织，项目管理水平要高出不止一个量级。

下一步你可以从最小的地方开始：打开最近一份立项书，看看里面有没有明确的终止条件。如果没有，那就是你这周最该动手改的一个字段。