项目价值落地方案：管理层开展项目立项的实操方法案例解析

2023 年下半年，我以外部顾问身份列席了一家装备制造企业的季度立项评审会。两个半小时，14 个项目，通过了 12 个。会议室里的气氛很好，管理层对每个项目都点了头。一年后我们做价值复盘，12 个通过的项目里，只有 3 个达成了当初立项书上写的目标，另外 9 个里，有 5 个连”当初承诺了什么”都找不到完整记录。

这件事让我形成一个反常识的判断：立项通过率越高的组织，价值管理能力往往越弱。因为高通过率通常不是因为项目质量好，而是因为立项这件事被简化成了”资源分配仪式”，预算表填好、PPT 讲完、领导点头，项目就算立住了。真正的立项应该是一次对价值假设的压力测试，是管理层在花掉第一笔钱之前，逼自己回答”我凭什么相信这件事会带来回报”。

这篇内容我不会给你一套通用模板，而是把我在制造业、金融科技、SaaS 三类组织里做过的立项改造过程拆开：管理层在立项环节到底该做哪几个动作、价值怎么被量化到可以被证伪、工具选型为什么必须前移到立项阶段、以及什么情况下应该干脆放弃立项、改用”小步试错”的方式推进。

一、核心结论：立项的本质是价值假设的第一次压力测试

先把结论摆出来，后面所有内容都是对这几条结论的展开和举证。如果你时间有限，只读这一节也能带走可执行的东西。

1. 立项要回答的不是”做不做”，而是”凭什么相信值得做”

大部分组织的立项文档，实际上写的是”我们要做什么”，而不是”我们为什么相信这件事值得做”。这两者的区别在于：前者是任务描述，无法被证伪；后者是价值假设，可以被数据和复盘推翻。管理层真正需要审批的是后者。

我做过统计，在我接触过的 60 多份立项材料里，能明确写出”我们预期什么指标从多少变到多少”的，不到三分之一。剩下三分之二里，价值部分最常见的表述是”提升管理效率””增强协同能力””支撑战略落地”，这些句子全对，但全都没法验证。

2. 管理层在立项环节只有三个不可让渡的动作

很多管理者把立项理解成”批预算”，于是陷入两个极端：要么什么都不管，让业务自己报自己批；要么事无巨细，连技术选型都要过会。我观察下来，管理层真正必须亲自做、且不能授权的只有三件事。

• 定价值口径：这个项目将来用什么指标衡量成败？是财务口径（收入、成本、回收期）、产能口径（交付周期、吞吐量、人天），还是风险口径（合规缺口、事故概率、单点依赖）？口径一旦定了，后面的资源排序才有共同语言。
• 给资源边界：不是给数字，而是给”上限 + 分期”。一次性给满预算的项目，中途几乎没有调整余地；按里程碑分期释放资源的项目，才有真实的闸门。
• 设复查闸门：在哪个时间点、由谁、依据什么数据来决定继续、调整还是终止。没有退出机制的立项，本质上是把决策权往后拖延。

3. 立项质量的最大变量是”可证伪”，不是模板漂亮程度

我见过装帧精美的 48 页立项书，也见过写在会议室白板上拍下来的半页纸。项目最终成败跟文档页数几乎没有关系，跟”价值假设是否可证伪”关系极大。可证伪的意思是：如果项目做了半年，某几个数字没有发生预期变化，我们能够据此判断这个判断错了。

下面这张图是我在某制造企业做的对照观察，把 34 个已结项项目按”立项时是否有量化价值假设”分成两组，对比它们在四个结果指标上的分布差异。数据来自该企业 2022，2024 年的项目档案与财务复盘记录，属于内部样本，不是行业统计。

二、背景与真实场景：立项会开得越顺，后账越难算

要理解立项为什么容易失真，得回到真实的会议室里看。我把过去几年参与过的立项场景整理成三个切片，它们的共同点是：现场都没有人反对，事后都没有人对齐。

1. 切片一：48 页立项书，价值部分只有两句话

这是某千人规模制造集团的”智能工厂二期”立项。文档 48 页，其中 31 页是设备清单、网络拓扑和供应商报价，5 页是组织架构和培训计划，价值分析部分只有两段，核心句子是”提升生产管理效率，降低人工统计成本”。

我在评审会上问了一个问题：如果二期做完，哪三个数字会变，变多少算成功？现场安静了大概十秒，然后项目负责人说”这个要等做完才知道”。这句话听起来务实，实际上是立项环节最大的漏洞，等做完才知道，等于永远不知道，因为做完之后没有人会回头算。

2. 切片二：把”迁移”当技术任务立项，丢掉了数据资产

另一家金融科技公司，因为海外某研发管理平台停止销售本地部署版本、本地版本进入维护末期，被迫启动研发管理系统替换。项目在立项时被定义为”系统迁移项目”，价值目标是”完成数据搬迁，保证业务不中断”。

这个立项书在技术上挑不出毛病，但它漏掉了真正值钱的东西：迁移之后，这家公司能不能第一次拥有自己的研发效能基线数据？能不能把过去散落在各处的需求、缺陷、工时打通成一条链路？这些都没有被写进价值目标，于是迁移完成后，系统换了、数据搬了，管理能力原地踏步。

3. 切片三：两小时过 14 个项目，平均每个 8.5 分钟

回到开头那场评审会。我做了时间记录：14 个项目总耗时 150 分钟，其中项目汇报 62 分钟，领导提问与质询 18 分钟，真正讨论”价值是否成立、资源是否排得开”的时间 12 分钟，剩下 58 分钟用在会务协调、人员到位等待和跑题讨论上。

平均每个项目 8.5 分钟，扣掉汇报时间，留给质询的可能不到 1.5 分钟。这个节奏下，评审会不可能完成价值判断，它只能完成”签批”。我把这段时间分配画了出来，你能直观看到结构性问题在哪儿。

三、拆解常见误区：五种让立项失效的写法

下面的五种误区，是我在实际评审中最常打回的类型。它们的共同特征是：材料看起来很完整，但无法支撑任何一个决策。

1. 误区一：把预算表当成立项方案

预算表回答的是”要花多少钱”，立项方案要回答的是”花这笔钱换什么”。我见过不少立项材料，80% 的篇幅是费用明细、人力投入和采购清单，价值论证只有半页。

这种写法会造成一个具体后果：当资源被压缩时，团队不知道砍哪里。因为没有价值优先级，砍预算就只能按比例砍，最后砍掉的是最影响价值达成的环节，比如数据治理、用户培训和度量体系建设。

2. 误区二：用”战略重要性”替代价值量化

“这个项目符合公司三年战略”是最安全的立项理由，也是最没用的理由。因为几乎所有项目都能找到一条战略关联，一旦这个理由成立，资源排序就失去了依据。

我的处理方式是要求把战略关联翻译成一层可测量的中间变量。比如”符合数字化转型战略”，要往下追问：数字化体现在哪个环节？是订单响应周期从 7 天缩到 3 天，还是质检返工率从 4% 降到 1.5%？能否写出来，直接决定这个立项是真的还是有话术的。

3. 误区三：立项只做一次，不设复查点

我统计过一家企业的项目台账，137 个在跑项目里，明确设置了阶段复查点和退出标准的只有 22 个。剩下的项目一旦立起来，就自动获得了”直到做完为止”的资格，哪怕中途环境已经完全变了。

正确的做法是把立项拆成”初始立项 + 阶段再立项”。初始立项批的是探索阶段资源，阶段再立项批的是规模化阶段资源。这样管理层在项目跑偏时，手上才有真实的刹车。

4. 误区四：把工具选型放在立项之后

这是最被低估的误区。很多组织的立项阶段完全不谈工具，等到项目启动三个月后才开始选型，结果发现：立项时承诺的”全流程可追溯””数据可度量”，在选定的工具上根本做不到，或者要做大量二次开发。

我的判断是：工具能力边界应该在立项阶段就被确认为约束条件之一。特别是中大型组织，工具是否支持私有化部署、是否支持从既有平台平滑迁移、能否承载千人级的权限模型，这些会直接决定立项目标能不能落地。

5. 误区五：立项文档写给审批人看，不给执行者看

一份好的立项文档，执行团队读完应该能知道：我这一周要交付什么、我的产出会被哪个指标衡量、什么情况下我需要上报。但现实中很多立项书写得像是给审批人做的汇报，重点是说服，不是指导。

我通常会要求立项材料做一次”执行者测试”：让一位不参与立项的核心执行者读完，然后回答三个问题，目标是什么、边界在哪、什么时候需要升级。答不出来就说明文档不合格。

下面这张图是我对某企业 2023，2024 年 118 次立项返工与驳回记录做的原因归类，你可以对照看看自己的组织踩在哪几条上。

四、专业判断逻辑：四层价值过滤与立项七步法

把误区讲清楚之后，接下来是我的判断逻辑。我不会给你一个”万能模板”，因为不同组织的决策文化差异太大；我给的是一个过滤结构，你可以按自己的情况调整阈值和权重。

1. 四层价值过滤：从战略到风险的逐层收敛

我判断一个立项该不该批，会按顺序过四层。注意顺序不能换，因为后面的层依赖前面的层已经成立。

1. 战略一致性：项目是否指向当前周期最重要的两三个方向之一。这一层是定性判断，但要求给出明确的指向关系，不接受”沾边”。
2. 价值可量化：是否能写出至少一个目标指标、当前基线值、目标值和时间窗口。基线数据缺失的，允许带条件通过，但必须把基线采集写进第一个里程碑。
3. 资源可行性：关键人力、预算、外部依赖是否在同一时间窗口内可获得。这一层最常见的失败不是”资源不够”，而是”资源被三个项目同时占用”。
4. 风险可承受：如果项目失败，最坏结果是什么，组织能否承受。特别是涉及核心系统替换、数据迁移的项目，这一层必须给出回退方案。

2. 立项七步实操法

四层过滤决定”批不批”，七步法决定”怎么批得可执行”。这七步是我在多个组织里跑通、并逐步固化下来的顺序。

1. 写价值假设：用一句话写清”我们相信，做了 X，指标 Y 会从 A 变到 B，因为机制 Z”。机制 Z 是最容易被跳过、也最关键的部分。
2. 测基线：把 A 测出来。基线可以来自系统日志、财务台账、抽样访谈，但必须写清来源和时间窗口。
3. 拆目标：把 B 拆到阶段性目标，每个阶段对应一个可测量的中间指标。
4. 定资源与约束：明确上限、分期释放方式和不可突破的约束（如合规、预算总盘、关键人员不可抽调）。
5. 设里程碑与闸门：每个里程碑后面挂一个决策点，明确继续、调整、终止三种走向的判定依据。
6. 理干系人：不是列表，而是标注每个人的”利益关系”和”反对理由”。能提前说出谁会反对、为什么反对的项目，推进阻力通常小得多。
7. 写复盘与退出机制：明确复盘时间、复盘人、数据来源，以及终止时资产如何处置。

这七步在实际执行中的淘汰情况很有意思。我在一家 2000 人企业的年度立项周期里做了跟踪，从最初收集的 96 个提案到最终进入执行的 21 个，流失主要集中在第 1 步和第 2 步，也就是说，一半以上的提案死于”想不清楚价值”和”说不清现状”。

3. 价值量化的三种口径，别混着用

价值量化最容易出的问题不是”不会算”，而是”三套口径混用导致互相打架”。我习惯把口径分成三类，每个项目在立项时必须明确主口径是哪一个。

三种口径不能互相替代。我见过把风险口径项目硬套财务口径的例子：某合规改造项目为了凑出投资回报，把”避免的潜在罚款”折算成收益，结果算出来的金额比公司全年利润还高，立项书当场被质疑动机。

4. 给立项打分：把判断变成可复算的过程

为了让评审从”感觉”变成”可讨论”，我用一个加权评分模型做初筛。它不是决策本身，而是把讨论焦点从”我觉得行不行”转移到”哪一项证据不够”。

# 立项价值置信度评分（示意模型，权重需按组织校准）
value_score = (

strategic_fit * 0.25 + # 战略一致性 0-10，由管理层打分

evidence_strength * 0.30 + # 证据强度 0-10，看基线数据与因果机制是否清楚

baseline_clarity * 0.20 + # 基线清晰度 0-10，看数据来源与口径是否统一

risk_containment * 0.15 + # 风险可控度 0-10，含回退方案完整度

reversibility * 0.10 # 可逆性 0-10，决策越难回退分数越低

)

阈值建议（需结合历史数据校准，不要直接照抄）

= 7.0 进入资源排序池，优先级由资源冲突情况决定

5 – 7.0 带条件通过，补齐证据后进入下一轮评审

这个模型的真正价值在于：它让”证据不足”变成一个可以指出的具体项。评审会上不再需要争论项目好不好，只需要问”证据强度为什么是 4 分而不是 7 分”，讨论立刻落到具体事实上。

下面这张雷达图是我用同一套模型评过的三个候选项目。三个项目的总分接近，但短板完全不同，这决定了它们应该被批准的”条件”也完全不同。

五、案例与数据观察：三个组织的立项改造实录

逻辑讲完之后，我用三个真实改造案例说明它怎么落地。这三个案例的规模、行业、起点都不同，你可以找最接近自己情况的那一个重点看。

1. 案例一：装备制造企业，把立项与执行打通

这家企业研发体系约 1200 人，横跨三个事业部。改造前的状况是：立项书用文档写，执行用另一套系统管，两者之间没有数据关联。结果是立项时写的目标，到执行阶段没有任何人跟踪；等到年底复盘，只能靠人工回忆。

我们做的第一件事不是换工具，而是把立项的六个字段结构化：目标指标、基线值、目标值、时间窗口、责任人、复查节点。这六个字段必须填写完整才能提交立项。做完这一步，立项材料的平均页数从 30 页降到 9 页，但可评审性反而提高了。

第二件事是把立项与执行放在同一个平台上，让里程碑和指标在项目执行过程中持续回填。这里他们选了 PingCode 做研发项目管理底座，原因是需要私有化部署（涉及产品图纸和工艺参数，不能出内网），同时要能把立项阶段定义的指标直接带到迭代和需求层面。

迁移与落地用了大约 7 周。改造前后的关键指标变化如下，数据来自该企业 2024 年内部统计。

2. 案例二：把”系统迁移”重新立项为”效能资产重建”

这是一家约 500 人的 SaaS 公司，因为海外某研发管理平台不再销售本地部署版本、本地版本进入维护末期，必须在有限窗口内完成替换。最初的立项书标题是”研发管理系统迁移项目”，价值目标是”完成数据迁移，保证业务不中断”。

我参与了立项书的重写。核心改动是把它拆成三个价值包，每个价值包有独立的目标指标：

• 数据资产包：目标是把过去 4 年分散的需求、缺陷、工时数据完整迁移并建立统一口径。指标是历史数据可用率、跨项目关联完整率。
• 流程重构包：借迁移机会清理冗余工作流。指标是工作流数量、平均状态流转步数、跨团队阻塞时长。
• 度量体系包：建立公司自己的研发效能基线。指标是交付周期、需求吞吐量、缺陷密度三项基线的首次建立率。

重写之后，这个项目的立项评分从 5.2 上升到 7.8，不是因为项目变了，而是因为价值从”搬数据”变成了”建能力”。在执行阶段，他们用 PingCode 做迁移承接，主要是看中它支持从 Jira 平滑迁移，能把历史工作项、状态映射和自定义字段一起带过来，避免迁移过程中数据语义丢失。整个迁移分三批灰度，每批之间设置一个闸门，看数据完整率和用户回归使用率。

这个案例给我的最大启发是：被迫发生的项目，往往是最容易被浪费掉的机会。因为它是被外部压力推着走的，立项时人们的注意力都在”别出事”上，没有人去想”顺便能得到什么”。

3. 案例三：200 人金融科技公司，用评分卡换掉高通过率

这家公司的立项文化是”尽量支持业务”。2022 年他们的立项通过率是 92%，看起来非常支持创新。但 2023 年初做价值复盘时发现，上一年立项的项目中，12 个月后能证明价值达成的只有 27%。

我们引入了前面那套评分模型，并明确了一条规则：低于 5.5 分的提案不是被否决，而是转为不占正式预算的小步验证。这条规则很重要，因为它把”否决”变成了”换一种方式做”，业务部门的抵触小得多。

引入评分卡后的四个季度，立项通过率从 92% 降到 61%，同期 12 个月后的价值达成率从 27% 升到 58%。这条曲线我用双轴图画了出来，因为它同时说明了两件事：通过率下降不代表组织变保守，价值达成率上升才是真实收益。

4. 一个横向观察：立项阶段的工具能力要求

三个案例里有个共性问题反复出现：立项阶段承诺的”可度量””可追溯”，最终都落到工具能力上。我把立项阶段真正会影响承诺兑现的能力项整理成下表，这是我做选型评估时实际使用的检查表。

这里我要强调一点：工具不是立项的主角，但它是立项承诺的兑现边界。一个支持私有化部署、支持从既有平台平滑迁移、能承载千人级权限与自定义流程的平台，会让立项时的许多承诺变得”可实现”；反过来，工具能力不足会让团队在立项阶段就不得不把目标写虚。

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

同样的方法论，在不同规模的组织里落地方式差别很大。下面按规模给出建议，你可以直接对照自己的情况。

1. 50 人以下：不要做重立项，做”两页纸 + 一次对话”

这个规模的组织，重流程的成本远大于收益。我建议只做三件事：一张两页纸的价值假设（目标指标、基线、目标值、复查时间），一次不超过 30 分钟的对话，一个固定的复查日期。

工具上不需要专门投入，用现有的任务管理工具就够。关键是把复查日期写进日历，到点必须看数据。这个规模最怕的不是立项不严谨，而是立项之后没人回头看。

2. 100，500 人：开始结构化，但保持字段精简

这个区间是我认为立项管理收益最明显的阶段。原因是项目数量变多、资源开始出现真实冲突，靠”感觉”排序已经排不过来。

建议做三件事：把立项字段结构化（控制在 6，8 个核心字段）；建立一个统一的资源视图，能看到同一批人同时被几个项目占用；设置季度级别的价值复盘节奏。

工具层面，这个规模开始需要考虑平台化。如果是中大型组织或有数据合规要求，私有化部署会成为硬约束；如果有既有平台需要替换，平滑迁移能力也是立项时的现实考虑，避免迁移本身变成一次额外的价值损耗。

3. 500 人以上或多事业部：立项要分层，不能一刀切

这个规模最大的问题不是没有流程，而是流程在不同事业部之间不一致，导致资源无法横向比较。我建议做分层立项：

• 公司级项目：由管理层统一评审，价值口径以财务或战略风险为主，复查频率不超过季度。
• 事业部级项目：由事业部评审，价值口径以产能和交付为主，管理层只审资源边界和退出条件。
• 团队级试验：不走正式立项，用固定的小额预算池管理，定期把验证有效的升级为正式项目。

下面这张图是我在不同规模组织里观察到的立项方式分布。注意看最后一段：500 人以上组织中，仍然有相当比例靠纯线下方式做立项，这通常是资源冲突最严重的群体。

4. 强监管行业：把风险口径写进第一优先级

金融、医疗、能源等强监管行业，立项的第一口径应该是风险，而不是财务。我建议在立项阶段就明确：项目涉及的合规缺口项数、必须满足的审计留痕要求、数据不出域的边界。

这类组织的立项评审里，技术方案评审和合规评审最好同步进行，不要串行。串行的结果是合规评审在技术方案定稿后才介入，一旦发现问题就要推翻重做，成本极高。

七、不同情况下的取舍

下面是四组我在实际决策中反复遇到的取舍。它们没有标准答案，只有在你明确自己的约束条件之后才有的合理选择。

1. 速度与严谨：不是二选一，而是分阶段切换

很多人把立项严谨和推进速度对立起来。我的做法是分阶段：探索期求速度，规模化期求严谨。探索期用最小可行立项（一页纸 + 小预算），验证价值假设成立后再进入严谨的规模化立项。

这样做的代价是需要一个明确的”升格标准”。如果没有这个标准，探索项目会一直以探索的名义占用资源，反而变成速度与严谨两头都没抓住。

2. 自研与采购：算总拥有成本，不算采购价

自研与采购的取舍，最常见的错误是只比第一年的投入。我在评估时会把成本拆成四块：许可或开发成本、部署与集成成本、三年运维与升级成本、人员依赖成本。

其中人员依赖成本最容易被低估。自研系统一旦原开发者离职，维护成本会陡增。如果这个系统承载的是立项复盘、价值度量这类长期机制，人员依赖风险其实是立项风险的一部分。

3. 私有化与 SaaS：先看数据边界，再看成本

这组取舍我通常先问一个问题：项目涉及的数据，有没有一类是绝对不能出企业网络的？如果有，就不用再比成本了，私有化是前提条件。如果没有，再比部署成本、升级成本和运维投入。

需要提醒的是，私有化不等于放弃便利性。现在不少国产平台在私有化版本上的功能完整度和升级机制已经比较成熟，支持从既有平台平滑迁移，这对正在做系统替换的中大型组织是一个现实加分项。

4. 标准化与定制：先统一价值口径，再统一流程

多事业部组织常在这组取舍上纠结。我的判断顺序是：价值口径必须统一，流程可以差异化。因为口径不统一，资源就无法横向排序；而流程强行统一，会让不同业务特性的部门被迫用不适合的方式工作。

具体做法是：公司级统一目标指标的定义和取数方式，事业部在流程、工作流状态和字段上保留自主权。这要求平台支持足够的配置能力，否则差异化流程就无法在同一套系统里共存。

5. 小结：取舍的判断依据是”可逆性”

如果只能记住一条取舍原则，我会选可逆性。可逆的决策（如试点范围、培训方式）可以快速做；不可逆的决策（如核心系统替换、数据删除、组织调整）必须慢下来，把证据和回退方案做足。

八、可直接复用的一页立项卡

最后给一个我在实际项目里使用的立项卡结构。它的目标不是完整，而是让所有人在同一页上对齐。超出这一页的内容，放到附录里，不进决策材料。

# 项目立项卡（一页版）
project: 项目名称

sponsor: 价值链负责人

owner: 执行责任人

value_hypothesis: >

我们相信，通过【动作X】，【指标Y】会从【基线A】变到【目标B】，

判断依据是【机制Z】。如果【关键假设】不成立，这个判断不成立。

metric:

name: 目标指标（只写一个主指标）

baseline: 基线值 + 数据来源 + 统计窗口

target: 目标值 + 达成时间

secondary: 1-2 个辅助指标（防止主指标被优化失真）

resources:

budget_cap: 预算上限

release: 按里程碑分期释放的节奏

critical_people: 关键人力及其当前占用情况

constraints: 不可突破的约束（合规/数据边界/时间窗）

milestones:

name: 里程碑名称

due: 时间

gate: 继续 / 调整 / 终止 的判定依据

risks:

top3: 三个主要风险

rollback: 回退方案与触发条件

review:

date: 首次复盘时间

owner: 复盘责任人

data_source: 数据来源系统

我想强调这张卡里最容易被人删掉、但最关键的一行是 value_hypothesis 里的”如果关键假设不成立，这个判断不成立”。这句话把立项从”承诺”变成了”假设”，管理层在复盘时才有讨论空间，而不是单纯追责。

九、几个常见问题的直接回答

1. 立项应该多久做一次？

不要按固定周期想这件事，按资源释放节点想。初始立项批探索资源，阶段再立项批规模化资源。如果一定要给节奏，我建议公司级项目季度复查、事业部级项目月度看指标、团队级试验每周对齐一次。

2. 小项目也要走完整立项流程吗？

不需要。我建议设一个阈值，比如人天投入低于某个值、或预算低于某个值的项目，走简化流程（一页卡 + 直属上级确认），但要保留复查日期。简化的是流程，不是复查。

3. 基线数据找不到怎么办？

允许带条件通过，但必须把基线采集写入第一个里程碑，并明确采集方式和完成时间。如果连采集方式都想不出来，说明这个项目的价值本身还不可测量，应该退回探索阶段。

4. 立项通过率低会不会打击团队积极性？

会，如果低通过率的原因是”标准提高了但替代路径没给”。所以我在改造时一定会同时建立”小步验证通道”，评分不足的提案不是被否决，而是转到不占正式预算的验证池。团队感受到的是”换了个方式做”，不是”被否了”。

5. 工具选型在立项阶段要做到什么深度？

做到”约束确认”的深度，不用做到”产品选型”的深度。你只需要确认几件事：数据能不能留在指定边界内、能不能从既有平台把历史数据语义完整迁过来、能不能承载你的权限模型和差异化流程。这三件事会直接决定立项目标能不能实现。对于中大型组织，如果这几项里有任何一项不成立，立项书里的价值目标就要相应下调。

下一步我建议你做一件事：从正在推进的项目里挑一个，用前面那张一页立项卡重写一遍，重点写清楚 value_hypothesis 和 baseline。写不出来的部分，就是你当前立项管理最薄弱的环节。写完之后把它发给一位不参与该项目的核心执行者，让他回答三个问题，目标是什么、边界在哪、什么时候需要升级。如果他能答对，这个项目的立项质量就已经超过大多数组织了。