项目立项评估的依据需要覆盖五个方面：战略与业务、需求与范围、投入与收益、风险与约束、组织与治理。每个方面都应有可核对的材料，并明确由谁提供。把这些依据按“提出—预审—评审—结论—归档”走一遍，评审会才能围绕事实做判断，最终形成启动、暂缓或补充材料的明确结论。
要点总览（TL;DR）
- 立项评估依据按五个维度组织：战略与业务、需求与范围、投入与收益、风险与约束、组织与治理，每个维度都要有可核对材料并明确提供人。
- 范围依据要写明暂不纳入的内容，收益假设要标明来源、测算口径和不确定性，风险要落到具体依赖对象和应对动作。
- 流程按“提出—预审—评审—结论—归档”推进，预审负责材料完整性把关，结论落到启动、暂缓或补充材料后重审并写明条件。
- 提供依据与做判断的角色分开：发起人、业务负责人、技术或交付负责人、财务接口人提供事实与假设，评审组与决策人给出结论。
- 材料提交前用完成检查清单逐项核对，缺项写明原因，评审记录中的分歧和待确认事项单列并指定责任人与时限。
立项评估要回答的五个问题与对应依据
立项评估的实质是回答五个问题：这件事该不该做、要做成什么样、需要投入多少、可能卡在哪里、由谁负责并如何决策。五个问题对应五类依据，缺哪一类，评审时就容易出现“方向没问题，但说不清边界和代价”的情况。只提交一份项目简介就上会，往往会在范围、投入或风险上被反复追问，反而拖长决策时间。
下表把评估维度、需要准备的依据材料和通常的提供人对齐，可作为立项材料的组织框架。
| 评估维度 | 要回答的问题 | 依据材料 | 提供人 |
|---|---|---|---|
| 战略与业务 | 为什么现在做这件事 | 项目来源说明、要解决的业务问题、目标客户或使用对象、与年度重点工作的关系 | 发起人、业务负责人 |
| 需求与范围 | 做到什么程度算完成 | 需求来源清单、初步范围边界（含暂不纳入的部分）、验收口径 | 发起人、业务接口人 |
| 投入与收益 | 要花多少、换回什么 | 人力与费用估算、成本构成、收益或价值假设及其成立条件 | 发起人、财务或预算接口人 |
| 风险与约束 | 可能卡在哪里 | 技术可行性判断、合规要求、外部依赖、时间窗口与关键假设 | 技术或交付负责人 |
| 组织与治理 | 谁负责、谁拍板 | 项目负责人提名、决策权限说明、评审规则与变更规则 | 发起人、评审组 |
准备材料时有两点容易被忽略。一是范围依据要写出“不做什么”，只写目标容易在评审中被不断加码；二是收益假设要标明来源和不确定性，例如收益来自哪个业务环节、按什么口径测算、哪些条件不成立时收益会明显下降。把假设写清楚，评审才能判断这个项目值得承担多大风险。
从提出到结论：立项评估的操作步骤
依据齐备之后，还需要一条固定的流程把它们送进决策。建议按五个步骤推进，每一步都写明输入、动作、输出和完成标志，避免材料在多人之间来回传递却无人对完整性负责。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 提出 | 业务需求或问题描述 | 发起人填写立项申请，写明目标、范围初稿、期望启动时间 | 立项申请单 | 申请单提交至预审人 |
| 预审 | 立项申请单 | 项目管理或业务接口人对照依据清单检查完整性，缺项退回补充 | 预审意见、补充清单 | 五类依据均有材料或写明缺项原因 |
| 评审 | 完整材料、评审议程 | 按议题组织评审会，逐项核对依据，记录分歧与待确认事项 | 评审记录 | 每个维度有明确意见，待确认事项单列 |
| 结论 | 评审记录 | 决策人给出启动、暂缓或补充材料后重审的意见，并写明条件 | 决策意见 | 结论明确且附有条件说明 |
| 归档 | 申请、评审记录、决策意见 | 存入统一位置，登记后续跟踪事项 | 立项档案 | 材料可检索，后续执行可对照 |
预审环节值得单独强调。它承担的是材料完整性把关，把明显缺项挡在评审会之前，让评审时间用于讨论分歧而不是补信息。预审人退回材料时应给出具体缺项，例如“收益假设未注明测算口径”“外部依赖未列出对接方”，而不是笼统要求“再完善一下”。
评审会的组织方式直接影响结论质量。建议按五个维度依次过议题，每个维度先由提供人简述依据，再由评审组提问，记录人同步记下分歧点和待确认事项。会议结束时如果仍有未决问题，结论可以写成“补充材料后重审”，并指定补充责任人和时限，这比勉强给出启动结论更稳妥。
归档不是流程的终点形式，而是后续跟踪的基准。立项时确认的范围、投入和风险假设，在项目执行中发生偏离时，需要有原始记录可供对照，判断是正常调整还是需要重新评审。把申请、评审记录和结论放在同一处，并保持可检索，能减少后续反复翻找邮件和聊天记录的成本。在项目协作工具中，这类材料通常可以按项目建立统一入口，让申请、评审记录和结论随项目持续留存；ONES 可用于承载这类立项流程的记录与跟踪，具体配置方式以团队实际使用为准。
谁提供依据、谁做判断：角色与交付物分工
评审会变成材料朗读，通常是因为提供依据和做判断的角色没有分开。合理的分工是：业务和技术角色负责把事实和假设说清楚，评审组负责在这些依据上做取舍。下表列出常见角色、交付物和完成时点。
| 角色 | 主要职责 | 交付物 | 完成时点 |
|---|---|---|---|
| 发起人 | 说明业务问题、目标与初步范围，牵头准备申请材料 | 立项申请单 | 提交预审前 |
| 业务负责人 | 确认业务价值与优先级，判断与年度重点的关系 | 业务确认意见 | 评审会前 |
| 技术或交付负责人 | 评估技术可行性、资源缺口与外部依赖 | 技术评估说明 | 评审会前 |
| 财务或预算接口人 | 核对成本构成与收益假设的测算口径 | 投入估算与假设说明 | 评审会前 |
| 评审组与决策人 | 按评审规则逐项核对依据，给出结论 | 评审记录与决策意见 | 评审会后 |
分工落地时有两个常见问题。一是发起人独自承担全部材料，业务和技术依据由他代写，评审时无人能对假设负责；二是决策人缺席评审会，结论迟迟无法形成。前者应在预审时检查各维度是否有对应角色的确认痕迹，后者应在评审规则中明确决策人到会或书面授权的条件。
评审组的人数与构成按项目影响范围确定。影响跨部门的项目，业务、技术、财务方都应有代表；影响范围有限的项目，可以简化评审组，但依据维度不宜减少。评审规则中还应写明变更处理方式：立项后范围或投入发生多大变化需要重新评审，由谁发起，这些规则在立项时定好，比事后争论更省事。
一个立项评估材料示例
以下示例为演示情景，用于说明依据如何组织成可评审的材料，不代表真实项目数据。
背景：某团队提出对内部审批系统进行改造，希望缩短审批流转时间。发起人提交立项申请，按五个维度分块填写。
- 战略与业务：项目来源为行政部门提出的流程效率问题；要解决的是审批环节多、流转状态不透明；与年度重点工作中“内部流程优化”相关。
- 需求与范围：需求来源为近半年的流程反馈记录；初步范围包括审批节点精简和状态查询，暂不纳入移动端改造；验收口径为典型审批流程的平均流转时间下降，具体目标值待业务确认。
- 投入与收益：人力估算为两名开发人员投入约两个月，另需少量测试支持；成本主要为内部人力；收益假设为审批等待时间减少带来的效率提升，假设条件是该流程月均审批量保持当前水平。
- 风险与约束：技术可行性初步判断为可基于现有系统改造；主要依赖为与人事系统的数据对接，需对方配合排期；时间窗口受年度系统维护期限制。
- 组织与治理：提名项目负责人一名；决策权限为预算范围内由部门负责人审批；变更规则为范围扩大需重新提交评审。
评审记录：评审组提出三个疑问——验收目标值缺少依据、人事系统对接排期未确认、收益假设未说明审批量波动的影响。结论为“补充材料后重审”，要求发起人补充目标值测算依据、对接方书面排期确认，并在收益假设中补充审批量下降情形下的说明。补充材料提交后第二次评审通过，结论为启动，附条件为对接排期确认后方可进入开发。
这个示例的可迁移规律有三条：依据按维度分块填写，每个维度都能独立核对；结论写明条件，而不是只写“同意”；待确认事项单列并指定责任人，避免在会议记录中被淹没。照此结构改写自己项目的材料时，重点检查每个维度是否都有具体材料支撑，而不是只有结论性描述。
立项评估的完成检查
材料提交评审前，可用以下清单逐项核对，判断评估是否达到可决策状态。清单中的每一项都应有明确答案，无法回答的项应写明原因并列入待确认事项。
- 五个维度的依据是否都有对应材料？缺项是否写明原因和补充计划？
- 范围边界是否写明了暂不纳入的内容？验收口径是否可核对？
- 投入估算是否列出成本构成？收益或价值假设是否标明来源、测算口径和不确定性？
- 风险是否落到具体依赖对象和应对动作，而不是只写“存在一定风险”？
- 项目负责人是否提名？决策权限和变更规则是否明确？
- 结论是否明确到启动、暂缓或补充材料后重审，并写明条件？
- 评审记录中的分歧和待确认事项是否单列，是否指定了责任人和时限？
- 申请、评审记录和结论是否归档到统一位置，后续执行能否对照？
清单全部通过，说明评估材料已具备进入决策的条件；仍有缺项时，优先补齐影响结论的维度，例如投入估算和关键依赖，其余缺项可在结论中作为条件写明。立项评估的价值在于让决策建立在可核对的事实和假设上，材料完整、结论有条件、记录可追溯，这三点做到，评估就算完成。
常见问题
立项评估材料准备到什么程度可以上评审会？
判断标准是五个维度的依据都有对应材料，或对缺项写明了原因和补充计划。范围边界要包含暂不纳入的内容，投入估算要有成本构成，收益假设要标明来源和测算口径，风险要落到具体依赖对象。预审环节可以承担这道把关，把明显缺项挡在评审会之前，让会议时间用于讨论分歧。
评审会上对某个维度争议较大、无法当场形成结论怎么办？
可以把结论写成“补充材料后重审”，同时指定补充责任人和时限，并写明需要补充的具体内容。例如验收目标值缺少测算依据、外部依赖未取得对接方排期确认，都应作为待确认事项单列。勉强给出启动结论，后续执行中容易因假设不成立而返工。
小项目或影响范围有限的项目，立项评估可以简化吗？
评审组的规模和构成可以按项目影响范围调整，影响范围有限的项目不必要求业务、技术、财务方全部到会。依据维度建议保留，只是每项材料的详略程度可以降低。范围、投入、风险这几项直接决定项目能否做成，简化时优先保证这些维度有可核对的内容。
立项后范围或投入发生变化，是否需要重新评审？
这取决于立项时定下的变更规则。建议在评审规则中写明：范围扩大或投入超出多大比例需要重新评审、由谁发起、走什么流程。立项时把规则定好，执行中发生偏离时就有依据判断是正常调整还是需要回到评审环节，也能用原始立项记录做对照。
立项申请、评审记录和结论应该保存在哪里？
关键是放在统一、可检索的位置，让后续执行能对照立项时确认的范围、投入和风险假设。可以按项目建立统一入口，把申请、评审记录和决策意见随项目持续留存。使用项目协作工具承载这类流程时，具体配置方式按团队实际使用情况确定。
