项目立项如何做好项目成员？PMO实操方法与操作步骤

我复盘过 60 多个立项案例，有一个数字一直让我不太舒服：立项评审会上，”项目成员”这一项平均只占 4 到 7 分钟，而执行阶段因为成员问题导致的返工、延期、重新走立项流程，平均要额外消耗 3 到 6 周。更麻烦的是，这 3 到 6 周通常不会出现在任何一份风险台账里，因为它早在立项那 5 分钟就已经埋下了。

很多 PMO 把”做好项目成员”理解为在立项模板里把名字填齐、部门填对、角色填满。但从我实际跟过的项目看，真正决定项目能不能跑起来的，不是名单上有谁，而是这些人有没有给出可验证的承诺。这篇文章讲的就是那 5 分钟应该怎么做，不是填一张成员名单，而是完成一套能落到执行期的承诺机制。

一、核心结论：立项阶段”做成员”，做的不是名单而是承诺

先把结论放在前面，方便你判断后面的内容值不值得看。我的判断是：立项阶段做项目成员，本质是让关键角色签下三份可验证的承诺，而不是在表格里登记三个字段。这三份承诺缺任何一份，执行期都会以”扯皮”的形式还回来。

1. 三份必须落地的承诺

第一份是结果承诺。谁对最终交付结果负责，而且是唯一的。注意”唯一”这两个字，很多立项表里写着”业务负责人：A、B”，看起来是双保险，实际是双不管。

第二份是产能承诺。这个人拿多少时间投入，以 FTE 或人天/周为单位，起止时间是什么，由谁批准。只写”参与”两个字，等于什么都没承诺。

第三份是决策承诺。这个角色能拍板什么，能批多少预算、能改多大范围、能在技术方案上有无否决权、能不能代表业务方确认验收口径。没有这一条，项目会在第一个争议点上卡住。

PMO 在立项阶段的真正产出物，不是《项目成员名单》，而是《项目角色与承诺表》加上关键角色的确认记录。名单是给人看的，承诺表是给执行期用的。

2. 一个反常识判断：核心成员越多，按期交付率越低

我统计了自己跟踪过的 47 个已结项项目，包含 21 个研发交付型、14 个系统实施型、12 个管理变革型，按立项时确定的核心成员规模分组，结果和大多数人的直觉相反。

原因其实不复杂。N 个人的沟通链路是 N×(N-1)/2，7 个人是 21 条，12 个人是 66 条。立项时每多塞一个”看起来相关”的人进核心圈，执行期就多一条需要维护的沟通链路，而且这条链路往往没有明确的信息产出。

所以我的第一个实操原则是：立项阶段宁可把核心成员压到 7 人以内，把其余人放进”接口人”或”知会人”层，也不要为了看起来阵容齐全而扩大核心圈。

3. 核心成员和参与人必须分层

我在很多立项文档里看到一张表塞了二十几个人，角色写着”项目成员”，投入写着”按需”。这种表在执行期没有任何约束力，因为”按需”意味着永远不需要。

我的做法是强制分三层：核心层（对结果负责，7 人以内）、接口层（提供输入或接收输出，有明确交付物）、知会层（只看进展，不承担交付）。三层的人填进不同表格，走不同确认流程。

二、真实场景：三个我亲历的立项翻车现场

抽象原则讲完，说三个我实际参与复盘的场景。这三个场景分别对应责任、产能、授权三类承诺的缺失，非常典型。

1. 场景 A：立项会 5 分钟通过名单，执行第 3 周发现关键人只在群里

某制造企业的供应链系统升级立项，评审会上成员名单一页纸，10 个人，主持人念完问”大家有没有意见”，没人说话，通过。项目启动第 3 周，我参加他们的周会，发现负责主数据梳理的那位业务骨干从来没出现在任何一次会议里。

追问才知道，他当时被另一个项目占满了，他的主管在立项会上根本没收到”他需要投入 50%”这个信息。名单是项目经理私下拟的，没有经过主管这一环。这不是沟通问题，是立项流程里缺了产能确认节点。

2. 场景 B：跨部门借调没有主管签字，项目启动即停摆

这是一家 300 人规模企业的数字化项目，需要从生产部门借调一名工艺工程师做需求对接，约定投入 3 个月。立项文件写得很漂亮，但没有任何一方主管签过字。

项目启动第二周，生产部门接到紧急订单，这位工程师被召回。项目经理拿着立项文件去找生产主管，对方说”我不知道有这个安排”。项目停摆 11 天，最后走公司层面协调才恢复。

复盘时我们算了一笔账：如果立项阶段多花 0.5 人天做一次主管确认签字，可以避免后面大约 18 人天的延误和协调成本。

3. 场景 C：角色表写了 8 个”负责人”，出了问题没人认账

某集团的数据中台项目，立项表里”负责人”这一列出现了 8 次，涉及数据质量、接口开发、权限管理、上线验收等各个板块。项目中期出现数据质量问题，开会时 8 个人逐一发言，结论是”这块应该是他们在管”。

我当时的判断是：一份文档里如果出现多个同名角色，说明这个角色根本没有被定义过。后来我们把这个项目的角色表重做了一遍，每个交付物只允许一个责任人，其余人只能出现在”配合””审批””知会”三列。

三、常见误区：PMO 在立项成员管理上最容易踩的六个坑

下面这六个误区，是我在评审和复盘里出现频率最高的。如果你手上正好有一份立项模板，可以对着检查一遍。

1. 用部门代表替代项目角色

立项表里写”财务部代表””生产部代表”，这是组织架构思维，不是项目思维。项目需要的是”负责成本口径确认的人””负责工艺参数验证的人”。同一个人在不同项目里的项目角色可能完全不同，用部门名代替角色名，等于没定义角色。

2. 核心成员与参与人混在一张表

混表最直接的后果是：核对进度时你不知道该找谁，出了问题时有责任的人太多。我见过最极端的一份立项表，27 个人全部标注为”项目成员”，其中只有 4 个真正参与交付。

3. 只写名字不写投入比例

没有投入比例的成员表，在执行期没有任何约束力。我建议至少写清三件事：每周投入人天或 FTE、投入起止时间、占用比例上限。三者缺一，都会在资源冲突时说不清。

4. 决策权与执行权不分离

有些项目把所有决策权都给了项目经理，结果业务方不认技术方案，或者反过来，业务方随时改需求而项目经理无法拒绝。立项时必须明确哪些决策归项目经理、哪些归业务负责人、哪些必须上升到项目指导委员会。

5. 只对项目经理授权，不对成员主管约束

这是最隐蔽的一个坑。项目文件签字的往往只有项目经理，成员的主管没有签。当资源冲突发生时，主管的第一优先级永远是他的部门 KPI，项目会被自动降级。

6. 名单靠 Excel 和邮件流转，版本失控

我见过一个项目在立项后 30 天内，成员名单出现了 6 个版本，分别在不同人的邮箱里。到执行期大家对照的基线都不一样。这不是工具问题，是流程没有唯一出口。

四、专业判断逻辑：五个维度与四道准入问题

讲完误区，说我实际用的判断框架。它的核心不是”谁能力强”,而是”谁在这个项目里承担了不可替代的承诺”。

1. 五个判断维度

维度一，结果责任。问一个问题：这个交付物如果失败，第一个被追责的是谁？如果答不出来，说明责任没定义。

维度二，投入承诺。问一个问题：这个人下周能拿出多少小时给这个项目？如果答案是”看情况”，他不应该进入核心层。

维度三，授权边界。问一个问题：他能在多大金额、多大范围变更上自己拍板？这个边界要写进立项文件。

维度四，接口关系。问一个问题：他的输入来自谁，输出给谁？接口关系决定了项目后期最容易出问题的地方。

维度五，可替换性。问一个问题：如果他明天离职或被抽调，谁能顶上来？没有任何备份的关键角色，就是项目的单点故障。

2. 四道准入问题

在实际筛选核心成员时，我用四道问题做初筛，任何一道答”否”，这个人就不进核心层：

1. 他是否对一个可交付成果负唯一责任？
2. 他是否能承诺每周不少于 0.4 FTE 的投入，且主管知晓？
3. 他是否在授权范围内能独立做出至少一类决策？
4. 他的角色是否有明确的备份人选或退出机制？

这四道问题看起来简单，但在我参与的立项评审里，能四道全过的候选人通常只占提名总数的四分之一左右。

3. 判断顺序：先定责任，再定人头

很多人做成员是反着来的：先看哪个部门能出人，再想让他干什么。正确的顺序是先拆交付物和责任，再去找能承担这份责任的人。

我通常的做法是先写一版”无名字的角色清单”，把每个交付物的责任角色、审批角色、配合角色列清楚，然后再往角色里填人。这样做的额外好处是：如果某个角色找不到合适的人，你能立刻判断是缩小范围还是调整方案，而不是先拉个人进来再想办法。

4. 单点风险的识别方法

我的做法很简单，在角色清单确定后，逐个角色问两个问题：这个角色是否只有一个人？这个人是否同时承担超过 3 个项目的关键角色？只要有一个答”是”，就标记为单点风险，并在立项文件中写明应对方式。

五、案例与数据观察：把”成员承诺”变成系统里的约束

框架讲完了，说一个我参与过的实际改进案例。这是一家约 320 人的装备制造企业，项目是 ERP 与 MES 的整合升级，涉及 IT、生产、工艺、质量、财务五个部门。

1. 案例背景与改进前的状态

项目第一次立项时，成员表上有 14 个人，核心层没有明确划分，投入比例一栏全部空白。立项评审会开了 150 分钟，成员议题只占约 5 分钟。

项目启动后问题集中爆发：主数据责任人不到位、接口人换了两次、验收口径在中期才被发现不一致。立项后 30 天内，成员名单变更了 4 次，到第 8 周项目实际进度落后计划约 3 周。

2. 改进动作：四个具体改变

第二次重新立项时，PMO 做了四件事。第一，把 14 人拆成 6 人核心层、5 人接口层、3 人知会层。第二，为每个核心角色写清楚唯一交付责任和授权金额上限。第三，逐个与成员直属主管做 30 分钟产能面谈，确认投入比例并签字。第四，把成员角色、权限、投入约束全部录入项目管理系统，作为基线。

这里说一句工具选择的实际考虑。这家企业有数据不出内网的要求，同时历史上用过 Jira，迁移成本是必须考虑的变量。他们最终选择的是 PingCode，主要原因有三点：它面向中大型企业、100 人以上组织的场景设计，角色与权限模型能承接”核心层/接口层/知会层”这种分层；支持私有化部署，满足内网要求；支持从 Jira 平滑迁移，历史项目数据不用重来。

需要说清楚的是，工具本身不会让成员管理变好。PingCode 在这类项目里的真实价值，是把”承诺”从文档里的文字变成系统里的约束，投入比例变成容量视图上的占用，授权边界变成可配置的审批权限，角色分层变成访问控制。约束一旦写进系统，执行期的口头协商空间就小了很多。

3. 改进前后的数据对比

这份数据来自我对该项目的两次立项记录和后续 12 周的进度跟踪，不是行业统计，样本为单项目，看趋势即可，不要直接套用绝对值。

4. 一个容易被忽略的观察：会议时长反而下降了

改进后立项会从 150 分钟降到 95 分钟，但成员议题占比从 5% 升到 22%。看起来矛盾，其实很合理：改进前会议大量时间花在讨论技术方案细节，成员问题被跳过，导致后续反复开会补救。

把成员议题前置，等于把后面几次协调会压缩到一次立项会里完成。同时，立项后的变更单数量从平均 6.5 张/项目降到 2.3 张/项目。

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

同一套方法，在不同项目类型和组织成熟度下，执行力度应该不同。下面按三个维度给建议。

1. 按项目类型调整核心成员规模与角色设计

合规或审计驱动型项目，交付物边界清楚，核心成员可以压得很紧，重点是证据链责任人。系统实施或交付型项目，需要业务、技术、数据三类角色齐全，接口人多一些。产品研发型项目，需要保留一定的冗余以应对探索性工作。组织变革型项目，核心成员人数不必多，但必须设置两层接口人。

2. 按组织成熟度调整流程强度

没有 PMO 或 PMO 很轻的组织，不要一上来就要求主管书面签字这一套，先从”投入比例必须写清”开始，这一条推行的阻力最小，收益也最直接。

有专职 PMO 的组织，可以把四道准入问题做成立项准入清单，不满足就不进入评审。PMO 强势的组织，可以进一步把角色承诺纳入项目考核，但要小心别把流程做成负担，否则业务部门会开始敷衍签字。

3. 按成员来源调整确认方式

内部全职成员，确认重点在主管和排期；内部兼职成员，确认重点在投入比例上限和优先级排序；外部供应商人员，确认重点在合同条款，尤其是关键人员替换需提前告知这一条。

这三种来源的确认方式差别很大，但很多立项文档用同一张表处理，结果是全职成员的排期没人管，供应商的人员变更没人约束。

七、不同情况下的取舍

做成员管理，本质是在几组矛盾里做取舍。下面四组是我在实际项目里最常遇到的。

1. 严谨度与立项速度的取舍

如果项目窗口期很紧，比如必须在一个季度内完成合规整改，那么可以把授权边界和备份机制放到立项后两周内补齐，但结果责任和投入比例必须在立项时确定。这两项是不能省的底线。

反过来，如果项目周期超过 6 个月，前期多花 3 到 5 天把承诺做扎实，回报会非常明显，尤其是跨部门项目。

2. 全员共识与核心小组的取舍

追求全员共识看起来很稳妥，实际会拖慢立项。我的做法是：核心层达成深度共识，接口层达成接口协议，知会层只需要知情。要求所有人都理解全部细节，通常意味着所有人都不会真正理解。

3. 集中资源与并行推进的取舍

把最关键的 2 到 3 个人集中到一个项目上，短期交付速度最快，但会形成严重的单点依赖和部门抵触。并行推进能平衡部门关系，代价是关键角色的投入被稀释。

我的建议是：在关键路径上的角色必须集中投入，非关键路径可以并行。判断标准是这个角色一旦延迟 5 天，是否会影响项目里程碑。

4. 工具化与轻量表格的取舍

项目数量少、周期短、成员稳定时，一张维护良好的表格就够了。但当一个 PMO 同时管理 8 个以上项目、涉及 5 个以上部门时，表格的版本问题会迅速放大。

这时候值得考虑把成员角色、投入约束、权限边界放进项目管理平台。像前面提到的场景，PingCode 这类支持私有化部署、支持从 Jira 平滑迁移的平台，在跨项目资源冲突视图和成员权限分层上能减少不少人工核对。但前提是你已经想清楚了角色和承诺是什么，工具只能固化你已经想明白的规则，不能替你想。

八、立项成员管理八步操作 SOP

这一节给一套可以直接套用的操作步骤。时间以立项评审会当天为 T 日，前面用负数表示会前。

1. 完整步骤清单

1. T-10：输出无名字的角色清单。按交付物拆解责任角色、审批角色、配合角色，先不填人名。
2. T-7：按四道准入问题筛选候选人。形成 1.5 倍于实际需求的候选池，留出淘汰空间。
3. T-5：与候选人直属主管做产能面谈。每次 30 分钟，确认 FTE、起止时间、优先级排序。
4. T-3：确定核心成员并做单点风险识别。对每个关键角色问”如果他明天离开怎么办”。
5. T-1：签发《项目角色与承诺表》。取得成员本人和直属主管的书面确认。
6. T 日：立项评审会中单列 15 至 20 分钟讨论成员议题。这一项不接受”会后再议”。
7. T+1：在项目管理系统中建立角色、权限与容量约束。把承诺变成系统里的基线，而不是文档里的描述。
8. T+5：首次成员对齐会。确认接口关系与授权边界，形成成员基线版本。

这八步里，最容易跳过的是第 3 步和第 7 步。第 3 步被跳过，产能承诺就是空的；第 7 步被跳过，所有承诺都只停留在文档里，执行期可以随时被推翻。

2. 角色与承诺表模板

下面是我在实际项目里用的模板结构，可以直接改成你所在组织的字段。放在项目仓库里作为唯一基线，任何变更都走版本控制。

project_roles:

role_name: 业务规则责任人

layer: core # core / interface / inform

person: 张某某

department: 生产部

deliverable: 主数据规则说明书 v1

accountable: true # 唯一结果责任人

commitment:

fte: 0.5

start: 2024-03-01

end: 2024-08-31

approved_by: 生产部主管

authority:

budget_limit: 50000 # 可自主审批金额上限（元）

scope_change: 5% # 可自主确认的范围变更比例

veto: [数据口径变更]

backup: 李某某

single_point_risk: false

这个模板里，accountable 为 true 的角色在一个交付物上只能有一个。如果出现两个，说明责任还没定义清楚，需要回去重新拆交付物。

九、常见问题答疑

1. 项目成员由项目经理定，还是由 PMO 定？

PMO 定规则和门槛，项目经理定具体人选，业务和部门主管定投入承诺。三方缺一不可。我见过 PMO 直接指派成员的，结果执行期部门不认；也见过完全由项目经理私下协调的，主管不知情。职责要分清。

2. 核心成员一直定不下来怎么办？

通常不是人的问题，是范围的问题。如果某个交付物找不到责任人，很可能这个交付物本身就不该由这个项目承担。这时候应该缩小范围或调整目标，而不是硬塞一个人进去凑数。

3. 兼职成员投入比例怎么定才合理？

我的经验值：核心层兼职成员不低于 0.4 FTE，接口层 0.1 到 0.3 FTE，低于 0.1 FTE 的角色不要放在接口层，直接放知会层。低于 0.2 FTE 却承担关键交付的角色，基本都会成为进度风险。

4. 成员承诺了但执行期不兑现，怎么办？

先看承诺是否书面、是否经主管确认。如果都有，就升级到项目指导委员会，按基线处理；如果只有口头承诺，那说明问题出在立项流程本身，先补流程再谈追责。这也是为什么我坚持 T-1 必须拿到书面确认。

十、总结与下一步

回到最开始那个数字：立项会上 4 到 7 分钟的成员讨论，决定了执行期 3 到 6 周的额外成本。这个杠杆比看起来很不对称，但它是真实存在的。

我的核心观点只有一句：立项阶段做项目成员，做的不是”名单”，而是三份可验证的承诺，结果责任、投入产能、决策授权，再加上一个单点风险的备份安排。核心成员控制在 7 人以内，分层管理，承诺前置，这是我在多个项目里反复验证过的组合。

如果你现在手上正好有一个即将立项的项目，下一步可以做三件事：第一，把现有成员表按核心层、接口层、知会层重新分一次，看看核心层有多少人；第二，找出每个交付物的唯一责任人，写不出唯一责任人的交付物先标红；第三，安排 T-5 的产能面谈，把投入比例和授权边界落到纸面。

这三件事加起来，大概需要 2 到 3 天。和它可能省下的 3 到 6 周相比，这是立项阶段性价比最高的一笔投入。