项目立项书模板：空白表格与填写规范

项目立项书可以用一张结构化表格承载，适用于单个项目的启动评审：先写清项目基本信息与立项依据，再明确目标与范围、交付物与里程碑、资源与预算、风险与假设，最后落到审批结论。本文提供一份可直接复制填写的空白模板，并逐字段说明填写口径、区分必填与选填，附一份完整填写示例，方便团队按项目类型调整后长期使用。

要点总览（TL;DR）

• 模板按七个区块组织：项目基本信息、立项依据与问题描述、目标与范围、交付物与里程碑、资源与预算、风险与假设、审批结论，复制后清空填写列即可使用。
• 必填字段覆盖项目对象、责任主体、立项依据、目标与范围、交付物与里程碑、人员与预算、主要风险及审批结论；项目编号、关键依赖、外部采购、前提假设等按项目复杂度选填。
• 填写时让未参与前期讨论的评审人读完表格能判断项目该不该做、能不能做成：目标带可观察结果，里程碑带可检查的完成标志，风险每条配应对和责任人。
• 必填项暂时无法确定时写明“待定”并注明补齐时间与责任人；选填项留空即可，不写“无”。
• 模板按项目类型增减字段，同步更新字段说明与必填选填分级，标注版本号和变更记录，并把评审中反复追问的信息按月回流到下一次调整。

可复制的项目立项书空白模板

下表覆盖单项目启动所需的核心信息，可直接复制到文档或表格工具中填写。表格按七个区块排列，填写顺序建议从上到下：先交代项目是什么、为什么做，再写做到什么程度、怎么交付、需要什么投入、有哪些不确定因素，最后由审批人给出结论。

区块	字段	填写内容
一、项目基本信息	项目名称
	项目编号
	项目负责人
	发起部门 / 发起人
	拟启动日期 / 计划完成日期
	项目类型
二、立项依据与问题描述	业务背景
	待解决的问题
	立项依据（数据、政策、客户需求等）
三、目标与范围	项目目标
	成功标准
	范围内事项
	范围外事项
四、交付物与里程碑	主要交付物
	里程碑计划
	关键依赖
	验收方式
五、资源与预算	人员投入
	预算构成
	外部采购 / 合作
	资源缺口
六、风险与假设	主要风险及应对
	前提假设
	约束条件
七、审批结论	评审意见
	结论（批准 / 有条件批准 / 退回补充）
	审批人 / 审批日期
	后续动作与责任人

复制时保留区块标题和字段名，清空“填写内容”列即可作为空白模板使用。如果团队使用在线文档或表格工具，可以把这张表作为一个固定页面，每次立项复制一份新副本填写，避免多人同时改同一份文件。

每个字段填什么：立项书字段说明

字段说明与上表逐项对应。填写时把握一个原则：让没有参与前期讨论的评审人读完表格，能判断这个项目该不该做、能不能做成。

基本信息字段

项目名称用一句话说清做什么，避免“系统优化项目”这类无法区分对象的写法。项目编号按团队既有编码规则填写，便于后续检索和归档。项目负责人填实际对结果负责的人，发起部门填需求或资源的主要来源。起止日期写计划值，评审通过后如有调整再更新。项目类型用于区分新建、改造、合规等类别，影响后续字段的取舍。

目标与范围字段的写法

项目目标写项目结束时希望达到的状态，尽量带可观察的结果，例如“完成某业务流程线上化，覆盖三个业务环节”。成功标准是判断目标是否达成的依据，写清指标名称、口径和时间点。范围内事项列出本项目负责的工作，范围外事项明确写出不做哪些相关内容，这一栏能减少执行阶段的争议。目标与范围两栏要相互对应，目标里提到的事情应在范围内有落点。

里程碑与交付物字段的颗粒度

交付物写项目结束时需要交出的成果，如文档、系统功能、培训材料，每项注明验收责任人。里程碑按阶段划分，每个里程碑写清时间点和可检查的完成标志，颗粒度控制在评审人能判断“到没到”的程度，通常一个项目三到六个里程碑即可。关键依赖写外部团队、供应商或前置项目，验收方式写谁在什么场合确认交付物合格。

资源预算字段的口径

人员投入写角色和投入比例或人天，不写具体姓名时注明由哪个团队派出。预算构成按科目列出金额和计算依据，注明是年度预算内还是额外申请。外部采购写清采购内容和预计金额区间。资源缺口如实写出当前尚未落实的人员或预算，这一栏直接影响审批结论，不宜留空或写“无”。

风险与假设字段的写法

风险写可能影响目标达成的事件，每条配一个应对动作和责任人，按影响程度排序，列三到五条主要风险即可。前提假设写立项成立所依赖的条件，例如“某系统接口按期开放”“预算在季度内批复”。约束条件写不可协商的限制，如上线时间窗口、合规要求。假设和约束要具体到可验证，避免写成泛泛的“存在不确定性”。

审批结论字段的作用

审批结论是立项书的闭环。评审意见记录评审会上提出的主要问题，结论从批准、有条件批准、退回补充中选一项，有条件批准需写明条件内容。审批人和日期保证责任可追溯。后续动作与责任人把评审会上确定的补充材料、方案细化等事项落到人和时间，避免结论停留在口头。

必填与选填：立项书字段分级

必填字段决定项目能否进入评审，缺项时评审无法形成有效判断；选填字段按项目复杂度和类型补充。下表给出分级建议，团队可在此基础上调整。

字段	级别	理由与适用情形
项目名称、项目负责人、发起部门、拟启动与完成日期	必填	缺少任何一项，评审无法确认项目对象和责任主体
业务背景、待解决问题、立项依据	必填	立项是否成立的核心判断材料
项目目标、成功标准、范围内与范围外事项	必填	决定项目边界，缺失会导致执行阶段反复确认
主要交付物、里程碑计划	必填	评审人据此判断可行性和时间安排
人员投入、预算构成	必填	资源是审批的关键依据，金额可写区间
主要风险及应对	必填	至少列出一条主要风险，体现对不确定性的评估
审批结论、审批人、审批日期	必填	立项生效的凭证
项目编号	选填	有编码规则的团队必填，小团队可评审后补
项目类型	选填	项目类型单一时可省略
关键依赖、验收方式	选填	涉及外部团队或跨部门交付时补充
外部采购 / 合作	选填	无外部采购时填“无”或省略
资源缺口	选填	资源已全部落实时可省略
前提假设、约束条件	选填	复杂项目或存在硬性限制时补充
评审意见、后续动作与责任人	选填	有条件批准或退回补充时必填

小项目与复杂项目的字段取舍

投入小、周期短、单团队完成的项目，可保留全部必填字段，选填字段只填关键依赖和验收方式，表格控制在一页内。跨部门、有外部采购或合规要求的项目，应补齐外部采购、资源缺口、前提假设和约束条件，并把里程碑拆得更细。取舍的依据是评审人是否需要该信息才能做判断，与项目金额大小无直接关系。

缺项时的处理方式

必填字段暂时无法确定的，在栏内写明“待定”并注明补齐时间和责任人，随立项材料一起提交，由评审人决定是否接受。评审前发现必填项缺失的，退回填写人补充，不进入评审议程。选填字段留空即可，不需要写“无”，以免与“已评估但无内容”混淆。

填写示例：一份完整的立项书

以下示例为演示情景，用于展示各字段的实际写法，项目背景和数据均为虚构。

示例背景：某公司客户服务部门提出，现有工单依靠邮件流转，响应时长缺少统计，拟启动“客服工单线上化项目”，由服务运营组负责，计划三个月完成。

区块	字段	示例填写内容
一、项目基本信息	项目名称	客服工单线上化项目
	项目编号	PRJ-2025-018
	项目负责人	服务运营组 张明
	发起部门 / 发起人	客户服务部 / 李华
	拟启动日期 / 计划完成日期	2025年4月1日 / 2025年6月30日
	项目类型	流程改造
二、立项依据与问题描述	业务背景	客服工单目前通过邮件流转，平均响应时长缺少统计，跨班次交接易遗漏
	待解决的问题	工单状态不透明、响应时长无法统计、交接遗漏
	立项依据	近三个月客户投诉中，约两成与响应不及时相关；部门年度计划包含服务流程线上化
三、目标与范围	项目目标	实现工单从受理到关闭的全流程线上流转，覆盖咨询、投诉、售后三类工单
	成功标准	上线后第二个月起，工单平均首次响应时长可统计，交接遗漏工单数为零
	范围内事项	工单表单设计、流转规则配置、历史工单迁移、客服人员培训
	范围外事项	不涉及呼叫中心电话系统改造，不接入外部客户自助门户
四、交付物与里程碑	主要交付物	线上工单流程一套、操作手册一份、培训记录一份
	里程碑计划	4月底完成表单与规则设计评审；5月底完成配置与试运行；6月底完成全员培训并正式上线
	关键依赖	依赖IT组提供账号与权限支持；依赖历史工单数据整理完成
	验收方式	由客户服务部负责人按成功标准验收，试运行两周后确认
五、资源与预算	人员投入	服务运营组2人各投入50%；IT组1人投入20%
	预算构成	工具订阅费按现有合同额度内使用；培训材料印制约2000元
	外部采购 / 合作	无
	资源缺口	历史工单整理需要临时支持1人，待部门内协调
六、风险与假设	主要风险及应对	客服人员对新流程接受度低：安排分班次培训并设两周答疑期，责任人张明；历史数据质量差：先抽样清洗再迁移，责任人IT组王强
	前提假设	现有工具合同额度可覆盖本项目用量；试运行期间业务量无明显波动
	约束条件	正式上线需避开季度结算周
七、审批结论	评审意见	目标与范围清晰；需补充历史工单迁移的数据量估算
	结论	有条件批准：补充数据量估算后启动
	审批人 / 审批日期	运营总监 陈静 / 2025年3月25日
	后续动作与责任人	3月28日前提交数据量估算，责任人张明

示例中目标写成可观察的状态，成功标准带统计口径和时间点；里程碑每个都带可检查的完成标志；风险每条配应对和责任人；审批结论给出条件并落到具体人和日期。填写自己的立项书时，可以对照这几处检查写法是否到位。

立项书填写完成后，评审流转往往涉及文档版本、审批记录和后续任务分派。在ONES中，立项书可以作为项目内的文档承载，评审意见和审批结论随文档留痕，评审通过后的补充事项可直接转为工作项指派给责任人，让立项结论与后续执行衔接在同一处。团队规模较小、评审流程简单时，用文档工具完成这一流程同样可行。

模板的调整与维护方法

模板的价值在于长期可用。调整时围绕字段增减、口径统一、版本记录和反馈回流四件事展开，每次改动都留下依据。

按项目类型增减字段

先统计过去半年立项书的实际使用情况，找出经常留空或经常被评审追问的字段。经常留空的选填字段可以删除或合并；经常被追问的信息应升为必填。研发类项目可增加技术方案链接字段，采购类项目可增加供应商比选字段，合规类项目可增加监管依据字段。增减字段时同步更新字段说明和必填选填分级，保持三处一致。

字段命名与口径统一

字段名使用团队日常说法，同一含义只保留一种叫法，例如统一用“项目负责人”而非混用“项目经理”。金额、日期、人天等字段注明格式，如“金额单位：元”“日期格式：YYYY年M月D日”。口径统一后，跨项目的立项书才能被快速比较和汇总。

模板版本与变更记录

模板文件标注版本号和生效日期，每次修改在变更记录中写明改了哪个字段、为什么改、由谁提出。旧版本立项书保持原样归档，不追溯修改，新项目一律使用当前版本。版本记录放在模板文件首页或单独的维护页，评审人填写前能确认用的是最新版。

评审反馈回流到模板的方式

每次评审结束后，记录评审人反复追问的信息和填写人反复解释的口径，按月汇总一次。汇总结果作为下一次模板调整的输入，调整后在新项目的评审中观察效果。反馈回流形成固定节奏后，模板会逐步贴合团队的实际决策需要，而不是停留在最初设计的样子。

常见问题

项目立项书和项目提案有什么区别，什么时候用哪一个？

项目立项书针对单个项目，回答“这个项目要不要启动、怎么启动”，内容围绕目标、范围、交付物、资源、风险和审批结论展开。项目提案通常用于多个项目之间的比较和准入排序，需要横向对比收益、成本和优先级。本文模板只覆盖单项目启动评审；如果团队要在几个候选项目之间做取舍，应使用项目提案与准入管理的材料，立项书在项目获准后再填写。

小团队没有正式评审会，立项书还需要填审批结论吗？

需要保留结论字段，但形式可以简化。审批结论的作用是留下“谁在什么时候同意启动”的记录，避免项目做到一半无人认账。小团队可以由项目负责人和一位业务负责人共同确认，在结论栏写明批准意见、确认人和日期即可，不必组织正式评审会。若项目后续需要申请预算或跨部门资源，这份记录会成为依据。

立项书里的目标写成了“提升效率”，评审时被退回，应该怎么改？

把目标改写成项目结束时可以观察到的状态，并补上判断依据。例如把“提升客服效率”改为“实现工单从受理到关闭的全流程线上流转，覆盖咨询、投诉、售后三类工单”，成功标准再写清指标名称、统计口径和时间点，如“上线后第二个月起，工单平均首次响应时长可统计”。目标与成功标准两栏要相互对应，目标里提到的事情应在范围内有落点。

立项书批准后项目范围发生变化，需要重新走立项吗？

取决于变化是否触及审批时的关键假设。范围小幅调整、里程碑顺延几天，通常在项目内更新立项书并知会审批人即可。若目标、预算、主要交付物或上线时间窗口发生实质变化，原审批结论的依据已经不成立，应补充变更说明重新提交审批。建议在模板维护时约定一条变更触发条件，写清哪些变化需要重新评审，减少执行阶段的判断分歧。

用在线文档填写立项书，怎么避免多人同时修改同一份文件？

把空白模板作为一个固定页面保存，每次立项复制一份新副本填写，副本按项目命名并放在对应项目的位置，模板页只读。评审意见和审批结论在副本上留痕，评审通过后的补充事项转为任务指派给责任人。ONES Wiki 支持文档协同与页面组织，可以把模板页和项目立项文档放在同一知识库中管理；团队规模较小、流程简单时，用常规文档工具按同样方式操作也可行。