项目立项、项目章程与项目启动常被混用，实际对应三个先后环节：立项回答“做不做、以什么条件做”，章程把决策写成正式文件并授权，启动则宣告项目进入执行。本文按“先决策、再成文、后启动”的顺序，说明三者的定义、边界与衔接方式。
要点总览（TL;DR）
- 项目立项是组织对“这个项目要不要做、以什么条件做”作出准入决策的环节，产出是批准结论与约束条件。
- 项目章程把立项决策固化为正式文件，明确目标、范围边界、关键角色与授权范围，回答“按什么做、谁负责”。
- 项目启动发生在章程确认之后，通过启动会宣告项目开始、完成团队对齐与初始交接，回答“现在开始做”。
- 三者是“先决策、再成文、后启动”的先后关系；决策归立项，成文归章程，动员归启动，顺序颠倒会让项目在授权不清的情况下进入执行。
- 项目提案是立项的输入，项目计划在章程确定的目标与范围内编制，多项目之间的准入比较属于项目组合管理，不属于单项目立项。
项目立项、项目章程、项目启动各自是什么
三个概念指向项目前期不同性质的工作。理解它们，先看每个环节的核心动作和产出物，再看它们在时间轴上的位置。
项目立项：对准入作出决策
项目立项是组织对“这个项目要不要做、以什么条件做”作出准入决策的环节。它的核心动作是评审与决策：收集项目背景、目标设想、预期收益、初步资源需求和主要风险，由有权决策的角色判断是否投入资源。立项的产出是批准结论与约束条件，例如批准、暂缓或否决，以及预算上限、时间窗口、必须满足的前提等。立项解决的是项目管理流程的入口问题——在资源被占用之前，先确认这件事值得做、组织也做得了。
项目章程：把决策固化为正式文件
项目章程是一份正式文件，作用是把立项决策写清楚、发出去、获得授权。它通常明确项目目标、范围边界、关键角色与职责、主要交付物、高层级里程碑、成功标准以及项目经理的授权范围。章程的文件属性体现在两点：一是它经过正式确认，成为后续工作的依据；二是它向组织内外宣告这个项目已被批准，项目经理可以据此调动资源。章程回答的是“按什么做、谁负责、授权到哪里”。
项目启动：宣告开始并完成初始交接
项目启动发生在决策与章程确认之后，是把项目正式推入执行的环节。典型动作包括召开启动会、向团队和相关方宣告项目开始、介绍目标与范围、明确沟通与协作方式、完成初始任务交接。启动回答的是“现在开始做”。它不重新判断项目该不该做，也不重新定义范围，而是让参与方对已批准的目标和分工形成共同理解，把项目从文件状态推进到工作状态。
一句话区分
立项回答做不做，章程回答按什么做，启动回答现在开始做。三者是“先决策、再成文、后启动”的先后关系，顺序颠倒或相互替代，都会让项目在授权不清或共识不足的情况下进入执行。
三者的边界：哪些事归立项，哪些归章程和启动
边界清晰，环节才不会互相挤占。下面按“主要归谁、通常不包括什么”说明，并给出交叉地带的处理方式。
| 环节 | 主要归属 | 通常不包括 |
|---|---|---|
| 项目立项 | 准入判断、资源承诺、约束条件、批准结论 | 详细执行计划、任务分解、具体排期 |
| 项目章程 | 正式授权、目标与范围基线、关键角色、成功标准 | 详细进度计划、逐项任务分工、日常协作规则 |
| 项目启动 | 宣告开始、团队对齐、初始交接、协作方式确认 | 重复审批、重新论证可行性、重定范围 |
立项的边界在于“决定做不做、以什么条件做”。它需要足够的信息支撑判断，但不必产出可直接执行的详细计划。把详细排期、任务分解放进立项评审，会拉长决策周期，也让评审焦点从“值不值得做”偏移到“怎么排”。
章程的边界在于“授权与基线”。它确定目标、范围和高层级里程碑，为后续计划提供依据，但不承担详细进度安排。章程写得过细，后续变化时修改成本高；写得过粗，团队又缺少判断范围变更的依据。较实用的做法是：目标、范围边界、关键角色和成功标准写明确，具体活动留给项目计划。
启动的边界在于“宣告与交接”。启动会不是第二次审批会，它的价值是让相关方对已批准的内容形成一致理解，明确谁在什么时间做什么、通过什么方式协作。若启动会上还在争论项目该不该做，说明立项或章程环节没有收口。
交叉地带的处理可以遵循一条原则：决策归立项，成文归章程，动员归启动。立项会上可以讨论章程草案的要点，但章程的正式确认应单独完成；启动会可以介绍章程内容，但不修改章程结论。需要调整目标或范围时，走变更流程回到章程层面处理，而不是在启动会上口头改定。
从立项到启动的流程与产出如何衔接
三个环节通过产出物逐级传递。前一环节的结论是后一环节的输入，交接清楚，项目进入执行时才有稳定的依据。
立项评审的输入与决策结论
立项评审的输入通常包括项目提案、业务背景与预期收益、初步范围设想、资源需求估算、主要风险与依赖。评审的输出是一份明确的决策结论：批准、有条件批准、暂缓或否决。有条件批准时，条件本身要写清楚，例如预算上限、必须完成的前置事项、决策复核时间点。结论含糊会让后续章程缺少可写的内容。
立项结论如何转化为章程内容
章程把立项结论展开为可执行的文件表述：把批准的目标写成项目目标，把约束条件写成范围边界与前提假设，把资源承诺对应到关键角色与授权范围，把评审中识别的风险写成高层级风险说明。转化过程中若发现立项结论存在缺口，应回到决策环节补充确认，而不是在章程里自行扩大授权。
章程批准后启动会的角色与动作
章程获得确认后，启动会承担动员与交接职能。常见动作包括：介绍项目背景、目标与范围；明确角色分工与决策路径；说明里程碑与近期工作安排；确认沟通节奏、协作工具与问题上报方式；完成初始任务交接。启动会结束时，团队应能回答“我们要达成什么、我负责什么、遇到问题找谁”。
各环节的状态与产出物
| 环节 | 典型状态 | 主要产出物 |
|---|---|---|
| 项目立项 | 待评审、评审中、已批准、暂缓、否决 | 立项申请、评审记录、批准结论与约束条件 |
| 项目章程 | 草稿、待确认、已确认 | 项目章程文件、授权说明、目标与范围基线 |
| 项目启动 | 待启动、已启动 | 启动会记录、角色与分工确认、初始任务交接清单 |
这些状态和产出物需要在团队共同可见的地方流转，否则容易出现“立项已批但没人知道”“章程写完却未传达”的情况。以 ONES 为例，ONES Project 支持围绕项目计划、工作项和迭代安排协同工作，团队可以及时了解任务状态与项目进展；ONES Wiki 支持文档关联任务，并可插入 ONES Project 的工作项列表，适合把立项结论、章程文档与后续工作项放在同一处对照。对于需要按角色控制可见范围的场景，ONES Project 提供产品、项目、任务多层级权限，可按组织架构、用户组、项目角色分配。上述能力承载的是评审记录、文档与状态的流转，立项标准与章程内容仍由组织自行确定。
与项目提案、项目计划、项目验收的区别
立项容易与几个相邻概念混用。区分的关键是看每个概念在流程中承担什么职能、产出什么。
| 概念 | 职能 | 与立项的关系 |
|---|---|---|
| 项目提案 | 提出项目设想，说明背景、目标与初步方案 | 提案是立项的输入，立项是对提案作出决策 |
| 项目章程 | 固化决策，明确目标、范围与授权 | 章程是立项结论的正式成文 |
| 项目计划 | 安排进度、任务、资源与交付节奏 | 计划在章程确定的目标与范围内编制 |
| 项目启动 | 宣告开始并完成初始交接 | 启动在章程确认之后进行 |
| 项目验收 | 核对交付物与目标，确认项目收尾 | 验收与启动首尾对应，一个开启执行，一个结束交付 |
项目提案与立项的关系最容易被颠倒。提案是提出想法的一方提交的材料，立项是拥有决策权的一方给出的结论。提案写得好，不等于项目已获批准；立项被批准，也不等于提案原样通过，决策时可能附加条件或调整范围。
项目计划与章程的区别在于详细程度和用途。章程确定目标、范围边界和授权，是后续计划的依据；计划把目标拆成可执行的活动、时间与责任。章程确认后再编制计划，计划才有稳定的参照；先做详细计划再补章程，容易出现计划与授权不一致。
项目启动与项目验收构成首尾对应：启动把项目推入执行，验收确认交付完成并收尾。两者都不承担审批职能，一个是动员，一个是核对。
多项目之间的准入比较与优先级排序，属于项目组合或提案准入管理的范畴，回答的是“多个候选中先做哪个”。单项目立项回答的是“这一个项目做不做”，两者决策对象不同，不宜混为一谈。
一个具体例子与常见误解
以下为演示情景，用于说明三个环节的顺序与交接，不代表特定组织的实际流程。
从立项到启动的完整示例
某团队计划建设一套内部数据报表系统。第一步，业务负责人提交项目提案，说明现状痛点、预期收益与初步资源需求。第二步，组织立项评审，评审结论为有条件批准：预算限定在给定范围内，要求先完成数据源梳理再进入开发。第三步，项目经理依据批准结论编写项目章程，写明项目目标、范围边界（覆盖哪些报表、不覆盖哪些系统）、关键角色、里程碑与授权范围，章程经确认后生效。第四步，召开启动会，向团队与相关方介绍目标与范围，明确分工、沟通节奏与问题上报路径，完成初始任务交接。至此项目进入执行。
这个过程中，每一步的产出都成为下一步的输入：提案支撑评审，评审结论支撑章程，章程支撑启动会的内容。任何一步缺失，后续环节都会缺少依据。
常见误解一：把立项会当启动会
立项会的目的是作出准入决策，参加者主要是决策与评审角色；启动会的目的是动员与交接，参加者是执行团队与相关方。把两者合并，容易出现项目尚未批准就向团队宣告开始，或启动会上仍在争论是否该做，导致执行团队带着不确定感开工。
常见误解二：章程写完就算启动
章程确认代表授权到位，不代表团队已经对齐。章程是文件，启动是动作。缺少启动环节，团队成员可能各自理解目标与分工，执行中出现偏差才回头对照章程。章程确认后安排一次启动会，把文件内容转化为共同理解，成本不高，收益明确。
常见误解三：启动后还能随意改立项结论
立项结论中的预算上限、范围约束和前提条件是后续工作的边界。项目执行中确需调整时，应通过变更流程重新确认，而不是在团队内部口头修改。启动之后随意改动立项结论，会让章程失去依据，也让资源承诺变得不可追踪。变更本身可以发生，关键是留下记录、经过相应授权，并同步更新章程与计划。
把三个环节分开执行、按顺序交接，项目在进入执行时就具备了三样东西：一个明确的决策结论、一份可依据的授权文件、一次团队对齐的启动。这三样东西共同构成项目前期的稳定起点。
常见问题
立项已经批准，但章程迟迟定不下来，项目可以先开工吗？
不建议先开工。立项批准解决的是“做不做”，章程解决的是“按什么做、授权到哪里”。缺少章程，团队在范围边界、关键角色和授权范围上没有共同依据，执行中容易出现各自理解不同、资源调动缺少凭据的情况。
如果章程确实需要时间细化，可以先明确目标、范围边界、关键角色和成功标准这几项核心内容，形成可确认的版本，再进入启动。详细的活动安排留给项目计划，不必等计划全部编完才启动。
小项目能不能把立项、章程和启动合并成一次会议完成？
可以简化形式，但三个动作的实质内容仍要分开确认。一次会议里可以先作出准入决策，再当场确认章程的核心要素，最后完成动员与交接。前提是参会角色齐全：有决策权的人、负责执行的人和相关方都在场，且决策结论与章程内容有书面记录。
合并的风险在于讨论焦点混杂。会上既在判断值不值得做，又在安排具体任务，容易让决策被执行细节带偏。若项目规模小、参与人少、约束条件简单，合并是可行的；若涉及跨部门资源承诺或预算审批，分开进行更稳妥。
项目执行中发现立项时的预算或范围假设不成立，应该怎么处理？
应通过变更流程重新确认，而不是在团队内部口头调整。立项结论中的预算上限、范围约束和前提条件是章程的依据，改动它们意味着授权基础发生变化。
具体做法是：说明原假设为何不成立、调整后的影响范围，提交给原决策角色或相应授权层级重新确认，形成新的结论后同步更新章程与计划，并保留变更记录。这样资源承诺仍然可追踪，后续复盘也有据可查。
章程由项目经理编写，是否意味着项目经理可以自行确定项目目标？
章程的编写可以由项目经理承担，但目标与授权范围来自立项决策，不由编写者自行设定。项目经理的角色是把批准结论准确转化为文件表述，并在转化中发现缺口时回到决策环节补充确认。
如果编写过程中发现立项结论对目标或范围的表述不够清楚，正确做法是向决策角色提出澄清，而不是在章程里自行扩大或缩小授权。章程确认后，它才成为项目经理调动资源的正式依据。
启动会上有人对项目是否该做提出质疑，应该怎么回应？
启动会不承担审批职能，它的任务是动员与交接。遇到对项目必要性的质疑，可以先记录问题，说明立项决策的结论与依据，并约定在会后由相应决策角色回应或走复核流程，避免启动会变成第二次评审会。
如果质疑指向的是立项环节确实存在的缺口，例如关键假设未验证、资源承诺不明确，则应暂停推进相关交接，回到决策环节补充确认。启动会照常完成已确定部分的动员，未确定部分明确责任人和时间点。
