项目立项如何做好项目背景？项目负责人最佳实践与操作步骤

2021 年我参与复盘一个预算 480 万元的数字化项目，翻到立项文档第一页时有点愣住：整份”项目背景”只有 217 个字，其中 140 多个字是从上一年另一份立项书里复制过来的，连”随着业务快速发展”这种句子都没改。那次评审被董事长当场打回，理由不是方案不好，而是”我看完不知道这件事为什么非做不可、为什么是今年做、不做会怎样”。后来我们花了三周重写背景，从 217 字扩到 1600 字，第二次评审以 11:1 通过，反对的那一票来自财务，他后来跟我说：”不是不同意，是你们把代价算清楚了之后，我没法反对。

“

这件事之后，我在 2021 到 2024 年间系统复盘了自己经手和旁听的 47 个立项项目，包括 IT 系统建设、产线改造、组织变革、合规整改四类。我发现一个很稳定的规律：项目背景写得越像”开场白”，项目在立项后三个月内出现范围变更、预算追加、目标漂移的概率就越高。背景不是文档的装饰，它是后面所有目标、范围、预算、里程碑的合法性来源。

这篇文章不讲”背景要写清楚”这种废话。我会把我实际用过的一套判断标准和操作步骤完整拆开，包括六要素模型、三层过滤法、七步写作流程，以及在 100 人以上组织里为什么背景要换一种写法。

一、核心结论：项目背景是立项决策的地基，不是文档的开场白

先给结论，后面再解释为什么。如果你时间有限，把这四条记住就够了。

1. 项目背景真正回答的只有一个问题：为什么是现在

很多人以为背景要回答”我们要做什么”。错了。”做什么”是方案要回答的，”为什么做”是目标要回答的。项目背景唯一不可替代的职责，是回答”为什么这件事必须现在做，而不是去年做、明年做、或者干脆不做”。

这个判断标准非常锋利。你拿它去砍自己写的背景，会发现至少一半的篇幅是无效的，行业趋势、政策背景、集团战略这些内容，如果不能用来说明”所以时间窗口是今天”，那就只是凑字数的。

2. 项目背景的读者不是审批领导，而是三个月后质疑你的人

这是我踩过的最大的一个坑。早期我写背景，脑子里想的是”怎么让老板点头”，于是拼命往上贴战略、贴行业大势。项目做起来之后，业务部门开始问：”当初为什么要做这个？我们现在的痛点和文档里写的不一样啊。”这时候我翻回立项书，发现里面找不到任何能支撑我继续推进的原始事实。

所以写背景时，我的假想读者换成了三类人：三个月后中途接手的人、半年后审计预算的人、一年后复盘项目价值的人。他们不在评审现场，只能靠这几百字理解这件事的来龙去脉。这个视角一换，你会发现需要写进去的东西完全不一样了。

3. 一份合格的背景必须能被反驳

这句话听起来反常识，但极其有用。如果一份项目背景写得任何人都挑不出毛病，那它大概率没有任何信息量。“提升管理效率””支撑业务发展””符合数字化转型趋势”，这些话永远正确，也永远无用。

合格的背景应该长这样：”华东仓日均出库单 3200 单，现有系统峰值处理能力 2800 单，2024 年双十一预售期已经出现连续 3 天积压，最严重一次积压 11 小时，导致 47 个客户投诉。”这段话可以被反驳，数据可能不准，因果可能不成立，方案可能不是唯一解。能被反驳，才有讨论价值。

4. 背景不是信息堆砌，是约束条件的排序

我见过很多写得”很丰富”的背景：市场环境、竞争格局、内部现状、技术趋势，四大段每段三百字。看完之后你依然不知道这个项目的边界在哪。

真正有价值的背景是带优先级的约束条件清单：哪条是硬约束（比如合规红线、截止日期），哪条是软约束（比如预算弹性、人力可协调），哪条是假设（可能变化）。把这三类分层写清楚，后面的范围和方案才有推导依据。下面这张图是我在自己样本里统计的对比结果。

二、真实场景：背景为什么总在同一个地方写砸

要解决问题，先得看清它在什么场景下发生。我把 47 个项目按发起方分成三类，发现背景出问题的位置高度集中。

1. 场景一：IT 部门接业务需求，背景基本靠转述

业务部门口头说”我们系统太慢了，要换一个”，IT 部门记下来，写成”现有系统性能不足，影响业务效率”。这就是典型的转述式背景。

问题在于，转述会丢掉全部量化信息和因果关系。“太慢”是感受，”平均响应 8.4 秒、超时率 17%”才是事实。前者写进背景，评审时无法验证；后者写进去，谁都能判断这件事值不值得投入。

我后来的做法是：只要业务方说”太慢””太乱””太多”，我就追问三个问题，慢到什么程度、发生在什么时间、造成了什么具体损失。这三个问题问完，背景的骨架就有了。

2. 场景二：业务部门自己发起，背景容易变成诉苦信

业务部门写背景有个天然倾向：把平时受的委屈全写进去。我见过一份背景写了 1800 字，其中 1200 字在讲”我们部门如何辛苦、如何不被重视、如何用 Excel 手工处理数据到凌晨”。

这些内容不能说假，但它解决不了立项问题。评审会上的决策者不关心你多辛苦，只关心这件事不做会带来多少可计量的损失。辛苦是情绪，损失是账目，两者在立项桌上的分量完全不同。

3. 场景三：集团下发任务，背景变成政策摘抄

这类项目的背景往往最容易写，也最容易写废。因为”集团要求”本身就是最强的合法性来源，于是大家就把集团文件复制粘贴一段，草草了事。

但这里藏着一个陷阱：集团要求只证明了”必须做”，没有证明”我们这么做”。同一份集团文件下发给十家子公司，每家的落地方式都应该不一样。如果你的背景和隔壁公司的背景长得一模一样，那你的项目就失去了本地化论证。

我处理这类项目的做法是，在政策摘抄之外额外加一段”本地落差分析”：集团要求的指标是什么，我们现在的实际水平是多少，中间的差距由哪几个具体环节造成。这一段往往只有 300 字，但它是整个项目真正的立足点。

4. 一个完整的返工案例

2022 年我参与过一家制造企业的仓储系统升级立项。第一次提交的背景是这样写的：

• 第一段：行业数字化趋势与政策导向，约 400 字
• 第二段：公司业务增长迅速，现有系统已不能满足需求，约 300 字
• 第三段：本次升级将引入先进技术，提升整体运营效率，约 200 字

结果评审会上被问了三组问题，全部答不上来：增长迅速具体是多少单量？现有系统的瓶颈在哪个环节、从什么时候开始出现？如果今年不做，明年会怎样？

我们用了 6 周时间返工，重写的背景只有 950 字，但包含了一张入库单量三年曲线、一份峰值处理能力测试报告、一段”现有系统在 2024 年 3 月已连续 5 天超过处理上限”的事实记录。第二次评审只用了 40 分钟就通过了。

这 6 周里，真正花在”写作”上的时间不到 8 小时。剩下全部花在找数据、跑测试、找一线员工访谈上。项目背景的难点从来不是写作，而是取证。

三、拆解六个高频误区：每一条我都踩过

下面这六条，是我在自己的文档和别人送审的文档里反复看到的。我把它们按危害程度排列，前三条会造成实质性的立项失败。

1. 误区一：把项目背景写成行业趋势报告

“随着云计算、大数据、人工智能技术的快速发展……”这个开头我在 47 份文档里看到了 19 次。

问题不在于这些话错，而在于它们完全不可证伪，因此对决策零贡献。行业趋势属于”通用背景”，它可以放在方案的技术选型章节作为论证前提，但不该占据项目背景的核心位置。项目背景要写的是”我们这里的特殊问题”，不是”大家面对的普遍情况”。

2. 误区二：把痛点写成形容词，而不是数字

“效率低””协同差””响应慢””体验不佳”，这四个词是我统计出的高频形容词，出现频率超过 70%。

形容词的问题是它没有阈值。效率低到什么程度才值得花 480 万？这个问题如果背景里回答不了，评审时必然被追问，而一旦被追问，你就只能当场估算，当场估算意味着可信度崩塌。

我的做法是强制替换：把每一个形容词后面加上”具体表现为”和一组数字。写不出来就说明你还没搞清楚，那就先别写。

3. 误区三：只写问题，不写不做这件事的代价

这是我认为最致命的一条。问题不等于代价。“系统响应慢”是问题，”订单处理超时导致客户流失、2023 年损失约 260 万元营收”才是代价。

评审决策的本质是资源分配，而资源分配的比较基准永远是”如果这笔钱不投在这里，投在别处会怎样”。你不给代价，决策者就无法比较，无法比较的结论就是”再研究研究”。

4. 误区四：缺少时间锚点

为什么是今年而不是明年？这个问题背后往往有硬性时间约束：监管截止日、旺季窗口期、设备保修到期、合同续签节点、人员编制周期。

时间锚点是背景里性价比最高的一句话。它通常只需要 30 到 50 个字，但能把整个项目的紧迫性从”重要不紧急”拉到”必须今年”。

5. 误区五：把解决方案混进背景

“由于现有系统架构老旧，我们需要建设一套微服务架构的新平台。”这句话的前半句是背景，后半句是方案。

混在一起的后果是：一旦方案被质疑，背景的合法性也被一起动摇了。正确的写法是先证明问题，再单独论证方案，中间用目标和范围隔开。背景只负责让问题成立，不负责让方案成立。

6. 误区六：背景、目标、范围三者互不呼应

我在评审时常用一个快速检查法：把背景里的每个痛点圈出来，去目标章节找对应的改善目标，再去范围章节找对应的建设内容。如果存在圈出来但对不上的痛点，说明背景写飘了。

这个检查法只需要十分钟，但能筛掉大部分”看起来很丰满、实际上前后脱节”的立项文档。下面这张雷达图是我在两个版本背景文档上的实际打分。

四、专业判断逻辑：六要素模型与三层过滤法

前面讲了”什么不能写”，这一节讲”应该写什么、按什么顺序判断”。这是我目前最常用的一套方法，已经用了三年，改了四版。

1. 六要素模型：一份完整的项目背景由六个部分构成

我把项目背景拆成六个必填要素，缺任何一个都会在评审时被追问：

这六项不需要平均用力。在我经手的项目里，投入产出比最高的是”代价测算”和”时机论证”这两项，它们通常只占背景总字数的 20%，却能决定 80% 的评审走向。

2. 三层过滤法：每条写进去的内容都要过三道筛子

我会把收集来的所有素材先过三道筛子，过不去的直接删掉，不管它看起来多有分量。

1. 可验证：这条信息能否定位到具体来源和时间？”某系统不太好用”过不去，”2024 年 3 月工单系统记录 217 起超时投诉”能过去。
2. 可量化：这条信息能否换算成数字？”影响客户体验”过不去，”导致 47 个客户投诉、其中 6 个转向竞品”能过去。
3. 可反驳：这条信息是否存在被证伪的可能？”符合数字化趋势”过不去，”按当前增速 2025 年缺口将达 1100 单”能过去，因为别人可以质疑我的增速假设。

三道筛子筛完，素材通常会剩下不到三分之一。这个损耗率是正常的，我第一次用的时候也很心疼，但筛出来的每一条都能在评审桌上站住。

3. 判断优先级：代价 > 时机 > 痛点 > 事实

如果背景篇幅有限，必须砍掉一部分内容，我的删减顺序是倒过来的：先删纯事实性的铺陈，再精简痛点描述，最后保留代价和时机。

原因是这四者在决策链条上的位置不同。事实是原料，痛点是加工，代价是结论，时机是催化剂。决策者真正需要的是结论和催化剂，原料可以放在附录里。

我见过反过来的写法：用了整页讲历史沿革和组织架构，最后两行说”因此有必要建设该系统”。这种背景读起来很完整，但在评审桌上的说服力接近于零。

4. 一句话检验法

写完之后，我会强迫自己用一句话把背景说完，格式是：“因为 [可量化的事实]，导致 [可量化的代价]，且 [时间窗口] 之前必须解决，否则 [可量化的后果]。”

如果这句话说不出来，或者说不顺，说明背景还没写到位。如果这句话只需要 60 个字就能说完，那你要反问自己：剩下的 1400 字是在做补充论证，还是在注水？

5. 不同角色对背景的关注点完全不同

这一点很少有人讲，但实际影响很大。同一份背景，四类决策者读的是四个不同的部分。我在提交前会专门检查这四个部分是否都被覆盖。

五、操作步骤：项目负责人写项目背景的七步法

下面是我现在实际执行的流程。它不是线性写作流程，而是”取证，加工，验证”的循环，最后一步往往会倒回第二步。

1. 第一步：去第一现场，不去会议室

这是整个流程里最重要的一步，也是最容易被跳过的一步。在会议室里听汇报得到的背景，和在现场看到、听到、问到的东西，完全是两种素材。

我做一个仓储项目时，在办公室听到的说法是”系统有点慢”。我到拣货区站了两个小时，看到的是：拣货员每次扫码后要等 3 到 5 秒，一个班次下来扫码约 1800 次，等于每天有 2.5 到 4 个小时纯粹在等系统。这个数字后来直接写进了项目背景，也成为项目最有力的论据。

现场取证有四个固定动作：观察真实操作流程、记录时间点、找一线员工问三个”为什么”、拍照或截屏留证。这四个动作做完，你手里就有了别人复制不了的材料。

2. 第二步：建立事实清单，每条标注来源和时间

我会用一张表管理所有事实性素材，字段包括：事实描述、数据来源、统计口径、时间范围、可信度评级。这一步看起来繁琐，但它是后面所有论证的基础。

标注来源和时间的目的不是严谨，而是防身。立项三个月后有人质疑数据时，你能在 30 秒内翻出原始出处。这一点我在审计场景里深有体会。

3. 第三步：把痛点换算成钱、时间或风险敞口

换算口径我常用三种：

• 人力口径：每天浪费 x 人×小时，按人均成本折算年度金额
• 营收口径：因问题导致的订单流失、客户流失、返工成本
• 风险口径：合规处罚上限、事故概率×损失额、违约赔付金额

三种口径至少要用一种，能叠加更好。我在仓储项目里同时用了前两种，得出的结论是年化损失区间 180 万到 320 万元，而项目预算 480 万元，回本周期不到两年。这个对比一说出来，评审的讨论焦点就从”要不要做”变成了”怎么做得更快”。

4. 第四步：锁定时间锚点

时间锚点通常来自五个地方：监管截止日、业务旺季窗口、设备或合同到期日、关联项目依赖节点、预算年度周期。找到之后，用一句话明确写出来。

需要注意，时间锚点必须是真的，不能编。编造紧迫性在评审现场很容易被拆穿，一旦被拆穿，整份文档的可信度都会受影响。

5. 第五步：写约束条件，分硬约束、软约束、假设三层

这一层是我在 2023 年之后才补上的，补上之后立项后的范围争议明显减少。

• 硬约束：不可协商的边界，如数据不出园区、必须通过等保三级、上线时间不得晚于 X 月
• 软约束：可协商的条件，如预算浮动范围、可借用的人力、可接受的过渡期
• 关键假设：若假设不成立则方案需重做，如”假定新仓在 2025 年 3 月前完成基建”

把假设单独列出来的好处是：一旦假设变化，你可以拿着立项文档说明”这不是范围蔓延，是前提变了”，从而触发正式的变更流程，而不是被动接受追加。

6. 第六步：写”不做的后果”，制造决策张力

这一步经常被忽略，但它往往是决定项目能否排进当年预算的关键。决策者面对的不是”做与不做”，而是”今年做与明年做”。你需要证明拖延本身是有成本的。

写法上要克制，不要威胁式表达。用推算代替断言：”按当前单量增速 12% 推算，2025 年峰值缺口将从 400 单扩大到约 1100 单，现有应急方案（临时增派 15 名临时工）的年度成本将从 62 万元上升至 170 万元以上。”

7. 第七步：反向验证，找三个人挑刺

定稿前，我会找三类人各读一遍：一个不懂业务的同事、一个会挑数字毛病的财务、一个将来要用这套系统的业务骨干。给他们的任务只有一个，找出你最站不住脚的那句话。

这三个人提的意见，通常能解决 80% 的评审提问。与其在评审桌上被当众拆解，不如在提交前被人私下拆解。下面这张图展示了这七步在实际项目里的耗时分布。

8. 项目背景的结构化模板

下面是我目前使用的模板骨架。它不是填空表，而是提醒你每个位置该放什么类型的证据。

【项目背景】
现状事实（3-5 条，每条带数据来源与时间）

事实 A：____（来源：____，统计口径：____，时间范围：____）

事实 B：____

核心痛点（2-3 条，每条带量化幅度）

痛点 1：____，当前水平 ____，合理水平 ____，缺口 ____

代价测算（至少一种口径）

人力口径：____ 人×小时/天，年化折算 ____ 万元

营收口径：年损失约 ____ 万元（计算过程见附录）

风险口径：____ 风险敞口约 ____ 万元

时机论证（为什么是现在）

时间锚点：____（硬性节点）

若延后一年：成本将增加 ____，或错过 ____

约束条件

硬约束：____

软约束：____

关键假设：____（若假设不成立，需重新评估范围）

不做的后果

按当前趋势推算，12 个月后 ____

【一句话概括】

因为 ____，导致 ____，且必须在 ____ 之前解决，否则 ____。

六、案例与数据观察：100 人以上组织的项目背景为什么更难写

前面讲的方法在中小团队基本通用。但当组织规模超过 100 人，特别是涉及多层级审批、合规要求和技术栈治理时，项目背景的写法需要做明显调整。这一节我用实际项目经验来说明差异。

1. 规模带来的三个结构性变化

我对比过自己在 30 人团队和 800 人组织里写背景的经历，差异集中在这三点：

• 证据链要求变长：小团队里”我问过仓库主管”就够了，大组织需要书面记录、数据报表、部门确认三方对齐
• 约束条件变多且互相冲突：合规要求、集团标准、现有技术栈、采购流程会同时施加限制，背景里必须显式列出冲突点
• 决策链条变长：一份背景可能要经过部门、中心、集团三层阅读，每层的关注点不同，需要保证任何一层都能独立读懂

第三点尤其关键。大组织里的项目背景要能被”跳读”。我现在的写法会在每段开头用一句加粗的判断句，让只读每段第一句的人也能完整理解逻辑。

2. 合规与数据主权驱动型项目的背景写法

这类项目有一个特点：痛点不是”效率低”，而是”不合规”或”存在数据主权风险”。我在 2023 年参与的一个制造集团项目中，背景的核心论证就是数据必须留在园区内。

这类背景的写法与效率型项目完全不同：

• 事实基础要引用具体的合规条款或内部审计结论，而不是主观感受
• 代价测算以风险敞口为主，比如”若发生数据外流事件，潜在处罚与商誉损失估计在 X 到 Y 之间”
• 约束条件中”数据不出园区”属于绝对硬约束，必须写在背景里而不是方案里

这也是为什么在 100 人以上、尤其是制造、金融、能源类组织里，支持私有化部署的项目管理平台会成为立项时的默认选项。因为私有化部署能力本身就是背景中”硬约束”的一部分，如果背景里写了数据不出园区，方案里却推荐了一个纯 SaaS 工具，这份立项文档在逻辑上就是自相矛盾的。

在这个场景下，PingCode 是我在实际项目中见过较多被选用的选项之一。它主要服务中大型企业及 100 人以上组织，支持私有化部署，这一点直接对应了背景里的硬约束条款；同时支持从 Jira 平滑迁移，对于历史项目数据沉淀较多的组织，迁移可行性也是背景中必须交代的前提条件。对于有国产替代诉求的组织，迁移路径的成熟度往往比功能清单更能决定立项能否通过。

3. 迁移类项目的背景要额外写清”迁移成本”

如果项目涉及工具替换或系统迁移，背景里必须有一段专门讲迁移成本。这一点我踩过坑：有一次立项时背景只写了”现有工具无法满足协同需求”，没有评估历史数据迁移的工作量，结果实施阶段发现要迁移 6 年的项目数据、约 4.2 万条工作项，额外投入了将近 200 人天。

后来我调整了写法，把迁移成本前置到背景里，用三个指标量化：历史数据量级、迁移停机窗口、迁移后数据完整性要求。这三个指标一写，评审时就不会再有人问”为什么不继续用原来的”。

4. 数据观察：背景完备度与立项后变更率的对应关系

我把 47 个样本按背景完备度分成三档，观察它们在立项后 90 天内的变更率差异。结果比我预想的更陡峭。

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

方法讲完，接下来是决策问题。不同类型项目在背景上的投入应该差异很大，我把常见情况分成四类。

1. 预算 50 万元以下的轻量项目：精简到一页

这个量级的项目不值得投入 40 小时做背景取证。我的建议是一页纸，包含四块内容：现状事实（2-3 条带数字）、核心痛点（1-2 条）、代价测算（一种口径即可）、时间锚点（如果有）。

轻量项目的背景目标不是说服，而是留痕。半年后有人问”当初为什么做这个”，你能翻出一页纸说清楚就够了。把省下来的时间投到方案设计上，收益更高。

2. 跨部门项目：背景要写成”共同事实”，而不是某一方的诉求

跨部门项目最大的风险是背景写成发起部门的单方陈述，其他部门读完之后觉得”这是你们的事”。我处理这类项目时有一个固定动作：把背景草稿发给每个相关部门，请他们确认其中的事实描述是否准确，并把确认意见记录在案。

这一步通常要多花两三天，但效果非常明显。经过各方确认的背景，在评审时几乎不会遭遇”情况不是这样”的当场反驳，因为反驳在会前就已经消化掉了。

3. 合规或政策驱动型项目：把条款和风险敞口写足

这类项目的背景逻辑不是”提升效率”，而是”规避损失”。写法上要把引用做实：引用具体条款编号、审计结论编号、监管要求原文位置。

同时要注意，这类项目最容易犯的错是把背景写成政策摘抄。政策只证明”必须做”，你还需要补充”我们现在的差距有多大”和”如果不做，风险暴露在哪个环节”。这两段才是本地化的核心。

4. 高层直接点名的项目：背景要补上”自上而下”之外的论证

这类项目的背景通常最好写，也最容易写得单薄，因为有最高层背书，写起来没压力。但我见过不止一次这样的项目在中期失去支持：高层换届、战略调整、预算收紧，一旦失去自上而下的推力，项目就悬空了。

我的做法是在背景里额外补一段自下而上的论证：即使没有高层要求，这件事在业务层面也同样成立，依据是一组具体数据。这段论证平时用不上，但在项目遭遇质疑时会成为唯一的支撑。

八、不同情况下的取舍

写项目背景的过程本质上是不断取舍。我把最常遇到的四组冲突列出来，附上我自己的判断。

1. 时间紧 vs 背景完整：优先保”代价”和”时机”

如果只剩两天，我会砍掉事实铺陈和痛点细节，把代价测算和时间锚点做扎实。原因是这两项对决策的边际影响最大。

但有一条底线：代价测算的数据来源必须真实，宁可用粗略区间，也不要编造精确数字。粗略区间被质疑时你说”这是保守估算，后续可细化”，编造数字被质疑时你无话可说。

2. 篇幅长 vs 可读性：用”跳读结构”替代删减

很多人以为可读性靠缩短篇幅，其实靠结构。我的做法是每段第一句写判断，后面写论据，附录放原始数据。这样读得快的人读每段第一句，读得细的人读完整段，各取所需。

一份 1800 字的背景，如果结构清晰，读起来比 800 字的流水账更快。问题从来不是太长，而是没有层次。

3. 事实完整 vs 组织敏感：把敏感内容转成中性表述

有些背景会涉及部门协作不畅、历史决策失误之类的内容。我的处理原则是：保留事实，去掉归因。

“A 部门与 B 部门数据不共享，导致重复录入 3 次”是事实，可以写；”A 部门本位主义严重，不愿配合”是归因，不要写。事实能推动解决，归因只会制造对立，而且归因往往经不起推敲。

4. 一次立项 vs 分期立项：背景决定切分方式

如果项目太大、一次批不下来，分期立项是常见做法。这时候背景的写法要变化：整期背景讲完整问题，分期背景只讲本期要解决的那一段，并且明确说明本期在整体中的位置。

我见过反面案例：分期项目的背景仍然按整体写，结果第一期项目做完，评审发现目标没达成，因为目标本来就是整体的目标。这个坑只要在背景里加一句”本立项为第一期，覆盖范围限于 X，二期覆盖 Y”就能避开。

九、总结与下一步

回过头看，我对项目背景的理解经历了三个阶段。第一阶段把它当格式要求，照着模板填；第二阶段把它当说服工具，琢磨怎么写得打动人；第三阶段才明白，项目背景的本质是一份证据档案，它的价值不在于让项目通过，而在于让项目在通过之后依然站得住。

如果只能记住一件事，我希望是这一条：项目背景里最贵的不是文字，是取证。我在仓储项目上花了 41 小时做现场取证和代价换算，换来的是六周返工的避免和一次 11:1 的评审通过。这笔账在任何规模的组织里都算得过来。

如果你现在手上正好有一个项目要立项，我的建议是今天就做三件事，不用等材料齐了再开始。

1. 去一次现场。找一个真实的操作场景，站两个小时，记录时间点和具体动作，回来你会发现至少有 3 条能写进背景的一手素材。
2. 写一句话概括。按”因为……导致……且必须在……之前解决，否则……”的格式填空。填不出来的部分，就是你还需要去取证的缺口。
3. 找一个人挑刺。把这一句话发给一个会挑毛病的同事，看他第一反应质疑哪个词。那个词就是你的背景下一次要被追问的地方。

做完这三件事，你写出来的背景可能只比原来多了 500 字，但立项会的讨论焦点会从”要不要做”变成”怎么做更快”。这个转变，值得你多花那 41 个小时。