项目立项报告用于回答一个项目是否启动、启动到什么程度。一份可用的报告通常包含项目概况、目标与范围、价值与可行性、交付与计划、资源与预算、风险与假设、审批结论七个章节，关键字段包括项目名称、发起人、目标与成功标准、范围边界、里程碑、预算与人力、主要风险及审批意见。下面给出一份可直接复制填写的空白模板，并逐项说明字段用途、必填取舍和填写示例；立项报告的目标、范围、里程碑与审批记录也可以在ONES中承载和归档。
要点总览（TL;DR）
- 立项报告按“项目概况—目标与范围—价值与可行性—交付与计划—资源与预算—风险与假设—审批结论”七章组织，每章对应一类启动判断。
- 关键字段包括项目名称、发起人、项目经理、项目目标、成功标准、范围边界、主要交付物、里程碑、人力投入、费用预算、主要风险和审批意见。
- 必填字段以“缺少即无法决策”为标准；小型内部改进可压缩价值测算与备选方案，跨部门或大额投入项目应补全依赖、验收与支撑材料。
- 模板可按项目类型增减章节，但保留目标、范围、交付、投入、风险、审批的主干，并统一成功标准与预算科目口径。
- 立项报告可在ONES Wiki中用页面模板库创建，页面组关联项目，版本记录与权限设置便于审批前后管理。
可复制空白立项报告模板
以下模板按章节顺序排列，方括号内为待填占位。复制到文档工具后，逐项替换占位内容即可形成初稿；不适用的选填项可标注“不适用”并简要说明原因，避免留空造成审批时反复追问。
一、项目概况
- 项目名称：【项目名称】
- 项目编号：【项目编号，如组织有统一编码规则】
- 项目发起人：【姓名／部门／职务】
- 项目经理：【姓名／部门】
- 发起日期：【YYYY年MM月DD日】
- 项目类型：【新产品／系统建设／流程优化／市场活动／其他】
- 一句话说明：【用一句话说明项目要解决什么问题、为谁解决】
二、目标与范围
- 项目背景：【当前业务现状、触发立项的事件或问题】
- 项目目标：【目标描述，尽量可衡量】
- 成功标准：【项目完成后用哪些指标判定成功，含指标口径与统计周期】
- 范围边界（包含）：【本项目明确交付的内容】
- 范围边界（不包含）：【明确排除的内容，防止预期扩散】
- 主要干系人：【角色、姓名、关注点】
三、价值与可行性
- 业务价值：【对收入、成本、效率、合规或客户体验的具体影响】
- 价值测算依据：【测算方法、数据来源、关键假设】
- 方案概述：【拟采用的主要实现路径】
- 备选方案：【其他可选路径及未采用原因】
- 可行性判断：【技术、资源、时间、合规四方面的初步结论】
- 支撑材料：【需求说明、调研记录、数据报表、技术预研结论等清单】
四、交付与计划
- 主要交付物：【交付物名称及验收方式】
- 里程碑计划：【里程碑名称、计划完成时间、交付标志】
- 关键依赖：【依赖的内部团队、外部供应商或前置项目】
- 验收方式：【验收人、验收标准、验收时间点】
五、资源与预算
- 人力投入：【角色、人数、投入比例、投入周期】
- 费用预算：【费用科目、金额、计算依据】
- 其他资源：【设备、场地、外部服务等】
- 资源来源：【内部调配／外部采购／专项预算】
六、风险与假设
- 主要风险：【风险描述、发生可能性、影响程度、应对措施、责任人】
- 关键假设：【项目成立所依赖的前提条件】
- 待决事项：【立项阶段尚未确定、需要审批方决策的问题】
七、审批结论
- 审批意见：【同意立项／有条件同意／暂缓／不立项】
- 审批条件：【如同意，附带的资源、范围或时间条件】
- 审批人及日期：【姓名／职务／日期】
- 抄送范围：【相关部门或角色】
审批签署区
| 角色 | 姓名 | 意见 | 签字／日期 |
|---|---|---|---|
| 项目发起人 | 【姓名】 | 【意见】 | 【日期】 |
| 业务负责人 | 【姓名】 | 【意见】 | 【日期】 |
| 财务负责人 | 【姓名】 | 【意见】 | 【日期】 |
| 技术负责人 | 【姓名】 | 【意见】 | 【日期】 |
| 最终审批人 | 【姓名】 | 【意见】 | 【日期】 |
章节与关键字段说明：每个字段支撑哪类启动决策
立项报告的每个章节都对应一类判断，填写时先想清楚这一章要让审批方决定什么，再决定写多细。字段写得全不等于写得好，能支撑对应判断的字段才有价值。
| 章节 | 填写目的 | 关键字段 | 支撑的启动决策 |
|---|---|---|---|
| 项目概况 | 让审批方快速识别项目身份与责任人 | 项目名称、发起人、项目经理、项目类型、一句话说明 | 做不做：这个项目是什么、由谁负责 |
| 目标与范围 | 把模糊需求转成可判定的目标与边界 | 项目目标、成功标准、范围包含与不包含、干系人 | 做到什么程度：交付到什么状态算完成 |
| 价值与可行性 | 说明投入的理由与实现路径是否成立 | 业务价值、测算依据、方案概述、备选方案、可行性判断 | 做不做：值不值得投入，路径是否可行 |
| 交付与计划 | 说明成果形态与推进节奏 | 主要交付物、里程碑、关键依赖、验收方式 | 怎么交付：分几步、依赖谁、如何验收 |
| 资源与预算 | 量化投入规模与来源 | 人力投入、费用预算、其他资源、资源来源 | 投入多少：需要多少人、多少钱、从哪里来 |
| 风险与假设 | 暴露不确定性与前置条件 | 主要风险、关键假设、待决事项 | 风险是否可接受：最坏情况能否承受 |
| 审批结论 | 固化决策结果与附带条件 | 审批意见、审批条件、审批人及日期 | 做不做：正式结论及约束 |
支撑材料与字段存在对应关系：目标与成功标准通常由需求说明或业务数据支撑；价值测算需要数据报表或调研记录；可行性判断需要技术预研结论或供应商方案；预算需要报价单或人力测算表。立项报告正文只写结论与依据摘要，完整材料作为附件或在文档中引用，便于审批人按需查阅。
当立项报告在ONES中编写时，可利用ONES Wiki的页面模板库一键创建制式化文档，减少每次从零搭结构的工作；报告页面组可关联对应项目，使立项文档与项目任务互相对应，审批通过后的目标、里程碑也能在同一项目上下文中持续跟踪。
必填与选填字段划分
必填字段的判断标准是：缺少该字段，审批方无法做出启动决策，或项目启动后无法界定责任与验收。其余字段按项目复杂度选填。
| 类别 | 字段 | 理由或适用情形 |
|---|---|---|
| 必填 | 项目名称、发起人、项目经理 | 确定项目身份与责任主体，任何规模项目都不可缺 |
| 必填 | 项目目标、成功标准 | 没有可判定的目标，后续验收与复盘失去依据 |
| 必填 | 范围包含与不包含 | 范围边界是控制预期扩散的最低要求 |
| 必填 | 主要交付物、里程碑计划 | 支撑“怎么交付”的判断，也是后续进度跟踪的基线 |
| 必填 | 人力投入、费用预算 | 支撑“投入多少”的判断；无费用项目可填“无新增费用” |
| 必填 | 主要风险、审批意见 | 风险决定可接受性，审批意见是立项生效的标志 |
| 选填 | 项目编号、项目类型 | 组织有统一编码或多项目并行管理时建议填写 |
| 选填 | 价值测算依据、备选方案 | 投入较大或存在多条实现路径时填写，小额内部改进可简化 |
| 选填 | 关键依赖、验收方式 | 跨团队协作或交付物需正式验收时填写 |
| 选填 | 关键假设、待决事项 | 存在明显前置条件或需审批方拍板的问题时填写 |
| 选填 | 抄送范围、其他资源 | 按组织审批习惯与资源类型决定 |
裁剪时可参考三条原则。小型内部改进项目可压缩价值测算与备选方案，保留目标、范围、里程碑、预算与风险；跨部门或对外交付项目应补全关键依赖、验收方式与干系人；投入超过组织设定阈值的项目，建议完整填写全部章节并附支撑材料。裁剪的结果应在报告开头注明“本报告适用简化模板”，让审批方知道哪些内容被有意省略。
填写示例：一份完整的立项报告
以下示例为演示情景，展示各必填字段的具体写法，组织可按自身口径替换内容。
项目概况
项目名称：客户合同审批线上化；发起人：运营部张明；项目经理：运营部李华；项目类型：流程优化；一句话说明：将纸质合同审批改为线上流转，缩短合同平均审批周期。
目标与范围
项目目标：合同审批平均周期从10个工作日缩短至5个工作日以内。成功标准：上线后连续两个月统计，平均审批周期不超过5个工作日，统计口径为合同提交至审批完成的自然日。范围包含：合同模板配置、三级审批流、审批记录查询。范围不包含：合同电子签章、与财务系统的付款对接。主要干系人：销售部关注审批速度，法务部关注条款合规，财务部关注付款衔接。
价值与可行性
业务价值：按去年合同量测算，审批周期缩短可减少因等待造成的签约延迟。测算依据：去年合同台账与审批耗时记录。方案概述：采用现有办公平台的工作流能力配置审批流。可行性判断：技术路径成熟，运营部可投入人力，法务部已确认审批节点设置。
交付与计划
主要交付物：线上审批流配置、操作手册、上线验收报告。里程碑：需求确认（第2周）、流程配置完成（第5周）、试运行（第7周）、正式上线（第8周）。关键依赖：法务部确认审批节点，IT部门开通权限。验收方式：运营部与法务部联合验收，以试运行期间审批记录为准。
资源与预算
人力投入：运营部2人各投入50%，IT部门1人投入20%，周期8周。费用预算：无新增采购费用，使用现有平台能力。资源来源：内部调配。
风险与假设
主要风险：法务审批节点确认延迟，影响配置进度，应对措施为第1周内完成节点确认会，责任人为李华。关键假设：现有平台工作流能力满足三级审批需求。待决事项：试运行范围是否覆盖全部合同类型。
审批结论
审批意见：同意立项，试运行阶段先覆盖标准合同类型。审批人：运营总监王强，日期：示例日期。抄送：法务部、财务部、IT部门。
模板的调整与维护方法
模板需要随组织项目类型和审批要求变化而调整，建议指定一名模板维护人，通常由项目管理办公室或运营管理岗承担，负责字段口径与版本管理。
- 按项目类型增减章节：研发类项目可增加技术方案与测试计划章节；市场活动类项目可强化预算与效果评估字段；合规类项目可增加监管要求对照表。增减时保持“目标—范围—交付—投入—风险—审批”的主干不变。
- 统一字段口径：成功标准、预算科目、风险等级等字段应有书面定义，避免不同项目各写各的。口径变更由维护人发起，经审批流程相关负责人确认后生效。
- 版本更新：每次调整记录版本号、变更内容与生效日期，旧版本保留可查，避免历史报告无法对照。
- 历史报告归档：立项报告按项目编号归档，与结项材料放在同一项目文档下，便于复盘时对照立项承诺与实际结果。
在ONES中维护这套模板时，可将定稿模板放入ONES Wiki页面模板库，新项目一键创建同结构文档；文档实时同步并记录页面版本，模板调整后可随时查看与回滚历史版本；通过为发起人、审批人、干系人配置不同读写权限，让报告在审批前保持受控、审批后对相关角色开放查阅。
常见问题
立项报告写到什么详细程度才算够用？
以审批方能否据此做出判断为准。目标、范围、里程碑、预算和风险这几项要写到可核对的程度，例如成功标准带指标口径和统计周期，里程碑带完成时间与交付标志。价值测算和备选方案在投入较大或存在多条路径时展开，小额内部改进可只写结论与简要依据。
项目还没有确定预算和人力，立项报告可以先提交吗？
可以提交，但应把未定部分写成待决事项，并说明需要谁在什么时间点给出结论。预算栏可先填估算区间与测算依据，注明“待财务确认”；人力栏写清角色与投入比例的需求。这样审批方看到的是明确的待决问题，而非空白字段。
支撑材料应该附在报告里还是单独归档？
正文只保留结论和依据摘要，完整材料作为附件或在文档中引用。需求说明、数据报表、技术预研结论、报价单等按字段对应挂接，审批人可按需查阅。归档时与立项报告放在同一项目文档下，便于结项复盘时对照立项承诺与实际结果。
同一组织内不同项目类型能否共用一份模板？
可以共用主干，按类型增减章节。研发类项目增加技术方案与测试计划，市场活动类强化预算与效果评估，合规类增加监管要求对照。增减时保持“目标—范围—交付—投入—风险—审批”的主干不变，并在报告开头注明所用模板版本，避免审批方误读被省略的内容。
立项报告在ONES中如何承载和归档？
ONES Wiki提供页面模板库，可一键创建制式化文档，减少每次从零搭结构的工作；页面组可关联项目，使立项文档与项目任务互相对应。文档实时同步并记录页面版本，支持查看与回滚；还可为发起人、审批人、干系人配置不同读写权限，让报告在审批前保持受控、审批后对相关角色开放查阅。
