计划基线流程与规范：项目负责人项目规划最佳实践关键指标

去年冬天，我参加一家制造企业的年度项目复盘，会议开到一半，业务负责人问了一句：“这个项目最初的计划到底是哪一版？”会议室安静了大约十秒。项目经理从文件夹里抽出三份带日期的计划表，分别是立项版、八月修订版和十一月修订版，三份都盖过部门章，但没有一个人能说清哪一份是当前生效的基线。更尴尬的是，财务按立项版核算预算，研发按十一月版排人力，业务按八月版的交付日期对外承诺。

这不是个例。我过去几年在几十个研发和交付团队里做过基线相关的访谈和流程梳理，一个反复出现的现象是：大多数团队并不缺“计划”，缺的是“被批准、被记录、被引用”的计划。计划写了很多版，但没有一版被正式冻结、编号、发布和引用，于是每次争议都要重新吵一遍“原计划是什么”。

这篇文章不打算再复述项目管理教科书里的定义。我想讲的是：作为项目负责人，你如何把“计划基线”从一份躺在线文档里的表格，变成一套可变更、可审计、可汇报的治理机制，以及围绕它应该盯哪几个关键指标，才能提前发现问题，而不是在复盘会上才发现问题。

一、先给结论：计划基线是“可变更的锚”，不是冻结的日期

先把结论摆出来。我带过项目、也帮别的团队梳理过基线流程，反复验证下来，有五条判断我认为是站得住的。

第一，基线解决的是参照系问题，不是执行力问题。很多人把基线当成“承诺不变”的象征，一旦延期就归咎于基线没守住。实际上基线唯一不可替代的作用是：让“现在偏离了多少”这个判断有据可依。没有基线，偏差讨论就会退化成立场之争。

第二，变更控制的严格程度，应该匹配变更的代价。一个内部工具的需求微调，走三级审批是浪费；一个涉及监管备案的交付节点变更，口头同意就是事故。基线规范的核心不是统一流程，而是分级授权。

第三，基线粒度是可配置的，不是越细越好。把任务拆到半天粒度再去冻结，结果是每周都要走变更；只在里程碑层面冻结，又会出现“里程碑没动但实际早就跑偏”。粒度的选择取决于你承受变更的成本和监测偏差的频率。

第四，关键指标的第一用途是预警，第二用途才是考核。我见过太多团队把 SPI、CPI 直接挂到项目经理绩效上，半年之后数据就“变漂亮”了，不是项目变好了，是填报口径变松了。

第五，基线管理的成本必须显性化。如果一个团队每个月花在填变更单、对齐版本上的时间超过四十人时，那这套流程大概率已经过重，需要简化而不是加强。

把这五条放在一起，可以画出一个成熟度阶梯：从没有基线，到有文档基线，到受控基线，再到能提前预测偏差的基线。每一级的能力差距，最终都会体现在响应速度和返工成本上。

二、真实场景：为什么“有基线”的项目仍然控不住

我在访谈里收集过一批具体场景，它们比任何定义都更能说明基线为什么会失效。下面这四个场景，几乎覆盖了八成以上的失控案例。

1. 复盘会上找不到“当前生效版本”

这是最普遍的一种。计划至少有三次修订，但修订过程没有被记录：谁提的、为什么改、谁批的、影响哪些下游，全都散落在聊天记录和邮件里。到了复盘时，只能靠记忆还原，而记忆是会被立场修饰的。

更麻烦的是，当“当前基线”不明确时，所有基于它的指标都失去意义。SPI 算出来是 0.92，但对比的是哪一版计划？如果对比的是最早那版，那这个数字既不好看也不真实。

2. 变更靠口头走，月底才发现偏差

我见过一个交付团队，需求变更是业务直接在群里 @ 开发，开发评估后直接改，测完上线。整个链路没有一张变更单。结果是：月底财务对账发现人力成本超了 18%，但没人说得清这 18% 是哪几个变更带来的。

口头变更最大的代价不是“乱”，而是无法归因。你可以接受成本超支，但你无法接受“不知道为什么超支”，因为这意味着下个项目还会再超一次。

3. 工具里存了基线，但没有任何人在看

不少团队在项目管理工具里配置了基线功能，冻结过一次，之后再也没碰过。原因通常是：没有配套的偏差对比节奏，没有明确的预警阈值，也没有人负责解读偏差。基线变成了一个“配置项”，而不是一个“管理动作”。

4. 跨部门对基线的认可度不一致

项目负责人认可基线，业务方认为“计划本来就该随时调整”，研发认为“变更是常态”。三方对同一份基线的态度不同，结果就是：项目负责人每次都要花大量精力做解释和游说，而不是做判断和决策。

把上面四种场景串起来看，会发现一个共同后果：偏差的发现时间被推后了。发现得越晚，可选的处理手段越少，补救成本越高。这不是线性的关系，而是典型的放大器效应。

三、误区拆解：五种让基线失效的典型做法

在讲怎么做之前，先把常见的坑说清楚。这五种做法我都亲眼见过，有的还亲手踩过。

1. 把基线当成“死线”，认为变更就是失败

这种观念的副作用非常大。当团队认为“提出变更等于承认做错了事”，变更就会转入地下：需求被悄悄塞进已有任务里，工期被悄悄挪用，风险被悄悄捂住。表面上变更率很低，实际上偏差在累积。

健康的基线文化应该允许变更，但要记录变更。变更率不是越低越好，而是要与项目所处的阶段匹配。探索期变更多是合理的，交付期变更多才是问题。

2. 只做进度基线，不做成本、范围基线

我见过很多团队的“基线”其实就是一张甘特图。范围没有冻结清单，成本没有批准的预算版本，质量和风险连辅助计划都没有。结果就是进度一推迟，其他维度全部被动。

范围基线尤其容易被忽略。如果需求清单没有版本号，那么“范围蔓延”这件事根本无法量化，也就无法在评审会上被讨论。

3. 变更流程要么没有，要么过重

两个极端都很常见。没有流程时，变更无法归因；流程过重时，团队会绕过流程。我见过一个团队，变更单要填七个字段、走四级审批，平均审批周期 9 天。结果是紧急变更全部走“事后补单”，补单率一度超过 40%。

判断流程是否过重的标准很简单：看紧急通道的使用比例。如果超过两成的变更走特批，说明常规流程的设计出了问题。

4. 指标只用来考核，不用来预警

把 SPI、CPI 直接绑定绩效，短期看数据很整齐，长期看数据会失真。一旦指标变成考核工具，填报人就有动机优化口径：把未完成任务标记为“待确认”，把变更拆成多个小变更降低单次影响值。

我的建议是：指标先跑三个月的预警周期，确认数据稳定、口径清晰，再考虑是否纳入考核，而且不要使用单一指标。

5. 工具里的基线和实际管理“两张皮”

工具里冻结了基线，但日常沟通、周会汇报、客户同步都用另一套 Excel。这种双轨制非常危险，因为两套数据会逐渐分叉，最后谁也不知道哪套是真的。

解决方式不是禁止 Excel，而是明确“唯一事实来源”：任何需要对外汇报的进度数据，必须以工具中的基线对比结果为准。

把这五个误区按出现频率和破坏力排一下，前两位通常是“变更流程缺失”和“工具与实际两张皮”，它们导致的返工和争议成本最高。

四、专业判断逻辑：概念校准与权限边界

讲完误区，回到判断逻辑。我发现很多讨论之所以吵不清，是因为四个词被混着用：计划、基线、版本、实际值。先把它们分开，后面所有的流程和指标才有地基。

1. 四个概念的分工

计划是意图，表示“我们打算怎么做”；基线是经批准的参照版本，表示“我们拿什么来比对”；版本是基线的迭代记录，表示“第几次被批准”；实际值是从执行系统中采集的真实数据，表示“我们实际做到了什么”。

四者缺一不可。只有计划没有基线，偏差无从谈起；只有基线没有版本，历史无法追溯；只有版本没有实际值，比对照样做不成。

2. 负责人权限的三问

在建立基线之前，项目负责人必须先回答三个问题。这三个问题答不上来，后面所有流程都会卡在“谁说了算”上。

第一问：谁有权批准基线？通常是项目发起人、项目委员会或 PMO，取决于组织。关键是这个角色要被明确写出来，而不是默认“项目经理自己定”。

第二问：谁有权修改基线？这决定了变更审批链的长度。我的经验是，按影响面分级：只影响本项目内部任务的变更由项目负责人批；影响里程碑或跨部门的变更由发起人批；影响预算总额或合同范围的变更必须上升到项目委员会。

第三问：谁有权查看偏差？这决定了透明度。如果只有项目经理能看到偏差数据，那预警就失去了意义。至少要保证发起人、核心团队负责人、PMO 都能看到同一份数据。

3. 基线粒度怎么定

粒度的判断依据是变更成本和偏差代价的比值。如果一次小型变更的成本很低（半天沟通即可确认），粒度可以粗一些；如果变更代价很高（涉及合同、资源重新调配），粒度必须细，以便尽早发现偏离。

一个可操作的经验值是：基线中的任务粒度，应该与你的例会和汇报节奏对齐。如果你每周开一次进度会，那么基线的最小监测单元就不要细于一周；如果基线细到半天，但只看周会，那细分就没有产生任何管理价值。

五、建立流程：从范围分解到基线发布的七步

下面是我在实践中反复打磨的七步流程。每一步都给负责人动作、输出物和检查点，可以直接对照检查。注意这不是理论框架，而是顺序上的先后依赖，跳过前面任一步，后面都会返工。

1. 目标与成功标准对齐

先明确项目要达成的业务目标，以及“怎么算成功”。这一步的常见错误是把交付物当成目标，比如“上线三个模块”，但没说清楚上线后要看什么指标变化。

输出物是一份目标声明，包含业务目标、成功标准、衡量方式和时间窗口。检查点：发起人是否书面确认过这份声明。

2. 范围边界与需求冻结窗口

确定项目做什么、不做什么，以及需求的冻结节奏。冻结不等于不动，而是明确“什么时候可以提、什么时候只能进下一版”。

输出物是范围清单加冻结窗口约定。检查点：有没有明确写出“本次不包含哪些内容”，这比写包含什么更重要。

3. 工作分解与进度排期

把范围拆成可估算的工作包，再排成进度。这一步的检查点是：每个工作包是否有唯一负责人、是否有明确的完成定义。如果一项工作有两个人负责，实际上就是没有人负责。

4. 成本预算与资源计划

基于工作包估算人力和非人力成本，形成预算版本。这一步最容易出问题的地方是估算依据缺失，只留下一个数字，没有说明数字是怎么来的。建议至少记录估算方法、假设条件和不确定性区间。

5. 辅助计划与风险登记

质量计划、资源计划、沟通计划、风险登记册。规模小的项目可以合并成一份，但不能全空。风险登记册尤其重要，它是后续变更影响评估的输入。

6. 干系人评审与正式批准

把前面的输出物打包，做一次正式评审。评审的目的不是走过场，而是让关键干系人对同一份计划达成共识。检查点：评审意见是否有书面记录，异议是否被处理或明确接受。

7. 基线发布、版本归档与通知

批准之后立刻冻结，赋予版本号，归档并通知所有干系人。这一步经常被省略，但它恰恰是“基线”与“计划”的分水岭。没有发布动作，就没有基线。

从时间投入看，这七步里最耗时的是第三步和第六步。评审环节的耗时往往被低估，但正是这一步决定了后面要走多少次变更。

六、规范设计：角色、变更闭环、模板与工具字段

有了流程，还需要规范来保证它可执行、可审计、可变更。我把规范拆成四块：角色权限、变更闭环、模板字段、工具最小字段集。

1. 角色权限矩阵

角色不清是变更扯皮的根源。下面这张矩阵可以直接拿去改造成团队版本。核心原则是：每个变更动作必须有且只有一个最终责任人。

2. 变更闭环的六个环节

一个完整的变更闭环应该包含：申请、影响评估、审批决策、基线更新、通知同步、归档复盘。我在实践里发现，最容易被省略的是最后两个环节，而它们恰恰决定了变更会不会重复发生。

1. 申请：提交变更内容、原因、期望时间，附上提出人。
2. 影响评估：评估对进度、成本、范围、质量、风险五个维度的影响，量化到具体数值。
3. 审批决策：按影响级别选择审批层级，明确批准、驳回或延期决策。
4. 基线更新：批准后更新基线并递增版本号，保留旧版本以便追溯。
5. 通知同步：把变更结果同步给所有受影响方，包括下游依赖团队。
6. 归档复盘：定期统计变更原因分布，识别系统性问题。

从通过率的角度看，各环节是逐级收敛的。如果审批环节的通过率异常低，说明前端评估质量不够；如果通知环节的触达率低，说明责任矩阵没落地。

3. 五类必备模板

模板不需要多，但必须覆盖关键节点。我建议至少准备这五类：

• 基线说明书：包含项目基本信息、范围清单、进度里程碑、预算总额、责任人、批准人、版本号、生效日期。
• 变更申请单：包含变更描述、原因分类、影响评估、优先级、期望决策时间。
• 影响评估表：五维度量化评估，注明评估人。
• 基线健康度看板：包含建立质量、执行偏差、变更健康三类指标。
• 变更归档统计表：按月统计变更数量、原因分布、平均审批周期、返工情况。

4. 工具中的最小字段集

不是所有人一开始就能上重型工具。但无论用什么工具，下面这些字段是基线管理的最小集合，缺一个都会造成追溯困难。

基础字段
baseline_id 基线唯一编号

version 版本号（递增）

approved_by 批准人

approved_at 批准时间

effective_at 生效时间

范围字段

scope_items 范围清单条目

freeze_window 冻结窗口起止

进度字段

milestones 里程碑及计划日期

planned_value 计划价值（PV）

成本字段

budget_at_completion 完工预算（BAC）

变更字段

change_id 变更编号

change_type 范围 / 进度 / 成本 / 质量 / 资源

impact_assessment 五维度影响评估

decision 批准 / 驳回 / 延期

这些字段不需要全部手工填写。好的工具可以把大部分字段从任务、工时、预算模块自动汇聚，你只需要维护基线和决策记录两类信息。

七、关键指标：从“有没有基线”到“基线是否健康”

很多团队考核的是“有没有建立基线”，这是一个二元指标，建立完就失效了。真正有价值的是“基线是否健康”，这是一组持续监测的指标。我把它分成三类：建立质量、执行偏差、变更健康。

1. 建立质量指标

这类指标用来判断基线本身是不是站得住脚，通常只在建立阶段和项目中期评估一次。

• 基线完整率：范围、进度、成本三类基线齐全的比例，目标值 100%。
• 评审覆盖率：关键干系人实际参与评审的比例，目标值不低于 90%。
• 估算依据完备率：有明确估算方法和假设记录的估算项占比，目标值不低于 85%。

2. 执行偏差指标

这是最常被提到的一组。我建议使用时务必写清公式、数据来源和汇报对象，否则很容易变成数字游戏。

3. 变更健康指标

这组指标最被忽视，但它们是判断基线流程是否有效的关键。我在几个团队里推行后，最直观的变化是：变更从“突发”变成了“可预期”。

• 变更率：统计周期内变更数量与基线任务总数之比。交付期持续高于 15% 说明前期范围管理有问题。
• 平均审批周期：从提交到决策的平均时长。超过 5 个工作日就该检查流程是否过重。
• 紧急变更占比：走特批通道的变更比例。超过 20% 说明常规流程失灵。
• 变更返工率：因变更导致返工的任务占比。这是最贵的指标，值得单独跟踪。
• 变更原因集中度：前三大原因占比。如果长期集中在“需求不清晰”，那问题不在变更流程，而在需求阶段。

把这几个指标放在同一张看板上，会看到一些有意思的关联。比如变更申请数量上升时，如果平均审批周期同步拉长，逾期未关闭的变更就会堆积，紧接着返工率会在两到三周后上升。这是一个可以被提前干预的链条。

八、案例观察：中大型组织如何把基线真正跑起来

前面讲的都是方法。但方法要落地，会碰到一个现实问题：中大型组织人多、项目多、协作方多，靠文档和表格管理基线，几乎必然失败。我在一家 300 人规模的研发组织里完整跟踪过这个过程，下面把观察到的数据和处理方式讲清楚。

这家组织的背景比较典型：研发加测试接近 300 人，同时并行 12 个项目，交付对象既有内部业务方也有外部客户，还涉及等保合规要求。他们的痛点和我前面描述的完全一致，基线有三版，没人说得清哪版有效；变更靠群聊，月末对不上账。

1. 改造前的三个具体问题

问题一，基线与实际执行数据分离。基线存放在共享盘里的表格，实际执行数据在另一套任务管理系统里，两者靠人工每周同步一次。同步一次大约需要 6 人时，且经常因为有人忘记更新而失真。

问题二，变更无法归因。变更通过邮件和群聊发起，没有统一编号。季度复盘时，他们尝试统计变更数量，最后只能给出一个大致区间，21 到 40 件之间。这个精度完全不足以支撑流程改进决策。

问题三，版本追溯困难。因为涉及等保合规，审计时需要证明“某个时间点的计划是什么”。人工查找一次历史版本平均耗时 45 分钟，而且不能保证找全。

2. 改造路径

他们的改造分三步走，每步之间隔了两周，给团队适应时间。

第一步是统一数据源。所有项目的任务、工时、里程碑都收进同一套项目管理系统，基线不再单独存放，而是从系统数据中生成快照。这一步他们选择了 PingCode，因为它支持私有化部署，符合这家企业的数据合规要求，同时具备基线快照和变更记录的能力。

第二步是建立变更闭环。变更从系统内发起，自动带出受影响的里程碑和任务，评估人只需填写影响值，审批按影响级别路由。他们设定了三级授权：影响单个任务由项目负责人批，影响里程碑由发起人批，影响预算由 PMO 加财务批。

第三步是看板上线。三类指标进入同一看板，每周例会只看看板，不再单独准备 PPT。

3. 三个月的观察数据

需要说明的是，下面是这个组织内部跟踪记录的样本数据，不是行业统计，仅作参考。

• 基线版本追溯耗时从平均 45 分钟降到 3 分钟以内，审计准备时间从 2 人天降到 0.5 人天。
• 变更登记完整率从估算的六成提升到接近 100%，季度复盘的变更数量第一次有了精确值。
• 平均变更审批周期从 6.8 天降到 3.4 天，主要收益来自分级授权而不是工具本身。
• 因变更导致的返工率从 22% 降到 11%，降幅主要出现在迁移后的第三个迭代。

这组数据里最值得注意的一点是：审批周期的改善主要来自授权分级，而不是工具速度。工具解决的是记录和追溯效率，流程设计才解决决策效率。两者缺一不可，但很多人会把顺序搞反。

顺带说一句，这家组织此前使用的是 Jira，迁移过程用了大约三周，包含字段映射、工作流适配和历史数据导入。PingCode 在这方面提供了平滑迁移支持，对已经有成熟工作流的团队来说，迁移成本比重新搭一套流程要低得多。

4. 一个值得复制的细节

这家组织做对了一件小事：他们把“基线说明书”压缩到了一页，只保留范围清单、里程碑、预算总额、责任人、版本号和批准人六个字段，其余细节留在系统里。

这么做的结果是，业务方愿意看这一页，也就愿意在评审时提出异议。相反，如果基线说明书有二十页，业务方基本不会仔细看，评审通过就变成了形式。基线文档的长度，直接影响干系人参与的质量。

九、行动建议：不同场景下该怎么做

方法是一样的，但落地方式必须随场景变化。下面按五种常见情况给出建议，你可以直接对号入座。

1. 十人以下的内部项目

不要建立完整的三类基线，成本不划算。建议只做范围清单加里程碑清单，标记版本号和批准人。变更走轻量记录，在任务系统里留一条变更说明即可，但要指定唯一决策人。

关键动作是把“谁可以决定改”写清楚。小团队最大的风险不是流程缺失，而是决策权模糊，导致每次变更都要全员讨论一遍。

2. 五十到两百人的多项目并行组织

这个规模开始需要标准化的基线说明书和变更单，但不要一开始就上评审委员会。建议先做两件事：统一模板和统一编号规则。变更审批按影响级别分两级，超过两级会明显拖慢节奏。

这个阶段最常见的失败是“模板很完整，但没人填全”。解决办法是砍字段，把必填项控制在八个以内，其余设为选填。

3. 强监管或合规要求高的行业

范围、进度、成本三类基线必须齐全，版本号规则要严格，变更记录必须可审计。建议把变更原因分类固化下来，方便在审计时说明变更的性质。

这类场景要特别注意“证据链完整性”：从变更申请到批准、到基线更新、到通知下游，每一个动作都要有时间戳和责任人。审计看的是链条，不是单点。

4. 敏捷或迭代式交付团队

不要试图冻结每个迭代的详细任务。合理的做法是：在发布层做基线，在迭代层做滚动规划。规模可以用发布目标、范围和关键里程碑来定义，迭代内的调整不算变更。

关键指标也要调整。SPI 和 CPI 在敏捷场景下参考价值有限，更实用的是迭代交付达成率、变更原因分布和返工率。

5. 多供应商或外包协同的项目

这类项目的核心风险是接口和依赖。建议在基线中专门设一节“外部依赖与接口冻结清单”，明确每个依赖的责任方和冻结时间。变更影响评估时必须包含对下游供应商的影响。

我在一个多方协同的项目里见过一次典型事故：内部团队调整了一个接口字段，没有通知外包方，导致对方返工两周。跨组织协同中，变更通知的触达率比审批速度更重要。

十、取舍：不同情况下的成本与收益权衡

做基线管理最难的不是“知道该做什么”，而是“知道什么可以不做”。下面五组取舍，是我在实际项目里反复面对的选择。

1. 粒度细 vs 粒度粗

粒度细的收益是偏差发现早，代价是变更频繁、治理成本高。粒度粗的收益是管理轻，代价是问题发现晚，补救空间小。

我的判断依据是：如果任务的变更代价高于监测代价，就值得细；反之就粗。比如硬件采购的交付节点变更代价极高，值得按周监测；而内部文档编写任务的变更代价很低，按里程碑监测就够了。

2. 流程重 vs 流程轻

流程重的收益是可追溯、可审计，代价是决策慢、容易被绕过。流程轻的收益是响应快，代价是归因困难。

一个实用的判断方法是观察特批比例。如果特批比例长期高于 20%，说明正常流程太重；如果变更原因长期集中在“信息不全”和“临时插入”，说明流程太轻，缺少前置约束。

3. 工具化 vs 手工台账

工具化的收益是数据一致、追溯快、可自动预警，代价是前期配置和迁移成本。手工台账的收益是上手快，代价是规模一大就失真。

我的经验分界线在项目数量和协作人数上：当同时并行项目超过 5 个，或涉及三个以上部门协同时，手工台账的维护成本会超过工具化成本。再往后拖，历史数据的补齐成本会成倍增加。

4. 指标用于预警 vs 用于考核

用于预警的收益是问题早发现，代价是需要持续投入解读成本。用于考核的收益是约束力强，代价是数据容易失真。

我建议的顺序是：先跑预警，稳定后再谈考核，而且考核不要用单一指标。把 SPI 单独挂到个人绩效上，几乎必然导致口径漂移。更稳妥的做法是用组合指标，如交付达成率加变更规范率加返工率。

5. 单一固定基线 vs 滚动式基线

单一固定基线的收益是参照清晰、审计友好，代价是应对变化的灵活性差。滚动式基线的收益是贴近现实，代价是历史比对复杂。

一个折中方案是双层基线：发布层保持固定基线不动，用于对外承诺和审计；执行层使用滚动预测，用于内部管理。这样既能守住承诺口径，又能反映真实趋势。

十一、结语：给项目一个可变更的锚

回到开头那个复盘会的场景。如果那家企业的项目经理手里有一份带版本号、带批准人、带生效日期的基线说明书，那场争论大概只需要三分钟就能结束，剩下的时间可以真正用来讨论“接下来怎么办”。

我在这篇文章里想传递的核心观点只有一个：计划基线的价值不在于“锁住计划”，而在于“提供一个可以被反复引用、被正式变更、被完整追溯的参照物”。它是一根锚，不是一道墙。

围绕这个判断，我把内容拆成了几层：先校准计划、基线、版本、实际值四个概念；再用五类误区说明常见失效路径；然后是七步建立流程、四块规范设计；最后是三类关键指标，从建立质量到执行偏差再到变更健康。

如果只能记住三件事，我希望是这三件。第一，变更必须有闭环，没有闭环的基线等于摆设。第二，基线粒度要和你的汇报节奏对齐，细到看不见等于白细。第三，指标先用于预警，稳定之后再考虑考核，顺序颠倒会毁掉数据可信度。

至于下一步，我建议你做一次最小成本的体检，只需要回答五个问题：

1. 你的项目现在有没有一份带版本号和批准人的基线？如果没有，先补这一份。
2. 最近十次变更，有多少张变更单？如果低于五张，说明记录缺失。
3. 你平均多久能发现一次进度偏差？如果超过两周，先优化监测频率。
4. 你的基线说明书有多少页？如果超过五页，试着压到一页再看干系人反馈。
5. 你的指标有没有被用于考核？如果有，检查一下口径有没有被“优化”过。

这五个问题不需要任何工具，也不需要额外预算，一个下午就能答完。但答完之后，你大概会清楚自己团队的基线管理处在哪个阶段，以及最该先动哪一块。治理的起点从来不是引入新流程，而是承认现在这一版基线到底算不算数。