项目立项流程怎么做：步骤、角色与评审检查

项目立项流程要在启动前把四件事说清楚：要不要做、值不值得做、怎么做、谁负责。具体做法是提出人提交申请与初步方案，业务、技术、财务分别评估，立项评审会给出启动、暂缓或否决的结论，最后形成可追溯的立项决议、目标与范围基线、角色分工和首批交付计划。本文只讨论单个项目是否启动的立项流程，多项目之间的准入比较与优先级排序不在范围内。

要点总览（TL;DR）

• 立项流程分五步：申请、分类评估、评审、决议与基线、首批计划确认，每步都有明确的输入、输出和完成标志。
• 业务、技术、财务三类评估各自出具书面意见，评审决策者据此给出启动、暂缓或否决的结论，决策者与执行者分离。
• 立项材料要写清可衡量的目标与统计口径、范围排除项、关键假设与风险、预算估算口径，示例中的写法可直接参照。
• 立项完成的标志是决议可追溯到评审记录、目标与范围形成基线、角色资源预算有归属、风险假设有人跟踪。
• 目标缺量化口径、预算无归属、暂缓或否决后未重新评审，属于不能进入执行阶段的阻断项。

立项流程的核心步骤与各步输出

立项流程可以拆成五步：申请、评估、评审、决议与基线、首批计划确认。五步的顺序有依赖关系——评估依赖申请材料的完整度，评审依赖评估意见，决议依赖评审结论，首批计划依赖决议确定的目标与范围。跳过任何一步，后续环节都会缺少判断依据。下表给出每步的输入、动作、输出和完成标志，可直接作为流程模板使用。

步骤	输入	动作	输出	完成标志
1. 立项申请	业务需求或问题描述、初步方案、预期收益的粗略估计	提出人填写立项申请，说明背景、目标、初步范围、期望时间与大致投入	立项申请单、初步方案	申请单字段填写完整，背景与目标能对应到具体业务问题
2. 分类评估	立项申请单、初步方案	业务负责人评估价值与紧迫性；技术负责人评估可行性与技术风险；财务或预算角色评估投入产出与预算归属	三份评估意见，各自给出结论与保留条件	三类评估意见齐全，每份意见有明确结论而非仅描述情况
3. 立项评审会	申请单、评估意见、必要的补充材料	评审决策者逐项质询目标、范围、投入与风险，形成启动、暂缓或否决的结论	评审记录，含结论、附加条件与待办事项	结论明确到一种类型，附加条件与待办有责任人和时限
4. 决议与基线	评审记录	整理立项决议，固化目标基线（可衡量的目标与验收口径）和范围基线（做什么、不做什么）	立项决议、目标与范围基线文档	决议可追溯到评审记录，目标有量化口径，范围边界写明排除项
5. 首批计划确认	立项决议、目标与范围基线	项目经理与承接团队确认角色分工、资源与预算归属、首批交付物与里程碑	项目章程或目标说明、首批交付计划、风险与假设清单	角色与资源有明确归属人，首批交付物有完成时间，风险与假设有跟踪人

三类评估的分工需要说清楚，否则容易出现“都评了但没人负责”的情况。业务评估回答“这件事对谁有价值、价值多大、晚做会怎样”；技术评估回答“现有条件下能否实现、主要技术风险在哪、需要哪些前置条件”；财务或预算评估回答“投入多少、钱从哪个预算出、回报周期大致多长”。三类评估各自出具书面意见，结论可以是“支持”“有条件支持”“不建议”，并写明条件内容。

评审会的决策方式建议采用明确表决而非默许通过：由评审决策者根据评估意见做出启动、暂缓或否决的结论。暂缓需要写明暂缓原因和重新评审的触发条件，例如预算到位或前置依赖完成；否决需要记录理由，便于后续类似提案参考。评审记录与立项决议分开保存，前者记录讨论过程与不同意见，后者只记录最终决定，两者共同构成可追溯的决策链。

在评审记录、立项决议和目标基线的承载上，如果团队使用项目协作工具，可以把申请单、评估意见、评审记录和决议放在同一个项目空间内，让决议关联到对应的评审记录，目标基线以可勾选的目标条目形式存在，后续执行阶段直接引用。ONES 支持在项目内建立文档与工作项的关联，立项材料与后续任务可以在同一处追溯，减少决议与执行脱节的情况。工具承载的是记录与追溯，评审的判断标准仍需团队自己定义。

立项中的角色分工与交付物

立项流程涉及五类角色：提出人、业务负责人、技术负责人、财务或预算角色、评审决策者。提出人通常是项目经理或业务骨干，负责把想法写成可评估的申请；三类评估角色各自出具专业意见；评审决策者对是否启动做最终判断。角色分工的核心是决策者与执行者分离：做评估的人不替自己做启动决定，做执行的人不绕过评审直接开工。

角色	主要职责	交付物
提出人 / 项目经理	发起立项、编写申请与初步方案、组织评估、整理评审材料、牵头形成决议与首批计划	立项申请单、初步方案、评审材料汇总、立项决议草稿、首批交付计划
业务负责人	评估业务价值、紧迫性与影响范围，确认验收口径的业务侧要求	业务价值评估意见
技术负责人	评估技术可行性、架构影响、技术风险与前置条件	技术可行性评估意见
财务或预算角色	评估投入估算口径、预算来源与回报预期，确认预算归属	投入产出评估意见、预算归属确认
评审决策者	主持评审、做出启动/暂缓/否决结论、对附加条件拍板	评审记录、立项决议
承接团队负责人	确认资源可投入、接受目标与范围基线、承接首批交付	资源承诺、项目章程或目标说明的确认

文档归属要避免两个常见问题：一是所有材料都由提出人代写，评估意见失去独立性；二是评审记录只记结论不记条件，执行阶段无法判断哪些前提必须满足。建议评估意见由各评估角色本人出具并署名，评审记录由提出人整理、决策者确认，立项决议由决策者签发。项目章程或目标说明在决议之后形成，由项目经理起草、承接团队负责人确认。

授权方面，评审决策者应被明确授予“在既定预算与资源范围内批准启动”的权限，超出权限的投入需要上升一级审批。这样常规项目不必层层上报，重大投入仍有控制。角色缺位时的处理方式需要提前约定：业务负责人缺席可由其授权代表出具意见，但需注明授权关系；财务角色暂时无法评估时，评审可给出“有条件启动”，把预算确认列为启动后的前置条件并设定完成时限；决策者无法到场时，评审顺延而非由提出人自行判断。

一个立项评审的填写示例

以下示例为演示情景，用于说明各字段的写法，不代表真实项目数据。示例项目为“客服工单系统与内部知识库打通”，目标是让客服在工单界面直接检索知识库内容。

背景与目标。当前客服处理工单时需在知识库系统单独搜索，平均每单多花约两分钟，且新员工检索准确率偏低。目标写成可衡量的形式：上线后三个月内，工单处理平均时长下降15%，知识库检索在工单场景的使用率达到60%以上，新员工独立处理工单的比例提升到80%。目标同时写明统计口径：时长数据取自工单系统的处理记录，使用率取自检索日志。

范围与不做什么。本期范围包括工单界面嵌入检索入口、知识库内容按工单分类做标签映射、检索结果点击埋点。明确排除：知识库内容的重写与扩充、工单系统本身的流程改造、面向外部客户的自助检索。排除项写进范围基线，后续如需纳入按变更规则处理。

关键假设与风险。假设一：知识库现有内容覆盖率足以支撑工单场景，需在启动后两周内用样本工单验证；假设二：工单系统提供可用的嵌入接口。风险包括接口改造工作量超出预估、知识库标签体系与工单分类对不齐。应对方式是先做两周的技术验证，验证不通过则调整方案或暂缓后续投入。

资源与预算估算口径。投入按人力与外部费用分列：开发两人约六周、知识库标签整理一人约三周，外部费用仅为接口联调可能产生的服务费，按上限估算。预算来源写明归属部门与预算科目，估算口径注明“按人天单价×人天”计算，便于评审时核对。

评审结论与后续动作。评审结论为“有条件启动”：条件是两周内完成接口技术验证和知识库覆盖率抽样，两项均通过则正式启动，任一不通过则回到评审。后续动作包括：技术负责人两周后提交验证结论，项目经理据此更新决议状态，财务角色确认预算冻结。评审记录中同时保留一位评审者对“新员工比例目标偏乐观”的不同意见，供执行阶段参考。

立项完成的检查清单

判断立项是否真正闭环，可以逐项核对以下条目。每条都给出可核验的判断标准，避免“基本完成”这类模糊结论。

• 目标与验收口径可衡量。每个目标有量化指标、统计口径和数据来源，验收时能直接对照，不依赖事后解释。
• 范围边界与变更规则明确。范围基线写明做什么和明确不做什么，变更规则说明谁提出、谁审批、什么情况下重新评审。
• 角色、资源与预算有归属。每个关键角色有具体的人，资源投入有承诺方，预算有科目和来源，不停留在“相关部门支持”。
• 风险与假设有记录和跟踪人。关键假设写明验证方式和时限，风险写明应对措施和责任人，且跟踪人已知晓自己的跟踪职责。
• 决议与评审记录可追溯。立项决议能关联到对应的评审记录，评审记录保留评估意见与不同意见，决议中的附加条件有完成时限。
• 首批交付计划可执行。首批交付物、里程碑时间和承接人明确，计划与目标基线对应，不存在目标有而计划无覆盖的情况。

阻断项是指未满足就不能进入执行阶段的条目。建议把以下三项设为阻断：目标缺少量化口径、预算无明确归属、评审结论为暂缓或否决而未重新评审。其余条目可以作为限期补正项，例如风险跟踪人未指定时允许在启动后一周内补齐，但需在决议中记录该待办。检查由项目经理自检、评审决策者或 PMO 复核，复核结果与决议一并归档，形成从申请到启动的完整记录链。

常见问题

立项评审给出“暂缓”结论后，项目团队接下来该做什么？

暂缓不等于终止，需要在评审记录中写明暂缓原因和重新评审的触发条件，例如预算到位、前置依赖完成或某项技术验证通过。提出人负责跟踪触发条件，条件满足后重新提交评审，而不是由团队自行判断后直接开工。如果触发条件在约定时限内未达成，应由评审决策者确认是否转为否决，避免项目长期停留在悬置状态。

小团队没有独立的财务或技术评估角色，立项流程可以简化吗？

可以简化角色数量，但要保留评估的独立性。常见做法是由不参与该项目执行的人承担评估职责，例如由团队负责人评估业务价值、由另一位技术骨干评估可行性，预算部分由掌握预算的人确认归属。关键是评估意见由本人出具并署名，提出人不代写全部意见。角色缺位时按约定处理：授权代表出具意见需注明授权关系，确实无法评估的部分列为有条件启动的前置条件并设定完成时限。

立项决议和目标基线确定后，执行中发现目标定得不合理怎么办？

按变更规则处理，而不是在执行中悄悄调整。范围基线中应事先写明变更由谁提出、谁审批、什么情况下需要重新评审。目标口径的调整通常需要回到评审决策者确认，并在决议中留下变更记录，使目标基线始终与最新决议一致。如果调整涉及预算或范围的重大变化，建议重新走一次评审，避免执行阶段的目标与当初批准的依据脱节。

立项申请单、评估意见、评审记录这些材料需要长期保存吗？

建议保存，并保持材料之间的关联。立项决议要能追溯到对应的评审记录，评审记录要保留各角色的评估意见和不同意见，这些材料在后续变更、验收争议和类似项目参考时都会用到。使用项目协作工具时，可以把申请单、评估意见、评审记录和决议放在同一个项目空间内并建立关联，目标基线以条目形式存在，执行阶段直接引用，减少决议与执行脱节。

立项检查清单里的阻断项和限期补正项如何区分？

阻断项是未满足就不能进入执行阶段的条目，建议至少包括目标缺少量化口径、预算无明确归属、评审结论为暂缓或否决而未重新评审这三类，因为它们直接影响后续执行是否有依据。限期补正项是可以在启动后约定时间内补齐的条目，例如风险跟踪人尚未指定，但需在决议中记录该待办、明确责任人和补齐时限。检查由项目经理自检、评审决策者或 PMO 复核，复核结果与决议一并归档。