项目立项要解决的是“这个项目该不该启动、以什么条件启动”。具体做法是把想法整理成一份可判断的立项申请，写清目标、范围、交付物、里程碑、资源与成本、主要风险，由发起人提交、相关方会签，决策人按统一标准评审并给出启动、暂缓或否决的结论；通过后形成立项决议和项目章程，用启动会落实角色与第一批任务。本文按申请内容、操作步骤、角色分工、评审判断、示例和启动交接依次展开。
要点总览（TL;DR）
- 立项的核心产出是一份可决策的立项申请：目标带指标、范围带不做清单、交付物带验收标准、预算分项列出、风险配应对思路。
- 操作顺序为登记想法、初步可行性判断、编写申请、预沟通会签、提交评审五步，每步都要有明确的完成标志，避免材料反复修改却无法提交。
- 角色分工要落到交付物和交接时点：发起人对目标负责，项目经理组织材料，业务与技术相关方评估需求与可行性，财务核对预算，决策人给出结论。
- 评审按目标价值、范围清晰度、资源预算、时间依赖、风险可控性五个维度判断，结论分为启动、有条件启动、暂缓或否决，有条件启动须写明条件、责任人和时限。
- 立项通过后归档决议、形成项目章程、召开启动会，把目标、里程碑和第一批任务落到人，并用检查清单确认立项工作完成。
立项要产出什么：一份可决策的立项申请包含哪些字段
立项申请的价值在于支撑一次决策，因此每个字段都要回答评审人关心的一个问题。字段齐全只是底线，更关键的是填写到可判断的程度：目标能被衡量，范围能被界定，交付物能被验收。下表给出常用字段、填写要求与示例，负责人一栏可按组织实际调整。
| 字段 | 填写要求 | 示例 | 负责人 |
|---|---|---|---|
| 项目名称与一句话目标 | 名称指向具体对象；目标含指标、基线和时间 | “审批流程系统改造：将平均审批时长从3天降至1天，年底前上线” | 发起人 |
| 业务背景与问题 | 说明现状、问题表现和影响范围，用数据或事实描述 | “现有系统不支持并行审批，跨部门单据平均滞留3天，月均积压约200单” | 发起人 |
| 范围与不做清单 | 写清纳入的流程、系统、部门，同时列出本期明确不做的内容 | “纳入采购、报销两类流程；本期不做移动端和外部供应商门户” | 项目经理 |
| 交付物与验收标准 | 每项交付物配可核验的验收条件 | “新审批引擎上线，采购流程端到端跑通，压测支持200并发” | 项目经理与业务方 |
| 里程碑与关键时间点 | 列出阶段节点、交付物和日期，标注外部依赖 | “需求确认（3月）、开发完成（6月）、试运行（9月）、全面上线（11月）” | 项目经理 |
| 资源与预算需求 | 按人力、采购、外部服务分项列出，说明占用周期 | “开发4人×5个月，测试2人×3个月，服务器与许可费用约XX万元” | 项目经理与财务 |
| 主要风险与假设 | 列出高影响风险、应对思路和成立所依赖的假设 | “风险：旧系统数据迁移质量不确定；假设：业务部门能在3月前完成流程确认” | 项目经理 |
| 发起人与责任人 | 明确谁对业务结果负责、谁对交付负责 | “发起人：运营总监；项目经理：信息部张某” | 发起人 |
填写中最常见的问题有三类。目标写成口号，如“提升审批效率”，评审时无法判断是否达成，应改为带指标和时间的目标。范围没有边界，只写“改造审批系统”，执行中容易不断加需求，应同时给出不做清单。预算只给总数，评审无法判断合理性，应按人力、采购、外部服务分项列出并说明测算依据。
从想法到提交：立项的五个操作步骤
立项按时间顺序可以拆成五步，每一步都有明确的输入、动作、输出和完成标志。完成标志的意义在于让参与者知道这一步什么时候算结束，避免材料反复修改却迟迟无法提交。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、登记项目想法 | 业务问题描述、提出人信息 | 记录想法来源、初步问题、期望收益，指定发起人 | 项目想法登记记录 | 发起人确认承接，问题描述可被他人理解 |
| 二、初步可行性判断 | 想法登记记录、现有资源与系统情况 | 粗判资源、时间、技术依赖是否具备基本条件，识别明显障碍 | 可行性初判意见 | 确认值得投入编写完整申请，或说明暂不推进的理由 |
| 三、编写立项申请 | 可行性初判意见、业务与技术要求 | 补齐目标、范围、交付物、里程碑、成本与风险，形成完整材料 | 立项申请初稿 | 字段齐全，目标、范围、交付物达到可判断程度 |
| 四、预沟通与会签 | 立项申请初稿 | 向技术、财务、业务相关方说明方案，收集意见并修订 | 会签意见与修订稿 | 关键相关方意见已回应，分歧点已记录 |
| 五、提交评审并形成结论 | 修订稿、会签记录 | 提交评审会，按标准答辩，记录结论与条件 | 立项决议或退回修改意见 | 结论明确，责任人和后续动作已落实 |
第二步常被跳过，导致投入大量精力编写材料后才发现资源或依赖不具备。初步可行性判断不必精确，但要能回答三个问题：有没有人做、时间窗口是否现实、是否依赖尚未确定的外部条件。第三步编写时，建议由项目经理主笔、发起人确认目标与业务价值，避免材料由单一角色闭门完成。第四步预沟通的作用是提前暴露分歧，技术侧关注可行性与依赖，财务侧关注预算构成，业务侧关注需求合理性，分歧在评审前解决比在评审会上争论更有效。
谁来做：立项过程中的角色分工与交付物
立项拖延或流于形式，常见原因是角色不清：有人提想法但没人对目标负责，有人写材料但没人能拍板。下表按角色列出职责、交付物和交接时点，组织可据此指定具体人员。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 项目发起人 | 提出想法，说明业务价值，对项目目标负责 | 业务背景与目标说明、发起人确认 | 想法登记时确认，评审前确认目标 |
| 项目经理或负责人 | 组织编写立项申请，协调预沟通，维护材料版本 | 立项申请、会签记录、评审材料 | 各步骤之间持续维护，评审前定稿 |
| 业务相关方 | 评估需求合理性与业务影响，确认验收标准 | 需求意见、验收标准确认 | 编写阶段提供，会签时确认 |
| 技术相关方 | 评估技术可行性、系统依赖与实施路径 | 技术可行性意见、依赖清单 | 可行性初判与预沟通阶段 |
| 财务或资源管理者 | 核对预算构成、人力占用与采购需求 | 预算核对意见 | 会签阶段 |
| 决策人或评审组 | 按统一标准评审，给出启动、暂缓或否决结论 | 立项决议、附加条件 | 评审会结束时 |
分工之外还要约定交接时点，否则容易出现材料写完却无人确认、意见收集后无人汇总的情况。一个实用做法是在立项申请首页标注各角色的确认状态，评审前逐项核对，未确认的字段在评审材料中显式标出，让评审人知道哪些内容仍有不确定性。
评审怎么判：立项决策标准与结论类型
评审要有统一口径，否则同类项目在不同会议上结论不一致。建议从五个维度判断：目标与业务价值是否清晰且值得投入；范围是否可界定，不做清单是否明确；资源与预算是否可行，人力占用是否与现有工作冲突；时间与依赖是否现实，关键外部条件是否可控；主要风险是否有应对思路。每个维度给出“满足、部分满足、不满足”的判断，比笼统打分更便于记录异议。
结论通常分三种。启动，即按申请方案推进，评审记录中写明批准的范围和预算上限。有条件启动，即原则同意，但附整改条件和时限，例如“预算按分项重新测算后两周内补充”“数据迁移方案需在开发启动前通过技术评审”，条件未满足前不进入下一阶段。暂缓或否决，需写明原因和重新提交的条件，避免同一材料反复上会。
评审记录至少包含：结论类型、附加条件、条件责任人、完成时限和下次复核时间。为减少评审流于形式，材料应提前发送，让评审人带着问题参会；会议限定在申请材料范围内提问，超出范围的建议记录为后续事项；对异议要如实记录，不因结论已定而省略。评审组人数和层级可按项目预算规模、影响范围分档设置，小规模项目可由部门负责人直接决策，跨部门或高投入项目再上升到评审组。
示例：一个内部系统改造项目的立项过程
以下为演示情景，用于说明字段、步骤、角色和评审结论如何串联，不作为真实案例。
某部门提出改造现有审批流程系统。想法登记阶段，发起人写明问题：现有系统不支持并行审批，跨部门单据平均滞留3天，月均积压约200单。初步可行性判断确认信息部有开发资源，但需与正在进行的另一系统升级错开时间，因此时间窗口定在下半年。
立项申请的关键字段填写如下：目标为“平均审批时长从3天降至1天，年底前上线”；范围为“采购、报销两类流程，覆盖总部及两个分公司”，不做清单为“本期不做移动端、外部供应商门户和与财务系统的自动对账”；交付物为“新审批引擎上线、两类流程端到端跑通、压测支持200并发”，验收标准由业务方确认；里程碑为需求确认3月、开发完成6月、试运行9月、全面上线11月；资源需求为开发4人×5个月、测试2人×3个月，另列服务器与许可费用；主要风险为旧系统数据迁移质量不确定，假设为业务部门3月前完成流程确认。
角色分工上，运营总监作为发起人对审批时长目标负责，信息部张某任项目经理组织材料与预沟通，业务部门确认流程与验收标准，技术相关方评估迁移方案，财务核对预算分项，分管领导作为决策人参加评审。
评审结论为有条件启动：原则同意立项，附加两个条件——预算按人力、采购、外部服务重新分项测算，两周内补充；数据迁移方案在开发启动前通过技术评审。记录中写明条件责任人和复核时间。从这个示例可以迁移的规律是：目标带指标、范围带不做清单、结论带条件，三者让立项从“表态同意”变成可跟踪的决策。
立项通过之后：启动交接与完成检查
立项结论只有落到启动动作才算完成。评审通过后，先把立项决议归档，与立项申请、会签记录放在同一处，形成项目章程的基础内容：目标、范围、交付物、里程碑、角色和批准条件。随后安排启动会，向团队宣贯目标与边界，确认各角色和汇报关系，把里程碑拆成第一批可执行任务，明确每项任务的负责人和完成时间。
启动交接的关键是把纸面内容转成可跟踪的对象：目标与范围写入项目章程，里程碑进入计划，第一批任务分配到人，评审附加条件作为待办事项单独跟踪。使用项目管理工具承载时，立项申请、评审记录、里程碑和任务可以放在同一项目空间中，条件整改和复核时间也能作为工作项跟踪。ONES 可用于承载立项材料、评审记录与任务跟踪，具体配置按组织流程确定。
立项工作是否完成，可用以下清单逐项核对：
- 立项申请字段齐全，目标、范围、交付物达到可判断程度；
- 关键相关方会签意见已收集并回应，分歧点有记录；
- 评审记录完整，结论类型、附加条件、责任人和时限明确；
- 立项决议已归档，项目章程已形成；
- 启动会已召开，角色、里程碑和第一批任务已确认到人；
- 变更与复核机制已约定，明确哪些变化需要重新评审、何时复核附加条件。
立项材料在执行中需要维护。范围、预算或里程碑发生实质性变化时，按约定触发变更评审，更新项目章程并保留版本记录；评审附加条件到期未完成的，由责任人说明进展并重新约定时间。把立项材料当作活文档维护，后续的进度汇报和结项验收才有可对照的基准。
常见问题
立项申请写到什么程度可以提交评审？
判断标准是评审人能据此做出启动与否的决定，而不是材料页数。具体看三点：目标含指标、基线和时间，能被衡量；范围既写纳入内容也写不做清单，能被界定；每项交付物配有可核验的验收条件。预算按人力、采购、外部服务分项列出并说明测算依据。若某字段仍有不确定性，可在材料中显式标出，让评审人知道风险所在，比含糊带过更有利于决策。
初步可行性判断和正式评审有什么区别，能不能合并？
两者目的不同。初步可行性判断发生在编写完整申请之前，只需粗判有没有人做、时间窗口是否现实、是否依赖尚未确定的外部条件，用来决定值不值得投入精力写材料。正式评审发生在材料与会签完成之后，按统一标准判断是否启动以及以什么条件启动。合并的后果是资源或依赖明显不具备的项目也会走完整流程，浪费发起人和相关方的时间。项目较小、条件清晰时，初判可以简化，但建议保留这一确认动作。
评审给出“有条件启动”后，条件没按时完成怎么办？
条件应作为独立事项跟踪，写明责任人、完成时限和复核时间。到期未完成时，由责任人说明进展和阻碍，重新约定时间，并判断是否影响后续阶段。若条件涉及关键前提，例如数据迁移方案未通过技术评审，则后续开发不应启动。把附加条件纳入项目工作项跟踪，并在下次复核时对照原记录检查，可以避免条件在启动后被遗忘。
立项通过后范围发生变化，需要重新走立项吗？
取决于变化的性质。范围、预算或里程碑发生实质性变化时，按立项时约定的变更机制触发变更评审，更新项目章程并保留版本记录；变化超出原批准范围较大的，可能需要回到原决策人或评审组重新确认。日常的任务调整和细节细化不必重新立项。建议在立项完成时就约定哪些变化需要重新评审，避免执行中每次调整都争论流程。
小团队或小预算项目也要走完整的立项流程吗？
流程可以裁剪，但关键要素建议保留：一句话目标、范围与不做清单、交付物、资源需求、主要风险和责任人。评审层级可按预算规模和影响范围分档，小规模项目由部门负责人直接决策即可，跨部门或高投入项目再上升到评审组。裁剪的是会议形式和材料篇幅，保留的是“是否启动、以什么条件启动”有据可依。具体分档标准由组织根据自身管理要求确定。
