去年我帮一家 320 人的智能硬件公司做研发流程诊断，翻出一个挺荒诞的数据：他们跨部门项目的平均立项周期是 27 个工作日，而这些项目的平均交付周期只有 34 个工作日。也就是说，”准备动作”吃掉了整个项目窗口的 44%。更离谱的是，这 27 天里真正用于判断”这个项目该不该做”的时间，加起来不到 3 天。
这篇文章不打算再复述一遍”立项要填什么表”。我想讲的是：跨部门立项的成败，取决于你有没有把它当成一个排期系统来设计，而不是一个审批系统。下面这套”周期落地方案”，是我在 6 家 100 人以上的组织里反复调整出来的，有可以直接抄的部分，也有必须按你自己组织形态改写的地方。
一、核心结论：立项要按”周期”设计，不能按”流程”设计
先把结论摆出来，后面所有内容都围绕这四条展开。如果你只读这一段，也应该能拿走一个可用的判断框架。
结论一：立项的本质是资源与时间的双向承诺，不是文档交付。一份 30 页的立项报告，如果没能换来”张三从 3 月 4 日起投入 60% 工时”，那它在项目管理意义上是零价值的。我见过太多团队把立项做成了作文比赛，评审会上讨论的全是措辞，没人确认排期。
结论二：立项周期必须分级，一条流水线会把小项目拖死、把大项目做浅。一个跨两部门、预算 20 万的系统改造，和一个跨五部门、预算 2000 万的新产品，走同一个七节点审批流，结果必然是前者被流程成本吃掉、后者在关键节点被草草放行。
结论三：立项的完成标志是”资源落位到具体日期”，而不是”审批通过”。这句话听起来像常识，但我调研过的 12 家 100 人以上组织里，只有 3 家把”资源承诺”设成了立项的必填字段，其余 9 家默认”通过了就是同意了”。
结论四：周期落地最有效的动作不是压缩天数，而是消除等待。立项周期里真正产生价值的处理时间通常只占三成，剩下七成是等待，等排期、等预算口径、等某位负责人出差回来签字。压缩处理时间有天花板，消除等待没有。
二、背景与真实场景：为什么跨部门立项总是拖成”月度事件”
要设计周期方案，先得知道时间到底花在哪里。我做过一个小样本统计，覆盖 6 家企业、47 个跨部门立项案例，把每个立项的工作日拆成”处理”和”等待”两类，结果和我预想的完全不一样。
1. 三类最典型的跨部门立项场景
第一类：新产品或新业务立项。典型参与方是市场、研发、供应链、财务、法务五方。它的特点是目标模糊度最高，”我们要做一个面向中小客户的轻量版”，这句话本身无法排期，必须先收敛成可验收的定义，这一步往往要吃掉 5 到 8 个工作日。
第二类：平台级技术改造立项。参与方是 IT、业务方、安全、运维。它的特点是依赖关系复杂，安全评审和运维上线窗口是硬约束，任何一个环节的排期变动都会连锁影响其他环节。
第三类：合规与安全驱动立项。参与方是法务、安全、业务。这类立项的荒诞之处在于：它有明确的截止日期，却没有明确的资源来源。因为它是”必须做”的，反而没人认真谈排期，最后靠加班硬扛。
2. 立项周期的真实成本结构
把 27 个工作日拆开看，会发现一个很不体面的事实：真正需要”人坐在那里思考和工作”的时间，大约只有 8 天，剩下的 19 天都在等。等待的形态五花八门，有的是等会议排期，有的是等某个字段的填写，有的是等两个部门对预算口径达成一致。
3. 挂在决策链上的四类角色
很多人以为立项慢是因为”领导不批”。我跟踪下来的结论恰好相反：立项慢，是因为没有人真正拥有”让它变快”的责任。决策链上通常有四类角色，每一类都有合理的拖延理由。
- 提出方：关心”我的需求能不能被接受”，不关心流程效率，倾向于把材料写得越厚越安全。
- 领域 PMO：关心”是否符合规范”，天然倾向于增加检查点，而不是删减检查点。
- 协作方负责人：关心”我要出多少人、出多久”，在没有明确承诺机制时，最优策略是拖着不表态。
- 审批领导：关心”风险和收益”，但往往只看到材料，看不到排期，容易把决策往后推一次会议。
这四类角色的诉求并不冲突，冲突的是他们各自被考核的指标。周期落地方案的核心，就是设计一套机制，让”让项目按时立项”变成每一方都获益的行为。
三、拆解常见误区：五个把立项拖垮的”合理做法”
下面这五个误区，每一个单独看都很有道理，合在一起就是灾难。我把它们按”额外耗时”排了序，数据来自前面提到的 47 个案例样本。
1. 误区一：把立项等同于写文档
这是最常见也最隐蔽的一个。团队把立项的产出定义为”一份通过评审的报告”，于是所有精力都投向措辞、排版、图表美化。文档是沟通载体，不是立项目的。判断方法很简单：立项报告写完后，如果没有人能说出”谁、从哪天开始、投入多少”，那这份报告就没完成使命。
2. 误区二：一套模板打天下
统一模板的初衷是降低理解成本，实际效果是抬高小项目的成本、降低大项目的标准。我见过一个团队用同一套 18 页模板处理预算 8 万的接口改造和预算 800 万的平台重构，结果是前者被拖了 12 天，后者的商业论证部分只写了半页。
3. 误区三：把审批节点当质量门
每加一个审批节点，团队就多一次”重新解释”的成本。更麻烦的是，节点越多，越没有人为整体质量负责。三个节点各自签了字，等于三个节点都没签字。真正有效的做法不是增加节点，而是让每个节点的准出条件唯一且可验证。
4. 误区四：立项通过 = 资源到位
这是我统计里最贵的误区，平均多花 7.4 个工作日。逻辑上它是一个”责任真空”：立项委员会认为资源问题已经交给部门负责人，部门负责人认为项目还没正式排期，于是项目在”已立项但没人做”的状态里漂了两周。
5. 误区五：没有否决机制，需求池变成垃圾场
很多团队担心”否决会打击积极性”，于是所有需求都进池子。但一个从不否决的立项机制，实际上是在用所有人的时间给少数人的想法买单。健康的立项体系，预审阶段的打回率应该在 30% 到 50% 之间，低于 20% 说明预审形同虚设。
四、专业判断逻辑：周期落地方案的四层设计
具体怎么落地？我把它拆成四层，从分级开始，到复盘闭环结束。这四层是有顺序的，跳过任何一层，后面的机制都会失效。
1. 第一层：分级，立项不是一件事，而是四件事
分级的核心是”用不同的周期上限约束不同量级的决策”。级别不是为了区分重要性，而是为了匹配决策成本。一个 20 万的改造和 2000 万的新产品，需要的论证深度、参与人数、风险审查范围完全不同。
| 级别 | 判定条件 | 立项周期上限 | 审批层级 | 必备材料 |
|---|---|---|---|---|
| S 级 | 跨 4 个以上部门，或预算 ≥ 500 万，或影响公司级战略目标 | 15 个工作日 | 立项委员会 + 分管高管 | 立项卡、商业论证、风险清单、资源承诺书 |
| A 级 | 跨 3 个部门，或预算 100-500 万 | 11 个工作日 | 领域 PMO + 交付负责人 | 立项卡、资源承诺书 |
| B 级 | 跨 2 个部门，或预算 20-100 万 | 5 个工作日 | 领域 PMO | 立项卡（一页） |
| C 级 | 单部门 + 1 个协作方，预算 < 20 万 | 2 个工作日 | 团队负责人备案 | 轻量立项卡（5 个字段） |
分级规则必须在需求入池那一刻就生效，而不是等预审之后再定。否则团队会默认按最高级别准备材料，分级就失去了意义。我建议把级别判定做成入池表单的必填项，并用自动规则给出建议值，人工可覆盖但要填理由。
2. 第二层：前置，预审会把一半以上的问题挡在门外
预审的目标不是”筛掉不好的项目”，而是”让进入评审的项目都具备可决策条件”。我在实践里把预审的准出条件定为三条：目标可验收、预算口径明确、协作方已知会。三条里缺任何一条，直接打回，不进评审。
这一步看起来是增加了环节，实际上是把原本散落在评审会上的争议提前消化了。我观察到的一个经验数据是：实施预审后，评审会平均时长从 92 分钟降到 41 分钟，而单次评审能处理的项目数从 3 个提升到 6 个。
3. 第三层：承诺，把”原则上支持”翻译成”谁、多少天、从哪天开始”
这是整套方案里我最坚持的一条。“原则上支持”不是承诺，它只是礼貌。有效的资源承诺必须包含三个字段，缺一不可：具体的人、开始的日期、投入的比例或人天。
为了让这一步可执行，我通常建议把立项卡做成结构化的，而不是自由文档。下面是我在多家公司用过、迭代了 4 版的立项卡模板。
立项编号: PRJ-2024-0731
立项级别: A # S/A/B/C，直接决定走哪条立项周期
一句话目标: 将订单履约系统的对接周期从 14 天压缩到 5 天
提出方: 供应链中心 – 王琳
交付方: 平台研发部 – 张野
协作方: 财务共享中心、信息安全部
预算口径: 平台研发部年度预算；超出 15 万部分走 IT 专项
关键里程碑:
2024-08-12 需求冻结
2024-09-06 联调完成
2024-09-20 灰度上线
资源承诺:
张野（后端）: 2024-08-05 起，投入 70%，合计 35 人天
李萌（前端）: 2024-08-12 起，投入 50%，合计 18 人天
信息安全部: 2024-08-28 前输出安全评审结论
验收标准: 5 类主流程单据对接成功率 ≥ 99.5%，人均单据处理耗时 ≤ 8 分钟
否决条件: 若 8 月 12 日需求未冻结，项目自动降级为 B 级并顺延一个周期
注意最后一行”否决条件”。没有自动后果的规则，等于没有规则。把”如果某条件不满足就自动降级或顺延”写进立项卡，能极大减少后续扯皮，因为后果在立项时就已经被各方认可了。
4. 第四层：闭环，立项后 30 天必须复盘一次
立项不是终点，它是一次预测。既然是预测，就应该被检验。我在方案里固定了一个动作：立项后第 30 个自然日，自动触发一次复盘，只看三个偏差，周期偏差、资源偏差、验收标准偏差。
这三个偏差的用处非常大。周期偏差超过 30%，说明前期的里程碑是拍脑袋定的；资源偏差超过 25%，说明资源承诺机制没有真正约束住排期；验收标准偏差大，说明预审的目标可验收性检查做得不够。复盘输出不需要长，一页三行就够，但必须进知识库，供下一个立项参考。
五、案例解析：一家 200+ 人研发组织如何把立项周期从 27 天压到 11 天
前面的逻辑讲完了，接下来是我实际参与的一段落地过程。这家公司是做企业级 SaaS 的，研发加产品约 240 人，另有供应链与财务等协作部门，整体规模在 300 人左右，属于典型的需要跨部门立项但又没有专职 PMO 的中大型组织。
1. 改造前的流程与三个硬卡点
改造前他们用的是”需求池 → 月度评审会 → 立项 → 排期”这条线。三个卡点非常典型。第一，评审会一个月一次，错过就要等 30 天，导致大量项目在”已准备好但没会开”的状态下空转。第二，立项通过后没有资源确认环节，研发负责人拿着通过的立项去要人，才发现关键成员已经被别的项目占满。第三，历史需求全在一张共享表格里，没人知道某个需求上次被谁打回过、为什么打回。
2. 用工具固化周期规则
流程设计完成后，他们需要一个能承载”状态机 + 时限 + 承诺字段 + 自动触发复盘”的载体。这家公司最终选了 PingCode，主要原因是三点：一是它面向中大型企业、100 人以上组织的场景做得比较完整，项目集、需求池、里程碑能串起来；二是支持私有化部署，他们的客户里有金融和制造行业，对数据落地有硬要求；三是他们原来用的是 Jira，历史数据量不小，迁移成本是选型里的关键变量。
具体配置上，他们把立项拆成了六个状态，每个状态都设了停留上限。这是我在方案里最看重的部分，状态机的价值不在于”能流转”，而在于”超时会被看见”。
状态机: 跨部门立项工作流
草稿 Draft
责任人: 提出方
停留上限: 3 个工作日
准出条件: 立项卡必填字段完整度 ≥ 90%
预审 Pre-screen
责任人: 领域 PMO
停留上限: 2 个工作日
准出条件: 输出「通过 / 打回 / 降级」三者之一
资源承诺 Commitment
责任人: 各协作方负责人
停留上限: 3 个工作日
准出条件: 每条承诺落到「人 + 起止日期 + 投入比例」
评审 Review
责任人: 立项委员会
停留上限: 2 个工作日（固定会期，错过顺延）
准出条件: 立项级别与预算口径确认
已立项 Approved
责任人: 交付方项目经理
停留上限: 1 个工作日
准出条件: 里程碑写入排期视图并全员可见
复盘 Retro
触发点: 立项后第 30 个自然日自动创建
准出条件: 输出周期偏差 / 资源偏差 / 标准偏差三项结论
3. 迁移与配置阶段的关键数据
工具选型之后的落地，我认为比选型本身更值得写。他们花了 2 周完成从原系统到新平台的迁移，比计划提前了 1 周，其中有几个数据我觉得有参考价值。
4. 改造后的量化结果
改造上线后，我们连续跟踪了 6 个月，指标变化比我预期的更明显。其中我最在意的是”立项后 30 天资源到位率”，因为这个指标直接反映了承诺机制是否真的产生了约束力，而不是又一份漂亮的表格。
六、不同情况下的行动建议
周期落地方案不是一套放之四海皆准的模板。组织规模、业务形态、合规要求不同，落地的重点差别很大。下面按四种典型情况分别给建议，你可以直接对号入座。
1. 50 人以下的团队：别做流程，做模板
这个规模做复杂流程的收益是负的。我的建议是只做两件事：一个一页纸的立项卡模板，加一个固定的周会节奏。不需要分级，不需要状态机，不需要审批系统。立项卡里保留四个字段就够：目标、验收标准、谁做、什么时候做完。
这个阶段最常见的错误是照搬大公司的立项流程，结果把仅有的三五个跨部门项目拖成月度事件。50 人以下，速度就是治理。
2. 100 到 500 人的组织：分级 + 状态机是核心
这个区间是周期方案收益最大的区间，也是本文主要讨论的场景。核心动作有三个：建立 S/A/B/C 四级规则并写进需求入池表单；把立项拆成不超过六个状态并设置停留上限；把资源承诺设为必填字段且必须包含人和日期。
工具层面，这个规模的团队通常已经有历史项目管理数据，迁移成本是必须提前评估的变量。建议在选型时把”历史数据能否平滑迁移”和”是否支持私有化部署”作为两个硬性筛选条件，而不是等到实施阶段才发现数据搬不过来。像 PingCode 这类面向中大型企业、支持私有化部署、并且对从 Jira 平滑迁移有完整方案的平台，在这个规模段是比较省心的选项。
3. 500 人以上或多事业部：先做机制统一，再做工具统一
这个规模最大的问题不是流程慢，而是各事业部各有一套流程，跨事业部立项就像两个国家谈判。我的建议是先统一三件事：立项级别定义、资源承诺的字段格式、复盘的时间点。这三件事统一之后，再统一工具，否则工具会把分裂固化下来。
另外一个容易被忽视的点是：这个规模下应该设专职或半专职的领域 PMO。没有人的流程一定会退化，这是我在多家公司反复验证过的规律。
4. 强合规行业：把合规检查前置，而不是加审批节点
金融、医疗、汽车电子这类行业，合规检查是刚性的，不能省。但做法可以优化。不要在立项流程里加节点，而是在预审阶段加检查清单。把法务、安全、数据合规的检查项变成预审的必填项，让不合规的项目在预审就被挡住，而不是等到评审会上才被否决。
这样做的好处是：检查项一旦标准化，就可以部分自动化。我见过一家公司把 12 项合规检查做成了预审清单，其中 7 项可以由系统根据字段自动判定，另外 5 项才需要人工确认，整体预审时间从 3 天降到了 1 天。
七、不同情况下的取舍
所有流程设计本质上都是取舍。我把跨部门立项里最常见的四组取舍列出来，并给出我的判断依据。这些判断不是绝对的，但至少能给你一个参照点。
1. 速度 vs 治理
这是最根本的一组取舍。我的判断依据是”可逆性”：如果决策错了可以低成本回退，就选速度；如果错了要付出巨大代价，就选治理。比如一个内部的报表工具改版，错了大不了回滚，没必要做三轮论证；但涉及资金结算逻辑的变更，就必须慢下来。
一个实用的做法是在立项卡里加一个”可逆性”字段，取值是”高 / 中 / 低”。可逆性高的项目自动降一级处理，可逆性低的自动升一级。这样速度与治理的权衡就不再依赖主观争论。
2. 标准化 vs 灵活性
标准化带来可比较性，灵活性带来适配性。我倾向于标准化”字段”，灵活化”内容”。也就是说，所有立项卡必须有相同的字段（目标、验收标准、资源承诺、否决条件），但每个字段填写多少字、附多少材料，由提交方自己决定。
这样既保证了不同项目之间可比，又不会让团队觉得被模板绑死。反过来做，字段随意、格式统一，是最糟糕的组合，因为它既不灵活也不可比。
3. 工具 vs 机制
经常有人问：是不是上个系统立项就快了？我的回答很直接：工具只能让已有的规则更快被执行，不能替代规则本身。如果”资源承诺”这件事在组织里没有被认可为必填项，那把它做成系统字段，团队也只会填”待定”。
正确的顺序是：先花两周把分级规则、状态准出条件、资源承诺格式谈清楚，再花两周配置工具。反过来做，通常会得到一个功能齐全但没人认真用的系统。
4. 中心化 PMO vs 分布式立项
| 取舍维度 | 选中心化 PMO | 选分布式立项 | 我的判断依据 |
|---|---|---|---|
| 立项周期可控性 | 强，口径统一 | 弱，各团队标准不一 | 跨 5 个以上部门的项目占比超过 20% 时，倾向于中心化 |
| 业务响应速度 | 慢，需要排队 | 快，业务方直接推进 | 业务变化频率高的行业，倾向于分布式 |
| 资源冲突处理 | 可全局调度 | 靠部门间自行协商 | 关键资源（如架构师、安全专家）稀缺时，倾向于中心化 |
| 流程退化风险 | 低 | 高，容易随人员流动失效 | 团队稳定性差时，倾向于中心化 |
我实际见过的效果最好的组合是”混合制”：中心化 PMO 只负责 S 级和 A 级立项，B 级和 C 级完全下放给团队，只保留事后抽检。这样既守住了关键决策的质量，又不会让 PMO 成为所有事情的瓶颈。
八、总结与下一步
回到开头那个 44% 的数字。跨部门立项之所以容易失控，不是因为审批太多，而是因为它同时承载了三件相互纠缠的事：判断该不该做、决定谁来做、约定什么时候做完。把它们塞进同一条流水线，必然互相拖累；把它们分层拆开，周期自然就下来了。
这篇文章里我认为最值得你带走的一个观点是：立项的优化对象是”等待”，不是”验证”。很多团队一谈提速，第一反应是砍掉评审、砍掉材料、砍掉论证，结果是把风险推到执行阶段，总成本反而更高。真正应该砍的是等排期、等口径、等会议、等签字，这些环节不产生任何决策价值。
第二个值得带走的观点是：没有自动后果的规则不是规则。停留上限、否决条件、自动降级，这三样东西看起来是流程细节，实际上是整个周期方案能不能自我运转的关键。没有它们，所有规则都依赖某个人持续推动，而人一定会流动。
至于下一步怎么做，我的建议是按这个顺序推进，不要跳步：
- 先测量。把最近 10 个跨部门立项的周期拆成”处理”和”等待”两部分，找到你自己的时间黑洞在哪里。这一步不需要任何工具，一张表格就够。
- 再分级。用一到两周时间把 S/A/B/C 的判定条件和周期上限定下来，写进需求入池表单。这一步需要各协作方负责人参与，不能由 PMO 单方面拍板。
- 然后固化承诺字段。把”人 + 起止日期 + 投入比例”设为立项的必填项，并明确”原则上支持”不被接受。这一条执行到位，效果立竿见影。
- 最后选载体。当规则明确之后，再去评估用什么工具承载。评估时优先看三件事：能不能配置状态停留上限、能不能支撑历史数据迁移、能不能满足部署与合规要求。对中大型企业来说，支持私有化部署和从 Jira 平滑迁移的平台，能省掉大量实施阶段的隐性成本。
最后补一句我的个人判断：立项流程的复杂度，应该和组织的决策成本成正比，而不是和组织的历史惯性成正比。很多流程之所以存在，只是因为”一直是这样”。每隔一年重看一遍你的立项流程，问一句”这个节点去年挡住了什么风险”，你会砍掉其中相当一部分。
常见问题解答（FAQ）
1. 跨部门项目从动议到正式立项，周期控制在多久算合理？我该怎么压缩？
我们公司每次立项都要拉七八个部门开会，前前后后拖了一个多月还没定下来，业务方天天催，我作为牵头人夹在中间特别难受。我一直在想是不是流程本身就有问题，但又说不清哪个环节该砍、哪个环节不能砍。
我的经验口径是：从立项动议到形成立项决议，常规跨部门项目控制在2到4周，涉及3个以上部门、周期超过6个月的大项目也不要超过6周，超过这个区间基本说明流程里混入了不该在这个阶段解决的问题。
把它拆成三段更可控：准备期3到5个工作日，产出一页纸立项建议书，只写背景、目标、不做的后果、里程碑骨架和资源缺口，不写详细计划；预沟通期5到8个工作日，牵头人逐个找关键干系人单聊20到30分钟，把异议在地面阶段消掉；评审决议期2到3个工作日，正式评审会只留需要当场拍板的分歧。
压缩周期的关键不是砍评审次数，而是把沟通前置，我做过的一个案例里，8个部门的异议在预沟通阶段解决掉七成，正式评审会只开了70分钟就出决议。如果某个议题在会上反复出现两次以上还没结论，说明决策权没放对位置，应该直接上升，而不是继续排会。
2. 立项会上各部门都说支持，但一谈到出人就打太极，这种资源承诺落不了地怎么办？
我们每次立项会气氛都很好，大家都说这个项目很重要必须支持，结果会后要人名要工时，一个个都说要回去排期，然后就没了下文。我不是没催，但催急了对方就说我推不动，我自己也觉得没底气。到底该怎么让资源承诺变成硬的东西？
核心问题是把会上要谈的内容换掉：会上不要讨论要不要做，那是立项之前就该对齐的；会上只确认谁做、做多少、什么时候开始。
具体做法是提前3个工作日发一张资源承诺表，每个部门必须填三列，具体到人的姓名、投入比例（建议用0.2或0.5这种FTE口径，不要写全力支持）、起止时间，会上只做确认和争议裁决，不做现场填表。同时每个交付物只设一个A（唯一拍板人），其余是执行和协同，避免出现两个部门都以为对方是主责的情况。
遇到资源确实排不出来的部门，当场把冲突提交给双方共同的上级裁决，绝不留到会后再说，这是最容易失守的一步。判断承诺真假有个很简单的标准：填不出人名和投入比例的，就当没承诺，直接进入升级流程。我见过最有效的一次，是牵头人当场把资源缺口和三个备选方案投在屏幕上，让决策者在会上三选一，20分钟就定完了。
3. 立项书写完就锁进抽屉了，怎么让周期落地方案真正跑到日常管理里？
我们公司立项文档写得挺漂亮，几十页PPT，评审也过了，但过了两周就没人看了，进度靠微信群问，节点靠记忆催。我怀疑是不是立项本身和后面的执行是两套东西。有没有办法让立项的成果直接变成能盯的东西？
判断立项有没有真正落地的标准很直接：立项文档里的内容能不能在项目管理平台里被逐条打开、逐条打勾、逐条看偏差。如果一份立项书3周内没有被任何人打开过，说明它根本没有被结构化，只是仪式性文件。
我的做法是把立项产出强制拆成三类结构化对象搬进平台：第一类是里程碑，每条必须带唯一负责人和具体日期，不接受2025年Q2这种模糊口径；第二类是交付物清单，每条带验收标准，验收标准的写法是能被第三方判断合格或不合格，而不是高质量完成；第三类是资源与预算基线，用来在后期做变更对照。
日常管理只盯两个指标：里程碑按期完成率和偏差天数，每周站会只看偏差排名前三的项。另外一定要设变更阈值，比如里程碑整体延后超过10个工作日或预算变动超过15%，必须重新走一次轻量评审，否则项目会在不知不觉中偏离立项时的假设。把立项当成一次数据建模，而不是一次作文，它才有可能活在执行里。
4. 公司没有专职PMO，跨部门立项怎么用最小成本跑起来？
我们是两百人左右的团队，没有PMO，也没有专门的流程岗，每次跨部门项目都是临时抓人牵头，全靠个人威望和人情推动。我很想知道，是不是一定得先建个PMO才能做规范立项，还是说有更轻的做法？
不需要先建PMO，立项流程的价值在于让资源冲突提前暴露，而不是让文档变厚。最小可用版本只要四件事：一页纸立项书，写清背景、目标、不做会怎样、里程碑骨架和资源缺口，控制在一页，逼自己说重点；一个明确的决策人，跨部门项目最怕集体负责，必须有一个能拍板的人，通常是发起方负责人或者双方共同的上级；
一次30到45分钟的评审会，只裁决分歧，不做汇报；一份台账，记录每个项目的里程碑、负责人、当前状态，用共享表格起步就够了。真正的成本不在流程而在纪律：新项目一律先立项后开工，没有例外，这条守不住，流程当天就废。
等同时并行的跨部门项目超过5个、或者开始出现两个项目抢同一个人力的冲突，再考虑引入工具或专职角色。我见过一个30人团队用一张共享表格跑了大半年，效果比很多有完整体系的公司还好，差别就在他们每次立项都把资源缺口摆到台面上解决，而不是绕过去。
文章包含AI辅助创作：周期落地方案：跨部门团队开展项目立项的最佳实践案例解析，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/284824
读者评论
我们公司80人左右，跨部门项目不多，C级2天能接受，但B级5天连财务预算口径都确认不完。分级表里20万就算跨部门项目，对小公司偏高。这套方法可能更适合150人以上有专职PMO的组织，小团队照搬容易卡在审批层级上。
资源承诺书如果只是填名字和投入比例，实际执行中还是会被临时抽调。我们后来在项目管理工具里把资源占用做成冲突提示，才稍微压住。文章说资源要落到日期没错，但没讲拿什么约束部门负责人，光靠一张立项卡可能不够。
预审打回率30%到50%这个区间有点理想化。我们打回多了，业务方就绕过预审直接找领导特批，反而更慢。除非高层也认这个规则，不然预审容易变成新的等待点。否决机制和积极性之间的度很难拿捏。