The roadmap sessions surfaced twelve conflicts. Resource conflicts where two workstreams need the same people during the same period. Timing conflicts where a milestone date does not account for an upstream dependency. Scope conflicts where two workstreams claim overlapping deliverables. Assumption conflicts where two teams are planning against incompatible premises. identifying twelve conflicts during planning is progress. Many programs do not surface them at all and discover them during execution instead. But identifying conflicts is the beginning of the work, not the end. The question is what happens to those twelve conflicts between the planning session and the start of execution.
The Conflict List Problem
Most programs that identify conflicts during planning create a list. The list captures what the conflict is, which workstreams are involved, and sometimes a brief description of the impact. The list goes into a slide deck or a shared document. Someone presents it at the next steering committee meeting. The steering committee acknowledges the conflicts and asks the program team to “work through them.” This is where the process typically stalls. “Work through them” is not a resolution protocol. It does not name who is responsible for each resolution. It does not specify by when. It does not define what resolution means. It does not establish what happens if the conflict is not resolved by the deadline. The conflicts sit on the list. Some get resolved informally through side conversations between workstream leads. Some get deferred because the resolution requires a decision that no one wants to make. Some are forgotten because the list is not actively managed. When execution starts, the unresolved conflicts reappear. They reappear as crises because execution adds time pressure and consequences that planning did not have. Programs that failed with good plans documents this pattern repeatedly: conflicts identified during planning, acknowledged by leadership, and left unresolved until execution forced a resolution under worse conditions.
What Execution-Grade Conflict Resolution Looks Like
An execution-grade Conflict Log differs from a conflict list in several ways. Named resolution owners. Each conflict has a specific individual (not a team, not a committee) responsible for driving it to resolution. The resolution owner is not necessarily the person who makes the decision. The resolution owner is the person responsible for ensuring the decision gets made, the affected parties are consulted, and the resolution is documented. Resolution deadlines. Each conflict has a date by which it must be resolved. The deadline is set based on when the conflict would affect execution if left unresolved. A resource conflict that affects month-one activities needs resolution before execution starts. An assumption conflict that affects month-six activities can be resolved during the first quarter. The deadlines create urgency and enable prioritization. Resolution criteria. Each conflict has a defined resolution state. For a resource conflict, resolution means a specific allocation decision documented and accepted by both workstreams. For a timing conflict, resolution means an adjusted milestone date with updated dependencies. For a scope conflict, resolution means a boundary decision documented in both workstream definitions. The team can objectively assess whether a conflict is resolved or still open. Escalation protocol. When a conflict cannot be resolved by the resolution owner within the workstream leads, there is a defined path for escalation. The protocol specifies who can escalate, to whom, and what information the escalation must include. The governance model (from the Architecture Blueprint) provides the escalation hierarchy. The risk nobody put on the register connects to conflict resolution: unresolved conflicts are risks. Every conflict that enters execution unresolved is a risk that the team has identified but not mitigated.
The Four Conflict Types and Their Resolution Patterns
Resource conflicts arise when multiple workstreams need the same resources during the same period. These often trace back to how Workstream Scoping defined boundaries and resource ownership. Resolution options: rephase one workstream to avoid the collision, secure additional resources, reduce the scope of one workstream to decrease resource demand, or accept a longer timeline. The resolution always involves a trade-off, and the trade-off should be made explicitly during planning rather than implicitly during execution. Timing conflicts arise when a milestone date does not account for upstream dependencies. Resolution options: adjust the downstream milestone date, accelerate the upstream dependency, remove the dependency by changing the design, or accept the risk that the downstream milestone may slip. Timing conflicts are often symptoms of optimism: the original dates were set without considering the dependency chain. Scope conflicts arise when two workstreams claim overlapping deliverables or when a deliverable sits in the gray area between workstream boundaries. Resolution: a boundary decision that assigns the deliverable to exactly one workstream, documented in both workstream definitions. Scope conflicts that are not resolved produce duplicate work or, worse, deliverables that fall between workstreams and are not produced by either. Assumption conflicts arise when two teams are planning against incompatible premises. One team assumes a specific technology platform; the other assumes a different one. One team assumes a sequential rollout; the other assumes a parallel rollout. Resolution requires identifying the assumption, determining which premise the program will adopt, and updating both teams’ plans to reflect the decision. The roadmap that tells you nothing describes roadmaps built on unresolved assumption conflicts: the timeline looks coherent because no one has checked whether the assumptions underneath it are internally consistent.
The Resolution Cadence
Conflict resolution is not a single event. It is a process that runs through the roadmap sessions and continues until execution starts. During roadmap sessions: Conflicts are surfaced and logged as they emerge from dependency mapping, milestone sequencing, and resource overlay exercises. Initial resolution owners and deadlines are assigned. Conflicts that can be resolved in the session are resolved immediately. Between sessions: Resolution owners drive their assigned conflicts toward resolution. They convene the affected parties, develop options, and make (or recommend) decisions. Conflicts that require escalation are escalated through the governance model. At the final roadmap review: The conflict log is reviewed in full. Every conflict should be either resolved (with documented resolution) or formally accepted as a residual risk with a management plan. A conflict log with more than two or three unresolved items at the end of roadmap sessions signals that the roadmap is not execution-grade. The cadence creates accountability. When resolution owners know their conflicts will be reviewed at the next session, the conversations happen between sessions. When the final review requires a clean conflict log, the urgency to resolve increases as the deadline approaches.
What Unresolved Conflicts Cost
Every conflict that enters execution unresolved will be resolved during execution. The difference is the cost of resolution. A resource conflict resolved during planning is a sequencing adjustment. The same conflict resolved during execution is a crisis: missed milestones, emergency contractor procurement, and team burnout. A timing conflict resolved during planning is a date change in a spreadsheet. The same conflict resolved during execution is a cascade through dependent milestones, a revised timeline presentation to the steering committee, and a credibility loss that makes future timeline commitments less trusted. The question is whether your program resolves its conflicts during planning when the cost is a difficult conversation: or whether those conflicts enter execution unresolved, where the cost is measured in delays, rework, and credibility.
Keep Reading
New to the Integrated Roadmap? Start with the foundations:
Ready to benchmark your work against best-in-class? See what excellence looks like: