项目规划计划基线教程：跨部门团队落地方案，避坑指南

三周前，我陪一家做智能硬件的客户复盘一个跨部门项目：需求评审会上七个部门全部点头，排期表发出去 17 页，里程碑写得清清楚楚。三周后打开进度表，硬件说结构件没到没法测，结构说供应商排产要等采购确认，采购说预算还没批。三个部门都坚称自己没有延期，因为"我的任务还没到开始时间"。

这不是执行力问题，是基线问题。他们有的是排期表，不是基线；有的是时间点，不是承诺。我在过去几年里复盘过四十多个跨部门项目，凡是出现"排期发下去、执行全变形"的，八成以上能在基线环节找到根因：目标没翻译到部门、资源没落到人、依赖靠口头、变更不留痕、升级没路径。

这篇教程不讲项目管理五大过程组，也不重抄术语表。我把跨部门团队从 0 到 1 建立计划基线的完整方法拆成结论、场景、误区、判断逻辑、落地六步、三张表、九个坑和 30 天行动清单，重点回答一个问题：怎么把一张"计划表"升级成一套被人认账的"受控承诺系统"。所有涉及工具功能、标准措辞的地方，都请按你所在组织的实际情况裁剪。

一、先给结论：跨部门项目缺的不是排期表，是一份"受控基线"

1. 一句话结论

跨部门项目的基线，本质是一份经过关键干系人确认、带版本号、受变更控制、可被用来判断偏差的承诺集合。它至少包含三件事：谁在什么时间交付什么、依赖谁、偏差由谁裁决。缺少任何一项，你手里的东西都只是计划草案，不是基线。

我见过太多团队把"发出去的排期表"当成基线。问题是排期表只回答了"什么时候"，没回答"谁承诺、基于什么假设、变了怎么办"。执行阶段一旦出现资源被抽走、需求加塞、上游延期，这份表立刻失去参照价值，它不能用来判断偏差，因为没人承认它是参照。

2. 计划、基线、执行版：三个版本，三种用途

很多混乱来自把三个版本混为一谈。我把它们的分工整理成下表，你可以对照自己团队现在用的是哪一种。

关键点在于：执行版本可以天天变，基线版本不可以随便变。一旦执行版和基线版出现偏差，你要做的不是偷偷把执行版改成基线版，而是启动偏差分析，判断这是正常波动、需要纠偏，还是需要走变更。

3. 基线包含什么：按组织裁剪，不照抄教科书

教科书常把基线拆成范围基线、进度基线、成本基线，再组合成绩效测量基线。实际落地时，很少有跨部门项目能把三项都做扎实。我的建议是按项目类型裁剪：

• 交付型项目（产品上线、系统迁移）：以范围基线 + 进度基线为核心，成本基线可以只做总额控制。
• 研发型项目（版本迭代、平台重构）：以范围基线为主，进度用里程碑而非精确日期锁定。
• 合规型项目（资质申报、审计整改）：以时间窗口和交付物清单为硬基线，成本反而不是重点。

我对这条建议的判断依据很简单：基线的价值在于能被检验，而不是覆盖面广。你锁了三个维度但三个都维护不动，还不如只锁两个维度、每周都能对得上。

二、真实场景：为什么"计划发下去"不等于"基线立起来"

1. 场景一：七个部门都点头，没人承诺资源

最典型的失败场景是评审会。七个部门负责人在会议室里对着甘特图逐行看，问"有没有问题"，全场摇头。散会后你发邮件，抄送所有人。你以为得到的是承诺，其实得到的是不反对。

不反对和承诺是两回事。承诺意味着：我知道这件事什么时候开始，我知道我要投入几个人、投入多久，我确认在那个时间段里我的资源不会被别的项目优先占用。而评审会上，很少有人会主动说"那个时间段我要做另一个项目，抽不出人"，因为那等于当众拒绝，成本太高。

所以我在做基线评审时，会把"有问题吗"换成三个必答问题：这个时间点你手上还有什么在跑？这个交付物你打算派谁？如果上游晚到三天，你的应对是什么？回答不上来的人，他的任务就不能进基线。

2. 场景二：需求没稳就冻结，基线变成负债

另一种常见操作是"先冻了再说"。项目刚立项，需求还是一页 PPT，项目经理为了显得有掌控力，直接把进度锁死。结果是每隔两周就要改一次基线，改到最后没人再认真对待版本号。

我的判断标准是：需求颗粒度没到能拆出可验收交付物之前，不要冻结进度基线。这时候可以立"方向基线"，锁住目标、范围边界和关键里程碑，但允许任务级排期滚动更新。等需求稳定到能定义验收标准，再冻结任务级进度。

3. 场景三：变更靠口头，版本越走越散

我印象最深的是一次系统迁移项目。上线前两周，业务方在群里说"这个功能先不做了，换成另一个"。项目经理口头答应了，改了自己的表，但没通知测试和运维。上线当天，测试按旧清单验证，运维按旧配置准备，两边都以为自己是对的。

这类问题的根因不是沟通意识，而是缺少一个唯一的变更入口。所有变更，无论多小，都必须走同一个入口：提交申请、评估影响、判定审批层级、更新版本、通知干系人。口头同意可以作为讨论，但不能作为生效。

4. 复盘数据：延期原因到底集中在哪

我把近几年复盘过的跨部门项目延期原因做了归类。下面这张帕累托图是我个人样本的分布，不是行业统计数据，但规律相当稳定：前四类原因占据了绝大多数延期事件，而这四类几乎都和基线机制有关，和团队努力程度无关。

三、拆解四个常见误区

1. 误区一：甘特图就是基线

甘特图是一种视图，基线是一种承诺状态。同一个甘特图，如果没人确认资源、没写依赖、没做变更控制，它就只是一张排期图。

我常用一个类比解释给业务方：甘特图像是婚礼流程表，基线像是已经发出去的请柬和订好的场地。流程表可以随时改，请柬发出去之后改动就要通知所有人、可能还要赔钱。区别不在于画得漂不漂亮，而在于改动的成本由谁承担。

2. 误区二：基线等于冻结的合同

把基线当合同，会直接摧毁它的可用性。团队会开始防御性排期：故意把工时填长、把风险写满、把交付承诺压低。基线一旦变成追责工具，就再也收集不到真实信息了。

正确的理解是：基线是偏差判断的参照，不是绩效惩罚的依据。偏差出现时，第一反应应该是"哪里需要支援"，而不是"谁没做到"。管理层如果拿基线直接问责，项目经理必须提前沟通清楚使用边界，否则流程会被绕开。

3. 误区三：基线越细越专业

我见过把基线做到 400 行任务的团队，结果每周维护要花掉项目经理一整天，三周后彻底放弃。跨部门场景下，任务颗粒度以能被单一责任人独立交付为宜，通常对应一到两周的工作量。再细就超出了跨部门协调的必要精度。

一个实用判断：如果某个任务你无法在周会上用一句话说明它的状态，说明它要么太细，要么定义不清。

4. 误区四：依赖问题靠"多沟通"解决

"加强沟通"是项目管理里最没有信息量的一句话。跨部门依赖的本质是双方对承诺的理解不一致，不是沟通频次不够。天天开会对齐，但没人写下"谁、在什么时间、给我什么东西、达不到怎么办"，沟通越多反而越混乱。

替代做法是把依赖变成结构化记录：依赖内容、依赖方接口人、需要时间、承诺时间、当前状态、延误时的升级对象。写下来之后，"多沟通"就变成了"按表核对"。

四、专业判断逻辑：基线是一套"受控承诺系统"

1. 五问检验法：你的基线是真基线吗

在决定基线是否可以发布前，我会用五个问题快速检验，任何一条答不上来就不发版：

1. 每个交付物的责任人是否具体到人，而不只是部门？
2. 每条跨部门依赖是否有接收方和给出方的双向确认？
3. 每个关键里程碑的完成标准是否可验收，而不是"基本完成"？
4. 变更申请是否有唯一入口、有明确的审批层级？
5. 偏差出现时，是否存在不依赖项目经理个人的升级路径？

第五问最容易被忽略，也最关键。如果所有跨部门冲突都要靠项目经理去斡旋，那这套基线是脆弱的人治系统，换个人就失效。

2. 承诺的四要素：人、物、时、量

我习惯把一条合格的基线承诺拆成四个要素，缺一不可：

• 人：谁交付、谁验收、谁批准，三个角色都要有名有姓。
• 物：交付物的物理形态是什么，文档、代码分支、样机、配置包。形态决定验收方式。
• 时：承诺时间是"提交时间"还是"验收通过时间"，这两个差几天在跨部门场景里经常引发争议。
• 量：投入多少人、投入多久。只确认"能做"不确认"投入多少"，等于没有承诺。

我见过一个典型反例：任务写"技术部 6 月底完成接口联调"。联调是谁做？6 月底是完成还是开始？投入几个人？三个问题一问，任务当场作废重写。

3. 成立信号与失败信号

基线是否真的立起来，不看文档，看行为。下面这组信号是我在项目观察中总结的，准确性还算稳定：

五、落地方案：五个输入、六步法、三张表

1. 建基线前必须拿到的五个输入

很多人一上来就排期，结果排出来的东西没人认。我的做法是先收齐五个输入，收不齐就不进入排期环节。

输入一：目标与成功标准。公司目标要翻译成项目目标，再翻译成部门交付。翻译过程中最重要的动作是问一句"如果这件事做成了，你部门能拿出什么证据"。拿不出证据的目标，说明还没翻译到位。

输入二：范围边界与不做什么。跨部门争议大多来自边界模糊。我会强制在基线文档里写一节"本项目不包含"，这一节往往比"包含什么"更有价值。

输入三：里程碑与跨部门接口。识别出哪些节点需要外部输入，每个接口指定一个唯一接口人。接口人不是传话筒，他要对输入质量负责。

输入四：资源承诺与容量。不要只问"能不能做"，要问"谁、从什么时候到什么时候、投入百分之多少"。容量表比排期表更能暴露风险。

输入五：假设、风险与升级路径。列出关键假设，并写明"如果这个假设不成立，基线需要重评"。同时约定升级路径：多长时间没解决、上升到哪一级。

2. 六步法：从目标解码到变更入口

六个步骤是我在实际项目里反复使用并简化后的版本，每一步都对应一个明确产出物。没有产出物的步骤，说明这一步没做实。

1. 目标解码与指标翻译。产出：项目目标，部门交付，验收标准的三级对照表。动作要点是把项目语言翻译成部门能接手的任务语言。
2. 交付物定义与工作分解。产出：以交付物为中心的分解结构。动作要点是自下而上检查，每个交付物都能被某个部门独立验收。
3. 里程碑依赖与关键路径。产出：里程碑依赖表，标注哪些依赖位于关键路径上。关键路径上的依赖必须双重确认，非关键路径上的可以适当放宽。
4. 资源容量与责任矩阵。产出：责任矩阵 + 资源容量表。动作要点是暴露冲突而不是掩盖冲突，冲突越早暴露，调整成本越低。
5. 基线评审与确认。产出：评审清单、书面确认记录、版本号。动作要点是书面确认，邮件或系统内的确认记录都行，口头不算。
6. 发布、存档与变更入口。产出：单一信息源 + 变更申请入口 + 版本发布规则。动作要点是让所有人知道"去哪里看最新版"和"怎么提变更"。

3. 三张核心表：责任、依赖、变更

如果只能带走三样东西，我建议是这三张表。它们比甘特图更能解决跨部门协作问题。

（1）跨部门责任矩阵。这张表解决"谁负责、谁批准、谁支持、谁知情"。字段建议：任务编号、交付物、负责部门、责任人、审批人、支持方、截止时间、验收标准、状态。注意"责任人"必须填人名，填部门等于没填。

（2）里程碑依赖表。这张表解决"我以为你会交"。字段建议：里程碑、前置依赖、依赖部门、接口人、需要时间、承诺时间、当前状态、风险等级、升级对象。风险等级建议用三档，超过三档没人认真区分。

（3）变更影响评估表。这张表解决"改了之后谁受影响"。字段建议：变更编号、变更内容、提出人、提出日期、影响范围、进度影响、成本影响、资源影响、风险变化、审批层级、生效版本、通知范围。

版本命名规则也必须提前定死，否则半年后没人分得清哪版是哪版。我常用的规则是：

版本号格式：V{大版本}.{小版本}-{发布日期}
示例：V1.0-20260315（首次发布基线）

V1.1-20260402（范围内微调，不影响里程碑）

V2.0-20260510（里程碑或关键路径变更，需高层审批）

变更编号格式：CR-{年份}{序号}

示例：CR-2026007（2026年第7次变更申请）

这个规则看起来简单，但它解决了一个高频争议：什么级别的变更需要谁来批。小版本由项目经理和交付负责人确认即可，大版本必须上升到项目指导层。规则前置，比事后争论高效得多。

六、案例观察：100 人以上组织里，基线是怎么被工具承载的

1. 大组织的真问题不是画不出甘特图

100 人以下的团队，靠共享表格加周会基本能撑住。但组织规模过百人之后，跨部门项目的基线会遇到三个新问题：信息源分散、权限层级复杂、历史版本追溯困难。

信息源分散是最致命的。计划在一张表里、依赖在会议纪要里、变更在聊天记录里、进度在另一个系统里。每次开会都要花二十分钟确认"哪个是最新版"。单一信息源不是效率问题，是基线能否成立的前提。基线之所以能作为参照，就是因为它是唯一的、权威的。

权限层级复杂是第二个问题。跨部门项目的基线文档，往往需要让不同层级、不同部门看到不同粒度的信息。所有人都看同一张全量表格，既不利于信息保密，也让阅读成本高到没人愿意打开。

2. PingCode 承载基线的四个关键能力

在服务中大型企业、尤其是 100 人以上组织的场景里，我接触过 PingCode。它的定位比较适合这类跨部门协作密度高的组织，从基线落地的角度看，有四块能力和前面的方法论是对得上的。

第一是计划与执行的分层承载。基线版本和执行进度可以分开管理并保留对照关系，这样"执行版天天变、基线版受控变"这个原则就有了落地的载体，而不是靠人工维护两张表。

第二是依赖关系的显性化。跨部门依赖可以在任务层面建立关联，前置项未完成时后置项会明确暴露，减少"我以为你会交"这类模糊地带。这一点对关键路径上的依赖尤其重要。

第三是变更与历史留痕。变更申请、影响评估、审批记录、版本号可以形成完整链路。这条链路的价值在复盘时最明显，你能还原出"当时为什么改了、谁批的、影响了什么"。

第四是私有化部署与信创适配。PingCode 支持私有化部署，这对数据敏感型行业（比如制造、金融、央国企）很关键。基线文档里往往包含产品路线、客户信息、成本结构，能不能部署在自己的环境里，直接决定了这些信息能不能完整录入。

另外，对已经在用 Jira 的组织，PingCode 支持 Jira 平滑迁移，是国产替代路径中比较常见的一个选择。这里我要提醒一句：迁移时最容易丢的不是任务数据，而是历史版本关系和变更记录。迁移方案里必须明确这两类数据的处理方式，否则迁完之后基线只剩当前状态，历史对照能力就没了。具体迁移能力请以你实际使用的版本和官方说明为准。

3. 工具承载前后：一个可观察的对比

下面这组对比来自我参与过的两个规模相近的跨部门项目，一个仍用共享表格加会议纪要维护基线，一个迁移到平台化管理。样本很小，只能作为观察，不能当行业结论。

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

1. 弱矩阵或职能型组织

这类组织里项目经理没有直接指挥权，最容易陷入"什么都靠求人"的状态。我的建议是把基线做成向上管理的工具，而不是向下压任务的工具。

具体做法：把跨部门依赖和资源冲突整理成一页纸的"决策需求清单"，明确写出"如果不决策，会影响哪个里程碑、影响多少天"。让决策层看到不决策的代价，比反复催办有效得多。同时要主动争取一个书面授权，明确项目经理在基线变更上的裁决边界。

2. 强矩阵或项目型组织

这类组织里项目经理权限较足，风险反而在另一个方向：容易把基线做成刚性合同，导致团队防御性排期。建议把重点放在偏差分析和纠偏机制上，而不是加严审批。

可以建立每周一次的基线偏差复盘，只看三件事：偏差幅度、偏差原因、纠偏动作。同时明确一条规则，因客观风险暴露导致的偏差不追责，因信息隐瞒导致的偏差才追责。这条规则能显著提升信息的真实性。

3. 已经在跑但基线失控的项目

如果项目已经启动、基线名存实亡，不要推倒重来。我的做法是重新基线化：选一个时间点作为新的基准，把当前真实状态确认为新基线，走一次完整评审，明确后续变更规则。

关键动作是向干系人说明"这是重新对齐，不是承认失败"。重新基线化时最好同步做一次范围清理，把已经确认不做的内容正式移出，避免基线越背越重。

4. 从 0 到 1 的新项目

新项目的优势是没有历史包袱，建议一开始就把三张表和版本规则建起来，即使内容很粗。粗但完整，好过精细但缺项。同时尽早确定工具承载方式，是继续用表格，还是迁移到平台，这个决定越晚做，迁移成本越高。

八、不同情况下的取舍

1. 粒度与维护成本的取舍

基线颗粒度越细，偏差越早发现，但维护成本也越高。我的经验阈值是：单个项目经理维护基线的时间，每周不应超过 4 小时。超过这个数，说明粒度太细或者工具承载方式不对，应该合并任务或换承载方式。

如果是跨 5 个以上部门、周期超过半年的项目，可以适当加密到周级；如果是周期一两个月的小项目，里程碑级就够了，任务级排期滚动更新即可。

2. 变更自由与变更受控的取舍

变更控制太松，基线失去参照意义；太紧，团队会绕过流程。我倾向的平衡点是：影响里程碑的变更必须走审批，不影响里程碑的范围内调整由项目经理确认即可。这个分界线要提前和指导层达成一致，并且写进基线文档。

另一条实用规则是设置"变更预算"，比如整个项目周期内允许 3 次大版本变更，超过之后必须重新评估项目可行性。这能抑制无节制的加塞。

3. 工具投入与流程投入的取舍

如果组织连基本的责任矩阵和依赖台账都没有，先别急着上工具。工具会放大已有的流程质量：流程清楚，工具让效率翻倍；流程混乱，工具只是把混乱数字化。

反过来，如果组织已经有成熟的项目管理规范，但仍在用共享表格维护跨部门基线，那工具投入的回报会很明显，尤其是单一信息源和变更留痕这两块。

4. 三条不能让的底线

在跨部门场景里，很多事可以妥协，但有三条我建议坚持：

• 责任人必须落到具体的人。部门责任在跨部门协调中无效，因为找不到对接对象。
• 关键路径依赖必须双向书面确认。口头确认在争议时无法举证，等于没有。
• 变更必须留痕。不留痕的变更会让复盘失去依据，也会让项目历史变成一笔糊涂账。

九、九个坑：表现、后果、替代做法

1. 只排期，不排资源

表现是任务表里只有时间和交付物，没有投入人力。后果是执行期资源被抽调时无法追溯，也无法判断是否具备完成的客观条件。替代做法是在基线评审前完成资源容量确认，把"谁、投入多少、什么时段"写进基线附件。

2. 需求未稳就冻结基线

表现是立项初期就把任务级进度锁死。后果是频繁变更、版本号失控、团队对基线失去信任。替代做法是在需求未稳阶段只锁方向基线和关键里程碑，等交付物定义清楚再冻结任务级进度。

3. 部门 KPI 冲突没有提前暴露

表现是各部门在自己的考核目标上都有理，但合起来互相冲突。后果是执行期互相拖延，谁也说服不了谁。替代做法是在目标解码阶段就把各部门当期考核指标摆到桌面上，由项目指导层裁决优先级。

4. 依赖靠口头确认

表现是"上周开会说好了"。后果是争议时无法举证，责任无法界定。替代做法是建立里程碑依赖表，每条依赖双向书面确认，明确承诺时间和延误处理方式。

5. 基线过细，维护成本过高

表现是任务表长达数百行，每周更新耗掉项目经理一整天。后果是几周后彻底放弃维护，基线名存实亡。替代做法是按项目周期选择粒度档位，并设置每周维护时间上限。

6. 把基线当合同或追责工具

表现是管理层直接用基线偏差问责部门。后果是团队开始防御性排期，信息质量急剧下降。替代做法是明确基线的使用边界，区分客观风险偏差和信息隐瞒偏差，前者不追责。

7. 变更不留痕，口头改计划

表现是群里一句"这个先不做了"就生效。后果是版本混乱、上下游信息不同步、复盘无依据。替代做法是设立唯一变更入口，所有变更必须走申请、评估、审批、发布、归档。

8. 没有升级路径，项目经理独自扛

表现是跨部门冲突全部卡在项目经理这里等协调。后果是决策延迟，项目被动等待。替代做法是约定升级触发条件和对应层级，例如同一问题超过三个工作日未解决，自动升级到项目指导层。

9. 基线发布后不维护，执行版与基线版脱节

表现是基线发布后没人再看，周会只更新各自任务状态。后果是偏差无法度量，基线变成一次性文档。替代做法是在周会固定展示基线对比视图，并把偏差分析列为常规议题。

十、变更闭环：基线变了，流程怎么走

1. 变更五步：从申请到发布

变更控制不是阻碍变化，而是让变化可见、可评估、可追溯。我常用的流程是五步：

1. 变更申请。由提出人提交，写清变更内容、原因、期望生效时间。提出人可以是业务方、技术方或项目经理本人。
2. 影响评估。由项目经理牵头，评估对进度、成本、资源、范围、风险五方面的影响。这一步必须给出量化结论，不能只写"有一定影响"。
3. 审批决策。按变更影响层级匹配审批权限。影响里程碑的上报指导层，不影响里程碑的由项目经理和交付负责人确认。
4. 更新与发布。更新基线版本号，发布变更通知，明确新版本生效时间和过渡安排。
5. 归档与复盘。变更记录归档，在月度复盘时回顾变更频次和原因分布，判断是否需要调整范围或资源。

2. 三句可以直接用的话术

跨部门沟通里，同一件事换个说法，推进效率差别很大。下面三句是我反复用过、效果比较稳定的表达方式：

• 把"你怎么又延期了"换成"这个延期对基线的哪条关键路径有影响，我们需要一起判断是纠偏还是走变更"。
• 把"这个需求必须做"换成"这个变更会影响哪些里程碑，需要哪一级审批，我们先做影响评估再决定"。
• 把"你们部门要配合"换成"这条依赖需要你们在什么时间给出什么交付物，接口人是谁，如果来不及我们提前升级"。

这三句话的共同点是把情绪表达换成结构化请求，让对方知道要做什么、什么时候做、做不到会怎样。

3. 版本号与通知范围

版本号规则前面已经给出。这里补充通知范围的判断：受变更影响的任务责任人、依赖该交付物的下游部门、以及需要知情的管理层，三类人必须收到通知。通知渠道尽可能统一，避免一部分人从系统里看、一部分人从群里看，导致版本认知不一致。

十一、30 天最小可用机制

1. 四周推进表

不要把 30 天目标设成"彻底解决跨部门协作问题"，那不现实。合理目标是建立一个最小可用机制：能对基线、能提变更、能看到偏差。

1. 第 1 周：统一语言。收集项目目标、范围边界、关键里程碑，产出目标解码表初稿。同时和相关方确认基线术语的含义，避免后面各说各话。
2. 第 2 周：搭两张表。建立责任矩阵和里程碑依赖表，组织一次跨部门对齐会，重点确认依赖和接口人。
3. 第 3 周：确认资源。完成资源容量确认，暴露冲突并向决策层提交决策需求清单，完成基线评审。
4. 第 4 周：发布与运转。发布基线并明确变更入口，建立周度偏差复盘，跑完第一轮变更流程。

2. 允许裁剪的部分

30 天计划在资源紧张时可以做裁剪。我建议的裁剪顺序是：先砍文档形式（能用表格就别做精美模板），再砍评审会议频次（合并成一次综合评审），最后才考虑砍依赖确认和资源确认。后两项一旦砍掉，基线就不成立。

另外，如果项目周期本就只有两三个月，可以把 30 天压缩到两周：第 1 周完成目标解码和依赖梳理，第 2 周完成资源确认和基线发布。

3. 怎么判断机制跑起来了

机制是否生效，看四个行为信号：有人主动提交变更申请而不是直接改任务；周会展示的是基线对比而非各自状态；跨部门冲突在约定时限后自动上升；偏差原因能够归类并形成改进动作。这四条中满足三条，说明机制已经运转起来。

回到开头那个项目。后来我们做的最重要的一件事，不是重新排期，而是把"发出去的排期表"作废，重新走了一遍目标解码、责任确认、依赖书面化和基线评审。第二次发布时，文档页数少了一半，但每个任务后面都有名字，每条依赖都有两个确认人。

基线不是项目经理一个人的文档，它是跨部门团队共同签下的承诺集合。它的价值不在于画得多完整，而在于偏差出现时，所有人都有一个共同的参照，知道该纠偏还是该走变更，该找谁而不是等谁。计划表解决的是"打算怎么做"，基线解决的是"谁来认账、变了怎么办"。

如果你准备动手，我建议下一步只做三件事：先选出当前最混乱的一个跨部门项目，用五问检验法做一次基线体检；然后花两天时间搭出责任矩阵和里程碑依赖表的初稿；最后在下一次跨部门会上，正式提出基线发布和变更入口的规则。三件事做完，你已经比大多数团队走得远了。