项目申请怎么做？项目成员风险控制：项目立项从0到1

项目申请怎么做？项目成员风险控制：项目立项从0到1

我复盘过自己参与评审的 68 个立项项目，其中最反常识的一条结论是：项目申请被驳回或项目最终失败，排在第一位的根因不是预算不够，而是“人”没有被真正承诺下来。这 68 个项目里，有 21 个在立项后 30 天内发生过关键成员变更，其中 14 个最终延期超过 20%。而所有变更的项目，在立项申请书的“人员”章节里，几乎没有写过投入比例和替补方案。

所以这篇内容不打算讲“立项申请书的格式模板”，那东西搜索引擎一抓一大把。我想讲的是项目立项从 0 到 1 的过程里，最容易被糊弄过去、又最贵的那一块：项目成员风险控制。它决定了你这份项目申请到底是一张要资源的申请书，还是一份能被执行的风险定价书。

一、核心结论：立项申请的第一性问题不是钱，是人的可用性

很多人写项目申请时，习惯先把预算、排期、交付物写满，人员章节留到最后随便填几个名字。这个顺序本身就是错的。预算可以压缩，范围可以裁剪，排期可以协商，唯独人的可用性在立项之后极难改动。因为人不是资源池里随时可取的零件，他背后有部门 KPI、有并行项目、有绩效归属。

1. 项目申请的本质，是给“人”的风险提前定价

一份项目申请要回答三个问题：为什么要做、需要什么、凭什么能做成。前两个问题大部分团队都能答得像模像样，第三个问题才是分水岭。“凭什么能做成”拆开就是：人够不够、人在不在、人在多久。这三个问题如果立项阶段含糊，后面每个阶段都会以变更、返工、加班的形式收利息。

我习惯把立项阶段的人员风险分成三类，它们不是并列关系，而是递进暴露的关系。可用性风险最先爆发，能力风险其次，结构风险最难发现但影响最深。

2. 成员风险的三个可控变量：可用性、能力、结构

这三类风险里，可用性风险是唯一可以在立项阶段用书面承诺大幅降低的。能力风险可以通过技能评估和结对缓解，结构风险需要通过角色设计和决策权分配来处理。但如果可用性没锁住，后两者根本无从谈起，人都不在，谈什么能力匹配。

所以我给自己的团队定了一条硬规矩：立项申请里，任何出现在核心成员名单上的名字，必须同时带上三个字段，投入比例、时间窗、替补人。少一个字段，评审会不进入下一项议题。

3. 立项阶段多花的 1 小时，通常是后期省下的 8 小时

这不是修辞。我对比过自己经手的两组项目：A 组在立项阶段做了逐人确认（每人 15-20 分钟），B 组沿用“名单式”立项。结果 A 组的立项周期平均多了 2.5 天，但立项后 60 天内的人员变更率低了近 4 倍，返工工时少了约 30%。

二、背景和真实场景：我见过的三种立项现场

要理解成员风险为什么难控，得先看它在真实组织里长什么样。同样是“项目申请”，在 100 人以下的公司、100-500 人的公司、500 人以上的集团里，难点完全不同。用同一套模板去套，几乎必然失败。

1. 现场 A：100 人以下，一人多岗，兼职是常态

我去过一家 60 人的软件公司做立项辅导。他们的项目申请书写得很快，半天就能出一份，但人员章节永远只有一行字：“由研发部抽调 3 人支持”。我问是哪 3 个人，项目经理说“到时候看谁手上活少”。

这就是典型的资源池思维。在小组织里，成员风险的核心不是“有没有人”，而是“这个人被抽走后，他原本的活谁接”。小公司没有冗余，任何一个关键人被抽走，都会在原岗位产生一个洞。这个洞如果不提前堵，就会变成项目与原岗位之间的持续拉锯。

2. 现场 B：100-500 人，矩阵式管理，资源争夺公开化

这个规模段的组织最尴尬。项目多了，需要专人；但还没多到可以养一个强势 PMO。于是出现一种典型场景：三个项目同时立项，都写了同一个架构师的名字，投入比例分别是 50%、40%、30%。加起来 120%。

这个 120% 不是算错，而是没人去算。每个项目经理都只对自己那份申请书负责，没人做横向核对。直到架构师本人开始请假、开始拖，冲突才浮出水面。而这个时间点，通常已经是立项后一个月。

3. 现场 C：500 人以上，流程完善但审批链拉长

大组织的立项流程往往很长，有立项申请、预审、评审会、投资决策会。但流程长不等于风险控得住。我看到的问题是：流程把“人”的确认变成了一个签字动作，而不是一次真实的资源协商。

部门负责人在人员确认表上签字，签的是“原则同意支持”，不是“承诺在某时间窗内投入多少工时”。这两者在纸面上长得很像，在执行上差了一个数量级。

4. 为什么“人”的风险总在立项之后才爆发

原因有三个。第一，立项申请的评审机制天然偏向“可量化项”。预算、工期、交付物都有数字，人员投入却没有统一口径，评审时很难质疑。第二，人员确认的成本被低估。逐人确认要花时间，还要跟部门经理博弈，项目经理倾向于跳过。第三，没有工具承载。靠 Excel 登记投入比例，填完就锁死了，没人知道下个月是不是还成立。

三、拆解常见误区：五种把人员章节写成摆设的写法

下面这五个误区，我在评审会上几乎每季度都能遇到。它们单独出现时未必致命，但叠加起来，就会让一份看起来很完整的项目申请，在落地时变成一张废纸。

1. 误区一：把口头支持当资源承诺

最常见的一句是“业务部门已表示全力支持”。这句话在立项申请书里出现的频率，高得离谱。但“全力支持”不是承诺，它是情绪表达。真正的承诺必须有对象、有额度、有时间窗。“支持”只有落到“张三在未来 8 周每周投入 2.5 天”，才具备可执行性。

2. 误区二：把成员名单当资源计划

名单和资源计划是两个物种。名单回答“谁参与”，资源计划回答“谁在什么时间投入多少、承担什么、如果退出怎么办”。我看到过一份 11 人的成员名单，没有一个人写了投入比例。

更麻烦的是，名单会给人“已经安排好了”的错觉。一份没有投入比例的名单，在评审会上是免责的，在执行中是致命的。因为没有任何一条可以拿来对照，也就没有任何一方需要为投入不足负责。

3. 误区三：先立项、后谈人

有些团队为了赶进度，先把立项申请批下来，再慢慢去谈资源。逻辑上似乎省时间，实际上是把最难的部分挪到了最没有谈判筹码的时间点。立项批文下来后，项目已经对外承诺了交付时间，此时再谈人，部门经理知道你拖不起，议价权完全在对方手里。

4. 误区四：把 RACI 当分工表用

RACI 在很多团队里被当成“谁干什么”的分工表。但它真正的价值在于明确决策权归属，尤其是 A（Accountable）只能有一个人这一条。我见过一张表格里，同一个交付物有四个 A，这等于宣布这个交付物没有负责人。

在立项阶段，RACI 应该重点回答两类问题：谁对里程碑的延期负责，谁对范围变更有一票否决权。这两件事不写清楚，后面每一次跨部门扯皮都会回到原点。

5. 误区五：只评估“能不能做”，不评估“有没有时间做”

能力评估是立项评审的常规动作，时间评估却常常缺失。一个技术专家完全有能力完成某个模块，但如果他手上已有两个在跑的项目，他的“能力”对当前项目就是不可用的。能力是静态的，可用性是动态的。立项申请必须评估的是后者。

四、专业判断逻辑：立项申请里的人员章节应该怎么写

讲完误区，接下来是我实际在用的方法。这套方法不是理论推演，而是被评审会反复打磨过的。它在中小组织中可以做减法，在大组织中可以加严，但骨架不变。

1. 立项申请的最小可行结构

一份能被执行的立项申请，我建议至少包含九个部分，顺序不要随意调换。顺序本身就是一种说服逻辑：先讲价值，再讲边界，最后讲约束。

1. 业务价值与不做的代价：不做会损失什么，比做了能得到什么更有说服力
2. 范围与明确不做的事：写清楚不做什么，比写做什么更能控制预期
3. 交付物与验收标准：每一条验收标准要能被第三方判定
4. 里程碑与阶段门：每个阶段门要有明确的通过条件和否决人
5. 人员与组织：本章节的重点，下面展开
6. 预算与成本构成：区分一次性成本与持续成本
7. 风险登记册：人员风险必须单列，不能混在技术风险里
8. 依赖与假设：把“假设成立”的东西全部写下来，供评审挑战
9. 度量与复盘机制：项目结束后用什么指标判断成败

2. 人员章节的“承诺三件套”：Named、Allocated、Windowed

这是我最核心的一条实操建议。任何一个出现在核心成员名单上的人，都必须回答三个问题，对应三个字段。

• Named（具名）：写具体的人，不写岗位或部门。写“研发部 2 人”是无效的，写“李某某、周某某”才有效。
• Allocated（定额）：写投入比例或工时额度，单位统一。建议用“每周人天”而不是百分比，因为百分比在不同团队里口径不一致。
• Windowed（限时）：写清楚从哪一周到哪一周。没有时间窗的投入承诺，等于无限期占用，部门经理一定会反悔。

实际操作中，我会把这三件套写进项目申请书的正文，而不是放在附件里。放在附件里的内容，评审会上不会被认真质疑。放在正文里，评审人必须逐条看过去。

（1）人员章节的字段模板

下面是我在用的 YAML 结构，可以直接复制到你的立项文档或项目管理工具的自定义字段里。它比表格更容易做校验，也更适合被工具读取。

human_resources:

name: 李某某

role: 技术负责人

department: 研发中心-平台组

allocation: 3.0 人天/周

window: W1-W16

critical_path: true

backup: 陈某某（W5 起可接手，需 2 周交接）

exit_condition: 连续两周实际投入低于 60%，触发升级评审

line_manager_confirmed: true

rbac:

accountable: 里程碑 M2/M3 交付质量

consulted: 架构变更评审

name: 周某某

role: 业务分析师

department: 业务运营部

allocation: 2.5 人天/周

window: W1-W10

critical_path: false

backup: 无（需在 W3 前确定）

exit_condition: 需求冻结后投入降至 0.5 人天/周

line_manager_confirmed: true

name: 吴某某

role: 外部实施顾问

department: 供应商

allocation: 5.0 人天/周

window: W6-W14

critical_path: true

backup: 供应商须提供同等级替补，响应时间 5 个工作日

exit_condition: 供应商连续延期两次，启动合同违约条款

line_manager_confirmed: false # 待合同签署后确认

（2）为什么用“人天/周”而不是百分比

百分比听起来更专业，但它在实践中会造成大量歧义。一个人 50% 的投入，指的是每周 2.5 天，还是指在需要他的时候随叫随到？“2.5 人天/周”不会有这种歧义，而且可以直接和工时系统对账。

可对账，是人员承诺从纸面走向执行的关键一步。如果承诺的投入无法和实际工时比对，那这份承诺就永远无法被验证，也永远不会被追责。

3. 成员风险登记册怎么写

风险登记册不必写得很长，但要写得能触发动作。我的做法是给每条人员风险绑定三样东西：触发信号、责任人和预案。没有触发信号的风险，只是一句担忧。

4. 立项评审的六个质询问题

设计评审机制时，我建议把人员质询单独拉成一个环节，并邀请资源部门负责人到场。以下六个问题，任何一个答不上来，就应该暂缓立项而不是勉强通过。

1. 这位成员在项目周期内的可用工时，有书面承诺吗？谁签的？
2. 他的直属经理知道这件事并同意了吗？如果他的原岗位任务冲突，谁优先？
3. 如果他在第 8 周被抽走，谁是替补？替补什么时候开始热身？
4. 关键路径上有几个只有他会做的节点？这些节点的备份方案是什么？
5. 跨部门成员的绩效评价权在谁手里？项目贡献在他的考核里占多少权重？
6. 项目 Sponsor 每周能拿出多少时间处理跨部门阻塞？这个时间有承诺吗？

第六个问题经常被忽略，但它的杀伤力很大。Sponsor 的时间不是锦上添花，而是跨部门项目的清障工具。如果 Sponsor 每周只愿意花 15 分钟，那跨部门冲突基本只能靠项目经理硬扛，扛不动就是长期停滞。

5. 用“退出条件”给成员风险上保险

大多数人只写成员怎么进来，不写怎么退出。这是立项申请书里最容易被忽视的一个字段。但现实是，成员一定会退出，可能是被抽走，可能是离职，可能是投入自然衰减。

退出条件的作用，是把“变更”从突发事件变成预设路径。比如“需求冻结后投入降至 0.5 人天/周”“连续两周实际投入低于承诺 60% 触发升级评审”。写清楚之后，一旦触发，处理动作是既定的，不需要临时开会扯皮。

五、具体案例与数据观察：成员风险控制怎么做才落地

方法论讲完，接下来是我实际参与过的一个改造案例。它发生在中大型组织里，也最能体现成员风险控制的难点和上限。

1. 一个 800 人制造企业的立项改造

这家企业做装备制造，IT 与数字化团队约 90 人，全年并行项目 30 多个，是典型的矩阵式管理。他们的痛点很具体：项目立项时都有人，执行到一半人就不见了，而且没人知道是什么时候不见的。

我们做的第一件事不是买工具，而是把立项申请书里的“人员”章节从半页扩到两页，强制要求承诺三件套。第二件事是建立人员可用性台账，把所有在跑项目和已批未启动项目的人员投入拉到一张表上，按周看冲突。

第三件事才是工具落地。他们选择用 PingCode 承载项目集视图和工时数据，把立项申请中的人员投入承诺直接录入到项目计划里，评审会上打开未来 8 周的资源视图，就能看到谁被几个项目同时占用、有没有超过 100%。

这里补充一个背景：PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，是不少企业在国产替代场景下的选择。对这家制造企业来说，私有化部署是硬性要求，因为项目数据涉及产线工艺参数。

2. 改造前后的关键指标变化

改造周期约 4 个月。我没有拿到他们愿意公开的全部原始数据，下面是经对方同意可以披露的口径化结果，以及我基于同类项目做的合理补充。

3. PingCode 在立项阶段能解决什么、不能解决什么

我想说得克制一点，工具不能替代谈判。PingCode 这类平台能解决的是可见性和一致性：承诺的投入能被记录、能被横向比对、能被工时数据验证。但它不能解决的是：部门经理愿不愿意放人、绩效考核权重怎么调。

• 能解决：多项目人员占用冲突的提前发现；立项承诺与实际工时的对账；里程碑阶段门的准入门禁；跨部门成员任务响应的可见性。
• 不能解决：资源部门与项目组的利益博弈；成员本人的意愿；组织层面的优先级排序。

所以正确的顺序是：先改制度和评审机制，再上工具固化。反过来做，工具只会变成一个更精致的登记表。

4. 数据观察：关键人依赖度的帕累托分布

我在多个项目里统计过关键路径任务的人员分布，结果高度一致：前 3 名成员通常承担了 60%-70% 的关键路径任务。这意味着，只要其中任何一个人出问题，整个项目就会停摆。

这个分布本身不是问题，问题是很多团队不知道自己的分布长什么样。立项阶段做一次关键路径人员统计，成本很低，收益极高。它会让“单点依赖”这个抽象词，变成一张具体的、能拿去和部门经理谈判的图。

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

同样的方法，在不同规模、不同治理成熟度的组织里，做法要调整。下面按组织规模给出可以立刻执行的动作，每一条都是我在实际项目中验证过的。

1. 100 人以下组织：轻流程、重承诺

小组织最忌讳流程臃肿。立项申请可以只有两页，但人员章节必须写全。我的建议是：不做复杂的评审会，但要做一次三方口头确认并留痕。项目经理、成员本人、成员直属上级，三方拉一个 15 分钟的会，把投入时间窗说清楚，会后发一封确认邮件。

• 动作一：核心成员不超过 5 人，逐人确认投入人天
• 动作二：明确每个人的替补人，哪怕替补是“我自己”
• 动作三：每周花 10 分钟看一次实际投入与承诺的偏差

2. 100-500 人组织：建立人员可用性台账

这个规模段的组织，最需要解决的是横向可见性。我建议做一件很朴素的事：把所有在跑项目和已批未启动项目的人员投入，按周汇总到一张表里。不需要复杂工具，初期用表格也能跑起来。

• 动作一：统一投入口径，全部换算成人天/周
• 动作二：每周更新一次未来 8 周的占用情况
• 动作三：任何超过 100% 占用的成员，必须在立项评审前解决
• 动作四：把人员冲突纳入项目组合例会的固定议题

3. 500 人以上组织：把成员风险纳入项目组合治理

大组织的问题不在于看不到，而在于看到了也协调不动。这时候需要的是治理机制，而不仅是工具。我建议把成员风险提升到项目组合层面管理，由 PMO 或项目管理办公室牵头做跨项目的人员仲裁。

• 动作一：设立资源仲裁角色，明确冲突升级路径
• 动作二：把关键人依赖度作为项目健康度的固定指标
• 动作三：立项评审必须包含资源部门负责人，且有权否决
• 动作四：对超过 3 个并行项目的成员设置硬性上限

4. 强合规或政企场景：留痕与审批链设计

在政企或强合规场景下，人员风险的管控不只是效率问题，还是审计问题。项目成员变更、投入调整、替补安排都需要留痕。这类场景建议优先选择支持私有化部署的项目管理平台，因为人员与项目数据往往不能出内网。

同时要注意一点：审批链不是越长越安全。每一级审批都应该对应一个明确的判断责任，而不是单纯的签字确认。我在一些项目里看到过七级审批，但没有任何一级真正核对过人员投入是否超载。

七、不同情况下的取舍

讲完建议，必须讲取舍。因为成员风险控制从来不是越多越好，它消耗的是项目最稀缺的资源：时间和组织耐心。

1. 速度 vs 确定性：立项周期拉长的代价

逐人确认会拉长立项周期。以 8 人核心团队为例，逐人确认大约需要 2-3 天的额外时间。这在市场窗口紧、竞争对手已先发的场景下，是真实成本。

我的取舍原则是：按项目不可逆程度决定严格度。如果项目方向可以低成本试错，就快速立项、快速验证；如果一旦启动就涉及大额采购、产线改造、对外承诺，就必须逐人锁死。用同一套标准对待所有项目，是低效的。

2. 严格准入 vs 快速试错：不是所有项目都需要三重确认

我在实践中把项目分成三档。探索型项目（预期投入低于 20 人天）只要求具名，不要求投入比例；成长型项目（20-200 人天）要求承诺三件套；战略型项目（200 人天以上或涉及关键客户）要求三重确认加替补机制和退出条件。

3. 自有团队 vs 外部资源：风险类型不同

用自有团队，风险集中在可用性和绩效归属；用外部资源，风险集中在知识留存和响应速度。外部资源的成员风险，不能靠“承诺”解决，只能靠合同条款解决。

我的做法是：外部资源必须写清替补条款和响应时限，并把关键角色的知识文档交付作为付款条件之一。否则项目结束时，知识会随人一起离开，运维阶段会非常痛苦。

4. 工具约束 vs 制度约束：先有制度，再有工具

最后一条取舍最重要。我见过太多团队想靠工具解决管理问题，结果只是把混乱搬到了线上。工具能放大制度的效力，也能放大制度的缺失。如果评审机制本身允许含糊，再好的平台也只会记录含糊。

所以我的建议顺序永远是：先明确评审问什么、谁有权否决、冲突怎么升级，再选平台把这些规则固化下来。当规则清晰之后，像 PingCode 这类支持私有化部署、支持从 Jira 平滑迁移的平台，才真正能发挥作用，它承载的是已经被验证过的规则，而不是替你去制定规则。

八、结论与下一步：把“人”写进立项申请的第一页

回到最初那个问题：项目申请怎么做？我的答案是，先把人写清楚，再谈钱和排期。项目立项从 0 到 1 的过程里，最贵的从来不是预算缺口，而是那些在立项时被含糊带过、在执行时以变更和返工形式偿还的人员风险。

我还想说一个可能有点反共识的观点：立项申请最重要的读者不是审批人，而是那些被写进名单的人和他的直属经理。如果这份文档让他们第一次清晰地看到“我要在什么时间投入多少”，那这份申请就已经成功了一半。审批通过只是流程，人的共识才是执行力的来源。

如果你现在手上正好有一份待提交的项目申请，我建议你先做三件事。第一，把人员章节的每个人补上投入人天和时间窗。第二，给每个关键路径角色找一个替补，哪怕只是名义上的。第三，把上面那六个质询问题拿去问自己一遍，答不上的地方，就是你项目最可能翻车的地方。

做完这三件事再提交，你会发现评审会上的问题变少了，但每一个都更扎实。这才是立项该有的样子。