实施计划管理指南：PMO如何做好项目规划，落地方案全流程

引言

2021年我以外部顾问身份进入一家做工业检测设备的公司，他们的PMO一共四个人，计划模板做得极漂亮：WBS拆到第四层，甘特图能拉到两年后，连每台测试设备的占用窗口都排进去了。项目启动会上，研发、生产、采购、销售的负责人都签了字。六个月后，这个项目的交付时间比基线晚了107天，而团队里没有一个人能说清楚，偏差究竟是从哪一周开始累积的。

后来我把这个项目的变更记录、周报和会议纪要翻了一遍，发现问题根本不在排期能力上，而在几个非常具体的断点上：范围描述用的是"支持多种协议"这种无法验收的表述；关键资源承诺是会上口头答应的，没进任何人的绩效；变更门槛形同虚设，研发负责人一句"客户催得急"就能把两周的工作插进来。这些断点加起来，比任何一次排期失误都致命。

这就是我写这篇指南的出发点：PMO做实施计划管理，真正要解决的不是"怎么把计划做得更好看"，而是"计划在组织里怎么跑得动"。下面我会把这条链路从定位、目标翻译、分层设计、基线冻结、变更控制一路讲到工具落地和复盘沉淀，每个环节都给出我实际用过的判断标准和动作清单，也会说明哪些做法在什么条件下不适用。

一、核心结论：计划管理的失效点，九成不在甘特图

先给结论，再展开论证。过去几年我参与过二十多个项目计划体系的搭建或诊断，其中真正因为"排期算法不对""工具不好用"导致失败的，占比不到一成。绝大多数失败可以归到五类断点上，而且这五类断点有明确的贡献排序。

1. 计划是一张"承诺网络"，不是一张时间表

大多数人对计划的理解停留在"什么时间做什么事"，这是把计划当成了时间表。但计划真正承载的是三样东西：范围边界（做什么、不做什么）、资源承诺（谁在什么时间投入多少）、责任归属（出偏差时谁负责解释）。时间只是这三样东西的呈现形式。

如果你把计划当时间表，那么进度落后时你的第一反应是"重新排一下"；如果你把计划当承诺网络，进度落后时你的第一反应是"哪一条承诺没有兑现，是谁没兑现，为什么"。这两种反应会导致完全不同的管理动作，也决定了计划体系最终是活的还是死的。

2. 计划失效的五类断点及其典型表现

我把见过的失效场景归成五类，并在一份覆盖37个项目的内部诊断数据里统计了各自的偏差贡献度（示意数据，样本为制造业、企业软件交付和集成类项目，偏差口径为"实际交付日期超出基线的天数占总延期天数的比例"）。

• 目标翻译断点：业务目标没有转成可交付物，范围边界模糊，导致后期不断追加。
• 资源承诺断点：关键人只在会上点头，没有进排期、没有进考核，被其他项目随时抽走。
• 基线缺失断点：计划从未冻结，所有偏差都"相对最新版本"计算，等于没有偏差。
• 变更失控断点：任何层级都能口头改计划，变更无记录、无门槛、无回溯。
• 可视化失真断点：汇报链条层层过滤，真实风险到不了决策层，等暴露时已无法挽回。

3. 为什么工具换了一轮又一轮，问题还在

我见过不少团队从Excel换到专业项目管理平台，又从平台换回Excel，来回折腾两三次。每次切换都会带来一阵"这次终于规范了"的兴奋，三个月后回到原点。原因很简单：工具解决的是"信息记录和传递"，解决不了"权限和承诺"。

一套工具可以让你三分钟生成一张漂亮的甘特图，但它没法让研发负责人真的把这个人交出来，也没法阻止销售在周五下午塞进一个新需求。所以我的建议顺序始终是：先定机制，再定字段，最后选工具。顺序错了，工具只会让混乱变得更整齐。

二、先定位，再谈方法：你的PMO属于哪一型

这是很多计划管理文章直接跳过的一步，但它是所有方法能不能用的前提。支持型、控制型、指令型三种PMO，在计划编制、审批、变更、资源调配上的话语权完全不同。你把指令型PMO的"计划审批权"套到支持型PMO身上，结果就是推不动，还会把关系搞僵。

1. 三种PMO定位下的计划权限差异

下表是我在实际诊断中用来给PMO定位的评估表，评分区间0，5分，分数越高代表该PMO在这项权限上的实际话语权越强。评分依据不是章程怎么写，而是"过去三个月里，这件事最终是谁拍板的"。

2. 定位不清时，PMO最先该争取的三件事

如果你所在的PMO处于支持型，先别急着推全套流程，那只会引起反弹。我建议按下面顺序争取三项"低阻力、高杠杆"的权力，每一项都有具体的争取话术和落地动作。

1. 计划模板统一权。理由不是"规范管理"，而是"减少你们的重复填写"。话术可以是：我们把三个部门的周报字段合并成一套，大家少填一半内容，数据还能自动汇总。这是最容易拿到的第一项权力。
2. 里程碑评审召集权。先争取"召集",不争"主持"。召集权意味着你能决定什么时候开、谁必须来。真正的评审结论仍由业务负责人拍板，但你已经掌握了节奏和议程。
3. 变更信息汇总权。不要求审批权，只要求"所有变更必须抄送PMO并进入台账"。这一步的价值在于三个月后你能拿出数据说话：这个季度一共发生了多少次变更，来自哪里，影响了多少天。

3. 一个简单的自测方法

拿过去三个月发生过的三件事来测：第一，有没有一次计划评审会因为PMO提出意见而改期或修改方案；第二，有没有一次变更因为PMO的记录而被追责或重新排期；第三，有没有一次资源冲突是PMO牵头协调解决的。三件里一件都没有，说明你们目前是支持型，后文关于审批和考核的部分需要降级使用，我会在对应位置标注。

三、计划的起点不是进度表，而是目标翻译

我在诊断项目时有个固定习惯：先不看计划表，先看项目章程和范围说明书。如果范围描述里出现"支持多种""尽快完成""参照同类产品"这类词，我基本可以预判这个项目后期会有严重的范围蔓延，跟排期能力无关。

1. 从业务目标到项目目标的三次翻译损耗

业务目标到项目目标之间，通常要经过三次翻译：公司战略目标翻译为业务目标（比如"今年新市场收入占比提升"），业务目标翻译为项目目标（"上线一套能支撑X业务的系统"），项目目标翻译为可交付物清单（具体到模块、接口、验收标准）。每一次翻译都会产生信息损耗，而损耗不会自动被察觉，只会在交付阶段以返工的形式集中爆发。

下面这组数据来自我参与诊断的12个项目，对比了"目标明确写进范围说明书的可交付物数量"与"实际交付时被追加的可交付物数量"（示意数据，统计口径为单个项目交付阶段新增或修改的功能条目数）。

2. 范围边界怎么写才不会被反复拉扯

我给团队的范围描述标准只有一条：每一条范围都必须能被一个具体的人在一个具体的时间点判定"完成"或"未完成"。做不到这一条，就说明它还停留在目标层，没到可交付物层。下面是我常用的改写对照。

• "支持多种数据源接入" → 改为"支持MySQL 5.7以上、PostgreSQL 12以上、Kafka 2.8以上三类数据源的结构化数据接入，单源首次接入配置时间不超过2人天"。
• "系统性能满足业务需求" → 改为"单表1000万行数据下，列表查询P95响应时间不超过1.5秒，并发50用户时不超过2.5秒"。
• "优化用户体验" → 删除。这类条目无法验收，写进范围只会成为后期扯皮的借口。
• "与现有系统对接" → 改为"与A系统通过REST接口对接订单主数据，接口字段以附件清单为准，A系统侧改造由A系统负责人承担"。

改写之后条目会变多，但每一条都能落到人头上。我的经验是，范围说明书的页数增加一倍，交付阶段的返工能减少三成左右，这个投入产出比非常划算。

3. 识别"假承诺"：谁签字，谁负责资源

启动会上全员点头是常态，但签字的人和出资源的人往往不是同一个。我见过最典型的情况是：研发负责人在计划上签了字，但他的团队同时承接了四个项目，实际可投入人力只有承诺的一半。签字时他没说谎，他只是没有权力从其他项目里把人抽出来。

所以我在计划评审时一定会追问三个问题：这个人现在在做什么项目？你打算从哪里把他调过来？如果他被调走，那个项目的哪一步会受影响，谁同意这个影响？三个问题问下来，真正的资源冲突会立刻显形。回答不了这三个问题的承诺，我一律标注为"待确认承诺"，不计入基线。

四、分层设计：一套计划体系，四种颗粒度

这是我认为最有价值、也最容易被做错的一节。很多PMO把"加强计划管理"理解为"把计划做得更细"，结果做到任务级颗粒度，每周更新一次，维护成本高得离谱，而且更新完就过期。正确的做法是分层，每一层有自己的颗粒度、刷新频率和服务对象。

1. 四个层级各管什么

关键原则是：上层不做下层的详细计划，下层不承担上层的汇报负担。我见过一个项目要求每个开发每天更新任务进度，同时周报要汇总到项目级，月度还要出组合报告，结果一周后所有人都开始敷衍填表。不是他们不配合，是这套要求本身在数学上就不成立。

2. 刷新频率如何分层

刷新频率的设计依据是"偏差在这个层级上多快会变得不可逆"。任务级的偏差一天内可以纠正，项目级的偏差两周内可以纠正，组合级的偏差一个季度后就很难回头。所以刷新频率应该与纠偏窗口匹配，而不是与"管理严格程度"挂钩。

3. 层级之间的"接口字段"

分层最容易出的问题是"层与层之间接不上"。任务级更新了，项目级不知道；项目级延期了，项目群级还以为正常。解决办法是明确每一层的接口字段，即哪些信息必须向上汇总，哪些必须向下拆解。

• 向上汇总字段：里程碑状态（达成/风险/延期）、偏差天数、变更次数与来源分类、关键资源占用率、前三大风险。这些字段必须能从下层自动汇总，不能靠人工填写。
• 向下拆解字段：本层承诺的交付日期、可使用的资源上限、必须遵守的验收标准、不允许突破的约束条件。
• 双向必须一致的字段：交付物编号和责任人。这两个字段一旦上下不一致，一切偏差分析都会失效。

接口字段确定之后，工具选型的标准就清楚了：任何不能自动完成上述汇总的计算工具，都会把成本转嫁到人工填表上。这也是我在后面工具章节里判断一套系统值不值得上的核心依据。

五、评审与基线：让计划获得"被承认"的身份

基线这个词被滥用得很厉害。很多团队说"我们有基线"，一问发现基线是随时更新的滚动版本，那么偏差永远接近零，因为分母一直在变。真正的基线只有一个特征：它会被冻结在某一个时间点上，之后所有的偏差都是相对它计算的。

1. 计划评审会怎么开才不流于形式

评审会开成走过场，几乎都是因为议程设计错了。多数评审会按"逐条过计划"的方式开，参会人被动听两个小时，最后问一句"大家没意见吧"。我建议改成三段式议程，总时长控制在90分钟以内。

1. 前20分钟：只讲约束和风险。由PMO报告本次计划的资源约束、依赖风险和已知不确定项，不讲进度安排。
2. 中间50分钟：只讨论三类高风险条目。即关键路径上的任务、跨部门依赖、以及资源承诺未确认的条目。其余条目默认通过。
3. 最后20分钟：确认承诺与待确认清单。逐条确认谁在什么时间点之前给出什么，明确列出未确认项，并约定补齐时间。

这套议程的核心逻辑是：评审会不是让所有人了解计划，而是让关键承诺得到确认。了解计划可以看文档，确认承诺必须当面进行。

2. 基线冻结的时点与意义

基线冻结的合适时点不是"计划写完那天"，而是"所有关键资源承诺确认完毕那天"。这两者之间往往差两到三周。如果提前冻结，你在三个星期后就必须走一轮变更，等于给变更控制开了个坏头。

冻结之后要立刻做一件事：把基线版本、冻结日期、确认人清单固化下来，并在工具里设为不可编辑的只读版本。所有后续的偏差分析都以它为基准。这一步在人工管理阶段很容易被绕过，所以我会要求至少在同一个地方留下快照，避免后续扯皮。

3. 资源承诺如何落纸面

我在这一环上的态度比较强硬：不落纸面的承诺等于没有承诺，但"落纸面"不等于签纸质文件。它可以是项目管理平台里的一条资源分配记录，也可以是一封确认邮件，关键是有明确的投入比例和时间段。下面是我要求的最小信息集合。

• 人名与角色，不用写"研发团队"这种集体名词。
• 投入比例与时间段，例如"9月1日至10月15日，投入60%"。
• 该资源当前所属的其他项目，以及被抽调时受影响的项目名称。
• 确认人，必须是该资源的直接管理者，不能是同级同事。

如果你们PMO是支持型（第一章自测结果），这一步可以降级为"要求项目经理自己在平台上登记资源分配"，PMO只做完整性检查，不参与确认。等积累了两三个季度的资源冲突数据后，再向上争取正式的资源协调机制。

六、变更控制：计划能不能活下来，全看这一环

变更控制是最容易被写成"变更要走流程"这种正确废话的一节。我见过的失败案例里，几乎没有哪个团队是因为"不重视变更"而失败的，相反，很多团队有完整的变更申请表和审批流，问题出在门槛设计不合理：要么门槛高到没人愿意走，要么低到走不走都一样。

1. 变更的三个门槛

我通常把变更划成三级，分别对应三种处理方式。划分依据不是工作量大小，而是"对关键路径的影响程度"和"是否需要调整对外承诺"。

2. 变更记录的真正用途是诊断

很多团队把变更记录当成留痕工具，为了将来追责用。这个用途太低价值了。变更记录真正的作用是识别偏差来源的结构分布：如果一个季度里，来自"需求新增"的变更占了六成，那说明问题出在前端的需求管理；如果来自"资源被抽调"的占了大头，那说明资源承诺机制没立住；如果来自"估算偏差"的占多数，那你该投资的是估算能力建设。

下面这组变更来源分布来自一家做企业软件交付的公司，统计周期为一个完整财年，共登记327条变更（示意数据）。

3. 例外管理与计划豁免的边界

任何流程都需要例外通道，否则会在紧急情况下被整体绕过。我会设一条明确的例外规则：在项目上线前两周的冲刺期内，允许项目经理在不超过5人天、不影响上线日期的前提下行使一次"先执行后补录"的例外权，但必须在48小时内完成补录，且同一项目最多使用两次。

例外权必须写清次数上限和补录时限，否则它会迅速变成常规通道。我在一个项目里见过例外权被连续使用九次，最后整个变更控制形同虚设。第二年我把次数上限写成两次，这个项目的变更登记率反而从61%升到了94%。

七、可视化与会议机制：让偏差被及时看见

计划管理的日常动作不是排期，是"看见偏差"。我见过太多团队把汇报当成了可视化，周报上写着"整体进度70%"，但实际上关键路径上已经卡了十天。真正有效的可视化要能回答问题，而不是展示状态。

1. 指标要少而准

我会把计划健康度压缩到五个指标，每个都指向一个可执行的动作。指标再多，管理层就不会看，团队也不会认真填。

• 里程碑达成率：按计划到期的里程碑中实际按时达成的比例。低于80%说明计划编制过于乐观或执行资源不足。
• 计划偏差率：实际完成时间与基线之差除以基线工期。用于衡量承诺质量，不用于考核个人。
• 变更频次与来源分布：用于诊断前端问题，按第6节的分类统计。
• 关键资源负荷率：承诺投入与实际投入的比值。超过110%意味着过度承诺，低于70%意味着资源浪费或登记不全。
• 风险升级时效：从风险被识别到进入决策层视野的平均天数。这个指标最能反映汇报链条的健康度。

2. 三层会议各解决什么问题

会议机制必须和计划层级匹配。我见过最常见的错误是把三个层级的问题塞进同一个周会，结果两个小时下来什么都没解决。我的建议是三层会议，各管一段，互不越界。

• 每日站会（15分钟）：只解决任务级阻塞，不汇报进度百分比。规则是"只说卡住的事，顺带说今天做什么"。
• 周度项目会（60分钟）：只处理项目级偏差与风险升级。议程固定为：上周承诺兑现情况、本周关键路径风险、需要升级的决策事项。单项进度默认线下同步，不上会。
• 月度经营对齐会（90分钟）：只做资源取舍和项目优先级调整，不讨论执行细节。PMO在这一层的职责是提供组合视图和资源冲突数据，而不是逐个汇报项目状态。

这套设计的关键在于"不该在会上解决什么"。我在一家公司推行时，明确规定周会不讨论技术方案，有争议的技术问题由技术负责人在会后24小时内给出结论。仅这一条，周会时长就从平均110分钟降到了55分钟，而里程碑达成率同期从68%升到了84%。

3. 汇报失真的四种典型原因

偏差看不见，通常不是因为没有数据，而是因为数据在上报过程中被过滤了。我总结出四种常见失真机制，每一种都有对应的破解办法。

1. 层层承诺一致的压力：下属知道上级已经向上承诺了日期，所以不敢报坏消息。破解办法是设立"预警不计责"规则，即主动提前预警的风险不纳入个人考核，事后暴露的才追责。
2. 进度百分比口径不统一：有人按工时算，有人按工作量算，汇总后毫无意义。破解办法是放弃百分比，改用"里程碑达成/未达成"二值判断。
3. 风险与问题的区分缺失：团队把风险当成问题，认为"还没发生就不该说"。破解办法是在模板里强制分列"已发生问题"和"未发生风险"两栏。
4. 汇总层级过多：五个人汇总给组长，组长汇总给经理，经理汇总给PMO，每层过滤10%，到顶就只剩一半信息。破解办法是让关键风险可以越级直达PMO，同时规定越级上报不作为对直接上级的负面评价。

八、工具化落地：什么时候该上系统，什么时候不该

先说结论：机制没跑通之前上系统，等于把混乱固化。我在这一节会给出一套判断信号，以及中大型组织在选型时真正该看的硬指标。

1. 上系统之前必须满足的三个信号

这三个信号只要缺一个，我都会建议先治理机制，不要急着采购或部署。

1. 接口字段已经稳定运行至少一个季度。也就是说，分层计划的上行汇总字段和下行拆解字段已经确定，团队按这套字段汇报过三个月的完整周期，没有大规模改动。字段没定就上系统，后面每改一次都是配置成本和迁移成本。
2. 基线冻结和变更分级已经是书面规则，并且在人工环境下被执行过。如果人工环境下变更分级都推不动，系统里的审批流只会被绕过，而且绕得更隐蔽。
3. 至少有一个项目群级别的真实痛点，例如跨十个以上项目的资源冲突靠Excel已经算不清楚了。这是系统真正能带来确定收益的地方。

2. 中大型组织的选型硬指标

当组织规模超过100人、同时在跑的项目超过15个、涉及跨部门资源协调时，Excel和零散工具的组合基本会失效。这时候选型的评判标准应该从"功能多不多"转向下面这四条硬指标。

• 分层计划模型是否原生支持。能不能直接把组合级、项目群级、项目级、任务级建在同一套数据模型里，而不是靠自定义字段硬凑。这一条决定了你的分层设计能不能落地。
• 资源负荷是否可跨项目计算。系统需要能在一个人被分配到多个项目时自动算出实际负荷率和冲突区间。这是中大型组织最刚性的需求。
• 变更分级是否能配置成工作流。一级变更要走轻量记录，三级变更要走多级审批和方案比选，且两级之间不能互相干扰。这一点很多系统做不到，只能全走一套流程。
• 部署方式与数据主权是否可控。对于制造业、金融、军工类客户，私有化部署往往是硬性要求，不能妥协。

以PingCode为例，它主要服务中大型企业及100人以上的组织，这两个特征正好对应上面提到的"规模临界点"。它的分层计划模型和跨项目资源负荷计算是针对这类组织的刚性需求设计的，同时支持私有化部署，支持Jira平滑迁移，是国产替代场景下比较稳妥的选择。我参与过的一家设备制造企业，在150人研发规模下从原有工具迁移到PingCode，主要动因就是私有化部署要求和跨项目资源冲突的可视化需求。

3. 迁移与私有化部署的现实考量

工具迁移最容易被低估的是"历史数据的处理"。我在实际项目里总结出三条经验，可以显著降低迁移风险。

1. 只迁移活跃项目，不迁历史归档。把已结项超过一年的项目导出为只读报表即可，不要把全部历史数据搬进新系统。历史数据字段不规范，迁移成本极高，且几乎不会被查询。
2. 先迁计划模型，再迁执行数据。先在新系统里把分层计划、字段定义、变更分级工作流配置好并试运行两周，确认机制跑得通，再开始迁移项目数据。
3. 保留双轨期。建议设置四到六周的双轨期，老系统只读、新系统写入。双轨期结束后一次性切换，避免长期并行导致的填报混乱。

关于私有化部署，需要提前确认的是升级路径和版本节奏。私有化部署在数据主权上优势明显，但版本更新通常滞后于云端版本，如果你的团队需要频繁使用新功能，需要在选型阶段就把升级机制问清楚，避免上线半年后陷入"想升级但没有明确路径"的被动局面。

九、复盘与沉淀：把估算能力变成组织资产

复盘这一环，绝大多数团队做成了形式主义，开会两小时，产出一份谁也不会再看的文档。我认为根本原因是复盘的目标定错了：复盘的目的不是总结这个项目做得好不好，而是让下一个项目的估算更准、风险识别更早。

1. 里程碑复盘与收尾复盘的区别

这两种复盘经常被混为一谈，实际用途完全不同，节奏也不同。

里程碑复盘的价值在于"及时调整"，收尾复盘的价值在于"能力沉淀"。前者动作要快，后者结论要稳。我见过团队为了省事只做收尾复盘，结果项目中期偏了也没人管，最后复盘时只能得出"整体延期两个月"这种毫无指导意义的结论。

2. 沉淀三类可复用资产

复盘如果只产出文字结论，下个项目一定还会踩同一个坑。我要求团队把复盘结论转成三类可以直接复用的结构化资产。

• 估算基准：按工作类型记录实际工时与估算工时的比值。比如"接口对接类工作，历史估算与实际的平均比值是1.4"，那么下次估算时就有据可依，而不是凭感觉。
• 风险清单：按项目类型沉淀高频风险条目和对应的应对动作。这份清单应该逐个项目迭代，条目只增不删，最多标注"低概率"。
• 协作教训：记录具体的协作失效场景和当时的解决方式。例如"依赖方接口文档平均延迟9天，有效的做法是在计划中前置一个文档对齐里程碑"。

3. PMO自身也需要被度量

这是我在很多组织里坚持要加的一条。PMO如果只度量项目，不度量自己，很容易退化成报表收集岗，也容易在业务方质疑时拿不出价值证明。我给PMO设的自我度量指标通常只有三个，都是可以客观统计的。

• 风险提前识别率：在风险实际发生前至少两周被纳入台账的比例。这个指标直接体现PMO的信息触达能力。
• 资源冲突化解率：PMO介入的资源冲突中，在两周内达成明确方案的比例。
• 计划体系采纳率：实际使用统一模板和字段的项目占比。这个指标反映机制的推广效果，比"完成了多少次培训"有意义得多。

我一般给这三个指标设的目标是：风险提前识别率70%以上，资源冲突化解率80%以上，计划体系采纳率90%以上。达不到的时候先别急着苛责团队，回头看看是不是模板字段太多、流程太长，或者PMO自己在评审会上没起到作用。

十、失效模式自查清单

把前面九节压缩成一张自查表，你可以在一次项目例会上花15分钟走一遍。每条按0分（完全没有）、1分（部分做到）、2分（稳定做到）打分，总分20分。根据我的经验，12分以下的组织大概率存在系统性的计划失效风险，需要从第二章的PMO定位问题开始处理。

这张表我用过很多次，最有意思的发现是：得分低的组织，问题往往集中在第3、7、8三条上，而这三条恰好都不依赖工具，只依赖管理动作。这也再次印证开头的判断，计划管理的瓶颈从来不在软件上。

结语：PMO的价值不在管表，在让计划成为组织共识

回到开头那家工业设备公司的项目。后来我们做的第一件事不是重排甘特图，而是把范围说明书里所有"支持多种""尽快完成"这类表述全部改写成可验收条目，条目数从23条变成了51条。第二件事是把七个关键资源的承诺从口头确认改成书面登记，其中两个当场暴露出无法兑现，项目组据此主动把交付日期往后推了三周。

最终这个项目仍然延期了，但延期从107天变成21天，而且每一步偏差都有据可查、有责任可归。这个结果对我来说已经足够好：计划管理的目标不是让项目不延期，而是让延期变得可见、可解释、可控制。

如果你准备动手，我建议按下面的顺序做三件事，不要贪多。第一周，用第三节的方法改写一份现有项目的范围说明书，看看条目会从多少条变成多少条，那些新增的条目就是你过去半年一直在填的坑。第二周，选出三个关键资源，用第五节的四条信息要求去确认承诺，把没确认的列成清单上报。第三周，把第一章的自查清单发给项目核心成员各自打分，收集回来的分歧本身就是最有价值的诊断信息。

三周之后你大概会拿到一份不太好看的现状数据。别急着修，先把数据留着。因为推进计划管理这件事，最需要的不是一套完美的方案，而是一组能说服别人一起改的事实。