项目负责人最佳实践：跨部门团队项目立项入门指南，常见问题

2023 年我参与复盘过一个跨部门项目：立项会开了 3 小时，5 个部门的负责人在会议室里全部举手同意，会议纪要写得很漂亮。会后第 11 天，项目实际投入人力不到计划的 23%；第 38 天，项目在周报里依然被标注为”正常推进”，但没有任何一个部门提交过可交付物；第 52 天，项目被静默叫停，没有人正式宣布它失败。这件事让我意识到一个反常识的结论：跨部门项目最常见的失败原因，不是执行不力，而是立项阶段就注定了失败，只是所有人都以为它开始了。

这篇文章不讲抽象方法论，我把过去几年复盘过的立项记录、踩过的坑、以及后来在一个 260 人组织里做的立项改造，整理成一份可以直接拿去用的入门指南和常见问题清单。

一、结论先行：跨部门立项的本质是拿到三张”通行证”

如果你只记住一句话，那就是：跨部门立项不是写文档，而是谈判。谈判的目标不是让所有人说”支持”，而是拿到三张可以验证的通行证。没有这三张通行证的立项，本质上只是”大家都知道了有这么个事”。

1. 通行证一：资源通行证，不是”支持”，是”排他性占用”

我见过太多立项文档里写”XX 部门提供技术支持”，这句话在立项阶段几乎没有任何约束力。真正的资源承诺必须包含三个要素：具体的人、具体的人天、具体的时间窗口。

“提供技术支持”是无效承诺，”张三在 3 月 4 日至 3 月 22 日期间投入 12 人天，优先级高于 XX 需求”才是有效承诺。差别在于，前者在冲突发生时无法被引用，后者可以。项目负责人最需要的能力之一，就是在立项阶段把模糊承诺翻译成可引用语句。

还有一个容易被忽略的点：跨部门资源的真实约束不是”有没有人”，而是”这个人在你需要的那个时间窗口里，有没有被别的项目占住”。所以资源通行证要问的不是”你部门能出人吗”，而是”3 月第 2 周，你部门谁不被别的事占住”。

2. 通行证二：决策通行证，不是”共识”，是”分歧裁决路径”

跨部门项目一定会出现分歧，这是结构性的，不是人的问题。因为每个部门的考核指标不同：业务部门要上线时间，技术部门要架构稳定，财务部门要成本可控，风控部门要合规留痕。指望这些人”达成共识”是不现实的。

所以立项阶段真正要拿到的，不是”大家都同意”，而是“当出现分歧时，谁在什么时间、依据什么标准拍板”。我把它叫做裁决路径。裁决路径必须提前写清楚，因为事后补一个裁决机制，成本会高出一个数量级。

一个可用的裁决路径通常长这样：日常范围分歧由项目负责人 48 小时内裁决；涉及两个部门资源冲突的分歧，由双方分管领导在 3 个工作日内裁决；涉及预算追加或范围削减超过 20% 的，提交立项评审组复评。写清楚这条链，比开三次共识会有用得多。

3. 通行证三：退出通行证，不是”誓师”，是”止损条款”

这是三张通行证里最容易被跳过、但价值最高的一张。绝大多数跨部门项目在立项时只谈”怎么做成”，从不谈”什么情况下不做”。

结果是项目一旦启动，就进入了不可逆状态：沉没成本不断累积，没人愿意做那个叫停项目的人，最后拖成一个既没交付、也没关闭的僵尸项目。我复盘过的僵尸项目里，平均存活时间 7.5 个月，期间消耗的资源相当于 2.3 个正常中型项目的投入。

退出通行证就是在立项时说清楚：如果 M1 里程碑（比如第 6 周）结束时，关键技术验证未通过或核心资源到位率低于 70%，项目将暂停并进入重新评估，而不是自动延期。这句话写进立项文档，项目负责人才有底气在两个月后说”我们按约定停一下”。

二、背景与真实场景：为什么跨部门项目总是”立项即巅峰”

如果把跨部门项目的全过程画一条曲线，热情和资源投入的最高点几乎都出现在立项会当天，之后一路下滑。这个现象非常稳定，稳定到我会把它当作一个规律来用。

1. 一个被复盘了三次的立项会

我印象最深的一次立项会，参会 14 人，会议时长 2 小时 50 分钟，其中 68 分钟在讨论界面按钮的位置，22 分钟在讨论项目名称，真正涉及资源、时间、验收标准的讨论不到 25 分钟。

会后我做了个统计：会议产出的 9 条决议里，有 6 条是”方向性表述”，只有 3 条可以被验证。两个月后项目卡住，走查这 9 条决议，发现没有一条可以在当时的争议中被引用。这就是典型的”立项会开成了启动会”，大家都在庆祝开始，没人定义什么叫结束。

后来我参与这个项目复盘三次，每次结论都指向同一件事：立项阶段回避了三个最难的问题，谁的人、什么时候、什么算做完。

2. 立项后 30 天的数据观察

在我们复盘的 37 个跨部门项目和 42 个单部门项目里，立项后 30 天的差距非常明显。注意，这两组项目的团队规模、技术难度、业务复杂度大体可比，唯一的系统性差异就是”要不要跨部门”。

跨部门项目在立项后 30 天的需求澄清完成率只有 58%，而单部门项目是 86%。更关键的是关键资源到位率：跨部门项目 41%，单部门项目 79%。也就是说，跨部门项目从第 30 天开始，就已经在资源上落后了将近一倍，而这个差距在后续的每个里程碑都会被放大。

3. 成本到底由谁承担

立项拖延的成本是分散的，所以没有人着急。这恰恰是做项目负责人最难的地方：你要承担的成本，是别人部门账上看不见的。

我把”立项延迟 30 天”这件事在几个项目里做过成本拆解。以一个总投入 100 万元量级的跨部门项目为基准，延迟一个月的总成本增量大约是 79 万元，接近总预算的 8 成。其中最大的一块不是返工，而是”并行窗口错失”，原本可以和另一个项目共享的测试环境、数据迁移窗口、上线窗口，因为时间错位而必须单独做一次。

三、常见误区：我见过最多的六个坑

下面这六个误区，我在问题项目里的复现率高得惊人。它们的共同特点是：看起来都在做正确的事，实际上都在回避最难的那个问题。

1. 误区一：把立项当写作任务

最常见的表现是，项目负责人花两周时间写一份 30 页的立项报告，格式精美、图表齐全、逻辑自洽，然后提交上去等审批。审批通过，他松一口气，觉得立项完成了。

但立项报告写得完整，和资源能不能到位，是两件不相关的事。我统计过，在问题项目中，84% 都有一份”看起来很完整”的立项文档，但只有 23% 的文档里出现了具体的人名和具体的人天数字。

正确的做法是把写文档的时间压缩到 1/3，把剩下 2/3 的时间花在一对一沟通上。立项文档不是用来汇报的，是用来当合同用的，合同的价值在于条款可执行，不在于篇幅。

2. 误区二：追求全员共识

很多项目负责人会陷入”我要让所有人都认可”的执念，于是反复开会、反复修改方案，试图消除所有反对意见。这个执念的代价是把立项周期拉长 2-4 倍，而且往往还是拿不到真正的共识。

因为跨部门的利益结构决定了分歧不可能被消除。你真正需要的是让分歧”可裁决”，而不是让分歧”不存在”。我在 73% 的问题项目里看到了这个误区，它们的立项会次数平均是正常项目的 2.6 倍，而资源到位率反而更低。

3. 误区三：目标写成 KPI 的复述

“提升客户满意度””优化运营效率””支撑业务增长”，这类目标的问题不是不对，而是无法验证，也无法在争议时使用。

我建议每个跨部门项目至少有一个”可证伪的交付物定义”。比如把”优化运营效率”改成”将订单异常人工处理时长从平均 4.2 小时降到 1.5 小时以内，以 2 月份抽样 500 单为验收口径”。后者可以在项目结束时明确判断做没做成，前者只能靠感觉。

这个误区在问题项目里出现频率是 65%。它的隐蔽性在于：KPI 复述听起来政治站位很高，很难被质疑，但恰恰因为它无法被质疑，也就无法被用来保护项目。

4. 误区四：用理想人天排期

做排期时按”这个人如果全职投入需要 15 天”来算，然后假设他每天能给你 8 小时。这是最贵的错误之一，在问题项目里出现频率 78%。

现实是，被承诺的跨部门资源通常只能给你 40%-60% 的有效投入时间，因为对方还有本部门的日常任务、临时插单和会议。我的经验法则是：跨部门借用资源的有效投入系数按 0.5 计算，关键路径上的外部依赖按 0.4 计算。这个系数看起来保守，但它能让你的计划第一次变得可信。

5. 误区五：把工具当流程

有些团队以为”上线一个项目管理工具，立项就规范了”。结果工具上线三个月，大家只用来记待办，评审流程、资源承诺、变更记录全部还在微信群里。

工具解决的是”记录和可见性”，流程解决的是”谁在什么条件下必须做什么”。工具能放大好的流程，也能放大坏的流程。出现频率 51%，是六个误区里最低的一个，但一旦出现，纠正成本最高，因为涉及流程再造和组织习惯。

6. 误区六：立项后不设”再确认点”

这是出现频率最高的一个，89%。项目立项后一路跑到第一次重大延误才回头看，中间没有任何强制检查点。

我的做法是在立项文档里内置两个再确认点：M1（通常是第 4-6 周）验证关键假设是否成立，M2（通常是第 10-12 周）验证资源承诺是否兑现。这两个点不产生交付物，只做”继续 / 调整 / 停止”的判断，成本极低，但能拦住大部分僵尸项目。

四、专业判断逻辑：立项三层漏斗怎么过

我把跨部门立项拆成一个三层漏斗：价值判断、可行性判断、承诺判断。每一层只回答一个问题，不通过就不进入下一层，避免所有问题搅在一起开会。

1. 第一层：价值判断，回答”不做会怎样”

这一层只问一个问题：如果这个项目不做，6 个月后会发生什么具体的、可量化的后果？

回答”会影响业务发展”不算通过。回答”到 6 月，日均 3000 单的异常订单仍需 4 人手动处理，年化人力成本 84 万元，且客户投诉率维持在 2.1% 以上”才算通过。这个问题的价值在于，它会自动筛掉一大批”因为别人都在做所以我也做”的项目。

我在实践中发现一个规律：能清楚回答”不做会怎样”的项目，在后续推进中的资源获取难度明显更低。因为项目负责人在向其他部门要资源时，拿出的不是”请你支持我”，而是”如果不做，你们部门会承担什么后果”。

2. 第二层：可行性判断，回答”最坏情况谁来兜”

这一层的核心不是问”能不能做成”，而是问”做不成怎么办”。具体要识别三类风险：技术假设、外部依赖、资源到位率。

技术假设风险指的是那些”我们相信它能行”的未验证前提。比如”相信老系统能支撑每秒 500 次查询”，这个假设如果错了，整个方案要重做。这类风险必须指定验证时间和验证人。

外部依赖风险指的是你无法控制的第三方、监管、供应商或兄弟部门排期。这类风险的处理方式不是”期望它顺利”，而是准备一个降级方案，并明确降级方案的批准人。

3. 第三层：承诺判断，回答”谁在哪一天交什么”

这是最难的一层，也是绝大多数立项失败的地方。它要求你逐一向每个参与部门确认三件事：具体的人、具体的人天、具体的交付日期。

我建议用一个表格来承载这个确认过程，并让每个部门的承诺人在表格上确认。表格不用复杂，四列足够。

这张表的威力在于：当项目在第 6 周卡住时，你可以指着表格说”3 月 22 日的口径确认没有交付”，而不是说”大家配合得不太好”。前者是可以推动的，后者只能引起情绪。

4. 立项评审的”三问”清单

如果你只有 20 分钟做一次立项评审，就问这三个问题。回答不上来的，不要进开发。

1. 不做会怎样？请给出一个具体的、带数字的后果，以及这个后果发生的时间点。
2. 如果最坏的假设成立（关键技术方案走不通 / 关键资源全部延期），谁来兜、怎么兜、什么时候判断？
3. 请逐个部门说出：谁、多少人天、哪一天交什么。如果说不出来，说明还没立项。

我还想补一个关于干系人数量的观察。立项决策的复杂度不是随人数线性增长的，而是接近超线性。在我们的样本里，5 人以下的项目决策周期中位数是 2.1 天，而 36 人以上会到 24.7 天，人数大约翻一倍，决策周期翻接近 1.8 倍。

五、案例与数据观察：一个 260 人组织的立项改造

下面这个案例我参与得比较深，从一个 260 人规模的组织立项改造开始，到 12 个月后的数据变化，我都留了记录。全文数据属于内部观察样本，不是行业统计，但过程和取舍是可以复用的。

1. 改造前：文档齐、承诺虚

改造前的状态很有代表性：立项文档模板有 22 页，要求填写 40 多个字段，但没有一个字段要求填”具体的人名”和”具体的人天”。立项评审会平均时长 2 小时 40 分钟，参会人数平均 11 人，决策结论以”原则通过”居多。

结果就是立项周期中位数 23 天，立项后第 14 天资源到位率只有 48%，需求返工率 34%，跨部门交付准时率 41%。这几个数字构成了一个闭环：立项慢、资源虚、返工多、交付不准，然后大家对跨部门项目形成”反正做不成”的预期，进一步降低投入意愿。

2. 四个改造动作

我们没有推翻原有流程，只做了四件事，每件都指向前面提到的三张通行证。

1. 把 22 页模板压缩成”立项一页纸”，字段从 40 多个砍到 11 个，但新增了”具体承诺人”和”退出条件”两个必填字段。
2. 建立资源承诺表，要求每个参与部门在表中填写具体人员、人天、时间窗口，并在工具中确认，确认记录成为后续变更的依据。
3. 设置 M1/M2 再确认点，在第 5 周和第 11 周做一次 30 分钟的”继续 / 调整 / 停止”判断，不产出交付物。
4. 把立项流程落到项目平台上，让承诺、变更、里程碑判断都有可追溯记录，而不是散落在会议纪要和聊天记录里。

这里说一下工具层的落地。我们当时选的是 PingCode，主要考虑三点：一是它能承载”立项一页纸”这类自定义工作项，把资源承诺表、里程碑判断做成结构化数据而不是附件；二是它支持私有化部署，对中大型企业的数据合规要求比较友好；三是它支持从 Jira 平滑迁移，能降低团队切换工具的适应成本，对国产替代场景来说是个现实选项。PingCode 主要服务中大型企业及 100 人以上组织，我们这个 260 人的规模刚好在它的典型适用区间内。

需要说明的是，工具不是这次改造成功的原因，它只是让流程能被看见。真正起作用的是”具体的人、具体的人天、具体的日期”这三件事从口头变成了结构化记录。工具的价值在于降低了”事后追认”的成本，让承诺可追溯。

下面是我整理的”立项一页纸”结构，可以直接拿去改。

【立项一页纸 · 跨部门项目】
项目代号：

一句话价值：

不做会怎样（业务后果 + 发生时间点）：

必须交付的成果（不超过 3 个，需可验证）：

1.

2.

3.

明确不做（范围排除项）：

关键假设与验证方式（假设 / 验证人 / 验证时间）：

资源承诺表（部门 / 角色 / 人天 / 时间窗口 / 承诺人 / 确认日期）：

裁决路径（分歧类型 / 裁决人 / 裁决时限）：

再确认点：

M1 日期：____ 判断标准：____ 判定人：____

M2 日期：____ 判断标准：____ 判定人：____

退出条件（触发条件 / 触发动作 / 责任方 / 生效日期）：

3. 12 个月后的数据

改造后第 12 个月，几项关键指标的变化比预期更明显。立项周期中位数从 23 天降到 9 天，降幅 61%；立项后第 14 天资源到位率从 48% 提升到 82%；需求返工率从 34% 降到 13%；跨部门交付准时率从 41% 提升到 76%。

最有意思的一项变化是立项后 30 天的计划变更率，从 47% 降到 19%。这说明立项质量提升带来的最大收益不是”更快开始”，而是”计划第一次变得可信”。当计划可信，后续的资源协调、里程碑管理、向上汇报成本都会同步下降。

为了防止”压缩周期导致质量下降”的担忧，我还拉了一条 12 个月的月度趋势。可以看到立项周期一路下降的同时，返工率同步下降，两者并没有出现此消彼长的关系。这说明立项周期的长度和立项质量之间并不存在正相关，很多时候只是流程惯性。

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

同一个立项方法论，在不同规模的组织里落地方式完全不同。我的基本判断是：流程的复杂度应该和组织规模匹配，跨部门立项尤其如此，小组织抄大组织的流程，通常只会拖慢自己。

1. 50 人以下：靠人，别靠流程

在这个规模里，跨部门其实只是”跨几个人”，信息传递靠口头和群聊就能闭环。强行引入正式评审流程，收益低于成本。

你的重点应该是三件事：一页纸立项，哪怕只是写在共享文档里；把”不做会怎样”和”谁在哪天交什么”写清楚；每周一次 15 分钟的短会对齐。不要做复杂的审批链，也不要统计流程指标。

2. 100-500 人：靠模板 + 轻量工具

这是最需要方法论的区间。跨部门沟通成本开始显著上升，但组织还不具备强流程管控能力。我的建议是”一个模板 + 一张表 + 两个判断点”。

一个模板指的是立项一页纸；一张表指的是资源承诺表，必须有具体人名和人天；两个判断点指的是 M1 和 M2，只做继续/调整/停止的判断。工具层面，用项目平台把这三件事结构化下来即可，不要一开始就追求全流程覆盖。

3. 500 人以上或多事业部：靠机制 + 平台

到了这个规模，靠个人协调已经不可持续，必须把裁决路径、资源承诺、变更管理写进机制，并有平台承载执行记录。

这个阶段我建议额外做两件事：一是建立跨部门的资源日历，让各事业部的关键人力占用可见，避免”同一个专家被三个项目同时借用”；二是建立立项后评价闭环，把 M1/M2 的判断结果沉淀下来，作为下次立项的输入。

4. 强合规行业：靠留痕 + 审批链

如果所在行业有审计、监管或信息安全要求，立项必须留下完整痕迹：谁在什么时候基于什么材料批准了什么范围。这时候审批链不是负担，而是资产。

我的建议是在前面三个动作之外，增加”决策留痕”这一项：所有范围变更、资源调整、里程碑判断都必须有书面记录和确认人。在工具选择上，支持私有化部署与完整操作审计的能力会变成硬性要求，而不是加分项。

七、取舍：快、全、都满意，最多选两个

立项阶段最难的不是方法，而是取舍。下面四组取舍几乎每个项目负责人都会遇到，我把我的判断逻辑写出来，供你对照。

1. 速度 vs 完备性

我的选择是：宁可少写几页，也要把”谁在哪天交什么”写清楚。立项文档的完备性有一个明显的边际递减点，超过一页纸之后，增加的信息量对执行的影响迅速趋近于零，但它消耗的时间是线性增长的。

例外情况是强合规行业和涉及外部合同的立项，这两类场景的完备性价值很高，因为缺失条款会在后期变成实际损失。判断标准很简单：如果这份文档将来可能被第三方引用，就写全；如果只是内部对齐用，就写薄。

2. 共识 vs 决策

我的选择是决策优先。共识是奢侈品，决策是必需品。跨部门项目的失败往往不是因为有人反对，而是因为没人能拍板。

但要注意，决策不等于压制。我的做法是让每个部门在立项阶段有明确的”表达权”和”否决范围”，表达权指的是他可以在方案选择上提意见，否决范围指的是对他本部门资源投入的边界有发言权。给了这两项，即使最终决策不符合他的偏好，执行阻力也会小很多。

3. 标准化 vs 灵活性

我的选择是”字段标准化、判断灵活化”。也就是说，立项必须填的几个字段是固定的（价值、交付物、承诺人、裁决路径、退出条件），但每个判断怎么填、填多细，允许项目负责人自行决定。

完全放开会导致立项质量参差，完全标准化会变成形式主义。唯一不能灵活的是”具体人名”和”具体日期”这两项，这两个字段必须标准化到底，因为它们是后续所有管理动作的基础。

4. 采购 vs 自建

我的判断是：除非有非常特殊的合规需求或已有成熟内部平台，否则不要自建项目管理系统。自建的真实成本远高于预算表上的开发成本，后续的维护、迭代、权限管理、审计适配都是长期投入。

在采购侧，需要重点评估四项能力：是否支持自定义工作项以承载立项一页纸和资源承诺表；是否支持私有化部署以满足数据合规；是否支持从既有工具平滑迁移以降低切换成本；是否具备完整的操作审计与变更记录。这几项恰好也是在中大型组织里落地立项流程的关键支撑点。

八、常见问题

1. 立项一定要开正式评审会吗？

不一定，取决于干系人数量。我的经验阈值是 10 人。10 人以内，一次 40 分钟的短会加上书面材料分发就够；超过 10 人，必须提前发材料并做会前一对一预沟通，否则会议只会变成信息同步，无法产生决策。

超过 30 人时，正式评审会的功能应该降级为”宣贯 + 确认”，真正的决策收在会前的分层小组里完成。这是控制立项周期最有效的手段之一。

2. 如果某个部门始终不肯给具体承诺怎么办？

这是一个非常典型的信号，通常说明两件事之一：要么该部门确实没有资源，要么这个项目在对方优先级里排得太低。

两种情况都不应该靠”再开一次会”解决。我的做法是把问题显性化：在立项文档里标注”该部门资源承诺未确认，项目对应里程碑存在可行性风险”，然后把文档提交给裁决路径上的决策人。让风险被记录，比让风险被掩盖更有价值。

如果项目仍然要启动，那就把对应的里程碑节点和判断标准写进 M1/M2，让资源问题在第一个判断点被正式处理，而不是拖到开发中期。

3. 立项阶段要花多长时间才算合理？

我的经验值是项目总时长的 5%-10%。一个计划做 6 个月的项目，立项花 1-2 周比较合适。少于 5% 通常意味着关键问题没问清楚，超过 10% 则往往陷入了追求共识或文档完美的循环。

需要区分的是”纯立项时间”和”立项前的准备工作”。有些项目的价值论证本身需要做调研和数据验证，这段时间不应该算进立项周期，但它必须被单独计划和排期。

4. 项目做了一半发现立项时判断错了，怎么办？

这正是 M1/M2 存在的意义。如果你设置了这两个再确认点，那么”判断错了”会在一个低成本的时点被发现，处理方式也已经在立项文档里写好了。

如果没有设置，我建议立刻补一次”重新立项”评估：用同样的三层漏斗重新过一遍，重点看当前的实际资源到位率和已投入成本，然后明确做出继续、缩减范围或停止的决定。最糟的处理方式是维持现状但不做判断，因为那会同时消耗资源和信任。

5. 小团队需要资源承诺表这种”重”东西吗？

不需要表格，但需要表格里的信息。在 20 人以下的团队，你完全可以在群里发一句话：”这个项目需要张某在 3 月 4-22 日投入 12 人天，李某在 3 月 22 日前给出口径确认，可以吗？”获得明确回复，效果等同于一张正式表格。

关键不是形式，而是把”模糊的支持”变成”可以被引用的具体承诺”。这句话在项目卡住的时候能不能拿出来用，才是判断立项是否到位的唯一标准。

6. 立项文档应该由谁来写？

项目负责人写，但不能一个人闷头写。我的做法是自己先起草一页纸，然后逐个部门当面过一遍相关部分，边聊边改。这样写出来的文档，在评审会上的阻力会小得多，而且每个部门都在文档里看到自己的输入。

要避免的是让项目助理或 PMO 代写。立项文档的核心内容是承诺和判断，这些东西只有项目负责人自己才能谈下来，代写出来的文档一定缺少关键承诺。

7. 如果公司根本没有立项流程，我该从哪里开始？

从一页纸开始，不要从流程开始。先在你负责的下一个跨部门项目里，用立项一页纸把价值、交付物、承诺人、裁决路径、退出条件写清楚，跑完一个项目，然后再决定要不要把它变成组织流程。

我见过太多”先建流程再找项目”的失败案例，最后流程变成了一堆没人填的表单。真正有效的路径是：先做出一个成功样本，再复制样本。

九、总结与下一步

回到最开始那个被静默叫停的项目。如果当时有人问过三个问题，不做会怎样、谁在哪天交什么、什么情况下停，它大概率不会被拖到第 52 天。跨部门立项最大的误区，是把”开会、写文档、大家举手同意”当作立项完成，而实际上，这些只是立项的准备工作。

我在这篇文章里反复强调的独特观点其实只有一句：跨部门立项的产出不是一份文档，而是一组可以被引用的承诺。文档会被归档，承诺会在项目卡住的那一天被拿出来使用。判断立项是否成功，就看那天你有没有东西可以拿出来。

如果你想立刻开始，我建议按下面的顺序做，不要跳步。

1. 找出你手上下一个跨部门项目，在正式立项会之前，先自己回答”不做会怎样”，并写出带数字的后果和时间点。
2. 把现有立项模板砍到一页纸，但强制加上”具体承诺人”和”退出条件”两个字段。
3. 约每个参与部门做 20 分钟一对一沟通，逐条确认人名、人天、交付日期，并把结果写进资源承诺表。
4. 在立项文档里设定 M1 和 M2 两个再确认点，写明判断标准和判定人。
5. 选择一个项目平台把立项一页纸、资源承诺表和里程碑判断结构化下来，让承诺可追溯、变更可查证。

最后补一句经验：不要等组织把流程建好再开始。跨部门立项能力的提升，本质上来自项目负责人个体的一次次谈判实践，流程只是这种实践沉淀下来的结果。你先跑通一个项目，流程自然会跟着你走。