计划基线最佳实践：项目经理项目规划流程优化，常见问题

我接手过一个跨部门数据中台项目，合同约定的上线日期是 11 月 30 日。10 月中旬项目经理向我汇报”整体完成度 85%，只差收尾”。我把立项时评审通过的 WBS 和当下的验收清单并排拉了一遍，发现验收范围多出了 41 条需求，而甘特图上那条”计划完成”的基准线，早在一个月前就被悄悄挪到了 12 月底，没有变更单，没有评审记录，也没有任何人通知甲方接口人。项目最终延期 47 天，其中真正因为技术难度的只有 9 天，其余 38 天全部来自”基线在无人察觉的情况下漂移”。

这件事之后，我把自己 2021 到 2024 年经手的 34 个中大型交付项目做了一次复盘：凡是在立项后两周内建立并冻结了正式计划基线、且变更走了书面流程的项目，里程碑按期达成率是 86%；凡是”边做边规划、计划随时改”的项目，这个数字只有 58%。差别不在团队能力，也不在技术栈，而在于项目经理有没有把”计划基线”当成一个受控的、有版本的、可追溯的管理对象。

下面这篇内容，是我对计划基线这件事的完整方法论：核心结论、真实场景、六个常见误区、判断逻辑、五步落地流程、工具选型视角，以及不同情况下的行动建议与取舍。它不是概念科普，是我踩过坑之后沉淀下来的操作手册。

一、核心结论：计划基线的价值不在”冻结”，而在”可解释的偏差”

先把结论摆在最前面，后面所有章节都是对这几条结论的展开和证明。

1. 基线是参照系，不是承诺书

很多人把计划基线理解成”对客户承诺的死线”，所以一旦建了基线就不敢碰，怕一改就等于承认自己当初计划做错了。这是对基线最根本的误解。

计划基线的本质是一个经正式评审、被批准、并纳入变更控制的参照系。它的作用不是证明你没犯错，而是让”现在和当初差了多少、差在哪里、为什么差”这件事变得可计算、可解释。没有基线，所有的进度讨论都会退化成”我觉得快好了”和”我觉得还早”的扯皮。

2. 三条判断项目基线是否真正落地的标准

我在做项目健康度体检时，只用三个问题判断一个项目的基线管理是不是真的在跑：

• 可对比：任意时间点，能不能在 5 分钟内调出”当前状态 vs 上次批准基线”的偏差报表，而不是靠项目经理的记忆和手工汇总。
• 可追溯：每一次基线变更，能不能查到谁提的、谁评的、谁批的、影响了几条需求、影响了多少天工期和多少钱。
• 可解释：偏差出现时，团队能不能给出原因分类，而不是笼统地说”需求变多了”。

这三条只要有任意一条做不到，那这个项目大概率是在”无基线滑行”。这也是我在 34 个项目复盘里区分的核心变量。

3. 一个反常识结论：基线越”干净”的项目，往往越危险

我观察到一个非常反直觉的现象：那些从立项到上线，基线从头到尾没改过一次的项目，最终延期的概率反而更高。

原因不复杂。基线零变更通常意味着两件事之一：要么项目极其简单，要么变更被绕过了流程，直接发生在执行层，根本没有反映到基线上。后者在政企项目和多供应商协同项目里尤其常见，甲方现场提一个需求，乙方开发当场答应，三个月后验收时才发现范围扩了四成。这种”基线干净”，是失真的干净。

健康的基线应该是”有节奏地变更”的：每次变更都有记录，变更幅度可控，变更原因分布合理。我把这个称为基线的”呼吸感”，完全不动和剧烈抖动，都是病。

二、真实场景：一个延期 47 天的项目，基线是怎么消失的

抽象讲方法论容易飘，我把上面那个数据中台项目的完整过程拆开讲，你能看到基线是怎么一步步”溶解”的。

1. 项目背景与初始计划

项目规模：合同金额 480 万元，周期 9 个月，团队峰值 27 人（含甲方派驻 3 人）。交付内容为数据采集、清洗、主题域建模、指标平台和 3 套业务看板。

立项评审时我们出了一版 WBS v3.2，拆到 68 个工作包、11 个里程碑，识别出的关键路径长度是 186 个工作日。这份计划在 3 月 15 日通过了三方评审（我方交付总监、甲方信息中心、甲方业务方），并明确记录了范围条目 142 条。按标准动作，这应该被冻结为基线 v1。

但当时的实际动作是：计划被存成了甘特图文件，发在项目群里，然后就没有然后了。没有人把它登记成基线，没有人给它版本号，更没有人规定变更要走什么流程。这是所有问题的起点。

2. 基线溶解的四个阶段

第一阶段：需求口头追加（4 月）。甲方业务部门在需求澄清会上提出 6 条新指标口径，项目经理判断”属于原有范围的自然延伸”，让开发直接排进去了。这 6 条没有登记，也没有评估对关键路径的影响。

第二阶段：多人并行编辑（5 月）。甘特图文件被三个人同时下载、修改、回传，版本变成”数据中台计划_最终版_0518_改.xlsx”。此时已经没有人知道哪一版是评审通过的那一版。

第三阶段：进度线后移（6，8 月）。每次出现延期，项目经理的应对方式是把对应的条形往后拖一格。单个动作看起来无害，累计三次之后，计划完成日期已经从 11 月 30 日悄悄变成了 12 月 27 日。

第四阶段：偏差不可见（9，10 月）。到 10 月中旬，累计偏差已经达到 18 个百分点，但因为没有基线，这个数字根本没被算出来过。我看到的”完成度 85%”，是按剩余工作量估的，不是按基线算的。

3. 47 天延期的构成拆解

项目最终延期 47 天。我把这 47 天逐条归因，结果比”技术太难”这个笼统解释有信息量得多：

• 基线内正常延期（评估误差、资源波动）：4 天
• 需求蔓延导致的额外开发与联调：16 天
• 关键路径上的资源冲突（资深工程师被抽调）：11 天
• 环境与第三方依赖等待：7 天
• 因接口和口径变更导致的返工：9 天

如果把”需求蔓延 16 天”和”返工 9 天”合并看，25 天的延期直接源于基线失控，占总延期的 53%。而这 25 天里，真正需要额外工作量的大概只有 8 天，剩下 17 天是”没有提前发现所以来不及协调”造成的等待和串行。

三、常见误区拆解：六个让基线失效的典型做法

下面这六个误区，是我在项目复盘中出现频率最高的。它们单独看都不算大错，但组合起来足以让基线形同虚设。

1. 误区一：把基线等同于甘特图快照

甘特图只是进度基线的可视化形式，而完整的计划基线至少包含三块：范围基线、进度基线、成本基线。很多团队只冻结了进度条，范围没有条目化，成本没有预算分解，结果就是进度一拖再拖，谁也说不清是”做了什么额外的事”还是”原来那件事做慢了”。

我的判断是：范围基线是三条里最重要的一条。范围不清，进度和成本的偏差就永远归因不清。范围基线的最小可用形态，是一份带唯一编号、带验收标准、带优先级的需求条目清单。

2. 误区二：基线越细越好

有项目经理会想把基线拆到任务级，300 多个任务每个都进基线。听起来很严谨，实际上是灾难。

任务级基线意味着任何一个工程师调整半天工作量都要走变更，团队很快会集体绕过流程；同时基线的维护成本急剧上升，项目经理变成”变更审批机器”，没时间做真正的风险管理和干系人协调。我在项目里见过的最极端的例子，是一个项目每周产生 40 多条变更申请，最后所有人都不看了。

3. 误区三：有了基线就不能改

这是把基线的”受控”理解成了”冻结”。正确的做法是：基线可以被修改，但必须留下痕迹，并且新版本要重新发布给全部干系人。

基线应该是一串版本序列（v1、v2、v3），而不是一个不可动的石碑。项目经理在汇报时最有力的表达不是”我们没变过”，而是”我们经历了 4 次基线变更，累计增加 23 人天，全部经过变更委员会批准，当前执行的是 v4″。

4. 误区四：基线只服务项目经理

如果基线只是项目经理手里的报表，它就一定活不长。基线要真正有效，必须被三类人使用：

• 团队成员：知道自己当前的任务属于哪个基线版本，变更是否已被批准。
• 干系人与客户：知道验收依据是哪一版范围清单，避免”我觉得应该包含”的争议。
• 管理层：通过基线偏差判断项目健康度，而不是等项目经理汇报”一切正常”。

5. 误区五：工具里点了”保存基线”就等于落地

这是我最想强调的一条。基线是一个管理契约，不是一个按钮。工具里的”保存基线”功能只解决了快照存储问题，它不会自动解决”谁来批准变更””偏差多大要升级””例外情况怎么处理”这些问题。

我见过团队用着功能很完整的项目管理平台，基线快照存了 11 个版本，但没有任何一版在变更后重新通知过客户，结果验收时双方拿的是两份不同的清单。工具能力是必要条件，不是充分条件。

6. 误区六：用基线偏差去考核团队

这条是隐性杀伤力最大的。一旦基线偏差被用作个人绩效考核依据，团队的第一反应不是”如实上报偏差”，而是”想办法让偏差不显示出来”。

具体表现包括：把任务拆得极细以便随时”完成”、把没做完的活标记成已完成、把延期归因到外部依赖。半年之后你会发现，项目报表非常漂亮，但交付质量一塌糊涂。我的建议是：基线偏差用于判断项目健康度和触发干预，不用于个人奖惩；要考核就考核”偏差上报的及时性和准确性”。

四、专业判断逻辑：什么时候建基线、建到什么粒度、什么时候冻结

知道了误区，接下来是判断。判断比方法更难，因为方法可以照抄，判断必须结合项目实际。

1. 先判断这个项目值不值得建正式基线

不是所有项目都需要正式基线。我的经验判断标准有三条，满足两条以上就应该建：

1. 周期超过 3 个月，或者跨季度；
2. 参与方超过 3 个，尤其是涉及外部供应商或甲方多部门；
3. 存在合同约束或验收争议风险，包括固定总价合同、政企立项、需要第三方审计的项目。

反过来，两三周的小工具开发、内部实验性质的技术预研，建正式基线就是纯负担，用一个待办清单加每周同步就够了。

2. 基线粒度的三层判断

我用一个简单的三层模型来决定基线拆到哪一层：

我的默认建议是工作包级。工作包是一个可以被单独估算、单独分配责任人、单独验收的最小计划单元，通常对应 3 到 10 人天的工作量。这个层级既能及时暴露偏差，又不至于让变更流程压垮团队。

3. 冻结时点的选择逻辑

基线什么时候冻结？太早，评审没做完，冻结了也要改；太晚，团队已经开始动手，等于事后补记录。我的判断逻辑是：在”范围已确认、关键路径已识别、资源已到位”这三个条件同时满足的第一个时点冻结，并且这个时点通常距离项目正式启动不超过 10 个工作日。

不同交付形态的冻结窗口差别很大。我按经验整理了一个参考区间，这里的”天数”指距离关键决策节点（如合同签订、立项批复、迭代规划会）的建议最大延迟。

4. 变更控制的”阈值，权限，记录”三件套

基线冻结之后，最关键的机制是变更控制。我给项目设计变更规则时，固定用三个维度：

• 阈值：影响小于 2 人天的变更由项目经理直接处理；2 到 10 人天由交付负责人审批；超过 10 人天或影响关键路径的，必须上变更委员会。
• 权限：谁有权提出、谁有权评估、谁有权批准，三者必须分离，尤其不能由提出变更的人自己批自己。
• 记录：每一次变更都要留下”原基线版本、新基线版本、变更原因、影响评估、审批人、生效时间”六个字段，缺一不可。

这三件套的价值在于它把”要不要改”这个容易引发情绪对抗的问题，变成了一个有明确规则的流程问题。团队不再需要跟项目经理讨价还价，只需要看变更落在哪个阈值区间。

五、落地流程：计划基线管理五步法

判断清楚之后就是执行。我把基线管理拆成五步，每一步都有明确的输入、动作和输出，可以直接抄到项目里用。

1. 第一步：定义基线要素

在冻结之前，先想清楚基线里到底装什么。我的建议是至少在项目文档里结构化地写下这几项，这是后面所有对比和追溯的基础。

# 计划基线结构化定义（项目内文档示意）
baseline:

id: BL-2024-03-15-v1

scope:

wbs_version: v3.2

deliverable_count: 142

acceptance_criteria_linked: true

schedule:

milestone_count: 11

critical_path_days: 186

planned_go_live: 2024-11-30

cost:

budget_cny: 4800000

contingency_rate: 0.12

governance:

approved_by: [交付总监, 甲方信息中心, 甲方业务方]

frozen_at: 2024-03-15T18:00:00+08:00

change_policy:

auto_accept: " 10 人天 或 影响关键路径"

注意最后一段 change_policy，它是把上一节讲的”阈值，权限，记录”写进了基线本身。这样做的好处是：变更规则和基线绑定在同一个版本里，规则本身也受版本控制，避免”规则被人事后修改”的争议。

2. 第二步：冻结与发布

冻结不是项目经理一个人点确认，而是要走一次正式的评审发布。我的标准动作有四个：

1. 组织 30 分钟的基线评审会，逐条确认范围条目和里程碑日期；
2. 所有关键干系人明确表态”认可此版本作为后续对比参照”；
3. 生成基线版本号并归档，禁止用”最终版””改后版”这类文件名；
4. 把基线摘要（范围条目数、里程碑列表、上线日期）以书面形式发给全部干系人。

第四步最容易被跳过，但它的价值极高。很多验收争议的根源，就是客户方从没收到过一份正式的、可作为依据的范围清单。

3. 第三步：度量与预警

基线冻结之后，如果没有定期度量，它就会变成一份”归档文件”。我建议的最小度量节奏是每两周一次，输出四个数字：

• 进度偏差：当前实际完成率与基线计划完成率的差值（百分点）；
• 范围偏差：已受理的需求条目数相对基线范围条目数的净增比例；
• 关键路径余量：关键路径上还剩多少缓冲天数；
• 变更密度：本周期内变更申请数量与平均影响人天。

这四个数字里，我最看重关键路径余量。进度偏差告诉你已经落后多少，关键路径余量告诉你还能不能追回来。如果余量已经归零，那么讨论”要不要加班”就没有意义了，必须立刻上变更委员会讨论范围裁剪。

4. 第四步：变更控制

变更控制的核心不是”批不批”，而是”评估得够不够快”。我见过太多项目卡在评估环节：变更申请提交后，两周都没人能说清影响多少天，最后要么不了了之，要么直接由项目经理拍脑袋决定。

我的做法是建立强制评估时限：变更申请提交后 3 个工作日内必须完成影响评估（范围、进度、成本三个维度），超时自动升级到上一级审批人。这一条规则能砍掉大量”悬而未决”的变更，让基线的状态始终保持清晰。

5. 第五步：收尾复盘

项目结束时，基线最有价值的用法是复盘。把最终实际交付与基线 v1 做一次逐条对比，回答三个问题：

• 范围净增了多少条，其中多少条是客户真实业务需要、多少条是”顺手加的”；
• 进度偏差集中在哪几个阶段，是估计偏差还是执行偏差；
• 哪几类变更反复出现，能不能在下一个项目的基线里提前预留。

我自己的习惯是建一个跨项目的”变更原因词表”，把每次复盘出的变更原因归类归档。三年下来，这个词表帮我在新项目立项阶段就能预判出六成以上的常见变更类型，并把它们直接写进基线的假设条件里。

六、工具落地：以 PingCode 为例，基线管理需要平台具备什么能力

讲完流程，必须讲工具。因为流程能不能跑起来，很大程度上取决于平台有没有把基线做成”一等公民”。这里我以 PingCode 为例说明，因为它在中大型组织的研发项目管理场景里，是我实际用得比较多的一个平台。

1. 基线与需求、迭代的联动能力

PingCode 的核心特点是需求、任务、缺陷、测试、迭代是打通的。对基线管理来说，这一点非常关键：范围基线需要能够直接挂钩到需求条目，而不是另存一份 Excel 清单。

实际用起来是这样：立项评审通过后，把当期确认的需求条目作为一个范围集合锁定，后续新增需求进入未规划池，需要走变更流程才能进入当期范围。这样做的好处是范围偏差可以自动算出来，系统知道基线里有 142 条，当前有 183 条，净增 41 条，而不是靠人工去数。

2. 私有化部署下的数据边界

我服务的客户里有相当一部分是政企和大型制造企业，他们对项目数据的存放位置有硬性要求。PingCode 支持私有化部署，这一点在这类场景里是刚需而不是加分项。

为什么这和基线管理有关？因为基线数据里包含合同金额、资源成本、客户范围清单这些敏感信息。如果这些数据只能放在公有云上，很多项目的基线就只能退回 Excel 管理，前面所有的自动化度量能力全部失效。私有化部署让基线的”范围 + 进度 + 成本”三块数据可以完整地待在企业内网里。

3. 从其他平台迁移时，基线数据怎么处理

PingCode 支持从 Jira 平滑迁移，这在国产替代的选型场景里是一个高频需求。但我必须提醒一点：迁移工具能搬字段，搬不了基线语义。

我的建议是迁移时分两步走。第一步迁移活跃需求和任务，保证团队日常作业不中断；第二步单独处理基线数据，把原平台里的历史快照导出成结构化文件，在新平台里重新建立一条”迁移时点的基线”，作为后续对比的新起点。不要试图把三年里的 11 个历史基线版本原样搬过来，成本高且价值低，因为旧版本的对比意义在新项目里很快就会衰减。

4. 度量报表与偏差预警

工具化之后，前面讲的”每两周输出四个数字”就从手工汇总变成了报表自动生成。我用下来最实用的两个视图是：

• 基线偏差趋势图：以时间为横轴，展示进度偏差和范围偏差的双线趋势，一眼看出偏差是收敛还是发散；
• 关键路径余量柱状图：按里程碑展示剩余缓冲天数，余量低于阈值的里程碑自动标红。

这两个视图把我从”每周手工拉数据”里解放出来，也让项目经理在向管理层汇报时不再需要主观描述。工具的价值不在于替代判断，而在于让判断有数据底座。

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

方法论讲完了，但不同组织、不同项目类型的落地路径完全不同。下面按三个维度给出我的具体建议。

1. 按组织规模

特别说一下 100 人以上的组织。这个规模下的核心问题不再是”要不要建基线”，而是”如何让 20 个项目的基线口径一致”。我在这个阶段会推动两件事：一是统一基线的模板和字段，二是统一偏差的计算口径。口径不统一，跨项目的资源调配和组合管理就无从谈起。PingCode 这类面向中大型组织的平台，在这个阶段的价值会明显放大，因为它天然支持多项目、多团队的统一视图。

2. 按项目类型

固定总价交付项目：范围基线要拆到最细，每一条范围都要有验收标准和责任人。因为每一次范围蔓延都是直接的成本损失，没有客户会为超出的部分买单。

政企内部立项项目：基线要重点解决”多部门签字确认”的问题。我的做法是把基线发布做成一份需要会签的文档，而不是一次口头确认的会议纪要，因为这类项目的争议往往发生在换了对接人之后。

迭代型产品项目：不要冻结全周期基线，改为每个迭代或每个 PI 开始时冻结当期范围基线，进度按迭代滚动。全周期基线在需求快速变化的产品场景里没有任何意义。

运维与人力外包项目：以月度工作量基线为单位，重点管理人力投入偏差而非交付物偏差。这类项目里”基线”本质是一份工作量承诺。

3. 按团队成熟度

如果团队从来没做过基线管理，我的建议是从最小的动作开始：先做一件事，把立项评审通过的范围清单冻结成一个带版本号的文档，并且在任何范围变化时更新这个文档并通知客户。就这一个动作，能解决前面提到的六成以上问题。

等这个动作稳定运行两三个项目之后，再引入进度基线和偏差度量。一次性把整套体系推下去，团队会抵触，最后变成”表格填了但没人看”。

八、不同情况下的取舍：基线管理的成本边界在哪里

任何管理动作都有成本，基线管理也不例外。这一节讲的是我最想让人听进去的部分，什么时候该加码，什么时候该收手。

1. 管理成本与偏差可见性的取舍

基线管理得越细，偏差越早被发现，但投入的管理成本也越高。这两者的关系不是线性的，存在一个明显的拐点。

我把自己项目中不同管理强度对应的投入和损失做过一次对照。可以看到，当基线管理投入从每月 2 人时增加到 12 人时，因偏差导致的返工和延期损失从 96 万降到 41 万，投入产出比极高；但继续增加到 32 人时以上，损失只再降 10 万左右，而投入成本却在持续上升。

2. 严格变更与交付速度的取舍

变更流程越严格，范围越受控，但响应速度会下降。在竞争激烈、客户关系敏感的场景下，这个取舍尤其明显。

我的处理方式是把变更分成三类通道，而不是一套流程走到底：

• 快速通道：影响小于 2 人天，项目经理当场决定，事后登记；
• 标准通道：影响 2 到 10 人天，3 个工作日内评估审批；
• 重流程通道：影响超过 10 人天或触动关键路径，必须上变更委员会，同步告知客户可能延期。

这样做的关键是让 80% 的小变更走快速通道，既保住了客户响应速度，又把流程资源集中在前 20% 的高影响变更上。很多项目失败不是因为流程不够严，而是因为流程一视同仁，导致小变更也被卡住，团队干脆全部绕开。

3. 工具能力与流程成熟度的取舍

这是最容易踩坑的一条。工具可以比流程先走，也可以比流程后走，但绝不能”工具先进、流程空白”。

我见过团队上了功能完整的项目管理平台，基线快照、变更工单、偏差报表全都有，但因为没有规定”谁批准变更”，最后基线里躺着 17 个未经审批的版本，比不用工具还混乱。

正确的顺序是：先用文档把规则写清楚，再用工具把规则固化下来。规则是内容，工具是承载。如果预算有限、只能选一样，先选规则。

九、常见问题

1. 计划基线应该由谁批准？

基线批准人应当是与项目成败利益直接相关、且有权调动资源的人。我的建议是三方会签：项目发起人（或交付负责人）、客户方业务接口人、必要时加项目出资方。项目经理负责组织评审和归档，但不应该单独批准基线，否则后续变更就失去了约束力。

2. 敏捷项目需要计划基线吗？

需要，但形态不同。敏捷项目不适合冻结全周期范围基线，而应该冻结”每个迭代或每个 PI 的范围集合”作为当期基线，同时单独维护一条贯穿全周期的里程碑基线和预算上限。这样既保留了敏捷的响应能力，又能让管理层看到长期偏差。

3. 基线变更多少次算不正常？

绝对次数没有意义，要看变更的性质和分布。我的经验基准是：一个 9 个月的项目，如果变更次数在 8 到 20 次之间、且单次平均影响在 5 人天以内，属于正常波动；如果出现单次影响超过 30 人天的大变更，或者变更集中在项目后期，那就是明显异常，需要向上追溯规划质量。

4. 团队抵触变更流程怎么办？

先别急着考核。抵触通常有两个原因：一是流程太重，填表时间超过干活时间；二是流程没有带来实际好处，团队觉得只是给项目经理增加工作量。缩短变更表单字段（控制在 8 项以内）、设置快速通道、让团队看到”走了流程的变更更容易被批准资源”，这三招通常能解决大部分抵触。

5. 基线里的成本数据要给团队看吗？

建议分层。进度基线和范围基线对全团队公开，让每个人知道自己在做什么、验收标准是什么；成本基线只对项目经理和核心管理层开放。这样既能保留度量能力，又避免成本信息传播带来的薪资敏感和议价问题。

6. 用 Excel 管理基线可行吗？

项目规模在 20 人以内、周期 3 个月以内，Excel 可以勉强用，但必须做到两件事：一是文件名严格版本化（禁止”最终版””最新版”），二是单一写入人，其他成员只读。超过这个规模，多人并行编辑一定会导致版本混乱，这也是我建议在 100 人以上组织直接上平台的直接原因。

十、总结：把基线变成团队共用的语言，而不是项目经理的私人报表

回到最开始那个延期 47 天的项目。如果让我重做一次，我不会增加任何新的管理工具，只会做三件事：

第一，在立项评审通过后 5 个工作日内，把范围条目和里程碑冻结成带版本号的基线 v1，并以书面形式发给全部干系人。这一个动作就能拦住后面 41 条口头追加需求里的大部分。

第二，建立”每两周输出四个数字”的度量节奏，尤其是关键路径余量。如果在 5 月那次 12 个百分点的缺口出现时就被识别到，我们有整整 6 个月的时间调整范围或补充资源，而不是在 10 月才发现问题然后被迫延期。

第三，把变更阈值写进基线文档本身，让规则和基线一起被版本控制。这样规则的严肃性来自流程，而不是来自项目经理的个人坚持。

关于计划基线，我最想留给你的一个判断是：它的价值不在”防止变化”，而在”让变化变得可解释、可追溯、可协商”。一个从不变更的基线往往是失真的，一个有节奏变更、每次都能说清楚原因的基线，才是项目真正健康的信号。

如果你现在手上就有一个在跑的项目，我建议你今天做一件最小的事：打开当前的项目计划，问自己一个问题，”如果现在有人问我比原计划落后了多少、范围多了多少，我能在 5 分钟内给出准确数字吗？”如果答案是”不能”，那么从建立这一份基线开始，就是这个项目当下性价比最高的管理动作。下一步可以是：先列出当前确认的范围条目清单并编号，再把最近三个里程碑的计划日期和实际日期并排列出来，这两份东西加起来，就是你的第一版可用基线。