项目立项书要回答清楚六个问题：为什么现在做、做到什么算完成、边界在哪里、需要投入什么、可能出什么问题、做完有什么收益。本文提供一张可直接复制的空白立项书表格，并逐栏说明填写口径、必填与选填的划分、一份完整填写示例，以及模板后续调整与版本维护的方法。示例中的项目情景为演示用途，用于说明写法。
要点总览（TL;DR）
- 立项书用一张表覆盖六个核心栏目：背景、目标、范围、资源需求、风险、预期收益，基础信息区记录名称、提出人、日期与版本。
- 背景写现状问题、触发事件与不做的后果；目标写可验收结果并配验收标准与完成时间，避免写成“推进”“优化”这类动作描述。
- 范围拆“包含”与“不包含”两列，排除项写到具体对象；资源需求按人力、预算、时间、外部依赖四行分项，人力写角色与投入比例。
- 风险按一行一个风险展开，每个风险写描述、可能性、影响、应对措施与责任人，触发信号要可观察；收益区分量化与定性，量化收益注明测算口径与数据来源。
- 必填底线是背景、目标与验收标准、范围包含项、核心资源量级、主要风险及应对、收益结论六项；小项目可裁剪详细预算科目、次要风险等，裁剪需上级或项目管理办公室确认。
可复制空白立项书模板
下表覆盖基础信息与六个核心栏目，可直接复制到文档或表格工具中填写。范围栏拆为“包含”与“不包含”两列，资源需求按人、预算、时间、外部依赖四行展开，风险栏按风险描述、可能性、影响、应对措施四列记录，收益栏区分量化收益与定性收益。
| 区域 | 字段 | 填写内容 |
|---|---|---|
| 基础信息 | 项目名称 | |
| 提出人 / 部门 | ||
| 填写日期 | ||
| 文档版本 | ||
| 背景 | 现状问题 | |
| 触发事件 | ||
| 不做的后果 | ||
| 目标 | 目标描述（结果导向） | |
| 验收标准 | ||
| 完成时间 | ||
| 范围 | 包含（做什么、交付什么） | |
| 不包含（明确排除项） | ||
| 资源需求 | 人力（角色与投入比例） | |
| 预算（科目与金额） | ||
| 时间（关键节点） | ||
| 外部依赖（供应商、接口方、审批） | ||
| 风险 | 风险描述 | |
| 可能性（高/中/低） | ||
| 影响（范围、进度、成本） | ||
| 应对措施与责任人 | ||
| 预期收益 | 量化收益（金额、工时、转化率等） | |
| 定性收益（体验、能力、合规等） | ||
| 测算口径与回收周期 |
风险栏在实际使用时通常不止一行，建议按“一行一个风险”展开，主要风险排在前面。收益栏的量化与定性两部分可以分行填写，便于评审时分别核对。
各栏目字段说明与填写口径
同一份立项书在评审中被质疑，多数情况是某个栏目写得过于笼统。下面逐栏说明每个字段该写什么、写到什么颗粒度，与上表字段一一对应。
| 栏目 | 该写什么 | 颗粒度要求 | 常见问题 |
|---|---|---|---|
| 背景 | 现状问题、触发事件、不做的后果 | 问题要能指向具体业务对象或数据，触发事件带时间 | 只写行业趋势，看不出与本项目的关联 |
| 目标 | 项目结束时可验收的结果 | 结果可核对，带指标或交付物名称 | 写成“推进”“优化”等动作描述 |
| 范围 | 包含的交付物清单与明确排除项 | 交付物逐项列出，排除项写清对象 | 只写包含项，边界靠口头约定 |
| 资源需求 | 人力角色与投入比例、预算科目、时间节点、外部依赖 | 角色到岗名或岗位，投入写百分比或人天 | 只写“需要若干开发人员” |
| 风险 | 来源、触发信号、影响面、应对与责任人 | 每个风险有可观察的触发信号和明确责任人 | 只列风险名称，没有应对动作 |
| 预期收益 | 收益类型、测算依据、回收周期 | 量化收益写公式或数据来源，定性收益写受益对象 | 收益数字没有测算口径 |
背景要回答“为什么现在做”。现状问题描述当前业务中具体的不便或损失，例如某环节每月人工核对耗时、某类请求平均响应时长；触发事件说明推动立项的外部或内部变化，如客户投诉、政策要求、系统到期；不做的后果说明拖延的代价，让评审人理解时间窗口。
目标写结果，不写动作。“上线新审批流程”是动作，“审批平均时长从3天降到1天，覆盖全部采购申请”是可验收结果。一个项目的主目标控制在两到三条，每条都对应验收标准与完成时间，验收标准要能被第三方核对。
范围用两列划边界。包含项列出交付物清单，如“采购申请线上审批功能、历史数据迁移、操作手册”；不包含项写清本次不处理的对象，如“不覆盖海外子公司”“不含移动端”。排除项写得越具体，后续范围蔓延的争议越少。
资源需求按四行分项。人力写角色与投入比例，如“后端开发1人投入50%、业务分析师1人投入30%”；预算按科目列，如软件采购、外包服务、差旅；时间写关键节点而非笼统工期；外部依赖写供应商交付、接口方配合、审批事项及其承诺时间。
风险每个风险写四要素：描述、可能性、影响、应对措施与责任人。触发信号要可观察，如“供应商样件连续两次验收不合格”，这样风险发生时能及时启动应对，而不是事后复盘才发现。
预期收益区分可量化与定性两类。量化收益注明测算依据，如“按去年12万笔申请、每笔节省8分钟人工计算”；定性收益写清受益对象与改善内容；回收周期说明投入与收益的时间关系，测算口径与数据来源一并注明，便于评审复核。
必填与选填的划分
模板字段齐全不等于每个项目都要填满。判定规则是：缺少该字段会导致评审无法判断项目是否值得做、能否做成，就列为必填；只影响执行细节的，可列为选填。
| 类别 | 字段 | 说明 |
|---|---|---|
| 必填 | 项目名称、提出人、日期、版本 | 基础信息，用于归档与追溯 |
| 必填 | 背景（现状问题、触发事件） | 评审判断必要性的依据 |
| 必填 | 目标与验收标准 | 判断项目是否可验收 |
| 必填 | 范围包含项 | 判断工作量与交付物 |
| 必填 | 核心资源（主要人力角色、总预算量级、关键时间节点） | 判断投入是否可承受 |
| 必填 | 主要风险及应对 | 判断风险是否可控 |
| 必填 | 收益结论（至少一条量化或定性收益及口径） | 判断投入产出是否合理 |
| 选填 | 详细预算科目拆分 | 小项目可只写总额与主要科目 |
| 选填 | 次要风险 | 影响面小的风险可合并为一条 |
| 选填 | 定性收益的展开描述 | 有量化收益时可从简 |
| 选填 | 附件清单（调研材料、报价单等） | 按需附上 |
小项目可以裁剪的字段包括：详细预算科目、次要风险、定性收益的展开描述、附件清单。不可裁剪的底线是背景、目标与验收标准、范围包含项、核心资源量级、主要风险及应对、收益结论——这六项缺任何一项，评审就无法完成基本判断。
裁剪后需由项目发起方的直接上级或项目管理办公室确认，确认记录写在立项书版本说明中。这样裁剪有据可查，后续复盘时也能区分“当时判断不需要”与“漏填”。
完整填写示例
以下示例为演示情景，展示六个栏目与模板字段的对应写法，项目内容为虚构。
| 栏目 | 示例内容 |
|---|---|
| 基础信息 | 项目名称：采购申请线上审批改造；提出人：行政部 张××；日期：2025-03-10；版本：V1.0 |
| 背景 | 现状：采购申请目前走纸质签批，平均流转3天，每月约1000笔，申请人需往返行政部两次。触发事件：2025年2月内部审计指出纸质签批存在丢失与补签风险，要求二季度内整改。不做：审计问题持续存在，且下半年办公地点分散后流转时间将进一步延长。 |
| 目标 | 2025年6月30日前，全部采购申请实现线上审批；审批平均时长从3天降到1天以内；审计所需的签批记录可完整导出。验收标准：连续一个月线上审批覆盖率100%，抽查20笔记录可完整追溯。 |
| 范围 | 包含：采购申请线上表单与审批流、历史纸质单据关键字段补录、审批记录导出功能、操作手册与一次培训。不包含：供应商管理模块改造、海外子公司采购流程、移动端审批。 |
| 资源需求 | 人力：业务分析师1人投入30%（需求梳理与验收），后端开发1人投入50%（流程与导出功能），行政专员1人投入20%（数据补录与培训组织）。预算：软件配置服务费8万元，培训与手册制作1万元。时间：4月中旬完成需求确认，5月底功能上线试运行，6月底全量切换。外部依赖：OA平台供应商承诺4月底前开放审批接口，需在合同中约定交付时间。 |
| 风险 | 风险1：OA接口延期交付。可能性中，影响为上线推迟。触发信号：4月25日接口文档仍未提供。应对：提前准备线下过渡方案，责任人：项目负责人。风险2：历史单据补录数据不全。可能性高，影响为审计追溯不完整。触发信号：补录抽查缺失率超过10%。应对：按部门分批补录并设置核对人，责任人：行政专员。 |
| 预期收益 | 量化收益：按每月1000笔、每笔节省申请人及审批人合计约20分钟计算，每月节省约333工时，按内部工时成本折算年化约40万元；测算口径为2024年全年申请量12万笔与现行纸质流程耗时统计。定性收益：审计记录完整可查，降低合规风险；分散办公后审批不受地点限制。回收周期：投入约9万元，按上述口径约3个月收回。 |
示例中每个栏目都落到具体对象、数字或可核对的事实：背景有审计结论和时间要求，目标有覆盖率与时长指标，范围有排除项，资源有角色投入比例与接口承诺时间，风险有触发信号与责任人，收益有测算公式与数据来源。
立项书填写完成并通过评审后，通常还需要在协作工具中承载文档评审、版本留存与后续任务跟踪。ONES Wiki 支持页面模板库，可一键创建制式化文档，把立项书模板固化为统一格式；文档实时同步并记录所有页面版本，支持随时查看与回滚，评审中的多轮修改可以追溯；页面组可关联项目，立项文档与后续需求、任务互相对应；文档内还可嵌入任务进度与报表，立项后的执行情况能在同一页面查看。立项书中的目标与范围确认后，ONES Assistant 可基于项目目标、范围和关键交付物生成结构化项目计划、里程碑、阶段任务与责任分工，把立项结论转成可执行的任务安排。
模板的调整与维护方法
模板需要随项目类型和组织实践演进，但调整要有记录、有确认，避免不同版本混用导致评审口径不一致。
按项目类型增减栏目。研发类项目可增加“技术方案要点”与“依赖系统清单”；市场活动类项目可增加“渠道与物料清单”；合规整改类项目可强化“监管要求条款”与“整改验收方式”。增减栏目时保持六个核心栏目不变，新增内容作为子字段挂靠，避免打乱评审人的阅读顺序。
记录字段口径变更。每次修改字段含义、颗粒度要求或必填规则，在模板附带的修订记录中写明变更内容、原因和生效日期。例如“2025-05起，资源需求栏人力投入统一写百分比，不再写人天”，让填写人知道新旧口径的差异。
维护版本号与修订记录。版本号建议采用主次两级：栏目结构变化升主版本，措辞与示例更新升次版本。修订记录至少包含版本号、日期、修改人、修改摘要四项，历史版本保留可查，便于对照旧立项书。
让评审反馈回流。评审中反复被追问的字段，说明口径不清，应补充说明或示例；长期无人填写的选填字段，评估是否删除或降级。可以每季度汇总一次评审意见，由项目管理办公室统一修订并发布新版本，发布时通知所有填写人。
模板维护的责任人建议固定到岗位而非个人，例如由项目管理办公室或质量管理部门持有模板的发布权，避免人员变动后模板失管。调整后的模板在协作工具中以页面模板形式更新，新建立的立项文档直接引用最新版本，减少旧版本扩散。
常见问题
立项书里的目标写成“提升审批效率”可以吗？评审时会被要求补充什么？
“提升审批效率”属于方向性表述，评审时通常会被追问三件事：提升到什么水平、覆盖哪些对象、什么时候可以核对。建议改成结果加指标加时间的写法，例如“审批平均时长从3天降到1天以内，覆盖全部采购申请，2025年6月30日前达成”。同时补一条验收标准，说明第三方如何核对，比如连续一个月覆盖率100%、抽查20笔记录可完整追溯。目标条目控制在两到三条，每条都对应验收标准与完成时间。
小项目填写立项书时，哪些字段可以省，省掉之后需要谁确认？
可以裁剪的是详细预算科目拆分、次要风险、定性收益的展开描述和附件清单。不能省的是背景、目标与验收标准、范围包含项、核心资源量级、主要风险及应对、收益结论这六项，缺任何一项评审都无法完成基本判断。裁剪后由项目发起方的直接上级或项目管理办公室确认，确认记录写进立项书版本说明，便于后续复盘区分“当时判断不需要”与“漏填”。
预期收益没有现成数据，测算口径怎么写才不会被评审打回？
没有现成数据时，把测算过程写出来比给一个孤立数字更可信。先写业务量基数及其来源，例如去年申请量12万笔来自系统统计；再写单笔节省的工时或成本及测量方式；最后给出折算公式与回收周期。定性收益写清受益对象与改善内容，例如审计记录完整可查、降低合规风险。测算口径与数据来源一并注明，评审人可以按同样口径复核，也能看出哪些假设需要验证。
风险栏只写风险名称和应对措施，够不够用？
通常不够。评审更关心风险什么时候会被发现、由谁负责启动应对。建议每个风险补齐四要素：描述、可能性、影响、应对措施与责任人，并加一条可观察的触发信号，例如“供应商样件连续两次验收不合格”“4月25日接口文档仍未提供”。触发信号明确后，风险出现时团队能按预设动作处理，而不是事后复盘才发现。风险按一行一个展开，主要风险排在前面。
立项书通过评审后，文档版本和后续任务怎么衔接？
评审通过后通常还有多轮修改和后续执行跟踪，需要把文档版本与任务对应起来。ONES Wiki 支持页面模板库，可一键创建制式化文档，把立项书模板固化为统一格式；文档实时同步并记录所有页面版本，支持随时查看与回滚，评审中的修改可以追溯；页面组可关联项目，立项文档与后续需求、任务互相对应；文档内还可嵌入任务进度与报表。立项书中的目标与范围确认后，ONES Assistant 可基于项目目标、范围和关键交付物生成结构化项目计划、里程碑、阶段任务与责任分工，把立项结论转成可执行的任务安排。
