项目立项前，怎样把“为什么要做”讲清楚

教程定位

这篇教程解决什么问题

很多项目卡在立项前，不是因为方案不够细，而是因为“为什么要做”没有被说清楚。业务方觉得痛点已经很明显，审批人看到的却只有一句“当前流程效率低，需建设系统提升体验”。这句话很难支持立项判断，因为它没有回答四个问题：真实业务问题是什么，现状已经造成什么损失，做成以后能带来什么目标收益，如果暂时不做会发生什么。

这篇文章只解决立项理由这一件事。读完后，你可以把散乱的业务痛点、现状数据、目标要求、会议纪要和审批模板，整理成一页可以给审批人判断的立项理由，同时附上问题证据清单和审批沟通要点。它不帮你写完整项目计划，不展开排期、人力、系统架构、里程碑，也不替审批人做预算和优先级决策。

适合的使用场景是：业务方已经提出项目想法，项目经理需要准备立项材料，但当前材料只有零散背景和几句口头抱怨。你可以让 AI 先帮你搭起论证骨架，再由业务负责人、财务、合规或审批链路中的关键人复核事实和判断。

使用场景

什么情况下最适合用这一套

假设你是一名项目经理，业务发起人找到你说：“这个报价审批太慢了，我们赶紧立个项目，把流程线上化。”你问有没有背景材料，对方发来几条会议纪要和一个审批表模板。审批表里的“项目背景”只有一句话：

这句话对业务方来说可能够了，因为他们每天都被催单、补材料、找审批人。但是对审批人来说，它几乎没有信息量。审批人不知道低效低到什么程度，影响了哪些客户，损失是偶发还是持续，做这个项目是不是比其他项目更急，目标收益是不是能验证，不做是不是也能靠管理动作解决。

这时不要急着让 AI 写“项目计划”。立项前最需要的是把“必要性”写清楚。一个合格的立项理由，应该让审批人即使不了解日常细节，也能判断：

AI 在这里的价值，不是替你拍板“项目值得做”，而是帮你把散落材料变成审批人能看懂的论证文本。你仍然要负责数据来源、损失口径、收益假设和风险边界。

1. 这个问题是不是客观存在，而不是个别人觉得不方便。
2. 问题带来的损失是不是已经影响业务结果，而不只是流程看起来不优雅。
3. 现在立项是不是有时间窗口，而不是随时做都一样。
4. 项目目标是不是和业务收益相关，而不只是“上线一个系统”。
5. 不做的后果是不是可描述、可验证，而不是吓人的口号。

当前渠道报价审批流程较为低效，影响销售推进，拟建设统一报价审批能力，提升审批效率和客户体验。

材料准备

开始前先把材料和边界备齐

在打开 AI 前，先把材料分成五类。材料不一定齐全，但分类能帮你看见缺口。

第一类是业务痛点记录。它可以来自业务方访谈、群聊记录、客服反馈、销售复盘、运营日报，也可以是会议纪要里的问题描述。不要只保留情绪词，例如“很慢”“很乱”“体验差”，要尽量保留具体事件，例如“华东区 6 月有 12 个报价审批超过 3 天，其中 4 个客户要求重新报价”。

第二类是现状数据。常见数据包括处理时长、退回次数、人工补录次数、丢单数量、客诉数量、重复沟通次数、差错率、超时率、影响金额。没有完整系统数据时，可以先用抽样记录或人工台账，但必须写清楚统计口径。

第三类是目标要求。目标不是“建设某系统”，而是项目完成后希望业务状态发生什么变化。例如“报价审批平均时长从 2.8 天降到 1 天内”“提交材料一次通过率提升到 90% 以上”“毛利低于阈值的报价必须被自动标记并进入复核”。

第四类是相关会议纪要。会议纪要的价值不只是证明大家讨论过，更重要的是提取不同角色的关注点。销售关心商机速度，财务关心毛利口径，法务关心条款风险，管理层关心投入产出。立项理由要把这些关注点放在同一个逻辑里。

第五类是审批模板。不同公司审批模板的栏目不一样，有的叫项目背景，有的叫立项必要性，有的叫业务价值，有的叫不立项影响。让 AI 输出前，先把模板栏目提供给它，避免生成一篇看起来完整但无法粘进审批系统的文章。

准备材料时要设定边界。AI 可以帮你压缩、归纳、改写和发现缺口，但不能替你编造数据，不能替你承诺收益，不能替你判断预算是否应该批准。如果涉及财务合规、客户合同、劳动用工、数据安全等高风险内容，AI 只能做表达辅助，最终口径必须由对应负责人确认。

实操流程

按这套步骤把工作跑起来

第一步，先写清审批人要做什么判断。

很多立项理由写不好，是因为作者默认审批人已经认同项目，只需要了解背景。实际上，审批人要判断的是“现在是否值得投入组织资源做这件事”。所以开头不要写宏大背景，也不要从技术方案开始，而是先写一句可判断的结论：

这句话里有三个要点：不是为了做系统，问题有具体对象，影响到了业务结果。它不需要一开始就写方案，也不需要承诺“彻底解决所有问题”。

第二步，把业务痛点改成可核查的问题陈述。

业务方常说“流程太慢”“大家都很痛苦”。这类表达可以作为线索，但不能直接放进立项理由。你要让 AI 帮你把痛点改成四段式问题陈述：谁受影响，在哪个环节发生，频率或规模是多少，造成什么后果。

例如，把“报价审批太慢，销售天天催”改成：

第三步，把现状损失写成证据，而不是抱怨。

审批人最怕看到没有证据的“影响很大”。你可以把损失拆成三层：时间损失、业务损失、管理风险。

时间损失说明组织在这个问题上消耗了多少重复劳动，例如“销售每单平均补充材料 1.7 次”“财务每周花 4 小时核对报价版本”。业务损失说明它影响了什么结果，例如“部分客户因报价响应慢转向竞品”“大促窗口内无法及时确认价格”。管理风险说明如果问题继续存在，组织会承担什么控制风险，例如“低于毛利红线的报价无法在提交时被识别，依赖审批人事后人工发现”。

证据不必都完美，但必须标来源。可以写“来自 6 月销售运营台账”“来自 6 月 18 日销售财务例会纪要”“来自 20 单抽样复核”。如果只是业务方估算，要明确写“业务估算，待财务复核”。这比把估算包装成确定事实更可信。

第四步，把目标收益写成业务状态变化。

很多立项理由会写“提升效率、优化体验、加强管理”。这些词可以出现，但不能停在这里。你需要让 AI 帮你把目标收益翻译成审批人能追踪的状态变化。

更好的写法是：

注意，这里仍然不是完整项目 KPI 方案。你只是把收益方向说清楚，让审批人判断它是否值得进一步投入。指标值必须来自业务共识或历史数据推算，不能由 AI 自行生成。

第五步，写“不做的后果”，但不要写成恐吓。

不做后果不是“如果不做，公司将失去竞争力”这种空话。它应该说明维持现状会继续带来哪些可预见成本，以及为什么靠临时管理动作很难稳定解决。

例如：

这段话克制但有力量。它没有吓人，也没有把项目写成唯一救命方案，而是说明“不做”意味着哪些问题会持续存在。

第六步，形成三件交付物。

第一件是项目立项理由页。它适合放进审批表或立项材料首页，通常包括一句话结论、业务问题、现状损失、目标收益、不做后果和需要审批人关注的判断点。

第二件是问题证据清单。它不一定放在正文里，但要在内部材料中保留，方便审批人追问时能回到数据来源。证据清单可以按“证据项、来源、时间范围、可靠性、待补充事项”整理。

第三件是审批沟通要点。它不是演讲稿，而是帮业务发起人和项目经理提前想清楚审批会上会被问到什么。例如“为什么不是先做管理规范”“为什么现在做”“收益如何验证”“哪些数据还需要补齐”。

建议立项，不是为了单纯把报价审批搬到线上，而是为了解决当前渠道报价审批时长过长、材料反复退回和低毛利报价识别滞后的问题。该问题已经影响重点商机推进，并带来毛利管控风险。

目前渠道客户的特殊折扣报价主要通过群消息和表格附件流转。2026 年 5 月至 6 月抽样的 86 单报价中，平均审批完成时间为 2.8 天，超过公司销售承诺时限的订单占 34%。销售在等待审批期间需要反复补充客户背景、历史价格和毛利测算，导致重点客户报价响应不稳定。

项目目标不是增加一个审批入口，而是形成统一的报价材料提交、毛利校验和审批记录留痕机制。立项后希望实现三类业务变化：报价审批平均完成时间降至 1 个工作日内，销售提交材料一次通过率提升至 90% 以上，低于毛利阈值的报价在提交时自动提示并进入复核。

如果本季度不立项，报价审批仍将依赖群消息、表格附件和人工提醒。短期可以通过要求销售补齐材料来缓解退回问题，但无法解决版本不统一、毛利校验滞后和审批记录分散的问题。进入三季度渠道促销期后，报价量预计增加，现有方式会继续放大审批等待和低毛利报价漏检风险。

输入示例

可以直接参考的输入材料

下面是一段可以直接粘给 AI 的输入材料。真实使用时，把公司名、客户名、金额等敏感信息做脱敏处理。

我要写一个项目立项理由页，只写为什么要做，不写完整项目计划。

项目暂定名：渠道报价审批改造
读者：销售运营负责人、财务负责人、项目审批委员会
当前审批模板栏目：项目背景、立项必要性、预期收益、不立项影响、补充说明

业务痛点记录：
1. 销售反馈特殊折扣报价审批太慢，客户经常催报价。华东和华南两个区域反馈最集中。
2. 当前报价材料通过企业微信群、Excel 附件和邮件流转，销售提交时经常缺少客户历史采购额、竞品报价、目标毛利测算。
3. 财务审批人说每周都要重复追问报价版本和毛利测算口径，同一客户有时出现两个报价版本。
4. 销售负责人在 6 月 18 日会议上提到，三季度渠道促销前如果不解决报价审批，重点客户报价响应会继续拖慢。

现状数据：
1. 2026 年 5 月至 6 月销售运营抽样 86 单特殊折扣报价，平均审批完成时间 2.8 天。
2. 其中 29 单超过公司对客户承诺的 2 个工作日响应时限，占 34%。
3. 86 单里有 31 单被退回补材料，占 36%。主要缺失项是历史采购额、目标毛利、竞品报价依据。
4. 财务抽查 20 单，发现 5 单存在报价版本不一致，需要重新确认。
5. 销售运营估算，5 月至 6 月因报价等待导致客户推迟下单 11 单，其中 3 单客户转向竞品。该数据是业务估算，尚未经过财务确认。

目标要求：
1. 报价审批平均完成时间希望降到 1 个工作日内。
2. 销售提交材料一次通过率希望提升到 90% 以上。
3. 低于毛利阈值的报价在提交时必须被提示，并进入财务复核。
4. 审批过程要有统一记录，后续可追溯客户、报价版本、毛利口径和审批意见。

会议纪要要点：
1. 销售希望先解决重点客户报价响应慢的问题。
2. 财务希望先统一材料和毛利测算口径，不希望只是增加一个线上审批入口。
3. 运营认为三季度促销期报价量会增加，如果继续靠群消息提醒，销售运营会继续被动催办。

请输出：
1. 一页项目立项理由，适合放进审批表。
2. 问题证据清单。
3. 审批沟通要点。

要求：
1. 不要编造输入材料里没有的数据。
2. 如果数据是估算，请明确标注。
3. 不要写项目排期、人力安排、系统架构和详细实施计划。
4. 语言要给审批人看，少用口号，多写事实、损失、收益和不做后果。

提示词

可复制使用的提示词

你可以把下面这段作为通用提示词，每次替换方括号里的内容。

如果你的审批模板很短，也可以加一句：

如果材料很乱，可以先让 AI 做一次整理，不直接写正文：

这个预处理提示词很有用。它能防止 AI 在材料不足时写出一篇看似顺滑、实际没有事实支撑的立项理由。

你是项目立项材料写作助手。请根据我提供的材料，帮我写“立项理由”，只论证为什么现在值得立项，不写完整项目计划。

项目主题：[写项目暂定名]
读者：[写审批人或审批委员会角色]
审批模板栏目：[粘贴模板栏目]

输入材料：
[粘贴业务痛点记录]
[粘贴现状数据]
[粘贴目标要求]
[粘贴会议纪要]
[粘贴其他限制条件]

请输出三部分：

第一部分：项目立项理由页
请包含：
1. 一句话结论，说明建议立项的核心原因。
2. 业务问题，说明谁受影响、哪个环节出问题、频率或范围是什么。
3. 现状损失，按时间损失、业务损失、管理风险归纳。
4. 目标收益，写成业务状态变化，不写空泛口号。
5. 不立项影响，说明维持现状会继续带来的后果，并区分确定事实和合理推断。
6. 审批人需要判断的问题，最多 3 条。

第二部分：问题证据清单
用表格列出证据项、来源、时间范围、能证明什么、可靠性、待补充事项。

第三部分：审批沟通要点
列出审批会上可能被问到的 5 个问题，并给出建议回应方向。

写作约束：
1. 不要编造数据、金额、比例、客户案例或领导表态。
2. 输入材料没有的数据，写成“待补充”，不要自行补齐。
3. 不要写项目计划、排期、资源分工、系统架构、功能清单和预算测算。
4. 不要把“建设系统”写成目标本身，要写业务问题和业务状态变化。
5. 如果存在业务估算、抽样数据或未经确认的判断，请在文中标注。
6. 语气要克制、可审阅、能进入审批材料。

请把最终立项理由压缩到 800 至 1200 字，适合直接粘贴进审批系统；证据清单和沟通要点可以另列。

先不要写立项理由。请只帮我检查材料是否足以支撑立项必要性，按“已具备证据、只有主观判断、缺失关键信息、需要人工确认”四类列出。

输出样例

AI 应该输出到什么程度

下面是基于上面输入材料，AI 可能输出的初稿。它可以作为第一版，但不能直接提交，后面仍要人工复核数据和口径。

这个输出样例已经有比较完整的论证骨架，但人工修改时仍要注意三件事。第一，所有百分比和单量必须能追溯到真实台账。第二，“三季度促销期报价量增加”还只是会议判断，需要补历史数据或改成更谨慎的表达。第三，输出里出现的“项目化解决”“统一机制”等词，最好再结合公司审批语言改得更具体。

渠道报价审批改造项目立项理由页

一、 一句话结论

建议启动渠道报价审批改造。当前问题不是单纯审批入口不统一，而是特殊折扣报价在材料提交、毛利校验、版本确认和审批留痕上缺少统一机制，已经造成报价响应延迟、重复补材料和低毛利报价识别滞后的管理风险。三季度渠道促销期报价量预计增加，如继续沿用现有方式，问题将进一步放大。

二、 业务问题

目前渠道客户特殊折扣报价主要依赖企业微信群、Excel 附件和邮件流转。销售提交报价时，客户历史采购额、竞品报价依据、目标毛利测算等关键信息经常不完整，财务审批人需要反复追问材料和确认报价版本。

根据销售运营对 2026 年 5 月至 6 月 86 单特殊折扣报价的抽样记录，平均审批完成时间为 2.8 天，其中 29 单超过公司对客户承诺的 2 个工作日响应时限，占 34%。同一批样本中，31 单因材料缺失被退回补充，占 36%。财务抽查 20 单后发现 5 单存在报价版本不一致，需要重新确认。

该问题主要影响华东、华南等报价需求集中的区域，也影响财务对毛利口径和报价版本的过程管控。

三、 现状损失

1. 时间损失：销售和财务在报价审批过程中反复补充材料、确认版本和催办审批，审批平均完成时间已达到 2.8 天，超过客户响应承诺的订单占 34%。
2. 业务损失：销售运营估算，2026 年 5 月至 6 月因报价等待导致客户推迟下单 11 单，其中 3 单客户转向竞品。该数据为业务估算，尚需财务或销售管理层复核。
3. 管理风险：当前方式缺少统一材料校验和毛利提示。低于毛利阈值的报价需要依赖审批人事后人工发现，且审批记录分散在群消息、附件和邮件中，后续追溯成本高。

四、 目标收益

本项目目标不是简单新增一个线上审批入口，而是形成统一的报价材料提交、毛利校验、版本记录和审批留痕机制。预期业务状态变化包括：

1. 报价审批平均完成时间由当前 2.8 天下降到 1 个工作日内。
2. 销售提交材料一次通过率提升至 90% 以上，减少退回补充和重复沟通。
3. 低于毛利阈值的报价在提交时被自动提示，并进入财务复核。
4. 审批过程形成统一记录，可追溯客户、报价版本、毛利口径和审批意见。

五、 不立项影响

如果本季度不立项，渠道报价审批仍将依赖群消息、Excel 附件和邮件流转。短期可以通过要求销售补齐材料、加强人工提醒来缓解部分退回问题，但无法稳定解决报价版本不统一、毛利校验滞后和审批记录分散的问题。

进入三季度渠道促销期后，报价量预计增加。现有方式可能继续导致审批等待时间拉长、重点客户响应不稳定、低毛利报价漏检风险上升。上述判断中，报价量增加来自 6 月 18 日会议判断，具体增长幅度需销售运营进一步补充。

六、 审批人需要判断的问题

1. 当前报价审批问题是否已经达到需要项目化解决的程度，而不仅是部门管理动作可以解决。
2. 是否认可先围绕材料完整性、毛利校验和审批留痕解决核心问题，而不是一次性扩大到全部报价管理场景。
3. 是否同意在三季度促销前启动立项准备，避免报价量上升后继续放大现有问题。

问题证据清单

| 证据项 | 来源 | 时间范围 | 能证明什么 | 可靠性 | 待补充事项 |
|---|---|---|---|---|---|
| 86 单特殊折扣报价抽样 | 销售运营抽样台账 | 2026 年 5 月至 6 月 | 平均审批时长、超时占比、退回补材料占比 | 中等，抽样数据 | 补充抽样口径和区域覆盖 |
| 平均审批完成时间 2.8 天 | 销售运营抽样台账 | 2026 年 5 月至 6 月 | 审批等待已超过业务预期 | 中等 | 确认开始和结束时间定义 |
| 29 单超过 2 个工作日 | 销售运营抽样台账 | 2026 年 5 月至 6 月 | 响应承诺存在违约风险 | 中等 | 核对客户承诺口径 |
| 31 单退回补材料 | 销售运营抽样台账 | 2026 年 5 月至 6 月 | 材料完整性问题较突出 | 中等 | 归类具体缺失字段 |
| 20 单财务抽查中 5 单版本不一致 | 财务抽查记录 | 未注明具体日期 | 存在报价版本管控问题 | 中等偏高 | 补充抽查样本选择规则 |
| 11 单推迟下单、3 单转向竞品 | 销售运营估算 | 2026 年 5 月至 6 月 | 可能存在业务损失 | 偏低，需复核 | 财务和销售负责人确认 |
| 三季度促销期报价量预计增加 | 6 月 18 日会议纪要 | 2026 年 6 月 18 日 | 说明问题有时间窗口 | 中等 | 补充历史促销期报价量 |

审批沟通要点

1. 如果被问“为什么不是加强管理就行”，建议回应：加强销售提交规范可以缓解材料缺失，但无法稳定解决版本记录分散、毛利阈值提示和审批留痕问题。立项理由不是替代管理要求，而是为关键控制点建立统一机制。
2. 如果被问“为什么现在做”，建议回应：当前 5 月至 6 月抽样已经显示审批时长和材料退回问题，三季度促销期报价量预计增加，如果继续沿用现有方式，等待和返工会进一步放大。
3. 如果被问“收益怎么验证”，建议回应：可以用审批平均完成时间、材料一次通过率、低毛利报价提示覆盖率和审批记录完整率作为后续验证指标。
4. 如果被问“是不是要覆盖所有报价场景”，建议回应：本次立项理由聚焦特殊折扣报价，不建议一开始扩大到全部报价管理场景，避免范围失控。
5. 如果被问“哪些数据还不够”，建议回应：客户推迟下单和转向竞品数据目前是业务估算，需财务和销售负责人进一步确认；三季度报价量增长幅度也需要补充历史数据。

人工验收

人要怎么检查和改到可用

立项理由是给人判断的，不是给 AI 展示文笔的。拿到 AI 初稿后，至少做下面这些检查。

一个简单的人工复核方法是，在每段旁边标注它回答的问题：这段回答“问题是什么”，这段回答“损失是什么”，这段回答“收益是什么”，这段回答“不做会怎样”。如果某段看不出回答哪个问题，通常就该删掉或改写。

1. 检查问题是否具体到业务对象和环节。不要只写“流程低效”，要看是否写清楚哪个流程、谁受影响、哪类订单或客户受影响、问题发生在哪个环节。
2. 检查数据是否有来源。每个单量、比例、金额、天数，都要能回到台账、系统报表、会议纪要或负责人确认。如果来源不清，就改成“待确认”，不要让它留在正文里装成事实。
3. 检查估算是否被标注。业务估算可以用，但必须明示。例如“销售运营估算，待财务复核”。没有这句话，审批人会以为这是已确认数据。
4. 检查目标收益是不是业务结果。把“建设线上化审批系统”改成“审批时长下降、材料一次通过率提升、毛利异常可识别、记录可追溯”。系统只是手段，不是立项必要性的核心。
5. 检查有没有偷偷写成完整项目计划。如果 AI 开始列功能模块、排期、人力、技术方案、预算拆分，就删掉。立项理由页只回答为什么值得立项，最多写清本次聚焦的业务范围，不展开执行方案。
6. 检查不做后果是否克制。不要写“如果不做将严重影响公司战略”这种大话。改成可预见后果，例如“报价量增加后，现有人工提醒方式会继续放大等待和返工”。
7. 检查是否平衡了不同审批人的关注。业务发起人常会强调增长和效率，财务可能更关心毛利口径，合规可能关心留痕，管理层关心投入产出。立项理由要让不同角色都能看到自己的判断点。
8. 检查是否暴露了材料缺口。一篇可信的立项理由不怕写“待补充”。如果客户流失金额没有确认，就把它放进证据清单的待补充项，而不是硬写进现状损失。
9. 检查语言是否适合审批系统。审批材料不需要文学化，也不需要咨询报告腔。最好是事实在前、判断在后、边界清楚。能用一句话说清楚的地方，不要写三句。
10. 检查高风险判断是否已交给人确认。涉及财务损失、合同违约、客户流失、合规风险、数据安全风险时，AI 只能协助整理表达。最终口径要由对应负责人确认。

失败反例

这些失败反例要提前避开

反例一：只写领导要求，没有业务问题。

问题在于，这句话只能说明有方向，不能说明为什么这个项目现在值得立项。审批人仍然不知道当前问题是什么、影响多大、为什么不是别的项目优先。

反例二：把口号当收益。

这类表达太泛，几乎适用于任何项目。应该改成可追踪的业务状态，例如审批时长、材料一次通过率、异常报价提示覆盖率、记录完整率。

反例三：让 AI 编造数据补足论证。

如果输入材料里没有损失测算和满意度调查，这就是危险内容。立项材料里的数字会影响资源决策，不能为了好看而生成。

反例四：把立项理由写成项目计划。

这些内容可能在后续计划里有用，但不能替代立项理由。审批人还没有判断为什么要做，就被带到了怎么做。

反例五：只写业务方痛苦，不写审批人关心的证据。

痛苦是真实线索，但审批人需要看到它是否具有规模和业务影响。应补充样本量、发生频率、超时比例、退回原因和影响结果。

反例六：不做后果写成恐吓。

这种写法容易引起反感，也经不起追问。更好的写法是说明维持现状会继续导致哪些已出现的问题，例如报价等待、材料返工、低毛利报价识别滞后。

反例七：把解决方案当成必要性。

审批人会继续问：为什么需要统一平台，当前分散方式造成了什么损失，是否有更轻量的替代动作。必要性要从业务问题出发，而不是从方案名称出发。

反例八：证据清单只放结论，不放来源。

这不是证据，只是判断。证据清单至少要写来源、时间范围和能证明什么。没有来源的内容，只能作为待核实线索。

反例九：把所有相邻问题都塞进来。

这样会让立项理由失焦，也会把审批人带向范围失控的担忧。立项前要先说清当前项目最该解决的核心问题，其他相关问题可以放入边界说明或后续议题。

根据公司数字化转型要求，为提升管理效率，拟建设报价审批系统。

项目完成后将全面提升业务效率，优化客户体验，增强企业竞争力。

预计每年可减少 500 万元损失，并提升客户满意度 30%。

第一阶段完成需求调研，第二阶段完成系统开发，第三阶段完成上线推广。项目组包括产品、研发、测试、运营。

销售每天都被客户催，大家对现状意见很大，希望尽快上线系统。

如果不做该项目，公司将失去市场竞争力，客户会大量流失。

我们需要建设统一审批平台，因此申请立项。

证据：审批慢、客户不满意、财务风险高。

本项目将同时解决报价审批、客户分层、销售预测、合同归档、回款跟踪和渠道政策管理问题。

主题边界

它和相邻主题的区别

这篇文章只讲“立项前怎样写清为什么要做”。它和几个相邻主题要区分开。

它不是项目计划写作。项目计划会讨论目标拆解、里程碑、资源分工、风险预案和交付节奏；本文只帮助你在计划之前说明项目必要性。审批人先判断要不要立项，之后才需要完整计划。

它不是需求范围说明。需求范围会定义哪些业务场景纳入、哪些功能要做、哪些边界不做；本文只在必要时点到“本次聚焦什么问题”，不展开功能清单和范围拆解。

它不是 ROI 测算。ROI 测算需要投入成本、收益金额、回收周期和财务假设；本文只把现状损失和目标收益写到足以支持立项讨论的程度。涉及金额的收益测算必须由财务或业务负责人确认。

它不是审批汇报 PPT。审批汇报可能需要页面结构、视觉呈现和讲述节奏；本文的产物更基础，是一页立项理由、证据清单和沟通要点。PPT 可以在这个基础上再做。

它也不是项目复盘。复盘发生在项目结束后，回答做得怎么样、经验是什么；本文发生在立项前，回答为什么现在值得投入资源去做。

最容易混淆的是“立项理由”和“解决方案”。好的立项理由会提到目标状态，但不会急着写系统设计。你要让审批人先相信问题值得解决，再进入方案讨论。只要文章始终围绕业务问题、现状损失、目标收益和不做后果，就不会偏离这张主题卡。