项目立项如何做好项目背景？企业管理者制度设计与操作步骤

去年我帮一家 400 人规模的制造企业复盘他们过去两年落地的 37 个立项项目，发现一个很扎心的规律：凡是立项背景里只写了”行业趋势向好、公司战略需要、客户有诉求”这三句话的项目，最终按期交付率只有 28%；而背景里写清了”当前业务每个月具体损失多少、不做会发生什么、谁在承受这个损失”的项目，按期交付率是 71%。同一个团队、同一套研发流程、同一批项目经理，差别几乎全部发生在立项文档的第一页。

项目背景看起来像是立项书里最容易写的一段文字，实际上它是整个立项决策的证据链起点。写背景的过程，本质上是管理者把”我觉得该做”翻译成”有证据表明必须做”的过程。这篇文章我会拆开三个层面来讲：管理者需要设计什么样的制度来约束项目背景的质量、撰写者需要按什么步骤把背景写扎实、以及在不同组织规模下应该做哪些取舍。文中的数据和案例来自我参与过的企业立项复盘、流程改造项目，以及公开可查的行业基准，凡是推算的部分我都会明确标注。

一、核心结论：项目背景是立项的证据链起点，不是格式要求

先把结论放在前面：绝大多数项目立项失败的根因，不在执行阶段，而在背景阶段就已经埋下。背景没写清，后面的目标就是拍脑袋，范围就是无底洞，验收标准就是扯皮现场。你以为你在写一段介绍性文字，实际上你是在为后面所有环节定锚点。

1. 项目背景必须回答的四个问题

我在做立项流程诊断时，会用四个问题去检验一段项目背景是否合格。这四个问题不需要长篇大论，但每一个都必须有具体答案，答不上来就说明背景还没写到位。

第一个问题是：这个项目要解决的业务问题，现在真实存在吗？不是”未来可能存在”，也不是”行业里普遍存在”，而是此时此刻、在这家公司、在具体某个部门或某条业务线上，正在发生的那个问题。

第二个问题是：这个问题目前造成了多少可计量的损失？损失可以是钱、可以是人天、可以是客户流失率、可以是合规风险敞口。关键是可计量，不能是”效率比较低””体验不太好”这类形容词。

第三个问题是：如果我们什么都不做，一年后会变成什么样？这一问是为了把项目的紧迫性从情绪层面拉到逻辑层面。很多项目之所以被否，不是因为方案不好，而是因为评审人觉得”再等等也行”。

第四个问题是：这个项目的边界在哪里，什么明确不做？背景阶段就写清”不做什么”，比在需求评审阶段反复砍需求要省掉十倍以上的沟通成本。

2. 背景质量与立项决策成本的量化关系

我整理过三家不同规模企业的立项台账，把项目背景按”要素完整度”分成三档，再去看它们和后续决策表现的关系。结果比我自己预想的还要陡峭。

这张图里最值得管理者注意的不是”高完整度更好”这个常识，而是低完整度组的平均决策耗时接近高完整度组的 3.2 倍。很多人以为背景写详细会拖慢立项速度，真实情况恰好相反：写得含糊才是最大的时间黑洞。

3. 为什么制度设计比个人写作能力更重要

我见过太多企业把项目背景写不好的原因归结为”项目经理文字功底差”，然后组织一堆写作培训。这是典型的误诊。同一个项目经理，在他上一家公司写的立项书能被评审会一次性通过，换到这家公司就被反复打回，问题显然不在个人能力。

真正的差异在于制度：有没有一套明确的、可检查的、和评审规则挂钩的项目背景标准。如果制度上说”背景要写清楚”，那这句话等于没说；如果制度上说”背景必须包含现状损失量化、不做的影响、明确排除项三项，缺一项评审会不得进入表决环节”，那这段话就有牙齿了。

二、真实场景：为什么项目背景被写成了官样文章

要解决问题，先要看清楚问题是在什么场景下被制造出来的。我跟踪过几十个立项流程，项目背景变成官样文章，通常不是因为有人偷懒，而是因为流程本身在奖励含糊。

1. 三个我亲历的场景切片

（1）场景一：立项书”抄上一版”

一家 600 人的零售企业，我翻他们的立项文档时发现，2023 年提交的 24 份立项书里，有 17 份的项目背景第一段几乎完全一致，都是”随着公司业务规模持续扩大，数字化建设成为支撑战略落地的关键抓手”。

这不是抄袭，这是模板惯性。因为他们的立项模板里，第一栏叫”项目背景”，下面留了三行空白，没有任何填写指引，也没有人检查。撰写者面对三行空白，最省力的做法就是把上一份复制过来改几个词。制度在这里起的作用是反向的：写得越笼统，越安全，因为笼统的内容不会被人挑出错误。

（2）场景二：背景是写给领导看的，不是给决策看的

另一家做工业设备的公司，他们项目经理私下跟我说过一句话：”背景这段我不写业务问题，我写领导在年度会上讲过什么。”因为在他们那里，立项能不能过，主要看有没有对上年度战略关键词。于是所有背景都在往战略口号上靠，真实的一线痛点反而没人写。

这个场景的后果在半年后集中爆发：三个项目在中期评审时被质疑”做完了也不解决实际问题”，回头看背景文档，里面确实没有一个字提到实际业务场景。当背景的评价标准是”政治正确”而不是”事实准确”，它就会自动退化成表态文本。

（3）场景三：背景写得挺好，但没人用它

最让人惋惜的是第三种情况。有一家企业的立项背景写得相当扎实，有数据、有场景、有损失测算。但项目一旦启动，这份文档就再也没人打开过。范围在扩大、目标在漂移，没有人回头去看当初背景里写的”不做什么”。

这说明背景文档的价值不在于写完那一刻，而在于后续每一次范围讨论、每一轮需求评审、每一次变更申请时能否被调取出来当作判据。写得好但用不上，等于没写。

2. 从需求提出到立项通过，漏斗在哪里漏

我把上面这些场景对应的流程节点做了一次汇总，画成从”业务方提出想法”到”立项通过”的完整漏斗。你会发现，最大的流失并不发生在评审环节。

这张图给我的最大启发是：如果你只在评审环节加严标准，你能守住的只是最后 42% 的关卡，前面 38% 的模糊需求你根本看不见。制度设计必须往前移到”业务方提出想法”这一步，否则再严的评审也只是在筛已经成型的文档。

三、拆解常见误区：项目背景写不好的五种典型模式

我把过去几年看过的立项文档做了一次归类，项目背景的问题高度集中在五种模式上。这五种模式不是并列关系，它们造成的后果严重程度差别很大。

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

这是出现频率最高的一种。”随着数字化转型加速””在 AI 技术快速迭代的背景下””根据某咨询机构报告显示，行业正朝着……”这类句子作为背景开头，看起来很有格局，实际上对决策零贡献。

原因很简单：行业趋势是所有人共享的信息，它不能区分”我们公司该做”和”我们公司不该做”。如果一段背景换成竞争对手的名字依然成立，那它就不是你的项目背景，而是一篇行业综述。

正确的做法是把趋势往下压两层：行业趋势 → 对我们所在细分市场的具体影响 → 对我们某个业务单元的具体压力。压到第三层，才会出现只有你们公司才有的信息。

2. 误区二：把”领导意图”当成项目背景

“根据年度战略规划要求””公司高层在经营分析会上明确指出”，这类表述在立项书里很常见。它的问题不是不真实，而是不可验证、不可追溯、不可复盘。

更重要的是，它剥夺了项目团队理解项目价值的机会。团队只知道”老板要做”，不知道”用户在哪里痛”，执行时遇到取舍就没有判断依据，只能不断向上请示。我在一家企业见过一个项目因为这个问题，在六个月里向上做了 23 次决策请示，平均每 8 天一次。

3. 误区三：只描述问题，不量化损失

这一条我说得直白一点：没有数字的背景，在评审会上没有议价能力。“当前审批流程效率较低，影响业务响应速度”这句话，可以被理解成损失 10 万元，也可以被理解成损失 1000 万元，评审人只能凭感觉投票。

量化损失不一定要求精确到个位数。我通常建议用区间加口径的方式表达，例如”当前每月因审批延迟导致的订单平均滞留 2.3 天，按日均 180 单、单均毛利 420 元估算，每月机会成本约 17 万至 19 万元”。有口径、有算法、有区间，就足够支撑决策了。

4. 误区四：背景与目标、范围、验收标准脱节

这是一种结构性问题。背景里说的是”解决客户投诉率高的问题”，目标写的是”建设统一的客户服务平台”，范围写的是”覆盖售前、售中、售后全流程”，验收标准写的是”系统上线并完成培训”。

这四段话各自都没问题，但连起来看就会发现：背景提出的问题，在验收标准里完全没有对应指标。项目上线了、培训完成了，但投诉率有没有降下来，没人负责。这就是典型的背景与后文脱节。

5. 误区五：一次性写完就归档，不做版本管理

项目背景不是一次性的静态文档。业务环境在变，如果背景里的损失测算、市场假设、约束条件发生了重大变化，项目本身的立项前提就已经动摇了，这时候需要的不是继续执行，而是重新评估立项合理性。

我见过一个做海外市场拓展的项目，背景里写的核心假设是”目标市场年增长率 12%”，项目执行到第八个月时该市场实际增速已经掉到 2%，但没有人触发重估，项目继续按原计划投入。背景文档一旦不更新，它就从一个决策工具变成了一个历史文件。

6. 五种误区造成的后果对比

这五种误区在驳回率和后续返工上表现差异很大，我按影响程度做了排序。

四、专业判断逻辑：项目背景的四层校验框架

前面讲的是问题，现在讲方法。我给企业做立项流程设计时，用的是一套四层校验框架。它不要求背景写得多长，但要求每一层都能被独立验证。

1. 第一层：战略一致性校验，这个项目为什么是现在

这一层要回答的不是”这个项目和战略有没有关系”，而是”为什么是现在”。几乎任何项目都能和战略扯上关系，但只有少数项目能说清楚为什么不能推迟到明年做。

我的判断方法是找”时间窗口”：如果现在不做，半年后做的成本会显著上升，或者机会窗口会关闭，那这个项目就具备紧迫性。如果现在做和三年后做的差别只是早晚，那它应该被排到资源更宽松的时期。

（1）时间窗口的三种典型来源

• 外部合规窗口：监管要求有明确生效日期，逾期会产生罚款或资质风险。
• 业务规模窗口：当前业务量已经逼近现有系统的容量上限，不做会导致明显故障。
• 竞争窗口：关键客户的采购决策周期有限，错过这一轮要等下一个周期。

（2）一个反例

有一家企业的立项背景写”为提升客户满意度，建议建设客户数据分析平台”。这个项目在战略上没问题，但时间窗口不成立，客户满意度已经连续三年在行业中位数以上，没有恶化趋势。这个项目后来被排到了下一个财年，资源让给了另一个客户流失率明显上升的业务线。

2. 第二层：问题真实性校验，损失是谁在承受

这一层是四层里最容易被糊弄过去的。我常用的追问是：这个问题具体发生在哪个岗位、哪个环节、每天发生几次？

如果回答是”全公司都有这个问题”，那基本可以判定没有真问题。真实的业务问题一定是有具体承载者的：某条产线的班组长、某个区域的销售支持、某家门店的店长。

更进一步，我会要求写出”谁在替这个问题买单”。是员工在加班补位，是客户在忍受延迟，还是财务在承担坏账？找到买单的人，损失的计量口径自然就出来了。

3. 第三层：收益可验证性校验，怎么证明做完了有用

很多项目背景只写”问题有多大”，不写”做完怎么验证”。这会导致验收阶段只能验收交付物，无法验收效果。

我的做法是在背景阶段就埋下对照指标：现状值是多少、目标值是多少、在多长时间内达到、由哪个部门负责取数。这四个要素在背景里写一行就够了，但它会让整个项目从”交付导向”转向”结果导向”。

4. 第四层：边界与可逆性校验，什么明确不做

最后一层最容易被忽略，但它对项目成本的保护作用最大。我要求背景里必须有一段”本项目明确不做的事项”，通常三到五条。

与之配套的是可逆性评估：如果这个项目做失败了，我们能退回到什么状态？投入能不能止损？可逆性差的项目，背景里的论证标准必须更高，因为它一旦失败就没有回头路。

5. 四层校验对决策信心的贡献

我把四层校验逐层叠加后的效果做了一次模拟对比，想看清楚哪一层带来的边际价值最大。

这张图给出的建议很反直觉：大多数企业花最多精力打磨的是战略一致性表述，但边际收益最高的是问题真实性校验。因为战略说辞再漂亮，评审人心里的疑问始终是”这事儿到底是不是真的”。

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

讲完方法论，我用一个真实案例把整条链路串起来。这是一家 800 人规模的装备制造企业，年立项数量在 60 到 80 个之间，横跨研发、生产、供应链、营销四条线。

1. 改造前的状态

2023 年初我进场时，他们的情况是：立项申请平均需要 2.8 轮评审才能通过，最长的拖了 47 个工作日。项目背景部分由项目经理自行撰写，公司只有一个 12 页的立项模板，其中”项目背景”占半页，没有任何填写说明。

更麻烦的是，他们同时在用三套工具管理立项：业务部门用邮件提需求、PMO 用 Excel 维护立项台账、研发部门用某项目管理工具管理已立项项目的执行。三套系统之间没有打通，一份背景文档要人工同步三次。

2. 改造的三个动作

（1）动作一：把项目背景拆成结构化字段

我们没有要求项目经理写更长的文字，而是把”项目背景”从一个大文本框拆成了六个必填字段：现状痛点、受影响角色、现状量化损失、不做的影响、时间窗口、明确不做的范围。每个字段有字数下限，但不设上限。

这个改动的关键不在拆分本身，而在于拆完之后系统可以校验完整性。以前”背景写得不好”是一个主观判断，现在”六个字段缺两个”是一个客观事实。

（2）动作二：按投入金额设置分级评审

我们把立项分成三级：50 万元以下为 C 级，只需部门负责人审批，背景字段填满即可；50 万至 200 万元为 B 级，需要 PMO 预审加跨部门评审；200 万元以上为 A 级，必须提交量化损失测算和可逆性评估。

分级制度最大的价值是把评审资源从低价值项目上释放出来。改造前他们所有项目都走同一套评审流程，导致小额项目排队等会，大额项目反而草草通过。

（3）动作三：把立项和执行放进同一个系统

这是整个改造中技术上最关键的一步。他们最终选择了 PingCode 作为承载平台，原因有几个：一是这家企业属于中大型组织，人数超过 100 人，且有多事业部并行，需要能支撑复杂组织结构的项目管理能力；二是他们对数据安全和部署方式有硬性要求，PingCode 支持私有化部署，这一点直接满足了他们的合规底线；三是他们过去有相当一部分研发流程跑在 Jira 上，PingCode 支持从 Jira 平滑迁移，历史数据和自定义工作流不用推倒重来，这对一个正在做国产替代的企业来说省掉了最痛的一段。

我特别想强调第三点。很多企业在做工具替换时，最大的阻力不是新工具好不好用，而是历史数据怎么办、团队习惯怎么办。迁移成本没算清楚就换工具，结果往往是新旧并行，最后变成更大的信息孤岛。

3. 改造后 12 个月的数据变化

我把改造前后各 12 个月的关键指标做了对比。需要说明的是，这些数据来自企业内部台账，样本量有限，不能直接外推到其他行业，但趋势和结构是清晰的。

这里有一个容易被忽略的细节：立项文档返工率从 44% 降到 13%，用了一个季度；但按期交付率从 61% 提升到 79%，用了三个季度。原因不难理解，立项阶段的质量改善要传导到交付结果，中间还要经过需求、开发、测试、上线这一整条链路。

我给很多管理者提醒过这一点：如果你只盯着按期交付率来判断立项流程改得好不好，你会在前六个月就放弃一个本来正确的方案。

4. 一个值得放大的观察：项目规模与文档复杂度并非线性关系

改造过程中我们还发现了一个反常识的现象。立项文档的复杂度并不是随着项目投入金额线性增长的，而是在某个区间之后开始下降，因为超大项目通常会拆分成多个子项目，单个子项目的文档复杂度反而回落。

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

方法论讲完了，但落在具体企业上，做法差别很大。我按组织规模和项目密度分成四种情况，分别给出可执行的建议。这一节你可以直接对照自己公司的状态来读。

1. 情况一：100 人以下、年立项少于 20 个

这个阶段最不应该做的事就是上一套复杂的立项制度。我见过太多 60 人的公司照搬大厂模板，结果项目经理每周花一天填表，业务部门怨声载道。

这个阶段我的建议是只抓一件事：把现状损失量化写出来。不需要六个字段，不需要分级评审，就在现有模板的背景后面加一句”如果这个项目一年不做，公司会损失多少”，并且要求必须有具体测算过程。

这一条能过滤掉大部分”拍脑袋项目”，成本几乎为零。至于工具，这个规模用共享文档加一张台账表就够了，不需要专门的建设投入。

2. 情况二：100 至 500 人、年立项 20 至 100 个

这个区间是大多数中大型企业的状态，也是立项制度收益最明显的区间。项目数量足够多，靠人盯已经盯不住；但组织还没复杂到需要多层审批的地步。

我建议的动作有三条：

1. 结构化背景字段，拆成四到六个必填项，在流程系统里做完整性校验，缺项不允许提交。
2. 按金额做两级评审，把 80% 的小项目从评审会上解放出来，让评审资源集中在 20% 的高风险项目上。
3. 立项与执行放进同一套系统。这个规模下，信息孤岛的代价开始超过工具引入的代价。像 PingCode 这类支持私有化部署、能承接中大型组织复杂权限结构的平台，很适合这一档企业用来打通立项与执行。

3. 情况三：500 人以上、多事业部并行

这个阶段的核心矛盾从”立项质量”变成了”立项标准统一”。各事业部会自发形成自己的立项习惯，最后总部拿不到可比的数据。

我的建议是统一字段定义，不统一字段内容。也就是说，”现状量化损失”这个字段的定义、计量口径、填写格式必须全公司一致，但不同事业部填的具体数值当然不同。这样总部才能做横向对比，才能判断哪个事业部的立项质量在下降。

同时必须建立背景版本管理机制：当项目背景中的核心假设发生重大变化时，触发项目重估。这个机制不需要很复杂，只要在系统里给背景字段加上版本记录和变更原因说明就够了。

4. 情况四：强监管行业

金融、医疗、能源这类强监管行业，立项背景里必须额外包含合规依据。这类项目的背景不是”要不要做”的问题，而是”必须在什么时候之前完成”的问题。

我建议这类企业把背景字段拆成两组：一组是业务价值论证，一组是合规依据引用。后者需要明确引用具体的法规编号和生效日期，这样在后续审计时可以直接作为凭证。

同时，这类企业的工具选型要把数据主权和部署方式放在第一位。像 PingCode 支持私有化部署这一点，在强监管场景下往往不是加分项而是准入门槛。

5. 四种情况的关键参数对照

我把四种情况的关键参数整理成一张表，方便对照。

七、不同情况下的取舍

任何制度设计都是取舍。这一节我把立项背景管理中最容易产生分歧的三组取舍讲清楚，并给出我的判断标准。

1. 取舍一：文档详细度 vs 决策速度

这是最常被拿来对立的一组。业务部门会说”填这么多字段太慢了”，PMO 会说”写不清楚后面更慢”。

我的判断标准是看返工成本占总成本的比例。如果返工成本超过 15%，说明文档详细度不足，应该加字段；如果低于 8%，说明当前详细度已经够了，再加字段只会增加形式主义负担。

这个判断标准的价值在于，它把一个原则之争变成了一个可以测量的运营指标。我参与过的企业里，返工成本占比通常在 10% 到 30% 之间波动，很少有企业真正测过这个数字。

2. 取舍二：集中管控 vs 业务自主

PMO 希望统一标准，业务部门希望灵活处理。这个冲突在 500 人以上的企业尤其明显。

我的建议是管控字段定义，放开字段内容。六个必填字段的名称、定义、格式由总部统一，但每个字段填什么、多长、用什么论据，交给业务部门自己决定。

另外，对年立项超过 30 个的事业部，可以允许他们在统一字段基础上增加 1 到 2 个行业特有字段，但增加的字段必须报 PMO 备案。这样既保住了横向可比性，又给了业务灵活度。

3. 取舍三：自研、采购还是不立项

这个取舍发生在具体项目层面，是背景分析要支撑的核心决策之一。我用四个维度来做对比：总拥有成本、见效周期、风险可控性、可逆性。

我的经验判断是：当自研在”可逆性”和”见效周期”上同时低于 5 分时，立项背景里必须给出非常强的差异化理由，否则大概率会变成沉没成本。这个门槛不高，但能挡掉相当一部分”因为想自己掌控所以自研”的冲动决策。

八、制度设计：把项目背景变成可检查项

前面讲的是判断和取舍，这一节讲制度。制度设计的核心目标只有一个：把”背景写得好不好”这个主观判断，变成”字段齐不齐、数据有没有口径、假设有没有版本”这样的客观检查。

1. 立项分级制度

分级的依据不应该只有金额。我通常建议用三个维度组合：投入金额、影响范围（涉及几个部门或几条业务线）、不可逆程度（失败后能否回退）。三个维度中只要有一个达到高等级，整个项目就升一级。

这样设计的原因是我见过太多”金额不大但影响全公司”的项目被当成小项目处理。比如一个改动客户主数据结构的项目，预算可能只有 30 万元，但一旦出错，影响的是所有业务线。

2. 模板设计的三条原则

• 字段化而非段落化：把背景拆成独立字段，每个字段有明确名称和填写说明，避免一大段文字里混着多个要素。
• 有下限无上限：每个字段设最少字数或最少要素数，但不限制最长篇幅。设上限会导致信息被压缩，设下限能防止敷衍。
• 可校验可追溯：字段是否填写、何时修改、由谁修改，都要在系统里留痕。这既是质量控制手段，也是后续复盘的数据源。

3. 评审规则设计

评审规则里最重要的一条是否决理由必须落到具体字段。不能只说”背景不清楚”，必须说明是”现状量化损失”字段缺少计量口径，还是”明确不做的范围”字段未填写。

这条规则看起来只是流程细节，但它产生的效果很显著：撰写者在提交前会主动对照字段自查，因为被驳回的理由是具体且可预期的。可预期的反馈比严厉的惩罚更能提升文档质量。

4. 制度执行强度与效果的关系

制度不是越严越好。我对比过不同执行强度下的实际效果，发现存在一个明显的拐点。

这张图我希望每个 PMO 负责人都看一遍。它说明一个很现实的问题：当制度严格到某个点之后，撰写者的目标会从”把项目说清楚”切换成”把检查项填满”。后者看起来文档更规范，实际上对决策毫无帮助。

九、操作步骤：项目背景撰写的六步法

制度解决的是”要不要写、写到什么程度”，操作步骤解决的是”具体怎么写”。下面这套六步法我在不同企业用过多次，步骤顺序不能颠倒，因为后一步依赖前一步的产出。

1. 第一步：锁定问题承载者

先不要写任何文字，先在纸上写下一个具体的岗位或部门名称。如果写不出具体角色，说明这个问题还停留在概念阶段，需要回去做访谈。

我的经验是，这个角色通常是”每天都因为这个痛一次”的人。每天痛一次，说明它是高频问题；每周痛一次，说明它值得优化但优先级不高；每月痛一次，除非损失金额极大，否则应该排后。

2. 第二步：还原一个具体的发生场景

用时间线的方式写一遍问题发生的完整过程。例如：客户下单 → 销售在系统里提交 → 审批卡在区域经理处 → 区域经理在出差 → 三天后审批通过 → 客户已转向竞品。

这个过程的详细程度很重要。场景写得越具体，后面的损失测算就越有依据，评审人也越容易代入。一段抽象描述和一段带时间点的过程描述，在评审会上的说服力差距是数量级的。

3. 第三步：做损失量化，写清口径

这一步是六步里最费时间的，也是最容易被跳过的。我通常建议按”发生频率 × 单次损失 × 影响范围”来拆解，三个因子中至少要有两个能拿到实际数据。

写不清楚精确值时，用区间加口径的方式表达，例如”月均影响订单约 180 至 220 单，单均毛利约 420 元，月度机会成本约 7.6 万至 9.2 万元”。不确定不等于可以省略，把不确定性本身写清楚，也是有效信息。

4. 第四步：写明不做会怎样

这一步要回答”为什么是现在”。写三个时间点就够了：三个月后会怎样、一年后会怎样、三年后会怎样。三个时间点的结论如果有明显差异，紧迫性就成立了。

如果三个时间点的结论几乎一样，那说明这个项目没有时间窗口，应该坦诚地把它排到更晚，而不是硬编一个紧迫理由。硬编的理由在评审会上撑不过两个问题。

5. 第五步：画出边界，明确不做什么

这一步需要和业务方一起确认。我常用的问法是：”如果这个项目只能解决一个问题，你希望是哪个？”这个问题能帮业务方自己排除掉大量附加诉求。

把排除掉的内容明确写进背景，通常会写三到五条。这些”不做”的条目在后续需求评审中会被反复引用，它们能挡掉的范围蔓延，价值往往超过项目本身的一部分功能。

6. 第六步：埋下验收对照指标

最后一步是在背景里写好现状值和目标值。格式可以参照下面这个结构，直接把模板填好放进立项系统即可。

【项目背景 – 结构化字段模板】
现状承载角色：区域销售支持岗（覆盖华东 6 个办事处，共 14 人）

发生频率：每周约 23 次审批超时（2024 年 1，6 月系统日志均值）

单次影响：订单平均滞留 2.3 天，其中 11% 转竞品成交

量化损失：月均机会成本 7.6 万，9.2 万元（口径：滞留订单数 × 转竞品率 × 单均毛利）

不做的影响：3 个月后月损失维持 8 万元量级；12 个月后随订单量增长预计升至 13 万元/月

时间窗口：2025 年 3 月前完成，因华东区新签年度框架协议将于该时点生效

明确不做：不改造财务结算链路、不覆盖华南区、不做移动端审批

验收对照指标：审批超时频次从 23 次/周 降至 5 次/周以内，观测周期为上线后连续 8 周

这个模板可以直接用，但我要提醒一点：模板里真正难填的是”量化损失”和”时间窗口”两栏，其他几栏通常十分钟能写完。如果这两栏你也十分钟写完了，大概率说明还没做扎实。

7. 六步法的完成度与立项结果关系

我跟踪过一批项目，看六步法的完成步数和最终立项结果的关系，结论比较直观。

十、总结：项目背景是管理者的判断题，不是项目经理的作文题

写到这里，我把核心观点收一下。项目背景做不好，绝大多数时候不是撰写能力问题，而是制度设计问题。一个企业如果只在模板里留三行空白叫”项目背景”，它就一定会收获三行官样文章。

我最有把握的一个判断是：项目背景的质量上限，由撰写者的能力决定；但项目背景的质量下限，由制度决定。而对企业来说，把下限从 30 分提到 70 分，比把上限从 85 分提到 90 分有价值得多。这就是为什么我始终建议管理者优先做制度设计，而不是优先做写作培训。

另外一点我想强调：项目背景不是立项文档的第一段，它是整个项目生命周期里唯一一份”论证项目为什么该存在”的材料。它的价值会一直延伸到验收阶段，当有人在项目中期提出要加一个需求时，背景里那句”明确不做的范围”就是你最有力的答复。

1. 给你的下一步行动清单

如果你读完之后想做点什么，我建议按下面的顺序推进，不要一次全做。

1. 本周内：随机抽 10 份过去一年的立项文档，用四层校验框架打分，算出你们公司的背景质量分布。这一步不需要任何工具，两个人半天就能完成。
2. 两周内：统计这 10 个项目的评审轮次和返工工时，算出返工成本占比。如果超过 15%，说明制度改进的收益足够大，可以立项推进。
3. 一个月内：把”项目背景”从一段文字改成四到六个结构化字段，先在 1 到 2 个部门试行，观察一个完整季度。
4. 一个季度内：如果试行效果成立，把字段固化到流程系统里，并同步调整评审规则，让否决理由必须落到具体字段。
5. 半年内：评估是否需要专门的平台承载立项与执行的打通。这个规模下，像 PingCode 这类支持私有化部署、能承接中大型组织复杂结构、并且支持从 Jira 平滑迁移的平台，可以纳入评估范围，特别是当你所在企业正在做国产替代规划时。

2. 最后一句提醒

不要指望一次改到位。我参与过的所有成功案例，都是先把一两个字段加上去，跑上两三个月看数据，再决定下一步加什么。立项制度的演进应该是迭代式的，而不是一次性推翻重来。推翻重来最大的风险不是方案不好，而是组织在执行层面对新流程的信任被消耗掉，一旦项目经理觉得”这套东西过几个月又要变”，他们就会选择用最敷衍的方式应付，那时候再好的设计也落不了地。

把项目背景当成一个需要持续迭代的管理产品来做，而不是一个需要一次性填完的表格，这件事就已经成功了一半。