项目立项书用于支撑“是否启动”的决策，把为什么做、做什么、做到什么程度、怎么算成功、需要什么投入、谁批准谁负责写成可评审、可追踪的书面依据。编写时先明确要回答的决策问题，再按背景、目标、范围、方案、资源、风险、职责、验收逐项落笔，最后经过相关方评审并留下决议记录。本文按编写顺序给出字段要点、角色分工、示例片段和提交前检查清单。
要点总览（TL;DR）
- 立项书服务于单项目“是否启动”的决策，需要回答为什么做、做什么、做到什么程度、怎么算成功、需要什么投入、谁批准谁负责六个问题。
- 编写顺序建议从证据到判断再到承诺：先收集背景与问题证据，再定义目标与成功标准，随后划定范围、给出方案与里程碑、估算资源预算、识别风险假设，最后提交评审并记录决议。
- 目标要写成可验证的结果，成功标准需包含指标、基线、数据来源和测量时点；范围部分要同时写明做什么和暂不纳入什么。
- 立项书由发起人确认目标与资源意愿，编写人组织成文并维护版本，业务、财务、技术等职能提供输入，评审审批角色按授权层级给出结论。
- 提交评审前逐项核对目标可度量、范围边界清楚、估算有依据、风险假设有责任人、审批路径明确、版本可追溯，并确认未参与编写的评审者能独立读懂六个决策问题。
立项书先回答哪几个决策问题
立项书服务于启动与否的判断，内容深度以“能否据此做出决策”为准。它需要说明项目值得做、目标可实现、投入可承受、风险可管理，无需展开到任务分解、详细排期和完整项目计划，这些属于立项通过后的计划编制工作。
一份可评审的立项书通常回答六个问题，每个问题对应一组内容。动笔前先把这组对应关系列出来，可以避免写到一半才发现关键信息缺失。
| 决策问题 | 对应内容 | 评审者关心的点 |
|---|---|---|
| 为什么做 | 背景与问题、现状数据、不做的后果 | 问题是否真实、紧迫，是否有证据支撑 |
| 做什么 | 项目目标、范围与交付物 | 目标与问题是否对应，边界是否清楚 |
| 做到什么程度 | 成功标准、验收口径、退出条件 | 指标是否可测量，基线是否明确 |
| 怎么算成功 | 衡量指标、测量方式、测量时点 | 结果能否在项目结束后被验证 |
| 需要什么投入 | 人力、预算、时间、关键依赖 | 估算是否有依据，投入与收益是否匹配 |
| 谁批准谁负责 | 发起人、项目经理、评审与审批角色 | 授权是否到位，责任是否落到人 |
这六个问题构成立项书的内容骨架。后续章节的编写步骤和字段要点，都是围绕把这张表填实、填准展开的。
按步骤编写立项书：从背景到审批
立项书适合按“先证据、后判断、再承诺”的顺序编写：先把问题和目标写清楚，再谈方案和投入，最后进入评审。每一步都有明确的输入、动作、输出和完成标志，完成标志达到即可进入下一步，不必等所有材料齐备再动笔。
第一步：收集背景与问题证据
输入是业务诉求、现状数据和相关方访谈记录。动作是把“感觉有问题”转成可陈述的事实，例如当前处理时长、差错率、客户投诉量、合规缺口。输出是一段问题陈述，包含现状、影响范围和不解决的后果。完成标志是：问题陈述中的关键数字都有出处，且至少一位业务相关方确认描述准确。
第二步：定义目标与成功标准
输入是第一步的问题陈述。动作是把问题转化为期望结果，并为每个结果设定指标、基线和测量方式。输出是目标清单和成功标准表。完成标志是：每条目标都能回答“项目结束后用什么数据证明达成了”，且基线值来自现有记录而非估计。
第三步：划定范围与交付物
输入是目标清单。动作是列出项目要产出的交付物，同时明确写出暂不纳入的事项。输出是范围说明和交付物清单。完成标志是：任一交付物都能对应到至少一条目标，且“不做什么”部分经过发起人确认。
第四步：给出初步方案、里程碑与关键依赖
输入是范围与交付物。动作是描述实现路径的主要阶段、各阶段里程碑和外部依赖，例如供应商交付、系统接口、审批窗口。输出是方案概述和里程碑表。完成标志是：每个里程碑有可检查的产出物，关键依赖标明了责任方和需要的时间点。
第五步：估算资源、预算与时间
输入是方案与里程碑。动作是按角色估算人力投入，按科目估算费用，并说明估算依据，例如历史项目数据、供应商报价、工时测算。输出是资源与预算表。完成标志是：每项估算都能指出依据来源，主要假设已写明。
第六步：识别风险、假设与应对
输入是前五步形成的全部内容。动作是列出可能影响目标达成的风险与前提假设，评估发生概率和影响程度，指定应对措施和责任人。输出是风险与假设清单。完成标志是：高影响风险均有应对方案和责任人，关键假设有验证方式。
第七步：提交评审并记录决议
输入是完整的立项书草稿。动作是确认评审参与人、提前分发材料、组织评审会，并记录评审意见、修改情况和最终决议。输出是评审记录与决议。完成标志是：审批角色给出明确结论（批准、有条件批准、退回修改或不批准），决议与修改意见归档在案。
立项书各字段怎么写：要点与常见写法
知道写哪些部分之后，真正困难的是每一栏怎么落笔。下面按主要字段给出填写要点和正反例，正例取自常见项目场景，反例是评审中经常被退回的写法。
| 字段 | 填写要点 | 推荐写法 | 应避免的写法 |
|---|---|---|---|
| 背景与问题 | 用现状事实和影响说明必要性 | “当前订单人工录入平均每单8分钟，月均差错37单，客户投诉中录入错误占21%” | “随着业务快速发展，现有方式已无法满足需求” |
| 目标 | 结果导向、可验证，避免把动作当目标 | “订单录入差错率从2.1%降至0.5%以下” | “建设订单录入系统，提升录入效率” |
| 范围 | 边界清晰，列出暂不纳入的事项 | “本期覆盖华东区订单录入；暂不纳入退货流程和海外订单” | “覆盖订单相关全部业务” |
| 成功标准与验收口径 | 写明指标、基线、测量方式和测量时点 | “上线后第3个月统计差错率，数据取自订单系统差错台账，基线为2024年季度均值2.1%” | “系统稳定运行，用户满意” |
| 资源与预算 | 人力、费用、时间分别估算并说明依据 | “开发2人×3个月，测试1人×1.5个月；费用含外购接口授权12万元，依据供应商报价单” | “预计投入若干人力和相应预算” |
| 风险与假设 | 写概率影响、应对措施和责任人 | “假设现有订单接口在项目期内不变更；若变更，由接口负责人评估影响并顺延里程碑” | “存在一定风险，需加强沟通” |
几个字段容易写偏，需要单独说明。目标字段常见的问题是把手段当结果，例如“完成系统选型”“开展三轮培训”都是动作，评审者无法据此判断项目是否成功，应改写为动作带来的可观察变化。范围字段常见的问题是只写做什么、不写不做什么，导致评审时各方对边界的理解不一致，后续容易产生范围争议。成功标准字段要落到测量方式上，指标、基线、数据来源、测量时点四要素齐全，验收时才有据可依。
资源与预算部分，估算依据比数字本身更重要。评审者往往无法判断“30万元”是否合理，但可以判断“依据两家供应商报价和内部工时测算得出”是否可信。风险部分则要避免只列风险不给应对，每条高影响风险都应写明触发条件、应对动作和责任人。
谁写、谁审、谁批：角色与交付物分工
立项书由发起人提出、编写人组织成文、多方提供输入、评审角色给出结论，写成一个人的文档往往在评审时暴露信息缺口。明确分工可以让每个角色知道自己要交什么、什么时候交。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 发起人 | 提出业务诉求，确认目标与资源投入意愿，对项目必要性负责 | 问题陈述初稿、目标确认意见、资源承诺 |
| 项目经理或编写人 | 组织内容编写，汇总各方估算，维护文档版本与修改记录 | 立项书正文、版本记录、评审材料 |
| 业务职能 | 提供现状数据、业务流程说明和使用方需求 | 现状数据、需求说明、业务确认意见 |
| 财务职能 | 审核预算科目、费用依据和合规要求 | 预算审核意见 |
| 技术或相关专业职能 | 评估方案可行性、依赖条件和实施风险 | 方案可行性意见、技术风险说明 |
| 评审与审批角色 | 按组织授权层级评审材料并给出结论 | 评审意见、审批决议 |
审批路径按组织授权确定，金额、影响范围、跨部门程度不同，审批层级也可能不同，编写前应先确认本次立项适用哪一级审批。评审记录与决议是立项书的配套交付物，需要与正文一并归档：正文说明项目要做什么，决议说明组织是否同意做、附带了哪些条件。有条件批准时，条件内容应逐条写入决议，作为后续跟踪的依据。
编写过程涉及多人提供数据和意见，文档版本容易混乱。可以在共享文档中维护唯一正文，各角色在对应章节提交内容或批注，编写人统一合并并记录修改；评审意见与决议作为附件或独立记录与正文关联保存，确保后续能追溯“谁在什么时间基于哪一版材料做出了什么结论”。ONES 的文档与工作项能力可以承载这类协作：立项书在文档中协同编写并保留版本，评审意见和决议作为记录关联到对应项目工作项，便于后续跟踪有条件批准事项的落实情况。
一份立项书示例：从问题到审批结论
以下示例为演示情景，用于说明关键部分的写法，实际编写时应替换为真实数据和本组织的审批口径。
背景与问题陈述
客服工单目前通过邮件分派，平均首次响应时间4.2小时，超时工单占18%，季度客户满意度调查中“响应速度”一项得分连续两个季度下降。工单在多个邮箱之间转派时存在遗漏，上季度有6单超过48小时无人处理。业务部门提出希望缩短响应时间并减少遗漏。
目标与成功标准
目标一：首次响应时间从4.2小时降至1.5小时以内。目标二：超时工单占比从18%降至5%以下。成功标准：上线后第2个月起，以工单系统统计报表为准，连续两个月达到上述指标；基线取立项前一个季度的系统统计均值。测量方式与数据来源在验收条款中写明。
范围、里程碑与资源估算
本期范围覆盖客服一线工单的接收、分派和响应计时；暂不纳入二线技术支持流程、知识库建设和海外站点。里程碑包括：需求确认与流程设计（第4周）、系统配置与试运行（第10周）、全量上线（第14周）、指标复核（上线后第2个月）。资源估算：流程与配置2人×3个月，培训1人×0.5个月；费用含系统订阅与短信通知，依据供应商报价单测算。
风险与应对
主要风险是客服人员对新分派规则不适应，导致试运行期响应时间短期上升。应对措施为分批次培训并在试运行期保留人工兜底分派，责任人为客服主管。关键假设是现有工单数据可导出用于基线统计，若数据字段缺失，由编写人在第2周前确认替代口径。
评审意见与决议记录
评审意见：财务确认预算科目无误；业务方要求补充海外站点的后续规划说明；评审组建议将指标复核时点提前到上线后第6周。决议：有条件批准，条件为补充海外站点规划说明并在两周内提交，指标复核时点按评审意见调整。决议记录与修改后的立项书一并归档，有条件事项列入后续跟踪。
提交前检查：立项书完成的标准
立项书是否可以进入评审，可以用一份清单逐项核对。全部条目满足即可提交；存在未满足项时，先补齐再送审，比在评审会上被退回更节省各方时间。
- 目标与成功标准可度量、有基线：每条目标都有指标、基线值、数据来源和测量时点，基线来自现有记录。
- 范围边界写明：交付物清单完整，暂不纳入的事项已列出并经发起人确认。
- 资源与预算有估算依据：人力、费用、时间分别说明来源，主要假设已注明。
- 风险、假设与责任人完整：高影响风险有应对措施和责任人，关键假设有验证方式。
- 评审角色与审批路径明确：评审参与人、审批层级和决议形式已按组织授权确认。
- 版本与变更记录可追溯：正文为唯一版本，修改记录完整，评审材料与决议和对应版本关联。
清单之外还有一项整体判断：把立项书交给一位未参与编写的评审者阅读，他能否在不追问的情况下回答那六个决策问题。如果能，文档基本达到可评审状态；如果仍需口头补充关键信息，说明相应字段还需要写实。
常见问题
立项书和项目计划有什么区别，编写时如何把握详略？
立项书回答的是“要不要做、值不值得投入”，内容以支撑启动决策为准；项目计划回答的是“具体怎么做、谁在什么时候完成什么”，包含任务分解、详细排期和资源分配。编写立项书时，方案部分写到主要阶段、里程碑和关键依赖即可，不必展开到任务级排期。立项通过后，再以立项书确定的目标、范围和资源为输入编制详细计划。
目标暂时无法量化时，立项书该怎么写成功标准？
先区分两种情况。如果指标本身可以量化，只是基线数据尚未收集，应在立项书中写明基线收集方式和完成时间，并把基线确认作为评审条件之一。如果目标确实偏定性，例如流程规范化程度，可以设定可观察的替代标准，例如关键流程节点的文档覆盖率、评审通过率或抽查合格率，并写明测量方式和测量时点。避免只写“明显改善”“用户满意”这类无法验证的表述。
评审时有条件批准，立项书需要怎么处理？
有条件批准意味着项目可以启动，但附带需要落实的条件。处理方式是把条件逐条写入决议记录，明确每条条件的责任人和完成时间，并将决议与对应版本的立项书一并归档。条件涉及立项书内容修改的，应更新正文并保留修改记录，注明修改依据来自哪次评审。后续跟踪时以决议中的条件清单为检查依据，条件全部落实后再进入常规执行阶段。
立项书编写过程中多方提供内容，版本混乱怎么避免？
可以约定一份共享文档作为唯一正文，各角色在对应章节提交内容或批注，由编写人统一合并，并在文档中保留修改记录。评审材料从该版本导出，评审意见和决议作为独立记录与正文关联保存。这样在追溯时可以回答“谁在什么时间基于哪一版材料提出了什么意见、形成了什么结论”。ONES 的文档与工作项能力可以承载这类协作：立项书在文档中协同编写并保留版本，评审意见和决议关联到对应项目工作项，便于跟踪有条件批准事项。
多个项目同时申报时，立项书能用来做优先级比较吗？
立项书本身聚焦单个项目的启动依据，可以说明本项目的问题、目标、投入和风险，但多个项目之间的准入比较、优先级排序和资源分配属于项目提案与准入管理的范畴。实际操作中，可以在单项目立项书之外增加一份组合层面的比较材料，统一各项目的评估口径，例如收益类型、投入规模、战略匹配度和风险等级，再据此排序。本文的编写方法适用于单项目立项书部分。
