项目立项书怎么编写：结构、步骤与评审要点

项目立项书要回答的是“这个项目为什么现在启动、要达成什么、怎么做、需要什么投入、如何判断成功”。它服务于单个项目的启动决策，把目标、范围、方案、资源、计划、风险和验收标准写成可评审、可追踪的文本。本文按“先定决策问题—逐字段填写—明确角色分工—参考示例—提交前检查”的顺序展开，适合第一次负责编写立项书的人照着使用。

要点总览（TL;DR）

• 立项书服务于单项目是否启动的决策，核心是回答为什么做、做成什么样、怎么做、要什么投入、如何判断成功五类问题。
• 编写顺序建议为背景与问题、目标与成功标准、范围与不做事项、实施方案与里程碑、资源与预算、风险与假设、验收标准与退出条件，前后字段要能相互对应。
• 立项书由项目经理整合成文，发起人、业务负责人、技术负责人、财务或采购分别提供业务、需求、技术与成本输入，评审结论与批准版本需留档。
• 提交前重点核对目标与验收标准是否可度量、范围边界是否明确、估算是否有依据和责任人、风险是否都有应对措施、评审意见是否闭环。
• 批准后的目标与里程碑应转入日常跟踪，避免立项书停留在归档状态。

立项书先回答哪几个决策问题

立项书的核心用途是支撑一个具体项目“是否启动”的判断。它把发起方的意图转成评审者能核对的信息，让决策者在有限时间内看清收益、代价和风险。多个项目之间先做哪个、资源如何排序，属于项目组合层面的准入与优先级管理，不在立项书的职责范围内。编写前先分清这一点，可以避免把立项书写成战略汇报或资源争夺材料。

围绕单项目启动决策，立项书需要回答五类问题，由此推导出对应字段：

决策问题	对应字段	填写顺序
为什么做：现状有什么问题，触发原因是什么，不做的后果是什么	项目背景与问题描述	1
做成什么样：要达成什么结果，如何度量，何时达成	目标与成功标准	2
做到哪里、不做到哪里：边界在哪里	范围与不做事项	3
怎么做、要什么投入：分几个阶段、谁来做、花多少	实施方案与里程碑、资源与预算、风险与假设	4
如何判断成功：交付什么、达到什么条件算完成或终止	验收标准与退出条件	5

这个顺序有内在依赖：目标和范围来自背景中的问题定义，实施方案和资源估算来自目标与范围，验收标准则要回到目标逐条对应。先写背景和目标，再写方案和资源，最后写验收，能减少前后矛盾。实际编写时可以先搭出全部字段的骨架，再按顺序填充内容，避免在某一节反复返工。

逐字段编写：从背景到验收标准

每个字段都有明确的输入、写法和输出。输入是编写者需要收集的信息，写法是组织文字的方式，输出是评审者能直接核对的内容。下面按字段说明。

项目背景与问题描述

输入来自业务现状数据、用户反馈、事件记录或合规要求。写法上分三层：现状是什么、什么原因触发了现在启动、如果不动手会带来什么后果。后果要具体，例如“每月人工核对耗时约X人天”“客户投诉集中在某一环节”。输出应让不了解该业务的评审者也能理解问题规模和紧迫性。避免只写“为了提升效率”这类无法核对的表述。

目标与成功标准

目标写项目完成后要达成的结果状态，成功标准写判断是否达成的度量方式。每条目标应包含指标、基线、目标值和时间边界，例如“上线后三个月内，订单处理平均时长从当前水平降至约定值”。目标数量控制在三到五条，按重要性排序。无法量化的目标要说明验证方式，例如“通过某类评审或验收测试确认”。

范围与不做事项

范围写本项目覆盖的业务对象、流程环节、系统模块或地域范围。不做事项同样要写，列出容易被误认为包含在内的内容，例如“本期不含移动端适配”“不含历史数据迁移”。这一节是后续变更讨论的基准，写得越具体，范围蔓延时的争议越少。输出形式可以是“包含/不包含”两栏清单。

实施方案与里程碑

实施方案说明完成项目的总体路径：分几个阶段、每阶段的主要工作、关键交付物。里程碑是阶段完成的标志，每个里程碑对应一个交付物和一个时点。写法上避免把里程碑写成“完成开发”这类笼统表述，改为“完成某模块联调并通过测试，产出测试报告”。输出应能让评审者看出关键路径和阶段之间的依赖。

资源与预算

资源包括人力、费用和外部依赖。人力按角色和投入程度估算，说明估算依据，例如参照类似项目的工作量或按阶段拆解。费用列出主要科目和金额区间，注明估算口径。外部依赖写明供应商、合作方或审批事项，以及依赖未满足时的影响。每项估算应标注责任人或估算来源，便于评审时追问。

风险与假设

风险写可能影响目标达成的不确定事件，每条包含触发条件、影响程度、应对措施和责任人。假设写项目成立所依赖的前提，例如“某系统接口在启动前可用”。假设一旦不成立，应触发重新评估。风险清单不必追求穷尽，优先列出影响目标和进度的主要风险，并确保每条都有应对动作而非仅描述。

验收标准与退出条件

验收标准逐条对应目标，说明交付物达到什么状态算通过，由谁确认。退出条件说明在什么情况下项目应暂停或终止，例如关键假设被证伪、预算超支超过约定比例、阶段评审连续未通过。退出条件提前写清，可以在项目偏离时提供决策依据，避免沉没成本持续累积。

谁写、谁审、谁批：角色与交付物分工

立项书由项目经理整合成文，但内容来自多个角色，单人闭门完成容易遗漏业务、技术和成本视角。下表列出常见分工，具体角色名称可按组织实际设置调整。

角色	提供的输入	确认事项	交付物
发起人	业务背景、启动原因、预期收益	目标与成功标准是否符合业务意图	背景与目标初稿
项目经理	整体结构、计划与里程碑、风险清单	各字段完整、前后一致	立项书完整稿
业务负责人	需求范围、验收口径	范围与不做事项、验收标准	范围清单与验收条目
技术负责人	技术可行性、实施方案、技术风险	方案与里程碑的技术合理性	实施方案与风险条目
财务或采购	费用估算口径、采购与合同依赖	预算与外部依赖	预算表与依赖清单

评审会由发起人或其授权人组织，参与方至少覆盖上述提供输入的角色。评审结论要记录三类信息：通过、有条件通过、不通过；有条件通过需写明条件和完成时限；评审意见逐条对应修改责任人和关闭时间。批准后的版本应标注版本号和批准日期，作为项目基线。后续目标、范围或预算发生实质变化时，走变更记录，说明变更原因、影响和批准人，避免在原文件上直接覆盖。

立项书批准后，目标和里程碑需要进入日常跟踪，否则文本容易停留在归档状态。在ONES中，可以把批准后的目标、里程碑和评审结论承接为可跟踪的项目信息，让后续的计划执行与阶段评审围绕同一份基线展开；具体字段设置可按团队现有流程配置。

一份立项书的填写示例

以下为演示情景，用于说明字段如何落笔，不代表真实企业案例。情景设定：某制造企业的客服部门希望上线一套工单分类与流转规则，减少工单在部门间的反复转派。约束条件为：预算有限、需在当季度内完成试点、现有工单系统不做替换。

背景：当前工单按人工判断转派，近一个季度统计显示约三成工单经历过至少一次转派，平均处理周期偏长，客户催办集中在转派环节。若不调整，随着工单量增长，人工判断的负担会继续上升。

目标与成功标准：试点范围内，工单一次转派准确率达到约定目标；试点周期内平均处理时长较基线下降约定幅度；试点结束前完成规则评审。每条目标标注基线值和统计口径。

范围与不做事项：包含试点部门的工单分类规则、转派规则和配套操作说明；不包含工单系统替换、其他部门推广、历史工单回溯清洗。

里程碑：第一周完成现状数据核对与规则初稿；第三周完成规则配置与内部测试，产出测试记录；第六周试点上线；第十周完成试点复盘，产出复盘报告。

风险：规则覆盖不足导致误分类，应对措施是设置人工兜底并每周复核样本，责任人为业务负责人；试点部门配合度不足，应对措施是提前确认对接人并纳入周会，责任人为项目经理。

验收标准：试点范围内规则按约定运行，复盘报告经业务负责人和技术负责人确认；退出条件为试点期内误分类率持续高于约定上限且两轮调整无效。

这个示例体现的取舍是：在系统不替换的约束下，把项目限定在规则和流程层面，用试点范围控制风险。可迁移的写法规律是：每个字段都落到具体对象、数值口径或责任人；范围同时写清不做什么；风险写触发条件和应对动作。适用边界在于，涉及系统重建或跨部门大规模推广的项目，范围和里程碑需要更细的拆分。

提交前的完成检查

立项书提交评审前，按以下清单逐项核对。每项给出通过标准，便于编写者自查，也便于评审者快速判断。

检查项	通过标准
目标与验收标准可度量	每条目标有指标、基线、目标值和时间边界；验收标准逐条对应目标，并写明确认人
范围边界明确	包含事项与不做事项分别列出，评审者能判断哪些需求属于本期
资源与时间估算有依据	人力、费用和外部依赖标注估算口径与责任人，里程碑对应交付物和时点
风险有应对措施与负责人	每条主要风险包含触发条件、影响、应对动作和责任人；关键假设已列出
评审意见闭环	评审结论、修改责任人和关闭时间均有记录，批准版本标注版本号与日期

检查时优先处理前后矛盾：目标与验收标准是否一致，范围与里程碑是否匹配，预算与实施方案是否对得上。发现缺项时回到对应字段补充输入，而不是在评审会上口头说明。全部检查项通过后，立项书即可提交评审；批准后将其作为项目基线，后续变更按约定流程记录。

常见问题

立项书写完后，评审会上最常见的返工原因是什么？

最常见的是目标与验收标准对不上：目标写了要改善某个指标，验收标准却只写“系统上线”或“报告提交”。其次是范围只写包含什么、没写不包含什么，评审时各方对本期边界理解不一致。第三类是资源与里程碑缺少估算依据，评审者无法判断时间和人力是否合理。

减少返工的做法是在提交前先做一次内部对齐：目标逐条对应验收条目，范围用包含与不包含两栏列出，里程碑对应到具体交付物和时点，每项估算标注来源或责任人。

项目规模较小、周期很短，立项书可以简化吗？

可以按决策需要裁剪字段，但不宜省略目标、范围、验收标准和风险这四项。小项目的背景可以压缩为一两句话，实施方案可以合并到里程碑中，预算按主要科目简要列出即可。

裁剪的判断标准是评审者能否据此做出启动决定，以及项目执行中能否据此判断是否偏离。如果项目涉及外部合同、跨部门协作或合规要求，即使周期短，也建议保留完整的资源与依赖说明。

立项书批准后，目标和范围发生变化该怎么处理？

建议走变更记录，而不是在原文件上直接覆盖。变更记录至少写明变更内容、变更原因、对目标、进度和预算的影响，以及批准人。批准后的版本标注版本号和日期，作为新的项目基线。

如果变化涉及项目是否继续成立，例如关键假设被证伪或预算大幅超出，应回到立项时的退出条件进行判断，由原批准人或其授权人重新决策。

立项书和项目计划是什么关系，需要写两份吗？

两者回答的问题不同。立项书回答“这个项目是否值得启动、要达成什么、边界在哪里”，项目计划回答“具体怎么排期、谁在什么时间完成哪些任务”。立项书批准后，项目计划在目标和范围的基础上进一步细化。

实际操作中，立项书里的实施方案与里程碑可以作为项目计划的起点，但任务分解、排期和资源分配通常在计划阶段完成。立项书不必写到任务级，否则会拖慢启动决策。

没有历史数据时，目标和成功标准怎么写？

先写清度量口径和验证方式，再约定基线值的获取安排。例如目标可以写成“试点期内某指标较试点前基线下降约定幅度”，并在立项书中说明基线数据在启动后第几周完成采集、由谁确认。

对于确实难以量化的目标，写明验证方式，例如通过某类评审、验收测试或用户确认。关键是让评审者知道将来依据什么判断达成，避免用“明显改善”“大幅提升”这类无法核对的表述。