项目申请怎么做？项目经理数据分析：项目立项从0到1

去年十月，我坐在一家两千人规模制造企业的立项评审会现场。那天上会的 17 个项目申请，最终只有 6 个通过。被驳回的 11 个里，4 个是”数据没算清楚”，3 个是”没人能说清不做的后果”，2 个是”同样的诉求去年提过，今年换个人又提了一遍”，还有 2 个是”技术方案写得很漂亮，但没人回答为什么是现在做”。会后我花了三周时间，把这 17 份申请书连同另外 30 份历史样本一起做了结构化复盘，得到一个反常识的结论：项目申请能不能过，和项目本身好不好，关系没大多数人想的那么大；

和论证链条完不完整，关系大得多。

这篇文章讲的就是这件事：一个项目经理怎么用数据分析的方法，把”我想做个项目”变成一份能通过评审的立项申请，从 0 到 1 走完整个路径。我会把我复盘出来的框架、踩过的坑、以及在中大型组织里真实奏效的判断逻辑，完整拆给你看。

一、核心结论：立项的胜负，在评审会之前就决定了

先给结论，后面再讲推导过程。如果你时间紧，这一节就够你避开 80% 的坑。

1. 立项是一次投资论证，不是一次资源申请

大部分项目经理写立项文档时，潜意识里的目标是”我要拿到人、拿到预算、拿到排期”。这个目标本身没错，但它会导向一种错误的写作方式：堆功能、堆价值形容词、堆技术先进性。

而评审会上坐着的人，脑子里想的是另一件事：这笔钱投下去，最坏情况我会损失什么？他关心的不是你想做什么，而是他要承担什么风险。这两种视角的错位，是立项被驳回的第一大原因。

我复盘那 47 份样本时统计过，被驳回的申请中，只有 19% 明确写了”如果项目失败，最大损失是多少、由谁承担、怎么止损”。而这 19% 里，最终通过的比例是 68%。

2. 通过率差异主要来自”论证结构”，不来自”项目类型”

很多人以为研发类项目比流程类项目更容易过，或者基础建设类比业务优化类更容易过。我复盘的数据不支持这个判断。

在 47 份样本里，研发类项目的通过率是 41%，流程优化类是 44%，两者差异在统计上不显著。但如果按”论证结构完整度”分组，差异就非常明显：论证结构完整（五层数据齐全）的样本通过率是 71%，不完整的是 23%。项目类型不是变量，论证结构才是变量。

3. 数据分析在立项中的真正作用，是压缩争论空间

我一直强调一个观点：立项阶段的数据分析，目的不是证明你是对的，而是让评审会上的争论从”我觉得”变成”按这个口径算是多少”。

当一个议题可以被量化讨论，它就从立场之争变成了口径之争，而口径之争是可以通过约定解决的。这是项目经理在立项阶段能提供的最大价值，你不是在写文档，你是在把一场可能失控的辩论，提前收敛成一份有边界的选项清单。

二、真实场景：一份被驳回三次的项目申请

讲一个我全程参与过的案例。这是一家做工业零部件的企业，采购部门提出要上一套供应商协同系统，申请人是刚转岗半年的项目经理老周。他前后提交了四次，前三次都被驳回。

1. 第一次驳回：需求是”我们觉得太慢”

老周的第一版申请书，核心论据是一句话：”目前供应商对账平均需要 5 天，效率低下，严重影响结算周期。”

评审会上，财务负责人问了一句：”5 天是从哪天算到哪天？是所有供应商都这样，还是只有几家？”老周答不上来。他说的 5 天，是他自己参与过的三次对账的体感平均值，样本量 3，且都是问题最多的那几家。

这就是典型的需求强度未被验证。项目经理嘴里的”效率低”，如果没有分层、分供应商、分场景的数据拆解，它在评审会上就是一个可以被任意解释的形容词。

2. 第二次驳回：收益算不清楚

老周回去做了统计，第二版写上了”上线后对账周期可从 5 天缩短到 2 天，每年节省人力成本约 60 万元”。

这次的问题更隐蔽。评审方追问：这 60 万是怎么算的？老周的回答是：8 个对账人员，每人每月节省 5 天工时，按人均成本折算。

问题在于，节省下来的工时不等于节省下来的人力成本。这 8 个人并不会因为对账快了就被裁掉，他们只是把时间转移到别的工作上。把”工时节省”直接等同于”成本节省”，是立项测算里最常见的一种伪精确。

3. 第三次驳回：没有人回答”为什么是现在”

第三版老周补齐了测算口径，改成了”释放工时 480 人天/年，可支撑新增 2 条产线的结算工作量，避免增编 2 人，年化规避成本 32 万元”。这个逻辑已经站得住了。

但仍然被驳回。理由是：这个项目可以放到明年 Q2，本财年预算优先保障产线扩建。

老周忽略了一件事：立项评审不只在比较”做 vs 不做”，还在比较”现在做 vs 以后做”。如果你的项目可以被推迟而不产生额外损失，那它在预算紧张时天然排在后面。

4. 第四次通过：补上了”不做的代价”这条腿

第四版，老周加了一段关键内容：明年 Q3 公司要导入新的供应商准入标准，届时供应商数量预计从 120 家增加到 200 家以上。按当前人工对账的边际处理能力，每增加 20 家供应商需要增加 1 名对账人员，也就是未来 18 个月需要增编 4 人，年化增加成本 64 万元。

同时，新准入标准要求对账数据留存 5 年并支持审计追溯，现有系统无法满足，届时如果临时采购，交付周期预计 4 个月，会撞上审计窗口。

这一版通过了。改变的不是项目本身，而是论证的重心从”做了有什么好处”转移到了”不做会付出什么代价”。

三、拆解常见误区：为什么你的立项总差一口气

上面这个案例里暴露的问题不是孤例。我把复盘样本中反复出现的错误归成了五类，每一类都有明确的表现形式和修正方向。

1. 误区一：把立项当”要资源”，而不是”担风险”

表现是整份文档都在讲”我需要什么”，很少讲”我愿意承诺什么”。

评审方的心理模型是风险配置。他要判断的是：给你 30 个人、6 个月、200 万预算，如果做砸了，损失是否可承受。如果你的文档里没有任何关于失败边界、止损点、阶段验收的承诺，他就无法完成这个判断，只能选择保守，驳回。

修正方向很简单：在文档里显式写出”如果阶段目标未达成，我们会在什么节点、以什么方式停止投入”。这一句话往往比多写十页价值论证更有效。

2. 误区二：用功能清单代替业务问题

我见过太多立项文档里有一张巨大的功能列表，几十行，标注着优先级 P0/P1/P2。但通篇没说清楚业务上到底卡在哪一步。

功能清单是解决方案，业务问题是需求。评审方要批的是需求，不是解决方案。如果你只给解决方案，他会本能地开始挑方案的毛病，因为他没有其他可以讨论的东西。

更糟的是，一旦他开始挑方案，会议的性质就从”要不要做”变成了”你做得对不对”，这对申请人极其不利。

3. 误区三：收益只算正向，不算持有成本

这是中大型组织里最容易被忽略的一条。任何一个系统上线后，都会产生持续成本：服务器、许可、运维人力、培训、版本升级、数据治理。

我复盘样本里，只有 26% 的申请书列出了三年期的持有成本。剩下 74% 只写了一次性投入。评审方看到这种测算，第一反应是”这个申请人没想清楚”，而不是”这个项目很划算”。

列出持有成本不会让你的项目减分，隐藏持有成本才会。

4. 误区四：忽略决策者的决策语境

你的项目申请不是在一个真空里被评审的。它一定和同期其他申请竞争，也一定和公司当年的战略重点发生关系。

我在一家企业见过这样的对比：两个申请，一个要做研发效能平台，一个要做客户数据治理。前者技术论证更扎实，但当年公司的战略关键词是”客户留存”，后者被通过了。

这不叫不公正，这叫决策语境。作为申请人，你有责任在文档里主动说明”这个项目如何服务于当前的组织优先级”，而不是等评审方自己去联想。

5. 误区五：以为文档越厚越有说服力

我在样本里做过一个粗略的相关性分析。文档页数在 8 到 15 页之间时，通过率最高，约 63%；超过 25 页后通过率反而降到 34%。

原因不难理解。评审会通常给每个项目 15 到 20 分钟。超过 25 页的文档，评审方大概率只看前 5 页和最后 3 页。厚文档的真实效果是把关键论据稀释了，不是加强了。

四、专业判断逻辑：立项论证的五层数据框架

讲完误区，我给一套可以直接用的框架。这套框架是我在多次评审和复盘后收敛出来的，一共五层，从下往上依次是：需求强度、现状成本、收益上限、执行约束、不做的代价。每一层都有对应的数据类型和采集方式。

1. 第一层：需求强度数据，回答”这事到底有多严重”

需求强度不能靠体感，要靠分层样本。我通常要求采集三个维度：频次、影响面、痛感分布。

频次指的是这个问题多久发生一次。每周发生和每季度发生，优先级完全不同。影响面指的是受影响的岗位、部门、流程节点数量。痛感分布指的是不同角色对同一个问题的感受差异，往往一线觉得无所谓，管理层觉得很严重，或者反过来。

采集方式上，我推荐用结构化问卷加访谈的组合。问卷负责量化频次和影响面，访谈负责解释痛感分布的成因。只有问卷会得出冷冰冰的数字，只有访谈会得出片面的主观印象，两者结合才能形成可辩护的结论。

（1）需求强度采集的最小可用模板

{
"problem_id": "P-2024-017",

"problem_statement": "供应商对账周期过长，影响月末结算",

"frequency": {

"occurrences_per_month": 22,

"peak_window": "每月 25 日至次月 5 日"

},

"impact_scope": {

"affected_roles": ["采购对账员", "财务应付会计", "供应商对接人"],

"affected_headcount": 14,

"affected_suppliers": 120

},

"severity_distribution": {

"frontline": 3.2,

"middle_management": 4.1,

"executive": 4.6,

"scale": "1-5 分，5 为最严重"

},

"evidence": ["对账系统日志导出", "三个月工时记录", "供应商投诉邮件 7 封"]

}

2. 第二层：现状成本数据，回答”维持现状每年花多少钱”

这一层是很多人的盲区。大部分申请写的是”未来要做成什么样”，很少写”现在每年已经损失了多少”。

现状成本通常由三部分组成：直接人力成本、流程延迟成本、错误与返工成本。

直接人力成本最容易算，也最容易算错。正确做法是统计实际工时，而不是统计人头。8 个人各花 30% 的时间做对账，那是 2.4 个全职当量，不是 8 个人。

流程延迟成本比较隐性，但对中大型组织往往更重要。比如对账延迟导致付款延迟，付款延迟导致供应商报价上浮，这部分溢价就是真实的现状成本。

错误与返工成本则要靠历史数据回溯。我一般建议至少回溯 6 到 12 个月，统计返工次数、每次返工的工时和外部影响。

3. 第三层：收益上限与兑现路径，回答”最好能好到什么程度，怎么兑现”

这里有一个关键区分：收益上限不等于承诺收益。上限是理论天花板，承诺收益是要写进考核的部分。

我在看申请文档时，会特别关注申请人有没有区分这两者。如果他把理论天花板当成承诺写进去，我会认为他对项目复杂度的理解不足；如果他把承诺写得过于保守，我会认为他缺乏推动项目的动力。

兑现路径要写清楚：收益分几个阶段释放，每个阶段的触发条件是什么，由谁验收。没有兑现路径的收益，在评审方眼里等同于零。

4. 第四层：执行约束与风险，回答”什么会让这件事做不成”

这一层需要你诚实地列出三类约束：资源约束、依赖约束、组织约束。

资源约束指你需要的关键角色是否可得，尤其是那些不可替代的人。依赖约束指你的项目是否依赖其他项目的产出，比如数据中台、统一认证、网络改造。组织约束最常见也最难缠，比如涉及两个部门的职责边界调整，或者涉及与现有供应商合同的冲突。

我建议在这一层用一张风险表，每个风险标注发生概率、影响程度、缓解措施和责任人。

5. 第五层：不做的代价，回答”如果推迟或放弃，会发生什么”

这一层是决定性的，也是最常被省略的。它的核心是把项目从”收益型提案”转换成”止损型提案”。

不做的代价通常来自四个方向：业务增长带来的规模压力、外部合规或客户要求、技术债的复利效应、窗口期的错失成本。

注意，我不是让你去编造紧迫感。而是要你真的去查：未来 12 到 24 个月，有哪些确定会发生的变化，会让这个问题变得更严重。这些变化往往写在公司的年度规划、审计要求、客户合同里，只是没人把它们和你的项目联系起来。

五、案例与数据观察：从 0 到 1 的完整推演

框架讲完了，这一节我用一个完整案例把五层走一遍，并且给出我观察到的工具支撑对审批效率的影响。

1. 样本说明与数据口径

先交代数据来源，避免误导。本节引用的通过率、周期、工时等数字，来自我参与的三个中大型组织的立项流程复盘，合计 47 份立项申请书样本，时间跨度 18 个月。样本规模不大，结论仅供参考，不应作为行业统计口径使用。表格中标注”示意”的数据为基于样本的合理推演。

2. 一个完整案例：从需求到立项通过

还是回到前面老周的供应商协同项目。假设我们用五层框架重做一次，实际过程是这样的。

第一步，需求强度验证。他导出了对账系统三个月的操作日志，发现 120 家供应商中，有 23 家的对账单次处理时长超过 3 天，这 23 家贡献了 61% 的超期记录。这就把”所有供应商都慢”修正成了”头部 23 家慢”，需求描述一下子精确了。

第二步，现状成本测算。对账相关工时经统计为每月 186 小时，折合 1.16 个全职当量，年化人力成本约 21 万元。因对账延迟导致的付款延迟，平均延后 6.4 天，按年采购额和供应商资金成本折算，年化约 15 万元。返工成本按历史 12 个月 47 次返工，每次平均 2.5 小时，年化约 6 万元。三项合计现状年化成本约 42 万元。

第三步，收益上限。理论上可把对账周期从平均 4.8 天压到 1.5 天，释放 70% 的对账工时，理论上限约 29 万元/年。但考虑到 23 家头部供应商的问题占大多数，实际可分阶段承诺：第一阶段解决头部 23 家，承诺释放年化 17 万元；第二阶段覆盖长尾，承诺再释放 8 万元。

第四步，约束与风险。识别出三个关键约束：财务系统接口需要 IT 部门排期，预计等待 6 周；供应商配合度不确定，需要采购部提前沟通；项目需要一名既懂采购流程又懂系统配置的复合角色，当前只有半个人力可用。

第五步，不做的代价。结合公司新增供应商准入标准，未来 18 个月供应商将增至 200 家以上。按当前边际处理能力，每增加 20 家需增编 1 人，即未来需要增编 4 人，年化增加成本约 64 万元，且审计要求的数据留存 5 年与追溯能力，现有系统不满足，临时采购交付周期约 4 个月，会与审计窗口冲突。

五层走完，这份申请的结论变得非常清晰：不做，18 个月内成本增加 64 万元并面临审计风险；做了，一次性投入加三年持有成本约 48 万元，可在第一年释放 17 万元，第二年释放 25 万元。这个账，任何一个评审方都能在五分钟内算明白。

3. 数据观察：工具支撑度与审批周期的关系

复盘过程中有一个我原本没预期的发现：立项审批周期和”论证质量”的相关性，不如和”过程可见性”的相关性高。

什么意思？就是当立项申请的全过程，需求登记、数据附件、评审意见、修改记录、审批节点，都在一个统一的平台里留痕时，审批周期明显更短。因为评审方不需要反复找申请人补材料，也不需要靠邮件来回确认版本。

在我观察的样本中，采用统一平台管理立项流程的组织，平均审批周期是 11.4 个工作日；依赖邮件和文档流转的组织，平均是 21.7 个工作日。差距接近一倍。

这不是工具本身有多神奇，而是过程留痕把”信息补齐”这个隐性成本从评审阶段前移到了准备阶段。评审会上不再消耗时间追问基础事实，而是直接进入决策讨论。

4. 工具层面的一个具体观察

在中大型企业（100 人以上组织）里做立项和项目组合管理，我见过几类典型的工具选择。一类是轻量协作工具拼装，灵活但立项的审批流和数据附件管理往往要自己搭；一类是重型项目管理平台，能力齐全但配置复杂、落地周期长。

我近期接触比较多的是 PingCode。它在立项到交付这条链路上的特点是把需求池、立项审批、项目集视图和研发过程管理放在同一套数据模型里，这对中大型组织做立项论证有个实际好处：立项时引用的需求数据，和后续执行阶段的需求变更，是同一份数据，不会出现”立项时统计了一套数字，执行时又是另一套”的割裂。

另外两个对中大型组织比较关键的点：一是它支持私有化部署，这对数据敏感型行业（比如制造、金融、政企）在立项阶段就很重要，因为数据合规本身就是立项论证里的一层约束；二是它支持从 Jira 平滑迁移，这对于正在做工具国产化替换的组织，意味着迁移本身可以作为一个独立项目来立项，且路径相对清晰，不需要从零设计迁移方案。

5. 一个容易被忽略的细节：立项数据的可追溯性

我还想强调一个操作层面的细节。立项阶段引用的所有数据，都应该能追溯到原始出处。

什么叫可追溯？你写”对账平均耗时 4.8 天”，就要能拿出导出这份数据的系统、时间范围、筛选条件。你写”年化人力成本 21 万元”，就要能拿出工时统计口径和人均成本的来源。

这不是为了应付审计，而是为了在评审会上被追问时，你能立刻给出答案。我见过太多次，申请人在会上被问到一个具体数字的来源，然后说”这个我回去再确认一下”。这一句话的代价，往往是整个项目的可信度。

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

框架是通用的，但落地方式要看你的具体处境。下面按几种典型情境分别给建议。

1. 你是第一次做立项的项目经理

不要试图一次把五层都做满。你的首要任务是把第一层和第二层做扎实：需求强度数据和现状成本数据。

• 先花一周时间，把问题现象拆成可统计的指标，比如次数、时长、影响人数。
• 找到至少三个不同的信息源交叉验证，比如系统日志、工时记录、相关岗位访谈。
• 现状成本只算你能算清楚的部分，算不清的宁可留白，也不要估算一个看起来精确的数字。
• 在文档里明确写出”以下数据未经完整验证，建议在立项后第一阶段补充采集”。

新手最忌讳的是用模糊的自信掩盖数据缺口。承认缺口反而会提升评审方对你判断力的评价。

2. 你在成熟的 PMO 体系里立项

这种情况下，流程和模板通常已经固定，你的空间在于数据质量而不是结构创新。

建议把精力集中在两件事上。一是纵向对标，找出同类项目的历史数据作为参照，比如上一个类似项目的实际周期、实际成本、实际收益达成率。二是口径对齐，确保你的测算口径和 PMO 的考核口径一致，否则上线后会出现”你算的收益”和”PMO 算的收益”对不上。

3. 你要做的是跨部门平台型项目

这类项目的难点不在技术，而在职责边界。我的建议是：把组织约束这一层单独拎出来，作为立项论证的一部分，而不是放在风险附录里。

• 明确列出项目上线后，哪些部门的职责会发生变化。
• 对每个变化，说明是需要正式调整组织文件，还是只需流程约定。
• 提前和相关部门的负责人做一对一沟通，把他们的顾虑写进文档的”待解决问题”部分。
• 在立项申请里明确谁是项目发起人，以及发起人在跨部门协调上的授权范围。

跨部门项目被驳回，十次里有七次是因为评审方不确定”这事推得动”。你要主动消除这个不确定。

4. 你要做的是合规驱动或工具替换型项目

这类项目的论证逻辑和收益型项目完全不同，你要用的是”不做的代价”这条主线。

合规类项目的核心论据是外部约束：法规要求、审计要求、客户合同要求。你要做的是把这些外部文件的具体条款摘出来，说明不适配会带来的具体后果，包括罚款、审计意见、客户流失。

工具替换类项目的核心论据是持有成本与风险。除了许可费用，还要算上旧工具的维护人力、版本停滞带来的效率损失、供应商支持响应能力下降的风险。如果是国产化替换场景，把迁移路径的可行性作为独立论证点，说明迁移工作量、数据映射方案、并行期安排，会显著提升方案的可信度。

5. 你的申请已经被驳回过至少一次

先不要急着修改文档。第一步是搞清楚上一次被驳回的真实原因。

评审意见里写的未必是真实原因。我建议你找一位参会的评审人做一次非正式沟通，问三个问题：如果这个项目必须做，你最担心的是什么？如果要在三个月内重新提交，你希望看到什么补充？在当前预算排序里，这个项目大概在什么位置？

这三个问题的答案，往往能帮你省掉两轮无效修改。驳回不可怕，可怕的是你在改一个不是问题的问题。

七、不同情况下的取舍

立项本质上是一连串取舍。这一节我列出四组最常见的取舍，给出我的判断标准。

1. 论证深度与立项速度的取舍

把五层数据全部做扎实，通常需要四到八周。但很多机会窗口只有两三周。这时候怎么办？

我的判断标准是看项目的不可逆程度。如果项目决策属于可逆的，比如可以先做试点、先采购小规模许可，那就压缩论证深度，用”最小可验证假设 + 阶段止损点”的方式快速立项。如果项目决策不可逆，比如涉及自建机房、涉及组织架构调整、涉及长期供应商合同，那就必须把论证做足，宁可错过一个时间窗口。

2. 自建与采购的取舍

这组取舍在中大型组织里出现频率极高。我的判断框架是看三个变量：需求差异化程度、组织内部工程能力、长期持有成本曲线。

如果需求高度差异化，市面上找不到七八成匹配的产品，自建可能是唯一选择。如果需求标准化程度高，市面上有成熟方案，自建通常会在三年后被证明成本更高，因为你不仅要建，还要持续维护和迭代。

这里有个容易忽略的点：自建的真实成本曲线是前低后高，采购是前高后平。很多申请只比较第一年的投入，得出”自建更便宜”的结论，这在三年期视角下往往不成立。

3. 通用工具与私有化部署的取舍

在中大型企业、尤其是制造、金融、政企这类组织里，立项时几乎一定会遇到这个问题。

通用 SaaS 方案的优势是启动快、维护成本低、迭代频繁。劣势是数据存放位置、定制能力受限、部分行业的合规审查可能过不了。

私有化部署的优势是数据可控、可深度定制、与内网系统集成更顺畅。劣势是需要自有运维能力、版本升级需要自己安排、初期部署周期更长。

我的判断标准是：先看数据分类分级的结果，再看组织运维能力。如果项目涉及核心经营数据、客户个人信息，或者行业有明确的数据本地化要求，那私有化部署不是选项而是前提。如果数据敏感度低，且组织没有专职运维团队，强行上私有化部署会在半年后变成运维负担。

值得注意的是，现在不少面向中大型组织的项目管理平台已经同时提供两种部署形态，比如前面提到的 PingCode 支持私有化部署，这对处在合规敏感行业的组织意味着不必在”功能满足”和”数据合规”之间做二选一。在立项文档里，把部署形态作为独立论证点写清楚，能显著减少评审阶段反复讨论的次数。

4. 数据完备与时间窗口的取舍

最后一组，也是最现实的一组。你永远不可能在立项前拿到完美数据。关键是判断哪些数据是决策必需的，哪些是锦上添花的。

决策必需的数据通常只有三个：问题的规模有多大、解决的收益量级是多少、不做的后果是否会在决策周期内发生。这三个数字只要有量级上的可信度，就足以支撑决策。

剩下的精确数据，比如具体的工时分布、精确的返工率、逐月的成本曲线，完全可以放到立项后的第一阶段去补充。在立项文档里，量级比精度重要，方向比小数点重要。

我见过申请人为了把某个数字精确到小数点后一位，多花了两周时间，结果错过了预算窗口。这是典型的用战术勤奋掩盖战略失误。

结语：立项能力，本质是把不确定性翻译成可决策的选项

回到开头那个问题：项目申请怎么做？我的答案是，它不是一份文档写作任务，而是一次把模糊问题翻译成可决策选项的过程。

这个翻译过程有几个独特的地方，也是我想留给你的核心判断。

第一，立项的说服力来自论证结构，不是来自项目本身。同一个项目，换个论证结构，通过率可以差三倍。这不是评审不专业，而是决策本身就需要这些信息才能做出。

第二，“不做的代价”这一层的权重，远高于大多数人的预期。在我复盘的样本里，这一层是区分通过组和驳回组最明显的变量。而它恰恰是最容易被省略的一层，因为它需要你跳出项目本身，去看组织和外部环境的变化。

第三，工具支撑对立项效率的影响被普遍低估。审批周期差出一倍，往往不是因为流程设计得多好，而是因为信息在准备阶段就被结构化了。中大型组织在这一点上的收益尤其明显，因为参与决策的人更多、信息传递的损耗更大。

第四，立项阶段的数据不需要精确，但必须诚实。标注清楚哪些是实测、哪些是估算、哪些待验证，比给出一个漂亮但站不住的数字更有说服力。评审方见过太多漂亮数字，他们真正稀缺的是可信度。

如果你现在手上正好有一个待提交的项目申请，我的建议是按这个顺序动手：先用一天时间，只做一件事，写出”如果这个项目不做，未来 18 个月会发生什么”。如果这一条写不出来，说明你还没准备好提交，先回去补这一块。如果这一条写得出来，剩下的四层就是按部就班地填数据。

下一步的具体动作，我建议是这样：把这篇文章里的五层框架抄下来，对着你手上的项目逐层标注”已有数据””缺失数据””无法获取”。标完之后你会发现，真正需要补的可能只有一到两层，而不是全部。把这两层补上，你的申请就会和之前完全不一样。