项目立项怎么做：从提案到启动的步骤与交付物

项目立项是把一个想法变成可决策、可启动、可追踪的项目的过程。它要回答四件事：做不做、做什么、谁来做、怎么算做成。围绕这四个问题，立项按“立项申请—可行性论证—评审决策—启动授权”四步推进，每步留下固定交付物，最后由决策角色给出明确结论，并把目标、范围、里程碑和责任人固化下来。本文按单项目立项展开，多项目之间的准入比较与排序不在讨论范围内。

要点总览（TL;DR）

• 项目立项要回答四个问题：做不做、做什么、谁来做、怎么算做成，对应“立项申请—可行性论证—评审决策—启动授权”四步流程。
• 立项申请单至少写清背景与问题、可验证目标、范围与排除项、初步资源与周期、关键风险五个字段，目标按“对象＋指标＋时点”表述。
• 评审结论落到书面，形态为批准、有条件批准、暂缓或否决，并记录附加条件、责任人与复核时间。
• 批准后通过项目章程固化目标、范围、里程碑、角色与决策机制，目标基线作为后续变更的参照。
• 立项是否完成按检查清单逐项核对，无明确决策结论、目标不可验证、责任人缺失属于阻断项。

立项要回答的四个问题与核心流程

立项的价值在于把模糊的提议压缩成一组可判断的问题。四个问题各有对应的判断对象：做不做，看业务价值与投入是否匹配；做什么，看范围边界是否清楚；谁来做，看责任人与资源是否落实；怎么算做成，看目标是否可验证。四个问题没有答案，立项就只是走形式。

四步流程与四个问题的对应关系是：立项申请回答“想做什么、为什么做”，可行性论证回答“能不能做、值不值得做”，评审决策回答“做不做、按什么条件做”，启动授权回答“谁来做、怎么算做成”。每一步都有输入、动作和输出，缺一步就会把风险推到执行阶段。

步骤	输入	动作	输出	负责人
立项申请	业务问题、初步想法、相关数据	填写申请单，明确目标、范围、初步资源与周期	立项申请单	提案人
可行性论证	立项申请单	从业务价值、技术可行性、资源投入、风险依赖四个维度论证	可行性说明	提案人牵头，相关专业角色参与
评审决策	申请单、可行性说明	组织评审会，逐项质询，形成结论	评审记录与决策结论	决策角色（如项目发起人或评审委员会）
启动授权	决策结论、评审意见	编写项目章程，确定目标基线，召开启动会	项目章程、目标基线、启动会记录	项目经理与项目发起人

需要区分单项目立项与多项目准入比较。单项目立项判断的是“这一个项目该不该启动”，结论是批准、有条件批准、暂缓或否决。多项目准入比较判断的是“多个候选项目之间先做哪个”，涉及优先级排序和资源分配，属于项目组合管理的范畴。两者使用部分相同的材料，但决策口径不同，不应在同一场评审里混用。

立项申请单怎么写：必填字段与填写要点

立项申请单是后续论证和评审的唯一基础材料，写法上要满足一个标准：评审人只看申请单，就能判断这个项目值不值得进入论证。字段不求多，但每个字段都要有实质内容。

字段	填写要求	示例
背景与问题	说明当前业务或用户遇到的具体问题，附数据或事实依据	客服工单中约三成涉及订单状态查询，人工回复平均耗时较长
目标与成功标准	写成“对象＋指标＋时点”的可验证结果	上线后三个月内，订单状态类工单占比下降至一成以内
范围与不做的事	列出包含的内容，同时明确本期排除项	包含自助查询页面与工单自动分类；不包含物流轨迹对接
初步资源与周期	给出人力角色、数量与预计周期，注明估算依据	产品1人、开发2人、测试1人，预计10周，依据同类项目工时
关键风险	列出可能影响目标达成的风险及初步应对	历史工单数据质量不足，需先做数据清洗

目标写法是最容易出问题的字段。“提升客户体验”无法验证，“三个月内订单状态类工单占比降到一成以内”可以验证：对象是订单状态类工单，指标是占比，时点是上线后三个月。目标里出现多个指标时，要分清主指标和辅助指标，避免评审时无法判断优先级。

范围边界要同时写“做什么”和“不做什么”。只写包含项，执行阶段就容易不断加需求；写明排除项，评审时才能判断资源估算是否合理。排除项不是永久不做，而是本期不做，后续可以通过变更流程重新纳入。

常见填写错误有三类：目标空泛，只有方向没有指标和时点；范围无边界，包含项写成愿望清单；资源估算缺失，只写“需要若干人力”，无法判断投入是否匹配价值。申请单提交前，提案人应按这三条自查一遍。

可行性论证与评审决策怎么组织

可行性论证要覆盖四个维度，每个维度给出结论和依据，而不是罗列信息。业务价值回答收益是否真实、能否衡量；技术可行性回答现有条件下能否实现、有哪些技术难点；资源与投入回答人力、预算、时间是否可得；风险与依赖回答哪些外部条件和关联团队会影响交付。

论证材料由提案人牵头编写，相关专业角色提供输入：技术负责人确认实现路径与难点，财务或业务负责人确认收益口径，关联团队确认依赖事项的时间承诺。论证结论要写成“可行”“有条件可行”“不可行”并说明条件，避免只给描述不给判断。

角色	职责	在评审中的动作
提案人	准备申请单与可行性说明	陈述方案，回答质询
项目发起人	对业务价值负责	确认目标与收益口径，参与决策
技术负责人	对技术可行性负责	确认实现路径、难点与工作量
资源管理方	对人力与预算负责	确认资源可调配时间与数量
评审决策角色	对是否启动负责	给出批准、有条件批准、暂缓或否决的结论

评审结论有三种形态。批准表示按申请方案启动；有条件批准表示启动，但需在限定时间内满足附加条件，例如完成数据清洗或确认某依赖团队的排期；暂缓表示当前不启动，待条件变化后重新提交；否决表示不启动，并记录理由，避免同一提案反复提交。三种形态都要落到书面结论，口头同意不算决策。

评审记录应留存以下证据：参会人员与角色、评审时间、申请单与可行性说明的版本、质询问题与答复要点、决策结论及其依据、附加条件与责任人、下次复核时间（适用于暂缓或有条件批准）。记录的作用是让后续执行阶段能追溯“当初为什么这样定”。

启动授权：项目章程与目标基线怎么定

评审批准只代表可以启动，启动授权要把批准结论转化为执行阶段可用的基线。项目章程是这一转化的载体，应包含目标、范围、里程碑、角色与决策机制五部分内容。目标直接引用申请单中通过评审的版本；范围写明包含项与本期排除项；里程碑给出关键节点与时间；角色明确项目经理、发起人及各职能责任人；决策机制说明变更、升级和争议由谁裁定。

基线要素	内容要求	后续变更方式
目标基线	主指标、辅助指标、衡量时点与口径	指标或时点调整需走变更评审
范围基线	包含项清单与本期排除项	新增范围需评估对周期与资源的影响
里程碑基线	关键节点、交付物与时间	节点顺延需说明原因并同步关联方
责任基线	各角色负责人与职责边界	责任人变更需更新章程并通知相关方

目标基线的作用是给后续变更提供参照。执行阶段出现需求增加、周期压缩或指标调整时，判断依据是“相对基线变了什么”，而不是凭印象讨论。基线一经确认，调整就要走变更流程并留下记录，这样项目结束时才能说清目标是否达成、偏差从何而来。

启动会的输入是项目章程与目标基线，产出是各方对目标、范围、里程碑和分工的确认，以及首批工作项的分配。启动会不是宣讲会，要留出时间让执行角色提出疑问，把章程中不清楚的地方当场澄清并更新文档。

立项材料与执行工作项的衔接方式，是把章程中的里程碑拆成可跟踪的工作项，把目标基线作为验收依据挂在项目上，把申请单、可行性说明、评审记录作为项目文档归档。这样执行阶段查看项目时，能同时看到“当初批准了什么”和“现在做到哪一步”。在ONES中，项目可以承载里程碑与工作项，文档模块可以归档立项申请、评审记录和项目章程，评审结论与目标基线在同一协作空间内流转，便于执行阶段对照追溯。

示例：一个立项从申请到启动的完整走法

以下为演示情景。某公司客服部门提出一个想法：减少人工回复订单状态查询的工作量。提案人按流程推进立项。

申请单的关键字段这样填写：背景为客服工单中订单状态查询占比偏高，人工回复耗时较长；目标为上线后三个月内，该类工单占比降至一成以内，人工回复平均时长同步下降；范围为自助查询页面与工单自动分类，本期不包含物流轨迹对接；资源为产品1人、开发2人、测试1人，预计10周；关键风险为历史工单分类数据质量不足。

可行性论证阶段，技术负责人确认自助查询页面可实现，工单自动分类依赖历史数据训练，数据清洗需要额外两周；资源管理方确认开发人力可在两周后到位；业务方确认收益口径按工单占比计算。评审会上出现争议：有评审人认为数据清洗应纳入本期范围，否则目标无法验证；提案人认为清洗属于前置准备，不应占用项目周期。最终结论为有条件批准：启动项目，但需在启动后两周内完成数据清洗并提交结果，否则目标基线顺延复核。

启动授权阶段，项目章程写入目标基线（工单占比降至一成以内，上线后三个月衡量）、范围基线（含自助查询与自动分类，不含物流轨迹）、里程碑（数据清洗完成、页面上线、三个月效果评估）和角色分工。启动会上，各方确认了里程碑时间，项目经理把三个里程碑拆成工作项，将评审记录与章程归档到项目文档中。后续如要增加物流轨迹对接，需按章程中的变更机制提交评审。

立项完成检查清单

判断立项是否真正走完，可以逐项核对下表。任何一项不通过，立项都不算完成。

检查项	通过标准	负责人
申请单完整性	背景、目标、范围、资源、风险五个字段均有实质内容	提案人
可行性论证覆盖度	业务价值、技术可行性、资源投入、风险依赖四个维度均有结论和依据	提案人
决策结论明确性	有书面结论，属于批准、有条件批准、暂缓或否决之一，附依据	评审决策角色
评审记录留存	参会角色、质询要点、附加条件与责任人、复核时间齐全	评审组织者
章程内容完整	目标、范围、里程碑、角色、决策机制五部分齐全	项目经理
目标可验证	目标包含对象、指标、时点，衡量口径无歧义	项目经理与发起人
范围有边界	包含项与本期排除项均已列明	项目经理
责任人落实	项目经理、发起人及各职能责任人均已确认	项目发起人
材料与工作项衔接	里程碑已拆为工作项，立项文档已归档到项目	项目经理

三类阻断项需要特别关注：没有明确决策结论，只有会议纪要中的倾向性意见；目标不可验证，无法在项目结束时判断是否达成；责任人缺失，章程中角色空缺或未获本人确认。出现任一阻断项，应回到对应步骤补齐，再进入执行阶段。

常见问题

立项评审给了“有条件批准”，附加条件没按时完成怎么办？

有条件批准意味着项目已启动，但目标基线或范围基线依赖附加条件成立。条件到期未完成时，应由项目经理把情况提交原评审决策角色复核，而不是自行默认条件满足。复核通常有三种处理：条件延期并同步调整相关里程碑；按未满足条件的状态重新界定目标基线；转为暂缓，待条件具备后重新提交。无论哪种处理，都要更新评审记录和项目章程，让执行团队看到当前生效的基线版本。

立项申请被否决后，同一个想法还能再提吗？

可以再提，但要有新的依据。否决结论应记录理由，例如收益口径不成立、资源无法调配或技术路径风险过高。再次提交时，申请单需要针对原否决理由给出变化说明：是业务数据更新了、资源条件改变了，还是方案范围做了缩减。把否决理由和新依据放在一起，评审才能判断这是新情况还是重复提案，避免同一材料反复占用评审时间。

项目立项和多个项目之间的准入比较，材料能共用吗？

部分材料可以共用，决策口径要分开。立项申请单、可行性说明中的业务价值与资源估算，对单项目立项和多项目比较都有参考价值。区别在于：单项目立项判断“这一个项目该不该启动”，结论是批准、有条件批准、暂缓或否决；多项目准入比较判断“几个候选项目先做哪个”，涉及优先级排序和资源分配。两类决策放在同一场评审里，容易出现“项目本身可行但因排序靠后被否”的混淆，建议分开组织、分别记录结论。

小项目也要走完整的四步流程吗？

流程可以裁剪，判断依据不能省。投入小、周期短、影响范围有限的项目，可以把可行性论证与评审决策合并为一次简短评审，申请单也可以精简字段。但四个问题仍需有答案：为什么做、做到什么程度、谁负责、怎么算完成。尤其目标的可验证性和责任人确认不宜省略，否则执行阶段无法判断项目是否达成，也无法追溯决策依据。裁剪的是文档篇幅和会议形式，不是决策本身。

立项材料归档后，执行阶段还需要维护吗？

需要，重点是保持“批准版本”和“当前版本”可区分。立项申请单、可行性说明、评审记录属于决策依据，应作为历史版本归档，不再随意修改；项目章程和目标基线会随变更流程更新，每次调整都要留下变更记录并注明生效时间。执行阶段查看项目时，能同时看到当初批准的目标和当前生效的基线，项目结束复盘时才能说清偏差来自哪里、由谁批准。