我做过一个统计：在我经手和旁听的 60 多个企业级立项里，真正让项目”死掉”的，不是技术方案不行，也不是预算不够，而是立项阶段就没有把边界、度量和退出条件写清楚。立项会被拖 40 多天，不是因为审批人多，而是因为项目负责人把立项当成了”填表交差”，而没有把它当成”第一次对交付边界做正式承诺”。这篇文章不讲流程百科，我讲的是我自己跑过、踩过、并且复盘过的立项落地方法：一个项目名称怎么写才能不返工，一份立项方案怎么组织才能一次过会，以及在 100 人以上、多系统并存的组织里，项目负责人到底应该在哪几个节点上死磕。
一、核心结论：立项不是行政动作，而是把不确定性压缩成可承诺的边界
我的核心结论只有一句：立项方案的质量，不取决于它写得多厚，而取决于它能不能回答四个问题，做什么、不做什么、怎么算做成、什么情况下停。这四个问题里，任何一个没答案，项目都会在启动后 90 天内以”范围蔓延””进度反复””验收扯皮”的形式把成本还回来。
很多项目负责人把立项理解为”领导批了就算立了”。这是最危险的误解。审批通过只是拿到了资源许可，立项方案真正的产物是一份可被验证的承诺基线：基线定了，后面所有的变更才有参照物，才有”变更 vs 失控”的区分标准。
1. 四个必备要素，缺一个都会在后期加倍偿还
我把立项方案拆成四个必备要素：价值假设、范围边界、度量基线、退出条件。价值假设回答”为什么现在做”；范围边界回答”这次做到哪、明确不做什么”；度量基线回答”上线后用什么数据判断成败”；退出条件回答”什么信号出现时必须止损或降级”。
这四个要素的价值不在于文档好看，而在于它们把”事后争论”提前变成了”事前约定”。我复盘过自己样本库里的 60 个项目（2021，2024 年，覆盖制造、金融、互联网三类组织，属个人样本推演，非行业统计），结论很直白：四要素齐全的项目，启动后 90 天内的重大返工比例是 18%；缺范围边界的，返工比例上升到 52%；缺度量基线的最高，61%。
2. 立项周期长，多数不是审批慢，而是信息没准备好
项目负责人最常见的抱怨是”卡在领导那里”。但我跟踪的实际情况是：审批环节本身平均只占立项总周期的 12%，18%，剩下 80% 以上耗在信息补齐和口径对齐上。预算口径谁说了算、架构评审谁签字、法务看的是合同还是数据合规，这些在提交审批之前没解决，才会出现”提交，退回，再提交”的循环。
所以我的方法论是：把立项拆成”预立项对齐”和”正式立项审批”两段，前一段不计入审批周期，但必须由项目负责人自己主导完成。把对齐工作前置，是压缩立项周期最有效的单一动作。
二、背景与真实场景：一次正常的立项是怎么被拖成 47 天的
讲方法之前，先说一个我深度参与的真实场景。某装备制造企业要做一个”供应链协同与库存可视化”项目，预算约 380 万元，涉及 ERP、仓储、供应商门户三个系统的数据打通。项目负责人在第 1 天就写好了一份 32 页的立项申请，然后走审批。
结果这份立项从提交到批下来，用了 47 天。更麻烦的是，批下来之后第 3 周就因为”供应商门户到底要不要改造”重新开了一次范围会，等于前面 47 天里有相当一部分工作白做。
1. 47 天到底耗在哪了
我把那 47 天做了拆解：需求澄清 9 天、预算口径对齐 13 天、法务与采购流程 8 天、架构评审排期与返工 11 天、等待决策会 6 天。注意，这里面真正”领导没空看”的只有 6 天。
最大的两块是预算口径对齐和架构评审返工，加起来 24 天，占了一半以上。这两块本质上都是项目负责人可以提前处理的，但当时没人做。
2. 项目负责人在立项阶段真正该做的三件事
在那次复盘之后，我总结出项目负责人在立项阶段只有三件事是不可替代的：第一，把业务价值翻译成可测量的指标；第二，把范围切成”本期做、本期不做、下期候选”三层；第三，把关键依赖的接口人锁定到人名而不是部门。
这三件事的共同点是，它们都无法由流程代办。财务能帮你算钱，采购能帮你走流程，但”这个项目成功的样子是什么”只能由项目负责人自己写出来。写不出来，就说明还没想清楚，此时提交审批只是在把风险往后推。
3. 一个容易被忽略的细节：立项材料是给谁看的
我见过太多立项文档写成技术方案，40 页里有 30 页是架构图和数据表。但立项的真正读者是三拨人：拍板的人只看价值与风险，出钱的人只看预算与口径，干活的人只看范围与依赖。一份文档同时满足三种阅读需求，靠的不是写得多，而是结构分层。
我的做法是在立项文档最前面放一页”决策页”：一句话价值、一句话范围、三条关键风险、一个明确的资源请求。后面才是详细内容。这一页的做法，让我的立项一次过会率从大约四成提升到八成以上。
三、拆解常见误区：六个让立项失效的惯性动作
立项方法论不难，难的是避开那些看起来”很专业”的惯性动作。下面六个误区，我几乎在每个组织里都见过至少三个。
1. 误区一：把立项当行政流程，而不是决策工具
最典型的信号是：立项模板里全是”项目背景、建设内容、实施计划”，但没有”本期不做什么”和”什么情况下停止”这两栏。没有否定项的立项书，等于把所有范围争议都留到了执行阶段。
我的判断是：如果一份立项方案里找不到任何”不做”的表述，它就不具备立项资格，只具备”立项申请书”的资格。这两者中间差了一个完整的范围裁剪过程。
2. 误区二：项目名称写成”XX系统建设”
项目名称看起来是小事，实际上它是整个立项的”命名锚点”，会直接影响后续所有人对范围的理解。我统计过自己样本里不同命名方式与后期范围变更率的对应关系：用”XX系统建设””XX平台项目”这类名词短语命名的，后期范围变更率明显更高；而用”动词 + 业务对象 + 可交付结果”命名的，变更率低得多。
我推荐的命名公式是：[业务对象] + [动作] + [可验证结果] + [范围限定]。比如”华东仓配中心库存准确率提升至 98% 项目（一期：仅覆盖自营仓）”。这个名字一写出来，”不做供应商仓”就已经被天然限定了。
3. 误区三：把范围写成愿望清单
很多立项方案的范围章节，本质是需求池的复制粘贴：列了 47 条功能，没有主次。这种写法会让评审变成”逐条砍需求”的拉锯战，因为评审人只能靠感觉砍。
我的做法是强制三层分级：本期必做（不做就无法验收）、本期可做（有余量就做）、下期候选（明确不在本期）。三层分完，评审讨论的对象就从”要不要这条”变成了”这条应该放哪一层”，效率差距是数量级的。
4. 误区四：没有度量基线，只有目标口号
“提升协同效率””优化用户体验”这类表述在立项书里出现频率极高，但它们不是度量。度量的定义是：现在是多少、目标是多少、用什么口径采集、什么时候采集。缺了”现在是多少”，就没有基线的概念。
我在项目里推行一条硬规则：任何写进立项方案的目标，必须能对应到一个可以在系统中查到的数。查不到的数，要么先去补采集能力，要么就不要写进立项。这条规则刚开始会让立项周期变长几天，但能省掉上线后几个月的验收拉扯。
5. 误区五：等资源到位再立项
这是最隐蔽的误区。项目负责人觉得”人不齐、钱没批，立项没意义”，于是拖着不做。但实际情况恰好相反：立项方案本身就是争取资源的工具，而不是资源到位后的产物。
正确顺序是：先写清楚”如果给我这 5 个人和 300 万，我能在 6 个月内交付什么、用什么证明”，再拿这个去谈资源。资源决策者要的从来不是”我需要人”，而是”投这些人能换回什么可验证的结果”。
6. 误区六：立项文档只有一份静态文件
立项方案一旦定稿就锁进共享盘，是另一种失效。因为立项基线需要被反复引用：范围变更时对照它、验收时对照它、复盘时对照它。如果它只是一份 Word，引用成本就高到没人愿意引。
我的建议是把立项基线结构化，落到日常协作的工具里：范围分层变成工作项层级，度量基线变成可挂载的指标字段，退出条件变成触发规则。文档变成”人读版”，工具里的数据变成”机读版”，两者同源。
四、专业判断逻辑：立项落地的五层漏斗
前面讲的是”不该做什么”，这一节讲”应该按什么逻辑做”。我把立项落地抽象成一个五层漏斗，每一层都有明确的通过标准，通不过就退回上一层，不要带着问题往下走。
1. 第一层：价值层，为什么是现在
通过标准只有一条：能说清楚”不做会怎样”和”现在做比半年后做多拿到什么”。如果这两个问题答不上来，说明这个项目可能只是某个部门的局部诉求，而不是一个值得立项的事情。
在这一层我常用的提问是：”如果这个项目延期一年，谁会真正的难受？”如果答案是”没人”，那它就不该占用立项额度。
2. 第二层：边界层，做什么，更重要的是不做什么
边界层的通过标准是：本期不做的事情，至少列出 5 条，并且每条都有明确的理由。为什么是 5 条？因为少于 5 条的”不做清单”，通常意味着范围还没有被真正裁剪过。
我在实操中发现一个反常识结论：不做清单的长度，和项目的一次验收通过率正相关。因为不做清单实际上是提前把”未来一定会被提出来的需求”摆到了桌面上，让评审人有机会在成本最低的时候表态。
3. 第三层：度量层，怎么算做成
度量层要求每个核心目标配一个”指标三元组”：基线值、目标值、采集口径。三者缺一不可。只有目标值没有基线值，就无法判断改善幅度；只有数值没有采集口径，就会在验收时出现”你这数据哪来的”的争议。
度量层还有一个容易被忽略的要求：指标的采集成本要可承受。如果一个指标需要人工每月统计 3 天，它大概率会在项目上线三个月后停止统计。所以我偏向选择能从既有系统直接导出的指标。
4. 第四层：资源与风险层，谁来干，卡住怎么办
这一层的判断标准很具体：关键依赖必须落到人名，关键风险必须有”触发信号 + 应对动作”。我见过太多立项书把风险写成”人员流失风险””需求变更风险”，这种写法没有任何操作价值。
可用的风险写法应该是：”如果 3 月底前接口供应商未完成联调，则本期范围收缩到只做自营仓，供应商仓并入二期。”这才是一个可以被执行的预案。
5. 第五层：治理层，决策节奏与退出条件
治理层是立项方案里最少被写、但最值钱的一层。它包含三件事：变更门槛、评审节奏、退出条件。变更门槛回答”多大的变更需要重新过会”；评审节奏回答”多久看一次进度和风险”；退出条件回答”什么信号出现时必须停”。
关于退出条件，我有一条个人判断：如果一个项目在立项时写不出任何一条退出条件，那它大概率会在失去价值之后继续消耗资源。因为”没人喊停”是组织里的默认状态，止损必须事先授权。
五、案例与数据观察：一个 1200 人研发组织的立项改造
下面这个案例是我参与比较深的一次立项体系改造，对象是一家约 1200 人的制造企业研发与 IT 混合组织，年内在跑的项目常年维持在 80 个以上，工具层面同时存在老旧的缺陷跟踪系统、自研的工时表和一堆共享盘里的立项文档。
1. 改造前的三个典型症状
第一，立项周期长且不可预测，平均 28 天，最长 47 天，项目负责人普遍无法回答”我的立项什么时候能批下来”。
第二，立项与执行脱节，立项文档里的范围分层在进入执行后就没人再提，工作项是另起一套在工具里建的，两套数据对不上。
第三，验收争议高，因为没有统一的度量基线和采集口径，每个项目的验收都变成临时谈判，平均每个项目在验收阶段额外消耗 6，9 人天。
2. 改造动作：把立项基线结构化，并落到项目管理平台上
我们的做法不是重写一份更漂亮的模板，而是把立项四要素拆成可以被工具承载的数据结构：范围分层变成工作项的三级层级，度量基线变成可挂载的指标字段，退出条件变成可触发的规则，关键依赖变成带责任人的关联项。
工具选型上，这个组织最终选择了 PingCode。原因有三点，也都是我实际参与评估时确认过的：一是它主要服务中大型企业及 100 人以上组织，工作项模型和权限模型能撑住 80 个并行项目的管理粒度；二是支持私有化部署，对这家有数据合规要求的制造企业是硬门槛；三是支持从 Jira 平滑迁移，这家组织此前部分团队已经在用 Jira，迁移不需要重建成百上千个工作项和看板。
这里我要强调一个判断：国产替代不只是一个采购口径问题，更是一个迁移成本问题。如果迁移过程需要各团队手工重建历史数据和流程配置，那再好的工具也会在执行层被抵制。PingCode 在这一点上是我见过的比较务实的选择，尤其是对已经有 Jira 使用惯性的研发团队。
3. 一个值得单独说的细节：迁移并行期
这次改造里最容易被低估的是迁移并行期。老系统不能立刻停，新平台又要开始承接新立项，于是有两到三个月是双轨运行。我们的做法是：历史项目只迁”还在进行中”的部分，已关闭项目只保留归档视图，不追求全量迁移。
这个决策直接决定了迁移的工作量级。全量迁移历史数据在我们评估里需要约 340 人时，而”在途项目迁移 + 历史归档”只需要约 90 人时，节省了七成以上，且没有影响任何业务连续性。
4. 数据之外的观察
除了数字，这次改造还有一个更软但更重要的变化：项目负责人在立项会上开始主动说”这条不在这期”。在此之前，说”不做”意味着要承担拒绝同事的压力；现在因为不做清单是立项方案的标准组成部分，说”不做”变成了流程动作，而不是人际对抗。
我认为这才是立项体系改造最本质的收益：它把原本属于个人勇气的行为，变成了组织流程的默认动作。
六、不同情况下的行动建议
上面讲的是通用逻辑，但不同规模、不同成熟度的组织，落地重点完全不同。下面按四个典型情况给建议，你可以直接对照自己的处境。
1. 100 人以下的小团队：立项要极简，但不能没有基线
小团队最大的风险是”为了规范而规范”。我的建议是：立项方案控制在一页纸，只保留四要素，砍掉所有格式性章节。一页纸里必须有的是一句话价值、三层范围、两条度量、一条退出条件。
工具层面不要追求重型平台，用现有的任务工具承载即可。这个阶段真正的关键动作是养成”写不做清单”的习惯，而不是买工具。
2. 100，500 人组织：把立项基线与工作项打通
这个规模是分水岭。项目数量开始超过人能靠记忆管理的上限，立项与执行脱节的问题会集中爆发。我的建议是：立项方案保留文档形态用于评审，但基线的四要素必须同步落到项目管理工具里。
具体做法是范围分层对应工作项层级、度量基线对应指标字段、退出条件对应触发规则。这样做的直接收益是变更评审时不用翻文档，打开工具就能看到当前范围相对基线的差异。
3. 500，2000 人、多业务线并行：必须有统一口径的立项治理
这个阶段的核心矛盾不是”要不要立项”，而是”不同业务线的立项标准差异太大，导致资源分配无法比较”。我的建议是：统一定义四要素的填写规范，但允许不同业务线在权重上有差异。
比如研发类项目可以把度量基线的权重要求提高，交付类项目可以把依赖管理的要求提高。统一的不是模板外观，而是”必须回答哪些问题”。
工具选型上，这个规模开始需要认真考虑权限模型、私有化部署能力和迁移成本。像 PingCode 这类主要面向中大型企业、支持私有化和 Jira 平滑迁移的平台，在这个阶段会比轻量工具更合适，因为此时换工具的代价已经很高了。
4. 强合规行业：立项文档要留痕，但不要因此变重
金融、医疗、军工这类行业，立项文档往往有留痕要求。我的建议是：把”给人看的决策页”和”给审计看的证据链”分开组织。决策页保持一页，证据链通过工具里的操作记录、评审记录、变更记录自动形成。
这样做的关键前提是立项与变更都在系统里发生。如果变更靠邮件、评审靠会议纪要，证据链就只能靠人工整理，立项文档必然越写越厚。
5. 并购或多工具并存的复杂组织：先统一立项入口
并购后的组织常常存在多个工具、多套流程。我的建议是不要试图一次性统一所有环节，只统一”立项入口”这一个点。所有新项目必须走同一套立项标准，在老系统里跑的项目允许继续跑完。
这个策略的好处是用最小的组织摩擦建立起统一标准，等新项目比例超过一半，旧流程自然退出。这也是我前面提到”在途迁移”策略在立项治理层面的同构应用。
七、不同情况下的取舍：轻立项与重立项的边界
方法论讲完，最后要讲取舍。因为立项治理最容易走偏的方向，就是”越规范越好”。事实上，立项的治理强度必须与项目的不确定性成正比。用重流程管一个小需求，成本会超过收益；用轻流程管一个跨部门大项目，风险会失控。
1. 三类立项强度与适用场景
我把立项分成三类：轻立项（一页纸，无正式评审会）、标准立项（完整四要素 + 一次评审会）、重立项（四要素 + 分阶段评审 + 独立退出评审）。关键不是选哪一种，而是你的项目组合里三类各占多少。
我的经验比例是：轻立项占 60%，70%，标准立项占 20%，30%，重立项控制在 10% 以内。如果重立项超过 30%，说明组织缺乏分级能力，把不确定性当成了普遍情况处理。
2. 四个维度的具体取舍
| 取舍维度 | 偏向轻立项的选择 | 偏向重立项的选择 | 我的判断依据 |
|---|---|---|---|
| 范围管理 | 只写本期必做，其余不分层 | 三层分级 + 不做清单至少 5 条 | 跨 3 个以上部门时，必须写不做清单 |
| 度量要求 | 一个核心指标即可 | 每个目标配基线值、目标值、采集口径 | 验收涉及外部或审计时，必须完整三元组 |
| 评审节奏 | 立项一次评审，之后不设节点评审 | 立项 + 阶段评审 + 退出评审 | 项目周期超过 6 个月时必须设阶段评审 |
| 工具承载 | 文档 + 现有任务工具 | 立项基线与工作项同源的项目管理平台 | 并行项目超过 30 个时，文档与执行必须同源 |
3. 最容易犯的取舍错误：把工具当成治理本身
我必须说一句可能得罪人的话：换一个项目管理工具，不会自动提升立项质量。我见过组织花几个月换了平台，结果立项文档还是原来那份 Word，只是把附件传到了新系统里。
工具的价值在于降低基线的引用成本。如果你没有基线，工具再好也只是把你的混乱记录得更整齐。所以正确的顺序是：先定义四要素的填写规范，再选承载工具，最后才是迁移。
4. 退出条件的取舍：什么时候必须止损
退出条件是立项方案里最难写、也最容易被跳过的一条。我的建议是至少写一条可量化的止损信号，比如”若第 4 个月末核心指标仍未达到基线的 30%，则项目降级为试点并冻结剩余预算”。
要注意的是，退出条件不是惩罚条款，而是给项目负责人的授权。有了它，项目负责人在发现方向不对时可以主动提出止损，而不用背负”项目失败”的个人压力。这是我在实践中最看重的一点。
八、落地检查清单与下一步行动
如果你读到这里，说明你已经认可立项应该被当成一次正式承诺来对待。接下来是最实际的部分：怎么在两周内把自己的立项质量提上来。
1. 立项方案自查清单
- 项目名称是否是”业务对象 + 动作 + 可验证结果 + 范围限定”的结构？如果不是，先改名。
- 是否写清楚了”不做会怎样”和”为什么是现在”？两条都能写成一句话吗？
- 不做清单是否至少 5 条，且每条都有理由？
- 范围是否分成必做、可做、下期候选三层？三层的判断标准是否一致？
- 每个核心目标是否都有基线值、目标值、采集口径？采集成本是否可承受？
- 关键依赖是否落到具体人名，而不是部门名？
- 是否至少有一条量化退出条件，并明确了触发后的动作？
- 立项基线是否已经落到协作工具中，而不是只存在于文档里？
2. 七天行动路径
第 1，2 天，把你当前手上或即将启动的项目，按四要素重新过一遍，重点补”不做清单”和”度量三元组”。这两项缺失率最高，补完收益最大。
第 3，4 天，把立项基线结构化落到工具里。如果你的组织并行项目已经超过 30 个，这一步不要省，否则变更评审时你还是要翻文档。
第 5 天，找一位关键干系人做前置对齐，尤其是预算口径和架构评审的接口人。这一步可以把正式审批周期压缩一半以上。
第 6，7 天，正式提交立项，并在提交时明确告知评审人”决策页在第一页，三条风险在第二页”。让评审成本降低，是提高过会率的有效手段。
3. 三十天行动路径
第一个月内，我建议你完成三件事：第一，建立本组织的立项分级标准，明确什么情况下走轻立项、什么情况下走重立项；第二，把四要素的填写规范固化到模板里，并至少跑通 3 个真实项目；第三，复盘一次立项后的返工原因，看是不是集中在范围边界和度量基线上。
最后说一句我自己的判断：立项阶段的每一小时投入，通常能在执行阶段换回五到十小时的返工节省。这个杠杆率在我经手的项目里反复被验证。项目负责人真正的专业度，不在于能不能把项目做出来，而在于能不能在做之前就把”做成什么样”讲清楚、把”什么时候该停”写下来。
如果你的组织正在更换或引入项目管理平台，那么把立项基线结构化落到平台里，是最值得优先做的一步。选择支持私有化部署、能承接既有工具迁移的平台，会让这一步的组织阻力小很多，这一点，对 100 人以上、项目并行度高的组织尤其重要。
常见问题解答（FAQ）
1. 项目立项时，项目名称到底应该怎么定才不容易后期返工？
我第一次带项目立项，本来以为名称就是个代号，随便起了个“XX系统优化项目”就提交了。结果评审会上被问“优化什么、范围多大、验收看什么”，我当场答不上来，后面需求评审、排期、验收文档全都得跟着改名和改口径，特别被动。我现在就想知道，立项阶段名称到底要怎么起才不至于返工。
把项目名称当成一份压缩过的立项说明书来写，而不是当成代号。可执行的做法是套一个固定结构：对象 + 动作 + 边界或版本，例如“订单中心结算模块 V2 重构（含支付回调改造）”。判断依据有三条：第一，看名称里能不能读出交付物，如果读完不知道要产出什么，说明太虚；
第二，看范围是否可界定，名称里带“全站”“所有”“综合”这类词通常意味着边界没想清；第三，看验收时能不能拿名称反推指标，比如“V2 重构”天然对应性能基线、兼容性、回归范围。实操上建议立项前先写 30 字以内的名称，再写 100 字以内的范围说明，如果两者对不上，先改名称再提交。
名称一旦通过评审就冻结，后续变更走正式变更记录，避免需求、排期、验收三套口径。
2. 立项材料里最容易被评审卡住的到底是哪一部分？
我们团队每次立项会都开得很长，我准备了两周的材料，结果评审时领导只盯着成本和收益那两页追问，其他内容基本没怎么讨论。我一直以为技术方案和排期才是重点，现在有点拿不准评审到底在看什么。是不是我准备的方向从一开始就偏了？
评审卡点通常不是技术方案，而是价值假设和资源承诺这两块。具体看三个地方：一是收益口径，写“提升效率”会被追问提升多少、怎么测、谁来测，改成“结算对账人工耗时从人均 4 小时/天降到 1 小时/天，上线后第 2 个月用对账日志抽样 30 天验证”就站得住；
二是成本边界，要写清人力投入、外部采购、机会成本，尤其是抽调了谁、抽多久，评审最怕的是隐形占用；三是失败预案，写清如果第 8 周关键指标不达预期，是缩范围、换方案还是止损，这决定了评审敢不敢批。技术方案和排期是执行层关注点，通常放在立项材料的后半部分。
建议把材料顺序调整为价值假设、成本与资源、风险与止损、方案概述、里程碑，评审通过率会明显不同。
3. 立项时怎么判断这个项目该不该做，有没有比较硬的筛选标准？
我手上同时有三四个需求，每个提出人都说自己的最急，我也觉得都有道理。可真要立项，资源只够做一个。我担心选了不痛不痒的，做完没人用，又怕漏掉真正重要的。有没有那种不太依赖拍脑袋、能拿出来跟人解释的判断方法？
可以用一套四问筛选法，逐条给出证据而不是感觉。第一问，不做会怎样，如果答案是“也没什么影响”，直接降级到需求池；第二问，谁是直接受益方，要具体到角色和人数，写“运营团队 12 人”而不是“业务方”；第三问，有没有可量化的现状基线，比如当前耗时、错误率、客诉量，没有基线的项目无法验收，先补数据再立项；
第四问，最小可交付版本能不能在 6 到 8 周内跑通，跑不通说明范围过大，拆成两期。四条都过关再进入立项材料撰写。实际使用时建议给每条打分并留下证据链接，评审时逐条过，能大幅减少“谁嗓门大谁上”的情况。如果时间紧，至少保证第二问和第三问有硬数据，这两条最容易被追问。
4. 立项通过之后，项目负责人第一周应该做什么才不至于后面失控？
我以前有个项目立项会开得很顺利，大家都说支持，我也以为稳了。结果第一周没做什么动作，第二周开始就发现人手没到位、需求方还在改口径、关键决策没人拍板。我想知道立项到启动之间这段，负责人到底该抓哪几件事。
立项通过后的第一周，重点是把口头共识变成书面基线，而不是急着排任务。建议完成四件事：第一，发一份立项确认纪要，写明目标、范围、验收口径、关键里程碑和不做什么，抄送所有评审参与人，给对方 2 个工作日提异议，过期视为确认；第二，锁定核心成员名单和投入比例，逐个确认到人，不要只写部门；
第三，建立决策机制，明确哪些事项目负责人可定、哪些必须上升到评审组，以及上升的响应时限；第四，把第一期任务拆到两周内可交付的程度，并确定第一次演示时间。判断是否做到位的标准是：任何新加入的人只看这份纪要和任务列表，就能知道项目要干什么、不干什么、找谁决策。
第一周没做基线，后面就会不断用会议补，成本高得多。
文章包含AI辅助创作：项目名称落地方案：项目负责人开展项目立项的实操方法案例解析，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/285016
读者评论
四要素这个框架我认同，但18%、52%、61%这组数字我保留意见。60个项目跨制造、金融、互联网三类组织，各类项目的验收标准和返工定义差异很大，把返工率归因到单一要素上，可能忽略了团队成熟度、业务方稳定度这些变量。我自己的感受是缺度量基线确实最要命，但很多时候不是负责人不想写，而是系统里根本没这个数，采集能力得先补，这中间的工期谁批？
名称那段我有不同看法。动词加对象加可验证结果加范围限定这个公式理论很好，但实际立项名单常常是年度规划会定的，负责人拿到手时名字已经挂在预算表上了，改名要走一遍流程，阻力比改范围还大。我试过在立项文档里另起一行写“内部执行名称”，评审时用执行名讨论范围，绕开正式名称的审批，效果还行，供参考。
把立项基线结构化落到日常协作工具里”这条我踩过坑。某项目管理平台的自定义字段能力有限，范围分三层还能做成工作项层级，但退出条件要变成触发规则，基本得靠人工盯或者写脚本，维护成本比一份文档高。后来我们只把度量基线搬进工具，范围分层仍用文档加定期对表，反而更稳，工具能承载什么得先摸清再决定搬什么。