项目立项书要回答的核心问题可以归为七类：为什么做、做什么、做到什么程度、怎么做、谁来做、花多少、有什么风险。本文提供一份虚构但前后自洽的立项书填写示例，逐项说明背景、目标、范围、里程碑、资源预算、风险与审批字段的写法，并指出哪些结构可以保留、哪些内容必须按你的项目实际替换。
要点总览（TL;DR）
- 项目立项书围绕七类问题展开：为什么做、做什么、做到什么程度、怎么做、谁来做、花多少、有什么风险。
- 示例采用虚构的制造企业设备巡检系统项目，给出基本信息、背景、目标、范围、里程碑、资源预算、风险与审批的完整填写内容。
- 背景写可观察的现象，成功标准写对象、动作、时间与可检验结果，范围同时列出排除项，风险按“风险—影响—应对”三段式填写。
- 章节结构与表格字段可保留，背景、目标数值、范围排除项、预算金额和审批路径必须按本单位实际替换。
- 示例为虚构情景，涉及预算、合规与审批权限时以组织制度为准；多项目准入比较不在本文范围。
示例目标：这份立项书要回答哪些问题
这份示例的用途是给出一份“填完之后长什么样”的参照样本。读者可以对照它检查自己的立项书是否把关键问题说清楚了，也可以按字段顺序逐项改写。它面向单个项目的启动判断：这个项目值不值得做、准备怎么做、做完以什么为标准验收。多个项目之间如何比较、如何排序、资源如何在全公司范围内分配，属于项目组合管理的范畴，本文不展开。
需要先说明的是，示例中的公司、项目、人员、金额、日期均为虚构，用于演示字段之间的逻辑关系，不代表任何真实客户案例，也不附带实测效果或量化收益。阅读时建议分两步：先通读第二节的完整示例，形成整体印象；再对照第三节的逐项解释，理解每个字段为什么这样写。如果你只需要一份可填写的骨架，可以直接使用第二节的字段结构，把内容替换为自己的项目信息。
示例假设的场景是：一家虚构的中型制造企业，计划上线一套内部设备巡检管理系统，由信息化部门牵头，涉及生产、设备、安全三个部门。选择这个场景是因为它同时包含业务需求、跨部门协作、预算和风险，能够覆盖立项书的主要字段。你的项目类型不同，字段的详略可以调整，但七类核心问题应当都有对应回答。
完整示例：一份虚构项目的立项书全文
以下为示例立项书的填写内容。为便于对照，按立项书常见章节顺序排列，字段名称可根据组织模板调整。
一、项目基本信息
| 字段 | 填写内容 |
|---|---|
| 项目名称 | 设备巡检管理系统建设（示例） |
| 项目编号 | XX-2025-014（示例编号） |
| 项目发起人 | 信息化部负责人（示例角色） |
| 项目经理 | 信息化部系统建设岗（示例角色） |
| 立项日期 | 2025年3月（示例日期） |
| 预计周期 | 6个月 |
| 预算规模 | 人民币80万元（示例金额，含软件、实施与首年运维） |
二、项目背景与问题描述
公司三个生产车间目前使用纸质巡检表，巡检记录由班组填写后交设备部归档。现状存在三个具体问题：一是巡检漏项难以及时发现，设备部通常在月末汇总时才能看到缺检情况；二是故障记录与巡检记录分散在两套台账中，排查同类设备重复故障时需要人工比对；三是安全部门每季度检查时需要临时收集巡检证据，准备时间约需一周。上述问题在近两年设备数量增加后更加明显。
三、项目目标与成功标准
项目目标：建成覆盖三个生产车间的设备巡检管理系统，实现巡检任务线上派发、巡检记录移动端填报、缺检自动提醒，并与现有故障报修流程打通。
成功标准（示例口径，需按实际基线校准）：
- 上线后三个月内，三个车间的日常巡检记录线上填报率达到95%以上；
- 缺检情况在计划时间点后24小时内可被设备部看到；
- 安全部门季度检查所需的巡检证据可从系统中直接导出，准备时间缩短到一天以内；
- 系统上线后首个季度内，完成与现有报修流程的数据对接。
四、项目范围
范围内：巡检点与巡检项配置、移动端巡检填报、缺检提醒、巡检记录查询与导出、与现有报修系统的接口对接、三个车间相关岗位的使用培训。
范围外：设备采购与更换、设备状态实时监控与传感器接入、报修系统本身的功能改造、其他厂区的推广。其他厂区如需使用，另行立项评估。
五、里程碑与交付物
| 阶段 | 时间（示例） | 交付物 |
|---|---|---|
| 需求确认 | 第1个月 | 巡检项清单、流程说明、接口需求说明 |
| 系统配置与开发 | 第2—3个月 | 巡检功能配置完成、接口联调完成 |
| 试点运行 | 第4个月 | 一个车间试点报告、问题清单 |
| 全面上线 | 第5个月 | 三个车间上线、培训记录 |
| 验收与移交 | 第6个月 | 验收报告、运维交接文档 |
六、团队角色与资源预算
| 角色 | 投入方式 | 主要职责 |
|---|---|---|
| 项目发起人 | 兼职，关键节点评审 | 批准预算与范围变更 |
| 项目经理 | 主要投入 | 计划、协调、进度与风险管理 |
| 设备部业务代表 | 兼职 | 巡检项确认、试点验收 |
| 生产车间班组长 | 兼职 | 试点使用与反馈 |
| 安全部代表 | 兼职 | 检查证据需求确认 |
| 外部实施方 | 按合同投入 | 系统配置、接口开发、培训支持 |
预算构成（示例）：软件许可与实施服务60万元，接口开发10万元，培训与差旅5万元，首年运维5万元，合计80万元。预算科目与金额需按组织采购制度核定。
七、风险与假设
| 风险或假设 | 影响 | 应对措施 |
|---|---|---|
| 车间班组对移动端操作接受度低 | 填报率不达标 | 试点期安排现场辅导，简化填报步骤 |
| 现有报修系统接口文档不完整 | 对接延期 | 第1个月完成接口摸底，预留两周缓冲 |
| 巡检项在实施过程中频繁调整 | 范围蔓延 | 需求确认后变更走审批，评估对工期影响 |
| 假设：三个车间网络覆盖满足移动端使用 | 若不成立需补充网络改造 | 试点前完成现场网络测试 |
八、审批与决策字段
申请事项：批准项目立项，批准预算80万元，授权项目经理按上述范围推进。审批路径（示例）：信息化部负责人审核→财务部预算审核→分管领导审批。审批意见栏记录同意、有条件同意或退回的理由，有条件同意时写明附加条件与复核时间。
逐项解释：每个字段为什么这样填
示例的价值不只在“填了什么”，更在“为什么这样填”。以下按关键字段说明判断依据，以及常见写法与示例写法的差异。
背景与问题描述：用事实说明启动理由
背景部分的任务是让审批人理解“现在不做会怎样”。示例没有写“提升管理效率”这类判断，而是列出漏项发现滞后、台账分散、检查准备耗时三个可观察的现象，并说明问题在设备数量增加后加剧。这种写法的好处是审批人可以自行判断问题是否成立。常见的问题是背景写成行业趋势或政策引用，与本单位的具体情况脱节，读者看完仍不知道为什么要现在做。
目标与成功标准：目标给方向，标准给验收口径
目标描述项目建成后的状态，成功标准则要能被检验。示例中的目标是一句话的方向描述，成功标准拆成四条，每条都包含对象、动作和时间条件，例如“上线后三个月内”“24小时内可被看到”。这样写的目的是让验收时有据可依。需要注意，示例中的95%、一天以内等数字是演示口径，实际填写时应基于本单位的现状基线设定，没有基线时先补测基线，再定目标值。
范围边界与排除项：把“不做什么”写清楚
范围部分最容易出问题的地方是只写做什么、不写不做什么。示例明确列出设备采购、传感器接入、报修系统改造、其他厂区推广四类排除项，并说明其他厂区需另行立项。排除项的作用是在项目后期有人提出新增需求时，有一个共同的参照点。写法上，排除项应当具体到可以被识别的对象，避免“其他相关事项”这类模糊表述。
里程碑与交付物：每个阶段有可检查的产物
里程碑不是时间表的美化，而是阶段判断的节点。示例为每个阶段配了交付物，例如需求确认阶段的产出是巡检项清单和接口需求说明，试点阶段的产出是试点报告和问题清单。这样安排使得“阶段是否完成”可以用产物是否存在来判断，而不是靠口头汇报。常见写法只列时间不列交付物，导致阶段评审缺乏依据。
资源预算与角色分工：投入方式比头衔更重要
角色表的关键列是“投入方式”。示例区分了兼职、主要投入和按合同投入，并写明每个角色的职责。审批人关心的是这些投入是否现实：业务代表兼职是否会影响确认进度，外部实施方的投入是否已包含在合同内。预算部分按科目列出构成，并注明需按采购制度核定，避免把示例金额当成报价依据。
风险与假设：写可控的动作，不写笼统的担忧
风险条目的写法是“风险—影响—应对”三段式，应对措施要落到具体动作，例如现场辅导、接口摸底、变更审批、网络测试。假设条目同样重要：示例把“网络覆盖满足使用”写成假设，并给出验证动作，这样假设不成立时项目组有预案。常见问题是风险写成“存在延期风险”而没有影响范围和应对动作，评审时无法判断项目组是否想过办法。
可迁移规律：换成自己的项目怎么改
示例中的字段结构可以直接沿用，内容需要按项目实际替换。以下区分可保留部分与必须替换部分，并给出改写步骤。
| 内容 | 处理方式 | 说明 |
|---|---|---|
| 七类核心问题与章节顺序 | 可原样保留 | 背景、目标、范围、里程碑、资源、风险、审批的先后逻辑通用 |
| 表格字段结构 | 可保留，按模板增删 | 角色表、里程碑表、风险表的列可按组织模板调整 |
| 项目背景与问题 | 必须替换 | 写本单位可观察的现象与数据 |
| 目标数值与成功标准 | 必须替换 | 基于现状基线设定，不照搬示例数字 |
| 范围排除项 | 必须替换 | 按本项目边界逐条列出 |
| 预算金额与科目 | 必须替换并核实 | 按组织采购与财务制度核定 |
| 审批路径 | 必须替换 | 按组织授权制度确定 |
改写目标与成功标准时，可以按“对象＋动作＋时间＋可检验结果”的结构逐条写。例如把“提升巡检管理水平”改写成“上线后三个月内，三个车间的日常巡检记录线上填报率达到某一基线以上”。数值来自本单位现状测量，没有测量就先安排一次基线统计。
改写范围与风险时，先列出项目要交付的产物清单，再逐项判断哪些不在本次范围内，形成排除项。风险从两个方向找：一是范围排除项被重新提出的可能，二是关键假设不成立时的后果。每条风险配一个具体应对动作和责任人，评审时更容易获得信任。
立项书编写完成后通常要经过多轮修改和会签。使用在线文档可以让发起人、财务、业务部门在同一份文档上批注，版本记录清晰；审批环节可以通过审批流记录同意意见与附加条件；立项通过后，里程碑和交付物可以直接转为后续跟踪的任务，减少从文档到执行之间的重复录入。ONES 提供文档协作、审批与工作项管理能力，适合把立项书的编写、评审和后续跟踪放在同一处衔接，具体功能与配置以实际使用版本为准。
适用边界：示例不能替代的判断
这份示例是虚构情景下的填写示范，不是真实客户案例，其中的公司、人员、金额、日期和效果数字均为演示用途。读者不应把示例中的数值当作行业基准或可承诺的收益，也不应把示例的审批路径当作通用流程。
示例处理的是单个项目是否启动、如何启动的判断。当组织需要同时评估多个项目、比较优先级、分配有限资源时，需要项目组合层面的准入标准和排序方法，这超出了本文范围。单份立项书写得完整，也不能替代组合层面的取舍。
涉及预算、合规、审批权限、数据安全等内容时，应以所在组织的财务制度、采购制度、授权制度和相关监管要求为准。示例中的预算科目划分和审批路径仅用于演示字段写法，实际填写前应向财务、法务或合规部门确认口径。立项书通过审批后，范围变更、预算调整等事项同样按组织制度执行。
常见问题
立项书里的成功标准没有历史数据做基线，怎么定目标值？
先补一次基线统计，再定目标值。可以从现有台账或纸质记录中抽取最近一个月的巡检完成情况、缺检发现时长、检查准备耗时等指标，作为现状基线。目标值在基线上设定，并在立项书中注明“基线来源与统计口径”，例如“基于2025年2月三个车间的纸质巡检记录统计”。如果时间不允许补测，可以先把成功标准写成方向性条件，例如“缺检在计划时间点后24小时内可被设备部看到”，并注明目标值待基线测量后补充，在需求确认阶段完成校准。
立项书审批时被要求补充材料，常见缺口有哪些？
常见缺口集中在三类。一是预算依据不足，只写了总额，没有科目构成和测算方式，审批人无法判断金额是否合理；二是范围排除项缺失，评审时无法判断项目边界，后续容易被追加需求；三是风险条目只有描述没有应对动作和责任人，看不出项目组是否做过预案。补充时按“科目—测算依据—责任人”补齐预算，按对象逐条列出排除项，并为每条风险配一个具体动作和责任人。若组织有采购或财务模板，优先按模板口径填写。
立项书通过后，范围和预算发生变化怎么处理？
按组织变更制度执行，不在立项书里自行修改结论。通常的做法是提交变更申请，说明变更内容、原因、对工期和预算的影响，由原审批路径或制度规定的审批人重新确认。立项书中可以提前写明变更规则，例如“范围确认后新增需求需走变更审批，并评估对里程碑的影响”，这样后续讨论有共同参照。预算调整涉及财务科目时，还需财务部门按制度复核。
单项目立项书和多个项目的准入评审有什么区别？
立项书回答的是单个项目值不值得启动、准备怎么做、以什么标准验收，关注项目自身的背景、目标、范围、资源和风险。多个项目之间的准入评审回答的是在有限资源下先做哪个、后做哪个，需要统一的评估维度、打分或排序规则，以及组合层面的资源分配。一份写得完整的立项书可以作为准入评审的输入材料，但不能替代组合层面的取舍标准。如果组织同时有多个候选项目，建议在立项书之外另设准入评审流程。
用在线文档写立项书，评审和后续跟踪怎么衔接？
可以把编写、评审和跟踪放在同一套协作环境里。发起人、财务和业务部门在同一份在线文档上批注，版本记录保留修改过程；审批环节通过审批流记录同意意见与附加条件；立项通过后，里程碑和交付物转为后续跟踪的任务，减少从文档到执行的重复录入。ONES 提供文档协作、审批与工作项管理能力，可用于这一衔接，具体功能与配置以实际使用版本为准。若组织已有既定工具链，按现有流程执行即可。
