去年秋天的一场立项评审会，我坐在会议室的角落做会议记录。那是当天第7个立项申请，业务负责人上台，背景部分用了三页PPT：行业数字化转型趋势、公司三年战略、竞争对手动态。评审委员听完问了三个问题：不做这个项目会损失什么？这个损失能不能量化？为什么必须这个季度做？台上沉默了将近二十秒，然后说”这个我们后面补充”。会议被迫延长了四十分钟，最后还是给了”暂缓”的结论。三周之后，同一个需求换了个名字、换了个部门，又报上来了。
这件事让我彻底想明白一个问题：绝大多数立项效率低，不是评审委员太挑剔，而是项目背景这一节根本没写明白。PMO 天天被抱怨”流程重、卡点慢”，但真正的卡点往往在材料的第一页，背景没提供决策所需的信息，评审就只能靠追问来补齐，追问就要约下一次会，一次立项被拖成一个月。
过去两年，我参与和旁听了 200 多场立项评审，整理过一批内部样本（下文数据来自我 2023，2024 年经手的样本整理，属于经验观察数据，不是行业统计口径）。我发现一个非常稳定的规律：背景章节写得扎实的项目，平均 22 分钟走完评审；背景写得含糊的项目，平均要 78 分钟，而且 6 个月内发生范围变更的概率高出 2.4 倍。这篇文章就是把这套从 0 到 1 的方法完整讲清楚。
一、先给结论：项目背景是立项的”证据链”，不是”气氛组”
1. 我的核心判断：背景章节决定立项评审 80% 的效率
很多 PMO 把”项目背景”理解成文档里的一个礼貌性开头，用来铺垫后面真正的重头戏，范围、预算、里程碑、资源。我的判断恰好相反：背景是整份立项材料里唯一决定”要不要做”的章节，其余章节决定的只是”怎么做”。
如果”要不要做”没被论证清楚，后面所有的 WBS、甘特图、人力估算都是在给一个错误的前提做精细化包装，越精细越浪费。这也是为什么我见过太多项目，立项材料做得极其漂亮，交付阶段却全面失控，因为它们从一开始就没想清楚为什么做。
PMI 多年的《 Pulse of the Profession 》调研反复指出，需求与目标不清晰是项目失败的首要原因之一。这个结论我从一线看是完全成立的，但我想补一句更具体的话：目标不清晰的根源，往往在立项那一刻就已经埋下了，而它的载体就是项目背景。
2. 一份合格的项目背景，必须回答三个问题
我把这三个问题称为”立项三问”，任何一版项目背景写完后，我都会拿这三问过一遍。
- 为什么是现在？，不是”这件事重要”，而是”为什么不能等到下个季度”。如果答案是”早点做也好，晚点做也行”，那这个项目大概率不该排在当前优先级。
- 不做会怎样？，把不作为的代价说清楚，包括收入损失、合规风险、客户流失、技术债累积、机会窗口关闭。
- 为什么是我们？，为什么由这个团队、用这种方式做，而不是采购、外包、或者干脆用现有系统凑合。
这三问看着简单，但我统计过一个数字：在我整理的样本里，能同时把三个问题用可验证证据回答清楚的立项材料，占比不到三成。剩下七成，不是缺”不做会怎样”，就是缺”为什么是现在”。
3. 一个可以直接套用的最小结构
如果你现在就要动手改模板，我建议把项目背景固定拆成四个小节，顺序不要变：事实（发生了什么）、影响（代价是多少）、时机（为什么此刻）、约束（边界在哪里）。后文第四章会详细展开每一层。
二、真实场景：三个立项现场，三种背景写法
1. 现场一：老板一句话型立项
最常见的场景。某次战略会上，高管提了一句”我们也要把数据中台做起来”，两周后，一个数据中台项目就出现在立项排期里。项目背景写的是”响应公司数字化转型战略，建设统一数据中台”。
这种背景的问题在于：它把”指令”当成了”论据”。战略方向是输入条件，不是理由。评审委员真正想知道的是：现在数据分散造成了哪些具体损失？是报表口径不一致导致每月多花 40 人天对齐？还是因为数据延迟导致促销决策错过窗口？
我的处理方式是回到源头，找 2，3 个业务部门做 30 分钟的访谈，把”一句话指令”翻译成三个可验证的业务事实。这一步通常只需要一天，但能让后续三个月的项目范围讨论少掉一半扯皮。
2. 现场二：客户投诉驱动型立项
这类项目的背景最好写，因为事实天然存在：某大客户连续三个月投诉系统响应慢，或者某次大促期间支付失败率飙升。但恰恰是这类项目，最容易把背景写成”情绪记录”，”客户非常不满，多次投诉，严重影响合作关系”。
我要求团队在这类背景里必须写清四个量：投诉频次、影响客户数、涉及合同金额、以及如果不解决的续约风险。举个例子，我们当时写的版本是：近 90 天内该客户提交 P2 以上工单 11 个，涉及年度合同金额约 480 万元，客户方 IT 负责人在最近一次季度回顾中明确提到”这是续约评估的关键项”。这三句话比任何形容词都有力量。
3. 现场三：合规倒计时型立项
合规类项目的背景写法与上面两类完全不同，它不靠”痛点”，靠”时间轴”。我记得做过一个数据合规整改项目，背景第一句就是：”监管要求在次年 3 月 31 日前完成存量个人信息的分类分级与最小化处理，逾期面临业务暂停风险。”
这类背景的核心是把外部硬约束转成内部排期倒推：从截止日往前推，留出测试、验收、审计的时间，得出最晚必须启动的日期。如果算出来的启动日晚于今天，那这个项目就不需要讨论优先级了，它必须立刻开始。
三、拆解常见误区：我见过的六种”背景写法”
1. 误区一：把公司战略当成项目背景
这是出现频率最高的错误。背景第一段永远是”根据公司三年战略规划，为提升数字化能力……”。问题在于，公司战略是所有项目共享的，它对单个项目的决策没有任何区分度。评审委员看完只会想：既然所有项目都能这么说，那我凭什么批你这个。
战略是”母集”，项目背景必须写出”子集”的独特性。正确的写法是：公司战略要求提升客户响应速度（母集），而当前客服平均首次响应时长 4.2 小时，高于行业基准的 1.5 小时，导致季度内流失 3 家中小客户（子集）。
2. 误区二：只写痛点，不写不做的代价
“现状存在数据孤岛””流程效率低下””用户体验不佳”，这些话都对，但都不可决策。痛点是状态描述，代价是量化后果，两者之间差着一整套证据。
我要求在背景里必须出现至少一个”不作为成本”的数字，形式可以是：每年多支出的人力成本、损失的订单金额、因故障导致的停机时长、因合规问题可能产生的罚款区间。哪怕是个估算区间，也必须给，因为没有代价就没有优先级。
3. 误区三：背景里没有可验证的数字
我做过一次内部抽查，随机抽 30 份立项材料，统计背景章节里可验证的数据点数量。结果是：平均 1.3 个，其中 9 份材料一个都没有。所谓”可验证”，指的是有明确来源、可以被复核的数字，比如来自工单系统的统计、财务系统的成本数据、客服系统的通话记录。
如果背景里全是”大量””严重””迫切””显著”，那这份材料在评审会上的命运基本已经注定。
4. 误区四：背景和范围混着写
我经常看到背景第二段就开始写”本项目将建设 A 模块、B 模块、C 模块”。这等于把结论塞进了前提里，评审委员还没判断该不该做，你就已经在讨论做什么了。
背景只回答”为什么”，范围回答”做什么”，两者必须物理隔离。我自己的习惯是：背景章节里禁止出现任何功能名词和模块名，只能出现业务现象和量化影响。这一条规则执行下来，评审效率提升非常明显。
5. 误区五：背景一次写完就锁死
反过来的错误也有：有些团队把背景当成”立项时的一次性作业”，写完归档，再也没人看。结果项目执行到中期，外部环境已经变了，团队还在按半年前的假设推进。
我的做法是在项目关键里程碑设置”背景复核”动作，只花 15 分钟，确认三个问题：当初的核心假设还成立吗？不作为成本变了吗？优先级是否需要重排？如果答案变了，就更新背景并同步给干系人。背景是活文档，不是历史文件。
6. 误区六：背景只给评审看，不给执行团队看
这是最隐蔽也最致命的。立项通过之后，执行团队拿到的往往是范围清单和排期表，却看不到背景。于是当需求方提出变更时，团队没有判断依据，只能被动接受，项目范围一点点膨胀。
我坚持让执行团队在启动会上重读一遍背景，并且明确告诉他们：任何超出背景所描述问题的需求，都有权要求重新走变更评估。这一句话，能挡掉相当一部分无效需求。
四、专业判断逻辑：项目背景的四层证据结构
1. 第一层：事实层，发生了什么
事实层的写作标准只有一个：换一个人来看，能复现你看到的结论。这要求你把现象写成可核查的陈述，并标注来源。
比如不要写”系统性能问题突出”，而要写”2024 年 3 月至 5 月，生产环境共发生 P1 级故障 7 次，累计不可用时长 11.5 小时，数据来源为运维值班记录与监控平台告警日志”。后者的每一句都可以被审计。
事实层还有一个容易被忽略的要求：只写事实，不写归因。很多人在描述现象时顺手就把原因写死了，”因为架构老旧所以慢”，但架构老旧只是假设之一，可能真实原因是索引缺失或慢查询。把归因留到技术方案章节，背景层负责把现象钉死。
2. 第二层：影响层，代价是多少
影响层是背景章节里最需要”翻译能力”的部分。业务方感受到的是痛，PMO 要把它翻译成组织能比较的单位：钱、人天、时间、风险等级。我一般分四类去写：
- 直接成本：多支出的人力、外包费、运维费、临时补救措施费用
- 收入影响：流失订单、客户流失、续约折扣、交付延期导致的违约
- 效率损失：每月重复人工处理耗时、审批等待时长、跨系统重复录入次数
- 风险敞口：合规处罚区间、数据泄露潜在损失、单点故障的业务中断时长
这四类里，只要有两条能被量化，背景就站得住。我的经验是，效率损失和风险敞口是最容易被忽视、但最容易拿数据的两个维度，因为它们的来源系统通常就在自己手里。
3. 第三层：时机层，为什么是现在
时机层是区分专业 PMO 和普通 PMO 的分水岭。写不出时机，项目就永远排在别人后面。可用的时机论据我归纳为五类：
- 外部截止日：监管要求、合同条款、审计窗口
- 业务节奏：大促、财年结算、开学季、旺季前的准备期
- 依赖窗口：上游系统上线时间、供应商合同到期时间
- 成本窗口：当前改造成本低，拖延后改造成本会指数上升
- 竞争窗口：客户明确表示在评估替代方案
这五类里，外
常见问题解答（FAQ）
1. 项目背景到底要写哪些内容，写多少字才算够？
我第一次写立项材料时，把行业趋势、市场空间、竞品分析全堆进「项目背景」，写了两千多字，结果评审会上老板第一句就问「所以你现在到底为什么要做这件事」。后来做 PMO 看过几十份立项材料，我发现背景写崩的几乎都是同一个原因：把它当成了行业报告摘抄，而不是决策依据。
我的做法是固定一个四问模板：一是触发事件，为什么是现在而不是上季度；二是不做的代价，把损失换算成可核对的口径，比如每月多消耗多少人天、客诉率高出几个百分点；三是受益方与收益口径，明确谁受益、用什么指标在什么时间点验收；四是约束条件，预算上限、合规红线、必须复用的既有系统。
四问各写一段，整页控制在 300-500 字，引用数据不超过三个来源，每个来源标注口径和截止时间。判断够不够的标准很简单：把背景单独发给一个不了解该项目的同事，他读完能说出「为什么做、不做的损失、做成的判定标准」这三件事，就算合格；如果他要反问「所以呢」，就是还没写完。
小项目可以只保留触发事件和不做的代价两句。
2. 项目背景和商业论证、立项报告是不是重复劳动，PMO 怎么避免同一份信息写三遍？
我们团队以前每立一个项目，业务写一遍需求说明、PMO 写一遍立项报告、财务再要一遍投入产出，同一套事实被三个人问三遍、写三遍，业务方怨气很大。我当时就想搞清楚，这几份东西到底各自解决什么问题，而不是简单粗暴地合并成一份文档。
我的划分是：项目背景回答「要不要做」，是事实与触发条件的陈述，讲究可核查；商业论证回答「值不值得做」，是投入产出的测算与假设，讲究口径和敏感度；立项报告回答「怎么做、谁来做、什么时候做完」，是范围、里程碑、资源与风险的承诺。三者层级不同，不能互相替代，但事实层可以只采集一次。
具体做法是让 PMO 维护一张背景信息卡，字段固定为触发事件、影响范围、量化代价、收益指标、约束条件，每项都标注数据来源与截止日期，其他文档只引用卡片编号，不再重述。评审时对背景有异议，就改卡片、不改文档。
这样做的直接效果是信息口径唯一，返工从改三份文档变成改一处，评审记录里也能清楚看到争议发生在事实层还是测算层。
3. PMO 推动项目立项从 0 到 1，最容易卡在哪个环节，怎么提效？
我接手 PMO 的第一年，最大的挫败感不是评审会开得多，而是每个项目都要来回补材料，一个立项平均跑两三轮评审，最长的一个拖了两个月还没批。后来复盘发现，真正花时间的不是决策本身，而是决策前谁都没把信息补齐。
卡点通常在评审会之前的准备阶段，所以我把立项拆成五个关卡：需求受理、背景信息卡填写、PMO 预审、评审会决策、立项决议归档，每关都设准入和准出标准。需求受理阶段就要求提报人填写触发事件和不做的代价，填不出来的直接退回补充，不进预审；
预审阶段 PMO 只检查事实可核查、收益有口径、约束有边界这三项，不合格不进评审会；评审会只做批、缓、否三选一，不再讨论背景事实，事实有异议会前解决。配合某项目管理平台把五关做成状态流转，材料版本和评审意见都留痕，避免线下反复传文件。
我们落地后的口径变化是：单个立项材料准备周期从平均两周压到三到五天，评审轮次从两到三轮压到一轮，退回补充的原因里「背景信息缺失或口径不一致」从占比最高降到个位数。关键不是流程更严，而是把返工挡在评审会之前。
4. 所有项目都要写完整的项目背景吗，小需求能不能简化？
我们内部有个做数据看板的小需求，投入不到十人天，提报人按模板写了满满一页背景，还附了三份行业报告，评审时大家都觉得是形式主义。但反过来，也有团队因为「项目太小不用写背景」，做完才发现和另一个在建项目重复建设。所以我一直在找一个能落地分级判断的口径。
我的判断依据是两条线：投入规模（人天）和影响范围（是否跨部门、是否涉及预算与合规）。低于十人天且不跨部门、不涉及资金与合规的，走简易通道，背景只写三句话，触发事件、不做的代价、验收信号，由 PMO 一次性确认即可，不进评审会。
超过这条线，或者虽然投入小但涉及跨部门协同、外部供应商、数据与合规红线的，必须写完整背景。同时留一个例外机制：任何人在简易通道里发现该项目与在建项目重叠、或者收益口径说不清，都可以直接升级为完整流程，避免用小项目的名义绕过决策。
这套分级落地后，简易通道的项目平均立项时间从五天降到一天以内，漏判导致的重复建设也基本消失。分级不是降低标准，而是把标准用在真正需要决策的地方。
文章包含AI辅助创作：项目背景怎么做？PMO效率提升：项目立项从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/277546
读者评论
分钟和78分钟这组数字我有点保留。我们内部也做过类似统计，发现时长差异很大程度被项目类型带偏了，合规类、客户投诉类背景天然有硬事实，本来就快；真正慢的是内部效率改进和竞品跟随类。建议按触发来源分层再看一次，否则容易把相关性说成因果。
关于背景里禁止出现功能名词这条，我部分认同但不太敢照搬。评审席上常有技术背景的委员，他们会追问大概用什么方式解决，纯业务现象描述到后面反而答不上来，可行性判断没了抓手。我的做法是留一句粗粒度的方向性描述，但不展开到模块。
老板一句话型立项那段写得很准，但落地最难。PMO去约两三个业务部门做三十分钟访谈，在很多组织里根本推不动，尤其那句话出自高管时没人愿意配合。我们后来是把数据要求前置到评审通知里，借评审委员的口去要，比PMO自己去要有效得多。