技能落地方案：PMO开展资源管理的风险控制案例解析

PMO做资源管理，最危险的信号往往不是“人不够”，而是每个人看起来都有安排、关键项目却持续延期：同一位架构师被三个项目同时列为下周可用，部门报表显示利用率达到 92%，项目经理却仍在等评审、等测试、等决策。资源风险控制的核心，不是把工时填得更满，而是提前识别关键能力、关键时点和关键依赖之间的冲突，并把冲突转化为可选择、可追责的决策。本文用一个明确标注为情景模拟的中大型企业案例，拆解 PMO 如何建立资源风险识别、升级、处置和复盘机制；

其中的数字用于演示判断方法，不代表任何企业的真实经营数据。

一、先讲核心结论：资源管理不是排满日历，而是控制交付风险

1. 资源风险的对象是交付承诺，不只是人员数量

我判断一项资源管理工作是否有效，首先不看利用率，而看关键交付承诺是否有可信的资源保障。一个团队即便有 30 名工程师，如果其中只有 2 人掌握某项核心架构能力，而 4 个项目都把这 2 人当作“可用资源”，实际风险仍然很高。

因此，PMO要管理的不只是“谁有空”，还包括能力是否匹配、可用时间是否真实、工作是否能并行、替补是否具备资格，以及资源冲突发生后谁有权做取舍。缺少其中任何一环，资源计划都可能只是表格上的承诺。

核心结论是：先锁定关键路径上的稀缺能力，再管理普通资源的负荷；先控制高影响冲突，再追求整体利用率。如果把所有岗位都用同一种工时口径管理，容易让最关键的风险淹没在平均值里。

2. PMO要形成闭环，而不是只收集资源计划

资源管理可以压缩成一个闭环：建立需求口径、核验实际可用量、识别供需冲突、评估影响、确定处置、跟踪结果、复盘预测偏差。PMO的价值不在于替各部门“分人”，而在于让冲突及其代价变得可见，让有决策权的人及时选择。

如果PMO只在项目启动时收一次需求，后续不更新，资源计划很快就会过期。人员请假、关键缺陷、需求变更、供应商延迟、跨项目支援都会改变可用能力。一个能被信任的机制，必须让变更及时进入同一套风险视图。

3. 不要用高利用率掩盖脆弱性

利用率高不等于交付效率高。资源持续接近满负荷时，临时缺陷、评审等待和优先级变化更容易形成队列。此时每个团队都看似忙碌，但系统缺少吸收波动的余量。PMO应同时观察负荷、关键岗位替补、等待时间和承诺兑现率，而不是把单一利用率当成管理目标。

下表中的阈值是建议基准，不是行业统一标准。企业应以历史交付数据校准，并按岗位稀缺程度、工作可预测性和业务后果调整。

二、背景和真实场景：计划看起来完整，关键能力却被重复承诺

1. 情景设定：三个项目争用同一组稀缺能力

为避免把模拟数据误写成真实企业案例，以下案例明确标注为情景模拟。设想一家约 600 人的企业，同时推进客户平台改造、数据治理和内部流程升级。PMO汇总计划后发现，三个项目都需要同一位资深架构师参与方案评审，也都需要同一名安全专家完成上线前检查。

项目计划各自看起来合理：平台项目认为架构师能投入每周两天，数据治理项目也按每周两天排了任务，流程升级项目则把评审安排在月末。实际情况是，架构师每周可用于项目工作的时间只有三天，剩余时间还要承担生产支持和技术决策。三个项目的承诺之和超过了可用量，冲突却没有出现在任何一个项目的单独计划里。

这类问题在组织内并不少见。项目团队通常按自身目标申请资源，职能部门则按人员编制和日常工作安排资源。两套视角都可能成立，却没有自动产生企业级优先级。PMO若只把计划汇总成一张表，得到的只是冲突清单，尚未形成风险控制。

2. 风险如何从排程问题演变成业务问题

在模拟案例中，架构评审延后会影响接口方案冻结；接口方案未冻结，开发团队便可能先按假设实现；后续发现设计不兼容，就需要返工。安全专家若在上线前才介入，整改时间会挤压测试和发布窗口。表面上是两个人的日程冲突，实质上是项目依赖顺序和业务承诺同时受到影响。

PMO因此不能只问“谁能支援”，还应追问：该资源参与的是哪项决策或交付物？晚一周会影响哪些后续任务？是否有替代方案？替代方案的成本和风险是什么？这些问题能把资源对话从人员争抢转向可比较的业务后果。

3. 从人员清单改成能力与时段视图

我建议把资源视图至少拆成四层：人员或岗位、能力标签、可用时段、已承诺工作。对关键能力，还要增加独立承担资格、替补人选和交接所需时间。只有“姓名加百分比”的表格，无法判断一个人是否真的能承担任务，也无法识别所谓替补是否需要数周指导。

在案例中，架构师名义上的每周三天可用量，还要扣除固定运维、例会和不可预测支持。PMO若将三天直接视为可排项目产能，会高估供给。可用量应以可重复、可验证的口径计算，并注明计算周期和保留缓冲，而不是把合同工时全部视为可交付工时。

三、常见误区：看见人头，不等于看见风险

1. 误区一：把利用率当成资源管理的唯一目标

利用率适合观察容量使用，却不适合单独评价资源配置质量。一个团队长期达到 95% 利用率，可能只是把等待、返工和临时任务排除在分母之外；也可能意味着没有空间处理紧急缺陷。若PMO把利用率当成唯一目标，部门会倾向于报满计划，项目则可能失去应对变化的余量。

更稳妥的做法是分开看计划负荷、实际投入、等待时间、返工比例和承诺兑现率。若利用率上升而准时交付率下降，说明忙碌没有转化为有效产出。此时应调查工作切换、依赖等待和需求变更，而不是继续要求团队“提高饱和度”。

2. 误区二：把总工时相等当成能力可替换

一个项目缺少 10 人日，并不意味着任意 10 人日都能补上。安全审查、数据建模、业务决策和测试自动化分别需要不同能力。用总工时相抵，容易让关键岗位仍然短缺，同时让非关键岗位出现闲置。

PMO应把需求描述成“能力、交付物、时间窗、最低资格”四项，而不是只写岗位名称或人数。例如，“上线前完成高风险接口的威胁建模，并在第 8 周前签署审查结论”，比“需要安全工程师 5 天”更能支持调配和替代判断。

3. 误区三：资源冲突交给项目经理私下协调

项目经理之间协调可以解决局部的小冲突，但无法解决多个项目争用同一能力时的企业级排序。若没有明确的决策层级，资源分配可能取决于谁先开会、谁声音更大，或者谁已经向业务方承诺了日期。

PMO的职责不是越过业务负责人替项目做所有选择，而是把决策材料准备好：受影响的里程碑、延误成本、替代方案、决策截止时间和未决风险。最终优先级应由拥有相应业务责任的人确认，并在资源台账中保留决定和理由。

4. 误区四：有工具就等于有治理

工具可以帮助记录需求、冲突和状态，却不能替组织定义什么叫“可用”、谁有权调整优先级、风险何时升级。字段设计不一致、更新责任不清、审批规则缺失时，系统只会更快地传播错误数据。

对于 100 人以上、跨多个部门并行交付的组织，统一的项目管理平台可以帮助聚合计划、工作项、角色和风险记录。例如，PingCode可用于中大型企业和较大规模组织的项目协同场景；但是否适合具体企业，仍需结合权限模型、流程复杂度、集成要求、数据治理和实际使用负担评估。先定义治理口径，再决定工具配置；不能把采购平台当作资源治理本身。

5. 误区五：只在季度计划时做一次资源盘点

季度盘点适合看容量和组合优先级，却不足以控制周级别的冲突。关键岗位可能在一次生产事故、一次临时审计或一次需求变更后迅速失去可用时间。若资源计划不随重大变化更新，PMO看到的只是历史状态。

建议采用分层节奏：组合层每月审视关键能力供需和项目优先级，项目层每周检查未来数周的冲突，重大事件发生时即时更新。节奏不必处处高频，重要的是关键资源和关键节点有足够快的反馈通道。

四、专业判断逻辑：把资源冲突变成可决策的风险

1. 先把需求写成可验证的资源承诺

资源需求应围绕工作结果表达。至少包括交付物、所需能力、开始与结束时间、投入量级、依赖关系、最低资格和需求置信度。比如“需要一位资深工程师”过于含糊；“第 5 至第 7 周，每周投入约两天，完成接口方案评审，需具备相关系统架构经验”才可核验。

需求置信度也值得记录。已批准的法定审查与尚未确认的探索性需求，不应拥有相同的资源优先级。PMO可将需求标记为已承诺、待确认、情景预留等状态，避免预估需求被误当成刚性占用。

2. 用供需窗口而非月度总量识别冲突

月度总量会掩盖时间错位。某位专家一个月有 12 人日可用，不代表能满足同一周的两个评审。应按项目阶段和关键节点观察供需曲线，尤其关注设计冻结、集成测试、审计检查、发布窗口等不可轻易移动的时点。

可以把资源需求按周或双周切片。对高度不确定的工作，不要假设精确到小时，而应给出区间和置信度。精细度应服务于决策：如果每周粒度足以发现冲突，就不必让所有岗位填报逐日计划。

3. 评估风险时同时考虑概率、影响和可恢复性

我不建议把风险分数做得过于复杂。PMO至少需要判断三件事：冲突发生的可能性有多大，发生后影响哪些承诺，以及组织能否在关键期限前恢复。一个概率中等但无法替代、影响监管窗口的资源风险，可能比概率较高但可由其他人员接手的普通工作更值得优先处理。

评分可以作为筛查工具，不能取代讨论。建议把影响拆为里程碑延误、成本增加、质量或安全暴露、业务窗口损失四类。再说明缓解动作、负责人和触发条件，这样评分才会导向行动，而非成为周报里的颜色标签。

4. 明确决策权和升级时限

资源冲突的处理速度，取决于谁有权做取舍。项目经理可以调整项目内部任务；职能负责人可以确认能力供给和人员安排；项目组合委员会或业务赞助人则应处理跨项目优先级。PMO负责呈现影响、推动决定、记录承诺和追踪结果。

升级时限应与风险窗口匹配。若冲突可能影响三周后的关键评审，不能等到周会才讨论。建议设置明确触发条件，例如关键资源连续两周超出批准容量、关键任务无合格替补、决策截止日临近仍未定案等。阈值应由组织依据交付周期和风险承受度设定。

5. 处置顺序要优先保护关键路径和不可逆承诺

发生冲突时，我通常建议按以下顺序讨论：先判断是否能调整任务顺序或缩小范围；再判断能否通过替补、结对或外部支持补足能力；随后评估是否可以改变里程碑或发布窗口；最后才讨论跨项目重新分配核心人员。这个顺序不是绝对规则，但能避免一上来就把人从一个项目抽走，却忽略了更低成本的方案。

若项目日期已对客户、监管机构或经营活动作出不可逆承诺，决策要显式评估违约、合规或窗口损失；若日期仍有弹性，则可以比较延后一个里程碑与增加外部资源的成本。所有方案都应写清假设和副作用，避免把“加人”当作没有成本的答案。

五、情景模拟案例：一次资源风险如何被提前化解

1. 识别冲突：从计划表里找出三个不一致

案例中的PMO将未来八周的关键资源需求按周整理，发现三处不一致：第一，架构师三项项目承诺合计每周六人日，但扣除固定支持后只有三人日可用于项目；第二，安全审查需求集中在第七周，安全专家已承担其他项目的上线检查；第三，两个项目把同一名数据工程师列为全职投入，然而其中一个项目的需求尚未通过业务评审。

PMO没有立即决定“谁先拿人”，而是分别验证需求的刚性、时间窗和替代可能性。平台项目的架构评审若晚两周，会推迟接口冻结；数据治理项目的部分建模工作可以先由团队完成，专家在关键评审点参与；流程升级项目的需求尚未批准，资源申请可以暂时降级为预留。

2. 建立风险排序：不只比较项目声量

为避免人为印象主导排序，PMO制作了一张简化的风险评分表。评分采用 1 至 5 的内部量表，仅用于比较该模拟案例中的风险，不是行业标准。影响评分考虑里程碑、业务窗口和恢复难度；可恢复性较低的风险即使发生概率不高，也会上升到优先讨论的位置。

这张表的目的不是把 4 乘以 5 得到一个貌似精确的数字，而是迫使讨论者说清楚：为什么影响高、恢复为什么困难、哪些假设还没有验证。对于分值接近的项目，PMO应保留判断理由，而不是让小数点制造客观性的错觉。

3. 比较方案：资源重排不是唯一选项

PMO与项目负责人、职能负责人一起评估四类处置：调整评审顺序、由资深人员带教替补、缩小首期交付范围、将非关键任务延后。方案比较时，不只看新增成本，还看对关键路径的影响、所需准备时间、质量风险和是否形成新的单点依赖。

4. 做出决定：用组合取舍替代“所有项目都不变”

情景模拟中的决定是：平台项目保留架构师参与关键评审，但把资料预审交给团队完成；数据治理项目安排一名中级工程师先完成可独立的建模任务，架构师只参加两个决策节点；流程升级项目在需求批准前不锁定核心架构资源；安全专家提前检查高风险接口，低风险项按清单由受训替补执行，最终结论仍由合格负责人确认。

这一决定不是让每个项目都拿到原先申请的资源，而是保护最不可逆的业务节点，并把可拆分、可延后或可培养的工作重新安排。PMO记录决策人、资源承诺、有效期限和重新评估条件，避免一项临时安排被误解为永久资源所有权。

5. 观察结果：把结果指标与因果链分开

在这个模拟案例中，假设经过八周跟踪，关键评审按调整后的窗口完成，未发生因架构冲突造成的接口返工；替补人员完成了低风险检查，但高风险审查仍由资深专家签署。这里的结果是情景推演，不是实测成效。它说明的不是某种方案必然成功，而是资源决策需要同时设定过程指标和结果指标。

过程指标可以观察冲突提前发现天数、需求口径完整率、决策等待时间、替补覆盖率；结果指标则看里程碑兑现、返工、缺陷逃逸和临时加班。若只记录“已协调完成”，无法判断协调是否真正降低了风险。

6. 复盘预测偏差：改进下一轮资源计划

复盘时，PMO应核对预测与实际的差异来源：需求是否临时增加、实际可用时间是否被高估、替补是否达到资格要求、日常支持是否漏计、任务是否因等待其他团队而无法启动。把偏差归因到具体输入，才能改善下一轮预测。

若架构师每周可用时间长期低于计划，问题可能不在项目经理估算，而在岗位容量口径；若需求常在评审前两周才确认，问题可能在治理流程和业务决策时点。把所有偏差归咎于“执行不力”，只会使团队下次更谨慎地填报，却不会改善资源可见性。

六、落地方法：从一张表开始，逐步建立资源风险控制机制

1. 第一步：定义统一字段和数据责任

不要一开始就搭建庞大的资源数据库。先确定最小可用字段，并指定谁提供、谁核验、多久更新。数据责任通常分散在项目经理、职能负责人和PMO之间，必须避免同一字段由多人随意修改却没人对准确性负责。

• 项目需求：项目经理提交交付物、能力、时段和需求置信度。
• 可用产能：职能负责人确认固定职责、请假、支持工作和可分配容量。
• 优先级：业务赞助人或组合决策机制确认跨项目排序。
• 风险状态：PMO维护冲突、影响、处置、负责人和复核日期。
• 实际投入：团队按组织允许的粒度记录，避免为记录而记录。

字段需要足以支持决策，但不应要求每个人填报无法验证的精细数据。若组织无法可靠记录逐小时投入，就采用周级区间和任务交付记录，明确数据只是容量估算，不伪装成精确测量。

2. 第二步：先管理关键岗位，再扩展到全员

全面管理每位员工的每周负荷，成本很高，也容易引发监控感。初期应聚焦关键岗位、关键能力和跨项目共享资源，例如架构、安全、数据治理、法务审查、测试环境维护等。发现机制有效后，再决定是否扩展到更多团队。

优先级可以按业务影响、替代难度和需求集中度筛选。某项能力即便只由少数人承担，只要多个关键项目都依赖它，就值得进入资源风险台账。反之，能够快速替换、交接成本低的常规工作，未必需要同等治理强度。

3. 第三步：建立会议节奏和升级规则

会议应服务于决策，而不是重复朗读状态。建议在周度资源冲突会上，只讨论超过阈值、接近关键节点或需要跨部门取舍的事项；月度组合会上再讨论容量结构、项目优先级和长期能力建设。会前由PMO发送冲突清单和方案，让决策者提前准备。

每个风险项都应有一个明确的决策截止日期。会议纪要至少记录选择了什么、未选择什么、谁承担后果、何时复核。没有期限的“持续关注”很容易变成无人负责的延期决定。

4. 第四步：把工具配置到治理流程中

当组织已经明确需求字段、权限和升级流程后，才适合设计系统工作流。项目管理平台可以将项目计划、工作项、角色、风险和审批记录关联起来，减少多份表格反复抄录。配置时要测试：跨项目查看权限是否合理，职能负责人能否更新容量，资源冲突能否被追踪，历史决策是否可审计。

如果团队正评估 PingCode，可以把它作为中大型组织协同与项目管理场景中的候选方案之一，围绕实际流程做试点，而不是仅凭功能清单决定。试点应覆盖一个共享关键资源的项目群，验证字段维护成本、权限适配、数据质量和管理者是否能据此做出更及时的取舍。

5. 第五步：设置有解释力的指标组合

指标应回答“风险是否更早被看到、决定是否更及时、结果是否更稳定”。建议避免把单一指标绑定个人奖惩，否则资源需求可能被少报、实际投入可能被美化。指标首先是治理信号，其次才可能用于绩效讨论。

• 冲突提前发现时间：从首次识别到计划关键节点的天数。
• 需求完整率：包含能力、时段、交付物和负责人信息的有效需求比例。
• 决策等待时间：从冲突升级到有权人确认方案的时间。
• 关键能力替补覆盖率：有合格替补且完成必要交接的关键能力占比。
• 计划承诺兑现率：按批准基线完成的关键里程碑比例，并注明范围变化。
• 计划外工作占比：实际投入中未在计划窗口内出现的工作比例。

七、不同情况下的行动建议：先区分是容量不足还是配置错误

1. 项目很多、资源少：先做组合取舍

当所有项目都说自己“必须优先”时，通常不是排程技巧不足，而是组织没有完成优先级选择。PMO应把项目收益、时效、风险、依赖和资源需求放在同一张组合视图里，要求业务决策者明确哪些承诺需要保留、哪些可以分阶段、哪些应暂停。

此时不应通过平均分配资源来追求表面公平。平均分配可能让所有项目都缺关键能力，结果是每个项目都慢。更合理的方案可能是集中资源完成一批高价值交付，同时让其他项目有计划地等待。

2. 少数专家成为瓶颈：降低单点依赖，不只增加短期容量

如果瓶颈集中在一两个专家，短期可通过集中评审、任务拆分、结对和外部支持缓解。但同时要评估长期知识转移、标准化和授权边界。若每次都靠同一位专家加班，短期交付可能维持，组织风险却会累积。

培养替补并非让新手立即承担高风险签署，而是按任务风险分级：资料准备、低风险检查、重复性分析可以逐步转移；关键决策和高风险批准仍由符合资格的人负责。替补覆盖率必须基于实际资格，而不是名单上多了一个名字。

3. 工作波动大、需求经常变：采用区间预测和缓冲

对于探索性研发、客户交付和故障响应等波动较大的工作，固定到每周每人每小时的计划往往会制造虚假精确。可以采用容量区间、情景计划和滚动窗口：明确基础承诺、可能需求和应急容量，并规定什么变化会触发重新估算。

缓冲不是未使用资源，而是用来吸收不确定性的能力。PMO要要求说明缓冲服务于什么风险、由谁批准启用、启用后如何调整其他承诺。没有规则的缓冲容易变成隐性闲置；没有缓冲的高波动计划则容易依赖持续加班。

4. 团队分散、跨部门协作慢：把等待也纳入资源风险

跨部门项目的瓶颈有时不是人员投入不足，而是决策等待、环境排期或交接延迟。此时增加执行人员未必缩短周期。PMO应记录依赖方的响应时限、待办队列、交付物验收标准和升级联系人，判断问题究竟在产能还是在流转。

如果某团队的工作长期卡在审批或测试环境，应优先改进服务流程、容量预留和接口标准。把等待中的人员记为“已投入”，会掩盖真正的系统瓶颈。

5. 数据不可靠：先降低精度，建立可持续的更新习惯

如果组织没有可靠工时数据，不要急着要求全员逐日填报。可以先从关键任务的计划区间、每周状态和里程碑结果开始，以少量高价值数据形成反馈。随着团队看到这些数据能减少重复争抢，更新质量通常比强制填表更容易改善。

数据质量也要被量化。PMO可抽查需求完整度、实际计划偏差和资源冲突记录，找出常见漏项。对于估算误差较大的团队，应先校准工作拆分和历史基线，而非直接把偏差归因于个人。

八、不同情况下的取舍：速度、公平、成本和韧性不能同时最大化

1. 追求短期速度，还是培养长期能力

外部专家、临时借调和集中投入可能更快解决当前缺口，但会增加成本、交接和知识留存风险。培养内部替补前期较慢，却能减少未来重复瓶颈。若需求是一次性、边界清晰且时间紧，短期外援可能更合算；若关键能力持续影响多个项目，应将能力建设纳入组合投资。

判断时要比较全周期代价，不要只看服务费用。内部专家带教需要时间，但能建立可复用能力；外部支持可能快速交付，却需要权限、合规和成果验收安排。

2. 追求项目公平，还是追求组合价值

公平不等于每个项目分到相同人日。更有意义的公平，是使用透明、一致的规则进行取舍，并让被延后的项目获得明确理由和重新评估时间。若组织必须保留多个项目同时推进，可以给出最低可行资源；若资源不足以保障关键路径，应坦诚调整承诺，而不是制造平均分配的假象。

3. 追求利用率，还是保留应急弹性

稳定、可预测的工作可以更接近计划产能；高变化、高风险、强依赖工作的团队需要更多弹性。将所有岗位设定同一个利用率目标，忽略了工作性质差异。PMO应根据历史波动、故障频率和恢复时间设定缓冲，并定期验证缓冲是否过多或不足。

4. 追求数据精细，还是减少管理负担

更细的数据不一定更有用。若录入工时的成本高于由此减少的决策误差，精细化就是负担。建议采用“能支持选择的最低精度”：组合层看月度容量和关键节点，项目层看周级冲突，任务层只在高风险工作中细化。

工具选择也服从同一原则。系统能力应减少重复录入、加强可追溯性并帮助识别冲突。若员工要在多个系统重复填同一信息，管理收益可能抵不过维护成本。通过试点测量录入耗时、信息完整度和冲突发现效率，再决定扩展范围，比一次性全面上线更稳妥。

九、常见问题：PMO资源管理实践中的关键边界

1. PMO是否应该直接分配每个人的工作？

通常不应。PMO可以建立口径、整合供需、识别冲突、推动取舍并追踪承诺，但人员管理和专业能力判断仍需职能负责人参与。只有当组织明确授权PMO承担组合资源决策时，PMO才应按授权范围进行分配，并保留决策依据。

2. 如何处理项目经理报出的资源需求总是偏高？

不要先假定项目经理故意多报。可以要求需求关联交付物、时间窗和估算依据，并比较历史预测偏差。对尚未批准的需求设为情景预留，对刚性承诺和探索性工作使用不同状态。若同类任务持续高估，再通过历史数据校准估算模型。

3. 资源利用率目标应该设多少？

没有适用于所有岗位的统一数字。重复性、稳定性高的工作与研发、运维、审批类工作，波动程度不同。企业应根据历史计划偏差、突发工作、等待和交付结果设定区间，并避免把利用率直接作为团队排名或个人绩效的唯一依据。

4. 小公司是否需要完整的资源管理系统？

不一定。小型组织可以先用共享台账和固定节奏处理关键冲突；真正需要的是一致口径、清晰责任和可追踪决策。当跨项目数量、权限复杂度和信息重复维护成本上升后，再评估平台化管理是否能带来净收益。

5. 资源冲突发生后，最先做什么？

先确认冲突是否真实：需求是否批准、时间是否重叠、能力是否必须由特定人员承担。随后明确影响和决策截止时间，再比较调序、替补、缩范围、延日期或外部支持等方案。不要在事实尚未核验前直接承诺加人或延期。

十、结语：资源管理最重要的产物，是有依据的取舍

1. 把“人不够”拆成可行动的问题

“人不够”可能意味着总容量不足，也可能是能力不匹配、时间窗冲突、需求未定、依赖等待或优先级未决。PMO越早把这些原因拆开，越能避免把所有问题都推给招聘、加班或工具采购。

本文的情景模拟说明，资源风险控制不是找到一张完美排班表，而是让关键风险在造成延期前可见，让决策者看清不同方案的成本，并把决定落实到负责人、时间和复核条件上。

2. 下一步从一个关键能力和一个项目群开始

如果你准备启动这项工作，可以先选出一个同时服务多个项目的关键能力，选取一个包含三至五个项目的项目群，按周整理未来八至十二周的需求和可用量。记录冲突、影响、替代方案、决定人和复核日期，连续运行四周，再根据实际偏差调整字段和阈值。

真正成熟的资源管理，不是让每个人看起来都很忙，而是让组织知道哪些承诺值得保护、哪些风险必须升级、哪些项目需要调整。当资源分配的依据透明、决定可追溯、预测能复盘，PMO才从报表汇总者转变为交付风险的控制者。