项目集内多个项目并行推进时，同一角色被反复拉进不同会议、同一交付物出现多个负责人、关键资源在两条排期上同时被占用，这些现象往往被当成单个项目的执行问题处理，结果按下葫芦浮起瓢。诊断的关键是先分清症状属于职责、资源还是依赖，再用证据验证原因，最后判断调整单个项目安排是否足够，还是需要动项目集组成。
要点总览（TL;DR）
- 诊断职责重叠与资源冲突，先把症状归入职责、资源、依赖三类，并用症状分类表记录涉及项目与初步归属。
- 对每类症状提出原因假设，用职责矩阵、资源占用台账、依赖清单逐项取证，标注已证实、已排除或待验证，不把推测当结论。
- 处置按由轻到重顺序：澄清职责边界、建立共享资源占用视图、显式登记跨项目依赖，前三步仍无法消除冲突且目标实质重叠时，再评估调整项目集组成。
- 处置后用同一角色跨项目占用时长、交付物负责人唯一率、依赖按期交接率验证效果，并把职责矩阵与资源台账纳入项目集例行评审防止复发。
先确认症状范围：是局部冲突还是项目集结构问题
诊断的第一步是把现象记录成可核对的事实，而不是停留在“大家都很忙”“协调不动”这类感受描述。建议由项目集管理者牵头，用一张症状分类表收集近一个季度的冲突记录，逐条标注涉及项目、发生时间和初步归属。归属只做粗分类，不急于下结论。
| 症状表现 | 涉及项目 | 初步归属 |
|---|---|---|
| 同一角色被两个以上项目同时排入关键会议或交付节点 | 项目A、项目C | 资源 |
| 同一交付物有多人认领负责，或评审时无人认领 | 项目B、项目D | 职责 |
| 上游项目交付延迟，下游项目排期未同步调整 | 项目A、项目D | 依赖 |
| 两个项目的目标描述高度相似，产出物可互相替代 | 项目B、项目C | 职责/组成 |
归类之后要区分两种性质。单项目执行问题表现为冲突集中在某一个项目内部，例如该项目自身排期过密、角色任命不清，其他项目受影响有限，处置范围主要在该项目内。项目集结构问题表现为冲突跨项目反复出现，同一资源或同一职责在多个项目间被争夺，且调整单个项目后冲突转移到别处。判断依据是冲突的复发性和跨项目分布，而不是冲突的严重程度。
这里需要明确项目集的边界。项目集以协调一组关联工作、获取单独管理各项目无法获得的共同收益为核心特征，项目之间存在共享资源、共同交付物或前后依赖。若只是若干互不关联的项目并列推进，遇到的是资源撞车，处理方式更接近多项目资源协调，不宜套用项目集结构诊断。此外，若问题实质是“这些项目是否都值得做”，属于项目组合层面的投资取舍与优先级排序，不在本文诊断范围内，应转入组合管理流程处理。
列出原因假设并用证据逐项排除
症状归类完成后，针对每一类症状提出原因假设，并为每条假设指定取证方式和证据来源。诊断纪律在于：假设只是待验证的判断，只有拿到可比对的材料后才能标注“已证实”或“已排除”，暂时拿不到证据的标为“待验证”，继续留在清单上，不用推测填补。
| 原因假设 | 取证方式 | 验证结论 |
|---|---|---|
| 假设一：职责边界未定义，或同一职责被跨项目重复授权 | 调取各项目职责矩阵（RACI或类似形式），与角色任命文件、项目章程逐项比对，重点看同一交付物是否出现多个A（负责）或空缺 | 已证实/已排除/待验证 |
| 假设二：共享资源没有统一调度口径 | 建立资源占用台账，按人按周记录各项目承诺投入比例，与各项目排期表比对，找出合计投入超过可用工时的时段 | 已证实/已排除/待验证 |
| 假设三：项目间依赖未显式登记 | 整理跨项目依赖清单，标注上游交付物、下游接收方和约定交接时间，与双方里程碑对齐检查是否存在未登记的隐性依赖 | 已证实/已排除/待验证 |
| 假设四：项目集组成本身不合理，多个项目目标高度重叠 | 比对项目目标陈述与预期收益，检查是否存在产出物可互相替代、收益重复计算的情况 | 已证实/已排除/待验证 |
取证时注意两个常见偏差。一是只查文档不查实际，职责矩阵写得清楚但实际执行中负责人已被调走，需要补充访谈或工作记录核对。二是把资源冲突直接归因于“人不够”，而台账显示的是同一批人在多个项目重复承诺，问题出在调度口径而非总量。假设四的验证要格外谨慎，目标表述相似不等于组成不合理，需要看到产出物层面的实质重叠才能支撑结论。
四条假设的验证结果会指向不同的处置重心：假设一成立，优先做职责澄清；假设二成立，优先建资源视图；假设三成立，优先补依赖登记；只有假设四成立，才需要进入项目集组成调整的讨论。多条同时成立时，按后文顺序逐层处理。
按排查顺序处置：从职责澄清到组成调整
处置遵循由轻到重的顺序，前一步完成并观察一段时间后再决定是否进入下一步，避免冲突尚未定性就调整组织结构。每一步都设定适用条件和停止点。
第一步：澄清职责边界。适用条件是假设一已证实。做法是逐个交付物确认唯一负责人，明确协作角色和审批角色，跨项目共用的角色要写清在各项目中的投入优先级。产物是更新后的职责矩阵，完成标志是所有关键交付物都有且只有一个负责人。风险在于职责重新划分可能触及既有考核关系，调整前应与相关方沟通并保留原矩阵版本，便于回溯。
第二步：建立项目集层面的共享资源占用视图。适用条件是假设二已证实。做法是把各项目的资源承诺按人、按周汇总到一张台账，标出超载时段，由项目集管理者统一协调优先级，而不是各项目经理私下协商。产物是资源占用台账和调度规则，完成标志是超载时段有明确的取舍结论。风险在于统一调度会削弱单个项目经理的自主权，需要事先约定哪些资源纳入统一口径、哪些仍由项目自管。
第三步：显式登记跨项目依赖并设置交接点。适用条件是假设三已证实。做法是建立依赖清单，每条依赖写明上游交付物、下游接收方、约定交接时间和验收标准，并在双方里程碑上设置对应的交接检查点。产物是依赖清单与更新后的里程碑，完成标志是每条依赖都有责任人和交接时间。
第四步：评估调整项目集组成。适用条件是前三步执行后冲突仍然反复出现，且假设四已证实存在实质性的目标重叠或收益重复。可选动作包括合并目标重叠的项目、拆分过大的项目、将关联度低的项目移出项目集。这一步涉及组织调整，执行前须备份现有计划、职责矩阵和资源台账，通知所有受影响的相关方，并设定停止点：若调整方案在评审中无法就收益归属达成一致，暂停调整，回到前三步检查是否还有未消除的职责或依赖问题。项目移出后要同步更新资源台账和依赖清单，避免留下悬空承诺。
在项目集管理工具中承载上述动作，可以把职责矩阵、资源占用视图和依赖清单放在同一项目集空间内维护，让职责变更、资源承诺和依赖交接的状态变化对相关方可见。ONES 项目集管理支持将关联项目纳入统一视图，工作项与里程碑的状态更新可被跨项目查看，适合作为职责矩阵、资源台账和依赖登记的落地载体；具体配置方式需结合团队现有流程确定。
验证恢复效果并防止冲突复发
处置完成后需要用指标确认冲突是否真正缓解，而不是凭“最近没人抱怨”判断。建议选取三个可量化指标，在处置前建立基线，处置后按固定周期复查。
| 验证指标 | 口径说明 | 复查周期 | 责任人 |
|---|---|---|---|
| 同一角色跨项目占用时长 | 按周统计关键角色在各项目的承诺投入合计，观察是否仍持续超过可用工时 | 每两周 | 项目集管理者 |
| 交付物负责人唯一率 | 关键交付物中负责人唯一且明确的比例 | 每月 | 各项目经理汇总 |
| 依赖按期交接率 | 依赖清单中按约定时间完成交接的条目占比 | 每月 | 依赖上下游双方确认 |
复查时点建议设在处置后第二周和第一个月末各一次，前者看短期是否止血，后者看是否稳定。指标未达预期时，先回到原因假设清单检查是否有标为“待验证”的条目尚未取证，再判断是否需要进入下一步处置，而不是直接跳到组织调整。
复发预防依靠机制而非一次性整改。把职责矩阵和资源占用台账纳入项目集例行评审议程，每次评审核对新增或变更的职责任命是否已更新矩阵、新承诺的资源投入是否已进入台账、新识别的跨项目依赖是否已登记。项目集组成发生变化时，同步触发这三项内容的复核。这样职责、资源和依赖的状态始终有据可查，冲突在积累成事故之前就能被发现。
常见问题
职责矩阵写得很清楚，但实际执行中还是出现职责重叠，诊断时应该先查什么？
先核对矩阵与实际执行是否一致，而不是直接修改矩阵。可以调取角色任命文件、项目章程和近期工作记录，重点看同一交付物是否出现多个负责人或负责人已调离但矩阵未更新。若矩阵本身清楚、执行偏离，问题更可能出在任命变更未同步或跨项目授权未协调；若矩阵本身存在多个负责人或空缺，则属于职责边界未定义。两种情况的处置动作不同，先分清再动手。
资源冲突反复出现，但各项目排期看起来并不满，这种情况怎么判断原因？
排期表上的投入比例不等于实际占用。建议按人按周建立资源占用台账，把各项目承诺投入比例汇总，与可用工时比对，找出合计投入超过可用工时的时段。若台账显示同一批人在多个项目重复承诺，问题出在调度口径而非总量不足；若台账显示总量确实超载，则需要项目集层面统一协调优先级。两种结论对应不同的处置重心，不宜直接归因为“人不够”。
什么情况下才需要调整项目集组成，而不是继续在单个项目内协调？
调整项目集组成属于较重的处置动作，适用条件是前三步（澄清职责边界、建立共享资源占用视图、显式登记跨项目依赖）执行后冲突仍然反复出现，且已证实多个项目存在实质性的目标重叠或收益重复，例如产出物可互相替代、收益被重复计算。仅目标描述相似不足以支撑结论。执行调整前须备份现有计划、职责矩阵和资源台账，通知受影响相关方，并设定停止点：若评审中无法就收益归属达成一致，暂停调整，回到前三步检查是否还有未消除的职责或依赖问题。
处置后指标没有明显改善，应该直接进入组织调整吗？
不建议直接跳到组织调整。先回到原因假设清单，检查是否有标为“待验证”的条目尚未取证，尤其是职责矩阵与实际执行是否一致、资源台账口径是否覆盖全部共享资源、依赖清单是否遗漏隐性依赖。若仍有未取证项，先补齐证据再判断；若证据已完整且前三步处置确已执行到位，冲突仍反复出现，再评估调整项目集组成。复查时点建议设在处置后第二周和第一个月末各一次，前者看短期是否止血，后者看是否稳定。
