项目立项如何做好项目背景？企业管理者数据分析与操作步骤

去年 4 月，我陪一家 800 人规模的汽车零部件企业做研发管理平台立项复盘。项目在董事会上被否，理由只有一句话：你们讲了 12 页行业趋势，但没人告诉我，这件事不做，公司一年会损失什么。会后我们把项目背景推倒重写，从 11 页压到 1 页，只留 6 个数字和 3 条硬约束。第二次上会，25 分钟通过，预算一次批了三年。

这个反差几乎每年都会在我参与的立项评审里重演一次。项目背景写得好不好，不取决于文笔，也不取决于你引用了哪家咨询公司的报告，而取决于你有没有把”不做的代价”算清楚。

这篇内容面向两类人：正在准备立项材料的管理者，和正在评审别人立项材料的管理者。下面这套判断逻辑、取数方法和操作步骤，是我在几十个中大型企业项目里反复用过、也反复踩过坑之后沉淀下来的，可以直接拿走用。

一、核心结论：项目背景的唯一使命，是证明”不做的代价高于做的代价”

1. 背景章节不是介绍，是论证

大部分立项材料把背景写成”公司介绍 + 行业趋势 + 我们有点问题”。这是把背景当成了开场白。但在真实的评审场景里，背景章节承担的是全篇最重的决策责任：它决定评审人要不要继续往后看，也决定预算要不要被砍。

我在 41 次立项评审的旁听记录里做过一个粗略统计：评审人在背景页的平均停留时间是 2.5 分钟，而 41 次否决意见中有 23 次（约 56%）的形成点就在背景页。也就是说，一半以上的项目在背景环节就已经死了，后面的方案写得再漂亮也没机会被看到。

所以背景章节的目标不是”讲清楚我们是谁”，而是回答一个问题：为什么是现在、为什么是这件事、不做会怎样。三个问题答不上来，材料就不该上会。

2. 三句话讲清背景的合格线

我常用的合格线是三句话：痛点的规模有多大（多少钱、多少人、多少时间）、痛点正在恶化还是稳定（趋势）、不做的话一年损失多少（不行动成本）。这三句话里必须包含可追溯的数字。

如果对方追问”这个数字从哪个系统导出来的”，你能当场答出来，背景才算过关。答不出来，说明背景还是形容词。

3. 背景章节和可行性章节的分工不能混

很多材料写崩，是因为把”为什么做”和”怎么做”糅在了一起，导致背景里出现大量方案细节，评审人读得累，还得自己从方案里反推问题。这两章的分工可以用下面这张表来对齐。

把这张表贴在写材料的电脑旁边，你会发现背景章节要砍掉的内容比要加的多得多。

二、真实场景：三个立项背景翻车现场，和一份 137 份材料的复盘

1. 场景一：800 人制造企业，第一版背景写了 11 页被否，第二版 1 页过审

这家企业研发 320 人，分 4 条产品线、11 个 Scrum 团队，已经用了 7 年的某海外研发管理工具。项目目标是把研发管理平台迁到国产平台（最终选型是 PingCode），同时重构需求流转流程。

第一版背景写了 11 页，其中 8 页是”数字化转型是大势所趋”加上三家咨询机构的市场规模引用，剩下 3 页写”当前工具不满足业务需求、协作效率低、跨部门沟通不畅”。董事会当场否掉。

第二版背景压到 1 页，只有 6 个数字和 3 条约束：

• 需求平均交付周期 68 天，对标同行标杆 45 天，差距 51%；
• 版本延期率 42%，其中约三分之二延期可归因到跨团队依赖与需求范围失控；
• 跨团队对齐会每周 6 场，每场 8 人 90 分钟，按 48 个工作周计约 3,456 人时/年，折合人力成本约 44.9 万元（人时成本按 130 元计）；
• 海外工具年费约 179.2 万元（320 人 × 5,600 元/人年），另有 1.5 FTE 投入在插件与报表维护上，年成本约 63 万元；
• 3 个关键客户合同含季度交付承诺，当年已发生 1 次违约赔付 46 万元、2 次商务折让共计 92 万元；
• 7 年历史数据：工作项 92 万条、附件 1.4 TB，海外供应商本地化版本合同 2026 年 3 月到期且不再续签。

3 条约束是：客户合同含数据不出境条款、集团内控要求私有化部署、迁移窗口只有 6 周且停机不能超过一个周末。这 3 条约束直接决定了后面的方案形态，但它们首先属于背景，因为它们是”为什么是现在”的一部分。

同样的项目、同样的方案，第二版 25 分钟过审。差别不在方案，在背景。

2. 场景二：集团数字化项目，因为背景没有基线被退回，错过预算窗口

第二个案例更常见。某集团要立项做统一的经营管理看板，背景写的是”当前管理效率低、数据分散、决策依赖经验”。评审现场 CFO 只问了一句：你说的效率低，具体是多少？月结出具时间延长了多少天？

汇报人答不上来，材料退回补充，来回折腾了两个月，错过当年预算窗口，项目推迟到下一个财年。直接损失不是钱，是时间，而时间窗口恰恰是立项里最贵的资源。

3. 场景三：国产替代驱动型立项，用效率话术讲合规问题，说服力打折

第三个案例是典型的驱动类型错配。项目本质是国产替代和供应链安全，但汇报人用了”提升研发效率 30%”这种效率话术来写背景。结果财务部门第一反应是”那你能证明这 30% 吗”，评审方向被带偏。

这类项目的背景重心应该放在风险敞口和时间表上：现有供应商的合同节点、数据出境合规要求、断供情景下的业务中断天数、切换所需的最短周期。效率提升可以写在收益章节，不该是背景的主线。

4. 数据复盘：137 份立项材料里，背景章节到底写了什么

我让团队把 2022，2024 年留存的中大型企业立项材料做了标注复盘，共 137 份，覆盖制造、金融、互联网、能源四个行业。需要说明：这是内部经验样本，不是公开统计，仅用于说明结构性规律。

结果是：背景章节平均 420 字，其中约 63% 的篇幅是外部趋势、政策或行业报告复述；只有约 11% 的篇幅给出了企业内部的可量化损失；明确写出”不做的代价”的只有约 9%。

更有意思的是量化程度和评审结果的关系。我们把 137 份材料按”是否包含可追溯的内部量化损失”分成两组，再对照它们的评审结果和讨论时长。

三、拆解七个常见误区：背景写不好，通常不是因为不会写

1. 误区一：把背景写成行业研究报告

典型症状是前五页全是市场规模、增速、渗透率。问题在于，这些内容对评审人的决策没有任何增量信息，他大概率比你更熟悉行业。外部数据唯一的合法用途是做标尺，不是做主体。

改法：任何一条外部数据后面必须紧跟一条内部数据，形成对比。比如”行业标杆需求交付周期 45 天，我们当前 68 天，差距 51%”。外部数据只出现一次，作为分母。

2. 误区二：只有形容词，没有基线数字

“效率低、沟通成本高、协同不畅”这三句话几乎是立项材料的通用模板，但它们无法被验证，也无法被反驳，因此也无法被采信。

改法示范。原句：”当前研发协作效率低，沟通成本高。”改后：”2024 年 7 月至 2025 年 6 月，11 个 Scrum 团队的跨团队对齐会共 288 场，累计消耗约 3,456 人时，折合人力成本约 44.9 万元，占研发总工时约 2.8%。”数字一旦落地，讨论就会从”有没有这个问题”变成”要不要解决这个问题”，这是完全不同层级的对话。

3. 误区三：把”领导要求”当成唯一动因

“董事长要求做数字化转型”确实是真实动因，但把它写进背景等于放弃论证。正确做法是往下追一层：领导为什么现在提这件事？通常是看到了某个可量化的事件，客户投诉、竞标失利、审计发现、竞争对手动作。

找到那个触发事件，把它写进背景，你的材料就从”执行命令”变成了”响应真实问题”。

4. 误区四：在背景里提前下结论

背景写到一半出现”因此需要采购某研发管理平台”，这是把方案结论前置了。评审人一旦觉得你在替他们做决定，会本能地开始挑刺。

背景应该停在”问题与约束”，把方案选择留给后面的章节。你可以写”当前工具在跨团队依赖可视化上存在能力缺口”，但不要写”所以要换掉它”。

5. 误区五：缺少”不做的代价”

这是最致命的缺失。绝大多数立项材料只论证”做了有什么好处”，不写”不做会损失什么”。但预算审批的本质是一场机会成本比较，批给你的钱，本来可以投给别的项目。你不写不做的代价，就等于默认不做的代价是零。

6. 误区六：数据来源不可追溯

背景里写了”效率损失约 500 万元”，但没说口径、时间窗、取数系统、计算方式。这种情况在评审现场极容易被击穿：一位懂业务的评审人问一句”这 500 万怎么算的”，整段论证就崩了。

改法：每个数字后面标注口径，比如”（口径：2024-07 至 2025-06，研发管理平台工作项表，按已关闭需求计算，含节假日）”。这一点点的括号，是专业度的分水岭。

7. 误区七：只写静态现状，不写变化趋势

单点数值说服力有限。”延期率 42%”只是一个状态；但”延期率从 2024 年 Q1 的 26% 上升到 2025 年 Q2 的 42%，连续 5 个季度上升”，这是一个正在恶化的过程。后者才会带来紧迫感，而紧迫感才是”为什么是现在”的答案。

四、专业判断逻辑：四层结构、三个必须、五步取数法

1. 四层结构：好背景是分层的，不是平铺的

我习惯把项目背景拆成四层来写，每层回答不同层级的问题，写完检查一遍，缺层就补。

战略层回答”这件事和公司今年最重要的三件事是什么关系”。如果答不上来，说明项目可能不该现在做。

业务层回答”具体哪个流程、哪个指标在恶化，基线是多少”。这一层必须全是数字。

组织层回答”影响多少人、跨几个部门、涉及哪些角色”。这决定推行难度和变革成本。

约束层回答”有哪些不可协商的边界条件”，例如合同到期时间、合规要求、预算窗口、停机窗口。约束层经常被忽略，但它往往是”为什么是现在”的最硬答案。

2. 三个必须：可验证、可归因、可对比

每一组背景数据都要过这三道筛子。

• 可验证：数字能从业务系统、财务系统或合同里导出来，且口径可复现；
• 可归因：问题能追到具体流程或机制缺口，而不是”员工不努力””部门不配合”；
• 可对比：要么跟行业标杆比，要么跟自己的历史比，孤立数字没有意义。

三道筛子过不去的数据，宁可不写。一个说不清来源的数字，比没有数字更危险。

3. 五步取数法：先找数据源，再写文字

大部分人是先写完背景，再去补数据，结果补出来的数据是”找得到什么就写什么”。正确的顺序完全相反：先确定要证明什么，再去找能证明它的数据。

1. 定义决策问题：这次立项要让评审人做的决定到底是什么？是批预算、批人力，还是批一个方向？
2. 锁定 3，5 个北极星痛点指标：不要贪多。研发类项目通常是交付周期、延期率、返工率、依赖阻塞时长；管理类项目通常是审批时长、月结天数、人工处理人时。
3. 回溯数据源：把可用系统列出来，项目管理平台工作项表、工单系统、财务凭证、HR 花名册、合同台账、采购订单。
4. 建立 12 个月基线：至少覆盖 12 个月，含旺季淡季，否则趋势判断会被季节性污染。
5. 计算不行动成本：把损失折算成年度金额，这是背景章节的收口句。

第 4 步的取数逻辑可以用一段 SQL 示意。下面这段是从研发管理平台里拉需求交付周期基线的典型写法，注意它同时保留了团队维度和月份维度，这样你既能看整体趋势，也能定位到具体团队的异常。

-- 需求交付周期基线（近 12 个月，按团队 + 月份）
SELECT

t.team_name,

DATE_TRUNC('month', w.created_at) AS month,

COUNT(*) AS closed_items,

AVG(EXTRACT(EPOCH FROM (w.closed_at - w.started_at)) / 86400) AS avg_cycle_days,

PERCENTILE_CONT(0.5) WITHIN GROUP (

ORDER BY EXTRACT(EPOCH FROM (w.closed_at - w.started_at)) / 86400

) AS median_cycle_days

FROM work_items w

JOIN teams t ON t.id = w.team_id

WHERE w.item_type = 'story'

AND w.status = 'done'

AND w.started_at IS NOT NULL

AND w.closed_at >= NOW() - INTERVAL '12 months'

GROUP BY 1, 2

ORDER BY 1, 2;

用中位数和平均值一起看，是为了防止少数超长尾需求把均值拉高，导致你在评审会上被问”是不是个别案例”。这种细节，是背景可信度的一部分。

4. 不行动成本的量化公式

背景章节的收口，应该是一个年度金额。我常用的拆解结构是：不行动成本 = 人力浪费 + 延期与违约损失 + 冗余维护成本 + 机会成本。前四项可算，第五项保守估。

仍用前面那家汽车零部件企业做例子。它当年的不行动成本拆下来是这样的：

• 跨团队对齐会议耗时：3,456 人时 × 130 元/人时 ≈ 44.9 万元；
• 插件与报表维护投入 1.5 FTE：约 63.0 万元；
• 延期赔付 46 万元 + 商务折让 92 万元 = 138.0 万元；
• 返工重复开发：约 1,100 人时/月 × 12 个月 × 130 元 ≈ 171.6 万元；
• 机会成本（因交付周期长导致的丢单，按保守口径估）≈ 150.0 万元。

合计约 567.5 万元/年。而整个平台替换与流程重构的三年总投入约 320 万元。

5. 用一个可复用的计算脚本固化口径

为了不让每次立项都重新吵架”这个数怎么来的”，我建议把这个计算写成一个脚本，存进项目知识库。口径固化之后，评审时直接展示脚本和输出结果，讨论成本会大幅下降。

def cost_of_inaction(meeting_hours, hourly_cost, plugin_fte_cost,
penalty_and_discount, rework_hours, opportunity_cost):

"""计算年化不行动成本，所有金额单位为元"""

meeting = meeting_hours * hourly_cost

rework = rework_hours * hourly_cost

total = meeting + plugin_fte_cost + penalty_and_discount + rework + opportunity_cost

return {

"跨团队对齐会议": meeting,

"插件与报表维护": plugin_fte_cost,

"延期赔付与折让": penalty_and_discount,

"返工重复开发": rework,

"机会成本（估算）": opportunity_cost,

"年化合计": total,

}

result = cost_of_inaction(

meeting_hours=3456,        # 6 场/周 × 8 人 × 1.5 小时 × 48 周

hourly_cost=130,           # 综合人时成本，含社保与管理摊销

plugin_fte_cost=630000,    # 1.5 FTE 年成本

penalty_and_discount=1380000,

rework_hours=13200,        # 1100 人时/月 × 12

opportunity_cost=1500000,

)

for k, v in result.items():

print(f"{k}: {v / 10000:.1f} 万元")

这种做法的额外好处是：当业务增长、人时成本变化时，背景数据可以自动更新，不用每次重新手工算一遍。

6. 从原始数据到背景数字，需要一个收敛漏斗

取数阶段容易陷入”数据越多越好”的陷阱。实际上一份好的背景章节，最终只会用 5，8 个数字。中间必然经历一次残酷的收敛。

五、案例与数据观察：一个研发管理平台立项背景的完整拆解

1. 项目全貌

还是那家汽车零部件企业。研发 320 人，4 条产品线，11 个 Scrum 团队，年营收约 18 亿元。原有研发管理工具是海外产品，用了 7 年，累计产生工作项 92 万条、附件 1.4 TB。

触发立项的直接事件有三个：海外供应商通知本地化版本合同 2026 年 3 月到期不再续签；两个客户合同新增数据不出境条款；当年 Q2 因交付延期发生一次违约赔付。三个事件叠加，让”要不要换平台”从可选项变成了必选项。

2. 背景里怎么论证”不是加人就能解决”

这是我在这类项目里最常被问到的一问：既然交付周期长，多招点人不就行了？背景章节必须提前把这个退路堵上，否则方案章节会被反复拉回原点。

当时的论证是这样的：交付周期 68 天中，纯粹编码时间只占约 21 天，其余 47 天分布在需求澄清、跨团队依赖等待、环境排队、验收返工上。也就是说，约 69% 的周期消耗在等待与返工，而不是产能不足。加人只会让等待队列更长。

这个拆解直接决定了后面的方案方向：不是买人力，而是解决依赖可视化和流程流转。背景章节把根因写清楚，方案章节才有立足点。

3. 约束层怎么写：私有化、迁移窗口、历史数据

这个项目的约束层有三条硬边界：集团内控要求系统私有化部署；客户合同要求研发数据不出境；业务不能接受超过一个周末的停机。

这三条约束在背景里的表述方式很关键，它们不是技术需求，而是决策边界。写清楚之后，方案评估时 PingCode 支持私有化部署这一点就成了硬性门槛，而不是加分项。同批评估的几个 SaaS 产品在第一轮就被排除，不是因为功能弱，而是因为不满足背景里已经写明的约束。

同样，7 年历史数据 92 万工作项、1.4 TB 附件，意味着迁移能力必须是方案评估的一级指标。PingCode 支持从 Jira 平滑迁移，这一点在方案阶段被重点验证：先在测试环境跑了一轮全量迁移，核对工作项数量、状态映射、附件完整性、评论与变更历史保留情况，确认无误后才排正式窗口。

4. 迁移后 6 个月的真实数据

项目正式切换后，我们跟踪了 6 个月的关键指标。以下数据来自该企业内部系统导出，属于单个案例的观察值，不代表所有企业的普遍水平。

• 需求平均交付周期：68 天 → 51 天，降幅 25%；
• 版本延期率：42% → 19%；
• 跨团队对齐会：每周 6 场 → 每周 3 场，会议人时下降约 50%；
• 需求返工率：23% → 11%；
• 插件与报表维护投入：1.5 FTE → 0.3 FTE。

5. 延期归因：背景里的因果链必须经得起追问

背景写到”延期率高”，评审人一定会追问”为什么高”。如果答不上来，后面所有方案都失去依据。我们在取数阶段做了一次归因分析，把过去 12 个月的延期版本逐条回溯。

注意这个分析的一个副产品：累计 81% 的原因里，只有”跨团队依赖阻塞”这 22% 是工具能力可以直接改善的，另外约 40% 属于流程与治理问题。这意味着如果立项只买工具不改流程，预期收益要按比例打折。这一点写进背景，反而会提升材料可信度，它证明你真的理解问题结构，而不是在卖方案。

六、不同情况下的行动建议：先判断驱动类型，再决定背景重心

1. 合规/替代驱动型立项

典型场景是国产替代、数据合规、供应商合同到期、审计整改。这类项目的背景重心应该放在约束与风险敞口上，而不是效率收益。

必备数据包括：现供应商合同到期日、替代方案的最短切换周期、断供情景下的业务中断天数与折算损失、合规条款涉及的业务范围和数据量。篇幅建议 1 页，其中时间表占三分之一。

最常见的坑是用效率话术包装合规需求，导致评审焦点被带偏到”你能不能证明效率提升”。记住，合规项目的预算理由是不做会有风险，不是做了会更高效。

2. 效率/成本驱动型立项

这是最经典的类型。背景重心放在基线数据、恶化趋势和不行动成本上，四层结构里的业务层要写满。

必备数据：3，5 个北极星痛点指标的历史趋势、行业或集团内部对标值、人力与时间浪费的金额折算、根因分布。篇幅建议 1，2 页，加一页数据附录。

最常见的坑是只写现状不写趋势。单点值只能证明有问题，趋势线才能证明问题在恶化，而恶化才是紧迫性的来源。

3. 增长/机会驱动型立项

这类项目的背景逻辑不是”有损失”，而是”错过窗口会失去什么”。比如新产品线投入、海外市场系统建设、产能扩张配套的信息化。

必备数据：市场窗口期长度、竞品动作时间线、错过窗口的机会成本估算、现有系统支撑新业务的能力缺口。篇幅建议 1 页，重点在时间窗口而非痛点规模。

要注意的是，机会成本估算极易被质疑夸大。我的做法是给出保守/中性/激进三档，并明确说明采用保守档作为立项依据，把敏感度留给评审人自己判断。

4. 领导指定型立项

现实中最常见，也最容易被写成”因为领导要求”。处理原则是：不要回避，但要往下追一层触发事件。

行动路径是，先确认领导提出这件事的场合和触发点（通常是某次客户投诉、某份审计报告、某个竞标失利、某次对标参观），然后把这个触发点转化为可量化的业务问题，写进背景。领导的要求放在战略层作为背书，业务问题作为主线。

七、不同情况下的取舍：背景写作里没有标准答案，只有代价选择

1. 背景写 1 页还是写 5 页

取舍标准是评审人的决策距离。如果评审人是一线业务负责人，他熟悉业务细节，你写 1 页数字就够，写多了是浪费他时间。如果评审人是董事会或外部董事，他离业务远，需要 1 页主背景加 2，3 页数据附录，让他在被追问时能翻到依据。

我的默认建议是主文 1 页，其余全部下沉到附录。原因很简单：背景章节的作用是引发提问，不是回答所有提问。

2. 用行业数据还是用内部数据

答案很明确：内部数据为主，行业数据为辅且只做标尺。行业数据的问题是它无法被验证、也无法被归因，评审人听完不会有行动冲动；内部数据的问题是不够震撼，但可以追问、可以复查、可以对应到具体的人和流程。

唯一的例外是当你确实没有任何内部基线数据时，那说明项目还不具备立项条件，第一件事应该是建立基线，而不是写材料。

3. 给点估计还是给区间

财务类、合同类的数字给点估计，因为可以精确取数。涉及机会成本、效率折算、未来收益类的数字给区间，并注明采用哪一档作为决策依据。

过度精确是一种风险。把机会成本写成”损失 1,437 万元”会让人怀疑你在编数字；写成”保守估计 1,200，1,600 万元，本材料采用保守档 1,200 万元”反而更可信。

4. 先量化再立项，还是先立项再量化

能先量化就先量化。但我承认现实中有大量项目必须先立项、后补数据，尤其是政策窗口期紧迫的项目。

这种情况下的折中做法是：背景里明确写”当前为初步估算，口径与置信度说明如下”，并在方案阶段设置一个数据校核里程碑，到了这个节点如果数据不支持原假设，项目有权调整范围。把不确定性写进材料，比假装确定更专业。

5. 工具类立项和流程类立项，先做哪个

这个取舍在研发管理领域特别高频。判断依据是根因分布：如果帕累托图显示主因是流程缺失（比如需求变更无评审机制），先做流程治理，工具只是承载；如果主因是信息不可视（依赖关系看不到、阻塞无法预警），工具能力就是核心解。

我的经验是，中大型企业里两者往往同时存在，但优先级不同。100 人以下的团队通常流程问题更大，100 人以上的组织，随着跨团队协作节点指数级增加，信息可视化的瓶颈会更早显现，这也是为什么规模在 100 人以上的组织，对研发管理平台的能力要求会明显上一个台阶。

6. 不同评审角色的关注点差异

同一份背景材料，不同角色看的东西完全不同。写的时候要有意识地为每个角色准备对应的数字，但不改变主线结构。

八、落地模板与自查清单：从明天开始可以照做的事

1. 一页纸背景模板（六段式）

这是我用得最多的一页纸结构，六段写完，背景基本就齐了。

2. 数据取数清单

写背景之前，先把下面这张清单填一遍。填不满的部分，就是你的背景最脆弱的地方。

• 痛点指标名称与计算口径（例如”需求交付周期 = 需求进入开发到关闭的自然日天数”）；
• 取数系统与表名，以及谁有权限导出；
• 时间窗（建议 12 个月，覆盖完整业务周期）；
• 是否含异常值处理规则，中位数与均值是否一致；
• 对标值来源（行业报告、集团内部同类单位、自身历史最优）；
• 人时成本、人年成本的核算口径，以及是否含社保与管理摊销；
• 合同类金额的凭证编号，便于评审现场核查；
• 数据导出日期，避免”三个月前的数据”被质疑时效性。

3. 上会前的十项自查

1. 背景里有没有明确写出”不做会损失多少钱”？
2. 每个数字后面有没有口径说明？
3. 有没有至少一条趋势证据，证明问题在恶化？
4. 有没有行业或内部对标值作为标尺？
5. 根因分析是否落到具体流程，而不是”人不行”？
6. 有没有把方案结论提前写进背景？如果有，删掉。
7. 背景篇幅是否控制在一页以内？超出部分是否下沉到附录？
8. 约束层是否写全了时间、合规、资源三类硬边界？
9. 如果被问”这个数字从哪来的”，你是否能在 10 秒内答出来？
10. 把材料给一个不懂业务的同事看，他能否在 3 分钟内说出这个项目为什么必须做？

第十条是我最看重的自测方法。立项材料的读者往往不是领域专家，如果他们读完背景还说不出”为什么必须做”，那这份材料在评审桌上大概率撑不过五分钟。

4. 一个容易被忽略的动作：背景写完后回填验证假设

项目上线 6 个月后，把背景章节里的基线数据和上线后的实际数据做一次对照，写成一份简短的复盘。这有三个作用：验证当初的假设是否成立、为下一个项目积累可信口径、以及在组织内建立”背景数据是认真的”这一信任资产。

我见过做得最好的团队，会把每次立项的背景基线和上线结果存进一个共享表里，三年下来积累了几十个项目的真实数据。等到下一次立项时，他们取数、对标、估算不行动成本的速度，是其他团队的好几倍，这才是真正的组织能力。

结语：背景章节是立项里投入产出比最高的一页纸

回到开头那家汽车零部件企业。第一次上会被否，不是因为项目不好，而是因为材料没有回答”不做会怎样”。第二次过审，25 分钟，靠的不是更华丽的方案，而是 6 个数字和 3 条约束，它们把决策从”感觉有必要”变成了”算出来必须做”。

我对项目背景的核心判断只有一句：它不是介绍，是论证；不是现状描述，是不行动成本的证明。行业趋势任何人都能写，你真正无法被替代的，是你对自己组织内部数据的掌握程度和归因能力。

下一步你可以做的三件事：第一，挑一个正在准备的立项项目，用本文第五节的取数脚本跑一遍近 12 个月的基线数据，看看趋势到底是稳定还是恶化；第二，用第六节的四类驱动判断一下你的项目属于哪一类，然后按对应权重重写背景；第三，用第八节的十项自查过一遍现有材料，把不满足的项标红，先补最致命的那两三项。

做完这三步，你的立项材料大概率能从”讲了很多”变成”说清楚了”，而后者才是决定预算能不能批下来的那一页。