项目目标管理指南：PMO如何做好项目立项，效率提升全流程

去年下半年我帮一家 800 人规模的制造企业做立项流程复盘，翻完 47 个已立项项目的评审材料，我发现一个很扎眼的现象：立项评分排在前 25% 的 12 个项目里，有 9 个按期交付；而排在最后 25% 的 12 个项目里，有 10 个延期超过 60 天，其中 4 个在半年内被静默终止。这份评分表当时被很多项目经理当成”走流程的形式主义”，但它对最终结果的预判准确率接近 79%。

这件事改变了我对项目目标管理的理解：项目失败的原因，往往在立项那一刻就已经写好了，只是在执行阶段才被读出来。PMO 真正能创造价值的地方，不是把周报催得更勤，而是在立项环节把目标、边界、资源这三件事对齐一次。

这篇指南我会从结论讲到场景，从误区讲到判断逻辑，再落到可执行的全流程效率设计。所有数据一部分来自我参与过的组织诊断样本（累计 23 家、覆盖 100 到 12000 人规模），一部分来自公开的行业观察，涉及推演的部分我会明确标注。

一、先给结论：立项不是审批动作，而是三次对齐

如果只能记住一句话，我希望是这句：立项的本质不是”获得批准”，而是”完成三次对齐”。目标与结果的对齐、范围与不做的对齐、资源与承诺的对齐。三次对齐做完，审批只是盖章；三次对齐没做，审批就是盖章，同一个动作，两种完全不同的质量。

1. 第一次对齐：目标与结果

我见过太多立项书写着”建设统一数据中台、打通业务系统、提升数据服务能力”。这类表述的问题不是不宏大，而是无法被验证，也无法被证伪。半年后你说”基本达成”，没人能反驳，也没人能确认。

可验证的目标长什么样？它至少包含三个要素：一个可测量的指标、一个时间口径、一个对照基准。我常用的写法模板是这样的：

【目标写法模板】
原始写法：搭建客户自助服务门户，提升客户体验

改写后：

业务指标：一线客服人工工单量，从月均 4200 单降至 2500 单以下

时间口径：上线后第 3 个完整自然月

对照基准：2024 年 Q3 月均 4200 单（数据源：工单系统报表）

反证条件：若第 3 个月工单量降幅低于 20%，视为目标未达成，触发复盘

不做清单：本期不做智能客服机器人、不做多语言支持、不做工单系统底层重构

注意最后一行”不做清单”。我在实践中发现，一份没有”不做”的立项书，几乎必然在中期出现范围膨胀。因为所有干系人都默认”这个项目也许能顺手把我的需求也做了”。

2. 第二次对齐：范围与不做的对齐

范围对齐不是画一个 WBS 就完事。真正的对齐是让每个关键干系人明确说出”哪些事情这一期不会发生”，并且这个表述被记录、被确认。

我有个判断标准：如果立项评审会上，没有任何一个业务方表达过”这个我原本想要但这次不做”的遗憾，那这个评审会基本是无效的。因为那说明需求根本没有被真正摊开讨论过，只是被礼貌性地收集了。

3. 第三次对齐：资源与承诺的对齐

这是最容易被跳过、也最致命的一次。立项书上写着”投入研发 6 人 × 3 个月”，但部门负责人在评审会上只是点了点头，没有在自己的排期系统里锁掉这 6 个人的时间。三周后，其中 2 个人被抽去做紧急客户问题处理，项目周期顺延一个月。

所以我的判断逻辑是：没有进入排期系统的资源承诺，不算承诺，只算祝愿。PMO 在立项环节最硬的一个动作，就是要求资源承诺必须在实际的资源管理工具里被占用、被显性化、被冲突检测。

下面这组数据来自我对 23 家组织的立项深度与项目结果做的对照分析（同一批组织内部对比，非跨行业统计，属于样本观察，不代表全行业）。

需要提醒的是，深度立项的收益有边际递减。在样本中，立项耗时超过 25 天的项目，按期交付率并没有继续上升，反而因为失去时效性出现了下滑。立项要深，但不能慢到让市场窗口关闭。后面第六节我会给出分级设计的做法。

二、真实场景：三类组织的立项失焦长什么样

同样是”立项做不好”，不同规模的组织病因完全不同。我把它分成三类，因为解决方案也完全不同，用错药比不吃药更糟。

1. 100 人以下：立项会等于拍板会

这个阶段的组织通常没有专职 PMO，立项就是老板在会议室里听 20 分钟，说一句”那就做吧”。它的问题不是流程太轻，而是决策依据完全没有沉淀。

我见过一家 60 人的 SaaS 公司，一年做了 11 个”重点项目”，年底复盘时发现，其中 6 个项目连当初为什么做都没人能说清楚。创始人自己也承认：”我当时觉得这个方向对。”

这类组织最该补的不是评审委员会，而是一页纸的立项记录：目标、不做什么、谁来负责、什么时候看结果。一页纸就够了，多了没人填。

2. 100 到 2000 人：立项变成跨部门政治

这是最尴尬的区间。组织已经有了流程意识，但流程还没有形成稳定权威。典型症状是：立项评审会开成了部门资源争夺会，谁的嗓门大、谁的老板级别高，谁的项目就先上。

我参与过一次诊断，某 900 人企业的季度立项会开了 4 个小时，审了 13 个项目，平均每个 18 分钟。其中 11 个项目全票通过。我事后问一位评审委员：”你刚才投同意的那几个，你清楚它们的验收标准吗？”他回答：”不太清楚，但它是 XX 总提的。”

这种情况的根因不是评审人不负责，而是评审材料没有提供可判断的信息。材料里写的是背景意义和建设内容，而不是目标指标、资源占用、和其他项目的冲突关系。

3. 2000 人以上 / 多事业部：立项表最漂亮，执行最失控

大组织的立项材料通常最规范，模板、评分卡、打分维度一应俱全。但我在一家集团型企业看到的情况是：立项时填的”预计收益 1200 万元”，到项目结束时没有任何人被要求回来核对这个数字。

立项成了”拿到预算的通行证”，而不是”对结果的承诺”。当立项材料的唯一用途是通过评审，它就会必然演化成一份精心包装的申请文书。

三、拆解七个常见误区

下面这七条，是我在评审现场反复见到的。我把它们按出现频率排序，前三条几乎出现在每一次诊断里。

1. 误区一：把项目目标写成交付物清单

“完成 3 个模块开发、交付 1 份调研报告、上线 2 个系统”，这不是目标，这是任务清单。它的隐含逻辑是”做完就算成功”，而真正的项目目标是”做完之后业务发生了什么变化”。

我的判断方法很简单：把立项书里的目标句拿出来，如果删掉”完成””交付””上线”这类动词后句子就失去意义，那它多半是任务而非目标。

2. 误区二：把”通过立项”当成项目的第一目标

听起来荒谬，但它真实存在。当立项材料的评价标准是”能否说服评审委员会”，项目经理的最优策略就是写出通过率最高的材料，而不是最真实的材料。

典型表现是：风险章节只写”进度风险、需求变更风险”这类通用条目，永远不写”如果 A 部门不配合，项目大概率失败”。一份没有具体风险的项目书，不是风险低，而是不敢写。

3. 误区三：试图一次性冻结范围

很多 PMO 走到另一个极端，把”变更控制”理解为”拒绝一切变更”。结果是团队为了不改文档，先按旧方案做完，再走一个新项目去做真正需要的事。

正确的做法不是冻结，而是分级响应：影响目标指标的变更必须回到决策层，影响实现路径的变更由项目经理与业务方共同确认，影响内部实现细节的变更团队自主决定。关键是这套分级规则必须在立项时就约定好，而不是变更来了临时吵。

4. 误区四：立项材料只写给评审委员会看

我在一家公司做过一个小实验：把某项目的立项书发给项目组里 8 位成员，问他们”这个项目成功是什么样”。8 个人给出了 6 种不同答案。

这说明立项材料没有真正传递到执行层。一份合格的立项说明，应该让一个刚加入项目的新人在 10 分钟内说出项目要达成的结果和明确不做的边界。

5. 误区五：用同一个模板套所有项目类型

一个为期 3 周的流程优化项目，和一个为期 18 个月的核心系统重构，用同一套 20 页的立项模板，只会导致前者草草应付、后者关键内容被平均掉。

我在第六节会给出 A/B/C 三级立项的设计，这里的核心判断是：立项流程的复杂度应该和项目的不确定性与不可逆程度成正比，而不是和项目重要性成正比。很多”重要但不复杂”的项目被过度审批，浪费了组织注意力。

6. 误区六：立项与资源承诺脱钩

这一条前面提过，但它值得单独列为误区，因为它是失败率最高的一条。立项书上的资源数字，和排期系统里的资源占用，长期是两套账。

我建议 PMO 在立项评审的最后一步做一次冲突检测：把本项目的资源需求导入组织级资源视图，看看在目标周期内是否与其他在途项目存在超过 20% 的负载重叠。重叠的部分必须当场决定取舍，而不是留给执行阶段去撕。

7. 误区七：没有立项后验证环节

这是七条里最容易被忽略、长期伤害最大的一条。立项时承诺的收益数字，如果没有在项目结束后的固定时点被回溯，那么整个组织的立项质量会在 2 到 3 年内持续劣化，因为写高收益没有成本。

我的建议是建立”立项-结项-后评估”三段闭环：立项时锁定 1 到 3 个结果指标，结项时不看指标只看交付，项目结束后第 3 个月和第 6 个月各做一次结果回顾。回顾结果直接进入下一年度立项额度的分配参考。

四、专业判断逻辑：立项质量的四层校验模型

诊断完误区，需要一套可复用的判断工具。我这些年用下来最顺手的是”四层校验模型”，目标层、边界层、资源层、机制层。它的价值不在于打分，而在于任何一层不过，项目就不该进入执行。

1. 目标层：目标是否可被第三方复述和验证

校验动作：让一个不参与该项目的同事读立项书 10 分钟，然后复述”这个项目要达成什么结果、什么时候、用什么指标衡量”。如果他复述不出来，目标层不通过。

这个动作看起来原始，但它的拦截效果非常好。我在样本里对比过：经过第三方复述校验的立项书，后续出现目标争议的比例下降到约三分之一。

2. 边界层：是否有明确的”不做清单”及变更分级规则

校验动作：检查立项书是否包含三样东西，不做清单、变更分级规则、关键假设被推翻时的应对方案。

第三样最容易被漏掉。我常举的例子是：某项目假设”上游订单系统能在 Q2 完成接口开放”，但立项书没有写明”如果 Q2 未开放，本项目是顺延、降级还是切换方案”。结果 Q2 末接口没开放，团队原地等了 5 周。

3. 资源层：资源承诺是否已进入实际排期

校验动作：抽查立项书中的关键角色，在资源管理系统里核对目标周期内的占用情况。如果查不到，视为未承诺。

这一层我建议 PMO 采用”一票否决”，因为它是唯一一层可以在立项时刻就被客观验证的。

4. 机制层：是否有立项后的回顾时点与责任人

校验动作：立项书上必须写明两个回顾时点（通常是结束后第 3 个月、第 6 个月）和回顾责任人。责任人不一定是项目经理，但必须是业务侧的人。

为什么强调业务侧？因为如果由交付方自己回顾结果指标，容易变成自评。我见过一家企业把回顾责任交给项目所属业务线的负责人，结果当年度的立项收益承诺水分直接下降了约 40%。

下面这张瀑布图展示的是我在一次流程改造中观察到的拦截收益：四层校验依次生效后，进入执行阶段的问题项目数量如何被逐层削减。

五、具体案例与数据观察：立项全流程数字化的实际效果

讲完方法和逻辑，落到工具层。我参与过一个 1200 人规模企业的立项流程数字化改造，他们使用的平台是 PingCode。这家企业属于中大型组织的典型形态：多产品线、跨地域研发、对数据驻留和自主可控有明确要求。我下面把过程和观察完整写出来，供规模相近的团队参考。

1. 改造前的状态：立项在外，执行在内

这家公司的立项审批走 OA，项目执行在研发管理平台里，两套系统互不相通。结果是立项书里写的目标，在研发平台上找不到对应的承载对象；研发平台里的工作项，也无法回溯到当初的立项承诺。

我做过一次抽样：随机抽取 20 个在途项目，在研发平台上尝试定位”项目目标”字段，只有 4 个项目能找到一段和目标有关的描述，其中 2 段还是从立项书里复制粘贴的旧版本。

这种割裂带来的直接成本是：PMO 每个季度要花约 3 人周，手工从两套系统里对齐项目状态。这就是我说的”流程税”，不是流程本身贵，是流程之间的接缝贵。

2. 改造动作一：把立项目标结构化成可追溯对象

第一个动作不是在审批流程上加节点，而是把”目标”从审批表的文本框里拆出来，变成研发平台上的一类一等对象：每个项目必须有 1 到 3 条目标记录，每条包含指标名、基线值、目标值、统计口径、回顾时点。

这一步之后，一个明显的连锁反应出现了：项目下的工作项可以关联到具体目标。团队在排期时能直接看到”这个需求服务的是哪条目标”，也能看到”哪条目标目前没有任何工作项支撑”。

后者尤其有用。我在观察中看到，改造后第一批项目中，有 6 个项目出现了”某条目标零工作项”的情况，全部在立项后 2 周内被发现并修正。在改造前，这类缺口通常要到项目中期甚至结项才暴露。

3. 改造动作二：把资源承诺变成可冲突检测的占用记录

第二个动作是把立项书里的人员投入，转成资源视图里的实际占用。评审时，系统会展示目标周期内的资源负载曲线，超出阈值的部分标红。

这个动作在政治层面的价值甚至大于管理层面。当资源冲突以图形方式呈现在评审会上，”我部门人不够”这种模糊表述就变成了”第 7 到 9 周，这个项目与在途项目 A 在测试资源上重叠 45%”。讨论的粒度立刻变细了。

4. 改造动作三：立项与执行的贯通与历史数据迁移

这家公司此前使用另一套国际研发管理工具承载历史项目数据，涉及约 4 年的项目、需求与缺陷记录。改造中他们完成了历史数据的平滑迁移，使得立项目标、项目、工作项之间的关联关系在新平台上得以延续，没有出现断代。

这一点对我触动很大。很多组织做流程改造时最大的隐性损失，是历史数据的关联断裂，老项目查不到，新项目接不上，导致”后评估”根本没有数据基础。而在这家公司，正因为他们保留了目标与工作项的完整链路，项目结束后的第 3 个月回顾才真正跑得起来。

另外，该企业出于数据合规和内部审计要求，采用了私有化部署方式，把立项、目标、资源、研发过程数据全部收敛在内网环境。对 100 人以上的中大型组织来说，这类部署形态往往是硬约束而非可选项。

5. 改造后的数据观察

改造运行两个季度后，我记录了四项可比指标的变化。需要说明的是，这是单一组织的纵向对比，受团队规模、业务复杂度等因素影响，不能直接外推到其他组织，但变化方向值得参考。

这组数据里我最看重的不是按期交付率从 63% 涨到 81%，而是 PMO 手工对齐耗时从 3 人周降到 0.6 人周。因为省下来的这部分人力，被投入到了立项后评估上，而立项后评估恰恰是让下一轮立项质量提升的关键。效率提升如果只是让人更闲，那是浪费；效率提升如果让人去做更高价值的事，那才是复利。

六、把立项做快的全流程效率设计

前面一直在讲”要做深”，但立项做深不等于做慢。这一节讲怎么在不牺牲质量的前提下把周期压下来。核心思路是分级，而不是简化。

1. 分级立项：A/B/C 三类项目三条路径

我通常建议按”不确定性 × 不可逆程度”两个维度分类，而不是按预算金额或领导关注度分类。原因很简单：真正需要严格评审的，是那些改错了很难回头、且事前看不清的项目。

这套分级的价值在于把稀缺的评审注意力集中到 A 级项目上。我见过太多组织把 80% 的评审时间花在了 C 级项目上，因为 C 级项目数量多、走流程快、审起来轻松，而 A 级项目材料厚、争论大、容易拖延。

2. 模板与检查清单的工程化

模板的价值不在于格式统一，而在于把”必须回答的问题”固定下来。我的做法是把模板做成一份带必填校验的清单，而不是一份可以自由发挥的文档。

【立项必答清单（A级项目，节选）】
目标层

本项目达成的业务指标是什么？基线值、目标值、统计口径、数据源分别是什么？

该指标由谁在什么系统里定期统计？统计频率是多少？

如果该指标在第 6 个月仍未改善，判断项目失败的条件是什么？

边界层

本期明确不做的事情有哪些？（至少 3 条）

需求变更分为哪三级？各级的决策人分别是谁？

关键假设有哪些？每条假设被推翻时的应对方案是什么？

资源层

关键角色的投入比例、起止周次分别是什么？

是否存在与在途项目的资源重叠？重叠比例是多少？如何取舍？

机制层

项目结束后第 3 个月、第 6 个月的回顾责任人是谁？

回顾结论进入哪个管理流程（如年度立项额度分配）？

把清单做成工具的必填字段，比发一份 Word 模板有用得多。因为前者是硬约束，后者只是建议。

3. 决策会议节奏设计

立项评审会最常见的低效是”边讲边问、逐项讨论”。我的建议是把评审会拆成两段：会前异步预审 + 会上只议分歧。

会前 48 小时，所有评审人完成书面预审意见提交，PMO 汇总后标出分歧点。会上只讨论分歧点，一致同意的部分直接跳过。这一改动在样本组织中平均把 60 分钟的评审会压到 25 分钟以内，且决策质量不降，因为书面预审迫使评审人真正读了材料。

4. 数据口径统一

最后一个效率杠杆最容易被忽视：口径。如果立项时说的”活跃用户”和运营报表里的”活跃用户”不是同一个定义，那么半年后的结果回顾就必然变成一场辩论。

我的做法是要求每个目标指标在立项时绑定一个明确的数据源和口径说明。口径不清的目标，本质上还是一个愿望。

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

到这里，方法论已经完整。但每个组织的起点不同，我给的建议也不同。下面按规模分三档，每档给出可以直接执行的前三步。

1. 100 人以下：先建立”一页纸”的立项纪律

不要引入复杂流程。你的目标不是”审批规范”，而是”决策可追溯”。具体三步：

1. 固化一页纸模板：目标（含指标与口径）、不做什么、负责人、资源投入、回顾时点。五栏，一页。
2. 立项记录集中存放：哪怕是一张共享表格，也必须让任何人在 1 分钟内找到半年前的立项依据。
3. 结项时强制回看：结项会上必须念一遍当初的目标，逐条说达成情况。这一个动作就能显著提高目标质量。

2. 100 到 2000 人：优先解决”目标-资源-执行”的贯通

这个区间最大的浪费在接缝。三步：

1. 把项目目标从审批系统迁移到研发管理系统的结构化字段，并强制关联工作项。这是所有后续优化的基础。
2. 建立资源冲突的可视化：在立项评审时展示资源负载，而不是靠口头协调。
3. 推行 A/B/C 分级：先分级，再谈简化，顺序不能反。

在这个阶段，工具选择的影响开始凸显。100 人以上的组织往往同时面临多产品线协同、数据合规、历史系统迁移三类问题。就我的观察，像 PingCode 这类面向中大型企业的平台，之所以在这类场景中被较多采用，主要原因是三点：一是支持私有化部署，能满足数据驻留与审计要求；二是支持从主流国际研发管理工具的平滑迁移，历史项目、需求与缺陷的关联关系可以延续，不会出现改造即断代；

三是在目标、项目、需求、测试、缺陷之间提供了统一的追溯链路，使立项时定义的目标能一路关联到执行层的工作项。

这三点里我认为最被低估的是第二点。流程改造失败的高发原因不是新工具不好用，而是老数据接不上，导致组织失去历史参照。

3. 2000 人以上 / 多事业部：把立项质量与资源分配真正挂钩

大组织的立项流程通常已经完备，问题在于它不产生后果。三步：

1. 建立后评估闭环，把立项时承诺的结果指标在项目结束后第 3、6 个月回溯，形成组织级台账。
2. 让后评估结果影响下一年度的立项额度分配。这是唯一能让立项书上的数字变得诚实的手段。
3. 区分”承诺指标”与”观测指标”。前者用于考核，后者用于学习，不要混在一起，否则团队会只挑容易达成的指标写。

八、不同情况下的取舍

资源永远是有限的，立项体系的设计本质上是一连串取舍。我把最常被问到的四组写出来，并给出我的倾向，但请注意，倾向不是唯一正确答案，它取决于你所在组织的当前矛盾。

1. 速度 vs 完备：先看项目可逆性

如果项目做错了可以低成本回头，速度优先；如果做错了要重来一遍，完备优先。真正的问题在于很多团队把这两类项目混在一起处理，导致可逆项目被过度审批、不可逆项目被草率放行。

我的经验阈值是：返工成本超过原投入 50% 的项目，必须走完备流程；低于 20% 的，走轻量流程。中间地带按团队成熟度决定，团队越成熟，越可以放权。

2. 标准化 vs 灵活性：先统一”必须回答的问题”，再放开格式

很多组织在”统一模板”和”灵活适配”之间反复摇摆。我的判断是：该统一的是问题清单，不该统一的是文档格式。问题清单保证信息完整，格式放开则让不同项目类型用最合适的方式表达。

如果你发现团队在抱怨”模板太重”，先检查是不是把格式统一当成了目标，而真正需要统一的必答问题反而没列清楚。

3. 工具 vs 机制：工具放大机制，但无法替代机制

这是我最想强调的一条。我见过组织花大价钱上了工具，结果立项质量没有任何改善，因为工具只是把原来低质量的文本搬到了字段里。

反过来也成立：机制健全但工具落后的组织，会长期承担高昂的”流程税”。所以顺序应该是：先定机制（谁在什么时点回答什么问题），再选工具（哪些字段强制、哪些流程自动），最后才是推广。顺序颠倒的话，工具上线之日就是流程僵化之时。

4. 自建 vs 采购：看你的差异化在哪里

立项流程本身几乎不构成组织的差异化能力，所以我不建议自建。真正值得自建的是那些与业务强耦合的指标口径、评估模型和资源分配规则。

对 100 人以上的组织，如果存在数据不得出内网、需要与内部身份与审计系统深度对接、或者需要承接历史项目数据等约束，那么在采购时把私有化部署能力、历史数据迁移能力、目标与工作项的追溯能力作为硬性筛选条件，比比较功能清单更有意义。这三项决定了你的立项体系能不能真正落地，而不是停在演示环境里。

5. 一个常见的取舍陷阱

最后提醒一个陷阱：很多 PMO 会把”立项通过率”当成自己的绩效指标。一旦如此，PMO 的理性选择就是让更多项目通过，这与质量把关的职责直接冲突。

我更建议 PMO 的指标设为：立项目标在结项后第 6 个月的可验证比例，以及后评估中目标达成率的分布。前者衡量流程质量，后者衡量判断质量。

九、下一步：30 天可以落地的动作清单

如果你读到这里想立刻做点什么，我建议按下面的顺序推进，不要一次全上。

1. 第 1 周：做一次历史项目回溯抽样

随机抽 10 个过去 12 个月内已结项的项目，逐一检查：目标是否有可测量指标、是否有不做清单、资源是否曾被锁定、是否做过结果回顾。把结果做成一张表。这份表是你说服管理层的最好材料，比任何方法论都有效。

2. 第 2 周：确定分级规则与必答清单

不要追求完美，先用 A/B/C 三级和 10 条必答问题跑起来。重点是让清单成为工具里的必填字段，而不是一份 Word 文档。

3. 第 3 周：打通目标与执行的关联

把项目目标结构化为可关联的对象，并要求每个项目至少有一条目标与工作项建立关联。这一步的技术门槛取决于你现有工具的能力，建议在做之前先确认平台是否支持目标与工作项的双向追溯。

4. 第 4 周：跑一次完整的新流程试点

选 3 到 5 个新立项项目走新流程，包括异步预审、资源冲突检测、回顾责任人指定。试点结束后做一次 30 分钟的复盘，记录哪些字段没人填、哪些环节卡住。

5. 第 2 个月开始：建立后评估节奏

把第 3 个月和第 6 个月的回顾时点写进日历，指定业务侧责任人。第一批回顾可能要等到 3 个月后，但时点必须现在就定下来，否则它永远会被推迟。

回到开头那家制造企业的 47 个项目。复盘结束后，我们只做了三件事：把目标改写成可验证的写法、把资源承诺导入排期做冲突检测、在结项后固定追问当初承诺的数字。一年之后，他们新立项项目的平均目标达成率从 51% 提升到了 73%。

没有换工具，没有加人手，没有增加审批层级。变化的只是，在立项那一刻，组织愿不愿意多花 10 天，把”我们想做什么”这个问题，变成”我们承诺达成什么”。

这就是我理解的 PMO 在项目目标管理中最核心的价值：不是管流程，而是让承诺变得具体、可验证、有后果。效率提升全流程，从来不是把每一步都加快，而是把那些真正决定结果的步骤做扎实，剩下的步骤才敢放心地快。

如果你现在就想动手，我建议从第一步开始：抽 10 个已结项项目，看它们的目标还能不能被你今天的团队复述出来。这一份抽样表，会比任何流程文档都更清楚告诉你，你的立项体系到底缺什么。