本文提供一份虚构的“客户服务系统升级”项目立项材料填写范例，覆盖立项申请、目标与范围、里程碑与资源、风险与评审结论等关键字段，并逐项解释填写依据和评审关注点。读者可对照这份示例完成自己的立项文档，再按组织实际情况替换角色、周期与资源设定。
要点总览（TL;DR）
- 本文用一份虚构的“客户服务系统升级”立项材料，演示立项申请、目标与成功标准、范围边界、里程碑与交付物、角色与资源、风险与应对、评审结论等字段的填写方式。
- 目标写成验收时可核对的结果，并配一条成功标准说明由谁、看什么确认；范围同时列出包含项与不包含项，减少评审时的边界争议。
- 里程碑绑定可检查的交付物，风险条目各配一条可执行动作，评审结论限定为通过、有条件通过或退回补充，并写明下一步动作。
- 示例适用于判断单个项目是否启动；多项目之间的准入比较、组织多级审批和不同项目规模的详略调整，需要按实际情况改写材料。
这份立项示例要解决什么问题
这份示例要回答一个具体问题：一份能进入评审会的立项材料，各字段应该写成什么样。很多立项文档的问题不在信息缺失，而在信息无法支撑判断——目标写成“提升客户满意度”，范围只列要做的事，里程碑只有日期没有交付物，评审人看完仍不知道这个项目该不该启动。示例用一份前后自洽的完整材料，让读者看到每个字段写到什么颗粒度才算可用。
需要先说明性质：示例中的“客户服务系统升级”项目、涉及的角色、周期和资源数量均为演示设定，不对应任何真实客户或真实项目，也不包含实测数据与量化成效。示例的价值在于展示填写结构和表述方式，其中的具体数字只用于说明写法，读者应替换为自己项目的实际测算。
示例覆盖的立项环节包括：立项申请的基本信息、项目背景与立项理由、目标与成功标准、范围边界、里程碑与关键交付物、角色分工与资源需求、主要风险与应对假设，以及评审结论与后续动作。这八个部分构成一份可提交评审的单项目立项材料。本文聚焦“单个项目是否启动”的判断，多个项目之间的准入比较与优先级排序不在讨论范围。
阅读方式建议分两步：先通读第二部分的完整示例，形成整体印象；再对照第三部分的逐项解释，理解每个字段为什么这样写、评审时会看什么。如果时间有限，可以直接使用第四部分归纳的填写规律清单，逐条检查自己的立项材料。
完整立项示例：客户服务系统升级项目
以下为示例项目的立项材料填写内容，各字段前后保持一致，可直接作为对照模板使用。
| 字段 | 填写内容 |
|---|---|
| 项目名称 | 客户服务系统升级项目 |
| 立项申请人 | 客户服务部 张明（示例角色） |
| 项目背景与立项理由 | 现有客服系统上线已超过四年，工单流转依赖人工分派，客户历史记录分散在系统与表格两处。近两个季度客服团队规模扩大后，新成员上手周期明显拉长，跨渠道咨询需要重复录入。业务侧提出将售前咨询与售后工单统一到同一入口处理，减少重复录入和转派等待。本项目即为响应该需求而提出。 |
| 项目目标 | 在项目验收时达成三项可验证结果：一、售前咨询与售后工单统一进入同一工单池，渠道入口由三个合并为一个；二、工单自动分派规则覆盖常见问题类型，人工分派比例下降；三、客户历史记录在工单页面内可完整查看，不再需要跨系统查询。 |
| 成功标准 | 验收时由客服主管与业务负责人共同确认：统一入口上线并完成一轮完整业务周期运行；自动分派规则经抽样核对，分派结果符合预设规则；历史记录迁移完成且抽查无缺失。 |
| 范围——包含项 | 统一工单入口的设计与上线；自动分派规则配置；历史客户记录迁移；客服团队操作培训；上线后四周的运行观察。 |
| 范围——不包含项 | 不包含呼叫中心话务系统改造；不包含客户自助服务门户建设；不包含与财务结算系统的对接；不包含客服绩效体系调整。以上事项如需推进，另行立项。 |
| 里程碑与关键交付物 | M1 需求确认完成——交付物：需求说明与范围确认单；M2 方案设计评审通过——交付物：系统设计方案与迁移方案；M3 系统配置与迁移完成——交付物：可运行的测试环境与迁移核对报告；M4 上线运行——交付物：正式环境上线记录与培训完成确认；M5 验收——交付物：验收结论与运行观察报告。 |
| 角色分工 | 项目负责人：统筹计划、协调资源、对评审结论负责；业务负责人：确认需求优先级与验收标准；系统实施人员：负责配置、迁移与上线操作；客服主管：组织培训并反馈运行问题；评审组：在关键里程碑节点给出通过或退回意见。 |
| 资源需求 | 实施人员投入按阶段分配，设计与迁移阶段为投入高峰；客服团队在培训与上线观察期安排固定时间参与；测试环境与正式环境资源由技术部门协调提供。具体人天与排期在计划阶段细化。 |
| 主要风险与应对 | 风险一：历史记录格式不统一导致迁移遗漏——应对：迁移前完成数据盘点，迁移后抽样核对并保留回退方案。风险二：自动分派规则与实际业务不匹配——应对：规则配置后先在小范围试运行，根据反馈调整后再全量启用。风险三：客服团队上线初期操作不熟练影响服务——应对：培训与上线观察期并行安排，保留人工分派作为过渡手段。 |
| 评审结论 | 有条件通过。条件为：迁移方案需补充数据核对的具体方法与责任人；自动分派规则需在试运行后提交一次专项确认。后续动作：项目负责人于两周内提交补充材料，评审组确认后项目进入执行阶段。 |
这份材料的自洽性体现在几处对应关系：目标中的三项结果分别对应范围中的统一入口、自动分派和历史记录迁移；里程碑的交付物覆盖了范围中的每一项工作；风险条目针对的正是迁移和规则配置这两个不确定性最高的环节；评审结论给出的条件也落在迁移方案与分派规则上。评审人沿着这条线索阅读，可以判断材料是否完整、承诺是否可兑现。
逐项解释：每个字段为什么这样填
目标写成可验证结果，而非动作描述
示例中的目标没有写“建设统一工单平台”或“推进客服系统升级”，而是写成验收时可以核对的状态：入口由三个合并为一个、自动分派覆盖常见问题类型、历史记录在工单页面内可查看。动作描述回答的是“团队要做什么”，可验证结果回答的是“做完之后什么变了”。评审人关心的是后者，因为立项的本质是判断投入是否值得，而判断依据只能是项目结束时的可观察变化。目标与成功标准成对出现，成功标准进一步说明由谁、用什么方式确认这些变化已经发生。
范围中明确不包含项的作用
包含项告诉评审人项目要做什么，不包含项告诉评审人项目不承诺什么。示例中明确排除呼叫中心改造、自助门户、财务对接和绩效调整，作用有三：防止评审人按自己的预期扩大项目边界；让后续出现的相关需求有明确的处理路径——另行立项；也保护项目团队在验收时不被范围外的期待追责。不包含项写得越具体，范围争议越少。常见写法问题是不包含项只写“其他相关事项”，这种表述等于没有边界。
里程碑绑定可交付物
示例的每个里程碑都配有一个可以拿出来看的交付物：需求确认单、设计方案、迁移核对报告、上线记录、验收结论。只写时间点的里程碑无法判断是否真正完成——“三月底完成设计”在三月三十一日可以被称为完成，也可以被称为未完成，取决于有没有可检查的产物。里程碑与交付物对应之后，进度汇报有了统一口径，评审也有了检查对象。里程碑数量不宜过多，示例用五个节点覆盖从需求确认到验收的完整链路，每个节点都对应一次需要确认的决策。
资源需求与角色职责的表述方式
示例没有在立项阶段给出精确到人天的资源数字，而是说明投入的分布：实施人员在设计与迁移阶段为高峰，客服团队在培训和观察期参与，环境资源由技术部门协调。这种写法的理由是立项阶段的信息精度尚不足以支撑精确测算，强行给出精确数字反而会在计划阶段被推翻。角色分工则写清每个角色对什么负责：项目负责人对评审结论负责，业务负责人确认验收标准，评审组在里程碑节点给出意见。职责写到“对什么负责”这一层，比罗列岗位名称更有用。
风险条目与应对措施配对
示例中的三条风险各自配有应对措施，且应对措施是可执行的动作：数据盘点加抽样核对加回退方案、小范围试运行后调整、培训与人工分派过渡并行。风险条目的常见问题是只列风险不给应对，或者应对写成“加强沟通”“密切关注”这类无法执行的说法。配对写法的检查标准很简单：每条应对措施应该能回答“谁在什么时候做什么”。风险数量也不必求多，聚焦不确定性最高、对目标影响最大的几项即可。
评审结论写明通过、有条件通过或退回
示例的评审结论是“有条件通过”，并写明了条件内容和后续动作：两周内提交补充材料，评审组确认后进入执行阶段。评审结论需要落到三种明确状态之一——通过、有条件通过、退回补充，每种状态都要带下一步动作。只写“原则同意”或“请进一步完善”会让申请人不知道是否可以开始执行。有条件通过尤其需要写清条件的数量、内容和确认方式，否则条件会在执行中被淡化。
从这份示例可以迁移的填写规律
示例的具体内容属于演示情景，但其中的填写结构可以迁移到多数单项目立项场景。以下五条规律可作为自查清单使用。
- 目标与验收标准成对出现。每写一条目标，就问一句“验收时由谁、看什么来确认”，把答案写进成功标准。没有验收方式的目标在评审中很难获得信任。
- 范围同时写清包含与不包含。包含项按工作模块列出，不包含项按容易被误认为属于本项目的事项列出，并注明另行立项的处理方式。
- 里程碑绑定可交付物而非时间点。每个里程碑问一句“到这个节点，我们能拿出什么东西给评审看”，把产物名称写进交付物栏。
- 风险与应对一一对应。每条风险后面跟一条可执行动作，动作包含责任人和触发时机；无法写出动作的风险，说明还没有想清楚如何管理。
- 评审结论落到明确的下一步动作。结论限定为通过、有条件通过、退回补充三种状态，每种状态都写明谁在什么时间做什么。
这五条规律共同指向一个判断标准：立项材料的每个字段都应该减少评审人的不确定性，而不是增加阅读量。迁移时保留结构，替换内容——把示例中的客服场景换成自己的业务对象，把演示角色换成实际责任人，把演示周期换成按组织节奏排定的节点。
立项材料从提交、补充、评审到结论确认，需要在团队之间流转并留下记录。ONES 瀑布项目管理解决方案基于 PMI、CMMI 理论，覆盖从立项到收尾的瀑布项目管理全过程，可将需求管理、研发管理、测试管理和资源管理流程连接起来。在立项之后的计划阶段，团队可以用「项目计划」按目标、交付物或项目阶段等维度创建工作分解结构，为任务设置前后置依赖，并用里程碑标记重要时间点、事件或决策点；设置计划与里程碑基线后，可对比计划与执行的偏差，追溯变更细节。资源安排上，项目经理可通过工时日历查看资源饱和度并调整节点负责人。这些能力承接的是立项通过之后的计划与跟踪动作，立项材料本身的字段设计仍取决于组织自己的评审要求。
适用边界：哪些情况需要调整示例
这份示例适用于判断单个项目是否启动的场景：一个业务需求已经明确，需要向评审方说明背景、目标、范围、投入与风险，并取得启动结论。在这个场景内，示例的字段结构和填写规律可以直接对照使用。
以下情况需要对示例做调整，或不属于本文覆盖范围：
- 多个项目之间的准入比较与优先级排序。本文示例只回答“这个项目该不该启动”，不涉及在资源有限时如何在多个候选项目之间取舍。这类判断需要额外的评估维度，不在本文范围。
- 组织审批层级不同。示例按单级评审组设计。如果组织设有部门初审、跨部门评审、管理层决策等多级审批，材料需要按层级拆分详略：初审侧重背景与必要性，决策层侧重目标、投入与风险，各层关注点不同，一份材料通用于所有层级往往哪一层都不够用。
- 材料详略随项目规模变化。示例中的项目涉及系统改造与数据迁移，材料需要覆盖方案与迁移风险。规模更小的项目可以压缩里程碑和风险条目数量，规模更大或跨部门的项目则需要补充依赖关系、合规要求和更细的资源测算。
- 角色、周期和资源为演示设定。示例中的项目负责人、业务负责人、实施人员等角色划分，以及里程碑节奏和资源投入分布，均需按实际组织结构和项目情况替换。直接照抄角色名称而不对应实际责任人，材料在评审时会被追问。
调整示例时保留的是字段之间的对应关系——目标对应验收标准，范围对应里程碑交付物，风险对应应对动作，评审结论对应下一步动作。这层结构不随项目类型变化，而变化的是每个字段里的具体内容。
常见问题
立项材料提交后被退回补充，通常是因为哪些字段没写清楚？
退回补充多集中在三类字段。第一类是目标与成功标准：目标只有动作描述，评审人无法判断项目结束时什么算完成。第二类是范围：只列包含项，不包含项写成“其他相关事项”，评审人按自己的预期理解项目边界。第三类是评审结论：只写“原则同意”或“请进一步完善”，没有说明是否可以开始执行、由谁在什么时间完成什么动作。
收到退回意见时，先确认意见指向的是信息缺失还是信息无法支撑判断。前者补内容，后者需要改写表述方式，例如把目标从“推进系统升级”改成验收时可核对的状态。
组织有多级审批时，一份立项材料需要拆成几份？
示例按单级评审组设计。如果组织设有部门初审、跨部门评审和管理层决策，通常需要按层级拆分详略，而不是把同一份材料逐级提交。部门初审侧重背景与必要性，说明需求从哪里来、不做的后果是什么；跨部门评审侧重范围与依赖，说明与其他团队或系统的衔接；管理层决策侧重目标、投入与风险，关注投入产出和关键不确定性。
拆分时保持各版本的目标、范围和里程碑口径一致，避免不同层级看到互相矛盾的承诺。材料变多不等于内容可以重复，每一层只保留该层做判断所需的信息。
项目规模较小，示例中的八个部分可以删减吗？
可以压缩，但字段之间的对应关系建议保留。小规模项目可以合并角色分工与资源需求，减少里程碑数量，风险条目只保留对目标影响最大的两三项。目标与成功标准、包含项与不包含项、评审结论与下一步动作这三组对应关系不宜省略，它们决定了评审人能否快速判断项目是否值得启动。
规模更大或跨部门的项目则需要反向补充：增加依赖关系说明、合规要求、更细的资源测算和分阶段的评审节点。调整的依据是项目的不确定性和涉及范围，而非材料篇幅本身。
立项通过后，目标和里程碑在计划阶段还需要再拆一次吗？
通常需要。立项材料中的目标回答“项目结束时什么变了”，里程碑回答“到哪个节点能拿出什么交付物”，两者都是评审层面的颗粒度。进入计划阶段后，需要把里程碑进一步分解为可分配、可跟踪的任务，并明确任务之间的前后置依赖。
在 ONES 中，团队可以用「项目计划」按目标、交付物或项目阶段等维度创建工作分解结构，为任务设置前后置依赖，并用里程碑标记重要时间点、事件或决策点；设置计划与里程碑基线后，可对比计划与执行的偏差并追溯变更细节。这样立项材料中的承诺在计划阶段有了承接对象，评审结论里的条件也能落到具体任务上。
示例中的角色和周期可以直接照搬到自己的项目吗？
不建议直接照搬。示例中的项目负责人、业务负责人、实施人员、客服主管和评审组均为演示设定，里程碑节奏和资源投入分布也只用于说明写法。照抄角色名称而不对应实际责任人，评审时容易被追问“这件事具体谁来做”。
替换时保留职责表述的结构：每个角色写清对什么负责，例如谁对评审结论负责、谁确认验收标准、谁在里程碑节点给出意见。周期和资源数量按组织实际排期和测算填写，立项阶段信息精度不足时，可以说明投入分布而非给出精确人天。
