项目规划如何做好阶段计划？PMO数据分析与操作步骤

上个月我参加一家装备制造企业的季度进度复盘会。PMO 拿出报表说 A 项目 SPI 0.83，进度落后；项目经理当场反驳："现场都干到 85% 了，你们这个数字不对。"两边各拿一份表，争论了四十分钟，最后谁也没说服谁，因为他们的分歧根本不是"进度快慢"，而是"完成"这两个字指的不是同一件事。

这个场景我见过太多次。绝大多数项目规划做不好阶段计划，问题不出在工具、也不出在分解得不够细，而在于阶段计划写完之后，PMO 拿它算不出偏差。计划里的交付物没有可观测的完成定义，PV 就没有基准，EV 就无法认领，SPI 就成了各说各话的数字。

这篇文章我换个角度讲"项目规划如何做好阶段计划"：不从"计划要包含哪些要素"讲，而从"PMO 要拿到什么数据，计划里就必须提前留出什么接口"倒推。下面是我在多个项目里反复验证过的一套做法，包括四个锚点、七步操作路径、偏差响应分层，以及一份可以直接拿去对照的自查清单。

一、核心结论：阶段计划不是排期表，是一份可核验的数据契约

先把结论放在最前面，后面所有内容都是围绕这四条展开的。

1. 阶段计划的本质是"承诺 + 依赖 + 判据"三件套，时间只是这三者的投影。甘特图是呈现形式，不是计划本身。
2. "完成判据"是阶段计划最容易缺失、也最致命的一环。没有可观测的完成定义，挣值口径就无法统一，PMO 的数据分析必然退化成"催进度"。
3. PMO 对阶段计划只有三个硬要求：可认领（量能落到具体责任人头上）、可比对（同一口径可跨阶段、跨项目比较）、可追溯（每个数字能追回原始记录）。
4. 阶段划分的范式必须先选定，再谈计划。瀑布生命周期、阶段门评审、敏捷迭代，对"阶段计划"的定义完全不同，混用是绝大多数计划失效的根源。

1. 为什么"数据契约"这个定义比"排期表"更有用

把阶段计划当作排期表，评价标准就变成了"时间排得准不准"。但项目管理的现实是：没有哪个项目的实际时间线和计划完全一致，所以按这个标准，几乎所有计划都是失败的，久而久之大家就不当真了。

把它当作数据契约，评价标准就换成了"能不能被核验"。一份契约只要满足三件事就算合格：约定了交付什么、约定了怎么算交付完成、约定了谁在什么时候提供核验依据。这三件事都做到，即使工期有偏差，团队依然能清楚地知道"现在到底走到哪了"。

我在一家做工业软件的公司做过对照。同一个项目组，改造前后的计划文档页数几乎没变，但 PMO 月度进度例会从平均 90 分钟压到 35 分钟，争议事项从每次 6～8 项降到 1～2 项。真正变化的不是文档厚度，而是每个数字背后终于有了共同的判定依据。

二、真实场景：我复盘过的三类"看起来完整、实际用不了"的计划

我把过去几年参与复盘的失效计划归了类，基本逃不出三种形态。它们的共同点是：打开文档觉得什么都有，交给 PMO 却什么都算不出来。

1. 只有时间轴的"倒排计划"

典型特征是从交付日期往前倒推，每个阶段给一个起止日期，阶段名写"设计阶段""开发阶段""测试阶段"。这种计划能回答"什么时候结束"，但回答不了"现在完成了多少"。

因为整个计划里没有一个可计量的交付物。当 PMO 问"开发阶段完成了多少"，唯一的答案只能是"大概七成"，而"大概七成"在挣值体系里是无法认领的。它既不能换算成 EV，也不能和 PV 比对，SPI 自然算不出来。

2. 只有交付物清单的"验收计划"

比上一种进步了一层，至少列了交付物：需求规格说明书、概要设计、测试报告、上线方案。但问题出在交付物写了，完成标准没写。

"需求规格说明书完成"是什么意思？初稿写完算完成，还是评审通过算完成，还是干系人签字确认算完成？这三种理解对应的 PV 曲线能差出一个阶段。我见过一个项目，三种理解同时存在于三方脑子里，结果同一时刻 PMO 算出 SPI 0.81、项目经理自评 0.95、客户方认为 1.0。

3. 只有责任人的"分派计划"

这类计划把每个阶段的任务分到了部门和姓名，看起来很负责，但缺依赖关系。跨部门的前置条件没有登记，于是出现"我这部分按计划做完了，但下不来因为等别人的东西"这种状态。

这种状态下，PMO 收到的进度数据全部是真的，但拼起来的项目状态是假的。因为进度不是各部分的平均值，而是关键路径上的最小值。局部都合格，整体照样卡死。

三、拆解常见误区：五个反复出现的错误

下面这五条，我几乎在每个"计划失效"的项目里都能碰到至少两三条。它们的共同特征是，看起来都对，但放在一起就互相打架。

1. 误区一：把阶段划分范式和评审机制混着用

最常见的错误是：用瀑布方式划分阶段（需求，设计，开发，测试，上线），却用敏捷的迭代节奏管理进度（两周一个迭代），最后用阶段门的方式做评审（没有评审通过不许进下一阶段）。

这三套东西各自自洽，但拼在一起会互相抵消。瀑布阶段的"完成"是里程碑式的，敏捷迭代的"完成"是增量式的，阶段门的"通过"是决策式的。三种"完成"定义同时在一个项目里跑，PV 就只能有一个基准，必然有一方是错的。

2. 误区二：用"评审通过"当完成判据

这是最隐蔽也最普遍的一条。"评审通过"看起来是个客观事件，但它其实是主观判断的集合体，评审人是谁、评审标准是什么、投票规则是什么，都没定义。

更麻烦的是，"评审通过"这个事件通常发生在阶段末尾。如果把它当作唯一的完成判据，那 EV 就只能在阶段末尾跳变，整个阶段内的 SPI 永远是 0，报表毫无预警价值。我有一个客户就是这样，项目组每个月报表都是"进度正常"，然后突然某天全线亮红。

3. 误区三：里程碑、检查点、阶段门当成同义词

三者完全不是一回事。里程碑是时间锚点，回答"到了这天应该处于什么状态"；检查点是过程校验，回答"中间有没有走偏"；阶段门是带决策权的放行机制，回答"要不要继续投入"。

把它们混在一起，最常见的后果是"里程碑变成了汇报会"。会议开完，没有决策、没有后续动作，只是确认了一下日期，然后下一个里程碑继续延期。

4. 误区四：基线"随时可改"

基线一旦可以随时改，PV 就失去了意义。我见过一个项目，一个季度内基线改了 11 次，每次改完报表都"回归正常"。这不是项目管理，是用修改基准的方式掩盖偏差。

基线可以变更，但必须走变更控制，且变更后的口径要能区分"是执行偏差还是计划变了"。否则 PMO 永远无法判断团队的真实交付能力。

5. 误区五：先算 SPI，再补完成判据

顺序反了。SPI 是 EV 除以 PV 的结果，而 EV 的认领规则必须由完成判据决定。没有判据就先建指标，等于先定刻度再定尺子。很多团队上了报表工具，数据看板做得漂亮，但数据本身没有统一的产生规则，最后报表只用来做汇报装饰。

四、专业判断逻辑：阶段计划的四个锚点

如果只看一个指标来判断阶段计划合不合格，我会看"能不能被第三方核验"。下面四个锚点，就是把这句抽象的话拆成可操作的四步。

1. 锚点一：范围，WBS 分解到"第三方可验证"

WBS 分到多细才够？业内通行的判断标准是工作包能被分配给单一责任人，且完成状态能被第三方独立验证。两个条件缺一不可。

"能被第三方验证"这一条最常被忽略。比如"完成系统架构优化"，第三方没法验证；改成"完成订单服务拆分，接口在压测环境下 P95 响应时间低于 200ms，压测报告归档"，第三方拿着报告就能判。这就是可验证。

2. 锚点二：交付物，完成判据必须可观测

这是全文最关键的一段。完成判据必须满足三个条件：可观测、可记录、有唯一责任人。

常见的挣值认领规则有三种，各有适用边界：

• 0/100 法则：未完成计 0，完成计 100。适用于工期短、成果不可分割的工作包，缺点是过程中 EV 恒为 0，缺乏预警。
• 50/50 法则：开工计 50，完成计 50。适用于工期较长、开工即产生实质投入的工作包，缺点是容易高估早期进度。
• 加权里程碑法：把工作包拆成若干可观测节点，各占一定权重。适用于长周期阶段，是目前实践中最能兼顾预警与真实性的做法。

我自己的默认选择是加权里程碑法，权重不按感觉分，而按该节点完成后剩余风险消除的比例来分。下面是一个判据定义的结构示例，可以直接套用到计划文档里：

交付物：订单服务拆分完成
责任人：后端一组 / 张工

完成判据（加权里程碑）：

节点1 权重 30%：接口契约冻结，契约文档归档至配置库，评审记录可见

节点2 权重 40%：功能在预发环境跑通，回归用例通过率 ≥ 98%，报告归档

节点3 权重 30%：压测报告归档，P95 < 200ms，无 P0/P1 缺陷未关闭

核验依据：配置库版本号 + 测试报告编号 + 缺陷清单快照

基线冻结日：2026-03-01（变更须走 CR 流程）

这个结构看起来啰嗦，但它解决了一个核心问题：EV 不再由人主观申报，而是由可查证的事实推导出来。PMO 拿到的是事实，不是态度。

3. 锚点三：依赖，跨部门依赖必须有责任人 + 承诺日期

依赖关系不登记，项目就一定会卡在部门墙之间。登记的标准也很简单：每一个前置依赖，都要有一个明确的责任人和一个明确的承诺交付日期。

"等硬件部门提供样机"不算依赖登记；"硬件部/李工，承诺 4 月 12 日前提供 3 台样机，用于联调"才算。前者无法跟踪，后者可以直接进 PMO 的依赖看板。

4. 锚点四：判据落到基线，基线必须冻结

前三个锚点做完，PV 才真正成立。PV 是把所有工作包的权重按时间铺开后的累计值，而这个铺开的版本一旦确认，就要冻结成基线。

冻结不等于不能改，而是改要有代价、要有记录、要能区分口径。我的做法是保留两套数：原始基线（用于评估团队真实交付能力）和当前基线（用于日常跟踪）。两套数的差值，本身就是一份很有价值的组织能力报告。

五、把数据采集点前置写进计划：PV、EV、SPI 的正确读法

前面四个锚点解决的是"计划能不能被核验"，这一节解决的是"核验出来的数字怎么读"。公式本身很简单，难点全在边界条件上。

1. PV 从哪来：基线确立与冻结

PV（计划价值）是按当前基线，在某一时点上计划完成的工作量折算值。它的可靠性完全取决于基线质量。基线若来自"倒推日期"，PV 就是假的；只有来自前文四个锚点，PV 才有意义。

还有一个细节常被忽略：PV 的计量单位最好用人天或工作量点数，而不是金额。用金额会引入费率波动、采购摊销等干扰，让进度问题看起来像成本问题。

2. EV 怎么认：完成判据决定挣值口径

EV（挣值）是实际完成的工作量按基线价值折算值。它的认领规则必须和 PV 同源，否则两者不可比。

我的建议是把 EV 认领绑定到前文定义的加权里程碑节点，并要求节点核验依据（文档、报告、版本号）在系统里可查。这条要求看起来是管理要求，实际是数据要求，它决定了 SPI 到底是一个可讨论的数字，还是一个可争吵的数字。

3. SPI / SV 的三种常见误用

进度偏差 SV = EV − PV，进度绩效指数 SPI = EV / PV。这两个指标的适用边界，比公式本身重要得多。

• 误用一：把进度指标当成价值指标。SPI 只能说明"做了多少计划内的事"，不能说明"做的这些事有没有价值"。SPI 1.0 的项目也可能因为需求本身错了而失败。
• 误用二：在非线性进度阶段直接读数。长周期阶段的投入通常前低后高，EV 的认领曲线和实际资源消耗曲线并不重合。此时 SPI 的绝对值会系统性偏离，更适合看趋势而非点位。
• 误用三：脱离基线谈阈值。经常看到"SPI 低于 0.9 要预警"这类说法，但阈值强依赖于基线口径和行业特性。我通常建议：先用自己组织过去 6～12 个月的项目数据标定期望区间，再据此设定阈值，不要直接抄外部数字。

4. 同一项目、三种口径，SPI 能差多少

为了说明口径的影响，我把前面提到的那个争议项目做了回算：同一个项目、同一时点，只更换 EV 认领口径，SPI 读数差异非常明显。

5. 阶段切多细，才既看得见又管得起

阶段切得越细，偏差发现得越早，但 PMO 和项目组的填报成本也越高。这是一条明确的取舍曲线，不存在"越细越好"。

我自己的经验区间是：单个阶段的实际工期控制在 4～8 周，阶段内至少有 2～3 个可观测的加权节点。低于 4 周，管理开销会明显侵蚀执行时间；超过 8 周，偏差发现的延迟会超过可容忍范围。

六、案例：一个 300 人研发组织的阶段计划改造

下面这个案例是我参与过的完整改造，规模在 300 人左右，业务是企业级软件产品研发，同时跑着十几个项目。我把过程和数据写下来，供规模相近的组织对照。

1. 改造前的状态

改造前的核心痛点是"计划各写各的"。十几个项目，阶段命名五花八门，交付物定义口径各异，PMO 每个月要花大量时间做数据清洗，最后拼出来的组织级进度视图基本不可用。

具体表现有三个：季度进度例会上，PMO 报的进度和项目组自评进度平均差异 14 个百分点；跨部门依赖问题平均在阶段末才暴露；每个月的进度数据整理要占用 PMO 两名成员各 3 天。

2. 具体做了什么

我们没有先上工具，而是先做了三件事：统一阶段模板、统一定义完成判据、统一依赖登记格式。这三件事花了大约六周，期间只产出文档和模板，没有任何系统改造。

之后才进入系统落地。因为组织规模在 100 人以上、且涉及多个事业部的数据隔离要求，选型时重点看的是能否私有化部署、能否按项目阶段维度沉淀结构化数据、能否与原有的需求与缺陷数据打通。

我们最终以 PingCode 作为落地平台。选择它的直接原因是三点：一是它主要服务中大型企业及 100 人以上组织，多项目、多团队的组织模型比较贴近我们的实际情况；二是支持私有化部署，满足我们对代码与项目数据不出内网的合规要求；三是支持 Jira 平滑迁移，我们原本在 Jira 上有几年的历史数据，迁移成本可控，对国产替代路线来说是比较省事的选项。

在具体用法上，我们把"阶段"作为一级结构，把加权里程碑节点作为阶段下的检查项，节点的核验依据（文档版本、测试报告、缺陷清单）挂到条目上。EV 不再由人填百分比，而是由节点完成状态自动汇总。这一步是整次改造中收益最明显的。

3. 改造后的观察

改造运行了两个完整季度。整体上，进度数据的整理时间大幅下降，PMO 从"做数据"转回"做判断"，这是我最看重的变化。

4. 这次改造里我判断错的地方

也要说一个失误。我们最初要求所有项目统一使用"2 周一个检查点"的节奏，结果发现硬件相关项目根本跑不动，样机验证周期本身就长于两周，硬套节奏只会产生大量"检查点未达标但无实质问题"的噪音。

后来我们改成按项目类型给三档节奏模板：软件迭代型用 2 周，集成交付型用 4 周，硬件与产线型用 6～8 周。统一的是判据的写法，不统一的是节奏本身。这个调整之后，噪音项减少了大约七成。

七、PMO 的七步操作路径

把前面的方法收拢成可执行的动作。每一步我都写清"输入，动作，输出物"，这样你拿到之后可以直接对照现有项目走一遍。

1. 步骤 1-3：收敛范围、定义交付物、设定判据

这三步是计划的地基，也是最容易被跳过的地方。跳过它们的代价，会在后面几个月以"数据不可用"的形式全部还回来。

• 步骤 1 收敛范围：输入是项目章程与需求清单，动作是把待交付内容逐条产品化（能描述出"交付了什么"），输出是待交付清单。无法产品化描述的条目，单独挂起，不进基线。
• 步骤 2 定义交付物：输入是待交付清单，动作是把每条交付物拆成阶段内可分配的粒度，输出是交付物与工作包对应表。
• 步骤 3 设定判据：输入是工作包，动作是为每个工作包定义可观测的完成判据与核验依据，输出是完成判据表（含加权节点、权重、核验依据）。

2. 步骤 4-5：梳理依赖、锁定基线

• 步骤 4 梳理依赖：输入是工作包清单，动作是逐条登记跨部门前置条件，明确责任人与承诺日期，输出是依赖登记表。
• 步骤 5 锁定基线：输入是判据表与依赖表，动作是按权重铺开时间形成 PV 曲线并冻结，输出是冻结基线版本。

这里要强调一点：基线冻结必须是一个有仪式感的动作。我在项目里通常会要求三方（项目组、PMO、业务方）对基线版本做一次书面确认。不是为了追责，而是为了让"改了基线"这件事有明确的时间戳。

3. 步骤 6-7：建立采集机制、设定响应规则

• 步骤 6 建立采集机制：输入是判据表，动作是把每个加权节点的完成状态与核验依据设为常规采集项，明确采集频率与责任人，输出是采集清单与责任人表。
• 步骤 7 设定响应规则：输入是历史项目数据，动作是标定期望区间、设定偏差阈值与对应的响应动作，输出是偏差响应矩阵。

八、阶段门评审与偏差响应：让机制真正咬合

计划做得再好，如果没有评审和响应机制咬合，三个月后就会退回到"文档没人看"的状态。这一节讲两个咬合点。

1. 阶段门评审的三档结论

阶段门最大的价值不是"评审"，而是"允许不通过"。只有一个结论的评审是走过场。我建议固化为三档：

• 通过：全部交付物判据达成，进入下一阶段，基线不变。
• 有条件通过：核心判据达成，存在少量未闭环项，明确整改项、责任人与闭环日期后放行，同时在基线上做标记，便于后续追踪。
• 不通过：核心判据未达成，暂停下一阶段投入，重新评估范围或资源。

关键在于"有条件通过"这一档。没有它，评审就只能在"通过"和"撕破脸"之间二选一，现实中一定会滑向前者。给评审留一个体面的中间档，反而能让把关真正发生。

2. 评审输入清单与形式化陷阱

我见过最多的形式化陷阱是：评审材料由项目组自行准备，PMO 只负责组织会议。这种情况下，材料本身就是被筛选过的，评审人只能看到项目组想让他看到的部分。

我的做法是把评审输入清单固化，包括：本阶段完成判据逐项自查结果、核验依据清单（文档版本/报告编号）、未闭环项列表及影响评估、下一阶段计划与依赖确认情况、当前 SPI 趋势与口径说明。这份清单由 PMO 按系统数据生成初稿，项目组补充说明，而不是从零开始写。

3. 偏差出现后的响应分层

偏差响应最忌讳"一刀切"：任何偏差都上报，管理层会被噪音淹没；任何偏差都不上报，问题会在沉默中累积。分层是唯一可行的做法。

下面这套分层是我在多个项目里调过的版本，阈值需要按组织情况自行标定，仅供参考结构。

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

同一套方法，在不同组织里的落地方式差别很大。下面按四种常见情况给建议，你可以直接对照自己所在的组织。

1. 50 人以下、单项目为主

这种规模不要上复杂的挣值体系，管理成本会超过收益。建议只做两件事：把完成判据写清楚，把依赖登记到责任人。

进度跟踪用"加权节点完成率"就够了，不必强行计算 SPI。节点完成率和实际交付的相关性，在小规模团队里通常比 SPI 更高。

2. 100 人以上、多项目并行

这个规模必须做口径统一，否则组织级视图永远拼不出来。优先级排序是：先统一判据写法，再统一采集机制，最后才考虑报表与看板。

工具选择上要重点看三件事：能否承载多项目多团队的组织模型、能否按阶段维度沉淀结构化数据、是否支持私有化部署以满足合规要求。100 人以上的组织通常还有历史数据迁移的问题，迁移成本要在选型阶段就算清楚。

3. 强合规或硬件制造类项目

这类项目的阶段划分往往不由项目组决定，而是由行业规范或客户流程规定。此时不建议改动阶段结构，而是在现有阶段内增设加权节点来提升过程中的可见度。

另外，这类项目的核验依据通常是正式文档，务必把文档编号体系纳入判据定义，让每个节点的完成都能追溯到唯一编号的文件。

4. 需求高度不确定的探索型项目

不要硬套阶段门。这类项目更适合用固定节奏的迭代，但要额外设计一个"累计完成度"的统一口径，否则跨迭代的进度无法比较。

我的做法是把探索型项目的判据定义为"假设验证结论"，而不是"功能交付"。每验证一个假设，就有一个可观测的结论产出，EV 认领有了依据，节奏又保持了敏捷。

十、不同情况下的取舍

做阶段计划本质上是一连串取舍。这里列出四个我最常被问到的，以及我的判断依据。

1. 颗粒度 vs 管理成本

颗粒度越细，可见度越高，填报成本也越高。判断依据是偏差发现提前带来的收益，是否大于填报投入的成本。

我的经验拐点在"阶段 4～8 周、阶段内 2～3 个节点"附近。如果你的项目纠偏窗口本来就很短（比如总工期只有两个月），那精细化的收益可能不足以覆盖成本，此时应优先保证判据清晰，而不是节点数量。

2. 基线刚性 vs 响应速度

基线越刚性，数据越可比；变更流程越宽松，响应越快。这两者无法同时最大化。

我的建议是分项目类型处理：交付范围相对稳定的项目，基线刚性优先；需求变化频繁的项目，响应速度优先，但要用"版本化基线"保证可比性。也就是每次变更生成一个新版本号，历史版本可查，而不是覆盖原基线。

3. 数据精度 vs 填报负担

PMO 经常希望数据越精确越好，但精度是有代价的。我见过要求项目组每天填报工时、结果填报质量极差，数据反而更不可信。

更现实的做法是：把自动可得的数据做到高精度（如缺陷数、代码提交、测试通过率），把需要人工填报的数据降低精度要求（如按周而不是按天）。这样整体数据质量通常更高。

4. 自建 vs 采购平台

自建的优点是贴合自身流程，缺点是维护成本高、跨项目口径难统一；采购平台的优缺点基本相反。

我的判断标准是：如果你组织的项目管理流程已经稳定运行两年以上，且差异点主要在数据展示层，可以考虑轻量自建；如果流程本身还在调整，优先选平台，把精力放在流程定义上，而不是工具开发上。

另外提醒一点：涉及多事业部、敏感项目数据的企业，选型时私有化部署能力应该作为硬性门槛，而不是加分项。这条在合规审查时经常成为卡点。

十一、一页纸自查清单与三个高频坑

最后给一份可以立刻拿去用的自查清单。我建议你拿现有项目对照走一遍，看哪一条不通过，比读十篇文章都有用。

1. 计划交付前的一页纸自查清单

1. 每个工作包是否有唯一的责任人（不是部门，是人）？
2. 每个工作包的完成判据是否可被第三方独立验证？
3. 每条判据是否对应一个可查证的核验依据（文档编号/报告编号/版本号）？
4. 工作包是否配置了加权节点，还是只能整包计 0 或计 100？
5. 每一项跨部门依赖是否登记了责任人和承诺日期？
6. 基线是否已冻结并留存版本号？变更是否有流程？
7. EV 的认领规则是否与 PV 的计量口径同源？
8. SPI 的期望区间是否用本组织历史数据标定过，而不是直接抄外部阈值？
9. 阶段门是否配置了"有条件通过"这一档？
10. 偏差响应是否有分层和闭环时限，还是只有"上报"一个动作？

2. 坑一：把阶段计划当成一次性文档

写完就归档，改的时候随手改。这是最常见的失效路径。阶段计划应该是活的数据源，它的节点状态每天在变，PMO 读的是这些状态，而不是那份文档。

判断方法很简单：如果你的计划文档一个月没有被打开过，而项目还在跑，那它大概率已经和现实脱节了。

3. 坑二：用评审代替判据

"评审通过就算完成"这句话的隐含前提是评审本身足够严谨。但现实是，评审经常发生在信息不完整、人员不齐、时间不够的情况下，结论的可靠性有限。

正确的做法是让评审去验证判据，而不是让评审本身成为判据。评审的输入是判据自查结果，输出是决策结论，判据不因为评审而改变。

4. 坑三：指标脱离基线谈偏差

没有冻结基线，SPI 就是一个没有参照系的数字。今天 0.85、下个月 0.92，看起来在改善，但如果基线被改过一次，这个改善可能完全不存在。

我的建议是把"基线版本号"作为所有进度报表的必填字段。看到 SPI 的第一反应，应该是先看它算在哪版基线上。

说到底，项目规划做阶段计划，真正难的不是把时间排出来，而是让这份计划在接下来的几个月里始终能被算、能被比、能被追。只要完成判据是可观测的、依赖是有责任人的、基线是冻结且带版本的，PMO 的数据分析就自然有了根基，进度例会也不再需要花四十分钟争论一个数字。

下一步你可以做一件很小的事：挑一个正在跑的项目，用第十一节那份十条清单逐条打钩，把不通过的项列出来。通常你会发现，真正需要改的并不是整份计划，而只是其中两三条定义。把这两三条补齐，下一个阶段的数据质量就会明显不一样。