项目立项如何做好项目背景？跨部门团队实操方法与操作步骤

上周三晚上十点，一个做智能硬件的朋友在电话里跟我复盘他们刚黄掉的项目。预算 480 万的产线数字化改造，横跨生产、质量、IT、财务四个部门，方案写了 60 页，结果立项评审会上被 CFO 三个问题问停：“这个项目不做会怎样？”“为什么是今年做？”“为什么是你们部门牵头？”他当场答不上来。问题不在方案质量，而在那 60 页里只有 4 页讲背景，而那 4 页里三页是行业趋势截图和领导讲话摘录。

这个场景我见得太多了。项目背景是立项材料里最像“走过场”的部分，却往往是唯一真正决定项目生死的一页。我做过八年企业数字化项目的立项辅导，经手和评审过的立项材料保守估计超过 300 份，今天把跨部门团队做项目背景的完整方法拆开讲，包括我踩过的坑、验证过的步骤，以及一套可以直接复制的工作流。

一、核心结论：项目背景不是“介绍”，是决策证据链

先把最反常识的结论放在前面：项目背景的写作目标不是让读者了解情况，而是让一个没参加过前期讨论的决策者，在十分钟内自己得出“这个项目应该做”的结论。这两件事看上去接近，实际完全不同。前者是叙述，后者是举证。

1. 我判断一份背景写得好不好，只看三个标准

可验证：每一个关键论断后面，都跟着一个可以被查证的事实、数据或文件编号。不是“效率低下”，而是“2024 年 Q2 平均对账周期 6.5 天，财务部月度加班 240 小时”。

可比较：现状和某种参照系放在一起。参照系可以是历史同期、兄弟工厂、行业基准、竞品水平，甚至就是“不做的话一年后会变成什么样”。没有参照系的数据，说服力会掉一半以上。

可归因：能说清楚“为什么这个问题现在必须由这个项目、这个团队来解决”，而不是一句“领导很重视”。决策者真正想确认的，是这件事和你之间有没有必然关系。

2. 跨部门场景还多一个要求：背景要当“共识凭证”

单个部门的立项，背景主要是给上级看的。跨部门立项不一样，背景同时要承担第二个功能，证明各部门已经就“问题是什么”达成了一致。很多项目死在执行阶段，根因不在资源，而在于生产部认为问题是“排产靠经验”，IT 部认为问题是“系统太老”，两个部门从立项那天起就在说两件事。

所以跨部门团队写背景时，我会要求多留一类内容：各部门对问题的原始表述，以及最终收敛后的统一表述。这份材料在项目中期吵起来的时候，能救命。

二、真实场景：跨部门立项为什么总在“背景”这一页卡住

我把近三年失败的立项案例做了归类，发现一个规律：方案部分被否的比例不到两成，背景部分被质疑到无法推进的比例接近六成。这不是因为评审专家爱抠字眼，而是因为背景是整个立项逻辑的地基，地基一松，后面所有投资测算、收益预测、里程碑都会被连带质疑。

1. 一个 480 万项目的完整复盘

回到开头那个朋友的项目。我后来帮他重新做了一遍背景，才发现问题的真实面貌：生产部认为痛点是换线时间长，平均一次换线 92 分钟；质量部认为是批次追溯慢，出问题要翻三天纸质记录；IT 部认为是 MES 和 ERP 之间的数据靠人工搬运，每月重复录入 1.2 万条。三个部门说的是三件事，被硬塞进同一份立项材料，评审专家看到的自然是一堆互不相关的现象。

真正让项目起死回生的动作很朴素：我们把三个部门的问题重新归因，发现它们共享同一个上游原因，产线数据采集点位不足，导致所有下游环节都在用人工补数据。这个归因一旦成立，480 万的预算就变得可以解释了，因为它一次性解决了三个部门的问题，而原来每个部门单独报预算，加起来是 610 万。

2. 跨部门背景最典型的三类冲突

口径冲突：同一件事，生产部说“每天损失 3 万”，财务部说“账面看不出来”。这类冲突不能靠协调解决，必须靠统一计算口径，把分子分母写清楚。

时序冲突：A 部门的问题是过去三个月才出现的，B 部门的问题是积累了五年的。放进同一份背景里，会让人怀疑项目的紧迫性到底是真紧迫还是临时起意。

归因冲突：每个部门都倾向于把问题归结到别人身上。这是人的本能，不是道德问题。我的处理办法是在访谈时只问事实不问责任，比如不问“为什么交付总是延迟”，而问“上个月 12 号那批货延迟了 4 天，当天发生了什么”。

3. 为什么“事情很急”永远说服不了评审专家

我统计过我们经手的立项答辩记录，凡是出现“形势紧迫”“窗口期有限”这类表述但没有量化支撑的，被追问的概率是 78%。原因很简单：紧迫性是可以被伪造的，而代价是可以被计算的。评审专家的职业习惯，就是把不可验证的形容词自动降权。

三、拆解常见误区：我见过最多的五种背景写法

下面这五种写法，出现在我审阅过的超过一半的立项材料里。它们不一定错，但几乎一定会让评审节奏变慢，甚至直接触发否决。

1. 误区一：把行业趋势当项目背景

典型句式是“随着数字化转型的深入推进……”。这类内容的问题不是不正确，而是它同时适用于一万个项目，因此对这个项目零信息量。评审专家每年看几十份立项材料，这类开头会自动被跳过。

我自己的处理规则是：行业趋势最多写两句，而且必须落到本企业的具体位置。比如不写“行业数字化率已达 62%”，而写“同规模同业中已有 7 家完成产线数据自动采集，我们目前的采集点位覆盖率是 31%，在可对标的 9 家企业中排第 8”。

2. 误区二：把领导讲话当立项依据

引用领导讲话不是问题，问题在于引用完就结束了。领导讲话应该被翻译成可执行的目标：领导说“要提升交付能力”，那背景里就应该接着写清楚“交付能力的当前基线是多少、目标是多少、差距来自哪几个环节”。否则这段话在一周后就会失去效力。

3. 误区三：只写现状痛点，不写“不做的代价”

这是我认为最致命的一个误区。绝大多数背景材料把 80% 的篇幅用来描述问题有多严重，却几乎不写如果什么都不做，未来 12 个月会发生什么。而决策的天平恰恰是靠这一端压下去的。

我要求团队在背景里必须有一段专门写“维持现状的成本”，并且要拆成三块：直接可量化的成本、机会成本、风险敞口。年化数字比月度数字更有冲击力，这是我在实践中反复验证过的。

4. 误区四：背景里塞满了技术方案

“采用微服务架构、引入中台能力”，这类内容出现得越早，评审专家越容易陷入技术细节的争论，而忘记确认业务问题本身是否成立。我的建议是把所有方案相关内容全部推到背景之后，背景只回答三个问题：发生了什么、为什么是现在、不做的后果是什么。

5. 误区五：跨部门背景只有牵头部门的视角

牵头部门写背景时，很容易不自觉地把自己放在主角位置。但评审专家会立刻问：“这件事对质量部有什么好处？”如果背景里只有牵头部门的收益，其他部门就会在评审现场保持沉默，而沉默在立项会上等同于反对票。

我的做法很直接：让每个参与部门在背景材料里都有一段属于自己的“问题陈述”，并且标明这段陈述由该部门负责人确认过。这个动作看起来只是加了五行字，但它把跨部门立项从“我牵头”变成了“我们一起”。

四、专业判断逻辑：项目背景的四层证据模型

把上面这些经验收拢起来，我最终固定下来一套写作框架，叫四层证据模型。它的价值在于：把“背景”这个模糊的概念拆成四层可检查、可补漏的结构，哪层缺了一目了然。跨部门团队尤其需要这个框架，因为四个人各写一段的产物，往往不成体系。

1. 第一层：外部事实层，为什么这件事在客观上成立

这一层放的是不依赖本企业立场就能成立的事实：政策变化、客户要求、供应链变化、行业标准更新、竞品动作。它的作用是提供“客观性背书”。

我要求这一层的内容必须满足一个条件：把这个事实拿给一个完全不了解公司的人看，他能判断出它确实存在。比如“某大客户在 2024 年 3 月的供应商审核中新增了批次追溯条款，未达标将影响年度份额”，这是事实层；“客户对交付越来越不满意”，这不是，这是内部感知。

2. 第二层：内部数据层，为什么这件事在本企业成立

这是最容易被写虚的一层。我的判断标准是：每一个数据都要能追溯到系统、报表或原始记录。写“库存周转慢”不合格，写“截至 2024 年 6 月，A 类物料平均周转 87 天，B 类 134 天，高于去年同期的 76 天和 112 天”才合格。

跨部门团队在这一层最容易打架。我的处理办法是先对齐口径，再讨论数字大小。口径包括：统计周期、数据来源系统、取数时点、是否含税、是否含在途。这五项写清楚，后面的争论会减少一大半。

3. 第三层：决策约束层，为什么是现在、为什么是这种规模

这一层是绝大多数团队完全漏掉的。它回答的是资源约束下的选择问题：为什么不能等明年做？为什么预算必须是这个数而不是一半？为什么不能拆成三个小项目？

我的经验是，这一层写得越清楚，方案部分被挑战的概率越低。因为决策者心里的问题其实就这几个，你在背景里主动回答了，评审会就变成了确认会。

4. 第四层：共识确认层，为什么是这些部门一起做

最后一层专门服务于跨部门场景。内容包括：本次立项涉及哪些部门、每个部门认可的问题陈述、部门之间的依赖关系、已经达成的初步分工共识。

很多团队觉得这层内容“太软”，不好意思写进正式材料。但我的观察正好相反：凡是背景里明确写出了部门共识的立项，在后续执行阶段的项目变更率明显更低。因为大家在前一天就已经把话说开了。

五、跨部门团队的项目背景七步实操法

框架讲完，下面是我实际带团队执行的一套流程。它之所以是七步，是因为我把每一步的产出物都固定下来了，没有产出物的步骤，在跨部门协作里等于没做。

1. 第一步：锁定决策人和决策标准

动笔之前先做这件事。列出这次立项要经过的评审层级，每一层的决策人是谁，他最关心什么。技术评审关心可行性，财务评审关心投入产出和现金流，业务评审关心对自己部门的影响，高管评审关心战略一致性和风险。

这一步的产出物是一张表：决策人 / 角色 / 最关心的三个问题 / 我准备用什么证据回答。我见过太多团队跳过这一步，结果背景写得极其用心，但完全没有对准任何一个评审人的关注点。

有一个细节值得强调：跨部门立项的决策人往往不止一个，且他们的关注点互相冲突。财务希望预算越少越好，业务希望范围越大越好，这时候背景要做的不是回避冲突，而是把冲突显性化，并给出取舍的依据。

2. 第二步：建立背景证据池

不要一开始就想怎么写，先收集素材。我要求团队在两天内完成一个证据池，按四层归类，每一条证据记录六个字段：内容、来源、时点、责任人、可信度评级、可引用位置。

实际收集时，我最常用的五个来源是：业务系统的原始报表、近 12 个月的问题工单和故障记录、客户投诉或审核记录、财务的成本明细、一线人员的访谈记录。其中一线访谈的价值经常被低估，因为报表能告诉你发生了什么，但只有一线能告诉你为什么会这样。

3. 第三步：跨部门访谈（怎么做才有效）

跨部门访谈最容易变成抱怨大会。我用的方法叫“事实回溯法”：不问你有什么问题，而是请你回忆最近一次具体的事件，从时间线开始讲。

我的访谈提纲固定为六个问题：

• 最近三个月，哪一天你印象最深？那天发生了什么？
• 这件事从什么时候开始出现，频率如何？
• 出现的时候你们是怎么补救的，花了多少人多少时间？
• 如果不补救，会发生什么后果？
• 你们认为的根本原因是什么？有没有不同的看法？
• 如果有一个项目能改善它，你希望它先解决哪一部分？

第六个问题的答案，往往就是后面范围界定的起点。我在实践中发现，把访谈记录原封不动地附在背景材料后面，比任何转述都有说服力。

4. 第四步：数据取证与口径对齐

这一步经常被压缩，但它决定背景的可信度上限。我的做法是先出一份口径说明书，再去取数，说明书写清楚五项：统计周期、数据来源系统、取数时点、计算规则、剔除项。

跨部门场景里有个高频陷阱：同一个指标，业务系统和财务系统算出来的数字不一样。不要在背景里选一个“好看”的，而要写清楚差异原因。我通常会写成“业务系统口径为 X，财务口径为 Y，差异主要来自在途订单的确认时点”，这种写法反而会大幅提升评审专家对你的信任度。

如果历史数据确实拿不到，就做小样本测量。我做过一个案例：为了验证拣货效率问题，我们在仓库蹲了三个班次，手工记录了 240 次拣货的完整路径和时间，最终得到“平均绕行距离 186 米、单次拣货 4.7 分钟”的结论。这份手写记录在评审会上的说服力，超过了所有系统报表。

5. 第五步：写“不做的代价”

这是我认为最能拉开水平差距的一步。我要求把它拆成三段来写，每一段都必须有数字。

直接成本：维持现状每年多花的钱、多投入的人力。机会成本：因为这个问题错失的收入、份额、订单或资质。风险敞口：一旦发生就难以承受的尾部风险，比如客户流失、审核失败、合规处罚。

三段的写法有区别。直接成本要精确，机会成本要保守，风险敞口要给概率区间。我一般的表达是“若 2025 年出现一次 A 类客户审核不通过，按历史损失区间估算，影响年度收入 6%，11%，发生概率约 20%，30%”。给出区间的数字，比给出一个漂亮数字更专业。

6. 第六步：跨部门预审会

正式评审之前，我一定会组织一次内部预审，只做一件事：让每个部门用五分钟讲一遍“你在这份背景里被写成了什么样子”。这个环节的作用是提前暴露认知差异。

我遇到过不止一次，质量部看完背景后说“我们从来没说过追溯慢是我们的主要痛点，我们想解决的是检测数据孤岛”。如果不是预审提前发现，这句话会在正式评审会上被说出来，效果完全不同。

预审会还要解决一个隐性问题：让每个部门在背景里看到自己的“收益归属”。如果某个部门在背景里只出现困难不出现收益，它在执行阶段的配合度一定不高。

7. 第七步：成稿与版本管理

最后一步是把材料固化下来，并且管好版本。跨部门立项的背景材料往往要改十几稿，改到后来没人知道哪句话是谁改的、为什么改。

我的做法是给背景材料建立版本记录，每一稿标注三件事：改动内容、改动原因、确认人。这份版本记录本身就是跨部门共识的证据，在后续项目出现争议时，它能证明某些决定是集体做出的，而不是某一个部门事后追加的。

六、案例与数据观察：一家 1200 人制造企业的立项背景改造

讲一个可以落地的完整案例。这是一家做精密结构件的制造企业，约 1200 人，跨部门的立项涉及生产、质量、工艺、IT、财务五个部门。他们的问题很有代表性：立项材料写得不少，但评审会永远开不完，一个项目平均要评审 4 次以上。

1. 改造前的状态：背景材料靠“拼接”

改造前，他们每个部门分别提供一段背景，由项目牵头人拼成一份文档。结果是五个部门说五件事，数据口径互不相同，财务看到生产部报的成本数字时当场质疑过两次。

更麻烦的是证据无法追溯。评审专家问“这个 92 分钟是怎么算出来的”，没人能答上来，因为那是三年前某次内部会议纪要里的一句话。这类问题在一次评审会上出现过 7 次，直接导致会议延期。

2. 关键改造动作：把证据链沉淀在项目管理平台上

这家企业用的是 PingCode，一家主要服务中大型企业及 100 人以上组织的项目管理平台，支持私有化部署，也支持从 Jira 平滑迁移。他们之前就在用 Jira，2023 年整体迁移到 PingCode，所以历史需求、缺陷、工单数据是连续的，这一点后来在立项背景改造中起到了关键作用。

具体做了三件事。第一，把立项背景的每一条证据都建成一个工作项，附上数据来源、取数时点和责任人，而不是写在 Word 里。评审专家问到任何一个数字，都能在系统里点开看到原始来源。

第二，把历史缺陷和工单数据作为背景证据池。他们从过去 18 个月的缺陷记录里筛出了 3 个高频问题类型，占比合计 71%，这个数据直接成了背景材料里“问题紧迫性”的核心论据，而且因为数据来自自家系统，可信度极高。

第三，把跨部门预审会搬到平台上，各部门对背景材料的确认动作留痕。每个部门负责人在系统里确认自己那段问题陈述，确认时间和确认人自动记录。这个动作把“我们部门认可这个问题”从口头承诺变成了可查证的记录。

顺带说一句，他们选择私有化部署的原因很实际：立项数据涉及成本、客户、工艺参数，不能出内网。这一点在评估同类平台时是个硬门槛，尤其是百人以上、有合规要求的中大型组织。

3. 改造前后的数据变化

改造持续了大约一个季度。下面这组数据来自该企业 2023 年 Q3 到 2024 年 Q4 的内部统计，为示意口径，用于说明变化趋势。

有一点我想特别说明：背景材料准备耗时下降，不是因为他们写得更少了，而是因为他们不用再反复找数据、反复对齐口径。改造后单份背景的字数其实增加了约 30%，但其中可追溯数据条目从 4 条涨到 23 条。写得多不等于写得慢，找不到证据才是真的慢。

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

方法不能一刀切。下面按角色和场景给出我认为优先级最高的动作，都是我实际验证过、见效比较快的。

1. 如果你是牵头业务部门

你最该做的是把“不做的代价”写扎实。业务部门的优势是懂一线、拿得到真实场景，劣势是财务语言弱。所以我建议你至少找一个财务同事帮你把代价折算成钱，哪怕只折算三项。

具体动作：挑过去 12 个月里最典型的三个事件，把它们的完整时间线、人力投入、返工成本和外部影响写出来。三个真实事件的说服力，远超过十个概括性的痛点描述。

2. 如果你是 PMO 或项目管理办公室

你的核心价值是做模板和检查机制，而不是替业务部门写背景。我建议你建立三样东西：背景材料的四层证据检查表、口径说明书模板、立项前预审会的标准议程。

另外一件事值得做：建立历史立项背景库。同一类项目第二次立项时，可以直接复用第一次的背景框架和数据口径，省下来的时间非常可观。我在一家零售企业推动过这件事，他们第二次做同类项目立项时，背景准备时间从 3 周降到了 5 天。

3. 如果你是 IT 或数字化部门

你在跨部门立项里经常扮演“被要求出方案”的角色。我的建议是不要在背景阶段就急着讲技术方案，而是先把业务问题翻译成可测量的指标，输出给业务部门确认。

你们手上最容易忽略的资产是系统日志和工单数据。这些数据是天然的背景证据，取数成本几乎为零，可信度却很高。我通常会让 IT 同事在立项前跑三张表：近 12 个月的高频问题排行、处理时长分布、人工干预次数。这三张表基本能撑起背景的材料层。

4. 如果你是刚组建的跨部门小组

先别写材料，先做两件事：统一问题表述、明确每个部门在背景里的“出场方式”。前者靠访谈和归因，后者靠分工表。

我会给每个部门分配一个明确的写作任务：谁负责外部事实，谁负责内部数据，谁负责部门影响。每个部门只写自己最擅长的那部分，最后由牵头人统稿。这样能避免所有人都写“行业趋势”这种无效内容。

八、不同情况下的取舍

前面讲的是标准动作，但真实项目里永远资源不足、时间不够。下面是我在不同约束下实际做出的选择，以及为什么这么选。

1. 时间紧 vs 证据全

如果只剩三天，我的取舍顺序是：先保“不做的代价”，再保“一个可验证的核心数据”，最后才补外部事实层。原因是决策者最容易被打动的是代价，最容易被质疑的是数字，而外部事实层的必要性最低。

如果只剩一天，那就只做一件事：找一个最近发生、有完整记录的真实事件，把它写透。一个具体案例的说服力，往往超过十页概括分析。

2. 数据拿不到时的替代方案

我遇到过很多次系统数据缺失的情况。这时候我会用小样本测量、专家估算法、行业基准对比三种替代方案，并且明确标注这是估算而非实测。标注清楚反而会加分，因为评审专家最忌讳的是拿估算冒充实测。

具体做法是：小样本取 100，300 个观测点，做区间估计而不是点估计；专家估算至少找三个人独立给数，取区间；行业基准要注明来源和可比性限制。

3. 部门利益冲突明显时怎么办

这种情况我的做法是把冲突写进背景，而不是藏起来。具体形式是在背景里加一小段“不同部门的关注点差异”，客观陈述各方诉求，然后说明本项目的设计如何同时回应这些诉求。

这么做有两个好处：一是让评审专家看到团队已经识别了风险；二是把潜在的内部争议提前放在桌面上，避免它在执行阶段以变更单的形式爆发。

4. 一年期项目 vs 三年期项目

短期项目的背景重点在紧迫性和快速见效，数据颗粒度要细，时间窗口要窄。我一般要求写到季度级，比如“如果 Q3 之前不能上线，会错过某客户的年度审核窗口”。

长期项目的背景重点在战略一致性和演进路径，这时候单点数据反而不重要，重要的是说明“为什么这个问题会长期存在、为什么现在开始做可以分阶段收效”。我一般会给出 12 个月、24 个月、36 个月三个时点的目标状态，而不是只给一个终局。

九、可直接复用的模板与自检清单

这一节给的是拿来就能用的东西。模板经过多次简化，控制在两页以内，因为太长的模板没人愿意填。

1. 一页纸项目背景模板

【项目背景】

结论前置（3 行以内）
本项目要解决的核心问题是：__________

如果不解决，未来 12 个月的影响是：__________

建议在 ____ 前启动，原因是：__________

外部事实（2，3 条，可查证）

事实内容 / 来源 / 时点
事实内容 / 来源 / 时点
内部数据（3，5 条，带口径）

指标名 / 当前值 / 参照值 / 口径说明 / 数据来源
……

不做的代价（分三块）
直接成本：____ 元/年

机会成本：____ 元/年（保守估计）

风险敞口：概率 ____%，影响区间 ____

决策约束
为什么是现在：__________

为什么是这个规模：__________

为什么不能拆分：__________

跨部门共识
涉及部门 / 各部门认可的问题陈述 / 已确认的分工

这个模板我用了大概四年，最大的改动是把“结论前置”放在最前面。很多评审专家只看前三行就决定要不要认真读下去，所以别把最重要的判断藏在第五页。

2. 立项前自检 12 问

提交之前把这份清单过一遍，我要求团队任何一项答“否”就必须回去补。

1. 背景里有没有一个可以被查证的量化现状？
2. 每个数字的口径、来源、时点是否写清楚？
3. 有没有写明“如果不做，12 个月后会发生什么”？
4. 外部事实的表述是否与本企业的具体位置挂钩？
5. 有没有解释“为什么必须是今年”？
6. 有没有解释“为什么是这个预算规模”？
7. 有没有说明“为什么不能拆成多个小项目”？
8. 每个参与部门是否都有自己的问题陈述？
9. 各部门的问题陈述是否指向同一个上游原因？
10. 背景里有没有混入技术方案内容？
11. 是否做过跨部门预审，各部门是否确认过自己的表述？
12. 版本记录是否完整，能否追溯到每一处改动的确认人？

第 9 问是最容易被忽略的一问。如果各部门的问题陈述指向不同的上游原因，那这个项目本质上还是几个独立项目拼在一起，预算会被质疑，范围会被反复讨论。

3. 背景材料常见问题速查表

十、常见问题答疑

1. 背景写多长合适？

我的经验值是正文 800，1500 字，附件不限。正文超过 2000 字，评审专家的阅读完成率会明显下降。但附件可以放得很厚，包括访谈记录、原始报表、口径说明，因为它们的价值在于被质疑时可以随时调取。

2. 数据不好看，要不要写进去？

要写，但要用正确的表述方式。不利数据如果被评审专家自己发现，损害远大于你主动说明。写法是：陈述事实、说明原因、给出应对。比如“返工率在 2024 年 Q2 上升到 9.1%，主因是新产品导入期工艺不稳定，本项目正是针对该环节”。

3. 跨部门访谈要访谈多少人？

我的经验值是每个部门 2，3 人，其中必须有 1 名一线执行人员和 1 名基层管理者。只访管理者容易得到官方表述，只访一线容易得到情绪化表述，两者交叉验证后的事实最接近真相。

4. 背景要不要写竞品对标？

要看情况。如果对标数据公开可查且口径可比，写进去是加分项。如果只能拿到零散传闻，我建议不写，因为一旦被质疑来源，整份材料的可信度都会被拖累。

5. 立项被否了，背景还能复用吗？

能，而且这是最高效的复用场景。我通常会在被否后立刻做一次复盘，把评审专家提出的所有质疑整理成清单，逐条补充证据。下一次立项时，这份补充后的背景通过率会明显提升。被否不是浪费，浪费的是没有被记录下来的质疑。

十一、总结：背景写得好的人，赢在证据的组织方式

回到开头那个朋友的项目。他后来重新做了一遍背景，把三个部门的问题归因到一个共同上游原因，用 240 次手工观测换来了换线时间的真实分布，把“不做的代价”折算成年化 620 万的损失区间。第二次评审，18 分钟通过。

我想说的独特观点是：项目背景的水平差异，本质不在写作能力，而在证据的组织能力。会写的人不是词藻更漂亮，而是更早地知道决策者会问什么、更快地拿到能回答这些问题的材料、更准地把它们放在最容易被看到的位置。

跨部门团队尤其如此。单个部门的立项靠一个人想清楚就够了，跨部门立项必须靠一套流程把五个人的认知拧到一起。四层证据模型解决结构问题，七步法解决执行问题，自检清单解决遗漏问题，这三样东西组合起来，才是跨部门背景写作的真正门槛。

下一步你可以这样做：先别改动现有材料，拿最近一个正在推进的立项，用第九节的自检 12 问过一遍，把答“否”的项挑出来。通常情况下，你会发现 3，5 个缺口，集中在“不做的代价”和“跨部门共识”这两块。这两块恰好也是投入产出比最高的部分，补上它们，通常只需要三到五天，但能省下后面几个月反复评审的时间。