实施计划落地方案：企业管理者开展项目规划的数据分析案例解析

我在 2022 年到 2025 年之间，以外部顾问身份跟过二十多个企业级项目的规划会和复盘会，行业覆盖装备制造、连锁零售、SaaS 和金融后台运营。这些项目里有一个反复出现的规律：凡是最后延期超过 50%、或者勉强上线却没人用的，问题几乎都能追溯到规划阶段，不是执行团队不努力，而是计划本身缺了让执行"可判断"的数据基础。这篇文章不讲项目管理理论，只回答一个具体问题：企业管理者在制定实施计划时，到底该拿数据分析做什么、做到什么颗粒度算够、以及在不同约束下该怎么取舍。

一、先给结论：落不了地的计划，问题在规划阶段就埋好了

大多数管理者对"落地失败"的归因是执行不力。我复盘过二十多个项目后发现，这个归因在七成情况下是错的。真正的分水岭出现在规划阶段：计划里有没有基线、有没有统一口径、有没有预设的决策规则，直接决定了这个计划能不能被追踪和调整。

1. 一个粗糙但稳定的判断

我给自己总结了一个不太严谨、但实战中命中率很高的判断标准：如果一个实施计划里，超过一半的关键节点无法用数字描述"是否达成"，这个计划的延期概率会显著上升。这不是统计结论，是我在二十多个项目复盘里反复观察到的现象，样本有限，但它帮我提前识别出了不少高风险计划。

这个判断背后的逻辑很朴素。当节点只有"完成系统对接""推进流程优化"这类描述时，项目经理在周会上无法证明自己完成了，管理者也无法证明他没完成。争议产生的那一刻，执行就已经停摆了。

2. 三个缺口：基线、口径、决策规则

我把规划阶段最常见的缺失归纳成三个缺口，它们出现的顺序通常是固定的，危害也是叠加的。

• 基线缺口：不知道现在处于什么水平，所以"提升 30%"这个目标既无法验证，也无法拆解。没有基线的目标，本质是一句口号。
• 口径缺口：同一个指标在不同部门算法不同。销售的"有效线索"和市场部的"有效线索"差了三层过滤条件，会议就变成了对数据的争论。
• 决策规则缺口：计划里写的是"按进度推进"，但没写什么情况下要暂停、什么情况下要转向、谁来拍板。等到问题暴露时，决策成本已经高到没人愿意拍板。

这三个缺口不是理论推演，而是我在复盘会上最常听到的三句话的根源，"数据不准""口径不一样""这个我们当时也没想到"。

3. 先做一次自检：你的计划缺在哪一层

在往下读之前，建议你拿手头正在推进的一个项目，按下面六个维度打个分（1 分最低，5 分最高）。这六个维度是我从复盘经验里提炼的，不是标准模型，但用来定位问题足够。

二、背景与真实场景：三种看起来不同、本质相同的困局

抽象讲缺口容易变成正确的废话。我把这几年印象最深的三个场景写出来，它们分别对应中小企业、中型集团和中大型企业的典型状态。为保护隐私，公司名和具体业务做了替换，数字是脱敏后的近似值。

1. 场景一：季度会开了三次，进度表更新了五版，交付仍然延期

一家做工业配件的企业，员工约 400 人，2023 年启动 ERP 与生产管理系统替换项目，原计划 6 个月上线。我是在第 9 个月介入复盘的。

翻他们的周报，前 12 周都写着"进度正常"。但把三份不同部门提交的进度表叠在一起看，同一个"基础数据清洗"任务，IT 部门标的是 100% 完成，生产部门标的是 40%。原因是双方对"完成"的定义不同：IT 认为数据导入无报错即完成，生产认为必须业务人员抽查确认才算完成。

这个口径差异在第 12 周才暴露，导致后续所有排期失效。最终项目延期到第 14 个月，预算超出原计划约 60%。而这 60% 里，我估算有接近一半来自返工和重复沟通，而不是技术难度。

2. 场景二：报表很漂亮，但没人敢拿它做决策

一家连锁零售企业，员工约 2000 人，门店扩张项目。

他们有很完整的月度经营分析报表，几十个指标，可视化做得也好看。但我参加他们的项目决策会时发现一个现象：讨论到关键节点要不要继续投入时，没有人引用这些报表。

会后我问了一位区域负责人，他的回答很直接："报表上的数字跟我们店里实际情况对不上，我不敢用它做决定。"具体差在哪？报表统计的是"系统订单量"，而门店实际考核的是"完成交付的订单量"，两者口径不同，差异在旺季能到 15% 以上。

当数据口径与业务实际脱节时，数据不会成为决策依据，只会成为会议装饰品。这是我在中型组织里见到最多的问题。

3. 场景三：试点很成功，全面推广就崩

一家金融后台运营中心，员工约 1200 人。他们在两个部门试点新的作业流程，三个月后各项指标明显改善，管理层决定全面推广。

推广到第 5 个月，效果不但没有复制，部分指标还退回了试点前水平。复盘结论是：试点期间参与的是各部门抽调的骨干，他们有能力消化流程变更；全面推广后由普通员工执行，而项目规划里从未评估过"人员能力分布"这个约束条件。

试点成功往往来自人的因素，而不是方法的因素，把试点结论直接当推广依据，是规划阶段最隐蔽的一类错误。

4. 三种场景的共同底层原因

这三个场景表面上分别是口径问题、数据可信问题和约束识别问题，但底层是同一件事：规划阶段用叙述性语言描述项目，而不是用可验证的数据结构描述项目。

叙述性语言适合汇报，不适合执行。执行需要的是一组能被核对、能被追踪、能被提前预警的结构化信息。这正是数据分析应该介入的地方。

三、拆解五个常见误区

下面这五个误区，是我在复盘会上出现频率最高的。每一个我都会给出对应的修正动作，方便你直接对照使用。

1. 误区一：把数据分析当成事后报表

最典型的表述是"等项目跑一段时间，我们再看数据"。这句话看似稳健，实际放弃了数据分析最大的价值区间。

项目规划阶段的不确定性最高，此时数据的边际价值也最大。等到项目执行到中期，很多决策已经变成了既成事实，数据只能用来解释，不能用来选择。

修正动作：在项目立项到排期之间，强制插入一个"数据诊断"环节，产出基线值、约束条件和关键假设清单，作为排期输入。

2. 误区二：目标层层下压，但不做指标拆解

"今年效率提升 20%"从高层传到部门，再传到小组，最后变成每个人头上一个模糊的数字。没有人知道自己的日常工作怎么影响这个 20%。

结果指标和过程指标之间如果没有拆解关系，目标就只是压力，不是路径。一个可执行的指标树，至少要能回答：我今天多做哪件事，会让那个结果指标发生变化。

修正动作：对每个结果指标，至少拆出 2 到 3 个过程指标，并明确过程指标的采集位置和频率。

3. 误区三：口径不统一，会议变成对数据的争论

这是我在中型组织里见到最频繁的消耗。两个小时的会，一个小时在争论"这个数字怎么来的"。

口径问题的可怕之处在于，它不是一次性成本，而是每次会议、每次汇报都要重复支付的成本。而且它会持续侵蚀管理者对数据的信任。

修正动作：建立一份数据口径表，明确每个指标的定义、公式、数据源、统计频率、责任人。这份表不需要很厚，但必须有人签字确认。

4. 误区四：只排期不排责任，只排责任不排验收

很多实施计划的甘特图做得非常精细，精确到周，但任务的责任人只写到部门。跨部门任务一旦挂在部门名下，实际就等于无人负责。

更进一步的问题是验收标准缺失。"完成流程优化"和"优化后审批平均时长从 3.2 天降到 1.5 天以内"，是两种完全不同力度的任务描述。

修正动作：把交付物、责任人、验收标准三列加进实施计划表，任何一行缺一列都不允许通过评审。

5. 误区五：只上线不复盘，经验随项目结束而蒸发

项目结项会上，大家松一口气，然后各自回到新的任务里。三个月后再启动类似项目，几乎从零开始。

没有复盘沉淀的项目，组织的项目能力不会累积，只会重复消耗。复盘不是写总结报告，而是把这次项目中的口径、阈值、决策规则和踩过的坑，固化成下一次可以直接复用的资产。

修正动作：结项时必须产出三样东西：更新后的指标基线、可直接复用的口径表、至少三条可执行的决策规则。

四、专业判断逻辑：数据分析在项目规划中的四层用途

把数据分析放进项目规划，不是加一个报表环节，而是要用它完成四件具体的判断工作。这四层是递进关系，跳过任何一层，后面都会出问题。

1. 第一层：定基线，先知道自己在哪

基线的意义不是记录历史，而是把"改善"变成可测量的动作。没有基线，就无法判断项目是成功了还是只是"感觉好了一点"。

我的经验是，基线至少要有三个时间维度的数据：当前水平、过去 6 到 12 个月的波动范围、季节性高点低点。只取一个平均数作为基线，很容易被特殊月份误导。

举个例子。如果某业务的平均响应时长是 4.2 小时，但旺季能到 7 小时，淡季 2.8 小时，那么把 4.2 作为唯一的基线，旺季时项目看起来一定失败，淡季时看起来一定成功。这种误判会直接摧毁团队对项目的信心。

2. 第二层：拆指标，把结果指标翻译成过程指标

结果指标负责定义成功，过程指标负责驱动行动。管理者真正需要关注的，是这两者之间的传导关系是否成立。

拆解时有一个常见陷阱：拆得太多。我见过一个项目拆出七十多个指标，最后没有任何一个被真正使用。我的建议是每个结果指标最多拆到第三层，过程指标总数控制在 15 个以内。

另一个陷阱是只拆不验。拆完之后要在历史数据上做一次回测：过去半年这个过程指标变化时，结果指标是否真的跟着变化。如果相关性很弱，说明拆解链条是错的。

3. 第三层：验假设，把排期从愿望变成推算

实施计划的排期里藏着大量未经验证的假设，只是它们通常不会被写出来。常见的三类是：资源假设、周期假设、转化假设。

资源假设是"这个团队能同时并行三个任务"，周期假设是"这个环节需要两周"，转化假设是"流程上线后 80% 的人会按新方式操作"。这三类假设如果不在规划阶段验证，就会在执行阶段以延期和返工的形式暴露。

验证的方式不需要很复杂。查看历史同类任务的完成时间分布、统计团队当前的实际并行任务数、在小范围内测试用户接受度，这些动作在规划阶段就能做，成本远低于执行阶段返工。

4. 第四层：控风险，设阈值和触发机制

风险登记表几乎每个项目都有，但绝大多数是摆设。原因很简单：只写了风险描述和应对措施，没写"什么时候算风险发生了"。

我在复盘时见过一份很典型的风险表，风险项写着"人员流失可能影响进度"，应对措施写着"加强团队建设"。这条风险在执行中从未被触发，因为没有人知道该在哪里触发。

可用的风险条目应该长这样：核心开发人员流失率超过 15%，或关键岗位空缺超过 10 个工作日，即触发应对流程，由项目负责人 3 个工作日内提出替代方案。有阈值，有触发人，有响应时限，才有意义。

五、从目标到验收：六张表把实施计划变成可执行结构

下面这六张表，是我在项目里反复使用并逐步收敛出来的。它们不复杂，但覆盖了从目标定义到复盘闭环的完整链条。你可以把它当成一份检查清单，逐项确认。

1. 目标，指标映射表

这张表的用途是确保每个业务目标都有对应的可测量指标，并且指标之间不冲突。

使用这张表时有一个关键动作：确认每个过程指标都能被系统自动采集，而不是依赖人工填报。人工填报的数据在项目压力下会迅速失真。

2. 数据口径表

口径表是六张表里最不起眼、但回报最高的一张。它解决的问题是"同一个词，大家理解不一样"。

一份能用的口径表，每个指标至少要写清七项内容。下面是一段可直接参考的模板结构。

指标名称: 需求平均交付周期
业务定义: 需求从进入"已确认"状态到进入"已验收"状态的自然日差

计算公式: SUM(验收日期 – 确认日期) / 验收需求数

数据来源: 研发管理平台需求状态流转日志

排除规则: 标记为"挂起"且单次挂起超过 7 个自然日的需求不计入

统计频率: 每周一 09:00 自动计算，按周和月两个粒度产出

责任人: 研发效能负责人（口径变更需其书面确认）

预警规则: 连续两周环比上升超过 15%，触发项目负责人复盘

我特别想强调"排除规则"和"口径变更需书面确认"这两项。前者决定了数据是否可信，后者决定了口径会不会在项目中途被悄悄改动。

3. 约束与风险登记表

约束是客观上限，风险是可能发生的不利事件。两者要分开记录，因为处理方式完全不同：约束要被动接受并围绕它设计路径，风险要主动监控并准备预案。

4. 里程碑，交付物表

里程碑如果没有交付物，就只是时间点。交付物如果没有验收标准，就只是形式。

这张表的关键是三列：里程碑名称、可交付物、验收标准。验收标准必须能被第三方复核，而不是由交付方自述完成。

5. 行动，责任人，时间，验收矩阵

这是把计划真正压到人身上的那张表。它比甘特图更重要，因为甘特图回答"什么时候"，这张表回答"谁在什么条件下算完成"。

• 行动：动词开头，描述具体动作，避免"推进""跟进"这类无终点的词。
• 责任人：必须是单个自然人，可以是部门内的人，但不能是部门本身。
• 时间：给出完成日期，而不是持续时间。持续时间会让人不断顺延。
• 验收：写明验收方式，例如"由质量负责人在测试环境验证 3 个工作日，通过率不低于 95%"。

6. 复盘与决策规则表

这张表是整套结构的收口。它预先定义了在什么情况下继续、什么情况下暂停、什么情况下转向。

提前定义决策规则的最大价值，是降低情绪对决策的干扰。当问题出现时，团队不是坐在会议室里争论要不要停，而是对照规则执行。

六、案例解析：一家 600 人装备制造企业的研发数字化项目推演

下面这个案例来自我 2023 年到 2024 年参与的一个项目。企业是装备制造行业，员工约 600 人，属于典型的中型组织。项目名称、具体产品和关键人员信息做了替换，指标数据是脱敏后的近似值，用于说明方法而非宣称效果。

1. 项目背景与第一轮失败

2023 年初，该企业启动研发数字化项目，目标是"提升研发交付效率、缩短交付周期"，计划周期 6 个月，预算数百万元级别。

项目由 IT 部门牵头，研发部门配合。规划文档写得很规范，有甘特图，有阶段划分，有风险清单。但第一轮结果是：实际上线时间拖到第 14 个月，预算超出原计划约 60%，且上线后三个月内，研发团队的日常管理方式几乎没有变化。

我在 2023 年 11 月介入复盘。当时管理层给出的判断是"研发部门配合度不够"。但翻开规划文档，问题一目了然：整个规划里没有一条基线数据。

2. 数据诊断发现的三个关键缺口

我们用三周时间做了数据诊断，没有用任何复杂工具，主要工作是翻历史记录和访谈。结果发现三个缺口。

（1）没有任何经过验证的基线

项目目标写着"缩短交付周期"，但没人知道当时的周期是多少。我们从研发管理平台的历史记录里拉出过去 12 个月的数据，发现需求平均交付周期是 42 天，且方差极大，最短 9 天，最长 138 天。

方差这么大，说明问题不在平均效率，而在流程中的异常等待。这个发现直接改变了项目方向。

（2）各部门对"交付周期"定义完全不同

研发部门统计的是从开发启动到提测的时间，产品部门统计的是从需求评审到上线的时间，业务部门感知的是从提需求到能使用的全部时间。三个口径差了平均 19 天。

这解释了为什么项目上线后没人觉得效率提升，每个部门看的数据都不一样。

（3）没有识别出真正的约束条件

访谈中我们发现，真正限制交付速度的不是开发人力和技术能力，而是需求在评审环节的平均等待时间，接近 11 天。规划文档里把评审列为"例行环节"，完全没有把它当作瓶颈处理。

3. 第二轮：用数据重构实施路径

2024 年第二轮启动时，我们没有直接进入工具选型，而是先重构了规划结构。整个过程分成四步。

第一步是建立统一口径。把"交付周期"统一定义为需求从"已确认"到"已验收"的自然日差，并明确排除挂起超过 7 天的需求。口径确定后，三个部门第一次在同一张表上看同一个数字。

第二步是重新拆解指标。把"缩短交付周期"这个结果指标，拆成三个过程指标：需求评审等待时长、在途需求数量、需求退回次数。每个指标都设置了阈值。

第三步是重新识别约束。基于数据，我们设定了两个硬约束：在途需求不超过 12 个，每周业务可用测试人力不超过 5 人天。这两条约束被写进了排期规则，而不是留在文档里。

第四步才是工具层选型。这一轮的关键需求很明确：需要能自动采集需求状态流转数据、支持跨部门统一视图、能承载研发流程的配置化改造。

4. 工具层选择：为什么考虑私有化部署与迁移成本

这家企业在第一轮用的是国外某项目管理工具，研发团队已经习惯了原有的工作方式。直接强制切换工具，在 600 人规模的组织里意味着巨大的隐性成本，不仅是数据迁移，还有使用习惯、报表体系、自动化脚本的重建。

第二轮评估时，我们把"迁移平滑度"作为一个独立评分项。最终选择的方案是 PingCode。这家企业当时的核心考虑有三点：第一，PingCode 主要服务中大型企业及 100 人以上组织，在 600 人规模的研发组织里，权限模型、跨项目视图和流程配置的成熟度比较匹配；第二，PingCode 支持私有化部署，能满足制造企业对数据不出内网的要求；第三，PingCode 支持 Jira 平滑迁移，历史需求、迭代、缺陷数据可以按映射规则批量导入，团队不需要从零重建数据资产。

对于有国产替代要求、同时又不想承受迁移阵痛的中大型组织来说，支持 Jira 平滑迁移的国产平台是一个值得优先评估的方向，PingCode 在很多评估清单里被视为国产替代不二选择之一。

我想补充一个判断：工具选型不应该在规划的第一步，而应该在指标、口径和约束都明确之后。因为只有到那时，你才知道自己需要工具采集什么数据、支持什么视图、承载什么流程。先选工具再想流程，是我见过最多的返工来源。

5. 结果与未达预期的部分

第二轮从 2024 年 3 月启动，到 2024 年 9 月完成主要模块上线，周期 6 个月，基本按期。项目结束后三个月的关键指标变化如下。

同时有几项没有达到预期，我一并写出来，因为这比成功经验更有参考价值。

• 缺陷逃逸率没有降到目标值 3% 以下。原因是部分遗留模块的测试用例覆盖率难以在短期内补齐，这部分需要更长周期投入。
• 业务部门的主观满意度提升有限。虽然交付周期缩短了，但业务侧更在意的是需求排期优先级，而这个问题属于资源分配机制，不是流程效率问题。
• 历史数据的清洗成本被低估。迁移过程中约 20% 的历史工作项因为状态定义混乱，无法直接映射，需要人工判定，实际耗时比计划多出约 3 周。

6. 管理者可复用的清单

把这次项目里真正起作用的动作抽出来，我整理成一份可以直接照着做的清单。

1. 在排期之前，先花 2 到 3 周做数据诊断，产出基线值和方差分布。
2. 对项目核心指标，逐项写出口径定义、计算公式、排除规则和责任人。
3. 把过程指标数量控制在 15 个以内，每个结果指标最多拆三层。
4. 识别约束条件，并把约束写成排期规则，而不是风险描述。
5. 为每个风险设定量化阈值、触发条件和响应时限。
6. 把"在途任务上限"作为一条硬规则写进执行机制。
7. 工具选型放在指标和口径确定之后，并把迁移成本作为独立评分项。
8. 结项时输出更新后的基线、可复用口径表和至少三条决策规则。

这八条里，我认为回报最高的是第一条和第二条。它们不依赖任何工具，只需要管理者愿意在项目启动前多花两三周时间。而这两三周，通常能省下后面几个月的返工。

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

方法能不能用，取决于组织规模、管理成熟度和项目性质。下面按三种典型情况给出不同力度的建议。这些都来自我在实际项目中的调整经验，不是通用模板。

1. 100 人以下的组织：优先解决口径和责任

这个规模的组织，最不缺的是沟通速度，最缺的是记录和沉淀。很多决策在走廊里就完成了，但没有留下可追溯的依据。

我的建议是不要上复杂体系，聚焦两件事：一份不超过 15 个指标的口径表，一份行动，责任人，时间，验收的清单。这两份东西用表格工具就能维护，不需要专门采购系统。

这个阶段过早引入重型平台，常见的结果是配置了一堆字段但没人维护，最后变成负担。我在不止一家 50 人左右的公司见过这种情况。

2. 100 到 1000 人的组织：重点建约束机制和自动采集

这个规模是问题最集中的区间。跨部门协作开始变多，但流程还没稳定，数据靠人工汇总已经开始失真。

建议做三件事：第一，明确在途任务上限，控制并行度；第二，把关键指标的采集从人工填报切换到系统自动采集；第三，建立双周一次的决策会，会议只讨论超阈值的事项。

工具层面，这个规模的组织通常已经需要专业平台支撑。评估时要重点看三件事：能否按业务实际配置流程、能否自动采集状态流转数据、迁移成本是否可控。对于已经在使用国外研发管理工具、又有国产化和私有化要求的组织，支持平滑迁移的国产平台可以显著降低切换阻力，PingCode 这类服务中大型企业及 100 人以上组织的平台，支持私有化部署和 Jira 平滑迁移，在这个环节值得优先纳入评估。

3. 1000 人以上的组织：先解决口径治理，再谈平台统一

这个规模的组织，最大的挑战不是工具不统一，而是口径不统一。不同事业部、不同区域各自定义指标，汇总到集团层面时，数字对不上是常态。

我的建议是分两步走。第一步是建立集团级的指标字典，明确哪些指标是强制的、口径由谁定义、变更需要谁审批。第二步才是平台统一，而且不必强求一次性统一，可以按业务单元分批推进。

一位集团层面的负责人跟我说过一句话，我印象很深："我们花了一年统一系统，结果发现最该统一的是定义。"这句话基本概括了大型组织的优先级顺序。

八、不同情况下的取舍

实施计划落地从来不缺方法，缺的是取舍。资源永远不够，你必须在几组矛盾里做选择。下面五组取舍是我在项目里反复遇到的，每组我都会给出我的倾向和边界条件。

1. 速度与口径：什么时候可以先用粗口径

口径治理有成本，追求完美口径会让项目迟迟无法启动。

我的倾向是：如果项目周期在 3 个月以内，且只影响单一部门，可以先用粗口径快速启动，但必须在项目文档里标注口径假设和后续校准时间点。如果项目跨三个以上部门，或者周期超过半年，口径必须先统一，否则后期的争议成本会远超前期投入。

2. 自建与采购：什么情况下值得自己搭

自建的优势是完全贴合业务，劣势是维护成本和迭代速度。采购的优势是成熟度高，劣势是需要迁就产品的既有逻辑。

我的判断标准是：如果你的核心业务逻辑本身就是竞争力所在，值得自建；如果只是管理流程的信息化，优先采购。大多数企业的研发管理和项目协同属于后者，自建的投入产出比通常不理想。

3. 全面铺开与试点：试点结论能不能外推

试点几乎是标准动作，但外推的前提经常被忽略。

我的经验是，在决定推广前，必须回答一个问题：试点对象的平均能力和推广对象的平均能力，差距有多大？如果试点用的是各部门骨干，推广对象是普通员工，那么试点结论至少要打七折估计。这个折扣不是悲观，是必要的保守。

4. 强管控与轻流程：管控力度的边界

流程太松，数据采集不上来；流程太严，团队会想办法绕过。这是一个持续需要校准的平衡点。

我的倾向是：在数据采集环节强管控，在具体工作方式上轻管控。比如强制要求工作项状态更新及时，但不规定每天必须怎么写日报。前者是数据可信度的基础，后者是形式主义的高发区。

5. 五组取舍的对照速查

最后一行的两个选项我故意留空，因为在二十多个项目里，我没有见过一次"先选工具再定指标"最后效果好的案例。这个顺序不该有例外。

九、结尾：从一份计划到一套运行机制

回到最开始那个判断。实施计划能不能落地，在规划阶段就已经决定了七成。剩下的三成，取决于执行过程中有没有及时发现问题并调整。

我想给出的一个不太一样的观点是：数据分析在项目管理中的真正价值，不是让管理者看得更清楚，而是让团队在没有管理者介入时也能判断对错。一份好的实施计划，应该让一线成员自己就能判断"这件事做完了没有""现在是不是该预警了""这个方向要不要停"。

如果所有判断都要等管理者拍板，那计划无论做得多细，都会在执行中层层延迟。反过来，如果口径清楚、阈值明确、规则前置，管理者的角色就从"每天救火"变成"定期校准"。这也是我在这几年项目里看到的最明显的能力分水岭。

如果你想在下一步真正动手，我的建议是从一个小项目开始，不要先改整个体系。具体做三件事：

1. 本周内选一个正在推进的项目，用第一节的六维自检表打分，找出最薄弱的两项。
2. 两周内补齐基线数据，至少拿到当前水平、过去 6 个月波动范围和季节性高点低点三组数字。
3. 一个月内产出一份口径表，覆盖不超过 15 个核心指标，并让每个指标的负责人书面确认。

这三件事做完，你大概率会发现，项目延期和反复沟通中有相当一部分，并不是能力问题，而是从来没有把"什么算成功""什么时候算出问题"这两件事写下来过。把它们写下来，实施计划才算真正开始。