立项审批管理方法大全：跨部门团队项目立项数据分析落地清单

立项审批这件事，很多团队把它做成了”填表，开会，盖章”的三段式流程，结果就是审批通过率常年维持在90%以上，可半年后复盘时发现有三成项目延期、两成项目直接砍掉。我在过去几年帮不同规模的组织梳理过立项审批链路，一个反复出现的现象是：立项审批的问题从来不是”审批太慢”，而是”提交上来的数据本来就是失真的”。审批环节只是把这些失真数据盖了一个合法的章。这篇文章不打算再罗列一遍审批流程图，而是把跨部门立项里真正决定成败的数据分析动作拆开，给出一份可以直接照着落地的清单。

一、核心结论：立项审批的成本大头不在审批环节，而在数据失真

先说结论，后面所有内容都是围绕这四个判断展开的。如果你只想记住一句话，那就是：立项审批的优化目标不是”更快地盖章”，而是”更便宜地否决”。一个组织如果能用极低成本识别出不该做的项目，它的资源利用率就会自动变好。

1. 立项审批的三个真实成本项

大部分团队在统计立项成本时，只看”审批耗时”这一个维度，也就是从提交到批复用了几天。这个数字好看，但几乎没有决策价值。真正吃资源的是另外三项。

第一项是评审人力成本。一场跨部门立项评审会，通常要拉上业务负责人、技术负责人、财务、法务、可能的交付方，一场会两小时，七个人，就是14个人时。如果这家公司一个月评审20个项目，一个月光开会就烧掉280个人时，一年3360个人时。

第二项是错误立项的沉没成本。这是最贵的一项。一个立项时被高估收益、低估工作量的项目，走到第三个月才被发现不对，此时投入的人力、采购、机会成本都已经沉没。我见过最典型的一次，是一个内部数据中台项目，立项时评估”3人4个月”，实际做到第5个月还在改需求，最后折算投入约为立项评估的3.2倍。

第三项是流程摩擦成本。跨部门立项因为涉及多个部门签字，经常出现”卡在某个部门邮箱里三天没人看”的情况。这部分成本不体现在财务报表上，但会持续消耗组织信任。

2. 一个反常识判断：立项通过率越高，治理水平可能越差

很多管理者把高通过率当成”流程顺畅”的证据。但从治理角度看，通过率长期高于85%的立项流程，通常意味着审批已经失去了筛选功能，退化成了登记功能。

原因很简单：如果每一个提交上来的项目都能通过，那么提交方就没有动力把立项数据做扎实。做扎实要花时间、要背责任，做粗糙反正也能过，理性选择就是做粗糙。久而久之，立项文档变成”为了让流程走完而写的东西”，而不是”为了让决策更准而写的东西”。

我接触过的一个团队，立项通过率是96%。听起来效率极高，但他们的项目按期交付率只有41%，且过去一年有11个项目在启动两个月内被叫停。这两个数字放在一起看，结论就很清楚了：审批环节没有承担任何筛选责任，所有筛选压力都被推到了执行阶段。执行阶段叫停的成本，是立项阶段叫停的十倍以上。

3. 跨部门立项数据分析的落点只有四件事

不要试图在立项阶段做完整的商业论证，那是浪费时间。立项阶段的数据分析，只需要回答四个问题，而且每一个问题都要有可验证的数据支撑，而不是形容词。

• 这件事不做会怎样？，验证必要性，区分”真需求”和”某个人想做的事”。
• 这件事能不能做成？，验证可行性，重点是技术路径和外部依赖是否已经确认。
• 做这件事会占掉谁的资源？，验证资源匹配度，尤其是跨部门借调的人力是否已经获得对方负责人确认。
• 做完之后怎么判断做得好不好？，验证可回溯性，立项时就要写清验收指标和复盘时间点。

这四个问题对应后面第四章要展开的”四层漏斗”。它们的共同特点是：答案必须是数据或明确的承诺，不能是主观形容。“预计能提升效率”不是立项数据，”预计把订单处理时长从平均4.2小时降到2.5小时”才是。

二、真实场景：跨部门立项为什么会变成”三方配合演戏”

抽象的道理讲完了，我们看一个具体的场景。这个场景我复现过很多次，不同公司只是人名和部门名换了，结构惊人地一致。

1. 一个百人规模企业的立项流程复盘

这是一家约180人的公司，主营业务是B端软件交付。他们的立项流程是这样的：业务部门提需求 → 填一份12页的立项申请Word → 部门负责人签字 → 转到技术负责人评估 → 转到财务评估预算 → 转回总经理审批 → 生效。

整个流程平均耗时9.5个工作日。看起来还算合理。但我跟踪了他们连续三个月的23个立项项目，发现了几个有意思的数字。

在这23个项目里，有19个通过了审批，通过率82.6%。但在这19个通过的项目中，有7个项目的实际投入人力超过了立项评估值的1.5倍，有4个项目在启动后两个月内被调整范围，有2个被彻底叫停。

更关键的发现是：这23份立项书里，只有6份写清了可量化的验收指标。其余17份的验收标准是”功能上线””系统稳定””业务满意”。而写清验收指标的6个项目，没有一个是延期的。

2. 三个部门的真实诉求其实并不一致

为什么立项数据会失真？因为填写立项书的人、评审立项书的人、执行立项书的人，诉求根本不一致。

业务部门的诉求是”先把资源拿到手”。所以他们在立项书里会倾向于高估收益、低估工作量、淡化风险。这不是道德问题，是位置决定的。

技术部门的诉求是”少接活、别背锅”。所以他们的技术评估往往偏保守，或者干脆写”需进一步调研”来把决策推回给业务方。

财务部门的诉求是”控制预算敞口”。他们关心的是这笔钱这个季度出不出得去，而不是项目能不能成。

三方诉求不一致，但流程要求三方都在同一份文档上签字，结果就是所有人都写一些不痛不痒的、不会让自己担责的话。立项书变成了一份”谁都没说错、但谁都没说清”的文件。

3. 数据在传递中被”美化”的四个节点

立项数据从提出到进入审批系统，中间会经历四次变形。理解这四次变形，比设计再复杂的审批流程都有用。

1. 第一次变形：需求方口述 → 立项书。口述时说的”大概能省不少人力”，落到纸面就变成了”预计节约人力成本约30人天/年”。这个数字没有测算依据。
2. 第二次变形：立项书 → 技术评估。技术方为了不承诺，会把”预估工期”写成区间，比如”2-4个月”。区间一旦出现，审批时就只会看下限。
3. 第三次变形：技术评估 → 财务评估。财务只核算显性成本，人力成本常常按人头平均成本粗略折算，忽略机会成本。
4. 第四次变形：多方会签 → 审批结论。每个环节只对自己那一段负责，最终结论是各段拼起来的，没有人对整体逻辑负责。

这四个节点里，最值得下功夫的是第一次和第二次。第一次决定数据的真实性下限，第二次决定数据的可信区间。

三、常见误区拆解：八个看起来正确、实际上有害的做法

下面这八条，都是我在实际项目中见到过、并且能够观察到负面结果的。它们共同的特点是：在管理直觉上说得通，在数据上站不住。

1. 误区一：把审批时长当第一指标

“审批时长”是最容易统计也最容易优化的指标，但它和立项质量几乎无关。你可以把审批时长压缩到一天，只要把所有项目都通过就行。

正确的做法是把审批时长和立项后返工率放在一起看。如果审批时长下降的同时返工率上升，说明你不是在优化流程，而是在取消流程。我建议的观测组合是：平均审批时长 + 立项后90天内范围变更率 + 立项后90天内叫停率。

2. 误区二：用统一模板代替统一口径

很多组织花大力气做了一份漂亮的立项模板，把所有字段都统一了。但字段统一不等于口径统一。同样是”预计收益”，有的部门填的是年化金额，有的填的是一次性节省，有的填的是”相当于几个人的工作量”。这三者在评审席上被当成同一类数字比较，结论必然是错的。

模板解决的是”填什么”，口径解决的是”怎么算”。后者才是立项数据分析的基础设施。一份好的立项口径说明，应该对每一个关键字段给出计算公式和取值边界。

3. 误区三：立项数据全部由提交方提供

让提交方同时提供对自己有利的数据，本身就是利益冲突。合理的做法是关键字段交叉验证：收益数据由提交方提供，参照基线由数据或财务方提供，工期数据由交付方提供，风险数据由风控或技术方补充。

实际操作中不需要搞得很重。哪怕是三个关键字段来自三个不同角色，立项数据的可信度就会明显上升。

4. 误区四：评审会当成决策会

两小时的会议里，前80分钟用来听汇报，后40分钟用来讨论和表决，这种会议结构注定做不出好决策。因为真正需要判断的部分没有时间展开。

更有效的结构是两段式：预审 + 决策。预审阶段由各专业口的人提前异步完成，只提交结论和分歧点；决策会只讨论分歧点。这样会议时长能压缩一半以上，讨论深度反而提升。

5. 误区五：只审批不回溯

这是最普遍也最致命的一条。绝大多数组织的立项审批是单向的：批了就批了，没有人回头看当初的评估准不准。

结果是立项评估永远无法校准。没有回溯的立项流程，本质上是在用同一套没被验证过的假设，反复做几十次决策。建议的做法是：每个立项项目在启动后第30天、第90天各做一次简短的偏差记录，只记三个数，实际投入、实际进度、是否偏离验收指标。

6. 误区六：把立项门槛设成”能拦住人”

有的管理者觉得立项通过率太高，于是提高门槛，加签字、加材料、加答辩。这么做短期能降低通过率，但降低的是”愿意提交申请的人”的数量，而不是”不该做的项目”的数量。

门槛应该加在验证环节，不加在材料环节。加验证意味着”你说能省30人天，请给出测算过程”，加材料意味着”再交一份PPT”。前者的边际收益是正的，后者是负的。

7. 误区七：忽略立项后的资源兑现

立项审批通过时承诺的人力，在执行阶段常常兑不了现。业务部门答应的3个开发人手，实际到位1.5个。这个问题在立项数据里往往看不出来，因为它不是一个”填错”的问题，而是一个”没写”的问题。

解决办法是在立项文档里明确资源承诺的具体形式：谁、什么时间、投入多少比例、由谁确认。含糊的”相关部门配合”是无效承诺。

8. 误区八：用工具替代规则

这是最后一条，也是我最想强调的一条。很多团队遇到立项混乱，第一反应是”上一套系统就好了”。但如果口径没统一、验证规则没定义、回溯机制没建立，上了系统只是把混乱搬到了线上，还会因为系统保留了历史记录，让混乱变得更可见、更难解释。

工具的作用是执行规则、固化数据、降低记录成本，而不是发明规则。先想清楚规则，再选工具，顺序不能反。

四、专业判断逻辑：立项数据分析的四层漏斗

前面讲了误区和场景，这一章给出一套可以直接落地的判断逻辑。我把它设计成四层漏斗，每一层都有明确的输入、判断标准和输出。核心思路是：越早淘汰无效项目，成本越低。

1. 第一层：必要性验证，解决”不做会怎样”

这一层要做的判断是：这个项目对应的需求是真实存在的吗？它的紧迫性来自哪里？

采用的判断方式是反事实提问：如果这个项目不做，会发生什么具体后果？如果答案是”影响不大”或”以后再说”，那它就不该在当前排期里。

这一层需要的输入数据包括：

• 需求来源与出现频次（例如：过去3个月被客户提及多少次）
• 不做的后果类型（合规风险 / 收入损失 / 客户流失 / 纯体验改善）
• 是否有替代方案，替代方案的代价是多少

我的经验是这一层能筛掉约15%-25%的立项申请。被筛掉的往往是”某个人觉得应该做”的项目，而不是”业务真的在疼”的项目。

2. 第二层：可行性验证，解决”能不能做成”

可行性验证的重点不是”技术上难不难”，而是关键依赖是否已经确认。我见过太多项目卡在”第三方接口还没谈好””上游数据还没有””关键人还没到位”这类问题上，而这些问题在立项阶段其实都已经显现，只是没有被写进文档。

这一层建议强制填写的字段：

1. 技术路径是否唯一？如果有多条路径，为什么选这条？
2. 外部依赖清单：每一项依赖的对接方、当前状态、最晚确认时间。
3. 关键人依赖：是否依赖某个特定个人的技能或时间？如果这个人不可用，Plan B 是什么？
4. 依赖项中”未确认”的比例。我建议把这一项作为硬性门槛，未确认依赖超过30%的项目，不应该进入排期。

3. 第三层：资源匹配度验证，解决”占谁的资源”

跨部门立项最大的坑就在这里。项目A的人力来自部门B，但部门B的负责人只是在会签栏签了字，并没有真正评估过自己的人手够不够。

这一层需要的是资源承诺的显性化。具体做法是把资源拆成：人力（谁、多少比例、多长时间）、预算（金额、科目、付款节奏）、以及机会成本（这些人和钱原本要做什么）。

第三个维度最容易被忽略，但它最能暴露问题。当你说”要占用张三60%的时间做三个月”时，必须回答”那这三个月里，张三原本负责的哪件事会停下来”。如果这个问题答不出来，说明这个资源承诺大概率是空的。

4. 第四层：可回溯性验证，解决”怎么判断做得好不好”

这一层最容易被跳过，因为它看起来不影响当下决策。但它决定了整个立项体系能不能持续改进。

可回溯性验证只需要检查三件事：验收指标是否可量化、数据从哪里取、什么时间点复盘。这三件事在立项文档里通常只需要几行字，但如果缺了，这个项目在事后就无法被评价，也就无法为下一次立项提供校准数据。

我建议的做法是在立项模板里加一个必填小节，格式如下：

验收指标：
指标名称：订单平均处理时长

当前基线：4.2 小时

目标值：≤ 2.5 小时

数据来源：订单系统 order_process_log 表，按月聚合

复盘时间：上线后第 30 天、第 90 天

复盘责任人：项目经理 + 业务方负责人

未达标处理：

若第 90 天仍高于 3.5 小时，项目组需提交偏差分析并提出收敛方案。

这段内容看起来简单，但它把”复盘”从一个道德要求变成了一个流程动作。能被自动触发的复盘，才会真的发生。

5. 四层漏斗的执行顺序为什么不能调换

有人会问，能不能先做资源匹配度验证，再做必要性验证？从成本角度看不能。必要性验证单人半小时就能完成，资源匹配度验证需要跨部门协调，成本是好几个数量级。

把便宜的动作放在前面，是漏斗设计的唯一原则。先砍掉不需要做的，再判断能不能做，再算要花多少资源，最后定怎么衡量。顺序一旦乱了，大量成本会消耗在最终会被否掉的项目上。

五、案例与数据观察：中大型企业如何把立项数据真正管起来

前面讲的是方法论。这一章讲落地载体。方法论再好，如果立项数据散落在邮件、Excel、聊天记录里，就无法做交叉验证、无法做回溯、无法做横向对比。

1. 为什么100人以上的组织需要专门的立项数据载体

50人以下的团队，立项靠沟通就够了，因为所有人都在一个房间里，信息传递损耗低。但当组织规模超过100人、跨越多个部门、存在多个并行项目时，口头和邮件同步的方式就会失效。

失效的表现有三个：第一，同一个指标在不同项目里口径不同，无法横向比较；第二，立项数据与执行数据割裂，无法做偏差分析；第三，历史立项记录无法沉淀，每次都是从零开始。

这也是为什么PingCode 这类面向中大型企业的项目管理平台，会把立项审批、需求管理、迭代执行、度量分析放在同一条数据链路上。它主要服务中大型企业及100人以上组织，这个定位本身就说明了一件事：立项数据治理是一个规模问题，人少的时候靠制度，人多了必须靠系统。

2. 私有化部署对跨部门立项数据的实际影响

跨部门立项的数据往往包含预算金额、人力成本、客户信息、技术架构依赖，这些内容在很多组织里属于不宜出内网的数据。这直接影响了工具选型。

PingCode 支持私有化部署，这一点在立项场景里不是可有可无的加分项，而是能否落地的前提。我见过的情况是：如果立项数据必须脱敏后才能进入外部系统，那脱敏过程本身就会成为新的失真源，业务方为了避免麻烦，会倾向于在立项书里少写具体数字。

数据一旦离开原环境，质量就会下降。私有化部署的价值在于让数据可以完整地留在原环境里被分析。

3. 从既有平台迁移时，立项数据如何承接

很多中大型企业已经有了一套在用的项目管理工具，可能是在Jira上做了大量定制。想换工具最大的顾虑不是功能，而是历史和配置能不能带过来。

PingCode 支持 Jira 平滑迁移，这一点在立项治理场景里很关键。因为立项数据是有历史依赖的：今年的立项评估需要参照去年的实际投入值，如果历史数据不能承接，第一年的回溯就无法开展，整个校准机制要推迟一年才能生效。

实际迁移时，我建议按这个顺序处理：先迁历史项目与工时数据，再迁审批流配置，最后迁度量看板。前两者决定能不能做偏差分析，后者决定能不能做横向对比。

4. 一组落地后的观测数据

下面这组数字来自我参与过的一个落地过程，组织规模约400人，跨5个业务部门，月均立项约18个。数据为过程观测值，不是行业统计。

这组数据里，我认为最值得关注的是通过率从82.6%降到68.3%。在很多组织里，通过率下降会被解读为”流程变严了、效率变低了”。但实际上，同期立项后90天的叫停数量从6个降到了2个。被拦在立项阶段的项目，和被叫停在执行阶段的项目，成本差了一个数量级。

5. 一个具体的失败案例和一个具体的成功案例

失败的那个项目，是做一套内部报表自动化。立项书上写”预计节约报表制作人力约15人天/月”。这个数字是怎么来的？是提出人按”每周报表大概花半天”估的。但实际统计后发现，真正的报表制作时间分散在4个人身上，每人每月约1.5天，合计6人天/月，不到立项评估的一半。

问题不在于项目做不做得成，而在于收益被高估了2.5倍，导致这个项目在优先级排序里被排到了一个本该更靠前的基础设施改造之前。半年后这件事被复盘时，提出人自己也承认当时是”顺手估的”。

成功的那个项目，是一个跨部门的数据对接。它在立项阶段做了一件很特别的事：把所有的外部依赖列了张表，每一项都标注了”已确认/待确认/未启动”，并给出了最晚确认时间。结果这个项目在执行阶段只延期了3天，原因是有一项依赖在预期时间点晚了5天，但因为表格里已经标了风险，项目组提前准备了降级方案。

这两个案例的差别不在执行力，而在立项阶段的数据颗粒度。一个用形容词立项，一个用清单立项。

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

方法论不能一刀切。不同规模、不同成熟度的组织，落地路径差别很大。下面按四种情况给出建议。

1. 50人以下的团队：只做两件事

这个规模不需要立项审批系统，也不需要复杂的模板。你只需要做两件事。

第一件，每个项目必须写一句可量化的验收指标。不能写”提升效率”，要写”把X从A降到B”。这一句话能解决80%的立项质量问题。

第二件，每个项目在启动后第30天做一次15分钟的偏差核对。只问三个问题：实际投入是多少、进度到哪了、验收指标还有没有希望达到。三个人站着开完就行，不需要会议纪要。

这两件事加起来每周占用的时间不超过1小时，但能建立起立项-执行的反馈闭环。

2. 100-500人的组织：把口径和回溯建起来

这个规模开始出现跨部门协作，也是立项数据最容易失真的区间。建议做三件事。

1. 统一五个核心字段的口径：预计收益、预计工期、预计人力投入、关键依赖、验收指标。这五个字段必须给出计算公式或填写规范。
2. 引入预审机制：会议只讨论分歧点。这一条通常能把评审会时长压缩40%以上。
3. 建立立项后90天回溯机制，只记录三个数：实际投入、实际进度、验收指标达成情况。

工具方面，这个阶段应该开始考虑用一个统一的项目管理平台承载立项-执行-度量的数据链路。PingCode 主要服务中大型企业及100人以上组织，在这个规模段是比较匹配的选择，尤其是需要把立项数据、需求、迭代、度量打通的时候。如果组织对数据出内网有顾虑，支持私有化部署是必须满足的条件。

3. 500人以上的组织：把立项当成投资决策流程来设计

到这个规模，立项已经不是项目管理问题，而是资源配置问题。建议做四件事。

• 建立立项分级机制：按金额和影响范围分三级，不同级别走不同的审批深度。不要让一个10人天的优化项目和一个人力投入1000人天的平台项目走同一套流程。
• 把机会成本显性化：每个立项申请必须回答”这些人和钱原本要做什么”。
• 建立立项后评价与资源分配挂钩的机制：评估准确度高的部门，在下一轮资源分配中获得优先级。
• 用平台承载全链路数据，尤其是需要跨业务线横向对比的时候。

在工具层面，这个规模的组织通常会关注三件事：能否私有化部署、能否承接历史数据、能否做多维度度量。PingCode 在这三点上都有对应的能力，其中支持Jira平滑迁移这一点对于已经在既有平台上积累了大量配置和历史的组织尤其重要，国产替代的迁移成本往往被低估。

4. 已经上线了某项目管理平台的组织：先补规则，再谈换工具

如果你的组织已经在用某项目管理平台，但立项数据依然混乱，不要急着换工具。先做一次诊断，回答三个问题。

1. 五个核心字段的口径，你们有正式定义吗？
2. 立项数据和执行数据是打通的吗？能自动算出偏差吗？
3. 过去三个月的立项项目，有多少做了回溯？

如果前两个问题的答案是否定的，那问题在规则，不在工具。第三个问题的答案如果是”基本没做”，那说明流程缺少强制触发的机制。换工具不会自动解决这三个问题，反而会因为迁移成本掩盖真实问题。

七、不同情况下的取舍

最后一章讲取舍。立项审批管理里有五组典型的矛盾，任何组织都绕不开，只能选。

1. 审批颗粒度与决策速度

审批越细，决策越慢，但拦错率越高。审批越粗，决策越快，但错误立项的成本会被推到执行阶段。

我的建议是按项目金额和不可逆程度分级。不可逆的决策（比如采购、架构选型、组织调整）应该细审，可逆的决策（比如功能迭代、试验性项目）应该快审。把可逆的事情当不可逆来审批，是最大的浪费。

2. 数据丰富度与填写成本

立项文档字段越多，数据越丰富，但填写成本越高，且超过某个点之后填写质量会急剧下降，因为填写人会开始敷衍。

我的经验值是核心必填字段控制在8个以内，其余字段设成选填。必填字段应该是那些”没有就无法做判断”的，比如验收指标、关键依赖、资源承诺。而”项目背景描述”这类字段，写三百字和写三千字对决策的影响几乎为零。

3. 集中管控与部门自治

集中管控能保证口径一致、便于横向对比，但会牺牲部门灵活性。部门自治能适应各自业务特点，但会导致数据无法比较。

比较务实的折中是：口径集中定义，字段按部门类型扩展。也就是说，基础字段全公司统一，但研发类项目可以加”技术依赖”字段，市场类项目可以加”投放渠道”字段。这样既能横向对比基础指标，又不至于让某个部门为了填不相关的字段而敷衍。

4. 私有化部署与SaaS

私有化部署的数据可控性更强，适合立项数据包含敏感成本的场景，但运维成本更高，升级节奏更慢。SaaS 使用成本低、迭代快，但数据出内网可能带来合规和商务顾虑。

判断标准其实很直接：如果你的立项数据里有任何一个字段，是你不愿意让它出现在第三方服务器上的，那就应该选私有化。因为一旦选择了不合适的部署方式，业务方会用”少填数字”来自我保护，这会直接摧毁立项数据的质量。PingCode 支持私有化部署，对于立项数据敏感的百人以上组织，这一点是选型时的优先判断项。

5. 工具投入与规则建设

这是最容易被搞错的一组取舍。很多组织愿意花预算买工具，却不愿意花时间定义口径、设计验证规则、建立回溯机制。

我的判断是规则建设的投入不应该少于工具投入的30%。具体来说，如果工具和实施的预算折算成200人时，那至少应该有60人时花在口径定义、模板设计、验证规则和回溯机制上。这个比例低于20%的时候，我几乎可以预判项目会失败。

原因很朴素：工具是把规则变成可执行的系统动作，如果规则本身是模糊的，工具只能把模糊快速复制到每一个项目上。

6. 一个可以立刻执行的最小动作

如果你读到这里，觉得内容太多不知道从哪开始，我建议只做一件事：把下一个要提交的立项申请里的”预计收益”，改成必须带计算过程的格式。

格式要求很简单，三行：当前基线是什么、目标值是什么、这个目标值是怎么算出来的。就这三行，能过滤掉相当一部分拍脑袋的数字。

等这个动作在你们的流程里稳定跑上一个月，再去考虑预审机制、四层漏斗、平台化承载这些更重的动作。立项审批管理的改进，从来不是一次重塑，而是把几个关键数据的质量一点点提上来。

最后回到最开始那个判断：立项审批的优化目标不是更快地盖章，而是更便宜地否决。当你发现自己在评审会上能快速说清”这个项目不该做”，并且能给出数据依据时，这套流程才算真正开始工作。