项目立项书模板建议覆盖六类栏目：项目基本信息、背景与问题、目标与成功标准、范围与交付物、资源与时间需求、风险与预期收益。这份模板按“拿到即可填写”的方式组织，先给空白表格，再逐栏说明填写口径，并用一个演示项目展示落笔方式。评审时能否据此判断“是否值得启动”，取决于背景证据、目标可验证性、范围边界和资源口径是否写清。
要点总览（TL;DR）
- 项目立项书模板建议覆盖六类栏目：项目基本信息、背景与问题、目标与成功标准、范围与交付物、资源与时间需求、风险与预期收益。
- 背景要写触发原因、现状与证据；目标写成可验证的结果并配成功标准；范围同时写明包含项与不包含项。
- 资源需求落到人、预算、时间三类并注明估算依据；风险逐条写影响、概率、应对与责任人；预期收益给出量化口径或估算依据。
- 必填栏目的判断标准是缺失后评审无法形成“是否启动”的结论；小型项目可简化预算与风险栏，大型项目增加依赖条件与收益验证方式为必填。
- 模板按项目类型增减栏目、记录版本变更、定期复盘字段有效性，保持字段说明与填写示例三者一致。
可复制空白立项书模板
下表可直接复制到文档或表格工具中使用。栏目按六类分组，填写要点列说明该栏应写到什么程度，“必填”标记用于常规规模项目的评审底线，具体调整规则见第三节。
| 分组 | 栏目 | 填写要点 | 必填/选填 |
|---|---|---|---|
| 一、项目基本信息 | 项目名称 | 使用组织内可识别的正式名称，避免代号与简称混用 | 必填 |
| 立项申请人 / 发起人 | 写明姓名、角色，发起人与申请人可为同一人 | 必填 | |
| 拟启动日期与期望完成日期 | 给出时间区间，注明是评审通过后启动还是已确定日期 | 必填 | |
| 项目类型 | 如新产品、系统改造、流程优化、合规整改等，用于匹配评审口径 | 必填 | |
| 关联项目或上级目标 | 说明本项目服务于哪个业务目标或项目群 | 选填 | |
| 二、背景与问题 | 触发原因 | 写清为什么现在提出立项：事件、需求、政策或数据变化 | 必填 |
| 现状描述与证据 | 用数据、记录、反馈或流程现状说明问题规模，标注数据来源与时间 | 必填 | |
| 不立项的后果 | 说明维持现状的影响，帮助评审判断紧迫性 | 选填 | |
| 三、目标与成功标准 | 项目目标 | 写成结果导向的一句话，包含对象、变化和衡量口径 | 必填 |
| 成功标准 | 列出可验证的验收条件，如指标值、交付物清单、评审通过条件 | 必填 | |
| 衡量方式与时间点 | 说明由谁、在什么时间、用什么数据判断目标达成 | 必填 | |
| 四、范围与交付物 | 范围包含项 | 列出本项目负责的业务、系统、流程或区域 | 必填 |
| 范围不包含项 | 明确排除项及归属，防止后续争议 | 必填 | |
| 关键交付物 | 逐项列出交付物名称、形式与接收方 | 必填 | |
| 五、资源与时间需求 | 人员需求 | 按角色列出人数与投入比例，注明内部调配还是外部引入 | 必填 |
| 预算需求 | 给出金额区间与主要科目，注明估算依据 | 必填 | |
| 时间需求 | 给出关键阶段划分与里程碑日期 | 必填 | |
| 依赖条件 | 列出需要其他团队、供应商或系统配合的前置条件 | 选填 | |
| 六、风险与预期收益 | 主要风险 | 逐条写风险描述、影响、发生概率、应对措施与责任人 | 必填 |
| 预期收益 | 给出量化口径或估算依据，区分直接收益与间接收益 | 必填 | |
| 收益验证方式 | 说明项目完成后如何跟踪收益是否实现 | 选填 |
复制使用时，建议保留分组列，便于评审人按“值不值得启动”的顺序阅读：先看背景与目标，再看范围与资源，最后看风险与收益。表格工具中可将“必填/选填”列改为数据验证下拉，减少漏填。
各栏目字段说明与填写口径
同一栏目写多写少，评审结论可能完全不同。下面按六类核心栏目说明填写方法，颗粒度以“评审人无需追问即可判断”为准。
背景：写触发原因、现状与证据
背景承担回答“为什么现在做”的任务。触发原因写具体事件或变化，例如某类工单量连续三个月上升、监管要求更新、现有系统停止维护。现状描述要附证据：数据报表、用户反馈记录、流程耗时统计、审计发现等，并标注来源与统计区间。仅有定性描述的背景，评审时通常需要补充材料。
目标：结果导向，成功标准可验证
目标写项目完成后业务或系统达到的状态，避免写成活动清单。“完成系统上线”是交付动作，“订单处理时长从两天缩短到半天”是结果。成功标准要与目标对应，写成可核验的条件：指标达到某数值、交付物通过某类评审、覆盖范围达到某个比例。同时写明衡量方式与时间点，明确数据由谁提供。
范围：同时写包含与不包含
范围包含项按业务对象、系统模块、流程环节或组织范围逐条列出。范围不包含项同样重要：把容易混淆的相邻工作明确排除，并注明由哪个项目或团队承接。只写包含项的立项书，在资源讨论阶段容易因边界不清反复返工。
资源需求：落到人、预算、时间三类
人员需求按角色写人数和投入比例，例如“后端开发2人，各投入50%，持续三个月”，比“需要开发资源”更便于评审排期。预算需求给出金额区间和主要科目，注明是报价、历史类比还是工作量估算。时间需求给出阶段划分和里程碑日期，并说明关键路径上的依赖。三类资源口径一致，评审才能比较投入与收益。
风险：写影响、概率、应对与责任人
每条风险独立成行，包含风险描述、可能影响、发生概率、应对措施和责任人。概率可用高、中、低或百分比区间，但同一份立项书内口径要统一。应对措施写具体动作，例如“提前锁定供应商产能”“设置两周一次的联合评审”，并落到具体角色。
预期收益：给出量化口径或估算依据
收益分直接收益与间接收益。直接收益尽量量化，如节省工时、减少差错、缩短周期，并写明计算口径：基数来自哪里、单价如何取、统计周期多长。间接收益如客户满意度、合规水平，说明观测指标和估算依据。无法量化的收益如实标注为定性判断，避免用无依据的数字支撑立项。
必填与选填的划分
必填栏目的判断标准是：缺失后评审无法形成“是否启动”的结论。按此标准，背景、目标与成功标准、范围包含与不包含、人员与预算需求、主要风险、预期收益属于必填；关联项目、不立项后果、依赖条件、收益验证方式属于选填，缺失不影响启动判断，但会影响后续管理精度。
| 类别 | 栏目 | 缺失后的影响 | 适用情形 |
|---|---|---|---|
| 必填 | 项目名称、申请人、时间区间、项目类型 | 无法识别项目与责任人，无法排入评审议程 | 所有立项 |
| 必填 | 触发原因、现状与证据 | 评审无法判断问题是否真实、是否紧迫 | 所有立项 |
| 必填 | 项目目标、成功标准、衡量方式 | 无法判断项目完成后是否算成功 | 所有立项 |
| 必填 | 范围包含项、范围不包含项、关键交付物 | 资源与责任边界不清，易在启动后争议 | 所有立项 |
| 必填 | 人员需求、预算需求、时间需求 | 无法比较投入规模，无法做出资源承诺 | 所有立项 |
| 必填 | 主要风险、预期收益 | 无法评估风险敞口与回报，启动依据不足 | 所有立项 |
| 选填 | 关联项目或上级目标 | 不影响启动判断，影响项目群视角下的对齐 | 项目群管理或目标对齐要求较高时填写 |
| 选填 | 不立项的后果 | 不影响启动判断，影响优先级讨论 | 多个项目竞争资源时建议填写 |
| 选填 | 依赖条件 | 不影响启动判断，影响排期准确性 | 存在跨团队或外部依赖时填写 |
| 选填 | 收益验证方式 | 不影响启动判断，影响上线后的收益跟踪 | 收益周期较长或金额较大时填写 |
按项目规模调整必填范围时，可采用分级规则：小型项目（周期短、投入少、影响单一团队）可将预算需求简化为金额区间，风险栏至少保留一条主要风险；中型项目按上表全量填写；大型或跨部门项目在此基础上增加依赖条件、不立项后果和收益验证方式为必填。分级标准由组织根据自身评审权限确定，并在模板版本说明中固定下来，避免每次评审临时争论。
一份填写完整的立项书示例
以下为演示情景，用于展示各栏目如何落笔，非真实客户案例。示例项目为“客服工单系统改造”，字段与第一节表格一一对应。
背景与目标写法
触发原因：客服团队连续两个季度反馈工单平均处理时长上升，且高峰期漏单投诉增加。现状与证据：根据客服系统2024年第二季度报表，工单平均处理时长为38小时，较上季度增加6小时；同期漏单投诉12起，均有工单记录可查。项目目标：将工单平均处理时长缩短至24小时以内，高峰期漏单率降至每月1起以下。成功标准：上线后连续两个月统计达到上述指标，且客服团队确认新流程可日常操作。衡量方式：由客服运营每月从系统导出报表核对，上线后第三个月做一次复盘评审。
范围包含与不包含的写法
范围包含项：工单分配规则调整、超时提醒功能、客服工作台界面改版、上线培训。范围不包含项：客服人员编制调整（由客服部另行规划）、与外部CRM系统的数据对接（归入下半年集成项目）、历史工单数据清洗（由数据团队承接）。关键交付物：改造后的工单系统、操作手册、两场培训记录、上线验收报告。
资源、风险与收益的填写示范
人员需求：产品经理1人投入50%，后端开发2人各投入60%，前端开发1人投入40%，测试1人投入30%，周期三个月。预算需求：外部接口服务采购约5万至8万元，依据供应商报价单；培训与文档制作约1万元，依据同类项目历史支出。时间需求：需求确认两周，开发六周，测试与上线四周，里程碑为第2周末需求冻结、第8周末提测、第12周末上线。主要风险：客服高峰期无法停机切换，影响上线窗口，概率中，应对为选择周末低峰切换并准备回滚方案，责任人为项目经理；需求变更导致延期，概率中，应对为需求冻结后变更需走评审，责任人为产品经理。预期收益：按当前工单量测算，处理时长缩短后每月节省客服工时约320小时，依据为第二季度工单量与平均时长；漏单投诉减少带来的客户留存改善为定性判断，暂不折算金额。收益验证方式：上线后每月统计处理时长与漏单数，连续三个月后由客服运营出具收益跟踪说明。
这份示例的填写密度可作为中等规模项目的参照：背景有数据和时间区间，目标有指标值，范围有排除项，资源有比例和依据，风险有责任人和动作，收益有计算口径。立项书进入评审流转后，文档的版本与权限管理会影响后续追溯。ONES Wiki 支持页面模板库一键创建制式化文档，页面组可关联项目使需求与文档对应，文档记录所有页面版本并支持查看与回滚，还可为不同角色配置读写权限，适合承载立项书从填写、评审到归档的过程。
模板的调整与维护方法
模板长期不调整会出现两类问题：字段过多导致填写负担，或字段过时导致评审依据失效。维护工作围绕按项目类型增减栏目、记录版本变更、定期复盘字段有效性三件事展开。
按项目类型增减栏目
先梳理组织内常见的项目类型，如新产品研发、系统改造、流程优化、合规整改，再为每类确定栏目差异。系统改造类项目可强化依赖条件和回滚安排；合规整改类项目可增加监管依据和验收标准栏；流程优化类项目可强化现状证据和收益口径。增减栏目时保持六类分组不变，只在组内调整，避免评审人每次面对不同结构。新增栏目先以选填试运行一个评审周期，确认有实际填写价值后再转为必填。
版本与变更记录方式
模板本身应有版本号和变更记录表，记录每次调整的日期、调整人、调整内容和原因。变更记录与模板放在同一文档中，填写人可据此判断自己使用的是否为最新版本。已提交评审的立项书保留其填写时的模板版本号，便于回溯评审依据。
| 版本号 | 调整日期 | 调整人 | 调整内容 | 调整原因 |
|---|---|---|---|---|
| V1.0 | （填写） | （填写） | 初始六类栏目与必填划分 | （填写） |
| V1.1 | （填写） | （填写） | （如：新增依赖条件为大型项目必填） | （填写） |
| V1.2 | （填写） | （填写） | （填写） | （填写） |
定期复盘字段有效性
建议每半年或每完成一批立项评审后做一次复盘，检查三类信号：某栏目连续多次为空或填写质量低，考虑简化或改为选填；评审中反复被追问的信息不在模板内，考虑新增栏目；某栏目填写内容从未影响评审结论，考虑合并。复盘由负责立项管理的角色组织，邀请近期参与评审的申请人和评审人各若干名，形成调整建议后按版本变更流程发布。模板调整后，同步更新字段说明和填写示例，保持三者一致。
常见问题
立项书里的“背景”只写定性描述可以吗？
可以写，但评审时通常需要补充证据。建议在触发原因之外，附上数据报表、用户反馈记录、流程耗时统计或审计发现，并标注来源与统计区间。仅有定性描述的背景，评审人难以判断问题规模与紧迫性，容易要求补充材料后再议。
小型项目也要按模板全量填写吗？
不需要。可按项目规模分级：小型项目（周期短、投入少、影响单一团队）可将预算需求简化为金额区间，风险栏至少保留一条主要风险；中型项目按模板全量填写；大型或跨部门项目增加依赖条件、不立项后果和收益验证方式为必填。分级标准由组织根据自身评审权限确定，并在模板版本说明中固定下来。
预期收益无法量化时怎么填？
如实标注为定性判断，并说明观测指标和估算依据。直接收益尽量量化，写明计算口径：基数来自哪里、单价如何取、统计周期多长；间接收益如客户满意度、合规水平，给出观测指标即可。避免用无依据的数字支撑立项，评审时反而更容易被追问。
立项书提交评审后，模板又更新了版本，已提交的文档要跟着改吗？
不需要。已提交评审的立项书保留其填写时的模板版本号，便于回溯评审依据。模板变更记录中注明调整日期、调整人、调整内容和原因，填写人可据此判断自己使用的是否为最新版本。新立项按最新版本填写即可。
用文档工具承载立项书时，版本和权限怎么管理比较稳妥？
立项书从填写、评审到归档会经历多次修改，文档工具需要能记录版本并支持回滚，同时按角色配置读写权限。ONES Wiki 支持页面模板库一键创建制式化文档，页面组可关联项目使需求与文档对应，文档记录所有页面版本并支持查看与回滚，还可为不同角色配置读写权限，适合承载这一过程。
