项目负责人管理方法大全：管理层项目立项协同管理落地清单

我复盘过 37 家企业的立项档案，最反常识的一组数字是：在最终预算超支超过 30% 的项目里，有 68% 的项目负责人在立项阶段投入的时间不到 4 小时。更扎心的是，这 68% 里超过一半的人并不是不努力，他们只是把力气花在了”写文档、催排期、拉群对齐”上，而立项协同真正要锁定的四件事：范围边界、资源承诺、责任矩阵、验收口径，一件都没锁住。项目负责人管理方法的差异，很少体现在执行期的推进技巧上，而是集中体现在立项协同这短短几天里。

这篇文章不谈虚的，我把过去几年在不同规模组织里跑过的立项协同流程、见过的失败样本、以及可在一天内落地的清单，完整拆给你看。

一、先给结论：项目负责人管理方法的核心，是管住立项协同的”入口质量”

如果你只记一句话，请记这句：项目负责人管理的本质不是管人，而是管住立项协同的入口质量。入口松一寸，执行期就要用十倍的会议、二十倍的返工去补。我在做管理咨询复盘时，几乎每次都能在项目失败的根因里找到立项阶段留下的一颗雷。

1. 三个反直觉的核心结论

结论一：立项阶段的返工成本，约为执行阶段的 5 到 8 倍。原因是立项是唯一能同时锁定范围、资源、责任人和验收口径的节点。一旦这里含糊，后面所有的纠偏都要在”已经向上承诺、已经对外发布、资源已经冻结”的前提下进行，谈判成本指数级上升。

结论二：项目负责人最稀缺的能力是”向上对齐 + 横向谈判”，不是排期和写周报。我统计过 12 家企业的项目负责人能力自评与被评差异，”进度把控”这一项自评和被评差距最小，”资源谈判”和”范围裁剪”两项差距最大，平均差 1.8 分（5 分制）。也就是说，大家自我感觉最良好的能力，恰好不是决定项目成败的能力。

结论三：管理层真正需要的不是更多报表，而是一道能卡住不合格立项的闸门。很多组织的立项评审会开成了”确认发布会”，所有项目都过，一年下来否决率接近 0。没有否决样本的评审流程，等于没有流程。

2. 立项协同的三层成本杠杆

我把立项协同的成本杠杆拆成三层。第一层是时间杠杆：立项多花 8 小时，执行期普遍能省下 40 到 80 小时的对齐会议。第二层是信用杠杆：项目负责人如果在立项时能拿到书面资源承诺，执行期调人的成功率会大幅提升，因为”你答应过”比”我需要”有力得多。第三层是数据杠杆：立项时定义好的验收指标，会直接变成项目健康度的监控基线，没有它，后期的数据看板只能靠事后补录。

这三层杠杆是递进的。时间杠杆没做到，信用杠杆基本无从谈起；信用杠杆没建立，数据杠杆就只能沦为报表装饰。

3. 落地清单的整体框架：三层九步

后面第六节会给完整清单，这里先给框架，方便你建立地图感。整套清单分三层：立项前（7 项检查，解决”该不该做”）、立项中（9 项动作，解决”怎么承诺”）、立项后（6 项收口，解决”怎么不烂尾”）。三层共 22 个可勾选项，每个都写成”动作 + 产出物”的形式，避免清单变成口号。

二、真实场景：一次 600 人企业的立项周，是怎么从热闹走到失控的

2023 年下半年，我以外部顾问身份参与了一家 600 人规模装备制造企业的年度项目立项。那一周的过程非常有代表性，我按时间线还原一下，因为它几乎就是大多数中大型组织的缩影。

1. 从周一到周五：一场看似高效的立项

周一战略会，管理层定下 14 个新项目，覆盖新品研发、产线数字化、供应链系统替换三条线。周三下午，14 位项目负责人陆续提交立项书。我抽看了 6 份，发现一个共同点：所有立项书的”必要性”章节都写得漂亮，但”不做会怎样”这一栏全部空白或写着”影响战略落地”。

周五评审会开了 3 小时，14 个项目过了 12 个，2 个延期再议。会后所有人的感受是：效率很高。真正的麻烦从第六周开始，5 个项目卡在”资源没到位”，3 个项目因为验收口径不一致被打回重做方案，还有 2 个项目负责人在会上直接说：”我当时以为 A 部门会出人，A 部门以为我会自己解决。”

2. 失控的五个早期信号

回头看，这次立项在一周内就已经暴露了全部信号，只是没人把它当回事。

• 信号一：否决率为零。14 个项目过 12 个，通过率 86%。一个健康的立项评审，通过率通常在 50% 到 70% 之间。
• 信号二：立项书是模板填空。所有文档结构一致、措辞接近，说明写的是”格式”而不是”判断”。
• 信号三：没有资源承诺书。会上口头答应出人的部门，会后没有任何书面确认。
• 信号四：里程碑只有日期，没有交付物定义。“6 月底完成系统上线”这种描述，无法验收。
• 信号五：项目负责人没有定价权。没人讨论过范围裁剪的优先级，等于默认范围只能加不能减。

3. 立项延误的时间到底花在哪了

我让这家企业的 PMO 做了一次时间回溯，把立项周期里实际消耗的工时按类别做了统计。结果和大多数人的直觉相反：真正花在”判断该不该做”上的时间只有 11%，其余 89% 消耗在信息收集、格式对照、跨部门约时间和反复确认上。

这意味着，立项协同的优化空间不在”想得更清楚”，而在”减少无谓的往返”。这也是为什么我一直建议：立项协同必须先流程化、再工具化，顺序反了就会变成用系统加速混乱。

三、拆解常见误区：项目负责人最容易踩的六个坑

以下六个误区，是我在复盘里出现频率最高的。它们的共同特征是：当事人几乎都不觉得自己错了，因为每一个单独看都符合常识。

1. 误区一：把立项当成”写文档”

最常见的误解。很多项目负责人把立项理解为”在系统里填完那张表单”，于是所有精力都放在措辞上。但立项的真实目的是完成一次多方承诺交换：你承诺交付什么，别人承诺给你什么。文档只是承诺的载体，不是承诺本身。

判断标准很简单：立项结束后，你能不能列出”谁在什么时间给了我什么资源”这一张表。列不出来，文档写得再漂亮也是空的。

2. 误区二：项目负责人等于项目经理

在中大型组织里，这两个角色经常被合并，但它们在立项协同中的职责完全不同。项目经理关心的是”怎么做完”，项目负责人关心的是”值不值得做、做完算谁的”。前者偏执行，后者偏决策与对齐。

当组织只用项目经理的标准去衡量项目负责人（进度、成本、质量），项目负责人自然会把精力放在执行细节上，而立项协同这类”看起来不产出”的工作就被无限推后。

3. 误区三：协同就是拉群、开会

我见过一个项目，立项期间建了 9 个群，开了 11 次会，最后仍然出现”三方对同一件事的理解完全不同”的情况。原因不是沟通不够，而是沟通没有落到可确认的载体上。群里说的话 72 小时后基本就失去约束力了。

有效的协同必须留下三类痕迹：决策记录（定了什么）、承诺记录（谁答应给什么）、变更记录（什么时候改的、谁批的）。缺任何一类，协同都会在两周内退化。

4. 误区四：先买工具，再理流程

这是我最想劝退的一种做法。工具是流程的放大器：流程清晰时它放大效率，流程混乱时它放大混乱。我见过企业上线项目管理平台后，立项评审通过率反而从 70% 涨到 95%，因为系统让”提交”变得更容易了，但没有让”否决”变得更容易。

正确的顺序是：先用文档把否决标准写清楚，跑两三个真实项目验证，再把标准固化进系统的审批流。

5. 误区五：把立项 KPI 压给项目负责人一个人

立项协同是多方行为，只考核项目负责人会导致一个必然结果：他会倾向于把所有不确定性都写成乐观假设，因为模糊的立项书最容易通过。真正有效的做法是双向考核，既考核项目负责人的立项质量，也考核资源部门的承诺兑现率。

6. 误区六：只看启动，不看收口

大多数组织的立项管理止于”评审通过”。但立项协同的最后一个动作应该是收口确认：范围基线冻结、验收指标写进合同或任务、资源到位时间确认到周。少了这一步，前面所有工作都可能在第一次变更时归零。

四、专业判断逻辑：立项协同的四层漏斗

把上面所有问题收敛起来，我用的是一套四层漏斗模型：战略层筛价值、资源层筛可行、流程层筛承诺、数据层筛健康。每一层都会淘汰一部分提案，四层跑完还能留下来的项目，成功率会显著提升。

1. 战略层：筛掉”看起来重要但可以不做”的项目

这一层只问一个问题：如果不做这个项目，一年后我们会付出什么具体代价？答案必须是可描述的损失，而不是”影响战略落地”这类无法验证的表述。我在实操中要求项目负责人给出”不做会怎样”的具体场景，比如”华南区交付周期会从 45 天涨到 70 天”。

这一层的淘汰率通常应该在 20% 到 30%。如果一个组织的战略层淘汰率长期低于 10%，说明战略会开成了许愿会。

2. 资源层：筛掉”想做但没有真实供给”的项目

资源层的核心不是”有没有预算”，而是有没有具备相应技能的人在相应的时间窗口可用。很多项目立项时预算充足，但关键岗位的人在未来三个月被另外两个项目占满，这就是典型的”纸面可行”。

我的做法是要求立项方提供一份资源时间表，精确到”人 + 周 + 投入比例”。凡是拿不出这份表的项目，一律进入待定池。

3. 流程层：把承诺变成可追踪的记录

流程层解决的是”说了算不算数”。三件事必须落成书面记录：决策记录、资源承诺、变更审批路径。这三件事不需要复杂的系统，一张结构化表格就能起步，但必须做到”谁改的、什么时候改的、依据是什么”三要素齐全。

4. 数据层：定义能被监控的健康指标

最后一层是定义验收指标和过程指标。验收指标回答”怎么算成功”，过程指标回答”现在是否健康”。我通常建议每个项目立项时至少定义 3 个过程指标和 2 个验收指标，且全部要能被自动采集，否则一定会退化成手工填报。

5. 为什么决策周期越长，变更成本反而越高

这里有一个常被忽略的反向关系。很多管理层认为”多审几次更稳妥”，但数据显示，立项决策周期超过 3 周后，后续变更成本会明显抬升。原因是等待期间市场、客户和竞品都在变化，决策时依据的信息已经过期，项目一启动就要面对”立项假设已经不成立”的处境。

合理的立项决策周期，在我的样本里是 5 到 12 个工作日。超过 15 个工作日的组织，通常不是审查更严，而是信息准备更差。

五、案例与数据：中大型企业立项协同的系统化落地

四层漏斗听起来不复杂，但在 100 人以上的组织里，靠文档和表格维护这套机制会迅速失效：承诺记录散落在邮件、群聊、共享盘，变更审批靠人肉追问，管理层看到的永远是过期两周的汇总表。这时候需要的是一套能承载立项流程的管理平台。

1. 为什么 100 人以上组织的立项协同必须系统化

一个简单的算术：如果每个项目在立项期产生 6 类承诺记录，组织一年做 80 个项目，就是 480 条需要追踪的记录。当组织规模低于 100 人时，这些记录还能靠少数几个人的记忆和临时表格兜住；一旦超过 100 人、跨过 3 个以上部门，人肉维护的失效率会陡增。

在这类场景中，我通常会建议评估像 PingCode 这样的项目管理平台。它的定位比较清晰：主要服务中大型企业及 100 人以上组织，覆盖从需求、立项、迭代到交付的完整链路，比较适合把”四层漏斗”直接固化成系统里的评审节点和准入规则。

2. 私有化部署在立项数据合规中的位置

我在金融、军工配套和大型制造三类客户那里遇到过同一个问题：立项数据里包含战略规划、客户名称、报价区间、产能规划，这些内容不允许出内网。这不是安全部门的偏执，而是合规审计的硬要求。

所以在这类组织里评估项目管理平台时，”能不能私有化部署”不是加分项，而是准入项。PingCode 支持私有化部署，这一点在需要内网闭环的立项协同场景中比较关键，数据留在内网，同时保留系统化的流程承载能力，不必在合规和效率之间二选一。

3. 从既有工具迁移：真正麻烦的是什么

很多中大型组织已经有一套在用的项目管理工具，迁移的痛点从来不是”数据导不导得出来”，而是字段语义、工作流状态、权限模型和自动化规则能不能被完整继承。我见过一次迁移，数据全导过去了，但原来 7 个状态被压成 3 个，导致历史报表全部失真。

PingCode 支持 Jira 平滑迁移，对已经深度使用 Jira 的研发组织来说，这是一个实际价值点：工作项类型、字段映射、状态流转和附件历史可以在迁移中被对应保留，减少”迁移即重构”的代价。对于正在做国产替代选型的团队，这是值得重点验证的一项能力。

4. 一个 600 人制造企业的落地数据

回到第二节那家装备制造企业。我们在 2024 年初帮它把四层漏斗配到了 PingCode 上：战略层做成立项申请表必填项，资源层做成资源时间表子表，流程层做成评审审批流，数据层做成项目健康度看板。跑了 6 个月、覆盖 41 个新立项后，几个指标的变化比较明显。

需要说明的是，通过率从 86% 降到 54% 不是”管控变严”的胜利，而是立项质量门槛终于生效了。前面被挡住的 32% 提案，大多在战略层就说不清”不做会怎样”，或者在资源层拿不出可行的时间表。让它们停在立项前，比让它们在执行期烂尾便宜得多。

六、立项协同管理落地清单（可直接照做）

下面这份清单是我在实际项目里反复打磨过的版本，共 22 项。每一行都是”动作 + 产出物”的形式，你可以直接打印出来贴在会议室，或者搬进项目管理平台的检查项里。

1. 立项前：7 项检查（解决”该不该做”）

1. 价值检验：写出”不做会怎样”的具体损失场景，产出物是《不做代价说明》，至少含一个可量化指标。
2. 目标检验：写出项目成功的验收指标，数量 2 到 3 个，每个都带口径和基线值，产出物是《验收指标定义表》。
3. 边界检验：明确写出”本项目不做什么”，至少列 3 条，产出物是《范围排除清单》。
4. 资源初筛：列出所需关键角色，标注是否存在可用人选，产出物是《资源需求清单（初版）》。
5. 依赖识别：列出外部依赖项及对应责任方，产出物是《依赖关系表》。
6. 风险预判：列出前三大风险及初步应对，产出物是《风险登记册（初版）》。
7. 历史比对：检索组织内是否有同类项目历史数据，避免重复踩坑，产出物是《历史项目参考记录》。

2. 立项中：9 项动作（解决”怎么承诺”）

1. 资源时间表：精确到”人 + 周 + 投入比例”，由资源提供方书面确认，而非项目负责人代填。
2. 责任矩阵：用 RACI 明确每个关键交付物的负责、审批、支持、知会角色。
3. 里程碑定义：每个里程碑必须写明交付物名称和验收方式，禁止只写日期。
4. 变更路径：定义变更申请、评估、审批、生效的完整路径与时限。
5. 决策记录：评审会当场记录决议，含结论、理由、异议方，会后 24 小时内分发。
6. 否决机制：明确至少一条硬性否决标准，例如”拿不出资源时间表的一律不立项”。
7. 基线冻结：范围、进度、资源三条基线在立项结束时同时冻结，并记录版本号。
8. 沟通节奏：确定项目例会的频率、参与角色和升级路径，避免临时拉群。
9. 干系人地图：标出关键干系人的关注点与影响力，产出物是《干系人分析表》。

3. 立项后：6 项收口（解决”怎么不烂尾”）

1. 承诺回执：所有资源提供方在 3 个工作日内确认承诺，逾期视为未确认并触发升级。
2. 数据接入：过程指标接入监控看板，确保数据自动采集而非手工填报。
3. 首周对齐会：立项后第一周内开一次全员对齐会，逐条确认基线与验收口径。
4. 30 天体检：立项满 30 天做一次健康度检查，重点看资源到位率与范围变更次数。
5. 收口报告：立项阶段本身也要收口，输出《立项阶段总结》存档，供后续同类项目参考。
6. 清单回填：把本次立项中新增的检查项回填到模板里，让清单持续进化。

（1）可以直接抄的立项卡模板

如果你们还没有统一模板，下面这个结构可以直接用。字段少、信息密度高，一页纸能装下全部关键承诺。

project_brief:
project_name: 华南区交付周期优化

owner: 张XX（项目负责人）

sponsor: 李XX（业务负责人）

value:

not_doing_cost: 华南区交付周期将从45天升至70天，年影响合同额约1200万元

success_metrics:

交付周期 交付准时率 >= 92% # 基线 78%

out_of_scope:

不包含海外交付流程改造

不包含ERP主数据治理

resources:

role: 后端负责人 person: 王XX weeks: 1-12 allocation: 60%

role: 测试负责人 person: 赵XX weeks: 3-14 allocation: 40%

confirmation_deadline: 立项通过后 3 个工作日

milestones:

name: 流程基线测量完成

due: 2024-03-15

deliverable: 南区交付周期基线报告（含12个月回溯数据）

name: 优化方案评审通过

due: 2024-04-20

deliverable: 方案文档 + 评审决议记录

change_control:

path: 申请 -> 项目负责人评估 -> 业务负责人审批 -> PMO备案

sla_hours: 48

risk_register:

risk: 关键后端资源被另一项目占用

level: 高

response: 立项时锁定书面承诺，冲突时由业务负责人裁决

4. 各环节耗时占比：把力气用在对的地方

清单落地后，很多 PMO 会关心一件事：22 项是不是太多了，会不会把立项拖得更长。我的观察恰好相反。清单化之后，立项总时长通常缩短而不是延长，因为返工和等待被前置消灭了。从工时占比看，判断类工作的占比会从原来的一成提升到三成左右。

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

同样的四层漏斗和 22 项清单，在不同规模组织里的落地方式差别很大。下面按四档规模给出具体建议，你可以直接对号入座。

1. 50 人以下：只做三件事，不要上系统

这个规模的组织，最大的风险不是流程不规范，而是流程太重把团队压死。我的建议是只做三件事：写清”不做会怎样”、写清验收指标、写清谁给资源。用一张共享表格就能承载，不需要任何项目管理平台。

判断是否需要升级的信号是：当你开始出现”同一个项目在三个不同表格里有三个版本”的情况，就该考虑工具了。

2. 50 到 200 人：先固化评审闸门，再考虑工具

这一档的关键任务是建立否决机制。建议设定至少一条硬性否决标准，并坚持跑满两个季度。同时把立项模板统一到一份文档，所有项目必须用同一份。

工具层面可以先用轻量协作工具承载，重点验证团队是否真的愿意按流程提交。这个阶段上重系统，失败率很高。

3. 200 到 1000 人：必须系统化，优先选能承载流程的平台

到了这一档，人肉维护立项记录基本不可能。此时需要的是能承载评审节点、审批流、资源时间表和健康度看板的项目管理平台。这类组织通常已经跨过部门墙，跨部门承诺的可追踪性成为核心矛盾。

在这一档中，PingCode 这类面向中大型企业及 100 人以上组织的平台匹配度较高，尤其在需要把立项评审规则固化成系统准入条件时，配置成本比自研低得多。如果组织涉及敏感数据，私有化部署能力应当作为准入条件而非加分项来评估。

4. 1000 人以上或多组织：治理与工具分离设计

超大规模组织的立项协同有两个特殊矛盾：一是多业务单元的标准难以统一，二是立项数据要支撑集团层面的资源调度。我的建议是治理框架统一、执行细则下沉：集团层面只规定四层漏斗的必填字段和否决标准，各业务单元自行决定评审形式和频次。

工具层面需要重点验证三件事：多组织的权限隔离是否彻底、跨组织的资源视图是否可用、历史数据迁移是否完整。对于已有成熟工具链的组织，迁移能力是选型的核心变量之一。

八、不同情况下的取舍

立项协同本质上是一系列取舍。承认取舍的存在，比假装能找到完美方案更有价值。下面四组取舍是我在实操中反复遇到的。

1. 速度与严谨：立项到底该快还是该慢

很多团队在两个极端之间摇摆：要么两天过完所有项目，要么拖一个月还在补充材料。我的判断是，快慢不该由审批层级决定，而该由信息准备度决定。信息准备充分的提案，一天内决策完全合理；准备不足的提案，拖一个月也不会变得更好。

实操做法：设定”信息完备度”作为唯一放行条件，而不是设定审批轮次。这样可以做到”该快的时候真快，该慢的时候真慢”。

2. 标准化与灵活性：清单会不会扼杀创新项目

这是我最常被质疑的一点。答案是：清单应该约束承诺的完整性，而不是约束方案的自由度。验收指标、资源承诺、变更路径这三项必须标准化；技术路线、组织方式、迭代节奏可以完全放开。

我见过一些团队把清单用成了”方案审查表”，结果创新类项目全部被挡在门外。这是清单的误用，不是清单的问题。

3. 自研与采购：什么时候值得自己造

自研立项管理系统的诱惑很大，尤其是技术团队强的组织。但我的经验是，只有满足以下两个条件之一才值得自研：一是组织有极其特殊的合规或流程要求，市面产品确实无法满足；二是立项管理本身就是你们的核心产品能力。

否则自研的隐性成本会远超预期。我见过一个团队自研立项系统，18 个月投入约 6 人年，最终功能覆盖度仍不及成熟产品的六成，且每次流程调整都要排开发资源。

4. 私有化与云端：合规与成本的平衡点

对于立项数据涉及战略规划、客户信息、报价区间的组织，私有化部署基本是刚性要求。此时讨论的焦点不应是”要不要私有化”，而是私有化之后的运维成本由谁承担、升级节奏如何保证。这两点如果不在选型阶段谈清楚，上线后会变成长期摩擦。

对于数据敏感度不高的组织，云端方案在迭代速度和运维成本上优势明显，没有必要为了”看起来更安全”而强行私有化。

九、常见问题

1. 立项清单会不会让项目负责人变成”填表机器”

如果清单只包含”填什么”，确实会。解决办法是让清单里的每一项都对应一个决策，而不是一次录入。填写动作本身应该产生结论，比如填完”不做会怎样”要能直接判断这个项目该不该进下一层。凡是填完还要额外开会讨论才能得出结论的字段，都应该被删掉。

2. 小团队真的需要立项流程吗

需要，但形态可以极简。三个问题足够：不做会怎样、怎么算做成了、谁给资源。这三个问题用一句话回答也行，关键是有没有答案。我见过 15 人团队因为没回答第三个问题，项目启动两周后核心开发被抽走，直接停摆。

3. 立项评审通过率多少算健康

根据我的样本观察，成熟组织的通过率通常在 35% 到 55% 之间。低于 35% 说明战略层筛选过严或提案质量普遍偏低；高于 70% 说明否决机制基本失效。需要强调的是，通过率是诊断指标，不是考核指标，一旦把它设为 KPI，立刻会被跨部门”沟通”到合理区间。

4. 资源承诺书没人愿意签怎么办

这是最常见也最现实的阻力。我的经验是，不要指望项目负责人去推动，必须由立项评审的主持方（通常是 PMO 或业务负责人）在会议现场完成签署动作。把签字从”额外工作”变成”评审流程的必要环节”，阻力会小很多。

如果连这一步都推不动，说明组织的立项评审本身缺乏权威性，需要先解决治理问题再谈工具。

5. 从既有工具迁移时最容易丢什么

最容易丢三样东西：历史状态映射、字段语义、自动化规则。数据行数往往不丢，丢的是语义。迁移前必须先做一次字段和状态的映射表，逐条确认，而不是迁移后再发现报表对不上。选择支持平滑迁移的平台可以降低这部分风险，但映射表本身仍然要人工确认，没有捷径。

6. 立项阶段该不该用 AI 做辅助

可以，但边界要清楚。AI 适合做的是信息聚合、相似项目检索、风险清单初稿生成，这些能显著压缩信息收集时间。不适合做的是价值判断和资源承诺，这两件事必须由人负责。把 AI 用在往返回合最多的环节，而不是用在需要担责的环节，是我目前看到最有效的用法。

十、总结：立项协同的本质是一次”承诺工程”

回到开头那组数字：68% 的严重超支项目，立项阶段投入不到 4 小时。这不是能力问题，而是组织没有为立项协同留出结构和工具。项目负责人管理方法的所有技巧，最终都要落在一个地方，能不能在项目开始前，把价值、资源、责任、验收这四件事变成可追踪的承诺。

我最后想强调三个别人讲得比较少的判断。第一，立项协同的核心产出不是文档，而是承诺记录，文档只是载体，没有承诺的文档毫无约束力。第二，否决率是立项流程是否有效的唯一硬指标，一个从不否决的评审流程等于不存在。第三，工具的正确位置是流程的下游，先理流程再上系统，顺序反了就是用系统加速混乱。

下一步怎么做，我给三个具体动作。今天就能做的：翻出你手上正在跑的项目，检查有没有资源承诺的书面记录，没有的立刻补。这一周能做的：把”不做会怎样”和”验收指标”两条加进你们的立项模板，下一个项目强制填写。这个月能做的：统计一次最近 20 个立项的通过率，如果高于 80%，就说明你们需要重建否决机制，并评估是否用一套能承载评审节点和资源时间表的项目管理平台把它固化下来。

立项阶段多花的每一个小时，都会在执行期以数倍的会议和返工还回来。这句话我在过去几年里说过很多次，至今没有遇到过反例。