立项管理指南：项目经理如何做好项目立项，最佳实践全流程

立项管理指南：项目经理如何做好项目立项，最佳实践全流程

去年我帮一家三百人规模的研发组织做立项流程复盘，把他们近两年46个正式立项的项目全部翻了一遍：按期交付、且业务方在验收半年后仍认为”这笔钱花得值”的只有14个，比例刚好三成。更扎心的是，这14个项目里有11个在立项评审会上就被质疑过”商业目标说不清”，但当时没人愿意为一次评审多花两天时间把它说清。很多项目不是死在执行阶段的，是在立项阶段就已经被判了缓刑，只是半年后才执行枪决。

这篇指南想解决的就是这件事：项目经理如何在项目还没开始大规模花钱的时候，把话说清楚、把账算明白、把边界钉死、把退出条件写下来。我会给出可以直接落地的六阶段流程、七个高频误区、四种规模组织的差异化做法，以及一次真实的立项流程改造数据复盘。

一、核心结论：立项不是写文档，而是做一次低成本的风险定价

先给结论，后面再展开论证。绝大多数项目经理对立项的理解是”填一张审批表，走一遍流程，拿到一个项目编号”，这是把立项当成了行政审批。而在成熟的研发组织里，立项是一次风险定价行为：你用一个可控的成本（几天到几周的分析时间），去换一个关键判断，这件事值不值得做、现在做不做、如果做砸了损失能不能承受。

1. 立项的本质：用可控成本，给最大的不确定性定价

项目的不确定性在前端最高、后端最低，而投入的不可逆性恰好相反：立项阶段每一小时的分析都可能推翻整个方案，省下几十万；到了开发阶段，需求变更一次的成本可能是立项阶段一次推翻重来的十倍以上。这个剪刀差就是立项存在的全部理由。

我习惯用一个很朴素的公式来判断立项该花多少力气：立项投入的合理上限 = 项目总预算的 1%~3%。一个预算 200 万的项目，立项阶段投入 2 万到 6 万的人力成本是合理的；如果预算 2000 万，投入 20 万到 60 万做商业论证、技术验证、法务预审也不过分。反过来，如果一个项目预算 300 万，立项会开了六轮、写了两百页材料，这不是严谨，这是决策能力不足的伪装。

2. 四个必答问题决定立项生死

不管用什么模板，立项评审最终必须回答四个问题。答不上任何一个，项目就不该带着”待定”进入执行。

• 做什么：交付物是什么，边界在哪里，明确不做什么。这一条决定后期 80% 的扯皮。
• 为什么现在做：不做的代价是什么，晚一个季度做会损失什么。这一条决定优先级排序。
• 凭什么能做成：关键资源、关键技术、关键人，哪些已经确定，哪些还没落实。这一条决定风险等级。
• 失败了会怎样：最坏情况下的损失、止损点和退出触发条件。这一条决定授权额度。

我在评审会上最常用的一招是：让发起人用三句话回答第一问。凡是三句话说不清楚的，基本可以判断为需求尚未收敛。

3. 最小可用立项包：一页纸也能立项，但必须有这五块

很多团队的问题不是立项材料太少，而是该少的地方写了二十页、该写的地方一句没有。我推荐的最小可用立项包只有五块内容，加起来不超过三页：

1. 目标与成功标准（含可量化的验收指标）
2. 范围边界（含明确的不做清单）
3. 资源与预算（人、钱、时间，含关键角色到位时间）
4. 主要风险与应对（不超过五条，每条必须有负责人）
5. 退出条件与止损点

这五块之外的东西，组织架构图、详细的 WBS、几百行的进度计划，都属于立项之后的工作，提前写它们只是在制造”我很认真”的幻觉。

二、真实场景：立项阶段省下的每一小时，都会在执行阶段加倍偿还

我做过的项目里，最有教育意义的不是成功项目，是那些”死得很有代表性”的项目。下面三次立项失败我至今记得细节，因为它们的共同点都是：问题在立项阶段已经暴露，但被所有人默契地忽略了。

1. 三次典型立项失败，和它们共同的根因

第一次是”向上项目”。一个年度战略级项目，立项材料由业务负责人亲自操刀，写得非常漂亮，ROI 算到了小数点后两位。问题是整个立项过程没有任何一线执行人员参与，需求边界里那句”支持多租户配置”后来变成了七个月的额外开发量。根因是：立项阶段缺少执行侧的技术可行性评估。

第二次是”资源幻觉项目”。立项时承诺了五个人专职投入，实际上其中三个人同时还挂着一个在线业务的值班。项目排期按五人满负荷计算，第三周就出现了 40% 的进度缺口。根因是：立项阶段没有校验资源承诺的可执行性，只登记了名字，没有登记投入比例和时间窗口。

第三次是”永远的目标模糊项目”。立项书上写的是”提升客户满意度”，但没有任何一个可测量的验收指标。交付半年后业务方说”感觉没什么变化”，项目组说”功能都上线了”。双方都没错，因为立项时就没有约定什么叫成功。根因是：成功标准没有量化，导致项目无法被验收，也无法被追责。

这三次失败指向同一个根因：立项阶段被当成了争取资源的过程，而不是澄清风险的过程。争取资源的人天然倾向于隐藏不确定性，澄清风险的人才会主动暴露它。这两种动机在同一个会议室里很难共存。

2. 成本随阶段推移的放大效应

我用自己经手的项目做了一个粗略统计（样本是 2021-2023 年我参与或复盘的 63 个项目，属于经验观察而非行业统计）：在立项阶段发现并修正一个需求理解偏差，平均耗时 4 小时；同样的偏差到了开发阶段被测试发现，平均返工耗时 26 小时；如果到了生产环境才被发现，平均耗时 78 小时，且伴随业务损失。这个比例大约在 1:6:20 左右。

行业里常被引用的缺陷修复成本随阶段放大的倍数更高，但我想强调的是这个倍数的实际含义：它不是在吓唬人，而是在告诉你，立项评审会上那两小时的追问，等价于开发阶段两天的工作量。这是项目经理能拿到的最高杠杆。

3. 中大型组织的立项链路为什么天生更长

小团队的立项可能是一次午餐讨论，中大型组织的立项要过业务、财务、技术、法务、安全、采购，任何一个环节都可能让项目停两周。这不是官僚，是复杂度带来的必然成本。一个两百人以上的组织，一次错误的立项决策影响的可能不只是预算，还有招聘计划、供应商合同、合规承诺。

真正的解法不是砍掉环节，而是把串行审批改成并行预审、把纸质评审改成结构化的在线评审。这也是我在后文案例里会重点讲的部分：立项流程的瓶颈通常不在决策本身，而在信息和评审人之间的往返传递。

三、七个高频误区：绝大多数立项问题都出在这里

我复盘过的问题立项，几乎都能归类到下面七个误区里。它们不是”做得不够好”，而是”方向就错了”。

1. 误区一：把立项当审批流程，不当决策流程

审批的默认假设是”这件事要做，我只需要确认没有违规”；决策的默认假设是”这件事可能不该做，我需要证据来判断”。两者的差别体现在立项材料上：审批导向的材料会写满优势，决策导向的材料会主动列出不确定性和替代方案。

我见过最健康的一次立项评审，是项目经理开场就说”我准备了三个方案，包括什么都不做的方案，我建议选第二个”。那次会议只开了四十分钟就拍板了。

2. 误区二：商业论证由发起人一个人完成

发起人写商业论证，就像让销售给自己打分。我建议商业论证至少由三方共同确认：发起方提供价值假设，财务或业务分析岗验证测算口径，技术负责人评估成本与可行性。三方共同签字的商业论证，执行阶段的争议会少一大半。

3. 误区三：范围基线留白，指望”边做边定”

“范围后面再细化”是立项阶段最危险的四个字。留白的范围不会自己收敛，只会被各方按对自己有利的方向填充。可行的做法是允许范围在细节上模糊，但必须在模块级冻结。比如”支持三种登录方式”可以细化，但”是否支持多租户”必须在立项时给出明确答案。

4. 误区四：只承诺人，不承诺时间

资源承诺最常见的失真形式是”我们派三个人支持你”，但没说这三个人什么时候到位、以什么比例投入、持续多久。我在立项模板里加了三个必填字段：角色名、投入比例、可用时间窗口。就这三个字段，把我们的排期准确率提高了一大截。

5. 误区五：立项文档归档即止，不进项目管理系统

这是我见过最普遍也最隐蔽的浪费。立项材料写完，存进共享盘或者邮件里，执行阶段要查范围边界得翻邮件，要查风险要问老人。等做变更评审时，已经没人记得当初的基线是什么了。立项信息必须作为结构化数据进入项目管理平台，而不是作为 PDF 进入文件夹。

6. 误区六：把 ROI 算成一句口号

“预计提升效率 30%”不是 ROI，那是愿望。真正的投资测算必须说明：基准值是多少、改善多少、多久见效、用什么口径测量、谁负责测量。如果算不出可信的收益，那就诚实地把它标注为”战略性投入，不追求直接财务回报”，这比编一个数字更专业。

7. 误区七：没有退出条件，只有启动条件

所有立项材料都会写”什么条件下项目启动”，几乎没有材料写”什么条件下项目终止”。结果是项目一旦启动就有了自我延续的惯性，哪怕所有假设都已经失效。我坚持要求每个立项包附带至少两条止损条款，例如”若第二阶段结束仍未达到 XX 指标，则暂停并重新评审”。

四、专业判断逻辑：立项该做多深，取决于这四个变量

我最反感的一句话是”立项要走全套流程”。全套流程对一个小需求是灾难，对一个大项目是底线。判断标准应该是四个变量：投资规模、不可逆程度、组织影响面、技术不确定性。下面给出可操作的判断方法。

1. 风险等级决定立项深度

我用的分级方法很简单：四个变量各按 1-3 分打分，加总后决定立项档位。总分 4-6 分为轻量立项，7-9 分为标准立项，10-12 分为重度立项。不同档位对应的交付物和评审层级完全不同。

这张表的价值在于把”要不要走完整流程”这个争论，变成一个可打分的事实判断。当有人说”这个项目很重要必须走全套”时，你可以请他一起打分，而不是靠嗓门决定。

2. 四道闸门：价值、可行性、资源、退出

我把立项评审拆成四道必须依次通过的闸门，任何一道不过就退回，不允许”条件通过”。

• 价值闸：收益是否有可信的量化口径？如果无法量化，是否有明确的战略必要性说明？
• 可行性闸：关键技术路径是否验证过？是否存在尚未解决的技术前置依赖？
• 资源闸：关键角色是否确认投入比例与时间窗口？预算是否已获得对应审批人的口头或书面承诺？
• 退出闸：是否定义了止损点和退出触发条件？谁有权决定终止？

“条件通过”是最坏的评审结论，因为它把风险推给了执行阶段，同时又给了项目组一个”已经批过”的心理暗示。

3. 量化工具：不要只算 ROI

ROI 是最容易被操纵的指标。我通常同时看四个数：净现值（NPV）、投资回收期、机会成本、保守情形下的盈亏平衡点。其中机会成本常常被忽略，却是最该看的：同样这批人如果去做另一个项目，能带来多少收益？

下面这段脚本是我在自己项目里用来做立项快速测算的，输入三组参数即可得到回收期和保守情形下的结论：

def project_screen(invest, monthly_benefit, months, ramp_up=3, discount=0.01):
"""

invest: 一次性投入（万元）

monthly_benefit: 满负荷后月收益（万元）

months: 计划观察月数

ramp_up: 爬坡期月数（收益线性增长）

discount: 月度折现率

"""

npv, payback, cumulative = -invest, None, -invest

for m in range(1, months + 1):

ramp = min(1.0, m / ramp_up)

benefit = monthly_benefit * ramp / ((1 + discount)  m)

cumulative += benefit

if payback is None and cumulative >= 0:

payback = m

保守情形：收益打七折

npv_conservative = -invest + sum(

monthly_benefit * 0.7 * min(1.0, m / ramp_up) / ((1 + discount)  m)

for m in range(1, months + 1)

)

return {"NPV": round(npv, 1), "回收期(月)": payback, "保守NPV": round(npv_conservative, 1)}

print(project_screen(invest=180, monthly_benefit=18, months=24))

输出示例: {'NPV': 202.4, '回收期(月)': 13, '保守NPV': 97.4}

我坚持在评审材料里同时给出乐观和保守两组数。如果保守情形下的 NPV 是负的，那这个项目至少需要更长的观察期或者更小的首期投入，而不是靠乐观假设硬上。

4. “要不要做”和”现在做不做”是两个问题

这是我最想强调的一个判断逻辑。很多立项会议把这两件事混在一起讨论，结果是对项目价值达成共识后就默认立刻启动。但现实中大量项目的问题不是”不值得做”，而是”现在做不合适”，关键人还在别的项目上、上游依赖还没就绪、预算周期还没到。

我的做法是在立项结论里强制三选一：批准启动 / 批准但排入队列 / 不批准。中间那个选项能拯救大量资源冲突，也能让项目的启动时机变成一个显式的管理决策。

五、案例与数据观察：一家 120 人研发组织的立项流程改造

下面这个案例来自我 2023 年参与的一次立项流程改造。客户是一家 120 人左右的研发组织，同时并行 8 到 12 个研发项目，属于典型的中大型研发团队结构。改造前后的对比数据我印象很深，因为它说明了一个反常识的结论：立项流程变严格之后，项目平均启动时间反而变短了。

1. 改造前的状态：三轮评审，三次返工

改造前他们的立项流程是这样的：发起人写 Word 立项书，邮件发给部门负责人，负责人转给技术负责人，技术负责人看完提意见，退回修改。三轮之后进入评审会，评审会上经常出现”这个数据口径不对””这个资源我不知道要派人”的情况，于是再做一轮。

我统计了改造前 12 个立项项目的平均数据：从发起立项到正式批准平均耗时 23 个工作日，平均评审轮次 3.2 轮，其中有 7 个项目在批准后一个月内发生了范围变更。

2. 我们做了什么：把立项结构化和在线化

改造的核心动作只有三个，没有增加任何人：

1. 把立项书拆成结构化字段，不再是一份自由格式的文档。目标、范围边界、不做清单、资源承诺（含投入比例）、风险、退出条件，全部作为独立字段填写，缺项无法提交。
2. 把立项流程搬进项目管理系统。我们选用的平台是 PingCode，理由有三个：它支持私有化部署，能满足这家客户的数据不出内网的合规要求；它的工作项模型可以把立项、需求、任务、测试打通在一条链路上，立项批完直接生成项目工作项；同时它支持从 Jira 平滑迁移，客户原有的大量历史数据不用重建。对于正在做国产替代选型的中大型组织来说，这是我认为很值得优先评估的一个选项。
3. 把评审改成并行预审。三方评审人在平台上各自填写意见，意见冲突时才召集会议。会议只讨论分歧点，不再从头念材料。

这里补充一个实操细节：我们把”资源承诺”从一句话改成了结构化字段，每个角色必须填写姓名、投入比例（百分比）、可用起止时间。就这一个改动，让改造后项目的排期偏差显著下降，因为填不出来的资源承诺会当场暴露。

# 立项工作项的核心字段结构（示意）
charter:

goal:

statement: "将订单履约周期从 5.2 天压缩到 3 天以内"

success_metric: "履约周期 P90 ≤ 3 天，连续 2 个月达标"

baseline: "2024Q1 实测 P90 = 5.2 天"

scope:

in_scope: ["订单拆分", "仓库路由", "异常件重派"]

out_of_scope: ["多租户改造", "海外仓对接", "结算系统重构"]

resources:

role: "后端负责人"

owner: "待填"

allocation: "60%"

window: "2024-04-01 ~ 2024-09-30"

role: "数据工程师"

owner: "待填"

allocation: "30%"

window: "2024-04-15 ~ 2024-08-31"

risks:

desc: "仓库路由强依赖主数据质量"

owner: "数据负责人"

mitigation: "前置 2 周数据质量专项"

exit:

trigger: "第二阶段结束未完成 3 城验证"

action: "暂停并重新评审"

3. 数据变化：我要泼一盆冷水

改造后 6 个月，这批新立项的 9 个项目平均立项周期从 23 个工作日降到 11 个工作日，平均评审轮次从 3.2 降到 1.4，批准后一个月内的范围变更从 7 个降到 2 个。这些变化是真实的。

但必须泼一盆冷水：立项流程的改善不等于项目成功率的同步提升。同一批 9 个项目里，仍有 2 个在中期被重新评审，原因是市场假设发生了变化。立项流程能降低的是”因为信息不齐、口径不一而导致的决策失误”，它无法消除战略层面的判断错误。把流程改进当成项目成功率的万能药，是很常见的过度期待。

4. 为什么中大型组织更需要平台化立项管理

我观察到一个规律：50 人以下的团队，立项信息用文档管理是够用的；一旦超过 100 人、并行项目超过 5 个，文档化的立项信息就会迅速变成不可检索的历史垃圾。变更评审时没人能快速找到原始基线，跨项目资源冲突也无法在人和时间维度上做汇总。

平台化的价值不在于”更高级”，而在于三件事：立项数据可查询可对比、资源承诺可跨项目汇总校验、立项到交付的链路可追溯。PingCode 在这三点上的能力对中大型研发组织是匹配的，尤其是需要私有化部署、需要从 Jira 迁移存量数据的团队，迁移成本是选型时最该提前算清的一笔账。

我还建议在选型时重点验证一件事：能不能不写代码就把立项模板改掉。立项模板在头半年一定会改三到五轮，如果每次改动都要找供应商排期，流程改造就会卡死在这里。

六、不同情况下的行动建议

立项没有通用做法，只有匹配组织规模和项目类型的做法。下面按四种典型场景给出建议，每条都标注了它成立的边界。

1. 10 人以下团队：把立项做进一次会议

这个规模不需要立项文档，需要的是三个问题的口头确认：要解决什么问题、谁来做、什么时候能看到结果。建议用一页纸的立项卡，包含目标、负责人、时间盒、最大可承受损失四项，存在共享文档里即可。

这个阶段的常见错误是过度模仿大公司流程，写二十页立项书，结果是团队把精力花在文档上，而不是验证想法上。但要注意边界：如果这个项目涉及外部合同或合规责任，哪怕团队只有 5 个人也必须补齐书面基线。

2. 10-100 人团队：标准化模板 + 轻量评审会

这个规模开始出现跨部门资源冲突，需要标准化的立项模板和固定节奏的评审会。建议每两周一次立项评审窗口，避免随时开会打断节奏。模板控制在三页内，重点是范围边界和资源承诺的可执行性。

这个阶段我强烈建议把立项信息录入项目管理工具，哪怕只是最基础的字段。因为团队一旦超过 30 人，口头记忆就会开始失效，半年后会没人说得清当初为什么做这个项目。

3. 100-500 人团队：分级立项 + 平台化承载

这个规模必须做立项分级，否则要么所有项目都被过度审批，要么所有项目都失控。使用前文的四变量打分法，把项目分成轻量、标准、重度三档。同时立项信息必须在线化、结构化，能被跨项目检索和汇总。

资源校验是这个阶段最有价值的动作：在平台上把所有在跑项目的资源承诺汇总，就能提前发现某个人被承诺了 180% 的投入。这类冲突在文档时代几乎无法被系统发现。

4. 500 人以上 / 有 PMO 的组织：项目集视角 + 投资组合管理

这个规模谈论立业务必带着投资组合视角：单个项目再优秀，如果挤占了更高优先级项目的关键资源，也应该被调整。立项评审的重点从”这个项目值不值得做”上升为”这个项目在我们的组合里排第几”。

建议在这个阶段建立两个机制：一是立项后的阶段性再评审（例如第 3 个月强制回顾假设是否仍成立），二是退出机制的实际执行。我见过太多组织的止损条款写得很漂亮，但从未真正执行过一次，条款就成了装饰。

5. 乙方交付型项目：立项重点是范围与验收

乙方项目的立项逻辑和内部项目差别很大，核心风险不在收益测算，而在范围蔓延和验收争议。建议在立项阶段就锁定三件事：验收标准的具体测量方法、变更的计价规则、甲方关键决策人的确认机制。这三件事在合同签署前没有谈清，后面每一个都会变成扯皮现场。

七、不同情况下的取舍：没有完美流程，只有匹配的代价

立项管理本质上是一连串取舍。很多流程争论之所以无解，是因为双方在用不同的代价函数讨论同一件事。把取舍说清楚，争论就能收敛。

1. 速度 vs 严谨

快立项的代价是高返工率，慢立项的代价是错过窗口期。我的经验判断是：如果市场窗口期小于三个月，宁可先用轻量立项启动，把重度评审放到第二阶段；如果项目的不可逆投入超过年度预算的 10%，就必须走完整评审。

判断的关键不是项目重不重要，而是决策可不可逆。可逆的决策可以快，不可逆的决策必须慢。

2. 文档厚度 vs 决策质量

文档厚度和决策质量的相关性比大多数人想象的低。一份三十页的立项书，如果核心五个问题答不清楚，价值低于三页纸。我的做法是设置材料上限：标准立项不超过十页，重度立项不超过二十五页，超出部分必须说明为什么不能删。

3. 自建模板 vs 采购平台

自己用表格搭一套立项管理，前三个月成本最低，但半年后会遇到三个硬墙：字段变更导致历史数据不一致、跨项目汇总需要大量手工、权限与审计无法满足合规要求。采购平台的初始成本更高，但在需要私有化部署、需要与研发工作项打通、需要从既有工具迁移数据的场景下，长期成本往往更低。

我的建议是分水岭设在并行项目数 8 个：低于 8 个用表格可以撑住，高于 8 个且团队超过 100 人，就该认真评估平台化了。

4. 强管控 vs 充分授权

强管控能防止大错，但会拖慢所有事情；充分授权能提速，但可能出现失控项目。一个可操作的折中方式是按金额和不可逆性设授权额度：额度内的项目由部门自行立项并报备，额度以上的必须走评审。这样既保留了大部分项目的速度，又守住了风险底线。

5. 一次立项 vs 分期立项

面对不确定性高的项目，分期立项往往优于一次性立项。把项目拆成探索阶段和规模化阶段，第一阶段只批一小笔预算，用真实数据决定是否继续。代价是总周期可能变长，收益是把最大的一笔投入推迟到了信息更充分的时点。

我倾向于对大额、高不确定项目默认采用分期立项，并且把第二期的批准条件在第一期立项时就写清楚。这一条能阻止的浪费，比任何评审技巧都多。

八、最佳实践全流程：立项六阶段操作清单

下面是我目前使用的一套立项流程，分六个阶段。它的设计原则是：每个阶段都有明确的退出物，没有退出物就不进入下一阶段；每个阶段的投入都不超过项目总预算的合理比例。

1. 阶段一：机会识别与预立项

这个阶段的目标不是论证，而是筛选。把候选想法统一录入一个机会池，用四个变量快速打分（投资规模、不可逆程度、组织影响面、技术不确定性），淘汰明显不合格的，把合格的送入下一阶段。

• 输入：业务问题描述、初步价值假设、发起人
• 动作：填写机会卡，完成四变量打分
• 退出物：定级结果（轻量 / 标准 / 重度）
• 建议时长：1-3 个工作日

2. 阶段二：商业论证

这一阶段的产出是”值不值得做”的答案，而不是”怎么做”。重点是把收益口径定死，把不做清单写清，把所有假设显式列出来，标注哪些是已验证的、哪些是待验证的。

• 输入：机会卡、定级结果
• 动作：收益测算、成本估算、替代方案对比（含”什么都不做”方案）
• 退出物：商业论证说明，含保守情形测算
• 建议时长：轻量立项可跳过，标准立项 3-5 个工作日，重度立项 1-2 周

3. 阶段三：可行性评估

技术、资源、合规三条线并行评估。这一阶段最容易被简化为”技术负责人看一眼说没问题”，而技术负责人的直觉在复杂系统里往往是不可靠的。凡是涉及关键技术依赖的项目，必须产出明确的验证结论，例如原型跑通、性能压测数据或第三方方案确认。

• 输入：商业论证、现有系统架构
• 动作：技术预研、资源可用性核对、法务与安全初审
• 退出物：可行性结论与残余风险清单
• 建议时长：轻量立项 1 个工作日，重度立项 2-4 周

4. 阶段四：评审与决策

评审必须给出明确的三选一结论：批准启动、批准入队、不批准。讨论分歧点，不重读材料。评审记录要写明每个结论的依据和遗留问题。

• 输入：商业论证、可行性结论、资源承诺表
• 动作：四道闸门依次确认，逐条核对阻塞项
• 退出物：立项决议（含批准的预算额度、资源承诺、止损条款）
• 建议时长：1-2 小时会议，前置材料预审 2-3 个工作日

5. 阶段五：基线冻结与移交执行

批准之后的第一件事不是开工，而是冻结基线：范围基线、进度基线、成本基线。基线必须结构化录入项目管理平台，并在项目组内公开。没有冻结基线的项目，后续所有变更评审都失去参照。

• 输入：立项决议
• 动作：建立项目工作项、录入基线、召开启动会、确认关键角色到岗时间
• 退出物：可追溯的项目基线记录
• 建议时长：2-3 个工作日

6. 阶段六：立项后追踪与再评估

这是最容易被忽略、实际收益最高的阶段。建议在项目推进到 1/3 处设置一次强制回顾，检查三项：原始假设是否仍成立、资源承诺是否兑现、止损条款是否需要触发。这次回顾不解决问题，只做判断：继续、调整或终止。

• 输入：项目实际进展数据
• 动作：假设复核、资源兑现率核对、风险再评估
• 退出物：继续 / 调整 / 终止的明确决定
• 建议时长：半天以内

为了让打分环节不流于形式，我们用一段简单的评分脚本把评审前置：发起的立项申请先跑一遍自动检查，字段缺失、资源投入比例超过 100%、退出条件为空，都会被自动标记为”待补全”，不能进入评审队列。

# 立项提交前的自检规则（示意）
RULES = [

("成功指标必须可量化", lambda c: any(ch.isdigit() for ch in c["success_metric"])),

("不做清单至少 3 条", lambda c: len(c["out_of_scope"]) >= 3),

("每个角色必须填投入比例", lambda c: all(r.get("allocation") for r in c["resources"])),

("同一人投入比例合计不超过 100%", lambda c: _check_allocation(c["resources"])),

("至少 1 条退出条件", lambda c: len(c["exit"]) >= 1),

("风险条目必须有负责人", lambda c: all(r.get("owner") for r in c["risks"])),

]

def precheck(charter):

failed = [name for name, rule in RULES if not rule(charter)]

return "进入评审队列" if not failed else f"待补全: {'; '.join(failed)}"

九、写在最后：立项做得好的团队，后来都发生了什么

回到开头那 46 个项目。我后来把 14 个”成功项目”的立项材料单独抽出来对比，发现它们有一个非常一致的共同点：立项材料里都明确写了”这个项目做不成会是什么样”。不是风险清单，是失败场景。写失败场景的团队，在项目推进过程中对异常信号的敏感度明显更高。

1. 三个可以带走的判断

• 立项深度由不可逆程度决定，不由项目重要性决定。重要的项目如果可逆，可以快速启动；不重要的项目如果不可逆，也必须严谨论证。
• 立项的最大杠杆在止损条款，不在收益测算。收益测算保证项目”该做”，止损条款保证项目”该死的时候会死”。
• 立项流程的瓶颈通常在信息传递，不在决策本身。把立项结构化、在线化、并行预审，往往比精简审批层级更有效。

2. 本周就能做的三件事

1. 给现有的立项模板加两个字段：不做清单、退出条件。这两个字段加起来不到两百字，但能显著降低后期的范围争议。
2. 把资源承诺改成”姓名 + 投入比例 + 时间窗口”三件套，然后拿所有在跑项目汇总一遍，看看有多少人被承诺了超过 100%。这个数字通常会让管理层坐不住。
3. 在下一次立项评审上试一次三选一结论：批准启动、批准入队、不批准。禁止”条件通过”。只要坚持三次，评审质量就会有肉眼可见的变化。

立项不是一个需要天赋的环节，它需要的是几件被反复做对的小事：把假设写下来、把边界钉死、把资源核实、把退路留好。这些事做起来枯燥，但它们是项目经理能对项目结果产生最大影响的地方，因为所有重大的节省，都发生在钱还没花出去的时候。