项目立项流程要解决的是在投入资源之前，把“要不要做、做什么、谁来做、做到什么程度”固定下来。它适用于单个项目的启动决策：由发起人提交申请与初步方案，业务、技术、财务等角色分别评估，决策人按授权审批，通过后形成立项决议与目标基线。本文按步骤、角色、文档字段、完整示例和完成检查展开，便于第一次负责立项或正在规范流程的人直接照做。
要点总览（TL;DR）
- 立项流程分六步：申请与初步方案、目标与收益确认、可行性与资源评估、预算核对、分级审批、决议与目标基线，每步都要有输入、动作、输出和完成标志。
- 角色上把发起、评估、审批、承接分开：发起人写申请，业务负责人确认目标与收益，技术与交付评估可行性，财务核对预算，决策人按授权拍板，项目经理承接基线。
- 立项申请与项目章程至少写清目标与成功标准、范围与不做事项、里程碑与资源、风险与假设、预算与收益口径、责任人六类字段。
- 判断流程是否到位，看目标可衡量、范围边界明确、资源预算有归口确认、审批权限匹配金额与风险、决议与基线完成留档。
- 常见缺口是目标写成口号、只写做什么不写不做什么、审批后材料散落，补上这三处流程才真正起决策作用。
立项流程的核心步骤与每步产出
立项流程可以拆成六个前后衔接的步骤。每一步都要有明确输入、具体动作、可留存的输出，以及判断“这一步做完了”的完成标志。缺少完成标志，流程就容易变成签字走过场。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 1. 立项申请与初步方案 | 业务需求、问题描述、初步设想 | 发起人填写立项申请，说明背景、目标草案、初步范围与期望时间 | 立项申请单、初步方案 | 申请字段完整，能说清要解决的问题和大致做法 | 发起人 |
| 2. 目标与收益确认 | 立项申请、业务现状数据 | 业务负责人核对目标是否对应真实业务问题，明确收益口径与衡量方式 | 确认后的目标与收益说明 | 目标可衡量，收益口径有数据来源或计算方式 | 业务负责人 |
| 3. 可行性与资源评估 | 目标、初步范围、现有资源情况 | 技术与交付角色评估实现路径、依赖条件、人力与时间可行性，提出调整意见 | 可行性评估意见、资源估算 | 关键依赖已识别，资源缺口有结论 | 技术负责人、交付负责人 |
| 4. 预算与投入核对 | 资源估算、采购或外协需求 | 财务或预算归口核对投入金额、成本归属与预算余额 | 预算核对意见 | 投入有归口确认，超预算部分有处理意见 | 财务或预算归口 |
| 5. 分级审批与决策 | 申请、评估意见、预算意见 | 按金额与风险对应的授权层级提交审批，决策人给出通过、调整后通过或暂缓的结论 | 审批记录、决策结论 | 审批人层级与项目金额、风险匹配，结论明确 | 决策审批人 |
| 6. 立项决议与目标基线 | 审批结论、评估意见 | 整理立项决议，固化目标、范围、里程碑、预算与责任人，形成项目章程 | 立项决议、项目章程、目标基线 | 决议与基线完成归档，项目团队可据此制定计划 | 项目经理、流程归口 |
顺序上，目标确认应在可行性评估之前完成，否则技术评估容易围绕错误的问题展开；预算核对放在资源估算之后，才能有可核对的投入口径。审批环节不必等所有细节完美，但必须让决策人看到目标、投入和主要风险三项信息。立项决议通过后，目标基线即成为后续计划与变更比较的参照，后续调整应走变更记录，而不是口头修改。
立项各角色的职责与交付物
立项流程空转，常见原因是角色重叠或空缺：有人提交了申请却没人确认收益，有人评估了技术却没人核对预算。把“谁发起、谁评估、谁审批、谁承接”分开写清，每个角色对应一份可检查的交付物，流程才有约束力。
| 角色 | 主要职责 | 交付物 | 常见失位表现 |
|---|---|---|---|
| 发起人 | 提出需求，编写立项申请与初步方案，配合补充信息 | 立项申请单、初步方案 | 只写一句需求，缺少问题描述与目标草案 |
| 业务负责人 | 确认业务目标、收益口径与优先级，对目标合理性负责 | 目标与收益确认意见 | 目标写成“提升效率”等无法衡量的表述 |
| 技术负责人 | 评估实现路径、技术依赖与工作量 | 技术可行性意见、工作量估算 | 只给结论不给依据，依赖条件未列出 |
| 交付负责人 | 评估交付节奏、人力配置与外部依赖 | 资源估算、交付风险说明 | 资源按理想情况估算，未考虑现有项目占用 |
| 财务或预算归口 | 核对投入金额、成本归属与预算余额 | 预算核对意见 | 审批时才发现无预算，返工重走流程 |
| 决策审批人 | 按授权对项目是否启动作出结论，对投入与风险平衡负责 | 审批记录、决策结论 | 授权层级不清，小事上会、大事无人拍板 |
| 项目管理办公室或流程归口 | 维护流程与模板，检查材料完整性，归档决议与基线 | 流程模板、立项台账、归档记录 | 只收材料不检查，归档缺失导致后续无法追溯 |
| 项目经理 | 承接立项结论，编制计划，维护目标基线与变更记录 | 项目计划、基线记录 | 立项后目标无人承接，执行与决议脱节 |
角色设置要与组织规模匹配。小团队可以由一人兼任业务负责人与决策人，但评估与审批不宜由同一人完成，否则可行性意见失去独立价值。流程归口的职责是保证材料完整和记录可查，不替代业务与技术做判断。
当立项申请、评审意见、审批结论和项目章程分散在邮件与聊天记录里，追溯成本会明显上升。ONES 可以用工作项承载立项申请，把评审意见、审批结论和项目章程作为同一事项下的记录留存，决议通过后将目标与里程碑固化为基线，供后续计划与变更对照。这样做的价值在于让每个环节的输入和输出有统一入口，减少材料散落造成的返工。
立项申请与项目章程的关键字段
立项申请回答“为什么做、打算怎么做”，项目章程回答“批准做什么、以什么为基线”。两者字段有重叠，但用途不同：申请用于评审，章程用于执行依据。字段设计的目标是让评审人有据可评、后续有据可查。
| 字段 | 立项申请 | 项目章程 | 填写要求 |
|---|---|---|---|
| 项目背景与问题描述 | 必填 | 引用申请内容 | 说明当前问题、影响范围和触发原因，避免只写“业务需要” |
| 目标与成功标准 | 目标草案 | 确认后的基线目标 | 目标可衡量，成功标准写明衡量方式与时间点 |
| 范围与不做事项 | 初步范围 | 确认范围及明确排除项 | “不做事项”要具体，例如不覆盖某类用户或某个区域 |
| 里程碑与关键资源 | 初步时间与资源需求 | 基线里程碑、资源承诺 | 里程碑对应可交付成果，资源写明角色与投入比例 |
| 风险与假设 | 主要风险与前提假设 | 确认后的风险清单 | 每条风险写明影响与应对方向，假设写明不成立时的后果 |
| 预算与收益口径 | 投入估算与预期收益 | 批准预算与收益衡量口径 | 金额、成本归属、收益计算方式写清，避免口径事后变化 |
| 责任人 | 发起人、拟任项目经理 | 项目负责人、审批人 | 与角色职责表一致，避免多头负责 |
字段数量不必追求齐全，但目标、范围、预算、责任人四项不能缺。范围中的“不做事项”尤其容易被省略，它直接决定后续需求讨论的边界。收益口径应在申请阶段就写明计算方式，例如按处理时长或人工投入折算，避免项目结束后各说各话。
一个单项目立项的完整示例
以下为演示情景，用于说明字段如何填写，不代表真实案例。某制造企业的客服部门提出建设售后工单系统，解决工单靠邮件流转、响应时长无法统计的问题。
发起与申请。客服主管作为发起人提交立项申请：背景为售后工单分散在邮箱与即时通讯工具中，平均响应时长缺少统计；目标草案为上线统一工单入口，将工单首次响应时长纳入统计；初步范围为工单创建、分派、状态跟踪与统计报表，不做事项为暂不接入外部客户自助门户；初步资源为两名开发人员投入约两个月，另需一名客服人员配合梳理流程；预期收益为响应时长可统计、工单遗漏减少；主要风险为历史工单数据迁移口径不清。
评估意见与调整。业务负责人确认目标与售后响应考核指标对应，收益口径按每月工单量与平均响应时长折算。技术负责人评估后认为统一入口可行，但历史数据迁移需要额外时间，建议首期只迁移近三个月数据。交付负责人指出两名开发人员中有一人同时承担其他项目，建议将首期里程碑从两个月调整为十周。财务核对后确认开发人力为内部投入，无额外采购预算，但报表工具需要小额订阅费用，已列入预算。评估意见汇总后，申请中的里程碑与迁移范围相应调整。
审批结论。该项目金额与风险处于部门负责人授权范围内，由部门负责人审批。结论为“调整后通过”：同意首期范围，历史数据仅迁移近三个月，里程碑按十周执行，报表工具订阅费用纳入部门预算。审批记录与调整说明一并留存。
立项后的目标基线。项目章程固化以下内容：目标为上线统一工单入口并实现首次响应时长统计；范围为工单创建、分派、状态跟踪、统计报表及近三个月历史数据迁移，不做外部客户自助门户；里程碑为需求确认、系统上线、试运行三节点；预算为内部人力加报表工具订阅费用；项目负责人为客服主管指定的项目经理。基线确定后，后续如需扩大迁移范围，走变更记录并重新确认时间。
立项流程的完成检查与常见缺口
判断立项是否做到位，可以按以下清单逐项核对。每一项都对应一个可观察的结果，而不是“已沟通”“已推进”这类描述。
- 目标是否可衡量：目标能否对应具体指标、时间点和衡量方式；若只能定性描述，是否写明了判断依据。
- 范围与不做事项是否写明：申请与章程中是否都有明确的范围边界，不做事项是否具体到对象或场景。
- 资源与预算是否有归口确认：人力、时间与费用是否分别有技术、交付、财务角色的确认意见，缺口是否有处理结论。
- 审批权限是否匹配金额与风险：审批人层级是否与项目金额、风险等级对应，是否存在越级审批或无人拍板的情况。
- 决议与基线是否留档：立项决议、项目章程、目标基线是否完成归档，项目经理能否直接据此编制计划。
- 评估意见是否被采纳或说明：技术、交付、财务提出的调整意见，是否在决议中体现或给出不采纳的理由。
- 变更入口是否明确：基线确定后，范围、时间、预算的调整是否有指定的记录方式和确认人。
常见缺口集中在三处：目标写成方向性口号，导致执行阶段无法判断是否达成；范围只写做什么、不写不做什么，需求讨论反复拉扯；审批与归档脱节，决议通过后材料散落，后续变更无据可依。把这三处补上，立项流程就能从签字环节变成真正的启动决策。流程归口可以定期抽查立项台账，检查决议、章程与基线是否齐全，发现缺失及时补齐，让流程持续可用。
常见问题
立项审批通过后，目标和范围还能改吗？
可以改，但要通过变更记录，而不是口头调整。立项决议通过后，目标、范围、里程碑和预算形成基线，成为后续计划与变更比较的参照。需要调整时，由项目经理提出变更，说明调整原因、影响范围和新的时间或预算口径，按原审批层级或组织规定的变更权限重新确认，并把变更记录与基线一并留档。这样执行阶段的范围蔓延有据可查，也便于复盘时区分原始目标和后续调整。
小团队人手少，立项角色可以合并吗？
可以合并部分角色，但要保留评估与审批的独立性。小团队中业务负责人与决策人由同一人兼任是常见做法，发起人也可能同时是项目经理。需要留意的是，可行性评估与审批不宜由同一人完成，否则评估意见失去独立价值；财务或预算核对若没有专职岗位，可由负责预算管理的人兼任，但要有明确的核对动作和记录。角色合并的前提是每项职责仍有对应的交付物，避免出现没人确认收益或没人核对投入的空缺。
立项申请要写到多细才能提交评审？
申请达到“能评审”的程度即可，不要求所有细节在申请阶段就确定。基本要求是：问题描述能说清当前状况和影响，目标有草案且指向可衡量的结果，范围有初步边界并列出主要的不做事项，资源与时间有大致估算，主要风险已识别。技术实现路径、详细工作量和精确预算可以在评估环节补充。如果申请只写一句需求或一个方向性目标，评审人无法判断是否值得投入，流程会退回补充材料，反而拉长周期。
多个项目同时申请时，立项流程要怎么衔接？
单项目立项解决的是“这个项目要不要启动”，多个项目同时申请时，各自仍按本文流程完成申请、评估和审批，但需要在审批前增加一步横向比较：由流程归口或项目管理办公室汇总各项目的目标、投入、资源占用和风险，供决策人判断优先级和资源冲突。资源冲突的结论应回写到各项目的立项材料中，例如调整里程碑或缩减范围。多项目之间的准入比较与排序属于项目提案与准入管理的范围，本文不展开，但单项目材料齐全、口径一致是横向比较能够进行的前提。
立项材料用邮件和文档管理，和用工具承载有什么区别？
区别主要在追溯成本和一致性。用邮件和分散文档管理时，申请、评审意见、审批结论和项目章程往往散落在不同位置，后续查证需要逐封翻找，变更时也容易只改一处、其他版本未同步。用统一的工作项或项目空间承载时，立项申请作为一条记录，评审意见、审批结论和章程作为同一事项下的附件或记录留存，决议通过后目标与里程碑固化为基线，后续计划和变更都对照同一份基线。ONES 可以用工作项承载立项申请并留存评审与审批记录，将目标与里程碑固化为基线供后续对照，减少材料散落造成的返工。选择哪种方式取决于组织现有的协作习惯和追溯要求，关键是保证同一项目的材料有统一入口。
