项目立项具体怎么做：步骤、角色与交付物

项目立项要回答三件事：这件事值不值得做、做到什么程度算成功、谁在什么节点签字放行。可执行的做法是走一条五步流程：提出申请并写清问题与目标，做初步可行性与投入估算，明确范围与验收标准，组织评审形成决策记录，确认资源与计划基线后正式启动。本文按这五步给出每步的输入、动作、产出，并附字段清单、角色分工、演示示例和放行检查清单。

要点总览（TL;DR）

• 项目立项的核心是回答三个问题：值不值得做、做到什么程度算成功、谁在什么节点签字放行，五步流程把这三个问题落到可检查的产出上。
• 五步依次是：立项申请、初步可行性判断、确定范围与验收标准、组织评审形成决策记录、确认资源与计划基线后启动；每步都要有输入、负责人和完成标志。
• 立项材料按固定字段填写，重点是把业务问题写具体、目标与成功标准分开写、范围与非目标同时写明、风险与假设各自有人负责。
• 发起人、项目经理、业务负责人、技术与资源方、决策人分工明确；小项目可合并角色，但说清业务价值和组织评估两类动作都要完成。
• 放行前逐项核对检查清单，目标可衡量、范围与非目标、资源来源、评审留档、计划基线属于阻断项，未满足不建议启动。

立项五步：从申请到正式启动

立项的价值在于把“想做一个项目”变成一份可以被判断、被审批、被执行的决策材料。五步流程的作用是让每个环节都有明确的输入、负责人和可检查的产出，避免只开一次会就宣布项目开始。下表给出整体结构，后面逐条说明。

步骤	输入	动作	输出	完成标志
1. 立项申请	业务问题描述、需求来源、初步想法	写清要解决的业务问题、项目目标与预期收益	立项申请书初稿	问题、目标、收益三项均有具体表述，发起人签字
2. 初步可行性判断	立项申请书初稿	评估资源、时间、依赖关系与主要风险，给出投入量级估算	可行性说明与投入估算	关键依赖已识别，投入估算有口径和区间
3. 确定范围与验收标准	可行性说明、业务需求	划定范围边界、写明非目标、定义可验证的验收标准	范围说明与验收标准	范围与非目标成文，验收标准可逐条验证
4. 组织立项评审	申请书、可行性说明、范围与验收标准	召集相关方评审，形成通过、修改或暂缓的结论并记录	评审记录与决策结论	决策结论明确，修改意见有责任人和期限
5. 确认资源与计划基线	决策结论、资源承诺	确认人员、预算、时间安排，形成计划基线并宣布启动	计划基线、启动通知	资源来源明确，基线经确认，启动范围与评审结论一致

第一步的关键是把“业务问题”写具体。例如“报销流程平均耗时 12 个工作日，财务每月收到大量催办”比“提升报销效率”更能支撑后续判断。目标要能对应到可观察的结果，预期收益要说明受益对象和衡量方式。

第二步的可行性判断不需要做到详细设计，但要覆盖四类约束：需要哪些角色投入、大致需要多长时间、依赖哪些外部条件、主要风险是什么。投入估算给出量级和区间即可，并注明估算依据，例如参照同类项目的历史投入。

第三步常被跳过，却是后续争议的主要来源。范围要写明本期做什么，非目标要写明本期明确不做什么。验收标准按可验证的方式描述，例如“报销单从提交到审批完成的中位时长不超过 3 个工作日”，而不是“流程明显加快”。

第四步的评审要有明确的决策人。评审结论只有三种：通过、修改后再审、暂缓或不予立项。修改意见要落到具体条目、责任人和完成期限，避免出现“原则同意、细节再议”这类无法跟踪的结论。

第五步把决策转化为执行条件。资源确认包括人员投入比例、预算来源和到位时间；计划基线包括里程碑、关键交付物和第一阶段的起止时间。基线确认后发布启动通知，通知中的范围与评审通过的结论保持一致。

立项文档要写哪些字段

立项材料常见的问题是描述空泛、无法判断。把材料拆成固定字段并规定填写要点，可以让发起人知道写什么、评审人知道看什么。以下字段清单可直接作为立项申请与评审材料的模板结构。

字段	填写要点	常见问题
项目背景与业务问题	说明现状、问题表现、影响范围和发生频率，附可获取的数据	只写“业务需要”，没有具体现象和数据
目标与成功标准	目标对应业务结果，成功标准可衡量，写明衡量口径和时间窗口	目标写成功能清单，成功标准无法验证
范围与非目标	本期交付边界逐项列出，非目标明确写出	范围只有一句话，边界靠口头理解
里程碑与关键交付物	按阶段列出时间点、交付物和验收方式	只有最终上线时间，中间无可检查节点
资源需求与预算口径	人员角色与投入比例、预算科目与来源、估算依据	只写总人数，未说明投入方式和预算出处
主要风险与假设	列出影响目标达成的风险和成立前提，每项有应对措施或验证方式	风险写成通用条目，无人负责
决策事项与审批人	写明需要评审决定的问题、决策人和决策时限	评审会上临时确定议题，结论无法追溯

目标与成功标准建议分开写。目标是方向性的业务结果，例如“缩短报销周期”；成功标准是判断是否达成的具体条件，例如“上线后三个月内，报销单审批中位时长不超过 3 个工作日，超期单据占比低于 10%”。两者分开，评审时才能既看方向也看可验证性。

风险与假设要区分开：风险是可能发生的不利事件，假设是项目成立所依赖的前提。例如“财务系统接口在项目期内可提供”是假设，“接口联调排期冲突导致延期”是风险。假设需要有人验证，风险需要有人跟踪，两者都应在材料中写明责任角色。

谁在立项中做什么：角色与交付物分工

立项推进不下去，常见原因是职责不清：申请由谁写、评估由谁做、结论由谁定没有约定。下表按角色列出动作和交付物，可作为立项启动时的分工依据。

角色	主要动作	交付物
发起人	提出立项申请，说明业务价值，确认项目与业务目标的关联	立项申请书中的背景、问题与预期收益部分
项目经理	组织材料编写，协调可行性与投入评估，汇总范围与计划草案	完整的立项材料、评审议程、计划基线草案
业务负责人	确认需求真实性和优先级，参与验收标准制定	需求确认意见、验收标准确认
技术与资源方	给出技术可行性、依赖条件和投入意见	可行性说明中的技术评估与资源估算
决策人	主持或参加评审，给出通过、修改或暂缓的结论	评审决策记录与审批签字

发起人和项目经理可以是同一人，小项目中常见这种安排；角色合并时仍要保证两类动作都完成：一类是说清业务价值和问题，一类是组织材料、评估和计划。业务负责人需要实质参与验收标准的制定，只在评审会上点头确认，容易导致上线后对结果判断不一致。

决策人应当在评审前拿到材料，评审会上聚焦需要决策的问题。评审记录要写明结论类型、修改事项、责任人和期限，以及下一次检查的时间点。暂缓立项的结论同样要记录原因和重新提交的条件，便于后续追溯。

示例：一个内部系统立项怎么走完

以下为演示情景，用于说明五步流程和字段如何落地，不代表真实项目数据。

背景与申请要点。某公司财务与业务部门反映报销流程环节多、审批人经常找不到单据，员工平均等待时间较长。发起人提交立项申请，业务问题写为“报销单从提交到审批完成平均耗时约 12 个工作日，其中约四成时间消耗在审批流转等待”，目标写为“将报销审批中位时长缩短到 3 个工作日以内”，预期收益写为“减少员工催办和财务重复沟通”。

可行性与投入估算。项目经理组织评估：需要财务系统提供单据状态接口，需要两名开发人员和一名财务业务接口人投入约六周；主要依赖是财务系统接口的开放时间，主要风险是审批规则梳理不完整导致返工。投入估算按人力工时给出区间，并注明参照同类流程改造项目的经验值。

范围与验收标准。范围写为“报销单提交、审批流转、状态查询三个环节的线上化改造”；非目标写为“本期不改变报销政策，不接入新的费用标准库”。验收标准写为“上线后三个月内，审批中位时长不超过 3 个工作日；超期单据占比低于 10%；审批状态可在员工端实时查询”。

评审结论与启动确认。评审会结论为“修改后通过”，修改事项是补充审批规则清单并明确财务接口人，责任人为项目经理，期限为两周。修改完成后，决策人签字确认，资源方确认两名开发人员的投入档期，计划基线确定第一阶段六周的里程碑，随后发布启动通知。

这个示例说明两点：评审结论可以是“修改后通过”，但修改事项必须具体到条目和期限；启动确认要落在资源和时间上，仅有评审通过结论还不足以开始执行。

立项完成检查清单

判断立项是否可以放行，可以逐项核对以下检查项。标注为阻断项的条件未满足时，建议不进入启动阶段。

检查项	核对内容	是否阻断
目标与成功标准可衡量	目标对应业务结果，成功标准有口径、数值和时间窗口	是
范围与非目标已写明	本期交付边界逐项列出，非目标明确	是
资源与预算有明确来源	人员投入比例、预算科目和来源已确认	是
风险与假设已记录并有人负责	每项风险有跟踪责任人，每项假设有验证方式	否，但需在启动前补齐责任人
评审结论与审批记录已留档	结论类型、修改事项、责任人和期限完整	是
计划基线已确认	里程碑、关键交付物和第一阶段起止时间经相关方确认	是

检查时容易忽略的是“修改后通过”的后续动作：修改事项完成后是否有人复核、复核结果是否记录。建议把复核作为放行的前置条件，避免评审结论停留在纸面。另外，计划基线与评审结论的范围要一致，启动通知中不应出现评审未覆盖的新增内容。

立项材料如何在协作平台中流转与留痕

立项涉及申请书、可行性说明、评审记录和决策结论等多份材料，参与角色分散在不同部门。材料靠邮件和聊天工具传递，容易出现版本混乱、修改意见丢失、评审结论找不到的情况。把立项材料集中存放、把评审意见和修改状态纳入跟踪、把通过后的结论交接为计划与任务，是立项阶段需要落实的三类管理动作。

第一类是集中存放。立项申请、评审记录和决策结论放在同一处，按项目归档，参与方按权限查阅，减少“最新版在哪”的沟通成本。第二类是跟踪评审意见与修改状态。评审提出的修改事项逐条记录，标明责任人和期限，完成后更新状态，复核人据此判断是否满足放行条件。第三类是向计划与任务交接。立项通过后，把范围、里程碑和交付物转为可执行的工作项，让计划基线成为后续跟踪的起点。

ONES 提供项目管理、知识库、工单管理等模块，可按方案组合使用，支持研发流程活动与跨域协作过程的可追溯性。在立项场景中，可以用知识库类模块集中存放立项申请与评审材料，用项目管理模块承载评审通过后的计划与任务，使决策结论与执行计划保持对应。具体采用哪种组合，需要结合团队现有的协作方式和权限要求确定。

常见问题

立项评审结论是“修改后通过”，接下来要做什么才算完成立项？

“修改后通过”意味着评审已认可方向，但材料或条件还需补齐。接下来要做三件事：把修改事项逐条落到条目、责任人和完成期限；修改完成后由指定复核人确认，并记录复核结果；复核通过后再进入资源与计划基线确认环节。复核结果未记录时，建议不把立项视为完成，避免结论停留在纸面。

小项目人手少，发起人和项目经理由同一人担任，立项流程可以简化吗？

可以合并角色，但要保证两类动作都完成：一类是说清业务问题、目标和预期收益，另一类是组织可行性评估、汇总范围和计划草案。可以简化的是材料篇幅和评审形式，例如用一页纸立项说明替代完整模板；不宜省略的是成功标准的可衡量性、范围与非目标的书面记录，以及决策结论的留档。这些内容决定了后续执行阶段判断是否达成的依据。

立项时业务问题还说不清具体数据，能不能先启动再补？

要看缺的是什么。如果缺的是问题现象的描述，可以先用手头可获取的信息写清现状、影响范围和发生频率，并注明数据口径与后续补充计划；如果连目标结果和成功标准都无法描述，建议先做小范围调研或问题梳理，再提交立项申请。目标与成功标准属于放行检查中的阻断项，缺失时启动会让后续验收缺少判断依据。

立项通过后，评审时的范围在执行中被要求扩大，应该怎么处理？

范围变更应回到决策环节处理，而不是在执行中默认接受。做法是把新增内容写成变更申请，说明对时间、资源和验收标准的影响，由原决策人或其授权人给出结论，并更新计划基线。启动通知和计划基线应与评审结论保持一致，出现评审未覆盖的新增内容时，先补充决策记录再调整计划，便于后续追溯责任和投入。

立项材料分散在邮件和聊天工具里，集中管理时优先解决什么？

优先解决三件事：把立项申请、评审记录和决策结论按项目集中存放，确保参与方看到的是同一版本；把评审提出的修改事项逐条记录责任人和期限，并跟踪完成状态；立项通过后把范围、里程碑和交付物转为可执行的工作项，让计划基线成为后续跟踪的起点。ONES 提供项目管理、知识库等模块，可按方案组合用于材料存放与计划承载，具体组合需结合团队协作方式和权限要求确定。