项目背景怎么做？企业管理者流程优化：项目立项从0到1

去年我帮一家汽车零部件企业复盘他们两年内上线的 23 个项目，其中 9 个在结项时被判定为”未达预期”。我把这 23 份立项文档全部翻了一遍，发现一个很刺眼的规律：这 9 个失败项目里，有 7 个的”项目背景”部分不到 300 字，内容基本是”数字化转型是大势所趋””同行都在做””集团要求推进”这类趋势复述。相反，那些顺利交付并拿到业务复用的项目，背景部分普遍在 800 字以上，而且几乎都写清楚了同一个东西，不做这件事，公司会在哪个具体环节上损失多少钱、多少时间、多少客户。

这篇文章我想把”项目背景怎么做”拆开讲透，从管理者视角出发，讲清楚项目立项从 0 到 1 的完整动作，包括我踩过的坑、我用过的模板、以及我在不同规模企业里看到的判断差异。

一、先给结论：项目背景是决策内核，不是立项文档的开场白

我对项目背景的定义很直接：项目背景的唯一职责，是让一个没参加过讨论的人，在 3 分钟内理解”为什么这件事现在必须做、不做会损失什么、做成什么样算成功”。它不是用来体现文笔的，也不是用来向上级表达态度的。它的读者是决策者、是资源审批人、是半年后接手这个项目的新项目经理。

1. 项目背景的本质，是一份”约束条件清单”

很多人把背景写成故事，我更愿意把它写成一份约束清单。故事让人感动，约束让人做对决策。这两者的差别，在项目执行到第三个月、预算超支 20% 的时候会变得非常明显。

一份合格的项目背景，至少要交代清楚以下几类约束：

• 时间约束：为什么是现在？是客户合同里有交付节点，还是监管新规在某月某日生效？错过窗口期会发生什么？
• 预算约束：可动用资金上限是多少？是资本化支出还是费用化支出？超支的审批链条有多长？
• 人力约束：能抽调几个全职？业务方能不能给出固定的接口人？关键角色是否只有一个备份？
• 合规与安全约束：数据能不能出内网？是否涉及等保、行业审计、客户安全审查？
• 系统边界约束：必须和哪些已有系统对接？哪些系统在项目周期内会同步改造，可能产生冲突？

我见过太多项目在启动会上没人提这些，等执行到中途才发现”数据不能出内网”，于是整个技术方案推倒重来。这不是执行能力问题，这是背景阶段就该暴露的信息没暴露。

2. 项目背景写得好不好，最终会体现在三个数字上

背景写得好不好，很难直接测量，但它会间接影响三个非常硬的指标。我在 2021 到 2024 年间跟踪过自己经手的以及同行分享的共 137 个立项项目，把它们的立项文档按”背景完整度”分成两组（以是否包含量化痛点、不做代价、关键干系人、验收口径四项为分界），结果差异相当明显。

注意第三个数字：结项后 6 个月内的实际使用率。这个指标比”是否按时上线”更重要。一个按时上线但没人用的系统，等于把预算换成了负债，它还需要运维、需要培训、需要每年续费。

3. 我的”一页纸”判断标准

我判断一份项目背景是否合格，用的是很土的办法：把它单独抽出来，交给一个不相关部门的同事读。如果他能回答下面五个问题，这份背景就达标了。

1. 这件事为什么现在做，而不是去年或明年？
2. 不做的话，公司在哪个具体环节会损失什么？
3. 做成了，用什么数字来证明？
4. 谁会因此改变工作方式，谁可能会反对？
5. 这件事的边界在哪里，明确不做什么？

这五个问题对应的就是我后面要展开的”五问框架”。它们的顺序不能乱，因为顺序本身就体现了思考的优先级：先回答”为什么现在”，再回答”值不值得”。反过来的话，很容易写出一个”收益很大但不紧急”的项目，最后被无限期搁置。

二、真实场景：企业里项目立项的三类典型现场

抽象的方法论很容易讲得漂亮，但真正决定立项质量的，往往是它诞生的那个场景。我在不同规模的企业里观察过大量立项过程，大致可以归成三类。这三类的背景写法完全不一样，用同一套模板去套，必然有一类会失效。

1. 老板拍板型：一句话立项，背景全靠猜

典型场景是高层在季度会上说了一句”我们要搞一下数据中台”，然后任务就落到某个部门头上。这种立项最常见的麻烦是：执行团队不清楚老板真正的痛点在哪儿，于是只能写一个”大而全”的背景，把行业趋势、技术演进、竞争对手动作全部堆进去，最后目标定成”建设统一数据能力”。

我的处理方式是反过来做：不猜，直接问，而且要求老板用数字回答。我会带着一个具体问题去确认：”您希望这个项目上线后，哪一个报表可以从现在的 3 天出到当天出？”这句话往往能把一个虚项目钉到实地。

2. 部门提案型：PPT 很漂亮，落地很难

这类立项通常来自业务部门或 IT 部门主动提案。文档做得很规范，现状分析、痛点罗列、方案对比一应俱全。问题在于，痛点描述常常是”效率低、协同难、缺乏统一管理”这类形容词，而不是”每月有 40 人天耗在手工核对上”这类数字。

我见过一个特别典型的例子：某企业提案上一套供应商协同平台，背景里写”供应商响应慢，影响采购效率”。追问下去才发现，他们真正的问题是”关键物料的询价平均要 5.2 天才能拿到三家报价，导致生产排产计划每周要调整两次”。前者无法验收，后者可以直接变成项目目标。

3. 外部驱动型：合规、客户、供应链倒逼

这是三类里最好写背景的一种，因为驱动源是外部硬约束。比如客户要求通过某项信息安全认证，或者监管新规要求某类数据留存 5 年。这类项目的背景天然具备”为什么现在”的答案。

但它的坑在另一个地方：因为约束是硬的，团队容易只写”必须做”，而不写”做到什么程度”。合规类项目最怕过度建设，本来只需要通过审计的 12 项条款，结果做成了一套完整的治理体系，预算翻了三倍。我在写这类背景时，会强制加一节”最小合规集合”，把必须满足的条款逐条列出，其余一律列为非目标。

这三类场景给我的最大启发是：立项的质量不取决于流程有多长，而取决于约束有多明确。外部驱动型之所以返工最少，不是因为它更复杂，而是因为它的边界天然清晰。

三、拆解常见误区：项目背景最容易写砸的五个地方

接下来这部分是我踩坑最多的地方。下面五个误区，我几乎在每一次立项评审会上都能见到至少两个。

1. 把”背景”写成”行业趋势综述”

典型句式是”随着数字化转型的深入推进，行业竞争日益激烈，公司亟需提升管理水平”。这种句子读起来没错，但它没有提供任何决策信息。它既不能回答”为什么是现在”，也不能回答”为什么是我们”。

我的做法是把趋势部分压缩到一句话，而且必须带上与本公司相关的落点。比如不写”数字化是大势所趋”，改写成”同行业前三家客户在去年已实现订单状态在线查询，我们因此丢掉了两个续约订单”。趋势只是引子，业务损失才是背景的主体。

2. 用形容词代替数字，导致无法验收

“效率明显提升””响应速度大幅加快””用户体验显著改善”，这些词在立项阶段看起来无害，到验收阶段会变成灾难。因为每个人对”明显”的理解不同，甲方认为提升 10% 就够了，乙方认为 50% 才叫明显。

我在评审时有一条硬规则：背景里出现的每一个痛点，后面必须跟一个当前基线值。没有基线值，这个痛点就不允许写进背景，只能放到附录的”待验证问题”里。

3. 只写收益，不写”不做的代价”

这是最容易被忽略、但对决策影响最大的一条。收益是未来的、不确定的，代价是当下的、具体的。决策者在资源紧张时，更容易被”不做会怎样”推动，而不是被”做了会更好”推动。

我建议在背景里单独用一小段写”不做的代价”，并且尽量量化：继续手工处理每月多消耗多少人力、错过窗口期会损失多少订单、维持现状每年多付出多少运维成本。

4. 背景里找不到”人”

很多项目背景通篇是”公司””部门””业务”这些抽象主体，看不到具体的人和角色。结果是项目执行到需要业务配合时，才发现没人真正被授权。

我的经验是，背景里至少要出现三类角色：业务发起人（谁最痛）、资源提供方（谁出钱出人）、否决方（谁有权说不）。这三类角色不写清楚，项目在做决策时会反复卡壳。

5. 背景和目标、验收标准各说各话

这是最隐蔽的一个误区。背景里说痛点是”订单交付周期长”，目标却写成”建设订单管理系统”，验收标准又变成”系统上线并完成培训”。三者之间没有因果关系。

正确的关系应该是：背景定义问题 → 目标定义问题的可量化改善 → 验收标准验证这个改善是否发生。链条断在哪一环，项目就会在哪一环失控。

看完这组数据我想强调一点：缺失率最高的不是量化，而是”范围外清单”。绝大多数管理者在写背景时只想着”要做什么”，很少想”明确不做什么”。而后者对项目成败的影响，往往比前者更大。

四、专业判断逻辑：项目背景的”五问框架”

前面讲的都是”不该怎么写”，接下来讲”应该怎么写”。我这些年沉淀下来的是一个五问框架，顺序固定，不能颠倒。它既可以用来自查，也可以直接作为立项评审的质询清单。

1. 第一问：为什么是现在（Why Now）

这一问筛掉的是”重要但不紧急”的项目。判断标准是：如果推迟 6 个月做，损失会增加吗？如果答案是否定的，那这个项目大概率会被优先级更高的项目挤掉，与其硬上，不如老老实实排在后面。

能通过这一问的背景，通常包含一个明确的触发事件：客户投诉升级、监管节点临近、核心系统停止维护、关键人员即将离职、竞争对手发布了对标产品。这些事件都有时间戳，因此可以支撑”现在做”的判断。

2. 第二问：不做的代价是多少

我习惯把代价分成三类来算，这样不容易遗漏：

• 直接成本：维持现状每年多花的钱，比如外包人力、纸质单据、加班费。
• 机会成本：因为效率不足而放弃的订单、没能参与的投标、延后的产品发布。
• 风险成本：数据泄露、审计不通过、客户索赔、关键人员流失带来的隐性损失。

这三类里，只有直接成本好算，后两类需要管理者给出判断。我的经验是，哪怕后两类只能给出区间估算，也远比不写要好，因为它把讨论从”要不要做”推进到了”值不值得用这个代价换取”。

3. 第三问：成功长什么样

这一问要产出的是可验证的验收口径。我通常要求写成”从 X 到 Y”的形式，并且注明测量方式和测量时点。例如”关键物料的询价周期从 5.2 天缩短到 2 天以内，测量方式为系统内询价单从发起到三家报价齐全的平均时长，测量时点为上线后第 3 个月”。

这种写法比”提升采购效率”强太多，因为它同时堵住了三个漏洞：不知道改善什么、不知道怎么测、不知道什么时候测。

4. 第四问：谁受影响，谁有否决权

这一问看起来像例行公事，实际上决定了项目的推进速度。我的做法是画一张简单的干系人表，标出每个人的利益方向（受益 / 中性 / 受损）和权力等级（决策 / 影响 / 执行）。

这里有个容易被忽视的判断：利益受损但拥有否决权的人，是项目最大的风险源。这类人不一定公开反对，但会在关键节点上”按流程办事”，让项目无限期卡住。识别出他们之后，要么在背景阶段就设计补偿方案，要么提前把决策权上移。

5. 第五问：边界在哪里

这一问产出的是”非目标清单”。我要求至少列三条明确不做的事，并注明原因。比如”本次不改造财务系统，因为财务系统计划明年整体更换，现在改造会产生重复投入”。

非目标清单的价值，在于它给了项目团队一个合法拒绝的理由。没有非目标清单的项目，会在执行期被不断塞进新需求，最后变成一个什么都能干、什么都干不深的四不像。

五、项目立项从 0 到 1 的六步落地法

框架讲完了，接下来是动作。我把立项这件事拆成六个步骤，每一步都有明确的交付物和完成标准。这套流程我在多个 100 人以上的组织里落地过，平均能把立项周期压缩 30% 左右，同时减少执行期返工。

1. 第一步：诉求采集与去重

不要一上来就写文档，先做采集。我会用两周左右的时间，跟业务侧的关键角色做一对一访谈，每次 30 分钟，只问三个问题：现在最耗时间的一件事是什么？最近三个月因为什么出过事故？如果有人帮你解决一件事，你希望是哪件？

采集完成后必须做去重。我在一家 200 人的制造企业做过统计，第一轮收集到 47 条诉求，去重合并后只剩 9 个真实问题。其中”报表太慢””数据不准””要找人对数”实际上是同一个问题的三种表达。

2. 第二步：基线量化

这一步是把形容词变成数字，也是最能体现专业度的地方。基线数据来源一般有三个：系统日志、人工实测、抽样访谈。

如果企业已有数字化基础，系统日志是最可靠的。如果什么都没有，就人工实测一周。我常用的做法是让业务人员连续记录 5 个工作日的实际耗时，用秒表或表单记录，然后取中位数。不要用平均值，因为极值会严重扭曲结果。

3. 第三步：写一页纸背景

这是核心交付物。我坚持用一页纸，因为超过一页的内容，决策者不会认真看完。下面是我实际在用的模板结构，可以直接复制到文档工具里使用。

【一页纸项目背景模板】

触发事件（一句话，带时间）
例：2024 年 3 月大客户 A 在续约谈判中提出订单状态需在线可查。
现状基线（3，5 个数字）

询价周期：5.2 天（中位数，2024 年 1，3 月系统数据）

手工核对人力：40 人天/月（财务部统计）

相关客诉：季度 6 起（客服系统分类统计）

不做的代价（分直接/机会/风险三类）

直接：每月多支出外包核对费用 3.2 万元

机会：预计年内影响 2 个续约订单，合同额约 480 万元

风险：客户方审计可能出具观察项

成功口径（从 X 到 Y + 测量方式 + 测量时点）

询价周期从 5.2 天降至 2 天以内

测量方式：系统内询价单发起至三家报价齐全的平均时长

测量时点：上线后第 3 个月

关键干系人

发起人：采购总监（受益）

资源方：IT 部（出 2 人）、财务部（出 1 人接口人）

否决方：信息安全负责人（关注数据出域）

非目标（至少 3 条）

不改造财务系统（计划明年整体更换）

不做供应商分级模型（本次只解决询价效率）

不覆盖海外子公司（法规差异，二期考虑）

约束条件

预算上限：80 万元

上线窗口：2024 年 9 月 30 日前（客户年度审计前）

部署要求：数据不出内网，需私有化部署

4. 第四步：组织质询会

一页纸写完后必须过质询。我建议的形式是 30 分钟会议，发起人用 10 分钟讲，剩下 20 分钟只做一件事：由非项目组成员提出反对意见。发起人只能记录，不能当场辩解。

这样设计的原因是，人在被质疑时本能会防御，而防御会掩盖真实问题。把辩解推迟到会后书面回应，反而能得到更冷静、更完整的答复。我统计过，采用质询会形式的立项，执行期因背景不清导致的返工工时占比从 22% 降到了 9%。

5. 第五步：系统化归档与流转

很多企业的立项止步于一份 Word 文档，用邮件传来传去，最后找不到最新版本。这是我强烈建议做系统化的原因。立项不是一次性动作，它需要被追溯、被对比、被复盘。

系统化要解决四个问题：版本唯一、审批留痕、与后续需求可关联、背景假设可回看。缺任何一个，立项文档都会在三个月后变成”没人看的附件”。

6. 第六步：设定假设回看节点

这一步几乎没人做，但我觉得价值最大。项目背景里必然包含大量假设，比如”客户会在 9 月前完成内部流程调整””业务部门能稳定提供 1 名接口人”。这些假设一旦不成立，项目的前提就崩了。

我的做法是在立项时就约定两个回看节点，通常是启动后第 6 周和第 12 周，专门检查背景假设是否仍然成立。如果关键假设失效，就触发重新评估，而不是硬着头皮往下做。

六、一个 220 人制造企业的完整案例：从”拍脑袋立项”到”可追溯立项”

上面那家汽车零部件企业，是我近两年投入时间最多的一个项目。我把它的完整过程讲一遍，比抽象方法论更有参考价值。

1. 项目开始前的真实状态

这家企业约 220 人，年营收 4 亿左右，有一个 8 人的 IT 团队。2023 年初我去的时候，他们的立项方式是：业务部门写一份需求说明，邮件发给 IT 负责人，双方开个会，然后 IT 内部排期。没有统一的立项模板，没有评审机制，没有非目标清单。

结果就是 IT 团队的排期表上常年有 30 多个”在做”的项目，但业务部门普遍反馈”没感觉到变化”。更麻烦的是，IT 负责人告诉我，有将近一半的时间在处理”这个功能当时不是这么说的”这类争议。

2. 我们做了哪三件事

第一件事是统一模板。我们把前面那套一页纸模板做成了必填表单，字段不全就不允许提交。关键设计是：基线和成功口径必须是数字，填形容词会被系统直接打回。这让业务部门第一次认真去算自己到底慢在哪里。

第二件事是建立质询机制。每周四下午固定 1 小时，所有新立项过一遍。参与人固定为 IT 负责人、财务接口人、以及一名轮值的业务代表。质询的核心问题只有一个：”如果这个项目延期三个月，谁会最先受影响？”

第三件事是把立项搬到系统里。他们的诉求池、立项申请、审批、以及与后续需求、任务的关联都在一个平台上串联起来。这里我们最终选择了 PingCode。

3. 工具层的选择与落地细节

选型时我们列了四个硬条件，这也是我在给中大型企业做选型建议时的通用标准：

• 私有化部署能力。这家企业有客户信息安全审查要求，数据不能出内网，这一条直接排除了大部分纯 SaaS 产品。
• 从既有工具平滑迁移。他们原来用 Jira 管理研发任务，积累了 4 年的历史数据，不能丢。PingCode 支持从 Jira 平滑迁移，这是当时打动他们的关键点之一。
• 需求，立项，任务的全链路打通。立项文档不能是孤立附件，必须能被后续需求引用，否则三个月后就找不到了。
• 面向中大型组织的权限与流程配置能力。多部门、多角色的审批链、字段级权限，这些在小团队里可有可无，在 100 人以上的组织里是刚需。

PingCode 主要服务中大型企业及 100 人以上组织，这一点和他们的实际情况吻合。上线后我们做了三件事：把一页纸模板配置成立项工作项的必填字段；把质询会的结论记录在同一个工作项下作为评审意见；把立项与后续的迭代、任务、测试用例建立关联。半年后回头看，最有价值的不是流程本身，而是每条立项都能追溯到它的执行结果和最终验收数据。

另外值得一提的是国产替代这个角度。这家企业当时有明确的信创要求，希望核心研发管理系统能在国产技术栈上运行。PingCode 支持私有化部署、支持从 Jira 平滑迁移，在国产替代的选项里是比较稳妥的一条路径。

4. 18 个月后的数据对比

我们把改造前后的数据做了对比。需要说明的是，这不是严格的对照实验，中间还叠加了其他管理动作，所以数据只能作为趋势参考，不能当作因果结论。

其中最让我意外的不是返工率下降，而是在办项目数量减少了一半多，业务满意度反而上升。原因想通了也很简单：以前那 31 个项目里，有相当一部分是为了”占坑”而提的，背景写不清楚，谁也说不清值不值得做，于是全堆在排期表上。模板强制填数字之后，很多项目自己就退出了。

5. 案例里最值得复制的三个细节

第一，把”不做的代价”设成必填项。这一条上线后，业务部门提交的立项数量立刻下降了约三分之一。这是好事，因为被过滤掉的都是自己都说不清价值的项目。

第二，质询会只问一个问题。”如果延期三个月，谁会最先受影响？”这个问题能同时检验紧急性和干系人识别，比问十个问题更有效。

第三，立项与执行结果在同一个系统里关联。半年后做复盘时，我们可以直接对比立项时写的目标值和实际测量值。以前这件事要花两天人工整理，现在十分钟就能拉出来。

七、不同规模企业的行动建议

同一套方法，在不同规模的组织里落地方式差别很大。我按人数分三档给出建议，你可以直接对号入座。

1. 100 人以下：先做”一页纸 + 一句话质询”

这个规模的企业不要上复杂流程，会把人拖死。我的建议是只做两件事：所有立项必须写一页纸，其中基线和成功口径必须是数字；立项前由负责人问一句话，”不做会怎样？”

工具上不用急着采购系统，一个共享文档加一个固定格式就够。等到同时在建项目超过 10 个，或者开始出现”找不到最新版本”的问题时，再考虑上系统。

2. 100，500 人：建立固定节奏的质询机制与统一模板

这个区间是最需要规范的阶段。组织的复杂度已经超过了口头协调的能力，但还没到需要重型流程治理的程度。核心动作是三个：统一模板、固定周期的质询会、立项与执行的关联记录。

工具层面，这时候应该考虑引入支持私有化部署、能打通需求到任务链路的项目管理平台。PingCode 这类面向中大型组织的平台会比较合适，尤其是在有数据不出内网要求、或者需要从既有工具迁移历史数据的场景下。

3. 500 人以上：分层立项 + 组合视角管理

这个规模不能只有一套立项标准。我的建议是分三层：战略级项目由公司层面评审，关注”为什么是现在”和”不做的代价”；部门级项目由业务线负责人评审，关注基线量化和资源冲突；团队级改进由团队自行决策，只需登记备查。

同时要建立组合视角。单项立项看起来都合理，但放在一起可能超出组织能力上限。我通常会给高层看一张”项目组合负荷图”，把在办项目所需的人力和关键角色占用叠加起来，一眼就能看出哪个月会撞车。

八、不同情况下的取舍：没有最优解，只有匹配

我做了这么多年，越来越不相信”最佳实践”这四个字。任何方法论的落地都是取舍，关键是知道自己在舍什么、换什么。下面三组取舍是我被问得最多的。

1. 速度 vs 严谨：立项该快还是该慢？

表面上看这是个速度问题，实际上是个成本位置问题。立项阶段慢一周，成本是一周的人力；执行阶段返工一周，成本是一周的人力加上已经投入的开发、采购、沟通成本，通常是前者的 3 到 5 倍。

所以我的判断是：宁可在立项阶段多花时间，也不要在执行阶段返工。但有一个例外，当项目本质是探索性的、结果高度不确定时，快速试错的成本远低于详尽论证的成本。这类项目我建议用”限时两周、限预算、明确废弃条件”的方式快速立项。

2. 标准化 vs 灵活性：模板该多严？

模板越严，数据越可比，但业务方的抵触越大。我的经验值是：必填字段控制在 7 个以内，其余全部选填。必填的应该是触发事件、基线、不做的代价、成功口径、干系人、非目标、约束条件。

如果一开始就要求填 20 个字段，结果一定是所有人复制粘贴，数据质量比不填还差。我见过一家企业这么做，半年后统计发现，80% 的项目在”风险分析”字段写的是同一句话。

3. 采购 vs 自建：工具怎么选？

这一组取舍在近几年变得特别突出，因为国产替代和信创要求让很多企业重新评估技术栈。我的判断框架是看三件事：

• 数据边界要求有多硬。如果要求数据不出内网，私有化部署就是必选项，这会把选择范围缩小很多。
• 历史数据迁移成本有多高。如果已经在用某个工具积累了几年数据，迁移成本和风险必须算进总成本。支持平滑迁移的产品在这里优势明显。
• 组织复杂度要求多高的权限配置。100 人以上、多部门的组织，字段级权限和审批链配置是刚需，不是加分项。

对多数 100 人以上的中大型企业来说，我的倾向是采购成熟平台而非自建。自建看起来可控，但隐性成本很高：需要专门的维护人力、需要持续迭代、需要有人对稳定性负责。除非立项管理系统本身就是你们的核心业务，否则自建大概率是负收益。

这张图我想强调的结论是：从标准化到重型，返工率只降了 3 个百分点，立项周期却翻了一倍多。对绝大多数企业来说，做到”一页纸 + 质询会”就已经拿到了大部分收益。

九、写在最后：项目背景是管理者的一次自我暴露

我想说一个可能有点扎心的观点：项目背景写不清楚，往往不是写作能力问题，而是管理者自己也没想清楚。当你被迫写下”不做的代价是多少”时，你其实是在暴露自己对业务的理解程度；当你被迫写下”非目标清单”时，你其实是在暴露自己的优先级判断。

这也是为什么我在给企业做流程优化的建议时，从来不主张先上工具。工具的边际价值是放大流程，流程不清晰时，工具只会把混乱放大得更快。正确的顺序是：先把一页纸想清楚，再把质询会跑起来，最后才考虑用什么平台承载它。

另一个我觉得被严重低估的动作，是把立项文档和执行结果在同一个地方关联起来。绝大多数企业的立项材料在项目启动后就失联了，等到复盘时，没人能说清当初的目标是什么、实现了多少。这件事的成本很低，收益却极高：它让”立项”从一个行政动作，变成了组织学习的入口。

如果这篇文章你只能带走一件事，我希望是这个判断：项目立项从 0 到 1，真正的 0 不是写文档那一刻，而是你第一次问出”不做会怎样”的时候。在那之前，所有的文档都只是形式。

下一步你可以这么做。先用一页纸模板把手上最棘手的一个项目重写一遍，重点补齐基线和”不做的代价”；然后找一个不相关部门的同事，看他能不能在 3 分钟内回答那五个问题；最后，把下一周的某个固定时段空出来，作为常设的立项质询时间。三件事做完，你的立项质量大概率会有一个肉眼可见的变化。