项目规划如何做好主计划？管理层制度设计与操作步骤

2023 年夏天，我受邀去一家年营收 18 亿的装备制造企业做项目管理体系复盘。这家公司不缺流程文件：他们有一本 62 页的《项目计划管理办法》，有 PMO，有每周一次的项目例会，还有一套看起来很完整的主计划甘特图。问题出在交付上，当年 14 个重点项目，只有 4 个按原定里程碑完成，平均延期 47 天，最长的延了 113 天。

我没有先看甘特图，而是先要了三样东西：最近半年的变更台账、最近六次计划评审会的签字记录、以及这 14 个项目在立项时对资源的口头承诺记录。结果是：变更台账有，但只记录了 21 条，而项目群里实际发生的需求变动我数出来 90 多条；评审会签字记录很齐全，但签字的人里没有一个职能部门负责人；资源承诺全是会议纪要里的一句“各部门支持”，没有具体到人、到天、到比例。

这就是我这些年反复看到的一个结构性事实：主计划做不好，绝大多数时候不是工具问题，也不是项目经理不会画甘特图，而是管理层没有为“计划”这件事设计过制度。计划本身是一个技术活，但让计划有权威、能被跨部门执行、能在变更中不失控，那是一个治理活。技术活交给项目经理，治理活只能管理层自己干。

这篇文章我想把这件事拆干净：主计划到底是什么、和项目计划怎么划边界、管理层要设计哪六个制度机制、操作上有哪八步、模板和指标怎么落、什么情况下该重、什么情况下该轻。全部基于我自己做过和看过的项目，不是教科书复述。

一、先给结论：主计划的成败，八成在制度，两成在工具

先把结论摆在前面，免得你读到一半才发现方向不对。

第一，主计划不是一张图，是一套“总调度契约”。它约束的是多个项目、多个部门、多个资源池之间的关系，而不是某一个项目的进度。你把它做成一张漂亮的甘特图，它依然可能一执行就散。

第二，主计划失效的核心症状，几乎总是“三个没有”：没有冻结的基线、没有代价的变更、没有承诺的资源。这三个“没有”，靠项目经理喊是喊不出来的，只能靠制度设计出来。

第三，管理层在主计划里的角色不是审批人，是承诺人和仲裁人。只签字不承诺资源的审批，本质上是一种责任转移，不是治理。

我在 2022 到 2024 年间，完整参与或深度复盘过 12 个“主计划失效”的项目群案例。按我自己归因的根因分类，分布是这样的（示意数据，基于我的项目复盘样本，非行业统计）：

为什么制度问题占比这么高？因为主计划天然是“逆人性”的。它要求各部门在信息不完全的时候，先把资源承诺出来；要求项目负责人在还没看到收益的时候，先接受进度约束；要求管理层在自己的部门目标和公司整体目标冲突时，做出取舍。没有制度兜底，任何一次冲突都会让主计划往后退一步，退到最后就成了一张废纸。

二、主计划、项目计划、部门计划：三层边界必须先讲清楚

我见过的混乱，一半来自概念没统一。同一个会议室里，老板说的“主计划”是年度经营计划里的项目总盘，PMO 说的“主计划”是多项目资源排布，项目经理说的“主计划”是他自己那个项目的 WBS。三个人在谈三件事，会开三小时也谈不拢。

1. 主计划管“关系”，项目计划管“执行”，部门计划管“产能”

我自己的定义是这样，你可以拿去和团队对齐：

• 主计划：连接战略目标和多个项目的总纲，管的是项目之间的优先级、共享资源的分配节奏、跨项目依赖、整体预算池和治理规则。它的最小单位通常是“里程碑”和“资源包”，不是“任务”。
• 项目计划：单个项目内部的执行方案，管的是范围、进度、成本、质量、风险和交付物。它的最小单位是“工作包”和“任务”。
• 部门计划：职能部门的产能与工作安排，管的是人力排班、日常运营、能力建设。它不直接对项目结果负责，但对项目资源供给负责。

三层计划的关系不是包含关系，是接口关系。主计划通过“资源包”和“里程碑”向项目计划下达约束，通过“资源预留比例”向部门计划下达约束。如果主计划直接拆到了任务级，它就已经降级成了项目计划，失去了跨部门调度的视野。

2. 三者最容易被混淆的四个场景

（1）把主计划做成项目计划的汇总。PMO 把 14 个项目的进度表拼在一起，起名叫主计划。这种汇总表只能看“有没有延期”，看不出“资源是否冲突”“依赖是否断裂”，因为每个项目自己排的时候都假设资源是无限的。

（2）把部门计划当成资源承诺。部门交了一份年度工作计划，里面写着“支持重点项目”。这不是承诺，是表态。真正的资源承诺必须落到“哪个岗位、哪个名字、几月到几月、投入百分比”。

（3）把主计划的变更当成项目变更。项目层面改个里程碑，如果它占用了共享资源或影响了其他项目，那就是主计划级变更，必须走主计划的审批通道。

（4）把主计划的评审当成形式过会。评审会开完，基线没冻结，两周后有人又改了日期，没人记录，这次评审就等于没开。

三、真实场景：我见过的三种典型失败形态

概念说完了，说点具体的。下面三种形态我在不同公司反复见，每一种都有明确的成因和解法。

1. 汇总型主计划：看着齐，一碰就散

某消费品公司，PMO 用一张 Excel 汇总了 23 个项目的里程碑。表面上看，全年节点清清楚楚。真正执行时，问题在第三个月集中爆发，三个项目同时要占用同一个测试团队，而这个团队只有 6 个人。

根本原因是：汇总不等于统筹。每个项目在排自己计划时，都默认“测试资源我随时能用”，汇总的时候也没有人去做资源碰撞检测。所以这张表反映的是 23 个理想世界，不是 1 个真实世界。

解法很直接：在形成主计划草案之前，必须做一次共享资源的需求叠加和冲突识别，冲突解决不了的项目，优先级就要往后排。这一步不做，主计划就是废纸。

2. 甘特图型主计划：精度很高，权威为零

某软件公司，项目经理花了三周做出一版颗粒度到天的项目群甘特图，2000 多行。评审会上各部门都点头。三个月后我再看，这张图已经没人打开了，因为这张图从评审通过的那天起就没冻结过基线，谁都可以改，改完也没人通知别人。

精度和权威是两件事。精度解决“看得清”，权威解决“改不动”。没有变更控制机制，精度越高，维护成本越高，废弃得越快。

3. 汇报型主计划：只报进度，不报风险

某工程企业，每周项目例会汇报 14 个项目的完成百分比。我连续看了六周的会议纪要，发现一个规律：风险项永远是“暂无”，而延期永远是在截止日前一周才被提出来。

这不是项目经理不诚实，是制度设计的问题，如果一个组织的例会只考核“有没有按期完成”，不鼓励提前暴露风险，那理性的做法就是把风险藏到最后一天。要改，必须让“提前识别风险”变成加分项，而不是“暴露问题”变成扣分项。

四、管理层制度设计：让主计划有权威的六个机制

下面这六个机制，是我在多家企业落地后收敛出来的一套组合。它们不是并列关系，有先后依赖，但必须成套存在，缺一个，主计划的权威就会从那个缺口漏掉。

1. 治理与权责机制：先决定谁说了算

目的：让每一个争议都有一个确定的、事前约定好的裁决点，而不是每次都找老板拍板。

制度条款建议写清楚四类角色：

• 项目决策委员会：由总经理或分管副总牵头，成员包含各职能负责人。职权是定优先级、批主计划基线、批重大变更、裁决资源冲突。建议每月一次固定会，紧急事项可临时召集。
• PMO / 计划管理岗：负责主计划的编制组织、冲突识别、基线维护、变更台账、数据统计。职权是"能不能上会"，不是"批不批"。
• 项目负责人：对单项目交付结果负责，有权在批准的范围和预算内自主调度。
• 职能经理：对资源供给质量和产能负责，必须书面承诺资源，并对承诺负责。

落地动作：把上面四类角色写成一页权责表（RACI），明确每类决策的"提议，审核，批准，知会"四种角色分别是谁。这张表必须由管理层签发，不能由 PMO 自己发。

常见坑：委员会成员只派代表参会，代表没有决策权。这会直接导致所有决议在会后被推翻。制度里必须写明：代表必须获得授权，否则会议决议无效。

2. 立项与优先级机制：决定什么该进主计划

目的：控制入口。主计划失控很多时候不是执行不好，是入口太松，什么都往里塞，资源自然不够分。

我建议的评分模型包含五个维度，每个维度 1-5 分，加权总分决定优先级：

落地动作：每季度做一次项目组合评审，把总分低于阈值的项目明确"暂缓"而不是"继续观察"。暂缓和继续观察有本质区别：前者释放资源，后者占用资源。

常见坑：只评分不排序。评分结果必须转成一个明确的资源分配顺序，否则评分也是一场表演。

3. 计划评审与基线机制：把"通过"变成"冻结"

目的：让主计划有一个不可随意改动的参照点。没有基线，就没有偏差，也就没有管理。

评审要审四样东西，缺一不可：

1. 目标与成功标准是否可衡量，"提升客户满意度"不是标准，"续约率从 78% 提到 85%"才是。
2. 范围边界是否闭合，明确写清"本阶段不做什么"，比写清"做什么"更重要。
3. 里程碑是否可验证，每个里程碑必须有一个客观的完成判据，比如"通过 X 测试用例"或"完成 X 份合同签署"。
4. 资源是否具体承诺，具体到岗位、姓名、投入比例、起止月份。

落地动作：评审通过当天，主计划版本号锁定为 V1.0-Baseline，写入配置库，任何人改动必须走变更流程。基线冻结不是不让改，是让改有代价、有记录、有审批。

常见坑：评审会当场"原则通过"，会后修改后再发。这一改，基线概念就没了。正确做法是：要么当场通过并冻结，要么明确不通过并约定下次评审时间。

4. 变更控制机制：让变更变贵但不变得不可能

目的：不是阻止变更，而是让变更的代价可见、可控、可追溯。

我建议按影响面分三级：

• 一级变更（重大）：影响主计划基线里程碑、跨项目依赖、共享资源超 15% 或预算超 10%。审批权在项目决策委员会，必须做完整影响分析。
• 二级变更（中等）：影响单项目内部关键路径或预算 5%-10%。审批权在 PMO 加项目负责人，需登记台账。
• 三级变更（轻微）：不影响里程碑和预算的细节调整。项目负责人自行记录，月度汇总上报。

影响分析必须回答三个问题：推迟什么、影响谁、谁承担代价。只回答"需要延期 10 天"的变更申请，一律退回。

变更申请单建议字段（可直接做成系统表单）
————————————————

变更编号: CR-2024-0142

提出人 / 日期: 张XX / 2024-06-11

所属项目: P-07 智能产线改造

变更级别: 一级

变更内容: 新增视觉检测模块联调环节

变更原因: 客户 6/10 现场评审提出，属合同范围外

影响分析:

里程碑影响: M3 由 07-20 推迟至 08-05（+16 天）

跨项目影响: P-11 共用测试工程师 2 人，冲突 8 人天

成本影响: 预算增加 38 万元（原预算 6.2%）

质量影响: 联调测试用例需增加 24 条

缓解方案: 测试资源由外部供应商补充 2 人（周期 3 周）

决策结论: 批准 / 有条件批准 / 驳回

决策人 / 日期: 项目决策委员会 / 2024-06-13

台账登记: 是

常见坑：变更没有级别，全部走同一条流程。结果是小事流程太重、没人愿意提，大事流程太轻、批得太随意。分级是让流程"贵得合理"。

5. 报告与例会机制：让信息在正确的时间到正确的人

目的：把"事后知道"变成"提前预警"。

我建议三层节奏：

• 周报（项目层）：只报三件事，本周里程碑状态（红/黄/绿）、下周关键风险、需要哪一级支持。控制在 1 页以内。
• 月度主计划评审（PMO 层）：看整体里程碑达成率、资源冲突数、变更台账、跨项目依赖状态。重点是趋势，不是单点。
• 季度项目组合复盘（决策委员会层）：决定项目是否继续、暂停、终止，调整优先级和资源池。

红黄绿的定义必须量化，不能靠感觉。我的建议：绿 = 无偏差或偏差≤3%；黄 = 偏差 3%-10% 且已有缓解方案；红 = 偏差>10% 或无有效缓解方案。

常见坑：周报里没有风险项就写"无风险"。这会导致周报变成形式。更好的做法是：如果连续三周报"无风险"，PMO 应该主动去查，因为完全没风险的项目往往意味着风险没被识别。

6. 考核与复盘机制：让制度长出牙齿

目的：让"按制度做事"和"个人利益"一致。这是最容易被跳过、也最不能跳过的一环。

考核指标不要全压在进度上，我建议按四类设计：

特别提醒一点：职能经理的考核里必须包含"资源承诺兑现率"。没有这一条，资源承诺永远是空话。这是我见过最有效的一个单点改动。

落地动作：每个项目结项后 15 个工作日内做一次复盘，输出"三件事"，做对了什么、做错了什么、制度上要改哪一条。复盘结论必须有人认领整改，否则复盘会变成故事会。

五、操作步骤：八步做出一版真能执行的主计划

制度是规则，步骤是动作。下面八步是我做项目群主计划时的标准动作，每一步我都标注了输入、关键动作、输出物和管理层检查点。

1. 对齐战略目标与成功标准

输入：公司年度战略重点、经营目标、上一年度复盘结论。

关键动作：把每个战略重点翻译成"项目群要达成的结果"，而不是"要做的事"。比如从"提升交付能力"翻译成"平均交付周期从 92 天压到 75 天"。

输出物：一页纸的《主计划目标与成功标准》，包含 3-5 个核心目标和对应的衡量口径。

管理层检查点：每个目标是否有唯一负责人？衡量口径是否可以在季度末用数据验证？

2. 界定范围与交付物边界

输入：目标定义、项目组合清单。

关键动作：明确本轮主计划覆盖哪些项目、不覆盖哪些项目；明确每个项目的核心交付物和明确排除项。

输出物：《范围说明书》，包含"包含项"和"排除项"两栏。

管理层检查点：排除项是否经过管理层确认？范围外的事项是否有明确的进入通道？

3. 拆解里程碑与工作包

输入：范围说明书。

关键动作：先在项目群层拆出 6-12 个跨项目关键里程碑，再在每个项目内拆到工作包（不要拆到任务级）。工作包的粒度标准是：可以估算、可以分配、可以验证。

输出物：项目群里程碑清单 + 各项目工作包清单。

管理层检查点：里程碑是否可验证？是否有"完成 80%"这种无法判定的表述？

4. 估算工期、成本与资源

输入：工作包清单、历史项目数据。

关键动作：三点估算（乐观/最可能/悲观），并对关键路径上的工作包做独立复核。资源估算必须落到"岗位 + 人天 + 时间窗口"，不能只写"需要开发 2 人"。

输出物：工期估算表、成本预算表、资源需求表。

管理层检查点：关键岗位的资源需求，是否已经和相关职能经理见过面并达成初步共识？

5. 识别依赖、风险与假设

输入：里程碑清单、资源需求表。

关键动作：做两件事，跨项目依赖矩阵、风险登记册。依赖矩阵要标出"谁在等谁""等多久""一旦延迟影响多大"。

输出物：依赖矩阵、风险登记册（含概率、影响、应对策略、责任人）。

管理层检查点：排名前 5 的风险，是否每一项都有明确的应对责任人和触发条件？

6. 形成主计划草案与备选方案

输入：前五步的全部输出。

关键动作：先做一次共享资源的需求叠加，识别冲突；再针对冲突给出 2-3 个方案，比如"降低并行度延长总工期""追加外部资源""调整优先级暂缓部分项目"，并明确每个方案的代价。只给一个方案的主计划，等于没有选择。

输出物：主计划草案（含资源冲突清单和备选方案对比）。

管理层检查点：备选方案的代价是否被清晰列出？决策委员会是否理解每个选择的后果？

7. 评审、签署并发布基线

输入：主计划草案。

关键动作：召开主计划评审会，逐项确认目标、范围、里程碑、资源承诺、风险。通过后立即冻结基线，版本号写入配置库，全员通知。

输出物：V1.0-Baseline 主计划、签署记录、资源承诺书。

管理层检查点：资源承诺是否具体到人？基线是否已冻结并通知到所有相关方？

8. 监控、变更、纠偏与复盘

输入：冻结的主计划基线、监控机制。

关键动作：按周监控里程碑状态，按月评审主计划健康度，按变更分级处理变更，按季度做组合复盘。纠偏动作必须有负责人和完成时间。

输出物：周度状态报告、月度主计划健康度报告、变更台账、季度复盘报告。

管理层检查点：连续两个月红黄灯的项目，是否已经启动升级处理？变更台账的完整性是否被抽查过？

六、模板与指标：一页主计划、三张表、五个指标

制度定方向，步骤定动作，模板定效率。我给团队用的标准配置是"一页 + 三表 + 五指标"，这套配置的好处是：管理层看得懂，PMO 维护得起，一线填得完。

1. 一页主计划：七块内容，控制在一页

核心逻辑是：如果一页纸说不清，说明还没想清楚。

• 目标块：3-5 个核心目标 + 衡量口径
• 范围块：包含项、排除项
• 里程碑块：6-12 个跨项目关键里程碑及日期
• 预算块：整体预算池 + 分项目预算
• 资源块：关键岗位的资源预留比例
• 风险块：Top 5 风险及应对责任人
• 治理块：决策委员会成员、评审节奏、变更审批权限

2. 三张表：里程碑清单、权责表、台账

（1）里程碑清单表：字段包括里程碑名称、所属项目、计划日期、完成判据、责任人、当前状态、最新预测日期。

（2）RACI 权责表：行是主计划相关的关键决策事项，列是四类角色（提议、审核、批准、知会），每格填具体角色名。

（3）风险与变更台账：这两本账建议合并在一个系统里，因为变更往往源于风险，风险往往引发变更。

3. 五个指标：不要超过五个

这里我特别想强调"变更受控率"这个指标。大多数企业只看变更数量，越少越好，结果逼着团队私下改计划。而变更受控率看的是"变更有没有走流程"，它鼓励的是透明，不是压制。这是我建议所有 PMO 优先引入的单指标。

七、工具支撑：制度跑起来之后，靠什么承载

我前面一直在说"工具不是根本原因"，但这不等于工具不重要。真实的经验是：制度决定能不能管住，工具决定能不能坚持下去。尤其是变更台账、跨项目依赖、资源冲突检测这三件事，纯靠 Excel 和微信群，几乎不可能在超过 15 个项目的规模下维持三个月以上。

1. 什么时候必须上系统

我自己的判断门槛是三条，命中任意两条就该考虑系统化：

• 并行的主计划级项目超过 15 个
• 共享资源池涉及三个以上部门
• 月度变更数量超过 20 条，且需要跨部门审批

低于这个规模，用规范的模板加严格的管理动作反而更划算，不必为了工具而工具。

2. 选型时我会重点看的六个维度

（1）多项目资源视图：能不能做资源需求叠加和冲突可视化，这是主计划工具的核心能力，很多工具只有单项目视图，不满足主计划场景。

（2）变更流程与台账的一体化：变更申请、影响分析、分级审批、台账登记是否在同一个对象上完成，而不是申请在 OA、记录在 Excel。

（3）依赖关系管理：跨项目依赖能不能建立、能不能预警，这是最容易缺失的能力。

（4）权限与治理结构映射：能不能把决策委员会、PMO、项目负责人、职能经理四类角色映射到系统权限，并支持变更审批分级。

（5）部署与合规：是否支持私有化部署，数据是否可控，能否满足企业信息安全和审计要求。

（6）迁移与过渡成本：是否能从现有工具平滑迁移，历史数据能否保留，团队学习成本有多高。

以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，在资源视图、多项目协同、变更流程配置上的适配度相对贴近主计划这类跨部门治理场景；同时它支持私有化部署，支持从 Jira 平滑迁移，对于正在做国产替代、又不想承担二次迁移风险的组织来说，是一个值得纳入对比清单的选项。我在给企业做选型建议时，一般会把它和另外两三个候选一起放进打分表，按上面六个维度加权评分，而不是直接推荐单一产品。

八、常见误区：这七个坑我几乎每家都能见到

误区不需要多讲道理，我把它们和对应的解法列在一起，你对照自查就行。

1. 把主计划当甘特图

甘特图是表达工具，不是管理对象。主计划的管理对象是里程碑、资源、依赖和变更。解法：主计划的一页纸里，甘特图只占一块，不是全部。

2. 管理层只审批、不承诺资源

这是最致命的。审批通过但没有资源承诺，等于把责任推给了项目负责人。解法：把"资源承诺书"设为主计划评审的必备附件。

3. 没有基线，或者基线随便改

没有基线就没有偏差管理，所有的"进度正常"都是自我安慰。解法：版本号冻结 + 变更走流程，改动必须有代价。

4. 制度太复杂，一线不执行

我见过一份 42 页的计划管理制度，一线根本没人读完。解法：制度正文控制在一页，配套表格不超过三张，其余内容放进操作手册。

5. 只考核进度，不考核价值和风险

只考核进度会导致团队"按日期交付一个没价值的东西"。解法：把交付质量合格率和风险预警及时率纳入考核。

6. 用概念科普替代治理设计

把项目管理过程组背得很熟，但没人签资源承诺书、没人管变更台账。解法：先解决权责和承诺，再谈方法论。

7. 复盘只找责任，不找制度缺陷

复盘变成批斗会，第二次复盘没人愿意说真话。解法：复盘输出必须包含"制度上要改哪一条"，且这条必须有人认领。

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

没有任何一套制度适合所有组织。下面是我基于组织规模、成熟度和项目复杂度给出的分类建议，你可以对号入座。

1. 按组织规模选择落地力度

（1）100 人以下、项目数少于 10 个。不要搞委员会和复杂评审。建议只做三件事：一页主计划、双周例会、简单变更登记。工具用现有的协作平台即可，重点是把基线概念建立起来。

（2）100-500 人、项目数 10-30 个。这是最容易失控的区间。建议完整落地前四个机制（治理权责、立项优先级、评审基线、变更控制），报告机制简化，考核先不挂钩。工具建议上系统，因为 Excel 在这个规模下必然失控。

（3）500 人以上、多事业部并行。六个机制全上，且必须先解决治理结构问题，谁是最终裁决人、跨事业部资源怎么协调。这个规模下，工具选型要重点看私有化部署能力和权限隔离能力，因为数据边界和审批边界必须一致。

2. 按项目复杂度选择制度重量

复杂度可以从"跨部门数量"和"不确定性高低"两个维度看。跨部门越多，治理机制必须越重；不确定性越高，计划精度反而要越粗、节奏要越密。

一个反直觉但很实用的原则：高不确定性的项目，主计划应该"里程碑粗、检查密"。把里程碑定到季度级别，但每周检查一次假设是否还成立。反过来，低不确定性、高跨部门的项目，则应该"里程碑细、检查疏"，因为变化少，重点在协调而不在预警。

3. 明确取舍：三个必须做出的选择

取舍一：要控制力，还是要速度。加一级审批就多一层控制，也多一天延迟。我的建议是：一级变更必须上委员会，但规定委员会必须在 3 个工作日内给出结论，超时视为默认通过。这能同时保住控制和速度。

取舍二：要计划精度，还是要维护成本。颗粒度到天的计划，维护成本大约是到周的 3 倍以上，且在高不确定性项目里几乎没有额外价值。我的建议是：主计划层面到周，项目计划层面到天，两层分开维护。

取舍三：要全面上线，还是要单点突破。六个机制一起上，大概率三个月后全部流于形式。我的建议是：先上"评审基线 + 变更控制"这两个抓手最直接的，跑通两个项目周期后再扩。

十、30/60/90 天落地路线与下一步动作

最后给一条可执行的时间线。这条路线我在两家企业实际跑过，节奏偏保守但胜在不容易反弹。

1. 第一个 30 天：统一语言，跑通试点

• 第 1 周：管理层开一次专题会，确认主计划的定义、三层边界、以及本文提到的六个机制要不要上、先上哪几个。
• 第 2 周：发布一页主计划模板、RACI 权责表模板、变更申请单模板。三个模板，不多不少。
• 第 3-4 周：选 2-3 个跨部门项目做试点，完整走一遍八步法，产出一版冻结的 V1.0-Baseline。

这 30 天的唯一目标是：让团队亲眼看到"基线冻结"和"变更走流程"是怎么运作的。不要追求覆盖全部项目。

2. 第 31-60 天：建立评审、变更、报告三条线

• 固化月度主计划评审会节奏，固定参会人，固定议程（里程碑、资源冲突、变更台账、依赖状态）。
• 上线变更分级标准，所有变更进入统一台账，开始统计"变更受控率"。
• 建立周报红黄绿量化定义，连续三周报"无风险"的项目由 PMO 主动复核。
• 如果项目数超过 15 个，这个阶段应该同步启动工具评估和部署准备。

3. 第 61-90 天：纳入考核，扩面复制

• 把"资源承诺兑现率"写入职能经理考核，把"变更受控率"写入项目负责人考核。
• 试点项目做第一次结构化复盘，输出"制度要改哪一条"并完成整改。
• 把试点经验复制到下一批项目，同时把主计划覆盖范围扩大到全部一级项目。

回到开头那家装备制造企业。他们在半年后做了一轮复查，14 个重点项目里有 11 个按基线交付，平均延期从 47 天降到 9 天。他们没有换工具，也没有增加人手，真正改的只有三件事：把资源承诺从会议纪要里的一句话变成了一页签字确认的资源承诺书；把变更从"随时改"变成三级审批加统一台账；把职能经理的考核里加进了"资源承诺兑现率"这一项。

所以我的核心观点是：主计划不是一个项目管理的技术问题，而是一个组织治理的设计问题。项目经理能画出最好的甘特图，但画不出权威；权威只能由管理层通过制度授予。你在制度上省下的每一点力气，都会在执行阶段以三倍的返工还回来。

如果你打算马上动手，我建议下一步只做一件事：把本文第四章的六个机制做成一张对照表，逐条标注"已具备 / 部分具备 / 完全缺失"，然后从"完全缺失且影响最大"的那一条开始。不要试图一次上齐六个，那几乎注定失败。先让一个机制真正跑起来，让组织感受到"计划是算数的"，剩下的机制会容易得多。