项目立项书用于回答两个问题：这个项目要不要启动，启动后按什么边界推进。本文交付一份可直接复制填写的空白模板，并逐字段说明填写口径、区分必填与选填、给出一份完整填写示例，最后说明模板如何随流程调整。适用范围是单个项目的启动审批；多个项目之间的准入比较与排序不在本文展开。立项书定稿后需要进入审批和项目台账，这类文档协同与版本留存工作可以放在ONES中承载。
要点总览（TL;DR）
- 空白模板按六个区块组织：项目基本信息、背景与问题、目标与成功标准、范围与交付物、资源与里程碑、风险与审批结论，可直接复制到文档或表格中填写。
- 填写顺序建议先定目标与成功标准，再写范围边界，最后补资源、里程碑与风险，让审批人读完能判断是否批准。
- 必填项围绕审批判断和结项依据确定：问题、目标、成功标准、验收方式、范围、不做事项、交付物、里程碑、风险与审批结论不可省略；预算、依赖、干系人等可按项目规模压缩。
- 文末附一份完整填写示例，演示目标、成功标准、范围边界、里程碑与风险如何互相支撑，示例为演示情景。
- 模板需要定期复核：审批中反复出现的补充提问、长期空置的字段、流程与台账口径变化，都是调整触发条件，历史立项书按原版本留存。
可复制空白立项书模板
下面这份模板按表格组织，共六个区块。复制到文档工具时，把每个区块转成一张小表；复制到电子表格时，把六个区块纵向排列在同一张表里，用区块名称作为分组行。两种形式字段完全一致，区别只在排版。
区块一：项目基本信息
| 字段 | 填写内容 |
|---|---|
| 项目名称 | |
| 项目编号 | |
| 提案人 / 日期 | |
| 项目负责人 | |
| 发起部门 / 参与部门 | |
| 项目类型 | |
| 预计周期 | |
| 预算量级 |
区块二：背景与问题
| 字段 | 填写内容 |
|---|---|
| 现状描述 | |
| 待解决问题 | |
| 不做的后果 | |
| 相关依据 |
区块三：目标与成功标准
| 字段 | 填写内容 |
|---|---|
| 项目目标 | |
| 成功标准 | |
| 验收方式 | |
| 验收责任人 |
区块四：范围与交付物
| 字段 | 填写内容 |
|---|---|
| 范围内事项 | |
| 明确不做事项 | |
| 主要交付物 | |
| 依赖与前置条件 |
区块五：资源与里程碑
| 字段 | 填写内容 |
|---|---|
| 人员投入 | |
| 预算与采购 | |
| 关键里程碑 | |
| 关键干系人 |
区块六：风险与审批结论
| 字段 | 填写内容 |
|---|---|
| 主要风险 | |
| 应对措施 | |
| 审批意见 | |
| 审批结论 | 批准 / 有条件批准 / 暂缓 / 不批准 |
| 审批人 / 日期 |
裁剪时保持区块顺序不变，只删减区块内的行。小项目可以合并“发起部门”和“参与部门”，把“预算与采购”简化为一行金额；跨部门项目则应在基本信息中补充接口人和决策链，在资源区块中按部门分列投入。
每个字段填什么：立项书字段说明
字段说明解决的是“知道有这一栏，但不知道写到什么程度”。下面按区块给出含义、填写口径和常见错误，颗粒度以“审批人读完能判断是否批准”为准。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 项目名称 | 项目的对外称呼 | 用业务对象加动作，如“客户合同线上签署改造” | 写成口号或内部代号，审批人无法识别 |
| 项目编号 | 与台账对应的唯一标识 | 沿用组织既有编号规则 | 留空，导致后续无法与预算、工时对应 |
| 项目类型 | 区分新建、改造、合规、研究等 | 从组织既定分类中选择 | 自造分类，造成台账口径混乱 |
| 现状描述 | 当前业务或系统状态 | 写事实和数据，不写评价 | 用“效率低”“体验差”代替具体现象 |
| 待解决问题 | 本项目要消除的具体问题 | 一个问题一行，可验证 | 把解决方案写成问题 |
| 不做的后果 | 不启动会发生的损失或风险 | 给出时间范围和影响对象 | 只写“影响发展”一类空话 |
| 项目目标 | 项目结束时要达到的状态 | 动词开头，指向可观察结果 | 目标与交付物混写 |
| 成功标准 | 判断目标达成的量化或可核验条件 | 每条标准对应一个验收动作 | 标准无法验收，如“显著提升” |
| 验收方式 | 由谁、用什么方法确认 | 写明评审、测试、数据核对等方式 | 只写“验收通过” |
| 范围内事项 | 项目负责推进的内容 | 按业务对象或系统模块列举 | 范围写成愿望清单 |
| 明确不做事项 | 本期排除的内容 | 与范围内事项一一对应地划界 | 整栏留空，后期范围蔓延 |
| 主要交付物 | 项目产出的可移交成果 | 写清形态，如文档、系统功能、流程规范 | 只写“完成项目” |
| 依赖与前置条件 | 项目启动或推进所需的外部条件 | 写明依赖方和需要的时间点 | 把风险写进依赖栏 |
| 人员投入 | 各角色投入的人数和比例 | 按角色列，注明是否专职 | 只写“相关部门配合” |
| 关键里程碑 | 阶段性节点及时间 | 每个里程碑对应一个可检查的产出 | 里程碑只有日期没有产出 |
| 主要风险 | 可能影响目标达成的不确定因素 | 按发生可能性和影响描述 | 罗列泛化风险，无对应措施 |
| 审批结论 | 决策人对立项的明确表态 | 四选一：批准、有条件批准、暂缓、不批准 | 只写“同意阅示”，没有结论 |
目标与成功标准是最容易写虚的两栏。可用的写法是：目标写“把某业务的某环节从A状态变为B状态”，成功标准写“上线后连续四周该环节处理时长为X以内、错误率为Y以下”。验收方式随之写成“由业务负责人在第四周核对系统报表并签字”。三栏形成一条链，审批人才能判断项目结束后如何结项。
范围边界的写法是把“做什么”和“不做什么”成对列出。例如范围内写“覆盖合同签署与归档两个环节”，不做事项写“不包含合同模板的法务审核流程改造”。成对表达让审批人看到边界是被主动划过的，而不是遗漏的。
必填与选填：按项目规模决定填写深度
立项书的必填项与项目规模无关，与“审批人是否需要据此做决定”有关。以下字段缺失会直接导致立项书无法进入审批，或批准后无法结项。
| 类别 | 字段 | 缺失后果 / 适用情形 |
|---|---|---|
| 必填 | 项目名称、提案人、项目负责人、预计周期 | 无法建立台账条目，责任无人承接 |
| 必填 | 待解决问题、项目目标、成功标准、验收方式 | 批准后无结项依据，项目无法判定成败 |
| 必填 | 范围内事项、明确不做事项、主要交付物 | 执行中范围蔓延，变更无基准 |
| 必填 | 关键里程碑、主要风险、审批结论、审批人 | 立项书退化为说明材料，没有决策记录 |
| 选填 | 项目编号 | 组织已有编号规则时必填；临时探索项目可后补 |
| 选填 | 预算与采购 | 不涉及新增支出的项目可写“无新增预算” |
| 选填 | 依赖与前置条件 | 完全内部闭环的小项目可省略 |
| 选填 | 关键干系人 | 单部门项目可并入参与部门一栏 |
| 选填 | 相关依据 | 有调研、数据或客户反馈时填写，增强说服力 |
裁剪规则可以概括为三条。第一，凡是审批人需要用来做判断的字段不能删，包括问题、目标、成功标准、范围和结论。第二，凡是结项时需要回看的字段不能删，包括里程碑、交付物和验收方式。第三，凡是只影响描述丰富度的字段可以压缩，例如背景依据可缩为一行引用，干系人可并入部门栏。
小项目与跨部门项目的填写深度差异主要体现在三处。小项目的里程碑可以只写两到三个节点，资源写清主责人即可；跨部门项目需要按部门分列投入、写明接口人和决策链，依赖与前置条件通常转为必填，因为跨部门协调的等待时间往往决定项目周期。判断标准是：项目涉及两个以上部门的资源调配时，按跨部门深度填写。
填写示例：一份完整的立项书样例
以下为演示情景，用于展示字段之间的对应关系，不代表真实项目。
| 区块 | 字段 | 示例内容 |
|---|---|---|
| 基本信息 | 项目名称 | 客户合同线上签署改造 |
| 基本信息 | 项目编号 | PRJ-2025-031 |
| 基本信息 | 提案人 / 日期 | 销售运营部 李某 / 3月10日 |
| 基本信息 | 项目负责人 | 销售运营部 王某 |
| 基本信息 | 发起部门 / 参与部门 | 销售运营部；法务部、信息技术部 |
| 基本信息 | 项目类型 | 流程改造 |
| 基本信息 | 预计周期 | 3个月 |
| 基本信息 | 预算量级 | 无新增采购，占用信息技术部2人月 |
| 背景与问题 | 现状描述 | 合同平均签署周期9个工作日，其中邮寄往返占5个工作日 |
| 背景与问题 | 待解决问题 | 纸质签署环节导致周期长、归档分散 |
| 背景与问题 | 不做的后果 | 本季度预计有30份合同因签署延迟影响回款确认 |
| 目标与成功标准 | 项目目标 | 把标准合同的签署与归档转为线上完成 |
| 目标与成功标准 | 成功标准 | 上线后连续四周合同平均签署周期不超过4个工作日；归档完整率100% |
| 目标与成功标准 | 验收方式 | 由销售运营负责人核对系统报表并签字确认 |
| 目标与成功标准 | 验收责任人 | 销售运营部负责人 |
| 范围与交付物 | 范围内事项 | 标准合同线上签署、签署后自动归档 |
| 范围与交付物 | 明确不做事项 | 不改造合同模板的法务审核流程；不覆盖非标准合同 |
| 范围与交付物 | 主要交付物 | 线上签署功能、归档规则说明、操作手册 |
| 范围与交付物 | 依赖与前置条件 | 法务部在4月前确认可线上签署的合同类型清单 |
| 资源与里程碑 | 人员投入 | 销售运营部1人专职；法务部1人兼职；信息技术部2人 |
| 资源与里程碑 | 关键里程碑 | 4月底完成签署流程配置；5月底完成试点部门上线；6月底全量上线并出验收报表 |
| 风险与审批 | 主要风险 | 法务确认清单延迟，导致配置无法按期开始 |
| 风险与审批 | 应对措施 | 4月第一周设检查点，未确认则先按标准合同默认清单推进并同步法务 |
| 风险与审批 | 审批结论 | 有条件批准：以法务清单在4月第一周确认为启动条件 |
| 风险与审批 | 审批人 / 日期 | 运营分管副总 张某 / 3月14日 |
这份示例中，目标“转为线上完成”与成功标准“周期不超过4个工作日、归档完整率100%”一一对应，验收方式指向可核对的系统报表，因此结项时有据可依。范围边界把非标准合同排除在外，里程碑的三个节点分别对应配置、试点、全量三个阶段，与交付物清单一致。风险栏写的是具体依赖项，应对措施给出了检查点和替代路径，审批结论因此可以写成“有条件批准”并附上条件，而不是笼统的“同意”。
模板的调整与维护方法
模板用久了会出现两类问题：字段与实际审批关注点脱节，或者字段越加越多、填写成本超过收益。维护的目标是让模板始终服务于审批判断，而不是变成填表负担。
调整的触发条件可以设为四类：审批中反复出现同一类补充提问，说明模板缺少对应字段；连续多个项目的某字段填写为空或写“无”，说明该字段可以降为选填；组织预算或立项流程发生变化，需要同步字段口径；项目台账新增统计维度，需要立项书提供对应数据。出现任一情况时启动一次模板复核。
字段增删建议走一次小范围评审：由模板维护人提出变更说明，写清新增或删除的字段、影响的填写人和对历史立项书的处理方式，交由经常审批立项书的决策人和项目负责人代表确认。评审重点看两件事：新字段是否真的影响审批判断，删除字段是否会导致结项时缺少依据。评审通过后更新版本号，并在模板页首标注生效日期。
版本与历史留存方面，每次调整保留旧版本，历史立项书按提交时的版本归档，不随模板更新而改写。这样在回看早期项目时，能还原当时的审批口径。模板与审批流程、项目台账的衔接也要同步检查：新增字段若需要进入台账统计，应确认台账侧有对应字段；审批结论的四个选项若发生调整，应同步更新审批环节的选项配置。
落地时，可以把模板放入组织的文档模板库统一分发，避免各团队自行复制出多个版本。ONES Wiki 提供页面模板库，可一键创建制式化文档模板，适合承载这类需要统一口径的立项书；文档会记录页面版本并支持查看与回滚，便于保留模板的历史版本。立项书定稿后，页面组可关联项目，使立项文档与项目工作保持对应，审批结论和关键里程碑也能在项目上下文中被后续执行环节引用。具体模板类型与版本记录范围以实际开通版本和配置为准。
维护检查清单：模板版本号与生效日期是否已更新；新增字段是否已进入台账口径；必填与选填划分是否仍与项目规模匹配；历史立项书是否按原版本留存；审批结论选项是否与审批环节一致。每次复核后逐项确认，可避免模板在多次小改动后失去一致性。
常见问题
立项书里的“目标”和“成功标准”有什么区别，能不能只写一个？
两栏承担不同作用。目标描述项目结束时要达到的状态，例如“把标准合同的签署与归档转为线上完成”；成功标准给出判断目标是否达成的可核验条件，例如“上线后连续四周平均签署周期不超过4个工作日、归档完整率100%”。只写目标，结项时缺少判定依据；只写标准，审批人不容易看出项目要改变什么。建议两栏成对填写，并让验收方式指向可核对的报表、评审记录或测试结果。
项目很小，能不能跳过“明确不做事项”这一栏？
这一栏建议保留，哪怕只写一行。范围边界的作用是在执行阶段出现新增需求时提供对照基准，小项目同样会遇到“顺手一起做”的追加请求。写法上可以很简短，例如“本期只覆盖标准合同，非标准合同不在范围内”。如果项目确实没有可预见的边界争议，也可以写“本期无排除事项”，明确表达已经考虑过边界，避免整栏留空。
审批结论写“有条件批准”时，条件应该写在哪里？
条件与结论放在同一处，写在审批意见栏，并让条件可检查。例如“有条件批准：以法务清单在4月第一周确认为启动条件”，同时把该条件对应到依赖与前置条件栏或风险应对措施中，形成前后一致。条件涉及时间点时写明具体日期，涉及交付物时写明由谁提供。这样项目启动后，团队能直接判断条件是否满足，不需要再回头询问审批人。
跨部门项目的立项书要额外写什么？
跨部门项目的填写深度主要增加在三处：基本信息中补充接口人和决策链，让审批人知道找谁确认；资源区块按部门分列投入人数与是否专职，避免只写“相关部门配合”；依赖与前置条件通常转为必填，写明依赖方和需要的时间点，因为跨部门协调的等待时间往往直接影响项目周期。判断标准是项目是否涉及两个以上部门的资源调配，涉及即按跨部门深度填写。
立项书定稿后，模板和文档版本怎么管理？
模板层面，每次调整保留旧版本，在模板页首标注版本号与生效日期，历史立项书按提交时的版本归档，不随模板更新而改写。文档层面，可以把模板放入统一的文档模板库分发，减少各团队自行复制产生的多个版本。ONES Wiki 提供页面模板库，可一键创建制式化文档模板；文档会记录页面版本并支持查看与回滚，便于保留模板的历史版本。具体模板类型与版本记录范围以实际开通版本和配置为准。
